[Pkg-openldap-devel] r844 - in openldap/vendor/openldap-release: . build clients/tools doc doc/drafts doc/guide/admin doc/man/man1 doc/man/man5 doc/man/man8 doc/rfc include libraries/liblber libraries/libldap libraries/libldap_r libraries/liblutil servers/slapd servers/slapd/back-bdb servers/slapd/back-ldap servers/slapd/back-ldbm servers/slapd/back-meta servers/slapd/back-perl servers/slapd/back-relay servers/slapd/back-sql servers/slapd/overlays servers/slapd/schema servers/slurpd
Matthijs Mohlmann
matthijs at alioth.debian.org
Sat Sep 15 10:38:53 UTC 2007
Author: matthijs
Date: 2007-09-15 10:38:52 +0000 (Sat, 15 Sep 2007)
New Revision: 844
Added:
openldap/vendor/openldap-release/doc/drafts/
openldap/vendor/openldap-release/doc/drafts/README
openldap/vendor/openldap-release/doc/drafts/draft-behera-ldap-password-policy-xx.txt
openldap/vendor/openldap-release/doc/drafts/draft-chu-ldap-csn-xx.txt
openldap/vendor/openldap-release/doc/drafts/draft-ietf-ldapbis-authmeth-xx.txt
openldap/vendor/openldap-release/doc/drafts/draft-ietf-ldapbis-bcp64-xx.txt
openldap/vendor/openldap-release/doc/drafts/draft-ietf-ldapbis-dn-xx.txt
openldap/vendor/openldap-release/doc/drafts/draft-ietf-ldapbis-filter-xx.txt
openldap/vendor/openldap-release/doc/drafts/draft-ietf-ldapbis-models-xx.txt
openldap/vendor/openldap-release/doc/drafts/draft-ietf-ldapbis-protocol-xx.txt
openldap/vendor/openldap-release/doc/drafts/draft-ietf-ldapbis-roadmap-xx.txt
openldap/vendor/openldap-release/doc/drafts/draft-ietf-ldapbis-strprep-xx.txt
openldap/vendor/openldap-release/doc/drafts/draft-ietf-ldapbis-syntaxes-xx.txt
openldap/vendor/openldap-release/doc/drafts/draft-ietf-ldapbis-url-xx.txt
openldap/vendor/openldap-release/doc/drafts/draft-ietf-ldapbis-user-schema-xx.txt
openldap/vendor/openldap-release/doc/drafts/draft-ietf-ldapext-acl-model-xx.txt
openldap/vendor/openldap-release/doc/drafts/draft-ietf-ldapext-ldap-c-api-xx.txt
openldap/vendor/openldap-release/doc/drafts/draft-ietf-ldapext-ldapv3-dupent-xx.txt
openldap/vendor/openldap-release/doc/drafts/draft-ietf-ldapext-ldapv3-vlv-xx.txt
openldap/vendor/openldap-release/doc/drafts/draft-ietf-ldapext-locate-xx.txt
openldap/vendor/openldap-release/doc/drafts/draft-joslin-config-schema-xx.txt
openldap/vendor/openldap-release/doc/drafts/draft-lachman-laser-ldap-mail-routing-xx.txt
openldap/vendor/openldap-release/doc/drafts/draft-legg-ldap-acm-admin-xx.txt
openldap/vendor/openldap-release/doc/drafts/draft-legg-ldap-acm-bac-xx.txt
openldap/vendor/openldap-release/doc/drafts/draft-legg-ldap-admin-xx.txt
openldap/vendor/openldap-release/doc/drafts/draft-legg-ldap-binary-xx.txt
openldap/vendor/openldap-release/doc/drafts/draft-legg-ldap-transfer-xx.txt
openldap/vendor/openldap-release/doc/drafts/draft-sermersheim-ldap-chaining-xx.txt
openldap/vendor/openldap-release/doc/drafts/draft-sermersheim-ldap-csn-xx.txt
openldap/vendor/openldap-release/doc/drafts/draft-sermersheim-ldap-distproc-xx.txt
openldap/vendor/openldap-release/doc/drafts/draft-sermersheim-ldap-subordinate-scope-xx.txt
openldap/vendor/openldap-release/doc/drafts/draft-zeilenga-ldap-adlist-xx.txt
openldap/vendor/openldap-release/doc/drafts/draft-zeilenga-ldap-assert-xx.txt
openldap/vendor/openldap-release/doc/drafts/draft-zeilenga-ldap-authzid-xx.txt
openldap/vendor/openldap-release/doc/drafts/draft-zeilenga-ldap-cosine-xx.txt
openldap/vendor/openldap-release/doc/drafts/draft-zeilenga-ldap-dontusecopy-xx.txt
openldap/vendor/openldap-release/doc/drafts/draft-zeilenga-ldap-incr.txt
openldap/vendor/openldap-release/doc/drafts/draft-zeilenga-ldap-managedit-xx.txt
openldap/vendor/openldap-release/doc/drafts/draft-zeilenga-ldap-noop-xx.txt
openldap/vendor/openldap-release/doc/drafts/draft-zeilenga-ldap-readentry-xx.txt
openldap/vendor/openldap-release/doc/drafts/draft-zeilenga-ldap-t-f-xx.txt
openldap/vendor/openldap-release/doc/drafts/draft-zeilenga-ldap-turn-xx.txt
openldap/vendor/openldap-release/doc/drafts/draft-zeilenga-ldap-txn-xx.txt
openldap/vendor/openldap-release/doc/drafts/draft-zeilenga-ldap-uuid-xx.txt
openldap/vendor/openldap-release/doc/drafts/draft-zeilenga-ldap-x509-xx.txt
openldap/vendor/openldap-release/doc/drafts/draft-zeilenga-ldup-sync-xx.txt
openldap/vendor/openldap-release/doc/rfc/
openldap/vendor/openldap-release/doc/rfc/INDEX
openldap/vendor/openldap-release/doc/rfc/rfc1274.txt
openldap/vendor/openldap-release/doc/rfc/rfc2079.txt
openldap/vendor/openldap-release/doc/rfc/rfc2247.txt
openldap/vendor/openldap-release/doc/rfc/rfc2251.txt
openldap/vendor/openldap-release/doc/rfc/rfc2252.txt
openldap/vendor/openldap-release/doc/rfc/rfc2253.txt
openldap/vendor/openldap-release/doc/rfc/rfc2254.txt
openldap/vendor/openldap-release/doc/rfc/rfc2255.txt
openldap/vendor/openldap-release/doc/rfc/rfc2256.txt
openldap/vendor/openldap-release/doc/rfc/rfc2293.txt
openldap/vendor/openldap-release/doc/rfc/rfc2294.txt
openldap/vendor/openldap-release/doc/rfc/rfc2307.txt
openldap/vendor/openldap-release/doc/rfc/rfc2377.txt
openldap/vendor/openldap-release/doc/rfc/rfc2587.txt
openldap/vendor/openldap-release/doc/rfc/rfc2589.txt
openldap/vendor/openldap-release/doc/rfc/rfc2649.txt
openldap/vendor/openldap-release/doc/rfc/rfc2696.txt
openldap/vendor/openldap-release/doc/rfc/rfc2713.txt
openldap/vendor/openldap-release/doc/rfc/rfc2714.txt
openldap/vendor/openldap-release/doc/rfc/rfc2798.txt
openldap/vendor/openldap-release/doc/rfc/rfc2829.txt
openldap/vendor/openldap-release/doc/rfc/rfc2830.txt
openldap/vendor/openldap-release/doc/rfc/rfc2849.txt
openldap/vendor/openldap-release/doc/rfc/rfc2891.txt
openldap/vendor/openldap-release/doc/rfc/rfc2926.txt
openldap/vendor/openldap-release/doc/rfc/rfc3045.txt
openldap/vendor/openldap-release/doc/rfc/rfc3062.txt
openldap/vendor/openldap-release/doc/rfc/rfc3088.txt
openldap/vendor/openldap-release/doc/rfc/rfc3112.txt
openldap/vendor/openldap-release/doc/rfc/rfc3296.txt
openldap/vendor/openldap-release/doc/rfc/rfc3377.txt
openldap/vendor/openldap-release/doc/rfc/rfc3383.txt
openldap/vendor/openldap-release/doc/rfc/rfc3663.txt
openldap/vendor/openldap-release/doc/rfc/rfc3671.txt
openldap/vendor/openldap-release/doc/rfc/rfc3672.txt
openldap/vendor/openldap-release/doc/rfc/rfc3673.txt
openldap/vendor/openldap-release/doc/rfc/rfc3674.txt
openldap/vendor/openldap-release/doc/rfc/rfc3687.txt
openldap/vendor/openldap-release/doc/rfc/rfc3698.txt
openldap/vendor/openldap-release/doc/rfc/rfc3703.txt
openldap/vendor/openldap-release/doc/rfc/rfc3712.txt
openldap/vendor/openldap-release/doc/rfc/rfc3727.txt
openldap/vendor/openldap-release/doc/rfc/rfc3771.txt
openldap/vendor/openldap-release/doc/rfc/rfc3829.txt
openldap/vendor/openldap-release/doc/rfc/rfc3866.txt
openldap/vendor/openldap-release/doc/rfc/rfc3876.txt
openldap/vendor/openldap-release/doc/rfc/rfc3909.txt
openldap/vendor/openldap-release/doc/rfc/rfc3928.txt
openldap/vendor/openldap-release/doc/rfc/rfc4013.txt
openldap/vendor/openldap-release/doc/rfc/rfc4370.txt
openldap/vendor/openldap-release/doc/rfc/rfc4373.txt
openldap/vendor/openldap-release/doc/rfc/rfc4403.txt
openldap/vendor/openldap-release/servers/slapd/schema/corba.schema
openldap/vendor/openldap-release/servers/slapd/schema/core.ldif
openldap/vendor/openldap-release/servers/slapd/schema/core.schema
openldap/vendor/openldap-release/servers/slapd/schema/cosine.schema
openldap/vendor/openldap-release/servers/slapd/schema/java.schema
openldap/vendor/openldap-release/servers/slapd/schema/ppolicy.schema
Modified:
openldap/vendor/openldap-release/CHANGES
openldap/vendor/openldap-release/build/openldap.m4
openldap/vendor/openldap-release/build/version.var
openldap/vendor/openldap-release/clients/tools/common.c
openldap/vendor/openldap-release/clients/tools/common.h
openldap/vendor/openldap-release/clients/tools/ldapcompare.c
openldap/vendor/openldap-release/clients/tools/ldapdelete.c
openldap/vendor/openldap-release/clients/tools/ldapmodify.c
openldap/vendor/openldap-release/clients/tools/ldapmodrdn.c
openldap/vendor/openldap-release/clients/tools/ldappasswd.c
openldap/vendor/openldap-release/clients/tools/ldapsearch.c
openldap/vendor/openldap-release/clients/tools/ldapwhoami.c
openldap/vendor/openldap-release/configure
openldap/vendor/openldap-release/configure.in
openldap/vendor/openldap-release/doc/guide/admin/guide.html
openldap/vendor/openldap-release/doc/man/man1/ldapsearch.1
openldap/vendor/openldap-release/doc/man/man5/slapd-bdb.5
openldap/vendor/openldap-release/doc/man/man5/slapd.conf.5
openldap/vendor/openldap-release/doc/man/man5/slapo-dynlist.5
openldap/vendor/openldap-release/doc/man/man5/slapo-ppolicy.5
openldap/vendor/openldap-release/doc/man/man8/slapadd.8
openldap/vendor/openldap-release/include/portable.hin
openldap/vendor/openldap-release/libraries/liblber/sockbuf.c
openldap/vendor/openldap-release/libraries/libldap/abandon.c
openldap/vendor/openldap-release/libraries/libldap/addentry.c
openldap/vendor/openldap-release/libraries/libldap/ldap-int.h
openldap/vendor/openldap-release/libraries/libldap/os-ip.c
openldap/vendor/openldap-release/libraries/libldap/os-local.c
openldap/vendor/openldap-release/libraries/libldap/request.c
openldap/vendor/openldap-release/libraries/libldap/search.c
openldap/vendor/openldap-release/libraries/libldap_r/thr_debug.c
openldap/vendor/openldap-release/libraries/liblutil/getpeereid.c
openldap/vendor/openldap-release/libraries/liblutil/passfile.c
openldap/vendor/openldap-release/libraries/liblutil/sockpair.c
openldap/vendor/openldap-release/servers/slapd/back-bdb/add.c
openldap/vendor/openldap-release/servers/slapd/back-bdb/back-bdb.h
openldap/vendor/openldap-release/servers/slapd/back-bdb/config.c
openldap/vendor/openldap-release/servers/slapd/back-bdb/filterindex.c
openldap/vendor/openldap-release/servers/slapd/back-bdb/index.c
openldap/vendor/openldap-release/servers/slapd/back-bdb/init.c
openldap/vendor/openldap-release/servers/slapd/back-bdb/modify.c
openldap/vendor/openldap-release/servers/slapd/back-bdb/search.c
openldap/vendor/openldap-release/servers/slapd/back-bdb/tools.c
openldap/vendor/openldap-release/servers/slapd/back-ldap/chain.c
openldap/vendor/openldap-release/servers/slapd/back-ldap/extended.c
openldap/vendor/openldap-release/servers/slapd/back-ldap/search.c
openldap/vendor/openldap-release/servers/slapd/back-ldbm/compare.c
openldap/vendor/openldap-release/servers/slapd/back-ldbm/ldbm.c
openldap/vendor/openldap-release/servers/slapd/back-meta/search.c
openldap/vendor/openldap-release/servers/slapd/back-perl/SampleLDAP.pm
openldap/vendor/openldap-release/servers/slapd/back-relay/config.c
openldap/vendor/openldap-release/servers/slapd/back-relay/op.c
openldap/vendor/openldap-release/servers/slapd/back-sql/entry-id.c
openldap/vendor/openldap-release/servers/slapd/backend.c
openldap/vendor/openldap-release/servers/slapd/backglue.c
openldap/vendor/openldap-release/servers/slapd/backover.c
openldap/vendor/openldap-release/servers/slapd/bconfig.c
openldap/vendor/openldap-release/servers/slapd/connection.c
openldap/vendor/openldap-release/servers/slapd/daemon.c
openldap/vendor/openldap-release/servers/slapd/dn.c
openldap/vendor/openldap-release/servers/slapd/entry.c
openldap/vendor/openldap-release/servers/slapd/init.c
openldap/vendor/openldap-release/servers/slapd/main.c
openldap/vendor/openldap-release/servers/slapd/overlays/Makefile.in
openldap/vendor/openldap-release/servers/slapd/overlays/dynlist.c
openldap/vendor/openldap-release/servers/slapd/overlays/pcache.c
openldap/vendor/openldap-release/servers/slapd/overlays/ppolicy.c
openldap/vendor/openldap-release/servers/slapd/overlays/rwm.c
openldap/vendor/openldap-release/servers/slapd/overlays/rwmmap.c
openldap/vendor/openldap-release/servers/slapd/overlays/syncprov.c
openldap/vendor/openldap-release/servers/slapd/overlays/translucent.c
openldap/vendor/openldap-release/servers/slapd/overlays/valsort.c
openldap/vendor/openldap-release/servers/slapd/proto-slap.h
openldap/vendor/openldap-release/servers/slapd/result.c
openldap/vendor/openldap-release/servers/slapd/sasl.c
openldap/vendor/openldap-release/servers/slapd/schema_init.c
openldap/vendor/openldap-release/servers/slapd/slap.h
openldap/vendor/openldap-release/servers/slapd/syncrepl.c
openldap/vendor/openldap-release/servers/slurpd/st.c
Log:
Load openldap-2.3.38 into openldap/vendor/openldap-release.
Modified: openldap/vendor/openldap-release/CHANGES
===================================================================
--- openldap/vendor/openldap-release/CHANGES 2007-09-15 10:30:38 UTC (rev 843)
+++ openldap/vendor/openldap-release/CHANGES 2007-09-15 10:38:52 UTC (rev 844)
@@ -1,5 +1,74 @@
OpenLDAP 2.3 Change Log
+OpenLDAP 2.3.38 Release (2007/08/20)
+ Fixed slapadd check for ';binary' when required (ITS#5071)
+ Fixed slapd select_backend/ManageDSAit (ITS#4986)
+ Fixed slapd integer/pointer types and overflow (ITS#5035)
+ Fixed slapd AVA_Sort on multivalued RDNs (ITS#5057)
+ Fixed slapd LDIF parsing error handling (ITS#5090)
+ Fixed slapd syncrepl searchbase scope (ITS#5073)
+ Fixed slapd-bdb missing index warning (ITS#5037)
+ Fixed slapd-bdb Quick index for ID 0 (ITS#5052)
+ Fixed slapd-bdb spurious empty DN warnings during add (ITS#5079)
+ Fixed slapd-hdb slapacl behavior (ITS#5087)
+ Fixed slapd-relay configuration (ITS#4322,ITS#4340)
+ Fixed slapd-sql structuralObjectClass issue (ITS#5088)
+ Fixed slapo-ppolicy double-free on shutdown (ITS#5094)
+ Fixed slapo-rwm/slapd-meta dup attrs after mapping (ITS#5091)
+ Fixed slapo-syncprov uninit'd vars (ITS#5048,#5049)
+ Fixed libldap ldap_add_result_entry (ITS#5056)
+ Added client tools support for ppolicy response (ITS#5061)
+ Removed lint
+ Build Environment
+ Fixed macro definition of open() in glibc 2.6 (ITS#5075)
+ Documentation
+ aspell --lang=en_US -c <manpage> (ITS#5076)
+ Debug messages cleaned up (ITS#5085)
+
+OpenLDAP 2.3.37 Release (2007/07/20)
+ Fixed slapd-glue/syncprov interaction (ITS#4623)
+ Fixed slapd-ldap search reference crash (ITS#5025)
+ Fixed slapd-ldbm crash on Compare op (ITS#5044)
+ Fixed slapo-rwm searchFilter double free (ITS#5043)
+ Clarified slapd-perl SampleLDAP.pm usage (ITS#4995)
+ Documentation
+ Fixed slapd.conf(5) for default loglevel (ITS#5027)
+
+OpenLDAP 2.3.36 Release (2007/06/17)
+ Fixed slapd error code on Windows (ITS#4945, #4606)
+ Fixed slapd mutex bug after failed startup (ITS#4957)
+ Fixed slapd sasl failed Bind bug (ITS#4954)
+ Fixed slapd sasl ssf logging (ITS#5001)
+ Fixed slapd tool op init (ITS#4911)
+ Fixed slapd-bdb no-op crasher (ITS#4925)
+ Fixed slapd-config olcLogLevel (ITS#4949)
+ Fixed slapd-config olcModuleLoad replace (ITS#4921,ITS#4923)
+ Fixed slapd-relay crash when no database can be selected (ITS#4958)
+ Fixed slapo-chain RFC3062 passwd exop handling (ITS#4964)
+ Fixed slapo-dynlist multiple group/url[/member] config (ITS#4989)
+ Fixed slapo-pcache handling of abandoned Operations (#5015)
+ Fixed slapo-pcache and -rwm interaction (ITS#4991)
+ Fixed slapo-ppolicy pwdReset/pwdMinAge (ITS#4970)
+ Fixed slapo-ppolicy control cleanup from ITS#4665
+ Fixed slapo-syncprov cookie parsing error (ITS#4977)
+ Fixed slapo-valsort crash on delete op (ITS#4966)
+ Fixed liblber compilation problem (ITS#5007)
+ Fixed libldap referral chasing loop (ITS#4955)
+ Fixed libldap response code handling on rebind (ITS#4924)
+ Fixed libldap SASL_MAX_BUFF_SIZE (ITS#4935)
+ Fixed libldap cldap assert (ITS#4992)
+ Fixed libldap_r thread debug issues (ITS#4972)
+ Fixed liblutil reading passwd from pipe (ITS#4875)
+ Fixed ldap client usage typo (ITS#4939)
+ Build Environment
+ Fixed --disable-overlays Makefile problem (ITS#4988)
+ Fixed HP-UX socklen_t problem (ITS#4629)
+ Documentation
+ Updated ldapsearch(1) with details on -C option (ITS#5009)
+ Updated slapadd(8) with details on -s option
+ Fixed slapd.conf(5) for correct loglevel packets (ITS#5011)
+ Fixed slapo-ppolicy(5) permanent pwdAccountLockedTime (ITS#4978)
+
OpenLDAP 2.3.35 Release (2007/04/09)
Fixed ldapmodify to use correct memory free functions (ITS#4901)
Fixed slapd acl set minor typo (ITS#4874)
@@ -178,7 +247,7 @@
Fixed slapo-syncprov need new CSN with delete syncID sets (ITS#4534)
Fixed slapo-syncprov startup when lastmod is off (ITS#4613)
Fixed slapo-accesslog cn=config purge bug (ITS#4595)
- Fixes slapo-auditlog DB initialization
+ Fixed slapo-auditlog DB initialization
Fixed slapo-ppolicy password hashing bug (ITS#4575)
Fixed slapo-ppolicy password modify pwdMustChange reset bug (ITS#4576)
Fixed slapo-ppolicy control can be critical (ITS#4596)
@@ -364,7 +433,7 @@
OpenLDAP 2.3.16 Release (2006/01/08)
Fixed slapd-bdb reindexing via cn=config not noticed issue (ITS#4260)
Fixed slapd-monitor connection search crash (ITS#4300)
- Flapd slapd cn=config bad ACL syntax modify crash (ITS#4306)
+ Fixed slapd cn=config bad ACL syntax modify crash (ITS#4306)
Fixed slapd ACL/suffix configuration issue (ITS#4307)
Fixed slapd-bdb/hdb cache issue (ITS#4308)
Fixed slapd-bdb/hdb/ldbm suffix add with default referral issue (ITS#4310)
Modified: openldap/vendor/openldap-release/build/openldap.m4
===================================================================
--- openldap/vendor/openldap-release/build/openldap.m4 2007-09-15 10:30:38 UTC (rev 843)
+++ openldap/vendor/openldap-release/build/openldap.m4 2007-09-15 10:38:52 UTC (rev 844)
@@ -1,5 +1,5 @@
dnl OpenLDAP Autoconf Macros
-dnl $OpenLDAP: pkg/ldap/build/openldap.m4,v 1.140.2.12 2007/02/13 04:35:39 kurt Exp $
+dnl $OpenLDAP: pkg/ldap/build/openldap.m4,v 1.140.2.13 2007/08/06 12:32:51 ando Exp $
dnl This work is part of OpenLDAP Software <http://www.openldap.org/>.
dnl
dnl Copyright 1998-2007 The OpenLDAP Foundation.
@@ -627,9 +627,9 @@
}
#if (DB_VERSION_MAJOR > 3) || (DB_VERSION_MINOR >= 1)
- rc = env->open( env, NULL, flags, 0 );
+ rc = (env->open)( env, NULL, flags, 0 );
#else
- rc = env->open( env, NULL, NULL, flags, 0 );
+ rc = (env->open)( env, NULL, NULL, flags, 0 );
#endif
if ( rc == 0 ) {
Modified: openldap/vendor/openldap-release/build/version.var
===================================================================
--- openldap/vendor/openldap-release/build/version.var 2007-09-15 10:30:38 UTC (rev 843)
+++ openldap/vendor/openldap-release/build/version.var 2007-09-15 10:38:52 UTC (rev 844)
@@ -1,5 +1,5 @@
#! /bin/sh
-# $OpenLDAP: pkg/ldap/build/version.var,v 1.7.2.85 2007/04/09 17:22:49 quanah Exp $
+# $OpenLDAP: pkg/ldap/build/version.var,v 1.7.2.94 2007/08/20 17:43:48 kurt Exp $
## This work is part of OpenLDAP Software <http://www.openldap.org/>.
##
## Copyright 1998-2007 The OpenLDAP Foundation.
@@ -15,9 +15,9 @@
ol_package=OpenLDAP
ol_major=2
ol_minor=3
-ol_patch=35
-ol_api_inc=20335
+ol_patch=38
+ol_api_inc=20338
ol_api_current=2
-ol_api_revision=23
+ol_api_revision=26
ol_api_age=2
-ol_release_date="2007/04/09"
+ol_release_date="2007/08/20"
Modified: openldap/vendor/openldap-release/clients/tools/common.c
===================================================================
--- openldap/vendor/openldap-release/clients/tools/common.c 2007-09-15 10:30:38 UTC (rev 843)
+++ openldap/vendor/openldap-release/clients/tools/common.c 2007-09-15 10:38:52 UTC (rev 844)
@@ -1,5 +1,5 @@
/* common.c - common routines for the ldap client tools */
-/* $OpenLDAP: pkg/ldap/clients/tools/common.c,v 1.39.2.11 2007/04/01 22:44:09 quanah Exp $ */
+/* $OpenLDAP: pkg/ldap/clients/tools/common.c,v 1.39.2.13 2007/08/13 20:03:51 ando Exp $ */
/* This work is part of OpenLDAP Software <http://www.openldap.org/>.
*
* Copyright 1998-2007 The OpenLDAP Foundation.
@@ -46,6 +46,8 @@
#include "ldap_defaults.h"
#include "ldap_pvt.h"
#include "lber_pvt.h"
+#include "lutil.h"
+#include "ldif.h"
#include "common.h"
@@ -87,6 +89,7 @@
int referrals = 0;
int protocol = -1;
int verbose = 0;
+int ldif = 0;
int version = 0;
#ifdef LDAP_CONTROL_X_CHAINING_BEHAVIOR
@@ -155,7 +158,7 @@
N_(" abandon, cancel (SIGINT sends abandon/cancel; not really controls)\n")
N_(" -f file read operations from `file'\n"),
N_(" -h host LDAP server\n"),
-N_(" -H URI LDAP Uniform Resource Indentifier(s)\n"),
+N_(" -H URI LDAP Uniform Resource Identifier(s)\n"),
N_(" -I use SASL Interactive mode\n"),
N_(" -k use Kerberos authentication\n"),
N_(" -K like -k, but do only step 1 of the Kerberos bind\n"),
@@ -1272,3 +1275,126 @@
return 0;
}
+#ifdef LDAP_CONTROL_PASSWORDPOLICYREQUEST
+static int
+print_ppolicy( LDAP *ld, LDAPControl *ctrl )
+{
+ int expire = 0, grace = 0, rc;
+ LDAPPasswordPolicyError pperr;
+
+ rc = ldap_parse_passwordpolicy_control( ld, ctrl,
+ &expire, &grace, &pperr );
+ if ( rc == LDAP_SUCCESS ) {
+ char buf[ BUFSIZ ], *ptr = buf;
+
+ if ( expire != -1 ) {
+ ptr += snprintf( ptr, sizeof( buf ) - ( ptr - buf ),
+ "expire=%d", expire );
+ }
+
+ if ( grace != -1 ) {
+ ptr += snprintf( ptr, sizeof( buf ) - ( ptr - buf ),
+ "%sgrace=%d", ptr == buf ? "" : " ", grace );
+ }
+
+ if ( pperr != PP_noError ) {
+ ptr += snprintf( ptr, sizeof( buf ) - ( ptr - buf ),
+ "%serror=%d (%s)", ptr == buf ? "" : " ",
+ pperr,
+ ldap_passwordpolicy_err2txt( pperr ) );
+ }
+
+ tool_write_ldif( ldif ? LDIF_PUT_COMMENT : LDIF_PUT_VALUE,
+ "ppolicy", buf, ptr - buf );
+ }
+
+ return rc;
+}
+#endif
+
+void tool_print_ctrls(
+ LDAP *ld,
+ LDAPControl **ctrls )
+{
+ int i;
+ char *ptr;
+
+ for ( i = 0; ctrls[i] != NULL; i++ ) {
+ /* control: OID criticality base64value */
+ struct berval b64 = BER_BVNULL;
+ ber_len_t len;
+ char *str;
+ int j;
+
+ len = ldif ? 2 : 0;
+ len += strlen( ctrls[i]->ldctl_oid );
+
+ /* add enough for space after OID and the critical value itself */
+ len += ctrls[i]->ldctl_iscritical
+ ? sizeof("true") : sizeof("false");
+
+ /* convert to base64 */
+ if ( ctrls[i]->ldctl_value.bv_len ) {
+ b64.bv_len = LUTIL_BASE64_ENCODE_LEN(
+ ctrls[i]->ldctl_value.bv_len ) + 1;
+ b64.bv_val = ber_memalloc( b64.bv_len + 1 );
+
+ b64.bv_len = lutil_b64_ntop(
+ (unsigned char *) ctrls[i]->ldctl_value.bv_val,
+ ctrls[i]->ldctl_value.bv_len,
+ b64.bv_val, b64.bv_len );
+ }
+
+ if ( b64.bv_len ) {
+ len += 1 + b64.bv_len;
+ }
+
+ ptr = str = malloc( len + 1 );
+ if ( ldif ) {
+ ptr = lutil_strcopy( ptr, ": " );
+ }
+ ptr = lutil_strcopy( ptr, ctrls[i]->ldctl_oid );
+ ptr = lutil_strcopy( ptr, ctrls[i]->ldctl_iscritical
+ ? " true" : " false" );
+
+ if ( b64.bv_len ) {
+ ptr = lutil_strcopy( ptr, " " );
+ ptr = lutil_strcopy( ptr, b64.bv_val );
+ }
+
+ if ( ldif < 2 ) {
+ tool_write_ldif( ldif ? LDIF_PUT_COMMENT : LDIF_PUT_VALUE,
+ "control", str, len );
+ }
+
+ free( str );
+ if ( b64.bv_len ) {
+ ber_memfree( b64.bv_val );
+ }
+
+ /* known controls */
+ if ( 0 ) {
+ /* dummy */ ;
+#ifdef LDAP_CONTROL_PASSWORDPOLICYREQUEST
+ } else if ( strcmp( LDAP_CONTROL_PASSWORDPOLICYRESPONSE, ctrls[i]->ldctl_oid ) == 0 ) {
+ (void)print_ppolicy( ld, ctrls[i] );
+#endif
+ }
+ }
+}
+
+int
+tool_write_ldif( int type, char *name, char *value, ber_len_t vallen )
+{
+ char *ldif;
+
+ if (( ldif = ldif_put( type, name, value, vallen )) == NULL ) {
+ return( -1 );
+ }
+
+ fputs( ldif, stdout );
+ ber_memfree( ldif );
+
+ return( 0 );
+}
+
Modified: openldap/vendor/openldap-release/clients/tools/common.h
===================================================================
--- openldap/vendor/openldap-release/clients/tools/common.h 2007-09-15 10:30:38 UTC (rev 843)
+++ openldap/vendor/openldap-release/clients/tools/common.h 2007-09-15 10:38:52 UTC (rev 844)
@@ -1,5 +1,5 @@
/* common.h - common definitions for the ldap client tools */
-/* $OpenLDAP: pkg/ldap/clients/tools/common.h,v 1.11.2.7 2007/01/02 21:43:41 kurt Exp $ */
+/* $OpenLDAP: pkg/ldap/clients/tools/common.h,v 1.11.2.8 2007/08/13 20:03:51 ando Exp $ */
/* This work is part of OpenLDAP Software <http://www.openldap.org/>.
*
* Copyright 1998-2007 The OpenLDAP Foundation.
@@ -61,6 +61,7 @@
extern int referrals;
extern int protocol;
extern int verbose;
+extern int ldif;
extern int version;
/* Defined in common.c, set in main() */
@@ -89,6 +90,8 @@
char *matched,
char *info,
char **refs ));
+void tool_print_ctrls LDAP_P(( LDAP *ld, LDAPControl **ctrls ));
+int tool_write_ldif LDAP_P(( int type, char *name, char *value, ber_len_t vallen ));
LDAP_END_DECL
Modified: openldap/vendor/openldap-release/clients/tools/ldapcompare.c
===================================================================
--- openldap/vendor/openldap-release/clients/tools/ldapcompare.c 2007-09-15 10:30:38 UTC (rev 843)
+++ openldap/vendor/openldap-release/clients/tools/ldapcompare.c 2007-09-15 10:38:52 UTC (rev 844)
@@ -1,5 +1,5 @@
/* ldapcompare.c -- LDAP compare tool */
-/* $OpenLDAP: pkg/ldap/clients/tools/ldapcompare.c,v 1.34.2.5 2007/01/02 21:43:41 kurt Exp $ */
+/* $OpenLDAP: pkg/ldap/clients/tools/ldapcompare.c,v 1.34.2.6 2007/08/13 18:04:39 quanah Exp $ */
/* This work is part of OpenLDAP Software <http://www.openldap.org/>.
*
* Copyright 1998-2007 The OpenLDAP Foundation.
@@ -238,6 +238,7 @@
char *matcheddn;
char *text;
char **refs;
+ LDAPControl **ctrls = NULL;
if ( not ) {
return LDAP_SUCCESS;
@@ -270,7 +271,7 @@
}
}
- rc = ldap_parse_result( ld, res, &code, &matcheddn, &text, &refs, NULL, 1 );
+ rc = ldap_parse_result( ld, res, &code, &matcheddn, &text, &refs, &ctrls, 1 );
if( rc != LDAP_SUCCESS ) {
fprintf( stderr, "%s: ldap_parse_result: %s (%d)\n",
@@ -300,10 +301,6 @@
}
}
- ber_memfree( text );
- ber_memfree( matcheddn );
- ber_memvfree( (void **) refs );
-
/* if we were told to be quiet, use the return value. */
if ( !quiet ) {
if ( code == LDAP_COMPARE_TRUE ) {
@@ -315,6 +312,15 @@
}
}
+ if ( ctrls ) {
+ tool_print_ctrls( ld, ctrls );
+ ldap_controls_free( ctrls );
+ }
+
+ ber_memfree( text );
+ ber_memfree( matcheddn );
+ ber_memvfree( (void **) refs );
+
return( code );
}
Modified: openldap/vendor/openldap-release/clients/tools/ldapdelete.c
===================================================================
--- openldap/vendor/openldap-release/clients/tools/ldapdelete.c 2007-09-15 10:30:38 UTC (rev 843)
+++ openldap/vendor/openldap-release/clients/tools/ldapdelete.c 2007-09-15 10:38:52 UTC (rev 844)
@@ -1,5 +1,5 @@
/* ldapdelete.c - simple program to delete an entry using LDAP */
-/* $OpenLDAP: pkg/ldap/clients/tools/ldapdelete.c,v 1.109.2.6 2007/01/02 21:43:41 kurt Exp $ */
+/* $OpenLDAP: pkg/ldap/clients/tools/ldapdelete.c,v 1.109.2.7 2007/08/13 18:04:39 quanah Exp $ */
/* This work is part of OpenLDAP Software <http://www.openldap.org/>.
*
* Copyright 1998-2007 The OpenLDAP Foundation.
@@ -211,6 +211,7 @@
int id;
int rc, code;
char *matcheddn = NULL, *text = NULL, **refs = NULL;
+ LDAPControl **ctrls = NULL;
LDAPMessage *res;
if ( verbose ) {
@@ -255,7 +256,7 @@
}
}
- rc = ldap_parse_result( ld, res, &code, &matcheddn, &text, &refs, NULL, 1 );
+ rc = ldap_parse_result( ld, res, &code, &matcheddn, &text, &refs, &ctrls, 1 );
if( rc != LDAP_SUCCESS ) {
fprintf( stderr, "%s: ldap_parse_result: %s (%d)\n",
@@ -287,6 +288,11 @@
}
}
+ if (ctrls) {
+ tool_print_ctrls( ld, ctrls );
+ ldap_controls_free( ctrls );
+ }
+
ber_memfree( text );
ber_memfree( matcheddn );
ber_memvfree( (void **) refs );
Modified: openldap/vendor/openldap-release/clients/tools/ldapmodify.c
===================================================================
--- openldap/vendor/openldap-release/clients/tools/ldapmodify.c 2007-09-15 10:30:38 UTC (rev 843)
+++ openldap/vendor/openldap-release/clients/tools/ldapmodify.c 2007-09-15 10:38:52 UTC (rev 844)
@@ -1,5 +1,5 @@
/* ldapmodify.c - generic program to modify or add entries using LDAP */
-/* $OpenLDAP: pkg/ldap/clients/tools/ldapmodify.c,v 1.158.2.12 2007/04/01 22:44:23 quanah Exp $ */
+/* $OpenLDAP: pkg/ldap/clients/tools/ldapmodify.c,v 1.158.2.13 2007/08/13 20:03:51 ando Exp $ */
/* This work is part of OpenLDAP Software <http://www.openldap.org/>.
*
* Copyright 1998-2007 The OpenLDAP Foundation.
@@ -1165,9 +1165,51 @@
}
if ( ldap_msgtype( res ) != LDAP_RES_INTERMEDIATE ) {
- rc = ldap_result2error( ld, res, 1 );
- if( rc != LDAP_SUCCESS ) ldap_perror( ld, opstr );
- return rc;
+ int code;
+ char *matcheddn = NULL, *text = NULL, **refs = NULL;
+ LDAPControl **ctrls = NULL;
+ rc = ldap_parse_result( ld, res, &code, &matcheddn, &text, &refs, &ctrls, 1 );
+
+ if ( rc != LDAP_SUCCESS ) {
+ fprintf( stderr, "%s: ldap_parse_result: %s (%d)\n",
+ prog, ldap_err2string( rc ), rc );
+ return rc;
+ }
+
+ if ( code != LDAP_SUCCESS ) {
+ tool_perror( prog, code, NULL, matcheddn, text, refs );
+ } else if ( verbose &&
+ ((matcheddn && *matcheddn) || (text && *text) || (refs && *refs) ))
+ {
+ printf( _("Delete Result: %s (%d)\n"),
+ ldap_err2string( code ), code );
+
+ if ( text && *text ) {
+ printf( _("Additional info: %s\n"), text );
+ }
+
+ if ( matcheddn && *matcheddn ) {
+ printf( _("Matched DN: %s\n"), matcheddn );
+ }
+
+ if ( refs ) {
+ int i;
+ for( i=0; refs[i]; i++ ) {
+ printf(_("Referral: %s\n"), refs[i] );
+ }
+ }
+ }
+
+ if (ctrls) {
+ tool_print_ctrls( ld, ctrls );
+ ldap_controls_free( ctrls );
+ }
+
+ ber_memfree( text );
+ ber_memfree( matcheddn );
+ ber_memvfree( (void **) refs );
+
+ return code;
}
#ifdef LDAP_GROUP_TRANSACTION
Modified: openldap/vendor/openldap-release/clients/tools/ldapmodrdn.c
===================================================================
--- openldap/vendor/openldap-release/clients/tools/ldapmodrdn.c 2007-09-15 10:30:38 UTC (rev 843)
+++ openldap/vendor/openldap-release/clients/tools/ldapmodrdn.c 2007-09-15 10:38:52 UTC (rev 844)
@@ -1,5 +1,5 @@
/* ldapmodrdn.c - generic program to modify an entry's RDN using LDAP */
-/* $OpenLDAP: pkg/ldap/clients/tools/ldapmodrdn.c,v 1.106.2.6 2007/01/02 21:43:41 kurt Exp $ */
+/* $OpenLDAP: pkg/ldap/clients/tools/ldapmodrdn.c,v 1.106.2.7 2007/08/13 18:04:39 quanah Exp $ */
/* This work is part of OpenLDAP Software <http://www.openldap.org/>.
*
* Copyright 1998-2007 The OpenLDAP Foundation.
@@ -242,6 +242,7 @@
{
int rc, code, id;
char *matcheddn=NULL, *text=NULL, **refs=NULL;
+ LDAPControl **ctrls = NULL;
LDAPMessage *res;
if ( verbose ) {
@@ -285,7 +286,7 @@
}
}
- rc = ldap_parse_result( ld, res, &code, &matcheddn, &text, &refs, NULL, 1 );
+ rc = ldap_parse_result( ld, res, &code, &matcheddn, &text, &refs, &ctrls, 1 );
if( rc != LDAP_SUCCESS ) {
fprintf( stderr, "%s: ldap_parse_result: %s (%d)\n",
@@ -315,6 +316,11 @@
}
}
+ if (ctrls) {
+ tool_print_ctrls( ld, ctrls );
+ ldap_controls_free( ctrls );
+ }
+
ber_memfree( text );
ber_memfree( matcheddn );
ber_memvfree( (void **) refs );
Modified: openldap/vendor/openldap-release/clients/tools/ldappasswd.c
===================================================================
--- openldap/vendor/openldap-release/clients/tools/ldappasswd.c 2007-09-15 10:30:38 UTC (rev 843)
+++ openldap/vendor/openldap-release/clients/tools/ldappasswd.c 2007-09-15 10:38:52 UTC (rev 844)
@@ -1,5 +1,5 @@
/* ldappasswd -- a tool for change LDAP passwords */
-/* $OpenLDAP: pkg/ldap/clients/tools/ldappasswd.c,v 1.127.2.6 2007/01/02 21:43:42 kurt Exp $ */
+/* $OpenLDAP: pkg/ldap/clients/tools/ldappasswd.c,v 1.127.2.7 2007/08/13 18:04:39 quanah Exp $ */
/* This work is part of OpenLDAP Software <http://www.openldap.org/>.
*
* Copyright 1998-2007 The OpenLDAP Foundation.
@@ -177,6 +177,7 @@
char *matcheddn = NULL, *text = NULL, **refs = NULL;
char *retoid = NULL;
struct berval *retdata = NULL;
+ LDAPControl **ctrls = NULL;
tool_init();
prog = lutil_progname( "ldappasswd", argc, argv );
@@ -310,6 +311,8 @@
goto done;
}
+ tool_server_controls( ld, NULL, 0);
+
rc = ldap_extended_operation( ld,
LDAP_EXOP_MODIFY_PASSWD, bv.bv_val ? &bv : NULL,
NULL, NULL, &id );
@@ -344,7 +347,7 @@
}
rc = ldap_parse_result( ld, res,
- &code, &matcheddn, &text, &refs, NULL, 0 );
+ &code, &matcheddn, &text, &refs, &ctrls, 0 );
if( rc != LDAP_SUCCESS ) {
ldap_perror( ld, "ldap_parse_result" );
rc = EXIT_FAILURE;
@@ -380,9 +383,17 @@
}
ber_free( ber, 1 );
+
+ } else if ( code == LDAP_SUCCESS && newpw.bv_val == NULL ) {
+ tool_perror( "ldap_parse_extended_result", LDAP_DECODING_ERROR,
+ " new password expected", NULL, NULL, NULL );
}
- if( verbose || code != LDAP_SUCCESS || matcheddn || text || refs ) {
+skip:
+ if( verbose || code != LDAP_SUCCESS ||
+ matcheddn || text || refs || ctrls )
+ {
+
printf( _("Result: %s (%d)\n"), ldap_err2string( code ), code );
if( text && *text ) {
@@ -399,6 +410,11 @@
printf(_("Referral: %s\n"), refs[i] );
}
}
+
+ if( ctrls ) {
+ tool_print_ctrls( ld, ctrls );
+ ldap_controls_free( ctrls );
+ }
}
ber_memfree( text );
Modified: openldap/vendor/openldap-release/clients/tools/ldapsearch.c
===================================================================
--- openldap/vendor/openldap-release/clients/tools/ldapsearch.c 2007-09-15 10:30:38 UTC (rev 843)
+++ openldap/vendor/openldap-release/clients/tools/ldapsearch.c 2007-09-15 10:38:52 UTC (rev 844)
@@ -1,5 +1,5 @@
/* ldapsearch -- a tool for searching LDAP directories */
-/* $OpenLDAP: pkg/ldap/clients/tools/ldapsearch.c,v 1.207.2.11 2007/01/02 21:43:42 kurt Exp $ */
+/* $OpenLDAP: pkg/ldap/clients/tools/ldapsearch.c,v 1.207.2.12 2007/08/13 20:03:51 ando Exp $ */
/* This work is part of OpenLDAP Software <http://www.openldap.org/>.
*
* Copyright 1998-2007 The OpenLDAP Foundation.
@@ -163,12 +163,6 @@
static void print_ctrls(
LDAPControl **ctrls );
-static int write_ldif LDAP_P((
- int type,
- char *name,
- char *value,
- ber_len_t vallen ));
-
static int dosearch LDAP_P((
LDAP *ld,
char *base,
@@ -186,7 +180,7 @@
static char *urlpre = NULL;
static char *base = NULL;
static char *sortattr = NULL;
-static int includeufn, vals2tmp = 0, ldif = 0;
+static int includeufn, vals2tmp = 0;
static int subentries = 0, valuesReturnFilter = 0;
static char *vrFilter = NULL;
@@ -1183,9 +1177,9 @@
if ( ldif < 2 ) {
ufn = ldap_dn2ufn( bv.bv_val );
- write_ldif( LDIF_PUT_COMMENT, NULL, ufn, ufn ? strlen( ufn ) : 0 );
+ tool_write_ldif( LDIF_PUT_COMMENT, NULL, ufn, ufn ? strlen( ufn ) : 0 );
}
- write_ldif( LDIF_PUT_VALUE, "dn", bv.bv_val, bv.bv_len );
+ tool_write_ldif( LDIF_PUT_VALUE, "dn", bv.bv_val, bv.bv_len );
rc = ldap_get_entry_controls( ld, entry, &ctrls );
if( rc != LDAP_SUCCESS ) {
@@ -1203,7 +1197,7 @@
if( ufn == NULL ) {
ufn = ldap_dn2ufn( bv.bv_val );
}
- write_ldif( LDIF_PUT_VALUE, "ufn", ufn, ufn ? strlen( ufn ) : 0 );
+ tool_write_ldif( LDIF_PUT_VALUE, "ufn", ufn, ufn ? strlen( ufn ) : 0 );
}
if( ufn != NULL ) ldap_memfree( ufn );
@@ -1217,7 +1211,7 @@
if (bv.bv_val == NULL) break;
if ( attrsonly ) {
- write_ldif( LDIF_PUT_NOVALUE, bv.bv_val, NULL, 0 );
+ tool_write_ldif( LDIF_PUT_NOVALUE, bv.bv_val, NULL, 0 );
} else if ( bvals ) {
for ( i = 0; bvals[i].bv_val != NULL; i++ ) {
@@ -1257,10 +1251,10 @@
&tmpfname[strlen(tmpdir) + sizeof(LDAP_DIRSEP) - 1] );
urlize( url );
- write_ldif( LDIF_PUT_URL, bv.bv_val, url, strlen( url ));
+ tool_write_ldif( LDIF_PUT_URL, bv.bv_val, url, strlen( url ));
} else {
- write_ldif( LDIF_PUT_VALUE, bv.bv_val,
+ tool_write_ldif( LDIF_PUT_VALUE, bv.bv_val,
bvals[ i ].bv_val, bvals[ i ].bv_len );
}
}
@@ -1295,7 +1289,7 @@
if( refs ) {
int i;
for( i=0; refs[i] != NULL; i++ ) {
- write_ldif( ldif ? LDIF_PUT_COMMENT : LDIF_PUT_VALUE,
+ tool_write_ldif( ldif ? LDIF_PUT_COMMENT : LDIF_PUT_VALUE,
"ref", refs[i], strlen(refs[i]) );
}
ber_memvfree( (void **) refs );
@@ -1328,14 +1322,14 @@
}
if ( ldif < 2 ) {
- write_ldif( ldif ? LDIF_PUT_COMMENT : LDIF_PUT_VALUE,
+ tool_write_ldif( ldif ? LDIF_PUT_COMMENT : LDIF_PUT_VALUE,
"extended", retoid, retoid ? strlen(retoid) : 0 );
}
ber_memfree( retoid );
if(retdata) {
if ( ldif < 2 ) {
- write_ldif( ldif ? LDIF_PUT_COMMENT : LDIF_PUT_BINARY,
+ tool_write_ldif( ldif ? LDIF_PUT_COMMENT : LDIF_PUT_BINARY,
"data", retdata->bv_val, retdata->bv_len );
}
ber_bvfree( retdata );
@@ -1366,7 +1360,7 @@
}
if ( ldif < 2 ) {
- write_ldif( ldif ? LDIF_PUT_COMMENT : LDIF_PUT_VALUE,
+ tool_write_ldif( ldif ? LDIF_PUT_COMMENT : LDIF_PUT_VALUE,
"partial", retoid, retoid ? strlen(retoid) : 0 );
}
@@ -1374,7 +1368,7 @@
if( retdata ) {
if ( ldif < 2 ) {
- write_ldif( ldif ? LDIF_PUT_COMMENT : LDIF_PUT_BINARY,
+ tool_write_ldif( ldif ? LDIF_PUT_COMMENT : LDIF_PUT_BINARY,
"data", retdata->bv_val, retdata->bv_len );
}
@@ -1426,7 +1420,7 @@
if( matcheddn ) {
if( *matcheddn ) {
if( !ldif ) {
- write_ldif( LDIF_PUT_VALUE,
+ tool_write_ldif( LDIF_PUT_VALUE,
"matchedDN", matcheddn, strlen(matcheddn) );
} else {
fprintf( stderr, _("Matched DN: %s\n"), matcheddn );
@@ -1439,7 +1433,7 @@
if( text ) {
if( *text ) {
if( !ldif ) {
- write_ldif( LDIF_PUT_TEXT, "text",
+ tool_write_ldif( LDIF_PUT_TEXT, "text",
text, strlen(text) );
} else {
fprintf( stderr, _("Additional information: %s\n"), text );
@@ -1453,7 +1447,7 @@
int i;
for( i=0; refs[i] != NULL; i++ ) {
if( !ldif ) {
- write_ldif( LDIF_PUT_VALUE, "ref", refs[i], strlen(refs[i]) );
+ tool_write_ldif( LDIF_PUT_VALUE, "ref", refs[i], strlen(refs[i]) );
} else {
fprintf( stderr, _("Referral: %s\n"), refs[i] );
}
@@ -1521,7 +1515,7 @@
}
if ( ldif < 2 ) {
- write_ldif( ldif ? LDIF_PUT_COMMENT : LDIF_PUT_VALUE,
+ tool_write_ldif( ldif ? LDIF_PUT_COMMENT : LDIF_PUT_VALUE,
"control", str, len );
}
@@ -1530,22 +1524,6 @@
}
}
-static int
-write_ldif( int type, char *name, char *value, ber_len_t vallen )
-{
- char *ldif;
-
- if (( ldif = ldif_put( type, name, value, vallen )) == NULL ) {
- return( -1 );
- }
-
- fputs( ldif, stdout );
- ber_memfree( ldif );
-
- return( 0 );
-}
-
-
#ifdef LDAP_CONTROL_PAGEDRESULTS
static int
parse_page_control(
Modified: openldap/vendor/openldap-release/clients/tools/ldapwhoami.c
===================================================================
--- openldap/vendor/openldap-release/clients/tools/ldapwhoami.c 2007-09-15 10:30:38 UTC (rev 843)
+++ openldap/vendor/openldap-release/clients/tools/ldapwhoami.c 2007-09-15 10:38:52 UTC (rev 844)
@@ -1,5 +1,5 @@
/* ldapwhoami.c -- a tool for asking the directory "Who Am I?" */
-/* $OpenLDAP: pkg/ldap/clients/tools/ldapwhoami.c,v 1.33.2.5 2007/01/02 21:43:42 kurt Exp $ */
+/* $OpenLDAP: pkg/ldap/clients/tools/ldapwhoami.c,v 1.33.2.6 2007/08/13 18:04:39 quanah Exp $ */
/* This work is part of OpenLDAP Software <http://www.openldap.org/>.
*
* Copyright 1998-2007 The OpenLDAP Foundation.
@@ -118,6 +118,7 @@
struct berval *retdata = NULL;
int id, code=0;
LDAPMessage *res;
+ LDAPControl **ctrls = NULL;
tool_init();
prog = lutil_progname( "ldapwhoami", argc, argv );
@@ -161,7 +162,7 @@
rc = ldap_whoami( ld, NULL, NULL, &id );
if( rc != LDAP_SUCCESS ) {
- ldap_perror( ld, "ldap_extended_operation" );
+ ldap_perror( ld, "ldap_whoami" );
rc = EXIT_FAILURE;
goto skip;
}
@@ -188,7 +189,7 @@
}
rc = ldap_parse_result( ld, res,
- &code, &matcheddn, &text, &refs, NULL, 0 );
+ &code, &matcheddn, &text, &refs, &ctrls, 0 );
if( rc != LDAP_SUCCESS ) {
ldap_perror( ld, "ldap_parse_result" );
@@ -212,7 +213,10 @@
}
}
- if( verbose || ( code != LDAP_SUCCESS ) || matcheddn || text || refs ) {
+skip:
+ if ( verbose || ( code != LDAP_SUCCESS ) ||
+ matcheddn || text || refs || ctrls )
+ {
printf( _("Result: %s (%d)\n"), ldap_err2string( code ), code );
if( text && *text ) {
@@ -229,6 +233,11 @@
printf(_("Referral: %s\n"), refs[i] );
}
}
+
+ if (ctrls) {
+ tool_print_ctrls( ld, ctrls );
+ ldap_controls_free( ctrls );
+ }
}
ber_memfree( text );
@@ -237,7 +246,6 @@
ber_memfree( retoid );
ber_bvfree( retdata );
-skip:
/* disconnect from server */
tool_unbind( ld );
tool_destroy();
Modified: openldap/vendor/openldap-release/configure
===================================================================
--- openldap/vendor/openldap-release/configure 2007-09-15 10:30:38 UTC (rev 843)
+++ openldap/vendor/openldap-release/configure 2007-09-15 10:38:52 UTC (rev 844)
@@ -1,5 +1,5 @@
#! /bin/sh
-# From configure.in OpenLDAP: pkg/ldap/configure.in,v 1.560.2.32 2007/01/02 21:43:40 kurt Exp .
+# From configure.in OpenLDAP: pkg/ldap/configure.in,v 1.560.2.33 2007/06/10 18:39:53 hallvard Exp .
# Guess values for system-dependent variables and create Makefiles.
# Generated by GNU Autoconf 2.59.
#
@@ -35722,9 +35722,9 @@
}
#if (DB_VERSION_MAJOR > 3) || (DB_VERSION_MINOR >= 1)
- rc = env->open( env, NULL, flags, 0 );
+ rc = (env->open)( env, NULL, flags, 0 );
#else
- rc = env->open( env, NULL, NULL, flags, 0 );
+ rc = (env->open)( env, NULL, NULL, flags, 0 );
#endif
if ( rc == 0 ) {
@@ -39558,6 +39558,7 @@
fi
+
echo "$as_me:$LINENO: checking for socklen_t" >&5
echo $ECHO_N "checking for socklen_t... $ECHO_C" >&6
if test "${ac_cv_type_socklen_t+set}" = set; then
@@ -39574,7 +39575,6 @@
#include <sys/socket.h>
#endif
-
int
main ()
{
@@ -39619,14 +39619,86 @@
fi
echo "$as_me:$LINENO: result: $ac_cv_type_socklen_t" >&5
echo "${ECHO_T}$ac_cv_type_socklen_t" >&6
-if test $ac_cv_type_socklen_t = yes; then
- :
+
+
+echo "$as_me:$LINENO: checking the type of arg 3 to accept()" >&5
+echo $ECHO_N "checking the type of arg 3 to accept()... $ECHO_C" >&6
+if test "${ol_cv_type_ber_socklen_t+set}" = set; then
+ echo $ECHO_N "(cached) $ECHO_C" >&6
else
+ set socklen_t int unsigned "unsigned long" long size_t
+ test "$ac_cv_type_socklen_t" = yes || shift
+ ol_cv_type_ber_socklen_t=$1 guessing="guessing "
+ for lentype in "$@" ; do for addrtype in "struct sockaddr" void ; do
+ cat >conftest.$ac_ext <<_ACEOF
+/* confdefs.h. */
+_ACEOF
+cat confdefs.h >>conftest.$ac_ext
+cat >>conftest.$ac_ext <<_ACEOF
+/* end confdefs.h. */
+$ac_includes_default
+#ifdef HAVE_SYS_SOCKET_H
+#include <sys/socket.h>
+#endif
+extern int accept(int s, $addrtype *ap, $lentype *lp);
+
+int
+main ()
+{
+
+accept(0, (struct sockaddr *) 0, ($lentype *) 0);
+
+ ;
+ return 0;
+}
+_ACEOF
+rm -f conftest.$ac_objext
+if { (eval echo "$as_me:$LINENO: \"$ac_compile\"") >&5
+ (eval $ac_compile) 2>conftest.er1
+ ac_status=$?
+ grep -v '^ *+' conftest.er1 >conftest.err
+ rm -f conftest.er1
+ cat conftest.err >&5
+ echo "$as_me:$LINENO: \$? = $ac_status" >&5
+ (exit $ac_status); } &&
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
+ { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+ (eval $ac_try) 2>&5
+ ac_status=$?
+ echo "$as_me:$LINENO: \$? = $ac_status" >&5
+ (exit $ac_status); }; } &&
+ { ac_try='test -s conftest.$ac_objext'
+ { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+ (eval $ac_try) 2>&5
+ ac_status=$?
+ echo "$as_me:$LINENO: \$? = $ac_status" >&5
+ (exit $ac_status); }; }; then
+ ol_cv_type_ber_socklen_t=$lentype guessing= ; break 2
+else
+ echo "$as_me: failed program was:" >&5
+sed 's/^/| /' conftest.$ac_ext >&5
+
+fi
+rm -f conftest.err conftest.$ac_objext conftest.$ac_ext
+ done ; done
+fi
+
+echo "$as_me:$LINENO: result: $guessing$ol_cv_type_ber_socklen_t *" >&5
+echo "${ECHO_T}$guessing$ol_cv_type_ber_socklen_t *" >&6
+
cat >>confdefs.h <<_ACEOF
-#define socklen_t int
+#define ber_socklen_t $ol_cv_type_ber_socklen_t
_ACEOF
+
+if test "$ac_cv_type_socklen_t" != yes; then
+
+cat >>confdefs.h <<_ACEOF
+#define socklen_t $ol_cv_type_ber_socklen_t
+_ACEOF
+
fi
Modified: openldap/vendor/openldap-release/configure.in
===================================================================
--- openldap/vendor/openldap-release/configure.in 2007-09-15 10:30:38 UTC (rev 843)
+++ openldap/vendor/openldap-release/configure.in 2007-09-15 10:38:52 UTC (rev 844)
@@ -1,4 +1,4 @@
-dnl $OpenLDAP: pkg/ldap/configure.in,v 1.560.2.32 2007/01/02 21:43:40 kurt Exp $
+dnl $OpenLDAP: pkg/ldap/configure.in,v 1.560.2.33 2007/06/10 18:39:53 hallvard Exp $
dnl This work is part of OpenLDAP Software <http://www.openldap.org/>.
dnl
dnl Copyright 1998-2007 The OpenLDAP Foundation.
@@ -25,7 +25,7 @@
dnl Configure.in for OpenLDAP
AC_COPYRIGHT([[Copyright 1998-2007 The OpenLDAP Foundation. All rights reserved.
Restrictions apply, see COPYRIGHT and LICENSE files.]])
-AC_REVISION([$OpenLDAP: pkg/ldap/configure.in,v 1.560.2.32 2007/01/02 21:43:40 kurt Exp $])
+AC_REVISION([$OpenLDAP: pkg/ldap/configure.in,v 1.560.2.33 2007/06/10 18:39:53 hallvard Exp $])
AC_INIT([OpenLDAP],,[http://www.openldap.org/its/])
m4_define([AC_PACKAGE_BUGREPORT],[<http://www.openldap.org/its/>])
AC_CONFIG_SRCDIR(build/version.sh)dnl
@@ -2378,15 +2378,44 @@
AC_CHECK_TYPES([long long])
AC_CHECK_TYPES([ptrdiff_t])
-AC_CHECK_TYPE([socklen_t],,
- [AC_DEFINE_UNQUOTED([socklen_t], [int],
- [Define to `int' if <sys/socket.h> does not define.])],
- [$ac_includes_default
+
+AC_CHECK_TYPE([socklen_t],,, [$ac_includes_default
#ifdef HAVE_SYS_SOCKET_H
#include <sys/socket.h>
+#endif])
+
+dnl socklen_t-like type in accept(), default socklen_t or int:
+dnl - The OS might define socklen_t without using it. POSIX moved from
+dnl int to size_t to socklen_t, hoping to stay at a 32-bit type, and
+dnl HP-UX now has selectors for what to use.
+dnl - On Solaris 2.8 the prototype has void *len, but the default is OK.
+AC_MSG_CHECKING([the type of arg 3 to accept()])
+AC_CACHE_VAL(ol_cv_type_ber_socklen_t, [
+ set socklen_t int unsigned "unsigned long" long size_t
+ test "$ac_cv_type_socklen_t" = yes || shift
+ ol_cv_type_ber_socklen_t=$1 guessing="guessing "
+ for lentype in "$@" ; do for addrtype in "struct sockaddr" void ; do
+ AC_COMPILE_IFELSE([AC_LANG_PROGRAM([$ac_includes_default
+#ifdef HAVE_SYS_SOCKET_H
+#include <sys/socket.h>
#endif
- ])
+extern int accept(int s, $addrtype *ap, $lentype *lp);
+], [
+accept(0, (struct sockaddr *) 0, ($lentype *) 0);
+])], [ol_cv_type_ber_socklen_t=$lentype guessing= ; break 2])
+ done ; done])
+AC_MSG_RESULT([$guessing$ol_cv_type_ber_socklen_t *])
+AC_DEFINE_UNQUOTED(ber_socklen_t, $ol_cv_type_ber_socklen_t,
+ [Define to the type of arg 3 for `accept'.])
+dnl Modules should use ber_socklen_t, not socklen_t. Define socklen_t
+dnl for the time being anyway, for backwards compatibility.
+if test "$ac_cv_type_socklen_t" != yes; then
+ AC_DEFINE_UNQUOTED([socklen_t], [$ol_cv_type_ber_socklen_t],
+ [Define like ber_socklen_t if <sys/socket.h> does not define.])
+fi
+
+
AC_TYPE_SIGNAL
AC_CHECK_TYPE([sig_atomic_t],,
Added: openldap/vendor/openldap-release/doc/drafts/README
===================================================================
--- openldap/vendor/openldap-release/doc/drafts/README (rev 0)
+++ openldap/vendor/openldap-release/doc/drafts/README 2007-09-15 10:38:52 UTC (rev 844)
@@ -0,0 +1,18 @@
+Internet-Drafts (I-Ds) are working documents of the Internet
+Engineering Task Force (IETF), its areas, its working groups, and
+individual contributors.
+
+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."
+
+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 go to <http://www.ietf.org/> for latest revisions (and
+status).
+
+$OpenLDAP: pkg/ldap/doc/drafts/README,v 1.8 2003/12/07 06:54:38 kurt Exp $
Added: openldap/vendor/openldap-release/doc/drafts/draft-behera-ldap-password-policy-xx.txt
===================================================================
--- openldap/vendor/openldap-release/doc/drafts/draft-behera-ldap-password-policy-xx.txt (rev 0)
+++ openldap/vendor/openldap-release/doc/drafts/draft-behera-ldap-password-policy-xx.txt 2007-09-15 10:38:52 UTC (rev 844)
@@ -0,0 +1,2298 @@
+
+
+
+
+Network Working Group J. Sermersheim
+Internet-Draft Novell, Inc
+Expires: January 18, 2006 L. Poitou
+ Sun Microsystems
+ July 17, 2005
+
+
+ Password Policy for LDAP Directories
+ draft-behera-ldap-password-policy-09.txt
+
+Status of this Memo
+
+ By submitting this Internet-Draft, each author represents that any
+ applicable patent or other IPR claims of which he or she is aware
+ have been or will be disclosed, and any of which he or she becomes
+ aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+ Internet-Drafts are working documents of the Internet Engineering
+ Task Force (IETF), its areas, and its working groups. Note that
+ other groups may also distribute working documents as Internet-
+ Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference
+ material or to cite them other than as "work in progress."
+
+ The list of current Internet-Drafts can be accessed at
+ http://www.ietf.org/ietf/1id-abstracts.txt.
+
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html.
+
+ This Internet-Draft will expire on January 18, 2006.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2005).
+
+Abstract
+
+ Password policy as described in this document is a set of rules that
+ controls how passwords are used and administered in Lightweight
+ Directory Access Protocol (LDAP) based directories. In order to
+ improve the security of LDAP directories and make it difficult for
+ password cracking programs to break into directories, it is desirable
+ to enforce a set of rules on password usage. These rules are made to
+ ensure that users change their passwords periodically, passwords meet
+
+
+
+Sermersheim & Poitou Expires January 18, 2006 [Page 1]
+
+Internet-Draft Password Policy for LDAP Directories July 2005
+
+
+ construction requirements, the re-use of old password is restricted,
+ and users are locked out after a certain number of failed attempts.
+
+Discussion Forum
+
+ Technical discussion of this document will take place on the IETF
+ LDAP Extensions mailing list <ldapext at ietf.org>. Please send
+ editorial comments directly to the authors.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sermersheim & Poitou Expires January 18, 2006 [Page 2]
+
+Internet-Draft Password Policy for LDAP Directories July 2005
+
+
+Table of Contents
+
+ 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5
+ 3. Application of password policy . . . . . . . . . . . . . . . . 6
+ 4. Articles of password policy . . . . . . . . . . . . . . . . . 7
+ 4.1 Password Usage Policy . . . . . . . . . . . . . . . . . . . . 7
+ 4.2 Password Modification Policy . . . . . . . . . . . . . . . . . 7
+ 4.3 Restriction of the Password Policy . . . . . . . . . . . . . . 10
+ 5. Schema used for Password Policy . . . . . . . . . . . . . . . 11
+ 5.1 The pwdPolicy Object Class . . . . . . . . . . . . . . . . . . 11
+ 5.2 Attribute Types used in the pwdPolicy ObjectClass . . . . . . 11
+ 5.3 Attribute Types for Password Policy State Information . . . . 16
+ 6. Controls used for Password Policy . . . . . . . . . . . . . . 21
+ 6.1 Request Control . . . . . . . . . . . . . . . . . . . . . . . 21
+ 6.2 Response Control . . . . . . . . . . . . . . . . . . . . . . . 21
+ 7. Policy Decision Points . . . . . . . . . . . . . . . . . . . . 23
+ 7.1 Locked Account Check . . . . . . . . . . . . . . . . . . . . . 23
+ 7.2 Password Must be Changed Now Check . . . . . . . . . . . . . . 23
+ 7.3 Password Expiration Check . . . . . . . . . . . . . . . . . . 23
+ 7.4 Remaining Grace AuthN Check . . . . . . . . . . . . . . . . . 23
+ 7.5 Time Before Expiration Check . . . . . . . . . . . . . . . . . 24
+ 7.6 Intruder Detection Check . . . . . . . . . . . . . . . . . . . 24
+ 7.7 Password Too Young Check . . . . . . . . . . . . . . . . . . . 24
+ 8. Server Policy Enforcement Points . . . . . . . . . . . . . . . 25
+ 8.1 Password-based Authentication . . . . . . . . . . . . . . . . 25
+ 8.2 Password Update Operations . . . . . . . . . . . . . . . . . . 27
+ 8.3 Other Operations . . . . . . . . . . . . . . . . . . . . . . . 30
+ 9. Client Policy Enforcement Points . . . . . . . . . . . . . . . 31
+ 9.1 Bind Operation . . . . . . . . . . . . . . . . . . . . . . . . 31
+ 9.2 Modify Operations . . . . . . . . . . . . . . . . . . . . . . 32
+ 9.3 Add Operation . . . . . . . . . . . . . . . . . . . . . . . . 33
+ 9.4 Compare Operation . . . . . . . . . . . . . . . . . . . . . . 33
+ 9.5 Other Operations . . . . . . . . . . . . . . . . . . . . . . . 34
+ 10. Administration of the Password Policy . . . . . . . . . . . . 35
+ 11. Password Policy and Replication . . . . . . . . . . . . . . . 36
+ 12. Security Considerations . . . . . . . . . . . . . . . . . . . 37
+ 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38
+ 14. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 39
+ 15. Normative References . . . . . . . . . . . . . . . . . . . . . 39
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 40
+ Intellectual Property and Copyright Statements . . . . . . . . 41
+
+
+
+
+
+
+
+
+
+Sermersheim & Poitou Expires January 18, 2006 [Page 3]
+
+Internet-Draft Password Policy for LDAP Directories July 2005
+
+
+1. Overview
+
+ LDAP-based directory services are currently accepted by many
+ organizations as the access protocol for directories. The ability to
+ ensure the secure read and update access to directory information
+ throughout the network is essential to the successful deployment.
+ Most LDAP implementations support many authentication schemes - the
+ most basic and widely used is the simple authentication i.e., user DN
+ and password. In this case, many LDAP servers have implemented some
+ kind of policy related to the password used to authenticate. Among
+ other things, this policy includes:
+
+ o Whether and when passwords expire.
+
+ o Whether failed bind attempts cause the account to be locked.
+
+ o If and how users are able to change their passwords.
+
+ In order to achieve greater security protection and ensure
+ interoperability in a heterogeneous environment, LDAP needs to
+ standardize on a common password policy model. This is critical to
+ the successful deployment of LDAP directories.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sermersheim & Poitou Expires January 18, 2006 [Page 4]
+
+Internet-Draft Password Policy for LDAP Directories July 2005
+
+
+2. Conventions
+
+ Imperative keywords defined in [RFC2119] are used in this document,
+ and carry the meanings described there.
+
+ All Basic Encoding Rules (BER) [X690] encodings follow the
+ conventions found in Section 5.1 of [RFC2251].
+
+ The term "password administrator" refers to a user that has
+ sufficient access control privileges to modify users' passwords. The
+ term "password policy administrator" refers to a user that has
+ sufficient access control privileges to modify the pwdPolicy object
+ defined in this document. The access control that is used to
+ determine whether an identity is a password administrator or password
+ policy administrator is beyond the scope of this document, but
+ typically implies that the password administrator has 'write'
+ privileges to the password attribute.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sermersheim & Poitou Expires January 18, 2006 [Page 5]
+
+Internet-Draft Password Policy for LDAP Directories July 2005
+
+
+3. Application of password policy
+
+ The password policy defined in this document can be applied to any
+ attribute holding a user's password used for an authenticated LDAP
+ bind operation. In this document, the term "user" represents any
+ LDAP client application that has an identity in the directory.
+
+ This policy is typically applied to the userPassword attribute in the
+ case of the LDAP simple authentication method [RFC2251] or the case
+ of password based SASL [RFC2222] authentication such as CRAM-MD5
+ [RFC2195] and DIGEST-MD5 [RFC2831].
+
+ The policy described in this document assumes that the password
+ attribute holds a single value. No considerations are made for
+ directories or systems that allow a user to maintain multi-valued
+ password attributes.
+
+ Server implementations MAY institute internal policy whereby certain
+ identities (such as directory administrators) are not forced to
+ comply with any of password policy. In this case, the password for a
+ directory administrator never expires; the account is never locked,
+ etc.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sermersheim & Poitou Expires January 18, 2006 [Page 6]
+
+Internet-Draft Password Policy for LDAP Directories July 2005
+
+
+4. Articles of password policy
+
+ The following sections explain in general terms each aspect of the
+ password policy defined in this document as well as the need for
+ each. These policies are subdivided into the general groups of
+ password usage and password modification. Implementation details are
+ presented in Section 8 and Section 9.
+
+4.1 Password Usage Policy
+
+ This section describes policy enforced when a password is used to
+ authenticate. The general focus of this policy is to minimize the
+ threat of intruders once a password is in use.
+
+4.1.1 Password Guessing Limit
+
+ In order to prevent intruders from guessing a user's password, a
+ mechanism exists to track the number of consecutive failed
+ authentication attempts, and take action when a limit is reached.
+ This policy consists of five parts:
+
+ o A configurable limit on failed authentication attempts.
+
+ o A counter to track the number of failed authentication attempts.
+
+ o A timeframe in which the limit of consecutive failed
+ authentication attempts must happen before action is taken.
+
+ o The action to be taken when the limit is reached. The action will
+ either be nothing, or the account will be locked.
+
+ o An amount of time the account is locked (if it is to be locked).
+ This can be indefinite.
+
+
+4.2 Password Modification Policy
+
+ This section describes policy enforced while users are modifying
+ passwords. The general focus of this policy is to ensure that when
+ users add or change their passwords, the security and effectiveness
+ of their passwords is maximized. In this document, the term "modify
+ password operation" refers to any operation that is used to add or
+ modify a password attribute. Often this is done by updating the
+ password attribute during an add or modify operation, but MAY be done
+ by other means such as an extended operation.
+
+
+
+
+
+
+Sermersheim & Poitou Expires January 18, 2006 [Page 7]
+
+Internet-Draft Password Policy for LDAP Directories July 2005
+
+
+4.2.1 Password Expiration, Expiration Warning, and Grace
+ Authentications
+
+ One of the key properties of a password is the fact that it is not
+ well known. If a password is frequently changed, the chances of that
+ user's account being broken into are minimized.
+
+ Password policy administrators may deploy a password policy that
+ causes passwords to expire after a given amount of time - thus
+ forcing users to change their passwords periodically.
+
+ As a side effect, there needs to be a way in which users are made
+ aware of this need to change their password before actually being
+ locked out of their accounts. One or both of the following methods
+ handle this:
+
+ o A warning may be returned to the user sometime before his password
+ is due to expire. If the user fails to heed this warning before
+ the expiration time, his account will be locked.
+
+ o The user may bind to the directory a preset number of times after
+ her password has expired. If she fails to change her password
+ during one of her 'grace' authentications, her account will be
+ locked.
+
+
+4.2.2 Password History
+
+ When the Password Expiration policy is used, an additional mechanism
+ may be employed to prevent users from simply re-using a previous
+ password (as this would effectively circumvent the expiration
+ policy).
+
+ In order to do this; a history of used passwords is kept. The
+ password policy administrator sets the number of passwords to be
+ stored at any given time. Passwords are stored in this history
+ whenever the password is changed. Users aren't allowed to specify
+ any passwords that are in the history list while changing passwords.
+
+4.2.3 Password Minimum Age
+
+ Users may circumvent the Password History mechanism by quickly
+ performing a series of password changes. If they change their
+ password enough times, their 'favorite' password will be pushed out
+ of the history list.
+
+ This process may be made less attractive to users by employing a
+ minimum age for passwords. If users are forced to wait 24 hours
+
+
+
+Sermersheim & Poitou Expires January 18, 2006 [Page 8]
+
+Internet-Draft Password Policy for LDAP Directories July 2005
+
+
+ between password changes, they may be less likely to cycle through a
+ history of 10 passwords.
+
+4.2.4 Password Quality and Minimum length
+
+ In order to prevent users from creating or updating passwords that
+ are easy to guess, a password quality policy may be employed. This
+ policy consists of two general mechanisms - ensuring that passwords
+ conform to a defined quality criterion and ensuring that they are of
+ a minimum length.
+
+ Forcing a password to comply with the quality policy may imply a
+ variety of things including:
+
+ o Disallowing trivial or well-known words make up the password.
+
+ o Forcing a certain number of digits be used.
+
+ o Disallowing anagrams of the user's name.
+
+ The implementation of this policy meets with the following problems:
+
+ o If the password to be added or updated is encrypted by the client
+ before being sent, the server has no way of enforcing this policy.
+ Therefore, the onus of enforcing this policy falls upon client
+ implementations.
+
+ o There are no specific definitions of what 'quality checking'
+ means. This can lead to unexpected behavior in a heterogeneous
+ environment.
+
+
+4.2.5 User Defined Passwords
+
+ In some cases, it is desirable to disallow users from adding and
+ updating their own passwords. This policy makes this functionality
+ possible.
+
+4.2.6 Password Change after Reset
+
+ This policy forces the user to update her password after it has been
+ set for the first time, or has been reset by a password
+ administrator.
+
+ This is needed in scenarios where a password administrator has set or
+ reset the password to a well-known value.
+
+
+
+
+
+Sermersheim & Poitou Expires January 18, 2006 [Page 9]
+
+Internet-Draft Password Policy for LDAP Directories July 2005
+
+
+4.2.7 Safe Modification
+
+ As directories become more commonly used, it will not be unusual for
+ clients to connect to a directory and leave the connection open for
+ an extended period. This opens up the possibility for an intruder to
+ make modifications to a user's password while that user's computer is
+ connected but unattended.
+
+ This policy forces the user to prove his identity by specifying the
+ old password during a password modify operation.
+
+ {TODO: This allows a dictionary attack unless we specify that this is
+ also subject to intruder detection. One solution is to require users
+ to authN prior to changing password. Another solution is to perform
+ intruder detection checks when the password for a non-authenticated
+ identity is being updated}
+
+4.3 Restriction of the Password Policy
+
+ The password policy defined in this document can apply to any
+ attribute containing a password. Password policy state information
+ is held in the user's entry, and applies to a password attribute, not
+ a particular password attribute value. Thus the server SHOULD
+ enforce that the password attribute subject to password policy,
+ contains one and only one password value.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sermersheim & Poitou Expires January 18, 2006 [Page 10]
+
+Internet-Draft Password Policy for LDAP Directories July 2005
+
+
+5. Schema used for Password Policy
+
+ The schema elements defined here fall into two general categories. A
+ password policy object class is defined which contains a set of
+ administrative password policy attributes, and a set of operational
+ attributes are defined that hold general password policy state
+ information for each user.
+
+5.1 The pwdPolicy Object Class
+
+ This object class contains the attributes defining a password policy
+ in effect for a set of users. Section 10 describes the
+ administration of this object, and the relationship between it and
+ particular objects.
+
+ ( 1.3.6.1.4.1.42.2.27.8.2.1
+ NAME 'pwdPolicy'
+ SUP top
+ AUXILIARY
+ MUST ( pwdAttribute )
+ MAY ( pwdMinAge $ pwdMaxAge $ pwdInHistory $ pwdCheckQuality $
+ pwdMinLength $ pwdExpireWarning $ pwdGraceAuthNLimit $ pwdLockout
+ $ pwdLockoutDuration $ pwdMaxFailure $ pwdFailureCountInterval $
+ pwdMustChange $ pwdAllowUserChange $ pwdSafeModify ) )
+
+
+5.2 Attribute Types used in the pwdPolicy ObjectClass
+
+ Following are the attribute types used by the pwdPolicy object class.
+
+5.2.1 pwdAttribute
+
+ This holds the name of the attribute to which the password policy is
+ applied. For example, the password policy may be applied to the
+ userPassword attribute.
+
+ ( 1.3.6.1.4.1.42.2.27.8.1.1
+ NAME 'pwdAttribute'
+ EQUALITY objectIdentifierMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
+
+
+5.2.2 pwdMinAge
+
+ This attribute holds the number of seconds that must elapse between
+ modifications to the password. If this attribute is not present, 0
+ seconds is assumed.
+
+
+
+
+Sermersheim & Poitou Expires January 18, 2006 [Page 11]
+
+Internet-Draft Password Policy for LDAP Directories July 2005
+
+
+ ( 1.3.6.1.4.1.42.2.27.8.1.2
+ NAME 'pwdMinAge'
+ EQUALITY integerMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
+ SINGLE-VALUE )
+
+
+5.2.3 pwdMaxAge
+
+ This attribute holds the number of seconds after which a modified
+ password will expire.
+
+ If this attribute is not present, or if the value is 0 the password
+ does not expire. If not 0, the value must be greater than or equal
+ to the value of the pwdMinAge.
+
+ ( 1.3.6.1.4.1.42.2.27.8.1.3
+ NAME 'pwdMaxAge'
+ EQUALITY integerMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
+ SINGLE-VALUE )
+
+
+5.2.4 pwdInHistory
+
+ This attribute specifies the maximum number of used passwords stored
+ in the pwdHistory attribute.
+
+ If this attribute is not present, or if the value is 0, used
+ passwords are not stored in the pwdHistory attribute and thus may be
+ reused.
+
+ ( 1.3.6.1.4.1.42.2.27.8.1.4
+ NAME 'pwdInHistory'
+ EQUALITY integerMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
+ SINGLE-VALUE )
+
+
+5.2.5 pwdCheckQuality
+
+ {TODO: Consider changing the syntax to OID. Each OID will list a
+ quality rule (like min len, # of special characters, etc). These
+ rules can be specified outside this document.}
+
+ {TODO: Note that even though this is meant to be a check that happens
+ during password modification, it may also be allowed to happen during
+ authN. This is useful for situations where the password is encrypted
+
+
+
+Sermersheim & Poitou Expires January 18, 2006 [Page 12]
+
+Internet-Draft Password Policy for LDAP Directories July 2005
+
+
+ when modified, but decrypted when used to authN.}
+
+ This attribute indicates how the password quality will be verified
+ while being modified or added. If this attribute is not present, or
+ if the value is '0', quality checking will not be enforced. A value
+ of '1' indicates that the server will check the quality, and if the
+ server is unable to check it (due to a hashed password or other
+ reasons) it will be accepted. A value of '2' indicates that the
+ server will check the quality, and if the server is unable to verify
+ it, it will return an error refusing the password.
+
+ ( 1.3.6.1.4.1.42.2.27.8.1.5
+ NAME 'pwdCheckQuality'
+ EQUALITY integerMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
+ SINGLE-VALUE )
+
+
+5.2.6 pwdMinLength
+
+ When quality checking is enabled, this attribute holds the minimum
+ number of characters that must be used in a password. If this
+ attribute is not present, no minimum password length will be
+ enforced. If the server is unable to check the length (due to a
+ hashed password or otherwise), the server will, depending on the
+ value of the pwdCheckQuality attribute, either accept the password
+ without checking it ('0' or '1') or refuse it ('2').
+
+ ( 1.3.6.1.4.1.42.2.27.8.1.6
+ NAME 'pwdMinLength'
+ EQUALITY integerMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
+ SINGLE-VALUE )
+
+
+5.2.7 pwdExpireWarning
+
+ This attribute specifies the maximum number of seconds before a
+ password is due to expire that expiration warning messages will be
+ returned to an authenticating user.
+
+ If this attribute is not present, or if the value is 0 no warnings
+ will be returned. If not 0, the value must be smaller than the value
+ of the pwdMaxAge attribute.
+
+ ( 1.3.6.1.4.1.42.2.27.8.1.7
+ NAME 'pwdExpireWarning'
+ EQUALITY integerMatch
+
+
+
+Sermersheim & Poitou Expires January 18, 2006 [Page 13]
+
+Internet-Draft Password Policy for LDAP Directories July 2005
+
+
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
+ SINGLE-VALUE )
+
+
+5.2.8 pwdGraceAuthNLimit
+
+ This attribute specifies the number of times an expired password can
+ be used to authenticate. If this attribute is not present or if the
+ value is 0, authentication will fail.
+
+ ( 1.3.6.1.4.1.42.2.27.8.1.8
+ NAME 'pwdGraceAuthNLimit'
+ EQUALITY integerMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
+ SINGLE-VALUE )
+
+
+5.2.9 pwdLockout
+
+ This attribute indicates, when its value is "TRUE", that the password
+ may not be used to authenticate after a specified number of
+ consecutive failed bind attempts. The maximum number of consecutive
+ failed bind attempts is specified in pwdMaxFailure.
+
+ If this attribute is not present, or if the value is "FALSE", the
+ password may be used to authenticate when the number of failed bind
+ attempts has been reached.
+
+ ( 1.3.6.1.4.1.42.2.27.8.1.9
+ NAME 'pwdLockout'
+ EQUALITY booleanMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
+ SINGLE-VALUE )
+
+
+5.2.10 pwdLockoutDuration
+
+ This attribute holds the number of seconds that the password cannot
+ be used to authenticate due to too many failed bind attempts. If
+ this attribute is not present, or if the value is 0 the password
+ cannot be used to authenticate until reset by a password
+ administrator.
+
+ ( 1.3.6.1.4.1.42.2.27.8.1.10
+ NAME 'pwdLockoutDuration'
+ EQUALITY integerMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
+ SINGLE-VALUE )
+
+
+
+Sermersheim & Poitou Expires January 18, 2006 [Page 14]
+
+Internet-Draft Password Policy for LDAP Directories July 2005
+
+
+5.2.11 pwdMaxFailure
+
+ This attribute specifies the number of consecutive failed bind
+ attempts after which the password may not be used to authenticate.
+ If this attribute is not present, or if the value is 0, this policy
+ is not checked, and the value of pwdLockout will be ignored.
+
+ ( 1.3.6.1.4.1.42.2.27.8.1.11
+ NAME 'pwdMaxFailure'
+ EQUALITY integerMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
+ SINGLE-VALUE )
+
+
+5.2.12 pwdFailureCountInterval
+
+ This attribute holds the number of seconds after which the password
+ failures are purged from the failure counter, even though no
+ successful authentication occurred.
+
+ If this attribute is not present, or if its value is 0, the failure
+ counter is only reset by a successful authentication.
+
+ ( 1.3.6.1.4.1.42.2.27.8.1.12
+ NAME 'pwdFailureCountInterval'
+ EQUALITY integerMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
+ SINGLE-VALUE )
+
+
+5.2.13 pwdMustChange
+
+ This attribute specifies with a value of "TRUE" that users must
+ change their passwords when they first bind to the directory after a
+ password is set or reset by a password administrator. If this
+ attribute is not present, or if the value is "FALSE", users are not
+ required to change their password upon binding after the password
+ administrator sets or resets the password. This attribute is not set
+ due to any actions specified by this document, it is typically set by
+ a password administrator after resetting a user's password.
+
+ ( 1.3.6.1.4.1.42.2.27.8.1.13
+ NAME 'pwdMustChange'
+ EQUALITY booleanMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
+ SINGLE-VALUE )
+
+
+
+
+
+Sermersheim & Poitou Expires January 18, 2006 [Page 15]
+
+Internet-Draft Password Policy for LDAP Directories July 2005
+
+
+5.2.14 pwdAllowUserChange
+
+ This attribute indicates whether users can change their own
+ passwords, although the change operation is still subject to access
+ control. If this attribute is not present, a value of "TRUE" is
+ assumed. This attribute is intended to be used in the absense of an
+ access control mechanism.
+
+ ( 1.3.6.1.4.1.42.2.27.8.1.14
+ NAME 'pwdAllowUserChange'
+ EQUALITY booleanMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
+ SINGLE-VALUE )
+
+
+5.2.15 pwdSafeModify
+
+ This attribute specifies whether or not the existing password must be
+ sent along with the new password when being changed. If this
+ attribute is not present, a "FALSE" value is assumed.
+
+ ( 1.3.6.1.4.1.42.2.27.8.1.15
+ NAME 'pwdSafeModify'
+ EQUALITY booleanMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
+ SINGLE-VALUE )
+
+
+5.3 Attribute Types for Password Policy State Information
+
+ Password policy state information must be maintained for each user.
+ The information is located in each user entry as a set of operational
+ attributes. These operational attributes are: pwdChangedTime,
+ pwdAccountLockedTime, pwdFailureTime, pwdHistory, pwdGraceUseTime,
+ pwdReset, pwdPolicySubEntry.
+
+5.3.1 Password Policy State Attribute Option
+
+ Since the password policy could apply to several attributes used to
+ store passwords, each of the above operational attributes must have
+ an option to specify which pwdAttribute it applies to. The password
+ policy option is defined as the following:
+
+ pwd-<passwordAttribute>
+
+ where passwordAttribute a string following the OID syntax
+ (1.3.6.1.4.1.1466.115.121.1.38). The attribute type descriptor
+ (short name) MUST be used.
+
+
+
+Sermersheim & Poitou Expires January 18, 2006 [Page 16]
+
+Internet-Draft Password Policy for LDAP Directories July 2005
+
+
+ For example, if the pwdPolicy object has for pwdAttribute
+ "userPassword" then the pwdChangedTime operational attribute, in a
+ user entry, will be:
+
+ pwdChangedTime;pwd-userPassword: 20000103121520Z
+
+ This attribute option follows sub-typing semantics. If a client
+ requests a password policy state attribute to be returned in a search
+ operation, and does not specify an option, all subtypes of that
+ policy state attribute are returned.
+
+5.3.2 pwdChangedTime
+
+ This attribute specifies the last time the entry's password was
+ changed. This is used by the password expiration policy. If this
+ attribute does not exist, the password will never expire.
+
+ ( 1.3.6.1.4.1.42.2.27.8.1.16
+ NAME 'pwdChangedTime'
+ DESC 'The time the password was last changed'
+ EQUALITY generalizedTimeMatch
+ ORDERING generalizedTimeOrderingMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
+ SINGLE-VALUE
+ NO-USER-MODIFICATION
+ USAGE directoryOperation )
+
+
+5.3.3 pwdAccountLockedTime
+
+ This attribute holds the time that the user's account was locked. A
+ locked account means that the password may no longer be used to
+ authenticate. A 000001010000Z value means that the account has been
+ locked permanently, and that only a password administrator can unlock
+ the account.
+
+ ( 1.3.6.1.4.1.42.2.27.8.1.17
+ NAME 'pwdAccountLockedTime'
+ DESC 'The time an user account was locked'
+ EQUALITY generalizedTimeMatch
+ ORDERING generalizedTimeOrderingMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
+ SINGLE-VALUE
+ NO-USER-MODIFICATION
+ USAGE directoryOperation )
+
+
+
+
+
+
+Sermersheim & Poitou Expires January 18, 2006 [Page 17]
+
+Internet-Draft Password Policy for LDAP Directories July 2005
+
+
+5.3.4 pwdFailureTime
+
+ This attribute holds the timestamps of the consecutive authentication
+ failures.
+
+ ( 1.3.6.1.4.1.42.2.27.8.1.19
+ NAME 'pwdFailureTime'
+ DESC 'The timestamps of the last consecutive authentication
+ failures'
+ EQUALITY generalizedTimeMatch
+ ORDERING generalizedTimeOrderingMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
+ NO-USER-MODIFICATION
+ USAGE directoryOperation )
+
+
+5.3.5 pwdHistory
+
+ This attribute holds a history of previously used passwords. Values
+ of this attribute are transmitted in string format as given by the
+ following ABNF:
+
+ pwdHistory = time "#" syntaxOID "#" length "#" data
+
+ time = <generalizedTimeString as specified in 6.14
+ of [RFC2252]>
+
+ syntaxOID = numericoid ; the string representation of the
+ ; dotted-decimal OID that defines the
+ ; syntax used to store the password.
+ ; numericoid is described in 4.1
+ ; of [RFC2252].
+
+ length = numericstring ; the number of octets in data.
+ ; numericstring is described in 4.1
+ ; of [RFC2252].
+
+ data = <octets representing the password in the format
+ specified by syntaxOID>.
+
+ This format allows the server to store, and transmit a history of
+ passwords that have been used. In order for equality matching to
+ function properly, the time field needs to adhere to a consistent
+ format. For this purpose, the time field MUST be in GMT format.
+
+ ( 1.3.6.1.4.1.42.2.27.8.1.20
+ NAME 'pwdHistory'
+ DESC 'The history of user s passwords'
+
+
+
+Sermersheim & Poitou Expires January 18, 2006 [Page 18]
+
+Internet-Draft Password Policy for LDAP Directories July 2005
+
+
+ EQUALITY octetStringMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.40
+ NO-USER-MODIFICATION
+ USAGE directoryOperation )
+
+
+5.3.6 pwdGraceUseTime
+
+ This attribute holds the timestamps of grace authentications after a
+ password has expired.
+
+ ( 1.3.6.1.4.1.42.2.27.8.1.21
+ NAME 'pwdGraceUseTime'
+ DESC 'The timestamps of the grace authentication after the
+ password has expired'
+ EQUALITY generalizedTimeMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
+ NO-USER-MODIFICATION
+ USAGE directoryOperation )
+
+
+5.3.7 pwdReset
+
+ This attribute holds a flag to indicate (when TRUE) that the password
+ has been updated by the password administrator and must be changed by
+ the user.
+
+ ( 1.3.6.1.4.1.42.2.27.8.1.22
+ NAME 'pwdReset'
+ DESC 'The indication that the password has been reset'
+ EQUALITY booleanMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
+ SINGLE-VALUE
+ USAGE directoryOperation )
+
+
+5.3.8 pwdPolicySubentry
+
+ This attribute points to the pwdPolicy subentry in effect for this
+ object.
+
+ ( 1.3.6.1.4.1.42.2.27.8.1.23
+ NAME 'pwdPolicySubentry'
+ DESC 'The pwdPolicy subentry in effect for this object'
+ EQUALITY distinguishedNameMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
+ SINGLE-VALUE
+ NO-USER-MODIFICATION
+
+
+
+Sermersheim & Poitou Expires January 18, 2006 [Page 19]
+
+Internet-Draft Password Policy for LDAP Directories July 2005
+
+
+ USAGE directoryOperation )
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sermersheim & Poitou Expires January 18, 2006 [Page 20]
+
+Internet-Draft Password Policy for LDAP Directories July 2005
+
+
+6. Controls used for Password Policy
+
+ This section details the controls used while enforcing password
+ policy. A request control is defined that is sent by a client with a
+ request operation in order to elicit a response control. The
+ response control contains various warnings and errors associated with
+ password policy.
+
+ {TODO: add a note about advertisement and discovery}
+
+6.1 Request Control
+
+ This control MAY be sent with any LDAP request message in order to
+ convey to the server that this client is aware of, and can process
+ the response control described in this document. When a server
+ receives this control, it will return the response control when
+ appropriate and with the proper data.
+
+ The controlType is 1.3.6.1.4.1.42.2.27.8.5.1 and the criticality may
+ be TRUE or FALSE. There is no controlValue.
+
+6.2 Response Control
+
+ If the client has sent a passwordPolicyRequest control, the server
+ (when solicited by the inclusion of the request control) sends this
+ control with the following operation responses: bindResponse,
+ modifyResponse, addResponse, compareResponse and possibly
+ extendedResponse, to inform of various conditions, and MAY be sent
+ with other operations (in the case of the changeAfterReset error).
+ The controlType is 1.3.6.1.4.1.42.2.27.8.5.1 and the controlValue is
+ the BER encoding of the following type:
+
+ PasswordPolicyResponseValue ::= SEQUENCE {
+ warning [0] CHOICE {
+ timeBeforeExpiration [0] INTEGER (0 .. maxInt),
+ graceAuthNsRemaining [1] INTEGER (0 .. maxInt) } OPTIONAL,
+ error [1] ENUMERATED {
+ passwordExpired (0),
+ accountLocked (1),
+ changeAfterReset (2),
+ passwordModNotAllowed (3),
+ mustSupplyOldPassword (4),
+ insufficientPasswordQuality (5),
+ passwordTooShort (6),
+ passwordTooYoung (7),
+ passwordInHistory (8) } OPTIONAL }
+
+ The timeBeforeExpiration warning specifies the number of seconds
+
+
+
+Sermersheim & Poitou Expires January 18, 2006 [Page 21]
+
+Internet-Draft Password Policy for LDAP Directories July 2005
+
+
+ before a password will expire. The graceAuthNsRemaining warning
+ specifies the remaining number of times a user will be allowed to
+ authenticate with an expired password. The passwordExpired error
+ signifies that the password has expired and must be reset. The
+ changeAfterReset error signifies that the password must be changed
+ before the user will be allowed to perform any operation other than
+ bind and modify. The passwordModNotAllowed error is set when a user
+ is restricted from changing her password. The
+ insufficientPasswordQuality error is set when a password doesn't pass
+ quality checking. The passwordTooYoung error is set if the age of
+ the password to be modified is not yet old enough.
+
+ Typically, only either a warning or an error will be encoded though
+ there may be exceptions. For example, if the user is required to
+ change a password after the password administrator set it, and the
+ password will expire in a short amount of time, the control may
+ include the timeBeforeExpiration warning and the changeAfterReset
+ error.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sermersheim & Poitou Expires January 18, 2006 [Page 22]
+
+Internet-Draft Password Policy for LDAP Directories July 2005
+
+
+7. Policy Decision Points
+
+ Following are a number of procedures used to make policy decisions.
+ These procedures are typically performed by the server while
+ processing an operation.
+
+ The following sections contain detailed instructions that refer to
+ attributes of the pwdPolicy object class. When doing so, the
+ attribute of the pwdPolicy object that governs the entry being
+ discussed is implied.
+
+7.1 Locked Account Check
+
+ A status of true is returned to indicate that the account is locked
+ if any of these conditions are met:
+
+ o The value of the pwdAccountLockedTime attribute is 000001010000Z.
+
+ o The current time is less than the value of the
+ pwdAccountLockedTime attribute added to the value of the
+ pwdLockoutDuration.
+
+ Otherwise a status of false is returned.
+
+7.2 Password Must be Changed Now Check
+
+ A status of true is returned to indicate that the account is locked
+ if all of these conditions are met:
+
+ The pwdMustChange attribute is set to TRUE.
+
+ The pwdReset attribute is set to TRUE.
+
+ Otherwise a status of false is returned.
+
+7.3 Password Expiration Check
+
+ A status of true is returned indicating that the password has expired
+ if the current time minus the value of pwdChangedTime is greater than
+ the value of the pwdMaxAge.
+
+ Otherwise, a status of false is returned.
+
+7.4 Remaining Grace AuthN Check
+
+ If the pwdGraceUseTime attribute is present, the number of values in
+ that attribute subtracted from the value of pwdGraceAuthNLimit is
+ returned. Otherwise zero is returned. A positive result specifies
+
+
+
+Sermersheim & Poitou Expires January 18, 2006 [Page 23]
+
+Internet-Draft Password Policy for LDAP Directories July 2005
+
+
+ the number of remaining grace authentications.
+
+7.5 Time Before Expiration Check
+
+ If the pwdExpireWarning attribute is not present a zero status is
+ returned. Otherwise the following steps are followed:
+
+ Subtract the time stored in pwdChangedTime from the current time to
+ arrive at the password's age. If the password's age is greater than
+ than the value of the pwdMaxAge attribute, a zero status is returned.
+ Subtract the value of the pwdExpireWarning attribute from the value
+ of the pwdMaxAge attribute to arrive at the warning age. If the
+ password's age is equal to or greater than the warning age, the value
+ of pwdMaxAge minus the password's age is returned.
+
+7.6 Intruder Detection Check
+
+ A status of true indicating that an intruder has been detected is
+ returned if the following conditions are met:
+
+ The pwdLockout attribute is TRUE.
+
+ The number of values in the pwdFailureTime attribute that are
+ younger than pwdFailureCountInterval is greater or equal to the
+ pwdMaxFailure attribute.
+
+ Otherwise a status of false is returned.
+
+ While performing this check, values of pwdFailureTime that are old by
+ more than pwdFailureCountInterval are purged and not counted.
+
+7.7 Password Too Young Check
+
+ A status of true indicating that not enough time has passed since the
+ password was last updated is returned if:
+
+ The value of pwdMinAge is non-zero and pwdChangedTime is present.
+
+ The value of pwdMinAge is greater than the current time minus the
+ value of pwdChangedTime.
+
+ Otherwise a false status is returned.
+
+
+
+
+
+
+
+
+
+Sermersheim & Poitou Expires January 18, 2006 [Page 24]
+
+Internet-Draft Password Policy for LDAP Directories July 2005
+
+
+8. Server Policy Enforcement Points
+
+ The server SHOULD enforce that the password attribute subject to a
+ password policy as defined in this document, contains one and only
+ one password value.
+
+ The scenarios in the following operations assume that the client has
+ attached a passwordPolicyRequest control to the request message of
+ the operation. In the event that the passwordPolicyRequest control
+ was not sent, no passwordPolicyResponse control is returned. All
+ other instructions remain the same.
+
+ For successfuly completed operations, unless otherwise stated, no
+ passwordPolicyResponse control is returned.
+
+8.1 Password-based Authentication
+
+ This section contains the policy enforcement rules and policy data
+ updates used while validating a password. Operations that validate
+ passwords include, but are not limited to, the Bind operation where
+ the simple choice specifies a password, and the compare operation
+ where the attribute being compared holds a password. Note that while
+ the compare operation does not authenticate a user to the LDAP
+ server, it may be used by an external application for purposes of
+ authentication.
+
+8.1.1 Fail if the account is locked
+
+ If the account is locked as specified in Section 7.1, the server
+ fails the operation with an appropriate resultCode (i.e.
+ invalidCredentials (49) in the case of a bind operation, compareFalse
+ (5) in the case of a compare operation, etc.). The server MAY set
+ the error: accountLocked (1) in the passwordPolicyResponse in the
+ controls field of the message.
+
+8.1.2 Validated Password Procedures
+
+ If the validation operation indicates that the password validated,
+ these procedures are followed in order:
+
+8.1.2.1 Policy state updates
+
+ Delete the pwdFailureTime and pwdAccountLockedTime attributes.
+
+8.1.2.2 Password must be changed now
+
+ If the decision in Section 7.2 returns true, the server sends to the
+ client a response with an appropriate successful resultCode (i.e.
+
+
+
+Sermersheim & Poitou Expires January 18, 2006 [Page 25]
+
+Internet-Draft Password Policy for LDAP Directories July 2005
+
+
+ success (0), compareTrue (6), etc.), and includes the
+ passwordPolicyResponse in the controls field of the bindResponse
+ message with the warning: changeAfterReset specified.
+
+ For bind, the server MUST then disallow all operations issued by this
+ user except modify password, bind, unbind, abandon and StartTLS
+ extended operation.
+
+8.1.2.3 Expired password
+
+ If the password has expired as per Section 7.3, the server either
+ returns a success or failure based on the state of grace
+ authentications.
+
+8.1.2.3.1 Remaining Grace Authentications
+
+ If there are remaining grace authentications as per Section 7.4, the
+ server adds a new value with the current time in pwdGraceUseTime.
+ Then it sends to the client a response with an appropriate successful
+ resultCode (i.e. success (0), compareTrue (6), etc.), and includes
+ the passwordPolicyResponse in the controls field of the response
+ message with the warning: graceAuthNsRemaining choice set to the
+ number of grace authentications left.
+
+ Implementor's note: The system time of the host machine may be more
+ granular than is needed to ensure unique values of this attribute.
+ It is recommended that a mechanism is used to ensure unique
+ generalized time values. The fractional seconds field may be used
+ for this purpose.
+
+8.1.2.3.2 No Remaining Grace Authentications
+
+ If there are no remaining grace authentications, the server fails the
+ operation with an appropriate resultCode (invalidCredentials (49),
+ compareFalse (5), etc.), and includes the passwordPolicyResponse in
+ the controls field of the bindResponse message with the error:
+ passwordExpired (0) set.
+
+8.1.2.4 Expiration Warning
+
+ If the result of Section 7.5 is a positive number, the server sends
+ to the client a response with an appropriate successful resultCode
+ (i.e. success (0), compareTrue (6), etc.), and includes the
+ passwordPolicyResponse in the controls field of the bindResponse
+ message with the warning: timeBeforeExiration set to the value as
+ described above. Otherwise, the server sends a successful response,
+ and omits the passwordPolicyResponse.
+
+
+
+
+Sermersheim & Poitou Expires January 18, 2006 [Page 26]
+
+Internet-Draft Password Policy for LDAP Directories July 2005
+
+
+8.1.2.5 AuthN Failed Procedures
+
+ If the authentication process indicates that the password failed
+ validation due to invalid credentials, these procedures are followed:
+
+8.1.2.5.1 Policy state update
+
+ Add the current time as a value of the pwdFailureTime attribute.
+
+ Implementor's note: The system time of the host machine may be more
+ granular than is needed to ensure unique values of this attribute.
+ It is recommended that a mechanism is used to ensure unique
+ generalized time values. The fractional seconds field may be used
+ for this purpose.
+
+8.1.2.5.2 Lock on intruder detection
+
+ If the check in Section 7.6 returns a true state, the server locks
+ the account by setting the value of the pwdAccountLockedTime
+ attribute to the current time. After locking the account, the server
+ fails the operation with an appropriate resultCode
+ (invalidCredentials (49), compareFalse (5), etc.), and includes the
+ passwordPolicyResponse in the controls field of the message with the
+ error: accountLocked (1).
+
+8.2 Password Update Operations
+
+ Because the password is stored in an attribute, various operations
+ (like add and modify) may be used to create or update a password.
+ But some alternate mechanisms have been defined or may be defined,
+ such as the LDAP Password Modify Extended Operation [RFC3062].
+
+ While processing a password update, the server performs the following
+ steps:
+
+8.2.1 Safe Modification
+
+ If pwdSafeModify is set to TRUE and if there is an existing password
+ value, the server ensures that the password update operation includes
+ the user's existing password.
+
+ When the LDAP modify operation is used to modify a password, this is
+ done by specifying both a delete action and an add or replace action,
+ where the delete action specifies the existing password, and the add
+ or replace action specifies the new password. Other password update
+ operations SHOULD employ a similar mechanism. Otherwise this policy
+ will fail.
+
+
+
+
+Sermersheim & Poitou Expires January 18, 2006 [Page 27]
+
+Internet-Draft Password Policy for LDAP Directories July 2005
+
+
+ If the existing password is not specified, the server does not
+ process the operation and sends the appropriate response message to
+ the client with the resultCode: insufficientAccessRights (50), and
+ includes the passwordPolicyResponse in the controls field of the
+ response message with the error: mustSupplyOldPassword (4).
+
+8.2.2 Change After Reset
+
+ If the decision in Section 7.2 returns true, the server ensures that
+ the password update operation contains no modifications other than
+ the modification of the password attribute. If other modifications
+ exist, the server sends a response message to the client with the
+ resultCode: insufficientAccessRights (50), and includes the
+ passwordPolicyResponse in the controls field of the response message
+ with the error: changeAfterReset (2).
+
+8.2.3 Rights Check
+
+ Check to see whether the bound identity has sufficient rights to
+ update the password. If the bound identity is a user changing its
+ own password, this MAY be done by checking the pwdAllowUserChange
+ attribute or using an access control mechanism. The determination of
+ this is implementation specific. If the user is not allowed to
+ update her password, the server sends a response message to the
+ client with the resultCode: insufficientAccessRights (50), and
+ includes the passwordPolicyResponse in the controls field of the
+ response message with the error: passwordModNotAllowed (3).
+
+8.2.4 Too Early to Update
+
+ If the check in Section 7.7 results in a true status The server sends
+ a response message to the client with the resultCode:
+ constraintViolation (19), and includes the passwordPolicyResponse in
+ the controls field of the response message with the error:
+ passwordTooYoung (7).
+
+8.2.5 Password Quality
+
+ Check the value of the pwdCheckQuality attribute. If the value is
+ non-zero, the server:
+
+ o Ensure that the password meets the quality criteria enforced by
+ the server. This enforcement is implementation specific.
+ If the server is unable to check the quality (due to a hashed
+ password or otherwise), the value of pwdCheckQuality is evaluated.
+ If the value is 1, operation continues. If the value is 2, the
+ server sends a response message to the client with the resultCode:
+ constraintViolation (19), and includes the passwordPolicyResponse
+
+
+
+Sermersheim & Poitou Expires January 18, 2006 [Page 28]
+
+Internet-Draft Password Policy for LDAP Directories July 2005
+
+
+ in the controls field of the response message with the error:
+ insufficientPasswordQuality (5).
+ If the server is able to check the password quality, and the check
+ fails, the server sends a response message to the client with the
+ resultCode: constraintViolation (19), and includes the
+ passwordPolicyResponse in the controls field of the response
+ message with the error: insufficientPasswordQuality (5).
+
+ o checks the value of the pwdMinLength attribute. If the value is
+ non-zero, it ensures that the new password is of at least the
+ minimum length.
+ If the server is unable to check the length (due to a hashed
+ password or otherwise), the value of pwdCheckQuality is evaluated.
+ If the value is 1, operation continues. If the value is 2, the
+ server sends a response message to the client with the resultCode:
+ constraintViolation (19), and includes the passwordPolicyResponse
+ in the controls field of the response message with the error:
+ passwordTooShort (6).
+ If the server is able to check the password length, and the check
+ fails, the server sends a response message to the client with the
+ resultCode: constraintViolation (19), and includes the
+ passwordPolicyResponse in the controls field of the response
+ message with the error: passwordTooShort (6).
+
+
+8.2.6 Invalid Reuse
+
+ If pwdInHistory is present and its value is non-zero, the server
+ checks whether this password exists in the entry's pwdHistory
+ attribute or in the current password attribute. If the password does
+ exist in the pwdHistory attribute or in the current password
+ attribute, the server sends a response message to the client with the
+ resultCode: constraintViolation (19), and includes the
+ passwordPolicyResponse in the controls field of the response message
+ with the error: passwordInHistory (8).
+
+8.2.7 Policy State Updates
+
+ If the steps have completed without causing an error condition, the
+ server performs the following steps in order to update the necessary
+ password policy state attributes:
+
+ If the value of either pwdMaxAge or pwdMinAge is non-zero, the server
+ updates the pwdChangedTime attribute on the entry to the current
+ time.
+
+ If the value of pwdInHistory is non-zero, the server adds the
+ previous password (if one existed) to the pwdHistory attribute. If
+
+
+
+Sermersheim & Poitou Expires January 18, 2006 [Page 29]
+
+Internet-Draft Password Policy for LDAP Directories July 2005
+
+
+ the number of attributes held in the pwdHistory attribute exceeds the
+ value of pwdInHistory, the server removes the oldest excess
+ passwords.
+
+ If the value the pwdMustChange is TRUE and the modification is
+ performed by a password administrator, then the pwdReset attribute is
+ set to TRUE. Otherwise, the pwdReset is removed from the user's
+ entry if it exists.
+
+ The pwdFailureTime and pwdGraceUseTime attributes is removed from the
+ user's entry if they exist.
+
+8.3 Other Operations
+
+ For operations other than bind, password update, unbind, abandon or
+ StartTLS, if the decision in Section 7.2 returns true, the server
+ sends a response message to the client with the resultCode:
+ insufficientAccessRights (50), and includes the
+ passwordPolicyResponse in the controls field of the response message
+ with the error: changeAfterReset (2).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sermersheim & Poitou Expires January 18, 2006 [Page 30]
+
+Internet-Draft Password Policy for LDAP Directories July 2005
+
+
+9. Client Policy Enforcement Points
+
+ These sections illustrate possible scenarios for each LDAP operation
+ and define the types of responses that identify those scenarios.
+
+ The scenarios in the following operations assume that the client
+ attached a passwordPolicyRequest control to the request message of
+ the operation, and thus may receive a passwordPolicyResponse control
+ in the response message. In the event that the passwordPolicyRequest
+ control was not sent, no passwordPolicyResponse control is returned.
+ All other instructions remain the same.
+
+9.1 Bind Operation
+
+ For every bind response received, the client checks the resultCode of
+ the bindResponse and checks for a passwordPolicyResponse control to
+ determine if any of the following conditions are true and MAY prompt
+ the user accordingly.
+
+ o bindResponse.resultCode = insufficientAccessRights (50),
+ passwordPolicyResponse.error = accountLocked (1): The password
+ failure limit has been reached and the account is locked. The
+ user needs to retry later or contact the password administrator to
+ reset the password.
+
+ o bindResponse.resultCode = success (0),
+ passwordPolicyResponse.error = changeAfterReset (2): The user is
+ binding for the first time after the password administrator set
+ the password. In this scenario, the client SHOULD prompt the user
+ to change his password immediately.
+
+ o bindResponse.resultCode = success (0),
+ passwordPolicyResponse.warning = graceAuthNsRemaining: The
+ password has expired but there are remaining grace
+ authentications. The user needs to change it.
+
+ o bindResponse.resultCode = invalidCredentials (49),
+ passwordPolicyResponse.error = passwordExpired (0): The password
+ has expired and there are no more grace authentications. The user
+ contacts the password administrator in order to have its password
+ reset.
+
+ o bindResponse.resultCode = success (0),
+ passwordPolicyResponse.warning = timeBeforeExpiration: The user's
+ password will expire in n number of seconds.
+
+
+
+
+
+
+Sermersheim & Poitou Expires January 18, 2006 [Page 31]
+
+Internet-Draft Password Policy for LDAP Directories July 2005
+
+
+9.2 Modify Operations
+
+9.2.1 Modify Request
+
+ If the application or client encrypts the password prior to sending
+ it in a password modification operation (whether done through
+ modifyRequest or another password modification mechanism), it SHOULD
+ check the values of the pwdMinLength, and pwdCheckQuality attributes
+ and SHOULD enforce these policies.
+
+9.2.2 Modify Response
+
+ If the modifyRequest operation was used to change the password, or if
+ another mechanism is used --such as an extendedRequest-- the
+ modifyResponse or other appropriate response MAY contain information
+ pertinent to password policy. The client checks the resultCode of
+ the response and checks for a passwordPolicyResponse control to
+ determine if any of the following conditions are true and optionally
+ notify the user of the condition.
+
+ o <pwdModResponse>.resultCode = insufficientAccessRights (50),
+ passwordPolicyResponse.error = mustSupplyOldPassword (4): The user
+ attempted to change her password without specifying the old
+ password but the password policy requires this.
+
+ o <pwdModResponse>.resultCode = insufficientAccessRights (50),
+ passwordPolicyResponse.error = changeAfterReset (2): The user must
+ change her password before submitting any other LDAP requests.
+
+ o <pwdModResponse>.resultCode = insufficientAccessRights (50),
+ passwordPolicyResponse.error = passwordModNotAllowed (3): The user
+ doesn't have sufficient rights to change his password.
+
+ o <pwdModResponse>.resultCode = constraintViolation (19),
+ passwordPolicyResponse.error = passwordTooYoung (7): It is too
+ soon after the last password modification to change the password.
+
+ o <pwdModResponse>.resultCode = constraintViolation (19),
+ passwordPolicyResponse.error = insufficientPasswordQuality (5):
+ The password failed quality checking.
+
+ o <pwdModResponse>.resultCode = constraintViolation (19),
+ passwordPolicyResponse.error = passwordTooShort (6): The length of
+ the password is too short.
+
+ o <pwdModResponse>.resultCode = constraintViolation (19),
+ passwordPolicyResponse.error = passwordInHistory (8): The password
+ has already been used; the user must choose a different one.
+
+
+
+Sermersheim & Poitou Expires January 18, 2006 [Page 32]
+
+Internet-Draft Password Policy for LDAP Directories July 2005
+
+
+9.3 Add Operation
+
+ If a password is specified in an addRequest, the client checks the
+ resultCode of the addResponse and checks for a passwordPolicyResponse
+ control to determine if any of the following conditions are true and
+ may prompt the user accordingly.
+
+ o addResponse.resultCode = insufficientAccessRights (50),
+ passwordPolicyResponse.error = passwordModNotAllowed (3): The user
+ doesn't have sufficient rights to add this password.
+
+ o addResponse.resultCode = constraintViolation (19),
+ passwordPolicyResponse.error = insufficientPasswordQuality (5):
+ The password failed quality checking.
+
+ o addResponse.resultCode = constraintViolation (19),
+ passwordPolicyResponse.error = passwordTooShort (6): The length of
+ the password is too short.
+
+
+9.4 Compare Operation
+
+ When a compare operation is used to compare a password, the client
+ checks the resultCode of the compareResponse and checks for a
+ passwordPolicyResponse to determine if any of the following
+ conditions are true and MAY prompt the user accordingly. These
+ conditions assume that the result of the comparison was true.
+
+ o compareResponse.resultCode = compareFalse (5),
+ passwordPolicyResponse.error = accountLocked (1): The password
+ failure limit has been reached and the account is locked. The
+ user needs to retry later or contact the password administrator to
+ reset the password.
+
+ o compareResponse.resultCode = compareTrue (6),
+ passwordPolicyResponse.warning = graceAuthNsRemaining: The
+ password has expired but there are remaining grace
+ authentications. The user needs to change it.
+
+ o compareResponse.resultCode = compareFalse (5),
+ passwordPolicyResponse.error = passwordExpired (0): The password
+ has expired and there are no more grace authentications. The user
+ must contact the password administrator to reset the password.
+
+ o compareResponse.resultCode = compareTrue (6),
+ passwordPolicyResponse.warning = timeBeforeExpiration: The user's
+ password will expire in n number of seconds.
+
+
+
+
+Sermersheim & Poitou Expires January 18, 2006 [Page 33]
+
+Internet-Draft Password Policy for LDAP Directories July 2005
+
+
+9.5 Other Operations
+
+ For operations other than bind, unbind, abandon or StartTLS, the
+ client checks the following result code and control to determine if
+ the user needs to change the password immediately.
+
+ o <Response>.resultCode = insufficientAccessRights (50),
+ passwordPolicyResponse.error = : changeAfterReset (2)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sermersheim & Poitou Expires January 18, 2006 [Page 34]
+
+Internet-Draft Password Policy for LDAP Directories July 2005
+
+
+10. Administration of the Password Policy
+
+ {TODO: Need to define an administrativeRole (need OID). Need to
+ describe whether pwdPolicy admin areas can overlap}
+
+ A password policy is defined for a particular subtree of the DIT by
+ adding to an LDAP subentry whose immediate superior is the root of
+ the subtree, the pwdPolicy auxiliary object class. The scope of the
+ password policy is defined by the SubtreeSpecification attribute of
+ the LDAP subentry as specified in [RFC3672].
+
+ It is possible to define password policies for different password
+ attributes within the same pwdPolicy entry, by specifying multiple
+ values of the pwdAttribute. But password policies could also be in
+ separate sub entries as long as they are contained under the same
+ LDAP subentry.
+
+ Modifying the password policy MUST NOT result in any change in users'
+ entries to which the policy applies.
+
+ It SHOULD be possible to overwrite the password policy for one user
+ by defining a new policy in a subentry of the user entry.
+
+ Each object that is controlled by password policy advertises the
+ subentry that is being used to control its policy in its
+ pwdPolicySubentry attribute. Clients wishing to examine or manage
+ password policy for an object may interrogate the pwdPolicySubentry
+ for that object in order to arrive at the proper pwdPolicy subentry.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sermersheim & Poitou Expires January 18, 2006 [Page 35]
+
+Internet-Draft Password Policy for LDAP Directories July 2005
+
+
+11. Password Policy and Replication
+
+ {TODO: This section needs to be changed to highlight the pitfals of
+ replication, sugest some implementation choices to overcome those
+ pitfals, but remove prescriptive language relating to the update of
+ state information}
+
+ The pwdPolicy object defines the password policy for a portion of the
+ DIT and MUST be replicated on all the replicas of this subtree, as
+ any subentry would be, in order to have a consistent policy among all
+ replicated servers.
+
+ The elements of the password policy that are related to the users are
+ stored in the entry themselves as operational attributes. As these
+ attributes are subject to modifications even on a read-only replica,
+ replicating them must be carefully considered.
+
+ The pwdChangedTime attribute MUST be replicated on all replicas, to
+ allow expiration of the password.
+
+ The pwdReset attribute MUST be replicated on all replicas, to deny
+ access to operations other than bind and modify password.
+
+ The pwdHistory attribute MUST be replicated to writable replicas. It
+ doesn't have to be replicated to a read-only replica, since the
+ password will never be directly modified on this server.
+
+ The pwdAccountLockedTime, pwdFailureTime and pwdGraceUseTime
+ attributes MUST be replicated to writable replicas, making the
+ password policy global for all servers. When the user entry is
+ replicated to a read-only replica, these attributes SHOULD NOT be
+ replicated. This means that the number of failures, of grace
+ authentications and the locking will take place on each replicated
+ server. For example, the effective number of failed attempts on a
+ user password will be N x M (where N is the number of servers and M
+ the value of pwdMaxFailure attribute). Replicating these attributes
+ to a read-only replica MAY reduce the number of tries globally but
+ MAY also introduce some inconstancies in the way the password policy
+ is applied.
+
+ Servers participating in a loosely consistent multi-master
+ replication agreement SHOULD employ a mechanism which ensures
+ uniqueness of values when populating the attributes pwdFailureTime
+ and pwdGraceUseTime. The method of achieving this is a local matter
+ and may consist of using a single authoritative source for the
+ generation of unique time values, or may consist of the use of the
+ fractional seconds part to hold a replica identifier.
+
+
+
+
+Sermersheim & Poitou Expires January 18, 2006 [Page 36]
+
+Internet-Draft Password Policy for LDAP Directories July 2005
+
+
+12. Security Considerations
+
+ This document defines a set of rules to implement in an LDAP server,
+ in order to mitigate some of the security risks associated with the
+ use of passwords and to make it difficult for password cracking
+ programs to break into directories.
+
+ Authentication with a password MUST follow the recommendations made
+ in [RFC2829].
+
+ Modifications of passwords SHOULD only occur when the connection is
+ protected with confidentiality and secure authentication.
+
+ Access controls SHOULD be used to restrict access to the password
+ policy attributes. The attributes defined to maintain the password
+ policy state information SHOULD only be modifiable by the password
+ administrator or higher authority. The pwdHistory attribute MUST be
+ subject to the same level of access control as the attrbute holding
+ the password.
+
+ As it is possible to define a password policy for one specific user
+ by adding a subentry immediately under the user's entry, Access
+ Controls SHOULD be used to restrict the use of the pwdPolicy object
+ class or the LDAP subentry object class.
+
+ When the intruder detection password policy is enforced, the LDAP
+ directory is subject to a denial of service attack. A malicious user
+ could deliberately lock out one specific user's account (or all of
+ them) by sending bind requests with wrong passwords. There is no way
+ to protect against this kind of attack. The LDAP directory server
+ SHOULD log as much information as it can (such as client IP address)
+ whenever an account is locked, in order to be able to identify the
+ origin of the attack. Denying anonymous access to the LDAP directory
+ is also a way to restrict this kind of attack.
+
+ Returning certain status codes (such as passwordPolicyResponse.error
+ = accountLocked) allows a denial of service attacker to know that it
+ has successfully denied service to an account. Servers SHOULD
+ implement additional checks which return the same status when it is
+ sensed that some number of failed authentication requests has occured
+ on a single connection, or from a client address. Server
+ implementors are encouraged to invent other checks similar to this in
+ order to thwart this type of DoS attack.
+
+
+
+
+
+
+
+
+Sermersheim & Poitou Expires January 18, 2006 [Page 37]
+
+Internet-Draft Password Policy for LDAP Directories July 2005
+
+
+13. IANA Considerations
+
+ <<<TBD>>>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sermersheim & Poitou Expires January 18, 2006 [Page 38]
+
+Internet-Draft Password Policy for LDAP Directories July 2005
+
+
+14. Acknowledgement
+
+ This document is based in part on prior work done by Valerie Chu from
+ Netscape Communications Corp, published as
+ draft-vchu-ldap-pwd-policy-00.txt (December 1998). Prasanta Behera
+ participated in early revisions of this document.
+
+15. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2195] Klensin, J., Catoe, R., and P. Krumviede, "IMAP/POP
+ AUTHorize Extension for Simple Challenge/Response",
+ RFC 2195, September 1997.
+
+ [RFC2222] Myers, J., "Simple Authentication and Security Layer
+ (SASL)", RFC 2222, October 1997.
+
+ [RFC2251] Wahl, M., Howes, T., and S. Kille, "Lightweight Directory
+ Access Protocol (v3)", RFC 2251, December 1997.
+
+ [RFC2252] Wahl, M., Coulbeck, A., Howes, T., and S. Kille,
+ "Lightweight Directory Access Protocol (v3): Attribute
+ Syntax Definitions", RFC 2252, December 1997.
+
+ [RFC2829] Wahl, M., Alvestrand, H., Hodges, J., and R. Morgan,
+ "Authentication Methods for LDAP", RFC 2829, May 2000.
+
+ [RFC2831] Leach, P. and C. Newman, "Using Digest Authentication as a
+ SASL Mechanism", RFC 2831, May 2000.
+
+ [RFC3062] Zeilenga, K., "LDAP Password Modify Extended Operation",
+ RFC 3062, February 2001.
+
+ [RFC3383] Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
+ Considerations for the Lightweight Directory Access
+ Protocol (LDAP)", BCP 64, RFC 3383, September 2002.
+
+ [RFC3672] Zeilenga, K., "Subentries in the Lightweight Directory
+ Access Protocol (LDAP)", RFC 3672, December 2003.
+
+ [X680] International Telecommunications Union, "Abstract Syntax
+ Notation One (ASN.1): Specification of basic notation",
+ ITU-T Recommendation X.680, July 2002.
+
+ [X690] International Telecommunications Union, "Information
+ Technology - ASN.1 encoding rules: Specification of Basic
+
+
+
+Sermersheim & Poitou Expires January 18, 2006 [Page 39]
+
+Internet-Draft Password Policy for LDAP Directories July 2005
+
+
+ Encoding Rules (BER), Canonical Encoding Rules (CER) and
+ Distinguished Encoding Rules (DER)", ITU-T Recommendation
+ X.690, July 2002.
+
+
+Authors' Addresses
+
+ Jim Sermersheim
+ Novell, Inc
+ 1800 South Novell Place
+ Provo, Utah 84606
+ USA
+
+ Phone: +1 801 861-3088
+ Email: jimse at novell.com
+
+
+ Ludovic Poitou
+ Sun Microsystems
+ 180, Avenue de l'Europe
+ Zirst de Montbonnot, 38334 Saint Ismier cedex
+ France
+
+ Phone: +33 476 188 212
+ Email: ludovic.poitou at sun.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sermersheim & Poitou Expires January 18, 2006 [Page 40]
+
+Internet-Draft Password Policy for LDAP Directories July 2005
+
+
+Intellectual Property Statement
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr at ietf.org.
+
+
+Disclaimer of Validity
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+Copyright Statement
+
+ Copyright (C) The Internet Society (2005). This document is subject
+ to the rights, licenses and restrictions contained in BCP 78, and
+ except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+Sermersheim & Poitou Expires January 18, 2006 [Page 41]
+
+
Added: openldap/vendor/openldap-release/doc/drafts/draft-chu-ldap-csn-xx.txt
===================================================================
--- openldap/vendor/openldap-release/doc/drafts/draft-chu-ldap-csn-xx.txt (rev 0)
+++ openldap/vendor/openldap-release/doc/drafts/draft-chu-ldap-csn-xx.txt 2007-09-15 10:38:52 UTC (rev 844)
@@ -0,0 +1,424 @@
+
+
+
+
+
+
+INTERNET-DRAFT Howard Y. Chu
+Intended Category: Standard Track Symas Corporation
+Expires in six months 1 December 2004
+
+
+ Change Sequence Numbers for LDAP
+ <draft-chu-ldap-csn-00.txt>
+
+
+Status of this Memo
+
+ This document is an Internet-Draft and is in full conformance with all
+ provisions of Section 10 of RFC2026.
+
+ This document is intended to be, after appropriate review and
+ revision, submitted to the RFC Editor as an Standard Track document.
+ Distribution of this memo is unlimited. Technical discussion of this
+ document will take place on the IETF LDAP Extensions mailing list
+ <ldapext at ietf.org>. Please send editorial comments directly to the
+ author <Kurt at OpenLDAP.org>.
+
+ Internet-Drafts are working documents of the Internet Engineering Task
+ Force (IETF), its areas, and its working groups. Note that other
+ groups may also distribute working documents as Internet-Drafts.
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference
+ material or to cite them other than as ``work in progress.''
+
+ The list of current Internet-Drafts can be accessed at
+ <http://www.ietf.org/ietf/1id-abstracts.txt>. The list of
+ Internet-Draft Shadow Directories can be accessed at
+ <http://www.ietf.org/shadow.html>.
+
+ Copyright (C) The Internet Society (2004). All Rights Reserved.
+
+ Please see the Full Copyright section near the end of this document
+ for more information.
+
+
+Abstract
+
+ This document describes the LDAP/X.500 Change Sequence Number 'CSN'
+ syntax and matching rules and associated attributes. CSNs are used
+ to impose a total ordering upon the sequence of updates applied
+ to a directory.
+
+
+
+
+Chu draft-chu-ldap-csn-00 [Page 1]
+
+INTERNET-DRAFT LDAP CSN 1 December 2004
+
+
+1. Background and Intended Use
+
+ In X.500 Directory Services [X.501], updates to a directory may need
+ to be distributed to multiple servers. The 'modifyTimeStamp' is already
+ defined for recording the time of an update, but it may be inadequate in
+ an environment where multiple servers with loosely synchronized clocks
+ are interoperating.
+
+ This document describes the 'CSN' syntax which augments a timestamp with
+ additional information to assist in coordinating updates among multiple
+ directory servers. This document describes the 'entryCSN' operational
+ attribute which carries the CSN of the last update applied to an entry
+ and also the 'contextCSN' operational attribute which carries the
+ greatest CSN of all updates applied to a directory context. Directory
+ clients and servers may use these attributes to assist in synchronizing
+ shadowed copies of directory information.
+
+ This document describes the 'csnMatch' and 'csnOrderingMatch' matching
+ rules corresponding to the 'CSN' syntax.
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in BCP 14 [RFC2119].
+
+ Schema definitions are provided using LDAP description formats
+ [RFC2252]. Definitions provided here are formatted (line wrapped) for
+ readability.
+
+
+2. CSN Schema Elements
+
+2.1 CSN Syntax
+
+ Values in this syntax are encoded according to the following BNF:
+
+ CSN = timestamp '#' operation-counter '#' replica-id
+
+ timestamp = <generalizedTimeString as specified in 6.14 of [RFC2252]>
+
+ operation-counter = 6hex-digit
+
+ replica-id = 2hex-digit
+
+ The timestamp SHALL use GMT and SHALL NOT include fractional seconds.
+
+ The operation-counter is set to zero at the start of each second, and
+ incremented by one for each update operation that occurs within that
+ second.
+
+ The replica-id is an identifier that represents a specific Replica in
+ a collection of cooperating servers.
+
+ The following is a LDAP syntax description [RFC2252] suitable for
+ publication in the subschema.
+
+ ( IANA-ASSIGNED-OID.1 DESC 'CSN' )
+
+
+
+
+
+Chu draft-chu-ldap-csn-00 [Page 2]
+
+INTERNET-DRAFT LDAP CSN 1 December 2004
+
+
+2.2 'csnMatch' Matching Rule
+
+ The 'csnMatch' matching rule compares an asserted CSN with a stored
+ CSN for equality. Its semantics are same as the octetStringMatch
+ [X.520][RFC2252] matching rule.
+
+ The following is a LDAP matching rule description [RFC2252] suitable
+ for publication in the subschema.
+
+ ( IANA-ASSIGNED-OID.2 NAME 'csnMatch'
+ SYNTAX IANA-ASSIGNED-OID.1 )
+
+
+2.3 'csnOrderingMatch' Matching Rule
+
+ The 'csnOrderingMatch' matching rule compares an asserted CSN
+ with a stored CSN for ordering. Its semantics are the same as the
+ octetStringOrderingMatch [X.520][RFC2252] matching rule.
+
+ The following is a LDAP matching rule description [RFC2252] suitable
+ for publication in the subschema.
+
+ ( IANA-ASSIGNED-OID.3 NAME 'csnOrderingMatch'
+ SYNTAX IANA-ASSIGNED-OID.1 )
+
+
+2.4. 'entryCSN' attribute
+
+ The 'entryCSN' operational attribute provides the CSN of the last
+ update applied to the entry.
+
+ The following is a LDAP attribute type description [RFC2252] suitable
+ for publication in the subschema.
+
+ ( IANA-ASSIGNED-OID.4 NAME 'entryCSN'
+ DESC 'CSN of the entry content'
+ EQUALITY csnMatch
+ ORDERING csnOrderingMatch
+
+
+
+Chu draft-chu-ldap-csn-00 [Page 3]
+
+INTERNET-DRAFT LDAP CSN 1 December 2004
+
+
+ SYNTAX IANA-ASSIGNED-OID.1
+ SINGLE-VALUE
+ NO-USER-MODIFICATION
+ USAGE directoryOperation )
+
+ Servers SHALL assign a CSN to each entry upon its addition to the
+ directory and provide the entry's CSN as the value of the
+ 'entryCSN' operational attribute. The entryCSN attribute SHOULD be
+ updated upon every update of the entry.
+
+2.5. 'contextCSN' attribute
+
+ The 'contextCSN' operational attribute provides the greatest CSN of
+ all the updates applied to a context.
+
+ The following is a LDAP attribute type description [RFC2252] suitable
+ for publication in the subschema.
+
+ ( IANA-ASSIGNED-OID.5 NAME 'contextCSN'
+ DESC 'the largest committed CSN of a context'
+ EQUALITY csnMatch
+ ORDERING csnOrderingMatch
+ SYNTAX IANA-ASSIGNED-OID.1
+ SINGLE-VALUE
+ NO-USER-MODIFICATION
+ USAGE directoryOperation )
+
+ Servers SHALL record the greatest CSN of all updates applied to a
+ context in the root entry of the context.
+
+
+3. Security Considerations
+
+
+ General LDAP security considerations [RFC3377] apply.
+
+
+4. IANA Considerations
+
+4.1. Object Identifier Registration
+
+ It is requested that IANA register upon Standards Action an LDAP
+ Object Identifier for use in this technical specification.
+
+ Subject: Request for LDAP OID Registration
+ Person & email address to contact for further information:
+ Howard Chu <hyc at symas.com>
+ Specification: RFC XXXX
+ Author/Change Controller: IESG
+ Comments:
+ Identifies the CSN schema elements
+
+
+4.2. Registration of the csnMatch descriptor
+
+ It is requested that IANA register upon Standards Action the LDAP
+ 'csnMatch' descriptor.
+
+ Subject: Request for LDAP Descriptor Registration
+ Descriptor (short name): csnMatch
+ Object Identifier: IANA-ASSIGNED-OID.2
+ Person & email address to contact for further information:
+ Howard Chu <hyc at symas.com>
+ Usage: Matching Rule
+ Specification: RFC XXXX
+ Author/Change Controller: IESG
+
+
+
+
+Chu draft-chu-ldap-csn-00 [Page 4]
+
+INTERNET-DRAFT LDAP CSN 1 December 2004
+
+
+4.3. Registration of the csnOrderingMatch descriptor
+
+ It is requested that IANA register upon Standards Action the LDAP
+ 'csnOrderingMatch' descriptor.
+
+ Subject: Request for LDAP Descriptor Registration
+ Descriptor (short name): csnOrderingMatch
+ Object Identifier: IANA-ASSIGNED-OID.3
+ Person & email address to contact for further information:
+ Howard Chu <hyc at symas.com>
+ Usage: Matching Rule
+ Specification: RFC XXXX
+ Author/Change Controller: IESG
+
+
+4.4. Registration of the entryCSN descriptor
+
+ It is requested that IANA register upon Standards Action the LDAP
+ 'entryCSN' descriptor.
+
+ Subject: Request for LDAP Descriptor Registration
+ Descriptor (short name): entryCSN
+ Object Identifier: IANA-ASSIGNED-OID.4
+ Person & email address to contact for further information:
+ Howard Chu <hyc at symas.com>
+ Usage: Attribute Type
+ Specification: RFC XXXX
+ Author/Change Controller: IESG
+
+
+4.5. Registration of the contextCSN descriptor
+
+ It is requested that IANA register upon Standards Action the LDAP
+ 'contextCSN' descriptor.
+
+ Subject: Request for LDAP Descriptor Registration
+ Descriptor (short name): contextCSN
+ Object Identifier: IANA-ASSIGNED-OID.5
+ Person & email address to contact for further information:
+ Howard Chu <hyc at symas.com>
+ Usage: Attribute Type
+ Specification: RFC XXXX
+ Author/Change Controller: IESG
+
+
+5. Acknowledgments
+
+ This document is based on prior work from the IETF LDUP working
+ group including the LDAP Replication Architecture [LDUPMODEL]
+ and the LDAP Content Synchronization Operation [LDUPSYNC].
+
+
+6. Author's Addresses
+
+ Howard Y. Chu
+ Symas Corporation
+ <hyc at symas.com>
+
+ Kurt D. Zeilenga
+ OpenLDAP Foundation
+ <Kurt at OpenLDAP.org>
+
+
+7. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14 (also RFC 2119), March 1997.
+
+
+
+Chu draft-chu-ldap-csn-00 [Page 5]
+
+INTERNET-DRAFT LDAP CSN 1 December 2004
+
+
+ [RFC2252] Wahl, M., A. Coulbeck, T. Howes, and S. Kille,
+ "Lightweight Directory Access Protocol (v3): Attribute
+ Syntax Definitions", RFC 2252, December 1997.
+
+ [RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access
+ Protocol (v3): Technical Specification", RFC 3377,
+ September 2002.
+
+ [X.501] International Telecommunication Union -
+ Telecommunication Standardization Sector, "The Directory
+ -- Models," X.501(1993) (also ISO/IEC 9594-2:1994).
+
+ [X.520] International Telecommunication Union -
+ Telecommunication Standardization Sector, "The
+ Directory: Selected Attribute Types", X.520(1993) (also
+ ISO/IEC 9594-6:1994).
+
+ [X.680] International Telecommunication Union -
+ Telecommunication Standardization Sector, "Abstract
+ Syntax Notation One (ASN.1) - Specification of Basic
+ Notation", X.680(1997) (also ISO/IEC 8824-1:1998).
+
+ [LDUPSYNC] Zeilenga, K. and Choi, J-H "LDAP Content Synchronization
+ Operation", draft-zeilenga-ldup-sync-05.txt, a work in
+ progress.
+
+
+8. Informative References
+
+ [RFC3383] Zeilenga, K., "IANA Considerations for LDAP", BCP 64
+ (also RFC 3383), September 2002.
+
+ [LDUPMODEL] Merrellls, J., Srinivasan, U., and Reed, E., "LDAP
+ Replication Architecture", draft-ietf-ldup-model-09.txt.
+
+
+
+Intellectual Property Rights
+
+ The IETF takes no position regarding the validity or scope of any
+
+
+
+Chu draft-chu-ldap-csn-00 [Page 6]
+
+INTERNET-DRAFT LDAP CSN 1 December 2004
+
+
+ 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 (2004). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its 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
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be followed,
+ or as required to translate it into languages other than English.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Chu draft-chu-ldap-csn-00 [Page 7]
+
Added: openldap/vendor/openldap-release/doc/drafts/draft-ietf-ldapbis-authmeth-xx.txt
===================================================================
--- openldap/vendor/openldap-release/doc/drafts/draft-ietf-ldapbis-authmeth-xx.txt (rev 0)
+++ openldap/vendor/openldap-release/doc/drafts/draft-ietf-ldapbis-authmeth-xx.txt 2007-09-15 10:38:52 UTC (rev 844)
@@ -0,0 +1,1937 @@
+
+INTERNET-DRAFT Editor: R. Harrison
+draft-ietf-ldapbis-authmeth-19.txt Novell, Inc.
+Obsoletes: 2251, 2829, 2830 February 2006
+Intended Category: Standards Track
+
+
+
+
+
+
+
+ LDAP: Authentication Methods
+ and
+ Security Mechanisms
+
+Status of this Memo
+
+ By submitting this Internet-Draft, each author represents that any
+ applicable patent or other IPR claims of which he or she is aware
+ have been or will be disclosed, and any of which he or she becomes
+ aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+ This document is intended to be, after appropriate review and
+ revision, submitted to the RFC Editor as a Standard Track document.
+ Distribution of this memo is unlimited. Technical discussion of
+ this document will take place on the IETF LDAP Revision Working
+ Group mailing list <ietf-ldapbis at OpenLDAP.org>. Please send
+ editorial comments directly to the author
+ <roger_harrison at novell.com>.
+
+ Internet-Drafts are working documents of the Internet Engineering
+ Task Force (IETF), its areas, and its working groups. Note that
+ other groups may also distribute working documents as Internet-
+ Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of six
+ months and may be updated, replaced, or obsoleted by other documents
+ at any time. It is inappropriate to use Internet-Drafts as
+ reference material or to cite them other than as "work in progress."
+
+ The list of current Internet-Drafts can be accessed at
+ http://www.ietf.org/ietf/1id-abstracts.html
+
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html.
+
+Abstract
+
+ This document describes authentication methods and security
+ mechanisms of the Lightweight Directory Access Protocol (LDAP).
+
+
+
+Harrison Expires August 2006 [Page 1]
+
+Internet-Draft LDAP Authentication Methods February 2006
+
+ This document details establishment of Transport Layer Security
+ (TLS) using the StartTLS operation.
+
+ This document details the simple Bind authentication method
+ including anonymous, unauthenticated, and name/password mechanisms
+ and the Simple Authentication and Security Layer (SASL) Bind
+ authentication method including the EXTERNAL mechanism.
+
+ This document discusses various authentication and authorization
+ states through which a session to an LDAP server may pass and the
+ actions that trigger these state changes.
+
+ This document, together with other documents in the LDAP Technical
+ Specification (see section 1 of [Roadmap]), obsoletes RFC 2251, RFC
+ 2829 and RFC 2830.
+
+Table of Contents
+
+ 1. Introduction.....................................................3
+ 1.1. Relationship to Other Documents................................5
+ 1.2. Conventions....................................................6
+ 2. Implementation Requirements......................................7
+ 3. StartTLS Operation...............................................7
+ 3.1. TLS Establishment Procedures...................................7
+ 3.1.1. StartTLS Request Sequencing..................................8
+ 3.1.2. Client Certificate...........................................8
+ 3.1.3. Server Identity Check........................................8
+ 3.1.3.1. Comparison of DNS Names...................................10
+ 3.1.3.2. Comparison of IP Addresses................................10
+ 3.1.3.3. Comparison of other subjectName types.....................10
+ 3.1.4. Discovery of Resultant Security Level.......................10
+ 3.1.5. Refresh of Server Capabilities Information..................11
+ 3.2. Effect of TLS on Authorization State..........................11
+ 3.3. TLS Ciphersuites..............................................11
+ 4. Authorization State.............................................12
+ 5. Bind Operation..................................................13
+ 5.1. Simple Authentication Method..................................13
+ 5.1.1. Anonymous Authentication Mechanism of Simple Bind...........13
+ 5.1.2. Unauthenticated Authentication Mechanism of Simple Bind.....13
+ 5.1.3. Name/Password Authentication Mechanism of Simple Bind.......14
+ 5.2. SASL Authentication Method....................................15
+ 5.2.1. SASL Protocol Profile.......................................15
+ 5.2.1.1. SASL Service Name for LDAP................................15
+ 5.2.1.2. SASL Authentication Initiation and Protocol Exchange......15
+ 5.2.1.3. Optional Fields...........................................16
+ 5.2.1.4. Octet Where Negotiated Security Layers Take Effect........17
+ 5.2.1.5. Determination of Supported SASL Mechanisms................17
+ 5.2.1.6. Rules for Using SASL Layers...............................17
+ 5.2.1.7. Support for Multiple Authentications......................18
+ 5.2.1.8. SASL Authorization Identities.............................18
+ 5.2.2. SASL Semantics Within LDAP..................................19
+
+Harrison Expires August 2006 [Page 2]
+
+Internet-Draft LDAP Authentication Methods February 2006
+
+ 5.2.3. SASL EXTERNAL Authentication Mechanism......................19
+ 5.2.3.1. Implicit Assertion........................................19
+ 5.2.3.2. Explicit Assertion........................................20
+ 6. Security Considerations.........................................20
+ 6.1. General LDAP Security Considerations..........................20
+ 6.2. StartTLS Security Considerations..............................21
+ 6.3. Bind Operation Security Considerations........................21
+ 6.3.1. Unauthenticated Mechanism Security Considerations...........21
+ 6.3.2. Name/Password Mechanism Security Considerations.............22
+ 6.3.3. Password-related Security Considerations....................22
+ 6.3.4. Hashed Password Security Considerations.....................23
+ 6.4.SASL Security Considerations...................................23
+ 6.5. Related Security Considerations...............................23
+ 7. IANA Considerations.............................................24
+ 8. Acknowledgments.................................................24
+ 9. Normative References............................................24
+ 10. Informative References.........................................25
+ Author's Address...................................................26
+ Appendix A. Authentication and Authorization Concepts..............26
+ A.1. Access Control Policy.........................................26
+ A.2. Access Control Factors........................................26
+ A.3. Authentication, Credentials, Identity.........................27
+ A.4. Authorization Identity........................................27
+ Appendix B. Summary of Changes.....................................27
+ B.1. Changes Made to RFC 2251......................................28
+ B.1.1. Section 4.2.1 (Sequencing of the Bind Request)..............28
+ B.1.2. Section 4.2.2 (Authentication and Other Security Services)..28
+ B.2. Changes Made to RFC 2829......................................28
+ B.2.1. Section 4 (Required security mechanisms)....................29
+ B.2.2. Section 5.1 (Anonymous authentication procedure)............29
+ B.2.3. Section 6 (Password-based authentication)...................29
+ B.2.4. Section 6.1 (Digest authentication).........................29
+ B.2.5. Section 6.2 ("simple" authentication choice with TLS).......29
+ B.2.6. Section 6.3 (Other authentication choices with TLS).........29
+ B.2.7. Section 7.1 (Certificate-based authentication with TLS).....30
+ B.2.8. Section 8 (Other mechanisms)................................30
+ B.2.9. Section 9 (Authorization identity)..........................30
+ B.2.10. Section 10 (TLS Ciphersuites)..............................30
+ B.3. Changes Made to RFC 2830: ....................................30
+ B.3.1. Section 3.6 (Server Identity Check).........................30
+ B.3.2. Section 3.7 (Refresh of Server Capabilities Information)....31
+ B.3.3. Section 5.2 (Effects of TLS on Authorization Identity)......31
+ B.3.4. Section 5.1.1 (TLS Closure Effects).........................31
+ Appendix C. Changes for draft-ldapbis-authmeth-19..................31
+ Intellectual Property Rights.......................................32
+ Full Copyright Statement...........................................33
+
+
+1. Introduction
+
+
+Harrison Expires August 2006 [Page 3]
+
+Internet-Draft LDAP Authentication Methods February 2006
+
+ The Lightweight Directory Access Protocol (LDAP) [Roadmap] is a
+ powerful protocol for accessing directories. It offers means of
+ searching, retrieving and manipulating directory content and ways to
+ access a rich set of security functions.
+
+ It is vital that these security functions be interoperable among all
+ LDAP clients and servers on the Internet; therefore there has to be
+ a minimum subset of security functions that is common to all
+ implementations that claim LDAP conformance.
+
+ Basic threats to an LDAP directory service include (but are not
+ limited to):
+
+ (1) Unauthorized access to directory data via data-retrieval
+ operations.
+
+ (2) Unauthorized access to directory data by monitoring access of
+ others.
+
+ (3) Unauthorized access to reusable client authentication
+ information by monitoring access of others.
+
+ (4) Unauthorized modification of directory data.
+
+ (5) Unauthorized modification of configuration information.
+
+ (6) Denial of Service: Use of resources (commonly in excess) in a
+ manner intended to deny service to others.
+
+ (7) Spoofing: Tricking a user or client into believing that
+ information came from the directory when in fact it did not,
+ either by modifying data in transit or misdirecting the client's
+ transport connection. Tricking a user or client into sending
+ privileged information to a hostile entity that appears to be
+ the directory server but is not. Tricking a directory server
+ into believing that information came from a particular client
+ when in fact it came from a hostile entity.
+
+ (8) Hijacking: An attacker seizes control of an established protocol
+ session.
+
+ Threats (1), (4), (5), (6), (7) are (8) are active attacks. Threats
+ (2) and (3) are passive attacks.
+
+ Threats (1), (4), (5) and (6) are due to hostile clients. Threats
+ (2), (3), (7) and (8) are due to hostile agents on the path between
+ client and server or hostile agents posing as a server, e.g., IP
+ spoofing.
+
+ LDAP offers the following security mechanisms:
+
+
+
+
+
+Harrison Expires August 2006 [Page 4]
+
+Internet-Draft LDAP Authentication Methods February 2006
+
+ (1) Authentication by means of the Bind operation. The Bind
+ operation provides a simple method which supports anonymous,
+ unauthenticated, and name/password mechanisms, and the Simple
+ Authentication and Security Layer (SASL) method which supports a
+ wide variety of authentication mechanisms.
+
+ (2) Mechanisms to support vendor-specific access control facilities
+ (LDAP does not offer a standard access control facility).
+
+ (3) Data integrity service by means of security layers in Transport
+ Layer Security (TLS) or SASL mechanisms.
+
+ (4) Data confidentiality service by means of security layers in TLS
+ or SASL mechanisms.
+
+ (5) Server resource usage limitation by means of administrative
+ limits configured on the server.
+
+ (6) Server authentication by means of the TLS protocol or SASL
+ mechanisms.
+
+ LDAP may also be protected by means outside the LDAP protocol, e.g.,
+ with IP-level security [RFC4301].
+
+ Experience has shown that simply allowing implementations to pick
+ and choose the security mechanisms that will be implemented is not a
+ strategy that leads to interoperability. In the absence of
+ mandates, clients will continue to be written that do not support
+ any security function supported by the server, or worse, they will
+ only support mechanisms that provide inadequate security for most
+ circumstances.
+
+ It is desirable to allow clients to authenticate using a variety of
+ mechanisms including mechanisms where identities are represented as
+ distinguished names [X.501][Models] in string form [LDAPDN] or as
+ used in different systems (e.g., simple user names [RFC4013]).
+ Because some authentication mechanisms transmit credentials in plain
+ text form, and/or do not provide data security services and/or are
+ subject to passive attacks, it is necessary to ensure secure
+ interoperability by identifying a mandatory-to-implement mechanism
+ for establishing transport-layer security services.
+
+ The set of security mechanisms provided in LDAP and described in
+ this document is intended to meet the security needs for a wide
+ range of deployment scenarios and still provide a high degree of
+ interoperability among various LDAP implementations and deployments.
+
+1.1. Relationship to Other Documents
+
+ This document is an integral part of the LDAP Technical
+ Specification [Roadmap].
+
+
+
+
+Harrison Expires August 2006 [Page 5]
+
+Internet-Draft LDAP Authentication Methods February 2006
+
+ This document, together with [Roadmap], [Protocol], and [Models],
+ obsoletes RFC 2251 in its entirety. Sections 4.2.1 (portions), and
+ 4.2.2 of RFC 2251 are obsoleted by this document. Appendix B.1
+ summarizes the substantive changes made to RFC 2251 by this document.
+
+ This document obsoletes RFC 2829 in its entirety. Appendix B.2
+ summarizes the substantive changes made to RFC 2829 by this document.
+
+ Sections 2 and 4 of RFC 2830 are obsoleted by [Protocol]. The
+ remainder of RFC 2830 is obsoleted by this document. Appendix B.3
+ summarizes the substantive changes made to RFC 2830 by this document.
+
+
+1.2. Conventions
+
+ The key words "MUST", "MUST NOT", "SHALL", "SHOULD", "SHOULD NOT",
+ "MAY", and "OPTIONAL" in this document are to be interpreted as
+ described in RFC 2119 [RFC2119].
+
+ The term "user" represents any human or application entity which is
+ accessing the directory using a directory client. A directory
+ client (or client) is also known as a directory user agent (DUA).
+
+ The term "transport connection" refers to the underlying transport
+ services used to carry the protocol exchange, as well as
+ associations established by these services.
+
+ The term "TLS layer" refers to TLS services used in providing
+ security services, as well as associations established by these
+ services.
+
+ The term "SASL layer" refers to SASL services used in providing
+ security services, as well as associations established by these
+ services.
+
+ The term "LDAP message layer" refers to the LDAP Message (PDU)
+ services used in providing directory services, as well as
+ associations established by these services.
+
+ The term "LDAP session" refers to combined services (transport
+ connection, TLS layer, SASL layer, LDAP message layer) and their
+ associations.
+
+ In general, security terms in this document are used consistently
+ with the definitions provided in [RFC2828]. In addition, several
+ terms and concepts relating to security, authentication, and
+ authorization are presented in Appendix A of this document. While
+ the formal definition of these terms and concepts is outside the
+ scope of this document, an understanding of them is prerequisite to
+ understanding much of the material in this document. Readers who
+ are unfamiliar with security-related concepts are encouraged to
+ review Appendix A before reading the remainder of this document.
+
+
+
+Harrison Expires August 2006 [Page 6]
+
+Internet-Draft LDAP Authentication Methods February 2006
+
+2. Implementation Requirements
+
+ LDAP server implementations MUST support the anonymous
+ authentication mechanism of the simple Bind method (section 5.1.1).
+
+ LDAP implementations that support any authentication mechanism other
+ than the anonymous authentication mechanism of the simple Bind
+ method MUST support the name/password authentication mechanism of
+ the simple Bind method (section 5.1.3) and MUST be capable of
+ protecting this name/password authentication using TLS as
+ established by the StartTLS operation (section 3).
+
+ Implementations SHOULD disallow the use of the name/password
+ authentication mechanism by default when suitable data security
+ services are not in place, and MAY provide other suitable data
+ security services for use with this authentication mechanism.
+
+ Implementations MAY support additional authentication mechanisms.
+ Some of these mechanisms are discussed below.
+
+ LDAP server implementations SHOULD support client assertion of
+ authorization identity via the SASL EXTERNAL mechanism (section
+ 5.2.3).
+
+ LDAP server implementations that support no authentication mechanism
+ other than the anonymous mechanism of the simple bind method SHOULD
+ support use of TLS as established by the the StartTLS operation
+ (section 3). (Other servers MUST support TLS per the second
+ paragraph of this section.)
+
+ Implementations supporting TLS MUST support the
+ TLS_RSA_WITH_3DES_EDE_CBC_SHA ciphersuite and SHOULD support the
+ TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA ciphersuite. Support for the
+ latter ciphersuite is recommended to encourage interoperability with
+ implementations conforming to earlier LDAP StartTLS specifications.
+
+
+3. StartTLS Operation
+
+ The Start Transport Layer Security (StartTLS) operation defined in
+ section 4.14 of [Protocol] provides the ability to establish TLS
+ [TLS] in an LDAP session.
+
+ The goals of using the TLS [TLS] protocol with LDAP are to ensure
+ data confidentiality and integrity, and to optionally provide for
+ authentication. TLS expressly provides these capabilities, although
+ the authentication services of TLS are available to LDAP only in
+ combination with the SASL EXTERNAL authentication method (see
+ section 5.2.3), and then only if the SASL EXTERNAL implementation
+ chooses to make use of the TLS credentials.
+
+
+3.1. TLS Establishment Procedures
+
+
+Harrison Expires August 2006 [Page 7]
+
+Internet-Draft LDAP Authentication Methods February 2006
+
+ This section describes the overall procedures clients and servers
+ must follow for TLS establishment. These procedures take into
+ consideration various aspects of the TLS layer including discovery
+ of resultant security level and assertion of the client's
+ authorization identity.
+
+
+3.1.1. StartTLS Request Sequencing
+
+ A client may send the StartTLS extended request at any time after
+ establishing an LDAP session, except:
+
+ - when TLS is currently established on the session,
+ - when a multi-stage SASL negotiation is in progress on the
+ session, or
+ - when there are outstanding responses for operation requests
+ previously issued on the session.
+
+ As described in [Protocol] Section 4.14.1, a (detected) violation of
+ any of these requirements results in a return of the operationsError
+ resultCode.
+
+ Client implementers should ensure that they strictly follow these
+ operation sequencing requirements to prevent interoperability
+ issues. Operational experience has shown that violating these
+ requirements causes interoperability issues because there are race
+ conditions that prevent servers from detecting some violations of
+ these requirements due to factors such as server hardware speed and
+ network latencies.
+
+ There is no general requirement that the client have or have not
+ already performed a Bind operation (section 5) before sending a
+ StartTLS operation request, however where a client intends to
+ perform both a Bind operation and a StartTLS operation, it SHOULD
+ first perform the StartTLS operation so that the Bind request and
+ response messages are protected by the data security services
+ established by the StartTLS operation.
+
+
+3.1.2. Client Certificate
+
+ If an LDAP server requests or demands that a client provide a user
+ certificate during TLS negotiation and the client does not present a
+ suitable user certificate (e.g., one that can be validated), the
+ server may use a local security policy to determine whether to
+ successfully complete TLS negotiation.
+
+ If a client that has provided a suitable certificate subsequently
+ performs a Bind operation using the SASL EXTERNAL authentication
+ mechanism (section 5.2.3), information in the certificate may be
+ used by the server to identify and authenticate the client.
+
+
+3.1.3. Server Identity Check
+
+Harrison Expires August 2006 [Page 8]
+
+Internet-Draft LDAP Authentication Methods February 2006
+
+
+ In order to prevent man-in-the-middle attacks the client MUST verify
+ the server's identity (as presented in the server's Certificate
+ message). In this section, the client's understanding of the
+ server's identity (typically the identity used to establish the
+ transport connection) is called the "reference identity".
+
+ The client determines the type (e.g., DNS name or IP address) of the
+ reference identity and performs a comparison between the reference
+ identity and each subjectAltName value of the corresponding type
+ until a match is produced. Once a match is produced, the server's
+ identity has been verified and the server identity check is
+ complete. Different subjectAltName types are matched in different
+ ways. Sections 3.1.3.1 - 3.1.3.3 explain how to compare values of
+ various subjectAltName types.
+
+ The client may map the reference identity to a different type prior
+ to performing a comparison. Mappings may be performed for all
+ available subjectAltName types to which the reference identity can
+ be mapped, however the reference identity should only be mapped to
+ types for which the mapping is either inherently secure (e.g.,
+ extracting the DNS name from a URI to compare with a subjectAltName
+ of type dNSName) or for which the mapping is performed in a secure
+ manner (e.g., using DNSSec, or using user- (or admin-) configured
+ host-to-address/address-to-host lookup tables).
+
+ The server's identity may also be verified by comparing the
+ reference identity to the Common Name (CN) [Schema] value in the
+ leaf RDN of the subjectName field of the server's certificate. This
+ comparison is performed using the rules for comparison of DNS names
+ in section 3.1.3.1 below, with the exception that no wildcard
+ matching is allowed. Although the use of the Common Name value is
+ existing practice, it is deprecated and Certification Authorities
+ are encouraged to provide subjectAltName values instead. Note that
+ the TLS implementation may represent DNs in certificates according
+ to X.500 or other conventions. For example, some X.500
+ implementations order the RDNs in a DN using a left-to-right (most
+ significant to least significant) convention instead of LDAP's
+ right-to-left convention.
+
+ If the server identity check fails, user-oriented clients SHOULD
+ either notify the user (clients may give the user the opportunity to
+ continue with the LDAP session in this case) or close the transport
+ connection and indicate that the server's identity is suspect.
+ Automated clients SHOULD close the transport connection and then
+ return or log an error indicating that the server's identity is
+ suspect or both.
+
+ Beyond the server identity check described in this section, clients
+ should be prepared to do further checking to ensure that the server
+ is authorized to provide the service it is requested to provide.
+ The client may need to make use of local policy information in
+ making this determination.
+
+
+Harrison Expires August 2006 [Page 9]
+
+Internet-Draft LDAP Authentication Methods February 2006
+
+
+3.1.3.1. Comparison of DNS Names
+
+ If the reference identity is an internationalized domain name,
+ conforming implementations MUST convert it to the ASCII Compatible
+ Encoding (ACE) format as specified in section 4 of RFC 3490
+ [RFC3490] before comparison with subjectAltName values of type
+ dNSName. Specifically, conforming implementations MUST perform the
+ conversion operation specified in section 4 of RFC 3490 as follows:
+
+ * in step 1, the domain name SHALL be considered a "stored
+ string";
+ * in step 3, set the flag called "UseSTD3ASCIIRules";
+ * in step 4, process each label with the "ToASCII"
+ operation; and
+ * in step 5, change all label separators to U+002E (full
+ stop).
+
+ After performing the "to-ASCII" conversion, the DNS labels and names
+ MUST be compared for equality according to the rules specified in
+ section 3 of RFC3490.
+
+ The '*' (ASCII 42) wildcard character is allowed in subjectAltName
+ values of type dNSName and then only as the left-most (least
+ significant) DNS label in that value. This wildcard matches any
+ left-most DNS label in the server name. That is, the subject
+ *.example.com matches the server names a.example.com and
+ b.example.com but does not match example.com or a.b.example.com.
+
+
+3.1.3.2. Comparison of IP Addresses
+
+ When the reference identity is an IP address, the identity MUST be
+ converted to the "network byte order" octet string representation
+ [RFC791][RFC2460]. For IP Version 4, as specified in RFC 791, the
+ octet string will contain exactly four octets. For IP Version 6, as
+ specified in RFC 2460, the octet string will contain exactly sixteen
+ octets. This octet string is then compared against subjectAltName
+ values of type iPAddress. A match occurs if the reference identity
+ octet string and value octet strings are identical.
+
+
+3.1.3.3. Comparison of other subjectName types
+
+ Client implementations MAY support matching against subjectAltName
+ values of other types as described in other documents.
+
+
+3.1.4. Discovery of Resultant Security Level
+
+
+
+
+
+
+Harrison Expires August 2006 [Page 10]
+
+Internet-Draft LDAP Authentication Methods February 2006
+
+ After a TLS layer is established in an LDAP session, both parties
+ are to each independently decide whether or not to continue based on
+ local policy and the security level achieved. If either party
+ decides that the security level is inadequate for it to continue, it
+ SHOULD remove the TLS layer immediately after the TLS
+ (re)negotiation has completed (see [Protocol] section 4.14.3 and
+ section 3.2 below). Implementations may reevaluate the security
+ level at any time and, upon finding it inadequate, should remove the
+ TLS layer.
+
+
+3.1.5. Refresh of Server Capabilities Information
+
+ After a TLS layer is established in an LDAP session, the client
+ SHOULD discard or refresh all information about the server it
+ obtained prior to the initiation of the TLS negotiation and not
+ obtained through secure mechanisms. This protects against man-in-
+ the-middle attacks that may have altered any server capabilities
+ information retrieved prior to TLS layer installation.
+
+ The server may advertise different capabilities after installing a
+ TLS layer. In particular, the value of 'supportedSASLMechanisms'
+ may be different after a TLS layer has been installed (specifically,
+ the EXTERNAL and PLAIN [PLAIN] mechanisms are likely to be listed
+ only after a TLS layer has been installed).
+
+
+3.2. Effect of TLS on Authorization State
+
+ The establishment, change, and/or closure of TLS may cause the
+ authorization state to move to a new state. This is discussed
+ further in Section 4.
+
+
+3.3. TLS Ciphersuites
+
+ Several issues should be considered when selecting TLS ciphersuites
+ that are appropriate for use in a given circumstance. These issues
+ include the following:
+
+ - The ciphersuite's ability to provide adequate confidentiality
+ protection for passwords and other data sent over the transport
+ connection. Client and server implementers should recognize
+ that some TLS ciphersuites provide no confidentiality protection
+ while other ciphersuites that do provide confidentiality
+ protection may be vulnerable to being cracked using brute force
+ methods, especially in light of ever-increasing CPU speeds that
+ reduce the time needed to successfully mount such attacks.
+
+ - Client and server implementers should carefully consider the
+ value of the password or data being protected versus the level
+ of confidentiality protection provided by the ciphersuite to
+ ensure that the level of protection afforded by the ciphersuite
+ is appropriate.
+
+Harrison Expires August 2006 [Page 11]
+
+Internet-Draft LDAP Authentication Methods February 2006
+
+
+ - The ciphersuite's vulnerability (or lack thereof) to man-in-the-
+ middle attacks. Ciphersuites vulnerable to man-in-the-middle
+ attacks SHOULD NOT be used to protect passwords or sensitive
+ data, unless the network configuration is such that the danger
+ of a man-in-the-middle attack is negligible.
+
+ - After a TLS negotiation (either initial or subsequent) is
+ completed, both protocol peers should independently verify that
+ the security services provided by the negotiated ciphersuite are
+ adequate for the intended use of the LDAP session. If not, the
+ TLS layer should be closed.
+
+
+4. Authorization State
+
+ Every LDAP session has an associated authorization state. This
+ state is comprised of numerous factors such as what (if any)
+ authorization state has been established, how it was established,
+ and what security services are in place. Some factors may be
+ determined and/or affected by protocol events (e.g., Bind, StartTLS,
+ or TLS closure), and some factors may be determined by external
+ events (e.g., time of day or server load).
+
+ While it is often convenient to view authorization state in
+ simplistic terms (as we often do in this technical specification)
+ such as "an anonymous state", it is noted that authorization systems
+ in LDAP implementations commonly involve many factors which
+ interrelate in complex manners.
+
+ Authorization in LDAP is a local matter. One of the key factors in
+ making authorization decisions is authorization identity. The Bind
+ operation defined in section 4.2 of [Protocol] and discussed further
+ in section 5 below allows information to be exchanged between the
+ client and server to establish an authorization identity for the
+ LDAP session. The Bind operation may also be used to move the LDAP
+ session to an anonymous authorization state (see section 5.1.1).
+
+ Upon initial establishment of the LDAP session, the session has an
+ anonymous authorization identity. Among other things this implies
+ that the client need not send a BindRequest in the first PDU of the
+ LDAP message layer. The client may send any operation request prior
+ to performing a Bind operation, and the server MUST treat it as if
+ it had been performed after an anonymous Bind operation (section
+ 5.1.1).
+
+ Upon receipt of a Bind request, the server immediately moves the
+ session to an anonymous authorization state. If the Bind request is
+ successful, the session is moved to the requested authentication
+ state with its associated authorization state. Otherwise, the
+ session remains in an anonymous state.
+
+
+
+
+Harrison Expires August 2006 [Page 12]
+
+Internet-Draft LDAP Authentication Methods February 2006
+
+ It is noted that other events both internal and external to LDAP may
+ result in the authentication and authorization states being moved to
+ an anonymous one. For instance, the establishment, change or
+ closure of data security services may result in a move to an
+ anonymous state, or the user's credential information (e.g.,
+ certificate) may have expired. The former is an example of an event
+ internal to LDAP whereas the latter is an example of an event
+ external to LDAP.
+
+
+5. Bind Operation
+
+ The Bind operation ([Protocol] section 4.2) allows authentication
+ information to be exchanged between the client and server to
+ establish a new authorization state.
+
+ The Bind request typically specifies the desired authentication
+ identity. Some Bind mechanisms also allow the client to specify the
+ authorization identity. If the authorization identity is not
+ specified, the server derives it from the authentication identity in
+ an implementation-specific manner.
+
+ If the authorization identity is specified, the server MUST verify
+ that the client's authentication identity is permitted to assume
+ (e.g., proxy for) the asserted authorization identity. The server
+ MUST reject the Bind operation with an invalidCredentials resultCode
+ in the Bind response if the client is not so authorized.
+
+
+5.1. Simple Authentication Method
+
+ The simple authentication method of the Bind Operation provides
+ three authentication mechanisms:
+
+ - An anonymous authentication mechanism (section 5.1.1).
+
+ - An unauthenticated authentication mechanism (section 5.1.2).
+
+ - A name/password authentication mechanism using credentials
+ consisting of a name (in the form of an LDAP distinguished name
+ [LDAPDN]) and a password (section 5.1.3).
+
+
+5.1.1. Anonymous Authentication Mechanism of Simple Bind
+
+ An LDAP client may use the anonymous authentication mechanism of the
+ simple Bind method to explicitly establish an anonymous
+ authorization state by sending a Bind request with a name value of
+ zero length and specifying the simple authentication choice
+ containing a password value of zero length.
+
+
+5.1.2. Unauthenticated Authentication Mechanism of Simple Bind
+
+
+Harrison Expires August 2006 [Page 13]
+
+Internet-Draft LDAP Authentication Methods February 2006
+
+ An LDAP client may use the unauthenticated authentication mechanism
+ of the simple Bind method to establish an anonymous authorization
+ state by sending a Bind request with a name value (a distinguished
+ name in LDAP string form [LDAPDN] of non-zero length) and specifying
+ the simple authentication choice containing a password value of zero
+ length.
+
+ The distinguished name value provided by the client is intended to
+ be used for trace (e.g., logging) purposes only. The value is not
+ to be authenticated or otherwise validated (including verification
+ that the DN refers to an existing directory object). The value is
+ not to be used (directly or indirectly) for authorization purposes.
+
+ Unauthenticated Bind operations can have significant security issues
+ (see section 6.3.1). In particular, users intending to perform
+ Name/Password Authentication may inadvertently provide an empty
+ password and thus cause poorly implemented clients to request
+ Unauthenticated access. Clients SHOULD be implemented to require
+ user selection of the Unauthenticated Authentication Mechanism by
+ means other than user input of an empty password. Clients SHOULD
+ disallow an empty password input to a Name/Password Authentication
+ user interface. Additionally, Servers SHOULD by default fail
+ Unauthenticated Bind requests with a resultCode of
+ unwillingToPerform.
+
+
+5.1.3. Name/Password Authentication Mechanism of Simple Bind
+
+ An LDAP client may use the name/password authentication mechanism of
+ the simple Bind method to establish an authenticated authorization
+ state by sending a Bind request with a name value (a distinguished
+ name in LDAP string form [LDAPDN] of non-zero length) and specifying
+ the simple authentication choice containing an OCTET STRING password
+ value of non-zero length.
+
+ Servers that map the DN sent in the Bind request to a directory
+ entry with an associated set of one or more passwords used with this
+ mechanism will compare the presented password to that set of
+ passwords. The presented password is considered valid if it matches
+ any member of this set.
+
+ A resultCode of invalidDNSyntax indicates that the DN sent in the
+ name value is syntactically invalid. A resultCode of
+ invalidCredentials indicates that the DN is syntactically correct
+ but not valid for purposes of authentication, or the password is not
+ valid for the DN or the server otherwise considers the credentials
+ to be invalid. A resultCode of success indicates that the
+ credentials are valid and the server is willing to provide service
+ to the entity these credentials identify.
+
+ Server behavior is undefined for Bind requests specifying the
+ name/password authentication mechanism with a zero-length name value
+ and a password value of non-zero length.
+
+
+Harrison Expires August 2006 [Page 14]
+
+Internet-Draft LDAP Authentication Methods February 2006
+
+ The name/password authentication mechanism of the simple Bind method
+ is not suitable for authentication in environments without
+ confidentiality protection.
+
+
+5.2. SASL Authentication Method
+
+ The sasl authentication method of the Bind Operation provides
+ facilities for using any SASL mechanism including authentication
+ mechanisms and other services (e.g., data security services).
+
+
+5.2.1. SASL Protocol Profile
+
+ LDAP allows authentication via any SASL mechanism [SASL]. As LDAP
+ includes native anonymous and name/password (plain text)
+ authentication methods, the ANONYMOUS [ANONYMOUS] and PLAIN [PLAIN]
+ SASL mechanisms are typically not used with LDAP.
+
+ Each protocol that utilizes SASL services is required to supply
+ certain information profiling the way they are exposed through the
+ protocol ([SASL] section 4). This section explains how each of
+ these profiling requirements are met by LDAP.
+
+
+5.2.1.1. SASL Service Name for LDAP
+
+ The SASL service name for LDAP is "ldap", which has been registered
+ with the IANA as a SASL service name.
+
+
+5.2.1.2. SASL Authentication Initiation and Protocol Exchange
+
+ SASL authentication is initiated via a BindRequest message
+ ([Protocol] section 4.2) with the following parameters:
+
+ - The version is 3.
+ - The AuthenticationChoice is sasl.
+ - The mechanism element of the SaslCredentials sequence contains
+ the value of the desired SASL mechanism.
+ - The optional credentials field of the SaslCredentials sequence
+ MAY be used to provide an initial client response for
+ mechanisms that are defined to have the client send data first
+ (see [SASL] sections 3 and 5 ).
+
+
+
+
+
+
+
+
+
+
+
+Harrison Expires August 2006 [Page 15]
+
+Internet-Draft LDAP Authentication Methods February 2006
+
+ In general, a SASL authentication protocol exchange consists of a
+ series of server challenges and client responses, the contents of
+ which are specific to and defined by the SASL mechanism. Thus for
+ some SASL authentication mechanisms, it may be necessary for the
+ client to respond to one or more server challenges by sending
+ BindRequest messages multiple times. A challenge is indicated by
+ the server sending a BindResponse message with the resultCode set to
+ saslBindInProgress. This indicates that the server requires the
+ client to send a new BindRequest message with the same SASL
+ mechanism to continue the authentication process.
+
+ To the LDAP message layer, these challenges and responses are opaque
+ binary tokens of arbitrary length. LDAP servers use the
+ serverSaslCreds field (an OCTET STRING) in a BindResponse message to
+ transmit each challenge. LDAP clients use the credentials field
+ (an OCTET STRING) in the SaslCredentials sequence of a BindRequest
+ message to transmit each response. Note that unlike some Internet
+ protocols where SASL is used, LDAP is not text based and does not
+ Base64-transform these challenge and response values.
+
+ Clients sending a BindRequest message with the sasl choice selected
+ SHOULD send a zero-length value in the name field. Servers
+ receiving a BindRequest message with the sasl choice selected SHALL
+ ignore any value in the name field.
+
+ A client may abort a SASL Bind negotiation by sending a BindRequest
+ message with a different value in the mechanism field of
+ SaslCredentials or with an AuthenticationChoice other than sasl.
+
+ If the client sends a BindRequest with the sasl mechanism field as
+ an empty string, the server MUST return a BindResponse with a
+ resultCode of authMethodNotSupported. This will allow the client to
+ abort a negotiation if it wishes to try again with the same SASL
+ mechanism.
+
+ The server indicates completion of the SASL challenge-response
+ exchange by responding with a BindResponse in which the resultCode
+ value is not saslBindInProgress.
+
+ The serverSaslCreds field in the BindResponse can be used to include
+ an optional challenge with a success notification for mechanisms
+ which are defined to have the server send additional data along with
+ the indication of successful completion.
+
+
+5.2.1.3. Optional Fields
+
+ As discussed above, LDAP provides an optional field for carrying an
+ initial response in the message initiating the SASL exchange and
+ provides an optional field for carrying additional data in the
+ message indicating outcome of the authentication exchange. As the
+ mechanism-specific content in these fields may be zero-length, SASL
+ requires protocol specifications to detail how an empty field is
+ distinguished from an absent field.
+
+Harrison Expires August 2006 [Page 16]
+
+Internet-Draft LDAP Authentication Methods February 2006
+
+
+ Zero-length initial response data is distinguished from no initial
+ response data in the initiating message, a BindRequest PDU, by the
+ presence of the SaslCredentials.credentials OCTET STRING (of length
+ zero) in that PDU. If the client does not intend to send an
+ initial response with the BindRequest initiating the SASL exchange,
+ it MUST omit the SaslCredentials.credentials OCTET STRING (rather
+ than including an zero-length OCTET STRING).
+
+ Zero-length additional data is distinguished from no additional
+ response data in the outcome message, a BindResponse PDU, by the
+ presence of the serverSaslCreds OCTET STRING (of length zero) in
+ that PDU. If a server does not intend to send additional data in
+ the BindResponse message indicating outcome of the exchange, the
+ server SHALL omit the serverSaslCreds OCTET STRING (rather than
+ including a zero-length OCTET STRING).
+
+
+5.2.1.4. Octet Where Negotiated Security Layers Take Effect
+
+ SASL layers take effect following the transmission by the server and
+ reception by the client of the final BindResponse in the SASL
+ exchange with a resultCode of success.
+
+ Once a SASL layer providing data integrity or confidentiality
+ services takes effect, the layer remains in effect until a new layer
+ is installed (i.e. at the first octet following the final
+ BindResponse of the Bind operation that caused the new layer to take
+ effect). Thus, an established SASL layer is not affected by a
+ failed or non-SASL Bind.
+
+
+5.2.1.5. Determination of Supported SASL Mechanisms
+
+ Clients may determine the SASL mechanisms a server supports by
+ reading the 'supportedSASLMechanisms' attribute from the root DSE
+ (DSA-Specific Entry) ([Models] section 5.1). The values of this
+ attribute, if any, list the mechanisms the server supports in the
+ current LDAP session state. LDAP servers SHOULD allow all clients--
+ even those with an anonymous authorization--to retrieve the
+ 'supportedSASLMechanisms' attribute of the root DSE both before and
+ after the SASL authentication exchange. The purpose of the latter
+ is to allow the client to detect possible downgrade attacks (see
+ section 6.4 and [SASL] section 6.1.2).
+
+ Because SASL mechanisms provide critical security functions, clients
+ and servers should be configurable to specify what mechanisms are
+ acceptable and allow only those mechanisms to be used. Both clients
+ and servers must confirm that the negotiated security level meets
+ their requirements before proceeding to use the session.
+
+
+5.2.1.6. Rules for Using SASL Layers
+
+
+Harrison Expires August 2006 [Page 17]
+
+Internet-Draft LDAP Authentication Methods February 2006
+
+ Upon installing a SASL layer, the client SHOULD discard or refresh
+ all information about the server it obtained prior to the initiation
+ of the SASL negotiation and not obtained through secure mechanisms.
+
+ If a lower level security layer (such as TLS) is installed, any SASL
+ layer SHALL be layered on top of such security layers regardless of
+ the order of their negotiation. In all other respects, the SASL
+ layer and other security layers act independently, e.g., if both a
+ TLS layer and a SASL layer are in effect then removing the TLS layer
+ does not affect the continuing service of the SASL layer.
+
+
+5.2.1.7. Support for Multiple Authentications
+
+ LDAP supports multiple SASL authentications as defined in [SASL]
+ section 4.
+
+
+5.2.1.8. SASL Authorization Identities
+
+ Some SASL mechanisms allow clients to request a desired
+ authorization identity for the LDAP session ([SASL] section 3.4.
+ The decision to allow or disallow the current authentication
+ identity to have access to the requested authorization identity is a
+ matter of local policy. The authorization identity is a string of
+ UTF-8 [RFC3629] encoded [Unicode] characters corresponding to the
+ following ABNF [RFC2234bis] grammar:
+
+ authzId = dnAuthzId / uAuthzId
+
+ ; distinguished-name-based authz id
+ dnAuthzId = "dn:" distinguishedName
+
+ ; unspecified authorization id, UTF-8 encoded
+ uAuthzId = "u:" userid
+ userid = *UTF8 ; syntax unspecified
+
+ where the distinguishedName rule is defined in section 3 of [LDAPDN]
+ and the UTF8 rule is defined in section 1.4 of [Models].
+
+ The dnAuthzId choice is used to assert authorization identities in
+ the form of a distinguished name to be matched in accordance with
+ the distinguishedNameMatch matching rule [Syntaxes]. There is no
+ requirement that the asserted distinguishedName value be that of an
+ entry in the directory.
+
+
+
+
+
+
+
+
+
+
+Harrison Expires August 2006 [Page 18]
+
+Internet-Draft LDAP Authentication Methods February 2006
+
+ The uAuthzId choice allows clients to assert an authorization
+ identity that is not in distinguished name form. The format of
+ userid is defined only as a sequence of UTF-8 [RFC3629] encoded
+ [Unicode] characters, and any further interpretation is a local
+ matter. For example, the userid could identify a user of a specific
+ directory service, be a login name or be an email address. A
+ uAuthzId SHOULD NOT be assumed to be globally unique. To compare
+ uAuthzID values, each uAuthzID value MUST be prepared as a "query"
+ string using [RFC4013] and then the two values are compared octet-
+ wise.
+
+ The above grammar is extensible. The authzId production may be
+ extended to support additional forms of identities. Each form is
+ distinguished by its unique prefix (see section 3.12 of [LDAPIANA]
+ for registration requirements).
+
+
+5.2.2. SASL Semantics Within LDAP
+
+ Implementers must take care to maintain the semantics of SASL
+ specifications when handling data that has different semantics in
+ the LDAP protocol.
+
+ For example, the SASL DIGEST-MD5 authentication mechanism [RFC2829]
+ utilizes an authentication identity and a realm which are
+ syntactically simple strings and semantically simple username and
+ realm values ([DIGEST-MD5] section 2.1). These values are not LDAP
+ DNs, and there is no requirement that they be represented or treated
+ as such.
+
+
+5.2.3. SASL EXTERNAL Authentication Mechanism
+
+ A client can use the SASL EXTERNAL [SASL] mechanism to request the
+ LDAP server to authenticate and establish a resulting authorization
+ identity using security credentials exchanged by a lower security
+ layer (such as by TLS authentication). If the client's
+ authentication credentials have not been established at a lower
+ security layer, the SASL EXTERNAL Bind MUST fail with a resultCode
+ of inappropriateAuthentication. Although this situation has the
+ effect of leaving the LDAP session in an anonymous state (section
+ 4), the state of any installed security layer is unaffected.
+
+ A client may either request that its authorization identity be
+ automatically derived from its authentication credentials exchanged
+ at a lower security layer or it may explicitly provide a desired
+ authorization identity. The former is known as an implicit
+ assertion, and the latter as an explicit assertion.
+
+
+5.2.3.1. Implicit Assertion
+
+
+
+
+Harrison Expires August 2006 [Page 19]
+
+Internet-Draft LDAP Authentication Methods February 2006
+
+ An implicit authorization identity assertion is performed by
+ invoking a Bind request of the SASL form using the EXTERNAL
+ mechanism name that does not include the optional credentials field
+ (found within the SaslCredentials sequence in the BindRequest). The
+ server will derive the client's authorization identity from the
+ authentication identity supplied by a security layer (e.g., a public
+ key certificate used during TLS layer installation) according to
+ local policy. The underlying mechanics of how this is accomplished
+ are implementation specific.
+
+
+5.2.3.2. Explicit Assertion
+
+ An explicit authorization identity assertion is performed by
+ invoking a Bind request of the SASL form using the EXTERNAL
+ mechanism name that includes the credentials field (found within the
+ SaslCredentials sequence in the BindRequest). The value of the
+ credentials field (an OCTET STRING) is the asserted authorization
+ identity and MUST be constructed as documented in section 5.2.1.8.
+
+
+6. Security Considerations
+
+ Security issues are discussed throughout this document. The
+ unsurprising conclusion is that security is an integral and
+ necessary part of LDAP. This section discusses a number of LDAP-
+ related security considerations.
+
+
+6.1. General LDAP Security Considerations
+
+ LDAP itself provides no security or protection from accessing or
+ updating the directory by other means than through the LDAP
+ protocol, e.g., from inspection of server database files by database
+ administrators.
+
+ Sensitive data may be carried in almost any LDAP message and its
+ disclosure may be subject to privacy laws or other legal regulation
+ in many countries. Implementers should take appropriate measures to
+ protect sensitive data from disclosure to unauthorized entities.
+
+ A session on which the client has not established data integrity and
+ privacy services (e.g., via StartTLS, IPsec or a suitable SASL
+ mechanism) is subject to man-in-the-middle attacks to view and
+ modify information in transit. Client and server implementers
+ SHOULD take measures to protect sensitive data in the LDAP session
+ from these attacks by using data protection services as discussed in
+ this document. Clients and servers should provide the ability to be
+ configured to require these protections. A resultCode of
+ confidentialityRequired indicates that the server requires
+ establishment of (stronger) data confidentiality protection in order
+ to perform the requested operation.
+
+
+
+Harrison Expires August 2006 [Page 20]
+
+Internet-Draft LDAP Authentication Methods February 2006
+
+ Access control should always be applied when reading sensitive
+ information or updating directory information.
+
+ Various security factors, including authentication and authorization
+ information and data security services may change during the course
+ of the LDAP session, or even during the performance of a particular
+ operation. Implementations should be robust in the handling of
+ changing security factors.
+
+
+6.2. StartTLS Security Considerations
+
+ All security gained via use of the StartTLS operation is gained by
+ the use of TLS itself. The StartTLS operation, on its own, does not
+ provide any additional security.
+
+ The level of security provided through the use of TLS depends
+ directly on both the quality of the TLS implementation used and the
+ style of usage of that implementation. Additionally, a man-in-the-
+ middle attacker can remove the StartTLS extended operation from the
+ 'supportedExtension' attribute of the root DSE. Both parties SHOULD
+ independently ascertain and consent to the security level achieved
+ once TLS is established and before beginning use of the TLS-
+ protected session. For example, the security level of the TLS layer
+ might have been negotiated down to plaintext.
+
+ Clients MUST either warn the user when the security level achieved
+ does not provide an acceptable level of data confidentiality and/or
+ data integrity protection, or be configurable to refuse to proceed
+ without an acceptable level of security.
+
+ As stated in section 3.1.2, a server may use a local security policy
+ to determine whether to successfully complete TLS negotiation.
+ Information in the user's certificate that is originated or verified
+ by the certification authority should be used by the policy
+ administrator when configuring the identification and authorization
+ policy.
+
+ Server implementers SHOULD allow server administrators to elect
+ whether and when data confidentiality and integrity are required, as
+ well as elect whether authentication of the client during the TLS
+ handshake is required.
+
+ Implementers should be aware of and understand TLS security
+ considerations as discussed in the TLS specification [TLS].
+
+
+6.3. Bind Operation Security Considerations
+
+ This section discusses several security considerations relevant to
+ LDAP authentication via the Bind operation.
+
+
+6.3.1. Unauthenticated Mechanism Security Considerations
+
+Harrison Expires August 2006 [Page 21]
+
+Internet-Draft LDAP Authentication Methods February 2006
+
+
+ Operational experience shows that clients can (and frequently do)
+ misuse the unauthenticated authentication mechanism of the simple
+ Bind method (see section 5.1.2). For example, a client program
+ might make a decision to grant access to non-directory information
+ on the basis of successfully completing a Bind operation. LDAP
+ server implementations may return a success response to an
+ unauthenticated Bind request. This may erroneously leave the client
+ with the impression that the server has successfully authenticated
+ the identity represented by the distinguished name when in reality,
+ an anonymous authorization state has been established. Clients that
+ use the results from a simple Bind operation to make authorization
+ decisions should actively detect unauthenticated Bind requests (by
+ verifying that the supplied password is not empty) and react
+ appropriately.
+
+
+6.3.2. Name/Password Mechanism Security Considerations
+
+ The name/password authentication mechanism of the simple Bind method
+ discloses the password to the server, which is an inherent security
+ risk. There are other mechanisms such as SASL DIGEST-MD5 [RFC2829]
+ that do not disclose the password to the server.
+
+
+6.3.3. Password-related Security Considerations
+
+ LDAP allows multi-valued password attributes. In systems where
+ entries are expected to have one and only one password,
+ administrative controls should be provided to enforce this behavior.
+
+ The use of clear text passwords and other unprotected authentication
+ credentials is strongly discouraged over open networks when the
+ underlying transport service cannot guarantee confidentiality. LDAP
+ implementations SHOULD NOT by default support authentication methods
+ using clear text passwords and other unprotected authentication
+ credentials unless the data on the session is protected using TLS or
+ other data confidentiality and data integrity protection.
+
+ The transmission of passwords in the clear--typically for
+ authentication or modification--poses a significant security risk.
+ This risk can be avoided by using SASL authentication [SASL]
+ mechanisms that do not transmit passwords in the clear or by
+ negotiating transport or session layer data confidentiality services
+ before transmitting password values.
+
+ To mitigate the security risks associated with the transfer of
+ passwords, a server implementation that supports any password-based
+ authentication mechanism that transmits passwords in the clear MUST
+ support a policy mechanism that at the time of authentication or
+ password modification, requires:
+
+ A TLS layer has been successfully installed.
+
+
+Harrison Expires August 2006 [Page 22]
+
+Internet-Draft LDAP Authentication Methods February 2006
+
+ OR
+
+ Some other data confidentiality mechanism that protects the
+ password value from eavesdropping has been provided.
+
+ OR
+
+ The server returns a resultCode of confidentialityRequired for
+ the operation (i.e. name/password Bind with password value,
+ SASL Bind transmitting a password value in the clear, add or
+ modify including a userPassword value, etc.), even if the
+ password value is correct.
+
+ Server implementations may also want to provide policy mechanisms to
+ invalidate or otherwise protect accounts in situations where a
+ server detects that a password for an account has been transmitted
+ in the clear.
+
+
+6.3.4. Hashed Password Security Considerations
+
+ Some authentication mechanisms (e.g., DIGEST-MD5) transmit a hash of
+ the password value that may be vulnerable to offline dictionary
+ attacks. Implementers should take care to protect such hashed
+ password values during transmission using TLS or other
+ confidentiality mechanisms.
+
+
+6.4.SASL Security Considerations
+
+ Until data integrity service is installed on an LDAP session, an
+ attacker can modify the transmitted values of the
+ 'supportedSASLMechanisms' attribute response and thus downgrade the
+ list of available SASL mechanisms to include only the least secure
+ mechanism. To detect this type of attack, the client may retrieve
+ the SASL mechanisms the server makes available both before and after
+ data integrity service is installed on an LDAP session. If the
+ client finds that the integrity-protected list (the list obtained
+ after data integrity service was installed) contains a stronger
+ mechanism than those in the previously obtained list, the client
+ should assume the previously obtained list was modified by an
+ attacker. In this circumstance it is recommended that the client
+ close the underlying transport connection and then reconnect to
+ reestablish the session.
+
+
+6.5. Related Security Considerations
+
+ Additional security considerations relating to the various
+ authentication methods and mechanisms discussed in this document
+ apply and can be found in [SASL], [RFC4013], [StringPrep] and
+ [RFC3629].
+
+
+
+Harrison Expires August 2006 [Page 23]
+
+Internet-Draft LDAP Authentication Methods February 2006
+
+7. IANA Considerations
+
+ It is requested that the IANA update the LDAP Protocol Mechanism
+ registry to indicate that this document and [Protocol] provide the
+ definitive technical specification for the StartTLS
+ (1.3.6.1.4.1.1466.20037) extended operation.
+
+
+8. Acknowledgments
+
+ This document combines information originally contained in RFC 2251,
+ RFC 2829 and RFC 2830 which are products of the LDAP Extensions
+ (LDAPEXT) Working Group.
+
+ This document is a product of the IETF LDAP Revision (LDAPBIS)
+ working group.
+
+
+9. Normative References
+
+ [[Note to the RFC Editor: please replace the citation tags used in
+ referencing Internet-Drafts with tags of the form RFCnnnn.]]
+
+ [LDAPDN] Zeilenga, Kurt D. (editor), "LDAP: String
+ Representation of Distinguished Names", draft-ietf-
+ ldapbis-dn-xx.txt, a work in progress.
+
+ [LDAPIANA] Zeilenga, K., "IANA Considerations for LDAP", draft-
+ ietf-ldapbis-bcp64-xx.txt, (a work in progress).
+
+ [Matching] Hoffman, Paul and Steve Hanna, "Matching Text Strings
+ in PKIX Certificates", draft-hoffman-pkix-stringmatch-
+ xx.txt, a work in progress.
+
+ [Models] Zeilenga, Kurt D. (editor), "LDAP: Directory
+ Information Models", draft-ietf-ldapbis-models-xx.txt,
+ a work in progress.
+
+ [Protocol] Sermersheim, J., "LDAP: The Protocol", draft-ietf-
+ ldapbis-protocol-xx.txt, a work in progress.
+
+ [RFC791] Information Sciences Institute, "INTERNET PROTOCOL
+ DARPA INTERNET PROGRAM PROTOCOL SPECIFICATION", RFC
+ 791, September 1981.
+
+ [RFC2119] Bradner, S., "Key Words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2234bis] Crocker, D., Ed. and P. Overell, "Augmented BNF for
+ Syntax Specifications: ABNF", draft-crocker-abnf-
+ rfc2234bis-xx, a work in progress.
+
+ [RFC2460] Deering, S., R. Hinden, "Internet Protocol, Version 6
+ (IPv6)", RFC 2460, December 1998.
+
+Harrison Expires August 2006 [Page 24]
+
+Internet-Draft LDAP Authentication Methods February 2006
+
+
+ [RFC3490] Falstrom, P., P. Hoffman, and A. Costello,
+ "Internationalizing Domain Names In Applications
+ (IDNA)", RFC 3490, March 2003.
+
+ [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
+ 10646", RFC 3629, STD 63, November 2003.
+
+ [RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User
+ Names and Passwords", RFC 4013, February 2005.
+
+ [Roadmap] K. Zeilenga, "LDAP: Technical Specification Road Map",
+ draft-ietf-ldapbis-roadmap-xx.txt, a work in progress.
+
+ [SASL] Melnikov, A. (editor), "Simple Authentication and
+ Security Layer (SASL)", draft-ietf-sasl-rfc2222bis-
+ xx.txt, a work in progress.
+
+ [Schema] Dally, K. (editor), "LDAP: User Schema", draft-ietf-
+ ldapbis-user-schema-xx.txt, a work in progress.
+
+ [StringPrep] M. Blanchet, "Preparation of Internationalized Strings
+ ('stringprep')", draft-hoffman-rfc3454bis-xx.txt, a
+ work in progress.
+
+ [Syntaxes] Legg, S. (editor), "LDAP: Syntaxes and Matching Rules",
+ draft-ietf-ldapbis-syntaxes-xx.txt, a work in progress.
+
+ [TLS] Dierks, T. and C. Allen. "The TLS Protocol Version
+ 1.1", draft-ietf-tls-rfc2246-bis-xx.txt, a work in
+ progress.
+
+ [Unicode] The Unicode Consortium, "The Unicode Standard, Version
+ 3.2.0" is defined by "The Unicode Standard, Version
+ 3.0" (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-
+ 61633-5), as amended by the "Unicode Standard Annex
+ #27: Unicode 3.1"
+ (http://www.unicode.org/reports/tr27/) and by the
+ "Unicode Standard Annex #28: Unicode 3.2"
+ (http://www.unicode.org/reports/tr28/).
+
+
+10. Informative References
+
+ [[Note to the RFC Editor: please replace the citation tags used in
+ referencing Internet-Drafts with tags of the form RFCnnnn.]]
+
+ [ANONYMOUS] Zeilenga, K., "Anonymous SASL Mechanism", draft-
+ zeilenga-sasl-anon-xx.txt, a work in progress.
+
+ [DIGEST-MD5] Leach, P. C. Newman, and A. Melnikov, "Using Digest
+ Authentication as a SASL Mechanism", draft-ietf-sasl-
+ rfc2831bis-xx.txt, a work in progress.
+
+
+Harrison Expires August 2006 [Page 25]
+
+Internet-Draft LDAP Authentication Methods February 2006
+
+ [PLAIN] Zeilenga, K.,"Plain SASL Mechanism", draft-zeilenga-
+ sasl-plain-xx.txt, a work in progress.
+
+ [RFC2828] Shirey, R., "Internet Security Glossary", RFC 2828, May
+ 2000.
+
+ [RFC2829] Wahl, M. et al, "Authentication Methods for LDAP", RFC
+ 2829, May 2000.
+
+ [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
+ Internet Protocol", RFC 4301, December 2005.
+
+Author's Address
+
+ Roger Harrison
+ Novell, Inc.
+ 1800 S. Novell Place
+ Provo, UT 84606
+ USA
+ +1 801 861 2642
+ roger_harrison at novell.com
+
+
+Appendix A. Authentication and Authorization Concepts
+
+ This appendix is non-normative.
+
+ This appendix defines basic terms, concepts, and interrelationships
+ regarding authentication, authorization, credentials, and identity.
+ These concepts are used in describing how various security
+ approaches are utilized in client authentication and authorization.
+
+
+A.1. Access Control Policy
+
+ An access control policy is a set of rules defining the protection
+ of resources, generally in terms of the capabilities of persons or
+ other entities accessing those resources. Security objects and
+ mechanisms, such as those described here, enable the expression of
+ access control policies and their enforcement.
+
+
+A.2. Access Control Factors
+
+ A request, when it is being processed by a server, may be associated
+ with a wide variety of security-related factors ([Protocol] section
+ 4.2). The server uses these factors to determine whether and how to
+ process the request. These are called access control factors
+ (ACFs). They might include source IP address, encryption strength,
+ the type of operation being requested, time of day, etc.. Some
+ factors may be specific to the request itself, others may be
+ associated with the transport connection via which the request is
+ transmitted, others (e.g., time of day) may be "environmental".
+
+
+Harrison Expires August 2006 [Page 26]
+
+Internet-Draft LDAP Authentication Methods February 2006
+
+ Access control policies are expressed in terms of access control
+ factors. For example, "a request having ACFs i,j,k can perform
+ operation Y on resource Z." The set of ACFs that a server makes
+ available for such expressions is implementation-specific.
+
+A.3. Authentication, Credentials, Identity
+
+ Authentication credentials are the evidence supplied by one party to
+ another, asserting the identity of the supplying party (e.g., a
+ user) who is attempting to establish a new authorization state with
+ the other party (typically a server). Authentication is the process
+ of generating, transmitting, and verifying these credentials and
+ thus the identity they assert. An authentication identity is the
+ name presented in a credential.
+
+ There are many forms of authentication credentials. The form used
+ depends upon the particular authentication mechanism negotiated by
+ the parties. X.509 certificates, Kerberos tickets, and simple
+ identity and password pairs are all examples of authentication
+ credential forms. Note that an authentication mechanism may
+ constrain the form of authentication identities used with it.
+
+
+A.4. Authorization Identity
+
+ An authorization identity is one kind of access control factor. It
+ is the name of the user or other entity that requests that
+ operations be performed. Access control policies are often
+ expressed in terms of authorization identities; for example, "entity
+ X can perform operation Y on resource Z."
+
+ The authorization identity of an LDAP session is often semantically
+ the same as the authentication identity presented by the client, but
+ it may be different. SASL allows clients to specify an
+ authorization identity distinct from the authentication identity
+ asserted by the client's credentials. This permits agents such as
+ proxy servers to authenticate using their own credentials, yet
+ request the access privileges of the identity for which they are
+ proxying [SASL]. Also, the form of authentication identity supplied
+ by a service like TLS may not correspond to the authorization
+ identities used to express a server's access control policy,
+ requiring a server-specific mapping to be done. The method by which
+ a server composes and validates an authorization identity from the
+ authentication credentials supplied by a client is implementation
+ specific.
+
+
+Appendix B. Summary of Changes
+
+ This appendix is non-normative.
+
+
+
+
+
+Harrison Expires August 2006 [Page 27]
+
+Internet-Draft LDAP Authentication Methods February 2006
+
+ This appendix summarizes substantive changes made to RFC 2251, RFC
+ 2829 and RFC 2830. In addition to the specific changes detailed
+ below, the reader of this document should be aware that numerous
+ general editorial changes have been made to the original content
+ from the source documents. These changes include the following:
+
+ - The material originally found in RFC 2251 sections 4.2.1 and
+ 4.2.2, RFC 2829 (all sections except sections 2 and 4) and RFC
+ 2830 was combined into a single document
+
+ - The combined material was substantially reorganized and edited
+ to group related subjects, improve the document flow and clarify
+ intent.
+
+ - Changes were made throughout the text to align with definitions
+ of LDAP protocol layers and IETF security terminology.
+
+ - Substantial updates and additions were made to security
+ considerations from both documents based on current operational
+ experience.
+
+
+B.1. Changes Made to RFC 2251
+
+ This section summarizes the substantive changes made to sections
+ 4.2.1 and 4.2.2 of RFC 2251 by this document. Additional
+ substantive changes to section 4.2.1 of RFC 2251 are also documented
+ in [Protocol].
+
+
+B.1.1. Section 4.2.1 (Sequencing of the Bind Request)
+
+ - Paragraph 1: Removed the sentence, "If at any stage the client
+ wishes to abort the bind process it MAY unbind and then drop the
+ underlying connection." The Unbind operation still permits this
+ behavior, but it is not documented explicitly.
+
+ - Clarified that the session is moved to an anonymous state upon
+ receipt of the BindRequest PDU and that it is only moved to a
+ non-anonymous state if and when the Bind request is successful.
+
+
+B.1.2. Section 4.2.2 (Authentication and Other Security Services)
+
+ - RFC 2251 states that anonymous authentication MUST be performed
+ using the simple bind method. This specification defines the
+ anonymous authentication mechanism of the simple bind method and
+ requires all conforming implementations to support it. Other
+ authentication mechanisms producing anonymous authentication and
+ authorization state may also be implemented and used by
+ conforming implementations.
+
+
+B.2. Changes Made to RFC 2829
+
+Harrison Expires August 2006 [Page 28]
+
+Internet-Draft LDAP Authentication Methods February 2006
+
+
+ This section summarizes the substantive changes made to RFC 2829.
+
+
+B.2.1. Section 4 (Required security mechanisms)
+
+ - The name/password authentication mechanism (see section B.2.5
+ below) protected by TLS replaces the SASL DIGEST-MD5 mechanism
+ as LDAP's mandatory-to-implement password-based authentication
+ mechanism. Implementations are encouraged to continue
+ supporting SASL DIGEST-MD5 [RFC2829].
+
+
+B.2.2. Section 5.1 (Anonymous authentication procedure)
+
+ - Clarified that anonymous authentication involves a name value of
+ zero length and a password value of zero length. The
+ unauthenticated authentication mechanism was added to handle
+ simple Bind requests involving a name value with a non-zero
+ length and a password value of zero length.
+
+
+B.2.3. Section 6 (Password-based authentication)
+
+ - See section B.2.1.
+
+
+B.2.4. Section 6.1 (Digest authentication)
+
+ - As the SASL-DIGEST-MD5 mechanism is no longer mandatory to
+ implement, this section is now historical and was not included
+ in this document. RFC 2829 section 6.1 continues to document the
+ SASL DIGEST-MD5 authentication mechanism.
+
+
+B.2.5. Section 6.2 ("simple" authentication choice with TLS)
+
+ - Renamed the "simple" authentication mechanism to the
+ name/password authentication mechanism to better describe it.
+
+ - The use of TLS was generalized to align with definitions of LDAP
+ protocol layers. TLS establishment is now discussed as an
+ independent subject and is generalized for use with all
+ authentication mechanisms and other security layers.
+
+ - Removed the implication that the userPassword attribute is the
+ sole location for storage of password values to be used in
+ authentication. There is no longer any implied requirement for
+ how or where passwords are stored at the server for use in
+ authentication.
+
+
+B.2.6. Section 6.3 (Other authentication choices with TLS)
+
+
+Harrison Expires August 2006 [Page 29]
+
+Internet-Draft LDAP Authentication Methods February 2006
+
+ - See section B.2.5.
+
+
+B.2.7. Section 7.1 (Certificate-based authentication with TLS)
+
+ - See section B.2.5.
+
+
+B.2.8. Section 8 (Other mechanisms)
+
+ - All SASL authentication mechanisms are explicitly allowed within
+ LDAP. Specifically, this means the SASL ANONYMOUS and SASL PLAIN
+ mechanisms are no longer precluded from use within LDAP.
+
+
+B.2.9. Section 9 (Authorization identity)
+
+ - Specified matching rules for dnAuthzID and uAuthzID values. In
+ particular, the DN value in the dnAuthzID form must be matched
+ using DN matching rules and the uAuthzID value MUST be prepared
+ using SASLprep rules before being compared octet-wise.
+
+ - Clarified that uAuthzID values should not be assumed to be
+ globally unique.
+
+
+B.2.10. Section 10 (TLS Ciphersuites)
+
+ - TLS Ciphersuite recommendations are no longer included in this
+ specification. Implementations must still support the
+ TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA ciphersuite.
+
+ - Clarified that anonymous authentication involves a name value of
+ zero length and a password value of zero length. The
+ unauthenticated authentication mechanism was added to handle
+ simple Bind requests involving a name value with a non-zero
+ length and a password value of zero length.
+
+
+B.3. Changes Made to RFC 2830:
+
+ This section summarizes the substantive changes made to sections 3
+ and 5 of RFC 2830. Readers should consult [Protocol] for summaries
+ of changes to other sections.
+
+
+B.3.1. Section 3.6 (Server Identity Check)
+
+
+
+
+
+
+
+
+Harrison Expires August 2006 [Page 30]
+
+Internet-Draft LDAP Authentication Methods February 2006
+
+ - Substantially updated the server identity check algorithm to
+ ensure that it is complete and robust. In particular, the use
+ of all relevant values in the subjectAltName and the subjectName
+ fields are covered by the algorithm and matching rules are
+ specified for each type of value. Mapped (derived) forms of the
+ server identity may now be used when the mapping is performed in
+ a secure fashion.
+
+
+B.3.2. Section 3.7 (Refresh of Server Capabilities Information)
+
+ - Clients are no longer required to always refresh information
+ about server capabilities following TLS establishment to allow
+ for situations where this information was obtained through a
+ secure mechanism.
+
+
+B.3.3. Section 5.2 (Effects of TLS on Authorization Identity)
+
+ - Establishing a TLS layer on an LDAP session may now cause the
+ authorization state of the LDAP session to change.
+
+
+B.3.4. Section 5.1.1 (TLS Closure Effects)
+
+ - Closing a TLS layer on an LDAP session changes the
+ authentication and authorization state of the LDAP session based
+ on local policy. Specifically, this means that implementations
+ are not required to to change the authentication and
+ authorization states to anonymous upon TLS closure.
+
+
+Appendix C. Changes for draft-ldapbis-authmeth-19
+
+ [[Note to RFC Editor: Please remove this appendix upon publication
+ of this Internet-Draft as an RFC.]]
+
+ This appendix is non-normative.
+
+ This appendix summarizes changes made in this revision of the
+ document.
+
+ General
+
+ - This draft has addressed all issues raised for the -18 version.
+
+ - Several minor edits for clarity and to remove typos based on
+ feedback from WG, IETF and IESG reviews.
+
+ Abstract
+ - Added statement regarding RFCs obsoleted by this document.
+
+ Section 2
+
+
+Harrison Expires August 2006 [Page 31]
+
+Internet-Draft LDAP Authentication Methods February 2006
+
+ - Changed mandatory-to-implement TLS ciphersuite from
+ TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA to
+ TLS_RSA_WITH_3DES_EDE_CBC_SHA based on IESG recommendation and
+ WG consensus.
+
+ Section 5.2.1.5
+ - Clarified that 'supportedSASLMechanisms' should be retrievable
+ by all clients both before and after SASL negotiation to allow
+ detection of mechanism downgrade attacks.
+
+ Section 5.2.1.6
+ - Changed wording to reflect the fact that SASL layers cannot be
+ uninstalled from the session.
+
+ Section 5.2.3
+ - Removed reference to IPsec as a source of authorization identity.
+
+ Section 6.2
+ - When TLS layer does not provide an acceptable level of security
+ client MUST warn the user or refuse to proceed. (This was
+ changed from SHOULD based on IESG recommendation and WG
+ consensus.)
+
+ - Added a security consideration regarding the proper usage of
+ information found in the client certificate.
+
+ Section 6.4
+ - Added a new section on SASL security considerations that
+ discusses SASL mechanism downgrade attacks.
+
+ Section 10
+ - Replaced references to RFC 2401 with RFC 4301.
+
+Intellectual Property Rights
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed
+ to pertain to the implementation or use of the technology described
+ in this document or the extent to which any license under such
+ rights might or might not be available; nor does it represent that
+ it has made any independent effort to identify any such rights.
+ Information on the procedures with respect to rights in RFC
+ documents can be found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use
+ of such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository
+ at http://www.ietf.org/ipr.
+
+
+
+
+
+Harrison Expires August 2006 [Page 32]
+
+Internet-Draft LDAP Authentication Methods February 2006
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at ietf-
+ ipr at ietf.org.
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2006).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ This document and the information contained herein are provided on
+ an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
+ REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
+ INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
+ IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
+ THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Harrison Expires August 2006 [Page 33]
+
\ No newline at end of file
Added: openldap/vendor/openldap-release/doc/drafts/draft-ietf-ldapbis-bcp64-xx.txt
===================================================================
--- openldap/vendor/openldap-release/doc/drafts/draft-ietf-ldapbis-bcp64-xx.txt (rev 0)
+++ openldap/vendor/openldap-release/doc/drafts/draft-ietf-ldapbis-bcp64-xx.txt 2007-09-15 10:38:52 UTC (rev 844)
@@ -0,0 +1,1179 @@
+
+
+
+
+
+
+INTERNET-DRAFT Kurt D. Zeilenga
+Intended Category: BCP OpenLDAP Foundation
+Expires in six months 23 January 2006
+Obsoletes: RFC 3383
+
+
+ IANA Considerations for LDAP
+ <draft-ietf-ldapbis-bcp64-06.txt>
+
+
+
+Status of Memo
+
+ This document is intended to be, after appropriate review and
+ revision, submitted to the RFC Editor as a Best Current Practice
+ document. This document is intended to replace RFC 3383.
+ Distribution of this memo is unlimited. Technical discussion of this
+ document will take place on the IETF LDAP Revision Working Group
+ (LDAPBIS) mailing list <ietf-ldapbis at openldap.org>. Please send
+ editorial comments directly to the document editor
+ <Kurt at OpenLDAP.org>.
+
+ By submitting this Internet-Draft, each author represents that any
+ applicable patent or other IPR claims of which he or she is aware
+ have been or will be disclosed, and any of which he or she becomes
+ aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+ Internet-Drafts are working documents of the Internet Engineering
+ Task Force (IETF), its areas, and its working groups. Note that other
+ groups may also distribute working documents as Internet-Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference
+ material or to cite them other than as "work in progress."
+
+ The list of current Internet-Drafts can be accessed at
+ http://www.ietf.org/1id-abstracts.html
+
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html
+
+
+ Copyright (C) The Internet Society (2006). All Rights Reserved.
+
+ Please see the Full Copyright section near the end of this document
+ for more information.
+
+
+
+
+Zeilenga IANA Considerations for LDAP [Page 1]
+
+INTERNET-DRAFT draft-ietf-ldapbis-bcp64-06.txt 23 January 2006
+
+
+Abstract
+
+ This document provides procedures for registering extensible elements
+ of Lightweight Directory Access Protocol (LDAP). The document also
+ provides guidelines to Internet Assigned Numbers Authority (IANA)
+ describing conditions under which new values can be assigned.
+
+
+1. Introduction
+
+ The Lightweight Directory Access Protocol [Roadmap] (LDAP) is an
+ extensible protocol. LDAP supports:
+
+ - addition of new operations,
+ - extension of existing operations, and
+ - extensible schema.
+
+ This document details procedures for registering values of used to
+ unambiguously identify extensible elements of the protocol including:
+
+ - LDAP message types;
+ - LDAP extended operations and controls;
+ - LDAP result codes;
+ - LDAP authentication methods;
+ - LDAP attribute description options; and
+ - Object Identifier descriptors.
+
+ These registries are maintained by the Internet Assigned Numbers
+ Authority (IANA).
+
+ In addition, this document provides guidelines to IANA describing the
+ conditions under which new values can be assigned.
+
+ This document replaces RFC 3383.
+
+
+2. Terminology and Conventions
+
+ This section details terms and conventions used in this document.
+
+
+2.1. Policy Terminology
+
+ The terms "IESG Approval", "Standards Action", "IETF Consensus",
+ "Specification Required", "First Come First Served", "Expert Review",
+ and "Private Use" are used as defined in BCP 26 [RFC2434].
+
+
+
+
+
+Zeilenga IANA Considerations for LDAP [Page 2]
+
+INTERNET-DRAFT draft-ietf-ldapbis-bcp64-06.txt 23 January 2006
+
+
+2.2. Requirement Terminology
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in BCP 14 [RFC2119]. In
+ this case, "the specification" as used by BCP 14 refers to the
+ processing of protocols being submitted to the IETF standards
+ process.
+
+
+2.3. Common ABNF Productions
+
+ A number of syntaxes in this document are described using ABNF
+ [ABNF]. These syntaxes rely on the following common productions:
+
+ ALPHA = %x41-5A / %x61-7A ; "A"-"Z" / "a"-"z"
+ LDIGIT = %x31-39 ; "1"-"9"
+ DIGIT = %x30 / LDIGIT ; "0"-"9"
+ HYPHEN = %x2D ; "-"
+ DOT = %x2E ; "."
+ number = DIGIT / ( LDIGIT 1*DIGIT )
+ keychar = ALPHA / DIGIT / HYPHEN
+ leadkeychar = ALPHA
+ keystring = leadkeychar *keychar
+
+ A keyword is a case-insensitive string of UTF-8 [RFC3629] encoded
+ Unicode [Unicode] restricted to the <keystring> production.
+
+
+3. IANA Considerations for LDAP
+
+ This section details each kind of protocol value which can be
+ registered and provides IANA guidelines on how to assign new values.
+
+ IANA may reject obviously bogus registrations.
+
+ LDAP values specified in RFCs MUST be registered. Other LDAP values,
+ except those in private-use name spaces, SHOULD be registered. RFCs
+ SHOULD NOT reference, use, or otherwise recognize unregistered LDAP
+ values.
+
+
+3.1. Object Identifiers
+
+ Numerous LDAP schema and protocol elements are identified by Object
+ Identifiers (OIDs) [X.680]. Specifications which assign OIDs to
+ elements SHOULD state who delegated the OIDs for its use.
+
+
+
+
+Zeilenga IANA Considerations for LDAP [Page 3]
+
+INTERNET-DRAFT draft-ietf-ldapbis-bcp64-06.txt 23 January 2006
+
+
+ For IETF developed elements, specifications SHOULD use OIDs under
+ "Internet Directory Numbers" (1.3.6.1.1.x). For elements developed
+ by others, any properly delegated OID can be used, including those
+ under "Internet Directory Numbers" (1.3.6.1.1.x) or "Internet Private
+ Enterprise Numbers" (1.3.6.1.4.1.x).
+
+ Internet Directory Numbers (1.3.6.1.1.x) will be assigned upon Expert
+ Review with Specification Required. Only one OID per specification
+ will be assigned. The specification MAY then assign any number of
+ OIDs within this arc without further coordination with IANA.
+
+ Internet Private Enterprise Numbers (1.3.6.1.4.1.x) are assigned by
+ IANA <http://www.iana.org/cgi-bin/enterprise.pl>. Practices for IANA
+ assignment of Internet Private Enterprise Numbers is detailed in RFC
+ 2578 [RFC2578].
+
+ To avoid interoperability problems between early implementations of a
+ "work in progress" and implementations of the published specification
+ (e.g., the RFC), experimental OIDs SHOULD be used in "works in
+ progress" and early implementations. OIDs under the Internet
+ Experimental OID arc (1.3.6.1.3.x) may be used for this purpose.
+ Practices for IANA assignment of these Internet Experimental numbers
+ is detailed in RFC 2578 [RFC2578]
+
+
+3.2 Protocol Mechanisms
+
+ LDAP provides a number of Root DSE attributes for discovery of
+ protocol mechanisms identified by OIDs, including the
+ supportedControl, supportedExtension, and supportedFeatures
+ attributes [Models],
+
+ A registry of OIDs used for discover of protocol mechanisms is
+ provided to allow implementors and others to locate the technical
+ specification for these protocol mechanisms. Future specifications
+ of additional Root DSE attributes holding values identifying protocol
+ mechanisms MAY extend this registry for their values.
+
+ Protocol Mechanisms are registered on a First Come First Served
+ basis.
+
+
+3.3 LDAP Syntaxes
+
+ This registry provides a listing of LDAP syntaxes [Models]. Each
+ LDAP syntax is identified by an object identifier (OID). This
+ registry is provided to allow implementors and others to locate the
+ technical specification describing a particular LDAP Syntax.
+
+
+
+Zeilenga IANA Considerations for LDAP [Page 4]
+
+INTERNET-DRAFT draft-ietf-ldapbis-bcp64-06.txt 23 January 2006
+
+
+ LDAP Syntaxes are registered on a First Come First Served with
+ Specification Required basis.
+
+ Note: unlike object classes, attribute types and various other kinds
+ of schema elements, descriptors are not used in LDAP to identify LDAP
+ Syntaxes.
+
+
+3.4. Object Identifier Descriptors
+
+ LDAP allows short descriptive names (or descriptors) to be used
+ instead of a numeric Object Identifier to identify select protocol
+ extensions [Protocol], schema elements [Models], LDAP URL [LDAPURL]
+ extensions, and other objects.
+
+ While the protocol allows the same descriptor to refer to different
+ object identifiers in certain cases and the registry supports
+ multiple registrations of the same descriptor (each indicating a
+ different kind of schema element and different object identifier),
+ multiple registrations of the same descriptor are to be avoided. All
+ such multiple registration requests require Expert Review.
+
+ Descriptors are restricted to strings of UTF-8 encoded Unicode
+ characters restricted by the following ABNF:
+
+ name = keystring
+
+ Descriptors are case-insensitive.
+
+ Multiple names may be assigned to a given OID. For purposes of
+ registration, an OID is to be represented in numeric OID form (e.g.,
+ 1.1.0.23.40) conforming to the ABNF:
+
+ numericoid = number 1*( DOT number )
+
+ While the protocol places no maximum length restriction upon
+ descriptors, they should be short. Descriptors longer than 48
+ characters may be viewed as too long to register.
+
+ A value ending with a hyphen ("-") reserves all descriptors which
+ start with that value. For example, the registration of the option
+ "descrFamily-" reserves all options which start with "descrFamily-"
+ for some related purpose.
+
+ Descriptors beginning with "x-" are for Private Use and cannot be
+ registered.
+
+ Descriptors beginning with "e-" are reserved for experiments and will
+
+
+
+Zeilenga IANA Considerations for LDAP [Page 5]
+
+INTERNET-DRAFT draft-ietf-ldapbis-bcp64-06.txt 23 January 2006
+
+
+ be registered on a First Come First Served basis.
+
+ All other descriptors require Expert Review to be registered.
+
+ The registrant need not "own" the OID being named.
+
+ The OID name space is managed by The ISO/IEC Joint Technical
+ Committee 1 - Subcommittee 6.
+
+
+3.5. AttributeDescription Options
+
+ An AttributeDescription [Models] can contain zero or more options
+ specifying additional semantics. An option SHALL be restricted to a
+ string UTF-8 encoded Unicode characters limited by the following
+ ABNF:
+
+ option = keystring
+
+ Options are case-insensitive.
+
+ While the protocol places no maximum length restriction upon option
+ strings, they should be short. Options longer than 24 characters may
+ be viewed as too long to register.
+
+ Values ending with a hyphen ("-") reserve all option names which
+ start with the name. For example, the registration of the option
+ "optionFamily-" reserves all options which start with "optionFamily-"
+ for some related purpose.
+
+ Options beginning with "x-" are for Private Use and cannot be
+ registered.
+
+ Options beginning with "e-" are reserved for experiments and will be
+ registered on a First Come First Served basis.
+
+ All other options require Standards Action or Expert Review with
+ Specification Required to be registered.
+
+
+3.6. LDAP Message Types
+
+ Each protocol message is encapsulated in an LDAPMessage envelope
+ [Protocol]. The protocolOp CHOICE indicates the type of message
+ encapsulated. Each message type consists of an ASN.1 identifier in
+ the form of a keyword and a non-negative choice number. The choice
+ number is combined with the class (APPLICATION) and data type
+ (CONSTRUCTED or PRIMITIVE) to construct the BER tag in the message's
+
+
+
+Zeilenga IANA Considerations for LDAP [Page 6]
+
+INTERNET-DRAFT draft-ietf-ldapbis-bcp64-06.txt 23 January 2006
+
+
+ encoding. The choice numbers for existing protocol messages are
+ implicit in the protocol's ASN.1 defined in [Protocol].
+
+ New values will be registered upon Standards Action.
+
+ Note: LDAP provides extensible messages which reduces, but does not
+ eliminate, the need to add new message types.
+
+
+3.7. LDAP Authentication Method
+
+ The LDAP Bind operation supports multiple authentication methods
+ [Protocol]. Each authentication choice consists of an ASN.1
+ identifier in the form of a keyword and a non-negative integer.
+
+ The registrant SHALL classify the authentication method usage using
+ one of the following terms:
+
+ COMMON - method is appropriate for common use on the
+ Internet,
+ LIMITED USE - method is appropriate for limited use,
+ OBSOLETE - method has been deprecated or otherwise found to
+ be inappropriate for any use.
+
+ Methods without publicly available specifications SHALL NOT be
+ classified as COMMON. New registrations of class OBSOLETE cannot be
+ registered.
+
+ New authentication method integers in the range 0-1023 require
+ Standards Action to be registered. New authentication method
+ integers in the range 1024-4095 require Expert Review with
+ Specification Required. New authentication method integers in the
+ range 4096-16383 will be registered on a First Come First Served
+ basis. Keywords associated with integers in the range 0-4095 SHALL
+ NOT start with "e-" or "x-". Keywords associated with integers in
+ the range 4096-16383 SHALL start with "e-". Values greater than or
+ equal to 16384 and keywords starting with "x-" are for Private Use
+ and cannot be registered.
+
+ Note: LDAP supports Simple Authentication and Security Layers [SASL]
+ as an authentication choice. SASL is an extensible
+ authentication framework.
+
+
+3.8. LDAP Result Codes
+
+ LDAP result messages carry an resultCode enumerated value to indicate
+ the outcome of the operation [Protocol]. Each result code consists
+
+
+
+Zeilenga IANA Considerations for LDAP [Page 7]
+
+INTERNET-DRAFT draft-ietf-ldapbis-bcp64-06.txt 23 January 2006
+
+
+ of a ASN.1 identifier in the form of a keyword and a non-negative
+ integer.
+
+ New resultCodes integers in the range 0-1023 require Standards Action
+ to be registered. New resultCode integers in the range 1024-4095
+ require Expert Review with Specification Required. New resultCode
+ integers in the range 4096-16383 will be registered on a First Come
+ First Served basis. Keywords associated with integers in the range
+ 0-4095 SHALL NOT start with "e-" or "x-". Keywords associated with
+ integers in the range 4096-16383 SHALL start with "e-". Values
+ greater than or equal to 16384 and keywords starting with "x-" are
+ for Private Use and cannot be registered.
+
+
+3.9. LDAP Search Scope
+
+ LDAP SearchRequest messages carry a scope enumerated value to
+ indicate the extend of search within the DIT [Protocol] Each search
+ value consists of a ASN.1 identifier in the form of a keyword and a
+ non-negative integer.
+
+ New scope integers in the range 0-1023 require Standards Action to be
+ registered. New scope integers in the range 1024-4095 require Expert
+ Review with Specification Required. New scope integers in the range
+ 4096-16383 will be registered on a First Come First Served basis.
+ Keywords associated with integers in the range 0-4095 SHALL NOT start
+ with "e-" or "x-". Keywords associated with integers in the range
+ 4096-16383 SHALL start with "e-". Values greater than or equal to
+ 16384 and keywords starting with "x-" are for Private Use and cannot
+ be registered.
+
+
+3.10. LDAP Filter Choice
+
+ LDAP filters are used in making assertions against an object
+ represented in the directory [Protocol]. The Filter CHOICE indicates
+ a type of assertion. Each Filter CHOICE consists of an ASN.1
+ identifier in the form of a keyword and a non-negative choice number.
+ The choice number is combined with the class (APPLICATION) and data
+ type (CONSTRUCTED or PRIMITIVE) to construct the BER tag in the
+ message's encoding.
+
+ Note: LDAP provides the extensibleMatching choice which reduces, but
+ does not eliminate, the need to add new filter choices.
+
+
+3.11. LDAP ModifyRequest Operation Type
+
+
+
+
+Zeilenga IANA Considerations for LDAP [Page 8]
+
+INTERNET-DRAFT draft-ietf-ldapbis-bcp64-06.txt 23 January 2006
+
+
+ The LDAP ModifyRequest carries a sequence of modification operations
+ [Protocol]. Each kind (e.g., add, delete, replace) of operation is
+ consists of a ASN.1 identifier in the form of a keyword and a
+ non-negative integer.
+
+ New operation type integers in the range 0-1023 require Standards
+ Action to be registered. New operation type integers in the range
+ 1024-4095 require Expert Review with Specification Required. New
+ operation type integers in the range 4096-16383 will be registered on
+ a First Come First Served basis. Keywords associated with integers
+ in the range 0-4095 SHALL NOT start with "e-" or "x-". Keywords
+ associated with integers in the range 4096-16383 SHALL start with
+ "e-". Values greater than or equal to 16384 and keywords starting
+ with "x-" are for Private Use and cannot be registered.
+
+
+3.12. LDAP authzId Prefixes
+
+ Authorization Identities in LDAP are strings conforming to the
+ <authzId> production [AuthMeth]. This production is extensible.
+ Each new specific authorization form is identified by a prefix string
+ conforming to the following ABNF:
+
+ prefix = keystring COLON
+ COLON = %x3A ; COLON (":" U+003A)
+
+ Prefixes are case-insensitive.
+
+ While the protocol places no maximum length restriction upon prefix
+ strings, they should be short. Prefixes longer than 12 characters
+ may be viewed as too long to register.
+
+ Prefixes beginning with "x-" are for Private Use and cannot be
+ registered.
+
+ Prefixes beginning with "e-" are reserved for experiments and will be
+ registered on a First Come First Served basis.
+
+ All other prefixes require Standards Action or Expert Review with
+ Specification Required to be registered.
+
+
+3.13. Directory Systems Names
+
+ The IANA-maintained "Directory Systems Names" registry [IANADSN] of
+ valid keywords for well known attributes was used in the LDAPv2
+ string representation of a distinguished name [RFC1779]. LDAPv2 is
+ now Historic [RFC3494].
+
+
+
+Zeilenga IANA Considerations for LDAP [Page 9]
+
+INTERNET-DRAFT draft-ietf-ldapbis-bcp64-06.txt 23 January 2006
+
+
+ Directory systems names are not known to be used in any other
+ context. LDAPv3 [LDAPDN] uses Object Identifier Descriptors [Section
+ 3.2] (which have a different syntax than directory system names).
+
+ New Directory System Names will no longer be accepted. For
+ historical purposes, the current list of registered names should
+ remain publicly available.
+
+
+4. Registration Procedure
+
+ The procedure given here MUST be used by anyone who wishes to use a
+ new value of a type described in Section 3 of this document.
+
+ The first step is for the requester to fill out the appropriate form.
+ Templates are provided in Appendix A.
+
+ If the policy is Standards Action, the completed form SHOULD be
+ provided to the IESG with the request for Standards Action. Upon
+ approval of the Standards Action, the IESG SHALL forward the request
+ (possibly revised) to IANA. The IESG SHALL be viewed as the owner of
+ all values requiring Standards Action.
+
+ If the policy is Expert Review, the requester SHALL post the
+ completed form to the <directory at apps.ietf.org> mailing list for
+ public review. The review period is two (2) weeks. If a revised
+ form is later submitted, the review period is restarted. Anyone may
+ subscribe to this list by sending a request to
+ <directory-request at apps.ietf.org>. During the review, objections may
+ be raised by anyone (including the Expert) on the list. After
+ completion of the review, the Expert, based upon public comments,
+ SHALL either approve the request and forward it to the IANA OR deny
+ the request. In either case, the Expert SHALL promptly notify the
+ requester of the action. Actions of the Expert may be appealed
+ [RFC2026]. The Expert is appointed by Applications Area Director(s).
+ The requester is viewed as the owner of values registered under
+ Expert Review.
+
+ If the policy is First Come First Served, the requester SHALL submit
+ the completed form directly to the IANA: <iana at iana.org>. The
+ requester is viewed as the owner of values registered under First
+ Come First Served.
+
+ Neither the Expert nor IANA will take position on the claims of
+ copyright or trademarks issues regarding completed forms.
+
+ Prior to submission of the Internet Draft (I-D) to the RFC Editor but
+ after IESG review and tentative approval, the document editor SHOULD
+
+
+
+Zeilenga IANA Considerations for LDAP [Page 10]
+
+INTERNET-DRAFT draft-ietf-ldapbis-bcp64-06.txt 23 January 2006
+
+
+ revise the I-D to use registered values.
+
+
+5. Registration Maintenance
+
+ This section discusses maintenance of registrations.
+
+
+5.1. Lists of Registered Values
+
+ IANA makes lists of registered values readily available to the
+ Internet community on their web site: <http://www.iana.org/>.
+
+
+5.2. Change Control
+
+ The registration owner MAY update the registration subject to the
+ same constraints and review as with new registrations. In cases
+ where the owner is not unable or unwilling to make necessary updates,
+ the IESG MAY assume ownership in order to update the registration.
+
+
+5.3. Comments
+
+ For cases where others (anyone other than the owner) have significant
+ objections to the claims in a registration and the owner does not
+ agree to change the registration, comments MAY be attached to a
+ registration upon Expert Review. For registrations owned by the
+ IESG, the objections SHOULD be addressed by initiating a request for
+ Expert Review.
+
+ The form to these requests is ad hoc, but MUST include the specific
+ objections to be reviewed and SHOULD contain (directly or by
+ reference) materials supporting the objections.
+
+
+6. Security Considerations
+
+ The security considerations detailed in BCP 26 [RFC2434] are
+ generally applicable to this document. Additional security
+ considerations specific to each name space are discussed in Section 3
+ where appropriate.
+
+ Security considerations for LDAP are discussed in documents
+ comprising the technical specification [Roadmap].
+
+
+7. Acknowledgment
+
+
+
+Zeilenga IANA Considerations for LDAP [Page 11]
+
+INTERNET-DRAFT draft-ietf-ldapbis-bcp64-06.txt 23 January 2006
+
+
+ This document is a product of the IETF LDAP Revision (LDAPBIS)
+ Working Group (WG). This document is a revision of RFC 3383, also a
+ product of the LDAPBIS WG.
+
+ This document includes text borrowed from "Guidelines for Writing an
+ IANA Considerations Section in RFCs" [RFC2434] by Thomas Narten and
+ Harald Alvestrand.
+
+
+8. Author's Address
+
+ Kurt D. Zeilenga
+ OpenLDAP Foundation
+
+ Email: Kurt at OpenLDAP.org
+
+
+9. References
+
+ [[Note to the RFC Editor: please replace the citation tags used in
+ referencing Internet-Drafts with tags of the form RFCnnnn where
+ possible.]]
+
+
+9.1. Normative References
+
+ [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
+ 3", BCP 9 (also RFC 2026), October 1996.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14 (also RFC 2119), March 1997.
+
+ [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
+ IANA Considerations Section in RFCs", BCP 26 (also RFC
+ 2434), October 1998.
+
+ [RFC2578] K. McCloghrie, D. Perkins, J. Schoenwaelder, "Structure
+ of Management Information Version 2 (SMIv2)", RFC 2578
+ (STD: 58), April 1999.
+ [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
+ 10646", RFC 3629 (also STD 63), November 2003.
+
+ [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
+ Specifications: ABNF", RFC 4234, October 2005.
+
+ [Roadmap] Zeilenga, K. (editor), "LDAP: Technical Specification
+ Road Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in
+ progress.
+
+
+
+Zeilenga IANA Considerations for LDAP [Page 12]
+
+INTERNET-DRAFT draft-ietf-ldapbis-bcp64-06.txt 23 January 2006
+
+
+ [AuthMeth] Harrison, R. (editor), "LDAP: Authentication Methods and
+ Connection Level Security Mechanisms",
+ draft-ietf-ldapbis-authmeth-xx.txt, a work in progress.
+
+ [Models] Zeilenga, K. (editor), "LDAP: Directory Information
+ Models", draft-ietf-ldapbis-models-xx.txt, a work in
+ progress.
+
+ [Protocol] Sermersheim, J. (editor), "LDAP: The Protocol",
+ draft-ietf-ldapbis-protocol-xx.txt, a work in progress.
+
+ [LDAPURL] Smith, M. (editor), "LDAP: Uniform Resource Locator",
+ draft-ietf-ldapbis-url-xx.txt, a work in progress.
+
+ [Unicode] The Unicode Consortium, "The Unicode Standard, Version
+ 3.2.0" is defined by "The Unicode Standard, Version 3.0"
+ (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5),
+ as amended by the "Unicode Standard Annex #27: Unicode
+ 3.1" (http://www.unicode.org/reports/tr27/) and by the
+ "Unicode Standard Annex #28: Unicode 3.2"
+ (http://www.unicode.org/reports/tr28/).
+
+ [X.680] International Telecommunication Union -
+ Telecommunication Standardization Sector, "Abstract
+ Syntax Notation One (ASN.1) - Specification of Basic
+ Notation", X.680(2002) (also ISO/IEC 8824-1:2002).
+
+
+9.2. Informative References
+
+ [RFC1779] Kille, S., "A String Representation of Distinguished
+ Names", RFC 1779, March 1995.
+
+ [RFC3494] Zeilenga, K., "Lightweight Directory Access Protocol
+ version 2 (LDAPv2) to Historic Status", RFC 3494, March
+ 2003.
+
+ [Syntaxes] Legg, S. (editor), "LDAP: Syntaxes and Matching Rules",
+ draft-ietf-ldapbis-syntaxes-xx.txt, a work in progress.
+
+ [LDAPDN] Zeilenga, K. (editor), "LDAP: String Representation of
+ Distinguished Names", draft-ietf-ldapbis-dn-xx.txt, a
+ work in progress.
+
+ [SASL] Melnikov, A. (Editor), "Simple Authentication and
+ Security Layer (SASL)",
+ draft-ietf-sasl-rfc2222bis-xx.txt, a work in progress.
+
+
+
+
+Zeilenga IANA Considerations for LDAP [Page 13]
+
+INTERNET-DRAFT draft-ietf-ldapbis-bcp64-06.txt 23 January 2006
+
+
+ [IANADSN] IANA, "Directory Systems Names",
+ http://www.iana.org/assignments/directory-system-names.
+
+
+Appendix A. Registration Templates
+
+ This appendix provides registration templates for registering new
+ LDAP values. Note that more than one value may be requested by
+ extending the template by listing multiple values, or through use of
+ tables.
+
+
+A.1. LDAP Object Identifier Registration Template
+
+ Subject: Request for LDAP OID Registration
+
+ Person & email address to contact for further information:
+
+ Specification: (I-D)
+
+ Author/Change Controller:
+
+ Comments:
+
+ (Any comments that the requester deems relevant to the request)
+
+
+A.2. LDAP Protocol Mechanism Registration Template
+
+ Subject: Request for LDAP Protocol Mechanism Registration
+
+ Object Identifier:
+
+ Description:
+
+ Person & email address to contact for further information:
+
+ Usage: (One of Control or Extension or Feature or other)
+
+ Specification: (RFC, I-D, URI)
+
+ Author/Change Controller:
+
+ Comments:
+
+ (Any comments that the requester deems relevant to the request)
+
+
+
+
+
+Zeilenga IANA Considerations for LDAP [Page 14]
+
+INTERNET-DRAFT draft-ietf-ldapbis-bcp64-06.txt 23 January 2006
+
+
+A.3. LDAP Syntax Registration Template
+
+ Subject: Request for LDAP Syntax Registration
+
+ Object Identifier:
+
+ Description:
+
+ Person & email address to contact for further information:
+
+ Specification: (RFC, I-D, URI)
+
+ Author/Change Controller:
+
+ Comments:
+
+ (Any comments that the requester deems relevant to the request)
+
+
+A.4. LDAP Descriptor Registration Template
+
+ Subject: Request for LDAP Descriptor Registration
+
+ Descriptor (short name):
+
+ Object Identifier:
+
+ Person & email address to contact for further information:
+
+ Usage: (One of administrative role, attribute type, matching rule,
+ name form, object class, URL extension, or other)
+
+ Specification: (RFC, I-D, URI)
+
+ Author/Change Controller:
+
+ Comments:
+
+ (Any comments that the requester deems relevant to the request)
+
+
+A.5. LDAP Attribute Description Option Registration Template
+
+ Subject: Request for LDAP Attribute Description Option Registration
+
+ Option Name:
+
+ Family of Options: (YES or NO)
+
+
+
+Zeilenga IANA Considerations for LDAP [Page 15]
+
+INTERNET-DRAFT draft-ietf-ldapbis-bcp64-06.txt 23 January 2006
+
+
+ Person & email address to contact for further information:
+
+ Specification: (RFC, I-D, URI)
+
+ Author/Change Controller:
+
+ Comments:
+
+ (Any comments that the requester deems relevant to the request)
+
+
+A.6. LDAP Message Type Registration Template
+
+ Subject: Request for LDAP Message Type Registration
+
+ LDAP Message Name:
+
+ Person & email address to contact for further information:
+
+ Specification: (Approved I-D)
+
+ Comments:
+
+ (Any comments that the requester deems relevant to the request)
+
+
+A.7. LDAP Authentication Method Registration Template
+
+ Subject: Request for LDAP Authentication Method Registration
+
+ Authentication Method Name:
+
+ Person & email address to contact for further information:
+
+ Specification: (RFC, I-D, URI)
+
+ Intended Usage: (One of COMMON, LIMITED-USE, OBSOLETE)
+
+ Author/Change Controller:
+
+ Comments:
+
+ (Any comments that the requester deems relevant to the request)
+
+
+A.8. LDAP Result Code Registration Template
+
+ Subject: Request for LDAP Result Code Registration
+
+
+
+Zeilenga IANA Considerations for LDAP [Page 16]
+
+INTERNET-DRAFT draft-ietf-ldapbis-bcp64-06.txt 23 January 2006
+
+
+ Result Code Name:
+
+ Person & email address to contact for further information:
+
+ Specification: (RFC, I-D, URI)
+
+ Author/Change Controller:
+
+ Comments:
+
+ (Any comments that the requester deems relevant to the request)
+
+
+A.8. LDAP Search Scope Registration Template
+
+ Subject: Request for LDAP Search Scope Registration
+
+ Search Scope Name:
+
+ Filter Scope String:
+
+ Person & email address to contact for further information:
+
+ Specification: (RFC, I-D, URI)
+
+ Author/Change Controller:
+
+ Comments:
+
+ (Any comments that the requester deems relevant to the request)
+
+
+A.9. LDAP Filter Choice Registration Template
+
+ Subject: Request for LDAP Filter Choice Registration
+
+ Filter Choice Name:
+
+ Person & email address to contact for further information:
+
+ Specification: (RFC, I-D, URI)
+
+ Author/Change Controller:
+
+ Comments:
+
+ (Any comments that the requester deems relevant to the request)
+
+
+
+
+Zeilenga IANA Considerations for LDAP [Page 17]
+
+INTERNET-DRAFT draft-ietf-ldapbis-bcp64-06.txt 23 January 2006
+
+
+A.10. LDAP ModifyRequest Operation Registration Template
+
+ Subject: Request for LDAP ModifyRequest Operation Registration
+
+ ModifyRequest Operation Name:
+
+ Person & email address to contact for further information:
+
+ Specification: (RFC, I-D, URI)
+
+ Author/Change Controller:
+
+ Comments:
+
+ (Any comments that the requester deems relevant to the request)
+
+
+Appendix B. Changes since RFC 3383
+
+ This informative appendix provides a summary of changes made since RFC
+ 3383.
+
+ - Object Identifier Descriptors practices were updated to require
+ all descriptors defined in RFCs to be registered and
+ recommending all other descriptors (excepting those in
+ private-use name space) be registered. Additionally, all
+ requests for multiple registrations of the same descriptor are
+ now subject to Expert Review.
+
+ - Protocol Mechanisms practices were updated to include values of
+ the 'supportedFeatures' attribute type.
+
+ - LDAP Syntax, Search Scope, Filter Choice, ModifyRequest
+ operation, and authzId prefixes registries were added.
+ [[Initial values provided in Appendix C. This Appendix is to be
+ removed by the RFC Editor before publication as an RFC.]]
+
+ - References to RFCs comprising the LDAP technical specifications
+ have been updated to latest revisions.
+
+ - References to ISO 10646 have been replaced with [Unicode].
+
+ - The "Assigned Values" appendix providing initial registry values
+ was removed.
+
+ - Numerous editorial changes were made.
+
+
+
+
+
+Zeilenga IANA Considerations for LDAP [Page 18]
+
+INTERNET-DRAFT draft-ietf-ldapbis-bcp64-06.txt 23 January 2006
+
+
+Appendix C. Initial Values for new registries
+
+ This appendix provides initial values for new registries.
+
+
+C.1. LDAP Syntaxes
+
+ Object Identifier Syntax Owner Reference
+ ----------------------------- -------------------------- ----- ---
+ 1.3.6.1.4.1.1466.115.121.1.3 Attribute Type Description IESG [Syntaxes]
+ 1.3.6.1.4.1.1466.115.121.1.6 Bit String IESG [Syntaxes]
+ 1.3.6.1.4.1.1466.115.121.1.7 Boolean IESG [Syntaxes]
+ 1.3.6.1.4.1.1466.115.121.1.11 Country String IESG [Syntaxes]
+ 1.3.6.1.4.1.1466.115.121.1.12 DN IESG [Syntaxes]
+ 1.3.6.1.4.1.1466.115.121.1.14 Delivery Method IESG [Syntaxes]
+ 1.3.6.1.4.1.1466.115.121.1.15 Directory String IESG [Syntaxes]
+ 1.3.6.1.4.1.1466.115.121.1.16 DIT Content Rule Description IESG [Syntaxes]
+ 1.3.6.1.4.1.1466.115.121.1.17 DIT Structure Rule Description IESG [Syntaxes]
+ 1.3.6.1.4.1.1466.115.121.1.21 Enhanced Guide IESG [Syntaxes]
+ 1.3.6.1.4.1.1466.115.121.1.22 Facsimile Telephone Number IESG [Syntaxes]
+ 1.3.6.1.4.1.1466.115.121.1.23 Fax IESG [Syntaxes]
+ 1.3.6.1.4.1.1466.115.121.1.24 Generalized Time IESG [Syntaxes]
+ 1.3.6.1.4.1.1466.115.121.1.25 Guide IESG [Syntaxes]
+ 1.3.6.1.4.1.1466.115.121.1.26 IA5 String IESG [Syntaxes]
+ 1.3.6.1.4.1.1466.115.121.1.27 Integer IESG [Syntaxes]
+ 1.3.6.1.4.1.1466.115.121.1.28 JPEG IESG [Syntaxes]
+ 1.3.6.1.4.1.1466.115.121.1.30 Matching Rule Description IESG [Syntaxes]
+ 1.3.6.1.4.1.1466.115.121.1.31 Matching Rule Use Description IESG [Syntaxes]
+ 1.3.6.1.4.1.1466.115.121.1.34 Name And Optional UID IESG [Syntaxes]
+ 1.3.6.1.4.1.1466.115.121.1.35 Name Form Description IESG [Syntaxes]
+ 1.3.6.1.4.1.1466.115.121.1.36 Numeric String IESG [Syntaxes]
+ 1.3.6.1.4.1.1466.115.121.1.37 Object Class Description IESG [Syntaxes]
+ 1.3.6.1.4.1.1466.115.121.1.38 OID IESG [Syntaxes]
+ 1.3.6.1.4.1.1466.115.121.1.39 Other Mailbox IESG [Syntaxes]
+ 1.3.6.1.4.1.1466.115.121.1.40 Octet String IESG [Syntaxes]
+ 1.3.6.1.4.1.1466.115.121.1.41 Postal Address IESG [Syntaxes]
+ 1.3.6.1.4.1.1466.115.121.1.44 Printable String IESG [Syntaxes]
+ 1.3.6.1.4.1.1466.115.121.1.50 Telephone Number IESG [Syntaxes]
+ 1.3.6.1.4.1.1466.115.121.1.51 Teletex Terminal Identifier IESG [Syntaxes]
+ 1.3.6.1.4.1.1466.115.121.1.52 Telex Number IESG [Syntaxes]
+ 1.3.6.1.4.1.1466.115.121.1.53 UTC Time IESG [Syntaxes]
+ 1.3.6.1.4.1.1466.115.121.1.54 LDAP Syntax Description IESG [Syntaxes]
+ 1.3.6.1.4.1.1466.115.121.1.58 Substring Assertion IESG [Syntaxes]
+
+
+C.2. LDAP Search Scopes
+
+ Name URLString Value Owner Reference
+
+
+
+Zeilenga IANA Considerations for LDAP [Page 19]
+
+INTERNET-DRAFT draft-ietf-ldapbis-bcp64-06.txt 23 January 2006
+
+
+ ---------------- --------- ----- ----- -------------------
+ baseObject base 0 IESG [Protocol][LDAPURL]
+ singleLevel one 1 IESG [Protocol][LDAPURL]
+ wholeSubtree sub 2 IESG [Protocol][LDAPURL]
+
+
+C.3. LDAP Filter Choices
+
+ Name Value Owner Reference
+ ---------------- ----- ----- ---------
+ and 0 IESG [Protocol]
+ or 1 IESG [Protocol]
+ not 2 IESG [Protocol]
+ equalityMatch 3 IESG [Protocol]
+ substrings 4 IESG [Protocol]
+ greaterOrEqual 5 IESG [Protocol]
+ lessOrEqual 6 IESG [Protocol]
+ present 7 IESG [Protocol]
+ approxMatch 8 IESG [Protocol]
+ extensibleMatch 9 IESG [Protocol]
+
+
+C.4. LDAP ModifyRequest Operations
+
+ Name Value Owner Reference
+ ---------------- ----- ----- ---------
+ add 0 IESG [Protocol]
+ delete 1 IESG [Protocol]
+ replace 2 IESG [Protocol]
+
+
+C.5. LDAP authzId prefixes
+
+ Name Prefix Owner Reference
+ ---------------- ------ ----- ---------
+ dnAuthzId dn: IESG [AuthMeth]
+ uAuthzId u: IESG [AuthMeth]
+
+
+Full Copyright
+
+ Copyright (C) The Internet Society (2006).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ This document and the information contained herein are provided on an
+
+
+
+Zeilenga IANA Considerations for LDAP [Page 20]
+
+INTERNET-DRAFT draft-ietf-ldapbis-bcp64-06.txt 23 January 2006
+
+
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+Intellectual Property Rights
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be found
+ in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this specification
+ can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr at ietf.org.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga IANA Considerations for LDAP [Page 21]
+
Added: openldap/vendor/openldap-release/doc/drafts/draft-ietf-ldapbis-dn-xx.txt
===================================================================
--- openldap/vendor/openldap-release/doc/drafts/draft-ietf-ldapbis-dn-xx.txt (rev 0)
+++ openldap/vendor/openldap-release/doc/drafts/draft-ietf-ldapbis-dn-xx.txt 2007-09-15 10:38:52 UTC (rev 844)
@@ -0,0 +1,843 @@
+
+
+
+
+
+INTERNET-DRAFT Editor: Kurt D. Zeilenga
+Intended Category: Standard Track OpenLDAP Foundation
+Expires in six months 10 February 2005
+Obsoletes: RFC 2253
+
+
+
+ LDAP: String Representation of Distinguished Names
+ <draft-ietf-ldapbis-dn-16.txt>
+
+
+
+Status of Memo
+
+ This document is intended to be, after appropriate review and
+ revision, submitted to the RFC Editor as a Standard Track document
+ replacing RFC 2253. Distribution of this memo is unlimited.
+ Technical discussion of this document will take place on the IETF LDAP
+ Revision (LDAPBIS) Working Group mailing list
+ <ietf-ldapbis at openldap.org>. Please send editorial comments directly
+ to the document editor <Kurt at OpenLDAP.org>.
+
+ By submitting this Internet-Draft, I accept the provisions of Section
+ 4 of RFC 3667. By submitting this Internet-Draft, I certify that any
+ applicable patent or other IPR claims of which I am aware have been
+ disclosed, or will be disclosed, and any of which I become aware will
+ be disclosed, in accordance with RFC 3668.
+
+ Internet-Drafts are working documents of the Internet Engineering Task
+ Force (IETF), its areas, and its working groups. Note that other
+ groups may also distribute working documents as Internet-Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference material
+ or to cite them other than as "work in progress."
+
+ The list of current Internet-Drafts can be accessed at
+ http://www.ietf.org/1id-abstracts.html
+
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html
+
+
+ Copyright (C) The Internet Society (2005). All Rights Reserved.
+
+ Please see the Full Copyright section near the end of this document
+ for more information.
+
+
+
+Zeilenga LDAP: Distinguished Names [Page 1]
+
+INTERNET-DRAFT draft-ietf-ldapbis-dn-16.txt 10 February 2005
+
+
+Abstract
+
+ The X.500 Directory uses distinguished names (DNs) as primary keys to
+ entries in the directory. This document defines the string
+ representation used in the Lightweight Directory Access Protocol
+ (LDAP) to transfer distinguished names. The string representation is
+ designed to give a clean representation of commonly used distinguished
+ names, while being able to represent any distinguished name.
+
+
+1. Background and Intended Usage
+
+ In X.500-based directory systems [X.500], including those accessed
+ using the Lightweight Directory Access Protocol (LDAP) [Roadmap],
+ distinguished names (DNs) are used to unambiguously refer to directory
+ entries [X.501][Models].
+
+ The structure of a DN [X.501] is described in terms of ASN.1 [X.680].
+ In the X.500 Directory Access Protocol [X.511] (and other ITU-defined
+ directory protocols), DNs are encoded using the Basic Encoding Rules
+ (BER) [X.690]. In LDAP, DNs are represented in the string form
+ described in this document.
+
+ It is important to have a common format to be able to unambiguously
+ represent a distinguished name. The primary goal of this
+ specification is ease of encoding and decoding. A secondary goal is
+ to have names that are human readable. It is not expected that LDAP
+ implementations with a human user interface would display these
+ strings directly to the user, but would most likely be performing
+ translations (such as expressing attribute type names in the local
+ national language).
+
+ This document defines the string representation of Distinguished Names
+ used in LDAP [Protocol][Syntaxes]. Section 2 details the RECOMMENDED
+ algorithm for converting a DN from its ASN.1 structured representation
+ to a string. Section 3 details how to convert a DN from a string to a
+ ASN.1 structured representation.
+
+ While other documents may define other algorithms for converting a DN
+ from its ASN.1 structured representation to a string, all algorithms
+ MUST produce strings which adhere to the requirements of Section 3.
+
+ This document does not define a canonical string representation for
+ DNs. Comparison of DNs for equality is to be performed in accordance
+ with the distinguishedNameMatch matching rule [Syntaxes].
+
+ This document is a integral part of the LDAP technical specification
+ [Roadmap] which obsoletes the previously defined LDAP technical
+
+
+
+Zeilenga LDAP: Distinguished Names [Page 2]
+
+INTERNET-DRAFT draft-ietf-ldapbis-dn-16.txt 10 February 2005
+
+
+ specification, RFC 3377, in its entirety. This document obsoletes RFC
+ 2253. Changes since RFC 2253 are summarized in Appendix B.
+
+ This specification assumes familiarity with X.500 [X.500] and the
+ concept of Distinguished Name [X.501][Models].
+
+
+1.1. Conventions
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in BCP 14 [RFC2119].
+
+ Character names in this document use the notation for code points and
+ names from the Unicode Standard [Unicode]. For example, the letter
+ "a" may be represented as either <U+0061> or <LATIN SMALL LETTER A>.
+
+ Note: a glossary of terms used in Unicode can be found in [Glossary].
+ Information on the Unicode character encoding model can be found in
+ [CharModel].
+
+
+2. Converting DistinguishedName from ASN.1 to a String
+
+ X.501 [X.501] defines the ASN.1 [X.680] structure of distinguished
+ name. The following is a variant provided for discussion purposes.
+
+ DistinguishedName ::= RDNSequence
+
+ RDNSequence ::= SEQUENCE OF RelativeDistinguishedName
+
+ RelativeDistinguishedName ::= SET SIZE (1..MAX) OF
+ AttributeTypeAndValue
+
+ AttributeTypeAndValue ::= SEQUENCE {
+ type AttributeType,
+ value AttributeValue }
+
+ This section defines the RECOMMENDED algorithm for converting a
+ distinguished name from an ASN.1 structured representation to an UTF-8
+ [RFC3629] encoded Unicode [Unicode] character string representation.
+ Other documents may describe other algorithms for converting a
+ distinguished name to a string, but only strings which conform to the
+ grammar defined in Section 3 SHALL be produced by LDAP
+ implementations.
+
+
+2.1. Converting the RDNSequence
+
+
+
+Zeilenga LDAP: Distinguished Names [Page 3]
+
+INTERNET-DRAFT draft-ietf-ldapbis-dn-16.txt 10 February 2005
+
+
+ If the RDNSequence is an empty sequence, the result is the empty or
+ zero length string.
+
+ Otherwise, the output consists of the string encodings of each
+ RelativeDistinguishedName in the RDNSequence (according to Section
+ 2.2), starting with the last element of the sequence and moving
+ backwards toward the first.
+
+ The encodings of adjoining RelativeDistinguishedNames are separated by
+ a comma (',' U+002C) character.
+
+
+2.2. Converting RelativeDistinguishedName
+
+ When converting from an ASN.1 RelativeDistinguishedName to a string,
+ the output consists of the string encodings of each
+ AttributeTypeAndValue (according to Section 2.3), in any order.
+
+ Where there is a multi-valued RDN, the outputs from adjoining
+ AttributeTypeAndValues are separated by a plus sign ('+' U+002B)
+ character.
+
+
+2.3. Converting AttributeTypeAndValue
+
+ The AttributeTypeAndValue is encoded as the string representation of
+ the AttributeType, followed by an equals sign ('=' U+003D) character,
+ followed by the string representation of the AttributeValue. The
+ encoding of the AttributeValue is given in Section 2.4.
+
+ If the AttributeType is defined to have a short name (descriptor)
+ [Models] and that short name is known to be registered
+ [REGISTRY][BCP64bis] as identifying the AttributeType, that short
+ name, a <descr>, is used. Otherwise the AttributeType is encoded as
+ the dotted-decimal encoding, a <numericoid>, of its OBJECT IDENTIFIER.
+ The <descr> and <numericoid> is defined in [Models].
+
+ Implementations are not expected to dynamically update their knowledge
+ of registered short names. However, implementations SHOULD provide a
+ mechanism to allow its knowledge of registered short names to be
+ updated.
+
+
+2.4. Converting an AttributeValue from ASN.1 to a String
+
+ If the AttributeType is of the dotted-decimal form, the AttributeValue
+ is represented by an number sign ('#' U+0023) character followed by
+ the hexadecimal encoding of each of the octets of the BER encoding of
+
+
+
+Zeilenga LDAP: Distinguished Names [Page 4]
+
+INTERNET-DRAFT draft-ietf-ldapbis-dn-16.txt 10 February 2005
+
+
+ the X.500 AttributeValue. This form is also used when the syntax of
+ the AttributeValue does not have a LDAP-specific [Syntaxes, Section
+ 3.1] string encoding defined for it or the LDAP-specific string
+ encoding is not restricted to UTF-8 encoded Unicode characters. This
+ form may also be used in other cases, such as when a reversible string
+ representation is desired (see Section 5.2).
+
+ Otherwise, if the AttributeValue is of a syntax which has a
+ LDAP-specific string encoding, the value is converted first to a UTF-8
+ encoded Unicode string according to its syntax specification (see
+ [Syntaxes, Section 3.3] for examples). If that UTF-8 encoded Unicode
+ string does not have any of the following characters which need
+ escaping, then that string can be used as the string representation of
+ the value.
+
+ - a space (' ' U+0020) or number sign ('#' U+0023) occurring at
+ the beginning of the string;
+
+ - a space (' ' U+0020) character occurring at the end of the
+ string;
+
+ - one of the characters '"', '+', ',', ';', '<', '>', or '\'
+ (U+0022, U+002B, U+002C, U+003B, U+003C, U+003E, or U+005C
+ respectively);
+
+ - the null (U+0000) character.
+
+ Other characters may be escaped.
+
+ Each octet of the character to be escaped is replaced by a backslash
+ and two hex digits, which form a single octet in the code of the
+ character. Alternatively, if and only if the character to be escaped
+ is one of
+
+ ' ', '"', '#', '+', ',', ';', '<', '=', '>', or '\'
+ (U+0020, U+0022, U+0023, U+002B, U+002C, U+003B,
+ U+003C, U+003D, U+003E, U+005C respectively)
+
+ it can be prefixed by a backslash ('\' U+005C).
+
+ Examples of the escaping mechanism are shown in Section 4.
+
+
+3. Parsing a String back to a Distinguished Name
+
+ The string representation of Distinguished Names is restricted to
+ UTF-8 [RFC3629] encoded Unicode [Unicode] characters. The structure
+ of this string representation is specified using the following
+
+
+
+Zeilenga LDAP: Distinguished Names [Page 5]
+
+INTERNET-DRAFT draft-ietf-ldapbis-dn-16.txt 10 February 2005
+
+
+ Augmented BNF [RFC2234] grammar:
+
+ distinguishedName = [ relativeDistinguishedName
+ *( COMMA relativeDistinguishedName ) ]
+ relativeDistinguishedName = attributeTypeAndValue
+ *( PLUS attributeTypeAndValue )
+ attributeTypeAndValue = attributeType EQUALS attributeValue
+ attributeType = descr / numericoid
+ attributeValue = string / hexstring
+
+ ; The following characters are to be escaped when they appear
+ ; in the value to be encoded: ESC, one of <escaped>, leading
+ ; SHARP or SPACE, trailing SPACE, and NULL.
+ string = [ ( leadchar / pair ) [ *( stringchar / pair )
+ ( trailchar / pair ) ] ]
+
+ leadchar = LUTF1 / UTFMB
+ LUTF1 = %x01-1F / %x21 / %x24-2A / %x2D-3A /
+ %x3D / %x3F-5B / %x5D-7F
+
+ trailchar = TUTF1 / UTFMB
+ TUTF1 = %x01-1F / %x21 / %x23-2A / %x2D-3A /
+ %x3D / %x3F-5B / %x5D-7F
+
+ stringchar = SUTF1 / UTFMB
+ SUTF1 = %x01-21 / %x23-2A / %x2D-3A /
+ %x3D / %x3F-5B / %x5D-7F
+
+ pair = ESC ( ESC / special / hexpair )
+ special = escaped / SPACE / SHARP / EQUALS
+ escaped = DQUOTE / PLUS / COMMA / SEMI / LANGLE / RANGLE
+ hexstring = SHARP 1*hexpair
+ hexpair = HEX HEX
+
+ where the productions <descr>, <numericoid>, <COMMA>, <DQUOTE>,
+ <EQUALS>, <ESC>, <HEX>, <LANGLE>, <NULL>, <PLUS>, <RANGLE>, <SEMI>,
+ <SPACE>, <SHARP>, <UTFMB> are defined in [Models].
+
+ Each <attributeType>, either a <descr> or a <numericoid>, refers to an
+ attribute type of an attribute value assertion (AVA). The
+ <attributeType> is followed by a <EQUALS> and an <attributeValue>.
+ The <attributeValue> is either in <string> or <hexstring> form.
+
+ If in <string> form, a LDAP string representation asserted value can
+ be obtained by replacing (left-to-right, non-recursively) each <pair>
+ appearing in the <string> as follows:
+ replace <ESC><ESC> with <ESC>;
+ replace <ESC><special> with <special>;
+
+
+
+Zeilenga LDAP: Distinguished Names [Page 6]
+
+INTERNET-DRAFT draft-ietf-ldapbis-dn-16.txt 10 February 2005
+
+
+ replace <ESC><hexpair> with the octet indicated by the <hexpair>.
+
+ If in <hexstring> form, a BER representation can be obtained from
+ converting each <hexpair> of the <hexstring> to the octet indicated by
+ the <hexpair>.
+
+ One or more attribute values assertions, separated by <PLUS>, for a
+ relative distinguished name.
+
+ Zero or more relative distinguished names, separated by <COMMA>, for a
+ distinguished name.
+
+ Implementations MUST recognize AttributeType name strings
+ (descriptors) listed in the following table, but MAY recognize other
+ name strings.
+
+ String X.500 AttributeType
+ ------ --------------------------------------------
+ CN commonName (2.5.4.3)
+ L localityName (2.5.4.7)
+ ST stateOrProvinceName (2.5.4.8)
+ O organizationName (2.5.4.10)
+ OU organizationalUnitName (2.5.4.11)
+ C countryName (2.5.4.6)
+ STREET streetAddress (2.5.4.9)
+ DC domainComponent (0.9.2342.19200300.100.1.25)
+ UID userId (0.9.2342.19200300.100.1.1)
+
+ Implementations MAY recognize other DN string representations (such as
+ that described in RFC 1779). However, as there is no requirement that
+ alternative DN string representations to be recognized (and, if so,
+ how), implementations SHOULD only generate DN strings in accordance
+ with Section 2 of this document.
+
+
+4. Examples
+
+ This notation is designed to be convenient for common forms of name.
+ This section gives a few examples of distinguished names written using
+ this notation. First is a name containing three relative
+ distinguished names (RDNs):
+
+ UID=jsmith,DC=example,DC=net
+
+ Here is an example name containing three RDNs, in which the first RDN
+ is multi-valued:
+
+ OU=Sales+CN=J. Smith,DC=example,DC=net
+
+
+
+Zeilenga LDAP: Distinguished Names [Page 7]
+
+INTERNET-DRAFT draft-ietf-ldapbis-dn-16.txt 10 February 2005
+
+
+ This example shows the method of escaping of a special characters
+ appearing in a common name:
+
+ CN=James \"Jim\" Smith\, III,DC=example,DC=net
+
+ The following shows the method for encoding a value which contains a
+ carriage return character:
+
+ CN=Before\0dAfter,DC=example,DC=net
+
+ In this RDN example, the type in the RDN is unrecognized, and the
+ value is the BER encoding of an OCTET STRING containing two octets
+ 0x48 and 0x69.
+
+ 1.3.6.1.4.1.1466.0=#04024869
+
+ Finally, this example shows an RDN whose commonName value consisting
+ of 5 letters:
+
+ Unicode Character Code UTF-8 Escaped
+ ------------------------------- ------ ------ --------
+ LATIN CAPITAL LETTER L U+004C 0x4C L
+ LATIN SMALL LETTER U U+0075 0x75 u
+ LATIN SMALL LETTER C WITH CARON U+010D 0xC48D \C4\8D
+ LATIN SMALL LETTER I U+0069 0x69 i
+ LATIN SMALL LETTER C WITH ACUTE U+0107 0xC487 \C4\87
+
+ could be encoded in printable ASCII (useful for debugging purposes)
+ as:
+
+ CN=Lu\C4\8Di\C4\87
+
+
+5. Security Considerations
+
+ The following security considerations are specific to the handling of
+ distinguished names. LDAP security considerations are discussed in
+ [Protocol] and other documents comprising the LDAP Technical
+ Specification [Roadmap].
+
+
+5.1. Disclosure
+
+ Distinguished Names typically consist of descriptive information about
+ the entries they name, which can be people, organizations, devices or
+ other real-world objects. This frequently includes some of the
+ following kinds of information:
+
+
+
+
+Zeilenga LDAP: Distinguished Names [Page 8]
+
+INTERNET-DRAFT draft-ietf-ldapbis-dn-16.txt 10 February 2005
+
+
+ - the common name of the object (i.e. a person's full name)
+ - an email or TCP/IP address
+ - its physical location (country, locality, city, street address)
+ - organizational attributes (such as department name or affiliation)
+
+ In some cases, such information can be considered sensitive. In many
+ countries, privacy laws exist which prohibit disclosure of certain
+ kinds of descriptive information (e.g., email addresses). Hence,
+ servers implementors are encouraged to support DIT structural rules
+ and name forms [Models] as these provide a mechanism for
+ administrators to select appropriate naming attributes for entries.
+ Administrators are encouraged to use these mechanisms, access
+ controls, and other administrative controls which may be available to
+ restrict use of attributes containing sensitive information in naming
+ of entries. Additionally, use of authentication and data security
+ services in LDAP [AuthMeth][Protocol] should be considered.
+
+
+5.2. Use of Distinguished Names in Security Applications
+
+ The transformations of an AttributeValue value from its X.501 form to
+ an LDAP string representation are not always reversible back to the
+ same BER (Basic Encoding Rules) or DER (Distinguished Encoding rules)
+ form. An example of a situation which requires the DER form of a
+ distinguished name is the verification of an X.509 certificate.
+
+ For example, a distinguished name consisting of one RDN with one AVA,
+ in which the type is commonName and the value is of the TeletexString
+ choice with the letters 'Sam' would be represented in LDAP as the
+ string <CN=Sam>. Another distinguished name in which the value is
+ still 'Sam' but of the PrintableString choice would have the same
+ representation <CN=Sam>.
+
+ Applications which require the reconstruction of the DER form of the
+ value SHOULD NOT use the string representation of attribute syntaxes
+ when converting a distinguished name to the LDAP format. Instead,
+ they SHOULD use the hexadecimal form prefixed by the number sign ('#'
+ U+0023) as described in the first paragraph of Section 2.4.
+
+
+6. Acknowledgment
+
+ This document is an update to RFC 2253, by Mark Wahl, Tim Howes, and
+ Steve Kille. RFC 2253 was a product of the IETF ASID Working Group.
+
+ This document is a product of the IETF LDAPBIS Working Group.
+
+
+
+
+
+Zeilenga LDAP: Distinguished Names [Page 9]
+
+INTERNET-DRAFT draft-ietf-ldapbis-dn-16.txt 10 February 2005
+
+
+7. Document Editor's Address
+
+ Kurt D. Zeilenga
+ OpenLDAP Foundation
+
+ Email: Kurt at OpenLDAP.org
+
+
+8. References
+
+ [[Note to the RFC Editor: please replace the citation tags used in
+ referencing Internet-Drafts with tags of the form RFCnnnn where
+ possible.]]
+
+
+8.1. Normative References
+
+ [X.501] International Telecommunication Union -
+ Telecommunication Standardization Sector, "The Directory
+ -- Models," X.501(1993) (also ISO/IEC 9594-2:1994).
+
+ [X.680] International Telecommunication Union -
+ Telecommunication Standardization Sector, "Abstract
+ Syntax Notation One (ASN.1) - Specification of Basic
+ Notation", X.680(1997) (also ISO/IEC 8824-1:1998).
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14 (also RFC 2119), March 1997.
+
+ [RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
+ Specifications: ABNF", RFC 2234, November 1997.
+
+ [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
+ 10646", RFC 3629 (also STD 63), November 2003.
+
+ [Unicode] The Unicode Consortium, "The Unicode Standard, Version
+ 3.2.0" is defined by "The Unicode Standard, Version 3.0"
+ (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5),
+ as amended by the "Unicode Standard Annex #27: Unicode
+ 3.1" (http://www.unicode.org/reports/tr27/) and by the
+ "Unicode Standard Annex #28: Unicode 3.2"
+ (http://www.unicode.org/reports/tr28/).
+
+ [Models] Zeilenga, K. (editor), "LDAP: Directory Information
+ Models", draft-ietf-ldapbis-models-xx.txt, a work in
+ progress.
+
+ [Roadmap] Zeilenga, K. (editor), "LDAP: Technical Specification
+
+
+
+Zeilenga LDAP: Distinguished Names [Page 10]
+
+INTERNET-DRAFT draft-ietf-ldapbis-dn-16.txt 10 February 2005
+
+
+ Road Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in
+ progress.
+
+ [Protocol] Sermersheim, J. (editor), "LDAP: The Protocol",
+ draft-ietf-ldapbis-protocol-xx.txt, a work in progress.
+
+ [Syntaxes] Legg, S. (editor), "LDAP: Syntaxes and Matching Rules",
+ draft-ietf-ldapbis-syntaxes-xx.txt, a work in progress.
+
+ [Schema] Dally, K. (editor), "LDAP: User Schema",
+ draft-ietf-ldapbis-user-schema-xx.txt, a work in
+ progress.
+
+ [REGISTRY] IANA, Object Identifier Descriptors Registry,
+ <http://www.iana.org/...>.
+
+8.2. Informative References
+
+ [ASCII] Coded Character Set--7-bit American Standard Code for
+ Information Interchange, ANSI X3.4-1986.
+
+ [X.500] International Telecommunication Union -
+ Telecommunication Standardization Sector, "The Directory
+ -- Overview of concepts, models and services,"
+ X.500(1993) (also ISO/IEC 9594-1:1994).
+
+ [X.690] International Telecommunication Union -
+ Telecommunication Standardization Sector, "Specification
+ of ASN.1 encoding rules: Basic Encoding Rules (BER),
+ Canonical Encoding Rules (CER), and Distinguished
+ Encoding Rules (DER)", X.690(1997) (also ISO/IEC
+ 8825-1:1998).
+
+ [RFC2849] Good, G., "The LDAP Data Interchange Format (LDIF) -
+ Technical Specification", RFC 2849, June 2000.
+
+ [BCP64bis] Zeilenga, K., "IANA Considerations for LDAP",
+ draft-ietf-ldapbis-bcp64-xx.txt, a work in progress.
+
+ [CharModel] Whistler, K. and M. Davis, "Unicode Technical Report
+ #17, Character Encoding Model", UTR17,
+ <http://www.unicode.org/unicode/reports/tr17/>, August
+ 2000.
+
+ [Glossary] The Unicode Consortium, "Unicode Glossary",
+ <http://www.unicode.org/glossary/>.
+
+
+
+
+
+Zeilenga LDAP: Distinguished Names [Page 11]
+
+INTERNET-DRAFT draft-ietf-ldapbis-dn-16.txt 10 February 2005
+
+
+Appendix A. Presentation Issues
+
+ This appendix is provided for informational purposes only, it is not a
+ normative part of this specification.
+
+ The string representation described in this document is not intended
+ to be presented to humans without translation. However, at times it
+ may be desirable to present non-translated DN strings to users. This
+ section discusses presentation issues associated with non-translated
+ DN strings. Presentation of translated DN strings issues are not
+ discussed in this appendix. Transcoding issues are also not discussed
+ in this appendix.
+
+ This appendix provides guidance for applications presenting DN strings
+ to users. This section is not comprehensive, it does not discuss all
+ presentation issues which implementors may face.
+
+ Not all user interfaces are capable of displaying the full set of
+ Unicode characters. Some Unicode characters are not displayable.
+
+ It is recommended that human interfaces use the optional hex pair
+ escaping mechanism (Section 2.3) to produce a string representation
+ suitable for display to the user. For example, an application can
+ generate a DN string for display which escapes all non-printable
+ characters appearing in the AttributeValue's string representation (as
+ demonstrated in the final example of Section 4).
+
+ When a DN string is displayed in free form text, it is often necessary
+ to distinguish the DN string from surrounding text. While this is
+ often done with white space (as demonstrated in Section 4), it is
+ noted that DN strings may end with white space. Careful readers of
+ Section 3 will note that characters '<' (U+003C) and '>' (U+003E) may
+ only appear in the DN string if escaped. These characters are
+ intended to be used in free form text to distinguish a DN string from
+ surrounding text. For example, <CN=Sam\ > distinguished the string
+ representation of the DN comprised of one RDN consisting of the AVA:
+ the commonName (CN) value 'Sam ' from the surrounding text. It should
+ be noted to the user that the wrapping '<' and '>' characters are not
+ part of the DN string.
+
+ DN strings can be quite long. It is often desirable to line-wrap
+ overly long DN strings in presentations. Line wrapping should be done
+ by inserting white space after the RDN separator character or, if
+ necessary, after the AVA separator character. It should be noted to
+ the user that the inserted white space is not part of the DN string
+ and is to be removed before use in LDAP. For example,
+
+ The following DN string is long:
+
+
+
+Zeilenga LDAP: Distinguished Names [Page 12]
+
+INTERNET-DRAFT draft-ietf-ldapbis-dn-16.txt 10 February 2005
+
+
+ CN=Kurt D. Zeilenga,OU=Engineering,L=Redwood Shores,
+ O=OpenLDAP Foundation,ST=California,C=US
+ so it has been line-wrapped for readability. The extra white
+ space is to be removed before the DN string is used in LDAP.
+
+ It is not advised to insert white space otherwise as it may not be
+ obvious to the user which white space is part of the DN string and
+ which white space was added for readability.
+
+ Another alternative is to use the LDAP Data Interchange Format (LDIF)
+ [RFC2849]. For example,
+
+ # This entry has a long DN...
+ dn: CN=Kurt D. Zeilenga,OU=Engineering,L=Redwood Shores,
+ O=OpenLDAP Foundation,ST=California,C=US
+ CN: Kurt D. Zeilenga
+ SN: Zeilenga
+ objectClass: person
+
+
+Appendix B. Changes made since RFC 2253
+
+ This appendix is provided for informational purposes only, it is not a
+ normative part of this specification.
+
+ The following substantive changes were made to RFC 2253:
+ - Removed IESG Note. The IESG Note has been addressed.
+ - Replaced all references to ISO 10646-1 with [Unicode].
+ - Clarified (in Section 1) that this document does not define a
+ canonical string representation.
+ - Clarified that Section 2 describes the RECOMMENDED encoding
+ algorithm and that alternative algorithms are allowed. Some
+ encoding options described in RFC 2253 are now treated as
+ alternative algorithms in this specification.
+ - Revised specification (in Section 2) to allow short names of any
+ registered attribute type to appear in string representations of
+ DNs instead of being restricted to a "published table". Remove
+ "as an example" language. Added statement (in Section 3) allowing
+ recognition of additional names but require recognization of those
+ names in the published table. The table is now published in
+ Section 3.
+ - Removed specification of additional requirements for LDAPv2
+ implementations which also support LDAPv3 (RFC 2253, Section 4) as
+ LDAPv2 is now Historic.
+ - Allow recognition of alternative string representations.
+ - Updated Section 2.4 to allow hex pair escaping of all characters
+ and clarified escaping for when multiple octet UTF-8 encodings are
+ present. Indicated that null (U+0000) character is to be escaped.
+
+
+
+Zeilenga LDAP: Distinguished Names [Page 13]
+
+INTERNET-DRAFT draft-ietf-ldapbis-dn-16.txt 10 February 2005
+
+
+ Indicated that equals sign ('=' U+003D) character may be escaped
+ as '\='.
+ - Rewrote Section 3 to use ABNF as defined in RFC 2234.
+ - Updated the Section 3 ABNF. Changes include:
+ + allow AttributeType short names of length 1 (e.g., 'L'),
+ + use more restrictive <oid> production in AttributeTypes,
+ + do not require escaping of equals sign ('=' U+003D) characters,
+ + do not require escaping of non-leading number sign ('#' U+0023)
+ characters,
+ + allow space (' ' U+0020) to escaped as '\ ',
+ + require hex escaping of null (U+0000) characters, and
+ + removed LDAPv2-only constructs.
+ - Updated Section 3 to describe how to parse elements of the
+ grammar.
+ - Rewrote examples.
+ - Added reference to documentations containing general LDAP security
+ considerations.
+ - Added discussion of presentation issues (Appendix A).
+ - Added this appendix.
+
+ In addition, numerous editorial changes were made.
+
+
+Intellectual Property Rights
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be found
+ in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this specification
+ can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr at ietf.org.
+
+
+
+
+
+Zeilenga LDAP: Distinguished Names [Page 14]
+
+INTERNET-DRAFT draft-ietf-ldapbis-dn-16.txt 10 February 2005
+
+
+Full Copyright
+
+ Copyright (C) The Internet Society (2005). This document is subject
+ to the rights, licenses and restrictions contained in BCP 78, and
+ except as set forth therein, the authors retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga LDAP: Distinguished Names [Page 15]
+
+
Added: openldap/vendor/openldap-release/doc/drafts/draft-ietf-ldapbis-filter-xx.txt
===================================================================
--- openldap/vendor/openldap-release/doc/drafts/draft-ietf-ldapbis-filter-xx.txt (rev 0)
+++ openldap/vendor/openldap-release/doc/drafts/draft-ietf-ldapbis-filter-xx.txt 2007-09-15 10:38:52 UTC (rev 844)
@@ -0,0 +1,724 @@
+Network Working Group M. Smith, Editor
+Request for Comments: DRAFT Pearl Crescent, LLC
+Obsoletes: RFC 2254 T. Howes
+Expires: 16 May 2005 Opsware, Inc.
+ 16 November 2004
+
+
+ LDAP: String Representation of Search Filters
+ <draft-ietf-ldapbis-filter-09.txt>
+
+
+
+Status of this Memo
+
+ By submitting this Internet-Draft, each author represents that any
+ applicable patent or other IPR claims of which he or she is aware
+ have been or will be disclosed, and any of which he or she become
+ aware will be disclosed, in accordance with RFC 3668.
+
+ This document is intended to be published as a Standards Track RFC,
+ replacing RFC 2254. Distribution of this memo is unlimited.
+ Technical discussion of this document will take place on the IETF
+ LDAP (v3) Revision (ldapbis) Working Group mailing list
+ <ietf-ldapbis at openldap.org>. Please send editorial comments directly
+ to the editor <mcs at pearlcrescent.com>.
+
+ Internet-Drafts are working documents of the Internet Engineering
+ Task Force (IETF), its areas, and its working groups. Note that
+ other groups may also distribute working documents as
+ Internet-Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference
+ material or to cite them other than a "work in progress."
+
+ The list of current Internet-Drafts can be accessed at
+ http://www.ietf.org/1id-abstracts.html
+
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html
+
+ Copyright (C) The Internet Society (2004). All Rights Reserved.
+ Please see the Full Copyright section near the end of this document
+ for more information.
+
+
+
+
+
+
+Smith & Howes Intended Category: Standards Track [Page 1]
+
+INTERNET-DRAFT LDAP: String Repres. of Search Filters 16 November 2004
+
+
+Abstract
+
+ LDAP search filters are transmitted in the LDAP protocol using a
+ binary representation that is appropriate for use on the network.
+ This document defines a human-readable string representation of LDAP
+ search filters that is appropriate for use in LDAP URLs [LDAPURL] and
+ in other applications.
+
+Table of Contents
+
+ Status of this Memo............................................1
+ Abstract.......................................................2
+ Table of Contents..............................................2
+1. Introduction...................................................2
+2. LDAP Search Filter Definition..................................3
+3. String Search Filter Definition................................4
+4. Examples.......................................................6
+5. Security Considerations........................................7
+6. IANA Considerations............................................7
+7. Normative References...........................................7
+8. Informative References.........................................8
+9. Acknowledgments................................................8
+10. Authors' Addresses.............................................9
+11. Appendix A: Changes Since RFC 2254.............................9
+11.1. Technical Changes...........................................9
+11.2. Editorial Changes...........................................10
+12. Appendix B: Changes Since Previous Document Revision...........11
+12.1. Technical Changes...........................................11
+12.2. Editorial Changes...........................................12
+ Intellectual Property Rights...................................12
+ Full Copyright.................................................13
+
+1. Introduction
+
+ The Lightweight Directory Access Protocol (LDAP) [Roadmap] defines a
+ network representation of a search filter transmitted to an LDAP
+ server. Some applications may find it useful to have a common way of
+ representing these search filters in a human-readable form; LDAP URLs
+ are an example of one such application. This document defines a
+ human-readable string format for representing the full range of
+ possible LDAP version 3 search filters, including extended match
+ filters.
+
+ This document is a integral part of the LDAP technical specification
+ [Roadmap] which obsoletes the previously defined LDAP technical
+ specification, RFC 3377, in its entirety.
+
+
+
+
+
+Smith & Howes Intended Category: Standards Track [Page 2]
+
+INTERNET-DRAFT LDAP: String Repres. of Search Filters 16 November 2004
+
+
+ This document replaces RFC 2254. Changes to RFC 2254 are summarized
+ in Appendix A.
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in BCP 14 [RFC2119].
+
+2. LDAP Search Filter Definition
+
+ An LDAP search filter is defined in Section 4.5.1 of [Protocol] as
+ follows:
+
+ Filter ::= CHOICE {
+ and [0] SET SIZE (1..MAX) OF filter Filter,
+ or [1] SET SIZE (1..MAX) OF filter Filter,
+ not [2] Filter,
+ equalityMatch [3] AttributeValueAssertion,
+ substrings [4] SubstringFilter,
+ greaterOrEqual [5] AttributeValueAssertion,
+ lessOrEqual [6] AttributeValueAssertion,
+ present [7] AttributeDescription,
+ approxMatch [8] AttributeValueAssertion,
+ extensibleMatch [9] MatchingRuleAssertion }
+
+ SubstringFilter ::= SEQUENCE {
+ type AttributeDescription,
+ -- initial and final can occur at most once
+ substrings SEQUENCE SIZE (1..MAX) OF substring CHOICE {
+ initial [0] AssertionValue,
+ any [1] AssertionValue,
+ final [2] AssertionValue } }
+
+ AttributeValueAssertion ::= SEQUENCE {
+ attributeDesc AttributeDescription,
+ assertionValue AssertionValue }
+
+ MatchingRuleAssertion ::= SEQUENCE {
+ matchingRule [1] MatchingRuleId OPTIONAL,
+ type [2] AttributeDescription OPTIONAL,
+ matchValue [3] AssertionValue,
+ dnAttributes [4] BOOLEAN DEFAULT FALSE }
+
+ AttributeDescription ::= LDAPString
+ -- Constrained to <attributedescription>
+ -- [Models]
+
+ AttributeValue ::= OCTET STRING
+
+
+
+
+Smith & Howes Intended Category: Standards Track [Page 3]
+
+INTERNET-DRAFT LDAP: String Repres. of Search Filters 16 November 2004
+
+
+ MatchingRuleId ::= LDAPString
+
+ AssertionValue ::= OCTET STRING
+
+ LDAPString ::= OCTET STRING -- UTF-8 encoded,
+ -- [Unicode] characters
+
+ The AttributeDescription, as defined in [Protocol], is a string
+ representation of the attribute description that is discussed in
+ [Models]. The AttributeValue and AssertionValue OCTET STRING have
+ the form defined in [Syntaxes]. The Filter is encoded for
+ transmission over a network using the Basic Encoding Rules (BER)
+ defined in [X.690], with simplifications described in [Protocol].
+
+3. String Search Filter Definition
+
+ The string representation of an LDAP search filter is a string of
+ UTF-8 [RFC3629] encoded Unicode characters [Unicode] that is defined
+ by the following grammar, following the ABNF notation defined in
+ [RFC2234]. The productions used that are not defined here are
+ defined in section 1.4 (Common ABNF Productions) of [Models] unless
+ otherwise noted. The filter format uses a prefix notation.
+
+ filter = LPAREN filtercomp RPAREN
+ filtercomp = and / or / not / item
+ and = AMPERSAND filterlist
+ or = VERTBAR filterlist
+ not = EXCLAMATION filter
+ filterlist = 1*filter
+ item = simple / present / substring / extensible
+ simple = attr filtertype assertionvalue
+ filtertype = equal / approx / greaterorequal / lessorequal
+ equal = EQUALS
+ approx = TILDE EQUALS
+ greaterorequal = RANGLE EQUALS
+ lessorequal = LANGLE EQUALS
+ extensible = ( attr [dnattrs]
+ [matchingrule] COLON EQUALS assertionvalue )
+ / ( [dnattrs]
+ matchingrule COLON EQUALS assertionvalue )
+ present = attr EQUALS ASTERISK
+ substring = attr EQUALS [initial] any [final]
+ initial = assertionvalue
+ any = ASTERISK *(assertionvalue ASTERISK)
+ final = assertionvalue
+ attr = attributedescription
+ ; The attributedescription rule is defined in
+ ; Section 2.5 of [Models].
+
+
+
+Smith & Howes Intended Category: Standards Track [Page 4]
+
+INTERNET-DRAFT LDAP: String Repres. of Search Filters 16 November 2004
+
+
+ dnattrs = COLON "dn"
+ matchingrule = COLON oid
+ assertionvalue = valueencoding
+ ; The <valueencoding> rule is used to encode an <AssertionValue>
+ ; from Section 4.1.6 of [Protocol].
+ valueencoding = 0*(normal / escaped)
+ normal = UTF1SUBSET / UTFMB
+ escaped = ESC HEX HEX
+ UTF1SUBSET = %x01-27 / %x2B-5B / %x5D-7F
+ ; UTF1SUBSET excludes 0x00 (NUL), LPAREN,
+ ; RPAREN, ASTERISK, and ESC.
+ EXCLAMATION = %x21 ; exclamation mark ("!")
+ AMPERSAND = %x26 ; ampersand (or AND symbol) ("&")
+ ASTERISK = %x2A ; asterisk ("*")
+ COLON = %x3A ; colon (":")
+ VERTBAR = %x7C ; vertical bar (or pipe) ("|")
+ TILDE = %x7E ; tilde ("~")
+
+
+ Note that although both the <substring> and <present> productions in
+ the grammar above can produce the "attr=*" construct, this construct
+ is used only to denote a presence filter.
+
+ The <valueencoding> rule ensures that the entire filter string is a
+ valid UTF-8 string and provides that the octets that represent the
+ ASCII characters "*" (ASCII 0x2a), "(" (ASCII 0x28), ")" (ASCII
+ 0x29), "\" (ASCII 0x5c), and NUL (ASCII 0x00) are represented as a
+ backslash "\" (ASCII 0x5c) followed by the two hexadecimal digits
+ representing the value of the encoded octet.
+
+ This simple escaping mechanism eliminates filter-parsing ambiguities
+ and allows any filter that can be represented in LDAP to be
+ represented as a NUL-terminated string. Other octets that are part of
+ the <normal> set may be escaped using this mechanism, for example,
+ non-printing ASCII characters.
+
+ For AssertionValues that contain UTF-8 character data, each octet of
+ the character to be escaped is replaced by a backslash and two hex
+ digits, which form a single octet in the code of the character. For
+ example, the filter checking whether the "cn" attribute contained a
+ value with the character "*" anywhere in it would be represented as
+ "(cn=*\2a*)".
+
+ 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. Implementations SHOULD accept as input strings that
+ are not valid UTF-8 strings. This is necessary because RFC 2254 did
+
+
+
+Smith & Howes Intended Category: Standards Track [Page 5]
+
+INTERNET-DRAFT LDAP: String Repres. of Search Filters 16 November 2004
+
+
+ not clearly define the term "string representation" (and in
+ particular did not mention that the string representation of an LDAP
+ search filter is a string of UTF-8 encoded Unicode characters).
+
+4. Examples
+
+ This section gives a few examples of search filters written using
+ this notation.
+
+ (cn=Babs Jensen)
+ (!(cn=Tim Howes))
+ (&(objectClass=Person)(|(sn=Jensen)(cn=Babs J*)))
+ (o=univ*of*mich*)
+ (seeAlso=)
+
+ The following examples illustrate the use of extensible matching.
+
+ (cn:caseExactMatch:=Fred Flintstone)
+ (cn:=Betty Rubble)
+ (sn:dn:2.4.6.8.10:=Barney Rubble)
+ (o:dn:=Ace Industry)
+ (:1.2.3:=Wilma Flintstone)
+ (:DN:2.4.6.8.10:=Dino)
+
+ The first example shows use of the matching rule "caseExactMatch."
+
+ The second example demonstrates use of a MatchingRuleAssertion form
+ without a matchingRule.
+
+ The third example illustrates the use of the ":oid" notation to
+ indicate that matching rule identified by the OID "2.4.6.8.10" should
+ be used when making comparisons, and that the attributes of an
+ entry's distinguished name should be considered part of the entry
+ when evaluating the match (indicated by the use of ":dn").
+
+ The fourth example denotes an equality match, except that DN
+ components should be considered part of the entry when doing the
+ match.
+
+ 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 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.
+
+
+
+
+Smith & Howes Intended Category: Standards Track [Page 6]
+
+INTERNET-DRAFT LDAP: String Repres. of Search Filters 16 November 2004
+
+
+ The following examples illustrate the use of the escaping mechanism.
+
+ (o=Parens R Us \28for all your parenthetical needs\29)
+ (cn=*\2A*)
+ (filename=C:\5cMyFile)
+ (bin=\00\00\00\04)
+ (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
+ substring indicator. The third illustrates the escaping of the
+ backslash character.
+
+ The fourth example shows a filter searching for the four octet value
+ 00 00 00 04 (hex), illustrating the use of the escaping mechanism to
+ represent arbitrary data, including NUL characters.
+
+ The fifth example illustrates the use of the escaping mechanism to
+ represent various non-ASCII UTF-8 characters. Specifically, there are
+ 5 characters in the <assertionvalue> portion of this example: LATIN
+ CAPITAL LETTER L (U+004C), LATIN SMALL LETTER U (U+0075), LATIN SMALL
+ LETTER C WITH CARON (U+010D), LATIN SMALL LETTER I (U+0069), and
+ LATIN SMALL LETTER C WITH ACUTE (U+0107).
+
+ The sixth and final example demonstrates assertion of a BER encoded
+ value.
+
+5. Security Considerations
+
+ This memo describes a string representation of LDAP search filters.
+ While the representation itself has no known security implications,
+ LDAP search filters do. They are interpreted by LDAP servers to
+ select entries from which data is retrieved. LDAP servers should
+ take care to protect the data they maintain from unauthorized access.
+
+ Please refer to the Security Considerations sections of [Protocol]
+ and [AuthMeth] for more information.
+
+6. IANA Considerations
+
+ This document has no actions for IANA.
+
+7. Normative References
+
+[AuthMeth] Harrison, R. (editor), "LDAP: Authentication Methods and
+ Connection Level Security Mechanisms",
+
+
+
+Smith & Howes Intended Category: Standards Track [Page 7]
+
+INTERNET-DRAFT LDAP: String Repres. of Search Filters 16 November 2004
+
+
+ draft-ietf-ldapbis-authmeth-xx.txt, a work in progress.
+
+[Models] Zeilenga, K. (editor), "LDAP: Directory Information Models",
+ draft-ietf-ldapbis-models-xx.txt, a work in progress.
+
+[Protocol] draft-ietf-ldapbis-protocol-xx.txt, a work in progress.
+
+[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14 (also RFC 2119), March 1997.
+
+[RFC2234] Crocker, D., Overell, P., "Augmented BNF for Syntax
+ Specifications: ABNF", RFC 2234, November 1997.
+
+[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
+ RFC 3629, November 2003.
+
+[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.
+
+[Unicode] The Unicode Consortium, "The Unicode Standard, Version
+ 3.2.0" is defined by "The Unicode Standard, Version 3.0"
+ (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5), as
+ amended by the "Unicode Standard Annex #27: Unicode 3.1"
+ (http://www.unicode.org/reports/tr27/) and by the "Unicode
+ Standard Annex #28: Unicode 3.2."
+
+8. Informative References
+
+[LDAPURL] Smith, M. (editor), "LDAP: Uniform Resource Locator",
+ draft-ietf-ldapbis-url-xx.txt, a work in progress.
+
+[X.690] Specification of ASN.1 encoding rules: Basic, Canonical, and
+ Distinguished Encoding Rules, ITU-T Recommendation X.690,
+ 1994.
+
+9. Acknowledgments
+
+ This document replaces RFC 2254 by Tim Howes. RFC 2254 was a product
+ of the IETF ASID Working Group.
+
+ Changes included in this revised specification are based upon
+ discussions among the authors, discussions within the LDAP (v3)
+ Revision Working Group (ldapbis), and discussions within other IETF
+ Working Groups. The contributions of individuals in these working
+ groups is gratefully acknowledged.
+
+
+
+Smith & Howes Intended Category: Standards Track [Page 8]
+
+INTERNET-DRAFT LDAP: String Repres. of Search Filters 16 November 2004
+
+
+10. Authors' Addresses
+
+ Mark Smith, Editor
+ Pearl Crescent, LLC
+ 447 Marlpool Dr.
+ Saline, MI 48176
+ USA
+ +1 734 944-2856
+ mcs at pearlcrescent.com
+
+
+ Tim Howes
+ Opsware, Inc.
+ 599 N. Mathilda Ave.
+ Sunnyvale, CA 94085
+ USA
+ +1 408 744-7509
+ howes at opsware.com
+
+11. Appendix A: Changes Since RFC 2254
+
+11.1. Technical Changes
+
+ Replaced [ISO 10646] reference with [Unicode].
+
+ The following technical changes were made to the contents of the
+ "String Search Filter Definition" section:
+
+ Added statement that the string representation is a string of UTF-8
+ encoded Unicode characters.
+
+ Revised all of the ABNF to use common productions from [Models].
+
+ Replaced the "value" rule with a new "assertionvalue" rule within the
+ "simple", "extensible", and "substring" ("initial", "any", and
+ "final") rules. This matches a change made in [Syntaxes].
+
+ Added "(" and ")" around the components of the <extensible>
+ subproductions for clarity.
+
+ Revised the "attr", "matchingrule", and "assertionvalue" ABNF to more
+ precisely reference productions from the [Models] and [Protocol]
+ documents.
+
+ "String Search Filter Definition" section: replaced "greater" and
+ "less" with "greaterorequal" and "lessorequal" to avoid confusion.
+
+
+
+
+
+Smith & Howes Intended Category: Standards Track [Page 9]
+
+INTERNET-DRAFT LDAP: String Repres. of Search Filters 16 November 2004
+
+
+ Introduced the "valueencoding" and associated "normal" and "escaped"
+ rules to reduce the dependence on descriptive text. The "normal"
+ production restricts filter strings to valid UTF-8 sequences.
+
+ Added a statement about expected behavior in light of RFC 2254's lack
+ of a clear definition of "string representation."
+
+
+
+11.2. Editorial Changes
+
+ Changed document title to include "LDAP:" prefix.
+
+ IESG Note: removed note about lack of satisfactory mandatory
+ authentication mechanisms.
+
+ Header and "Authors' Addresses" sections: added Mark Smith as the
+ document editor and updated affiliation and contact information.
+
+ "Table of Contents", "IANA Considerations", and "Intellectual
+ Property Rights" sections: added.
+
+ 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
+ this document (instead of RFC 1960). Added reference to the [Roadmap]
+ document.
+
+ "LDAP Search Filter Definition" section: made corrections to the LDAP
+ search filter ABNF so it matches that used in [Protocol].
+
+ Clarified the definition of 'value' (now 'assertionvalue') to take
+ into account the fact that it is not precisely an AttributeAssertion
+ from [Protocol] section 4.1.6 (special handling is required for some
+ characters). Added a note that each octet of a character to be
+ escaped is replaced by a backslash and two hex digits, which
+ represent a single octet.
+
+ "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". Corrected the description of this
+ example: (sn:dn:2.4.6.8.10:=Barney Rubble). Replaced the numeric OID
+ in the first extensible match example with "caseExactMatch" to
+ demonstrate use of the descriptive form. Used "DN" (uppercase) in
+
+
+
+Smith & Howes Intended Category: Standards Track [Page 10]
+
+INTERNET-DRAFT LDAP: String Repres. of Search Filters 16 November 2004
+
+
+ the last extensible match example to remind the reader to treat the
+ <dnattrs> production as case insensitive. Reworded the description
+ of the fourth escaping mechanism example to avoid making assumptions
+ about byte order. Added text to the fifth escaping mechanism example
+ to spell out what the non-ASCII characters are in Unicode terms.
+
+ "Security Considerations" section: added references to [Protocol] and
+ [AuthMeth].
+
+ "Normative References" section: renamed from "References" per new RFC
+ guidelines. Changed from [1] style to [Protocol] style throughout the
+ document. Added entries for [Unicode], [RFC2119], [AuthMeth],
+ [Models], and [Roadmap] and updated the UTF-8 reference. Replaced
+ RFC 822 reference with a reference to RFC 2234.
+
+ "Informative References" section: (new section) moved [X.690] to this
+ section. Added a reference to [LDAPURL].
+
+ "Acknowledgments" section: added.
+
+ "Appendix A: Changes Since RFC 2254" section: added.
+
+ "Appendix B: Changes Since Previous Document Revision" section:
+ added.
+
+ Surrounded the names of all ABNF productions with "<" and ">" where
+ they are used in descriptive text.
+
+ Replaced all occurrences of "LDAPv3" with "LDAP."
+
+
+12. Appendix B: Changes Since Previous Document Revision
+
+ This appendix lists all changes relative to the previously published
+ revision, draft-ietf-ldapbis-filter-08.txt. Note that when
+ appropriate these changes are also included in Appendix A, but are
+ also included here for the benefit of the people who have already
+ reviewed draft-ietf-ldapbis-filter-08.txt. This section will be
+ removed before this document is published as an RFC.
+
+
+12.1. Technical Changes
+
+ Removed the third option from the "extensible" production that
+ allowed creation of a MatchingRuleAssertion that only had a
+ matchValue (disallowed By [Protocol]). Added "(" and ")" around the
+ components of the <extensible> subproductions for clarity.
+
+
+
+
+Smith & Howes Intended Category: Standards Track [Page 11]
+
+INTERNET-DRAFT LDAP: String Repres. of Search Filters 16 November 2004
+
+
+12.2. Editorial Changes
+
+ "Introduction" section: referenced [Roadmap] upon first use of LDAP
+ and expanded the paragraph that begins "This document is an integral
+ part of the LDAP technical specification..." to match the text used
+ in [Protocol].
+
+ "LDAP Search Filter Definition" section: reworded the last paragraph
+ for clarity.
+
+ "Examples" section: Replaced the numeric OID in the first extensible
+ match example with "caseExactMatch" to demonstrate use of the
+ descriptive form. Used "DN" (uppercase) in the last extensible match
+ example to remind the reader to treat the <dnattrs> production as
+ case insensitive. Reworded the description of the fourth escaping
+ mechanism example to avoid making assumptions about byte order.
+ Added text to the fifth escaping mechanism example to spell out what
+ the non-ASCII characters are in Unicode terms.
+
+ References: added [LDAPURL] and moved [X.690] to "Informative
+ References."
+
+ "Acknowledgements" section: added the sentence "RFC 2254 was a
+ product of the IETF ASID Working Group."
+
+ Changed these two sections to unnumbered ones: "Intellectual Property
+ Rights" and "Full Copyright."
+
+ Surrounded the names of all ABNF productions with "<" and ">" where
+ they are used in descriptive text.
+
+ Replaced all occurrences of "LDAPv3" with "LDAP."
+
+
+Intellectual Property Rights
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+
+
+
+Smith & Howes Intended Category: Standards Track [Page 12]
+
+INTERNET-DRAFT LDAP: String Repres. of Search Filters 16 November 2004
+
+
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr at ietf.org.
+
+Full Copyright
+
+ Copyright (C) The Internet Society (2004). This document is subject
+ to the rights, licenses and restrictions contained in BCP 78, and
+ except as set forth therein, the authors retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+This Internet Draft expires on 16 May 2005.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Smith & Howes Intended Category: Standards Track [Page 13]
\ No newline at end of file
Added: openldap/vendor/openldap-release/doc/drafts/draft-ietf-ldapbis-models-xx.txt
===================================================================
--- openldap/vendor/openldap-release/doc/drafts/draft-ietf-ldapbis-models-xx.txt (rev 0)
+++ openldap/vendor/openldap-release/doc/drafts/draft-ietf-ldapbis-models-xx.txt 2007-09-15 10:38:52 UTC (rev 844)
@@ -0,0 +1,2857 @@
+
+
+
+
+INTERNET-DRAFT Editor: Kurt D. Zeilenga
+Intended Category: Standard Track OpenLDAP Foundation
+Expires in six months 21 February 2005
+Obsoletes: RFC 2251, RFC 2252, RFC 2256, RFC 3674
+
+
+
+ LDAP: Directory Information Models
+ <draft-ietf-ldapbis-models-14.txt>
+
+
+
+Status of this Memo
+
+ This document is intended to be published as a Standard Track RFC.
+ Distribution of this memo is unlimited. Technical discussion of this
+ document will take place on the IETF LDAP Revision Working Group
+ mailing list <ietf-ldapbis at openldap.org>. Please send editorial
+ comments directly to the editor <Kurt at OpenLDAP.org>.
+
+ By submitting this Internet-Draft, I accept the provisions of Section
+ 4 of RFC 3667. By submitting this Internet-Draft, I certify that any
+ applicable patent or other IPR claims of which I am aware have been
+ disclosed, or will be disclosed, and any of which I become aware will
+ be disclosed, in accordance with RFC 3668.
+
+ Internet-Drafts are working documents of the Internet Engineering Task
+ Force (IETF), its areas, and its working groups. Note that other
+ groups may also distribute working documents as Internet-Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference material
+ or to cite them other than as "work in progress."
+
+ The list of current Internet-Drafts can be accessed at
+ http://www.ietf.org/1id-abstracts.html
+
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html
+
+
+ Copyright (C) The Internet Society (2005). All Rights Reserved.
+
+ Please see the Full Copyright section near the end of this document
+ for more information.
+
+
+
+
+
+Zeilenga LDAP Models [Page 1]
+
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
+Abstract
+
+ The Lightweight Directory Access Protocol (LDAP) is an Internet
+ protocol for accessing distributed directory services which act in
+ accordance with X.500 data and service models. This document
+ describes the X.500 Directory Information Models, as used in LDAP.
+
+Table of Contents
+
+ Status of this Memo 1
+ Abstract 2
+ Table of Contents
+ 1. Introduction 3
+ 1.1. Relationship to Other LDAP Specifications
+ 1.2. Relationship to X.501 4
+ 1.3. Conventions
+ 1.4. Common ABNF Productions
+ 2. Model of Directory User Information 6
+ 2.1. The Directory Information Tree 7
+ 2.2. Structure of an Entry
+ 2.3. Naming of Entries 8
+ 2.4. Object Classes 9
+ 2.5. Attribute Descriptions 12
+ 2.6. Alias Entries 16
+ 3. Directory Administrative and Operational Information 17
+ 3.1. Subtrees
+ 3.2. Subentries 18
+ 3.3. The 'objectClass' attribute
+ 3.4. Operational attributes 19
+ 4. Directory Schema 22
+ 4.1. Schema Definitions 23
+ 4.2. Subschema Subentries 32
+ 4.3. 'extensibleObject' 35
+ 4.4. Subschema Discovery 36
+ 5. DSA (Server) Informational Model
+ 5.1. Server-specific Data Requirements 37
+ 6. Other Considerations 40
+ 6.1. Preservation of User Information 41
+ 6.2. Short Names
+ 6.3. Cache and Shadowing
+ 7. Implementation Guidelines 42
+ 7.1. Server Guidelines
+ 7.2. Client Guidelines
+ 8. Security Considerations 43
+ 9. IANA Considerations
+ 10. Acknowledgments 44
+ 11. Editor's Address
+ 12. References
+
+
+
+Zeilenga LDAP Models [Page 2]
+
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
+ 12.1. Normative References 45
+ 12.2. Informative References
+ Appendix A. Changes
+ Intellectual Property Rights 51
+ Full Copyright
+
+
+1. Introduction
+
+ This document discusses the X.500 Directory Information Models
+ [X.501], as used by the Lightweight Directory Access Protocol (LDAP)
+ [Roadmap].
+
+ The Directory is "a collection of open systems cooperating to provide
+ directory services" [X.500]. The information held in the Directory is
+ collectively known as the Directory Information Base (DIB). A
+ Directory user, which may be a human or other entity, accesses the
+ Directory through a client (or Directory User Agent (DUA)). The
+ client, on behalf of the directory user, interacts with one or more
+ servers (or Directory System Agents (DSA)). A server holds a fragment
+ of the DIB.
+
+ The DIB contains two classes of information:
+
+ 1) user information (e.g., information provided and administrated
+ by users). Section 2 describes the Model of User Information.
+
+ 2) administrative and operational information (e.g., information
+ used to administer and/or operate the directory). Section 3
+ describes the model of Directory Administrative and Operational
+ Information.
+
+ These two models, referred to as the generic Directory Information
+ Models, describe how information is represented in the Directory.
+ These generic models provide a framework for other information models.
+ Section 4 discusses the subschema information model and subschema
+ discovery. Section 5 discusses the DSA (Server) Informational Model.
+
+ Other X.500 information models, such as access control distribution
+ knowledge, and replication knowledge information models, may be
+ adapted for use in LDAP. Specification of how these models apply to
+ LDAP is left to future documents.
+
+
+1.1. Relationship to Other LDAP Specifications
+
+ This document is a integral part of the LDAP technical specification
+ [Roadmap] which obsoletes the previously defined LDAP technical
+
+
+
+Zeilenga LDAP Models [Page 3]
+
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
+ specification, RFC 3377, in its entirety.
+
+ This document obsoletes RFC 2251 sections 3.2 and 3.4, as well as
+ portions of sections 4 and 6. Appendix A.1 summarizes changes to
+ these sections. The remainder of RFC 2251 is obsoleted by the
+ [Protocol], [AuthMeth], and [Roadmap] documents.
+
+ This document obsoletes RFC 2252 sections 4, 5 and 7. Appendix A.2
+ summarizes changes to these sections. The remainder of RFC 2252 is
+ obsoleted by [Syntaxes].
+
+ This document obsoletes RFC 2256 sections 5.1, 5.2, 7.1 and 7.2.
+ Appendix A.3 summarizes changes to these sections. The remainder of
+ RFC 2256 is obsoleted by [Schema] and [Syntaxes].
+
+ This document obsoletes RFC 3674 in its entirety. Appendix A.4
+ summarizes changes since RFC 3674.
+
+
+1.2. Relationship to X.501
+
+ This document includes material, with and without adaptation, from
+ [X.501] as necessary to describe this protocol. These adaptations
+ (and any other differences herein) apply to this protocol, and only
+ this protocol.
+
+
+1.3. Conventions
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in BCP 14 [RFC2119].
+
+ Schema definitions are provided using LDAP description formats (as
+ defined in Section 4.1). Definitions provided here are formatted
+ (line wrapped) for readability. Matching rules and LDAP syntaxes
+ referenced in these definitions are specified in [Syntaxes].
+
+
+1.4. Common ABNF Productions
+
+ A number of syntaxes in this document are described using Augmented
+ Backus-Naur Form (ABNF) [RFC2234]. These syntaxes (as well as a
+ number of syntaxes defined in other documents) rely on the following
+ common productions:
+
+ keystring = leadkeychar *keychar
+ leadkeychar = ALPHA
+
+
+
+Zeilenga LDAP Models [Page 4]
+
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
+ keychar = ALPHA / DIGIT / HYPHEN
+ number = DIGIT / ( LDIGIT 1*DIGIT )
+
+ ALPHA = %x41-5A / %x61-7A ; "A"-"Z" / "a"-"z"
+ DIGIT = %x30 / LDIGIT ; "0"-"9"
+ LDIGIT = %x31-39 ; "1"-"9"
+ HEX = DIGIT / %x41-46 / %x61-66 ; "0"-"9" / "A"-"F" / "a"-"f"
+
+ SP = 1*SPACE ; one or more " "
+ WSP = 0*SPACE ; zero or more " "
+
+ NULL = %x00 ; null (0)
+ SPACE = %x20 ; space (" ")
+ DQUOTE = %x22 ; quote (""")
+ SHARP = %x23 ; octothorpe (or sharp sign) ("#")
+ DOLLAR = %x24 ; dollar sign ("$")
+ SQUOTE = %x27 ; single quote ("'")
+ LPAREN = %x28 ; left paren ("(")
+ RPAREN = %x29 ; right paren (")")
+ PLUS = %x2B ; plus sign ("+")
+ COMMA = %x2C ; comma (",")
+ HYPHEN = %x2D ; hyphen ("-")
+ DOT = %x2E ; period (".")
+ SEMI = %x3B ; semicolon (";")
+ LANGLE = %x3C ; left angle bracket ("<")
+ EQUALS = %x3D ; equals sign ("=")
+ RANGLE = %x3E ; right angle bracket (">")
+ ESC = %x5C ; backslash ("\")
+ USCORE = %x5F ; underscore ("_")
+ LCURLY = %x7B ; left curly brace "{"
+ RCURLY = %x7D ; right curly brace "}"
+
+ ; Any UTF-8 [UTF-8] encoded Unicode [Unicode] character
+ UTF8 = UTF1 / UTFMB
+ UTFMB = UTF2 / UTF3 / UTF4
+ UTF0 = %x80-BF
+ UTF1 = %x00-7F
+ UTF2 = %xC2-DF UTF0
+ UTF3 = %xE0 %xA0-BF UTF0 / %xE1-EC 2(UTF0) /
+ %xED %x80-9F UTF0 / %xEE-EF 2(UTF0)
+ UTF4 = %xF0 %x90-BF 2(UTF0) / %xF1-F3 3(UTF0) /
+ %xF4 %x80-8F 2(UTF0)
+
+ OCTET = %x00-FF ; Any octet (8-bit data unit)
+
+ Object identifiers (OIDs) [X.680] are represented in LDAP using a
+ dot-decimal format conforming to the ABNF:
+
+
+
+
+Zeilenga LDAP Models [Page 5]
+
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
+ numericoid = number 1*( DOT number )
+
+ Short names, also known as descriptors, are used as more readable
+ aliases for object identifiers. Short names are case insensitive and
+ conform to the ABNF:
+
+ descr = keystring
+
+ Where either an object identifier or a short name may be specified,
+ the following production is used:
+
+ oid = descr / numericoid
+
+ While the <descr> form is generally preferred when the usage is
+ restricted to short names referring to object identifiers which
+ identify like kinds of objects (e.g., attribute type descriptions,
+ matching rule descriptions, object class descriptions), the
+ <numericoid> form should be used when the object identifiers may
+ identify multiple kinds of objects or when an unambiguous short name
+ (descriptor) is not available.
+
+ Implementations SHOULD treat short names (descriptors) used in an
+ ambiguous manner (as discussed above) as unrecognized.
+
+ Short Names (descriptors) are discussed further in Section 6.2.
+
+
+2. Model of Directory User Information
+
+ As [X.501] states:
+
+ The purpose of the Directory is to hold, and provide access to,
+ information about objects of interest (objects) in some 'world'.
+ An object can be anything which is identifiable (can be named).
+
+ An object class is an identified family of objects, or conceivable
+ objects, which share certain characteristics. Every object belongs
+ to at least one class. An object class may be a subclass of other
+ object classes, in which case the members of the former class, the
+ subclass, are also considered to be members of the latter classes,
+ the superclasses. There may be subclasses of subclasses, etc., to
+ an arbitrary depth.
+
+ A directory entry, a named collection of information, is the basic
+ unit of information held in the Directory. There are multiple kinds
+ of directory entries.
+
+ An object entry represents a particular object. An alias entry
+
+
+
+Zeilenga LDAP Models [Page 6]
+
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
+ provides alternative naming. A subentry holds administrative and/or
+ operational information.
+
+ The set of entries representing the DIB are organized hierarchically
+ in a tree structure known as the Directory Information Tree (DIT).
+
+ Section 2.1 describes the Directory Information Tree
+ Section 2.2 discusses the structure of entries.
+ Section 2.3 discusses naming of entries.
+ Section 2.4 discusses object classes.
+ Section 2.5 discusses attribute descriptions.
+ Section 2.6 discusses alias entries.
+
+
+2.1. The Directory Information Tree
+
+ As noted above, the DIB is composed of a set of entries organized
+ hierarchically in a tree structure known as the Directory Information
+ Tree (DIT). Specifically, a tree where vertices are the entries.
+
+ The arcs between vertices define relations between entries. If an arc
+ exists from X to Y, then the entry at X is the immediate superior of Y
+ and Y is the immediate subordinate of X. An entry's superiors are the
+ entry's immediate superior and its superiors. An entry's subordinates
+ are all of its immediate subordinates and their subordinates.
+
+ Similarly, the superior/subordinate relationship between object
+ entries can be used to derive a relation between the objects they
+ represent. DIT structure rules can be used to govern relationships
+ between objects.
+
+ Note: An entry's immediate superior is also known as the entry's
+ parent and an entry's immediate subordinate is also known as the
+ entry's child. Entries which have the same parent are known as
+ siblings.
+
+
+2.2. Structure of an Entry
+
+ An entry consists of a set of attributes which hold information about
+ the object which the entry represents. Some attributes represent user
+ information and are called user attributes. Other attributes
+ represent operational and/or administrative information and are called
+ operational attributes.
+
+ An attribute is an attribute description (a type and zero or more
+ options) with one or more associated values. An attribute is often
+ referred to by its attribute description. For example, the
+
+
+
+Zeilenga LDAP Models [Page 7]
+
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
+ 'givenName' attribute is the attribute which consists of the attribute
+ description 'givenName' (the 'givenName' attribute type [Schema] and
+ zero options) and one or more associated values.
+
+ The attribute type governs whether the attribute can have multiple
+ values, the syntax and matching rules used to construct and compare
+ values of that attribute, and other functions. Options indicate
+ subtypes and other functions.
+
+ Attribute values conform to the defined syntax of the attribute type.
+
+ No two values of an attribute may be equivalent. Two values are
+ considered equivalent if and only if they would match according to the
+ equality matching rule of the attribute type or, if the attribute type
+ is defined with no equality matching rule, two values are equivalent
+ if and only if they are identical. (See 2.5.1 for other
+ restrictions.)
+
+ For example, a 'givenName' attribute can have more than one value,
+ they must be Directory Strings, and they are case insensitive. A
+ 'givenName' attribute cannot hold both "John" and "JOHN" as these are
+ equivalent values per the equality matching rule of the attribute
+ type.
+
+ Additionally, no attribute is to have a value which is not equivalent
+ to itself. For example, the 'givenName' attribute cannot have as a
+ value a directory string which includes the REPLACEMENT CHARACTER
+ (U+FFFD) code point as matching involving that directory string is
+ Undefined per this attribute's equality matching rule.
+
+ When an attribute is used for naming of the entry, one and only one
+ value of the attribute is used in forming the Relative Distinguished
+ Name. This value is known as a distinguished value.
+
+
+2.3. Naming of Entries
+
+2.3.1. Relative Distinguished Names
+
+ Each entry is named relative to its immediate superior. This relative
+ name, known as its Relative Distinguished Name (RDN) [X.501], is
+ composed of an unordered set of one or more attribute value assertions
+ (AVA) consisting of an attribute description with zero options and an
+ attribute value. These AVAs are chosen to match attribute values
+ (each a distinguished value) of the entry.
+
+ An entry's relative distinguished name must be unique among all
+ immediate subordinates of the entry's immediate superior (i.e., all
+
+
+
+Zeilenga LDAP Models [Page 8]
+
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
+ siblings).
+
+ The following are examples of string representations of RDNs [LDAPDN]:
+
+ UID=12345
+ OU=Engineering
+ CN=Kurt Zeilenga+L=Redwood Shores
+
+ The last is an example of a multi-valued RDN. That is, an RDN
+ composed of multiple AVAs.
+
+
+2.3.2. Distinguished Names
+
+ An entry's fully qualified name, known as its Distinguished Name (DN)
+ [X.501], is the concatenation of its RDN and its immediate superior's
+ DN. A Distinguished Name unambiguously refers to an entry in the
+ tree. The following are examples of string representations of DNs
+ [LDAPDN]:
+
+ UID=nobody at example.com,DC=example,DC=com
+ CN=John Smith,OU=Sales,O=ACME Limited,L=Moab,ST=Utah,C=US
+
+
+2.3.3. Alias Names
+
+ An alias, or alias name, is "an name for an object, provided by the
+ use of alias entries" [X.501]. Alias entries are described in Section
+ 2.6.
+
+
+2.4. Object Classes
+
+ An object class is "an identified family of objects (or conceivable
+ objects) which share certain characteristics" [X.501].
+
+ As defined in [X.501]:
+
+ Object classes are used in the Directory for a number of purposes:
+
+ - describing and categorising objects and the entries that
+ correspond to these objects;
+
+ - where appropriate, controlling the operation of the Directory;
+
+ - regulating, in conjunction with DIT structure rule
+ specifications, the position of entries in the DIT;
+
+
+
+
+Zeilenga LDAP Models [Page 9]
+
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
+ - regulating, in conjunction with DIT content rule
+ specifications, the attributes that are contained in entries;
+
+ - identifying classes of entry that are to be associated with a
+ particular policy by the appropriate administrative authority.
+
+ An object class (a subclass) may be derived from an object class
+ (its direct superclass) which is itself derived from an even more
+ generic object class. For structural object classes, this process
+ stops at the most generic object class, 'top' (defined in Section
+ 2.4.1). An ordered set of superclasses up to the most superior
+ object class of an object class is its superclass chain.
+
+ An object class may be derived from two or more direct
+ superclasses (superclasses not part of the same superclass chain).
+ This feature of subclassing is termed multiple inheritance.
+
+ Each object class identifies the set of attributes required to be
+ present in entries belonging to the class and the set of attributes
+ allowed to be present in entries belonging to the class. As an entry
+ of a class must meet the requirements of each class it belongs to, it
+ can be said that an object class inherits the sets of allowed and
+ required attributes from its superclasses. A subclass can identify an
+ attribute allowed by its superclass as being required. If an
+ attribute is a member of both sets, it is required to be present.
+
+ Each object class is defined to be one of three kinds of object
+ classes: Abstract, Structural, or Auxiliary.
+
+ Each object class is identified by an object identifier (OID) and,
+ optionally, one or more short names (descriptors).
+
+
+2.4.1. Abstract Object Classes
+
+ An abstract object class, as the name implies, provides a base of
+ characteristics from which other object classes can be defined to
+ inherit from. An entry cannot belong to an abstract object class
+ unless it belongs to a structural or auxiliary class which inherits
+ from that abstract class.
+
+ Abstract object classes can not derive from structural nor auxiliary
+ object classes.
+
+ All structural object classes derive (directly or indirectly) from the
+ 'top' abstract object class. Auxiliary object classes do not
+ necessarily derive from 'top'.
+
+
+
+
+Zeilenga LDAP Models [Page 10]
+
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
+ The following is the object class definition (see Section 4.1.1) for
+ the 'top' object class:
+
+ ( 2.5.6.0 NAME 'top' ABSTRACT MUST objectClass )
+
+ All entries belong to the 'top' abstract object class.
+
+
+2.4.2. Structural Object Classes
+
+ As stated in [X.501]:
+
+ An object class defined for use in the structural specification of
+ the DIT is termed a structural object class. Structural object
+ classes are used in the definition of the structure of the names
+ of the objects for compliant entries.
+
+ An object or alias entry is characterised by precisely one
+ structural object class superclass chain which has a single
+ structural object class as the most subordinate object class.
+ This structural object class is referred to as the structural
+ object class of the entry.
+
+ Structural object classes are related to associated entries:
+
+ - an entry conforming to a structural object class shall
+ represent the real-world object constrained by the object
+ class;
+
+ - DIT structure rules only refer to structural object classes;
+ the structural object class of an entry is used to specify the
+ position of the entry in the DIT;
+
+ - the structural object class of an entry is used, along with an
+ associated DIT content rule, to control the content of an
+ entry.
+
+ The structural object class of an entry shall not be changed.
+
+ Each structural object class is a (direct or indirect) subclass of the
+ 'top' abstract object class.
+
+ Structural object classes cannot subclass auxiliary object classes.
+
+ Each entry is said to belong to its structural object class as well as
+ all classes in its structural object class's superclass chain.
+
+
+
+
+
+Zeilenga LDAP Models [Page 11]
+
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
+2.4.3. Auxiliary Object Classes
+
+ Auxiliary object classes are used to augment the characteristics of
+ entries. They are commonly used to augment the sets of attributes
+ required and allowed to be present in an entry. They can be used to
+ describe entries or classes of entries.
+
+ Auxiliary object classes cannot subclass structural object classes.
+
+ An entry can belong to any subset of the set of auxiliary object
+ classes allowed by the DIT content rule associated with the structural
+ object class of the entry. If no DIT content rule is associated with
+ the structural object class of the entry, the entry cannot belong to
+ any auxiliary object class.
+
+ The set of auxiliary object classes which an entry belongs to can
+ change over time.
+
+
+2.5. Attribute Descriptions
+
+ An attribute description is composed of an attribute type (see Section
+ 2.5.1) and a set of zero or more attribute options (see Section
+ 2.5.2).
+
+ An attribute description is represented by the ABNF:
+
+ attributedescription = attributetype options
+ attributetype = oid
+ options = *( SEMI option )
+ option = 1*keychar
+
+ where <attributetype> identifies the attribute type and each <option>
+ identifies an attribute option. Both <attributetype> and <option>
+ productions are case insensitive. The order in which <option>s appear
+ is irrelevant. That is, any two <attributedescription>s which consist
+ of the same <attributetype> and same set of <option>s are equivalent.
+
+ Examples of valid attribute descriptions:
+
+ 2.5.4.0
+ cn;lang-de;lang-en
+ owner
+
+ An attribute description with an unrecognized attribute type is to be
+ treated as unrecognized. Servers SHALL treat an attribute description
+ with an unrecognized attribute option as unrecognized. Clients MAY
+ treat an unrecognized attribute option as a tagging option (see
+
+
+
+Zeilenga LDAP Models [Page 12]
+
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
+ Section 2.5.2.1).
+
+ All attributes of an entry must have distinct attribute descriptions.
+
+
+2.5.1. Attribute Types
+
+ An attribute type governs whether the attribute can have multiple
+ values, the syntax and matching rules used to construct and compare
+ values of that attribute, and other functions.
+
+ If no equality matching is specified for the attribute type:
+ - the attribute (of the type) cannot be used for naming;
+ - when adding the attribute (or replacing all values), no two values
+ may be equivalent (see 2.2);
+ - individual values of a multi-valued attribute are not to be
+ independently added or deleted;
+ - attribute value assertions (such as matching in search filters and
+ comparisons) using values of such a type cannot be performed.
+
+ Otherwise, the specified equality matching rule is to be used for the
+ purposes of evaluating attribute value assertions concerning the
+ attribute type. The specified equality rule is to be transitive and
+ commutative.
+
+ The attribute type indicates whether the attribute is a user attribute
+ or an operational attribute. If operational, the attribute type
+ indicates the operational usage and whether the attribute is
+ modifiable by users or not. Operational attributes are discussed in
+ Section 3.4.
+
+ An attribute type (a subtype) may derive from a more generic attribute
+ type (a direct supertype). The following restrictions apply to
+ subtyping:
+ - a subtype must have the same usage as its direct supertype,
+ - a subtype's syntax must be the same, or a refinement of, its
+ supertype's syntax, and
+ - a subtype must be collective [RFC3671] if its supertype is
+ collective.
+
+ An attribute description consisting of a subtype and no options is
+ said to be the direct description subtype of the attribute description
+ consisting of the subtype's direct supertype and no options.
+
+ Each attribute type is identified by an object identifier (OID) and,
+ optionally, one or more short names (descriptors).
+
+
+
+
+
+Zeilenga LDAP Models [Page 13]
+
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
+2.5.2. Attribute Options
+
+ There are multiple kinds of attribute description options. The LDAP
+ technical specification details one kind: tagging options.
+
+ Not all options can be associated with attributes held in the
+ directory. Tagging options can be.
+
+ Not all options can be used in conjunction with all attribute types.
+ In such cases, the attribute description is to be treated as
+ unrecognized.
+
+ An attribute description that contains mutually exclusive options
+ shall be treated as unrecognized. That is, "cn;x-bar;x-foo", where
+ "x-foo" and "x-bar" are mutually exclusive, is to be treated as
+ unrecognized.
+
+ Other kinds of options may be specified in future documents. These
+ documents must detail how new kinds of options they define relate to
+ tagging options. In particular, these documents must detail whether
+ or not new kinds of options can be associated with attributes held in
+ the directory, how new kinds of options affect transfer of attribute
+ values, and how new kinds of options are treated in attribute
+ description hierarchies.
+
+ Options are represented as short case insensitive textual strings
+ conforming to the <option> production defined in Section 2.5 of this
+ document.
+
+ Procedures for registering options are detailed in BCP 64 [BCP64bis].
+
+
+2.5.2.1. Tagging Options
+
+ Attributes held in the directory can have attribute descriptions with
+ any number of tagging options. Tagging options are never mutually
+ exclusive.
+
+ An attribute description with N tagging options is a direct
+ (description) subtype of all attribute descriptions of the same
+ attribute type and all but one of the N options. If the attribute
+ type has a supertype, then the attribute description is also a direct
+ (description) subtype of the attribute description of the supertype
+ and the N tagging options. That is, 'cn;lang-de;lang-en' is a direct
+ (description) subtype of 'cn;lang-de', 'cn;lang-en', and
+ 'name;lang-de;lang-en' ('cn' is a subtype of 'name', both are defined
+ in [Schema]).
+
+
+
+
+Zeilenga LDAP Models [Page 14]
+
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
+2.5.3. Attribute Description Hierarchies
+
+ An attribute description can be the direct subtype of zero or more
+ other attribute descriptions as indicated by attribute type subtyping
+ (as described in Section 2.5.1) or attribute tagging option subtyping
+ (as described in Section 2.5.2.1). These subtyping relationships are
+ used to form hierarchies of attribute descriptions and attributes.
+
+ As adapted from [X.501]:
+
+ Attribute hierarchies allow access to the DIB with varying degrees
+ of granularity. This is achieved by allowing the value components
+ of attributes to be accessed by using either their specific
+ attribute description (a direct reference to the attribute) or by
+ a more generic attribute description (an indirect reference).
+
+ Semantically related attributes may be placed in a hierarchical
+ relationship, the more specialized being placed subordinate to the
+ more generalized. Searching for, or retrieving attributes and
+ their values is made easier by quoting the more generalized
+ attribute description; a filter item so specified is evaluated for
+ the more specialized descriptions as well as for the quoted
+ description.
+
+ Where subordinate specialized descriptions are selected to be
+ returned as part of a search result these descriptions shall be
+ returned if available. Where the more general descriptions are
+ selected to be returned as part of a search result both the
+ general and the specialized descriptions shall be returned, if
+ available. An attribute value shall always be returned as a value
+ of its own attribute description.
+
+ All of the attribute descriptions in an attribute hierarchy are
+ treated as distinct and unrelated descriptions for user
+ modification of entry content.
+
+ An attribute value stored in an object or alias entry is of
+ precisely one attribute description. The description is indicated
+ when the value is originally added to the entry.
+
+ For the purpose of subschema administration of the entry, a
+ specification that an attribute is required is fulfilled if the entry
+ contains a value of an attribute description belonging to an attribute
+ hierarchy where the attribute type of that description is the same as
+ the required attribute's type. That is, a "MUST name" specification
+ is fulfilled by 'name' or 'name;x-tag-option', but is not fulfilled by
+ 'CN' nor by 'CN;x-tag-option' (even though 'CN' is a subtype of
+ 'name'). Likewise, an entry may contain a value of an attribute
+
+
+
+Zeilenga LDAP Models [Page 15]
+
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
+ description belonging to an attribute hierarchy where the attribute
+ type of that description is either explicitly included in the
+ definition of an object class to which the entry belongs or allowed by
+ the DIT content rule applicable to that entry. That is, 'name' and
+ 'name;x-tag-option' are allowed by "MAY name" (or by "MUST name"), but
+ 'CN' and 'CN;x-tag-option' are not allowed by "MAY name" (nor by "MUST
+ name").
+
+ For the purposes of other policy administration, unless stated
+ otherwise in the specification of the particular administrative model,
+ all of the attribute descriptions in an attribute hierarchy are
+ treated as distinct and unrelated descriptions.
+
+
+2.6. Alias Entries
+
+ As adapted from [X.501]:
+
+ An alias, or an alias name, for an object is an alternative name
+ for an object or object entry which is provided by the use of
+ alias entries.
+
+ Each alias entry contains, within the 'aliasedObjectName'
+ attribute (known as the 'aliasedEntryName' attribute in X.500]), a
+ name of some object. The distinguished name of the alias entry is
+ thus also a name for this object.
+
+ NOTE - The name within the 'aliasedObjectName' is said to be
+ pointed to by the alias. It does not have to be the
+ distinguished name of any entry.
+
+ The conversion of an alias name to an object name is termed
+ (alias) dereferencing and comprises the systematic replacement of
+ alias names, where found within a purported name, by the value of
+ the corresponding 'aliasedObjectName' attribute. The process may
+ require the examination of more than one alias entry.
+
+ Any particular entry in the DIT may have zero or more alias names.
+ It therefore follows that several alias entries may point to the
+ same entry. An alias entry may point to an entry that is not a
+ leaf entry and may point to another alias entry.
+
+ An alias entry shall have no subordinates, so that an alias entry
+ is always a leaf entry.
+
+ Every alias entry shall belong to the 'alias' object class.
+
+ An entry with the 'alias' object class must also belong to an object
+
+
+
+Zeilenga LDAP Models [Page 16]
+
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
+ class (or classes), or be governed by a DIT content rule, which allows
+ suitable naming attributes to be present.
+
+ Example:
+ dn: cn=bar,dc=example,dc=com
+ objectClass: top
+ objectClass: alias
+ objectClass: extensibleObject
+ cn: bar
+ aliasedObjectName: cn=foo,dc=example,dc=com
+
+
+2.6.1. 'alias' object class
+
+ Alias entries belong to the 'alias' object class.
+
+ ( 2.5.6.1 NAME 'alias'
+ SUP top STRUCTURAL
+ MUST aliasedObjectName )
+
+
+2.6.2. 'aliasedObjectName' attribute type
+
+ The 'aliasedObjectName' attribute holds the name of the entry an alias
+ points to. The 'aliasedObjectName' attribute is known as the
+ 'aliasedEntryName' attribute in X.500.
+
+ ( 2.5.4.1 NAME 'aliasedObjectName'
+ EQUALITY distinguishedNameMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
+ SINGLE-VALUE )
+
+ The 'distinguishedNameMatch' matching rule and the DistinguishedName
+ (1.3.6.1.4.1.1466.115.121.1.12) syntax are defined in [Syntaxes].
+
+
+3. Directory Administrative and Operational Information
+
+ This section discusses select aspects of the X.500 Directory
+ Administrative and Operational Information model [X.501]. LDAP
+ implementations MAY support other aspects of this model.
+
+
+3.1. Subtrees
+
+ As defined in [X.501]:
+
+ A subtree is a collection of object and alias entries situated at
+
+
+
+Zeilenga LDAP Models [Page 17]
+
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
+ the vertices of a tree. Subtrees do not contain subentries. The
+ prefix sub, in subtree, emphasizes that the base (or root) vertex
+ of this tree is usually subordinate to the root of the DIT.
+
+ A subtree begins at some vertex and extends to some identifiable
+ lower boundary, possibly extending to leaves. A subtree is always
+ defined within a context which implicitly bounds the subtree. For
+ example, the vertex and lower boundaries of a subtree defining a
+ replicated area are bounded by a naming context.
+
+
+3.2. Subentries
+
+ A subentry is a "special sort of entry, known by the Directory, used
+ to hold information associated with a subtree or subtree refinement"
+ [X.501]. Subentries are used in Directory to hold for administrative
+ and operational purposes as defined in [X.501]. Their use in LDAP is
+ detailed in [RFC3672].
+
+ The term "(sub)entry" in this specification indicates that servers
+ implementing X.500(93) models are, in accordance with X.500(93) as
+ described in [RFC3672], to use a subentry and that other servers are
+ to use an object entry belonging to the appropriate auxiliary class
+ normally used with the subentry (e.g., 'subschema' for subschema
+ subentries) to mimic the subentry. This object entry's RDN SHALL be
+ formed from a value of the 'cn' (commonName) attribute [Schema] (as
+ all subentries are named with 'cn').
+
+
+3.3. The 'objectClass' attribute
+
+ Each entry in the DIT has an 'objectClass' attribute.
+
+ ( 2.5.4.0 NAME 'objectClass'
+ EQUALITY objectIdentifierMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
+
+ The 'objectIdentifierMatch' matching rule and the OBJECT IDENTIFIER
+ (1.3.6.1.4.1.1466.115.121.1.38) syntax are defined in [Syntaxes].
+
+ The 'objectClass' attribute specifies the object classes of an entry,
+ which (among other things) is used in conjunction with the controlling
+ schema to determine the permitted attributes of an entry. Values of
+ this attribute can be modified by clients, but the 'objectClass'
+ attribute cannot be removed.
+
+ Servers which follow X.500(93) models SHALL restrict modifications of
+ this attribute to prevent the basic structural class of the entry from
+
+
+
+Zeilenga LDAP Models [Page 18]
+
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
+ being changed. That is, one cannot change a 'person' into a
+ 'country'.
+
+ When creating an entry or adding an 'objectClass' value to an entry,
+ all superclasses of the named classes SHALL be implicitly added as
+ well if not already present. That is, if the auxiliary class 'x-a' is
+ a subclass of the class 'x-b', adding 'x-a' to 'objectClass' causes
+ 'x-b' to be implicitly added (if is not already present).
+
+ Servers SHALL restrict modifications of this attribute to prevent
+ superclasses of remaining 'objectClass' values from being deleted.
+ That is, if the auxiliary class 'x-a' is a subclass of the auxiliary
+ class 'x-b' and the 'objectClass' attribute contains 'x-a' and 'x-b',
+ an attempt to delete only 'x-b' from the 'objectClass' attribute is an
+ error.
+
+
+3.4. Operational attributes
+
+ Some attributes, termed operational attributes, are used or maintained
+ by servers for administrative and operational purposes. As stated in
+ [X.501]: "There are three varieties of operational attributes:
+ Directory operational attributes, DSA-shared operational attributes,
+ and DSA-specific operational attributes."
+
+ A directory operational attribute is used to represent operational
+ and/or administrative information in the Directory Information Model.
+ This includes operational attributes maintained by the server (e.g.
+ 'createTimestamp') as well as operational attributes which hold values
+ administrated by the user (e.g. 'ditContentRules').
+
+ A DSA-shared operational attribute is used to represent information of
+ the DSA Information Model which is shared between DSAs.
+
+ A DSA-specific operational attribute is used to represent information
+ of the DSA Information Model which is specific to the DSA (though, in
+ some cases, may be derived from information shared between DSAs)
+ (e.g., 'namingContexts').
+
+ The DSA Information Model operational attributes are detailed in
+ [X.501].
+
+ Operational attributes are not normally visible. They are not
+ returned in search results unless explicitly requested by name.
+
+ Not all operational attributes are user modifiable.
+
+ Entries may contain, among others, the following operational
+
+
+
+Zeilenga LDAP Models [Page 19]
+
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
+ attributes:
+
+ - creatorsName: the Distinguished Name of the user who added this
+ entry to the directory,
+
+ - createTimestamp: the time this entry was added to the directory,
+
+ - modifiersName: the Distinguished Name of the user who last
+ modified this entry, and
+
+ - modifyTimestamp: the time this entry was last modified.
+
+ Servers SHOULD maintain the 'creatorsName', 'createTimestamp',
+ 'modifiersName', and 'modifyTimestamp' attributes for all entries of
+ the DIT.
+
+
+3.4.1. 'creatorsName'
+
+ This attribute appears in entries which were added using the protocol
+ (e.g., using the Add operation). The value is the distinguished name
+ of the creator.
+
+ ( 2.5.18.3 NAME 'creatorsName'
+ EQUALITY distinguishedNameMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
+ SINGLE-VALUE NO-USER-MODIFICATION
+ USAGE directoryOperation )
+
+ The 'distinguishedNameMatch' matching rule and the DistinguishedName
+ (1.3.6.1.4.1.1466.115.121.1.12) syntax are defined in [Syntaxes].
+
+
+3.4.2. 'createTimestamp'
+
+ This attribute appears in entries which were added using the protocol
+ (e.g., using the Add operation). The value is the time the entry was
+ added.
+
+ ( 2.5.18.1 NAME 'createTimestamp'
+ EQUALITY generalizedTimeMatch
+ ORDERING generalizedTimeOrderingMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
+ SINGLE-VALUE NO-USER-MODIFICATION
+ USAGE directoryOperation )
+
+ The 'generalizedTimeMatch' and 'generalizedTimeOrderingMatch' matching
+ rules and the GeneralizedTime (1.3.6.1.4.1.1466.115.121.1.24) syntax
+
+
+
+Zeilenga LDAP Models [Page 20]
+
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
+ are defined in [Syntaxes].
+
+
+3.4.3. 'modifiersName'
+
+ This attribute appears in entries which have been modified using the
+ protocol (e.g., using Modify operation). The value is the
+ distinguished name of the last modifier.
+
+ ( 2.5.18.4 NAME 'modifiersName'
+ EQUALITY distinguishedNameMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
+ SINGLE-VALUE NO-USER-MODIFICATION
+ USAGE directoryOperation )
+
+ The 'distinguishedNameMatch' matching rule and the DistinguishedName
+ (1.3.6.1.4.1.1466.115.121.1.12) syntax are defined in [Syntaxes].
+
+
+3.4.4. 'modifyTimestamp'
+
+ This attribute appears in entries which have been modified using the
+ protocol (e.g., using the Modify operation). The value is the time
+ the entry was last modified.
+
+ ( 2.5.18.2 NAME 'modifyTimestamp'
+ EQUALITY generalizedTimeMatch
+ ORDERING generalizedTimeOrderingMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
+ SINGLE-VALUE NO-USER-MODIFICATION
+ USAGE directoryOperation )
+
+ The 'generalizedTimeMatch' and 'generalizedTimeOrderingMatch' matching
+ rules and the GeneralizedTime (1.3.6.1.4.1.1466.115.121.1.24) syntax
+ are defined in [Syntaxes].
+
+
+3.4.5. 'structuralObjectClass'
+
+ This attribute indicates the structural object class of the entry.
+
+ ( 2.5.21.9 NAME 'structuralObjectClass'
+ EQUALITY objectIdentifierMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
+ SINGLE-VALUE NO-USER-MODIFICATION
+ USAGE directoryOperation )
+
+ The 'objectIdentifierMatch' matching rule and OBJECT IDENTIFIER
+
+
+
+Zeilenga LDAP Models [Page 21]
+
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
+ (1.3.6.1.4.1.1466.115.121.1.38) syntax is defined in [Syntaxes].
+
+
+3.4.6. 'governingStructureRule'
+
+ This attribute indicates the structure rule governing the entry.
+
+ ( 2.5.21.10 NAME 'governingStructureRule'
+ EQUALITY integerMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
+ SINGLE-VALUE NO-USER-MODIFICATION
+ USAGE directoryOperation )
+
+ The 'integerMatch' matching rule and INTEGER
+ (1.3.6.1.4.1.1466.115.121.1.27) syntax is defined in [Syntaxes].
+
+
+4. Directory Schema
+
+ As defined in [X.501]:
+
+ The Directory Schema is a set of definitions and constraints
+ concerning the structure of the DIT, the possible ways entries are
+ named, the information that can be held in an entry, the
+ attributes used to represent that information and their
+ organization into hierarchies to facilitate search and retrieval
+ of the information and the ways in which values of attributes may
+ be matched in attribute value and matching rule assertions.
+
+ NOTE 1 - The schema enables the Directory system to, for example:
+
+ - prevent the creation of subordinate entries of the wrong
+ object-class (e.g. a country as a subordinate of a person);
+
+ - prevent the addition of attribute-types to an entry
+ inappropriate to the object-class (e.g. a serial number to a
+ person's entry);
+
+ - prevent the addition of an attribute value of a syntax not
+ matching that defined for the attribute-type (e.g. a printable
+ string to a bit string).
+
+ Formally, the Directory Schema comprises a set of:
+
+ a) Name Form definitions that define primitive naming relations
+ for structural object classes;
+
+ b) DIT Structure Rule definitions that define the names that
+
+
+
+Zeilenga LDAP Models [Page 22]
+
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
+ entries may have and the ways in which the entries may be
+ related to one another in the DIT;
+
+ c) DIT Content Rule definitions that extend the specification of
+ allowable attributes for entries beyond those indicated by the
+ structural object classes of the entries;
+
+ d) Object Class definitions that define the basic set of mandatory
+ and optional attributes that shall be present, and may be
+ present, respectively, in an entry of a given class, and which
+ indicate the kind of object class that is being defined;
+
+ e) Attribute Type definitions that identify the object identifier
+ by which an attribute is known, its syntax, associated matching
+ rules, whether it is an operational attribute and if so its
+ type, whether it is a collective attribute, whether it is
+ permitted to have multiple values and whether or not it is
+ derived from another attribute type;
+
+ f) Matching Rule definitions that define matching rules.
+
+ And in LDAP:
+
+ g) LDAP Syntax definitions that define encodings used in LDAP.
+
+
+4.1. Schema Definitions
+
+ Schema definitions in this section are described using ABNF and rely
+ on the common productions specified in Section 1.2 as well as these:
+
+ noidlen = numericoid [ LCURLY len RCURLY ]
+ len = number
+
+ oids = oid / ( LPAREN WSP oidlist WSP RPAREN )
+ oidlist = oid *( WSP DOLLAR WSP oid )
+
+ extensions = *( SP xstring SP qdstrings )
+ xstring = "X" HYPHEN 1*( ALPHA / HYPHEN / USCORE )
+
+ qdescrs = qdescr / ( LPAREN WSP qdescrlist WSP RPAREN )
+ qdescrlist = [ qdescr *( SP qdescr ) ]
+ qdescr = SQUOTE descr SQUOTE
+
+ qdstrings = qdstring / ( LPAREN WSP qdstringlist WSP RPAREN )
+ qdstringlist = [ qdstring *( SP qdstring ) ]
+ qdstring = SQUOTE dstring SQUOTE
+ dstring = 1*( QS / QQ / QUTF8 ) ; escaped UTF-8 string
+
+
+
+Zeilenga LDAP Models [Page 23]
+
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
+ QQ = ESC %x32 %x37 ; "\27"
+ QS = ESC %x35 ( %x43 / %x63 ) ; "\5C" / "\5c"
+
+ ; Any UTF-8 encoded Unicode character
+ ; except %x27 ("'") and %x5C ("\")
+ QUTF8 = QUTF1 / UTFMB
+
+ ; Any ASCII character except %x27 ("'") and %x5C ("\")
+ QUTF1 = %x00-26 / %x28-5B / %x5D-7F
+
+ Schema definitions in this section also share a number of common
+ terms.
+
+ The NAME field provides a set of short names (descriptors) which are
+ to be used as aliases for the OID.
+
+ The DESC field optionally allows a descriptive string to be provided
+ by the directory administrator and/or implementor. While
+ specifications may suggest a descriptive string, there is no
+ requirement that the suggested (or any) descriptive string be used.
+
+ The OBSOLETE field, if present, indicates the element is not active.
+
+ Implementors should note that future versions of this document may
+ expand these definitions to include additional terms. Terms whose
+ identifier begins with "X-" are reserved for private experiments, and
+ are followed by <SP> and <qdstrings> tokens.
+
+
+4.1.1. Object Class Definitions
+
+ Object Class definitions are written according to the ABNF:
+
+ ObjectClassDescription = LPAREN WSP
+ numericoid ; object identifier
+ [ SP "NAME" SP qdescrs ] ; short names (descriptors)
+ [ SP "DESC" SP qdstring ] ; description
+ [ SP "OBSOLETE" ] ; not active
+ [ SP "SUP" SP oids ] ; superior object classes
+ [ SP kind ] ; kind of class
+ [ SP "MUST" SP oids ] ; attribute types
+ [ SP "MAY" SP oids ] ; attribute types
+ extensions WSP RPAREN
+
+ kind = "ABSTRACT" / "STRUCTURAL" / "AUXILIARY"
+
+ where:
+ <numericoid> is object identifier assigned to this object class;
+
+
+
+Zeilenga LDAP Models [Page 24]
+
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
+ NAME <qdescrs> are short names (descriptors) identifying this object
+ class;
+ DESC <qdstring> is a short descriptive string;
+ OBSOLETE indicates this object class is not active;
+ SUP <oids> specifies the direct superclasses of this object class;
+ the kind of object class is indicated by one of ABSTRACT,
+ STRUCTURAL, or AUXILIARY, default is STRUCTURAL;
+ MUST and MAY specify the sets of required and allowed attribute
+ types, respectively; and
+ <extensions> describe extensions.
+
+
+4.1.2. Attribute Types
+
+ Attribute Type definitions are written according to the ABNF:
+
+ AttributeTypeDescription = LPAREN WSP
+ numericoid ; object identifier
+ [ SP "NAME" SP qdescrs ] ; short names (descriptors)
+ [ SP "DESC" SP qdstring ] ; description
+ [ SP "OBSOLETE" ] ; not active
+ [ SP "SUP" SP oid ] ; supertype
+ [ SP "EQUALITY" SP oid ] ; equality matching rule
+ [ SP "ORDERING" SP oid ] ; ordering matching rule
+ [ SP "SUBSTR" SP oid ] ; substrings matching rule
+ [ SP "SYNTAX" SP noidlen ] ; value syntax
+ [ SP "SINGLE-VALUE" ] ; single-value
+ [ SP "COLLECTIVE" ] ; collective
+ [ SP "NO-USER-MODIFICATION" ] ; not user modifiable
+ [ SP "USAGE" SP usage ] ; usage
+ extensions WSP RPAREN ; extensions
+
+ usage = "userApplications" / ; user
+ "directoryOperation" / ; directory operational
+ "distributedOperation" / ; DSA-shared operational
+ "dSAOperation" ; DSA-specific operational
+
+ where:
+ <numericoid> is object identifier assigned to this attribute type;
+ NAME <qdescrs> are short names (descriptors) identifying this
+ attribute type;
+ DESC <qdstring> is a short descriptive string;
+ OBSOLETE indicates this attribute type is not active;
+ SUP oid specifies the direct supertype of this type;
+ EQUALITY, ORDERING, SUBSTR provide the oid of the equality,
+ ordering, and substrings matching rules, respectively;
+ SYNTAX identifies value syntax by object identifier and may suggest
+ a minimum upper bound;
+
+
+
+Zeilenga LDAP Models [Page 25]
+
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
+ SINGLE-VALUE indicates attributes of this type are restricted to a
+ single value;
+ COLLECTIVE indicates this attribute type is collective
+ [X.501][RFC3671];
+ NO-USER-MODIFICATION indicates this attribute type is not user
+ modifiable;
+ USAGE indicates the application of this attribute type; and
+ <extensions> describe extensions.
+
+ Each attribute type description must contain at least one of the SUP
+ or SYNTAX fields. If no SYNTAX field is provided, the attribute type
+ description takes its value from the supertype.
+
+ If SUP field is provided, the EQUALITY, ORDERING, and SUBSTRING
+ fields, if not specified, take their value from the supertype.
+
+ Usage of userApplications, the default, indicates that attributes of
+ this type represent user information. That is, they are user
+ attributes.
+
+ A usage of directoryOperation, distributedOperation, or dSAOperation
+ indicates that attributes of this type represent operational and/or
+ administrative information. That is, they are operational attributes.
+
+ directoryOperation usage indicates that the attribute of this type is
+ a directory operational attribute. distributedOperation usage
+ indicates that the attribute of this DSA-shared usage operational
+ attribute. dSAOperation usage indicates that the attribute of this
+ type is a DSA-specific operational attribute.
+
+ COLLECTIVE requires usage userApplications. Use of collective
+ attribute types in LDAP is discussed in [RFC3671].
+
+ NO-USER-MODIFICATION requires an operational usage.
+
+ Note that the <AttributeTypeDescription> does not list the matching
+ rules which can be used with that attribute type in an extensibleMatch
+ search filter [Protocol]. This is done using the 'matchingRuleUse'
+ attribute described in Section 4.1.4.
+
+ This document refines the schema description of X.501 by requiring
+ that the SYNTAX field in an <AttributeTypeDescription> be a string
+ representation of an object identifier for the LDAP string syntax
+ definition with an optional indication of the suggested minimum bound
+ of a value of this attribute.
+
+ A suggested minimum upper bound on the number of characters in a value
+ with a string-based syntax, or the number of bytes in a value for all
+
+
+
+Zeilenga LDAP Models [Page 26]
+
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
+ other syntaxes, may be indicated by appending this bound count inside
+ of curly braces following the syntax's OBJECT IDENTIFIER in an
+ Attribute Type Description. This bound is not part of the syntax name
+ itself. For instance, "1.3.6.4.1.1466.0{64}" suggests that server
+ implementations should allow a string to be 64 characters long,
+ although they may allow longer strings. Note that a single character
+ of the Directory String syntax may be encoded in more than one octet
+ since UTF-8 [RFC3629] is a variable-length encoding.
+
+
+4.1.3. Matching Rules
+
+ Matching rules are used in performance of attribute value assertions,
+ such as in performance of a Compare operation. They are also used in
+ evaluation of a Search filters, in determining which individual values
+ are be added or deleted during performance of a Modify operation, and
+ used in comparison of distinguished names.
+
+ Each matching rule is identified by an object identifier (OID) and,
+ optionally, one or more short names (descriptors).
+
+ Matching rule definitions are written according to the ABNF:
+
+ MatchingRuleDescription = LPAREN WSP
+ numericoid ; object identifier
+ [ SP "NAME" SP qdescrs ] ; short names (descriptors)
+ [ SP "DESC" SP qdstring ] ; description
+ [ SP "OBSOLETE" ] ; not active
+ SP "SYNTAX" SP numericoid ; assertion syntax
+ extensions WSP RPAREN ; extensions
+
+ where:
+ <numericoid> is object identifier assigned to this matching rule;
+ NAME <qdescrs> are short names (descriptors) identifying this
+ matching rule;
+ DESC <qdstring> is a short descriptive string;
+ OBSOLETE indicates this matching rule is not active;
+ SYNTAX identifies the assertion syntax (the syntax of the assertion
+ value) by object identifier; and
+ <extensions> describe extensions.
+
+
+4.1.4. Matching Rule Uses
+
+ A matching rule use lists the attribute types which are suitable for
+ use with an extensibleMatch search filter.
+
+ Matching rule use descriptions are written according to the following
+
+
+
+Zeilenga LDAP Models [Page 27]
+
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
+ ABNF:
+
+ MatchingRuleUseDescription = LPAREN WSP
+ numericoid ; object identifier
+ [ SP "NAME" SP qdescrs ] ; short names (descriptors)
+ [ SP "DESC" SP qdstring ] ; description
+ [ SP "OBSOLETE" ] ; not active
+ SP "APPLIES" SP oids ; attribute types
+ extensions WSP RPAREN ; extensions
+
+ where:
+ <numericoid> is the object identifier of the matching rule
+ associated with this matching rule use description;
+ NAME <qdescrs> are short names (descriptors) identifying this
+ matching rule use;
+ DESC <qdstring> is a short descriptive string;
+ OBSOLETE indicates this matching rule use is not active;
+ APPLIES provides a list of attribute types the matching rule applies
+ to; and
+ <extensions> describe extensions.
+
+
+4.1.5. LDAP Syntaxes
+
+ LDAP Syntaxes of (attribute and assertion) values are described in
+ terms of ASN.1 [X.680] and, optionally, have an octet string encoding
+ known as the LDAP-specific encoding. Commonly, the LDAP-specific
+ encoding is constrained to a string of Unicode [Unicode] characters in
+ UTF-8 [RFC3629] form.
+
+ Each LDAP syntax is identified by an object identifier (OID).
+
+ LDAP syntax definitions are written according to the ABNF:
+
+ SyntaxDescription = LPAREN WSP
+ numericoid ; object identifier
+ [ SP "DESC" SP qdstring ] ; description
+ extensions WSP RPAREN ; extensions
+
+ where:
+ <numericoid> is the object identifier assigned to this LDAP syntax;
+ DESC <qdstring> is a short descriptive string; and
+ <extensions> describe extensions.
+
+
+4.1.6. DIT Content Rules
+
+ A DIT content rule is a "rule governing the content of entries of a
+
+
+
+Zeilenga LDAP Models [Page 28]
+
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
+ particular structural object class" [X.501].
+
+ For DIT entries of a particular structural object class, a DIT content
+ rule specifies which auxiliary object classes the entries are allowed
+ to belong to and which additional attributes (by type) are required,
+ allowed or not allowed to appear in the entries.
+
+ The list of precluded attributes cannot include any attribute listed
+ as mandatory in the rule, the structural object class, or any of the
+ allowed auxiliary object classes.
+
+ Each content rule is identified by the object identifier, as well as
+ any short names (descriptors), of the structural object class it
+ applies to.
+
+ An entry may only belong to auxiliary object classes listed in the
+ governing content rule.
+
+ An entry must contain all attributes required by the object classes
+ the entry belongs to as well as all attributes required by the
+ governing content rule.
+
+ An entry may contain any non-precluded attributes allowed by the
+ object classes the entry belongs to as well as all attributes allowed
+ by the governing content rule.
+
+ An entry cannot include any attribute precluded by the governing
+ content rule.
+
+ An entry is governed by (if present and active in the subschema) the
+ DIT content rule which applies to the structural object class of the
+ entry (see Section 2.4.2). If no active rule is present for the
+ entry's structural object class, the entry's content is governed by
+ the structural object class (and possibly other aspects of user and
+ system schema). DIT content rules for superclasses of the structural
+ object class of an entry are not applicable to that entry.
+
+ DIT content rule descriptions are written according to the ABNF:
+
+ DITContentRuleDescription = LPAREN WSP
+ numericoid ; object identifier
+ [ SP "NAME" SP qdescrs ] ; short names (descriptors)
+ [ SP "DESC" SP qdstring ] ; description
+ [ SP "OBSOLETE" ] ; not active
+ [ SP "AUX" SP oids ] ; auxiliary object classes
+ [ SP "MUST" SP oids ] ; attribute types
+ [ SP "MAY" SP oids ] ; attribute types
+ [ SP "NOT" SP oids ] ; attribute types
+
+
+
+Zeilenga LDAP Models [Page 29]
+
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
+ extensions WSP RPAREN ; extensions
+
+ where:
+ <numericoid> is the object identifier of the structural object class
+ associated with this DIT content rule;
+ NAME <qdescrs> are short names (descriptors) identifying this DIT
+ content rule;
+ DESC <qdstring> is a short descriptive string;
+ OBSOLETE indicates this DIT content rule use is not active;
+ AUX specifies a list of auxiliary object classes which entries
+ subject to this DIT content rule may belong to;
+ MUST, MAY, and NOT specify lists of attribute types which are
+ required, allowed, or precluded, respectively, from appearing in
+ entries subject to this DIT content rule; and
+ <extensions> describe extensions.
+
+
+4.1.7. DIT Structure Rules and Name Forms
+
+ It is sometimes desirable to regulate where object and alias entries
+ can be placed in the DIT and how they can be named based upon their
+ structural object class.
+
+
+4.1.7.1. DIT Structure Rules
+
+ A DIT structure rule is a "rule governing the structure of the DIT by
+ specifying a permitted superior to subordinate entry relationship. A
+ structure rule relates a name form, and therefore a structural object
+ class, to superior structure rules. This permits entries of the
+ structural object class identified by the name form to exist in the
+ DIT as subordinates to entries governed by the indicated superior
+ structure rules" [X.501].
+
+ DIT structure rule descriptions are written according to the ABNF:
+
+ DITStructureRuleDescription = LPAREN WSP
+ ruleid ; rule identifier
+ [ SP "NAME" SP qdescrs ] ; short names (descriptors)
+ [ SP "DESC" SP qdstring ] ; description
+ [ SP "OBSOLETE" ] ; not active
+ SP "FORM" SP oid ; NameForm
+ [ SP "SUP" ruleids ] ; superior rules
+ extensions WSP RPAREN ; extensions
+
+ ruleids = ruleid / ( LPAREN WSP ruleidlist WSP RPAREN )
+ ruleidlist = ruleid *( SP ruleid )
+ ruleid = number
+
+
+
+Zeilenga LDAP Models [Page 30]
+
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
+ where:
+ <ruleid> is the rule identifier of this DIT structure rule;
+ NAME <qdescrs> are short names (descriptors) identifying this DIT
+ structure rule;
+ DESC <qdstring> is a short descriptive string;
+ OBSOLETE indicates this DIT structure rule use is not active;
+ FORM is specifies the name form associated with this DIT structure
+ rule;
+ SUP identifies superior rules (by rule id); and
+ <extensions> describe extensions.
+
+ If no superior rules are identified, the DIT structure rule applies
+ to an autonomous administrative point (e.g. the root vertex of the
+ subtree controlled by the subschema) [X.501].
+
+
+4.1.7.2. Name Forms
+
+ A name form "specifies a permissible RDN for entries of a particular
+ structural object class. A name form identifies a named object
+ class and one or more attribute types to be used for naming (i.e.
+ for the RDN). Name forms are primitive pieces of specification
+ used in the definition of DIT structure rules" [X.501].
+
+ Each name form indicates the structural object class to be named,
+ a set of required attribute types, and a set of allowed attribute
+ types. A particular attribute type cannot be in both sets.
+
+ Entries governed by the form must be named using a value from each
+ required attribute type and zero or more values from the allowed
+ attribute types.
+
+ Each name form is identified by an object identifier (OID) and,
+ optionally, one or more short names (descriptors).
+
+ Name form descriptions are written according to the ABNF:
+
+ NameFormDescription = LPAREN WSP
+ numericoid ; object identifier
+ [ SP "NAME" SP qdescrs ] ; short names (descriptors)
+ [ SP "DESC" SP qdstring ] ; description
+ [ SP "OBSOLETE" ] ; not active
+ SP "OC" SP oid ; structural object class
+ SP "MUST" SP oids ; attribute types
+ [ SP "MAY" SP oids ] ; attribute types
+ extensions WSP RPAREN ; extensions
+
+ where:
+
+
+
+Zeilenga LDAP Models [Page 31]
+
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
+ <numericoid> is object identifier which identifies this name form;
+ NAME <qdescrs> are short names (descriptors) identifying this name
+ form;
+ DESC <qdstring> is a short descriptive string;
+ OBSOLETE indicates this name form is not active;
+ OC identifies the structural object class this rule applies to,
+ MUST and MAY specify the sets of required and allowed, respectively,
+ naming attributes for this name form; and
+ <extensions> describe extensions.
+
+ All attribute types in the required ("MUST") and allowed ("MAY") lists
+ shall be different.
+
+
+4.2. Subschema Subentries
+
+ Subschema (sub)entries are used for administering information about
+ the directory schema. A single subschema (sub)entry contains all
+ schema definitions (see Section 4.1) used by entries in a particular
+ part of the directory tree.
+
+ Servers which follow X.500(93) models SHOULD implement subschema using
+ the X.500 subschema mechanisms (as detailed in Section 12 of [X.501]),
+ and so these are not ordinary object entries but subentries (see
+ Section 3.2). LDAP clients SHOULD NOT assume that servers implement
+ any of the other aspects of X.500 subschema.
+
+ Servers MAY allow subschema modification. Procedures for subschema
+ modification are discussed in Section 14.5 of [X.501].
+
+ A server which masters entries and permits clients to modify these
+ entries SHALL implement and provide access to these subschema
+ (sub)entries including providing a 'subschemaSubentry' attribute in
+ each modifiable entry. This is so clients may discover the attributes
+ and object classes which are permitted to be present. It is strongly
+ RECOMMENDED that all other servers implement this as well.
+
+ The value of the 'subschemaSubentry' attribute is the name of the
+ subschema (sub)entry holding the subschema controlling the entry.
+
+ ( 2.5.18.10 NAME 'subschemaSubentry'
+ EQUALITY distinguishedNameMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
+ NO-USER-MODIFICATION SINGLE-VALUE
+ USAGE directoryOperation )
+
+ The 'distinguishedNameMatch' matching rule and the DistinguishedName
+ (1.3.6.1.4.1.1466.115.121.1.12) syntax are defined in [Syntaxes].
+
+
+
+Zeilenga LDAP Models [Page 32]
+
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
+ Subschema is held in (sub)entries belonging to the subschema auxiliary
+ object class.
+
+ ( 2.5.20.1 NAME 'subschema' AUXILIARY
+ MAY ( dITStructureRules $ nameForms $ ditContentRules $
+ objectClasses $ attributeTypes $ matchingRules $
+ matchingRuleUse ) )
+
+ The 'ldapSyntaxes' operational attribute may also be present in
+ subschema entries.
+
+ Servers MAY provide additional attributes (described in other
+ documents) in subschema (sub)entries.
+
+ Servers SHOULD provide the attributes 'createTimestamp' and
+ 'modifyTimestamp' in subschema (sub)entries, in order to allow clients
+ to maintain their caches of schema information.
+
+ The following subsections provide attribute type definitions for each
+ of schema definition attribute types.
+
+
+4.2.1. 'objectClasses'
+
+ This attribute holds definitions of object classes.
+
+ ( 2.5.21.6 NAME 'objectClasses'
+ EQUALITY objectIdentifierFirstComponentMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.37
+ USAGE directoryOperation )
+
+ The 'objectIdentifierFirstComponentMatch' matching rule and the
+ ObjectClassDescription (1.3.6.1.4.1.1466.115.121.1.37) syntax are
+ defined in [Syntaxes].
+
+
+4.2.2. 'attributeTypes'
+
+ This attribute holds definitions of attribute types.
+
+ ( 2.5.21.5 NAME 'attributeTypes'
+ EQUALITY objectIdentifierFirstComponentMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.3
+ USAGE directoryOperation )
+
+ The 'objectIdentifierFirstComponentMatch' matching rule and the
+ AttributeTypeDescription (1.3.6.1.4.1.1466.115.121.1.3) syntax are
+ defined in [Syntaxes].
+
+
+
+Zeilenga LDAP Models [Page 33]
+
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
+4.2.3. 'matchingRules'
+
+ This attribute holds definitions of matching rules.
+
+ ( 2.5.21.4 NAME 'matchingRules'
+ EQUALITY objectIdentifierFirstComponentMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.30
+ USAGE directoryOperation )
+
+ The 'objectIdentifierFirstComponentMatch' matching rule and the
+ MatchingRuleDescription (1.3.6.1.4.1.1466.115.121.1.30) syntax are
+ defined in [Syntaxes].
+
+
+4.2.4 'matchingRuleUse'
+
+ This attribute holds definitions of matching rule uses.
+
+ ( 2.5.21.8 NAME 'matchingRuleUse'
+ EQUALITY objectIdentifierFirstComponentMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.31
+ USAGE directoryOperation )
+
+ The 'objectIdentifierFirstComponentMatch' matching rule and the
+ MatchingRuleUseDescription (1.3.6.1.4.1.1466.115.121.1.31) syntax are
+ defined in [Syntaxes].
+
+
+4.2.5. 'ldapSyntaxes'
+
+ This attribute holds definitions of LDAP syntaxes.
+
+ ( 1.3.6.1.4.1.1466.101.120.16 NAME 'ldapSyntaxes'
+ EQUALITY objectIdentifierFirstComponentMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.54
+ USAGE directoryOperation )
+
+ The 'objectIdentifierFirstComponentMatch' matching rule and the
+ SyntaxDescription (1.3.6.1.4.1.1466.115.121.1.54) syntax are defined
+ in [Syntaxes].
+
+
+4.2.6. 'dITContentRules'
+
+ This attribute lists DIT Content Rules which are present in the
+ subschema.
+
+ ( 2.5.21.2 NAME 'dITContentRules'
+
+
+
+Zeilenga LDAP Models [Page 34]
+
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
+ EQUALITY objectIdentifierFirstComponentMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.16
+ USAGE directoryOperation )
+
+ The 'objectIdentifierFirstComponentMatch' matching rule and the
+ DITContentRuleDescription (1.3.6.1.4.1.1466.115.121.1.16) syntax are
+ defined in [Syntaxes].
+
+
+4.2.7. 'dITStructureRules'
+
+ This attribute lists DIT Structure Rules which are present in the
+ subschema.
+
+ ( 2.5.21.1 NAME 'dITStructureRules'
+ EQUALITY integerFirstComponentMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.17
+ USAGE directoryOperation )
+
+ The 'integerFirstComponentMatch' matching rule and the
+ DITStructureRuleDescription (1.3.6.1.4.1.1466.115.121.1.17) syntax are
+ defined in [Syntaxes].
+
+
+4.2.8 'nameForms'
+
+ This attribute lists Name Forms which are in force.
+
+ ( 2.5.21.7 NAME 'nameForms'
+ EQUALITY objectIdentifierFirstComponentMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.35
+ USAGE directoryOperation )
+
+ The 'objectIdentifierFirstComponentMatch' matching rule and the
+ NameFormDescription (1.3.6.1.4.1.1466.115.121.1.35) syntax are defined
+ in [Syntaxes].
+
+
+4.3. 'extensibleObject' object class
+
+ The 'extensibleObject' auxiliary object class allows entries that
+ belong to it to hold any user attribute. The set of allowed attribute
+ types of this object class is implicitly the set of all attribute
+ types of userApplications usage.
+
+ ( 1.3.6.1.4.1.1466.101.120.111 NAME 'extensibleObject'
+ SUP top AUXILIARY )
+
+
+
+
+Zeilenga LDAP Models [Page 35]
+
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
+ The mandatory attributes of the other object classes of this entry are
+ still required to be present and any precluded attributes are still
+ not allowed to be present.
+
+
+
+4.4. Subschema Discovery
+
+ To discover the DN of the subschema (sub)entry holding the subschema
+ controlling a particular entry, a client reads that entry's
+ 'subschemaSubentry' operational attribute. To read schema attributes
+ from the subschema (sub)entry, clients MUST issue a Search operation
+ [Protocol] where baseObject is the DN of the subschema (sub)entry,
+ scope is baseObject, filter is "(objectClass=subschema)" [Filters],
+ and attributes field lists the names of the desired schema attributes
+ (as they are operational). Note: the "(objectClass=subschema)" filter
+ allows LDAP servers which gateway to X.500 to detect that subentry
+ information is being requested.
+
+ Clients SHOULD NOT assume a published subschema is complete nor assume
+ the server supports all of the schema elements it publishes nor assume
+ the server does not support an unpublished element.
+
+
+5. DSA (Server) Informational Model
+
+ The LDAP protocol assumes there are one or more servers which jointly
+ provide access to a Directory Information Tree (DIT). The server
+ holding the original information is called the "master" (for that
+ information). Servers which hold copies of the original information
+ are referred to as "shadowing" or "caching" servers.
+
+ As defined in [X.501]:
+
+ context prefix: The sequence of RDNs leading from the Root of the
+ DIT to the initial vertex of a naming context; corresponds to
+ the distinguished name of that vertex.
+
+ and:
+
+ naming context: A subtree of entries held in a single master DSA.
+
+ That is, a naming context is the largest collection of entries,
+ starting at an entry that is mastered by a particular server, and
+ including all its subordinates and their subordinates, down to the
+ entries which are mastered by different servers. The context prefix
+ is the name of the initial entry.
+
+
+
+
+Zeilenga LDAP Models [Page 36]
+
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
+ The root of the DIT is a DSA-specific Entry (DSE) and not part of any
+ naming context (or any subtree); each server has different attribute
+ values in the root DSE.
+
+
+5.1. Server-specific Data Requirements
+
+ An LDAP server SHALL provide information about itself and other
+ information that is specific to each server. This is represented as a
+ group of attributes located in the root DSE, which is named with the
+ DN with zero RDNs (whose [LDAPDN] representation is as the zero-length
+ string).
+
+ These attributes are retrievable, subject to access control and other
+ restrictions, if a client performs a Search operation [Protocol] with
+ an empty baseObject, scope of baseObject, the filter "(objectClass=*)"
+ [Filters], and with the attributes field listing the names of the
+ desired attributes. It is noted that root DSE attributes are
+ operational, and like other operational attributes, are not returned
+ in search requests unless requested by name.
+
+ The root DSE SHALL NOT be included if the client performs a subtree
+ search starting from the root.
+
+ Servers may allow clients to modify attributes of the root DSE where
+ appropriate.
+
+ The following attributes of the root DSE are defined in [Syntaxes].
+ Additional attributes may be defined in other documents.
+
+ - altServer: alternative servers;
+
+ - namingContexts: naming contexts;
+
+ - supportedControl: recognized LDAP controls;
+
+ - supportedExtension: recognized LDAP extended operations;
+
+ - supportedFeatures: recognized LDAP features;
+
+ - supportedLDAPVersion: LDAP versions supported; and
+
+ - supportedSASLMechanisms: recognized Simple Authentication and
+ Security Layers (SASL) [SASL] mechanisms.
+
+ The values provided for these attributes may depend on
+ session-specific and other factors. For example, a server supporting
+ the SASL EXTERNAL mechanism might only list "EXTERNAL" when the
+
+
+
+Zeilenga LDAP Models [Page 37]
+
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
+ client's identity has been established by a lower level. See
+ [AuthMeth].
+
+ The root DSE may also include a 'subschemaSubentry' attribute. If so,
+ it refers to the subschema (sub)entry holding the schema controlling
+ the root DSE. Clients SHOULD NOT assume that this subschema
+ (sub)entry controls other entries held by the server. General
+ subschema discovery procedures are provided in Section 4.4.
+
+
+5.1.1. 'altServer'
+
+ The 'altServer' attribute lists URIs referring to alternative servers
+ which may be contacted when this server becomes unavailable. URIs for
+ servers implementing the LDAP are written according to [LDAPURL].
+ Other kinds of URIs may be provided. If the server does not know of
+ any other servers which could be used this attribute will be absent.
+ Clients may cache this information in case their preferred server
+ later becomes unavailable.
+
+ ( 1.3.6.1.4.1.1466.101.120.6 NAME 'altServer'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
+ USAGE dSAOperation )
+
+ The IA5String (1.3.6.1.4.1.1466.115.121.1.26) syntax is defined in
+ [Syntaxes].
+
+
+5.1.2. 'namingContexts'
+
+ The 'namingContexts' attribute lists the context prefixes of the
+ naming contexts the server masters or shadows (in part or in whole).
+ If the server is a first-level DSA [X.501], it should list (in
+ addition) an empty string (indicating the root of the DIT). If the
+ server does not master or shadow any information (e.g. it is an LDAP
+ gateway to a public X.500 directory) this attribute will be absent.
+ If the server believes it masters or shadows the entire directory, the
+ attribute will have a single value, and that value will be the empty
+ string (indicating the root of the DIT).
+
+ This attribute may be used, for example, to select a suitable entry
+ name for subsequent operations with this server.
+
+ ( 1.3.6.1.4.1.1466.101.120.5 NAME 'namingContexts'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
+ USAGE dSAOperation )
+
+ The DistinguishedName (1.3.6.1.4.1.1466.115.121.1.12) syntax is
+
+
+
+Zeilenga LDAP Models [Page 38]
+
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
+ defined in [Syntaxes].
+
+
+5.1.3. 'supportedControl'
+
+ The 'supportedControl' attribute lists object identifiers identifying
+ the request controls [Protocol] the server supports. If the server
+ does not support any request controls, this attribute will be absent.
+ Object identifiers identifying response controls need not be listed.
+
+ Procedures for registering object identifiers used to discovery of
+ protocol mechanisms are detailed in BCP 64 [BCP64bis].
+
+ ( 1.3.6.1.4.1.1466.101.120.13 NAME 'supportedControl'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
+ USAGE dSAOperation )
+
+ The OBJECT IDENTIFIER (1.3.6.1.4.1.1466.115.121.1.38) syntax is
+ defined in [Syntaxes].
+
+
+5.1.4. 'supportedExtension'
+
+ The 'supportedExtension' attribute lists object identifiers
+ identifying the extended operations [Protocol] which the server
+ supports. If the server does not support any extended operations,
+ this attribute will be absent.
+
+ An extended operation generally consists of an extended request and an
+ extended response but may also include other protocol data units (such
+ as intermediate responses). The object identifier assigned to the
+ extended request is used to identify the extended operation. Other
+ object identifiers used in the extended operation need not be listed
+ as values of this attribute.
+
+ Procedures for registering object identifiers used to discovery of
+ protocol mechanisms are detailed in BCP 64 [BCP64bis].
+
+ ( 1.3.6.1.4.1.1466.101.120.7 NAME 'supportedExtension'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
+ USAGE dSAOperation )
+
+ The OBJECT IDENTIFIER (1.3.6.1.4.1.1466.115.121.1.38) syntax is
+ defined in [Syntaxes].
+
+
+5.1.5. 'supportedFeatures'
+
+
+
+
+Zeilenga LDAP Models [Page 39]
+
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
+ The 'supportedFeatures' attribute lists object identifiers identifying
+ elective features which the server supports. If the server does not
+ support any discoverable elective features, this attribute will be
+ absent.
+
+ ( 1.3.6.1.4.1.4203.1.3.5 NAME 'supportedFeatures'
+ EQUALITY objectIdentifierMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
+ USAGE dSAOperation )
+
+ Procedures for registering object identifiers used to discovery of
+ protocol mechanisms are detailed in BCP 64 [BCP64bis].
+
+ The OBJECT IDENTIFIER (1.3.6.1.4.1.1466.115.121.1.38) syntax and
+ objectIdentifierMatch matching rule are defined in [Syntaxes].
+
+
+5.1.6. 'supportedLDAPVersion'
+
+ The 'supportedLDAPVersion' attribute lists the versions of LDAP which
+ the server supports.
+
+ ( 1.3.6.1.4.1.1466.101.120.15 NAME 'supportedLDAPVersion'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
+ USAGE dSAOperation )
+
+ The INTEGER (1.3.6.1.4.1.1466.115.121.1.27) syntax are defined in
+ [Syntaxes].
+
+
+5.1.7. 'supportedSASLMechanisms'
+
+ The 'supportedSASLMechanisms' attribute lists the SASL mechanisms
+ [SASL] which the server recognizes and/or supports [AuthMeth]. The
+ contents of this attribute may depend on the current session state.
+ If the server does not support any SASL mechanisms this attribute will
+ not be present.
+
+ ( 1.3.6.1.4.1.1466.101.120.14 NAME 'supportedSASLMechanisms'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ USAGE dSAOperation )
+
+ The Directory String (1.3.6.1.4.1.1466.115.121.1.15) syntax is defined
+ in [Syntaxes].
+
+
+6. Other Considerations
+
+
+
+
+Zeilenga LDAP Models [Page 40]
+
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
+6.1. Preservation of User Information
+
+ Syntaxes may be defined which have specific value and/or value form
+ (representation) preservation requirements. For example, a syntax
+ containing digitally signed data can mandate the server preserve both
+ the value and form of value presented to ensure signature is not
+ invalidated.
+
+ Where such requirements have not been explicitly stated, servers
+ SHOULD preserve the value of user information but MAY return the value
+ in a different form. And where a server is unable (or unwilling) to
+ preserve the value of user information, the server SHALL ensure that
+ an equivalent value (per Section 2.3) is returned.
+
+
+6.2. Short Names
+
+ Short names, also known as descriptors, are used as more readable
+ aliases for object identifiers and are used to identify various schema
+ elements. However, it is not expected that LDAP implementations with
+ human user interface would display these short names (nor the object
+ identifiers they refer to) to the user, but would most likely be
+ performing translations (such as expressing the short name in one of
+ the local national languages). For example, the short name "st"
+ (stateOrProvinceName) might be displayed to a German-speaking user as
+ "Land".
+
+ The same short name might have different meaning in different
+ subschemas and, within a particular subschema, the same short name
+ might refer to different object identifiers each identifying a
+ different kind of schema element.
+
+ Implementations MUST be prepared that the same short name might be
+ used in a subschema to refer to the different kinds of schema
+ elements. That is, there might be an object class 'x-fubar' and an
+ attribute type 'x-fubar' in a subschema.
+
+ Implementations MUST be prepared that the same short name might be
+ used in the different subschemas to refer to the different schema
+ elements. That is, there might be two matching rules 'x-fubar', each
+ in different subschemas.
+
+ Procedures for registering short names (descriptors) are detailed in
+ BCP 64 [BCP64bis].
+
+
+6.3. Cache and Shadowing
+
+
+
+
+Zeilenga LDAP Models [Page 41]
+
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
+ Some servers may hold cache or shadow copies of entries, which can be
+ used to answer search and comparison queries, but will return
+ referrals or contact other servers if modification operations are
+ requested. Servers that perform shadowing or caching MUST ensure that
+ they do not violate any access control constraints placed on the data
+ by the originating server.
+
+
+7. Implementation Guidelines
+
+7.1 Server Guidelines
+
+ Servers MUST recognize all names of attribute types and object classes
+ defined in this document but, unless stated otherwise, need not
+ support the associated functionality. Servers SHOULD recognize all
+ the names of attribute types and object classes defined in Section 3
+ and 4, respectively, of [Schema].
+
+ Servers MUST ensure that entries conform to user and system schema
+ rules or other data model constraints.
+
+ Servers MAY support DIT Content Rules. Servers MAY support DIT
+ Structure Rules and Name Forms.
+
+ Servers MAY support alias entries.
+
+ Servers MAY support the 'extensibleObject' object class.
+
+ Servers MAY support subentries. If so, they MUST do so in accordance
+ with [RFC3672]. Servers which do not support subentries SHOULD use
+ object entries to mimic subentries as detailed in Section 3.2.
+
+ Servers MAY implement additional schema elements. Servers SHOULD
+ provide definitions of all schema elements they support in subschema
+ (sub)entries.
+
+
+7.2 Client Guidelines
+
+ In the absence of prior agreements with servers, clients SHOULD NOT
+ assume that servers support any particular schema elements beyond
+ those referenced in Section 7.1. The client can retrieve subschema
+ information as described in Section 4.4.
+
+ Clients MUST NOT display nor attempt to decode as ASN.1, a value if
+ its syntax is not known. Clients MUST NOT assume the LDAP-specific
+ string encoding is restricted to a UTF-8 encoded string of Unicode
+ characters or any particular subset of Unicode (such as a printable
+
+
+
+Zeilenga LDAP Models [Page 42]
+
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
+ subset) unless such restriction is explicitly stated. Clients SHOULD
+ NOT send attribute values in a request that are not valid according to
+ the syntax defined for the attributes.
+
+
+8. Security Considerations
+
+ Attributes of directory entries are used to provide descriptive
+ information about the real-world objects they represent, which can be
+ people, organizations or devices. Most countries have privacy laws
+ regarding the publication of information about people.
+
+ General security considerations for accessing directory information
+ with LDAP are discussed in [Protocol] and [AuthMeth].
+
+
+9. IANA Considerations
+
+ It is requested that the Internet Assigned Numbers Authority (IANA)
+ update the LDAP descriptors registry as indicated in the following
+ template:
+
+ Subject: Request for LDAP Descriptor Registration Update
+ Descriptor (short name): see comment
+ Object Identifier: see comment
+ Person & email address to contact for further information:
+ Kurt Zeilenga <kurt at OpenLDAP.org>
+ Usage: see comment
+ Specification: RFC XXXX
+ Author/Change Controller: IESG
+ Comments:
+
+ The following descriptors (short names) should be added to
+ the registry.
+
+ NAME Type OID
+ ------------------------ ---- -----------------
+ governingStructureRule A 2.5.21.10
+ structuralObjectClass A 2.5.21.9
+
+ The following descriptors (short names) should be updated to
+ refer to this RFC.
+
+ NAME Type OID
+ ------------------------ ---- -----------------
+ alias O 2.5.6.1
+ aliasedObjectName A 2.5.4.1
+ altServer A 1.3.6.1.4.1.1466.101.120.6
+
+
+
+Zeilenga LDAP Models [Page 43]
+
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
+ attributeTypes A 2.5.21.5
+ createTimestamp A 2.5.18.1
+ creatorsName A 2.5.18.3
+ dITContentRules A 2.5.21.2
+ dITStructureRules A 2.5.21.1
+ extensibleObject O 1.3.6.1.4.1.1466.101.120.111
+ ldapSyntaxes A 1.3.6.1.4.1.1466.101.120.16
+ matchingRuleUse A 2.5.21.8
+ matchingRules A 2.5.21.4
+ modifiersName A 2.5.18.4
+ modifyTimestamp A 2.5.18.2
+ nameForms A 2.5.21.7
+ namingContexts A 1.3.6.1.4.1.1466.101.120.5
+ objectClass A 2.5.4.0
+ objectClasses A 2.5.21.6
+ subschema O 2.5.20.1
+ subschemaSubentry A 2.5.18.10
+ supportedControl A 1.3.6.1.4.1.1466.101.120.13
+ supportedExtension A 1.3.6.1.4.1.1466.101.120.7
+ supportedFeatures A 1.3.6.1.4.1.4203.1.3.5
+ supportedLDAPVersion A 1.3.6.1.4.1.1466.101.120.15
+ supportedSASLMechanisms A 1.3.6.1.4.1.1466.101.120.14
+ top O 2.5.6.0
+
+
+10. Acknowledgments
+
+ This document is based in part on RFC 2251 by M. Wahl, T. Howes, and
+ S. Kille; RFC 2252 by M. Wahl, A. Coulbeck, T. Howes, S. Kille; and
+ RFC 2556 by M. Wahl, all products of the IETF Access, Searching and
+ Indexing of Directories (ASID) Working Group. This document is also
+ based in part on "The Directory: Models" [X.501], a product of the
+ International Telephone Union (ITU). Additional text was borrowed
+ from RFC 2253 by M. Wahl, T. Howes, and S. Kille.
+
+ This document is a product of the IETF LDAP Revision (LDAPBIS) Working
+ Group.
+
+
+11. Editor's Address
+
+ Kurt D. Zeilenga
+ OpenLDAP Foundation
+
+ Email: Kurt at OpenLDAP.org
+
+
+12. References
+
+
+
+Zeilenga LDAP Models [Page 44]
+
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
+ [[Note to the RFC Editor: please replace the citation tags used in
+ referencing Internet-Drafts with tags of the form RFCnnnn where
+ possible.]]
+
+
+12.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14 (also RFC 2119), March 1997.
+
+ [RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
+ Specifications: ABNF", RFC 2234, November 1997.
+
+ [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
+ 10646", RFC 3629 (also STD 63), November 2003.
+
+ [RFC3671] Zeilenga, K., "Collective Attributes in LDAP", RFC 3671,
+ December 2003.
+
+ [RFC3672] Zeilenga, K. and S. Legg, "Subentries in LDAP", RFC
+ 3672, December 2003.
+
+ [BCP64bis] Zeilenga, K., "IANA Considerations for LDAP",
+ draft-ietf-ldapbis-bcp64-xx.txt, a work in progress.
+
+ [Roadmap] Zeilenga, K. (editor), "LDAP: Technical Specification
+ Road Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in
+ progress.
+
+ [Protocol] Sermersheim, J. (editor), "LDAP: The Protocol",
+ draft-ietf-ldapbis-protocol-xx.txt, a work in progress.
+
+ [AuthMeth] Harrison, R. (editor), "LDAP: Authentication Methods and
+ Connection Level Security Mechanisms",
+ draft-ietf-ldapbis-authmeth-xx.txt, a work in progress.
+
+ [Filters] Smith, M. (editor), LDAPbis WG, "LDAP: String
+ Representation of Search Filters",
+ draft-ietf-ldapbis-filter-xx.txt, a work in progress.
+
+ [LDAPDN] Zeilenga, K. (editor), "LDAP: String Representation of
+ Distinguished Names", draft-ietf-ldapbis-dn-xx.txt, a
+ work in progress.
+
+ [LDAPURL] Smith, M. (editor), "LDAP: Uniform Resource Locator",
+ draft-ietf-ldapbis-url-xx.txt, a work in progress.
+
+ [SASL] Melnikov, A. (Editor), "Simple Authentication and
+
+
+
+Zeilenga LDAP Models [Page 45]
+
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
+ Security Layer (SASL)",
+ draft-ietf-sasl-rfc2222bis-xx.txt, a work in progress.
+
+ [Syntaxes] Legg, S. (editor), "LDAP: Syntaxes and Matching Rules",
+ draft-ietf-ldapbis-syntaxes-xx.txt, a work in progress.
+
+ [Schema] Dally, K. (editor), "LDAP: User Schema",
+ draft-ietf-ldapbis-user-schema-xx.txt, a work in
+ progress.
+
+ [Unicode] The Unicode Consortium, "The Unicode Standard, Version
+ 3.2.0" is defined by "The Unicode Standard, Version 3.0"
+ (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5),
+ as amended by the "Unicode Standard Annex #27: Unicode
+ 3.1" (http://www.unicode.org/reports/tr27/) and by the
+ "Unicode Standard Annex #28: Unicode 3.2"
+ (http://www.unicode.org/reports/tr28/).
+
+ [X.500] International Telecommunication Union -
+ Telecommunication Standardization Sector, "The Directory
+ -- Overview of concepts, models and services,"
+ X.500(1993) (also ISO/IEC 9594-1:1994).
+
+ [X.501] International Telecommunication Union -
+ Telecommunication Standardization Sector, "The Directory
+ -- Models," X.501(1993) (also ISO/IEC 9594-2:1994).
+
+ [X.680] International Telecommunication Union -
+ Telecommunication Standardization Sector, "Abstract
+ Syntax Notation One (ASN.1) - Specification of Basic
+ Notation", X.680(2002) (also ISO/IEC 8824-1:2002).
+
+
+12.2. Informative References
+
+ None.
+
+
+Appendix A. Changes
+
+ This appendix is non-normative.
+
+ This document amounts to nearly a complete rewrite of portions of RFC
+ 2251, RFC 2252, and RFC 2256. This rewrite was undertaken to improve
+ overall clarity of technical specification. This appendix provides a
+ summary of substantive changes made to the portions of these documents
+ incorporated into this document. Readers should consult [Roadmap],
+ [Protocol], [Syntaxes], and [Schema] for summaries of remaining
+
+
+
+Zeilenga LDAP Models [Page 46]
+
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
+ portions of these documents.
+
+
+A.1 Changes to RFC 2251
+
+ This document incorporates from RFC 2251 sections 3.2 and 3.4,
+ portions of Section 4 and 6 as summarized below.
+
+
+A.1.1 Section 3.2 of RFC 2251
+
+ Section 3.2 of RFC 2251 provided a brief introduction to the X.500
+ data model, as used by LDAP. The previous specification relied on
+ [X.501] but lacked clarity in how X.500 models are adapted for use by
+ LDAP. This document describes the X.500 data models, as used by LDAP
+ in greater detail, especially in areas where adaptation is needed.
+
+ Section 3.2.1 of RFC 2251 described an attribute as "a type with one
+ or more associated values." In LDAP, an attribute is better described
+ as an attribute description, a type with zero or more options, and one
+ or more associated values.
+
+ Section 3.2.2 of RFC 2251 mandated that subschema subentries contain
+ objectClasses and attributeTypes attributes, yet X.500(93) treats
+ these attributes as optional. While generally all implementations
+ that support X.500(93) subschema mechanisms will provide both of these
+ attributes, it is not absolutely required for interoperability that
+ all servers do. The mandate was removed for consistency with
+ X.500(93). The subschema discovery mechanism was also clarified to
+ indicate that subschema controlling an entry is obtained by reading
+ the (sub)entry referred to by that entry's 'subschemaSubentry'
+ attribute.
+
+
+A.1.2 Section 3.4 of RFC 2251
+
+ Section 3.4 of RFC 2251 provided "Server-specific Data Requirements".
+ This material, with changes, was incorporated in Section 5.1 of this
+ document.
+
+ Changes:
+
+ - Clarify that attributes of the root DSE are subject to "other
+ restrictions" in addition to access controls.
+
+ - Clarify that only recognized extended requests need to be enumerated
+ 'supportedExtension'.
+
+
+
+
+Zeilenga LDAP Models [Page 47]
+
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
+ - Clarify that only recognized request controls need to be enumerated
+ 'supportedControl'.
+
+ - Clarify that root DSE attributes are operational and, like other
+ operational attributes, will not be returned in search requests
+ unless requested by name.
+
+ - Clarify that not all root DSE attributes are user modifiable.
+
+ - Remove inconsistent text regarding handling of the
+ 'subschemaSubentry' attribute within the root DSE. The previous
+ specification stated that the 'subschemaSubentry' attribute held in
+ the root DSE referred to "subschema entries (or subentries) known by
+ this server." This is inconsistent with the attribute intended use
+ as well as its formal definition as a single valued attribute
+ [X.501]. It is also noted that a simple (possibly incomplete) list
+ of subschema (sub)entries is not terrible useful. This document (in
+ section 5.1) specifies that the 'subschemaSubentry' attribute of the
+ root DSE refers to the subschema controlling the root DSE. It is
+ noted that the general subschema discovery mechanism remains
+ available (see Section 4.4 of this document).
+
+
+A.1.2 Section 4 of RFC 2251
+
+ Portions of Section 4 of RFC 2251 detailing aspects of the information
+ model used by LDAP were incorporated in this document, including:
+
+ - Restriction of distinguished values to attributes whose descriptions
+ have no options (from Section 4.1.3);
+
+ - Data model aspects of Attribute Types (from Section 4.1.4),
+ Attribute Descriptions (from 4.1.5), Attribute (from 4.1.8),
+ Matching Rule Identifier (from 4.1.9); and
+
+ - User schema requirements (from Section 4.1.6, 4.5.1, and 4.7).
+
+
+Clarifications to these portions include:
+
+ - Subtyping and AttributeDescriptions with options.
+
+
+
+
+
+A.1.3 Section 6 of RFC 2251
+
+
+
+
+Zeilenga LDAP Models [Page 48]
+
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
+ The Section 6.1 and the second paragraph of Section 6.2 of RFC 2251
+ where incorporated into this document.
+
+
+A.2 Changes to RFC 2252
+
+ This document incorporates Sections 4, 5 and 7 from RFC 2252.
+
+
+A.2.1 Section 4 of RFC 2252
+
+ The specification was updated to use Augmented BNF [RFC2234]. The
+ string representation of an OBJECT IDENTIFIER was tighten to
+ disallow leading zeros as described in RFC 2252 text.
+
+ The <descr> syntax was changed to disallow semicolon (U+003B)
+ characters to appear to be consistent its natural language
+ specification "descr is the syntactic representation of an object
+ descriptor, which consists of letters and digits, starting with a
+ letter." In a related change, the statement "an
+ AttributeDescription can be used as the value in a NAME part of an
+ AttributeTypeDescription" was deleted. RFC 2252 provided no
+ specification of the semantics of attribute options appearing in
+ NAME fields.
+
+ RFC 2252 stated that the <descr> form of <oid> SHOULD be preferred
+ over the <numericoid> form. However, <descr> form can be ambiguous.
+ To address this issue, the imperative was replaced with a statement
+ (in Section 1.4) that while the <descr> form is generally preferred,
+ <numericoid> should be used where an unambiguous <descr> is not
+ available. Additionally, an expanded discussion of descriptor
+ issues is discussed in Section 6.2 (Short Names).
+
+ The ABNF for a quoted string (qdstring) was updated to reflect
+ support for the escaping mechanism described in 4.3 of RFC 2252.
+
+
+A.2.2 Section 5 of RFC 2252
+
+ Definitions of operational attributes provided in Section 5 of RFC
+ 2252 where incorporated into this document.
+
+ The 'namingContexts' description was clarified. A first-level DSA
+ should publish, in addition to other values, "" indicating the root
+ of the DIT.
+
+ The 'altServer' description was clarified. It may hold any URI.
+
+
+
+
+Zeilenga LDAP Models [Page 49]
+
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
+ The 'supportedExtension' description was clarified. A server need
+ only list the OBJECT IDENTIFIERs associated with the extended
+ requests of the extended operations it recognizes.
+
+ The 'supportedControl' description was clarified. A server need
+ only list the OBJECT IDENTIFIERs associated with the request
+ controls it recognizes.
+
+ Descriptions for the 'structuralObjectClass' and
+ 'governingStructureRule' operational attribute types were added.
+
+
+A.2.3 Section 7 of RFC 2252
+
+ Section 7 of RFC 2252 provides definitions of the 'subschema' and
+ 'extensibleObject' object classes. These definitions where
+ integrated into Section 4.2 and Section 4.3 of this document,
+ respectively. Section 7 of RFC 2252 also contained the object class
+ implementation requirement. This was incorporated into Section 7 of
+ this document.
+
+ The specification of 'extensibleObject' was clarified of how it
+ interacts with precluded attributes.
+
+
+A.3 Changes to RFC 2256
+
+ This document incorporates Sections 5.1, 5.2, 7.1, and 7.2 of RFC
+ 2256.
+
+ Section 5.1 of RFC 2256 provided the definition of the 'objectClass'
+ attribute type. This was integrated into Section 2.4.1 of this
+ document. The statement "One of the values is either 'top' or
+ 'alias'" was replaced with statement that one of the values is 'top'
+ as entries belonging to 'alias' also belong to 'top'.
+
+ Section 5.2 of RFC 2256 provided the definition of the
+ 'aliasedObjectName' attribute type. This was integrated into
+ Section 2.6.2 of this document.
+
+ Section 7.1 of RFC 2256 provided the definition of the 'top' object
+ class. This was integrated into Section 2.4.1 of this document.
+
+ Section 7.2 of RFC 2256 provided the definition of the 'alias'
+ object class. This was integrated into Section 2.6.1 of this
+ document.
+
+
+
+
+
+Zeilenga LDAP Models [Page 50]
+
+INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
+
+
+A.4 Changes to RFC 3674
+
+ This document made no substantive change to the 'supportedFeatures'
+ technical specification provided in RFC 3674.
+
+
+
+Intellectual Property Rights
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be found
+ in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this specification
+ can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr at ietf.org.
+
+
+
+Full Copyright
+
+ Copyright (C) The Internet Society (2005). This document is subject
+ to the rights, licenses and restrictions contained in BCP 78, and
+ except as set forth therein, the authors retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+
+
+Zeilenga LDAP Models [Page 51]
+
Added: openldap/vendor/openldap-release/doc/drafts/draft-ietf-ldapbis-protocol-xx.txt
===================================================================
--- openldap/vendor/openldap-release/doc/drafts/draft-ietf-ldapbis-protocol-xx.txt (rev 0)
+++ openldap/vendor/openldap-release/doc/drafts/draft-ietf-ldapbis-protocol-xx.txt 2007-09-15 10:38:52 UTC (rev 844)
@@ -0,0 +1,3709 @@
+
+
+Internet-Draft Editor: J. Sermersheim
+Intended Category: Standard Track Novell, Inc
+Document: draft-ietf-ldapbis-protocol-32.txt Oct 2005
+Obsoletes: RFCs 2251, 2830, 3771
+
+
+ LDAP: The Protocol
+
+
+Status of this Memo
+
+ By submitting this Internet-Draft, each
+ author represents that any applicable patent or other IPR claims of
+ which he or she is aware have been or will be disclosed, and any of
+ which he or she becomes aware will be disclosed, in accordance with
+ Section 6 of BCP 79.
+
+ Internet-Drafts are working documents of the Internet Engineering
+ Task Force (IETF), its areas, and its working groups. Note that other
+ groups may also distribute working documents as Internet-Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference
+ material or to cite them other than as "work in progress".
+
+ The list of current Internet-Drafts can be accessed at
+ http://www.ietf.org/ietf/1id-abstracts.txt.
+
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html.
+
+ This Internet-Draft will expire in February 2005.
+
+ Technical discussion of this document will take place on the IETF
+ LDAP Revision Working Group (LDAPbis) mailing list <ietf-
+ ldapbis at openldap.org>. Please send editorial comments directly to the
+ editor <jimse at novell.com>.
+
+
+Abstract
+
+ This document describes the protocol elements, along with their
+ semantics and encodings, of the Lightweight Directory Access Protocol
+ (LDAP). LDAP provides access to distributed directory services that
+ act in accordance with X.500 data and service models. These protocol
+ elements are based on those described in the X.500 Directory Access
+ Protocol (DAP).
+
+
+Table of Contents
+
+
+
+Sermersheim Internet-Draft - Expires April 2006 Page 1
+ Lightweight Directory Access Protocol Version 3
+
+ 1. Introduction....................................................3
+ 1.1. Relationship to Other LDAP Specifications.....................3
+ 2. Conventions.....................................................3
+ 3. Protocol Model..................................................4
+ 3.1 Operation and LDAP Message Layer Relationship..................5
+ 4. Elements of Protocol............................................5
+ 4.1. Common Elements...............................................5
+ 4.1.1. Message Envelope............................................5
+ 4.1.2. String Types................................................7
+ 4.1.3. Distinguished Name and Relative Distinguished Name..........7
+ 4.1.4. Attribute Descriptions......................................8
+ 4.1.5. Attribute Value.............................................8
+ 4.1.6. Attribute Value Assertion...................................8
+ 4.1.7. Attribute and PartialAttribute..............................9
+ 4.1.8. Matching Rule Identifier....................................9
+ 4.1.9. Result Message..............................................9
+ 4.1.10. Referral..................................................11
+ 4.1.11. Controls..................................................13
+ 4.2. Bind Operation...............................................14
+ 4.3. Unbind Operation.............................................17
+ 4.4. Unsolicited Notification.....................................17
+ 4.5. Search Operation.............................................18
+ 4.6. Modify Operation.............................................29
+ 4.7. Add Operation................................................31
+ 4.8. Delete Operation.............................................31
+ 4.9. Modify DN Operation..........................................32
+ 4.10. Compare Operation...........................................33
+ 4.11. Abandon Operation...........................................34
+ 4.12. Extended Operation..........................................35
+ 4.13. IntermediateResponse Message................................36
+ 4.14. StartTLS Operation..........................................37
+ 5. Protocol Encoding, Connection, and Transfer....................39
+ 5.1. Protocol Encoding............................................39
+ 5.2. Transmission Control Protocol (TCP)..........................40
+ 5.3. Termination of the LDAP session..............................40
+ 6. Security Considerations........................................40
+ 7. Acknowledgements...............................................42
+ 8. Normative References...........................................42
+ 9. Informative References.........................................44
+ 10. IANA Considerations...........................................44
+ 11. Editor's Address..............................................45
+ Appendix A - LDAP Result Codes....................................46
+ A.1 Non-Error Result Codes........................................46
+ A.2 Result Codes..................................................46
+ Appendix B - Complete ASN.1 Definition............................51
+ Appendix C - Changes..............................................57
+ C.1 Changes made to RFC 2251:.....................................57
+ C.2 Changes made to RFC 2830:.....................................62
+ C.3 Changes made to RFC 3771:.....................................63
+
+
+
+
+
+
+Sermersheim Internet-Draft - Expires April 2006 Page 2
+ Lightweight Directory Access Protocol Version 3
+
+1. Introduction
+
+ The Directory is "a collection of open systems cooperating to provide
+ directory services" [X.500]. A directory user, which may be a human
+ or other entity, accesses the Directory through a client (or
+ Directory User Agent (DUA)). The client, on behalf of the directory
+ user, interacts with one or more servers (or Directory System Agents
+ (DSA)). Clients interact with servers using a directory access
+ protocol.
+
+ This document details the protocol elements of the Lightweight
+ Directory Access Protocol (LDAP), along with their semantics.
+ Following the description of protocol elements, it describes the way
+ in which the protocol elements are encoded and transferred.
+
+
+1.1. Relationship to Other LDAP Specifications
+
+ This document is an integral part of the LDAP Technical Specification
+ [Roadmap] which obsoletes the previously defined LDAP technical
+ specification, RFC 3377, in its entirety.
+
+ This document, together with [Roadmap], [AuthMeth], and [Models],
+ obsoletes RFC 2251 in its entirety. Section 3.3 is obsoleted by
+ [Roadmap]. Sections 4.2.1 (portions), and 4.2.2 are obsoleted by
+ [AuthMeth]. Sections 3.2, 3.4, 4.1.3 (last paragraph), 4.1.4, 4.1.5,
+ 4.1.5.1, 4.1.9 (last paragraph), 5.1, 6.1, and 6.2 (last paragraph)
+ are obsoleted by [Models]. The remainder of RFC 2251 is obsoleted by
+ this document. Appendix C.1 summarizes substantive changes in the
+ remainder.
+
+ This document obsoletes RFC 2830, Sections 2 and 4. The remainder of
+ RFC 2830 is obsoleted by [AuthMeth]. Appendix C.2 summarizes
+ substantive changes to the remaining sections.
+
+ This document also obsoletes RFC 3771 in entirety.
+
+
+2. Conventions
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY" in this document are
+ to be interpreted as described in [Keyword].
+
+ Character names in this document use the notation for code points and
+ names from the Unicode Standard [Unicode]. For example, the letter
+ "a" may be represented as either <U+0061> or <LATIN SMALL LETTER A>.
+
+ Note: a glossary of terms used in Unicode can be found in [Glossary].
+ Information on the Unicode character encoding model can be found in
+ [CharModel].
+
+
+
+
+Sermersheim Internet-Draft - Expires April 2006 Page 3
+ Lightweight Directory Access Protocol Version 3
+
+ The term "transport connection" refers to the underlying transport
+ services used to carry the protocol exchange, as well as associations
+ established by these services.
+
+ The term "TLS layer" refers to TLS services used in providing
+ security services, as well as associations established by these
+ services.
+
+ The term "SASL layer" refers to SASL services used in providing
+ security services, as well as associations established by these
+ services.
+
+ The term "LDAP message layer" refers to the LDAP Message Protocol
+ Data Unit (PDU) services used in providing directory services, as
+ well as associations established by these services.
+
+ The term "LDAP session" refers to combined services (transport
+ connection, TLS layer, SASL layer, LDAP message layer) and their
+ associations.
+
+ See the table in Section 5 for an illustration of these four terms.
+
+
+3. Protocol Model
+
+ The general model adopted by this protocol is one of clients
+ performing protocol operations against servers. In this model, a
+ client transmits a protocol request describing the operation to be
+ performed to a server. The server is then responsible for performing
+ the necessary operation(s) in the Directory. Upon completion of an
+ operation, the server typically returns a response containing
+ appropriate data to the requesting client.
+
+ Protocol operations are generally independent of one another. Each
+ operation is processed as an atomic action, leaving the directory in
+ a consistent state.
+
+ Although servers are required to return responses whenever such
+ responses are defined in the protocol, there is no requirement for
+ synchronous behavior on the part of either clients or servers.
+ Requests and responses for multiple operations generally may be
+ exchanged between a client and server in any order. If required,
+ synchronous behavior may be controlled by client applications.
+
+ The core protocol operations defined in this document can be mapped
+ to a subset of the X.500 (1993) Directory Abstract Service [X.511].
+ However there is not a one-to-one mapping between LDAP operations and
+ X.500 Directory Access Protocol (DAP) operations. Server
+ implementations acting as a gateway to X.500 directories may need to
+ make multiple DAP requests to service a single LDAP request.
+
+
+
+
+
+Sermersheim Internet-Draft - Expires April 2006 Page 4
+ Lightweight Directory Access Protocol Version 3
+
+
+3.1. Operation and LDAP Message Layer Relationship
+
+ Protocol operations are exchanged at the LDAP message layer. When the
+ transport connection is closed, any uncompleted operations at the
+ LDAP message layer, when possible, are abandoned, and when not
+ possible, are completed without transmission of the response. Also,
+ when the transport connection is closed, the client MUST NOT assume
+ that any uncompleted update operations have succeeded or failed.
+
+
+4. Elements of Protocol
+
+ The protocol is described using Abstract Syntax Notation One
+ ([ASN.1]), and is transferred using a subset of ASN.1 Basic Encoding
+ Rules ([BER]). Section 5 specifies how the protocol elements are
+ encoded and transferred.
+
+ In order to support future extensions to this protocol, extensibility
+ is implied where it is allowed per ASN.1 (i.e. sequence, set, choice,
+ and enumerated types are extensible). In addition, ellipses (...)
+ have been supplied in ASN.1 types that are explicitly extensible as
+ discussed in [LDAPIANA]. Because of the implied extensibility,
+ clients and servers MUST (unless otherwise specified) ignore trailing
+ SEQUENCE components whose tags they do not recognize.
+
+ Changes to the protocol other than through the extension mechanisms
+ described here require a different version number. A client indicates
+ the version it is using as part of the BindRequest, described in
+ Section 4.2. If a client has not sent a Bind, the server MUST assume
+ the client is using version 3 or later.
+
+ Clients may attempt to determine the protocol versions a server
+ supports by reading the 'supportedLDAPVersion' attribute from the
+ root DSE (DSA-Specific Entry) [Models].
+
+
+4.1. Common Elements
+
+ This section describes the LDAPMessage envelope Protocol Data Unit
+ (PDU) format, as well as data type definitions, which are used in the
+ protocol operations.
+
+
+4.1.1. Message Envelope
+
+ For the purposes of protocol exchanges, all protocol operations are
+ encapsulated in a common envelope, the LDAPMessage, which is defined
+ as follows:
+
+
+
+
+
+
+Sermersheim Internet-Draft - Expires April 2006 Page 5
+ Lightweight Directory Access Protocol Version 3
+
+ LDAPMessage ::= SEQUENCE {
+ messageID MessageID,
+ protocolOp CHOICE {
+ bindRequest BindRequest,
+ bindResponse BindResponse,
+ unbindRequest UnbindRequest,
+ searchRequest SearchRequest,
+ searchResEntry SearchResultEntry,
+ searchResDone SearchResultDone,
+ searchResRef SearchResultReference,
+ modifyRequest ModifyRequest,
+ modifyResponse ModifyResponse,
+ addRequest AddRequest,
+ addResponse AddResponse,
+ delRequest DelRequest,
+ delResponse DelResponse,
+ modDNRequest ModifyDNRequest,
+ modDNResponse ModifyDNResponse,
+ compareRequest CompareRequest,
+ compareResponse CompareResponse,
+ abandonRequest AbandonRequest,
+ extendedReq ExtendedRequest,
+ extendedResp ExtendedResponse,
+ ...,
+ intermediateResponse IntermediateResponse },
+ controls [0] Controls OPTIONAL }
+
+ MessageID ::= INTEGER (0 .. maxInt)
+
+ maxInt INTEGER ::= 2147483647 -- (2^^31 - 1) --
+
+ The ASN.1 type Controls is defined in Section 4.1.11.
+
+ The function of the LDAPMessage is to provide an envelope containing
+ common fields required in all protocol exchanges. At this time the
+ only common fields are the messageID and the controls.
+
+ If the server receives an LDAPMessage from the client in which the
+ LDAPMessage SEQUENCE tag cannot be recognized, the messageID cannot
+ be parsed, the tag of the protocolOp is not recognized as a request,
+ or the encoding structures or lengths of data fields are found to be
+ incorrect, then the server SHOULD return the Notice of Disconnection
+ described in Section 4.4.1, with the resultCode set to protocolError,
+ and MUST immediately terminate the LDAP session as described in
+ Section 5.3.
+
+ In other cases where the client or server cannot parse an LDAP PDU,
+ it SHOULD abruptly terminate the LDAP session (Section 5.3) where
+ further communication (including providing notice) would be
+ pernicious. Otherwise, server implementations MUST return an
+ appropriate response to the request, with the resultCode set to
+ protocolError.
+
+
+
+Sermersheim Internet-Draft - Expires April 2006 Page 6
+ Lightweight Directory Access Protocol Version 3
+
+4.1.1.1. Message ID
+
+ All LDAPMessage envelopes encapsulating responses contain the
+ messageID value of the corresponding request LDAPMessage.
+
+ The message ID of a request MUST have a non-zero value different from
+ the messageID of any other request in progress in the same LDAP
+ session. The zero value is reserved for the unsolicited notification
+ message.
+
+ Typical clients increment a counter for each request.
+
+ A client MUST NOT send a request with the same message ID as an
+ earlier request in the same LDAP session unless it can be determined
+ that the server is no longer servicing the earlier request (e.g.
+ after the final response is received, or a subsequent Bind
+ completes). Otherwise the behavior is undefined. For this purpose,
+ note that Abandon and successfully abandoned operations do not send
+ responses.
+
+
+4.1.2. String Types
+
+ The LDAPString is a notational convenience to indicate that, although
+ strings of LDAPString type encode as ASN.1 OCTET STRING types, the
+ [ISO10646] character set (a superset of [Unicode]) is used, encoded
+ following the [UTF-8] algorithm. Note that Unicode characters U+0000
+ through U+007F are the same as ASCII 0 through 127, respectively, and
+ have the same single octet UTF-8 encoding. Other Unicode characters
+ have a multiple octet UTF-8 encoding.
+
+ LDAPString ::= OCTET STRING -- UTF-8 encoded,
+ -- [ISO10646] characters
+
+ The LDAPOID is a notational convenience to indicate that the
+ permitted value of this string is a (UTF-8 encoded) dotted-decimal
+ representation of an OBJECT IDENTIFIER. Although an LDAPOID is
+ encoded as an OCTET STRING, values are limited to the definition of
+ <numericoid> given in Section 1.4 of [Models].
+
+ LDAPOID ::= OCTET STRING -- Constrained to <numericoid> [Models]
+
+ For example,
+
+ 1.3.6.1.4.1.1466.1.2.3
+
+
+4.1.3. Distinguished Name and Relative Distinguished Name
+
+ An LDAPDN is defined to be the representation of a Distinguished Name
+ (DN) after encoding according to the specification in [LDAPDN].
+
+ LDAPDN ::= LDAPString
+ -- Constrained to <distinguishedName> [LDAPDN]
+
+Sermersheim Internet-Draft - Expires April 2006 Page 7
+ Lightweight Directory Access Protocol Version 3
+
+
+ A RelativeLDAPDN is defined to be the representation of a Relative
+ Distinguished Name (RDN) after encoding according to the
+ specification in [LDAPDN].
+
+ RelativeLDAPDN ::= LDAPString
+ -- Constrained to <name-component> [LDAPDN]
+
+
+4.1.4. Attribute Descriptions
+
+ The definition and encoding rules for attribute descriptions are
+ defined in Section 2.5 of [Models]. Briefly, an attribute description
+ is an attribute type and zero or more options.
+
+ AttributeDescription ::= LDAPString
+ -- Constrained to <attributedescription>
+ -- [Models]
+
+
+4.1.5. Attribute Value
+
+ A field of type AttributeValue is an OCTET STRING containing an
+ encoded attribute value. The attribute value is encoded according to
+ the LDAP-specific encoding definition of its corresponding syntax.
+ The LDAP-specific encoding definitions for different syntaxes and
+ attribute types may be found in other documents and in particular
+ [Syntaxes].
+
+ AttributeValue ::= OCTET STRING
+
+ Note that there is no defined limit on the size of this encoding;
+ thus protocol values may include multi-megabyte attribute values
+ (e.g. photographs).
+
+ Attribute values may be defined which have arbitrary and non-
+ printable syntax. Implementations MUST NOT display nor attempt to
+ decode an attribute value if its syntax is not known. The
+ implementation may attempt to discover the subschema of the source
+ entry, and retrieve the descriptions of 'attributeTypes' from it
+ [Models].
+
+ Clients MUST only send attribute values in a request that are valid
+ according to the syntax defined for the attributes.
+
+
+4.1.6. Attribute Value Assertion
+
+ The AttributeValueAssertion (AVA) type definition is similar to the
+ one in the X.500 Directory standards. It contains an attribute
+ description and a matching rule ([Models] Section 4.1.3) assertion
+ value suitable for that type. Elements of this type are typically
+ used to assert that the value in assertionValue matches a value of an
+ attribute.
+
+Sermersheim Internet-Draft - Expires April 2006 Page 8
+ Lightweight Directory Access Protocol Version 3
+
+
+ AttributeValueAssertion ::= SEQUENCE {
+ attributeDesc AttributeDescription,
+ assertionValue AssertionValue }
+
+ AssertionValue ::= OCTET STRING
+
+ The syntax of the AssertionValue depends on the context of the LDAP
+ operation being performed. For example, the syntax of the EQUALITY
+ matching rule for an attribute is used when performing a Compare
+ operation. Often this is the same syntax used for values of the
+ attribute type, but in some cases the assertion syntax differs from
+ the value syntax. See objectIdentiferFirstComponentMatch in
+ [Syntaxes] for an example.
+
+
+4.1.7. Attribute and PartialAttribute
+
+ Attributes and partial attributes consist of an attribute description
+ and attribute values. A PartialAttribute allows zero values, while
+ Attribute requires at least one value.
+
+ PartialAttribute ::= SEQUENCE {
+ type AttributeDescription,
+ vals SET OF value AttributeValue }
+
+ Attribute ::= PartialAttribute(WITH COMPONENTS {
+ ...,
+ vals (SIZE(1..MAX))})
+
+ No two of the attribute values may be equivalent as described by
+ Section 2.3 of [Models]. The set of attribute values is unordered.
+ Implementations MUST NOT rely upon the ordering being repeatable.
+
+
+4.1.8. Matching Rule Identifier
+
+ Matching rules are defined in Section 4.1.3 of [Models]. A matching
+ rule is identified in the protocol by the printable representation of
+ either its <numericoid>, or one of its short name descriptors
+ [Models], e.g. 'caseIgnoreMatch' or '2.5.13.2'.
+
+ MatchingRuleId ::= LDAPString
+
+
+4.1.9. Result Message
+
+ The LDAPResult is the construct used in this protocol to return
+ success or failure indications from servers to clients. To various
+ requests, servers will return responses containing the elements found
+ in LDAPResult to indicate the final status of the protocol operation
+ request.
+
+
+
+Sermersheim Internet-Draft - Expires April 2006 Page 9
+ Lightweight Directory Access Protocol Version 3
+
+ LDAPResult ::= SEQUENCE {
+ resultCode ENUMERATED {
+ success (0),
+ operationsError (1),
+ protocolError (2),
+ timeLimitExceeded (3),
+ sizeLimitExceeded (4),
+ compareFalse (5),
+ compareTrue (6),
+ authMethodNotSupported (7),
+ strongerAuthRequired (8),
+ -- 9 reserved --
+ referral (10),
+ adminLimitExceeded (11),
+ unavailableCriticalExtension (12),
+ confidentialityRequired (13),
+ saslBindInProgress (14),
+ noSuchAttribute (16),
+ undefinedAttributeType (17),
+ inappropriateMatching (18),
+ constraintViolation (19),
+ attributeOrValueExists (20),
+ invalidAttributeSyntax (21),
+ -- 22-31 unused --
+ noSuchObject (32),
+ aliasProblem (33),
+ invalidDNSyntax (34),
+ -- 35 reserved for undefined isLeaf --
+ aliasDereferencingProblem (36),
+ -- 37-47 unused --
+ inappropriateAuthentication (48),
+ invalidCredentials (49),
+ insufficientAccessRights (50),
+ busy (51),
+ unavailable (52),
+ unwillingToPerform (53),
+ loopDetect (54),
+ -- 55-63 unused --
+ namingViolation (64),
+ objectClassViolation (65),
+ notAllowedOnNonLeaf (66),
+ notAllowedOnRDN (67),
+ entryAlreadyExists (68),
+ objectClassModsProhibited (69),
+ -- 70 reserved for CLDAP --
+ affectsMultipleDSAs (71),
+ -- 72-79 unused --
+ other (80),
+ ... },
+ matchedDN LDAPDN,
+ diagnosticMessage LDAPString,
+ referral [3] Referral OPTIONAL }
+
+
+
+Sermersheim Internet-Draft - Expires April 2006 Page 10
+ Lightweight Directory Access Protocol Version 3
+
+ The resultCode enumeration is extensible as defined in Section 3.6 of
+ [LDAPIANA]. The meanings of the listed result codes are given in
+ Appendix A. If a server detects multiple errors for an operation,
+ only one result code is returned. The server should return the result
+ code that best indicates the nature of the error encountered. Servers
+ may return substituted result codes to prevent unauthorized
+ disclosures.
+
+ The diagnosticMessage field of this construct may, at the server's
+ option, be used to return a string containing a textual, human-
+ readable (terminal control and page formatting characters should be
+ avoided) diagnostic message. As this diagnostic message is not
+ standardized, implementations MUST NOT rely on the values returned.
+ Diagnostic messages typically supplement the resultCode with
+ additional information. If the server chooses not to return a textual
+ diagnostic, the diagnosticMessage field MUST be empty.
+
+ For certain result codes (typically, but not restricted to
+ noSuchObject, aliasProblem, invalidDNSyntax and
+ aliasDereferencingProblem), the matchedDN field is set (subject to
+ access controls) to the name of the last entry (object or alias) used
+ in finding the target (or base) object. This will be a truncated form
+ of the provided name or, if an alias was dereferenced while
+ attempting to locate the entry, of the resulting name. Otherwise the
+ matchedDN field is empty.
+
+
+4.1.10. Referral
+
+ The referral result code indicates that the contacted server cannot
+ or will not perform the operation and that one or more other servers
+ may be able to. Reasons for this include:
+
+ - The target entry of the request is not held locally, but the
+ server has knowledge of its possible existence elsewhere.
+
+ - The operation is restricted on this server -- perhaps due to a
+ read-only copy of an entry to be modified.
+
+ The referral field is present in an LDAPResult if the resultCode is
+ set to referral, and absent with all other result codes. It contains
+ one or more references to one or more servers or services that may be
+ accessed via LDAP or other protocols. Referrals can be returned in
+ response to any operation request (except Unbind and Abandon which do
+ not have responses). At least one URI MUST be present in the
+ Referral.
+
+ During a Search operation, after the baseObject is located, and
+ entries are being evaluated, the referral is not returned. Instead,
+ continuation references, described in Section 4.5.3, are returned
+ when other servers would need to be contacted to complete the
+ operation.
+
+ Referral ::= SEQUENCE SIZE (1..MAX) OF uri URI
+
+Sermersheim Internet-Draft - Expires April 2006 Page 11
+ Lightweight Directory Access Protocol Version 3
+
+
+ URI ::= LDAPString -- limited to characters permitted in
+ -- URIs
+
+ If the client wishes to progress the operation, it contacts one of
+ the supported services found in the referral. If multiple URIs are
+ present, the client assumes that any supported URI may be used to
+ progress the operation.
+
+ Clients that follow referrals MUST ensure that they do not loop
+ between servers. They MUST NOT repeatedly contact the same server for
+ the same request with the same parameters. Some clients use a counter
+ that is incremented each time referral handling occurs for an
+ operation, and these kinds of clients MUST be able to handle at least
+ ten nested referrals while progressing the operation.
+
+ A URI for a server implementing LDAP and accessible via [TCP]/[IP]
+ (v4 or v6) is written as an LDAP URL according to [LDAPURL].
+
+ Referral values which are LDAP URLs follow these rules:
+
+ - If an alias was dereferenced, the <dn> part of the LDAP URL MUST
+ be present, with the new target object name.
+
+ - It is RECOMMENDED that the <dn> part be present to avoid
+ ambiguity.
+
+ - If the <dn> part is present, the client uses this name in its next
+ request to progress the operation, and if it is not present the
+ client uses the same name as in the original request.
+
+ - Some servers (e.g. participating in distributed indexing) may
+ provide a different filter in a URL of a referral for a Search
+ operation.
+
+ - If the <filter> part of the LDAP URL is present, the client uses
+ this filter in its next request to progress this Search, and if it
+ is not present the client uses the same filter as it used for that
+ Search.
+
+ - For Search, it is RECOMMENDED that the <scope> part be present to
+ avoid ambiguity.
+
+ - If the <scope> part is missing, the scope of the original Search
+ is used by the client to progress the operation.
+
+ - Other aspects of the new request may be the same as or different
+ from the request which generated the referral.
+
+ Other kinds of URIs may be returned. The syntax and semantics of such
+ URIs is left to future specifications. Clients may ignore URIs that
+ they do not support.
+
+
+
+Sermersheim Internet-Draft - Expires April 2006 Page 12
+ Lightweight Directory Access Protocol Version 3
+
+ UTF-8 encoded characters appearing in the string representation of a
+ DN, search filter, or other fields of the referral value may not be
+ legal for URIs (e.g. spaces) and MUST be escaped using the % method
+ in [URI].
+
+
+4.1.11. Controls
+
+ Controls provide a mechanism whereby the semantics and arguments of
+ existing LDAP operations may be extended. One or more controls may be
+ attached to a single LDAP message. A control only affects the
+ semantics of the message it is attached to.
+
+ Controls sent by clients are termed 'request controls' and those sent
+ by servers are termed 'response controls'.
+
+ Controls ::= SEQUENCE OF control Control
+
+ Control ::= SEQUENCE {
+ controlType LDAPOID,
+ criticality BOOLEAN DEFAULT FALSE,
+ controlValue OCTET STRING OPTIONAL }
+
+ The controlType field is the dotted-decimal representation of an
+ OBJECT IDENTIFIER which uniquely identifies the control. This
+ provides unambiguous naming of controls. Often, response control(s)
+ solicited by a request control share controlType values with the
+ request control.
+
+ The criticality field only has meaning in controls attached to
+ request messages (except UnbindRequest). For controls attached to
+ response messages and the UnbindRequest, the criticality field SHOULD
+ be FALSE, and MUST be ignored by the receiving protocol peer. A value
+ of TRUE indicates that it is unacceptable to perform the operation
+ without applying the semantics of the control. Specifically, the
+ criticality field is applied as follows:
+
+ - If the server does not recognize the control type, determines that
+ it is not appropriate for the operation, or is otherwise unwilling
+ to perform the operation with the control, and the criticality
+ field is TRUE, the server MUST NOT perform the operation, and for
+ operations that have a response message, MUST return with the
+ resultCode set to unavailableCriticalExtension.
+
+ - If the server does not recognize the control type, determines that
+ it is not appropriate for the operation, or is otherwise unwilling
+ to perform the operation with the control, and the criticality
+ field is FALSE, the server MUST ignore the control.
+
+ - Regardless of criticality, if a control is applied to an
+ operation, it is applied consistently and impartially to the
+ entire operation.
+
+
+
+Sermersheim Internet-Draft - Expires April 2006 Page 13
+ Lightweight Directory Access Protocol Version 3
+
+ The controlValue may contain information associated with the
+ controlType. Its format is defined by the specification of the
+ control. Implementations MUST be prepared to handle arbitrary
+ contents of the controlValue octet string, including zero bytes. It
+ is absent only if there is no value information which is associated
+ with a control of its type. When a controlValue is defined in terms
+ of ASN.1, and BER encoded according to Section 5.1, it also follows
+ the extensibility rules in Section 4.
+
+ Servers list the controlType of request controls they recognize in
+ the 'supportedControl' attribute in the root DSE (Section 5.1 of
+ [Models]).
+
+ Controls SHOULD NOT be combined unless the semantics of the
+ combination has been specified. The semantics of control
+ combinations, if specified, are generally found in the control
+ specification most recently published. When a combination of controls
+ is encountered whose semantics are invalid, not specified (or not
+ known), the message is considered to be not well-formed, thus the
+ operation fails with protocolError. Controls with a criticality of
+ FALSE may be ignored in order to arrive at a valid combination.
+ Additionally, unless order-dependent semantics are given in a
+ specification, the order of a combination of controls in the SEQUENCE
+ is ignored. Where the order is to be ignored but cannot be ignored by
+ the server, the message is considered not well-formed and the
+ operation fails with protocolError. Again, controls with a
+ criticality of FALSE may be ignored in order to arrive at a valid
+ combination.
+
+ This document does not specify any controls. Controls may be
+ specified in other documents. Documents detailing control extensions
+ are to provide for each control:
+
+ - the OBJECT IDENTIFIER assigned to the control,
+
+ - direction as to what value the sender should provide for the
+ criticality field (note: the semantics of the criticality field
+ are defined above should not be altered by the control's
+ specification),
+
+ - whether the controlValue field is present, and if so, the format
+ of its contents,
+
+ - the semantics of the control, and
+
+ - optionally, semantics regarding the combination of the control
+ with other controls.
+
+
+4.2. Bind Operation
+
+
+
+
+
+Sermersheim Internet-Draft - Expires April 2006 Page 14
+ Lightweight Directory Access Protocol Version 3
+
+ The function of the Bind operation is to allow authentication
+ information to be exchanged between the client and server. The Bind
+ operation should be thought of as the "authenticate" operation.
+ Operational, authentication, and security-related semantics of this
+ operation are given in [AuthMeth].
+
+ The Bind request is defined as follows:
+
+ BindRequest ::= [APPLICATION 0] SEQUENCE {
+ version INTEGER (1 .. 127),
+ name LDAPDN,
+ authentication AuthenticationChoice }
+
+ AuthenticationChoice ::= CHOICE {
+ simple [0] OCTET STRING,
+ -- 1 and 2 reserved
+ sasl [3] SaslCredentials,
+ ... }
+
+ SaslCredentials ::= SEQUENCE {
+ mechanism LDAPString,
+ credentials OCTET STRING OPTIONAL }
+
+ Fields of the BindRequest are:
+
+ - version: A version number indicating the version of the protocol
+ to be used at the LDAP message layer. This document describes
+ version 3 of the protocol. There is no version negotiation. The
+ client sets this field to the version it desires. If the server
+ does not support the specified version, it MUST respond with a
+ BindResponse where the resultCode is set to protocolError.
+
+ - name: If not empty, the name of the Directory object that the
+ client wishes to bind as. This field may take on a null value (a
+ zero length string) for the purposes of anonymous binds
+ ([AuthMeth] Section 5.1) or when using Simple Authentication and
+ Security Layer [SASL] authentication ([AuthMeth] Section 5.2).
+ Where the server attempts to locate the named object, it SHALL NOT
+ perform alias dereferencing.
+
+ - authentication: information used in authentication. This type is
+ extensible as defined in Section 3.7 of [LDAPIANA]. Servers that
+ do not support a choice supplied by a client return a BindResponse
+ with the resultCode set to authMethodNotSupported.
+
+ Textual passwords (consisting of a character sequence with a known
+ character set and encoding) transferred to the server using the
+ simple AuthenticationChoice SHALL be transferred as [UTF-8]
+ encoded [Unicode]. Prior to transfer, clients SHOULD prepare text
+ passwords as "query" strings by applying the [SASLprep] profile of
+ the [Stringprep] algorithm. Passwords consisting of other data
+ (such as random octets) MUST NOT be altered. The determination of
+ whether a password is textual is a local client matter.
+
+
+Sermersheim Internet-Draft - Expires April 2006 Page 15
+ Lightweight Directory Access Protocol Version 3
+
+
+4.2.1. Processing of the Bind Request
+
+ Before processing a BindRequest, all uncompleted operations MUST
+ either complete or be abandoned. The server may either wait for the
+ uncompleted operations to complete, or abandon them. The server then
+ proceeds to authenticate the client in either a single-step, or
+ multi-step Bind process. Each step requires the server to return a
+ BindResponse to indicate the status of authentication.
+
+ After sending a BindRequest, clients MUST NOT send further LDAP PDUs
+ until receiving the BindResponse. Similarly, servers SHOULD NOT
+ process or respond to requests received while processing a
+ BindRequest.
+
+ If the client did not bind before sending a request and receives an
+ operationsError to that request, it may then send a BindRequest. If
+ this also fails or the client chooses not to bind on the existing
+ LDAP session, it may terminate the LDAP session, re-establish it and
+ begin again by first sending a BindRequest. This will aid in
+ interoperating with servers implementing other versions of LDAP.
+
+ Clients may send multiple Bind requests to change the authentication
+ and/or security associations or to complete a multi-stage Bind
+ process. Authentication from earlier binds is subsequently ignored.
+
+ For some SASL authentication mechanisms, it may be necessary for the
+ client to invoke the BindRequest multiple times ([AuthMeth] Section
+ 5.2). Clients MUST NOT invoke operations between two Bind requests
+ made as part of a multi-stage Bind.
+
+ A client may abort a SASL bind negotiation by sending a BindRequest
+ with a different value in the mechanism field of SaslCredentials, or
+ an AuthenticationChoice other than sasl.
+
+ If the client sends a BindRequest with the sasl mechanism field as an
+ empty string, the server MUST return a BindResponse with the
+ resultCode set to authMethodNotSupported. This will allow clients to
+ abort a negotiation if it wishes to try again with the same SASL
+ mechanism.
+
+
+4.2.2. Bind Response
+
+ The Bind response is defined as follows.
+
+ BindResponse ::= [APPLICATION 1] SEQUENCE {
+ COMPONENTS OF LDAPResult,
+ serverSaslCreds [7] OCTET STRING OPTIONAL }
+
+ BindResponse consists simply of an indication from the server of the
+ status of the client's request for authentication.
+
+
+
+Sermersheim Internet-Draft - Expires April 2006 Page 16
+ Lightweight Directory Access Protocol Version 3
+
+ A successful Bind operation is indicated by a BindResponse with a
+ resultCode set to success. Otherwise, an appropriate result code is
+ set in the BindResponse. For BindResponse, the protocolError result
+ code may be used to indicate that the version number supplied by the
+ client is unsupported.
+
+ If the client receives a BindResponse where the resultCode is set to
+ protocolError, it is to assume that the server does not support this
+ version of LDAP. While the client may be able proceed with another
+ version of this protocol (this may or may not require closing and re-
+ establishing the transport connection), how to proceed with another
+ version of this protocol is beyond the scope of this document.
+ Clients which are unable or unwilling to proceed SHOULD terminate the
+ LDAP session.
+
+ The serverSaslCreds field is used as part of a SASL-defined bind
+ mechanism to allow the client to authenticate the server to which it
+ is communicating, or to perform "challenge-response" authentication.
+ If the client bound with the simple choice, or the SASL mechanism
+ does not require the server to return information to the client, then
+ this field SHALL NOT be included in the BindResponse.
+
+
+4.3. Unbind Operation
+
+ The function of the Unbind operation is to terminate an LDAP session.
+ The Unbind operation is not the antithesis of the Bind operation as
+ the name implies. The naming of these operations are historical. The
+ Unbind operation should be thought of as the "quit" operation.
+
+ The Unbind operation is defined as follows:
+
+ UnbindRequest ::= [APPLICATION 2] NULL
+
+ The client, upon transmission of the UnbindRequest, and the server,
+ upon receipt of the UnbindRequest are to gracefully terminate the
+ LDAP session as described in Section 5.3.
+
+ Uncompleted operations are handled as specified in Section 3.1.
+
+
+4.4. Unsolicited Notification
+
+ An unsolicited notification is an LDAPMessage sent from the server to
+ the client which is not in response to any LDAPMessage received by
+ the server. It is used to signal an extraordinary condition in the
+ server or in the LDAP session between the client and the server. The
+ notification is of an advisory nature, and the server will not expect
+ any response to be returned from the client.
+
+
+
+
+
+
+Sermersheim Internet-Draft - Expires April 2006 Page 17
+ Lightweight Directory Access Protocol Version 3
+
+ The unsolicited notification is structured as an LDAPMessage in which
+ the messageID is zero and protocolOp is set to the extendedResp
+ choice using the ExtendedResponse type (See Section 4.12). The
+ responseName field of the ExtendedResponse always contains an LDAPOID
+ which is unique for this notification.
+
+ One unsolicited notification (Notice of Disconnection) is defined in
+ this document. The specification of an unsolicited notification
+ consists of:
+
+ - the OBJECT IDENTIFIER assigned to the notification (to be
+ specified in the responseName,
+
+ - the format of the contents of the responseValue (if any),
+
+ - the circumstances which will cause the notification to be sent,
+ and
+
+ - the semantics of the message.
+
+
+4.4.1. Notice of Disconnection
+
+ This notification may be used by the server to advise the client that
+ the server is about to terminate the LDAP session on its own
+ initiative. This notification is intended to assist clients in
+ distinguishing between an exceptional server condition and a
+ transient network failure. Note that this notification is not a
+ response to an Unbind requested by the client. Uncompleted operations
+ are handled as specified in Section 3.1.
+
+ The responseName is 1.3.6.1.4.1.1466.20036, the responseValue field
+ is absent, and the resultCode is used to indicate the reason for the
+ disconnection. When the strongerAuthRequired resultCode is returned
+ with this message, it indicates that the server has detected that an
+ established security association between the client and server has
+ unexpectedly failed or been compromised.
+
+ Upon transmission of the Notice of Disconnection, the server
+ gracefully terminates the LDAP session as described in Section 5.3.
+
+
+4.5. Search Operation
+
+ The Search operation is used to request a server to return, subject
+ to access controls and other restrictions, a set of entries matching
+ a complex search criterion. This can be used to read attributes from
+ a single entry, from entries immediately subordinate to a particular
+ entry, or a whole subtree of entries.
+
+
+4.5.1. Search Request
+
+ The Search request is defined as follows:
+
+Sermersheim Internet-Draft - Expires April 2006 Page 18
+ Lightweight Directory Access Protocol Version 3
+
+
+ SearchRequest ::= [APPLICATION 3] SEQUENCE {
+ baseObject LDAPDN,
+ scope ENUMERATED {
+ baseObject (0),
+ singleLevel (1),
+ wholeSubtree (2),
+ ... },
+ derefAliases ENUMERATED {
+ neverDerefAliases (0),
+ derefInSearching (1),
+ derefFindingBaseObj (2),
+ derefAlways (3) },
+ sizeLimit INTEGER (0 .. maxInt),
+ timeLimit INTEGER (0 .. maxInt),
+ typesOnly BOOLEAN,
+ filter Filter,
+ attributes AttributeSelection }
+
+ AttributeSelection ::= SEQUENCE OF selector LDAPString
+ -- The LDAPString is constrained to
+ -- <attributeSelector> in Section 4.5.1.7
+
+ Filter ::= CHOICE {
+ and [0] SET SIZE (1..MAX) OF filter Filter,
+ or [1] SET SIZE (1..MAX) OF filter Filter,
+ not [2] Filter,
+ equalityMatch [3] AttributeValueAssertion,
+ substrings [4] SubstringFilter,
+ greaterOrEqual [5] AttributeValueAssertion,
+ lessOrEqual [6] AttributeValueAssertion,
+ present [7] AttributeDescription,
+ approxMatch [8] AttributeValueAssertion,
+ extensibleMatch [9] MatchingRuleAssertion,
+ ... }
+
+ SubstringFilter ::= SEQUENCE {
+ type AttributeDescription,
+ substrings SEQUENCE SIZE (1..MAX) OF substring CHOICE {
+ initial [0] AssertionValue, -- can occur at most once
+ any [1] AssertionValue,
+ final [2] AssertionValue } -- can occur at most once
+ }
+
+ MatchingRuleAssertion ::= SEQUENCE {
+ matchingRule [1] MatchingRuleId OPTIONAL,
+ type [2] AttributeDescription OPTIONAL,
+ matchValue [3] AssertionValue,
+ dnAttributes [4] BOOLEAN DEFAULT FALSE }
+
+
+
+
+
+
+Sermersheim Internet-Draft - Expires April 2006 Page 19
+ Lightweight Directory Access Protocol Version 3
+
+ Note that an X.500 "list"-like operation can be emulated by the
+ client requesting a singleLevel Search operation with a filter
+ checking for the presence of the 'objectClass' attribute, and that an
+ X.500 "read"-like operation can be emulated by a baseObject Search
+ operation with the same filter. A server which provides a gateway to
+ X.500 is not required to use the Read or List operations, although it
+ may choose to do so, and if it does, it must provide the same
+ semantics as the X.500 Search operation.
+
+
+4.5.1.1. SearchRequest.baseObject
+
+ The name of the base object entry (or possibly the root) relative to
+ which the Search is to be performed.
+
+
+4.5.1.2. SearchRequest.scope
+
+ Specifies the scope of the Search to be performed. The semantics (as
+ described in [X.511]) of the defined values of this field are:
+
+ baseObject: The scope is constrained to the entry named by
+ baseObject.
+
+ singleLevel: The scope is constrained to the immediate
+ subordinates of the entry named by baseObject.
+
+ wholeSubtree: the scope is constrained to the entry named by the
+ baseObject, and all its subordinates.
+
+
+4.5.1.3. SearchRequest.derefAliases
+
+ An indicator as to whether or not alias entries (as defined in
+ [Models]) are to be dereferenced during stages of the Search
+ operation.
+
+ The act of dereferencing an alias includes recursively dereferencing
+ aliases which refer to aliases.
+
+ Servers MUST detect looping while dereferencing aliases in order to
+ prevent denial of service attacks of this nature.
+
+ The semantics of the defined values of this field are:
+
+ neverDerefAliases: Do not dereference aliases in searching or in
+ locating the base object of the Search.
+
+
+
+
+
+
+
+
+Sermersheim Internet-Draft - Expires April 2006 Page 20
+ Lightweight Directory Access Protocol Version 3
+
+ derefInSearching: While searching subordinates of the base object,
+ dereference any alias within the search scope. Dereferenced
+ objects become the vertices of further search scopes where the
+ Search operation is also applied. If the search scope is
+ wholeSubtree, the Search continues in the subtree(s) of any
+ dereferenced object. If the search scope is singleLevel, the
+ search is applied to any dereferenced objects, and is not applied
+ to their subordinates. Servers SHOULD eliminate duplicate entries
+ that arise due to alias dereferencing while searching.
+
+ derefFindingBaseObj: Dereference aliases in locating the base
+ object of the Search, but not when searching subordinates of the
+ base object.
+
+ derefAlways: Dereference aliases both in searching and in locating
+ the base object of the Search.
+
+
+4.5.1.4. SearchRequest.sizeLimit
+
+ A size limit that restricts the maximum number of entries to be
+ returned as a result of the Search. A value of zero in this field
+ indicates that no client-requested size limit restrictions are in
+ effect for the Search. Servers may also enforce a maximum number of
+ entries to return.
+
+
+4.5.1.5. SearchRequest.timeLimit
+
+ A time limit that restricts the maximum time (in seconds) allowed for
+ a Search. A value of zero in this field indicates that no client-
+ requested time limit restrictions are in effect for the Search.
+ Servers may also enforce a maximum time limit for the Search.
+
+
+4.5.1.6. SearchRequest.typesOnly
+
+ An indicator as to whether Search results are to contain both
+ attribute descriptions and values, or just attribute descriptions.
+ Setting this field to TRUE causes only attribute descriptions (no
+ values) to be returned. Setting this field to FALSE causes both
+ attribute descriptions and values to be returned.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sermersheim Internet-Draft - Expires April 2006 Page 21
+ Lightweight Directory Access Protocol Version 3
+
+4.5.1.7. SearchRequest.filter
+
+ A filter that defines the conditions that must be fulfilled in order
+ for the Search to match a given entry.
+
+ The 'and', 'or' and 'not' choices can be used to form combinations of
+ filters. At least one filter element MUST be present in an 'and' or
+ 'or' choice. The others match against individual attribute values of
+ entries in the scope of the Search. (Implementor's note: the 'not'
+ filter is an example of a tagged choice in an implicitly-tagged
+ module. In BER this is treated as if the tag was explicit.)
+
+ A server MUST evaluate filters according to the three-valued logic of
+ [X.511] (1993) Clause 7.8.1. In summary, a filter is evaluated to
+ either "TRUE", "FALSE" or "Undefined". If the filter evaluates to
+ TRUE for a particular entry, then the attributes of that entry are
+ returned as part of the Search result (subject to any applicable
+ access control restrictions). If the filter evaluates to FALSE or
+ Undefined, then the entry is ignored for the Search.
+
+ A filter of the "and" choice is TRUE if all the filters in the SET OF
+ evaluate to TRUE, FALSE if at least one filter is FALSE, and
+ otherwise Undefined. A filter of the "or" choice is FALSE if all of
+ the filters in the SET OF evaluate to FALSE, TRUE if at least one
+ filter is TRUE, and Undefined otherwise. A filter of the 'not' choice
+ is TRUE if the filter being negated is FALSE, FALSE if it is TRUE,
+ and Undefined if it is Undefined.
+
+ A filter item evaluates to Undefined when the server would not be
+ able to determine whether the assertion value matches an entry.
+ Examples include:
+
+ - An attribute description in an equalityMatch, substrings,
+ greaterOrEqual, lessOrEqual, approxMatch or extensibleMatch
+ filter is not recognized by the server.
+
+ - The attribute type does not define the appropriate matching
+ rule.
+
+ - A MatchingRuleId in the extensibleMatch is not recognized by
+ the server or is not valid for the attribute type.
+
+ - The type of filtering requested is not implemented.
+
+ - The assertion value is invalid.
+
+ For example, if a server did not recognize the attribute type
+ shoeSize, the filters (shoeSize=*), (shoeSize=12), (shoeSize>=12) and
+ (shoeSize<=12) would each evaluate to Undefined.
+
+ Servers MUST NOT return errors if attribute descriptions or matching
+ rule ids are not recognized, assertion values are invalid, or the
+ assertion syntax is not supported. More details of filter processing
+ are given in Clause 7.8 of [X.511].
+
+Sermersheim Internet-Draft - Expires April 2006 Page 22
+ Lightweight Directory Access Protocol Version 3
+
+
+
+4.5.1.7.1. SearchRequest.filter.equalityMatch
+
+ The matching rule for an equalityMatch filter is defined by the
+ EQUALITY matching rule for the attribute type or subtype. The filter
+ is TRUE when the EQUALITY rule returns TRUE as applied to the
+ attribute or subtype and the asserted value.
+
+
+4.5.1.7.2. SearchRequest.filter.substrings
+
+ There SHALL be at most one 'initial', and at most one 'final' in the
+ 'substrings' of a SubstringFilter. If 'initial' is present, it SHALL
+ be the first element of 'substrings'. If 'final' is present, it SHALL
+ be the last element of 'substrings'.
+
+ The matching rule for an AssertionValue in a substrings filter item
+ is defined by the SUBSTR matching rule for the attribute type or
+ subtype. The filter is TRUE when the SUBSTR rule returns TRUE as
+ applied to the attribute or subtype and the asserted value.
+
+ Note that the AssertionValue in a substrings filter item conforms to
+ the assertion syntax of the EQUALITY matching rule for the attribute
+ type rather than the assertion syntax of the SUBSTR matching rule for
+ the attribute type. Conceptually, the entire SubstringFilter is
+ converted into an assertion value of the substrings matching rule
+ prior to applying the rule.
+
+
+4.5.1.7.3. SearchRequest.filter.greaterOrEqual
+
+ The matching rule for a greaterOrEqual filter is defined by the
+ ORDERING matching rule for the attribute type or subtype. The filter
+ is TRUE when the ORDERING rule returns FALSE as applied to the
+ attribute or subtype and the asserted value.
+
+
+4.5.1.7.4. SearchRequest.filter.lessOrEqual
+
+ The matching rules for a lessOrEqual filter are defined by the
+ ORDERING and EQUALITY matching rules for the attribute type or
+ subtype. The filter is TRUE when either the ORDERING or EQUALITY rule
+ returns TRUE as applied to the attribute or subtype and the asserted
+ value.
+
+
+4.5.1.7.5. SearchRequest.filter.present
+
+ A present filter is TRUE when there is an attribute or subtype of the
+ specified attribute description present in an entry, FALSE when no
+ attribute or subtype of the specified attribute description is
+ present in an entry, and Undefined otherwise.
+
+
+Sermersheim Internet-Draft - Expires April 2006 Page 23
+ Lightweight Directory Access Protocol Version 3
+
+
+4.5.1.7.6. SearchRequest.filter.approxMatch
+
+ An approxMatch filter is TRUE when there is a value of the attribute
+ type or subtype for which some locally-defined approximate matching
+ algorithm (e.g. spelling variations, phonetic match, etc.) returns
+ TRUE. If a value matches for equality, it also satisfies an
+ approximate match. If approximate matching is not supported for the
+ attribute, this filter item should be treated as an equalityMatch.
+
+
+4.5.1.7.7. SearchRequest.filter.extensibleMatch
+
+ The fields of the extensibleMatch filter item are evaluated as
+ follows:
+
+ - If the matchingRule field is absent, the type field MUST be
+ present, and an equality match is performed for that type.
+
+ - If the type field is absent and the matchingRule is present, the
+ matchValue is compared against all attributes in an entry which
+ support that matchingRule.
+
+ - If the type field is present and the matchingRule is present, the
+ matchValue is compared against the specified attribute type and
+ its subtypes.
+
+ - If the dnAttributes field is set to TRUE, the match is
+ additionally applied against all the AttributeValueAssertions in
+ an entry's distinguished name, and evaluates to TRUE if there is
+ at least one attribute or subtype in the distinguished name for
+ which the filter item evaluates to TRUE. The dnAttributes field is
+ present to alleviate the need for multiple versions of generic
+ matching rules (such as word matching), where one applies to
+ entries and another applies to entries and DN attributes as well.
+
+ The matchingRule used for evaluation determines the syntax for the
+ assertion value. Once the matchingRule and attribute(s) have been
+ determined, the filter item evaluates to TRUE if it matches at least
+ one attribute type or subtype in the entry, FALSE if it does not
+ match any attribute type or subtype in the entry, and Undefined if
+ the matchingRule is not recognized, the matchingRule is unsuitable
+ for use with the specified type, or the assertionValue is invalid.
+
+
+4.5.1.7. SearchRequest.attributes
+
+ A selection list of the attributes to be returned from each entry
+ which matches the search filter. Attributes which are subtypes of
+ listed attributes are implicitly included. LDAPString values of this
+ field are constrained to the following Augmented Backus-Naur Form
+ ([ABNF]):
+
+ attributeSelector = attributedescription / selectorspecial
+
+Sermersheim Internet-Draft - Expires April 2006 Page 24
+ Lightweight Directory Access Protocol Version 3
+
+
+ selectorspecial = noattrs / alluserattrs
+
+ noattrs = %x31.2E.31 ; "1.1"
+
+ alluserattrs = %x2A ; asterisk ("*")
+
+ The <attributedescription> production is defined in Section 2.5 of
+ [Models].
+
+ There are three special cases which may appear in the attributes
+ selection list:
+
+ - an empty list with no attributes,
+
+ - a list containing "*" (with zero or more attribute
+ descriptions), and
+
+ - a list containing only "1.1".
+
+ An empty list requests the return of all user attributes.
+
+ A list containing "*" requests the return of all user attributes
+ in addition to other listed (operational) attributes.
+
+ A list containing only the OID "1.1" indicates that no attributes
+ are to be returned. If "1.1" is provided with other
+ attributeSelector values, the "1.1" attributeSelector is ignored.
+ This OID was chosen because it does not (and can not) correspond
+ to any attribute in use.
+
+ Client implementors should note that even if all user attributes are
+ requested, some attributes and/or attribute values of the entry may
+ not be included in Search results due to access controls or other
+ restrictions. Furthermore, servers will not return operational
+ attributes, such as objectClasses or attributeTypes, unless they are
+ listed by name. Operational attributes are described in [Models].
+
+ Attributes are returned at most once in an entry. If an attribute
+ description is named more than once in the list, the subsequent names
+ are ignored. If an attribute description in the list is not
+ recognized, it is ignored by the server.
+
+
+4.5.2. Search Result
+
+ The results of the Search operation are returned as zero or more
+ SearchResultEntry and/or SearchResultReference messages, followed by
+ a single SearchResultDone message.
+
+ SearchResultEntry ::= [APPLICATION 4] SEQUENCE {
+ objectName LDAPDN,
+ attributes PartialAttributeList }
+
+
+Sermersheim Internet-Draft - Expires April 2006 Page 25
+ Lightweight Directory Access Protocol Version 3
+
+ PartialAttributeList ::= SEQUENCE OF
+ partialAttribute PartialAttribute
+
+ SearchResultReference ::= [APPLICATION 19] SEQUENCE
+ SIZE (1..MAX) OF uri URI
+
+ SearchResultDone ::= [APPLICATION 5] LDAPResult
+
+ Each SearchResultEntry represents an entry found during the Search.
+ Each SearchResultReference represents an area not yet explored during
+ the Search. The SearchResultEntry and SearchResultReference messages
+ may come in any order. Following all the SearchResultReference and
+ SearchResultEntry responses, the server returns a SearchResultDone
+ response, which contains an indication of success, or detailing any
+ errors that have occurred.
+
+ Each entry returned in a SearchResultEntry will contain all
+ appropriate attributes as specified in the attributes field of the
+ Search Request, subject to access control and other administrative
+ policy. Note that the PartialAttributeList may hold zero elements.
+ This may happen when none of the attributes of an entry were
+ requested, or could be returned. Note also that the partialAttribute
+ vals set may hold zero elements. This may happen when typesOnly is
+ requested, access controls prevent the return of values, or other
+ reasons.
+
+ Some attributes may be constructed by the server and appear in a
+ SearchResultEntry attribute list, although they are not stored
+ attributes of an entry. Clients SHOULD NOT assume that all attributes
+ can be modified, even if permitted by access control.
+
+ If the server's schema defines short names [Models] for an attribute
+ type then the server SHOULD use one of those names in attribute
+ descriptions for that attribute type (in preference to using the
+ <numericoid> [Models] format of the attribute type's object
+ identifier). The server SHOULD NOT use the short name if that name is
+ known by the server to be ambiguous, or otherwise likely to cause
+ interoperability problems.
+
+
+4.5.3. Continuation References in the Search Result
+
+ If the server was able to locate the entry referred to by the
+ baseObject but was unable or unwilling to search one or more non-
+ local entries, the server may return one or more
+ SearchResultReference messages, each containing a reference to
+ another set of servers for continuing the operation. A server MUST
+ NOT return any SearchResultReference messages if it has not located
+ the baseObject and thus has not searched any entries; in this case it
+ would return a SearchResultDone containing either a referral or
+ noSuchObject result code (depending on the server's knowledge of the
+ entry named in the baseObject).
+
+
+
+Sermersheim Internet-Draft - Expires April 2006 Page 26
+ Lightweight Directory Access Protocol Version 3
+
+ If a server holds a copy or partial copy of the subordinate naming
+ context (Section 5 of [Models]), it may use the search filter to
+ determine whether or not to return a SearchResultReference response.
+ Otherwise SearchResultReference responses are always returned when in
+ scope.
+
+ The SearchResultReference is of the same data type as the Referral.
+
+ If the client wishes to progress the Search, it issues a new Search
+ operation for each SearchResultReference that is returned. If
+ multiple URIs are present, the client assumes that any supported URI
+ may be used to progress the operation.
+
+ Clients that follow search continuation references MUST ensure that
+ they do not loop between servers. They MUST NOT repeatedly contact
+ the same server for the same request with the same parameters. Some
+ clients use a counter that is incremented each time search result
+ reference handling occurs for an operation, and these kinds of
+ clients MUST be able to handle at least ten nested referrals while
+ progressing the operation.
+
+ Note that the Abandon operation described in Section 4.11 applies
+ only to a particular operation sent at the LDAP message layer between
+ a client and server. The client must abandon subsequent Search
+ operations it wishes to individually.
+
+ A URI for a server implementing LDAP and accessible via [TCP]/[IP]
+ (v4 or v6) is written as an LDAP URL according to [LDAPURL].
+
+ SearchResultReference values which are LDAP URLs follow these rules:
+
+ - The <dn> part of the LDAP URL MUST be present, with the new target
+ object name. The client uses this name when following the
+ reference.
+
+ - Some servers (e.g. participating in distributed indexing) may
+ provide a different filter in the LDAP URL.
+
+ - If the <filter> part of the LDAP URL is present, the client uses
+ this filter in its next request to progress this Search, and if it
+ is not present the client uses the same filter as it used for that
+ Search.
+
+ - If the originating search scope was singleLevel, the <scope> part
+ of the LDAP URL will be "base".
+
+ - It is RECOMMENDED that the <scope> part be present to avoid
+ ambiguity. In the absence of a <scope> part, the scope of the
+ original Search request is assumed.
+
+ - Other aspects of the new Search request may be the same as or
+ different from the Search request which generated the
+ SearchResultReference.
+
+
+Sermersheim Internet-Draft - Expires April 2006 Page 27
+ Lightweight Directory Access Protocol Version 3
+
+ - The name of an unexplored subtree in a SearchResultReference need
+ not be subordinate to the base object.
+
+ Other kinds of URIs may be returned. The syntax and semantics of such
+ URIs is left to future specifications. Clients may ignore URIs that
+ they do not support.
+
+ UTF-8 encoded characters appearing in the string representation of a
+ DN, search filter, or other fields of the referral value may not be
+ legal for URIs (e.g. spaces) and MUST be escaped using the % method
+ in [URI].
+
+
+
+4.5.3.1. Examples
+
+ For example, suppose the contacted server (hosta) holds the entry
+ <DC=Example,DC=NET> and the entry <CN=Manager,DC=Example,DC=NET>. It
+ knows that both LDAP servers (hostb) and (hostc) hold
+ <OU=People,DC=Example,DC=NET> (one is the master and the other server
+ a shadow), and that LDAP-capable server (hostd) holds the subtree
+ <OU=Roles,DC=Example,DC=NET>. If a wholeSubtree Search of
+ <DC=Example,DC=NET> is requested to the contacted server, it may
+ return the following:
+
+ SearchResultEntry for DC=Example,DC=NET
+ SearchResultEntry for CN=Manager,DC=Example,DC=NET
+ SearchResultReference {
+ ldap://hostb/OU=People,DC=Example,DC=NET??sub
+ ldap://hostc/OU=People,DC=Example,DC=NET??sub }
+ SearchResultReference {
+ ldap://hostd/OU=Roles,DC=Example,DC=NET??sub }
+ SearchResultDone (success)
+
+ Client implementors should note that when following a
+ SearchResultReference, additional SearchResultReference may be
+ generated. Continuing the example, if the client contacted the server
+ (hostb) and issued the Search request for the subtree
+ <OU=People,DC=Example,DC=NET>, the server might respond as follows:
+
+ SearchResultEntry for OU=People,DC=Example,DC=NET
+ SearchResultReference {
+ ldap://hoste/OU=Managers,OU=People,DC=Example,DC=NET??sub }
+ SearchResultReference {
+ ldap://hostf/OU=Consultants,OU=People,DC=Example,DC=NET??sub }
+ SearchResultDone (success)
+
+ Similarly, if a singleLevel Search of <DC=Example,DC=NET> is
+ requested to the contacted server, it may return the following:
+
+
+
+
+
+
+Sermersheim Internet-Draft - Expires April 2006 Page 28
+ Lightweight Directory Access Protocol Version 3
+
+ SearchResultEntry for CN=Manager,DC=Example,DC=NET
+ SearchResultReference {
+ ldap://hostb/OU=People,DC=Example,DC=NET??base
+ ldap://hostc/OU=People,DC=Example,DC=NET??base }
+ SearchResultReference {
+ ldap://hostd/OU=Roles,DC=Example,DC=NET??base }
+ SearchResultDone (success)
+
+ If the contacted server does not hold the base object for the Search,
+ but has knowledge of its possible location, then it may return a
+ referral to the client. In this case, if the client requests a
+ subtree Search of <DC=Example,DC=ORG> to hosta, the server returns a
+ SearchResultDone containing a referral.
+
+ SearchResultDone (referral) {
+ ldap://hostg/DC=Example,DC=ORG??sub }
+
+
+4.6. Modify Operation
+
+ The Modify operation allows a client to request that a modification
+ of an entry be performed on its behalf by a server. The Modify
+ Request is defined as follows:
+
+ ModifyRequest ::= [APPLICATION 6] SEQUENCE {
+ object LDAPDN,
+ changes SEQUENCE OF change SEQUENCE {
+ operation ENUMERATED {
+ add (0),
+ delete (1),
+ replace (2),
+ ... },
+ modification PartialAttribute } }
+
+ Fields of the Modify Request are:
+
+ - object: The value of this field contains the name of the entry to
+ be modified. The server SHALL NOT perform any alias dereferencing
+ in determining the object to be modified.
+
+ - changes: A list of modifications to be performed on the entry. The
+ entire list of modifications MUST be performed in the order they
+ are listed as a single atomic operation. While individual
+ modifications may violate certain aspects of the directory schema
+ (such as the object class definition and DIT content rule), the
+ resulting entry after the entire list of modifications is
+ performed MUST conform to the requirements of the directory model
+ and controlling schema [Models].
+
+ - operation: Used to specify the type of modification being
+ performed. Each operation type acts on the following
+ modification. The values of this field have the following
+ semantics respectively:
+
+
+Sermersheim Internet-Draft - Expires April 2006 Page 29
+ Lightweight Directory Access Protocol Version 3
+
+ add: add values listed to the modification attribute,
+ creating the attribute if necessary;
+
+ delete: delete values listed from the modification attribute.
+ If no values are listed, or if all current values of the
+ attribute are listed, the entire attribute is removed;
+
+ replace: replace all existing values of the modification
+ attribute with the new values listed, creating the attribute
+ if it did not already exist. A replace with no value will
+ delete the entire attribute if it exists, and is ignored if
+ the attribute does not exist.
+
+ - modification: A PartialAttribute (which may have an empty SET
+ of vals) used to hold the attribute type or attribute type and
+ values being modified.
+
+ Upon receipt of a Modify Request, the server attempts to perform the
+ necessary modifications to the DIT and returns the result in a Modify
+ Response, defined as follows:
+
+ ModifyResponse ::= [APPLICATION 7] LDAPResult
+
+ The server will return to the client a single Modify Response
+ indicating either the successful completion of the DIT modification,
+ or the reason that the modification failed. Due to the requirement
+ for atomicity in applying the list of modifications in the Modify
+ Request, the client may expect that no modifications of the DIT have
+ been performed if the Modify Response received indicates any sort of
+ error, and that all requested modifications have been performed if
+ the Modify Response indicates successful completion of the Modify
+ operation. Whether the modification was applied or not cannot be
+ determined by the client if the Modify Response was not received
+ (e.g. the LDAP session was terminated or the Modify operation was
+ abandoned).
+
+ Servers MUST ensure that entries conform to user and system schema
+ rules or other data model constraints. The Modify operation cannot be
+ used to remove from an entry any of its distinguished values, i.e.
+ those values which form the entry's relative distinguished name. An
+ attempt to do so will result in the server returning the
+ notAllowedOnRDN result code. The Modify DN operation described in
+ Section 4.9 is used to rename an entry.
+
+ For attribute types which specify no equality matching, the rules in
+ Section 2.5.1 of [Models] are followed.
+
+ Note that due to the simplifications made in LDAP, there is not a
+ direct mapping of the changes in an LDAP ModifyRequest onto the
+ changes of a DAP ModifyEntry operation, and different implementations
+ of LDAP-DAP gateways may use different means of representing the
+ change. If successful, the final effect of the operations on the
+ entry MUST be identical.
+
+
+Sermersheim Internet-Draft - Expires April 2006 Page 30
+ Lightweight Directory Access Protocol Version 3
+
+
+4.7. Add Operation
+
+ The Add operation allows a client to request the addition of an entry
+ into the Directory. The Add Request is defined as follows:
+
+ AddRequest ::= [APPLICATION 8] SEQUENCE {
+ entry LDAPDN,
+ attributes AttributeList }
+
+ AttributeList ::= SEQUENCE OF attribute Attribute
+
+ Fields of the Add Request are:
+
+ - entry: the name of the entry to be added. The server SHALL NOT
+ dereference any aliases in locating the entry to be added.
+
+ - attributes: the list of attributes that, along with those from the
+ RDN, make up the content of the entry being added. Clients MAY or
+ MAY NOT include the RDN attribute(s) in this list. Clients MUST
+ NOT supply NO-USER-MODIFICATION attributes such as the
+ createTimestamp or creatorsName attributes, since the server
+ maintains these automatically.
+
+ Servers MUST ensure that entries conform to user and system schema
+ rules or other data model constraints. For attribute types which
+ specify no equality matching, the rules in Section 2.5.1 of [Models]
+ are followed (this applies to the naming attribute in addition to any
+ multi-valued attributes being added).
+
+ The entry named in the entry field of the AddRequest MUST NOT exist
+ for the AddRequest to succeed. The immediate superior (parent) of an
+ object or alias entry to be added MUST exist. For example, if the
+ client attempted to add <CN=JS,DC=Example,DC=NET>, the
+ <DC=Example,DC=NET> entry did not exist, and the <DC=NET> entry did
+ exist, then the server would return the noSuchObject result code with
+ the matchedDN field containing <DC=NET>.
+
+ Upon receipt of an Add Request, a server will attempt to add the
+ requested entry. The result of the Add attempt will be returned to
+ the client in the Add Response, defined as follows:
+
+ AddResponse ::= [APPLICATION 9] LDAPResult
+
+ A response of success indicates that the new entry has been added to
+ the Directory.
+
+
+4.8. Delete Operation
+
+ The Delete operation allows a client to request the removal of an
+ entry from the Directory. The Delete Request is defined as follows:
+
+ DelRequest ::= [APPLICATION 10] LDAPDN
+
+Sermersheim Internet-Draft - Expires April 2006 Page 31
+ Lightweight Directory Access Protocol Version 3
+
+
+ The Delete Request consists of the name of the entry to be deleted.
+ The server SHALL NOT dereference aliases while resolving the name of
+ the target entry to be removed.
+
+ Only leaf entries (those with no subordinate entries) can be deleted
+ with this operation.
+
+ Upon receipt of a Delete Request, a server will attempt to perform
+ the entry removal requested and return the result in the Delete
+ Response defined as follows:
+
+ DelResponse ::= [APPLICATION 11] LDAPResult
+
+
+4.9. Modify DN Operation
+
+ The Modify DN operation allows a client to change the Relative
+ Distinguished Name (RDN) of an entry in the Directory, and/or to move
+ a subtree of entries to a new location in the Directory. The Modify
+ DN Request is defined as follows:
+
+ ModifyDNRequest ::= [APPLICATION 12] SEQUENCE {
+ entry LDAPDN,
+ newrdn RelativeLDAPDN,
+ deleteoldrdn BOOLEAN,
+ newSuperior [0] LDAPDN OPTIONAL }
+
+ Fields of the Modify DN Request are:
+
+ - entry: the name of the entry to be changed. This entry may or may
+ not have subordinate entries.
+
+ - newrdn: the new RDN of the entry. The value of the old RDN is
+ supplied when moving the entry to a new superior without changing
+ its RDN. Attribute values of the new RDN not matching any
+ attribute value of the entry are added to the entry and an
+ appropriate error is returned if this fails.
+
+ - deleteoldrdn: a boolean field that controls whether the old RDN
+ attribute values are to be retained as attributes of the entry, or
+ deleted from the entry.
+
+ - newSuperior: if present, this is the name of an existing object
+ entry which becomes the immediate superior (parent) of the
+ existing entry.
+
+ The server SHALL NOT dereference any aliases in locating the objects
+ named in entry or newSuperior.
+
+ Upon receipt of a ModifyDNRequest, a server will attempt to perform
+ the name change and return the result in the Modify DN Response,
+ defined as follows:
+
+
+Sermersheim Internet-Draft - Expires April 2006 Page 32
+ Lightweight Directory Access Protocol Version 3
+
+ ModifyDNResponse ::= [APPLICATION 13] LDAPResult
+
+ For example, if the entry named in the entry field was <cn=John
+ Smith,c=US>, the newrdn field was <cn=John Cougar Smith>, and the
+ newSuperior field was absent, then this operation would attempt to
+ rename the entry to be <cn=John Cougar Smith,c=US>. If there was
+ already an entry with that name, the operation would fail with the
+ entryAlreadyExists result code.
+
+ Servers MUST ensure that entries conform to user and system schema
+ rules or other data model constraints. For attribute types which
+ specify no equality matching, the rules in Section 2.5.1 of [Models]
+ are followed (this pertains to newrdn and deleteoldrdn).
+
+ The object named in newSuperior MUST exist. For example, if the
+ client attempted to add <CN=JS,DC=Example,DC=NET>, the
+ <DC=Example,DC=NET> entry did not exist, and the <DC=NET> entry did
+ exist, then the server would return the noSuchObject result code with
+ the matchedDN field containing <DC=NET>.
+
+ If the deleteoldrdn field is TRUE, the attribute values forming the
+ old RDN but not the new RDN are deleted from the entry. If the
+ deleteoldrdn field is FALSE, the attribute values forming the old RDN
+ will be retained as non-distinguished attribute values of the entry.
+
+ Note that X.500 restricts the ModifyDN operation to only affect
+ entries that are contained within a single server. If the LDAP server
+ is mapped onto DAP, then this restriction will apply, and the
+ affectsMultipleDSAs result code will be returned if this error
+ occurred. In general, clients MUST NOT expect to be able to perform
+ arbitrary movements of entries and subtrees between servers or
+ between naming contexts.
+
+
+4.10. Compare Operation
+
+ The Compare operation allows a client to compare an assertion value
+ with the values of a particular attribute in a particular entry in
+ the Directory. The Compare Request is defined as follows:
+
+ CompareRequest ::= [APPLICATION 14] SEQUENCE {
+ entry LDAPDN,
+ ava AttributeValueAssertion }
+
+ Fields of the Compare Request are:
+
+ - entry: the name of the entry to be compared. The server SHALL NOT
+ dereference any aliases in locating the entry to be compared.
+
+ - ava: holds the attribute value assertion to be compared.
+
+ Upon receipt of a Compare Request, a server will attempt to perform
+ the requested comparison and return the result in the Compare
+ Response, defined as follows:
+
+Sermersheim Internet-Draft - Expires April 2006 Page 33
+ Lightweight Directory Access Protocol Version 3
+
+
+ CompareResponse ::= [APPLICATION 15] LDAPResult
+
+ The resultCode is set to compareTrue, compareFalse, or an appropriate
+ error. compareTrue indicates that the assertion value in the ava
+ field matches a value of the attribute or subtype according to the
+ attribute's EQUALITY matching rule. compareFalse indicates that the
+ assertion value in the ava field and the values of the attribute or
+ subtype did not match. Other result codes indicate either that the
+ result of the comparison was Undefined (Section 4.5.1), or that some
+ error occurred.
+
+ Note that some directory systems may establish access controls which
+ permit the values of certain attributes (such as userPassword) to be
+ compared but not interrogated by other means.
+
+
+4.11. Abandon Operation
+
+ The function of the Abandon operation is to allow a client to request
+ that the server abandon an uncompleted operation. The Abandon Request
+ is defined as follows:
+
+ AbandonRequest ::= [APPLICATION 16] MessageID
+
+ The MessageID is that of an operation which was requested earlier at
+ this LDAP message layer. The Abandon request itself has its own
+ MessageID. This is distinct from the MessageID of the earlier
+ operation being abandoned.
+
+ There is no response defined in the Abandon operation. Upon receipt
+ of an AbandonRequest, the server MAY abandon the operation identified
+ by the MessageID. Since the client cannot tell the difference between
+ a successfully abandoned operation and an uncompleted operation, the
+ application of the Abandon operation is limited to uses where the
+ client does not require an indication of its outcome.
+
+ Abandon, Bind, Unbind, and StartTLS operations cannot be abandoned.
+
+ In the event that a server receives an Abandon Request on a Search
+ operation in the midst of transmitting responses to the Search, that
+ server MUST cease transmitting entry responses to the abandoned
+ request immediately, and MUST NOT send the SearchResultDone. Of
+ course, the server MUST ensure that only properly encoded LDAPMessage
+ PDUs are transmitted.
+
+ The ability to abandon other (particularly update) operations is at
+ the discretion of the server.
+
+ Clients should not send Abandon requests for the same operation
+ multiple times, and MUST also be prepared to receive results from
+ operations it has abandoned (since these may have been in transit
+ when the Abandon was requested, or are not able to be abandoned).
+
+
+Sermersheim Internet-Draft - Expires April 2006 Page 34
+ Lightweight Directory Access Protocol Version 3
+
+ Servers MUST discard Abandon requests for message IDs they do not
+ recognize, for operations which cannot be abandoned, and for
+ operations which have already been abandoned.
+
+
+4.12. Extended Operation
+
+ The Extended operation allows additional operations to be defined for
+ services not already available in the protocol. For example, to Add
+ operations to install transport layer security (see Section 4.14).
+
+ The Extended operation allows clients to make requests and receive
+ responses with predefined syntaxes and semantics. These may be
+ defined in RFCs or be private to particular implementations.
+
+ Each Extended operation consists of an Extended request and an
+ Extended response.
+
+ ExtendedRequest ::= [APPLICATION 23] SEQUENCE {
+ requestName [0] LDAPOID,
+ requestValue [1] OCTET STRING OPTIONAL }
+
+ The requestName is a dotted-decimal representation of the unique
+ OBJECT IDENTIFIER corresponding to the request. The requestValue is
+ information in a form defined by that request, encapsulated inside an
+ OCTET STRING.
+
+ The server will respond to this with an LDAPMessage containing an
+ ExtendedResponse.
+
+ ExtendedResponse ::= [APPLICATION 24] SEQUENCE {
+ COMPONENTS OF LDAPResult,
+ responseName [10] LDAPOID OPTIONAL,
+ responseValue [11] OCTET STRING OPTIONAL }
+
+ The responseName field, when present, contains an LDAPOID which is
+ unique for this extended operation or response. This field is
+ optional (even when the extension specification specifies an LDAPOID
+ to be returned in the field). The field will be absent whenever the
+ server is unable or unwilling to determine the appropriate LDAPOID to
+ return, for instance when the requestName cannot be parsed or its
+ value is not recognized.
+
+ Where the requestName is not recognized, the server returns
+ protocolError (The server may return protocolError in other cases).
+
+ The requestValue and responseValue fields contain information
+ associated with the operation. The format of these fields is defined
+ by the specification of the Extended operation. Implementations MUST
+ be prepared to handle arbitrary contents of these fields, including
+ zero bytes. Values that are defined in terms of ASN.1 and BER encoded
+ according to Section 5.1, also follow the extensibility rules in
+ Section 4.
+
+
+Sermersheim Internet-Draft - Expires April 2006 Page 35
+ Lightweight Directory Access Protocol Version 3
+
+ Servers list the requestName of Extended Requests they recognize in
+ the 'supportedExtension' attribute in the root DSE (Section 5.1 of
+ [Models]).
+
+ Extended operations may be specified in other documents. The
+ specification of an Extended operation consists of:
+
+ - the OBJECT IDENTIFIER assigned to the requestName,
+
+ - the OBJECT IDENTIFIER (if any) assigned to the responseName (note
+ that the same OBJECT IDENTIFIER may be used for both the
+ requestName and responseName),
+
+ - the format of the contents of the requestValue and responseValue
+ (if any), and
+
+ - the semantics of the operation.
+
+
+4.13. IntermediateResponse Message
+
+ While the Search operation provides a mechanism to return multiple
+ response messages for a single Search request, other operations, by
+ nature, do not provide for multiple response messages.
+
+ The IntermediateResponse message provides a general mechanism for
+ defining single-request/multiple-response operations in LDAP. This
+ message is intended to be used in conjunction with the Extended
+ operation to define new single-request/multiple-response operations
+ or in conjunction with a control when extending existing LDAP
+ operations in a way that requires them to return Intermediate
+ response information.
+
+ It is intended that the definitions and descriptions of Extended
+ operations and controls that make use of the IntermediateResponse
+ message will define the circumstances when an IntermediateResponse
+ message can be sent by a server and the associated meaning of an
+ IntermediateResponse message sent in a particular circumstance.
+
+ IntermediateResponse ::= [APPLICATION 25] SEQUENCE {
+ responseName [0] LDAPOID OPTIONAL,
+ responseValue [1] OCTET STRING OPTIONAL }
+
+ IntermediateResponse messages SHALL NOT be returned to the client
+ unless the client issues a request that specifically solicits their
+ return. This document defines two forms of solicitation: Extended
+ operation and request control. IntermediateResponse messages are
+ specified in documents describing the manner in which they are
+ solicited (i.e. in the Extended operation or request control
+ specification that uses them). These specifications include:
+
+ - the OBJECT IDENTIFIER (if any) assigned to the responseName,
+
+ - the format of the contents of the responseValue (if any), and
+
+Sermersheim Internet-Draft - Expires April 2006 Page 36
+ Lightweight Directory Access Protocol Version 3
+
+
+ - the semantics associated with the IntermediateResponse message.
+
+ Extensions that allow the return of multiple types of
+ IntermediateResponse messages SHALL identify those types using unique
+ responseName values (note that one of these may specify no value).
+
+ Sections 4.13.1 and 4.13.2 describe additional requirements on the
+ inclusion of responseName and responseValue in IntermediateResponse
+ messages.
+
+
+4.13.1. Usage with LDAP ExtendedRequest and ExtendedResponse
+
+ A single-request/multiple-response operation may be defined using a
+ single ExtendedRequest message to solicit zero or more
+ IntermediateResponse messages of one or more kinds followed by an
+ ExtendedResponse message.
+
+
+4.13.2. Usage with LDAP Request Controls
+
+ A control's semantics may include the return of zero or more
+ IntermediateResponse messages prior to returning the final result
+ code for the operation. One or more kinds of IntermediateResponse
+ messages may be sent in response to a request control.
+
+ All IntermediateResponse messages associated with request controls
+ SHALL include a responseName. This requirement ensures that the
+ client can correctly identify the source of IntermediateResponse
+ messages when:
+
+ - two or more controls using IntermediateResponse messages are
+ included in a request for any LDAP operation or
+
+ - one or more controls using IntermediateResponse messages are
+ included in a request with an LDAP Extended operation that uses
+ IntermediateResponse messages.
+
+
+4.14. StartTLS Operation
+
+ The Start Transport Layer Security (StartTLS) operation's purpose is
+ to initiate installation of a TLS layer. The StartTLS operation is
+ defined using the Extended operation mechanism described in Section
+ 4.12.
+
+
+
+
+
+
+
+
+
+Sermersheim Internet-Draft - Expires April 2006 Page 37
+ Lightweight Directory Access Protocol Version 3
+
+4.14.1. StartTLS Request
+
+ A client requests TLS establishment by transmitting a StartTLS
+ request message to the server. The StartTLS request is defined in
+ terms of an ExtendedRequest. The requestName is
+ "1.3.6.1.4.1.1466.20037", and the requestValue field is always
+ absent.
+
+ The client MUST NOT send any LDAP PDUs at this LDAP message layer
+ following this request until it receives a StartTLS Extended response
+ and, in the case of a successful response, completes TLS
+ negotiations.
+
+ Detected sequencing problems (particularly those detailed in Section
+ 3.1.1 of [AuthMeth]) result in the resultCode being set to
+ operationsError.
+
+ If the server does not support TLS (whether by design or by current
+ configuration), it returns with the resultCode set to protocolError
+ as described in Section 4.12.
+
+
+4.14.2. StartTLS Response
+
+ When a StartTLS request is received, servers supporting the operation
+ MUST return a StartTLS response message to the requestor. The
+ responseName is "1.3.6.1.4.1.1466.20037" when provided (See 4.12).
+ The responseValue is always absent.
+
+ If the server is willing and able to negotiate TLS, it returns the
+ StartTLS response with the resultCode set to success. Upon client
+ receipt of a successful StartTLS response, protocol peers may
+ commence with TLS negotiation as discussed in Section 3 of
+ [AuthMeth].
+
+ If the server is otherwise unwilling or unable to perform this
+ operation, the server is to return an appropriate result code
+ indicating the nature of the problem. For example, if the TLS
+ subsystem is not presently available, the server may indicate so by
+ returning with the resultCode set to unavailable. In cases where a
+ non-success result code is returned, the LDAP session is left without
+ a TLS layer.
+
+
+4.14.3. Removal of the TLS Layer
+
+ Either the client or server MAY remove the TLS layer and leave the
+ LDAP message layer intact by sending and receiving a TLS closure
+ alert.
+
+
+
+
+Sermersheim Internet-Draft - Expires April 2006 Page 38
+ Lightweight Directory Access Protocol Version 3
+
+ The initiating protocol peer sends the TLS closure alert and MUST
+ wait until it receives a TLS closure alert from the other peer before
+ sending further LDAP PDUs.
+
+ When a protocol peer receives the initial TLS closure alert, it may
+ choose to allow the LDAP message layer to remain intact. In this
+ case, it MUST immediately transmit a TLS closure alert. Following
+ this, it MAY send and receive LDAP PDUs.
+
+ Protocol peers MAY terminate the LDAP session after sending or
+ receiving a TLS closure alert.
+
+
+5. Protocol Encoding, Connection, and Transfer
+
+ This protocol is designed to run over connection-oriented, reliable
+ transports, where the data stream is divided into octets (8-bit
+ units), with each octet and each bit being significant.
+
+ One underlying service, LDAP over TCP, is defined in Section
+ 5.2. This service is generally applicable to applications providing
+ or consuming X.500-based directory services on the Internet. This
+ specification was generally written with the TCP mapping in mind.
+ Specifications detailing other mappings may encounter various
+ obstacles.
+
+ Implementations of LDAP over TCP MUST implement the mapping as
+ described in Section 5.2.
+
+ This table illustrates the relationship between the different layers
+ involved in an exchange between two protocol peers:
+
+ +----------------------+
+ | LDAP message layer |
+ +----------------------+ > LDAP PDUs
+ +----------------------+ < data
+ | SASL layer |
+ +----------------------+ > SASL-protected data
+ +----------------------+ < data
+ | TLS layer |
+ Application +----------------------+ > TLS-protected data
+ ------------+----------------------+ < data
+ Transport | transport connection |
+ +----------------------+
+
+
+5.1. Protocol Encoding
+
+ The protocol elements of LDAP SHALL be encoded for exchange using the
+ Basic Encoding Rules [BER] of [ASN.1] with the following
+ restrictions:
+
+ - Only the definite form of length encoding is used.
+
+
+Sermersheim Internet-Draft - Expires April 2006 Page 39
+ Lightweight Directory Access Protocol Version 3
+
+
+ - OCTET STRING values are encoded in the primitive form only.
+
+ - If the value of a BOOLEAN type is true, the encoding of the value
+ octet is set to hex "FF".
+
+ - If a value of a type is its default value, it is absent. Only some
+ BOOLEAN and INTEGER types have default values in this protocol
+ definition.
+
+ These restrictions are meant to ease the overhead of encoding and
+ decoding certain elements in BER.
+
+ These restrictions do not apply to ASN.1 types encapsulated inside of
+ OCTET STRING values, such as attribute values, unless otherwise
+ stated.
+
+
+5.2. Transmission Control Protocol (TCP)
+
+ The encoded LDAPMessage PDUs are mapped directly onto the [TCP]
+ bytestream using the BER-based encoding described in Section 5.1. It
+ is recommended that server implementations running over the TCP
+ provide a protocol listener on the Internet Assigned Numbers
+ Authority (IANA)-assigned LDAP port, 389 [PortReg]. Servers may
+ instead provide a listener on a different port number. Clients MUST
+ support contacting servers on any valid TCP port.
+
+
+5.3. Termination of the LDAP session
+
+ Termination of the LDAP session is typically initiated by the client
+ sending an UnbindRequest (Section 4.3), or by the server sending a
+ Notice of Disconnection (Section 4.4.1). In these cases each protocol
+ peer gracefully terminates the LDAP session by ceasing exchanges at
+ the LDAP message layer, tearing down any SASL layer, tearing down any
+ TLS layer, and closing the transport connection.
+
+ A protocol peer may determine that the continuation of any
+ communication would be pernicious, and in this case may abruptly
+ terminate the session by ceasing communication and closing the
+ transport connection.
+
+ In either case, when the LDAP session is terminated, uncompleted
+ operations are handled as specified in Section 3.1.
+
+
+6. Security Considerations
+
+ This version of the protocol provides facilities for simple
+ authentication using a cleartext password, as well as any [SASL]
+ mechanism. Installing SASL and/or TLS layers can provide integrity
+ and other data security services.
+
+
+Sermersheim Internet-Draft - Expires April 2006 Page 40
+ Lightweight Directory Access Protocol Version 3
+
+ It is also permitted that the server can return its credentials to
+ the client, if it chooses to do so.
+
+ Use of cleartext password is strongly discouraged where the
+ underlying transport service cannot guarantee confidentiality and may
+ result in disclosure of the password to unauthorized parties.
+
+ Servers are encouraged to prevent directory modifications by clients
+ that have authenticated anonymously [AuthMeth].
+
+ Security considerations for authentication methods, SASL mechanisms,
+ and TLS are described in [AuthMeth].
+
+ It should be noted that SASL authentication exchanges do not provide
+ data confidentiality nor integrity protection for the version or name
+ fields of the BindRequest nor the resultCode, diagnosticMessage, or
+ referral fields of the BindResponse nor of any information contained
+ in controls attached to Bind requests or responses. Thus information
+ contained in these fields SHOULD NOT be relied on unless otherwise
+ protected (such as by establishing protections at the transport
+ layer).
+
+ Implementors should note that various security factors, including
+ authentication and authorization information and data security
+ services may change during the course of the LDAP session, or even
+ during the performance of a particular operation. For instance,
+ credentials could expire, authorization identities or access controls
+ could change, or the underlying security layer(s) could be replaced
+ or terminated. Implementations should be robust in the handling of
+ changing security factors.
+ In some cases, it may be appropriate to continue the operation even
+ in light of security factor changes. For instance, it may be
+ appropriate to continue an Abandon operation regardless of the
+ change, or to continue an operation when the change upgraded (or
+ maintained) the security factor. In other cases, it may be
+ appropriate to fail, or alter the processing of the operation. For
+ instance, if confidential protections were removed, it would be
+ appropriate to either fail a request to return sensitive data, or
+ minimally, to exclude the return of sensitive data.
+
+ Implementations which cache attributes and entries obtained via LDAP
+ MUST ensure that access controls are maintained if that information
+ is to be provided to multiple clients, since servers may have access
+ control policies which prevent the return of entries or attributes in
+ Search results except to particular authenticated clients. For
+ example, caches could serve result information only to the client
+ whose request caused it to be in the cache.
+
+
+
+
+
+
+
+
+Sermersheim Internet-Draft - Expires April 2006 Page 41
+ Lightweight Directory Access Protocol Version 3
+
+ Servers may return referrals or Search result references which
+ redirect clients to peer servers. It is possible for a rogue
+ application to inject such referrals into the data stream in an
+ attempt to redirect a client to a rogue server. Clients are advised
+ to be aware of this, and possibly reject referrals when
+ confidentiality measures are not in place. Clients are advised to
+ reject referrals from the StartTLS operation.
+
+ The matchedDN and diagnosticMessage fields, as well as some
+ resultCode values (e.g., attributeOrValueExists and
+ entryAlreadyExists), could disclose the presence or absence of
+ specific data in the directory which is subject to access and other
+ administrative controls. Server implementations should restrict
+ access to protected information equally under both normal and error
+ conditions.
+
+ Protocol peers MUST be prepared to handle invalid and arbitrary
+ length protocol encodings. Invalid protocol encodings include: BER
+ encoding exceptions, format string and UTF-8 encoding exceptions,
+ overflow exceptions, integer value exceptions, and binary mode on/off
+ flag exceptions. The LDAPv3 PROTOS [PROTOS-LDAP] test suite provides
+ excellent examples of these exceptions and test cases used to
+ discover flaws.
+
+ In the event that a protocol peer senses an attack which in its
+ nature could cause damage due to further communication at any layer
+ in the LDAP session, the protocol peer should abruptly terminate the
+ LDAP session as described in Section 5.3.
+
+
+7. Acknowledgements
+
+ This document is based on RFC 2251 by Mark Wahl, Tim Howes, and Steve
+ Kille. RFC 2251 was a product of the IETF ASID Working Group.
+
+ It is also based on RFC 2830 by Jeff Hodges, RL "Bob" Morgan, and
+ Mark Wahl. RFC 2830 was a product of the IETF LDAPEXT Working Group.
+
+ It is also based on RFC 3771 by Roger Harrison, and Kurt Zeilenga.
+ RFC 3771 was an individual submission to the IETF.
+
+ This document is a product of the IETF LDAPBIS Working Group.
+ Significant contributors of technical review and content include Kurt
+ Zeilenga, Steven Legg, and Hallvard Furuseth.
+
+
+8. Normative References
+
+ [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
+ Specifications: ABNF", draft-crocker-abnf-rfc2234bis-
+ xx.txt, (a work in progress).
+
+
+
+
+Sermersheim Internet-Draft - Expires April 2006 Page 42
+ Lightweight Directory Access Protocol Version 3
+
+ [ASN.1] ITU-T Recommendation X.680 (07/2002) | ISO/IEC 8824-1:2002
+ "Information Technology - Abstract Syntax Notation One
+ (ASN.1): Specification of basic notation"
+
+ [AuthMeth] Harrison, R., "LDAP: Authentication Methods and Connection
+ Level Security Mechanisms", draft-ietf-ldapbis-authmeth-
+ xx.txt, (a work in progress).
+
+ [BER] ITU-T Rec. X.690 (07/2002) | ISO/IEC 8825-1:2002,
+ "Information technology - ASN.1 encoding rules:
+ Specification of Basic Encoding Rules (BER), Canonical
+ Encoding Rules (CER) and Distinguished Encoding Rules
+ (DER)", 2002.
+
+ [IP] Postel, J., "Internet Protocol", STD5 and RFC 791,
+ September 1981
+
+ [ISO10646] Universal Multiple-Octet Coded Character Set (UCS) -
+ Architecture and Basic Multilingual Plane, ISO/IEC 10646-1
+ : 1993.
+
+ [Keyword] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", RFC 2119, March 1997.
+
+ [LDAPDN] Zeilenga, K., "LDAP: String Representation of
+ Distinguished Names", draft-ietf-ldapbis-dn-xx.txt, (a
+ work in progress).
+
+ [LDAPIANA] Zeilenga, K., "IANA Considerations for LDAP", draft-ietf-
+ ldapbis-bcp64-xx.txt, (a work in progress).
+
+ [LDAPURL] Smith, M., "LDAP: Uniform Resource Locator", draft-ietf-
+ ldapbis-url-xx.txt, (a work in progress).
+
+ [Models] Zeilenga, K., "LDAP: Directory Information Models", draft-
+ ietf-ldapbis-models-xx.txt (a work in progress).
+
+ [Roadmap] Zeilenga, K., "LDAP: Technical Specification Road Map",
+ draft-ietf-ldapbis-roadmap-xx.txt (a work in progress).
+
+ [SASL] Melnikov, A., "Simple Authentication and Security Layer",
+ draft-ietf-sasl-rfc2222bis-xx.txt (a work in progress).
+
+ [SASLPrep] Zeilenga, K., "Stringprep profile for user names and
+ passwords", draft-ietf-sasl-saslprep-xx.txt, (a work in
+ progress).
+
+ [StringPrep] Hoffman P. and M. Blanchet, "Preparation of
+ Internationalized Strings ('stringprep')", draft-hoffman-
+ rfc3454bis-xx.txt, a work in progress.
+
+ [Syntaxes] Legg, S., and K. Dally, "LDAP: Syntaxes and Matching
+ Rules", draft-ietf-ldapbis-syntaxes-xx.txt, (a work in
+ progress).
+
+Sermersheim Internet-Draft - Expires April 2006 Page 43
+ Lightweight Directory Access Protocol Version 3
+
+
+ [TCP] Postel, J., "Transmission Control Protocol", STD7 and RFC
+ 793, September 1981
+
+ [TLS] Dierks, T. and C. Allen. "The TLS Protocol Version 1.1",
+ draft-ietf-tls-rfc2246-bis-xx.txt, a work in progress.
+
+ [Unicode] The Unicode Consortium, "The Unicode Standard, Version
+ 3.2.0" is defined by "The Unicode Standard, Version 3.0"
+ (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5),
+ as amended by the "Unicode Standard Annex #27: Unicode
+ 3.1" (http://www.unicode.org/reports/tr27/) and by the
+ "Unicode Standard Annex #28: Unicode 3.2"
+ (http://www.unicode.org/reports/tr28/).
+
+ [URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
+ Resource Identifiers (URI): Generic Syntax", RFC 2396,
+ August 1998.
+
+ [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO
+ 10646", STD63 and RFC3629, November 2003.
+
+ [X.500] ITU-T Rec. X.500, "The Directory: Overview of Concepts,
+ Models and Service", 1993.
+
+ [X.501] ITU-T Rec. X.501, "The Directory: Models", 1993.
+
+ [X.511] ITU-T Rec. X.511, "The Directory: Abstract Service
+ Definition", 1993.
+
+
+9. Informative References
+
+ [Glossary] The Unicode Consortium, "Unicode Glossary",
+ <http://www.unicode.org/glossary/>.
+
+ [CharModel] Whistler, K. and M. Davis, "Unicode Technical Report
+ #17, Character Encoding Model", UTR17,
+ <http://www.unicode.org/unicode/reports/tr17/>, August
+ 2000.
+
+ [PROTOS-LDAP] University of Oulu, "PROTOS Test-Suite: c06-ldapv3"
+ <http://www.ee.oulu.fi/research/ouspg/protos/testing/c06/l
+ dapv3/>
+
+ [PortReg] IANA, "Port Numbers",
+ http://www.iana.org/assignments/port-numbers
+
+
+10. IANA Considerations
+
+
+
+
+
+Sermersheim Internet-Draft - Expires April 2006 Page 44
+ Lightweight Directory Access Protocol Version 3
+
+ It is requested that the Internet Assigned Numbers Authority (IANA)
+ update the LDAP result code registry to indicate that this document
+ provides the definitive technical specification for result codes 0-
+ 36, 48-54, 64-70, 80-90. It is also noted that one resultCode value
+ (strongAuthRequired) has been renamed (to strongerAuthRequired).
+
+ It is requested that the IANA update the LDAP Protocol Mechanism
+ registry to indicate that this document and [AuthMeth] provides the
+ definitive technical specification for the StartTLS
+ (1.3.6.1.4.1.1466.20037) Extended operation.
+
+ It is requested that the IANA update the occurrence of "RFC XXXX" in
+ this section and Appendix B with this RFC number at publication.
+
+ It is requested that IANA assign upon Standards Action an LDAP Object
+ Identifier [LDAPIANA] to identify the ASN.1 module defined in this
+ document.
+
+ Subject: Request for LDAP Object Identifier Registration
+ Person & email address to contact for further information:
+ Jim Sermersheim <jimse at novell.com>
+ Specification: RFC XXXX
+ Author/Change Controller: IESG
+ Comments:
+ Identifies the LDAP ASN.1 module
+
+ [[Note to RFC Editor: please replace the occurrence of <IANA-
+ ASSIGNED-DIRECTORY-NUMBER> in Appendix B with the IANA assigned
+ OID.]]
+
+
+11. Editor's Address
+
+ Jim Sermersheim
+ Novell, Inc.
+ 1800 South Novell Place
+ Provo, Utah 84606, USA
+ jimse at novell.com
+ +1 801 861-3088
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sermersheim Internet-Draft - Expires April 2006 Page 45
+ Lightweight Directory Access Protocol Version 3
+
+Appendix A. LDAP Result Codes
+
+ This normative appendix details additional considerations regarding
+ LDAP result codes and provides a brief, general description of each
+ LDAP result code enumerated in Section 4.1.9.
+
+ Additional result codes MAY be defined for use with extensions
+ [LDAPIANA]. Client implementations SHALL treat any result code which
+ they do not recognize as an unknown error condition.
+
+ The descriptions provided here do not fully account for result code
+ substitutions used to prevent unauthorized disclosures (such as
+ substitution of noSuchObject for insufficientAccessRights, or
+ invalidCredentials for insufficientAccessRights).
+
+
+A.1. Non-Error Result Codes
+
+ These result codes (called "non-error" result codes) do not indicate
+ an error condition:
+ success (0),
+ compareFalse (5),
+ compareTrue (6),
+ referral (10), and
+ saslBindInProgress (14).
+
+ The success, compareTrue, and compareFalse result codes indicate
+ successful completion (and, hence, are referred to as "successful"
+ result codes).
+
+ The referral and saslBindInProgress result codes indicate the client
+ needs to take additional action to complete the operation.
+
+
+A.2. Result Codes
+
+ Existing LDAP result codes are described as follows:
+
+ success (0)
+ Indicates the successful completion of an operation. Note:
+ this code is not used with the Compare operation. See
+ compareFalse (5) and compareTrue (6).
+
+ operationsError (1)
+ Indicates that the operation is not properly sequenced with
+ relation to other operations (of same or different type).
+
+ For example, this code is returned if the client attempts to
+ StartTLS [TLS] while there are other uncompleted operations
+ or if a TLS layer was already installed.
+
+ protocolError (2)
+ Indicates the server received data which is not well-formed.
+
+
+Sermersheim Internet-Draft - Expires April 2006 Page 46
+ Lightweight Directory Access Protocol Version 3
+
+ For Bind operation only, this code is also used to indicate
+ that the server does not support the requested protocol
+ version.
+
+ For Extended operations only, this code is also used to
+ indicate that the server does not support (by design or
+ configuration) the Extended operation associated with the
+ requestName.
+
+ For request operations specifying multiple controls, this may
+ be used to indicate that the server cannot ignore the order
+ of the controls as specified, or that the combination of the
+ specified controls is invalid or unspecified.
+
+ timeLimitExceeded (3)
+ Indicates that the time limit specified by the client was
+ exceeded before the operation could be completed.
+
+ sizeLimitExceeded (4)
+ Indicates that the size limit specified by the client was
+ exceeded before the operation could be completed.
+
+ compareFalse (5)
+ Indicates that the Compare operation has successfully
+ completed and the assertion has evaluated to FALSE or
+ Undefined.
+
+ compareTrue (6)
+ Indicates that the Compare operation has successfully
+ completed and the assertion has evaluated to TRUE.
+
+ authMethodNotSupported (7)
+ Indicates that the authentication method or mechanism is not
+ supported.
+
+ strongerAuthRequired (8)
+ Indicates the server requires strong(er) authentication in
+ order to complete the operation.
+
+ When used with the Notice of Disconnection operation, this
+ code indicates that the server has detected that an
+ established security association between the client and
+ server has unexpectedly failed or been compromised.
+
+ referral (10)
+ Indicates that a referral needs to be chased to complete the
+ operation (see Section 4.1.10).
+
+ adminLimitExceeded (11)
+ Indicates that an administrative limit has been exceeded.
+
+ unavailableCriticalExtension (12)
+ Indicates a critical control is unrecognized (see Section
+ 4.1.11).
+
+Sermersheim Internet-Draft - Expires April 2006 Page 47
+ Lightweight Directory Access Protocol Version 3
+
+
+ confidentialityRequired (13)
+ Indicates that data confidentiality protections are required.
+
+ saslBindInProgress (14)
+ Indicates the server requires the client to send a new bind
+ request, with the same SASL mechanism, to continue the
+ authentication process (see Section 4.2).
+
+ noSuchAttribute (16)
+ Indicates that the named entry does not contain the specified
+ attribute or attribute value.
+
+ undefinedAttributeType (17)
+ Indicates that a request field contains an unrecognized
+ attribute description.
+
+ inappropriateMatching (18)
+ Indicates that an attempt was made (e.g. in an assertion) to
+ use a matching rule not defined for the attribute type
+ concerned.
+
+ constraintViolation (19)
+ Indicates that the client supplied an attribute value which
+ does not conform to the constraints placed upon it by the
+ data model.
+
+ For example, this code is returned when multiple values are
+ supplied to an attribute which has a SINGLE-VALUE constraint.
+
+ attributeOrValueExists (20)
+ Indicates that the client supplied an attribute or value to
+ be added to an entry, but the attribute or value already
+ exists.
+
+ invalidAttributeSyntax (21)
+ Indicates that a purported attribute value does not conform
+ to the syntax of the attribute.
+
+ noSuchObject (32)
+ Indicates that the object does not exist in the DIT.
+
+ aliasProblem (33)
+ Indicates that an alias problem has occurred. For example,
+ the code may used to indicate an alias has been dereferenced
+ which names no object.
+
+ invalidDNSyntax (34)
+ Indicates that an LDAPDN or RelativeLDAPDN field (e.g. search
+ base, target entry, ModifyDN newrdn, etc.) of a request does
+ not conform to the required syntax or contains attribute
+ values which do not conform to the syntax of the attribute's
+ type.
+
+
+Sermersheim Internet-Draft - Expires April 2006 Page 48
+ Lightweight Directory Access Protocol Version 3
+
+
+ aliasDereferencingProblem (36)
+ Indicates that a problem occurred while dereferencing an
+ alias. Typically an alias was encountered in a situation
+ where it was not allowed or where access was denied.
+
+ inappropriateAuthentication (48)
+ Indicates the server requires the client which had attempted
+ to bind anonymously or without supplying credentials to
+ provide some form of credentials.
+
+ invalidCredentials (49)
+ Indicates that the provided credentials (e.g. the user's name
+ and password) are invalid.
+
+ insufficientAccessRights (50)
+ Indicates that the client does not have sufficient access
+ rights to perform the operation.
+
+ busy (51)
+ Indicates that the server is too busy to service the
+ operation.
+
+ unavailable (52)
+ Indicates that the server is shutting down or a subsystem
+ necessary to complete the operation is offline.
+
+ unwillingToPerform (53)
+ Indicates that the server is unwilling to perform the
+ operation.
+
+ loopDetect (54)
+ Indicates that the server has detected an internal loop (e.g.
+ while dereferencing aliases or chaining an operation).
+
+ namingViolation (64)
+ Indicates that the entry's name violates naming restrictions.
+
+ objectClassViolation (65)
+ Indicates that the entry violates object class restrictions.
+
+ notAllowedOnNonLeaf (66)
+ Indicates that the operation is inappropriately acting upon a
+ non-leaf entry.
+
+ notAllowedOnRDN (67)
+ Indicates that the operation is inappropriately attempting to
+ remove a value which forms the entry's relative distinguished
+ name.
+
+ entryAlreadyExists (68)
+ Indicates that the request cannot be fulfilled (added, moved,
+ or renamed) as the target entry already exists.
+
+
+Sermersheim Internet-Draft - Expires April 2006 Page 49
+ Lightweight Directory Access Protocol Version 3
+
+
+ objectClassModsProhibited (69)
+ Indicates that an attempt to modify the object class(es) of
+ an entry's 'objectClass' attribute is prohibited.
+
+ For example, this code is returned when a client attempts to
+ modify the structural object class of an entry.
+
+ affectsMultipleDSAs (71)
+ Indicates that the operation cannot be performed as it would
+ affect multiple servers (DSAs).
+
+ other (80)
+ Indicates the server has encountered an internal error.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sermersheim Internet-Draft - Expires April 2006 Page 50
+ Lightweight Directory Access Protocol Version 3
+
+Appendix B. Complete ASN.1 Definition
+
+ This appendix is normative.
+
+ Lightweight-Directory-Access-Protocol-V3 {1 3 6 1 1 <IANA-
+ ASSIGNED-DIRECTORY-NUMBER>}
+ -- Copyright (C) The Internet Society (2005). This version of
+ -- this ASN.1 module is part of RFC XXXX; see the RFC itself
+ -- for full legal notices.
+ DEFINITIONS
+ IMPLICIT TAGS
+ EXTENSIBILITY IMPLIED ::=
+
+ BEGIN
+
+ LDAPMessage ::= SEQUENCE {
+ messageID MessageID,
+ protocolOp CHOICE {
+ bindRequest BindRequest,
+ bindResponse BindResponse,
+ unbindRequest UnbindRequest,
+ searchRequest SearchRequest,
+ searchResEntry SearchResultEntry,
+ searchResDone SearchResultDone,
+ searchResRef SearchResultReference,
+ modifyRequest ModifyRequest,
+ modifyResponse ModifyResponse,
+ addRequest AddRequest,
+ addResponse AddResponse,
+ delRequest DelRequest,
+ delResponse DelResponse,
+ modDNRequest ModifyDNRequest,
+ modDNResponse ModifyDNResponse,
+ compareRequest CompareRequest,
+ compareResponse CompareResponse,
+ abandonRequest AbandonRequest,
+ extendedReq ExtendedRequest,
+ extendedResp ExtendedResponse,
+ ...,
+ intermediateResponse IntermediateResponse },
+ controls [0] Controls OPTIONAL }
+
+ MessageID ::= INTEGER (0 .. maxInt)
+
+ maxInt INTEGER ::= 2147483647 -- (2^^31 - 1) --
+
+ LDAPString ::= OCTET STRING -- UTF-8 encoded,
+ -- [ISO10646] characters
+
+ LDAPOID ::= OCTET STRING -- Constrained to <numericoid> [Models]
+
+ LDAPDN ::= LDAPString -- Constrained to <distinguishedName>
+ -- [LDAPDN]
+
+
+Sermersheim Internet-Draft - Expires April 2006 Page 51
+ Lightweight Directory Access Protocol Version 3
+
+ RelativeLDAPDN ::= LDAPString -- Constrained to <name-component>
+ -- [LDAPDN]
+
+ AttributeDescription ::= LDAPString
+ -- Constrained to <attributedescription>
+ -- [Models]
+
+ AttributeValue ::= OCTET STRING
+
+ AttributeValueAssertion ::= SEQUENCE {
+ attributeDesc AttributeDescription,
+ assertionValue AssertionValue }
+
+ AssertionValue ::= OCTET STRING
+
+ PartialAttribute ::= SEQUENCE {
+ type AttributeDescription,
+ vals SET OF value AttributeValue }
+
+ Attribute ::= PartialAttribute(WITH COMPONENTS {
+ ...,
+ vals (SIZE(1..MAX))})
+
+ MatchingRuleId ::= LDAPString
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sermersheim Internet-Draft - Expires April 2006 Page 52
+ Lightweight Directory Access Protocol Version 3
+
+ LDAPResult ::= SEQUENCE {
+ resultCode ENUMERATED {
+ success (0),
+ operationsError (1),
+ protocolError (2),
+ timeLimitExceeded (3),
+ sizeLimitExceeded (4),
+ compareFalse (5),
+ compareTrue (6),
+ authMethodNotSupported (7),
+ strongerAuthRequired (8),
+ -- 9 reserved --
+ referral (10),
+ adminLimitExceeded (11),
+ unavailableCriticalExtension (12),
+ confidentialityRequired (13),
+ saslBindInProgress (14),
+ noSuchAttribute (16),
+ undefinedAttributeType (17),
+ inappropriateMatching (18),
+ constraintViolation (19),
+ attributeOrValueExists (20),
+ invalidAttributeSyntax (21),
+ -- 22-31 unused --
+ noSuchObject (32),
+ aliasProblem (33),
+ invalidDNSyntax (34),
+ -- 35 reserved for undefined isLeaf --
+ aliasDereferencingProblem (36),
+ -- 37-47 unused --
+ inappropriateAuthentication (48),
+ invalidCredentials (49),
+ insufficientAccessRights (50),
+ busy (51),
+ unavailable (52),
+ unwillingToPerform (53),
+ loopDetect (54),
+ -- 55-63 unused --
+ namingViolation (64),
+ objectClassViolation (65),
+ notAllowedOnNonLeaf (66),
+ notAllowedOnRDN (67),
+ entryAlreadyExists (68),
+ objectClassModsProhibited (69),
+ -- 70 reserved for CLDAP --
+ affectsMultipleDSAs (71),
+ -- 72-79 unused --
+ other (80),
+ ... },
+ matchedDN LDAPDN,
+ diagnosticMessage LDAPString,
+ referral [3] Referral OPTIONAL }
+
+ Referral ::= SEQUENCE SIZE (1..MAX) OF uri URI
+
+Sermersheim Internet-Draft - Expires April 2006 Page 53
+ Lightweight Directory Access Protocol Version 3
+
+
+ URI ::= LDAPString -- limited to characters permitted in
+ -- URIs
+
+ Controls ::= SEQUENCE OF control Control
+
+ Control ::= SEQUENCE {
+ controlType LDAPOID,
+ criticality BOOLEAN DEFAULT FALSE,
+ controlValue OCTET STRING OPTIONAL }
+
+ BindRequest ::= [APPLICATION 0] SEQUENCE {
+ version INTEGER (1 .. 127),
+ name LDAPDN,
+ authentication AuthenticationChoice }
+
+ AuthenticationChoice ::= CHOICE {
+ simple [0] OCTET STRING,
+ -- 1 and 2 reserved
+ sasl [3] SaslCredentials,
+ ... }
+
+ SaslCredentials ::= SEQUENCE {
+ mechanism LDAPString,
+ credentials OCTET STRING OPTIONAL }
+
+ BindResponse ::= [APPLICATION 1] SEQUENCE {
+ COMPONENTS OF LDAPResult,
+ serverSaslCreds [7] OCTET STRING OPTIONAL }
+
+ UnbindRequest ::= [APPLICATION 2] NULL
+
+ SearchRequest ::= [APPLICATION 3] SEQUENCE {
+ baseObject LDAPDN,
+ scope ENUMERATED {
+ baseObject (0),
+ singleLevel (1),
+ wholeSubtree (2),
+ ... },
+ derefAliases ENUMERATED {
+ neverDerefAliases (0),
+ derefInSearching (1),
+ derefFindingBaseObj (2),
+ derefAlways (3) },
+ sizeLimit INTEGER (0 .. maxInt),
+ timeLimit INTEGER (0 .. maxInt),
+ typesOnly BOOLEAN,
+ filter Filter,
+ attributes AttributeSelection }
+
+ AttributeSelection ::= SEQUENCE OF selector LDAPString
+ -- The LDAPString is constrained to
+ -- <attributeSelector> in Section 4.5.1.7
+
+
+Sermersheim Internet-Draft - Expires April 2006 Page 54
+ Lightweight Directory Access Protocol Version 3
+
+ Filter ::= CHOICE {
+ and [0] SET SIZE (1..MAX) OF filter Filter,
+ or [1] SET SIZE (1..MAX) OF filter Filter,
+ not [2] Filter,
+ equalityMatch [3] AttributeValueAssertion,
+ substrings [4] SubstringFilter,
+ greaterOrEqual [5] AttributeValueAssertion,
+ lessOrEqual [6] AttributeValueAssertion,
+ present [7] AttributeDescription,
+ approxMatch [8] AttributeValueAssertion,
+ extensibleMatch [9] MatchingRuleAssertion,
+ ... }
+
+ SubstringFilter ::= SEQUENCE {
+ type AttributeDescription,
+ substrings SEQUENCE SIZE (1..MAX) OF substring CHOICE {
+ initial [0] AssertionValue, -- can occur at most once
+ any [1] AssertionValue,
+ final [2] AssertionValue } -- can occur at most once
+ }
+
+ MatchingRuleAssertion ::= SEQUENCE {
+ matchingRule [1] MatchingRuleId OPTIONAL,
+ type [2] AttributeDescription OPTIONAL,
+ matchValue [3] AssertionValue,
+ dnAttributes [4] BOOLEAN DEFAULT FALSE }
+
+ SearchResultEntry ::= [APPLICATION 4] SEQUENCE {
+ objectName LDAPDN,
+ attributes PartialAttributeList }
+
+ PartialAttributeList ::= SEQUENCE OF
+ partialAttribute PartialAttribute
+
+ SearchResultReference ::= [APPLICATION 19] SEQUENCE
+ SIZE (1..MAX) OF uri URI
+
+ SearchResultDone ::= [APPLICATION 5] LDAPResult
+
+ ModifyRequest ::= [APPLICATION 6] SEQUENCE {
+ object LDAPDN,
+ changes SEQUENCE OF change SEQUENCE {
+ operation ENUMERATED {
+ add (0),
+ delete (1),
+ replace (2),
+ ... },
+ modification PartialAttribute } }
+
+ ModifyResponse ::= [APPLICATION 7] LDAPResult
+
+ AddRequest ::= [APPLICATION 8] SEQUENCE {
+ entry LDAPDN,
+ attributes AttributeList }
+
+Sermersheim Internet-Draft - Expires April 2006 Page 55
+ Lightweight Directory Access Protocol Version 3
+
+
+ AttributeList ::= SEQUENCE OF attribute Attribute
+
+ AddResponse ::= [APPLICATION 9] LDAPResult
+
+ DelRequest ::= [APPLICATION 10] LDAPDN
+
+ DelResponse ::= [APPLICATION 11] LDAPResult
+
+ ModifyDNRequest ::= [APPLICATION 12] SEQUENCE {
+ entry LDAPDN,
+ newrdn RelativeLDAPDN,
+ deleteoldrdn BOOLEAN,
+ newSuperior [0] LDAPDN OPTIONAL }
+
+ ModifyDNResponse ::= [APPLICATION 13] LDAPResult
+
+ CompareRequest ::= [APPLICATION 14] SEQUENCE {
+ entry LDAPDN,
+ ava AttributeValueAssertion }
+
+ CompareResponse ::= [APPLICATION 15] LDAPResult
+
+ AbandonRequest ::= [APPLICATION 16] MessageID
+
+ ExtendedRequest ::= [APPLICATION 23] SEQUENCE {
+ requestName [0] LDAPOID,
+ requestValue [1] OCTET STRING OPTIONAL }
+
+ ExtendedResponse ::= [APPLICATION 24] SEQUENCE {
+ COMPONENTS OF LDAPResult,
+ responseName [10] LDAPOID OPTIONAL,
+ responseValue [11] OCTET STRING OPTIONAL }
+
+ IntermediateResponse ::= [APPLICATION 25] SEQUENCE {
+ responseName [0] LDAPOID OPTIONAL,
+ responseValue [1] OCTET STRING OPTIONAL }
+
+ END
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sermersheim Internet-Draft - Expires April 2006 Page 56
+ Lightweight Directory Access Protocol Version 3
+
+Appendix C. Changes
+
+ This appendix is non-normative.
+
+ This appendix summarizes substantive changes made to RFC 2251, RFC
+ 2830, and RFC 3771.
+
+
+C.1. Changes made to RFC 2251:
+
+ This section summarizes the substantive changes made to Sections 1,
+ 2, 3.1, and 4 through the remainder of RFC 2251. Readers should
+ consult [Models] and [AuthMeth] for summaries of changes to other
+ sections.
+
+
+C.1.1. Section 1 (Status of this Memo)
+
+ - Removed IESG note. Post publication of RFC 2251, mandatory LDAP
+ authentication mechanisms have been standardized which are
+ sufficient to remove this note. See [AuthMeth] for authentication
+ mechanisms.
+
+
+C.1.2. Section 3.1 (Protocol Model) and others
+
+ - Removed notes giving history between LDAP v1, v2 and v3. Instead,
+ added sufficient language so that this document can stand on its
+ own.
+
+
+C.1.3. Section 4 (Elements of Protocol)
+
+ - Clarified where the extensibility features of ASN.1 apply to the
+ protocol. This change affected various ASN.1 types by the
+ inclusion of ellipses (...) to certain elements.
+ - Removed the requirement that servers which implement version 3 or
+ later MUST provide the 'supportedLDAPVersion' attribute. This
+ statement provided no interoperability advantages.
+
+
+C.1.4. Section 4.1.1 (Message Envelope)
+
+ - There was a mandatory requirement for the server to return a
+ Notice of Disconnection and drop the transport connection when a
+ PDU is malformed in a certain way. This has been updated such that
+ the server SHOULD return the Notice of Disconnection, and MUST
+ terminate the LDAP Session.
+
+
+C.1.5. Section 4.1.1.1 (Message ID)
+
+ - Required that the messageID of requests MUST be non-zero as the
+ zero is reserved for Notice of Disconnection.
+
+Sermersheim Internet-Draft - Expires April 2006 Page 57
+ Lightweight Directory Access Protocol Version 3
+
+ - Specified when it is and isn't appropriate to return an already
+ used message id. RFC 2251 accidentally imposed synchronous server
+ behavior in its wording of this.
+
+
+C.1.6. Section 4.1.2 (String Types)
+
+ - Stated that LDAPOID is constrained to <numericoid> from [Models].
+
+
+C.1.7. Section 4.1.5.1 (Binary Option) and others
+
+ - Removed the Binary Option from the specification. There are
+ numerous interoperability problems associated with this method of
+ alternate attribute type encoding. Work to specify a suitable
+ replacement is ongoing.
+
+
+C.1.8. Section 4.1.8 (Attribute)
+
+ - Combined the definitions of PartialAttribute and Attribute here,
+ and defined Attribute in terms of PartialAttribute.
+
+
+C.1.9. Section 4.1.10 (Result Message)
+
+ - Renamed "errorMessage" to "diagnosticMessage" as it is allowed to
+ be sent for non-error results.
+ - Moved some language into Appendix A, and refer the reader there.
+ - Allowed matchedDN to be present for other result codes than those
+ listed in RFC 2251.
+ - renamed the code "strongAuthRequired" to "strongerAuthRequired" to
+ clarify that this code may often be returned to indicate that a
+ stronger authentication is needed to perform a given operation.
+
+
+C.1.10. Section 4.1.11 (Referral)
+
+ - Defined referrals in terms of URIs rather than URLs.
+ - Removed the requirement that all referral URIs MUST be equally
+ capable of progressing the operation. The statement was ambiguous
+ and provided no instructions on how to carry it out.
+ - Added the requirement that clients MUST NOT loop between servers.
+ - Clarified the instructions for using LDAPURLs in referrals, and in
+ doing so added a recommendation that the scope part be present.
+ - Removed imperatives which required clients to use URLs in specific
+ ways to progress an operation. These did nothing for
+ interoperability.
+
+
+C.1.11. Section 4.1.12 (Controls)
+
+ - Specified how control values defined in terms of ASN.1 are to be
+ encoded.
+
+Sermersheim Internet-Draft - Expires April 2006 Page 58
+ Lightweight Directory Access Protocol Version 3
+
+ - Noted that the criticality field is only applied to request
+ messages (except UnbindRequest), and must be ignored when present
+ on response messages and UnbindRequest.
+ - Specified that non-critical controls may be ignored at the
+ server's discretion. There was confusion in the original wording
+ which led some to believe that recognized controls may not be
+ ignored as long as they were associated with a proper request.
+ - Added language regarding combinations of controls and the ordering
+ of controls on a message.
+ - Specified that when the semantics of the combination of controls
+ is undefined or unknown, it results in a protocolError.
+ - Changed "The server MUST be prepared" to "Implementations MUST be
+ prepared" in the eighth paragraph to reflect that both client and
+ server implementations must be able to handle this (as both parse
+ controls).
+
+
+C.1.12. Section 4.2 (Bind Operation)
+
+ - Mandated that servers return protocolError when the version is not
+ supported.
+ - Disambiguated behavior when the simple authentication is used, the
+ name is empty and the password is non-empty.
+ - Required servers to not dereference aliases for Bind. This was
+ added for consistency with other operations and to help ensure
+ data consistency.
+ - Required that textual passwords be transferred as UTF-8 encoded
+ Unicode, and added recommendations on string preparation. This was
+ to help ensure interoperability of passwords being sent from
+ different clients.
+
+
+C.1.13. Section 4.2.1 (Sequencing of the Bind Request)
+
+ - This section was largely reorganized for readability and language
+ was added to clarify the authentication state of failed and
+ abandoned Bind operations.
+ - Removed: "If a SASL transfer encryption or integrity mechanism has
+ been negotiated, that mechanism does not support the changing of
+ credentials from one identity to another, then the client MUST
+ instead establish a new connection."
+ If there are dependencies between multiple negotiations of a
+ particular SASL mechanism, the technical specification for that
+ SASL mechanism details how applications are to deal with them.
+ LDAP should not require any special handling.
+ - Dropped MUST imperative in paragraph 3 to align with [Keywords].
+ - Mandated that clients not send non-Bind operations while a Bind is
+ in progress, and suggested that servers not process them if they
+ are received. This is needed to ensure proper sequencing of the
+ Bind in relationship to other operations.
+
+
+
+
+
+Sermersheim Internet-Draft - Expires April 2006 Page 59
+ Lightweight Directory Access Protocol Version 3
+
+C.1.14. Section 4.2.3 (Bind Response)
+
+ - Moved most error-related text to Appendix A, and added text
+ regarding certain errors used in conjunction with the Bind
+ operation.
+ - Prohibited the server from specifying serverSaslCreds when not
+ appropriate.
+
+
+C.1.15. Section 4.3 (Unbind Operation)
+
+ - Specified that both peers are to cease transmission and terminate
+ the LDAP session for the Unbind operation.
+
+
+C.1.16. Section 4.4 (Unsolicited Notification)
+
+ - Added instructions for future specifications of Unsolicited
+ Notifications.
+
+
+C.1.17. Section 4.5.1 (Search Request)
+
+ - SearchRequest attributes is now defined as an AttributeSelection
+ type rather than AttributeDescriptionList, and an ABNF is
+ provided.
+ - SearchRequest attributes may contain duplicate attribute
+ descriptions. This was previously prohibited. Now servers are
+ instructed to ignore subsequent names when they are duplicated.
+ This was relaxed in order to allow different short names and also
+ OIDs to be requested for an attribute.
+ - The present search filter now evaluates to Undefined when the
+ specified attribute is not known to the server. It used to
+ evaluate to FALSE, which caused behavior inconsistent with what
+ most would expect, especially when the not operator was used.
+ - The Filter choice SubstringFilter substrings type is now defined
+ with a lower bound of 1.
+ - The SubstringFilter substrings 'initial, 'any', and 'final' types
+ are now AssertionValue rather than LDAPString. Also, added
+ imperatives stating that 'initial' (if present) must be listed
+ first, and 'final' (if present) must be listed last.
+ - Disambiguated the semantics of the derefAliases choices. There was
+ question as to whether derefInSearching applied to the base object
+ in a wholeSubtree Search.
+ - Added instructions for equalityMatch, substrings, greaterOrEqual,
+ lessOrEqual, and approxMatch.
+
+
+C.1.18. Section 4.5.2 (Search Result)
+
+ - Recommended that servers not use attribute short names when it
+ knows they are ambiguous or may cause interoperability problems.
+ - Removed all mention of ExtendedResponse due to lack of
+ implementation.
+
+Sermersheim Internet-Draft - Expires April 2006 Page 60
+ Lightweight Directory Access Protocol Version 3
+
+
+
+C.1.19. Section 4.5.3 (Continuation References in the Search Result)
+
+ - Made changes similar to those made to Section 4.1.11.
+
+
+C.1.20. Section 4.5.3.1 (Example)
+
+ - Fixed examples to adhere to changes made to Section 4.5.3.
+
+
+C.1.21. Section 4.6 (Modify Operation)
+
+ - Replaced AttributeTypeAndValues with Attribute as they are
+ equivalent.
+ - Specified the types of modification changes which might
+ temporarily violate schema. Some readers were under the impression
+ that any temporary schema violation was allowed.
+
+
+C.1.22. Section 4.7 (Add Operation)
+
+ - Aligned Add operation with X.511 in that the attributes of the RDN
+ are used in conjunction with the listed attributes to create the
+ entry. Previously, Add required that the distinguished values be
+ present in the listed attributes.
+ - Removed requirement that the objectClass attribute MUST be
+ specified as some DSE types do not require this attribute.
+ Instead, generic wording was added, requiring the added entry to
+ adhere to the data model.
+ - Removed recommendation regarding placement of objects. This is
+ covered in the data model document.
+
+
+C.1.23. Section 4.9 (Modify DN Operation)
+
+ - Required servers to not dereference aliases for Modify DN. This
+ was added for consistency with other operations and to help ensure
+ data consistency.
+ - Allow Modify DN to fail when moving between naming contexts.
+ - Specified what happens when the attributes of the newrdn are not
+ present on the entry.
+
+
+C.1.24. Section 4.10 (Compare Operation)
+
+ - Specified that compareFalse means that the Compare took place and
+ the result is false. There was confusion which lead people to
+ believe that an Undefined match resulted in compareFalse.
+ - Required servers to not dereference aliases for Compare. This was
+ added for consistency with other operations and to help ensure
+ data consistency.
+
+
+Sermersheim Internet-Draft - Expires April 2006 Page 61
+ Lightweight Directory Access Protocol Version 3
+
+
+C.1.25. Section 4.11 (Abandon Operation)
+
+ - Explained that since Abandon returns no response, clients should
+ not use it if they need to know the outcome.
+ - Specified that Abandon and Unbind cannot be abandoned.
+
+
+C.1.26. Section 4.12 (Extended Operation)
+
+ - Specified how values of Extended operations defined in terms of
+ ASN.1 are to be encoded.
+ - Added instructions on what Extended operation specifications
+ consist of.
+ - Added a recommendation that servers advertise supported Extended
+ operations.
+
+
+C.1.27. Section 5.2 (Transfer Protocols)
+
+ - Moved referral-specific instructions into referral-related
+ sections.
+
+
+C.1.28. Section 7 (Security Considerations)
+
+ - Reworded notes regarding SASL not protecting certain aspects of
+ the LDAP Bind messages.
+ - Noted that Servers are encouraged to prevent directory
+ modifications by clients that have authenticated anonymously
+ [AuthMeth].
+ - Added a note regarding the possibility of changes to security
+ factors (authentication, authorization, data confidentiality).
+ - Warned against following referrals that may have been injected in
+ the data stream.
+ - Noted that servers should protect information equally, whether in
+ an error condition or not, and mentioned specifically; matchedDN,
+ diagnosticMessage, and resultCodes.
+ - Added a note regarding malformed and long encodings.
+
+
+C.1.29. Appendix A (Complete ASN.1 Definition)
+
+ - Added "EXTENSIBILITY IMPLIED" to ASN.1 definition.
+ - Removed AttributeType. It is not used.
+
+
+C.2. Changes made to RFC 2830:
+
+ This section summarizes the substantive changes made to Sections of
+ RFC 2830. Readers should consult [AuthMeth] for summaries of changes
+ to other sections.
+
+
+
+Sermersheim Internet-Draft - Expires April 2006 Page 62
+ Lightweight Directory Access Protocol Version 3
+
+C.2.1. Section 2.3 (Response other than "success")
+
+ - Removed wording indicating that referrals can be returned from
+ StartTLS.
+ - Removed requirement that only a narrow set of result codes can be
+ returned. Some result codes are required in certain scenarios, but
+ any other may be returned if appropriate.
+ - Removed requirement that the ExtendedResponse.responseName MUST be
+ present. There are circumstances where this is impossible, and
+ requiring this is at odds with language in Section 4.12.
+
+
+C.2.1. Section 4 (Closing a TLS Connection)
+
+ - Reworded most of this section to align with definitions of the
+ LDAP protocol layers.
+ - Removed instructions on abrupt closure as this is covered in other
+ areas of the document (specifically, Section 5.3)
+
+
+C.3. Changes made to RFC 3771:
+
+ - Rewrote to fit into this document. In general, semantics were
+ preserved. Supporting and background language seen as redundant
+ due to its presence in this document was omitted.
+ - Specified that Intermediate responses to a request may be of
+ different types, and one of the response types may be specified to
+ have no response value.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sermersheim Internet-Draft - Expires April 2006 Page 63
+ Lightweight Directory Access Protocol Version 3
+
+
+
+
+Intellectual Property Statement
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at ietf-
+ ipr at ietf.org.
+
+Disclaimer of Validity
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Copyright Statement
+
+ Copyright (C) The Internet Society (2005).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+Sermersheim Internet-Draft - Expires April 2006 Page 64
Added: openldap/vendor/openldap-release/doc/drafts/draft-ietf-ldapbis-roadmap-xx.txt
===================================================================
--- openldap/vendor/openldap-release/doc/drafts/draft-ietf-ldapbis-roadmap-xx.txt (rev 0)
+++ openldap/vendor/openldap-release/doc/drafts/draft-ietf-ldapbis-roadmap-xx.txt 2007-09-15 10:38:52 UTC (rev 844)
@@ -0,0 +1,396 @@
+
+
+
+
+
+INTERNET-DRAFT Editor: Kurt D. Zeilenga
+Intended Category: Standard Track OpenLDAP Foundation
+Expires in six months 10 February 2005
+Obsoletes: RFC 2251-2256, 2829-2830, 3377, 3771
+
+
+
+ Lightweight Directory Access Protocol (LDAP):
+ Technical Specification Road Map
+ <draft-ietf-ldapbis-roadmap-07.txt>
+
+
+
+Status of this Memo
+
+ This document is intended to be published as a Standard Track RFC.
+ Distribution of this memo is unlimited. Technical discussion of this
+ document will take place on the IETF LDAP Revision Working Group
+ mailing list <ietf-ldapbis at openldap.org>. Please send editorial
+ comments directly to the author <Kurt at OpenLDAP.org>.
+
+ By submitting this Internet-Draft, I accept the provisions of Section
+ 4 of RFC 3667. By submitting this Internet-Draft, I certify that any
+ applicable patent or other IPR claims of which I am aware have been
+ disclosed, or will be disclosed, and any of which I become aware will
+ be disclosed, in accordance with RFC 3668.
+
+ Internet-Drafts are working documents of the Internet Engineering Task
+ Force (IETF), its areas, and its working groups. Note that other
+ groups may also distribute working documents as Internet-Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference material
+ or to cite them other than as "work in progress."
+
+ The list of current Internet-Drafts can be accessed at
+ http://www.ietf.org/1id-abstracts.html
+
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html
+
+
+ Copyright (C) The Internet Society (2005). All Rights Reserved.
+
+ Please see the Full Copyright section near the end of this document
+ for more information.
+
+
+
+
+Zeilenga LDAP: TS Road Map [Page 1]
+
+INTERNET-DRAFT draft-ietf-ldapbis-roadmap-07 10 February 2005
+
+
+Abstract
+
+ The Lightweight Directory Access Protocol (LDAP) is an Internet
+ protocol for accessing distributed directory services which act in
+ accordance with X.500 data and service models. This document provides
+ a roadmap of the LDAP Technical Specification.
+
+
+Conventions
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in BCP 14 [RFC2119].
+
+
+1. The LDAP Technical Specification
+
+ The technical specification detailing version 3 of the Lightweight
+ Directory Access Protocol (LDAP), an Internet Protocol, consists of
+ this document and the following documents:
+
+ LDAP: The Protocol [Protocol],
+ LDAP: Directory Information Models [Models],
+ LDAP: Authentication Methods and Connection Level Security
+ Mechanisms [AuthMeth],
+ LDAP: String Representation of Distinguished Names [LDAPDN],
+ LDAP: String Representation of Search Filters [Filters],
+ LDAP: Uniform Resource Locator [LDAPURL],
+ LDAP: Syntaxes and Matching Rules [Syntaxes],
+ LDAP: Internationalized String Preparation [LDAPprep], and
+ LDAP: User Schema [Schema].
+
+ The terms "LDAP" and "LDAPv3" are commonly used to informally refer to
+ the protocol specified by this technical specification. The LDAP
+ suite, as defined here, should be formally identified in other
+ documents by a normative reference to this document.
+
+ LDAP is an extensible protocol. Extensions to LDAP may be specified
+ in other documents. Nomenclature denoting such combinations of
+ LDAP-plus-extension(s) is not defined by this document but may be
+ defined in some future document(s). Extensions are expected to be
+ truly optional.
+
+ IANA (Internet Assigned Numbers Authority) considerations for LDAP
+ described in BCP 64 [BCP64bis] apply fully to this revision of the
+ LDAP technical specification.
+
+
+
+
+
+Zeilenga LDAP: TS Road Map [Page 2]
+
+INTERNET-DRAFT draft-ietf-ldapbis-roadmap-07 10 February 2005
+
+
+2. Relationship to X.500
+
+ This technical specification defines LDAP in terms of [X.500] as an
+ X.500 access mechanism. An LDAP server MUST act in accordance with
+ X.500(1993) series of International Telecommunication Union - Telecom
+ Standardization (ITU-T) Recommendations when providing the service.
+ However, it is not required that an LDAP server make use of any X.500
+ protocols in providing this service, e.g. LDAP can be mapped onto any
+ other directory system so long as the X.500 data and service models
+ [X.501][X.511] as used in LDAP is not violated in the LDAP interface.
+
+ This technical specification explicitly incorporates portions of
+ X.500(93). Later revisions of X.500 do not automatically apply to
+ this technical specification.
+
+
+3. Security Considerations
+
+ LDAP security considerations are discussed in each document comprising
+ the technical specification.
+
+
+4. Relationship to Obsolete Specifications
+
+ This technical specification, as defined in Section 1, obsoletes
+ entirely the previously defined LDAP technical specification [RFC3377]
+ (which consists of RFC 2251-2256, RFC 2829-2830, RFC 3771, and RFC
+ 3377 itself). The technical specification was significantly
+ reorganized.
+
+ This document replaces RFC 3377 as well as Section 3.3 of RFC 2251.
+ [Models] replaces portions of RFC 2251, RFC 2252 and RFC 2256.
+ [Protocol] replaces the majority RFC 2251, portions of RFC 2252, and
+ all of RFC 3771. [AuthMeth] replaces RFC 2829, RFC 2830, and portions
+ of RFC 2251. [Syntaxes] replaces the majority of RFC 2252 and
+ portions of RFC 2256. [Schema] replaces the majority of RFC 2256.
+ [LDAPDN] replaces RFC 2253. [Filters] replaces RFC 2254. [LDAPURL]
+ replaces RFC 2255.
+
+ [LDAPprep] is new to this revision of the LDAP technical
+ specification.
+
+ Each document of this specification contains appendices summarizing
+ changes to all sections of the specifications they replace. Appendix
+ A.1 of this document details changes made to RFC 3377. Appendix A.2
+ of this document details changes made to Section 3.3 of RFC 2251.
+
+ Additionally, portions of this technical specification update and/or
+
+
+
+Zeilenga LDAP: TS Road Map [Page 3]
+
+INTERNET-DRAFT draft-ietf-ldapbis-roadmap-07 10 February 2005
+
+
+ replace a number of other documents not listed above. These
+ relationships are discussed in the documents detailings these portions
+ of this technical specification.
+
+
+5. Acknowledgments
+
+ This document is based largely on RFC 3377 by J. Hodges and R.
+ Morgan, a product of the LDAPBIS and LDAPEXT Working Groups. The
+ document also borrows from RFC 2251 by M. Wahl, T. Howes, and S.
+ Kille, a product of the ASID Working Group.
+
+ This document is a product of the IETF LDAPBIS Working Group.
+
+
+6. Author's Address
+
+ Kurt D. Zeilenga
+ OpenLDAP Foundation
+
+ Email: Kurt at OpenLDAP.org
+
+
+7. References
+
+ [[Note to the RFC Editor: please replace the citation tags used in
+ referencing Internet-Drafts with tags of the form RFCnnnn where
+ possible.]]
+
+
+7.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14 (also RFC 2119), March 1997.
+
+ [BCP64bis] Zeilenga, K., "IANA Considerations for LDAP",
+ draft-ietf-ldapbis-bcp64-xx.txt, a work in progress.
+
+ [Protocol] Sermersheim, J. (editor), "LDAP: The Protocol",
+ draft-ietf-ldapbis-protocol-xx.txt, a work in progress.
+
+ [Models] Zeilenga, K. (editor), "LDAP: Directory Information
+ Models", draft-ietf-ldapbis-models-xx.txt, a work in
+ progress.
+
+ [AuthMeth] Harrison, R. (editor), "LDAP: Authentication Methods and
+ Connection Level Security Mechanisms",
+ draft-ietf-ldapbis-authmeth-xx.txt, a work in progress.
+
+
+
+Zeilenga LDAP: TS Road Map [Page 4]
+
+INTERNET-DRAFT draft-ietf-ldapbis-roadmap-07 10 February 2005
+
+
+ [LDAPDN] Zeilenga, K. (editor), "LDAP: String Representation of
+ Distinguished Names", draft-ietf-ldapbis-dn-xx.txt, a
+ work in progress.
+
+ [Filters] Smith, M. (editor), LDAPbis WG, "LDAP: String
+ Representation of Search Filters",
+ draft-ietf-ldapbis-filter-xx.txt, a work in progress.
+
+ [LDAPURL] Smith, M. (editor), "LDAP: Uniform Resource Locator",
+ draft-ietf-ldapbis-url-xx.txt, a work in progress.
+
+ [Syntaxes] Legg, S. (editor), "LDAP: Syntaxes and Matching Rules",
+ draft-ietf-ldapbis-syntaxes-xx.txt, a work in progress.
+
+ [LDAPprep] Zeilenga, K., "LDAP: Internationalized String
+ Preparation", draft-ietf-ldapbis-strprep-xx.txt, a work
+ in progress.
+
+ [Schema] Dally, K. (editor), "LDAP: User Schema",
+ draft-ietf-ldapbis-user-schema-xx.txt, a work in
+ progress.
+
+ [X.500] International Telecommunication Union -
+ Telecommunication Standardization Sector, "The Directory
+ -- Overview of concepts, models and services,"
+ X.500(1993) (also ISO/IEC 9594-1:1994).
+
+ [X.501] International Telecommunication Union -
+ Telecommunication Standardization Sector, "The Directory
+ -- Models," X.501(1993) (also ISO/IEC 9594-2:1994).
+
+ [X.511] International Telecommunication Union -
+ Telecommunication Standardization Sector, "The
+ Directory: Abstract Service Definition", X.511(1993)
+ (also ISO/IEC 9594-3:1993).
+
+
+7.2. Informative References
+
+ None.
+
+
+Appendix A. Changes to Previous Documents
+
+ This appendix outlines changes this document makes relative to the
+ documents it replaces (in whole or in part).
+
+
+
+
+
+Zeilenga LDAP: TS Road Map [Page 5]
+
+INTERNET-DRAFT draft-ietf-ldapbis-roadmap-07 10 February 2005
+
+
+Appendix A.1. Changes to RFC 3377
+
+ This document is nearly a complete rewrite of RFC 3377 as much of the
+ material of RFC 3377 is no longer applicable. The changes include
+ redefining the terms "LDAP" and "LDAPv3" to refer to this revision of
+ the technical specification.
+
+
+Appendix A.2. Changes to Section 3.3 of RFC 2251
+
+ The section was modified slightly (the word "document" was replaced
+ with "technical specification") to clarify that it applies to the
+ entire LDAP technical specification.
+
+
+
+Intellectual Property Rights
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be found
+ in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this specification
+ can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr at ietf.org.
+
+
+
+Full Copyright
+
+ Copyright (C) The Internet Society (2005). This document is subject
+ to the rights, licenses and restrictions contained in BCP 78, and
+ except as set forth therein, the authors retain all their rights.
+
+
+
+
+Zeilenga LDAP: TS Road Map [Page 6]
+
+INTERNET-DRAFT draft-ietf-ldapbis-roadmap-07 10 February 2005
+
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga LDAP: TS Road Map [Page 7]
+
+
+
Added: openldap/vendor/openldap-release/doc/drafts/draft-ietf-ldapbis-strprep-xx.txt
===================================================================
--- openldap/vendor/openldap-release/doc/drafts/draft-ietf-ldapbis-strprep-xx.txt (rev 0)
+++ openldap/vendor/openldap-release/doc/drafts/draft-ietf-ldapbis-strprep-xx.txt 2007-09-15 10:38:52 UTC (rev 844)
@@ -0,0 +1,787 @@
+
+
+
+
+
+
+Internet-Draft Kurt D. Zeilenga
+Intended Category: Standard Track OpenLDAP Foundation
+Expires in six months 23 January 2006
+
+
+
+ LDAP: Internationalized String Preparation
+ <draft-ietf-ldapbis-strprep-07.txt>
+
+
+
+Status of this Memo
+
+ This document is intended to be published as a Standard Track RFC.
+ Distribution of this memo is unlimited. Technical discussion of this
+ document will take place on the IETF LDAP Revision Working Group
+ mailing list <ietf-ldapbis at openldap.org>. Please send editorial
+ comments directly to the editor <Kurt at OpenLDAP.org>.
+
+ By submitting this Internet-Draft, each author represents that any
+ applicable patent or other IPR claims of which he or she is aware have
+ been or will be disclosed, and any of which he or she becomes aware
+ will be disclosed, in accordance with Section 6 of BCP 79.
+
+ Internet-Drafts are working documents of the Internet Engineering Task
+ Force (IETF), its areas, and its working groups. Note that other
+ groups may also distribute working documents as Internet-Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference material
+ or to cite them other than as "work in progress."
+
+ The list of current Internet-Drafts can be accessed at
+ http://www.ietf.org/1id-abstracts.html
+
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html
+
+
+ Copyright (C) The Internet Society (2006). All Rights Reserved.
+
+ Please see the Full Copyright section near the end of this document
+ for more information.
+
+
+
+
+
+
+
+Zeilenga LDAPprep [Page 1]
+
+Internet-Draft draft-ietf-ldapbis-strprep-07 23 January 2006
+
+
+Abstract
+
+ The previous Lightweight Directory Access Protocol (LDAP) technical
+ specifications did not precisely define how character string matching
+ is to be performed. This led to a number of usability and
+ interoperability problems. This document defines string preparation
+ algorithms for character-based matching rules defined for use in LDAP.
+
+
+Conventions and Terms
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in BCP 14 [RFC2119].
+
+ Character names in this document use the notation for code points and
+ names from the Unicode Standard [Unicode]. For example, the letter
+ "a" may be represented as either <U+0061> or <LATIN SMALL LETTER A>.
+ In the lists of mappings and the prohibited characters, the "U+" is
+ left off to make the lists easier to read. The comments for character
+ ranges are shown in square brackets (such as "[CONTROL CHARACTERS]")
+ and do not come from the standard.
+
+ Note: a glossary of terms used in Unicode can be found in [Glossary].
+ Information on the Unicode character encoding model can be found in
+ [CharModel].
+
+ The term "combining mark", as used in this specification, refers to
+ any Unicode [Unicode] code point which has a mark property (Mn, Mc,
+ Me). Appendix A provides a definitive list of combining marks.
+
+
+1. Introduction
+
+1.1. Background
+
+ A Lightweight Directory Access Protocol (LDAP) [Roadmap] matching rule
+ [Syntaxes] defines an algorithm for determining whether a presented
+ value matches an attribute value in accordance with the criteria
+ defined for the rule. The proposition may be evaluated to True,
+ False, or Undefined.
+
+ True - the attribute contains a matching value,
+
+ False - the attribute contains no matching value,
+
+ Undefined - it cannot be determined whether the attribute contains
+ a matching value or not.
+
+
+
+Zeilenga LDAPprep [Page 2]
+
+Internet-Draft draft-ietf-ldapbis-strprep-07 23 January 2006
+
+
+ For instance, the caseIgnoreMatch matching rule may be used to compare
+ whether the commonName attribute contains a particular value without
+ regard for case and insignificant spaces.
+
+
+1.2. X.500 String Matching Rules
+
+ "X.520: Selected attribute types" [X.520] provides (amongst other
+ things) value syntaxes and matching rules for comparing values
+ commonly used in the Directory. These specifications are inadequate
+ for strings composed of Unicode [Unicode] characters.
+
+ The caseIgnoreMatch matching rule [X.520], for example, is simply
+ defined as being a case insensitive comparison where insignificant
+ spaces are ignored. For printableString, there is only one space
+ character and case mapping is bijective, hence this definition is
+ sufficient. However, for Unicode string types such as
+ universalString, this is not sufficient. For example, a case
+ insensitive matching implementation which folded lower case characters
+ to upper case would yield different different results than an
+ implementation which used upper case to lower case folding. Or one
+ implementation may view space as referring to only SPACE (U+0020), a
+ second implementation may view any character with the space separator
+ (Zs) property as a space, and another implementation may view any
+ character with the whitespace (WS) category as a space.
+
+ The lack of precise specification for character string matching has
+ led to significant interoperability problems. When used in
+ certificate chain validation, security vulnerabilities can arise. To
+ address these problems, this document defines precise algorithms for
+ preparing character strings for matching.
+
+
+1.3. Relationship to "stringprep"
+
+ The character string preparation algorithms described in this document
+ are based upon the "stringprep" approach [RFC3454]. In "stringprep",
+ presented and stored values are first prepared for comparison and so
+ that a character-by-character comparison yields the "correct" result.
+
+ The approach used here is a refinement of the "stringprep" [RFC3454]
+ approach. Each algorithm involves two additional preparation steps.
+
+ a) prior to applying the Unicode string preparation steps outlined in
+ "stringprep", the string is transcoded to Unicode;
+
+ b) after applying the Unicode string preparation steps outlined in
+ "stringprep", the string is modified to appropriately handle
+
+
+
+Zeilenga LDAPprep [Page 3]
+
+Internet-Draft draft-ietf-ldapbis-strprep-07 23 January 2006
+
+
+ characters insignificant to the matching rule.
+
+ Hence, preparation of character strings for X.500 matching involves
+ the following steps:
+
+ 1) Transcode
+ 2) Map
+ 3) Normalize
+ 4) Prohibit
+ 5) Check Bidi (Bidirectional)
+ 6) Insignificant Character Handling
+
+ These steps are described in Section 2.
+
+ It is noted that while various tables of Unicode characters included
+ or referenced by this specification are derived from Unicode [UNICODE]
+ data, these tables are to be considered definitive for the purpose of
+ implementing this specification.
+
+
+1.4. Relationship to the LDAP Technical Specification
+
+ This document is a integral part of the LDAP technical specification
+ [Roadmap] which obsoletes the previously defined LDAP technical
+ specification [RFC3377] in its entirety.
+
+ This document details new LDAP internationalized character string
+ preparation algorithms used by [Syntaxes] and possible other technical
+ specifications defining LDAP syntaxes and/or matching rules.
+
+
+1.5. Relationship to X.500
+
+ LDAP is defined [Roadmap] in X.500 terms as an X.500 access mechanism.
+ As such, there is a strong desire for alignment between LDAP and X.500
+ syntax and semantics. The character string preparation algorithms
+ described in this document are based upon "Internationalized String
+ Matching Rules for X.500" [XMATCH] proposal to ITU/ISO Joint Study
+ Group 2.
+
+
+2. String Preparation
+
+ The following six-step process SHALL be applied to each presented and
+ attribute value in preparation for character string matching rule
+ evaluation.
+
+ 1) Transcode
+
+
+
+Zeilenga LDAPprep [Page 4]
+
+Internet-Draft draft-ietf-ldapbis-strprep-07 23 January 2006
+
+
+ 2) Map
+ 3) Normalize
+ 4) Prohibit
+ 5) Check bidi
+ 6) Insignificant Character Handling
+
+ Failure in any step causes the assertion to evaluate to Undefined.
+
+ The character repertoire of this process is Unicode 3.2 [Unicode].
+
+ Note that this six-step process specification is intended to described
+ expected matching behavior. Implementations are free use alternative
+ processes so long as the matching rule evaluation behavior provided is
+ consistent with the behavior described by this specification.
+
+
+2.1. Transcode
+
+ Each non-Unicode string value is transcoded to Unicode.
+
+ PrintableString [X.680] value are transcoded directly to Unicode.
+
+ UniversalString, UTF8String, and bmpString [X.680] values need not be
+ transcoded as they are Unicode-based strings (in the case of
+ bmpString, a subset of Unicode).
+
+ TeletexString [X.680] values are transcoded to Unicode. As there is
+ no standard for mapping TeletexString values to Unicode, the mapping
+ is left a local matter.
+
+ For these and other reasons, use of TeletexString is NOT RECOMMENDED.
+
+ The output is the transcoded string.
+
+
+2.2. Map
+
+ SOFT HYPHEN (U+00AD) and MONGOLIAN TODO SOFT HYPHEN (U+1806) code
+ points are mapped to nothing. COMBINING GRAPHEME JOINER (U+034F) and
+ VARIATION SELECTORs (U+180B-180D, FF00-FE0F) code points are also
+ mapped to nothing. The OBJECT REPLACEMENT CHARACTER (U+FFFC) is
+ mapped to nothing.
+
+ CHARACTER TABULATION (U+0009), LINE FEED (LF) (U+000A), LINE
+ TABULATION (U+000B), FORM FEED (FF) (U+000C), CARRIAGE RETURN (CR)
+ (U+000D), and NEXT LINE (NEL) (U+0085) are mapped to SPACE (U+0020).
+
+ All other control code (e.g., Cc) points or code points with a control
+
+
+
+Zeilenga LDAPprep [Page 5]
+
+Internet-Draft draft-ietf-ldapbis-strprep-07 23 January 2006
+
+
+ function (e.g., Cf) are mapped to nothing. The following is a
+ complete list of these code points: U+0000-0008, 000E-001F, 007F-0084,
+ 0086-009F, 06DD, 070F, 180E, 200C-200F, 202A-202E, 2060-2063,
+ 206A-206F, FEFF, FFF9-FFFB, 1D173-1D17A, E0001, E0020-E007F.
+
+ ZERO WIDTH SPACE (U+200B) is mapped to nothing. All other code points
+ with Separator (space, line, or paragraph) property (e.g, Zs, Zl, or
+ Zp) are mapped to SPACE (U+0020). The following is a complete list of
+ these code points: U+0020, 00A0, 1680, 2000-200A, 2028-2029, 202F,
+ 205F, 3000.
+
+ For case ignore, numeric, and stored prefix string matching rules,
+ characters are case folded per B.2 of [RFC3454].
+
+ The output is the mapped string.
+
+
+2.3. Normalize
+
+ The input string is be normalized to Unicode Form KC (compatibility
+ composed) as described in [UAX15]. The output is the normalized
+ string.
+
+
+2.4. Prohibit
+
+ All Unassigned code points are prohibited. Unassigned code points are
+ listed in Table A.1 of [RFC3454].
+
+ Characters which, per Section 5.8 of [Stringprep], change display
+ properties or are deprecated are prohibited. These characters are are
+ listed in Table C.8 of [RFC3454].
+
+ Private Use code points are prohibited. These characters are listed
+ in Table C.3 of [RFC3454].
+
+ All non-character code points are prohibited. These code points are
+ listed in Table C.4 of [RFC3454].
+
+ Surrogate codes are prohibited. These characters are listed in Table
+ C.5 of [RFC3454].
+
+ The REPLACEMENT CHARACTER (U+FFFD) code point is prohibited.
+
+ The step fails if the input string contains any prohibited code point.
+ Otherwise, the output is the input string.
+
+
+
+
+
+Zeilenga LDAPprep [Page 6]
+
+Internet-Draft draft-ietf-ldapbis-strprep-07 23 January 2006
+
+
+2.5. Check bidi
+
+ Bidirectional characters are ignored.
+
+
+2.6. Insignificant Character Handling
+
+ In this step, the string is modified to ensure proper handling of
+ characters insignificant to the matching rule. This modification
+ differs from matching rule to matching rule.
+
+ Section 2.6.1 applies to case ignore and exact string matching.
+ Section 2.6.2 applies to numericString matching.
+ Section 2.6.3 applies to telephoneNumber matching.
+
+
+2.6.1. Insignificant Space Handling
+
+ For the purposes of this section, a space is defined to be the SPACE
+ (U+0020) code point followed by no combining marks.
+
+ NOTE - The previous steps ensure that the string cannot contain any
+ code points in the separator class, other than SPACE (U+0020).
+
+ If the input string contains at least one non-space character, then
+ the string is modified such that the string starts with exactly one
+ space character, ends with exactly one SPACE character, and that any
+ inner (non-empty) sequence of space characters is replaced with
+ exactly two SPACE characters. For instance, the input strings
+ "foo<SPACE>bar<SPACE><SPACE>", results in the output
+ "<SPACE>foo<SPACE><SPACE>bar<SPACE>".
+
+ Otherwise, if the string being prepared is an initial, any, or final
+ substring, then the output string is exactly one SPACE character, else
+ the output string is exactly two SPACEs.
+
+ Appendix B discusses the rationale for the behavior.
+
+
+2.6.2. numericString Insignificant Character Handling
+
+ For the purposes of this section, a space is defined to be the SPACE
+ (U+0020) code point followed by no combining marks.
+
+ All spaces are regarded as insignificant and are to be removed.
+
+ For example, removal of spaces from the Form KC string:
+ "<SPACE><SPACE>123<SPACE><SPACE>456<SPACE><SPACE>"
+
+
+
+Zeilenga LDAPprep [Page 7]
+
+Internet-Draft draft-ietf-ldapbis-strprep-07 23 January 2006
+
+
+ would result in the output string:
+ "123456"
+ and the Form KC string:
+ "<SPACE><SPACE><SPACE>"
+ would result in the output string:
+ "" (an empty string).
+
+
+2.6.3. telephoneNumber Insignificant Character Handling
+
+ For the purposes of this section, a hyphen is defined to be
+ HYPHEN-MINUS (U+002D), ARMENIAN HYPHEN (U+058A), HYPHEN (U+2010),
+ NON-BREAKING HYPHEN (U+2011), MINUS SIGN (U+2212), SMALL HYPHEN-MINUS
+ (U+FE63), or FULLWIDTH HYPHEN-MINUS (U+FF0D) code point followed by no
+ combining marks and a space is defined to be the SPACE (U+0020) code
+ point followed by no combining marks.
+
+ All hyphens and spaces are considered insignificant and are to be
+ removed.
+
+ For example, removal of hyphens and spaces from the Form KC string:
+ "<SPACE><HYPHEN>123<SPACE><SPACE>456<SPACE><HYPHEN>"
+ would result in the output string:
+ "123456"
+ and the Form KC string:
+ "<HYPHEN><HYPHEN><HYPHEN>"
+ would result in the (empty) output string:
+ "".
+
+
+3. Security Considerations
+
+ "Preparation for International Strings ('stringprep')" [RFC3454]
+ security considerations generally apply to the algorithms described
+ here.
+
+
+4. Acknowledgments
+
+ The approach used in this document is based upon design principles and
+ algorithms described in "Preparation of Internationalized Strings
+ ('stringprep')" [RFC3454] by Paul Hoffman and Marc Blanchet. Some
+ additional guidance was drawn from Unicode Technical Standards,
+ Technical Reports, and Notes.
+
+ This document is a product of the IETF LDAP Revision (LDAPBIS) Working
+ Group.
+
+
+
+
+Zeilenga LDAPprep [Page 8]
+
+Internet-Draft draft-ietf-ldapbis-strprep-07 23 January 2006
+
+
+5. Author's Address
+
+ Kurt D. Zeilenga
+ OpenLDAP Foundation
+
+ Email: Kurt at OpenLDAP.org
+
+
+6. References
+
+ [[Note to the RFC Editor: please replace the citation tags used in
+ referencing Internet-Drafts with tags of the form RFCnnnn where
+ possible.]]
+
+
+6.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14 (also RFC 2119), March 1997.
+
+ [RFC3454] Hoffman, P. and M. Blanchet, "Preparation of
+ Internationalized Strings ('stringprep')", RFC 3454,
+ December 2002.
+
+ [Roadmap] Zeilenga, K. (editor), "LDAP: Technical Specification
+ Road Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in
+ progress.
+
+ [Syntaxes] Legg, S. (editor), "LDAP: Syntaxes and Matching Rules",
+ draft-ietf-ldapbis-syntaxes-xx.txt, a work in progress.
+
+ [Unicode] The Unicode Consortium, "The Unicode Standard, Version
+ 3.2.0" is defined by "The Unicode Standard, Version 3.0"
+ (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5),
+ as amended by the "Unicode Standard Annex #27: Unicode
+ 3.1" (http://www.unicode.org/reports/tr27/) and by the
+ "Unicode Standard Annex #28: Unicode 3.2"
+ (http://www.unicode.org/reports/tr28/).
+
+ [UAX15] Davis, M. and M. Duerst, "Unicode Standard Annex #15:
+ Unicode Normalization Forms, Version 3.2.0".
+ <http://www.unicode.org/unicode/reports/tr15/tr15-22.html>,
+ March 2002.
+
+ [X.680] International Telecommunication Union -
+ Telecommunication Standardization Sector, "Abstract
+ Syntax Notation One (ASN.1) - Specification of Basic
+ Notation", X.680(2002) (also ISO/IEC 8824-1:2002).
+
+
+
+Zeilenga LDAPprep [Page 9]
+
+Internet-Draft draft-ietf-ldapbis-strprep-07 23 January 2006
+
+
+6.2. Informative References
+
+ [X.500] International Telecommunication Union -
+ Telecommunication Standardization Sector, "The Directory
+ -- Overview of concepts, models and services,"
+ X.500(1993) (also ISO/IEC 9594-1:1994).
+
+ [X.501] International Telecommunication Union -
+ Telecommunication Standardization Sector, "The Directory
+ -- Models," X.501(1993) (also ISO/IEC 9594-2:1994).
+
+ [X.520] International Telecommunication Union -
+ Telecommunication Standardization Sector, "The
+ Directory: Selected Attribute Types", X.520(1993) (also
+ ISO/IEC 9594-6:1994).
+
+ [Glossary] The Unicode Consortium, "Unicode Glossary",
+ <http://www.unicode.org/glossary/>.
+
+ [CharModel] Whistler, K. and M. Davis, "Unicode Technical Report
+ #17, Character Encoding Model", UTR17,
+ <http://www.unicode.org/unicode/reports/tr17/>, August
+ 2000.
+
+ [Filters] Smith, M. (editor), LDAPbis WG, "LDAP: String
+ Representation of Search Filters",
+ draft-ietf-ldapbis-filter-xx.txt, a work in progress.
+
+ [XMATCH] Zeilenga, K., "Internationalized String Matching Rules
+ for X.500", draft-zeilenga-ldapbis-strmatch-xx.txt, a
+ work in progress.
+
+
+Appendix A. Combining Marks
+
+ This appendix is normative.
+
+ This table was derived from Unicode [Unicode] data
+ files, it lists all code points with the Mn, Mc, or Me
+ properties. This table is to be considered definitive
+ for the purposes of implementation of this
+ specification.
+
+
+ 0300-034F 0360-036F 0483-0486 0488-0489 0591-05A1
+ 05A3-05B9 05BB-05BC 05BF 05C1-05C2 05C4 064B-0655 0670
+ 06D6-06DC 06DE-06E4 06E7-06E8 06EA-06ED 0711 0730-074A
+ 07A6-07B0 0901-0903 093C 093E-094F 0951-0954 0962-0963
+
+
+
+Zeilenga LDAPprep [Page 10]
+
+Internet-Draft draft-ietf-ldapbis-strprep-07 23 January 2006
+
+
+ 0981-0983 09BC 09BE-09C4 09C7-09C8 09CB-09CD 09D7
+ 09E2-09E3 0A02 0A3C 0A3E-0A42 0A47-0A48 0A4B-0A4D
+ 0A70-0A71 0A81-0A83 0ABC 0ABE-0AC5 0AC7-0AC9 0ACB-0ACD
+ 0B01-0B03 0B3C 0B3E-0B43 0B47-0B48 0B4B-0B4D 0B56-0B57
+ 0B82 0BBE-0BC2 0BC6-0BC8 0BCA-0BCD 0BD7 0C01-0C03
+ 0C3E-0C44 0C46-0C48 0C4A-0C4D 0C55-0C56 0C82-0C83
+ 0CBE-0CC4 0CC6-0CC8 0CCA-0CCD 0CD5-0CD6 0D02-0D03
+ 0D3E-0D43 0D46-0D48 0D4A-0D4D 0D57 0D82-0D83 0DCA
+ 0DCF-0DD4 0DD6 0DD8-0DDF 0DF2-0DF3 0E31 0E34-0E3A
+ 0E47-0E4E 0EB1 0EB4-0EB9 0EBB-0EBC 0EC8-0ECD 0F18-0F19
+ 0F35 0F37 0F39 0F3E-0F3F 0F71-0F84 0F86-0F87 0F90-0F97
+ 0F99-0FBC 0FC6 102C-1032 1036-1039 1056-1059 1712-1714
+ 1732-1734 1752-1753 1772-1773 17B4-17D3 180B-180D 18A9
+ 20D0-20EA 302A-302F 3099-309A FB1E FE00-FE0F FE20-FE23
+ 1D165-1D169 1D16D-1D172 1D17B-1D182 1D185-1D18B
+ 1D1AA-1D1AD
+
+
+
+Appendix B. Substrings Matching
+
+ This appendix is non-normative.
+
+ In absence of substrings matching, the insignificant
+ space handling for case ignore/exact matching could be
+ simplified. Specifically, the handling could be as
+ require all sequences of one or more spaces be replaced
+ with one space and, if string contains non-space
+ characters, removal of all all leading spaces and
+ trailing spaces.
+
+ In the presence of substrings matching, this simplified
+ space handling would lead to unexpected and undesirable
+ matching behavior. For instance:
+ 1) (CN=foo\20*\20bar) would match the CN value "foobar" but not
+ "foo<SPACE>bar" nor "foo<SPACE><SPACE>bar";
+ 2) (CN=*\20foobar\20*) would match "foobar", but (CN=*\20*foobar*\20*)
+ would not;
+ 3) (CN=foo\20*\20bar) would match "foo<SPACE>X<SPACE>bar" but not
+ "foo<SPACE><SPACE>bar".
+
+ Note to readers not familiar with LDAP substrings matching: the LDAP
+ filter [Filters] assertion (CN=A*B*C) says "match any value (of the
+ attribute CN) which begins with A, contains B after A, ends with C
+ where C is also after B."
+
+ The first case illustrates that this simplified space handling would
+ cause leading and trailing spaces in substrings of the string to be
+
+
+
+Zeilenga LDAPprep [Page 11]
+
+Internet-Draft draft-ietf-ldapbis-strprep-07 23 January 2006
+
+
+ regarded as insignificant. However, only leading and trailing (as
+ well as multiple consecutive spaces) of the string (as a whole) are
+ insignificant.
+
+ The second case illustrates that this simplified space handling would
+ cause sub-partitioning failures. That is, if a prepared any substring
+ matches a partition of the attribute value, then an assertion
+ constructed by subdividing that substring into multiple substrings
+ should also match.
+
+ The third case illustrates that this simplified space handling causes
+ another partitioning failure. Though both the initial or final
+ strings match different portions of "foo<SPACE>X<SPACE>bar" with
+ neither matching the X portion, they don't match a string consisting
+ of the two matched portions less the unmatched X portion.
+
+ In designing an appropriate approach for space handling for substrings
+ matching, one must study key aspects of X.500 case exact/ignore
+ matching. X.520 [X.520] says:
+ The [substrings] rule returns TRUE if there is a partitioning of
+ the attribute value (into portions) such that:
+ - the specified substrings (initial, any, final) match different
+ portions of the value in the order of the strings sequence;
+ - initial, if present, matches the first portion of the value;
+ - final, if present, matches the last portion of the value;
+ - any, if present, matches some arbitrary portion of the value.
+
+ That is, the substrings assertion (CN=foo\20*\20bar) matches the
+ attribute value "foo<SPACE><SPACE>bar" as the value can be partitioned
+ into the portions "foo<SPACE>" and "<SPACE>bar" meeting the above
+ requirements.
+
+ X.520 also says:
+ [T]he following spaces are regarded as not significant:
+ - leading spaces (i.e. those preceding the first character that is
+ not a space);
+ - trailing spaces (i.e. those following the last character that is
+ not a space);
+ - multiple consecutive spaces (these are taken as equivalent to a
+ single space character).
+
+ This statement applies to the assertion values and attribute values
+ as whole strings, and not individually to substrings of an assertion
+ value. In particular, the statements should be taken to mean that
+ if an assertion value and attribute value match without any
+ consideration to insignificant characters, then that assertion value
+ should also match any attribute value which differs only by inclusion
+ or removal of insignificant characters.
+
+
+
+Zeilenga LDAPprep [Page 12]
+
+Internet-Draft draft-ietf-ldapbis-strprep-07 23 January 2006
+
+
+ Hence, the assertion (CN=foo\20*\20bar) matches
+ "foo<SPACE><SPACE><SPACE>bar" and "foo<SPACE>bar" as these values
+ only differ from "foo<SPACE><SPACE>bar" by the inclusion or removal
+ of insignificant spaces.
+
+ Astute readers of this text will also note that there are special
+ cases where the specified space handling does not ignore spaces
+ which could be considered insignificant. For instance, the assertion
+ (CN=\20*\20*\20) does not match "<SPACE><SPACE><SPACE>"
+ (insignificant spaces present in value) nor " " (insignificant
+ spaces not present in value). However, as these cases have no
+ practical application that cannot be met by simple assertions, e.g.
+ (cn=\20), and this minor anomaly can only be fully addressed by a
+ preparation algorithm to be used in conjunction with
+ character-by-character partitioning and matching, the anomaly is
+ considered acceptable.
+
+
+
+Intellectual Property Rights
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed
+ to pertain to the implementation or use of the technology described
+ in this document or the extent to which any license under such
+ rights might or might not be available; nor does it represent that
+ it has made any independent effort to identify any such rights.
+ Information on the procedures with respect to rights in RFC documents
+ can be found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use
+ of such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository
+ at http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr at ietf.org.
+
+
+
+Full Copyright
+
+ Copyright (C) The Internet Society (2006).
+
+
+
+Zeilenga LDAPprep [Page 13]
+
+Internet-Draft draft-ietf-ldapbis-strprep-07 23 January 2006
+
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
+ REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
+ INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
+ IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
+ THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga LDAPprep [Page 14]
+
Added: openldap/vendor/openldap-release/doc/drafts/draft-ietf-ldapbis-syntaxes-xx.txt
===================================================================
--- openldap/vendor/openldap-release/doc/drafts/draft-ietf-ldapbis-syntaxes-xx.txt (rev 0)
+++ openldap/vendor/openldap-release/doc/drafts/draft-ietf-ldapbis-syntaxes-xx.txt 2007-09-15 10:38:52 UTC (rev 844)
@@ -0,0 +1,3027 @@
+
+
+
+
+
+
+INTERNET-DRAFT S. Legg
+draft-ietf-ldapbis-syntaxes-11.txt eB2Bcom
+Intended Category: Standards Track 23 June 2005
+Obsoletes: RFC 2252, RFC 2256 Updates: RFC 3698
+
+
+ Lightweight Directory Access Protocol (LDAP):
+ Syntaxes and Matching Rules
+
+ Copyright (C) The Internet Society (2005). All Rights Reserved.
+
+ Status of this Memo
+
+ By submitting this Internet-draft, each author represents that any
+ applicable patent or other IPR claims of which he or she is aware
+ have been or will be disclosed, and any of which he or she becomes
+ aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+ By submitting this Internet-draft, I accept the provisions of Section
+ 3 of BCP 78.
+
+ Internet-Drafts are working documents of the Internet Engineering
+ Task Force (IETF), its areas, and its working groups. Note that
+ other groups may also distribute working documents as
+ Internet-Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference
+ material or to cite them other than as "work in progress".
+
+ The list of current Internet-Drafts can be accessed at
+ http://www.ietf.org/1id-abstracts.html
+
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html
+
+ This document is intended to be, after appropriate review and
+ revision, submitted to the RFC Editor as a Standard Track document.
+ Distribution of this document is unlimited. Technical discussion of
+ this document should take place on the IETF LDAP Revision Working
+ Group (LDAPbis) mailing list <ietf-ldapbis at openldap.org>. Please
+ send editorial comments directly to the editor
+ <steven.legg at eb2bcom.com>.
+
+ This Internet-Draft expires on 23 December 2005.
+
+Abstract
+
+
+
+Legg Expires 23 December 2005 [Page 1]
+
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
+
+ Each attribute stored in a Lightweight Directory Access Protocol
+ (LDAP) directory, and whose values may be transfered in the LDAP
+ protocol, has a defined syntax which constrains the structure and
+ format of its values. The comparison semantics for values of a
+ syntax are not part of the syntax definition but are instead provided
+ through separately defined matching rules. Matching rules specify an
+ argument, an assertion value, which also has a defined syntax. This
+ document defines a base set of syntaxes and matching rules for use in
+ defining attributes for LDAP directories.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Legg Expires 23 December 2005 [Page 2]
+
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 2. Conventions. . . . . . . . . . . . . . . . . . . . . . . . . . 5
+ 3. Syntaxes . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
+ 3.1. General Considerations . . . . . . . . . . . . . . . . . 6
+ 3.2. Common Definitions . . . . . . . . . . . . . . . . . . . 7
+ 3.3. Syntax Definitions . . . . . . . . . . . . . . . . . . . 7
+ 3.3.1. Attribute Type Description . . . . . . . . . . . 7
+ 3.3.2. Bit String . . . . . . . . . . . . . . . . . . . 8
+ 3.3.3. Boolean. . . . . . . . . . . . . . . . . . . . . 8
+ 3.3.4. Country String . . . . . . . . . . . . . . . . . 8
+ 3.3.5. Delivery Method. . . . . . . . . . . . . . . . . 9
+ 3.3.6. Directory String . . . . . . . . . . . . . . . . 9
+ 3.3.7. DIT Content Rule Description . . . . . . . . . . 10
+ 3.3.8. DIT Structure Rule Description . . . . . . . . . 11
+ 3.3.9. DN . . . . . . . . . . . . . . . . . . . . . . . 11
+ 3.3.10. Enhanced Guide . . . . . . . . . . . . . . . . . 12
+ 3.3.11. Facsimile Telephone Number . . . . . . . . . . . 13
+ 3.3.12. Fax. . . . . . . . . . . . . . . . . . . . . . . 13
+ 3.3.13. Generalized Time . . . . . . . . . . . . . . . . 14
+ 3.3.14. Guide. . . . . . . . . . . . . . . . . . . . . . 15
+ 3.3.15. IA5 String . . . . . . . . . . . . . . . . . . . 16
+ 3.3.16. Integer. . . . . . . . . . . . . . . . . . . . . 16
+ 3.3.17. JPEG . . . . . . . . . . . . . . . . . . . . . . 16
+ 3.3.18. LDAP Syntax Description. . . . . . . . . . . . . 17
+ 3.3.19. Matching Rule Description. . . . . . . . . . . . 17
+ 3.3.20. Matching Rule Use Description. . . . . . . . . . 18
+ 3.3.21. Name and Optional UID. . . . . . . . . . . . . . 18
+ 3.3.22. Name Form Description. . . . . . . . . . . . . . 19
+ 3.3.23. Numeric String . . . . . . . . . . . . . . . . . 19
+ 3.3.24. Object Class Description . . . . . . . . . . . . 19
+ 3.3.25. Octet String . . . . . . . . . . . . . . . . . . 20
+ 3.3.26. OID. . . . . . . . . . . . . . . . . . . . . . . 20
+ 3.3.27. Other Mailbox. . . . . . . . . . . . . . . . . . 21
+ 3.3.28. Postal Address . . . . . . . . . . . . . . . . . 21
+ 3.3.29. Printable String . . . . . . . . . . . . . . . . 22
+ 3.3.30. Substring Assertion. . . . . . . . . . . . . . . 23
+ 3.3.31. Telephone Number . . . . . . . . . . . . . . . . 23
+ 3.3.32. Teletex Terminal Identifier. . . . . . . . . . . 24
+ 3.3.33. Telex Number . . . . . . . . . . . . . . . . . . 25
+ 3.3.34. UTC Time . . . . . . . . . . . . . . . . . . . . 25
+ 4. Matching Rules . . . . . . . . . . . . . . . . . . . . . . . . 26
+ 4.1. General Considerations . . . . . . . . . . . . . . . . . 26
+ 4.2. Matching Rule Definitions. . . . . . . . . . . . . . . . 28
+ 4.2.1. bitStringMatch . . . . . . . . . . . . . . . . . 28
+ 4.2.2. booleanMatch . . . . . . . . . . . . . . . . . . 29
+ 4.2.3. caseExactIA5Match. . . . . . . . . . . . . . . . 29
+
+
+
+Legg Expires 23 December 2005 [Page 3]
+
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
+
+ 4.2.4. caseExactMatch . . . . . . . . . . . . . . . . . 30
+ 4.2.5. caseExactOrderingMatch . . . . . . . . . . . . . 30
+ 4.2.6. caseExactSubstringsMatch . . . . . . . . . . . . 31
+ 4.2.7. caseIgnoreIA5Match . . . . . . . . . . . . . . . 31
+ 4.2.8. caseIgnoreIA5SubstringsMatch . . . . . . . . . . 32
+ 4.2.9. caseIgnoreListMatch. . . . . . . . . . . . . . . 32
+ 4.2.10. caseIgnoreListSubstringsMatch. . . . . . . . . . 33
+ 4.2.11. caseIgnoreMatch. . . . . . . . . . . . . . . . . 33
+ 4.2.12. caseIgnoreOrderingMatch. . . . . . . . . . . . . 34
+ 4.2.13. caseIgnoreSubstringsMatch. . . . . . . . . . . . 34
+ 4.2.14. directoryStringFirstComponentMatch . . . . . . . 35
+ 4.2.15. distinguishedNameMatch . . . . . . . . . . . . . 36
+ 4.2.16. generalizedTimeMatch . . . . . . . . . . . . . . 36
+ 4.2.17. generalizedTimeOrderingMatch . . . . . . . . . . 37
+ 4.2.18. integerFirstComponentMatch . . . . . . . . . . . 37
+ 4.2.19. integerMatch . . . . . . . . . . . . . . . . . . 38
+ 4.2.20. integerOrderingMatch . . . . . . . . . . . . . . 38
+ 4.2.21. keywordMatch . . . . . . . . . . . . . . . . . . 38
+ 4.2.22. numericStringMatch . . . . . . . . . . . . . . . 39
+ 4.2.23. numericStringOrderingMatch . . . . . . . . . . . 39
+ 4.2.24. numericStringSubstringsMatch . . . . . . . . . . 40
+ 4.2.25. objectIdentifierFirstComponentMatch. . . . . . . 40
+ 4.2.26. objectIdentifierMatch. . . . . . . . . . . . . . 41
+ 4.2.27. octetStringMatch . . . . . . . . . . . . . . . . 41
+ 4.2.28. octetStringOrderingMatch . . . . . . . . . . . . 42
+ 4.2.29. telephoneNumberMatch . . . . . . . . . . . . . . 42
+ 4.2.30. telephoneNumberSubstringsMatch . . . . . . . . . 43
+ 4.2.31. uniqueMemberMatch. . . . . . . . . . . . . . . . 44
+ 4.2.32. wordMatch. . . . . . . . . . . . . . . . . . . . 44
+ 5. Security Considerations. . . . . . . . . . . . . . . . . . . . 44
+ 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 45
+ 7. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 45
+ Appendix A. Summary of Syntax Object Identifiers . . . . . . . . . 47
+ Appendix B. Changes from RFC 2252. . . . . . . . . . . . . . . . . 48
+ Normative References . . . . . . . . . . . . . . . . . . . . . . . 50
+ Informative References . . . . . . . . . . . . . . . . . . . . . . 52
+ Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 53
+ Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 53
+
+1. Introduction
+
+ Each attribute stored in a Lightweight Directory Access Protocol
+ (LDAP) directory [ROADMAP], and whose values may be transfered in the
+ LDAP protocol [PROT], has a defined syntax (i.e., data type) which
+ constrains the structure and format of its values. The comparison
+ semantics for values of a syntax are not part of the syntax
+ definition but are instead provided through separately defined
+ matching rules. Matching rules specify an argument, an assertion
+
+
+
+Legg Expires 23 December 2005 [Page 4]
+
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
+
+ value, which also has a defined syntax. This document defines a base
+ set of syntaxes and matching rules for use in defining attributes for
+ LDAP directories.
+
+ Readers are advised to familiarize themselves with the Directory
+ Information Models [MODELS] before reading the rest of this document.
+ Section 3 provides definitions for the base set of LDAP syntaxes.
+ Section 4 provides definitions for the base set of matching rules for
+ LDAP.
+
+ This document is a integral part of the LDAP technical specification
+ [ROADMAP] which obsoletes the previously defined LDAP technical
+ specification [RFC3377] in its entirety.
+
+ Sections 4, 5 and 7 of RFC 2252 [RFC2252] are obsoleted by [MODELS].
+ The remainder of RFC 2252 is obsoleted by this document. Sections 6
+ and 8 of RFC 2256 [RFC2256] are obsoleted by this document. The
+ remainder of RFC 2256 is obsoleted by [SCHEMA] and [MODELS]. All but
+ Section 2.11 of RFC 3698 [RFC3698] is obsoleted by this document.
+
+ A number of schema elements which were included in the previous
+ revision of the LDAP technical specification are not included in this
+ revision of LDAP. Public Key Infrastructure schema elements are now
+ specified in [LDAP-PKI]. Unless reintroduced in future technical
+ specifications, the remainder are to be considered Historic.
+
+ The changes with respect to RFC 2252 are described in Appendix B of
+ this document.
+
+2. Conventions
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in BCP 14, RFC 2119
+ [KEYWORD].
+
+ Syntax definitions are written according to the <SyntaxDescription>
+ ABNF [ABNF] rule specified in [MODELS], and matching rule definitions
+ are written according to the <MatchingRuleDescription> ABNF rule
+ specified in [MODELS], except that the syntax and matching rule
+ definitions provided in this document are line-wrapped for
+ readability. When such definitions are transfered as attribute
+ values in the LDAP protocol (e.g., as values of the ldapSyntaxes and
+ matchingRules attributes [MODELS] respectively) then those values
+ would not contain line breaks.
+
+3. Syntaxes
+
+
+
+
+Legg Expires 23 December 2005 [Page 5]
+
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
+
+ Syntax definitions constrain the structure of attribute values stored
+ in an LDAP directory, and determine the representation of attribute
+ and assertion values transfered in the LDAP protocol.
+
+ Syntaxes that are required for directory operation, or that are in
+ common use, are specified in this section. Servers SHOULD recognize
+ all the syntaxes listed in this document, but are not required to
+ otherwise support them, and MAY recognise or support other syntaxes.
+ However, the definition of additional arbitrary syntaxes is
+ discouraged since it will hinder interoperability. Client and server
+ implementations typically do not have the ability to dynamically
+ recognize new syntaxes.
+
+3.1. General Considerations
+
+ The description of each syntax specifies how attribute or assertion
+ values conforming to the syntax are to be represented when transfered
+ in the LDAP protocol [PROT]. This representation is referred to as
+ the LDAP-specific encoding to distinguish it from other methods of
+ encoding attribute values (e.g., the Basic Encoding Rules (BER)
+ encoding [BER] used by X.500 [X.500] directories).
+
+ The LDAP-specific encoding of a given attribute syntax always
+ produces octet-aligned values. To the greatest extent possible,
+ encoding rules for LDAP syntaxes should produce character strings
+ that can be displayed with little or no translation by clients
+ implementing LDAP. However, clients MUST NOT assume that the
+ LDAP-specific encoding of a value of an unrecognized syntax is a
+ human-readable character string. There are a few cases (e.g., the
+ JPEG syntax) when it is not reasonable to produce a human-readable
+ representation.
+
+ Each LDAP syntax is uniquely identified with an object identifier
+ [ASN.1] represented in the dotted-decimal format (short descriptive
+ names are not defined for syntaxes). These object identifiers are
+ not intended to be displayed to users. The object identifiers for
+ the syntaxes defined in this document are summarized in Appendix A.
+
+ A suggested minimum upper bound on the number of characters in an
+ attribute value with a string-based syntax, or the number of octets
+ in a value for all other syntaxes, MAY be indicated by appending the
+ bound inside of curly braces following the syntax's OBJECT IDENTIFIER
+ in an attribute type definition (see the <noidlen> rule in [MODELS]).
+ Such a bound is not considered part of the syntax identifier.
+
+ For example, "1.3.6.1.4.1.1466.115.121.1.15{64}" in an attribute
+ definition suggests that the directory server will allow a value of
+ the attribute to be up to 64 characters long, although it may allow
+
+
+
+Legg Expires 23 December 2005 [Page 6]
+
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
+
+ longer character strings. Note that a single character of the
+ Directory String syntax can be encoded in more than one octet since
+ UTF-8 [UTF8] is a variable-length encoding. Therefore a 64 character
+ string may be more than 64 octets in length.
+
+3.2. Common Definitions
+
+ The following ABNF rules are used in a number of the syntax
+ definitions in Section 3.3.
+
+ PrintableCharacter = ALPHA / DIGIT / SQUOTE / LPAREN / RPAREN /
+ PLUS / COMMA / HYPHEN / DOT / EQUALS /
+ SLASH / COLON / QUESTION / SPACE
+ PrintableString = 1*PrintableCharacter
+ IA5String = *(%x00-7F)
+ SLASH = %x2F ; forward slash ("/")
+ COLON = %x3A ; colon (":")
+ QUESTION = %x3F ; question mark ("?")
+
+ The <ALPHA>, <DIGIT>, <SQUOTE>, <LPAREN>, <RPAREN>, <PLUS>, <COMMA>,
+ <HYPHEN>, <DOT>, <EQUALS> and <SPACE> rules are defined in [MODELS].
+
+3.3. Syntax Definitions
+
+3.3.1. Attribute Type Description
+
+ A value of the Attribute Type Description syntax is the definition of
+ an attribute type. The LDAP-specific encoding of a value of this
+ syntax is defined by the <AttributeTypeDescription> rule in [MODELS].
+
+ For example, the following definition of the createTimestamp
+ attribute type from [MODELS] is also a value of the Attribute Type
+ Description syntax (note: line breaks have been added for
+ readability - they are not part of the value when transfered in
+ protocol).
+
+ ( 2.5.18.1 NAME 'createTimestamp'
+ EQUALITY generalizedTimeMatch
+ ORDERING generalizedTimeOrderingMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
+ SINGLE-VALUE NO-USER-MODIFICATION
+ USAGE directoryOperation )
+
+ The LDAP definition for the Attribute Type Description syntax is:
+
+ ( 1.3.6.1.4.1.1466.115.121.1.3 DESC 'Attribute Type Description' )
+
+ This syntax corresponds to the AttributeTypeDescription ASN.1 type
+
+
+
+Legg Expires 23 December 2005 [Page 7]
+
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
+
+ from [X.501].
+
+3.3.2. Bit String
+
+ A value of the Bit String syntax is a sequence of binary digits. The
+ LDAP-specific encoding of a value of this syntax is defined by the
+ following ABNF:
+
+ BitString = SQUOTE *binary-digit SQUOTE "B"
+ binary-digit = "0" / "1"
+
+ The <SQUOTE> rule is defined in [MODELS].
+
+ Example:
+ '0101111101'B
+
+ The LDAP definition for the Bit String syntax is:
+
+ ( 1.3.6.1.4.1.1466.115.121.1.6 DESC 'Bit String' )
+
+ This syntax corresponds to the BIT STRING ASN.1 type from [ASN.1].
+
+3.3.3. Boolean
+
+ A value of the Boolean syntax is one of the Boolean values, true or
+ false. The LDAP-specific encoding of a value of this syntax is
+ defined by the following ABNF:
+
+ Boolean = "TRUE" / "FALSE"
+
+ The LDAP definition for the Boolean syntax is:
+
+ ( 1.3.6.1.4.1.1466.115.121.1.7 DESC 'Boolean' )
+
+ This syntax corresponds to the BOOLEAN ASN.1 type from [ASN.1].
+
+3.3.4. Country String
+
+ A value of the Country String syntax is one of the two-character
+ codes from ISO 3166 [ISO3166] for representing a country. The
+ LDAP-specific encoding of a value of this syntax is defined by the
+ following ABNF:
+
+ CountryString = 2(PrintableCharacter)
+
+ The <PrintableCharacter> rule is defined in Section 3.2.
+
+ Examples:
+
+
+
+Legg Expires 23 December 2005 [Page 8]
+
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
+
+ US
+ AU
+
+ The LDAP definition for the Country String syntax is:
+
+ ( 1.3.6.1.4.1.1466.115.121.1.11 DESC 'Country String' )
+
+ This syntax corresponds to the following ASN.1 type from [X.520]:
+
+ PrintableString (SIZE (2)) -- ISO 3166 codes only
+
+3.3.5. Delivery Method
+
+ A value of the Delivery Method syntax is a sequence of items that
+ indicate, in preference order, the service(s) by which an entity is
+ willing and/or capable of receiving messages. The LDAP-specific
+ encoding of a value of this syntax is defined by the following ABNF:
+
+ DeliveryMethod = pdm *( WSP DOLLAR WSP pdm )
+
+ pdm = "any" / "mhs" / "physical" / "telex" / "teletex" /
+ "g3fax" / "g4fax" / "ia5" / "videotex" / "telephone"
+
+ The <WSP> and <DOLLAR> rules are defined in [MODELS].
+
+ Example:
+ telephone $ videotex
+
+ The LDAP definition for the Delivery Method syntax is:
+
+ ( 1.3.6.1.4.1.1466.115.121.1.14 DESC 'Delivery Method' )
+
+ This syntax corresponds to the following ASN.1 type from [X.520]:
+
+ SEQUENCE OF INTEGER {
+ any-delivery-method (0),
+ mhs-delivery (1),
+ physical-delivery (2),
+ telex-delivery (3),
+ teletex-delivery (4),
+ g3-facsimile-delivery (5),
+ g4-facsimile-delivery (6),
+ ia5-terminal-delivery (7),
+ videotex-delivery (8),
+ telephone-delivery (9) }
+
+3.3.6. Directory String
+
+
+
+
+Legg Expires 23 December 2005 [Page 9]
+
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
+
+ A value of the Directory String syntax is a string of one or more
+ arbitrary characters from the Universal Character Set (UCS) [UCS]. A
+ zero length character string is not permitted. The LDAP-specific
+ encoding of a value of this syntax is the UTF-8 encoding [UTF8] of
+ the character string. Such encodings conform to the following ABNF:
+
+ DirectoryString = 1*UTF8
+
+ The <UTF8> rule is defined in [MODELS].
+
+ Example:
+ This is a value of Directory String containing #!%#@.
+
+ Servers and clients MUST be prepared to receive arbitrary UCS code
+ points, including code points outside the range of printable ASCII
+ and code points not presently assigned to any character.
+
+ Attribute type definitions using the Directory String syntax should
+ not restrict the format of Directory String values, e.g., by
+ requiring that the character string conforms to specific patterns
+ described by ABNF. A new syntax should be defined in such cases.
+
+ The LDAP definition for the Directory String syntax is:
+
+ ( 1.3.6.1.4.1.1466.115.121.1.15 DESC 'Directory String' )
+
+ This syntax corresponds to the DirectoryString parameterized ASN.1
+ type from [X.520].
+
+ The DirectoryString ASN.1 type allows a choice between the
+ TeletexString, PrintableString or UniversalString ASN.1 types from
+ [ASN.1]. However, note that the chosen alternative is not indicated
+ in the LDAP-specific encoding of a Directory String value.
+
+ Implementations which convert Directory String values from the
+ LDAP-specific encoding to the BER encoding used by X.500 must choose
+ an alternative that permits the particular characters in the string,
+ and must convert the characters from the UTF-8 encoding into the
+ character encoding of the chosen alternative. When converting
+ Directory String values from the BER encoding to the LDAP-specific
+ encoding the characters must be converted from the character encoding
+ of the chosen alternative into the UTF-8 encoding. These conversions
+ SHOULD be done in a manner consistent with the Transcode step of the
+ string preparation algorithms [PREP] for LDAP.
+
+3.3.7. DIT Content Rule Description
+
+ A value of the DIT Content Rule Description syntax is the definition
+
+
+
+Legg Expires 23 December 2005 [Page 10]
+
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
+
+ of a DIT (Directory Information Tree) content rule. The
+ LDAP-specific encoding of a value of this syntax is defined by the
+ <DITContentRuleDescription> rule in [MODELS].
+
+ Example:
+ ( 2.5.6.4 DESC 'content rule for organization'
+ NOT ( x121Address $ telexNumber ) )
+
+ Note: a line break has been added for readability - it is not part
+ of the value.
+
+ The LDAP definition for the DIT Content Rule Description syntax is:
+
+ ( 1.3.6.1.4.1.1466.115.121.1.16
+ DESC 'DIT Content Rule Description' )
+
+ This syntax corresponds to the DITContentRuleDescription ASN.1 type
+ from [X.501].
+
+3.3.8. DIT Structure Rule Description
+
+ A value of the DIT Structure Rule Description syntax is the
+ definition of a DIT structure rule. The LDAP-specific encoding of a
+ value of this syntax is defined by the <DITStructureRuleDescription>
+ rule in [MODELS].
+
+ Example:
+ ( 2 DESC 'organization structure rule' FORM 2.5.15.3 )
+
+ The LDAP definition for the DIT Structure Rule Description syntax is:
+
+ ( 1.3.6.1.4.1.1466.115.121.1.17
+ DESC 'DIT Structure Rule Description' )
+
+ This syntax corresponds to the DITStructureRuleDescription ASN.1 type
+ from [X.501].
+
+3.3.9. DN
+
+ A value of the DN syntax is the (purported) distinguished name (DN)
+ of an entry [MODELS]. The LDAP-specific encoding of a value of this
+ syntax is defined by the <distinguishedName> rule from the string
+ representation of distinguished names [LDAPDN].
+
+ Examples (from [LDAPDN]):
+ UID=jsmith,DC=example,DC=net
+ OU=Sales+CN=J. Smith,DC=example,DC=net
+ CN=John Smith\, III,DC=example,DC=net
+
+
+
+Legg Expires 23 December 2005 [Page 11]
+
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
+
+ CN=Before\0dAfter,DC=example,DC=net
+ 1.3.6.1.4.1.1466.0=#04024869,DC=example,DC=com
+ CN=Lu\C4\8Di\C4\87
+
+ The LDAP definition for the DN syntax is:
+
+ ( 1.3.6.1.4.1.1466.115.121.1.12 DESC 'DN' )
+
+ The DN syntax corresponds to the DistinguishedName ASN.1 type from
+ [X.501]. Note that a BER encoded distinguished name (as used by
+ X.500) re-encoded into the LDAP-specific encoding is not necessarily
+ reversible to the original BER encoding since the chosen string type
+ in any DirectoryString components of the distinguished name is not
+ indicated in the LDAP-specific encoding of the distinguished name
+ (see Section 3.3.6).
+
+3.3.10. Enhanced Guide
+
+ A value of the Enhanced Guide syntax suggests criteria, which consist
+ of combinations of attribute types and filter operators, to be used
+ in constructing filters to search for entries of particular object
+ classes. The Enhanced Guide syntax improves upon the Guide syntax by
+ allowing the recommended depth of the search to be specified.
+
+ The LDAP-specific encoding of a value of this syntax is defined by
+ the following ABNF:
+
+ EnhancedGuide = object-class SHARP WSP criteria WSP
+ SHARP WSP subset
+ object-class = WSP oid WSP
+ subset = "baseobject" / "oneLevel" / "wholeSubtree"
+
+ criteria = and-term *( BAR and-term )
+ and-term = term *( AMPERSAND term )
+ term = EXCLAIM term /
+ attributetype DOLLAR match-type /
+ LPAREN criteria RPAREN /
+ true /
+ false
+ match-type = "EQ" / "SUBSTR" / "GE" / "LE" / "APPROX"
+ true = "?true"
+ false = "?false"
+ BAR = %x7C ; vertical bar ("|")
+ AMPERSAND = %x26 ; ampersand ("&")
+ EXCLAIM = %x21 ; exclamation mark ("!")
+
+ The <SHARP>, <WSP>, <oid>, <LPAREN>, <RPAREN>, <attributetype> and
+ <DOLLAR> rules are defined in [MODELS].
+
+
+
+Legg Expires 23 December 2005 [Page 12]
+
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
+
+ The LDAP definition for the Enhanced Guide syntax is:
+
+ ( 1.3.6.1.4.1.1466.115.121.1.21 DESC 'Enhanced Guide' )
+
+
+ Example:
+ person#(sn$EQ)#oneLevel
+
+ The Enhanced Guide syntax corresponds to the EnhancedGuide ASN.1 type
+ from [X.520]. The EnhancedGuide type references the Criteria ASN.1
+ type, also from [X.520]. The <true> rule above represents an empty
+ "and" expression in a value of the Criteria type. The <false> rule
+ above represents an empty "or" expression in a value of the Criteria
+ type.
+
+3.3.11. Facsimile Telephone Number
+
+ A value of the Facsimile Telephone Number syntax is a subscriber
+ number of a facsimile device on the public switched telephone
+ network. The LDAP-specific encoding of a value of this syntax is
+ defined by the following ABNF:
+
+ fax-number = telephone-number *( DOLLAR fax-parameter )
+ telephone-number = PrintableString
+ fax-parameter = "twoDimensional" /
+ "fineResolution" /
+ "unlimitedLength" /
+ "b4Length" /
+ "a3Width" /
+ "b4Width" /
+ "uncompressed"
+
+ The <telephone-number> is a string of printable characters that
+ complies with the internationally agreed format for representing
+ international telephone numbers [E.123]. The <PrintableString> rule
+ is defined in Section 3.2. The <DOLLAR> rule is defined in [MODELS].
+
+ The LDAP definition for the Facsimile Telephone Number syntax is:
+
+ ( 1.3.6.1.4.1.1466.115.121.1.22 DESC 'Facsimile Telephone Number')
+
+ The Facsimile Telephone Number syntax corresponds to the
+ FacsimileTelephoneNumber ASN.1 type from [X.520].
+
+3.3.12. Fax
+
+ A value of the Fax syntax is an image which is produced using the
+ Group 3 facsimile process [FAX] to duplicate an object, such as a
+
+
+
+Legg Expires 23 December 2005 [Page 13]
+
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
+
+ memo. The LDAP-specific encoding of a value of this syntax is the
+ string of octets for a Group 3 Fax image as defined in [FAX].
+
+ The LDAP definition for the Fax syntax is:
+
+ ( 1.3.6.1.4.1.1466.115.121.1.23 DESC 'Fax' )
+
+ The ASN.1 type corresponding to the Fax syntax is defined as follows,
+ assuming EXPLICIT TAGS:
+
+ Fax ::= CHOICE {
+ g3-facsimile [3] G3FacsimileBodyPart
+ }
+
+ The G3FacsimileBodyPart ASN.1 type is defined in [X.420].
+
+3.3.13. Generalized Time
+
+ A value of the Generalized Time syntax is a character string
+ representing a date and time. The LDAP-specific encoding of a value
+ of this syntax is a restriction of the format defined in [ISO8601],
+ and is described by the following ABNF:
+
+ GeneralizedTime = century year month day hour
+ [ minute [ second / leap-second ] ]
+ [ fraction ]
+ g-time-zone
+
+ century = 2(%x30-39) ; "00" to "99"
+ year = 2(%x30-39) ; "00" to "99"
+ month = ( %x30 %x31-39 ) ; "01" (January) to "09"
+ / ( %x31 %x30-32 ) ; "10" to "12"
+ day = ( %x30 %x31-39 ) ; "01" to "09"
+ / ( %x31-32 %x30-39 ) ; "10" to "29"
+ / ( %x33 %x30-31 ) ; "30" to "31"
+ hour = ( %x30-31 %x30-39 ) / ( %x32 %x30-33 ) ; "00" to "23"
+ minute = %x30-35 %x30-39 ; "00" to "59"
+
+ second = ( %x30-35 %x30-39 ) ; "00" to "59"
+ leap-second = ( %x36 %x30 ) ; "60"
+
+ fraction = ( DOT / COMMA ) 1*(%x30-39)
+ g-time-zone = %x5A ; "Z"
+ / g-differential
+ g-differential = ( MINUS / PLUS ) hour [ minute ]
+ MINUS = %x2D ; minus sign ("-")
+
+ The <DOT>, <COMMA> and <PLUS> rules are defined in [MODELS].
+
+
+
+Legg Expires 23 December 2005 [Page 14]
+
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
+
+ The above ABNF allows character strings which do not represent valid
+ dates (in the Gregorian calendar) and/or valid times (e.g., February
+ 31, 1994). Such character strings SHOULD be considered invalid for
+ this syntax.
+
+ The time value represents coordinated universal time (equivalent to
+ Greenwich Mean Time) if the "Z" form of <g-time-zone> is used,
+ otherwise the value represents a local time in the time zone
+ indicated by <g-differential>. In the latter case, coordinated
+ universal time can be calculated by subtracting the differential from
+ the local time. The "Z" form of <g-time-zone> SHOULD be used in
+ preference to <g-differential>.
+
+ If <minute> is omitted then <fraction> represents a fraction of an
+ hour, otherwise if <second> and <leap-second> are omitted then
+ <fraction> represents a fraction of a minute, otherwise <fraction>
+ represents a fraction of a second.
+
+ Examples:
+ 199412161032Z
+ 199412160532-0500
+
+ Both example values represent the same coordinated universal time:
+ 10:32 AM, December 16, 1994.
+
+ The LDAP definition for the Generalized Time syntax is:
+
+ ( 1.3.6.1.4.1.1466.115.121.1.24 DESC 'Generalized Time' )
+
+ This syntax corresponds to the GeneralizedTime ASN.1 type from
+ [ASN.1], with the constraint that local time without a differential
+ SHALL NOT be used.
+
+3.3.14. Guide
+
+ A value of the Guide syntax suggests criteria, which consist of
+ combinations of attribute types and filter operators, to be used in
+ constructing filters to search for entries of particular object
+ classes. The Guide syntax is obsolete and should not be used for
+ defining new attribute types.
+
+ The LDAP-specific encoding of a value of this syntax is defined by
+ the following ABNF:
+
+ Guide = [ object-class SHARP ] criteria
+
+ The <object-class> and <criteria> rules are defined in Section
+ 3.3.10. The <SHARP> rule is defined in [MODELS].
+
+
+
+Legg Expires 23 December 2005 [Page 15]
+
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
+
+ The LDAP definition for the Guide syntax is:
+
+ ( 1.3.6.1.4.1.1466.115.121.1.25 DESC 'Guide' )
+
+ The Guide syntax corresponds to the Guide ASN.1 type from [X.520].
+
+3.3.15. IA5 String
+
+ A value of the IA5 String syntax is a string of zero, one or more
+ characters from International Alphabet 5 (IA5) [T.50], the
+ international version of the ASCII character set. The LDAP-specific
+ encoding of a value of this syntax is the unconverted string of
+ characters, which conforms to the <IA5String> rule in Section 3.2.
+
+ The LDAP definition for the IA5 String syntax is:
+
+ ( 1.3.6.1.4.1.1466.115.121.1.26 DESC 'IA5 String' )
+
+ This syntax corresponds to the IA5String ASN.1 type from [ASN.1].
+
+3.3.16. Integer
+
+ A value of the Integer syntax is a whole number of unlimited
+ magnitude. The LDAP-specific encoding of a value of this syntax is
+ the optionally signed decimal digit character string representation
+ of the number (so, for example, the number 1321 is represented by the
+ character string "1321"). The encoding is defined by the following
+ ABNF:
+
+ Integer = ( HYPHEN LDIGIT *DIGIT ) / number
+
+ The <HYPHEN>, <LDIGIT>, <DIGIT> and <number> rules are defined in
+ [MODELS].
+
+ The LDAP definition for the Integer syntax is:
+
+ ( 1.3.6.1.4.1.1466.115.121.1.27 DESC 'INTEGER' )
+
+ This syntax corresponds to the INTEGER ASN.1 type from [ASN.1].
+
+3.3.17. JPEG
+
+ A value of the JPEG syntax is an image in the JPEG File Interchange
+ Format (JFIF), as described in [JPEG]. The LDAP-specific encoding of
+ a value of this syntax is the sequence of octets of the JFIF encoding
+ of the image.
+
+ The LDAP definition for the JPEG syntax is:
+
+
+
+Legg Expires 23 December 2005 [Page 16]
+
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
+
+ ( 1.3.6.1.4.1.1466.115.121.1.28 DESC 'JPEG' )
+
+ The JPEG syntax corresponds to the following ASN.1 type:
+
+ JPEG ::= OCTET STRING (CONSTRAINED BY
+ { -- contents octets are an image in the --
+ -- JPEG File Interchange Format -- })
+
+3.3.18. LDAP Syntax Description
+
+ A value of the LDAP Syntax Description syntax is the description of
+ an LDAP syntax. The LDAP-specific encoding of a value of this syntax
+ is defined by the <SyntaxDescription> rule in [MODELS].
+
+ The LDAP definition for the LDAP Syntax Description syntax is:
+
+ ( 1.3.6.1.4.1.1466.115.121.1.54 DESC 'LDAP Syntax Description' )
+
+ The above LDAP definition for the LDAP Syntax Description syntax is
+ itself a legal value of the LDAP Syntax Description syntax.
+
+ The ASN.1 type corresponding to the LDAP Syntax Description syntax is
+ defined as follows, assuming EXPLICIT TAGS:
+
+ LDAPSyntaxDescription ::= SEQUENCE {
+ identifier OBJECT IDENTIFIER,
+ description DirectoryString { ub-schema } OPTIONAL }
+
+ The DirectoryString parameterized ASN.1 type is defined in [X.520].
+
+ The value of ub-schema (an integer) is implementation defined. A
+ non-normative definition appears in [X.520].
+
+3.3.19. Matching Rule Description
+
+ A value of the Matching Rule Description syntax is the definition of
+ a matching rule. The LDAP-specific encoding of a value of this
+ syntax is defined by the <MatchingRuleDescription> rule in [MODELS].
+
+ Example:
+ ( 2.5.13.2 NAME 'caseIgnoreMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+ Note: a line break has been added for readability - it is not part of
+ the syntax.
+
+ The LDAP definition for the Matching Rule Description syntax is:
+
+
+
+
+Legg Expires 23 December 2005 [Page 17]
+
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
+
+ ( 1.3.6.1.4.1.1466.115.121.1.30 DESC 'Matching Rule Description' )
+
+ This syntax corresponds to the MatchingRuleDescription ASN.1 type
+ from [X.501].
+
+3.3.20. Matching Rule Use Description
+
+ A value of the Matching Rule Use Description syntax indicates the
+ attribute types to which a matching rule may be applied in an
+ extensibleMatch search filter [PROT]. The LDAP-specific encoding of
+ a value of this syntax is defined by the <MatchingRuleUseDescription>
+ rule in [MODELS].
+
+ Example:
+ ( 2.5.13.16 APPLIES ( givenName $ surname ) )
+
+ The LDAP definition for the Matching Rule Use Description syntax is:
+
+ ( 1.3.6.1.4.1.1466.115.121.1.31
+ DESC 'Matching Rule Use Description' )
+
+ This syntax corresponds to the MatchingRuleUseDescription ASN.1 type
+ from [X.501].
+
+3.3.21. Name and Optional UID
+
+ A value of the Name and Optional UID syntax is the distinguished name
+ [MODELS] of an entity optionally accompanied by a unique identifier
+ that serves to differentiate the entity from others with an identical
+ distinguished name.
+
+ The LDAP-specific encoding of a value of this syntax is defined by
+ the following ABNF:
+
+ NameAndOptionalUID = distinguishedName [ SHARP BitString ]
+
+ The <BitString> rule is defined in Section 3.3.2. The
+ <distinguishedName> rule is defined in [LDAPDN]. The <SHARP> rule is
+ defined in [MODELS].
+
+ Note that although the '#' character may occur in the string
+ representation of a distinguished name, no additional escaping of
+ this character is performed when a <distinguishedName> is encoded in
+ a <NameAndOptionalUID>.
+
+ Example:
+ 1.3.6.1.4.1.1466.0=#04024869,O=Test,C=GB#'0101'B
+
+
+
+
+Legg Expires 23 December 2005 [Page 18]
+
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
+
+ The LDAP definition for the Name and Optional UID syntax is:
+
+ ( 1.3.6.1.4.1.1466.115.121.1.34 DESC 'Name And Optional UID' )
+
+ This syntax corresponds to the NameAndOptionalUID ASN.1 type from
+ [X.520].
+
+3.3.22. Name Form Description
+
+ A value of the Name Form Description syntax is the definition of a
+ name form, which regulates how entries may be named. The
+ LDAP-specific encoding of a value of this syntax is defined by the
+ <NameFormDescription> rule in [MODELS].
+
+ Example:
+ ( 2.5.15.3 NAME 'orgNameForm' OC organization MUST o )
+
+ The LDAP definition for the Name Form Description syntax is:
+
+ ( 1.3.6.1.4.1.1466.115.121.1.35 DESC 'Name Form Description' )
+
+ This syntax corresponds to the NameFormDescription ASN.1 type from
+ [X.501].
+
+3.3.23. Numeric String
+
+ A value of the Numeric String syntax is a sequence of one or more
+ numerals and spaces. The LDAP-specific encoding of a value of this
+ syntax is the unconverted string of characters, which conforms to the
+ following ABNF:
+
+ NumericString = 1*(DIGIT / SPACE)
+
+ The <DIGIT> and <SPACE> rules are defined in [MODELS].
+
+ Example:
+ 15 079 672 281
+
+ The LDAP definition for the Numeric String syntax is:
+
+ ( 1.3.6.1.4.1.1466.115.121.1.36 DESC 'Numeric String' )
+
+ This syntax corresponds to the NumericString ASN.1 type from [ASN.1].
+
+3.3.24. Object Class Description
+
+ A value of the Object Class Description syntax is the definition of
+ an object class. The LDAP-specific encoding of a value of this
+
+
+
+Legg Expires 23 December 2005 [Page 19]
+
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
+
+ syntax is defined by the <ObjectClassDescription> rule in [MODELS].
+
+ Example:
+ ( 2.5.6.2 NAME 'country' SUP top STRUCTURAL MUST c
+ MAY ( searchGuide $ description ) )
+
+ Note: a line break has been added for readability - it is not part of
+ the syntax.
+
+ The LDAP definition for the Object Class Description syntax is:
+
+ ( 1.3.6.1.4.1.1466.115.121.1.37 DESC 'Object Class Description' )
+
+ This syntax corresponds to the ObjectClassDescription ASN.1 type from
+ [X.501].
+
+3.3.25. Octet String
+
+ A value of the Octet String syntax is a sequence of zero, one or more
+ arbitrary octets. The LDAP-specific encoding of a value of this
+ syntax is the unconverted sequence of octets, which conforms to the
+ following ABNF:
+
+ OctetString = *OCTET
+
+ The <OCTET> rule is defined in [MODELS]. Values of this syntax are
+ not generally human-readable.
+
+ The LDAP definition for the Octet String syntax is:
+
+ ( 1.3.6.1.4.1.1466.115.121.1.40 DESC 'Octet String' )
+
+ This syntax corresponds to the OCTET STRING ASN.1 type from [ASN.1].
+
+3.3.26. OID
+
+ A value of the OID syntax is an object identifier; a sequence of two
+ or more non-negative integers that uniquely identify some object or
+ item of specification. Many of the object identifiers used in LDAP
+ also have IANA registered names [RFC3383].
+
+ The LDAP-specific encoding of a value of this syntax is defined by
+ the <oid> rule in [MODELS].
+
+ Examples:
+ 1.2.3.4
+ cn
+
+
+
+
+Legg Expires 23 December 2005 [Page 20]
+
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
+
+ The LDAP definition for the OID syntax is:
+
+ ( 1.3.6.1.4.1.1466.115.121.1.38 DESC 'OID' )
+
+ This syntax corresponds to the OBJECT IDENTIFIER ASN.1 type from
+ [ASN.1].
+
+3.3.27. Other Mailbox
+
+ A value of the Other Mailbox syntax identifies an electronic mailbox,
+ in a particular named mail system. The LDAP-specific encoding of a
+ value of this syntax is defined by the following ABNF:
+
+ OtherMailbox = mailbox-type DOLLAR mailbox
+ mailbox-type = PrintableString
+ mailbox = IA5String
+
+ The <mailbox-type> rule represents the type of mail system in which
+ the mailbox resides, for example "MCIMail", and <mailbox> is the
+ actual mailbox in the mail system described by <mailbox-type>. The
+ <PrintableString> and <IA5String> rules are defined in Section 3.2.
+ The <DOLLAR> rule is defined in [MODELS].
+
+ The LDAP definition for the Other Mailbox syntax is:
+
+ ( 1.3.6.1.4.1.1466.115.121.1.39 DESC 'Other Mailbox' )
+
+ The ASN.1 type corresponding to the Other Mailbox syntax is defined
+ as follows, assuming EXPLICIT TAGS:
+
+ OtherMailbox ::= SEQUENCE {
+ mailboxType PrintableString,
+ mailbox IA5String
+ }
+
+3.3.28. Postal Address
+
+ A value of the Postal Address syntax is a sequence of strings of one
+ or more arbitrary UCS characters, which form an address in a physical
+ mail system.
+
+ The LDAP-specific encoding of a value of this syntax is defined by
+ the following ABNF:
+
+ PostalAddress = line *( DOLLAR line )
+ line = 1*line-char
+ line-char = %x00-23
+ / (%x5C "24") ; escaped "$"
+
+
+
+Legg Expires 23 December 2005 [Page 21]
+
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
+
+ / %x25-5B
+ / (%x5C "5C") ; escaped "\"
+ / %x5D-7F
+ / UTFMB
+
+ Each character string (i.e., <line>) of a postal address value is
+ encoded as a UTF-8 [UTF8] string except that "\" and "$" characters,
+ if they occur in the string, are escaped by a "\" character followed
+ by the two hexadecimal digit code for the character. The <DOLLAR>
+ and <UTFMB> rules are defined in [MODELS].
+
+ Many servers limit the postal address to no more than six lines of no
+ more than thirty characters each.
+
+ Example:
+ 1234 Main St.$Anytown, CA 12345$USA
+ \241,000,000 Sweepstakes$PO Box 1000000$Anytown, CA 12345$USA
+
+ The LDAP definition for the Postal Address syntax is:
+
+ ( 1.3.6.1.4.1.1466.115.121.1.41 DESC 'Postal Address' )
+
+ This syntax corresponds to the PostalAddress ASN.1 type from [X.520],
+ i.e.,
+
+ PostalAddress ::= SEQUENCE SIZE(1..ub-postal-line) OF
+ DirectoryString { ub-postal-string }
+
+ The values of ub-postal-line and ub-postal-string (both integers) are
+ implementation defined. Non-normative definitions appear in [X.520].
+
+3.3.29. Printable String
+
+ A value of the Printable String syntax is a string of one or more
+ latin alphabetic, numeric, and selected punctuation characters as
+ specified by the <PrintableCharacter> rule in Section 3.2.
+
+ The LDAP-specific encoding of a value of this syntax is the
+ unconverted string of characters, which conforms to the
+ <PrintableString> rule in Section 3.2.
+
+ Example:
+ This is a PrintableString.
+
+ The LDAP definition for the PrintableString syntax is:
+
+ ( 1.3.6.1.4.1.1466.115.121.1.44 DESC 'Printable String' )
+
+
+
+
+Legg Expires 23 December 2005 [Page 22]
+
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
+
+ This syntax corresponds to the PrintableString ASN.1 type from
+ [ASN.1].
+
+3.3.30. Substring Assertion
+
+ A value of the Substring Assertion syntax is a sequence of zero, one
+ or more character substrings used as an argument for substring
+ extensible matching of character string attribute values, i.e., as
+ the matchValue of a MatchingRuleAssertion [PROT]. Each substring is
+ a string of one or more arbitrary characters from the Universal
+ Character Set (UCS) [UCS]. A zero length substring is not permitted.
+
+ The LDAP-specific encoding of a value of this syntax is defined by
+ the following ABNF:
+
+ SubstringAssertion = [ initial ] any [ final ]
+
+ initial = substring
+ any = ASTERISK *(substring ASTERISK)
+ final = substring
+ ASTERISK = %x2A ; asterisk ("*")
+
+ substring = 1*substring-character
+ substring-character = %x00-29
+ / (%x5C "2A") ; escaped "*"
+ / %x2B-5B
+ / (%x5C "5C") ; escaped "\"
+ / %x5D-7F
+ / UTFMB
+
+ Each <substring> of a Substring Assertion value is encoded as a UTF-8
+ [UTF8] string, except that "\" and "*" characters, if they occur in
+ the substring, are escaped by a "\" character followed by the two
+ hexadecimal digit code for the character.
+
+ The Substring Assertion syntax is used only as the syntax of
+ assertion values in the extensible match. It is not used as an
+ attribute syntax, or in the SubstringFilter [PROT].
+
+ The LDAP definition for the Substring Assertion syntax is:
+
+ ( 1.3.6.1.4.1.1466.115.121.1.58 DESC 'Substring Assertion' )
+
+ This syntax corresponds to the SubstringAssertion ASN.1 type from
+ [X.520].
+
+3.3.31. Telephone Number
+
+
+
+
+Legg Expires 23 December 2005 [Page 23]
+
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
+
+ A value of the Telephone Number syntax is a string of printable
+ characters that complies with the internationally agreed format for
+ representing international telephone numbers [E.123].
+
+ The LDAP-specific encoding of a value of this syntax is the
+ unconverted string of characters, which conforms to the
+ <PrintableString> rule in Section 3.2.
+
+ Examples:
+ +1 512 315 0280
+ +1-512-315-0280
+ +61 3 9896 7830
+
+ The LDAP definition for the Telephone Number syntax is:
+
+ ( 1.3.6.1.4.1.1466.115.121.1.50 DESC 'Telephone Number' )
+
+ The Telephone Number syntax corresponds to the following ASN.1 type
+ from [X.520]:
+
+ PrintableString (SIZE(1..ub-telephone-number))
+
+ The value of ub-telephone-number (an integer) is implementation
+ defined. A non-normative definition appears in [X.520].
+
+3.3.32. Teletex Terminal Identifier
+
+ A value of this syntax specifies the identifier and (optionally)
+ parameters of a teletex terminal.
+
+ The LDAP-specific encoding of a value of this syntax is defined by
+ the following ABNF:
+
+ teletex-id = ttx-term *(DOLLAR ttx-param)
+ ttx-term = PrintableString ; terminal identifier
+ ttx-param = ttx-key COLON ttx-value ; parameter
+ ttx-key = "graphic" / "control" / "misc" / "page" / "private"
+ ttx-value = *ttx-value-octet
+
+ ttx-value-octet = %x00-23
+ / (%x5C "24") ; escaped "$"
+ / %x25-5B
+ / (%x5C "5C") ; escaped "\"
+ / %x5D-FF
+
+ The <PrintableString> and <COLON> rules are defined in Section 3.2.
+ The <DOLLAR> rule is defined in [MODELS].
+
+
+
+
+Legg Expires 23 December 2005 [Page 24]
+
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
+
+ The LDAP definition for the Teletex Terminal Identifier syntax is:
+
+ ( 1.3.6.1.4.1.1466.115.121.1.51
+ DESC 'Teletex Terminal Identifier' )
+
+ This syntax corresponds to the TeletexTerminalIdentifier ASN.1 type
+ from [X.520].
+
+3.3.33. Telex Number
+
+ A value of the Telex Number syntax specifies the telex number,
+ country code and answerback code of a telex terminal.
+
+ The LDAP-specific encoding of a value of this syntax is defined by
+ the following ABNF:
+
+ telex-number = actual-number DOLLAR country-code
+ DOLLAR answerback
+ actual-number = PrintableString
+ country-code = PrintableString
+ answerback = PrintableString
+
+ The <PrintableString> rule is defined in Section 3.2. The <DOLLAR>
+ rule is defined in [MODELS].
+
+ The LDAP definition for the Telex Number syntax is:
+
+ ( 1.3.6.1.4.1.1466.115.121.1.52 DESC 'Telex Number' )
+
+ This syntax corresponds to the TelexNumber ASN.1 type from [X.520].
+
+3.3.34. UTC Time
+
+ A value of the UTC Time syntax is a character string representing a
+ date and time to a precision of one minute or one second. The year
+ is given as a two-digit number. The LDAP-specific encoding of a
+ value of this syntax follows the format defined in [ASN.1] for the
+ UTCTime type and is described by the following ABNF:
+
+ UTCTime = year month day hour minute [ second ]
+ [ u-time-zone ]
+ u-time-zone = %x5A ; "Z"
+ / u-differential
+ u-differential = ( MINUS / PLUS ) hour minute
+
+ The <year>, <month>, <day>, <hour>, <minute>, <second> and <MINUS>
+ rules are defined in Section 3.3.13. The <PLUS> rule is defined in
+ [MODELS].
+
+
+
+Legg Expires 23 December 2005 [Page 25]
+
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
+
+ The above ABNF allows character strings which do not represent valid
+ dates (in the Gregorian calendar) and/or valid times. Such character
+ strings SHOULD be considered invalid for this syntax.
+
+ The time value represents coordinated universal time if the "Z" form
+ of <u-time-zone> is used, otherwise the value represents a local
+ time. In the latter case, if <u-differential> is provided then
+ coordinated universal time can be calculated by subtracting the
+ differential from the local time. The <u-time-zone> SHOULD be
+ present in time values and the "Z" form of <u-time-zone> SHOULD be
+ used in preference to <u-differential>.
+
+ The LDAP definition for the UTC Time syntax is:
+
+ ( 1.3.6.1.4.1.1466.115.121.1.53 DESC 'UTC Time' )
+
+ Note: This syntax is deprecated in favor of the Generalized Time
+ syntax.
+
+ The UTC Time syntax corresponds to the UTCTime ASN.1 type from
+ [ASN.1].
+
+4. Matching Rules
+
+ Matching rules are used by directory implementations to compare
+ attribute values against assertion values when performing Search and
+ Compare operations [PROT]. They are also used when comparing a
+ purported distinguished name [MODELS] with the name of an entry.
+ When modifying entries, matching rules are used to identify values to
+ be deleted and to prevent an attribute from containing two equal
+ values.
+
+ Matching rules that are required for directory operation, or that are
+ in common use, are specified in this section.
+
+4.1. General Considerations
+
+ A matching rule is applied to attribute values through an
+ AttributeValueAssertion or MatchingRuleAssertion [PROT]. The
+ conditions under which an AttributeValueAssertion or
+ MatchingRuleAssertion evaluates to Undefined are specified elsewhere
+ [PROT]. If an assertion is not Undefined then the result of the
+ assertion is the result of applying the selected matching rule. A
+ matching rule evaluates to TRUE, and in some cases Undefined, as
+ specified in the description of the matching rule, otherwise it
+ evaluates to FALSE.
+
+ Each assertion contains an assertion value. The definition of each
+
+
+
+Legg Expires 23 December 2005 [Page 26]
+
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
+
+ matching rule specifies the syntax for the assertion value. The
+ syntax of the assertion value is typically, but not necessarily, the
+ same as the syntax of the attribute values to which the matching rule
+ may be applied. Note that an AssertionValue in a SubstringFilter
+ [PROT] conforms to the assertion syntax of the equality matching rule
+ for the attribute type rather than the assertion syntax of the
+ substrings matching rule for the attribute type. Conceptually, the
+ entire SubstringFilter is converted into an assertion value of the
+ substrings matching rule prior to applying the rule.
+
+ The definition of each matching rule indicates the attribute syntaxes
+ to which the rule may be applied, by specifying conditions the
+ corresponding ASN.1 type of a candidate attribute syntax must
+ satisfy. These conditions are also satisfied if the corresponding
+ ASN.1 type is a tagged or constrained derivative of the ASN.1 type
+ explicitly mentioned in the rule description (i.e., ASN.1 tags and
+ constraints are ignored in checking applicability), or an alternative
+ reference notation for the explicitly mentioned type. Each rule
+ description lists as examples of applicable attribute syntaxes, the
+ complete list of the syntaxes defined in this document to which the
+ matching rule applies. A matching rule may be applicable to
+ additional syntaxes defined in other documents if those syntaxes
+ satisfy the conditions on the corresponding ASN.1 type.
+
+ The description of each matching rule indicates whether the rule is
+ suitable for use as the equality matching rule (EQUALITY), ordering
+ matching rule (ORDERING) or substrings matching rule (SUBSTR) in an
+ attribute type definition [MODELS].
+
+ Each matching rule is uniquely identified with an object identifier.
+ The definition of a matching rule should not be subsequently changed.
+ If a change is desirable then a new matching rule with a different
+ object identifier should be defined instead.
+
+ Servers MAY implement the wordMatch and keywordMatch matching rules,
+ but SHOULD implement the other matching rules in Section 4.2.
+ Servers MAY implement additional matching rules.
+
+ Servers which implement the extensibleMatch filter SHOULD allow the
+ matching rules listed in Section 4.2 to be used in the
+ extensibleMatch filter and SHOULD allow matching rules to be used
+ with all attribute types known to the server, where the assertion
+ syntax of the matching rule is the same as the value syntax of the
+ attribute.
+
+ Servers MUST publish in the matchingRules attribute, the definitions
+ of matching rules referenced by values of the attributeTypes and
+ matchingRuleUse attributes in the same subschema entry. Other
+
+
+
+Legg Expires 23 December 2005 [Page 27]
+
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
+
+ unreferenced matching rules MAY be published in the matchingRules
+ attribute.
+
+ If the server supports the extensibleMatch filter, then the server
+ MAY use the matchingRuleUse attribute to indicate the applicability
+ (in an extensibleMatch filter) of selected matching rules to
+ nominated attribute types.
+
+4.2. Matching Rule Definitions
+
+ Nominated character strings in assertion and attribute values are
+ prepared according to the string preparation algorithms [PREP] for
+ LDAP when evaluating the following matching rules:
+
+ numericStringMatch,
+ numericStringSubstringsMatch,
+ caseExactMatch,
+ caseExactOrderingMatch,
+ caseExactSubstringsMatch,
+ caseExactIA5Match,
+ caseIgnoreIA5Match,
+ caseIgnoreIA5SubstringsMatch,
+ caseIgnoreListMatch,
+ caseIgnoreListSubstringsMatch,
+ caseIgnoreMatch,
+ caseIgnoreOrderingMatch,
+ caseIgnoreSubstringsMatch,
+ directoryStringFirstComponentMatch,
+ telephoneNumberMatch,
+ telephoneNumberSubstringsMatch and
+ wordMatch.
+
+ The Transcode, Normalize, Prohibit and Check bidi steps are the same
+ for each of the matching rules. However, the Map and Insignificant
+ Character Handling steps depends on the specific rule, as detailed in
+ the description of these matching rules in the sections that follow.
+
+4.2.1. bitStringMatch
+
+ The bitStringMatch rule compares an assertion value of the Bit String
+ syntax to an attribute value of a syntax (e.g., the Bit String
+ syntax) whose corresponding ASN.1 type is BIT STRING.
+
+ If the corresponding ASN.1 type of the attribute syntax does not have
+ a named bit list [ASN.1] (which is the case for the Bit String
+ syntax) then the rule evaluates to TRUE if and only if the attribute
+ value has the same number of bits as the assertion value and the bits
+ match on a bitwise basis.
+
+
+
+Legg Expires 23 December 2005 [Page 28]
+
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
+
+ If the corresponding ASN.1 type does have a named bit list then
+ bitStringMatch operates as above except that trailing zero bits in
+ the attribute and assertion values are treated as absent.
+
+ The LDAP definition for the bitStringMatch rule is:
+
+ ( 2.5.13.16 NAME 'bitStringMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 )
+
+ The bitStringMatch rule is an equality matching rule.
+
+4.2.2. booleanMatch
+
+ The booleanMatch rule compares an assertion value of the Boolean
+ syntax to an attribute value of a syntax (e.g., the Boolean syntax)
+ whose corresponding ASN.1 type is BOOLEAN.
+
+ The rule evaluates to TRUE if and only if the attribute value and the
+ assertion value are both TRUE or both FALSE.
+
+ The LDAP definition for the booleanMatch rule is:
+
+ ( 2.5.13.13 NAME 'booleanMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 )
+
+ The booleanMatch rule is an equality matching rule.
+
+4.2.3. caseExactIA5Match
+
+ The caseExactIA5Match rule compares an assertion value of the IA5
+ String syntax to an attribute value of a syntax (e.g the IA5 String
+ syntax) whose corresponding ASN.1 type is IA5String.
+
+ The rule evaluates to TRUE if and only if the prepared attribute
+ value character string and the prepared assertion value character
+ string have the same number of characters and corresponding
+ characters have the same code point.
+
+ In preparing the attribute value and assertion value for comparison,
+ characters are not case folded in the Map preparation step, and only
+ Insignificant Space Handling is applied in the Insignificant
+ Character Handling step.
+
+ The LDAP definition for the caseExactIA5Match rule is:
+
+ ( 1.3.6.1.4.1.1466.109.114.1 NAME 'caseExactIA5Match'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
+
+
+
+
+Legg Expires 23 December 2005 [Page 29]
+
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
+
+ The caseExactIA5Match rule is an equality matching rule.
+
+4.2.4. caseExactMatch
+
+ The caseExactMatch rule compares an assertion value of the Directory
+ String syntax to an attribute value of a syntax (e.g., the Directory
+ String, Printable String, Country String or Telephone Number syntax)
+ whose corresponding ASN.1 type is DirectoryString or one of the
+ alternative string types of DirectoryString, e.g., PrintableString
+ (the other alternatives do not correspond to any syntax defined in
+ this document).
+
+ The rule evaluates to TRUE if and only if the prepared attribute
+ value character string and the prepared assertion value character
+ string have the same number of characters and corresponding
+ characters have the same code point.
+
+ In preparing the attribute value and assertion value for comparison,
+ characters are not case folded in the Map preparation step, and only
+ Insignificant Space Handling is applied in the Insignificant
+ Character Handling step.
+
+ The LDAP definition for the caseExactMatch rule is:
+
+ ( 2.5.13.5 NAME 'caseExactMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+ The caseExactMatch rule is an equality matching rule.
+
+4.2.5. caseExactOrderingMatch
+
+ The caseExactOrderingMatch rule compares an assertion value of the
+ Directory String syntax to an attribute value of a syntax (e.g., the
+ Directory String, Printable String, Country String or Telephone
+ Number syntax) whose corresponding ASN.1 type is DirectoryString or
+ one of its alternative string types.
+
+ The rule evaluates to TRUE if, and only if, in the code point
+ collation order, the prepared attribute value character string
+ appears earlier than the prepared assertion value character string,
+ i.e., the attribute value is "less than" the assertion value.
+
+ In preparing the attribute value and assertion value for comparison,
+ characters are not case folded in the Map preparation step, and only
+ Insignificant Space Handling is applied in the Insignificant
+ Character Handling step.
+
+ The LDAP definition for the caseExactOrderingMatch rule is:
+
+
+
+Legg Expires 23 December 2005 [Page 30]
+
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
+
+ ( 2.5.13.6 NAME 'caseExactOrderingMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+ The caseExactOrderingMatch rule is an ordering matching rule.
+
+4.2.6. caseExactSubstringsMatch
+
+ The caseExactSubstringsMatch rule compares an assertion value of the
+ Substring Assertion syntax to an attribute value of a syntax (e.g.,
+ the Directory String, Printable String, Country String or Telephone
+ Number syntax) whose corresponding ASN.1 type is DirectoryString or
+ one of its alternative string types.
+
+ The rule evaluates to TRUE if and only if the prepared substrings of
+ the assertion value match disjoint portions of the prepared attribute
+ value character string in the order of the substrings in the
+ assertion value, and an <initial> substring, if present, matches the
+ beginning of the prepared attribute value character string, and a
+ <final> substring, if present, matches the end of the prepared
+ attribute value character string. A prepared substring matches a
+ portion of the prepared attribute value character string if
+ corresponding characters have the same code point.
+
+ In preparing the attribute value and assertion value substrings for
+ comparison, characters are not case folded in the Map preparation
+ step, and only Insignificant Space Handling is applied in the
+ Insignificant Character Handling step.
+
+ The LDAP definition for the caseExactSubstringsMatch rule is:
+
+ ( 2.5.13.7 NAME 'caseExactSubstringsMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
+
+ The caseExactSubstringsMatch rule is a substrings matching rule.
+
+4.2.7. caseIgnoreIA5Match
+
+ The caseIgnoreIA5Match rule compares an assertion value of the IA5
+ String syntax to an attribute value of a syntax (e.g the IA5 String
+ syntax) whose corresponding ASN.1 type is IA5String.
+
+ The rule evaluates to TRUE if and only if the prepared attribute
+ value character string and the prepared assertion value character
+ string have the same number of characters and corresponding
+ characters have the same code point.
+
+ In preparing the attribute value and assertion value for comparison,
+ characters are case folded in the Map preparation step, and only
+
+
+
+Legg Expires 23 December 2005 [Page 31]
+
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
+
+ Insignificant Space Handling is applied in the Insignificant
+ Character Handling step.
+
+ The LDAP definition for the caseIgnoreIA5Match rule is:
+
+ ( 1.3.6.1.4.1.1466.109.114.2 NAME 'caseIgnoreIA5Match'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
+
+ The caseIgnoreIA5Match rule is an equality matching rule.
+
+4.2.8. caseIgnoreIA5SubstringsMatch
+
+ The caseIgnoreIA5SubstringsMatch rule compares an assertion value of
+ the Substring Assertion syntax to an attribute value of a syntax (e.g
+ the IA5 String syntax) whose corresponding ASN.1 type is IA5String.
+
+ The rule evaluates to TRUE if and only if the prepared substrings of
+ the assertion value match disjoint portions of the prepared attribute
+ value character string in the order of the substrings in the
+ assertion value, and an <initial> substring, if present, matches the
+ beginning of the prepared attribute value character string, and a
+ <final> substring, if present, matches the end of the prepared
+ attribute value character string. A prepared substring matches a
+ portion of the prepared attribute value character string if
+ corresponding characters have the same code point.
+
+ In preparing the attribute value and assertion value substrings for
+ comparison, characters are case folded in the Map preparation step,
+ and only Insignificant Space Handling is applied in the Insignificant
+ Character Handling step.
+
+ ( 1.3.6.1.4.1.1466.109.114.3 NAME 'caseIgnoreIA5SubstringsMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
+
+ The caseIgnoreIA5SubstringsMatch rule is a substrings matching rule.
+
+4.2.9. caseIgnoreListMatch
+
+ The caseIgnoreListMatch rule compares an assertion value that is a
+ sequence of strings to an attribute value of a syntax (e.g., the
+ Postal Address syntax) whose corresponding ASN.1 type is a SEQUENCE
+ OF the DirectoryString ASN.1 type.
+
+ The rule evaluates to TRUE if and only if the attribute value and the
+ assertion value have the same number of strings and corresponding
+ strings (by position) match according to the caseIgnoreMatch matching
+ rule.
+
+
+
+
+Legg Expires 23 December 2005 [Page 32]
+
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
+
+ In [X.520] the assertion syntax for this matching rule is defined to
+ be:
+
+ SEQUENCE OF DirectoryString {ub-match}
+
+ i.e., different from the corresponding type for the Postal Address
+ syntax. The choice of the Postal Address syntax for the assertion
+ syntax of the caseIgnoreListMatch in LDAP should not be seen as
+ limiting the matching rule to only apply to attributes with the
+ Postal Address syntax.
+
+ The LDAP definition for the caseIgnoreListMatch rule is:
+
+ ( 2.5.13.11 NAME 'caseIgnoreListMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 )
+
+ The caseIgnoreListMatch rule is an equality matching rule.
+
+4.2.10. caseIgnoreListSubstringsMatch
+
+ The caseIgnoreListSubstringsMatch rule compares an assertion value of
+ the Substring Assertion syntax to an attribute value of a syntax
+ (e.g., the Postal Address syntax) whose corresponding ASN.1 type is a
+ SEQUENCE OF the DirectoryString ASN.1 type.
+
+ The rule evaluates to TRUE if and only if the assertion value
+ matches, per the caseIgnoreSubstringsMatch rule, the character string
+ formed by concatenating the strings of the attribute value, except
+ that none of the <initial>, <any>, or <final> substrings of the
+ assertion value are considered to match a substring of the
+ concatenated string which spans more than one of the original strings
+ of the attribute value.
+
+ Note that, in terms of the LDAP-specific encoding of the Postal
+ Address syntax, the concatenated string omits the <DOLLAR> line
+ separator and the escaping of "\" and "$" characters.
+
+ The LDAP definition for the caseIgnoreListSubstringsMatch rule is:
+
+ ( 2.5.13.12 NAME 'caseIgnoreListSubstringsMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
+
+ The caseIgnoreListSubstringsMatch rule is a substrings matching rule.
+
+4.2.11. caseIgnoreMatch
+
+ The caseIgnoreMatch rule compares an assertion value of the Directory
+ String syntax to an attribute value of a syntax (e.g., the Directory
+
+
+
+Legg Expires 23 December 2005 [Page 33]
+
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
+
+ String, Printable String, Country String or Telephone Number syntax)
+ whose corresponding ASN.1 type is DirectoryString or one of its
+ alternative string types.
+
+ The rule evaluates to TRUE if and only if the prepared attribute
+ value character string and the prepared assertion value character
+ string have the same number of characters and corresponding
+ characters have the same code point.
+
+ In preparing the attribute value and assertion value for comparison,
+ characters are case folded in the Map preparation step, and only
+ Insignificant Space Handling is applied in the Insignificant
+ Character Handling step.
+
+ The LDAP definition for the caseIgnoreMatch rule is:
+
+ ( 2.5.13.2 NAME 'caseIgnoreMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+ The caseIgnoreMatch rule is an equality matching rule.
+
+4.2.12. caseIgnoreOrderingMatch
+
+ The caseIgnoreOrderingMatch rule compares an assertion value of the
+ Directory String syntax to an attribute value of a syntax (e.g., the
+ Directory String, Printable String, Country String or Telephone
+ Number syntax) whose corresponding ASN.1 type is DirectoryString or
+ one of its alternative string types.
+
+ The rule evaluates to TRUE if, and only if, in the code point
+ collation order, the prepared attribute value character string
+ appears earlier than the prepared assertion value character string,
+ i.e., the attribute value is "less than" the assertion value.
+
+ In preparing the attribute value and assertion value for comparison,
+ characters are case folded in the Map preparation step, and only
+ Insignificant Space Handling is applied in the Insignificant
+ Character Handling step.
+
+ The LDAP definition for the caseIgnoreOrderingMatch rule is:
+
+ ( 2.5.13.3 NAME 'caseIgnoreOrderingMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+ The caseIgnoreOrderingMatch rule is an ordering matching rule.
+
+4.2.13. caseIgnoreSubstringsMatch
+
+
+
+
+Legg Expires 23 December 2005 [Page 34]
+
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
+
+ The caseIgnoreSubstringsMatch rule compares an assertion value of the
+ Substring Assertion syntax to an attribute value of a syntax (e.g.,
+ the Directory String, Printable String, Country String or Telephone
+ Number syntax) whose corresponding ASN.1 type is DirectoryString or
+ one of its alternative string types.
+
+ The rule evaluates to TRUE if and only if the prepared substrings of
+ the assertion value match disjoint portions of the prepared attribute
+ value character string in the order of the substrings in the
+ assertion value, and an <initial> substring, if present, matches the
+ beginning of the prepared attribute value character string, and a
+ <final> substring, if present, matches the end of the prepared
+ attribute value character string. A prepared substring matches a
+ portion of the prepared attribute value character string if
+ corresponding characters have the same code point.
+
+ In preparing the attribute value and assertion value substrings for
+ comparison, characters are case folded in the Map preparation step,
+ and only Insignificant Space Handling is applied in the Insignificant
+ Character Handling step.
+
+ The LDAP definition for the caseIgnoreSubstringsMatch rule is:
+
+ ( 2.5.13.4 NAME 'caseIgnoreSubstringsMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
+
+ The caseIgnoreSubstringsMatch rule is a substrings matching rule.
+
+4.2.14. directoryStringFirstComponentMatch
+
+ The directoryStringFirstComponentMatch rule compares an assertion
+ value of the Directory String syntax to an attribute value of a
+ syntax whose corresponding ASN.1 type is a SEQUENCE with a mandatory
+ first component of the DirectoryString ASN.1 type.
+
+ Note that the assertion syntax of this matching rule differs from the
+ attribute syntax of attributes for which this is the equality
+ matching rule.
+
+ The rule evaluates to TRUE if and only if the assertion value matches
+ the first component of the attribute value using the rules of
+ caseIgnoreMatch.
+
+ The LDAP definition for the directoryStringFirstComponentMatch
+ matching rule is:
+
+ ( 2.5.13.31 NAME 'directoryStringFirstComponentMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+
+
+Legg Expires 23 December 2005 [Page 35]
+
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
+
+ The directoryStringFirstComponentMatch rule is an equality matching
+ rule. When using directoryStringFirstComponentMatch to compare two
+ attribute values (of an applicable syntax), an assertion value must
+ first be derived from one of the attribute values. An assertion
+ value can be derived from an attribute value by taking the first
+ component of that attribute value.
+
+4.2.15. distinguishedNameMatch
+
+ The distinguishedNameMatch rule compares an assertion value of the DN
+ syntax to an attribute value of a syntax (e.g., the DN syntax) whose
+ corresponding ASN.1 type is DistinguishedName.
+
+ The rule evaluates to TRUE if and only if the attribute value and the
+ assertion value have the same number of relative distinguished names
+ and corresponding relative distinguished names (by position) are the
+ same. A relative distinguished name (RDN) of the assertion value is
+ the same as an RDN of the attribute value if and only if they have
+ the same number of attribute value assertions and each attribute
+ value assertion (AVA) of the first RDN is the same as the AVA of the
+ second RDN with the same attribute type. The order of the AVAs is
+ not significant. Also note that a particular attribute type may
+ appear in at most one AVA in an RDN. Two AVAs with the same
+ attribute type are the same if their values are equal according to
+ the equality matching rule of the attribute type. If one or more of
+ the AVA comparisons evaluate to Undefined and the remaining AVA
+ comparisons return TRUE then the distinguishedNameMatch rule
+ evaluates to Undefined.
+
+ The LDAP definition for the distinguishedNameMatch rule is:
+
+ ( 2.5.13.1 NAME 'distinguishedNameMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
+
+ The distinguishedNameMatch rule is an equality matching rule.
+
+4.2.16. generalizedTimeMatch
+
+ The generalizedTimeMatch rule compares an assertion value of the
+ Generalized Time syntax to an attribute value of a syntax (e.g the
+ Generalized Time syntax) whose corresponding ASN.1 type is
+ GeneralizedTime.
+
+ The rule evaluates to TRUE if and only if the attribute value
+ represents the same universal coordinated time as the assertion
+ value. If a time is specified with the minutes or seconds absent
+ then the number of minutes or seconds (respectively) is assumed to be
+ zero.
+
+
+
+Legg Expires 23 December 2005 [Page 36]
+
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
+
+ The LDAP definition for the generalizedTimeMatch rule is:
+
+ ( 2.5.13.27 NAME 'generalizedTimeMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 )
+
+ The generalizedTimeMatch rule is an equality matching rule.
+
+4.2.17. generalizedTimeOrderingMatch
+
+ The generalizedTimeOrderingMatch rule compares the time ordering of
+ an assertion value of the Generalized Time syntax to an attribute
+ value of a syntax (e.g the Generalized Time syntax) whose
+ corresponding ASN.1 type is GeneralizedTime.
+
+ The rule evaluates to TRUE if and only if the attribute value
+ represents a universal coordinated time which is earlier than the
+ universal coordinated time represented by the assertion value.
+
+ The LDAP definition for the generalizedTimeOrderingMatch rule is:
+
+ ( 2.5.13.28 NAME 'generalizedTimeOrderingMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 )
+
+ The generalizedTimeOrderingMatch rule is an ordering matching rule.
+
+4.2.18. integerFirstComponentMatch
+
+ The integerFirstComponentMatch rule compares an assertion value of
+ the Integer syntax to an attribute value of a syntax (e.g the DIT
+ Structure Rule Description syntax) whose corresponding ASN.1 type is
+ a SEQUENCE with a mandatory first component of the INTEGER ASN.1
+ type.
+
+ Note that the assertion syntax of this matching rule differs from the
+ attribute syntax of attributes for which this is the equality
+ matching rule.
+
+ The rule evaluates to TRUE if and only if the assertion value and the
+ first component of the attribute value are the same integer value.
+
+ The LDAP definition for the integerFirstComponentMatch matching rule
+ is:
+
+ ( 2.5.13.29 NAME 'integerFirstComponentMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )
+
+ The integerFirstComponentMatch rule is an equality matching rule.
+ When using integerFirstComponentMatch to compare two attribute values
+
+
+
+Legg Expires 23 December 2005 [Page 37]
+
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
+
+ (of an applicable syntax), an assertion value must first be derived
+ from one of the attribute values. An assertion value can be derived
+ from an attribute value by taking the first component of that
+ attribute value.
+
+4.2.19. integerMatch
+
+ The integerMatch rule compares an assertion value of the Integer
+ syntax to an attribute value of a syntax (e.g the Integer syntax)
+ whose corresponding ASN.1 type is INTEGER.
+
+ The rule evaluates to TRUE if and only if the attribute value and the
+ assertion value are the same integer value.
+
+ The LDAP definition for the integerMatch matching rule is:
+
+ ( 2.5.13.14 NAME 'integerMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )
+
+ The integerMatch rule is an equality matching rule.
+
+4.2.20. integerOrderingMatch
+
+ The integerOrderingMatch rule compares an assertion value of the
+ Integer syntax to an attribute value of a syntax (e.g the Integer
+ syntax) whose corresponding ASN.1 type is INTEGER.
+
+ The rule evaluates to TRUE if and only if the integer value of the
+ attribute value is less than the integer value the assertion value.
+
+ The LDAP definition for the integerOrderingMatch matching rule is:
+
+ ( 2.5.13.15 NAME 'integerOrderingMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )
+
+ The integerOrderingMatch rule is an ordering matching rule.
+
+4.2.21. keywordMatch
+
+ The keywordMatch rule compares an assertion value of the Directory
+ String syntax to an attribute value of a syntax (e.g., the Directory
+ String syntax) whose corresponding ASN.1 type is DirectoryString.
+
+ The rule evaluates to TRUE if and only if the assertion value
+ character string matches any keyword in the attribute value. The
+ identification of keywords in the attribute value and the exactness
+ of the match are both implementation specific.
+
+
+
+
+Legg Expires 23 December 2005 [Page 38]
+
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
+
+ The LDAP definition for the keywordMatch rule is:
+
+ ( 2.5.13.33 NAME 'keywordMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+4.2.22. numericStringMatch
+
+ The numericStringMatch rule compares an assertion value of the
+ Numeric String syntax to an attribute value of a syntax (e.g the
+ Numeric String syntax) whose corresponding ASN.1 type is
+ NumericString.
+
+ The rule evaluates to TRUE if and only if the prepared attribute
+ value character string and the prepared assertion value character
+ string have the same number of characters and corresponding
+ characters have the same code point.
+
+ In preparing the attribute value and assertion value for comparison,
+ characters are not case folded in the Map preparation step, and only
+ numericString Insignificant Character Handling is applied in the
+ Insignificant Character Handling step.
+
+ The LDAP definition for the numericStringMatch matching rule is:
+
+ ( 2.5.13.8 NAME 'numericStringMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 )
+
+ The numericStringMatch rule is an equality matching rule.
+
+4.2.23. numericStringOrderingMatch
+
+ The numericStringOrderingMatch rule compares an assertion value of
+ the Numeric String syntax to an attribute value of a syntax (e.g the
+ Numeric String syntax) whose corresponding ASN.1 type is
+ NumericString.
+
+ The rule evaluates to TRUE if, and only if, in the code point
+ collation order, the prepared attribute value character string
+ appears earlier than the prepared assertion value character string,
+ i.e., the attribute value is "less than" the assertion value.
+
+ In preparing the attribute value and assertion value for comparison,
+ characters are not case folded in the Map preparation step, and only
+ numericString Insignificant Character Handling is applied in the
+ Insignificant Character Handling step.
+
+ The rule is identical to the caseIgnoreOrderingMatch rule except that
+ all space characters are skipped during comparison (case is
+
+
+
+Legg Expires 23 December 2005 [Page 39]
+
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
+
+ irrelevant as characters are numeric).
+
+ The LDAP definition for the numericStringOrderingMatch matching rule
+ is:
+
+ ( 2.5.13.9 NAME 'numericStringOrderingMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 )
+
+ The numericStringOrderingMatch rule is an ordering matching rule.
+
+4.2.24. numericStringSubstringsMatch
+
+ The numericStringSubstringsMatch rule compares an assertion value of
+ the Substring Assertion syntax to an attribute value of a syntax (e.g
+ the Numeric String syntax) whose corresponding ASN.1 type is
+ NumericString.
+
+ The rule evaluates to TRUE if and only if the prepared substrings of
+ the assertion value match disjoint portions of the prepared attribute
+ value character string in the order of the substrings in the
+ assertion value, and an <initial> substring, if present, matches the
+ beginning of the prepared attribute value character string, and a
+ <final> substring, if present, matches the end of the prepared
+ attribute value character string. A prepared substring matches a
+ portion of the prepared attribute value character string if
+ corresponding characters have the same code point.
+
+ In preparing the attribute value and assertion value for comparison,
+ characters are not case folded in the Map preparation step, and only
+ numericString Insignificant Character Handling is applied in the
+ Insignificant Character Handling step.
+
+ The LDAP definition for the numericStringSubstringsMatch matching
+ rule is:
+
+ ( 2.5.13.10 NAME 'numericStringSubstringsMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
+
+ The numericStringSubstringsMatch rule is a substrings matching rule.
+
+4.2.25. objectIdentifierFirstComponentMatch
+
+ The objectIdentifierFirstComponentMatch rule compares an assertion
+ value of the OID syntax to an attribute value of a syntax (e.g the
+ Attribute Type Description, DIT Content Rule Description, LDAP Syntax
+ Description, Matching Rule Description, Matching Rule Use
+ Description, Name Form Description or Object Class Description
+ syntax) whose corresponding ASN.1 type is a SEQUENCE with a mandatory
+
+
+
+Legg Expires 23 December 2005 [Page 40]
+
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
+
+ first component of the OBJECT IDENTIFIER ASN.1 type.
+
+ Note that the assertion syntax of this matching rule differs from the
+ attribute syntax of attributes for which this is the equality
+ matching rule.
+
+ The rule evaluates to TRUE if and only if the assertion value matches
+ the first component of the attribute value using the rules of
+ objectIdentifierMatch.
+
+ The LDAP definition for the objectIdentifierFirstComponentMatch
+ matching rule is:
+
+ ( 2.5.13.30 NAME 'objectIdentifierFirstComponentMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
+
+ The objectIdentifierFirstComponentMatch rule is an equality matching
+ rule. When using objectIdentifierFirstComponentMatch to compare two
+ attribute values (of an applicable syntax), an assertion value must
+ first be derived from one of the attribute values. An assertion
+ value can be derived from an attribute value by taking the first
+ component of that attribute value.
+
+4.2.26. objectIdentifierMatch
+
+ The objectIdentifierMatch rule compares an assertion value of the OID
+ syntax to an attribute value of a syntax (e.g the OID syntax) whose
+ corresponding ASN.1 type is OBJECT IDENTIFIER.
+
+ The rule evaluates to TRUE if and only if the assertion value and the
+ attribute value represent the same object identifier, that is, the
+ same sequence of integers, whether represented explicitly in the
+ <numericoid> form of <oid> or implicitly in the <descr> form (see
+ [MODELS]).
+
+ If an LDAP client supplies an assertion value in the <descr> form,
+ and the chosen descriptor is not recognized by the server, then the
+ objectIdentifierMatch rule evaluates to Undefined.
+
+ The LDAP definition for the objectIdentifierMatch matching rule is:
+
+ ( 2.5.13.0 NAME 'objectIdentifierMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
+
+ The objectIdentifierMatch rule is an equality matching rule.
+
+4.2.27. octetStringMatch
+
+
+
+
+Legg Expires 23 December 2005 [Page 41]
+
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
+
+ The octetStringMatch rule compares an assertion value of the Octet
+ String syntax to an attribute value of a syntax (e.g the Octet String
+ or JPEG syntax) whose corresponding ASN.1 type is the OCTET STRING
+ ASN.1 type.
+
+ The rule evaluates to TRUE if and only if the attribute value and the
+ assertion value are the same length and corresponding octets (by
+ position) are the same.
+
+ The LDAP definition for the octetStringMatch matching rule is:
+
+ ( 2.5.13.17 NAME 'octetStringMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )
+
+ The octetStringMatch rule is an equality matching rule.
+
+4.2.28. octetStringOrderingMatch
+
+ The octetStringOrderingMatch rule compares an assertion value of the
+ Octet String syntax to an attribute value of a syntax (e.g the Octet
+ String or JPEG syntax) whose corresponding ASN.1 type is the OCTET
+ STRING ASN.1 type.
+
+ The rule evaluates to TRUE if and only if the attribute value appears
+ earlier in the collation order than the assertion value. The rule
+ compares octet strings from the first octet to the last octet, and
+ from the most significant bit to the least significant bit within the
+ octet. The first occurrence of a different bit determines the
+ ordering of the strings. A zero bit precedes a one bit. If the
+ strings contain different numbers of octets but the longer string is
+ identical to the shorter string up to the length of the shorter
+ string then the shorter string precedes the longer string.
+
+ The LDAP definition for the octetStringOrderingMatch matching rule
+ is:
+
+ ( 2.5.13.18 NAME 'octetStringOrderingMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )
+
+ The octetStringOrderingMatch rule is an ordering matching rule.
+
+4.2.29. telephoneNumberMatch
+
+ The telephoneNumberMatch rule compares an assertion value of the
+ Telephone Number syntax to an attribute value of a syntax (e.g the
+ Telephone Number syntax) whose corresponding ASN.1 type is a
+ PrintableString representing a telephone number.
+
+
+
+
+Legg Expires 23 December 2005 [Page 42]
+
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
+
+ The rule evaluates to TRUE if and only if the prepared attribute
+ value character string and the prepared assertion value character
+ string have the same number of characters and corresponding
+ characters have the same code point.
+
+ In preparing the attribute value and assertion value for comparison,
+ characters are case folded in the Map preparation step, and only
+ telephoneNumber Insignificant Character Handling is applied in the
+ Insignificant Character Handling step.
+
+ The LDAP definition for the telephoneNumberMatch matching rule is:
+
+ ( 2.5.13.20 NAME 'telephoneNumberMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 )
+
+ The telephoneNumberMatch rule is an equality matching rule.
+
+4.2.30. telephoneNumberSubstringsMatch
+
+ The telephoneNumberSubstringsMatch rule compares an assertion value
+ of the Substring Assertion syntax to an attribute value of a syntax
+ (e.g the Telephone Number syntax) whose corresponding ASN.1 type is a
+ PrintableString representing a telephone number.
+
+ The rule evaluates to TRUE if and only if the prepared substrings of
+ the assertion value match disjoint portions of the prepared attribute
+ value character string in the order of the substrings in the
+ assertion value, and an <initial> substring, if present, matches the
+ beginning of the prepared attribute value character string, and a
+ <final> substring, if present, matches the end of the prepared
+ attribute value character string. A prepared substring matches a
+ portion of the prepared attribute value character string if
+ corresponding characters have the same code point.
+
+ In preparing the attribute value and assertion value substrings for
+ comparison, characters are case folded in the Map preparation step,
+ and only telephoneNumber Insignificant Character Handling is applied
+ in the Insignificant Character Handling step.
+
+ The LDAP definition for the telephoneNumberSubstringsMatch matching
+ rule is:
+
+ ( 2.5.13.21 NAME 'telephoneNumberSubstringsMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
+
+ The telephoneNumberSubstringsMatch rule is a substrings matching
+ rule.
+
+
+
+
+Legg Expires 23 December 2005 [Page 43]
+
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
+
+4.2.31. uniqueMemberMatch
+
+ The uniqueMemberMatch rule compares an assertion value of the Name
+ And Optional UID syntax to an attribute value of a syntax (e.g the
+ Name And Optional UID syntax) whose corresponding ASN.1 type is
+ NameAndOptionalUID.
+
+ The rule evaluates to TRUE if and only if the <distinguishedName>
+ components of the assertion value and attribute value match according
+ to the distinguishedNameMatch rule and either, the <BitString>
+ component is absent from both the attribute value and assertion
+ value, or the <BitString> component is present in both the attribute
+ value and the assertion value and the <BitString> component of the
+ assertion value matches the <BitString> component of the attribute
+ value according to the bitStringMatch rule.
+
+ Note that this matching rule has been altered from its description in
+ X.520 [X.520] in order to make the matching rule commutative. Server
+ implementors should consider using the original X.520 semantics
+ (where the matching was less exact) for approximate matching of
+ attributes with uniqueMemberMatch as the equality matching rule.
+
+ The LDAP definition for the uniqueMemberMatch matching rule is:
+
+ ( 2.5.13.23 NAME 'uniqueMemberMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.34 )
+
+ The uniqueMemberMatch rule is an equality matching rule.
+
+4.2.32. wordMatch
+
+ The wordMatch rule compares an assertion value of the Directory
+ String syntax to an attribute value of a syntax (e.g., the Directory
+ String syntax) whose corresponding ASN.1 type is DirectoryString.
+
+ The rule evaluates to TRUE if and only if the assertion value word
+ matches, according to the semantics of caseIgnoreMatch, any word in
+ the attribute value. The precise definition of a word is
+ implementation specific.
+
+ The LDAP definition for the wordMatch rule is:
+
+ ( 2.5.13.32 NAME 'wordMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+5. Security Considerations
+
+ In general, the LDAP-specific encodings for syntaxes defined in this
+
+
+
+Legg Expires 23 December 2005 [Page 44]
+
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
+
+ document do not define canonical encodings. That is, a
+ transformation from an LDAP-specific encoding into some other
+ encoding (e.g., BER) and back into the LDAP-specific encoding will
+ not necessarily reproduce exactly the original octets of the
+ LDAP-specific encoding. Therefore an LDAP-specific encoding should
+ not be used where a canonical encoding is required.
+
+ Furthermore, the LDAP-specific encodings do not necessarily enable an
+ alternative encoding of values of the Directory String and DN
+ syntaxes to be reconstructed, e.g., a transformation from a
+ Distinguished Encoding Rules (DER) [BER] encoding to an LDAP-specific
+ encoding and back to a DER encoding may not reproduce the original
+ DER encoding. Therefore LDAP-specific encodings should not be used
+ where reversibility to DER is needed, e.g., for the verification of
+ digital signatures. Instead, DER or a DER-reversible encoding should
+ be used.
+
+ When interpreting security-sensitive fields, and in particular fields
+ used to grant or deny access, implementations MUST ensure that any
+ matching rule comparisons are done on the underlying abstract value,
+ regardless of the particular encoding used.
+
+6. Acknowledgements
+
+ This document is primarily a revision of RFC 2252 by M. Wahl, A.
+ Coulbeck, T. Howes, and S. Kille. RFC 2252 was a product of the IETF
+ ASID Working Group.
+
+ This document is based upon input of the IETF LDAPBIS working group.
+ The author would like to thank Kathy Dally for editing the early
+ drafts of this revision, and Jim Sermersheim and Kurt Zeilenga for
+ their significant contributions to this revision.
+
+7. IANA Considerations
+
+ The Internet Assigned Numbers Authority (IANA) is requested to update
+ the LDAP descriptors registry [BCP64] as indicated by the following
+ templates:
+
+ Subject: Request for LDAP Descriptor Registration Update
+ Descriptor (short name): see comment
+ Object Identifier: see comment
+ Person & email address to contact for further information:
+ Steven Legg <steven.legg at eb2bcom.com>
+ Usage: see comment
+ Specification: RFC XXXX
+ Author/Change Controller: IESG
+ Comments:
+
+
+
+Legg Expires 23 December 2005 [Page 45]
+
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
+
+ The following descriptors (short names) should be updated to refer
+ to RFC XXXX.
+
+ NAME Type OID
+ ------------------------------------------------------------------
+ bitStringMatch M 2.5.13.16
+ booleanMatch M 2.5.13.13
+ caseExactIA5Match M 1.3.6.1.4.1.1466.109.114.1
+ caseExactMatch M 2.5.13.5
+ caseExactOrderingMatch M 2.5.13.6
+ caseExactSubstringsMatch M 2.5.13.7
+ caseIgnoreIA5Match M 1.3.6.1.4.1.1466.109.114.2
+ caseIgnoreListMatch M 2.5.13.11
+ caseIgnoreListSubstringsMatch M 2.5.13.12
+ caseIgnoreMatch M 2.5.13.2
+ caseIgnoreOrderingMatch M 2.5.13.3
+ caseIgnoreSubstringsMatch M 2.5.13.4
+ directoryStringFirstComponentMatch M 2.5.13.31
+ distinguishedNameMatch M 2.5.13.1
+ generalizedTimeMatch M 2.5.13.27
+ generalizedTimeOrderingMatch M 2.5.13.28
+ integerFirstComponentMatch M 2.5.13.29
+ integerMatch M 2.5.13.14
+ integerOrderingMatch M 2.5.13.15
+ keywordMatch M 2.5.13.33
+ numericStringMatch M 2.5.13.8
+ numericStringOrderingMatch M 2.5.13.9
+ numericStringSubstringsMatch M 2.5.13.10
+ objectIdentifierFirstComponentMatch M 2.5.13.30
+ octetStringMatch M 2.5.13.17
+ octetStringOrderingMatch M 2.5.13.18
+ telephoneNumberMatch M 2.5.13.20
+ telephoneNumberSubstringsMatch M 2.5.13.21
+ uniqueMemberMatch M 2.5.13.23
+ wordMatch M 2.5.13.32
+
+ The descriptor for the object identifier 2.5.13.0 was incorrectly
+ registered as objectIdentifiersMatch (extraneous `s') in BCP 64.
+ It should be changed to the following with a reference to
+ RFC XXXX.
+
+ NAME Type OID
+ ------------------------------------------------------------------
+ objectIdentifierMatch M 2.5.13.0
+
+
+ Subject: Request for LDAP Descriptor Registration
+ Descriptor (short name): caseIgnoreIA5SubstringsMatch
+
+
+
+Legg Expires 23 December 2005 [Page 46]
+
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
+
+ Object Identifier: 1.3.6.1.4.1.1466.109.114.3
+ Person & email address to contact for further information:
+ Steven Legg <steven.legg at eb2bcom.com>
+ Usage: other (M)
+ Specification: RFC XXXX
+ Author/Change Controller: IESG
+
+Appendix A. Summary of Syntax Object Identifiers
+
+ The following list summarizes the object identifiers assigned to the
+ syntaxes defined in this document.
+
+ Syntax OBJECT IDENTIFIER
+ ==============================================================
+ Attribute Type Description 1.3.6.1.4.1.1466.115.121.1.3
+ Bit String 1.3.6.1.4.1.1466.115.121.1.6
+ Boolean 1.3.6.1.4.1.1466.115.121.1.7
+ Country String 1.3.6.1.4.1.1466.115.121.1.11
+ Delivery Method 1.3.6.1.4.1.1466.115.121.1.14
+ Directory String 1.3.6.1.4.1.1466.115.121.1.15
+ DIT Content Rule Description 1.3.6.1.4.1.1466.115.121.1.16
+ DIT Structure Rule Description 1.3.6.1.4.1.1466.115.121.1.17
+ DN 1.3.6.1.4.1.1466.115.121.1.12
+ Enhanced Guide 1.3.6.1.4.1.1466.115.121.1.21
+ Facsimile Telephone Number 1.3.6.1.4.1.1466.115.121.1.22
+ Fax 1.3.6.1.4.1.1466.115.121.1.23
+ Generalized Time 1.3.6.1.4.1.1466.115.121.1.24
+ Guide 1.3.6.1.4.1.1466.115.121.1.25
+ IA5 String 1.3.6.1.4.1.1466.115.121.1.26
+ Integer 1.3.6.1.4.1.1466.115.121.1.27
+ JPEG 1.3.6.1.4.1.1466.115.121.1.28
+ LDAP Syntax Description 1.3.6.1.4.1.1466.115.121.1.54
+ Matching Rule Description 1.3.6.1.4.1.1466.115.121.1.30
+ Matching Rule Use Description 1.3.6.1.4.1.1466.115.121.1.31
+ Name And Optional UID 1.3.6.1.4.1.1466.115.121.1.34
+ Name Form Description 1.3.6.1.4.1.1466.115.121.1.35
+ Numeric String 1.3.6.1.4.1.1466.115.121.1.36
+ Object Class Description 1.3.6.1.4.1.1466.115.121.1.37
+ Octet String 1.3.6.1.4.1.1466.115.121.1.40
+ OID 1.3.6.1.4.1.1466.115.121.1.38
+ Other Mailbox 1.3.6.1.4.1.1466.115.121.1.39
+ Postal Address 1.3.6.1.4.1.1466.115.121.1.41
+ Printable String 1.3.6.1.4.1.1466.115.121.1.44
+ Substring Assertion 1.3.6.1.4.1.1466.115.121.1.58
+ Telephone Number 1.3.6.1.4.1.1466.115.121.1.50
+ Teletex Terminal Identifier 1.3.6.1.4.1.1466.115.121.1.51
+ Telex Number 1.3.6.1.4.1.1466.115.121.1.52
+ UTC Time 1.3.6.1.4.1.1466.115.121.1.53
+
+
+
+Legg Expires 23 December 2005 [Page 47]
+
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
+
+Appendix B. Changes from RFC 2252
+
+ This annex lists the significant differences between this
+ specification and RFC 2252.
+
+ This annex is provided for informational purposes only. It is not a
+ normative part of this specification.
+
+ 1. The IESG Note has been removed.
+
+ 2. The major part of Sections 4, 5 and 7 has been moved to [MODELS]
+ and revised. Changes to the parts of these sections moved to
+ [MODELS] are detailed in [MODELS].
+
+ 3. BNF descriptions of syntax formats have been replaced by ABNF
+ [ABNF] specifications.
+
+ 4. The ambiguous statement in RFC 2252, Section 4.3 regarding the
+ use of a backslash quoting mechanism to escape separator symbols
+ has been removed. The escaping mechanism is now explicitly
+ represented in the ABNF for the syntaxes where this provision
+ applies.
+
+ 5. The description of each of the LDAP syntaxes has been expanded so
+ that they are less dependent on knowledge of X.500 for
+ interpretation.
+
+ 6. The relationship of LDAP syntaxes to corresponding ASN.1 type
+ definitions has been made explicit.
+
+ 7. The set of characters allowed in a <PrintableString> (formerly
+ <printablestring>) has been corrected to align with the
+ PrintableString ASN.1 type in [ASN.1]. Specifically, the double
+ quote character has been removed and the single quote character
+ and equals sign have been added.
+
+ 8. Values of the Directory String, Printable String and Telephone
+ Number syntaxes are now required to have at least one character.
+
+ 9. The <DITContentRuleDescription>, <NameFormDescription> and
+ <DITStructureRuleDescription> rules have been moved to [MODELS].
+
+ 10. The corresponding ASN.1 type for the Other Mailbox syntax has
+ been incorporated from RFC 1274.
+
+ 11. A corresponding ASN.1 type for the LDAP Syntax Description syntax
+ has been invented.
+
+
+
+
+Legg Expires 23 December 2005 [Page 48]
+
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
+
+ 12. The Binary syntax has been removed because it was not adequately
+ specified, implementations with different incompatible
+ interpretations exist, and it was confused with the ;binary
+ transfer encoding.
+
+ 13. All discussion of transfer options, including the ";binary"
+ option, has been removed. All imperatives regarding binary
+ transfer of values have been removed.
+
+ 14. The Delivery Method, Enhanced Guide, Guide, Octet String, Teletex
+ Terminal Identifier and Telex Number syntaxes from RFC 2256 have
+ been incorporated.
+
+ 15. The <criteria> rule for the Enhanced Guide and Guide syntaxes has
+ been extended to accommodate empty "and" and "or" expressions.
+
+ 16. An encoding for the <ttx-value> rule in the Teletex Terminal
+ Identifier syntax has been defined.
+
+ 17. The PKI-related syntaxes (Certificate, Certificate List and
+ Certificate Pair) have been removed. They are reintroduced in
+ [LDAP-PKI] (as is the Supported Algorithm syntax from RFC 2256).
+
+ 18. The MHS OR Address syntax has been removed since its
+ specification (in RFC 2156) is not at draft standard maturity.
+
+ 19. The DL Submit Permission syntax has been removed as it depends on
+ the MHS OR Address syntax.
+
+ 20. The Presentation Address syntax has been removed since its
+ specification (in RFC 1278) is not at draft standard maturity.
+
+ 21. The ACI Item, Access Point, Audio, Data Quality, DSA Quality, DSE
+ Type, LDAP Schema Description, Master And Shadow Access Points,
+ Modify Rights, Protocol Information, Subtree Specification,
+ Supplier Information, Supplier Or Consumer and Supplier And
+ Consumer syntaxes have been removed. These syntaxes are
+ referenced in RFC 2252, but not defined.
+
+ 22. The LDAP Schema Definition syntax (defined in RFC 2927) and the
+ Mail Preference syntax have been removed on the grounds that they
+ are out of scope for the core specification.
+
+ 23. The description of each of the matching rules has been expanded
+ so that they are less dependent on knowledge of X.500 for
+ interpretation.
+
+ 24. The caseIgnoreIA5SubstringsMatch matching rule from RFC 2798 has
+
+
+
+Legg Expires 23 December 2005 [Page 49]
+
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
+
+ been added.
+
+ 25. The caseIgnoreListSubstringsMatch, caseIgnoreOrderingMatch and
+ caseIgnoreSubstringsMatch matching rules have been added to the
+ list of matching rules for which the provisions for handling
+ leading, trailing and multiple adjoining whitespace characters
+ apply (now through string preparation). This is consistent with
+ the definitions of these matching rules in X.500. The
+ caseIgnoreIA5SubstringsMatch rule has also been added to the
+ list.
+
+ 26. The specification of the octetStringMatch matching rule from
+ RFC 2256 has been added to this document.
+
+ 27. The presentationAddressMatch matching rule has been removed as it
+ depends on an assertion syntax (Presentation Address) that is not
+ at draft standard maturity.
+
+ 28. The protocolInformationMatch matching rule has been removed as it
+ depends on an undefined assertion syntax (Protocol Information).
+
+ 29. The definitive reference for ASN.1 has been changed from X.208 to
+ X.680 since X.680 is the version of ASN.1 referred to by X.500.
+
+ 30. The specification of the caseIgnoreListSubstringsMatch matching
+ rule from RFC 2798 & X.520 has been added.
+
+ 31. String preparation algorithms have been applied to the character
+ string matching rules.
+
+ 32. The specifications of the booleanMatch, caseExactMatch,
+ caseExactOrderingMatch, caseExactSubstringsMatch,
+ directoryStringFirstComponentMatch, integerOrderingMatch,
+ keywordMatch, numericStringOrderingMatch,
+ octetStringOrderingMatch and wordMatch matching rules from
+ RFC 3698 & X.520 have been added.
+
+Normative References
+
+ [KEYWORD] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [UTF8] Yergeau, F., "UTF-8, a transformation format of ISO
+ 10646", RFC 3629, November 2003.
+
+ [BCP64] Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
+ Considerations for the Lightweight Directory Access
+ Protocol (LDAP)", BCP 64, RFC 3383, September 2002.
+
+
+
+Legg Expires 23 December 2005 [Page 50]
+
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
+
+ [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
+ Specifications: ABNF", draft-crocker-abnf-rfc2234bis-
+ xx.txt, a work in progress, March 2005.
+
+ [ROADMAP] Zeilenga, K., "Lightweight Directory Access Protocol
+ (LDAP): Technical Specification Road Map", draft-ietf-
+ ldapbis-roadmap-xx.txt, a work in progress, February 2005.
+
+ [MODELS] Zeilenga, K., "LDAP: Directory Information Models", draft-
+ ietf-ldapbis-models-xx.txt, a work in progress, February
+ 2005.
+
+ [PROT] Sermersheim, J., "LDAP: The Protocol", draft-ietf-ldapbis-
+ protocol-xx.txt, a work in progress, May 2005.
+
+ [LDAPDN] Zeilenga, K., "LDAP: String Representation of
+ Distinguished Names", draft-ietf-ldapbis-dn-xx.txt, a work
+ in progress, February 2005.
+
+ [PREP] Zeilenga, K., "LDAP: Internationalized String
+ Preparation", draft-ietf-ldapbis-strprep-xx.txt, a work in
+ progress, February 2005.
+
+ [E.123] Notation for national and international telephone numbers,
+ ITU-T Recommendation E.123, 1988.
+
+ [FAX] Standardization of Group 3 facsimile apparatus for
+ document transmission - Terminal Equipment and Protocols
+ for Telematic Services, ITU-T Recommendation T.4, 1993
+
+ [T.50] International Reference Alphabet (IRA) (Formerly
+ International Alphabet No. 5 or IA5) Information
+ Technology - 7-Bit Coded Character Set for Information
+ Interchange, ITU-T Recommendation T.50, 1992
+
+ [X.420] ITU-T Recommendation X.420 (1996) | ISO/IEC 10021-7:1997,
+ Information Technology - Message Handling Systems (MHS):
+ Interpersonal messaging system
+
+ [X.501] ITU-T Recommendation X.501 (1993) | ISO/IEC 9594-2:1994,
+ Information Technology - Open Systems Interconnection -
+ The Directory: Models
+
+ [X.520] ITU-T Recommendation X.520 (1993) | ISO/IEC 9594-6:1994,
+ Information Technology - Open Systems Interconnection -
+ The Directory: Selected attribute types
+
+ [ASN.1] ITU-T Recommendation X.680 (07/02) | ISO/IEC 8824-1:2002,
+
+
+
+Legg Expires 23 December 2005 [Page 51]
+
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
+
+ Information technology - Abstract Syntax Notation One
+ (ASN.1): Specification of basic notation
+
+ [ISO3166] ISO 3166, "Codes for the representation of names of
+ countries".
+
+ [ISO8601] ISO 8601:2004, "Data elements and interchange formats --
+ Information interchange -- Representation of dates and
+ times".
+
+ [UCS] Universal Multiple-Octet Coded Character Set (UCS) -
+ Architecture and Basic Multilingual Plane, ISO/IEC
+ 10646-1: 1993 (with amendments).
+
+ [JPEG] JPEG File Interchange Format (Version 1.02). Eric
+ Hamilton, C-Cube Microsystems, Milpitas, CA, September 1,
+ 1992.
+
+Informative References
+
+ [RFC2252] Wahl, M., Coulbeck, A., Howes, T. and S. Kille,
+ "Lightweight Directory Access Protocol (v3): Attribute
+ Syntax Definitions", RFC 2252, December 1997.
+
+ [RFC2256] Wahl, M., "A Summary of the X.500(96) User Schema for use
+ with LDAPv3", RFC 2256, December 1997.
+
+ [RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access
+ Protocol (v3): Technical Specification", RFC 3377,
+ September 2002.
+
+ [RFC3698] Zeilenga, K., "Lightweight Directory Access Protocol
+ (LDAP): Additional Matching Rules", RFC 3698, February
+ 2004.
+
+ [SCHEMA] Sciberras, A., "LDAP: Schema for User Applications",
+ draft-ietf-ldapbis-user-schema-xx.txt, a work in progress,
+ April 2005.
+
+ [LDAP-PKI] Zeilenga, K. D., "Lightweight Directory Access Protocol
+ (LDAP) schema definitions for X.509 Certificates", draft-
+ zeilenga-ldap-x509-xx.txt, a work in progress, February
+ 2005.
+
+ [X.500] ITU-T Recommendation X.500 (1993) | ISO/IEC 9594-1:1994,
+ Information Technology - Open Systems Interconnection -
+ The Directory: Overview of concepts, models and services
+
+
+
+
+Legg Expires 23 December 2005 [Page 52]
+
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
+
+ [BER] ITU-T Recommendation X.690 (07/02) | ISO/IEC 8825-1:2002,
+ Information technology - ASN.1 encoding rules:
+ Specification of Basic Encoding Rules (BER), Canonical
+ Encoding Rules (CER) and Distinguished Encoding Rules
+ (DER)
+
+Author's Address
+
+ Steven Legg
+ eB2Bcom
+ Suite3, Woodhouse Corporate Centre
+ 935 Station Street
+ Box Hill North, Victoria 3129
+ AUSTRALIA
+
+ Phone: +61 3 9896 7830
+ Fax: +61 3 9896 7801
+ EMail: steven.legg at eb2bcom.com
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2005).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+
+
+
+Legg Expires 23 December 2005 [Page 53]
+
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
+
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr at ietf.org.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Legg Expires 23 December 2005 [Page 54]
+
Added: openldap/vendor/openldap-release/doc/drafts/draft-ietf-ldapbis-url-xx.txt
===================================================================
--- openldap/vendor/openldap-release/doc/drafts/draft-ietf-ldapbis-url-xx.txt (rev 0)
+++ openldap/vendor/openldap-release/doc/drafts/draft-ietf-ldapbis-url-xx.txt 2007-09-15 10:38:52 UTC (rev 844)
@@ -0,0 +1,841 @@
+
+
+
+Network Working Group Mark Smith, Editor
+Request for Comments: DRAFT Pearl Crescent, LLC
+Obsoletes: RFC 2255 Tim Howes
+Expires: 4 July 2005 Opsware, Inc.
+
+ 4 January 2005
+
+
+ LDAP: Uniform Resource Locator
+ <draft-ietf-ldapbis-url-09.txt>
+
+
+
+Status of this Memo
+
+ By submitting this Internet-Draft, each author represents that any
+ applicable patent or other IPR claims of which he or she is aware
+ have been or will be disclosed, and any of which he or she become
+ aware will be disclosed, in accordance with RFC 3668.
+
+ This document is intended to be published as a Standards Track RFC,
+ replacing RFC 2255. Distribution of this memo is unlimited.
+ Technical discussion of this document will take place on the IETF
+ LDAP (v3) Revision (ldapbis) Working Group mailing list
+ <ietf-ldapbis at openldap.org>. Please send editorial comments directly
+ to the editor <mcs at pearlcrescent.com>.
+
+ Internet-Drafts are working documents of the Internet Engineering
+ Task Force (IETF), its areas, and its working groups. Note that
+ other groups may also distribute working documents as
+ Internet-Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference
+ material or to cite them other than a "work in progress."
+
+ The list of current Internet-Drafts can be accessed at
+ http://www.ietf.org/1id-abstracts.html
+
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html
+
+ Copyright (C) The Internet Society (2004). All Rights Reserved.
+ Please see the Full Copyright section near the end of this document
+ for more information.
+
+
+
+
+
+Smith & Howes Intended Category: Standards Track [Page 1]
+
+INTERNET-DRAFT LDAP: Uniform Resource Locator 4 January 2005
+
+
+Abstract
+
+ This document describes a format for a Lightweight Directory Access
+ Protocol (LDAP) Uniform Resource Locator (URL). An LDAP URL
+ describes an LDAP search operation that is used to retrieve
+ information from an LDAP directory, or, in the context of an LDAP
+ referral or reference, an LDAP URL describes a service where an LDAP
+ operation may be progressed.
+
+Table of Contents
+
+ Status of this Memo............................................1
+ Abstract.......................................................2
+ Table of Contents..............................................2
+1. Introduction...................................................2
+2. URL Definition.................................................3
+2.1. Percent-Encoding............................................5
+3. Defaults for Fields of the LDAP URL............................5
+4. Examples.......................................................6
+5. Security Considerations........................................8
+6. IANA Considerations............................................9
+7. Normative References...........................................9
+8. Informative References.........................................10
+9. Acknowledgements...............................................10
+10. Authors' Addresses.............................................11
+11. Appendix A: Changes Since RFC 2255.............................11
+11.1. Technical Changes...........................................11
+11.2. Editorial Changes...........................................12
+12. Appendix B: Changes Since Previous Document Revision...........14
+12.1. Technical Changes...........................................14
+12.2. Editorial Changes...........................................14
+ Intellectual Property Rights...................................14
+ Full Copyright.................................................15
+
+1. Introduction
+
+ LDAP is the Lightweight Directory Access Protocol [Roadmap]. This
+ document specifies the LDAP URL format for version 3 of LDAP and
+ clarifies how LDAP URLs are resolved. This document also defines an
+ extension mechanism for LDAP URLs. This mechanism may be used to
+ provide access to new LDAP extensions.
+
+ Note that not all of the parameters of the LDAP search operation
+ described in [Protocol] can be expressed using the format defined in
+ this document. Note also that URLs may be used to represent reference
+ knowledge, including for non-search operations.
+
+
+
+
+
+Smith & Howes Intended Category: Standards Track [Page 2]
+
+INTERNET-DRAFT LDAP: Uniform Resource Locator 4 January 2005
+
+
+ This document is a integral part of the LDAP technical specification
+ [Roadmap] which obsoletes the previously defined LDAP technical
+ specification, RFC 3377, in its entirety.
+
+ This document replaces RFC 2255. See Appendix A for a list of changes
+ relative to RFC 2255.
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in BCP 14 [RFC2119].
+
+2. URL Definition
+
+ An LDAP URL begins with the protocol prefix "ldap" and is defined by
+ the following grammar, following the ABNF notation defined in
+ [RFC2234].
+
+ ldapurl = scheme COLON SLASH SLASH [host [COLON port]]
+ [SLASH dn [QUESTION [attributes]
+ [QUESTION [scope] [QUESTION [filter]
+ [QUESTION extensions]]]]]
+ ; <host> and <port> are defined
+ ; in Sections 3.2.2 and 3.2.3
+ ; of [RFC2396bis].
+ ; <filter> is from Section 3 of
+ ; [Filters], subject to the
+ ; provisions of the
+ ; "Percent-Encoding" section
+ ; below.
+
+ scheme = "ldap"
+
+ dn = distinguishedName ; From Section 3 of [LDAPDN],
+ ; subject to the provisions of
+ ; the "Percent-Encoding"
+ ; section below.
+
+ attributes = attrdesc *(COMMA attrdesc)
+ attrdesc = selector *(COMMA selector)
+ selector = attributeSelector ; From Section 4.5.1 of
+ ; [Protocol], subject to the
+ ; provisions of the
+ ; "Percent-Encoding" section
+ ; below.
+
+ scope = "base" / "one" / "sub"
+ extensions = extension *(COMMA extension)
+ extension = [EXCLAMATION] extype [EQUALS exvalue]
+
+
+
+Smith & Howes Intended Category: Standards Track [Page 3]
+
+INTERNET-DRAFT LDAP: Uniform Resource Locator 4 January 2005
+
+
+ extype = oid ; From section 1.4 of [Models].
+
+ exvalue = LDAPString ; From section 4.1.2 of
+ ; [Protocol], subject to the
+ ; provisions of the
+ ; "Percent-Encoding" section
+ ; below.
+
+ EXCLAMATION = %x21 ; exclamation mark ("!")
+ SLASH = %x2F ; forward slash ("/")
+ COLON = %x3A ; colon (":")
+ QUESTION = %x3F ; question mark ("?")
+
+
+ The "ldap" prefix indicates an entry or entries accessible from the
+ LDAP server running on the given hostname at the given portnumber.
+ Note that the <host> may contain literal IPv6 addresses as specified
+ in Section 3.2.2 of [RFC2396bis].
+
+ The <dn> is an LDAP Distinguished Name using the string format
+ described in [LDAPDN]. It identifies the base object of the LDAP
+ search or the target of a non-search operation.
+
+ The <attributes> construct is used to indicate which attributes
+ should be returned from the entry or entries.
+
+ The <scope> construct is used to specify the scope of the search to
+ perform in the given LDAP server. The allowable scopes are "base"
+ for a base object search, "one" for a one-level search, or "sub" for
+ a subtree search.
+
+ The <filter> is used to specify the search filter to apply to entries
+ within the specified scope during the search. It has the format
+ specified in [Filters].
+
+ The <extensions> construct provides the LDAP URL with an
+ extensibility mechanism, allowing the capabilities of the URL to be
+ extended in the future. Extensions are a simple comma-separated list
+ of type=value pairs, where the =value portion MAY be omitted for
+ options not requiring it. Each type=value pair is a separate
+ extension. These LDAP URL extensions are not necessarily related to
+ any of the LDAP extension mechanisms. Extensions may be supported or
+ unsupported by the client resolving the URL. An extension prefixed
+ with a '!' character (ASCII 0x21) is critical. An extension not
+ prefixed with a '!' character is non-critical.
+
+ If an LDAP URL extension is implemented (that is, if the
+ implementation understands it and is able to use it), the
+
+
+
+Smith & Howes Intended Category: Standards Track [Page 4]
+
+INTERNET-DRAFT LDAP: Uniform Resource Locator 4 January 2005
+
+
+ implementation MUST make use of it. If an extension is not
+ implemented and is marked critical, the implementation MUST NOT
+ process the URL. If an extension is not implemented and it not
+ marked critical, the implementation MUST ignore the extension.
+
+ The extension type (<extype>) MAY be specified using the numeric OID
+ <numericoid> form (e.g., 1.2.3.4) or the descriptor <descr> form
+ (e.g., myLDAPURLExtension). Use of the <descr> form SHOULD be
+ restricted to registered object identifier descriptive names. See
+ [LDAPIANA] for registration details and usage guidelines for
+ descriptive names.
+
+ No LDAP URL extensions are defined in this document. Other documents
+ or a future version of this document MAY define one or more
+ extensions.
+
+2.1. Percent-Encoding
+
+ A generated LDAP URL MUST consist only of the restricted set of
+ characters included in one of the following three productions defined
+ in [RFC2396bis]:
+
+ <reserved>
+ <unreserved>
+ <pct-encoded>
+
+ Implementations SHOULD accept other valid UTF-8 strings [RFC3629] as
+ input. An octet MUST be encoded using the percent-encoding mechanism
+ described in section 2.1 of [RFC2396bis] in any of these situations:
+
+ The octet is not in the reserved set defined in section 2.2 of
+ [RFC2396bis] or in the unreserved set defined in section 2.3 of
+ [RFC2396bis].
+
+ It is the single Reserved character '?' and occurs inside a <dn>,
+ <filter>, or other element of an LDAP URL.
+
+ It is a comma character ',' that occurs inside an <exvalue>.
+
+ Note that before the percent-encoding mechanism is applied, the
+ extensions component of the LDAP URL may contain one or more null
+ (zero) bytes. No other component may.
+
+3. Defaults for Fields of the LDAP URL
+
+ Some fields of the LDAP URL are optional, as described above. In the
+ absence of any other specification, the following general defaults
+ SHOULD be used when a field is absent. Note that other documents MAY
+
+
+
+Smith & Howes Intended Category: Standards Track [Page 5]
+
+INTERNET-DRAFT LDAP: Uniform Resource Locator 4 January 2005
+
+
+ specify different defaulting rules; for example, section 4.1.10 of
+ [Protocol] specifies a different rule for determining the correct DN
+ to use when it is absent in an LDAP URL that is returned as a
+ referral.
+
+ <host>
+ If no <host> is given, the client must have some apriori knowledge
+ of an appropriate LDAP server to contact.
+
+ <port>
+ The default LDAP port is TCP port 389.
+
+ <dn>
+ If no <dn> is given, the default is the zero-length DN, "".
+
+ <attributes>
+ If the <attributes> part is omitted, all user attributes of the
+ entry or entries should be requested (e.g., by setting the
+ attributes field AttributeDescriptionList in the LDAP search
+ request to a NULL list, or by using the special <alluserattrs>
+ selector "*").
+
+ <scope>
+ If <scope> is omitted, a <scope> of "base" is assumed.
+
+ <filter>
+ If <filter> is omitted, a filter of "(objectClass=*)" is assumed.
+
+ <extensions>
+ If <extensions> is omitted, no extensions are assumed.
+
+
+4. Examples
+
+ The following are some example LDAP URLs using the format defined
+ above. The first example is an LDAP URL referring to the University
+ of Michigan entry, available from an LDAP server of the client's
+ choosing:
+
+ ldap:///o=University%20of%20Michigan,c=US
+
+ The next example is an LDAP URL referring to the University of
+ Michigan entry in a particular ldap server:
+
+ ldap://ldap1.example.net/o=University%20of%20Michigan,c=US
+
+ Both of these URLs correspond to a base object search of the
+ "o=University of Michigan,c=US" entry using a filter of
+
+
+
+Smith & Howes Intended Category: Standards Track [Page 6]
+
+INTERNET-DRAFT LDAP: Uniform Resource Locator 4 January 2005
+
+
+ "(objectclass=*)", requesting all attributes.
+
+ The next example is an LDAP URL referring to only the postalAddress
+ attribute of the University of Michigan entry:
+
+ ldap://ldap1.example.net/o=University%20of%20Michigan,
+ c=US?postalAddress
+
+ The corresponding LDAP search operation is the same as in the
+ previous example, except that only the postalAddress attribute is
+ requested.
+
+ The next example is an LDAP URL referring to the set of entries found
+ by querying the given LDAP server on port 6666 and doing a subtree
+ search of the University of Michigan for any entry with a common name
+ of "Babs Jensen", retrieving all attributes:
+
+ ldap://ldap1.example.net:6666/o=University%20of%20Michigan,
+ c=US??sub?(cn=Babs%20Jensen)
+
+ The next example is an LDAP URL referring to all children of the c=GB
+ entry:
+
+ LDAP://ldap1.example.com/c=GB?objectClass?ONE
+
+ The objectClass attribute is requested to be returned along with the
+ entries, and the default filter of "(objectclass=*)" is used.
+
+ The next example is an LDAP URL to retrieve the mail attribute for
+ the LDAP entry named "o=Question?,c=US" is given below, illustrating
+ the use of the percent-encoding mechanism on the reserved character
+ '?'.
+
+ ldap://ldap2.example.com/o=Question%3f,c=US?mail
+
+ The next example (which is broken into two lines for readability)
+ illustrates the interaction between the LDAP string representation of
+ filters quoting mechanism and URL quoting mechanisms.
+
+ ldap://ldap3.example.com/o=Babsco,c=US
+ ???(four-octet=%5c00%5c00%5c00%5c04)
+
+ The filter in this example uses the LDAP escaping mechanism of \ to
+ encode three zero or null bytes in the value. In LDAP, the filter
+ would be written as (four-octet=\00\00\00\04). Because the \
+ character must be escaped in a URL, the \'s are percent-encoded as
+ %5c (or %5C) in the URL encoding.
+
+
+
+
+Smith & Howes Intended Category: Standards Track [Page 7]
+
+INTERNET-DRAFT LDAP: Uniform Resource Locator 4 January 2005
+
+
+ The next example illustrates the interaction between the LDAP string
+ representation of DNs quoting mechanism and URL quoting mechanisms.
+
+ ldap://ldap.example.com/o=An%20Example%5C2C%20Inc.,c=US
+
+ The DN encoded in the above URL is:
+
+ o=An Example\2C Inc.,c=US
+
+ That is, the left-most RDN value is:
+
+ An Example, Inc.
+
+ The following three URLs that are equivalent, assuming that the
+ defaulting rules specified in section 4 of this document are used:
+
+ ldap://ldap.example.net
+ ldap://ldap.example.net/
+ ldap://ldap.example.net/?
+
+ These three URLs all point to the root DSE on the ldap.example.net
+ server.
+
+The final two examples show use of a hypothetical, experimental bind
+name extension (the value associated with the extension is an LDAP DN).
+
+ ldap:///??sub??e-bindname=cn=Manager%2cdc=example%2cdc=com
+ ldap:///??sub??!e-bindname=cn=Manager%2cdc=example%2cdc=com
+
+ The two URLs are the same, except that the second one marks the
+ e-bindname extension as critical. Notice the use of the
+ percent-encoding mechanism to encode the commas within the
+ distinguished name value in the e-bindname extension.
+
+
+5. Security Considerations
+
+ General URL security considerations discussed in [RFC2396bis] are
+ relevant for LDAP URLs.
+
+ The use of security mechanisms when processing LDAP URLs requires
+ particular care, since clients may encounter many different servers
+ via URLs, and since URLs are likely to be processed automatically,
+ without user intervention. A client SHOULD have a user-configurable
+ policy that controls which servers the client will establish LDAP
+ sessions with using which security mechanisms, and SHOULD NOT
+ establish LDAP sessions that are inconsistent with this policy. If a
+ client chooses to reuse an existing LDAP session when resolving one
+
+
+
+Smith & Howes Intended Category: Standards Track [Page 8]
+
+INTERNET-DRAFT LDAP: Uniform Resource Locator 4 January 2005
+
+
+ or more LDAP URLs, it MUST ensure that the session is compatible with
+ the URL and that no security policies are violated.
+
+ Sending authentication information, no matter the mechanism, may
+ violate a user's privacy requirements. In the absence of specific
+ policy permitting authentication information to be sent to a server,
+ a client should use an anonymous LDAP session. (Note that clients
+ conforming to previous LDAP URL specifications, where all LDAP
+ sessions are anonymous and unprotected, are consistent with this
+ specification; they simply have the default security policy.) Simply
+ opening a transport connection to another server may violate some
+ users' privacy requirements, so clients should provide the user with
+ a way to control URL processing.
+
+ Some authentication methods, in particular reusable passwords sent to
+ the server, may reveal easily-abused information to the remote server
+ or to eavesdroppers in transit, and should not be used in URL
+ processing unless explicitly permitted by policy. Confirmation by
+ the human user of the use of authentication information is
+ appropriate in many circumstances. Use of strong authentication
+ methods that do not reveal sensitive information is much preferred.
+ If the URL represents a referral for an update operation, strong
+ authentication methods SHOULD be used. Please refer to the Security
+ Considerations section of [AuthMeth] for more information.
+
+ The LDAP URL format allows the specification of an arbitrary LDAP
+ search operation to be performed when evaluating the LDAP URL.
+ Following an LDAP URL may cause unexpected results, for example, the
+ retrieval of large amounts of data, the initiation of a long-lived
+ search, etc. The security implications of resolving an LDAP URL are
+ the same as those of resolving an LDAP search query.
+
+6. IANA Considerations
+
+ This document has no actions for IANA.
+
+7. Normative References
+
+[AuthMeth] Harrison, R. (editor), "LDAP: Authentication Methods",
+ draft-ietf-ldapbis-authmeth-xx.txt, a work in progress. a
+ work in progress.
+
+[LDAPDN] Zeilenga, K. (editor), "LDAP: String Representation of
+ Distinguished Names", draft-ietf-ldapbis-dn-xx.txt, a work
+ in progress.
+
+[Filters] Smith, M. and Howes, T., "LDAP: String Representation of
+ Search Filters", draft-ietf-ldapbis-filter-xx.txt, a work in
+
+
+
+Smith & Howes Intended Category: Standards Track [Page 9]
+
+INTERNET-DRAFT LDAP: Uniform Resource Locator 4 January 2005
+
+
+ progress.
+
+[RFC2119] Bradner, S., "Key Words for use in RFCs to Indicate
+ Requirement Levels," RFC 2119, BCP 14, March 1997.
+
+[Protocol] Sermersheim, J. (editor), "LDAP: The Protocol",
+ draft-ietf-ldapbis-protocol-xx.txt, a work in progress.
+
+[RFC2234] Crocker, D., Overell, P., "Augmented BNF for Syntax
+ Specifications: ABNF", RFC 2234, November 1997.
+
+[RFC2396bis]
+ Berners-Lee, T., Fielding, R. and Masinter, L., "Uniform
+ Resource Identifiers (URI): Generic Syntax",
+ draft-fielding-uri-rfc2396bis-xx.txt, a work in progress.
+
+[Roadmap] K. Zeilenga (editor), "LDAP: Technical Specification Road
+ Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in progress.
+
+[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
+ RFC 3629, November 2003.
+
+8. Informative References
+
+[LDAPIANA] Zeilenga, K., "IANA Considerations for LDAP",
+ draft-ietf-ldapbis-bcp64-xx.txt, a work in progress. None.
+
+9. Acknowledgements
+
+ The LDAP URL format was originally defined at the University of
+ Michigan. This material is based upon work supported by the National
+ Science Foundation under Grant No. NCR-9416667. The support of both
+ the University of Michigan and the National Science Foundation is
+ gratefully acknowledged.
+
+ This document is an update to RFC 2255 by Tim Howes and Mark Smith.
+ Changes included in this revised specification are based upon
+ discussions among the authors, discussions within the LDAP (v3)
+ Revision Working Group (ldapbis), and discussions within other IETF
+ Working Groups. The contributions of individuals in these working
+ groups is gratefully acknowledged. Several people in particular have
+ made valuable comments on this document; RL "Bob" Morgan, Mark Wahl,
+ Kurt Zeilenga, Jim Sermersheim, and Hallvard Furuseth deserve special
+ thanks for their contributions.
+
+
+
+
+
+
+
+Smith & Howes Intended Category: Standards Track [Page 10]
+
+INTERNET-DRAFT LDAP: Uniform Resource Locator 4 January 2005
+
+
+10. Authors' Addresses
+
+ Mark Smith, Editor
+ Pearl Crescent, LLC
+ 447 Marlpool Dr.
+ Saline, MI 48176
+ USA
+ +1 734 944-2856
+ mcs at pearlcrescent.com
+
+ Tim Howes
+ Opsware, Inc.
+ 599 N. Mathilda Ave.
+ Sunnyvale, CA 94085
+ USA
+ +1 408 744-7509
+ howes at opsware.com
+
+11. Appendix A: Changes Since RFC 2255
+
+11.1. Technical Changes
+
+ The following technical changes were made to the contents of the "URL
+ Definition" section:
+
+ Revised all of the ABNF to use common productions from [Models].
+
+ Replaced references to [RFC2396] with a reference to [RFC2396bis]
+ (this allows literal IPv6 addresses to be used inside the <host>
+ portion of the URL, and a note was added to remind the reader of this
+ enhancement). Referencing [RFC2396bis] required changes to the ABNF
+ and text so that productions that are no longer defined by
+ [RFC2396bis] are not used. For example, <hostport> is not defined by
+ [RFC2396bis] so it has been replaced with host [COLON port]. Note:
+ [RFC2396bis] includes new definitions for the "Reserved" and
+ "Unreserved" sets of characters, and the net result is that the
+ following two additional characters should be percent-encoded when
+ they appear anywhere in the data used to construct an LDAP URL: "["
+ and "]" (these two characters were first added to the Reserved set by
+ RFC 2732).
+
+ Changed the definition of <attrdesc> to refer to <attributeSelector>
+ from [Protocol]. This allows use of "*" in the <attrdesc> part of
+ the URL. It is believed that existing implementations of RFC 2255
+ already support this.
+
+ Avoided use of <prose-val> (bracketed-string) productions in the
+ <dn>, <host>, <attrdesc>, and <exvalue> rules.
+
+
+
+Smith & Howes Intended Category: Standards Track [Page 11]
+
+INTERNET-DRAFT LDAP: Uniform Resource Locator 4 January 2005
+
+
+ Changed the ABNF for <ldapurl> to group the <dn> component with the
+ preceding <SLASH>.
+
+ Changed the <extype> rule to be an <oid> from [Models].
+
+ Changed the text about extension types so it references [LDAPIANA].
+ Reordered rules to more closely follow the order the elements appear
+ in the URL.
+
+ "Bindname Extension": removed due to lack of known implementations.
+
+
+11.2. Editorial Changes
+
+ Changed document title to include "LDAP:" prefix.
+
+ IESG Note: removed note about lack of satisfactory mandatory
+ authentication mechanisms.
+
+ "Status of this Memo" section: updated boilerplate to match current
+ I-D guidelines.
+
+ "Abstract" section: separated from introductory material.
+
+ "Table of Contents" and "IANA Considerations" sections: added.
+
+ "Introduction" section: new section; separated from the Abstract.
+ Changed the text indicate that RFC 2255 is replaced by this document
+ (instead of RFC 1959). Added text to indicate that LDAP URLs are
+ used for references and referrals. Fixed typo (replaced the nonsense
+ phrase "to perform to retrieve" with "used to retrieve"). Added a
+ note to let the reader know that not all of the parameters of the
+ LDAP search operation described in [Protocol] can be expressed using
+ this format.
+
+ "URL Definition" section: removed second copy of <ldapurl> grammar
+ and following two paragraphs (editorial error in RFC 2255). Fixed
+ line break within '!' sequence. Reformatted the ABNF to improve
+ readability by aligning comments and adding some blank lines.
+ Replaced "residing in the LDAP server" with "accessible from the LDAP
+ server" in the sentence immediately following the ABNF. Removed the
+ sentence "Individual attrdesc names are as defined for
+ AttributeDescription in [Protocol]." because [Protocol]'s
+ <attributeSelector> is now used directly in the ABNF. Reworded last
+ paragraph to clarify which characters must be percent-encoded. Added
+ text to indicate that LDAP URLs are used for references and
+ referrals. Added text that refers to the ABNF from RFC 2234.
+ Clarified and strengthened the requirements with respect to
+
+
+
+Smith & Howes Intended Category: Standards Track [Page 12]
+
+INTERNET-DRAFT LDAP: Uniform Resource Locator 4 January 2005
+
+
+ processing of URLs that contain implements and not implemented
+ extensions (the approach now closely matches that specified in
+ [Protocol] for LDAP controls).
+
+ "Defaults for Fields of the LDAP URL" section: added; formed by
+ moving text about defaults out of the "URL Definition" section.
+ Replaced direct reference to the attribute name "*" with a reference
+ to the special <alluserattrs> selector "*" defined in [Protocol].
+
+ "URL Processing" section: removed.
+
+ "Examples" section: Modified examples to use example.com and
+ example.net hostnames. Added missing '?' to the LDAP URL example
+ whose filter contains three null bytes. Removed space after one
+ comma within a DN. Revised the bindname example to use e-bindname.
+ Changed the name of an attribute used in one example from "int" to
+ "four-octet" to avoid potential confusion. Added an example that
+ demonstrates the interaction between DN escaping and URL
+ percent-encoding. Added some examples to show URL equivalence with
+ respect to the <dn> portion of the URL. Used uppercase in some
+ examples to remind the reader that some tokens are case-insensitive.
+
+ "Security Considerations" section: Added a note about connection
+ reuse. Added a note about using strong authentication methods for
+ updates. Added a reference to [AuthMeth]. Added note that simply
+ opening a connection may violate some users' privacy requirements.
+ Adopted the working group's revised LDAP terminology specification by
+ replacing the word "connection" with "LDAP session" or "LDAP
+ connection" as appropriate.
+
+ "Acknowledgements" section: added statement about this being an
+ update to RFC 2255. Added Kurt Zeilenga, Jim Sermersheim, and
+ Hallvard Furuseth.
+
+ "Normative References" section: renamed from "References" per new RFC
+ guidelines. Changed from [1] style to [Protocol] style throughout the
+ document. Added references to RFC 2234 and RFC 3629. Updated all
+ RFC 1738 references to point to the appropriate sections within
+ [RFC2396bis]. Updated the LDAP references to refer to LDAPBis WG
+ documents. Removed the reference to the LDAP Attribute Syntaxes
+ document and added references to the [AuthMeth], [LDAPIANA], and
+ [Roadmap] documents.
+
+ "Informative References" section: added.
+
+ Header and "Authors' Addresses" sections: added "editor" next to Mark
+ Smith's name. Updated affiliation and contact information.
+
+
+
+
+Smith & Howes Intended Category: Standards Track [Page 13]
+
+INTERNET-DRAFT LDAP: Uniform Resource Locator 4 January 2005
+
+
+ Copyright: updated the year.
+
+ Throughout the document: surrounded the names of all ABNF productions
+ with "<" and ">" where they are used in descriptive text.
+
+
+
+12. Appendix B: Changes Since Previous Document Revision
+
+ This appendix lists all changes relative to the previously published
+ revision, draft-ietf-ldapbis-url-08.txt. Note that when appropriate
+ these changes are also included in Appendix A, but are also included
+ here for the benefit of the people who have already reviewed
+ draft-ietf-ldapbis-url-08.txt. This section will be removed before
+ this document is published as an RFC.
+
+12.1. Technical Changes
+
+ Throughout the document: Replaced references to [RFC2396] and
+ [RFC2732] with references to [RFC2396bis]. This required changes to
+ the ABNF and text so that productions that are no longer defined by
+ [RFC2396bis] are not used. For example, <hostport> is not defined by
+ [RFC2396bis] so it has been replaced with host [COLON port]. Note:
+ [RFC2396bis] includes new definitions for the "Reserved" and
+ "Unreserved" sets of characters, and the net result is that the
+ following two additional characters should be percent-encoded when
+ they appear anywhere in the data used to construct an LDAP URL: "["
+ and "]" (these two characters were first added to the Reserved set by
+ RFC 2732).
+
+12.2. Editorial Changes
+
+ Throughout the document: Replaced phrases like "Escaping using the %
+ method" with "Percent-encoding" to be consistent with the terminology
+ used in [RFC2396bis].
+
+ "URL Definition" section: For consistency, replaced all occurrences
+ of the phrase 'see the "Percent-Encoding" section below' with
+ 'subject to the provisions of the "Percent-Encoding" section below.'
+
+ Updated the copyright year to 2005.
+
+
+Intellectual Property Rights
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+
+
+
+Smith & Howes Intended Category: Standards Track [Page 14]
+
+INTERNET-DRAFT LDAP: Uniform Resource Locator 4 January 2005
+
+
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr at ietf.org.
+
+Full Copyright
+
+ Copyright (C) The Internet Society (2005). This document is subject
+ to the rights, licenses and restrictions contained in BCP 78, and
+ except as set forth therein, the authors retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+This Internet Draft expires on 4 July 2005.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Smith & Howes Intended Category: Standards Track [Page 15]
+
+
Added: openldap/vendor/openldap-release/doc/drafts/draft-ietf-ldapbis-user-schema-xx.txt
===================================================================
--- openldap/vendor/openldap-release/doc/drafts/draft-ietf-ldapbis-user-schema-xx.txt (rev 0)
+++ openldap/vendor/openldap-release/doc/drafts/draft-ietf-ldapbis-user-schema-xx.txt 2007-09-15 10:38:52 UTC (rev 844)
@@ -0,0 +1,1963 @@
+
+
+
+
+
+
+INTERNET-DRAFT Editor: A. Sciberras
+Intended Category: Standard Track eB2Bcom
+Updates: RFC 2247, RFC 2798, RFC 2377 January 30, 2006
+Obsoletes: RFC 2256
+
+ LDAP: Schema for User Applications
+ draft-ietf-ldapbis-user-schema-11.txt
+
+ Copyright (C) The Internet Society (2006). All Rights Reserved.
+
+ Status of this Memo
+
+ By submitting this Internet-Draft, each author represents that any
+ applicable patent or other IPR claims of which he or she is aware
+ have been or will be disclosed, and any of which he or she becomes
+ aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+ By submitting this Internet-Draft, I accept the provisions of Section
+ 3 of BCP 78.
+
+ Internet-Drafts are working documents of the Internet Engineering
+ Task Force (IETF), its areas, and its working groups. Note that
+ other groups may also distribute working documents as
+ Internet-Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference
+ material or to cite them other than as "work in progress".
+
+ The list of current Internet-Drafts can be accessed at
+ http://www.ietf.org/1id-abstracts.html
+
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html
+
+ This document is intended to be, after appropriate review and
+ revision, submitted to the RFC Editor as a Standard Track document.
+ Distribution of this document is unlimited. Technical discussion of
+ this document should take place on the IETF LDAP Revision Working
+ Group (LDAPbis) mailing list <ietf-ldapbis at openldap.org>. Please
+ send editorial comments directly to the editor
+ <andrew.sciberras at eb2bcom.com>.
+
+ This Internet-Draft expires on 30 July 2006.
+
+
+
+
+
+
+Sciberras Expires 30 July 2006 [Page 1]
+
+INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
+
+
+Abstract
+
+ This document is an integral part of the Lightweight Directory Access
+ Protocol (LDAP) technical specification [Roadmap]. It provides a
+ technical specification of attribute types and object classes
+ intended for use by LDAP directory clients for many directory
+ services, such as, White Pages. These objects are widely used as a
+ basis for the schema in many LDAP directories. This document does
+ not cover attributes used for the administration of directory
+ servers, nor does it include directory objects defined for specific
+ uses in other documents.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sciberras Expires 30 July 2006 [Page 2]
+
+INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
+
+
+Table of Contents
+
+ Status of this Memo . . . . . . . . . . . . . . . . . . . . . . . 1
+ Copyright Notice. . . . . . . . . . . . . . . . . . . . . . . . . 1
+ Abstract. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
+ Table of Contents . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 5
+ 1.1 Relationship with other specifications . . . . . . . . . 5
+ 1.2 Conventions. . . . . . . . . . . . . . . . . . . . . . . 5
+ 1.3 General Issues . . . . . . . . . . . . . . . . . . . . . 5
+
+ 2. Attribute Types . . . . . . . . . . . . . . . . . . . . . . . 6
+ 2.1 'businessCategory' . . . . . . . . . . . . . . . . . . . 6
+ 2.2 'c'. . . . . . . . . . . . . . . . . . . . . . . . . . . 6
+ 2.3 'cn' . . . . . . . . . . . . . . . . . . . . . . . . . . 7
+ 2.4 'dc' . . . . . . . . . . . . . . . . . . . . . . . . . . 7
+ 2.5 'description'. . . . . . . . . . . . . . . . . . . . . . 8
+ 2.6 'destinationIndicator' . . . . . . . . . . . . . . . . . 8
+ 2.7 'distinguishedName'. . . . . . . . . . . . . . . . . . . 8
+ 2.8 'dnQualifier'. . . . . . . . . . . . . . . . . . . . . . 9
+ 2.9 'enhancedSearchGuide'. . . . . . . . . . . . . . . . . . 9
+ 2.10 'facsimileTelephoneNumber' . . . . . . . . . . . . . . . 10
+ 2.11 'generationQualifier'. . . . . . . . . . . . . . . . . . 10
+ 2.12 'givenName'. . . . . . . . . . . . . . . . . . . . . . . 10
+ 2.13 'houseIdentifier'. . . . . . . . . . . . . . . . . . . . 11
+ 2.14 'initials' . . . . . . . . . . . . . . . . . . . . . . . 11
+ 2.15 'internationalISDNNumber'. . . . . . . . . . . . . . . . 11
+ 2.16 'l'. . . . . . . . . . . . . . . . . . . . . . . . . . . 12
+ 2.17 'member' . . . . . . . . . . . . . . . . . . . . . . . . 12
+ 2.18 'name' . . . . . . . . . . . . . . . . . . . . . . . . . 12
+ 2.19 'o'. . . . . . . . . . . . . . . . . . . . . . . . . . . 13
+ 2.20 'ou' . . . . . . . . . . . . . . . . . . . . . . . . . . 13
+ 2.21 'owner'. . . . . . . . . . . . . . . . . . . . . . . . . 13
+ 2.22 'physicalDeliveryOfficeName' . . . . . . . . . . . . . . 13
+ 2.23 'postalAddress'. . . . . . . . . . . . . . . . . . . . . 14
+ 2.24 'postalCode' . . . . . . . . . . . . . . . . . . . . . . 14
+ 2.25 'postOfficeBox'. . . . . . . . . . . . . . . . . . . . . 14
+ 2.26 'preferredDeliveryMethod'. . . . . . . . . . . . . . . . 15
+ 2.27 'registeredAddress'. . . . . . . . . . . . . . . . . . . 15
+ 2.28 'roleOccupant' . . . . . . . . . . . . . . . . . . . . . 16
+ 2.29 'searchGuide'. . . . . . . . . . . . . . . . . . . . . . 16
+ 2.30 'seeAlso'. . . . . . . . . . . . . . . . . . . . . . . . 16
+ 2.31 'serialNumber' . . . . . . . . . . . . . . . . . . . . . 17
+ 2.32 'sn' . . . . . . . . . . . . . . . . . . . . . . . . . . 17
+ 2.33 'st' . . . . . . . . . . . . . . . . . . . . . . . . . . 17
+ 2.34 'street' . . . . . . . . . . . . . . . . . . . . . . . . 18
+ 2.35 'telephoneNumber'. . . . . . . . . . . . . . . . . . . . 18
+ 2.36 'teletexTerminalIdentifier'. . . . . . . . . . . . . . . 18
+
+
+
+Sciberras Expires 30 July 2006 [Page 3]
+
+INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
+
+
+ 2.37 'telexNumber'. . . . . . . . . . . . . . . . . . . . . . 19
+ 2.38 'title'. . . . . . . . . . . . . . . . . . . . . . . . . 19
+ 2.39 'uid'. . . . . . . . . . . . . . . . . . . . . . . . . . 19
+ 2.40 'uniqueMember' . . . . . . . . . . . . . . . . . . . . . 19
+ 2.41 'userPassword' . . . . . . . . . . . . . . . . . . . . . 20
+ 2.42 'x121Address'. . . . . . . . . . . . . . . . . . . . . . 21
+ 2.43 'x500UniqueIdentifier' . . . . . . . . . . . . . . . . . 21
+
+ 3. Object Classes. . . . . . . . . . . . . . . . . . . . . . . . 22
+ 3.1 'applicationProcess' . . . . . . . . . . . . . . . . . . 22
+ 3.2 'country'. . . . . . . . . . . . . . . . . . . . . . . . 22
+ 3.3 'dcObject' . . . . . . . . . . . . . . . . . . . . . . . 22
+ 3.4 'device' . . . . . . . . . . . . . . . . . . . . . . . . 23
+ 3.5 'groupOfNames' . . . . . . . . . . . . . . . . . . . . . 23
+ 3.6 'groupOfUniqueNames' . . . . . . . . . . . . . . . . . . 23
+ 3.7 'locality' . . . . . . . . . . . . . . . . . . . . . . . 24
+ 3.8 'organization' . . . . . . . . . . . . . . . . . . . . . 24
+ 3.9 'organizationalPerson' . . . . . . . . . . . . . . . . . 24
+ 3.10 'organizationalRole' . . . . . . . . . . . . . . . . . . 25
+ 3.11 'organizationalUnit' . . . . . . . . . . . . . . . . . . 25
+ 3.12 'person' . . . . . . . . . . . . . . . . . . . . . . . . 26
+ 3.13 'residentialPerson'. . . . . . . . . . . . . . . . . . . 26
+ 3.14 'uidObject'. . . . . . . . . . . . . . . . . . . . . . . 26
+
+ 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
+
+ 5. Security Considerations . . . . . . . . . . . . . . . . . . . 28
+
+ 6. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . 29
+
+ 7. References. . . . . . . . . . . . . . . . . . . . . . . . . . 30
+ 7.1 Normative. . . . . . . . . . . . . . . . . . . . . . . . 30
+ 7.2 Informative. . . . . . . . . . . . . . . . . . . . . . . 31
+
+ 8. Author's Address. . . . . . . . . . . . . . . . . . . . . . . 31
+
+ 9. Intellectual Property Statement . . . . . . . . . . . . . . . 32
+
+ 10. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 32
+
+
+
+
+
+
+
+
+
+
+
+
+Sciberras Expires 30 July 2006 [Page 4]
+
+INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
+
+
+1. Introduction
+
+ This document provides an overview of attribute types and object
+ classes intended for use by Lightweight Directory Access Protocol
+ (LDAP) directory clients for many directory services, such as, White
+ Pages. Originally specified in the X.500 [X.500] documents, these
+ objects are widely used as a basis for the schema in many LDAP
+ directories. This document does not cover attributes used for the
+ administration of directory servers, nor does it include directory
+ objects defined for specific uses in other documents.
+
+1.1 Relationship with other specifications
+
+ This document is an integral part of the LDAP technical specification
+ [Roadmap] which obsoletes the previously defined LDAP technical
+ specification, RFC 3377, in its entirety. In terms of RFC 2256,
+ Sections 6 and 8 of RFC 2256 are obsoleted by [Syntaxes]. Sections
+ 5.1, 5.2, 7.1 and 7.2 of RFC 2256 are obsoleted by [Models]. The
+ remainder of RFC 2256 is obsoleted by this document. Section 2.4 of
+ this document supersedes the technical specification for the 'dc'
+ attribute type and 'dcObject' object class found in RFC 2247. The
+ remainder of RFC 2247 remains in force.
+
+ This document updates RFC 2798 by replacing the informative
+ description of the 'uid' attribute type, with the definitive
+ description provided in Section 2.39 of this document.
+
+ A number of schema elements which were included in the previous
+ revision of the LDAP Technical Specification are not included in this
+ revision of LDAP. PKI-related schema elements are now specified in
+ [LDAP-PKI]. Unless reintroduced in future technical specifications,
+ the remainder are to be considered Historic.
+
+ The descriptions in this document SHALL be considered definitive for
+ use in LDAP.
+
+1.2 Conventions
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in RFC 2119 [RFC2119].
+
+1.3 General Issues
+
+ This document references Syntaxes defined in Section 3 of [Syntaxes]
+ and Matching Rules defined in Section 4 of [Syntaxes].
+
+ The definitions of Attribute Types and Object Classes are written
+
+
+
+Sciberras Expires 30 July 2006 [Page 5]
+
+INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
+
+
+ using the Augmented Backus-Naur Form (ABNF) [RFC4234] of
+ AttributeTypeDescription and ObjectClassDescription given in
+ [Models]. Lines have been folded for readability. When such values
+ are transferred as attribute values in the LDAP Protocol the values
+ will not contain line breaks.
+
+2. Attribute Types
+
+ The Attribute Types contained in this section hold user information.
+
+ There is no requirement that servers implement the 'searchGuide' and
+ 'teletexTerminalIdentifier' attribute types. In fact, their use is
+ greatly discouraged.
+
+ An LDAP server implementation SHOULD recognize the rest of the
+ attribute types described in this section.
+
+2.1 'businessCategory'
+
+ The 'businessCategory' attribute type describes the kinds of business
+ performed by an organization. Each kind is one value of this
+ multi-valued attribute.
+ (Source: X.520 [X.520])
+
+ ( 2.5.4.15 NAME 'businessCategory'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+ 1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax
+ [Syntaxes].
+
+ Examples: "banking", "transportation" and "real estate".
+
+2.2 'c'
+
+ The 'c' ('countryName' in X.500) attribute type contains a two-letter
+ ISO 3166 [ISO3166] country code.
+ (Source: X.520 [X.520])
+
+ ( 2.5.4.6 NAME 'c'
+ SUP name
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.11
+ SINGLE-VALUE )
+
+ 1.3.6.1.4.1.1466.115.121.1.11 refers to the Country String syntax
+ [Syntaxes].
+
+
+
+
+Sciberras Expires 30 July 2006 [Page 6]
+
+INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
+
+
+ Examples: "DE", "AU" and "FR".
+
+2.3 'cn'
+
+ The 'cn' ('commonName' in X.500) attribute type contains names of an
+ object. Each name is one value of this multi-valued attribute. If
+ the object corresponds to a person, it is typically the person's full
+ name.
+ (Source: X.520 [X.520])
+
+ ( 2.5.4.3 NAME 'cn'
+ SUP name )
+
+ Examples: "Martin K Smith", "Marty Smith" and "printer12".
+
+2.4 'dc'
+
+ The 'dc' ('domainComponent' in RFC 2247) attribute type is a string
+ holding one component, a label, of a DNS domain name [RFC1034]. The
+ encoding of IA5String for use in LDAP is simply the characters of the
+ ASCII label. The equality matching rule is case insensitive, as is
+ today's DNS.
+ (Source: RFC 2247 [RFC2247])
+
+ ( 0.9.2342.19200300.100.1.25 NAME 'dc'
+ EQUALITY caseIgnoreIA5Match
+ SUBSTR caseIgnoreIA5SubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
+ SINGLE-VALUE )
+
+ 1.3.6.1.4.1.1466.115.121.1.26 refers to the IA5 String syntax
+ [Syntaxes].
+
+ Examples: Valid values include "example" and "com". The value
+ "example.com" is invalid, because it contains two label
+ components.
+
+ Directory applications supporting International Domain Names SHALL
+ use the ToASCII method [RFC3490] to produce the domain name component
+ label. The special considerations discussed in section 4 of RFC 3490
+ [RFC3490] should be taken, depending on whether the domain component
+ is used for "stored" or "query" purposes.
+
+
+
+
+
+
+
+
+
+Sciberras Expires 30 July 2006 [Page 7]
+
+INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
+
+
+2.5 'description'
+
+ The 'description' attribute type contains human-readable descriptive
+ phrases about the object. Each description is one value of this
+ multi-valued attribute.
+ (Source: X.520 [X.520])
+
+ ( 2.5.4.13 NAME 'description'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+ 1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax
+ [Syntaxes].
+
+ Examples: "a color printer", "Maintenance is done every Monday, at
+ 1pm." and "distribution list for all technical staff".
+
+2.6 'destinationIndicator'
+
+ The 'destinationIndicator' attribute type contains country and city
+ strings, associated with the object (the addressee), needed to
+ provide the Public Telegram Service. The strings are composed in
+ accordance with CCITT Recommendations F.1 [F.1] and F.31 [F.31].
+ Each string is one value of this multi-valued attribute.
+ (Source: X.520 [X.520])
+
+ ( 2.5.4.27 NAME 'destinationIndicator'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 )
+
+ 1.3.6.1.4.1.1466.115.121.1.44 refers to the Printable String syntax
+ [Syntaxes].
+
+ Examples: "AASD" as a destination indicator for Sydney, Australia.
+ "GBLD" as a destination indicator for London, United
+ Kingdom.
+
+ It is noted that the directory will not ensure that values of this
+ attribute conform to the F.1 and F.30 CCITT Recommendations. It is
+ the application's responsibility to ensure destination indicators
+ that it stores in this attribute are appropriately constructed.
+
+2.7 'distinguishedName'
+
+ The 'distinguishedName' attribute type is not used as the name of the
+ object itself, but it is instead a base type from which some user
+
+
+
+Sciberras Expires 30 July 2006 [Page 8]
+
+INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
+
+
+ attribute types with a DN syntax can inherit.
+
+ It is unlikely that values of this type itself will occur in an
+ entry. LDAP server implementations which do not support attribute
+ subtyping need not recognize this attribute in requests. Client
+ implementations MUST NOT assume that LDAP servers are capable of
+ performing attribute subtyping.
+ (Source: X.520 [X.520])
+
+ ( 2.5.4.49 NAME 'distinguishedName'
+ EQUALITY distinguishedNameMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
+
+ 1.3.6.1.4.1.1466.115.121.1.12 refers to the DN syntax [Syntaxes].
+
+2.8 'dnQualifier'
+
+ The 'dnQualifier' attribute type contains disambiguating information
+ strings to add to the relative distinguished name of an entry. The
+ information is intended for use when merging data from multiple
+ sources in order to prevent conflicts between entries which would
+ otherwise have the same name. Each string is one value of this
+ multi-valued attribute. It is recommended that a value of the
+ 'dnQualifier' attribute be the same for all entries from a particular
+ source.
+ (Source: X.520 [X.520])
+
+ ( 2.5.4.46 NAME 'dnQualifier'
+ EQUALITY caseIgnoreMatch
+ ORDERING caseIgnoreOrderingMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 )
+
+ 1.3.6.1.4.1.1466.115.121.1.44 refers to the Printable String syntax
+ [Syntaxes].
+
+ Examples: "20050322123345Z" - timestamps can be used to disambiguate
+ information.
+ "123456A" - serial numbers can be used to disambiguate
+ information.
+
+2.9 'enhancedSearchGuide'
+
+ The 'enhancedSearchGuide' attribute type contains sets of information
+ for use by directory clients in constructing search filters. Each
+ set is one value of this multi-valued attribute.
+ (Source: X.520 [X.520])
+
+
+
+
+Sciberras Expires 30 July 2006 [Page 9]
+
+INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
+
+
+ ( 2.5.4.47 NAME 'enhancedSearchGuide'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.21 )
+
+ 1.3.6.1.4.1.1466.115.121.1.21 refers to the Enhanced Guide syntax
+ [Syntaxes].
+
+ Examples: "person#(sn$APPROX)#wholeSubtree" and
+ "organizationalUnit#(ou$SUBSTR)#oneLevel".
+
+2.10 'facsimileTelephoneNumber'
+
+ The 'facsimileTelephoneNumber' attribute type contains telephone
+ numbers (and, optionally, the parameters) for facsimile terminals.
+ Each telephone number is one value of this multi-valued attribute.
+ (Source: X.520 [X.520])
+
+ ( 2.5.4.23 NAME 'facsimileTelephoneNumber'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.22 )
+
+ 1.3.6.1.4.1.1466.115.121.1.22 refers to the Facsimile Telephone
+ Number syntax [Syntaxes].
+
+ Examples: "+61 3 9896 7801" and "+81 3 347 7418$fineResolution".
+
+2.11 'generationQualifier'
+
+ The 'generationQualifier' attribute type contains name strings that
+ are the part of a person's name which typically is the suffix. Each
+ string is one value of this multi-valued attribute.
+ (Source: X.520 [X.520])
+
+ ( 2.5.4.44 NAME 'generationQualifier'
+ SUP name )
+
+ Examples: "III", "3rd" and "Jr.".
+
+2.12 'givenName'
+
+ The 'givenName' attribute type contains name strings that are the
+ part of a person's name which is not their surname. Each string is
+ one value of this multi-valued attribute.
+ (Source: X.520 [X.520])
+
+ ( 2.5.4.42 NAME 'givenName'
+ SUP name )
+
+ Examples: "Andrew", "Charles" and "Joanne".
+
+
+
+
+Sciberras Expires 30 July 2006 [Page 10]
+
+INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
+
+
+2.13 'houseIdentifier'
+
+ The 'houseIdentifier' attribute type contains identifiers for a
+ building within a location. Each identifier is one value of this
+ multi-valued attribute.
+ (Source: X.520 [X.520])
+
+ ( 2.5.4.51 NAME 'houseIdentifier'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+ 1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax
+ [Syntaxes].
+
+ Examples: "20" to represent the house number 20.
+
+2.14 'initials'
+
+ The 'initials' attribute type contains strings of initials of some or
+ all of an individual's names, except the surname(s). Each string is
+ one value of this multi-valued attribute.
+ (Source: X.520 [X.520])
+
+ ( 2.5.4.43 NAME 'initials'
+ SUP name )
+
+ Examples: "K. A." and "K".
+
+2.15 'internationalISDNNumber'
+
+ The 'internationalISDNNumber' attribute type contains Integrated
+ Services Digital Network (ISDN) addresses, as defined in the
+ International Telecommunication Union (ITU) Recommendation E.164
+ [E.164]. Each address is one value of this multi-valued attribute.
+ (Source: X.520 [X.520])
+
+ ( 2.5.4.25 NAME 'internationalISDNNumber'
+ EQUALITY numericStringMatch
+ SUBSTR numericStringSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 )
+
+ 1.3.6.1.4.1.1466.115.121.1.36 refers to the Numeric String syntax
+ [Syntaxes].
+
+ Example: "0198 333 333".
+
+
+
+
+
+Sciberras Expires 30 July 2006 [Page 11]
+
+INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
+
+
+2.16 'l'
+
+ The 'l' ('localityName' in X.500) attribute type contains names of a
+ locality or place, such as a city, county or other geographic region.
+ Each name is one value of this multi-valued attribute.
+ (Source: X.520 [X.520])
+
+ ( 2.5.4.7 NAME 'l'
+ SUP name )
+
+ Examples: "Geneva", "Paris" and "Edinburgh".
+
+2.17 'member'
+
+ The 'member' attribute type contains the Distinguished Names of
+ objects that are on a list or in a group. Each name is one value of
+ this multi-valued attribute.
+ (Source: X.520 [X.520])
+
+ ( 2.5.4.31 NAME 'member'
+ SUP distinguishedName )
+
+ Examples: "cn=James Clarke,ou=Finance,o=Widget\, Inc." and
+ "cn=John Xerri,ou=Finance,o=Widget\, Inc." may
+ be two members of the financial team (group) at Widget,
+ Inc. In which case, both of these distinguished names would
+ be present as individual values of the member attribute.
+
+2.18 'name'
+
+ The 'name' attribute type is the attribute supertype from which user
+ attribute types with the name syntax inherit. Such attribute types
+ are typically used for naming. The attribute type is multi-valued.
+
+ It is unlikely that values of this type itself will occur in an
+ entry. LDAP server implementations which do not support attribute
+ subtyping need not recognize this attribute in requests. Client
+ implementations MUST NOT assume that LDAP servers are capable of
+ performing attribute subtyping.
+ (Source: X.520 [X.520])
+
+ ( 2.5.4.41 NAME 'name'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+ 1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax
+ [Syntaxes].
+
+
+
+Sciberras Expires 30 July 2006 [Page 12]
+
+INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
+
+
+2.19 'o'
+
+ The 'o' ('organizationName' in X.500) attribute type contains the
+ names of an organization. Each name is one value of this
+ multi-valued attribute.
+ (Source: X.520 [X.520])
+
+ ( 2.5.4.10 NAME 'o'
+ SUP name )
+
+ Examples: "Widget", "Widget, Inc." and "Widget, Incorporated.".
+
+2.20 'ou'
+
+ The 'ou' ('organizationalUnitName' in X.500) attribute type contains
+ the names of an organizational unit. Each name is one value of this
+ multi-valued attribute.
+ (Source: X.520 [X.520])
+
+ ( 2.5.4.11 NAME 'ou'
+ SUP name )
+
+ Examples: "Finance", "Human Resources" and "Research and
+ Development".
+
+2.21 'owner'
+
+ The 'owner' attribute type contains the Distinguished Names of
+ objects that have an ownership responsibility for the object that is
+ owned. Each owner's name is one value of this multi-valued
+ attribute.
+ (Source: X.520 [X.520])
+
+ ( 2.5.4.32 NAME 'owner'
+ SUP distinguishedName )
+
+ Example: The mailing list object, whose DN is "cn=All Employees,
+ ou=Mailing List,o=Widget\, Inc.", is owned by the Human
+ Resources Director.
+ Therefore, the value of the 'owner' attribute within the
+ mailing list object, would be the DN of the director (role):
+ "cn=Human Resources Director,ou=employee,o=Widget\, Inc.".
+
+2.22 'physicalDeliveryOfficeName'
+
+ The 'physicalDeliveryOfficeName' attribute type contains names that a
+ Postal Service uses to identify a post office.
+ (Source: X.520 [X.520])
+
+
+
+Sciberras Expires 30 July 2006 [Page 13]
+
+INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
+
+
+ ( 2.5.4.19 NAME 'physicalDeliveryOfficeName'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+ 1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax
+ [Syntaxes].
+
+ Examples: "Bremerhaven, Main" and "Bremerhaven, Bonnstrasse".
+
+2.23 'postalAddress'
+
+ The 'postalAddress' attribute type contains addresses used by a
+ Postal Service to perform services for the object. Each address is
+ one value of this multi-valued attribute.
+ (Source: X.520 [X.520])
+
+ ( 2.5.4.16 NAME 'postalAddress'
+ EQUALITY caseIgnoreListMatch
+ SUBSTR caseIgnoreListSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 )
+
+ 1.3.6.1.4.1.1466.115.121.1.41 refers to the Postal Address syntax
+ [Syntaxes].
+
+ Example: "15 Main St.$Ottawa$Canada".
+
+2.24 'postalCode'
+
+ The 'postalCode' attribute type contains codes used by a Postal
+ Service to identify postal service zones. Each code is one value of
+ this multi-valued attribute.
+ (Source: X.520 [X.520])
+
+ ( 2.5.4.17 NAME 'postalCode'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+ 1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax
+ [Syntaxes].
+
+ Example: "22180", to identify Vienna, VA in the USA.
+
+2.25 'postOfficeBox'
+
+ The 'postOfficeBox' attribute type contains postal box identifiers
+ that a Postal Service uses when a customer arranges to receive mail
+
+
+
+Sciberras Expires 30 July 2006 [Page 14]
+
+INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
+
+
+ at a box on premises of the Postal Service. Each postal box
+ identifier is a single value of this multi-valued attribute.
+ (Source: X.520 [X.520])
+
+ ( 2.5.4.18 NAME 'postOfficeBox'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+ 1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax
+ [Syntaxes].
+
+ Example: "Box 45".
+
+2.26 'preferredDeliveryMethod'
+
+ The 'preferredDeliveryMethod' attribute type contains an indication
+ of the preferred method of getting a message to the object.
+ (Source: X.520 [X.520])
+
+ ( 2.5.4.28 NAME 'preferredDeliveryMethod'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.14
+ SINGLE-VALUE )
+
+ 1.3.6.1.4.1.1466.115.121.1.14 refers to the Delivery Method syntax
+ [Syntaxes].
+
+ Example: If the mhs-delivery Delivery Method is preferred over
+ telephone-delivery, which is preferred over all other
+ methods, the value would be: "mhs $ telephone".
+
+2.27 'registeredAddress'
+
+ The 'registeredAddress' attribute type contains postal addresses
+ suitable for reception of telegrams or expedited documents, where it
+ is necessary to have the recipient accept delivery. Each address is
+ one value of this multi-valued attribute.
+ (Source: X.520 [X.520])
+
+ ( 2.5.4.26 NAME 'registeredAddress'
+ SUP postalAddress
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 )
+
+ 1.3.6.1.4.1.1466.115.121.1.41 refers to the Postal Address syntax
+ [Syntaxes].
+
+ Example: "Receptionist$Widget, Inc.$15 Main St.$Ottawa$Canada".
+
+
+
+
+Sciberras Expires 30 July 2006 [Page 15]
+
+INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
+
+
+2.28 'roleOccupant'
+
+ The 'roleOccupant' attribute type contains the Distinguished Names of
+ objects (normally people) that fulfill the responsibilities of a role
+ object. Each distinguished name is one value of this multi-valued
+ attribute.
+ (Source: X.520 [X.520])
+
+ ( 2.5.4.33 NAME 'roleOccupant'
+ SUP distinguishedName )
+
+ Example: The role object, "cn=Human Resources
+ Director,ou=Position,o=Widget\, Inc.", is fulfilled by two
+ people whose object names are "cn=Mary
+ Smith,ou=employee,o=Widget\, Inc." and "cn=James
+ Brown,ou=employee,o=Widget\, Inc.". The 'roleOccupant'
+ attribute will contain both of these distinguished names,
+ since they are the occupants of this role.
+
+2.29 'searchGuide'
+
+ The 'searchGuide' attribute type contains sets of information for use
+ by clients in constructing search filters. It is superseded by
+ 'enhancedSearchGuide', described above in section 2.9. Each set is
+ one value of this multi-valued attribute.
+ (Source: X.520 [X.520])
+
+ ( 2.5.4.14 NAME 'searchGuide'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.25 )
+
+ 1.3.6.1.4.1.1466.115.121.1.25 refers to the Guide syntax [Syntaxes].
+
+ Example: "person#sn$EQ".
+
+2.30 'seeAlso'
+
+ The 'seeAlso' attribute type contains Distinguished Names of objects
+ that are related to the subject object. Each related object name is
+ one value of this multi-valued attribute.
+ (Source: X.520 [X.520])
+
+ ( 2.5.4.34 NAME 'seeAlso'
+ SUP distinguishedName )
+
+ Example: The person object, "cn=James Brown,ou=employee,o=Widget\,
+ Inc." is related to the role objects, "cn=Football Team
+ Captain,ou=sponsored activities,o=Widget\, Inc." and
+ "cn=Chess Team,ou=sponsored activities,o=Widget\, Inc.".
+
+
+
+Sciberras Expires 30 July 2006 [Page 16]
+
+INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
+
+
+ Since the role objects are related to the person object, the
+ 'seeAlso' attribute will contain the distinguished name of
+ each role object as separate values.
+
+2.31 'serialNumber'
+
+ The 'serialNumber' attribute type contains the serial numbers of
+ devices. Each serial number is one value of this multi-valued
+ attribute.
+ (Source: X.520 [X.520])
+
+ ( 2.5.4.5 NAME 'serialNumber'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 )
+
+ 1.3.6.1.4.1.1466.115.121.1.44 refers to the Printable String syntax
+ [Syntaxes].
+
+ Examples: "WI-3005" and "XF551426".
+
+2.32 'sn'
+
+ The 'sn' ('surname' in X.500) attribute type contains name strings
+ for the family names of a person. Each string is one value of this
+ multi-valued attribute.
+ (Source: X.520 [X.520])
+
+ ( 2.5.4.4 NAME 'sn'
+ SUP name )
+
+ Example: "Smith".
+
+2.33 'st'
+
+ The 'st' ('stateOrProvinceName' in X.500) attribute type contains the
+ full names of states or provinces. Each name is one value of this
+ multi-valued attribute.
+ (Source: X.520 [X.520])
+
+ ( 2.5.4.8 NAME 'st'
+ SUP name )
+
+ Example: "California".
+
+
+
+
+
+
+
+Sciberras Expires 30 July 2006 [Page 17]
+
+INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
+
+
+2.34 'street'
+
+ The 'street' ('streetAddress' in X.500) attribute type contains site
+ information from a postal address (i.e., the street name, place,
+ avenue, and the house number.). Each street is one value of this
+ multi-valued attribute.
+ (Source: X.520 [X.520])
+
+ ( 2.5.4.9 NAME 'street'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+ 1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax
+ [Syntaxes].
+
+ Example: "15 Main St.".
+
+2.35 'telephoneNumber'
+
+ The 'telephoneNumber' attribute type contains telephone numbers that
+ comply with the ITU Recommendation E.123 [E.123]. Each number is one
+ value of this multi-valued attribute.
+ (Source: X.520 [X.520])
+
+ ( 2.5.4.20 NAME 'telephoneNumber'
+ EQUALITY telephoneNumberMatch
+ SUBSTR telephoneNumberSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 )
+
+ 1.3.6.1.4.1.1466.115.121.1.50 refers to the Telephone Number syntax
+ [Syntaxes].
+
+ Example: "+1 234 567 8901".
+
+2.36 'teletexTerminalIdentifier'
+
+ The withdrawal of Rec. F.200 has resulted in the withdrawal of this
+ attribute.
+ (Source: X.520 [X.520])
+
+ ( 2.5.4.22 NAME 'teletexTerminalIdentifier'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.51 )
+
+ 1.3.6.1.4.1.1466.115.121.1.51 refers to the Teletex Terminal
+ Identifier syntax [Syntaxes].
+
+
+
+
+
+Sciberras Expires 30 July 2006 [Page 18]
+
+INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
+
+
+2.37 'telexNumber'
+
+ The 'telexNumber' attribute type contains sets of strings which are a
+ telex number, country code, and answerback code of a telex terminal.
+ Each set is one value of this multi-valued attribute.
+ (Source: X.520 [X.520])
+
+ ( 2.5.4.21 NAME 'telexNumber'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.52 )
+
+ 1.3.6.1.4.1.1466.115.121.1.52 refers to the Telex Number syntax
+ [Syntaxes].
+
+ Example: "12345$023$ABCDE".
+
+2.38 'title'
+
+ The 'title' attribute type contains the title of a person in their
+ organizational context. Each title is one value of this multi-valued
+ attribute.
+ (Source: X.520 [X.520])
+
+ ( 2.5.4.12 NAME 'title'
+ SUP name )
+ Examples: "Vice President", "Software Engineer" and "CEO".
+
+2.39 'uid'
+
+ The 'uid' ('userid' in RFC 1274) attribute type contains computer
+ system login names associated with the object. Each name is one
+ value of this multi-valued attribute.
+ (Source: RFC 2798 [RFC2798] and RFC 1274 [RFC1274])
+
+ ( 0.9.2342.19200300.100.1.1 NAME 'uid'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+ 1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax
+ [Syntaxes].
+
+ Examples: "s9709015", "admin" and "Administrator".
+
+2.40 'uniqueMember'
+
+ The 'uniqueMember' attribute type contains the Distinguished Names of
+ an object that is on a list or in a group, where the Relative
+ Distinguished Names of the object include a value that distinguishes
+
+
+
+Sciberras Expires 30 July 2006 [Page 19]
+
+INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
+
+
+ between objects when a distinguished name has been reused. Each
+ distinguished name is one value of this multi-valued attribute.
+ (Source: X.520 [X.520])
+
+ ( 2.5.4.50 NAME 'uniqueMember'
+ EQUALITY uniqueMemberMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.34 )
+
+ 1.3.6.1.4.1.1466.115.121.1.34 refers to the Name and Optional UID
+ syntax [Syntaxes].
+
+ Example: If "ou=1st Battalion,o=Defense,c=US" is a battalion that was
+ disbanded, establishing a new battalion with the "same" name
+ would have a unique identifier value added, resulting in
+ "ou=1st Battalion, o=Defense,c=US#'010101'B".
+
+2.41 'userPassword'
+
+ The 'userPassword' attribute contains octet strings that are known
+ only to the user and the system to which the user has access. Each
+ string is one value of this multi-valued attribute.
+
+ The application SHOULD prepare textual strings used as passwords by
+ transcoding them to Unicode, applying SASLprep [RFC4013], and
+ encoding as UTF-8. The determination of whether a password is
+ textual is a local client matter.
+ (Source: X.509 [X.509])
+
+ ( 2.5.4.35 NAME 'userPassword'
+ EQUALITY octetStringMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )
+
+ 1.3.6.1.4.1.1466.115.121.1.40 refers to the Octet String syntax
+ [Syntaxes].
+
+ Passwords are stored using an Octet String syntax and are not
+ encrypted. Transfer of cleartext passwords is strongly discouraged
+ where the underlying transport service cannot guarantee
+ confidentiality and may result in disclosure of the password to
+ unauthorized parties.
+
+ An example of a need for multiple values in the 'userPassword'
+ attribute is an environment where every month the user was expected
+ to use a different password generated by some automated system.
+ During transitional periods, like the last and first day of the
+ periods, it may be necessary to allow two passwords for the two
+ consecutive periods to be valid in the system.
+
+
+
+
+Sciberras Expires 30 July 2006 [Page 20]
+
+INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
+
+
+2.42 'x121Address'
+
+ The 'x121Address' attribute type contains data network addresses as
+ defined by ITU Recommendation X.121 [X.121]. Each address is one
+ value of this multi-valued attribute.
+ (Source: X.520 [X.520])
+
+ ( 2.5.4.24 NAME 'x121Address'
+ EQUALITY numericStringMatch
+ SUBSTR numericStringSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 )
+
+ 1.3.6.1.4.1.1466.115.121.1.36 refers to the Numeric String syntax
+ [Syntaxes].
+
+ Example: "36111222333444555".
+
+2.43 'x500UniqueIdentifier'
+
+ The 'x500UniqueIdentifier' attribute type contains binary strings
+ that are used to distinguish between objects when a distinguished
+ name has been reused. Each string is one value of this multi-valued
+ attribute.
+ In X.520 [X.520], this attribute type is called 'uniqueIdentifier'.
+ This is a different attribute type from both the 'uid' and
+ 'uniqueIdentifier' LDAP attribute types. The 'uniqueIdentifier'
+ attribute type is defined in [RFC1274].
+ (Source: X.520 [X.520])
+
+ ( 2.5.4.45 NAME 'x500UniqueIdentifier'
+ EQUALITY bitStringMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 )
+
+ 1.3.6.1.4.1.1466.115.121.1.6 refers to the Bit String syntax
+ [Syntaxes].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sciberras Expires 30 July 2006 [Page 21]
+
+INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
+
+
+3. Object Classes
+
+ LDAP servers SHOULD recognize all the Object Classes listed here as
+ values of the 'objectClass' attribute (see [Models]).
+
+3.1 'applicationProcess'
+
+ The 'applicationProcess' object class definition is the basis of an
+ entry which represents an application executing in a computer system.
+ (Source: X.521 [X.521])
+
+ ( 2.5.6.11 NAME 'applicationProcess'
+ SUP top
+ STRUCTURAL
+ MUST cn
+ MAY ( seeAlso $
+ ou $
+ l $
+ description ) )
+
+3.2 'country'
+
+ The 'country' object class definition is the basis of an entry which
+ represents a country.
+ (Source: X.521 [X.521])
+
+ ( 2.5.6.2 NAME 'country'
+ SUP top
+ STRUCTURAL
+ MUST c
+ MAY ( searchGuide $
+ description ) )
+
+3.3 'dcObject'
+
+ The 'dcObject' object class permits an entry to contains domain
+ component information. This object class is defined as auxiliary,
+ because it will be used in conjunction with an existing structural
+ object class.
+ (Source: RFC 2247 [RFC2247])
+
+ ( 1.3.6.1.4.1.1466.344 NAME 'dcObject'
+ SUP top
+ AUXILIARY
+ MUST dc )
+
+
+
+
+
+
+Sciberras Expires 30 July 2006 [Page 22]
+
+INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
+
+
+3.4 'device'
+
+ The 'device' object class is the basis of an entry which represents
+ an appliance, computer or network element.
+ (Source: X.521 [X.521])
+
+ ( 2.5.6.14 NAME 'device'
+ SUP top
+ STRUCTURAL
+ MUST cn
+ MAY ( serialNumber $
+ seeAlso $
+ owner $
+ ou $
+ o $
+ l $
+ description ) )
+
+3.5 'groupOfNames'
+
+ The 'groupOfNames' object class is the basis of an entry which
+ represents a set of named objects including information related to
+ the purpose or maintenance of the set.
+ (Source: X.521 [X.521])
+
+ ( 2.5.6.9 NAME 'groupOfNames'
+ SUP top
+ STRUCTURAL
+ MUST ( member $
+ cn )
+ MAY ( businessCategory $
+ seeAlso $
+ owner $
+ ou $
+ o $
+ description ) )
+
+3.6 'groupOfUniqueNames'
+
+ The 'groupOfUniqueNames' object class is the same as the
+ 'groupOfNames' object class except that the object names are not
+ repeated or reassigned within a set scope.
+ (Source: X.521 [X.521])
+
+ ( 2.5.6.17 NAME 'groupOfUniqueNames'
+ SUP top
+ STRUCTURAL
+ MUST ( uniqueMember $
+
+
+
+Sciberras Expires 30 July 2006 [Page 23]
+
+INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
+
+
+ cn )
+ MAY ( businessCategory $
+ seeAlso $
+ owner $
+ ou $
+ o $
+ description ) )
+
+3.7 'locality'
+
+ The 'locality' object class is the basis of an entry which represents
+ a place in the physical world.
+ (Source: X.521 [X.521])
+
+ ( 2.5.6.3 NAME 'locality'
+ SUP top
+ STRUCTURAL
+ MAY ( street $
+ seeAlso $
+ searchGuide $
+ st $
+ l $
+ description ) )
+
+3.8 'organization'
+
+ The 'organization' object class is the basis of an entry which
+ represents a structured group of people.
+ (Source: X.521 [X.521])
+
+ ( 2.5.6.4 NAME 'organization'
+ SUP top
+ STRUCTURAL
+ MUST o
+ MAY ( userPassword $ searchGuide $ seeAlso $
+ businessCategory $ x121Address $ registeredAddress $
+ destinationIndicator $ preferredDeliveryMethod $
+ telexNumber $ teletexTerminalIdentifier $
+ telephoneNumber $ internationaliSDNNumber $
+ facsimileTelephoneNumber $ street $ postOfficeBox $
+ postalCode $ postalAddress $ physicalDeliveryOfficeName $
+ st $ l $ description ) )
+
+3.9 'organizationalPerson'
+
+ The 'organizationalPerson' object class is the basis of an entry
+ which represents a person in relation to an organization.
+ (Source: X.521 [X.521])
+
+
+
+Sciberras Expires 30 July 2006 [Page 24]
+
+INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
+
+
+ ( 2.5.6.7 NAME 'organizationalPerson'
+ SUP person
+ STRUCTURAL
+ MAY ( title $ x121Address $ registeredAddress $
+ destinationIndicator $ preferredDeliveryMethod $
+ telexNumber $ teletexTerminalIdentifier $
+ telephoneNumber $ internationaliSDNNumber $
+ facsimileTelephoneNumber $ street $ postOfficeBox $
+ postalCode $ postalAddress $ physicalDeliveryOfficeName $
+ ou $ st $ l ) )
+
+3.10 'organizationalRole'
+
+ The 'organizationalRole' object class is the basis of an entry which
+ represents a job, function or position in an organization.
+ (Source: X.521 [X.521])
+
+ ( 2.5.6.8 NAME 'organizationalRole'
+ SUP top
+ STRUCTURAL
+ MUST cn
+ MAY ( x121Address $ registeredAddress $ destinationIndicator $
+ preferredDeliveryMethod $ telexNumber $
+ teletexTerminalIdentifier $ telephoneNumber $
+ internationaliSDNNumber $ facsimileTelephoneNumber $
+ seeAlso $ roleOccupant $ preferredDeliveryMethod $
+ street $ postOfficeBox $ postalCode $ postalAddress $
+ physicalDeliveryOfficeName $ ou $ st $ l $
+ description ) )
+
+3.11 'organizationalUnit'
+
+ The 'organizationalUnit' object class is the basis of an entry which
+ represents a piece of an organization.
+ (Source: X.521 [X.521])
+
+ ( 2.5.6.5 NAME 'organizationalUnit'
+ SUP top
+ STRUCTURAL
+ MUST ou
+ MAY ( businessCategory $ description $ destinationIndicator $
+ facsimileTelephoneNumber $ internationaliSDNNumber $ l $
+ physicalDeliveryOfficeName $ postalAddress $ postalCode $
+ postOfficeBox $ preferredDeliveryMethod $
+ registeredAddress $ searchGuide $ seeAlso $ st $ street $
+ telephoneNumber $ teletexTerminalIdentifier $
+ telexNumber $ userPassword $ x121Address ) )
+
+
+
+
+Sciberras Expires 30 July 2006 [Page 25]
+
+INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
+
+
+3.12 'person'
+
+ The 'person' object class is the basis of an entry which represents a
+ human being.
+ (Source: X.521 [X.521])
+
+ ( 2.5.6.6 NAME 'person'
+ SUP top
+ STRUCTURAL
+ MUST ( sn $
+ cn )
+ MAY ( userPassword $
+ telephoneNumber $
+ seeAlso $ description ) )
+
+3.13 'residentialPerson'
+
+ The 'residentialPerson' object class is the basis of an entry which
+ includes a person's residence in the representation of the person.
+ (Source: X.521 [X.521])
+
+ ( 2.5.6.10 NAME 'residentialPerson'
+ SUP person
+ STRUCTURAL
+ MUST l
+ MAY ( businessCategory $ x121Address $ registeredAddress $
+ destinationIndicator $ preferredDeliveryMethod $
+ telexNumber $ teletexTerminalIdentifier $
+ telephoneNumber $ internationaliSDNNumber $
+ facsimileTelephoneNumber $ preferredDeliveryMethod $
+ street $ postOfficeBox $ postalCode $ postalAddress $
+ physicalDeliveryOfficeName $ st $ l ) )
+
+3.14 'uidObject'
+
+ The 'uidObject' object class permits an entry to contains user
+ identification information. This object class is defined as
+ auxiliary, because it will be used in conjunction with an existing
+ structural object class.
+ (Source: RFC 2377 [RFC2377])
+
+ ( 1.3.6.1.1.3.1 NAME 'uidObject'
+ SUP top
+ AUXILIARY
+ MUST uid )
+
+
+
+
+
+
+Sciberras Expires 30 July 2006 [Page 26]
+
+INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
+
+
+4. IANA Considerations
+
+ It is requested that the Internet Assigned Numbers Authority (IANA)
+ update the LDAP descriptors registry as indicated in the following
+ template:
+
+ Subject: Request for LDAP Descriptor Registration Update
+ Descriptor (short name): see comment
+ Object Identifier: see comment
+ Person & email address to contact for further information:
+ Andrew Sciberras <andrew.sciberras at eb2bcom.com>
+ Usage: (A = attribute type, O = Object Class) see comment
+ Specification: RFC XXXX [editor's note: The RFC number will be
+ the one assigned to this document.]
+ Author/Change Controller: IESG
+ Comments
+ In the LDAP descriptors registry, the following descriptors (short
+ names) should be updated to refer to RFC XXXX [editor's note: This
+ document]. Names that need to be reserved, rather than assigned to
+ an Object Identifier, will contain an Object Identifier value of
+ RESERVED.
+
+ NAME Type OID
+ ------------------------ ---- ----------------------------
+ applicationProcess O 2.5.6.11
+ businessCategory A 2.5.4.15
+ c A 2.5.4.6
+ cn A 2.5.4.3
+ commonName A 2.5.4.3
+ country O 2.5.6.2
+ countryName A 2.5.4.6
+ DC A 0.9.2342.19200300.100.1.25
+ dcObject O 1.3.6.1.4.1.1466.344
+ description A 2.5.4.13
+ destinationIndicator A 2.5.4.27
+ device O 2.5.6.14
+ distinguishedName A 2.5.4.49
+ dnQualifier A 2.5.4.46
+ domainComponent A 0.9.2342.19200300.100.1.25
+ enhancedSearchGuide A 2.5.4.47
+ facsimileTelephoneNumber A 2.5.4.23
+ generationQualifier A 2.5.4.44
+ givenName A 2.5.4.42
+ GN A RESERVED
+ groupOfNames O 2.5.6.9
+ groupOfUniqueNames O 2.5.6.17
+ houseIdentifier A 2.5.4.51
+ initials A 2.5.4.43
+
+
+
+Sciberras Expires 30 July 2006 [Page 27]
+
+INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
+
+
+ internationalISDNNumber A 2.5.4.25
+ L A 2.5.4.7
+ locality O 2.5.6.3
+ localityName A 2.5.4.7
+ member A 2.5.4.31
+ name A 2.5.4.41
+ o A 2.5.4.10
+ organization O 2.5.6.4
+ organizationName A 2.5.4.10
+ organizationalPerson O 2.5.6.7
+ organizationalRole O 2.5.6.8
+ organizationalUnit O 2.5.6.5
+ organizationalUnitName A 2.5.4.11
+ ou A 2.5.4.11
+ owner A 2.5.4.32
+ person O 2.5.6.6
+ physicalDeliveryOfficeName A 2.5.4.19
+ postalAddress A 2.5.4.16
+ postalCode A 2.5.4.17
+ postOfficeBox A 2.5.4.18
+ preferredDeliveryMethod A 2.5.4.28
+ registeredAddress A 2.5.4.26
+ residentialPerson O 2.5.6.10
+ roleOccupant A 2.5.4.33
+ searchGuide A 2.5.4.14
+ seeAlso A 2.5.4.34
+ serialNumber A 2.5.4.5
+ sn A 2.5.4.4
+ st A 2.5.4.8
+ street A 2.5.4.9
+ surname A 2.5.4.4
+ telephoneNumber A 2.5.4.20
+ teletexTerminalIdentifier A 2.5.4.22
+ telexNumber A 2.5.4.21
+ title A 2.5.4.12
+ uid A 0.9.2342.19200300.100.1.1
+ uidObject O 1.3.6.1.1.3.1
+ uniqueMember A 2.5.4.50
+ userId A 0.9.2342.19200300.100.1.1
+ userPassword A 2.5.4.35
+ x121Address A 2.5.4.24
+ x500UniqueIdentifier A 2.5.4.45
+
+5. Security Considerations
+
+ Attributes of directory entries are used to provide descriptive
+ information about the real-world objects they represent, which can be
+ people, organizations or devices. Most countries have privacy laws
+
+
+
+Sciberras Expires 30 July 2006 [Page 28]
+
+INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
+
+
+ regarding the publication of information about people.
+
+ Transfer of cleartext passwords is strongly discouraged where the
+ underlying transport service cannot guarantee confidentiality and
+ integrity, since this may result in disclosure of the password to
+ unauthorized parties.
+
+ Multiple attribute values for the 'userPassword' attribute need to be
+ used with care. Especially reset/deletion of a password by an admin
+ without knowing the old user password gets tricky or impossible if
+ multiple values for different applications are present.
+
+ Certainly, applications which intend to replace the 'userPassword'
+ value(s) with new value(s) should use modify/replaceValues (or
+ modify/deleteAttribute+addAttribute). Additionally, server
+ implementations are encouraged to provide administrative controls
+ which, if enabled, restrict the 'userPassword' attribute to one
+ value.
+
+ Note that when used for authentication purposes [AuthMeth], the user
+ need only prove knowledge of one of the values, not all of the
+ values.
+
+
+6. Acknowledgements
+
+ The definitions, on which this document is based, have been developed
+ by committees for telecommunications and international standards.
+
+ This document is an update of RFC 2256 by Mark Wahl. RFC 2256 was a
+ product of the IETF ASID Working Group.
+
+ The 'dc' attribute type definition and the 'dcObject' object class
+ definition in this document supersede the specification in RFC 2247
+ by S. Kille, M. Wahl, A. Grimstad, R. Huber, and S. Sataluri.
+
+ The 'uid' attribute type definition in this document supersedes the
+ specification of the 'userid' in RFC 1274 by P. Barker and S. Kille
+ and of the uid in RFC 2798 by M. Smith.
+
+ The 'uidObject' object class definition in this document supersedes
+ the specification of the 'uidObject' in RFC 2377 by A. Grimstad, R.
+ Huber, S. Sataluri and M. Smith.
+
+ This document is based upon input of the IETF LDAPBIS working group.
+ The author wishes to thank S. Legg and K. Zeilenga for their
+ significant contribution to this update. The author would also like
+ to thank Kathy Dally who edited early drafts of this document.
+
+
+
+Sciberras Expires 30 July 2006 [Page 29]
+
+INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
+
+
+7. References
+
+7.1 Normative
+
+ [E.123] Notation for national and international telephone
+ numbers, ITU-T Recommendation E.123, 1988
+
+ [E.164] The international public telecommunication numbering
+ plan, ITU-T Recommendation E.164, 1997
+
+ [F.1] Operational Provisions For The International Public
+ Telegram Service Transmission System, CCITT
+ Recommendation F.1, 1992
+
+ [F.31] Telegram Retransmission System, CCITT Recommendation
+ F.31, 1988
+
+ [ISO3166] ISO 3166, "Codes for the representation of names of
+ countries".
+
+ [Models] K. Zeilenga, "LDAP: The Models", draft-ietf-ldapbis-
+ models-xx (a work in progress)
+
+ [RFC1034] P. Mockapetris, " DOMAIN NAMES - CONCEPTS AND
+ FACILITIES", RFC 1034, January 1987
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", RFC 2119, March 1997
+
+ [RFC3490] Faltstrom P., Hoffman P., Costello A.,
+ "Internationalizing Domain Names in Applications
+ (IDNA)", RFC 3490, March 2003
+
+ [RFC4013] Zeilenga K., "SASLprep: Stringprep profile for User
+ Names and Passwords", RFC 4013, February 2005.
+
+ [RFC4234] Crocker, D., Overell P., "Augmented BNF for Syntax
+ Specifications: ABNF", RFC 4234, October 2005
+
+ [Roadmap] Zeilenga, K., "LDAP: Technical Specification Road
+ Map", draft-ietf-ldapbis-roadmap-xx (a work in
+ progress)
+
+ [Syntaxes] S. Legg (editor), "LDAP: Syntaxes", draft-ietf-ldapbis-
+ syntaxes-xx (a work in progress)
+
+ [X.121] International numbering plan for public data networks,
+ ITU-T Recommendation X.121, 1996
+
+
+
+Sciberras Expires 30 July 2006 [Page 30]
+
+INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
+
+
+ [X.509] The Directory: Authentication Framework, ITU-T
+ Recommendation X.509, 1993
+
+ [X.520] The Directory: Selected Attribute Types, ITU-T
+ Recommendation X.520, 1993
+
+ [X.521] The Directory: Selected Object Classes. ITU-T
+ Recommendation X.521, 1993
+
+7.2 Informative
+
+ [AuthMeth] Harrison R., "LDAP: Authentication Methods and
+ Connection Level Security Mechanisms", draft-ietf-
+ ldapbis-authmeth-xx (a work in progress)
+
+ [LDAP-PKI] Zeilenga, K., "Lightweight Directory Access Protocol
+ (LDAP) schema definitions for X.509 Certificates",
+ draft-zeilenga-ldap-x509-xx (a work in progress)
+
+ [RFC1274] Barker, P., Kille, S.,"The COSINE and Internet X.500
+ Schema", RFC 1274, November 1991
+
+ [RFC2247] Kille, S., Wahl, M., Grimstad, A., Huber, R., and
+ Sataluri, S., "Using Domains in LDAP/X.500
+ Distinguished Names", RFC 2247, January 1998
+
+ [RFC2377] Grimstad, A., Huber, R., Sataluri, S., and Wahl, M.,
+ "Naming Plan for Internet-Enabled Applications", RFC
+ 2377, September 1998.
+
+ [RFC2798] Smith, M., "Definition of the inetOrgPerson LDAP Object
+ Class", RFC 2798, April 2000
+
+ [X.500] ITU-T Recommendations X.500 (1993) | ISO/IEC
+ 9594-1:1994, Information Technology - Open Systems
+ Interconnection - The Directory: Overview of concepts,
+ models and services.
+
+8. Author's Address
+
+ Andrew Sciberras
+ eB2Bcom
+ Suite 3, Woodhouse Corporate Centre,
+ 935 Station Street,
+ Box Hill North, Victoria 3129
+ AUSTRALIA
+
+ Phone: +61 3 9896 7833
+
+
+
+Sciberras Expires 30 July 2006 [Page 31]
+
+INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
+
+
+ Email: andrew.sciberras at eb2bcom.com
+
+9. Intellectual Property Statement
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr at ietf.org.
+
+10. Full Copyright Statement
+
+ Copyright (C) The Internet Society (2006).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+
+
+
+
+
+
+
+Sciberras Expires 30 July 2006 [Page 32]
+
+INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
+
+
+ Appendix A Changes Made Since RFC 2256
+
+ This appendix lists the changes that have been made from RFC 2256 to
+ this I-D.
+
+ This appendix is not a normative part of this specification, which
+ has been provided for informational purposes only.
+
+ 1. Replaced the document title.
+
+ 2. Removed the IESG Note.
+
+ 3. Dependencies on RFC 1274 have been eliminated.
+
+ 4. Added a Security Considerations section and an IANA
+ considerations section.
+
+ 5. Deleted the conformance requirement for subschema object
+ classes in favor of a statement in [Syntaxes].
+
+ 6. Added explanation to attribute types and to each object class.
+
+ 7. Removed Section 4, Syntaxes, and Section 6, Matching Rules,
+ (moved to [Syntaxes]).
+
+ 8. Removed the certificate-related attribute types:
+ authorityRevocationList, cACertificate,
+ certificateRevocationList, crossCertificatePair,
+ deltaRevocationList, supportedAlgorithms, and userCertificate.
+
+ Removed the certificate-related Object Classes:
+ certificationAuthority, certificationAuthority-V2,
+ cRLDistributionPoint, strongAuthenticationUser, and
+ userSecurityInformation
+
+ LDAP PKI is now discussed in [LDAP-CRL] and [LDAP-CERT].
+
+ 9. Removed the dmdName, knowledgeInformation,
+ presentationAddress, protocolInformation, and
+ supportedApplicationContext attribute types and the dmd,
+ applicationEntity, and dSA object classes.
+
+ 10. Deleted the aliasedObjectName and objectClass attribute type
+ definitions. Deleted the alias and top object class
+ definitions. They are included in [Models].
+
+ 11. Added the 'dc' attribute type from RFC 2247.
+
+
+
+
+Sciberras Expires 30 July 2006 [Page 33]
+
+INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
+
+
+ 12. Numerous edititorial changes.
+
+ 13. Removed upper bound after the SYNTAX oid in all attribute
+ definitions where it appeared.
+
+ 14. Added text about Unicode, SASLprep and UTF-8 for userPassword.
+
+ changes since 07:
+
+ 15. Corrected examples in preferredDeliveryMethod, uniqueMember,
+ postalAddress, and registeredAddress attribute types.
+
+ 16. Clarified and corrected examples in owner and roleOccupant
+ attribute types.
+
+ 17. Added RFC 2234 to normative references.
+
+ 18. Added RFC 1274 and RFC 2798 to informative references.
+
+ 19. Removed the statement about RFC 2026 conformance.
+
+ 20. Added the IPR Disclosure and Notice
+
+ 21. Updated the Copyright text.
+
+ changes since 08:
+
+ 22. Included RFC 2377 into Updates header and Informative
+ References
+
+ 23. Changed Editor information to Andrew Sciberras.
+
+ 24. Updated I-D Template information.
+
+ 25. References made consistent with other LDAPbis ID's. [ROADMAP]
+ -> [RoadMap] and [AUTHMETH] -> [AuthMeth].
+
+ 26. Changed Introduction to include an (LDAP) acronym after the
+ first usage.
+
+ 27. Renamed section 1.1 to "Relationship with other
+ specifications" from "Situation".
+
+ 28. Included definitions, comments and references for 'dcObject'
+ and 'uidObject'.
+
+ 29. Replaced PKI schema references to use draft-zeilenga-ldap-
+ x509-xx
+
+
+
+Sciberras Expires 30 July 2006 [Page 34]
+
+INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
+
+
+ 30. Spelt out and referenced ABNF on first usage.
+
+ 31. Removed Section 2.4 (Source). Replaced the source table with
+ explicit references for each definition.
+
+ 32. All references to an attribute type or object class are
+ enclosed in single quotes.
+
+ 33. The layout of attribute type definitions has been changed to
+ provide consistency throughout the document:
+ > Section Heading
+ > Description of Attribute type
+ > Multivalued description
+ > Source Information
+ > Definition
+ > Example
+ > Additional Comments
+
+ Adding this consistent output included the addition of
+ examples to some definitions.
+
+ 34. References to alternate names for attributes types are
+ provided with a reference to where they were originally
+ specified.
+
+ 35. Clarification of the description of 'distinguishedName' and
+ 'name', in regards to these attribute types being supertypes.
+
+ 36. Spelt out ISDN on first usage.
+
+ 37. Inserted a reference to [Syntaxes] for the
+ 'teletexTerminalIdentifier' definition's SYNTAX OID.
+
+ 38. Additional names were added to the IANA Considerations. Names
+ include 'commonName', 'dcObject', 'domainComponent', 'GN',
+ 'localityName', 'organizationName', 'organizationUnitName',
+ 'surname', 'uidObject' and 'userid'.
+
+ 39. Renamed all instances of supercede to supersede.
+
+ 40. Moved [F.1], [F.30] and [SASLprep] from informative to
+ normative references.
+
+ 41. Changed the 'c' definition to be consistent with X.500.
+
+ 42. Added text to 'dc', making the distinction between 'stored'
+ and 'query' values when preparing IDN strings.
+
+
+
+
+Sciberras Expires 30 July 2006 [Page 35]
+
Added: openldap/vendor/openldap-release/doc/drafts/draft-ietf-ldapext-acl-model-xx.txt
===================================================================
--- openldap/vendor/openldap-release/doc/drafts/draft-ietf-ldapext-acl-model-xx.txt (rev 0)
+++ openldap/vendor/openldap-release/doc/drafts/draft-ietf-ldapext-acl-model-xx.txt 2007-09-15 10:38:52 UTC (rev 844)
@@ -0,0 +1,2886 @@
+
+
+
+
+
+
+
+Internet-Draft E. Stokes
+LDAP Extensions WG B. Blakley
+Intended Category: Standards Track Tivoli Systems
+Expires: 14 January 2001 D. Rinkevich
+ IBM
+ R. Byrne
+ Sun Microsystems
+ 14 July 2000
+
+ Access Control Model for LDAPv3
+ <draft-ietf-ldapext-acl-model-06.txt>
+
+STATUS OF THIS MEMO
+
+This document is an Internet-Draft and is in full
+conformance with all provisions of Section 10 of RFC2026.
+
+Internet-Drafts are working documents of the Internet
+Engineering Task Force (IETF), its areas, and its working
+groups. Note that other groups may also distribute working
+documents as Internet-Drafts. Internet-Drafts are draft
+documents valid for a maximum of six months and may be
+updated, replaced, or obsoleted by other documents at any
+time. It is inappropriate to use Internet-Drafts as
+reference material or to cite them other than as "work in
+progress."
+
+The list of current Internet-Drafts can be accessed at
+http://www.ietf.org/ietf/1id-abstracts.txt
+
+The list of Internet-Draft Shadow Directories can be
+accessed at http://www.ietf.org/shadow.html.
+
+Comments and suggestions on this document are encouraged.
+Comments on this document should be sent to the LDAPEXT
+working group discussion list:
+
+ ietf-ldapext at netscape.com
+
+COPYRIGHT NOTICE
+
+Copyright (C) The Internet Society (2000). All Rights
+Reserved.
+
+ABSTRACT
+
+This document describes the access control model for the
+Lightweight Directory Application Protocol V3 (LDAPv3)
+directory service. It includes a description of the model,
+the LDAP controls, and the extended operations to the LDAP
+protocol. The current LDAP APIs are sufficient for most
+
+
+
+Stokes, et al Expires 14 January 2001 [Page 1]
+
+
+
+
+
+Internet-Draft Access Control Model 14 July 2000
+
+
+
+access control operations. An API (in a separate document)
+is needed for the extended operation getEffectiveAccess. A
+separate requirements document for access control exists
+[REQTS]. The access control model used the requirements
+documents as a guideline for the development of this
+specification and are reflected in this specification to the
+extent that the working group could agree on an access
+control model.
+
+
+The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
+"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", and
+"MAY" used in this document are to be interpreted as
+described in [Bradner97].
+
+
+
+1. Introduction
+
+The ability to securely access (replicate and distribute)
+directory information throughout the network is necessary
+for successful deployment. LDAP's acceptance as an access
+protocol for directory information is driving the need to
+provide an access control model definition for LDAP
+directory content among servers within an enterprise and the
+Internet. Currently LDAP does not define an access control
+model, but one is needed to ensure consistent secure access,
+replication, and management across heterogeneous LDAP
+implementations. The major objective is to provide a simple,
+usable, and implementable, but secure and efficient access
+control model for LDAP while also providing the appropriate
+flexibility to meet the needs of both the Internet and
+enterprise environments and policies. This document defines
+the model and the protocol extensions (controls and extended
+operations).
+
+This draft does not (and cannot) fully specify the behavior
+of the Access Control Model in a distributed environment
+(e.g. propagating access control information across servers
+and ACI administration) because there is no LDAP standard
+defining how to distribute directory data between LDAP
+servers. The behavior of the Access Control Model in
+distributed environments is beyond the scope of this draft.
+
+
+
+2. The LDAPv3 Access Control Model
+
+Access Control mechanisms evaluate requests for access to
+protected resources and make decisions about whether those
+requests should be granted or denied. In order to make a
+
+
+
+Stokes, et al Expires 14 January 2001 [Page 2]
+
+
+
+
+
+Internet-Draft Access Control Model 14 July 2000
+
+
+
+grant/deny decision about a request for access to a
+protected resource, an access control mechanism needs to
+evaluate policy data. This policy data describes security-
+relevant characteristics of the requesting subject and the
+rules which govern the use of the target object.
+
+No mechanism is defined in this document for storage of
+access control information at the server beyond indicating
+that the attribute holding access control information is an
+operational attribute.
+
+The access control mechanisms specified in this document are
+neutral with respect to policy inheritance mechanisms,
+explicit vs. implicit denial, and group nesting.
+
+The access control model defines
+
+ - What flows on the wire for interoperability
+
+ The existing LDAP protocol flows for ldap operations
+ are used to manipulate access control information. A
+ set of permissions and their semantics with respect to
+ ldap operations is defined. The permissions parallel
+ the types of ldap operations defined. What is
+ transmitted is exactly what is read back. Encoding of
+ access control information on the wire is per the
+ LDAPv3 specifications.
+
+ There is an additional LDAP control and extended
+ protocol operation defined, getEffectiveRights. LDAP
+ clients use the control and extended operation to
+ manage and administer access control policy enforced by
+ LDAP servers.
+
+ Servers may store access control information in any way
+ they choose. In particular, servers may use the access
+ control mechanisms of their datastores to store and
+ enforce LDAP access control, or they may implement
+ access control managers external to their datastores.
+ Datastores and external access control managers MAY
+ implement any access control rule syntax and semantics
+ they choose, but the semantics MUST be compatible with
+ those defined in the section titled "Operational
+ Semantics of Access Control Operations".
+
+ - Attributes and classes for application portability of
+ access control information
+
+ An access control information attribute (ldapACI) for
+ application portability: This attribute is used as
+ input to the LDAP APIs so access control information
+
+
+
+Stokes, et al Expires 14 January 2001 [Page 3]
+
+
+
+
+
+Internet-Draft Access Control Model 14 July 2000
+
+
+
+ can be addressed uniformly independent of how that
+ information is addressed and stored at the server.
+ This same attribute appears in LDIF output for
+ interchange of access control information.
+
+ An access control information subentry class
+ (ldapACISubEntry) and a set of attributes
+ (supportedAccessControlSchemes which is used in the
+ rootDSE and accessControlSchemes which is used in the
+ subentry ldapACISubEntry) to identity the access
+ control mechanisms supported by a server and in a given
+ part of the namespace, respectively.
+
+ - An attribute in the rootDSE, discloseOnError, to
+ control whether it is permissible for the server to
+ return the name of an entry or attribute in an error
+ (or empty set) operation result. This closes a hole on
+ the ability to discover information you are not
+ authorized to discover.
+
+ - A mechanism to control access to access control
+ information: The access control information attribute,
+ ldapACI, is used to control access to access control
+ information (controls access to itself). How to get an
+ initial ldapACI in the directory is server specific and
+ beyond the scope of this model.
+
+Servers can support multiple access control mechanisms, but
+MUST be capable of supporting the LDAP Mechanism in the DIT
+scoped by the rootDSE (entire server's DIT) for that server
+and SHOULD be capable of supporting the LDAP mechanism in an
+arbitrary part (subtree) of the DIT.
+
+The accessControlSchemes attribute in the ldapACISubEntry
+indicates which access control mechanism is in effect for
+the scope of that ldapACISubEntry. The
+supportedAccessControlSchemes attribute in the rootDSE
+indicates which acess control mechanisms are supported by
+the server; those mechanisms are in effect in that server's
+DIT unless overridden by a mechanism defined in a
+ldapACISubEntry elsewhere in that DIT.
+
+Changing the value(s) of either the
+supportedAccessControlSchemes or accessControlSchemes
+attributes changes the mechanism(s) in effect for the scope
+of those attributes (where scope is either that of the
+rootDSE or ldapACISubEntry).
+
+Through the use of the mechanism rootDSE attribute and
+ldapACI subentry, it is possible to run multiple mechanisms
+in either the same subtree or separate subtrees. If two
+
+
+
+Stokes, et al Expires 14 January 2001 [Page 4]
+
+
+
+
+
+Internet-Draft Access Control Model 14 July 2000
+
+
+
+mechanisms are run in the same subtree, it is desirable that
+the result be the same independent of mechanism, but
+definition and discussion of this is beyond the scope of
+this model.
+
+
+
+3. Access Control Mechanism Attributes
+
+Two attributes are defined to identify which access control
+mechanisms are supported by a given server and by a given
+subtree: supportedAccessControlSchemes and
+accessControlSchemes. (We chose these names based on the
+X.500 attribute, AccessControlScheme which is single-valued
+and defined in X.501).
+
+
+3.1 Root DSE Attribute for Access Control Mechanism
+
+The server advertises which access control mechanisms it
+supports by inclusion of the 'supportedAccessControlSchemes'
+attribute in the root DSE. This attribute is a list of
+OIDs, each of which identify an access control mechanism
+supported by the server. By default, these are also the
+mechanisms in effect in subtrees beneath the root in that
+server unless overridden by a ldapACISubEntry (see section
+"Subentry Class Access Control Mechanism").
+
+ (<OID to be assigned>
+ NAME 'supportedAccessControlSchemes'
+ DESC list of access control mechanisms supported
+ by this directory server
+ SYNTAX LDAPOID
+ USAGE dSAOperation
+ )
+
+The access control mechanism defined is:
+ LDAPv3 <OID to be assigned>
+
+Other vendor access control mechanisms MAY be defined (by
+OID) and are the responsibility of those vendors to provide
+the definition and OID.
+
+
+3.2 Root DSE Attribute for Control of Disclosing Errors
+
+The server specifies whether it is permissible for the name
+of an entry or attribute to be disclosed in an error (or
+empty) operation result. This rootDSE attribute is
+discloseOnError. The default for discloseOnError is false
+(0) or not to disclose on error. The lack of this attribute
+
+
+
+Stokes, et al Expires 14 January 2001 [Page 5]
+
+
+
+
+
+Internet-Draft Access Control Model 14 July 2000
+
+
+
+in the rootDSE is interpreted as the default.
+
+ (<OID to be assigned>
+ NAME 'discloseOnError'
+ DESC specify whether to return the name of an
+ entry or attribute in an error (or
+ empty) operation result; 0=do not
+ disclose (default); 1=disclose
+ SYNTAX LDAPString
+ USAGE dSAOperation
+
+
+3.3 Subentry Class Access Control Mechanism
+
+A given naming context MUST provide information about which
+access control mechanisms are in effect for that portion of
+the namespace. This information is contained in a subentry
+(ldapACISubEntry class), derived from [SUBENTRY].
+ldapACISubEntry MAY be used to define the scope of an access
+control mechanism. The value(s) held in the rootDSE
+attribute, supportedAccessControlSchemes, are the mechanisms
+in effect in subtrees beneath the root in that server unless
+overridden in a ldapACISubEntry further down the tree held
+by that server. The scope of that ldapACISubEntry is to the
+end of the subtree held by that server or until another
+ldapACISubEntry is encountered in that subtree held by that
+server. The ldapACISubEntry class is defined as:
+
+
+ ( <OID to be assigned>
+ NAME 'ldapACISubEntry'
+ DESC 'LDAP ACI Subentry class'
+ SUP ldapSubEntry STRUCTURAL
+ MUST ( accessControlSchemes )
+ )
+
+The accessControlSchemes attribute MUST be in each ldap
+access control subentry entry associated with a naming
+context whose access control mechanism is different from
+adjacent naming contexts supported by that directory server.
+accessControlSchemes lists the values (list of OIDs) that
+define the access control mechanisms in effect for the scope
+of that ldap access control subentry. Although, in general,
+this attribute will define only a single mechanism (single
+value), more than one mechanism MAY be in effect for the
+scope of that subentry.
+
+ (<OID to be assigned>
+ NAME 'accessControlSchemes'
+ DESC list of access control mechanisms supported
+ in this subtree
+
+
+
+Stokes, et al Expires 14 January 2001 [Page 6]
+
+
+
+
+
+Internet-Draft Access Control Model 14 July 2000
+
+
+
+ SYNTAX LDAPOID
+ USAGE dSAOperation
+ )
+
+
+
+4. The Access Control Information Attribute (ldapACI)
+
+The access control information attribute, ldapACI, is
+defined as:
+
+ (<OID to be assigned>
+ NAME 'ldapACI'
+ DESC 'ldap access control information'
+ EQUALITY caseIgnoreMatch
+ SYNTAX directoryString
+ USAGE directoryOperation
+ )
+
+The intent of the attribute definition is to design a common
+interchange format. Any given LDAP server should be able to
+translate the below defined attribute into meaningful
+operation requests. Each server should be able to understand
+the attribute; there should not be any ambiguity into what
+any part of the syntax means.
+
+While the end goal is to have a common behavior model
+between different LDAP server implementations, the attribute
+definition alone will not ensure identical ACL processing
+behavior between servers. The semantics of how a server
+interprets the ACI syntax are defined in the "Operational
+Semantics of Access Control" section of this document.
+Additionally, while the server must recognize and act on the
+attribute when received over the wire, there are no
+requirements for the server to physically store this
+attribute.
+
+The attribute definition maintains an assumption that the
+receiving server supports inheritance within the security
+model. If the server does not support inheritance, the
+receiving server must expand any inherited information based
+on the scope flag. If the server does not support partial
+inheritance and both the entry and subtree scope are used,
+then entry is the prevailing scope. (It is possible for two
+values in the ldapACI attribute to have different scopes
+given the syntax of ldapACI; one might contain 'entry' and
+another might contain 'subtree'. This implies that some
+ldapACI values inherit down the DIT and othersdo not - hence
+partial inheritance of the ldapACI attribute.)
+
+The attribute is defined so access control information (ACI)
+
+
+
+Stokes, et al Expires 14 January 2001 [Page 7]
+
+
+
+
+
+Internet-Draft Access Control Model 14 July 2000
+
+
+
+can be addressed in a server independent of server
+implementation. This attribute is used in typical LDAP APIs
+and in LDIF output of ACI. This attribute may be queried or
+set on all directory objects. The BNF and definitions are
+given below.
+
+
+4.1 The BNF
+
+
+4.1.1 ACI String Representation
+
+ Values of this syntax are encoded according to the
+ following BNF which follows the BNF encoding
+ conventions described in [ABNF]:
+
+ ldapACI = scope "#" rights "#" attr "#" subject
+
+ scope = "entry" / "subtree"
+
+ rights = (("grant:" / "deny:") permissions) /
+ ("grant:" permissions ";deny:" permissions)
+
+ permissions = [permission *("," permission)]
+
+ permission = "a" / ; add
+ "d" / ; delete
+ "e" / ; export
+ "i" / ; import
+ "n" / ; renameDN
+ "b" / ; browseDN
+ "t" / ; returnDN
+ "r" / ; read
+ "s" / ; search
+ "w" / ; write (mod-add)
+ "o" / ; obliterate (mod-del)
+ "c" / ; compare
+ "m" / ; make
+
+ attr = "[all]" / "[entry]" / (attribute *("," attribute))
+
+ attribute = ; OID syntax (1.3.6.1.4.1.1466.115.121.1.38)
+ ; from [ATTR]
+
+ subject = ["authnLevel:" authnLevel ":"]
+ (("authzID-" authzID) /
+ ("role:" dn) /
+ ("group:" dn) /
+ ("subtree:" dn) /
+ ("ipAddress:" ipAddress) /
+ "public:" /
+
+
+
+Stokes, et al Expires 14 January 2001 [Page 8]
+
+
+
+
+
+Internet-Draft Access Control Model 14 July 2000
+
+
+
+ "this:")
+
+ authnLevel = "any" /
+ "simple" /
+ sasl
+
+ sasl = "sasl:"
+ ("any" /
+ mechanism)
+
+ mechanism = ; sasl mechanism from 4.2 of [LDAPv3]
+
+ authzID = ; authzID from [AuthMeth] repeated below
+ ; for convenience
+
+ authzId = dnAuthzId / uAuthzId
+
+ ; distinguished-name-based authz id.
+ dnAuthzId = "dn:" dn
+
+ dn = utf8string ; with syntax defined in [UTF]
+
+ ; unspecified userid, UTF-8 encoded.
+ uAuthzId = "u:" userid
+ userid = utf8string ; syntax unspecified
+
+ ipAddress = printableString
+ ; dotted decimal form (e.g. 10.0.0.6)
+ ; or use wildcards such as 12.3.45.* to
+ ; specify a specific subnetwork
+ ; or 123.45.6.*+255.255.255.115 to
+ ; specify a subnetmask
+ ; or use a wildcard domain name such as
+ ; *.airius.com to specify a specific
+ ; DNS domain
+
+ printableString ; printableString syntax from [ATTR]
+
+
+Note that the colon following the "public" and "this"
+subject options exist only to simplify string parsing.
+
+Note also that per [AuthMeth], authzID may be expanded in
+the future.
+
+See section titled 'ACI Examples' for examples of the string
+representation.
+
+
+
+
+
+
+
+Stokes, et al Expires 14 January 2001 [Page 9]
+
+
+
+
+
+Internet-Draft Access Control Model 14 July 2000
+
+
+
+4.1.2 ACI Binary Representation
+
+ The following ASN.1 data type is used to represent this
+ syntax when transferred in binary form:
+
+ ldapACI ::= SEQUENCE {
+ scope ENUMERATED {
+ entry (0),
+ subtree (1) },
+ rights SEQUENCE OF CHOICE {
+ grant [0] Permissions,
+ deny [1] Permissions },
+ attr CHOICE {
+ all [0] NULL,
+ entry [1] NULL,
+ attributes [2] SEQUENCE OF Attribute },
+ subject SEQUENCE {
+ authnLevel CHOICE {
+ any [0] NULL,
+ simple [1] NULL,
+ sasl [2] CHOICE {
+ any [0] NULL,
+ mechanism [1] LDAPString -- from [LDAPv3]
+ }
+ },
+ subject CHOICE {
+ dn [0] DN,
+ user [1] utf8String
+ role [1] DN,
+ group [2] DN,
+ subtree [3] DN,
+ ipAddress [4] IPAddress,
+ public [6] NULL,
+ this [7] NULL }, } -- may be expanded
+ per [AuthMeth]
+
+ Permissions ::= SEQUENCE OF ENUMERATED {
+ add (0),
+ delete (1),
+ export (2),
+ import (3),
+ renameDN (4),
+ browseDN (5),
+ returnDN (6),
+ read (7),
+ search (8),
+ write (9),
+ obliterate (10),
+ compare (11),
+ make (12) }
+
+
+
+
+Stokes, et al Expires 14 January 2001 [Page 10]
+
+
+
+
+
+Internet-Draft Access Control Model 14 July 2000
+
+
+
+ Attribute ::= AttributeType -- from [LDAPv3]
+
+ IPAddress ::= PrintableString -- (e.g. 10.0.0.6)
+
+
+
+4.2 The Components of ldapACI Attribute
+
+This section defines components that comprise the access
+control information attribute, ldapACI.
+
+
+4.2.1 Scope
+
+Two scopes for access control information are defined:
+
+ - entry - the access control information in the ldapACI
+ attribute applies only to the entry in which it is
+ contained
+
+ - subtree - the access control information in the ldapACI
+ attribute applies to each entry down the subtree unless
+ it is overridden by an entry-specific ldapACI whose
+ values are more specific.
+
+Use of prescriptive ACIs and scoping via use of a
+ldapACISubEntry is outside the scope of this document.
+
+
+4.2.2 Access Rights and Permissions
+
+Access rights can apply to an entire object or to attributes
+of the object. Access can be granted or denied. Either or
+both of the actions "grant" | "deny" may be used when
+creating or updating ldapACI.
+
+Each of the LDAP access permissions are discrete. One
+permission does not imply another permission. The
+permissions which apply to attributes and the entry parallel
+the type of ldap operations that can be performed.
+
+Permissions which apply to attributes:
+
+ r Read Read attribute values
+ w Write Modify-add values
+ o Obliterate Modify-delete values
+ s Search Search entries with specified attributes
+ c Compare Compare attributes
+ m Make Make attributes on a new entry below
+ this entry
+
+
+
+
+Stokes, et al Expires 14 January 2001 [Page 11]
+
+
+
+
+
+Internet-Draft Access Control Model 14 July 2000
+
+
+
+ 1. r Read
+
+ If granted, permits attributes and values to be
+ returned in a read or search operation.
+
+ 2. w Write
+
+ If granted, permits attributes and values to be added
+ in a modify operation.
+
+ 3. o Obliterate
+
+ If granted, permits attributes and values to be
+ deleted in a modify operation.
+
+ 4. s Search
+
+ If granted, permits attributes and values to be
+ included in a search operation.
+
+ 5. c Compare
+
+ If granted, permites attributes and value to be used
+ in a compare operation.
+
+ 6. m Make
+
+ The attribute permission "m" is required for all
+ attributes that are placed on an object when it is
+ created. Just as the "w" and "o" permissions are used
+ in the Modify operation, the "m" permission is used in
+ the Add operation. Additionally, note that "w" and "o"
+ have no bearing on the Add operation and "m" has no
+ bearing on the Modify operation. Since a new object
+ does not yet exist, the "a" and "m" permissions needed
+ to create it must be granted on the new object's
+ parent. This differs from "w" and "o" which must be
+ granted on the object being modified. The "m"
+ permission is distinct and separate from the "w" and
+ "o" permissions so that there is no conflict between
+ the permissions needed to add new children to an entry
+ and the permissions needed to modify existing children
+ of the same entry.
+
+Note: Modify-replace values of an attribute requires "w"
+and "o" permission.
+
+Permissions that apply to an entire entry:
+
+
+ a Add Add an entry below this entry
+
+
+
+Stokes, et al Expires 14 January 2001 [Page 12]
+
+
+
+
+
+Internet-Draft Access Control Model 14 July 2000
+
+
+
+ d Delete Delete this entry
+ e Export Export entry & subordinates to new
+ location
+ i Import Import entry & subordinates from some
+ location
+ n RenameDN Rename an entry's DN
+ b BrowseDN Browse an entry's DN
+ t ReturnDN Allows DN of entry to be disclosed in
+ an operation result
+
+
+ 1. a Add
+
+ If granted, permits creation of an entry in the DIT
+ subject to control on all attributes and values to be
+ placed in the new entry at time of creation. In order
+ to add an entry, permission must also be granted to
+ add at least the mandatory attributes.
+
+ 2. d Delete
+
+ If granted, permits the entry to be removed from the
+ DIT regardless of controls on attributes within the
+ entry.
+
+ 3. e Export
+
+ If granted, permits an entry and its subordinates (if
+ any) to be exported; that is, removed from the current
+ location and placed in a new location subject to the
+ granting of suitable permission at the destination.
+ If the last RDN is changed, Rename is also required at
+ the current location. In order to export an entry or
+ its subordinates, there are no prerequisite
+ permissions to contained attributed, including the RDN
+ attributes; this is true even when the operation
+ causes new attribute values to be added or removed as
+ the result of the changes of RDN.
+
+ 4. i Import
+
+ If granted, permits an entry and its suordinates (if
+ any) to be imported; that is, removed from some other
+ location and placed a t the location to which the
+ permission applies subject to the granting of suitable
+ permissions at the source location. In order to
+ import an entry or its subordinates, there are no
+ prerequisite permissions to contained attributed,
+ including the RDN attributes; this is true even when
+ the operation causes new attribute values to be added
+ or removed as the result of the changes of RDN.
+
+
+
+Stokes, et al Expires 14 January 2001 [Page 13]
+
+
+
+
+
+Internet-Draft Access Control Model 14 July 2000
+
+
+
+ 5. n RenameDN
+
+ Granting Rename is necessary for an entry to be
+ renamed with a new RDN, taking into account
+ consequential changes to the distinguished names of
+ subordinate entries, if any; if the name of the
+ superior is unchanged, the grant is sufficient. In
+ order to rename an entry, there are no prerequisite
+ permissions to contained attributed, including the RDN
+ attributes; this is true even when the operation
+ causes new attribute values to be added or removed as
+ the result of the changes of RDN.
+
+ 6. b BrowseDN
+
+ If granted, permits entries to be accessed using
+ directory operations which do not explicitly provide
+ the name of the entry.
+
+ 7. t ReturnDN
+
+ If granted, allows the distinguished name of the entry
+ to be disclosed in the operation result.
+
+All permissions (for grant and deny) for an attribute/entry
+and a given subject MUST be contained within one ldapACI
+value, i.e. (in abbreviated form)
+
+ ldapACI: ...grant OID.attr1 subjectA
+ ldapACI: ...deny OID.attr1 subjectA
+
+must be ldapACI: ...grant ... deny... OID.attr1 subjectA
+
+Using the defined BNF it is possible for the permission
+string to be empty. The ACI
+
+ ldapACI: subtree#grant#OID.attr1#group:cn=Dept XYZ,c=US
+
+ ldapACI: subtree#grant:r,s#[all]#group:cn=Dept XYZ,c=US
+
+means that this group (Dept XYZ) is granted permission to
+read and search all attributes except OID.attr1 because
+OID.attr1 is more specific than "[all]".
+
+
+4.2.3 Attributes
+
+Attribute describes an attribute name in the form of a
+dotted decimal OID for that <attr>. If the string (OID)
+refers to an attribute not defined in the given server's
+schema, the server SHOULD report an error. "[entry]" means
+
+
+
+Stokes, et al Expires 14 January 2001 [Page 14]
+
+
+
+
+
+Internet-Draft Access Control Model 14 July 2000
+
+
+
+the permissions apply to the entire object. This could mean
+actions such as delete the object, or add a child object.
+"[all]" means the permission set apply to all attributes of
+the entry.
+
+If the keyword "[all]" and another attribute are both
+specified within an ACI, the more specific permission set
+for the attribute overrides the less specific permission set
+for "[all]".
+
+
+4.2.4 Subjects and Associated Authentication
+
+The following subjects are defined and MUST be supported:
+
+ - authzID, defined per [authmeth]
+
+ - group, defined as the distinguished name of a
+ groupOfNames or groupOfUniqueNames entry
+
+ - role
+
+ - subtree, defined as the distinguished name of a non-
+ leaf node in the DIT
+
+ - ipAddress,
+
+ - public, defined as public access
+
+ - this, defined as the user whose name matches that of
+ the entry being accessed
+
+Other parties MAY define other subjects. It is the
+responsibility of those parties to provide the definition.
+
+A subject may be qualified by the type of authentication
+required for access to a given attribute(s) or entry. If no
+authnLevel is present, then no specific type of
+authentication is additionally required for access. If
+authnLevel is specified, then that type of authentication is
+additionally required for access. The authnLevels parallel
+the authentication mechanisms specified for LDAPv3: simple,
+SASL (any type of SASL mechanism), and a SASL-specific
+mechanism. The authnLevel of is not an acceptable mechanism
+for this case) as part of obtaining access.
+
+
+4.3 Grant/Deny Evaluation Rules
+
+The decision whether to grant or deny a client access to a
+particular piece of information is based on several pieces
+
+
+
+Stokes, et al Expires 14 January 2001 [Page 15]
+
+
+
+
+
+Internet-Draft Access Control Model 14 July 2000
+
+
+
+of information found within the ldapaci value. Throughout
+the decision making process, there are guiding principals.
+
+ - Specificity: More specific policies MUST override less
+ specific ones (e.g. individual user entry in ACI takes
+ precedence over group entry).
+
+ - Deny takes precedence over Grant.
+
+ - When there are conflicting ACI values, deny takes
+ precedence over grant.
+
+ - Deny is the default when there is no access control
+ information.
+
+Precendence of Scope Types (highest to lowest)
+
+ - entry
+
+ - subtree
+
+Precedence of Subjects within a Scope (highest to lowest):
+
+ - ipAddress
+
+ - authzID, this
+
+ - group, role, this, public
+
+ - subtree, public
+
+Although other types MAY be defined given the BNF, use of
+the well-known types aids in interoperability and
+operational consistency.
+
+Access Decision algorithm:
+
+ 1. Determine all the ldapACI values which could apply to
+ the target DN which is being accessed. This is the DN
+ of the entry which is being queried in a search,
+ modified, deleted, etc. When determining all the
+ ldapACI values, the scope field should be used. All
+ ldapACI values with a scope of 'entry' take precedence
+ over ldapACI values with a scope of 'subtree'.
+
+ 2. Determine which ldapACI (of the set determined in step
+ 1) apply to the bound DN. This is determined by
+ looking at the subject (combination of subject type
+ and subject value) and bind type. If no bind is in
+ effect (this is possible in ldapv3), then treat this
+ lack of bind as if bound as anonymous. Start with the
+
+
+
+Stokes, et al Expires 14 January 2001 [Page 16]
+
+
+
+
+
+Internet-Draft Access Control Model 14 July 2000
+
+
+
+ most specific subject type. If at any time, at least
+ one ldapACI value exists for a specificity level, then
+ processing stops; the exception here is 'this' because
+ this may also be combined with group to use power of
+ 'this'. Evaluation should take place on set of
+ ldapACI values which are all of the same specificity
+ level. Subjects of the same precedence are combined
+ using union semantics.
+
+ 3. Evaluate the remaining ldapACI values and determine a
+ grant/deny decision. If conflicting ldapACI value
+ exists for the same attribute, or attributes (i.e. one
+ ldapACI grants permission and another denies
+ permission), then deny takes precedence over grant.
+ For example, if one is granted permission to
+ "objectclass" in one ldapACI value by being a member
+ of group cn=Admin, and denied permission by being a
+ member of cn = NontrustedAdmins, then the bound user
+ would not receive permission to objectclass.
+
+ The rule of specificity also applies to the
+ attributes. If one is denied permission to "[ all ]"
+ attributes, but granted permission to "objectclass"
+ then the more specific value of "objectclass" takes
+ precedence over the less specific value of "[ all ] ".
+ In this case the user would be granted permission to
+ "objectclass" but denied permission to all other
+ attributes.
+
+
+
+5. Required Permissions for each LDAP Operation
+
+This section defines the required permissions for each LDAP
+operation but even if these requirements are satisfied the
+server MAY refuse to carry out the operation due to other
+implementation specific security considerations. For
+example, a server may refuse to modify an entry because the
+database where that entry resides is in read only mode.
+Another example might be that although the access control is
+available to the userPassword attribute a server may refuse
+modifications due to some server specific policy governing
+access to passwords.
+
+Here, we specify the rights required by a user when
+performing an LDAP operation in terms of the LDAP
+permissions specified in section 6.1. Recall that "a, d,
+e, i, n, b,t" are permissions that apply to entries as a
+whole while permissions "r, s, w, o, c, m" apply to
+attributes within entries.
+
+
+
+
+Stokes, et al Expires 14 January 2001 [Page 17]
+
+
+
+
+
+Internet-Draft Access Control Model 14 July 2000
+
+
+
+Required permissions for LDAP extended operations and LDAP
+controls are beyond the scope of this draft.
+
+There is a requirement that a user should not be able to
+infer the existence of data in the Directory, if the user
+does not have the required access rights to that data. An
+example of this requirement would be in a hosting
+environment where you would not want any users from the coke
+subtree to be able to even discover that the pepsi tree was
+hosted on the same server. This "discloseOnError" feature
+will be set once for server in the rootDSE advertised by the
+attribute discloseOnError. The default for discloseOnError
+is false (0). The lack of this attribute in the rootDSE is
+interpreted as the default. The details of its effects are
+addressed below, operation by operation.
+
+For the following, assume that the authorization identity of
+the user doing the operation is authzID.
+
+
+5.1 Bind Operation
+
+This draft does not require any permissions to allow a bind
+operation to proceed.
+
+
+5.2 Search Operation
+
+Recall that the parameters of the Search operation per RFC
+2251 [LDAPv3] Section 4.5 are:
+
+ SearchRequest ::= [APPLICATION 3] SEQUENCE {
+ baseObject LDAPDN,
+ scope ENUMERATED {
+ baseObject (0),
+ singleLevel (1),
+ wholeSubtree (2) },
+ derefAliases ENUMERATED {
+ neverDerefAliases (0),
+ derefInSearching (1),
+ derefFindingBaseObj (2),
+ derefAlways (3) },
+ sizeLimit INTEGER (0 .. maxInt),
+ timeLimit INTEGER (0 .. maxInt),
+ typesOnly BOOLEAN,
+ filter Filter,
+ attributes AttributeDescriptionList }
+
+Suppose a server is processing a search request from user
+authzID with parameters as above and is processing the entry
+with dn candidateDN to decide if it may be returned or not.
+
+
+
+Stokes, et al Expires 14 January 2001 [Page 18]
+
+
+
+
+
+Internet-Draft Access Control Model 14 July 2000
+
+
+
+Then the permissions required by authzID that need to be
+evaluated are as follows:
+
+
+ 1. permission "b" to the entry candidateDN
+
+ If this permission is not granted then the dn
+ candidateDN MUST not be returned nor any attribute
+ type nor attribute value from this entry.
+
+ If this permission is granted then the dn candidateDN
+ MAY be returned.
+
+ Note: The idea of the "b" permission is to say "a user
+ has discovery rights" at a certain entry in the
+ directory. Assuming that the further required
+ permissions below are satisfied then having "b" right
+ is enough to allow the server to return candidateDN.
+ Of course candidateDN contains in it's components,
+ attributes and attribute values for all the ancestors
+ of candidateDN. This can lead to the slightly odd
+ situation that we can discover the naming attribute of
+ an entry and that attribute's value by virtue of
+ having the required searching permissions to it's
+ child but not by searching the entry directly.
+
+ 2. permission "s" to each attribute appearing in a
+ presence test during the evaluation of the search
+ filter. permission "r" to each attribute appearing in
+ non-presence tests (see rfc1960, section 3:
+ equalityMatch, substrings, greaterOrEquial,
+ lessOrEqual, present, approxMatch, extensibleMatch)
+ during the evaluation of the search filter.
+
+ The above statement covers the case where the
+ attributes are being evaluated as part of an
+ extensibleMatch (RFC 2251 section 4.5.1) which appears
+ in the filter. In the case where the dnAttributes
+ field of the extensibleMatch is true then we do not
+ require any access checks to the attributes of the dn
+ candidateDN as access to these is taken to be granted
+ by the "b" permission, which has already been required
+ above.
+
+ If there is an attribute in a filter element to which
+ the required permission is not granted then that
+ filter element evaluates to "Undefined" of the three-
+ valued-logic of X.511(93).
+
+ Note A: Although both "r" and "s" permissions will
+ typically be granted to attributes we keep both
+
+
+
+Stokes, et al Expires 14 January 2001 [Page 19]
+
+
+
+
+
+Internet-Draft Access Control Model 14 July 2000
+
+
+
+ permissions as there are cases where the distinction
+ is useful. For example, the ability to grant the
+ right to discover that a user entry contains a
+ userPassword attribute, but not to read it's value
+ ("s" but not "r"). The converse, granting "r" but not
+ "s" permission is less easy to motivate.
+
+ Note B: There is an unusual behaviour with respect to
+ naming attributes illustrated in the following
+ example:
+
+ Suppose I have "b" rights to cn=fred,o=sun.com and "r"
+ rights to attribute objectclass but not "r" rights to
+ cn then with search filter (objectclass=*) I get back
+ the dn and objectclass (and so can see the value of
+ cn), but with a search filter of (cn=fred) I do not
+ get anything.
+
+ 3. permission "r" to each attribute in the attribute list
+
+ AttributeDescriptionList (or all attributes in the
+ entry candidateDN if AttributeDescriptionList is *)
+ whose type and/or value will be returned.
+
+ Note: The presence of an attribute in an entry is only
+ ever volunteered by the server if "r" permission is
+ granted to it, though a user may infer the presence of
+ an attribute with "s" permission by using a presence
+ test on that attribute in the search filter.
+
+ 4. permission "t" to the entry candidateDN
+
+ If this permission is not granted then the dn
+ candidateDN MUST NOT be returned. If the server knows
+ of an alias for the entry, this alias may be returned
+ instead. If no alias name is available then the entry
+ candidateDN MUST be omitted from the search results.
+
+
+ 5. Disclose on error for the Search operation
+
+ If every entry in the scope of the search fails to
+ satisfy item 1 (browse right on the candidate entry)
+ or item 2 (right to use the filter on that entry) and
+ if discloseOnError is not granted to the baseObject
+ entry then the operation MUST fail with a "no such
+ object error" and the matchedDN of the LDAPResult MUST
+ be set to "". If every entry in the scope of the
+ search fails to satisfy items 1 or 2 above and
+ discloseOnError is granted to the baseObject then the
+ empty set of results is returned.
+
+
+
+Stokes, et al Expires 14 January 2001 [Page 20]
+
+
+
+
+
+Internet-Draft Access Control Model 14 July 2000
+
+
+
+5.3 Modify Operation
+
+Recall that the parameters of the Modify operation per
+RFC2251 [LDAPv3] Section 4.6 are:
+
+ ModifyRequest ::= [APPLICATION 6] SEQUENCE {
+ object LDAPDN,
+ modification SEQUENCE OF SEQUENCE {
+ operation ENUMERATED {
+ add (0),
+ delete (1),
+ replace (2) },
+ modification AttributeTypeAndValues } }
+
+
+ AttributeTypeAndValues ::= SEQUENCE {
+ type AttributeDescription,
+ vals SET OF AttributeValue }
+
+Then the permissions required by authzID that need to be
+evaluated are as follows:
+
+
+ 1. permission "w" to each attribute being added to object
+
+ If this permission is not granted to such an
+ attribute, then the operation MUST fail. In this
+ case, if discloseOnError is not granted to the entry
+ then "no such object" error is returned; if
+ discloseOnError is granted to the entry and a
+ duplicate attribute value is being added then
+ "attribute value already exists" error is returned; if
+ discloseOnError is granted to the entry and no
+ duplicate value is being added then an "insufficient
+ access" error is returned.
+
+ 2. permission "o" to each attribute for which a value is
+ being deleted from object
+
+ If this permission is not granted to such an attribute
+ then the operation MUST fail. In this case, if
+ discloseOnError is not granted to the entry then "no
+ such object" error is returned; if discloseOnError is
+ granted to the entry and the attribute or one of the
+ values to be deleted does not exist then a "no such
+ attribute or value" error is returned; if
+ discloseOnError is granted to the entry and the
+ attribute and all values specified to be deleted exist
+ then an "insufficient access" error is returned.
+
+
+
+
+
+Stokes, et al Expires 14 January 2001 [Page 21]
+
+
+
+
+
+Internet-Draft Access Control Model 14 July 2000
+
+
+
+ 3. permissions "o" and "w" to each attribute being
+ replaced in object
+
+ If one of these these permissions is not granted to
+ such an attribute then the operation MUST fail. In
+ this case, if discloseOnError is not granted to the
+ entry then a "no such object" error is returned; if
+ discloseOnError is granted to the entry then
+ "insufficient access" error is returned.
+
+
+5.4 Add Operation
+
+Recall that the parameters of the Add operation per RFC2251
+[LDAPv3] Section 4.7 are:
+
+ AddRequest ::= [APPLICATION 8] SEQUENCE {
+ entry LDAPDN,
+ attributes AttributeList }
+
+
+ AttributeList ::= SEQUENCE OF SEQUENCE {
+ type AttributeDescription,
+ vals SET OF AttributeValue }
+
+Then the permissions required by authzID that need to be
+evaluated are as follows:
+
+ permission "a" to the parent of entry
+
+ The access rights required for the creation of a root
+ entry in the Directory are beyond the scope of this
+ document. They will be vendor specific.
+
+ 1. permission "m" to the parent of entry for each
+ attribute being added to entry
+
+If any of these permissions are not granted then the
+operation MUST fail. In this case if discloseOnError is on
+and the entry to be added does not already exist then
+"insufficient access" is returned. If it does exist then
+"Entry already exists" is returned. If discloseOnError is
+off then "No such object" is returned (meaning the parent
+object).
+
+If they are all granted then the operation MAY proceed.
+
+Note: We require "m" permission to each attribute to prevent
+an entry from aquiring "unintended" rights (via group or
+role membership), to stop a "rogue" ACI being added that
+would prevent even admins deleting the entry and general
+
+
+
+Stokes, et al Expires 14 January 2001 [Page 22]
+
+
+
+
+
+Internet-Draft Access Control Model 14 July 2000
+
+
+
+consistency with the MODIFY operation.
+
+Note: The access rights required for the creation of the
+first entry in the directory are beyond the scope of this
+document.
+
+
+5.5 Delete Operation
+
+Recall that the parameters of the Delete operation per
+RFC2251 [LDAPv3] Section 4.10 are:
+
+ DelRequest ::= [APPLICATION 10] LDAPDN
+
+Then the permissions required by authzID that need to be
+evaluated are as follows:
+
+
+ 1. permission "d" to the entry in the Delete request
+
+If this permission is not granted, then the operation MUST
+fail. In this case if discloseOnError is on and the entry
+to be deleted exists then "insufficient access" is returned.
+If it does not exist then "No such Object" is returned. If
+discloseOnError is off then "No such object" is returned
+(meaning the parent object).
+
+If this permission is granted, then the operation MAY
+proceed.
+
+Note: One could also require the "o" permission to be
+granted to allow the operation to proceed, but customer
+experience has shown that the requirement of the additional
+permission is not useful nor expected, and X.500 requires
+only the "d" permission.
+
+
+5.6 Modify DN Operation
+
+Recall that the parameters of the Modify DN operation per
+RFC2251 [LDAPv3] Section 4.6 are:
+
+ ModifyDNRequest ::= [APPLICATION 12] SEQUENCE {
+ entry LDAPDN,
+ newrdn RelativeLDAPDN,
+ deleteoldrdn BOOLEAN,
+ newSuperior [0] LDAPDN OPTIONAL }
+
+Then the permissions required by authzID that need to be
+evaluated are as follows:
+
+
+
+
+Stokes, et al Expires 14 January 2001 [Page 23]
+
+
+
+
+
+Internet-Draft Access Control Model 14 July 2000
+
+
+
+ 1. If newSuperior is not present (ie. only the RDN is
+ being renamed) then permission "n" to entry is
+ required.
+
+ 2. If newSuperior is present then permission "e" to entry
+ and permission "i" to newSuperior are required.
+
+If any of these permissions are not granted then the
+operation MUST fail. In this case, if discloseOnError is on
+then an "insufficient access error" is returned. Otherwise,
+"No such object" is returned.
+
+If they are all granted then the operation MAY proceed.
+
+Note A: We do not require any additional permissions in the
+case where deleteoldrdn is TRUE.
+
+Note B: These permissions allow the naming attribute of an
+entry (or entries) to be changed even though "o" and "w"
+permissions are not available on the entry. Distinguishing
+the permissions like this allows us to grant permissions for
+the ModifyDN operation, but not the Modify operation and
+vice versa.
+
+
+5.7 Compare Operation
+
+Recall that the parameters of the Compare operation per
+RFC2251 [LDAPv3] Section 4.10 are:
+
+ CompareRequest ::= [APPLICATION 14] SEQUENCE {
+ entry LDAPDN,
+ ava AttributeValueAssertion }
+
+Then the permissions required by authzID that need to be
+evaluated are as follows:
+
+
+ 1. permission "c" to the attribute in entry on which the
+ comparison is being made.
+
+If any of these permissions are not granted then the
+operation MUST fail. In this case, if discloseOnError is on
+then an "insufficient access error" is returned. Otherwise,
+"No such object" is returned.
+
+If they are all granted then the operation MAY proceed.
+
+
+
+
+
+
+
+Stokes, et al Expires 14 January 2001 [Page 24]
+
+
+
+
+
+Internet-Draft Access Control Model 14 July 2000
+
+
+
+5.8 Abandon Operation
+
+Recall that the parameters of the Abandon operation per
+RFC2251 [LDAPv3] Section 4.6 are:
+
+ AbandonRequest ::= [APPLICATION 16] MessageID
+
+authzID always has the right to send an Abandon Operation
+for an operation he previously initiated.
+
+
+5.9 Extended Operation
+
+Recall that the parameters of the Extended operation per
+RFC2251 [LDA{v3] Section 4.12 are:
+
+ ExtendedRequest ::= [APPLICATION 23] SEQUENCE {
+ requestName [0] LDAPOID,
+ requestValue [1] OCTET STRING OPTIONAL }
+
+The access required for an Extended Operation is beyond the
+scope of this document. The required access will normally
+be defined by the implementor of the extended request.
+
+
+
+6. Required Permissions for Handling Aliases and References
+
+
+Use of aliases and referrals are part of LDAPv3. However,
+neither is particularly well-defined. Alias
+objects/attributes are defined in RFC 2256 as derived from
+X.500, but LDAPv3 does not explicitly define its semantics
+or behavior. X.500 does define alias semantics and behavior
+with respect to access control; we define its behavior in
+LDAPv3 based on the X.511, section 7.11.1. Referrals and
+knowledge information are still under design in LDAPv3; they
+are defined in X.500, however, X.500 punts on their
+semantics and behavior with respect to access control. We
+define their semantics and behavior in LDAPv3 in terms that
+should be independent of the future LDAPv3 definition of
+referrals and knowledge information.
+
+
+6.1 ACI Distribution
+
+Currently there is no LDAP standard defining how to
+distribute directory data between LDAP servers. Consequently
+this draft cannot fully specify the behavior of the Access
+Control Model in a distributed environment. The case of
+distribution via referrals is treated in the "Referrals"
+
+
+
+Stokes, et al Expires 14 January 2001 [Page 25]
+
+
+
+
+
+Internet-Draft Access Control Model 14 July 2000
+
+
+
+section below. In the case of chaining (where one LDAP
+server forwards a request to another on behalf of a client)
+then it is server specific how the access control model
+behaves in this environment. Similarly it is server specific
+how the server determines whether the chaining of an
+operation is permitted in the first place. For example, the
+implementation may choose to regard the local naming context
+and the remote subordinate naming context as seperate Access
+Control Specific Areas, or it may regard the DIT as one
+Access Control Specific Area and implement mechanisms to
+propagate access control information between the two
+servers. The behavior of the Access Control Model in
+distributed environments such as these is beyond the scope
+of this draft.
+
+
+6.2 Aliases
+
+There are two things to protect with respect to aliases:
+the real name of the aliased object and the location of the
+server holding it.
+
+If alias de-referencing is required in the process of
+locating a target entry, no specifc permissions are
+necessary for alias de-referencing to take place. Access
+control is enforced at the object pointed to by the alias.
+
+If alias de-referencing would result in a
+continuationReference (e.g. from a search operation), then
+browse permission is required to the alias entry and read
+permission is required to the 'aliasedObjectName' attribute.
+Requiring these permission closes the hole of discovery.
+
+
+6.3 Referrals
+
+If a referral is to be followed, no specifc permissions are
+necessary for the ldap client to follow the referral. Access
+control is enforced at the referenced object. If a referral
+is returned, then browse is required on the entry and read
+permission is required to the attribute containing the
+referral (we cannot name this attribute exactly today
+because there are no RFCs on this - only drafts). If the
+server implements a default referral, then no special
+permissions are required to read and return that referral.
+Requiring these permissions closes the hole of discovery.
+In the default case, it is assumed that a default referral
+is public.
+
+
+
+
+
+
+Stokes, et al Expires 14 January 2001 [Page 26]
+
+
+
+
+
+Internet-Draft Access Control Model 14 July 2000
+
+
+
+7. Controlling Access to Access Control Information
+
+The ldapACI attribute is used to specify control for who has
+permission to set/change access control information
+(ldapACI). The ldapACI attribute/OID is just another
+attribute described with a scope, set of rights and
+permissions, and subject as a value of the ldapACI
+attribute. (See the example in the "ACI Examples" section).
+
+If the policy for controlling the ldapACI attribute is not
+specified for any object in the tree, behavior is
+implementation defined. For instance, if no object anywhere
+in the tree defines the access for ldapACI within the
+ldapACI attribute, then the server could simply assert that
+the 'root DN' is considered the policy owner (controller for
+controlling access control) for all objects.
+
+
+
+8. ACI Examples
+
+Note that in the examples, the form "OID.<attrname>" refers
+to the OID in dotted decimal form for the attribute
+<attrname>. This shorthand notation is used only for the
+examples. In implementation, the dotted decimal form of the
+OID is used.
+
+
+8.1 Attribute Definition
+
+The following examples show the access required to control
+access to the ldapACI attribute. The first example shows
+controlling the access control on an individual entry and
+its attributes. The second example shows controlling the
+access control on a subtree.
+
+ ldapACI: entry#grant:r,w#
+ OID.ldapACI#authnLevel:any:role:cn=aciAdmin
+
+ ldapACI: subtree#grant:r,w#
+ OID.ldapACI#authnLevel:any:role:cn=aciAdmin
+
+The next example shows a ldapACI attribute where a group
+"cn=Dept XYZ, c=US" is being given permissions to read,
+search, and compare attribute attr1. The permission applies
+to the entire subtree below the node containing this ACI.
+Authentication of a specified type is not required.
+
+ ldapACI:subtree#grant;r,s,c#
+ OID.attr1#group:cn=Dept XYZ,c=US
+
+
+
+
+Stokes, et al Expires 14 January 2001 [Page 27]
+
+
+
+
+
+Internet-Draft Access Control Model 14 July 2000
+
+
+
+The next example shows an ACI attribute where a role
+"cn=SysAdmins,o=Company" is being given permissions to add
+objects below this node and read, search, and compare
+attributes attr2 and attr3. The permission applies to the
+entire subtree below the node containing this ACI.
+
+ ldapACI: subtree#grant:a#
+ [entry]#role:cn=SysAdmins,o=Company
+
+ ldapACI: subtree#grant:r,s,c#
+ OID.attr2#role:cn=SysAdmins,o=Company
+
+ ldapACI: subtree#grant:r,s,c#
+ OID.attr3#role:cn=SysAdmins,o=Company
+
+
+8.2 Modifying the ldapACI Values
+
+Modify-Replace works as defined in the ldap operation
+modify. If the attribute value does not exist, create the
+value. If the attribute does exist, replace the value. If
+the ldapACI value is replaced, all ldapACI values are
+replaced.
+
+A given ldapACI for an entry:
+
+ ldapACI: subtree#deny:r,w#[all]#group:cn=Dept ABC
+
+ ldapACI: subtree#grant:r#OID.attr1#group:cn=Dept XYZ
+
+perform the following change:
+
+ dn: cn=someEntry
+ changetype: modify
+ replace: ldapACI
+ ldapACI: subtree#grant:r,w#[all]#group:cn=Dept LMN
+
+The resulting ACI is:
+
+ldapACI: subtree#grant:r,w#[all]#group:cn=Dept LMN
+
+( ldapACI values for Dept XYZ and ABC are lost through the
+replace )
+
+During an ldapmodify-add, if the ACI does not exist, the
+create the ACI with the specific ldapACI value(s). If the
+ACI does exist, then add the specified values to the given
+ldapACI. For example a given ACI:
+
+ldapACI: subtree#grant:r,w#[all]#group:cn=Dept XYZ
+
+
+
+
+Stokes, et al Expires 14 January 2001 [Page 28]
+
+
+
+
+
+Internet-Draft Access Control Model 14 July 2000
+
+
+
+with a modification:
+
+ dn: cn=someEntry
+ changetype: modify
+ add: ldapACI
+ ldapACI: subtree#grant:r#OID.attr1#group:cn=Dept XYZ
+
+would yield an multi-valued ACI of:
+
+ ldapACI: subtree#grant:r,w#[all]#group:cn=Dept XYZ
+
+ ldapACI: subtree#grant:r#OID.attr1#group:cn=Dept XYZ
+
+To delete a particular ACI value, use the regular ldapmodify
+- delete syntax
+
+Given an ACI of:
+
+ ldapACI: subtree#grant:r,w#[all]#group:cn=Dept XYZ
+ ldapACI: subtree#grant:r#OID.attr1#group:cn=Dept XYZ
+
+ dn: cn = some Entry
+ changetype: modify
+ delete: ldapACI
+ ldapACI: subtree#grant:r#OID.attr1#group:cn=Dept XYZ
+
+would yield a remaining ACI on the server of
+
+ldapACI: subtree#grant:r,w#[all]#group:cn=Dept XYZ
+
+The attributes which are defined for access control
+interchange may be used in all LDAP operations.
+
+Within the ldapmodify-delete operation, the entire acl may
+be deleted by specifying
+
+ dn: cn = some Entry
+ changetype: modify
+ delete: ldapACI
+
+In this case, the entry would then inherit its ACI from some
+other node in the tree depending on the server inheritance
+model.
+
+Similarly, if all values of ldapACI are deleted, then the
+access control information for that entry is defined by that
+implementation's inheritance model.
+
+
+
+
+
+
+
+Stokes, et al Expires 14 January 2001 [Page 29]
+
+
+
+
+
+Internet-Draft Access Control Model 14 July 2000
+
+
+
+8.3 Evaluation
+
+These examples assume that the ldapACI entries listed in
+each example are the only ACI which applies to the entry in
+question; if backing-store ACI also exists, the effective
+policy may be different from that listed in each example.
+See section 10 for a discussion of the semantics of ldapACI
+entries when backing-store ACI administration is also used.
+
+Assume cn=jsmith is a member of group cn=G1. Assume
+cn=jsmith is a member of group cn=G2.
+
+ Example #1
+ dn: o=XYZ, c=US
+ ldapACI: subtree#grant:r#attr1
+ #authzID-dn:cn=jsmith,ou=ABC,o=XYZ,c=US
+ ldapACI: subtree#grant:w#attr1
+ #group:cn=G1,ou=ABC,o=XYZ,c=US
+
+ What rights does cn=jsmith have to attr1 of o=XYZ,c=US?
+ Read (r) access; authzID is higher precedence than
+ group.
+
+
+ Example #2
+ dn: o=XYZ, c=US
+ ldapACI: subtree#grant:r#attr2
+ #group:cn=G1,ou=ABC,o=XYZ,c=US
+ ldapACI: subtree#grant:w#attr2
+ #group:cn=G2,ou=ABC,o=XYZ,c=US
+
+ What rights does cn=jsmith have to attr2 of o=XYZ,c=US?
+ Read-write (r,w) access; ACI is combined because both
+ subjects (group) have same precedence.
+
+
+ Example #3
+ dn: o=XYZ, c=US
+ ldapACI: subtree#grant:r,w#attr3
+ #group:cn=G1,ou=ABC,o=XYZ,c=US
+ ldapACI: subtree#deny:w#attr3#group:cn=G2,ou=ABC,o=XYZ,c=US
+
+ What rights does cn=jsmith have to attr3 of o=XYZ, c=US?
+ Read access; write is denied (deny has precedence over
+ grant).
+
+
+ Example #4
+ dn: o=XYZ, c=US
+ ldapACI: subtree#grant:w#attr4
+ #authzID-dn:cn=jsmith,ou=ABC,o=XYZ,c=US
+
+
+
+Stokes, et al Expires 14 January 2001 [Page 30]
+
+
+
+
+
+Internet-Draft Access Control Model 14 July 2000
+
+
+
+ ldapACI: subtree#grant:r#attr4#subtree:ou=ABC,ou=XYZ,c=US
+
+ What rights does cn=jsmith have to attr4 of o=XYZ, c=US?
+ Write (w); rights given to an authzID take precedence
+ over those given to a subtree.
+
+
+ Example #5
+ dn: o=XYZ, c=US
+ ldapACI: subtree#grant:m#OID.attr5
+ #authzID-dn:cn=jsmith,o=ABC,c=US
+ ldapACI: subtree#grant:m#OID.cn
+ #authzID-dn:cn=jsmith,o=ABC,c=US
+ ldapACI: subtree#grant:m#OID.sn
+ #authzID-dn:cn=jsmith,o=ABC,c=US
+ ldapACI: subtree#grant:a#[entry]
+ #authzID-dn:#cn=jsmith,o=ABC,c=US
+
+ What rights does cn=jsmith have to o=XYZ, c=US?
+ Make(m) on attributes attr5, cn, and sn and Add(a)
+ on the entry. These are the minimal yet sufficient
+ permissions to create a new object,
+ cn=New, o=XYZ, c=US with values for the attr5, cn,
+ and sn attributes. This example illustrates how the
+ "m" permission can be used to limit the attributes
+ that can be created on a new entry.
+
+ Example #6
+ dn: c=US
+ ldapACI: subtree#grant:m#[all]#subtree:c=US
+ dn: o=XYZ, c=US
+ ldapACI: subtree#grant:a#[entry]#
+ authzID-dn:cn=jsmith,o=ABC,c=US
+
+ What rights does cn=jsmith have to o=XYZ, c=US?
+ Make(m) on attributes all attributes and Add(a) on the
+ entry. These are sufficient permissions to create a new
+ object, cn=New, o=XYZ, c=US with values any desired
+ attributes. For administrators who do not wish to limit
+ the attributes that can be created on new entries, this
+ example shows how a single ldapACI at the top of the
+ domain solves the problem.
+
+
+
+9. Operational Semantics of Access Control Operations
+
+The semantics of access control operations described in this
+document are defined operationally in terms of "histories".
+A history is a sequence of actions (x1, x2, ..., xN).
+
+
+
+
+Stokes, et al Expires 14 January 2001 [Page 31]
+
+
+
+
+
+Internet-Draft Access Control Model 14 July 2000
+
+
+
+9.1 Types of actions
+
+We consider five types of actions:
+
+ - LDAP Access Control Policy Update actions: invocations
+ of ldap modify when used to add, delete, or replace the
+ aci attribute; invocations of ldap add when used to add
+ an entry with an aci attribute. A LDAP Access Control
+ Policy Update action may replace the policy (by
+ completely replacing the aci attribute with new policy
+ information) or it may grant or deny specific rights
+ while leaving others unaffected.
+
+ - LDAP Access Control Policy Query operations:
+ invocations of ldap search when used to retrieve the
+ aci attribute; invocations of ldap search with the
+ getEffectiveRightsRequest control; invocations of the
+ ldapGetEffectiveRightsRequest extended operation.
+
+ - Datastore Access Control Policy Update Actions: any
+ operation implemented by the server which LDAP is using
+ as its datastore which changes the access policy
+ enforced with respect to attempts to access LDAP
+ directory entries and their attributes.
+
+ - LDAP Access Request operations: invocations of LDAP
+ entry or attribute access operations (Read, Update,
+ Search, Compare, etc...).
+
+ - Other operations: anything else, including Datastore
+ operations which do not change the access policy
+ enforced by the server.
+
+
+9.2 Semantics of Histories
+
+The semantics of histories are defined as follows:
+
+ - LDAP Update (Replace), LDAP Query
+
+ The Query will show that the subject has all rights
+ granted by the Update operation, and no rights not
+ granted by the Update operation.
+
+ - LDAP Update (Grant), LDAP Query
+
+ The Query will show that the subject has all rights
+ granted by the Update operation. The Query may show
+ that the subject also has other rights not granted by
+ the Update operation, depending on the policy in force
+ before the Update operation.
+
+
+
+Stokes, et al Expires 14 January 2001 [Page 32]
+
+
+
+
+
+Internet-Draft Access Control Model 14 July 2000
+
+
+
+ - LDAP Update (Deny), LDAP Query
+
+ The Query will show that the subject does not have any
+ right denied by the Update operation. The Query may
+ show that the subject has rights not denied by the
+ Update operation, depending on the policy in force
+ before the Update operation.
+
+ - LDAP Update (Replace), LDAP Access Request
+
+ The Request will succeed if it requires only rights
+ granted to the requesting subject by the Update
+ operation. The Request will fail if it requires any
+ right not granted by the Update operation.
+
+ - LDAP Update (Grant), LDAP Access Request
+
+ The Request will succeed if it requires only rights
+ granted to the requesting subject by the Update
+ operation. The Request may succeed if it requires
+ rights not granted by the Update operation, depending
+ on the policy in force before the Update operation.
+
+ - LDAP Update (Deny), LDAP Access Request
+
+ The Request will fail if it requires any right denied
+ to the requesting subject by the Update operation. If
+ the Request requires only rights which were not denied
+ by the Update operation, it may succeed, depending on
+ the policy in force before the Update operation.
+
+ - LDAP Update (Replace), Other, LDAP Query
+
+ The Query will show that the subject has all rights
+ granted by the Update operation, and no rights not
+ granted by the Update operation.
+
+ - LDAP Update (Grant), Other, LDAP Query
+
+ The Query will show that the subject has all rights
+ granted by the Update operation. The Query may show
+ that the subject also has other rights not granted by
+ the Update operation, depending on the policy in force
+ before the Update operation.
+
+ - LDAP Update (Deny), Other, LDAP Query
+
+ The Query will show that the subject does not have any
+ right denied by the Update operation. The Query may
+ show that the subject has rights not denied by the
+ Update operation, depending on the policy in force
+
+
+
+Stokes, et al Expires 14 January 2001 [Page 33]
+
+
+
+
+
+Internet-Draft Access Control Model 14 July 2000
+
+
+
+ before the Update operation.
+
+ - LDAP Update (Replace), Other, LDAP Access Request
+
+ The Request will succeed if it requires only rights
+ granted to the requesting subject by the Update
+ operation. The Request will fail if it requires any
+ right not granted by the Update operation.
+
+ - LDAP Update (Grant), Other, LDAP Access Request
+
+ The Request will succeed if it requires only rights
+ granted to the requesting subject by the Update
+ operation. The Request may succeed if it requires
+ rights not granted by the Update operation, depending
+ on the policy in force before the Update operation.
+
+ - LDAP Update (Deny), Other, LDAP Access Request
+
+ The Request will fail if it requires any right denied
+ to the requesting subject by the Update operation. If
+ the Request requires only rights which were not denied
+ by the Update operation, it may succeed, depending on
+ the policy in force before the Update operation.
+
+ - LDAP Update (Replace), Datastore Policy Update, LDAP
+ Query
+
+ The result of the Query is not defined.
+
+ - LDAP Update (Grant), Datastore Policy Update, LDAP
+ Query
+
+ The result of the Query is not defined.
+
+ - LDAP Update (Deny), Datastore Policy Update, LDAP Query
+
+ The result of the Query is not defined.
+
+ - LDAP Update (Replace), Datastore Policy Update, LDAP
+ Access Request
+
+ The result of the Access Request is not defined.
+
+ - LDAP Update (Grant), Datastore Policy Update, LDAP
+ Access Request
+
+ The result of the Access Request is not defined.
+
+ - LDAP Update (Deny), Datastore Policy Update, LDAP
+ Access Request
+
+
+
+Stokes, et al Expires 14 January 2001 [Page 34]
+
+
+
+
+
+Internet-Draft Access Control Model 14 July 2000
+
+
+
+ The result of the Access Request is not defined.
+
+
+
+10. Access Control Parameters for LDAP Controls & Extended
+Operations
+
+This section defines the parameters used in the access
+control LDAP controls and extended operations in this
+document.
+
+targetDN specifies the initial directory entry in DN syntax
+on which the control or extended operation is performed.
+
+whichObject specifies whether the access control information
+(in the get effective rights control) which is retrieved is
+for the target directory entry (ENTRY) or the target
+directory entry and its subtree (SUBTREE).
+
+rights in the get effective rights control or extended
+operation response is of the form specified in the BNF for
+<rights>.
+
+subject is a LDAP string that defines the subject. Access
+control is get/set on a subject. The syntax of the subject
+is the same as the subject field in the BNF.
+
+
+
+11. Access Control Information (ACI) Controls
+
+The access control information controls provide a way to
+manipulate access control information in conjunction with a
+LDAP operation. One LDAP control is defined. This control
+allows access control information to be retrieved while
+manipulating other directory information for that entry.
+The control is:
+
+ - getEffectiveRights to obtain the effective rights for a
+ given directory entry(s) for a given subject during a
+ ldap_search operation
+
+11.1 getEffectiveRights Control
+
+
+11.1.1 Request Control
+
+This control may only be included in the ldap_search
+message as part of the controls field of the
+LDAPMessage, as defined in Section 4.1.12 of [LDAPv3].
+
+
+
+
+Stokes, et al Expires 14 January 2001 [Page 35]
+
+
+
+
+
+Internet-Draft Access Control Model 14 July 2000
+
+
+
+The controlType is set to <OID to be assigned>. The
+criticality MAY be either TRUE or FALSE (where absent is
+also equivalent to FALSE) at the client's option. The
+controlValue is an OCTET STRING, whose value is the BER
+encoding of a value of the following SEQUENCE:
+
+ getEffectiveRightsRequest ::= SEQUENCE {
+ effectiveRightsRequest SEQUENCE OF SEQUENCE {
+ whichObject ENUMERATED {
+ LDAP_ENTRY (1),
+ LDAP_SUBTREE (2)
+ },
+ subject <see <subject > in BNF> | "*"
+ }
+ }
+
+The effectiveRightsRequest is a set of sequences that state
+the whichObject (entry or entry plus subtree) and specifics
+of the control request to be performed. A "*" in the subject
+field specifies that all DN types are to be used in
+returning the effective rights. This control is applied to
+the filter and scope set by the ldap_search operation, i.e.
+base, one-level, subtree. So the attributes/values returned
+are defined by the ldap_search operation.
+
+11.1.2 Response Control
+
+This control is included in the ldap_search_response message
+as part of the controls field of the LDAPMessage, as defined
+in Section 4.1.12 of [LDAPv3].
+
+The controlType is set to <OID to be assigned>. There is no
+need to set the criticality on the response. The
+controlValue is an OCTET STRING, whose value is the BER
+encoding of a value of the following SEQUENCE:
+
+ getEffectiveRightsResponse ::= {
+ result ENUMERATED {
+ success (0),
+ operationsError (1),
+ unavailableCriticalExtension (12),
+ noSuchAttribute (16),
+ undefinedAttributeType (17),
+ invalidAttributeSyntax (21),
+ insufficientRights (50),
+ unavailable (52),
+ unwillingToPerform (53),
+ other (80)
+ }
+ }
+
+
+
+
+Stokes, et al Expires 14 January 2001 [Page 36]
+
+
+
+
+
+Internet-Draft Access Control Model 14 July 2000
+
+
+
+The effective rights returned are returned with each entry
+returned by the search result. The control response for
+ldap_search is:
+
+ PartialEffectiveRightsList ::= SEQUENCE OF SEQUENCE {
+ rights <see <rights> in BNF>,
+ whichObject ENUMERATED {
+ LDAP_ENTRY (1),
+ LDAP_SUBTREE (2)
+ },
+ subject < see <subject> in BNF >
+ }
+
+Although this extends the search operation, there are no
+incompatibilities between versions. LDAPv2 cannot send a
+control, hence the above structure cannot be returned to a
+LDAPv2 client. A LDAPv3 client cannot send this request to
+a LDAPv2 server. A LDAPv3 server not supporting this
+control cannot return the additional data.
+
+11.1.3 Client-Server Interaction
+
+The getEffectiveRightsRequest control requests the rights
+that MUST be in effect for requested directory
+entry/attribute based on the subject DN. The server that
+consumes the search operation looks up the rights for the
+returned directory information based on the subject DN and
+returns that rights information.
+
+There are six possible scenarios that may occur as a result
+of the getEffectiveRights control being included on the
+search request:
+
+
+ 1. If the server does not support this control and the
+ client specified TRUE for the control's criticality
+ field, then the server MUST return
+ unavailableCriticalExtension as a return code in the
+ searchResponse message and not send back any other
+ results. This behavior is specified in section 4.1.12
+ of [LDAPv3].
+
+ 2. If the server does not support this control and the
+ client specified FALSE for the control's criticality
+ field, then the server MUST ignore the control and
+ process the request as if it were not present. This
+ behavior is specified in section 4.1.12 of [LDAPv3].
+
+ 3. If the server supports this control but for some
+ reason such as cannot process specified family and the
+ client specified TRUE for the control's criticality
+
+
+
+Stokes, et al Expires 14 January 2001 [Page 37]
+
+
+
+
+
+Internet-Draft Access Control Model 14 July 2000
+
+
+
+ field, then the server SHOULD do the following: return
+ unavailableCriticalExtension as a return code in the
+ searchResult message.
+
+ 4. If the server supports this control but for some
+ reason such as cannot process specified family and the
+ client specified FALSE for the control's criticality
+ field, then the server should process as 'no rights
+ returned for that family' and include the result
+ Unavailable in the getEffectiveRightsResponse control
+ in the searchResult message.
+
+ 5. If the server supports this control and can return the
+ rights per the family information, then it should
+ include the getEffectiveRightsResponse control in the
+ searchResult message with a result of success.
+
+ 6. If the search request failed for any other reason,
+ then the server SHOULD omit the
+ getEffectiveRightsResponse control from the
+ searchResult message.
+
+The client application is assured that the correct rights
+are returned for scope of the search operation if and only
+if the getEffectiveRightsResponse control returns the
+rights. If the server omits the getEffectiveRightsResponse
+control from the searchResult message, the client SHOULD
+assume that the control was ignored by the server.
+
+The getEffectiveRightsResponse control, if included by the
+server in the searchResponse message, should have the
+getEffectiveRightsResult set to either success if the rights
+are returned or set to the appropriate error code as to why
+the rights could not be returned.
+
+The server may not be able to return a right because it may
+not exist in that directory object's attribute; in this
+case, the rights request is ignored with success.
+
+
+12. Access Control Extended Operation
+
+An extended operation, get effective rights, is defined to
+obtain the effective rights for a given directory entry for
+a given subject. This operation may help with the
+management of access control information independent of
+manipulating other directory information.
+
+
+
+
+
+
+
+Stokes, et al Expires 14 January 2001 [Page 38]
+
+
+
+
+
+Internet-Draft Access Control Model 14 July 2000
+
+
+
+12.1 LDAP Get Effective Rights Operation
+
+ldapGetEffectiveRightsRequest ::= [APPLICATION 23] SEQUENCE
+{
+ requestName [0] <OID to be assigned>,
+ requestValue [1] OCTET STRING OPTIONAL }
+
+ where
+
+ requestValue ::= SEQUENCE {
+ targetDN LDAPDN,
+ updates SEQUENCE OF SEQUENCE {
+ whichObject ENUMERATED {
+ LDAP_ENTRY (1),
+ LDAP_SUBTREE (2)
+ },
+ attr SEQUENCE {
+ attr <see <attr> in BNF >
+ },
+ subject < see <subject> in BNF > | "*"
+ }
+ }
+
+
+The requestName is a dotted-decimal representation of the
+OBJECT IDENTIFIER corresponding to the request. The
+requestValue is information in a form defined by that
+request, encapsulated inside an OCTET STRING.
+
+The server will respond to this with an LDAPMessage
+containing the ExtendedResponse which is a rights list.
+
+ldapGetEffectiveRightsResponse ::= [APPLICATION 24] SEQUENCE
+{
+ COMPONENTS OF LDAPResult,
+ responseName [10] <OID to be assigned> OPTIONAL,
+ effectiveRights [11] OCTET STRING OPTIONAL }
+
+ where
+
+ effectiveRights ::= SEQUENCE OF SEQUENCE {
+ rights <see <rights> in BNF>,
+ whichObject ENUMERATED {
+ LDAP_ENTRY (1),
+ LDAP_SUBTREE (2)
+ },
+ subject < see <subject> in BNF >
+ }
+
+If the server does not recognize the request name, it MUST
+return only the response fields from LDAPResult, containing
+
+
+
+Stokes, et al Expires 14 January 2001 [Page 39]
+
+
+
+
+
+Internet-Draft Access Control Model 14 July 2000
+
+
+
+the protocolError result code.
+
+
+
+13. Security Considerations
+
+This document proposes protocol elements for transmission of
+security policy information. Security considerations are
+discussed throughout this draft. Because subject security
+attribute information is used to evaluate decision requests,
+it is security-sensitive information and must be protected
+against unauthorized modification whenever it is stored or
+transmitted.
+
+Interaction of access control with other directory functions
+(other than the ones defined in this document) are not
+defined in this document, but instead in the documents where
+those directory functions are defined. For example, the
+directory replication documents should address the
+interaction of access control with the replication function.
+
+
+
+14. References
+
+[LDAPv3] M. Wahl, T. Howes, S. Kille, "Lightweight Directory
+Access Protocol (v3)", RFC 2251, December 1997.
+
+[ECMA] ECMA, "Security in Open Systems: A Security
+Framework" ECMA TR/46, July 1988.
+
+[REQTS] Stokes, Byrne, Blakley, "Access Control Requirements
+for LDAP", RFC 2820, May 2000.
+
+[ATTR] M.Wahl, A, Coulbeck, T. Howes, S. Kille, "Lightweight
+Directory Access Protocol (v3)": Attribute Syntax
+Definitions, RFC 2252, December 1997.
+
+[UTF] M. Wahl, S. Kille, "Lightweight Directory Access
+Protocol (v3)": A UTF-8 String Representation of
+Distinguished Names", RFC 2253, December 1997.
+
+[Bradner97] Bradner, Scott, "Key Words for use in RFCs to
+Indicate Requirement Levels", RFC 2119.
+
+[AuthMeth] Wahl, M., Alvestrand, H., Hodges, J. and R.
+Morgan, "Authentication Methods for LDAP", RFC 2829, May
+2000.
+
+[ABNF] D. Crocker, P. Overell, "Augmented BNF for Syntax
+Specifications: ABNF", RFC 2234, November 1997.
+
+
+
+Stokes, et al Expires 14 January 2001 [Page 40]
+
+
+
+
+
+Internet-Draft Access Control Model 14 July 2000
+
+
+
+ACKNOWLEDGEMENT
+
+This is to acknowledge the numerous companies and individuals who have
+contributed their valuable help and insights to the development of this
+specification.
+
+
+AUTHOR(S) ADDRESS
+
+ Ellen Stokes Bob Blakley
+ Tivoli Systems Tivoli Systems
+ 6300 Bridgepoint Parkway 6300 Bridgepoint Parkway
+ Austin, TX 78731 Austin, TX 78731
+ USA USA
+ mail-to: estokes at tivoli.com mail-to: blakley at tivoli.com
+ phone: +1 512 436 9098 phone: +1 512 436 1564
+ fax: +1 512 436 1199 fax: +1 512 436 1199
+
+
+ Debbie Rinkevich Robert Byrne
+ IBM Sun Microsystems
+ 11400 Burnet Rd 29 Chemin du Vieux Chene
+ Austin, TX 78758 Meylan ZIRST 38240
+ USA France
+ mail-to: djbrink at us.ibm.com mail-to: rbyrne at france.sun.com
+ phone: +1 512 838 1960 phone: +33 (0)4 76 41 42 05
+ fax: +1 512 838 8597
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Stokes, et al Expires 14 January 2001 [Page 41]
+
+
+
+
+
+Internet-Draft Access Control Model 14 July 2000
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Stokes, et al Expires 14 January 2001 [Page 42]
+
+
+
+
+
+
+
+
+
+ CONTENTS
+
+
+ 1. Introduction....................................... 2
+
+ 2. The LDAPv3 Access Control Model.................... 2
+
+ 3. Access Control Mechanism Attributes................ 5
+ 3.1 Root DSE Attribute for Access Control
+ Mechanism.................................... 5
+ 3.2 Root DSE Attribute for Control of Disclosing
+ Errors....................................... 5
+ 3.3 Subentry Class Access Control Mechanism...... 6
+
+ 4. The Access Control Information Attribute
+ (ldapACI).......................................... 7
+ 4.1 The BNF...................................... 8
+ 4.1.1 ACI String Representation 8
+ 4.1.2 ACI Binary Representation 10
+ 4.2 The Components of ldapACI Attribute.......... 11
+ 4.2.1 Scope 11
+ 4.2.2 Access Rights and Permissions 11
+ 4.2.3 Attributes 14
+ 4.2.4 Subjects and Associated
+ Authentication 15
+ 4.3 Grant/Deny Evaluation Rules.................. 15
+
+ 5. Required Permissions for each LDAP Operation....... 17
+ 5.1 Bind Operation............................... 18
+ 5.2 Search Operation............................. 18
+ 5.3 Modify Operation............................. 21
+ 5.4 Add Operation................................ 22
+ 5.5 Delete Operation............................. 23
+ 5.6 Modify DN Operation.......................... 23
+ 5.7 Compare Operation............................ 24
+ 5.8 Abandon Operation............................ 25
+ 5.9 Extended Operation........................... 25
+
+ 6. Required Permissions for Handling Aliases and
+ References......................................... 25
+ 6.1 ACI Distribution............................. 25
+ 6.2 Aliases...................................... 26
+ 6.3 Referrals.................................... 26
+
+ 7. Controlling Access to Access Control
+ Information........................................ 27
+
+ 8. ACI Examples....................................... 27
+ 8.1 Attribute Definition......................... 27
+ 8.2 Modifying the ldapACI Values................. 28
+ 8.3 Evaluation................................... 30
+
+
+
+ - i -
+
+
+
+
+
+
+
+
+
+
+
+ 9. Operational Semantics of Access Control
+ Operations......................................... 31
+ 9.1 Types of actions............................. 32
+ 9.2 Semantics of Histories....................... 32
+
+10. Access Control Parameters for LDAP Controls &
+ Extended Operations................................ 35
+
+11. Access Control Information (ACI) Controls.......... 35
+ 11.1 getEffectiveRights Control................... 35
+ 11.1.1 Request Control 35
+ 11.1.2 Response Control 36
+ 11.1.3 Client-Server Interaction 37
+
+12. Access Control Extended Operation.................. 38
+ 12.1 LDAP Get Effective Rights Operation.......... 39
+
+13. Security Considerations............................ 40
+
+14. References......................................... 40
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ - ii -
+
+
+
+
+
+
+
+
+
+
+
+Full Copyright Statement
+
+Copyright (C) The Internet Society (2000).á All Rights
+Reserved.
+
+This document and translations of it may be copied and
+furnished to others, and derivative works that comment on or
+otherwise explain it or assist in its implementation may be
+prepared, copied, published and distributed, in whole or in
+part, without restriction of any kind, provided that the
+above copyright notice and this paragraph are included on
+all such copies and derivative works.á However, this
+document itself may not be modified in any way, such as by
+removing the copyright notice or references to the Internet
+Society or other Internet organizations, except as needed
+for the purpose of developing Internet standards in which
+case the procedures for copyrights defined in the Internet
+Standards process must be followed, or as required to
+translate it into languages other than English.
+
+The limited permissions granted above are perpetual and will
+not be revoked by the Internet Society or its successors or
+assigns.
+
+This document and the information contained herein is
+provided on an "AS IS" basis and THE INTERNET SOCIETY AND
+THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL
+WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO
+ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
+INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ - iii -
+
+
+
+
Added: openldap/vendor/openldap-release/doc/drafts/draft-ietf-ldapext-ldap-c-api-xx.txt
===================================================================
--- openldap/vendor/openldap-release/doc/drafts/draft-ietf-ldapext-ldap-c-api-xx.txt (rev 0)
+++ openldap/vendor/openldap-release/doc/drafts/draft-ietf-ldapext-ldap-c-api-xx.txt 2007-09-15 10:38:52 UTC (rev 844)
@@ -0,0 +1,4647 @@
+
+
+Network Working Group M. Smith, Editor
+INTERNET-DRAFT Netscape Communications Corp.
+Intended Category: Standards Track T. Howes
+Obsoletes: RFC 1823 Loudcloud, Inc.
+Expires: May 2001 A. Herron
+ Microsoft Corp.
+ M. Wahl
+ Sun Microsystems, Inc.
+ A. Anantha
+ Microsoft Corp.
+
+
+ 17 November 2000
+
+ The C LDAP Application Program Interface
+ <draft-ietf-ldapext-ldap-c-api-05.txt>
+
+
+1. Status of this Memo
+
+This document is an Internet-Draft and is in full conformance with all
+provisions of Section 10 of RFC2026. Internet-Drafts are working docu-
+ments of the Internet Engineering Task Force (IETF), its areas, and its
+working groups. Note that other groups may also distribute working
+documents as Internet-Drafts.
+
+Internet-Drafts are draft documents valid for a maximum of six months
+and may be updated, replaced, or obsoleted by other documents at any
+time. It is inappropriate to use Internet-Drafts as reference material
+or to cite them other than as "work in progress."
+
+The list of current Internet-Drafts can be accessed at
+http://www.ietf.org/ietf/1id-abstracts.txt.
+
+The list of Internet-Draft Shadow Directories can be accessed at
+http://www.ietf.org/shadow.html.
+
+This draft document will be submitted to the RFC Editor as a Standards
+Track document. Distribution of this memo is unlimited. Technical dis-
+cussion of this document will take place on the IETF LDAP Extension
+Working Group mailing list <ietf-ldapext at netscape.com>. Please send
+editorial comments directly to the authors.
+
+Copyright (C) The Internet Society (1997-1999). All Rights Reserved.
+
+Please see the Copyright section near the end of this document for more
+information.
+
+
+
+
+Expires: May 2001 [Page 1]
+
+C LDAP API C LDAP Application Program Interface 17 November 2000
+
+
+2. Introduction
+
+This document defines a C language application program interface (API)
+to the Lightweight Directory Access Protocol (LDAP). This document
+replaces the previous definition of this API, defined in RFC 1823,
+updating it to include support for features found in version 3 of the
+LDAP protocol. New extended operation functions were added to support
+LDAPv3 features such as controls. In addition, other LDAP API changes
+were made to support information hiding and thread safety.
+
+The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+document are to be interpreted as described in RFC 2119[1].
+
+The C LDAP API is designed to be powerful, yet simple to use. It defines
+compatible synchronous and asynchronous interfaces to LDAP to suit a
+wide variety of applications. This document gives a brief overview of
+the LDAP model, then an overview of how the API is used by an applica-
+tion program to obtain LDAP information. The API calls are described in
+detail, followed by appendices that provide example code demonstrating
+use of the API, the namespace consumed by the API, a summary of require-
+ments for API extensions, known incompatibilities with RFC 1823, and a
+list of changes made since the last revision of this document.
+
+
+3. Table of Contents
+
+1. Status of this Memo............................................1
+2. Introduction...................................................2
+3. Table of Contents..............................................2
+4. Overview of the LDAP Model.....................................4
+5. Overview of LDAP API Use and General Requirements..............4
+6. Header Requirements............................................6
+7. Common Data Structures and Types...............................7
+8. Memory Handling Overview.......................................9
+9. Retrieving Information About the API Implementation............9
+9.1. Retrieving Information at Compile Time......................10
+9.2. Retrieving Information During Execution.....................11
+10. Result Codes...................................................14
+11. Performing LDAP Operations.....................................16
+11.1. Initializing an LDAP Session................................16
+11.2. LDAP Session Handle Options.................................17
+11.3. Working With Controls.......................................23
+11.3.1. A Client Control That Governs Referral Processing........24
+11.4. Authenticating to the directory.............................25
+11.5. Closing the session.........................................27
+11.6. Searching...................................................28
+11.7. Reading an Entry............................................32
+
+
+
+Expires: May 2001 [Page 2]
+
+C LDAP API C LDAP Application Program Interface 17 November 2000
+
+
+
+11.8. Listing the Children of an Entry............................32
+11.9. Comparing a Value Against an Entry..........................33
+11.10. Modifying an entry..........................................35
+11.11. Modifying the Name of an Entry..............................37
+11.12. Adding an entry.............................................39
+11.13. Deleting an entry...........................................41
+11.14. Extended Operations.........................................43
+12. Abandoning An Operation........................................44
+13. Obtaining Results and Peeking Inside LDAP Messages.............45
+14. Handling Errors and Parsing Results............................47
+15. Stepping Through a List of Results.............................51
+16. Parsing Search Results.........................................51
+16.1. Stepping Through a List of Entries or References............52
+16.2. Stepping Through the Attributes of an Entry.................53
+16.3. Retrieving the Values of an Attribute.......................54
+16.4. Retrieving the name of an entry.............................55
+16.5. Retrieving controls from an entry...........................56
+16.6. Parsing References..........................................57
+17. Encoded ASN.1 Value Manipulation...............................58
+17.1. BER Data Structures and Types...............................58
+17.2. Memory Disposal and Utility Functions.......................60
+17.3. Encoding....................................................60
+17.4. Encoding Example............................................63
+17.5. Decoding....................................................64
+17.6. Decoding Example............................................67
+18. Security Considerations........................................70
+19. Acknowledgements...............................................70
+20. Copyright......................................................70
+21. Bibliography...................................................71
+22. Authors' Addresses.............................................72
+23. Appendix A - Sample C LDAP API Code............................73
+24. Appendix B - Namespace Consumed By This Specification..........74
+25. Appendix C - Summary of Requirements for API Extensions........75
+25.1. Compatibility...............................................75
+25.2. Style.......................................................75
+25.3. Dependence on Externally Defined Types......................75
+25.4. Compile Time Information....................................76
+25.5. Runtime Information.........................................76
+25.6. Values Used for Session Handle Options......................76
+26. Appendix D - Known Incompatibilities with RFC 1823.............76
+26.1. Opaque LDAP Structure.......................................76
+26.2. Additional Result Codes.....................................77
+26.3. Freeing of String Data with ldap_memfree()..................77
+26.4. Changes to ldap_result()....................................77
+26.5. Changes to ldap_first_attribute() and ldap_next_attribute...77
+26.6. Changes to ldap_modrdn() and ldap_modrdn_s() Functions......78
+26.7. Changes to the berval structure.............................78
+26.8. API Specification Clarified.................................78
+
+
+Expires: May 2001 [Page 3]
+
+C LDAP API C LDAP Application Program Interface 17 November 2000
+
+
+26.9. Deprecated Functions........................................78
+27. Appendix E - Data Types and Legacy Implementations.............79
+28. Appendix F - Changes Made Since Last Document Revision.........80
+28.1. API Changes.................................................80
+28.2. Editorial Changes and Clarifications........................81
+
+
+4. Overview of the LDAP Model
+
+LDAP is the lightweight directory access protocol, described in [2] and
+[3]. It can provide a lightweight frontend to the X.500 directory [4],
+or a stand-alone service. In either mode, LDAP is based on a client-
+server model in which a client makes a TCP connection to an LDAP server,
+over which it sends requests and receives responses.
+
+The LDAP information model is based on the entry, which contains infor-
+mation about some object (e.g., a person). Entries are composed of
+attributes, which have a type and one or more values. Each attribute has
+a syntax that determines what kinds of values are allowed in the attri-
+bute (e.g., ASCII characters, a jpeg photograph, etc.) and how those
+values behave during directory operations (e.g., is case significant
+during comparisons).
+
+Entries may be organized in a tree structure, usually based on politi-
+cal, geographical, and organizational boundaries. Each entry is uniquely
+named relative to its sibling entries by its relative distinguished name
+(RDN) consisting of one or more distinguished attribute values from the
+entry. At most one value from each attribute may be used in the RDN.
+For example, the entry for the person Babs Jensen might be named with
+the "Barbara Jensen" value from the commonName attribute.
+
+A globally unique name for an entry, called a distinguished name or DN,
+is constructed by concatenating the sequence of RDNs from the entry up
+to the root of the tree. For example, if Babs worked for the University
+of Michigan, the DN of her U-M entry might be "cn=Barbara Jensen,
+o=University of Michigan, c=US". The DN format used by LDAP is defined
+in [5].
+
+Operations are provided to authenticate, search for and retrieve infor-
+mation, modify information, and add and delete entries from the tree.
+The next sections give an overview of how the API is used and detailed
+descriptions of the LDAP API calls that implement all of these func-
+tions.
+
+
+5. Overview of LDAP API Use and General Requirements
+
+An application generally uses the C LDAP API in four simple steps.
+
+
+
+Expires: May 2001 [Page 4]
+
+C LDAP API C LDAP Application Program Interface 17 November 2000
+
+
+ 1. Initialize an LDAP session with a primary LDAP server. The
+ ldap_init() function returns a handle to the session, allowing
+ multiple connections to be open at once.
+
+ 2. Authenticate to the LDAP server. The ldap_sasl_bind() function
+ and friends support a variety of authentication methods.
+
+ 3. Perform some LDAP operations and obtain some results.
+ ldap_search() and friends return results which can be parsed by
+ ldap_parse_result(), ldap_first_entry(), ldap_next_entry(), etc.
+
+ 4. Close the session. The ldap_unbind() function closes the connec-
+ tion.
+
+Operations can be performed either synchronously or asynchronously. The
+names of the synchronous functions end in _s. For example, a synchronous
+search can be completed by calling ldap_search_s(). An asynchronous
+search can be initiated by calling ldap_search(). All synchronous rou-
+tines return an indication of the outcome of the operation (e.g, the
+constant LDAP_SUCCESS or some other result code). The asynchronous rou-
+tines make available to the caller the message id of the operation ini-
+tiated. This id can be used in subsequent calls to ldap_result() to
+obtain the result(s) of the operation. An asynchronous operation can be
+abandoned by calling ldap_abandon() or ldap_abandon_ext(). Note that
+there is no requirement that an LDAP API implementation not block when
+handling asynchronous API functions; the term "asynchronous" as used in
+this document refers to the fact that the sending of LDAP requests can
+be separated from the receiving of LDAP responses.
+
+Results and errors are returned in an opaque structure called LDAPMes-
+sage. Routines are provided to parse this structure, step through
+entries and attributes returned, etc. Routines are also provided to
+interpret errors. Later sections of this document describe these rou-
+tines in more detail.
+
+LDAP version 3 servers can return referrals and references to other
+servers. By default, implementations of this API will attempt to follow
+referrals automatically for the application. This behavior can be dis-
+abled globally (using the ldap_set_option() call) or on a per-request
+basis through the use of a client control.
+
+All DN and string attribute values passed into or produced by this C
+LDAP API are represented using the character set of the underlying LDAP
+protocol version in use. When this API is used with LDAPv3, DN and
+string values are represented as UTF-8[6] characters. When this API is
+used with LDAPv2, the US-ASCII[7] or T.61[7] character set are used.
+Future documents MAY specify additional APIs supporting other character
+sets.
+
+
+
+Expires: May 2001 [Page 5]
+
+C LDAP API C LDAP Application Program Interface 17 November 2000
+
+
+For compatibility with existing applications, implementations of this
+API will by default use version 2 of the LDAP protocol. Applications
+that intend to take advantage of LDAP version 3 features will need to
+use the ldap_set_option() call with a LDAP_OPT_PROTOCOL_VERSION to
+switch to version 3.
+
+Unless otherwise indicated, conformant implementations of this specifi-
+cation MUST implement all of the C LDAP API functions as described in
+this document, and they MUST use the function prototypes, macro defini-
+tions, and types defined in this document.
+
+Note that this API is designed for use in environments where the 'int'
+type is at least 32 bits in size.
+
+
+6. Header Requirements
+
+To promote portability of applications, the following requirements are
+imposed on the headers used by applications to access the services of
+this API:
+
+Name and Inclusion
+ Applications only need to include a single header named ldap.h
+ to access all of the API services described in this document.
+ Therefore, the following C source program MUST compile and exe-
+ cute without errors:
+
+ #include <ldap.h>
+
+ int
+ main()
+ {
+ return 0;
+ }
+
+ The ldap.h header MAY include other implementation-specific
+ headers.
+
+Implementations SHOULD also provide a header named lber.h to facilitate
+development of applications desiring compatibility with older LDAP
+implementations. The lber.h header MAY be empty. Old applications that
+include lber.h in order to use BER facilities will need to include
+ldap.h.
+
+
+Idempotence
+ All headers SHOULD be idempotent; that is, if they are included
+ more than once the effect is as if they had only been included
+
+
+
+Expires: May 2001 [Page 6]
+
+C LDAP API C LDAP Application Program Interface 17 November 2000
+
+
+ once.
+
+Must Be Included Before API Is Used
+ An application MUST include the ldap.h header before referencing
+ any of the function or type definitions described in this API
+ specification.
+
+Mutual Independence
+ Headers SHOULD be mutually independent with minimal dependence
+ on system or any other headers.
+
+Use of the 'const' Keyword
+ This API specification is defined in terms of ISO C[8]. It
+ makes use of function prototypes and the 'const' keyword. The
+ use of 'const' in this specification is limited to simple, non-
+ array function parameters to avoid forcing applications to
+ declare parameters and variables that accept return values from
+ LDAP API functions as 'const.' Implementations specifically
+ designed to be used with non-ISO C translators SHOULD provide
+ function declarations without prototypes or function prototypes
+ without specification of 'const' arguments.
+
+Definition of 'struct timeval'
+ This API specification uses the 'struct timeval' type. Imple-
+ mentations of this API MUST ensure that the struct timeval type
+ is by default defined as a consequence of including the ldap.h
+ header. Because struct timeval is usually defined in one or
+ more system headers, it is possible for header conflicts to
+ occur if ldap.h also defines it or arranges for it to be defined
+ by including another header. Therefore, applications MAY want
+ to arrange for struct timeval to be defined before they include
+ ldap.h. To support this, the ldap.h header MUST NOT itself
+ define struct timeval if the preprocessor symbol
+ LDAP_TYPE_TIMEVAL_DEFINED is defined before ldap.h is included.
+
+
+7. Common Data Structures and Types
+
+Data structures and types that are common to several LDAP API functions
+are defined here:
+
+ typedef struct ldap LDAP;
+
+ typedef struct ldapmsg LDAPMessage;
+
+ typedef struct berelement BerElement;
+
+ typedef <impl_len_t> ber_len_t;
+
+
+
+Expires: May 2001 [Page 7]
+
+C LDAP API C LDAP Application Program Interface 17 November 2000
+
+
+ typedef struct berval {
+ ber_len_t bv_len;
+ char *bv_val;
+ } BerValue;
+
+ struct timeval {
+ <impl_sec_t> tv_sec;
+ <impl_usec_t> tv_usec;
+ };
+
+The LDAP structure is an opaque data type that represents an LDAP ses-
+sion Typically this corresponds to a connection to a single server, but
+it MAY encompass several server connections in the face of LDAPv3 refer-
+rals.
+
+The LDAPMessage structure is an opaque data type that is used to return
+entry, reference, result, and error information. An LDAPMessage struc-
+ture can represent the beginning of a list, or chain of messages that
+consists of a series of entries, references, and result messages as
+returned by LDAP operations such as search. LDAP API functions such as
+ldap_parse_result() that operate on message chains that can contain more
+than one result message always operate on the first result message in
+the chain. See the "Obtaining Results and Peeking Inside LDAP Messages"
+section of this document for more information.
+
+The BerElement structure is an opaque data type that is used to hold
+data and state information about encoded data. It is described in more
+detail in the section "Encoded ASN.1 Value Manipulation" later in this
+document.
+
+The `ber_len_t' type is an unsigned integral data type that is large
+enough to contain the length of the largest piece of data supported by
+the API implementation. The `<impl_len_t>' in the `ber_len_t' typedef
+MUST be replaced with an appropriate type. The width (number of signi-
+ficant bits) of `ber_len_t' MUST be at least 32 and no larger than that
+of `unsigned long'. See the appendix "Data Types and Legacy Implementa-
+tions" for additional considerations.
+
+The BerValue structure is used to represent arbitrary binary data and
+its fields have the following meanings:
+
+bv_len Length of data in bytes.
+
+bv_val A pointer to the data itself.
+
+
+The timeval structure is used to represent an interval of time and its
+fields have the following meanings:
+
+
+
+Expires: May 2001 [Page 8]
+
+C LDAP API C LDAP Application Program Interface 17 November 2000
+
+
+tv_sec Seconds component of time interval.
+
+tv_usec Microseconds component of time interval.
+
+Note that because the struct timeval definition typically is derived
+from a system header, the types used for the tv_sec and tv_usec com-
+ponents are implementation-specific integral types. Therefore,
+`<impl_sec_t>' and `<impl_usec_t>' in the struct timeval definition MUST
+be replaced with appropriate types. See the earlier section "Header
+Requirements" for more information on struct timeval.
+
+
+8. Memory Handling Overview
+
+All memory that is allocated by a function in this C LDAP API and
+returned to the caller SHOULD be disposed of by calling the appropriate
+"free" function provided by this API. The correct "free" function to
+call is documented in each section of this document where a function
+that allocates memory is described.
+
+Memory that is allocated through means outside of the C LDAP API MUST
+NOT be disposed of using a function provided by this API.
+
+If a pointer value passed to one of the C LDAP API "free" functions is
+NULL, graceful failure (i.e, ignoring of the NULL pointer) MUST occur.
+
+The complete list of "free" functions that are used to dispose of allo-
+cated memory is:
+
+ ber_bvecfree()
+ ber_bvfree()
+ ber_free()
+ ldap_control_free()
+ ldap_controls_free()
+ ldap_memfree()
+ ldap_msgfree()
+ ldap_value_free()
+ ldap_value_free_len()
+
+
+9. Retrieving Information About the API Implementation
+
+Applications developed to this specification need to be able to deter-
+mine information about the particular API implementation they are using
+both at compile time and during execution.
+
+
+
+
+
+
+Expires: May 2001 [Page 9]
+
+C LDAP API C LDAP Application Program Interface 17 November 2000
+
+
+9.1. Retrieving Information at Compile Time
+
+All conformant implementations MUST include the following five defini-
+tions in a header so compile time tests can be done by LDAP software
+developers:
+
+ #define LDAP_API_VERSION level
+ #define LDAP_VERSION_MIN min-version
+ #define LDAP_VERSION_MAX max-version
+ #define LDAP_VENDOR_NAME "vend-name"
+ #define LDAP_VENDOR_VERSION vend-version
+
+where:
+
+ "level" is replaced with the RFC number given to this C LDAP API
+ specification when it is published as a standards track RFC.
+
+ min-version is replaced with the lowest LDAP protocol version sup-
+ ported by the implementation.
+
+ max-version is replaced with the highest LDAP protocol version sup-
+ ported by the implementation. This SHOULD be 3.
+
+ "vend-name" is replaced with a text string that identifies the
+ party that supplies the API implementation.
+
+ "vend-version" is a supplier-specific version number multiplied
+ times 100.
+
+Note that the LDAP_VENDOR_NAME macro SHOULD be defined as "" if no ven-
+dor name is available and the LDAP_VENDOR_VERSION macro SHOULD be
+defined as 0 if no vendor-specific version information is available.
+
+For example, if this specification is published as RFC 88888, Netscape
+Communication's version 4.0 implementation that supports LDAPv2 and v3
+might include macro definitions like these:
+
+ #define LDAP_API_VERSION 88888 /* RFC 88888 compliant */
+ #define LDAP_VERSION_MIN 2
+ #define LDAP_VERSION_MAX 3
+ #define LDAP_VENDOR_NAME "Netscape Communications Corp."
+ #define LDAP_VENDOR_VERSION 400 /* version 4.0 */
+
+and application code can test the C LDAP API version level using a
+construct such as this one:
+
+ #if (LDAP_API_VERSION >= 88888)
+ /* use features supported in RFC 88888 or later */
+
+
+
+Expires: May 2001 [Page 10]
+
+C LDAP API C LDAP Application Program Interface 17 November 2000
+
+
+ #endif
+
+Until such time as this document is published as an RFC, implementations
+SHOULD use the value 2000 plus the revision number of this draft for
+LDAP_API_VERSION. For example, the correct value for LDAP_API_VERSION
+for revision 05 of this draft is 2005.
+
+Documents that extend this specification SHOULD define a macro of the
+form:
+
+ #define LDAP_API_FEATURE_x level
+
+where "x" is replaced with a name (textual identifier) for the feature
+and "level" is replaced with the number of the RFC that specifies the
+API extension. The name SHOULD NOT begin with the string "X_".
+
+For example, if C LDAP API extensions for Transport Layer Security [9]
+were published in RFC 99999, that RFC might require conformant implemen-
+tations to define a macro like this:
+
+ #define LDAP_API_FEATURE_TLS 99999
+
+
+Private or experimental API extensions SHOULD be indicated by defining a
+macro of this same form where "x" (the extension's name) begins with the
+string "X_" and "level" is replaced with a integer number that is
+specific to the extension.
+
+It is RECOMMENDED that private or experimental API extensions use only
+the following prefixes for macros, types, and function names:
+ LDAP_X_
+ LBER_X_
+ ldap_x_
+ ber_x_
+and that these prefixes not be used by standard extensions.
+
+
+9.2. Retrieving Information During Execution
+
+The ldap_get_option() call (described in greater detail later in this
+document) can be used during execution in conjunction with an option
+parameter value of LDAP_OPT_API_INFO (0x00) to retrieve some basic
+information about the API and about the specific implementation being
+used. The ld parameter to ldap_get_option() can be either NULL or a
+valid LDAP session handle which was obtained by calling ldap_init().
+The optdata parameter to ldap_get_option() SHOULD be the address of an
+LDAPAPIInfo structure which is defined as follows:
+
+
+
+
+Expires: May 2001 [Page 11]
+
+C LDAP API C LDAP Application Program Interface 17 November 2000
+
+
+ typedef struct ldapapiinfo {
+ int ldapai_info_version; /* version of this struct (1) */
+ int ldapai_api_version; /* revision of API supported */
+ int ldapai_protocol_version; /* highest LDAP version supported */
+ char **ldapai_extensions; /* names of API extensions */
+ char *ldapai_vendor_name; /* name of supplier */
+ int ldapai_vendor_version; /* supplier-specific version times 100 */
+ } LDAPAPIInfo;
+
+In addition, API implementations MUST include the following macro defin-
+ition:
+
+ #define LDAP_API_INFO_VERSION 1
+
+Note that the ldapai_info_version field of the LDAPAPIInfo structure
+SHOULD be set to the value LDAP_API_INFO_VERSION (1) before calling
+ldap_get_option() so that it can be checked for consistency. All other
+fields are set by the ldap_get_option() function.
+
+The members of the LDAPAPIInfo structure are:
+
+ldapai_info_version
+ A number that identifies the version of the LDAPAPIInfo struc-
+ ture. This SHOULD be set to the value LDAP_API_INFO_VERSION
+ (1) before calling ldap_get_option(). If the value received
+ is not recognized by the API implementation, the
+ ldap_get_option() function sets ldapai_info_version to a valid
+ value that would be recognized, sets the ldapai_api_version to
+ the correct value, and returns an error without filling in any
+ of the other fields in the LDAPAPIInfo structure.
+
+ldapai_api_version
+ A number that matches that assigned to the C LDAP API RFC sup-
+ ported by the API implementation. This SHOULD match the value
+ of the LDAP_API_VERSION macro defined earlier.
+
+ldapai_protocol_version
+ The highest LDAP protocol version supported by the implementa-
+ tion. For example, if LDAPv3 is the highest version supported
+ then this field will be set to 3.
+
+ldapai_vendor_name
+ A zero-terminated string that contains the name of the party
+ that produced the LDAP API implementation. This field may be
+ set to NULL if no name is available. If non-NULL, the caller
+ is responsible for disposing of the memory occupied by passing
+ this pointer to ldap_memfree() which is described later in
+ this document. This value SHOULD match the value of the
+
+
+
+Expires: May 2001 [Page 12]
+
+C LDAP API C LDAP Application Program Interface 17 November 2000
+
+
+ LDAP_VENDOR_NAME macro described earlier in this document.
+
+ldapai_vendor_version
+ An implementation-specific version number multiplied by 100.
+ For example, if the implementation version is 4.0 then this
+ field will be set to 400. If no version information is avail-
+ able, this field will be set to 0. This value SHOULD match
+ the value of the LDAP_VENDOR_VERSION macro described earlier
+ in this document.
+
+ldapai_extensions
+ A NULL-terminated array of character strings that lists the
+ names of the API extensions supported by the LDAP API imple-
+ mentation. These names will typically match the textual iden-
+ tifiers that appear in the "x" portion of the
+ LDAP_API_FEATURE_x macros described above, although the pre-
+ cise value MUST be defined by documents that specify C LDAP
+ API extensions. If no API extensions are supported, this
+ field will be set to NULL. The caller is responsible for
+ disposing of the memory occupied by this array by passing it
+ to ldap_value_free() which is described later in this docu-
+ ment. To retrieve more information about a particular exten-
+ sion, the ldap_get_option() call can be used with an option
+ parameter value of LDAP_OPT_API_FEATURE_INFO (0x15). The opt-
+ data parameter to the ldap_get_option() SHOULD be the address
+ of an LDAPAPIFeatureInfo structure which is defined as fol-
+ lows:
+
+ typedef struct ldap_apifeature_info {
+ int ldapaif_info_version; /* version of this struct (1) */
+ char *ldapaif_name; /* name of supported feature */
+ int ldapaif_version; /* revision of supported feature */
+ } LDAPAPIFeatureInfo;
+
+ In addition, API implementations MUST include the following
+ macro definition:
+
+ #define LDAP_FEATURE_INFO_VERSION 1
+
+ Note that the ldapaif_info_version field of the LDAPAPI-
+ FeatureInfo structure SHOULD be set to the value
+ LDAP_FEATURE_INFO_VERSION (1) and the ldapaif_name field
+ SHOULD be set to the extension name string as described below
+ before ldap_get_option() is called. The call will fill in the
+ ldapaif_version field of the LDAPAPIFeatureInfo structure.
+
+ The members of the LDAPAPIFeatureInfo structure are:
+
+
+
+
+Expires: May 2001 [Page 13]
+
+C LDAP API C LDAP Application Program Interface 17 November 2000
+
+
+ ldapaif_info_version
+ A number that identifies the version of the LDAPAPI-
+ FeatureInfo structure. This SHOULD be set to the value
+ LDAP_FEATURE_INFO_VERSION (1) before calling
+ ldap_get_option(). If the value received is not recognized
+ by the API implementation, the ldap_get_option() function
+ sets ldapaif_info_version to a valid value that would be
+ recognized and returns an error without filling in the
+ ldapaif_version field in the LDAPAPIFeatureInfo structure.
+
+ ldapaif_name
+ The name of an extension, as returned in the
+ ldapai_extensions array of the LDAPAPIInfo structure and as
+ specified in the document that describes the extension.
+
+ ldapaif_version
+ This field will be set as a result of calling
+ ldap_get_option(). It is a number that matches that
+ assigned to the C LDAP API extension RFC supported for this
+ extension. For private or experimental API extensions, the
+ value is extension-specific. In either case, the value of
+ ldapaxi_ext_version SHOULD be identical to the value of the
+ LDAP_API_FEATURE_x macro defined for the extension
+ (described above).
+
+
+10. Result Codes
+
+Many of the LDAP API routines return result codes, some of which indi-
+cate local API errors and some of which are LDAP resultCodes that are
+returned by servers. All of the result codes are non-negative integers.
+Supported result codes are as follows (hexadecimal values are given in
+parentheses after the constant):
+
+ LDAP_SUCCESS (0x00)
+ LDAP_OPERATIONS_ERROR (0x01)
+ LDAP_PROTOCOL_ERROR (0x02)
+ LDAP_TIMELIMIT_EXCEEDED (0x03)
+ LDAP_SIZELIMIT_EXCEEDED (0x04)
+ LDAP_COMPARE_FALSE (0x05)
+ LDAP_COMPARE_TRUE (0x06)
+ LDAP_STRONG_AUTH_NOT_SUPPORTED (0x07)
+ LDAP_STRONG_AUTH_REQUIRED (0x08)
+ LDAP_REFERRAL (0x0a) -- new in LDAPv3
+ LDAP_ADMINLIMIT_EXCEEDED (0x0b) -- new in LDAPv3
+ LDAP_UNAVAILABLE_CRITICAL_EXTENSION (0x0c) -- new in LDAPv3
+ LDAP_CONFIDENTIALITY_REQUIRED (0x0d) -- new in LDAPv3
+ LDAP_SASL_BIND_IN_PROGRESS (0x0e) -- new in LDAPv3
+
+
+
+Expires: May 2001 [Page 14]
+
+C LDAP API C LDAP Application Program Interface 17 November 2000
+
+
+ LDAP_NO_SUCH_ATTRIBUTE (0x10)
+ LDAP_UNDEFINED_TYPE (0x11)
+ LDAP_INAPPROPRIATE_MATCHING (0x12)
+ LDAP_CONSTRAINT_VIOLATION (0x13)
+ LDAP_TYPE_OR_VALUE_EXISTS (0x14)
+ LDAP_INVALID_SYNTAX (0x15)
+ LDAP_NO_SUCH_OBJECT (0x20)
+ LDAP_ALIAS_PROBLEM (0x21)
+ LDAP_INVALID_DN_SYNTAX (0x22)
+ LDAP_IS_LEAF (0x23) -- not used in LDAPv3
+ LDAP_ALIAS_DEREF_PROBLEM (0x24)
+ LDAP_INAPPROPRIATE_AUTH (0x30)
+ LDAP_INVALID_CREDENTIALS (0x31)
+ LDAP_INSUFFICIENT_ACCESS (0x32)
+ LDAP_BUSY (0x33)
+ LDAP_UNAVAILABLE (0x34)
+ LDAP_UNWILLING_TO_PERFORM (0x35)
+ LDAP_LOOP_DETECT (0x36)
+ LDAP_NAMING_VIOLATION (0x40)
+ LDAP_OBJECT_CLASS_VIOLATION (0x41)
+ LDAP_NOT_ALLOWED_ON_NONLEAF (0x42)
+ LDAP_NOT_ALLOWED_ON_RDN (0x43)
+ LDAP_ALREADY_EXISTS (0x44)
+ LDAP_NO_OBJECT_CLASS_MODS (0x45)
+ LDAP_RESULTS_TOO_LARGE (0x46) -- reserved for CLDAP
+ LDAP_AFFECTS_MULTIPLE_DSAS (0x47) -- new in LDAPv3
+ LDAP_OTHER (0x50)
+ LDAP_SERVER_DOWN (0x51)
+ LDAP_LOCAL_ERROR (0x52)
+ LDAP_ENCODING_ERROR (0x53)
+ LDAP_DECODING_ERROR (0x54)
+ LDAP_TIMEOUT (0x55)
+ LDAP_AUTH_UNKNOWN (0x56)
+ LDAP_FILTER_ERROR (0x57)
+ LDAP_USER_CANCELLED (0x58)
+ LDAP_PARAM_ERROR (0x59)
+ LDAP_NO_MEMORY (0x5a)
+ LDAP_CONNECT_ERROR (0x5b)
+ LDAP_NOT_SUPPORTED (0x5c)
+ LDAP_CONTROL_NOT_FOUND (0x5d)
+ LDAP_NO_RESULTS_RETURNED (0x5e)
+ LDAP_MORE_RESULTS_TO_RETURN (0x5f)
+ LDAP_CLIENT_LOOP (0x60)
+ LDAP_REFERRAL_LIMIT_EXCEEDED (0x61)
+
+
+
+
+
+
+
+Expires: May 2001 [Page 15]
+
+C LDAP API C LDAP Application Program Interface 17 November 2000
+
+
+11. Performing LDAP Operations
+
+This section describes each LDAP operation API call in detail. Most
+functions take a "session handle," a pointer to an LDAP structure con-
+taining per-connection information. Many routines return results in an
+LDAPMessage structure. These structures and others are described as
+needed below.
+
+
+11.1. Initializing an LDAP Session
+
+ldap_init() initializes a session with an LDAP server. The server is not
+actually contacted until an operation is performed that requires it,
+allowing various options to be set after initialization.
+
+ LDAP *ldap_init(
+ const char *hostname,
+ int portno
+ );
+
+Use of the following routine is deprecated:
+
+ LDAP *ldap_open(
+ const char *hostname,
+ int portno
+ );
+
+Unlike ldap_init(), ldap_open() attempts to make a server connection
+before returning to the caller. A more complete description can be
+found in RFC 1823.
+
+Parameters are:
+
+hostname Contains a space-separated list of hostnames or dotted strings
+ representing the IP address of hosts running an LDAP server to
+ connect to. Each hostname in the list MAY include a port number
+ which is separated from the host itself with a colon (:) char-
+ acter. The hosts will be tried in the order listed, stopping
+ with the first one to which a successful connection is made.
+
+ Note: A suitable representation for including a literal IPv6[10]
+ address in the hostname parameter is desired, but has not yet been
+ determined or implemented in practice.
+
+portno Contains the TCP port number to connect to. The default LDAP
+ port of 389 can be obtained by supplying the value zero (0) or
+ the macro LDAP_PORT (389). If a host includes a port number
+ then this parameter is ignored.
+
+
+
+Expires: May 2001 [Page 16]
+
+C LDAP API C LDAP Application Program Interface 17 November 2000
+
+
+ldap_init() and ldap_open() both return a "session handle," a pointer to
+an opaque structure that MUST be passed to subsequent calls pertaining
+to the session. These routines return NULL if the session cannot be ini-
+tialized in which case the operating system error reporting mechanism
+can be checked to see why the call failed.
+
+Note that if you connect to an LDAPv2 server, one of the LDAP bind calls
+described below SHOULD be completed before other operations can be per-
+formed on the session. LDAPv3 does not require that a bind operation be
+completed before other operations can be performed.
+
+The calling program can set various attributes of the session by calling
+the routines described in the next section.
+
+
+11.2. LDAP Session Handle Options
+
+The LDAP session handle returned by ldap_init() is a pointer to an
+opaque data type representing an LDAP session. In RFC 1823 this data
+type was a structure exposed to the caller, and various fields in the
+structure could be set to control aspects of the session, such as size
+and time limits on searches.
+
+In the interest of insulating callers from inevitable changes to this
+structure, these aspects of the session are now accessed through a pair
+of accessor functions, described below.
+
+ldap_get_option() is used to access the current value of various
+session-wide parameters. ldap_set_option() is used to set the value of
+these parameters. Note that some options are READ-ONLY and cannot be
+set; it is an error to call ldap_set_option() and attempt to set a
+READ-ONLY option.
+
+Note that if automatic referral following is enabled (the default), any
+connections created during the course of following referrals will
+inherit the options associated with the session that sent the original
+request that caused the referrals to be returned.
+
+ int ldap_get_option(
+ LDAP *ld,
+ int option,
+ void *outvalue
+ );
+
+ int ldap_set_option(
+ LDAP *ld,
+ int option,
+ const void *invalue
+
+
+
+Expires: May 2001 [Page 17]
+
+C LDAP API C LDAP Application Program Interface 17 November 2000
+
+
+ );
+
+ #define LDAP_OPT_ON (<impl_void_star_value>)
+ #define LDAP_OPT_OFF ((void *)0)
+
+ LDAP_OPT_ON MUST be defined as a non-null pointer to void; that is,
+ <impl_void_star_value> MUST be replaced with a non-null pointer to
+ void, e.g., one could use:
+ #define LDAP_OPT_ON ((void *)1)
+ if that value is safe to use on the architecture where the API is
+ implemented.
+
+Parameters are:
+
+ld The session handle. If this is NULL, a set of global defaults is
+ accessed. New LDAP session handles created with ldap_init() or
+ ldap_open() inherit their characteristics from these global
+ defaults.
+
+option The name of the option being accessed or set. This parameter
+ SHOULD be one of the following constants, which have the indi-
+ cated meanings. After the constant the actual hexadecimal value
+ of the constant is listed in parentheses.
+
+
+ LDAP_OPT_API_INFO (0x00)
+ Type for invalue parameter: not applicable (option is READ-ONLY)
+
+ Type for outvalue parameter: LDAPAPIInfo *
+
+ Description:
+ Used to retrieve some basic information about the LDAP API
+ implementation at execution time. See the section "Retriev-
+ ing Information About the API Implementation" above for more
+ information. This option is READ-ONLY and cannot be set.
+
+ LDAP_OPT_DEREF (0x02)
+ Type for invalue parameter: int *
+
+ Type for outvalue parameter: int *
+
+ Description:
+ Determines how aliases are handled during search. It SHOULD
+ have one of the following values: LDAP_DEREF_NEVER (0x00),
+ LDAP_DEREF_SEARCHING (0x01), LDAP_DEREF_FINDING (0x02), or
+ LDAP_DEREF_ALWAYS (0x03). The LDAP_DEREF_SEARCHING value
+ means aliases are dereferenced during the search but not when
+ locating the base object of the search. The
+
+
+
+Expires: May 2001 [Page 18]
+
+C LDAP API C LDAP Application Program Interface 17 November 2000
+
+
+ LDAP_DEREF_FINDING value means aliases are dereferenced when
+ locating the base object but not during the search. The
+ default value for this option is LDAP_DEREF_NEVER.
+
+ LDAP_OPT_SIZELIMIT (0x03)
+ Type for invalue parameter: int *
+
+ Type for outvalue parameter: int *
+
+ Description:
+ A limit on the number of entries to return from a search. A
+ value of LDAP_NO_LIMIT (0) means no limit. The default value
+ for this option is LDAP_NO_LIMIT.
+
+ LDAP_OPT_TIMELIMIT (0x04)
+ Type for invalue parameter: int *
+
+ Type for outvalue parameter: int *
+
+ Description:
+ A limit on the number of seconds to spend on a search. A
+ value of LDAP_NO_LIMIT (0) means no limit. The default value
+ for this option is LDAP_NO_LIMIT. This value is passed to
+ the server in the search request only; it does not affect how
+ long the C LDAP API implementation itself will wait locally
+ for search results. Note that the timeout parameter passed
+ to the ldap_search_ext_s() or ldap_result() functions can be
+ used to specify a limit on how long the API implementation
+ will wait for results.
+
+ LDAP_OPT_REFERRALS (0x08)
+ Type for invalue parameter: void * (LDAP_OPT_ON or LDAP_OPT_OFF)
+
+ Type for outvalue parameter: int *
+
+ Description:
+ Determines whether the LDAP library automatically follows
+ referrals returned by LDAP servers or not. It MAY be set to
+ one of the constants LDAP_OPT_ON or LDAP_OPT_OFF; any non-
+ NULL pointer value passed to ldap_set_option() enables this
+ option. When reading the current setting using
+ ldap_get_option(), a zero value means OFF and any non-zero
+ value means ON. By default, this option is ON.
+
+ LDAP_OPT_RESTART (0x09)
+ Type for invalue parameter: void * (LDAP_OPT_ON or LDAP_OPT_OFF)
+
+ Type for outvalue parameter: int *
+
+
+
+Expires: May 2001 [Page 19]
+
+C LDAP API C LDAP Application Program Interface 17 November 2000
+
+
+ Description:
+ Determines whether LDAP I/O operations are automatically res-
+ tarted if they abort prematurely. It MAY be set to one of the
+ constants LDAP_OPT_ON or LDAP_OPT_OFF; any non-NULL pointer
+ value passed to ldap_set_option() enables this option. When
+ reading the current setting using ldap_get_option(), a zero
+ value means OFF and any non-zero value means ON. This option
+ is useful if an LDAP I/O operation can be interrupted prema-
+ turely, for example by a timer going off, or other interrupt.
+ By default, this option is OFF.
+
+ LDAP_OPT_PROTOCOL_VERSION (0x11)
+ Type for invalue parameter: int *
+
+ Type for outvalue parameter: int *
+
+ Description:
+ This option indicates the version of the LDAP protocol used
+ when communicating with the primary LDAP server. It SHOULD be
+ one of the constants LDAP_VERSION2 (2) or LDAP_VERSION3 (3).
+ If no version is set the default is LDAP_VERSION2 (2).
+
+ LDAP_OPT_SERVER_CONTROLS (0x12)
+ Type for invalue parameter: LDAPControl **
+
+ Type for outvalue parameter: LDAPControl ***
+
+ Description:
+ A default list of LDAP server controls to be sent with each
+ request. See the Working With Controls section below.
+
+ LDAP_OPT_CLIENT_CONTROLS (0x13)
+ Type for invalue parameter: LDAPControl **
+
+ Type for outvalue parameter: LDAPControl ***
+
+ Description:
+ A default list of client controls that affect the LDAP ses-
+ sion. See the Working With Controls section below.
+
+ LDAP_OPT_API_FEATURE_INFO (0x15)
+ Type for invalue parameter: not applicable (option is READ-ONLY)
+
+ Type for outvalue parameter: LDAPAPIFeatureInfo *
+
+ Description:
+ Used to retrieve version information about LDAP API extended
+ features at execution time. See the section "Retrieving
+
+
+
+Expires: May 2001 [Page 20]
+
+C LDAP API C LDAP Application Program Interface 17 November 2000
+
+
+ Information About the API Implementation" above for more
+ information. This option is READ-ONLY and cannot be set.
+
+ LDAP_OPT_HOST_NAME (0x30)
+ Type for invalue parameter: char *
+
+ Type for outvalue parameter: char **
+
+ Description:
+ The host name (or list of hosts) for the primary LDAP server.
+ See the definition of the hostname parameter to ldap_init()
+ for the allowed syntax. Note that if the portno parameter
+ passed to ldap_init() is a value other than 0 or 389
+ (LDAP_PORT), this value SHOULD include a string like
+ ":portno" after each hostname or IP address that did not have
+ one in the original hostname parameter that was passed to
+ ldap_init(). For example, if this hostname value was passed
+ to ldap_init():
+
+ "ldap.example.com:389 ldap2.example.com"
+
+ and the portno parameter passed to ldap_init() was 6389, then
+ the value returned for the LDAP_OPT_HOST_NAME option SHOULD
+ be:
+
+ "ldap.example.com:389 ldap2.example.com:6389"
+
+
+ LDAP_OPT_RESULT_CODE (0x31)
+ Type for invalue parameter: int *
+
+ Type for outvalue parameter: int *
+
+ Description:
+ The most recent local (API generated) or server returned LDAP
+ result code that occurred for this session.
+
+ LDAP_OPT_ERROR_STRING (0x32)
+ Type for invalue parameter: char *
+
+ Type for outvalue parameter: char **
+
+ Description:
+ The message returned with the most recent LDAP error that
+ occurred for this session.
+
+ LDAP_OPT_MATCHED_DN (0x33)
+ Type for invalue parameter: char *
+
+
+
+Expires: May 2001 [Page 21]
+
+C LDAP API C LDAP Application Program Interface 17 November 2000
+
+
+ Type for outvalue parameter: char **
+
+ Description:
+ The matched DN value returned with the most recent LDAP error
+ that occurred for this session.
+
+
+outvalue The address of a place to put the value of the option. The
+ actual type of this parameter depends on the setting of the
+ option parameter. For outvalues of type char ** and LDAPCon-
+ trol **, a copy of the data that is associated with the LDAP
+ session ld is returned; callers should dispose of the memory by
+ calling ldap_memfree() or ldap_controls_free(), depending on
+ the type of data returned.
+
+invalue A pointer to the value the option is to be given. The actual
+ type of this parameter depends on the setting of the option
+ parameter. The data associated with invalue is copied by the
+ API implementation to allow callers of the API to dispose of or
+ otherwise change their copy of the data after a successful call
+ to ldap_set_option(). If a value passed for invalue is invalid
+ or cannot be accepted by the implementation, ldap_set_option()
+ should return -1 to indicate an error.
+
+Both ldap_get_option() and ldap_set_option() return 0 if successful and
+-1 if an error occurs. If -1 is returned by either function, a specific
+result code MAY be retrieved by calling ldap_get_option() with an option
+value of LDAP_OPT_RESULT_CODE. Note that there is no way to retrieve a
+more specific result code if a call to ldap_get_option() with an option
+value of LDAP_OPT_RESULT_CODE fails.
+
+When a call to ldap_get_option() succeeds, the API implementation MUST
+NOT change the state of the LDAP session handle or the state of the
+underlying implementation in a way that affects the behavior of future
+LDAP API calls. When a call to ldap_get_option() fails, the only ses-
+sion handle change permitted is setting the LDAP result code (as
+returned by the LDAP_OPT_RESULT_CODE option).
+
+When a call to ldap_set_option() fails, it MUST NOT change the state of
+the LDAP session handle or the state of the underlying implementation in
+a way that affects the behavior of future LDAP API calls.
+
+Standards track documents that extend this specification and specify new
+options SHOULD use values for option macros that are between 0x1000 and
+0x3FFF inclusive. Private and experimental extensions SHOULD use values
+for the option macros that are between 0x4000 and 0x7FFF inclusive. All
+values below 0x1000 and above 0x7FFF that are not defined in this docu-
+ment are reserved and SHOULD NOT be used. The following macro MUST be
+
+
+
+Expires: May 2001 [Page 22]
+
+C LDAP API C LDAP Application Program Interface 17 November 2000
+
+
+defined by C LDAP API implementations to aid extension implementors:
+ #define LDAP_OPT_PRIVATE_EXTENSION_BASE 0x4000 /* to 0x7FFF inclusive */
+
+
+
+11.3. Working With Controls
+
+LDAPv3 operations can be extended through the use of controls. Controls
+can be sent to a server or returned to the client with any LDAP message.
+These controls are referred to as server controls.
+
+The LDAP API also supports a client-side extension mechanism through the
+use of client controls. These controls affect the behavior of the LDAP
+API only and are never sent to a server. A common data structure is
+used to represent both types of controls:
+
+ typedef struct ldapcontrol {
+ char *ldctl_oid;
+ struct berval ldctl_value;
+ char ldctl_iscritical;
+ } LDAPControl;
+
+The fields in the ldapcontrol structure have the following meanings:
+
+ldctl_oid The control type, represented as a string.
+
+ldctl_value The data associated with the control (if any). To
+ specify a zero-length value, set ldctl_value.bv_len to
+ zero and ldctl_value.bv_val to a zero-length string.
+ To indicate that no data is associated with the con-
+ trol, set ldctl_value.bv_val to NULL.
+
+ldctl_iscritical Indicates whether the control is critical of not. If
+ this field is non-zero, the operation will only be car-
+ ried out if the control is recognized by the server
+ and/or client. Note that the LDAP unbind and abandon
+ operations have no server response, so clients SHOULD
+ NOT mark server controls critical when used with these
+ two operations.
+
+Some LDAP API calls allocate an ldapcontrol structure or a NULL-
+terminated array of ldapcontrol structures. The following routines can
+be used to dispose of a single control or an array of controls:
+
+ void ldap_control_free( LDAPControl *ctrl );
+ void ldap_controls_free( LDAPControl **ctrls );
+If the ctrl or ctrls parameter is NULL, these calls do nothing.
+
+
+
+
+Expires: May 2001 [Page 23]
+
+C LDAP API C LDAP Application Program Interface 17 November 2000
+
+
+A set of controls that affect the entire session can be set using the
+ldap_set_option() function (see above). A list of controls can also be
+passed directly to some LDAP API calls such as ldap_search_ext(), in
+which case any controls set for the session through the use of
+ldap_set_option() are ignored. Control lists are represented as a NULL-
+terminated array of pointers to ldapcontrol structures.
+
+Server controls are defined by LDAPv3 protocol extension documents; for
+example, a control has been proposed to support server-side sorting of
+search results [11].
+
+One client control is defined in this document (described in the follow-
+ing section). Other client controls MAY be defined in future revisions
+of this document or in documents that extend this API.
+
+
+11.3.1. A Client Control That Governs Referral Processing
+
+As described previously in the section "LDAP Session Handle Options,"
+applications can enable and disable automatic chasing of referrals on a
+session-wide basic by using the ldap_set_option() function with the
+LDAP_OPT_REFERRALS option. It is also useful to govern automatic refer-
+ral chasing on per-request basis. A client control with an OID of
+1.2.840.113556.1.4.616 exists to provide this functionality.
+
+ /* OID for referrals client control */
+ #define LDAP_CONTROL_REFERRALS "1.2.840.113556.1.4.616"
+
+ /* Flags for referrals client control value */
+ #define LDAP_CHASE_SUBORDINATE_REFERRALS 0x00000020U
+ #define LDAP_CHASE_EXTERNAL_REFERRALS 0x00000040U
+
+To create a referrals client control, the ldctl_oid field of an LDAPCon-
+trol structure MUST be set to LDAP_CONTROL_REFERRALS
+("1.2.840.113556.1.4.616") and the ldctl_value field MUST be set to a
+value that contains a set of flags. The ldctl_value.bv_len field MUST
+be set to sizeof(ber_uint_t), and the ldctl_value.bv_val field MUST
+point to a ber_uint_t which contains the flags value." The ber_uint_t
+type is define in the section "BER Data Structures and Types" below.
+
+The flags value can be set to zero to disable automatic chasing of
+referrals and LDAPv3 references altogether. Alternatively, the flags
+value can be set to the value LDAP_CHASE_SUBORDINATE_REFERRALS
+(0x00000020U) to indicate that only LDAPv3 search continuation refer-
+ences are to be automatically chased by the API implementation, to the
+value LDAP_CHASE_EXTERNAL_REFERRALS (0x00000040U) to indicate that only
+LDAPv3 referrals are to be automatically chased, or the logical OR of
+the two flag values (0x00000060U) to indicate that both referrals and
+
+
+
+Expires: May 2001 [Page 24]
+
+C LDAP API C LDAP Application Program Interface 17 November 2000
+
+
+references are to be automatically chased.
+
+
+11.4. Authenticating to the directory
+
+The following functions are used to authenticate an LDAP client to an
+LDAP directory server.
+
+The ldap_sasl_bind() and ldap_sasl_bind_s() functions can be used to do
+general and extensible authentication over LDAP through the use of the
+Simple Authentication Security Layer [12]. The routines both take the
+dn to bind as, the method to use, as a dotted-string representation of
+an OID identifying the method, and a struct berval holding the creden-
+tials. The special constant value LDAP_SASL_SIMPLE (NULL) can be passed
+to request simple authentication, or the simplified routines
+ldap_simple_bind() or ldap_simple_bind_s() can be used.
+
+ int ldap_sasl_bind(
+ LDAP *ld,
+ const char *dn,
+ const char *mechanism,
+ const struct berval *cred,
+ LDAPControl **serverctrls,
+ LDAPControl **clientctrls,
+ int *msgidp
+ );
+
+ int ldap_sasl_bind_s(
+ LDAP *ld,
+ const char *dn,
+ const char *mechanism,
+ const struct berval *cred,
+ LDAPControl **serverctrls,
+ LDAPControl **clientctrls,
+ struct berval **servercredp
+ );
+
+ int ldap_simple_bind(
+ LDAP *ld,
+ const char *dn,
+ const char *passwd
+ );
+
+ int ldap_simple_bind_s(
+ LDAP *ld,
+ const char *dn,
+ const char *passwd
+ );
+
+
+
+Expires: May 2001 [Page 25]
+
+C LDAP API C LDAP Application Program Interface 17 November 2000
+
+
+ The use of the following routines is deprecated and more complete
+ descriptions can be found in RFC 1823:
+
+ int ldap_bind( LDAP *ld, const char *dn, const char *cred,
+ int method );
+
+ int ldap_bind_s( LDAP *ld, const char *dn, const char *cred,
+ int method );
+
+ int ldap_kerberos_bind( LDAP *ld, const char *dn );
+
+ int ldap_kerberos_bind_s( LDAP *ld, const char *dn );
+
+Parameters are:
+
+ld The session handle.
+
+dn The name of the entry to bind as. If NULL, a zero length
+ DN is sent to the server.
+
+mechanism Either LDAP_SASL_SIMPLE (NULL) to get simple authentica-
+ tion, or a text string identifying the SASL method.
+
+cred The credentials with which to authenticate. Arbitrary
+ credentials can be passed using this parameter. The format
+ and content of the credentials depends on the setting of
+ the mechanism parameter. If the cred parameter is NULL and
+ the mechanism is LDAP_SASL_SIMPLE, a zero-length octet
+ string is sent to the server in the simple credentials
+ field of the bind request. If the cred parameter is NULL
+ and the mechanism is anything else, no credentials are sent
+ to the server in the bind request.
+
+passwd For ldap_simple_bind(), the password that is sent to the
+ server in the simple credentials field of the bind request.
+ If NULL, a zero length password is sent to the server.
+
+serverctrls List of LDAP server controls, or NULL if no server controls
+ are used.
+
+clientctrls List of client controls, or NULL if no client controls are
+ used.
+
+msgidp This result parameter will be set to the message id of the
+ request if the ldap_sasl_bind() call succeeds. The value
+ is undefined if a value other than LDAP_SUCCESS is
+ returned.
+
+
+
+
+Expires: May 2001 [Page 26]
+
+C LDAP API C LDAP Application Program Interface 17 November 2000
+
+
+servercredp This result parameter will be filled in with the creden-
+ tials passed back by the server for mutual authentication,
+ if given. An allocated berval structure is returned that
+ SHOULD be disposed of by calling ber_bvfree(). NULL SHOULD
+ be passed to ignore this field. If an API error occurs or
+ the server did not return any credentials, *servercredp is
+ set to NULL.
+
+Additional parameters for the deprecated routines are not described.
+Interested readers are referred to RFC 1823.
+
+The ldap_sasl_bind() function initiates an asynchronous bind operation
+and returns the constant LDAP_SUCCESS if the request was successfully
+sent, or another LDAP result code if not. See the section below on
+error handling for more information about possible errors and how to
+interpret them. If successful, ldap_sasl_bind() places the message id
+of the request in *msgidp. A subsequent call to ldap_result(), described
+below, can be used to obtain the result of the bind.
+
+The ldap_simple_bind() function initiates a simple asynchronous bind
+operation and returns the message id of the operation initiated. A sub-
+sequent call to ldap_result(), described below, can be used to obtain
+the result of the bind. In case of error, ldap_simple_bind() will return
+-1, setting the session error parameters in the LDAP structure appropri-
+ately.
+
+The synchronous ldap_sasl_bind_s() and ldap_simple_bind_s() functions
+both return the result of the operation, either the constant
+LDAP_SUCCESS if the operation was successful, or another LDAP result
+code if it was not. See the section below on error handling for more
+information about possible errors and how to interpret them.
+
+Note that if an LDAPv2 server is contacted, no other operations over the
+connection can be attempted before a bind call has successfully com-
+pleted.
+
+Subsequent bind calls can be used to re-authenticate over the same con-
+nection, and multistep SASL sequences can be accomplished through a
+sequence of calls to ldap_sasl_bind() or ldap_sasl_bind_s().
+
+
+11.5. Closing the session
+
+The following functions are used to unbind from the directory, close
+open connections, and dispose of the session handle.
+
+ int ldap_unbind_ext( LDAP *ld, LDAPControl **serverctrls,
+ LDAPControl **clientctrls );
+
+
+
+Expires: May 2001 [Page 27]
+
+C LDAP API C LDAP Application Program Interface 17 November 2000
+
+
+ int ldap_unbind( LDAP *ld );
+
+ int ldap_unbind_s( LDAP *ld );
+
+Parameters are:
+
+ld The session handle.
+
+serverctrls List of LDAP server controls, or NULL if no server controls
+ are to be used.
+
+clientctrls List of client controls, or NULL if no client controls are
+ to be used.
+
+The ldap_unbind_ext(), ldap_unbind() and ldap_unbind_s() all work syn-
+chronously in the sense that they send an unbind request to the server,
+close all open connections associated with the LDAP session handle, and
+dispose of all resources associated with the session handle before
+returning. Note, however, that there is no server response to an LDAP
+unbind operation. All three of the unbind functions return LDAP_SUCCESS
+(or another LDAP result code if the request cannot be sent to the LDAP
+server). After a call to one of the unbind functions, the session han-
+dle ld is invalid and it is illegal to make any further LDAP API calls
+using ld.
+
+The ldap_unbind() and ldap_unbind_s() functions behave identically. The
+ldap_unbind_ext() function allows server and client controls to be
+included explicitly, but note that since there is no server response to
+an unbind request there is no way to receive a response to a server con-
+trol sent with an unbind request.
+
+
+
+11.6. Searching
+
+The following functions are used to search the LDAP directory, returning
+a requested set of attributes for each entry matched. There are five
+variations.
+
+ int ldap_search_ext(
+ LDAP *ld,
+ const char *base,
+ int scope,
+ const char *filter,
+ char **attrs,
+ int attrsonly,
+ LDAPControl **serverctrls,
+ LDAPControl **clientctrls,
+
+
+
+Expires: May 2001 [Page 28]
+
+C LDAP API C LDAP Application Program Interface 17 November 2000
+
+
+ struct timeval *timeout,
+ int sizelimit,
+ int *msgidp
+ );
+
+ int ldap_search_ext_s(
+ LDAP *ld,
+ const char *base,
+ int scope,
+ const char *filter,
+ char **attrs,
+ int attrsonly,
+ LDAPControl **serverctrls,
+ LDAPControl **clientctrls,
+ struct timeval *timeout,
+ int sizelimit,
+ LDAPMessage **res
+ );
+
+ int ldap_search(
+ LDAP *ld,
+ const char *base,
+ int scope,
+ const char *filter,
+ char **attrs,
+ int attrsonly
+ );
+
+ int ldap_search_s(
+ LDAP *ld,
+ const char *base,
+ int scope,
+ const char *filter,
+ char **attrs,
+ int attrsonly,
+ LDAPMessage **res
+ );
+
+ int ldap_search_st(
+ LDAP *ld,
+ const char *base,
+ int scope,
+ const char *filter,
+ char **attrs,
+ int attrsonly,
+ struct timeval *timeout,
+ LDAPMessage **res
+ );
+
+
+
+Expires: May 2001 [Page 29]
+
+C LDAP API C LDAP Application Program Interface 17 November 2000
+
+
+Parameters are:
+
+ld The session handle.
+
+base The dn of the entry at which to start the search. If NULL,
+ a zero length DN is sent to the server.
+
+scope One of LDAP_SCOPE_BASE (0x00), LDAP_SCOPE_ONELEVEL (0x01),
+ or LDAP_SCOPE_SUBTREE (0x02), indicating the scope of the
+ search.
+
+filter A character string as described in [13], representing the
+ search filter. The value NULL can be passed to indicate
+ that the filter "(objectclass=*)" which matches all entries
+ is to be used. Note that if the caller of the API is using
+ LDAPv2, only a subset of the filter functionality described
+ in [13] can be successfully used.
+
+attrs A NULL-terminated array of strings indicating which attri-
+ butes to return for each matching entry. Passing NULL for
+ this parameter causes all available user attributes to be
+ retrieved. The special constant string LDAP_NO_ATTRS
+ ("1.1") MAY be used as the only string in the array to
+ indicate that no attribute types are to be returned by the
+ server. The special constant string LDAP_ALL_USER_ATTRS
+ ("*") can be used in the attrs array along with the names
+ of some operational attributes to indicate that all user
+ attributes plus the listed operational attributes are to be
+ returned.
+
+attrsonly A boolean value that MUST be zero if both attribute types
+ and values are to be returned, and non-zero if only types
+ are wanted.
+
+timeout For the ldap_search_st() function, this specifies the local
+ search timeout value (if it is NULL, the timeout is infin-
+ ite). If a zero timeout (where tv_sec and tv_usec are both
+ zero) is passed, API implementations SHOULD return
+ LDAP_PARAM_ERROR.
+
+ For the ldap_search_ext() and ldap_search_ext_s() func-
+ tions, the timeout parameter specifies both the local
+ search timeout value and the operation time limit that is
+ sent to the server within the search request. Passing a
+ NULL value for timeout causes the default timeout stored in
+ the LDAP session handle (set by using ldap_set_option()
+ with the LDAP_OPT_TIMELIMIT parameter) to be sent to the
+ server with the request but an infinite local search
+
+
+
+Expires: May 2001 [Page 30]
+
+C LDAP API C LDAP Application Program Interface 17 November 2000
+
+
+ timeout to be used. If a zero timeout (where tv_sec and
+ tv_usec are both zero) is passed in, API implementations
+ SHOULD return LDAP_PARAM_ERROR. If a zero value for tv_sec
+ is used but tv_usec is non-zero, an operation time limit of
+ 1 SHOULD be passed to the LDAP server as the operation time
+ limit. For other values of tv_sec, the tv_sec value itself
+ SHOULD be passed to the LDAP server.
+
+sizelimit For the ldap_search_ext() and ldap_search_ext_s() calls,
+ this is a limit on the number of entries to return from the
+ search. A value of LDAP_NO_LIMIT (0) means no limit. A
+ value of LDAP_DEFAULT_SIZELIMIT (-1) means use the default
+ timeout from the LDAP session handle (which is set by cal-
+ ling ldap_set_option() with the LDAP_OPT_SIZELIMIT parame-
+ ter).
+
+res For the synchronous calls, this is a result parameter which
+ will contain the results of the search upon completion of
+ the call. If an API error occurs or no results are
+ returned, *res is set to NULL.
+
+serverctrls List of LDAP server controls, or NULL if no server controls
+ are to be used.
+
+clientctrls List of client controls, or NULL if no client controls are
+ to be used.
+
+msgidp This result parameter will be set to the message id of the
+ request if the ldap_search_ext() call succeeds. The value
+ is undefined if a value other than LDAP_SUCCESS is
+ returned.
+
+There are three options in the session handle ld which potentially
+affect how the search is performed. They are:
+
+ LDAP_OPT_SIZELIMIT
+ LDAP_OPT_TIMELIMIT
+ LDAP_OPT_DEREF
+
+These options are fully described in the earlier section "LDAP Session
+Handle Options."
+
+The ldap_search_ext() function initiates an asynchronous search opera-
+tion and returns the constant LDAP_SUCCESS if the request was success-
+fully sent, or another LDAP result code if not. See the section below
+on error handling for more information about possible errors and how to
+interpret them. If successful, ldap_search_ext() places the message id
+of the request in *msgidp. A subsequent call to ldap_result(), described
+
+
+
+Expires: May 2001 [Page 31]
+
+C LDAP API C LDAP Application Program Interface 17 November 2000
+
+
+below, can be used to obtain the results from the search. These results
+can be parsed using the result parsing routines described in detail
+later.
+
+Similar to ldap_search_ext(), the ldap_search() function initiates an
+asynchronous search operation and returns the message id of the opera-
+tion initiated. As for ldap_search_ext(), a subsequent call to
+ldap_result(), described below, can be used to obtain the result of the
+bind. In case of error, ldap_search() will return -1, setting the ses-
+sion error parameters in the LDAP structure appropriately.
+
+The synchronous ldap_search_ext_s(), ldap_search_s(), and
+ldap_search_st() functions all return the result of the operation,
+either the constant LDAP_SUCCESS if the operation was successful, or
+another LDAP result code if it was not. See the section below on error
+handling for more information about possible errors and how to interpret
+them. Entries returned from the search (if any) are contained in the
+res parameter. This parameter is opaque to the caller. Entries, attri-
+butes, values, etc., can be extracted by calling the parsing routines
+described below. The results contained in res SHOULD be freed when no
+longer in use by calling ldap_msgfree(), described later.
+
+The ldap_search_ext() and ldap_search_ext_s() functions support LDAPv3
+server controls, client controls, and allow varying size and time limits
+to be easily specified for each search operation. The ldap_search_st()
+function is identical to ldap_search_s() except that it takes an addi-
+tional parameter specifying a local timeout for the search. The local
+search timeout is used to limit the amount of time the API implementa-
+tion will wait for a search to complete. After the local search timeout
+expires, the API implementation will send an abandon operation to abort
+the search operation.
+
+11.7. Reading an Entry
+
+LDAP does not support a read operation directly. Instead, this operation
+is emulated by a search with base set to the DN of the entry to read,
+scope set to LDAP_SCOPE_BASE, and filter set to "(objectclass=*)" or
+NULL. attrs contains the list of attributes to return.
+
+
+11.8. Listing the Children of an Entry
+
+LDAP does not support a list operation directly. Instead, this operation
+is emulated by a search with base set to the DN of the entry to list,
+scope set to LDAP_SCOPE_ONELEVEL, and filter set to "(objectclass=*)" or
+NULL. attrs contains the list of attributes to return for each child
+entry.
+
+
+
+
+Expires: May 2001 [Page 32]
+
+C LDAP API C LDAP Application Program Interface 17 November 2000
+
+
+11.9. Comparing a Value Against an Entry
+
+The following routines are used to compare a given attribute value
+assertion against an LDAP entry. There are four variations:
+
+ int ldap_compare_ext(
+ LDAP *ld,
+ const char *dn,
+ const char *attr,
+ const struct berval *bvalue,
+ LDAPControl **serverctrls,
+ LDAPControl **clientctrls,
+ int *msgidp
+ );
+
+ int ldap_compare_ext_s(
+ LDAP *ld,
+ const char *dn,
+ const char *attr,
+ const struct berval *bvalue,
+ LDAPControl **serverctrls,
+ LDAPControl **clientctrls
+ );
+
+ int ldap_compare(
+ LDAP *ld,
+ const char *dn,
+ const char *attr,
+ const char *value
+ );
+
+ int ldap_compare_s(
+ LDAP *ld,
+ const char *dn,
+ const char *attr,
+ const char *value
+ );
+
+Parameters are:
+
+ld The session handle.
+
+dn The name of the entry to compare against. If NULL, a zero
+ length DN is sent to the server.
+
+attr The attribute to compare against.
+
+bvalue The attribute value to compare against those found in the
+
+
+
+Expires: May 2001 [Page 33]
+
+C LDAP API C LDAP Application Program Interface 17 November 2000
+
+
+ given entry. This parameter is used in the extended rou-
+ tines and is a pointer to a struct berval so it is possible
+ to compare binary values.
+
+value A string attribute value to compare against, used by the
+ ldap_compare() and ldap_compare_s() functions. Use
+ ldap_compare_ext() or ldap_compare_ext_s() if you need to
+ compare binary values.
+
+serverctrls List of LDAP server controls, or NULL if no server controls
+ are to be used.
+
+clientctrls List of client controls, or NULL if no client controls are
+ to be used.
+
+msgidp This result parameter will be set to the message id of the
+ request if the ldap_compare_ext() call succeeds. The value
+ is undefined if a value other than LDAP_SUCCESS is
+ returned.
+
+The ldap_compare_ext() function initiates an asynchronous compare opera-
+tion and returns the constant LDAP_SUCCESS if the request was success-
+fully sent, or another LDAP result code if not. See the section below
+on error handling for more information about possible errors and how to
+interpret them. If successful, ldap_compare_ext() places the message id
+of the request in *msgidp. A subsequent call to ldap_result(), described
+below, can be used to obtain the result of the compare.
+
+Similar to ldap_compare_ext(), the ldap_compare() function initiates an
+asynchronous compare operation and returns the message id of the opera-
+tion initiated. As for ldap_compare_ext(), a subsequent call to
+ldap_result(), described below, can be used to obtain the result of the
+bind. In case of error, ldap_compare() will return -1, setting the ses-
+sion error parameters in the LDAP structure appropriately.
+
+The synchronous ldap_compare_ext_s() and ldap_compare_s() functions both
+return the result of the operation: one of the constants
+LDAP_COMPARE_TRUE or LDAP_COMPARE_FALSE if the operation was successful,
+or another LDAP result code if it was not. See the section below on
+error handling for more information about possible errors and how to
+interpret them.
+
+The ldap_compare_ext() and ldap_compare_ext_s() functions support LDAPv3
+server controls and client controls.
+
+
+
+
+
+
+
+Expires: May 2001 [Page 34]
+
+C LDAP API C LDAP Application Program Interface 17 November 2000
+
+
+11.10. Modifying an entry
+
+The following routines are used to modify an existing LDAP entry. There
+are four variations:
+
+ typedef union mod_vals_u {
+ char **modv_strvals;
+ struct berval **modv_bvals;
+ } mod_vals_u_t;
+
+ typedef struct ldapmod {
+ int mod_op;
+ char *mod_type;
+ mod_vals_u_t mod_vals;
+ } LDAPMod;
+ #define mod_values mod_vals.modv_strvals
+ #define mod_bvalues mod_vals.modv_bvals
+
+ int ldap_modify_ext(
+ LDAP *ld,
+ const char *dn,
+ LDAPMod **mods,
+ LDAPControl **serverctrls,
+ LDAPControl **clientctrls,
+ int *msgidp
+ );
+
+ int ldap_modify_ext_s(
+ LDAP *ld,
+ const char *dn,
+ LDAPMod **mods,
+ LDAPControl **serverctrls,
+ LDAPControl **clientctrls
+ );
+
+ int ldap_modify(
+ LDAP *ld,
+ const char *dn,
+ LDAPMod **mods
+ );
+
+ int ldap_modify_s(
+ LDAP *ld,
+ const char *dn,
+ LDAPMod **mods
+ );
+
+Parameters are:
+
+
+
+Expires: May 2001 [Page 35]
+
+C LDAP API C LDAP Application Program Interface 17 November 2000
+
+
+ld The session handle.
+
+dn The name of the entry to modify. If NULL, a zero length DN
+ is sent to the server.
+
+mods A NULL-terminated array of modifications to make to the
+ entry.
+
+serverctrls List of LDAP server controls, or NULL if no server controls
+ are to be used.
+
+clientctrls List of client controls, or NULL if no client controls are
+ to be used.
+
+msgidp This result parameter will be set to the message id of the
+ request if the ldap_modify_ext() call succeeds. The value
+ is undefined if a value other than LDAP_SUCCESS is
+ returned.
+
+The fields in the LDAPMod structure have the following meanings:
+
+mod_op The modification operation to perform. It MUST be one of
+ LDAP_MOD_ADD (0x00), LDAP_MOD_DELETE (0x01), or
+ LDAP_MOD_REPLACE (0x02). This field also indicates the
+ type of values included in the mod_vals union. It is logi-
+ cally ORed with LDAP_MOD_BVALUES (0x80) to select the
+ mod_bvalues form. Otherwise, the mod_values form is used.
+
+mod_type The type of the attribute to modify.
+
+mod_vals The values (if any) to add, delete, or replace. Only one of
+ the mod_values or mod_bvalues variants can be used,
+ selected by ORing the mod_op field with the constant
+ LDAP_MOD_BVALUES. mod_values is a NULL-terminated array of
+ zero-terminated strings and mod_bvalues is a NULL-
+ terminated array of berval structures that can be used to
+ pass binary values such as images.
+
+For LDAP_MOD_ADD modifications, the given values are added to the
+entry, creating the attribute if necessary.
+
+For LDAP_MOD_DELETE modifications, the given values are deleted from the
+entry, removing the attribute if no values remain. If the entire attri-
+bute is to be deleted, the mod_vals field can be set to NULL.
+
+For LDAP_MOD_REPLACE modifications, the attribute will have the listed
+values after the modification, having been created if necessary, or
+removed if the mod_vals field is NULL. All modifications are performed
+
+
+
+Expires: May 2001 [Page 36]
+
+C LDAP API C LDAP Application Program Interface 17 November 2000
+
+
+in the order in which they are listed.
+
+The ldap_modify_ext() function initiates an asynchronous modify opera-
+tion and returns the constant LDAP_SUCCESS if the request was success-
+fully sent, or another LDAP result code if not. See the section below
+on error handling for more information about possible errors and how to
+interpret them. If successful, ldap_modify_ext() places the message id
+of the request in *msgidp. A subsequent call to ldap_result(), described
+below, can be used to obtain the result of the modify.
+
+Similar to ldap_modify_ext(), the ldap_modify() function initiates an
+asynchronous modify operation and returns the message id of the opera-
+tion initiated. As for ldap_modify_ext(), a subsequent call to
+ldap_result(), described below, can be used to obtain the result of the
+modify. In case of error, ldap_modify() will return -1, setting the ses-
+sion error parameters in the LDAP structure appropriately.
+
+The synchronous ldap_modify_ext_s() and ldap_modify_s() functions both
+return the result of the operation, either the constant LDAP_SUCCESS if
+the operation was successful, or another LDAP result code if it was not.
+See the section below on error handling for more information about pos-
+sible errors and how to interpret them.
+
+The ldap_modify_ext() and ldap_modify_ext_s() functions support LDAPv3
+server controls and client controls.
+
+
+11.11. Modifying the Name of an Entry
+
+In LDAPv2, the ldap_modrdn(), ldap_modrdn_s(), ldap_modrdn2(), and
+ldap_modrdn2_s() routines were used to change the name of an LDAP entry.
+They could only be used to change the least significant component of a
+name (the RDN or relative distinguished name). LDAPv3 provides the
+Modify DN protocol operation that allows more general name change
+access. The ldap_rename() and ldap_rename_s() routines are used to
+change the name of an entry, and the use of the ldap_modrdn(),
+ldap_modrdn_s(), ldap_modrdn2(), and ldap_modrdn2_s() routines is depre-
+cated.
+
+ int ldap_rename(
+ LDAP *ld,
+ const char *dn,
+ const char *newrdn,
+ const char *newparent,
+ int deleteoldrdn,
+ LDAPControl **serverctrls,
+ LDAPControl **clientctrls,
+ int *msgidp
+
+
+
+Expires: May 2001 [Page 37]
+
+C LDAP API C LDAP Application Program Interface 17 November 2000
+
+
+ );
+ int ldap_rename_s(
+ LDAP *ld,
+ const char *dn,
+ const char *newrdn,
+ const char *newparent,
+ int deleteoldrdn,
+ LDAPControl **serverctrls,
+ LDAPControl **clientctrls
+ );
+
+ The use of the following routines is deprecated and more complete
+ descriptions can be found in RFC 1823:
+
+ int ldap_modrdn(
+ LDAP *ld,
+ const char *dn,
+ const char *newrdn
+ );
+ int ldap_modrdn_s(
+ LDAP *ld,
+ const char *dn,
+ const char *newrdn
+ );
+ int ldap_modrdn2(
+ LDAP *ld,
+ const char *dn,
+ const char *newrdn,
+ int deleteoldrdn
+ );
+ int ldap_modrdn2_s(
+ LDAP *ld,
+ const char *dn,
+ const char *newrdn,
+ int deleteoldrdn
+ );
+
+Parameters are:
+
+ld The session handle.
+
+dn The name of the entry whose DN is to be changed. If NULL,
+ a zero length DN is sent to the server.
+
+newrdn The new RDN to give the entry.
+
+newparent The new parent, or superior entry. If this parameter is
+ NULL, only the RDN of the entry is changed. The root DN
+
+
+
+Expires: May 2001 [Page 38]
+
+C LDAP API C LDAP Application Program Interface 17 November 2000
+
+
+ SHOULD be specified by passing a zero length string, "".
+ The newparent parameter SHOULD always be NULL when using
+ version 2 of the LDAP protocol; otherwise the server's
+ behavior is undefined.
+
+deleteoldrdn This parameter only has meaning on the rename routines if
+ newrdn is different than the old RDN. It is a boolean
+ value, if non-zero indicating that the old RDN value(s) is
+ to be removed, if zero indicating that the old RDN value(s)
+ is to be retained as non-distinguished values of the entry.
+
+serverctrls List of LDAP server controls, or NULL if no server controls
+ are to be used.
+
+clientctrls List of client controls, or NULL if no client controls are
+ to be used.
+
+msgidp This result parameter will be set to the message id of the
+ request if the ldap_rename() call succeeds. The value is
+ undefined if a value other than LDAP_SUCCESS is returned.
+
+The ldap_rename() function initiates an asynchronous modify DN operation
+and returns the constant LDAP_SUCCESS if the request was successfully
+sent, or another LDAP result code if not. See the section below on
+error handling for more information about possible errors and how to
+interpret them. If successful, ldap_rename() places the DN message id
+of the request in *msgidp. A subsequent call to ldap_result(), described
+below, can be used to obtain the result of the rename.
+
+The synchronous ldap_rename_s() returns the result of the operation,
+either the constant LDAP_SUCCESS if the operation was successful, or
+another LDAP result code if it was not. See the section below on error
+handling for more information about possible errors and how to interpret
+them.
+
+The ldap_rename() and ldap_rename_s() functions both support LDAPv3
+server controls and client controls.
+
+
+11.12. Adding an entry
+
+The following functions are used to add entries to the LDAP directory.
+There are four variations:
+
+ int ldap_add_ext(
+ LDAP *ld,
+ const char *dn,
+ LDAPMod **attrs,
+
+
+
+Expires: May 2001 [Page 39]
+
+C LDAP API C LDAP Application Program Interface 17 November 2000
+
+
+ LDAPControl **serverctrls,
+ LDAPControl **clientctrls,
+ int *msgidp
+ );
+
+ int ldap_add_ext_s(
+ LDAP *ld,
+ const char *dn,
+ LDAPMod **attrs,
+ LDAPControl **serverctrls,
+ LDAPControl **clientctrls
+ );
+
+ int ldap_add(
+ LDAP *ld,
+ const char *dn,
+ LDAPMod **attrs
+ );
+
+ int ldap_add_s(
+ LDAP *ld,
+ const char *dn,
+ LDAPMod **attrs
+ );
+
+Parameters are:
+
+ld The session handle.
+
+dn The name of the entry to add. If NULL, a zero length DN is
+ sent to the server.
+
+attrs The entry's attributes, specified using the LDAPMod struc-
+ ture defined for ldap_modify(). The mod_type and mod_vals
+ fields MUST be filled in. The mod_op field is ignored
+ unless ORed with the constant LDAP_MOD_BVALUES, used to
+ select the mod_bvalues case of the mod_vals union.
+
+serverctrls List of LDAP server controls, or NULL if no server controls
+ are to be used.
+
+clientctrls List of client controls, or NULL if no client controls are
+ to be used.
+
+msgidp This result parameter will be set to the message id of the
+ request if the ldap_add_ext() call succeeds. The value is
+ undefined if a value other than LDAP_SUCCESS is returned.
+
+
+
+
+Expires: May 2001 [Page 40]
+
+C LDAP API C LDAP Application Program Interface 17 November 2000
+
+
+Note that the parent of the entry being added must already exist or the
+parent must be empty (i.e., equal to the root DN) for an add to succeed.
+
+The ldap_add_ext() function initiates an asynchronous add operation and
+returns the constant LDAP_SUCCESS if the request was successfully sent,
+or another LDAP result code if not. See the section below on error han-
+dling for more information about possible errors and how to interpret
+them. If successful, ldap_add_ext() places the message id of the
+request in *msgidp. A subsequent call to ldap_result(), described below,
+can be used to obtain the result of the add.
+
+Similar to ldap_add_ext(), the ldap_add() function initiates an asyn-
+chronous add operation and returns the message id of the operation ini-
+tiated. As for ldap_add_ext(), a subsequent call to ldap_result(),
+described below, can be used to obtain the result of the add. In case of
+error, ldap_add() will return -1, setting the session error parameters
+in the LDAP structure appropriately.
+
+The synchronous ldap_add_ext_s() and ldap_add_s() functions both return
+the result of the operation, either the constant LDAP_SUCCESS if the
+operation was successful, or another LDAP result code if it was not.
+See the section below on error handling for more information about pos-
+sible errors and how to interpret them.
+
+The ldap_add_ext() and ldap_add_ext_s() functions support LDAPv3 server
+controls and client controls.
+
+
+
+11.13. Deleting an entry
+
+The following functions are used to delete a leaf entry from the LDAP
+directory. There are four variations:
+
+ int ldap_delete_ext(
+ LDAP *ld,
+ const char *dn,
+ LDAPControl **serverctrls,
+ LDAPControl **clientctrls,
+ int *msgidp
+ );
+
+ int ldap_delete_ext_s(
+ LDAP *ld,
+ const char *dn,
+ LDAPControl **serverctrls,
+ LDAPControl **clientctrls
+ );
+
+
+
+Expires: May 2001 [Page 41]
+
+C LDAP API C LDAP Application Program Interface 17 November 2000
+
+
+
+ int ldap_delete(
+ LDAP *ld,
+ const char *dn
+ );
+
+ int ldap_delete_s(
+ LDAP *ld,
+ const char *dn
+ );
+
+Parameters are:
+
+ld The session handle.
+
+dn The name of the entry to delete. If NULL, a zero length DN
+ is sent to the server.
+
+serverctrls List of LDAP server controls, or NULL if no server controls
+ are to be used.
+
+clientctrls List of client controls, or NULL if no client controls are
+ to be used.
+
+msgidp This result parameter will be set to the message id of the
+ request if the ldap_delete_ext() call succeeds. The value
+ is undefined if a value other than LDAP_SUCCESS is
+ returned.
+
+Note that the entry to delete must be a leaf entry (i.e., it must have
+no children). Deletion of entire subtrees in a single operation is not
+supported by LDAP.
+
+The ldap_delete_ext() function initiates an asynchronous delete opera-
+tion and returns the constant LDAP_SUCCESS if the request was success-
+fully sent, or another LDAP result code if not. See the section below
+on error handling for more information about possible errors and how to
+interpret them. If successful, ldap_delete_ext() places the message id
+of the request in *msgidp. A subsequent call to ldap_result(), described
+below, can be used to obtain the result of the delete.
+
+Similar to ldap_delete_ext(), the ldap_delete() function initiates an
+asynchronous delete operation and returns the message id of the opera-
+tion initiated. As for ldap_delete_ext(), a subsequent call to
+ldap_result(), described below, can be used to obtain the result of the
+delete. In case of error, ldap_delete() will return -1, setting the ses-
+sion error parameters in the LDAP structure appropriately.
+
+
+
+
+Expires: May 2001 [Page 42]
+
+C LDAP API C LDAP Application Program Interface 17 November 2000
+
+
+The synchronous ldap_delete_ext_s() and ldap_delete_s() functions both
+return the result of the operation, either the constant LDAP_SUCCESS if
+the operation was successful, or another LDAP result code if it was not.
+See the section below on error handling for more information about pos-
+sible errors and how to interpret them.
+
+The ldap_delete_ext() and ldap_delete_ext_s() functions support LDAPv3
+server controls and client controls.
+
+
+11.14. Extended Operations
+
+The ldap_extended_operation() and ldap_extended_operation_s() routines
+allow extended LDAP operations to be passed to the server, providing a
+general protocol extensibility mechanism.
+
+ int ldap_extended_operation(
+ LDAP *ld,
+ const char *requestoid,
+ const struct berval *requestdata,
+ LDAPControl **serverctrls,
+ LDAPControl **clientctrls,
+ int *msgidp
+ );
+
+ int ldap_extended_operation_s(
+ LDAP *ld,
+ const char *requestoid,
+ const struct berval *requestdata,
+ LDAPControl **serverctrls,
+ LDAPControl **clientctrls,
+ char **retoidp,
+ struct berval **retdatap
+ );
+
+Parameters are:
+
+ld The session handle.
+
+requestoid The dotted-OID text string naming the request.
+
+requestdata The arbitrary data needed by the operation (if NULL, no
+ data is sent to the server).
+
+serverctrls List of LDAP server controls, or NULL if no server controls
+ are to be used.
+
+clientctrls List of client controls, or NULL if no client controls are
+
+
+
+Expires: May 2001 [Page 43]
+
+C LDAP API C LDAP Application Program Interface 17 November 2000
+
+
+ to be used.
+
+msgidp This result parameter will be set to the message id of the
+ request if the ldap_extended_operation() call succeeds. The
+ value is undefined if a value other than LDAP_SUCCESS is
+ returned.
+
+retoidp Pointer to a character string that will be set to an allo-
+ cated, dotted-OID text string returned by the server. This
+ string SHOULD be disposed of using the ldap_memfree() func-
+ tion. If an API error occurs or no OID is returned by the
+ server, *retoidp is set to NULL.
+
+retdatap Pointer to a berval structure pointer that will be set an
+ allocated copy of the data returned by the server. This
+ struct berval SHOULD be disposed of using ber_bvfree(). If
+ an API error occurs or no data is returned by the server,
+ *retdatap is set to NULL.
+
+The ldap_extended_operation() function initiates an asynchronous
+extended operation and returns the constant LDAP_SUCCESS if the request
+was successfully sent, or another LDAP result code if not. See the sec-
+tion below on error handling for more information about possible errors
+and how to interpret them. If successful, ldap_extended_operation()
+places the message id of the request in *msgidp. A subsequent call to
+ldap_result(), described below, can be used to obtain the result of the
+extended operation which can be passed to ldap_parse_extended_result()
+to obtain the OID and data contained in the response.
+
+The synchronous ldap_extended_operation_s() function returns the result
+of the operation, either the constant LDAP_SUCCESS if the operation was
+successful, or another LDAP result code if it was not. See the section
+below on error handling for more information about possible errors and
+how to interpret them. The retoid and retdata parameters are filled in
+with the OID and data from the response.
+
+The ldap_extended_operation() and ldap_extended_operation_s() functions
+both support LDAPv3 server controls and client controls.
+
+
+12. Abandoning An Operation
+
+The following calls are used to abandon an operation in progress:
+
+ int ldap_abandon_ext(
+ LDAP *ld,
+ int msgid,
+ LDAPControl **serverctrls,
+
+
+
+Expires: May 2001 [Page 44]
+
+C LDAP API C LDAP Application Program Interface 17 November 2000
+
+
+ LDAPControl **clientctrls
+ );
+
+ int ldap_abandon(
+ LDAP *ld,
+ int msgid
+ );
+
+
+ld The session handle.
+
+msgid The message id of the request to be abandoned.
+
+serverctrls List of LDAP server controls, or NULL if no server controls
+ are to be used.
+
+clientctrls List of client controls, or NULL if no client controls are
+ to be used.
+
+ldap_abandon_ext() abandons the operation with message id msgid and
+returns the constant LDAP_SUCCESS if the abandon was successful or
+another LDAP result code if not. See the section below on error han-
+dling for more information about possible errors and how to interpret
+them.
+
+ldap_abandon() is identical to ldap_abandon_ext() except that it does
+not accept client or server controls and it returns zero if the abandon
+was successful, -1 otherwise.
+
+After a successful call to ldap_abandon() or ldap_abandon_ext(), results
+with the given message id are never returned from a subsequent call to
+ldap_result(). There is no server response to LDAP abandon operations.
+
+
+13. Obtaining Results and Peeking Inside LDAP Messages
+
+ldap_result() is used to obtain the result of a previous asynchronously
+initiated operation. Note that depending on how it is called,
+ldap_result() can actually return a list or "chain" of result messages.
+The ldap_result() function only returns messages for a single request,
+so for all LDAP operations other than search only one result message is
+expected; that is, the only time the "result chain" can contain more
+than one message is if results from a search operation are returned.
+Once a chain of messages has been returned to the caller, it is no
+longer tied in any caller-visible way to the LDAP request that produced
+it. However, it MAY be tied to the session handle. Therefore, a chain
+of messages returned by calling ldap_result() or by calling a synchro-
+nous search routine will never be affected by subsequent LDAP API calls
+
+
+
+Expires: May 2001 [Page 45]
+
+C LDAP API C LDAP Application Program Interface 17 November 2000
+
+
+except for ldap_msgfree() (which is used to dispose of a chain of mes-
+sages) and the unbind calls (which dispose of a session handle):
+ldap_unbind(), ldap_unbind_s(), or ldap_unbind_ext(), or functions
+defined by extensions of this API.
+
+ldap_msgfree() frees the result messages (possibly an entire chain of
+messages) obtained from a previous call to ldap_result() or from a call
+to a synchronous search routine.
+
+ldap_msgtype() returns the type of an LDAP message.
+
+ldap_msgid() returns the message ID of an LDAP message.
+
+ int ldap_result(
+ LDAP *ld,
+ int msgid,
+ int all,
+ struct timeval *timeout,
+ LDAPMessage **res
+ );
+
+ int ldap_msgfree( LDAPMessage *res );
+
+ int ldap_msgtype( LDAPMessage *res );
+
+ int ldap_msgid( LDAPMessage *res );
+
+Parameters are:
+
+ld The session handle.
+
+msgid The message id of the operation whose results are to be
+ returned, the constant LDAP_RES_UNSOLICITED (0) if an unsoli-
+ cited result is desired, or or the constant LDAP_RES_ANY (-1)
+ if any result is desired.
+
+all Specifies how many messages will be retrieved in a single call
+ to ldap_result(). This parameter only has meaning for search
+ results. Pass the constant LDAP_MSG_ONE (0x00) to retrieve one
+ message at a time. Pass LDAP_MSG_ALL (0x01) to request that
+ all results of a search be received before returning all
+ results in a single chain. Pass LDAP_MSG_RECEIVED (0x02) to
+ indicate that all messages retrieved so far are to be returned
+ in the result chain.
+
+timeout A timeout specifying how long to wait for results to be
+ returned. A NULL value causes ldap_result() to block until
+ results are available. A timeout value of zero seconds
+
+
+
+Expires: May 2001 [Page 46]
+
+C LDAP API C LDAP Application Program Interface 17 November 2000
+
+
+ specifies a polling behavior.
+
+res For ldap_result(), a result parameter that will contain the
+ result(s) of the operation. If an API error occurs or no
+ results are returned, *res is set to NULL. For ldap_msgfree(),
+ the result chain to be freed, obtained from a previous call to
+ ldap_result(), ldap_search_s(), or ldap_search_st(). If res is
+ NULL, nothing is done and ldap_msgfree() returns zero.
+
+Upon successful completion, ldap_result() returns the type of the first
+result returned in the res parameter. This will be one of the following
+constants.
+
+ LDAP_RES_BIND (0x61)
+ LDAP_RES_SEARCH_ENTRY (0x64)
+ LDAP_RES_SEARCH_REFERENCE (0x73) -- new in LDAPv3
+ LDAP_RES_SEARCH_RESULT (0x65)
+ LDAP_RES_MODIFY (0x67)
+ LDAP_RES_ADD (0x69)
+ LDAP_RES_DELETE (0x6B)
+ LDAP_RES_MODDN (0x6D)
+ LDAP_RES_COMPARE (0x6F)
+ LDAP_RES_EXTENDED (0x78) -- new in LDAPv3
+
+ldap_result() returns 0 if the timeout expired and -1 if an error
+occurs, in which case the error parameters of the LDAP session handle
+will be set accordingly.
+
+ldap_msgfree() frees each message in the result chain pointed to by res
+and returns the type of the last message in the chain. If res is NULL,
+nothing is done and the value zero is returned.
+
+ldap_msgtype() returns the type of the LDAP message it is passed as a
+parameter. The type will be one of the types listed above, or -1 on
+error.
+
+ldap_msgid() returns the message ID associated with the LDAP message
+passed as a parameter, or -1 on error.
+
+
+14. Handling Errors and Parsing Results
+
+The following calls are used to extract information from results and
+handle errors returned by other LDAP API routines. Note that
+ldap_parse_sasl_bind_result() and ldap_parse_extended_result() must typ-
+ically be used in addition to ldap_parse_result() to retrieve all the
+result information from SASL Bind and Extended Operations respectively.
+
+
+
+
+Expires: May 2001 [Page 47]
+
+C LDAP API C LDAP Application Program Interface 17 November 2000
+
+
+ int ldap_parse_result(
+ LDAP *ld,
+ LDAPMessage *res,
+ int *errcodep,
+ char **matcheddnp,
+ char **errmsgp,
+ char ***referralsp,
+ LDAPControl ***serverctrlsp,
+ int freeit
+ );
+
+ int ldap_parse_sasl_bind_result(
+ LDAP *ld,
+ LDAPMessage *res,
+ struct berval **servercredp,
+ int freeit
+ );
+
+ int ldap_parse_extended_result(
+ LDAP *ld,
+ LDAPMessage *res,
+ char **retoidp,
+ struct berval **retdatap,
+ int freeit
+ );
+
+ #define LDAP_NOTICE_OF_DISCONNECTION "1.3.6.1.4.1.1466.20036"
+
+ char *ldap_err2string( int err );
+
+ The use of the following routines is deprecated and more complete
+ descriptions can be found in RFC 1823:
+
+ int ldap_result2error(
+ LDAP *ld,
+ LDAPMessage *res,
+ int freeit
+ );
+
+ void ldap_perror( LDAP *ld, const char *msg );
+
+Parameters are:
+
+ld The session handle.
+
+res The result of an LDAP operation as returned by
+ ldap_result() or one of the synchronous API operation
+ calls.
+
+
+
+Expires: May 2001 [Page 48]
+
+C LDAP API C LDAP Application Program Interface 17 November 2000
+
+
+errcodep This result parameter will be filled in with the LDAP
+ resultCode field from the LDAPMessage message. This is the
+ indication from the server of the outcome of the operation.
+ NULL SHOULD be passed to ignore this field.
+
+matcheddnp If the server returned a matchedDN string to indicate how
+ much of a name passed in a request was recognized, this
+ result parameter will be filled in with that matchedDN
+ string. Otherwise, this field will be set to NULL. NULL
+ SHOULD be passed to ignore this field. The matched DN
+ string SHOULD be freed by calling ldap_memfree() which is
+ described later in this document. Note that the server may
+ return a zero length matchedDN (in which case *matchednp is
+ set to an allocated copy of "") which is different than not
+ returning a value at all (in which case *matcheddnp is set
+ to NULL).
+
+errmsgp This result parameter will be filled in with the contents
+ of the error message field from the LDAPMessage message.
+ The error message string SHOULD be freed by calling
+ ldap_memfree() which is described later in this document.
+ NULL SHOULD be passed to ignore this field.
+
+referralsp This result parameter will be filled in with the contents
+ of the referrals field from the LDAPMessage message, indi-
+ cating zero or more alternate LDAP servers where the
+ request is to be retried. The referrals array SHOULD be
+ freed by calling ldap_value_free() which is described later
+ in this document. NULL SHOULD be passed to ignore this
+ field. If no referrals were returned, *referralsp is set
+ to NULL.
+
+serverctrlsp This result parameter will be filled in with an allocated
+ array of controls copied out of the LDAPMessage message.
+ If serverctrlsp is NULL, no controls are returned. The
+ control array SHOULD be freed by calling
+ ldap_controls_free() which was described earlier. If no
+ controls were returned, *serverctrlsp is set to NULL.
+
+freeit A boolean that determines whether the res parameter is
+ disposed of or not. Pass any non-zero value to have these
+ routines free res after extracting the requested informa-
+ tion. This is provided as a convenience; you can also use
+ ldap_msgfree() to free the result later. If freeit is
+ non-zero, the entire chain of messages represented by res
+ is disposed of.
+
+servercredp For SASL bind results, this result parameter will be filled
+
+
+
+Expires: May 2001 [Page 49]
+
+C LDAP API C LDAP Application Program Interface 17 November 2000
+
+
+ in with the credentials passed back by the server for
+ mutual authentication, if given. An allocated berval struc-
+ ture is returned that SHOULD be disposed of by calling
+ ber_bvfree(). NULL SHOULD be passed to ignore this field.
+
+retoidp For extended results, this result parameter will be filled
+ in with the dotted-OID text representation of the name of
+ the extended operation response. This string SHOULD be
+ disposed of by calling ldap_memfree(). NULL SHOULD be
+ passed to ignore this field. If no OID was returned,
+ *retoidp is set to NULL. The LDAP_NOTICE_OF_DISCONNECTION
+ macro is defined as a convenience for clients that wish to
+ check an OID to see if it matches the one used for the
+ unsolicited Notice of Disconnection (defined in RFC 2251[2]
+ section 4.4.1).
+
+retdatap For extended results, this result parameter will be filled
+ in with a pointer to a struct berval containing the data in
+ the extended operation response. It SHOULD be disposed of
+ by calling ber_bvfree(). NULL SHOULD be passed to ignore
+ this field. If no data is returned, *retdatap is set to
+ NULL.
+
+err For ldap_err2string(), an LDAP result code, as returned by
+ ldap_parse_result() or another LDAP API call.
+
+Additional parameters for the deprecated routines are not described.
+Interested readers are referred to RFC 1823.
+
+The ldap_parse_result(), ldap_parse_sasl_bind_result(), and
+ldap_parse_extended_result() functions all skip over messages of type
+LDAP_RES_SEARCH_ENTRY and LDAP_RES_SEARCH_REFERENCE when looking for a
+result message to parse. They return the constant LDAP_SUCCESS if the
+result was successfully parsed and another LDAP API result code if not.
+If a value other than LDAP_SUCCESS is returned, the values of all the
+result parameters are undefined. Note that the LDAP result code that
+indicates the outcome of the operation performed by the server is placed
+in the errcodep ldap_parse_result() parameter. If a chain of messages
+that contains more than one result message is passed to these routines
+they always operate on the first result in the chain.
+
+ldap_err2string() is used to convert a numeric LDAP result code, as
+returned by ldap_parse_result(), ldap_parse_sasl_bind_result(),
+ldap_parse_extended_result() or one of the synchronous API operation
+calls, into an informative zero-terminated character string message
+describing the error. It returns a pointer to static data and it MUST
+NOT return NULL; the value returned is always a valid null-terminated
+"C" string.
+
+
+
+Expires: May 2001 [Page 50]
+
+C LDAP API C LDAP Application Program Interface 17 November 2000
+
+
+15. Stepping Through a List of Results
+
+The ldap_first_message() and ldap_next_message() routines are used to
+step through the list of messages in a result chain returned by
+ldap_result(). For search operations, the result chain can actually
+include referral messages, entry messages, and result messages.
+ldap_count_messages() is used to count the number of messages returned.
+The ldap_msgtype() function, described above, can be used to distinguish
+between the different message types.
+
+ LDAPMessage *ldap_first_message( LDAP *ld, LDAPMessage *res );
+
+ LDAPMessage *ldap_next_message( LDAP *ld, LDAPMessage *msg );
+
+ int ldap_count_messages( LDAP *ld, LDAPMessage *res );
+
+Parameters are:
+
+ld The session handle.
+
+res The result chain, as obtained by a call to one of the synchronous
+ search routines or ldap_result().
+
+msg The message returned by a previous call to ldap_first_message()
+ or ldap_next_message().
+
+ldap_first_message() and ldap_next_message() will return NULL when no
+more messages exist in the result set to be returned. NULL is also
+returned if an error occurs while stepping through the entries, in which
+case the error parameters in the session handle ld will be set to indi-
+cate the error.
+
+If successful, ldap_count_messages() returns the number of messages con-
+tained in a chain of results; if an error occurs such as the res parame-
+ter being invalid, -1 is returned. The ldap_count_messages() call can
+also be used to count the number of messages that remain in a chain if
+called with a message, entry, or reference returned by
+ldap_first_message(), ldap_next_message(), ldap_first_entry(),
+ldap_next_entry(), ldap_first_reference(), ldap_next_reference().
+
+
+16. Parsing Search Results
+
+The following calls are used to parse the entries and references
+returned by ldap_search() and friends. These results are returned in an
+opaque structure that MAY be accessed by calling the routines described
+below. Routines are provided to step through the entries and references
+returned, step through the attributes of an entry, retrieve the name of
+
+
+
+Expires: May 2001 [Page 51]
+
+C LDAP API C LDAP Application Program Interface 17 November 2000
+
+
+an entry, and retrieve the values associated with a given attribute in
+an entry.
+
+
+16.1. Stepping Through a List of Entries or References
+
+The ldap_first_entry() and ldap_next_entry() routines are used to step
+through and retrieve the list of entries from a search result chain.
+The ldap_first_reference() and ldap_next_reference() routines are used
+to step through and retrieve the list of continuation references from a
+search result chain. ldap_count_entries() is used to count the number
+of entries returned. ldap_count_references() is used to count the number
+of references returned.
+
+ LDAPMessage *ldap_first_entry( LDAP *ld, LDAPMessage *res );
+
+ LDAPMessage *ldap_next_entry( LDAP *ld, LDAPMessage *entry );
+
+ LDAPMessage *ldap_first_reference( LDAP *ld, LDAPMessage *res );
+
+ LDAPMessage *ldap_next_reference( LDAP *ld, LDAPMessage *ref );
+
+ int ldap_count_entries( LDAP *ld, LDAPMessage *res );
+
+ int ldap_count_references( LDAP *ld, LDAPMessage *res );
+
+Parameters are:
+
+ld The session handle.
+
+res The search result, as obtained by a call to one of the synchro-
+ nous search routines or ldap_result().
+
+entry The entry returned by a previous call to ldap_first_entry() or
+ ldap_next_entry().
+
+ref The reference returned by a previous call to
+ ldap_first_reference() or ldap_next_reference().
+
+ldap_first_entry(), ldap_next_entry(), ldap_first_reference() and
+ldap_next_reference() all return NULL when no more entries or references
+exist in the result set to be returned. NULL is also returned if an
+error occurs while stepping through the entries or references, in which
+case the error parameters in the session handle ld will be set to indi-
+cate the error.
+
+ldap_count_entries() returns the number of entries contained in a chain
+of entries; if an error occurs such as the res parameter being invalid,
+
+
+
+Expires: May 2001 [Page 52]
+
+C LDAP API C LDAP Application Program Interface 17 November 2000
+
+
+-1 is returned. The ldap_count_entries() call can also be used to count
+the number of entries that remain in a chain if called with a message,
+entry or reference returned by ldap_first_message(),
+ldap_next_message(), ldap_first_entry(), ldap_next_entry(),
+ldap_first_reference(), ldap_next_reference().
+
+ldap_count_references() returns the number of references contained in a
+chain of search results; if an error occurs such as the res parameter
+being invalid, -1 is returned. The ldap_count_references() call can
+also be used to count the number of references that remain in a chain.
+
+
+16.2. Stepping Through the Attributes of an Entry
+
+The ldap_first_attribute() and ldap_next_attribute() calls are used to
+step through the list of attribute types returned with an entry.
+
+ char *ldap_first_attribute(
+ LDAP *ld,
+ LDAPMessage *entry,
+ BerElement **ptr
+ );
+
+ char *ldap_next_attribute(
+ LDAP *ld,
+ LDAPMessage *entry,
+ BerElement *ptr
+ );
+
+ void ldap_memfree( char *mem );
+
+Parameters are:
+
+ld The session handle.
+
+entry The entry whose attributes are to be stepped through, as returned
+ by ldap_first_entry() or ldap_next_entry().
+
+ptr In ldap_first_attribute(), the address of a pointer used inter-
+ nally to keep track of the current position in the entry. In
+ ldap_next_attribute(), the pointer returned by a previous call to
+ ldap_first_attribute(). The BerElement type itself is an opaque
+ structure that is described in more detail later in this document
+ in the section "Encoded ASN.1 Value Manipulation".
+
+mem A pointer to memory allocated by the LDAP library, such as the
+ attribute type names returned by ldap_first_attribute() and
+ ldap_next_attribute, or the DN returned by ldap_get_dn(). If mem
+
+
+
+Expires: May 2001 [Page 53]
+
+C LDAP API C LDAP Application Program Interface 17 November 2000
+
+
+ is NULL, the ldap_memfree() call does nothing.
+
+ldap_first_attribute() and ldap_next_attribute() will return NULL when
+the end of the attributes is reached, or if there is an error, in which
+case the error parameters in the session handle ld will be set to indi-
+cate the error.
+
+Both routines return a pointer to an allocated buffer containing the
+current attribute name. This SHOULD be freed when no longer in use by
+calling ldap_memfree().
+
+ldap_first_attribute() will allocate and return in ptr a pointer to a
+BerElement used to keep track of the current position. This pointer MAY
+be passed in subsequent calls to ldap_next_attribute() to step through
+the entry's attributes. After a set of calls to ldap_first_attribute()
+and ldap_next_attribute(), if ptr is non-NULL, it SHOULD be freed by
+calling ber_free( ptr, 0 ). Note that it is very important to pass the
+second parameter as 0 (zero) in this call, since the buffer associated
+with the BerElement does not point to separately allocated memory.
+
+The attribute type names returned are suitable for passing in a call to
+ldap_get_values() and friends to retrieve the associated values.
+
+
+16.3. Retrieving the Values of an Attribute
+
+ldap_get_values() and ldap_get_values_len() are used to retrieve the
+values of a given attribute from an entry. ldap_count_values() and
+ldap_count_values_len() are used to count the returned values.
+ldap_value_free() and ldap_value_free_len() are used to free the values.
+
+ char **ldap_get_values(
+ LDAP *ld,
+ LDAPMessage *entry,
+ const char *attr
+ );
+
+ struct berval **ldap_get_values_len(
+ LDAP *ld,
+ LDAPMessage *entry,
+ const char *attr
+ );
+
+ int ldap_count_values( char **vals );
+
+ int ldap_count_values_len( struct berval **vals );
+
+ void ldap_value_free( char **vals );
+
+
+
+Expires: May 2001 [Page 54]
+
+C LDAP API C LDAP Application Program Interface 17 November 2000
+
+
+ void ldap_value_free_len( struct berval **vals );
+
+Parameters are:
+
+ld The session handle.
+
+entry The entry from which to retrieve values, as returned by
+ ldap_first_entry() or ldap_next_entry().
+
+attr The attribute whose values are to be retrieved, as returned by
+ ldap_first_attribute() or ldap_next_attribute(), or a caller-
+ supplied string (e.g., "mail").
+
+vals The values returned by a previous call to ldap_get_values() or
+ ldap_get_values_len().
+
+Two forms of the various calls are provided. The first form is only
+suitable for use with non-binary character string data. The second _len
+form is used with any kind of data.
+
+ldap_get_values() and ldap_get_values_len() return NULL if no values are
+found for attr or if an error occurs.
+
+ldap_count_values() and ldap_count_values_len() return -1 if an error
+occurs such as the vals parameter being invalid.
+
+If a NULL vals parameter is passed to ldap_value_free() or
+ldap_value_free_len(), nothing is done.
+
+Note that the values returned are dynamically allocated and SHOULD be
+freed by calling either ldap_value_free() or ldap_value_free_len() when
+no longer in use.
+
+
+16.4. Retrieving the name of an entry
+
+ldap_get_dn() is used to retrieve the name of an entry.
+ldap_explode_dn() and ldap_explode_rdn() are used to break up a name
+into its component parts. ldap_dn2ufn() is used to convert the name into
+a more "user friendly" format.
+
+ char *ldap_get_dn( LDAP *ld, LDAPMessage *entry );
+
+ char **ldap_explode_dn( const char *dn, int notypes );
+
+ char **ldap_explode_rdn( const char *rdn, int notypes );
+
+ char *ldap_dn2ufn( const char *dn );
+
+
+
+Expires: May 2001 [Page 55]
+
+C LDAP API C LDAP Application Program Interface 17 November 2000
+
+
+Parameters are:
+
+ld The session handle.
+
+entry The entry whose name is to be retrieved, as returned by
+ ldap_first_entry() or ldap_next_entry().
+
+dn The dn to explode, such as returned by ldap_get_dn(). If NULL,
+ a zero length DN is used.
+
+rdn The rdn to explode, such as returned in the components of the
+ array returned by ldap_explode_dn(). If NULL, a zero length DN
+ is used.
+
+notypes A boolean parameter, if non-zero indicating that the dn or rdn
+ components are to have their type information stripped off
+ (i.e., "cn=Babs" would become "Babs").
+
+ldap_get_dn() will return NULL if there is some error parsing the dn,
+setting error parameters in the session handle ld to indicate the error.
+It returns a pointer to newly allocated space that the caller SHOULD
+free by calling ldap_memfree() when it is no longer in use. Note the
+format of the DNs returned is given by [5]. The root DN is returned as
+a zero length string ("").
+
+ldap_explode_dn() returns a NULL-terminated char * array containing the
+RDN components of the DN supplied, with or without types as indicated by
+the notypes parameter. The components are returned in the order they
+appear in the dn. The array returned SHOULD be freed when it is no
+longer in use by calling ldap_value_free().
+
+ldap_explode_rdn() returns a NULL-terminated char * array containing the
+components of the RDN supplied, with or without types as indicated by
+the notypes parameter. The components are returned in the order they
+appear in the rdn. The array returned SHOULD be freed when it is no
+longer in use by calling ldap_value_free().
+
+ldap_dn2ufn() converts the DN into the user friendly format described in
+[14]. The UFN returned is newly allocated space that SHOULD be freed by
+a call to ldap_memfree() when no longer in use.
+
+
+16.5. Retrieving controls from an entry
+
+ldap_get_entry_controls() is used to extract LDAP controls from an
+entry.
+
+
+
+
+
+Expires: May 2001 [Page 56]
+
+C LDAP API C LDAP Application Program Interface 17 November 2000
+
+
+ int ldap_get_entry_controls(
+ LDAP *ld,
+ LDAPMessage *entry,
+ LDAPControl ***serverctrlsp
+ );
+
+Parameters are:
+
+ld The session handle.
+
+entry The entry to extract controls from, as returned by
+ ldap_first_entry() or ldap_next_entry().
+
+serverctrlsp This result parameter will be filled in with an allocated
+ array of controls copied out of entry. The control array
+ SHOULD be freed by calling ldap_controls_free(). If ser-
+ verctrlsp is NULL, no controls are returned. If no con-
+ trols were returned, *serverctrlsp is set to NULL.
+
+ldap_get_entry_controls() returns an LDAP result code that indicates
+whether the reference could be successfully parsed (LDAP_SUCCESS if all
+goes well). If ldap_get_entry_controls() returns a value other than
+LDAP_SUCCESS, the value of the serverctrlsp output parameter is unde-
+fined.
+
+
+
+16.6. Parsing References
+
+ldap_parse_reference() is used to extract referrals and controls from a
+SearchResultReference message.
+
+
+ int ldap_parse_reference(
+ LDAP *ld,
+ LDAPMessage *ref,
+ char ***referralsp,
+ LDAPControl ***serverctrlsp,
+ int freeit
+ );
+
+Parameters are:
+
+ld The session handle.
+
+ref The reference to parse, as returned by ldap_result(),
+ ldap_first_reference(), or ldap_next_reference().
+
+
+
+
+Expires: May 2001 [Page 57]
+
+C LDAP API C LDAP Application Program Interface 17 November 2000
+
+
+referralsp This result parameter will be filled in with an allocated
+ array of character strings. The elements of the array are
+ the referrals (typically LDAP URLs) contained in ref. The
+ array SHOULD be freed when no longer in used by calling
+ ldap_value_free(). If referralsp is NULL, the referral
+ URLs are not returned. If no referrals were returned,
+ *referralsp is set to NULL.
+
+serverctrlsp This result parameter will be filled in with an allocated
+ array of controls copied out of ref. The control array
+ SHOULD be freed by calling ldap_controls_free(). If ser-
+ verctrlsp is NULL, no controls are returned. If no con-
+ trols were returned, *serverctrlsp is set to NULL.
+
+freeit A boolean that determines whether the ref parameter is
+ disposed of or not. Pass any non-zero value to have this
+ routine free ref after extracting the requested informa-
+ tion. This is provided as a convenience; you can also use
+ ldap_msgfree() to free the result later.
+
+ldap_parse_reference() returns an LDAP result code that indicates
+whether the reference could be successfully parsed (LDAP_SUCCESS if all
+goes well). If a value other than LDAP_SUCCESS is returned, the value
+of the referralsp and serverctrlsp result parameters are undefined.
+
+
+
+17. Encoded ASN.1 Value Manipulation
+
+This section describes routines which MAY be used to encode and decode
+BER-encoded ASN.1 values, which are often used inside of control and
+extension values.
+
+With the exceptions of two new functions ber_flatten() and ber_init(),
+these functions are compatible with the University of Michigan LDAP 3.3
+implementation of BER.
+
+Note that the functions defined in this section all provide a method for
+determining success or failure but generally do not provide access to
+specific error codes. Therefore, applications that require precise
+error information when encoding or decoding ASN.1 values SHOULD NOT use
+these functions.
+
+
+17.1. BER Data Structures and Types
+
+The following additional integral types are defined for use in manipula-
+tion of BER encoded ASN.1 values:
+
+
+
+Expires: May 2001 [Page 58]
+
+C LDAP API C LDAP Application Program Interface 17 November 2000
+
+
+ typedef <impl_tag_t> ber_tag_t; /* for BER tags */
+
+ typedef <impl_int_t> ber_int_t; /* for BER ints, enums, and Booleans */
+
+ typedef <impl_unit_t> ber_uint_t; /* unsigned equivalent of ber_uint_t */
+
+ typedef <impl_slen_t> ber_slen_t; /* signed equivalent of ber_len_t */
+
+Note that the actual definition for these four integral types is imple-
+mentation specific; that is, `<impl_tag_t>', `<impl_int_t>',
+`<impl_uint_t>', and `<impl_slen_t>' MUST each be replaced with an
+appropriate implementation-specific type.
+
+The `ber_tag_t' type is an unsigned integral data type that is large
+enough to hold the largest BER tag supported by the API implementation.
+The width (number of significant bits) of `ber_tag_t' MUST be at least
+32, greater than or equal to that of `unsigned int' (so that integer
+promotions won't promote it to `int'), and no wider than that of
+`unsigned long'.
+
+The `ber_int_t' and `ber_uint_t' types are the signed and unsigned vari-
+ants of an integral type that is large enough to hold integers for pur-
+poses of BER encoding and decoding. The width of `ber_int_t' MUST be at
+least 32 and no larger than that of `long'.
+
+The `ber_slen_t' type is the signed variant of the `ber_len_t' integral
+type, i.e. if `ber_len_t' is unsigned long, then `ber_slen_t' is signed
+long. The `<impl_slen_t>' in the `ber_len_t' typedef MUST be replaced
+with an appropriate type. Note that `ber_slen_t' is not used directly
+in the C LDAP API but is provided for the convenience of application
+developers and for use by extensions to the API.
+
+ typedef struct berval {
+ ber_len_t bv_len;
+ char *bv_val;
+ } BerValue;
+
+As defined earlier in the section "Common Data Structures", a berval
+structure contains an arbitrary sequence of bytes and an indication of
+its length. The bv_len element is an unsigned integer. The bv_val is
+not necessarily zero-terminated. Applications MAY allocate their own
+berval structures.
+
+As defined earlier in the section "Common Data Structures", the BerEle-
+ment structure is an opaque structure:
+
+ typedef struct berelement BerElement;
+
+
+
+
+Expires: May 2001 [Page 59]
+
+C LDAP API C LDAP Application Program Interface 17 November 2000
+
+
+It contains not only a copy of the encoded value, but also state infor-
+mation used in encoding or decoding. Applications cannot allocate their
+own BerElement structures. The internal state is neither thread-
+specific nor locked, so two threads SHOULD NOT manipulate the same
+BerElement value simultaneously.
+
+A single BerElement value cannot be used for both encoding and decoding.
+
+17.2. Memory Disposal and Utility Functions
+
+ void ber_bvfree( struct berval *bv );
+
+ber_bvfree() frees a berval structure returned from this API. Both the
+bv->bv_val string and the berval structure itself are freed. If bv is
+NULL, this call does nothing.
+
+ void ber_bvecfree( struct berval **bv );
+
+ber_bvecfree() frees an array of berval structures returned from this
+API. Each of the berval structures in the array are freed using
+ber_bvfree(), then the array itself is freed. If bv is NULL, this call
+does nothing.
+
+ struct berval *ber_bvdup( const struct berval *bv );
+
+ber_bvdup() returns a copy of a berval structure. The bv_val field in
+the returned berval structure points to a different area of memory than
+the bv_val field in the bv argument. The NULL pointer is returned on
+error (e.g. out of memory).
+
+ void ber_free( BerElement *ber, int fbuf );
+
+ber_free() frees a BerElement which is returned from the API calls
+ber_alloc_t() or ber_init(). Each BerElement SHOULD be freed by the
+caller. The second argument fbuf SHOULD always be set to 1 to ensure
+that the internal buffer used by the BER functions is freed as well as
+the BerElement container itself. If ber is NULL, this call does noth-
+ing.
+
+
+17.3. Encoding
+
+ BerElement *ber_alloc_t( int options );
+
+ber_alloc_t() constructs and returns BerElement. The NULL pointer is
+returned on error. The options field contains a bitwise-or of options
+which are to be used when generating the encoding of this BerElement.
+One option is defined and SHOULD always be supplied:
+
+
+
+Expires: May 2001 [Page 60]
+
+C LDAP API C LDAP Application Program Interface 17 November 2000
+
+
+ #define LBER_USE_DER 0x01
+
+When this option is present, lengths will always be encoded in the
+minimum number of octets. Note that this option does not cause values
+of sets to be rearranged in tag and byte order or default values to be
+removed, so these functions are not sufficient for generating DER output
+as defined in X.509 and X.680. If the caller takes responsibility for
+ordering values of sets correctly and removing default values, DER out-
+put as defined in X.509 and X.680 can be produced.
+
+Unrecognized option bits are ignored.
+
+The BerElement returned by ber_alloc_t() is initially empty. Calls to
+ber_printf() will append bytes to the end of the ber_alloc_t().
+
+ int ber_printf( BerElement *ber, const char *fmt, ... );
+
+The ber_printf() routine is used to encode a BER element in much the
+same way that sprintf() works. One important difference, though, is
+that state information is kept in the ber argument so that multiple
+calls can be made to ber_printf() to append to the end of the BER ele-
+ment. ber MUST be a pointer to a BerElement returned by ber_alloc_t().
+ber_printf() interprets and formats its arguments according to the for-
+mat string fmt. ber_printf() returns -1 if there is an error during
+encoding and a non-negative number if successful. As with sprintf(),
+each character in fmt refers to an argument to ber_printf().
+
+The format string can contain the following format characters:
+
+'t' Tag. The next argument is a ber_tag_t specifying the tag to
+ override the next element to be written to the ber. This works
+ across calls. The integer tag value SHOULD contain the tag
+ class, constructed bit, and tag value. For example, a tag of
+ "[3]" for a constructed type is 0xA3U. All implementations MUST
+ support tags that fit in a single octet (i.e., where the tag
+ value is less than 32) and they MAY support larger tags.
+
+'b' Boolean. The next argument is an ber_int_t, containing either 0
+ for FALSE or 0xff for TRUE. A boolean element is output. If
+ this format character is not preceded by the 't' format modif-
+ ier, the tag 0x01U is used for the element.
+
+'e' Enumerated. The next argument is a ber_int_t, containing the
+ enumerated value in the host's byte order. An enumerated ele-
+ ment is output. If this format character is not preceded by the
+ 't' format modifier, the tag 0x0AU is used for the element.
+
+'i' Integer. The next argument is a ber_int_t, containing the
+
+
+
+Expires: May 2001 [Page 61]
+
+C LDAP API C LDAP Application Program Interface 17 November 2000
+
+
+ integer in the host's byte order. An integer element is output.
+ If this format character is not preceded by the 't' format
+ modifier, the tag 0x02U is used for the element.
+
+'B' Bitstring. The next two arguments are a char * pointer to the
+ start of the bitstring, followed by a ber_len_t containing the
+ number of bits in the bitstring. A bitstring element is output,
+ in primitive form. If this format character is not preceded by
+ the 't' format modifier, the tag 0x03U is used for the element.
+
+'X' Reserved and not to be used. In older revisions of this specif-
+ ication,
+
+'n' Null. No argument is needed. An ASN.1 NULL element is output.
+ If this format character is not preceded by the 't' format
+ modifier, the tag 0x05U is used for the element.
+
+'o' Octet string. The next two arguments are a char *, followed by
+ a ber_len_t with the length of the string. The string MAY con-
+ tain null bytes and are do not have to be zero-terminated. An
+ octet string element is output, in primitive form. If this for-
+ mat character is not preceded by the 't' format modifier, the
+ tag 0x04U is used for the element.
+
+'s' Octet string. The next argument is a char * pointing to a
+ zero-terminated string. An octet string element in primitive
+ form is output, which does not include the trailing '\0' (null)
+ byte. If this format character is not preceded by the 't' format
+ modifier, the tag 0x04U is used for the element.
+
+'v' Several octet strings. The next argument is a char **, an array
+ of char * pointers to zero-terminated strings. The last element
+ in the array MUST be a NULL pointer. The octet strings do not
+ include the trailing '\0' (null) byte. Note that a construct
+ like '{v}' is used to get an actual SEQUENCE OF octet strings.
+ The 't' format modifier cannot be used with this format charac-
+ ter.
+
+'V' Several octet strings. A NULL-terminated array of struct berval
+ *'s is supplied. Note that a construct like '{V}' is used to
+ get an actual SEQUENCE OF octet strings. The 't' format modifier
+ cannot be used with this format character.
+
+'{' Begin sequence. No argument is needed. If this format charac-
+ ter is not preceded by the 't' format modifier, the tag 0x30U is
+ used.
+
+'}' End sequence. No argument is needed. The 't' format modifier
+
+
+
+Expires: May 2001 [Page 62]
+
+C LDAP API C LDAP Application Program Interface 17 November 2000
+
+
+ cannot be used with this format character.
+
+'[' Begin set. No argument is needed. If this format character is
+ not preceded by the 't' format modifier, the tag 0x31U is used.
+
+']' End set. No argument is needed. The 't' format modifier cannot
+ be used with this format character.
+
+Each use of a '{' format character SHOULD be matched by a '}' character,
+either later in the format string, or in the format string of a subse-
+quent call to ber_printf() for that BerElement. The same applies to the
+'[' and ']' format characters.
+
+Sequences and sets nest, and implementations of this API MUST maintain
+internal state to be able to properly calculate the lengths.
+
+ int ber_flatten( BerElement *ber, struct berval **bvPtr );
+
+The ber_flatten routine allocates a struct berval whose contents are a
+BER encoding taken from the ber argument. The bvPtr pointer points to
+the returned berval structure, which SHOULD be freed using ber_bvfree().
+This routine returns 0 on success and -1 on error.
+
+The ber_flatten API call is not present in U-M LDAP 3.3.
+
+The use of ber_flatten on a BerElement in which all '{' and '}' format
+modifiers have not been properly matched is an error (i.e., -1 will be
+returned by ber_flatten() if this situation is exists).
+
+
+17.4. Encoding Example
+
+The following is an example of encoding the following ASN.1 data type:
+
+ Example1Request ::= SEQUENCE {
+ s OCTET STRING, -- must be printable
+ val1 INTEGER,
+ val2 [0] INTEGER DEFAULT 0
+ }
+
+
+ int encode_example1(const char *s, ber_int_t val1, ber_int_t val2,
+ struct berval **bvPtr)
+ {
+ BerElement *ber;
+ int rc = -1;
+
+ *bvPtr = NULL; /* in case of error */
+
+
+
+Expires: May 2001 [Page 63]
+
+C LDAP API C LDAP Application Program Interface 17 November 2000
+
+
+ ber = ber_alloc_t(LBER_USE_DER);
+
+ if (ber == NULL) return -1;
+
+ if (ber_printf(ber,"{si",s,val1) == -1) {
+ goto done;
+ }
+
+ if (val2 != 0) {
+ if (ber_printf(ber,"ti",(ber_tag_t)0x80,val2) == -1) {
+ goto done;
+ }
+ }
+
+ if (ber_printf(ber,"}") == -1) {
+ goto done;
+ }
+
+ rc = ber_flatten(ber,bvPtr);
+
+ done:
+ ber_free(ber,1);
+ return rc;
+ }
+
+
+17.5. Decoding
+
+The following two macros are available to applications: LBER_ERROR and
+LBER_DEFAULT. Both of these macros MUST be #define'd as ber_tag_t
+integral values that are treated as invalid tags by the API implementa-
+tion. It is RECOMMENDED that the values of LBER_ERROR and LBER_DEFAULT
+be the same and that they be defined as values where all octets have the
+value 0xFF. ISO C guarantees that these definitions will work:
+
+ #define LBER_ERROR ((ber_tag_t)-1)
+ #define LBER_DEFAULT ((ber_tag_t)-1)
+
+The intent is that LBER_ERROR and LBER_DEFAULT are both defined as the
+integer value that has all octets set to 0xFF, as such a value is not a
+valid BER tag.
+
+ BerElement *ber_init( const struct berval *bv );
+
+The ber_init function constructs a BerElement and returns a new BerEle-
+ment containing a copy of the data in the bv argument. ber_init returns
+the NULL pointer on error.
+
+
+
+
+Expires: May 2001 [Page 64]
+
+C LDAP API C LDAP Application Program Interface 17 November 2000
+
+
+ ber_tag_t ber_scanf( BerElement *ber, const char *fmt, ... );
+
+The ber_scanf() routine is used to decode a BER element in much the same
+way that sscanf() works. One important difference, though, is that some
+state information is kept with the ber argument so that multiple calls
+can be made to ber_scanf() to sequentially read from the BER element.
+The ber argument SHOULD be a pointer to a BerElement returned by
+ber_init(). ber_scanf interprets the bytes according to the format
+string fmt, and stores the results in its additional arguments.
+ber_scanf() returns LBER_ERROR on error, and a different value on suc-
+cess. If an error occurred, the values of all the result parameters are
+undefined.
+
+The format string contains conversion specifications which are used to
+direct the interpretation of the BER element. The format string can
+contain the following characters:
+
+'a' Octet string. A char ** argument MUST be supplied. Memory is
+ allocated, filled with the contents of the octet string, zero-
+ terminated, and the pointer to the string is stored in the argu-
+ ment. The returned value SHOULD be freed using ldap_memfree.
+ The tag of the element MUST indicate the primitive form (con-
+ structed strings are not supported) but is otherwise ignored and
+ discarded during the decoding. This format cannot be used with
+ octet strings which could contain null bytes.
+
+'O' Octet string. A struct berval ** argument MUST be supplied,
+ which upon return points to an allocated struct berval contain-
+ ing the octet string and its length. ber_bvfree() SHOULD be
+ called to free the allocated memory. The tag of the element
+ MUST indicate the primitive form (constructed strings are not
+ supported) but is otherwise ignored during the decoding.
+
+'b' Boolean. A pointer to a ber_int_t MUST be supplied. The
+ ber_int_t value stored will be 0 for FALSE or nonzero for TRUE.
+ The tag of the element MUST indicate the primitive form but is
+ otherwise ignored during the decoding.
+
+'e' Enumerated. A pointer to a ber_int_t MUST be supplied. The
+ enumerated value stored will be in host byte order. The tag of
+ the element MUST indicate the primitive form but is otherwise
+ ignored during the decoding. ber_scanf() will return an error
+ if the value of the enumerated value cannot be stored in a
+ ber_int_t.
+
+'i' Integer. A pointer to a ber_int_t MUST be supplied. The
+ ber_int_t value stored will be in host byte order. The tag of
+ the element MUST indicate the primitive form but is otherwise
+
+
+
+Expires: May 2001 [Page 65]
+
+C LDAP API C LDAP Application Program Interface 17 November 2000
+
+
+ ignored during the decoding. ber_scanf() will return an error
+ if the integer cannot be stored in a ber_int_t.
+
+'B' Bitstring. A char ** argument MUST be supplied which will point
+ to the allocated bits, followed by a ber_len_t * argument, which
+ will point to the length (in bits) of the bitstring returned.
+ ldap_memfree SHOULD be called to free the bitstring. The tag of
+ the element MUST indicate the primitive form (constructed bit-
+ strings are not supported) but is otherwise ignored during the
+ decoding.
+
+'n' Null. No argument is needed. The element is verified to have a
+ zero-length value and is skipped. The tag is ignored.
+
+'t' Tag. A pointer to a ber_tag_t MUST be supplied. The ber_tag_t
+ value stored will be the tag of the next element in the BerEle-
+ ment ber, represented so it can be written using the 't' format
+ of ber_printf(). The decoding position within the ber argument
+ is unchanged by this; that is, the fact that the tag has been
+ retrieved does not affect future use of ber.
+
+'v' Several octet strings. A char *** argument MUST be supplied,
+ which upon return points to an allocated NULL-terminated array
+ of char *'s containing the octet strings. NULL is stored if the
+ sequence is empty. ldap_memfree SHOULD be called to free each
+ element of the array and the array itself. The tag of the
+ sequence and of the octet strings are ignored.
+
+'V' Several octet strings (which could contain null bytes). A
+ struct berval *** MUST be supplied, which upon return points to
+ a allocated NULL-terminated array of struct berval *'s contain-
+ ing the octet strings and their lengths. NULL is stored if the
+ sequence is empty. ber_bvecfree() can be called to free the
+ allocated memory. The tag of the sequence and of the octet
+ strings are ignored.
+
+'x' Skip element. The next element is skipped. No argument is
+ needed.
+
+'{' Begin sequence. No argument is needed. The initial sequence
+ tag and length are skipped.
+
+'}' End sequence. No argument is needed.
+
+'[' Begin set. No argument is needed. The initial set tag and
+ length are skipped.
+
+']' End set. No argument is needed.
+
+
+
+Expires: May 2001 [Page 66]
+
+C LDAP API C LDAP Application Program Interface 17 November 2000
+
+
+ ber_tag_t ber_peek_tag( BerElement *ber,
+ ber_len_t *lenPtr );
+
+ber_peek_tag() returns the tag of the next element to be parsed in the
+BerElement argument. The length of this element is stored in the
+*lenPtr argument. LBER_DEFAULT is returned if there is no further data
+to be read. The decoding position within the ber argument is unchanged
+by this call; that is, the fact that ber_peek_tag() has been called does
+not affect future use of ber.
+
+ ber_tag_t ber_skip_tag( BerElement *ber, ber_len_t *lenPtr );
+
+ber_skip_tag() is similar to ber_peek_tag(), except that the state
+pointer in the BerElement argument is advanced past the first tag and
+length, and is pointed to the value part of the next element. This rou-
+tine SHOULD only be used with constructed types and situations when a
+BER encoding is used as the value of an OCTET STRING. The length of the
+value is stored in *lenPtr.
+
+ ber_tag_t ber_first_element( BerElement *ber,
+ ber_len_t *lenPtr, char **opaquePtr );
+
+ ber_tag_t ber_next_element( BerElement *ber,
+ ber_len_t *lenPtr, char *opaque );
+
+ber_first_element() and ber_next_element() are used to traverse a SET,
+SET OF, SEQUENCE or SEQUENCE OF data value. ber_first_element() calls
+ber_skip_tag(), stores internal information in *lenPtr and *opaquePtr,
+and calls ber_peek_tag() for the first element inside the constructed
+value. LBER_DEFAULT is returned if the constructed value is empty.
+ber_next_element() positions the state at the start of the next element
+in the constructed type. LBER_DEFAULT is returned if there are no
+further values.
+
+The len and opaque values SHOULD NOT be used by applications other than
+as arguments to ber_next_element(), as shown in the example below.
+
+
+17.6. Decoding Example
+
+The following is an example of decoding an ASN.1 data type:
+
+ Example2Request ::= SEQUENCE {
+ dn OCTET STRING, -- must be printable
+ scope ENUMERATED { b (0), s (1), w (2) },
+ ali ENUMERATED { n (0), s (1), f (2), a (3) },
+ size INTEGER,
+ time INTEGER,
+
+
+
+Expires: May 2001 [Page 67]
+
+C LDAP API C LDAP Application Program Interface 17 November 2000
+
+
+ tonly BOOLEAN,
+ attrs SEQUENCE OF OCTET STRING, -- must be printable
+ [0] SEQUENCE OF SEQUENCE {
+ type OCTET STRING -- must be printable,
+ crit BOOLEAN DEFAULT FALSE,
+ value OCTET STRING
+ } OPTIONAL }
+
+ #define TAG_CONTROL_LIST 0xA0U /* context specific cons 0 */
+
+ int decode_example2(struct berval *bv)
+ {
+ BerElement *ber;
+ ber_len_t len;
+ ber_tag_t res;
+ ber_int_t scope, ali, size, time, tonly;
+ char *dn = NULL, **attrs = NULL;
+ int i,rc = 0;
+
+ ber = ber_init(bv);
+ if (ber == NULL) {
+ fputs("ERROR ber_init failed\n", stderr);
+ return -1;
+ }
+
+ res = ber_scanf(ber,"{aiiiib{v}",&dn,&scope,&ali,
+ &size,&time,&tonly,&attrs);
+
+ if (res == LBER_ERROR) {
+ fputs("ERROR ber_scanf failed\n", stderr);
+ ber_free(ber,1);
+ return -1;
+ }
+
+ /* *** use dn */
+ ldap_memfree(dn);
+
+ for (i = 0; attrs != NULL && attrs[i] != NULL; i++) {
+ /* *** use attrs[i] */
+ ldap_memfree(attrs[i]);
+ }
+ ldap_memfree((char *)attrs);
+
+ if (ber_peek_tag(ber,&len) == TAG_CONTROL_LIST) {
+ char *opaque;
+ ber_tag_t tag;
+
+ for (tag = ber_first_element(ber,&len,&opaque);
+
+
+
+Expires: May 2001 [Page 68]
+
+C LDAP API C LDAP Application Program Interface 17 November 2000
+
+
+ tag != LBER_DEFAULT;
+ tag = ber_next_element (ber,&len,opaque)) {
+
+ ber_len_t tlen;
+ ber_tag_t ttag;
+ char *type;
+ ber_int_t crit;
+ struct berval *value;
+
+ if (ber_scanf(ber,"{a",&type) == LBER_ERROR) {
+ fputs("ERROR cannot parse type\n", stderr);
+ break;
+ }
+ /* *** use type */
+ ldap_memfree(type);
+
+ ttag = ber_peek_tag(ber,&tlen);
+ if (ttag == 0x01U) { /* boolean */
+ if (ber_scanf(ber,"b",
+ &crit) == LBER_ERROR) {
+ fputs("ERROR cannot parse crit\n",
+ stderr);
+ rc = -1;
+ break;
+ }
+ } else if (ttag == 0x04U) { /* octet string */
+ crit = 0;
+ } else {
+ fputs("ERROR extra field in controls\n",
+ stderr );
+ break;
+ }
+
+ if (ber_scanf(ber,"O}",&value) == LBER_ERROR) {
+ fputs("ERROR cannot parse value\n", stderr);
+ rc = -1;
+ break;
+ }
+ /* *** use value */
+ ber_bvfree(value);
+ }
+ }
+
+ if ( rc == 0 ) { /* no errors so far */
+ if (ber_scanf(ber,"}") == LBER_ERROR) {
+ rc = -1;
+ }
+ }
+
+
+
+Expires: May 2001 [Page 69]
+
+C LDAP API C LDAP Application Program Interface 17 November 2000
+
+
+ ber_free(ber,1);
+
+ return rc;
+ }
+
+
+
+18. Security Considerations
+
+LDAPv2 supports security through protocol-level authentication using
+clear-text passwords. LDAPv3 adds support for SASL [12] (Simple Authen-
+tication Security Layer) methods. LDAPv3 also supports operation over a
+secure transport layer using Transport Layer Security TLS [9]. Readers
+are referred to the protocol documents for discussion of related secu-
+rity considerations.
+
+Implementations of this API SHOULD be cautious when handling authentica-
+tion credentials. In particular, keeping long-lived copies of creden-
+tials without the application's knowledge is discouraged.
+
+
+19. Acknowledgements
+
+Many members of the IETF ASID and LDAPEXT working groups as well as
+members of the Internet at large have provided useful comments and
+suggestions that have been incorporated into this document. Chris
+Weider deserves special mention for his contributions as co-author of
+earlier revisions of this document.
+
+The original material upon which this specification is based was sup-
+ported by the National Science Foundation under Grant No. NCR-9416667.
+
+
+20. Copyright
+
+Copyright (C) The Internet Society (1997-2000). All Rights Reserved.
+
+This document and translations of it may be copied and furnished to oth-
+ers, and derivative works that comment on or otherwise explain it or
+assist in its implementation may be prepared, copied, published and dis-
+tributed, in whole or in part, without restriction of any kind, provided
+that the above copyright notice and this paragraph are included on all
+such copies and derivative works. However, this document itself may not
+be modified in any way, such as by removing the copyright notice or
+references to the Internet Society or other Internet organizations,
+except as needed for the purpose of developing Internet standards in
+which case the procedures for copyrights defined in the Internet Stan-
+dards process must be followed, or as required to translate it into
+
+
+
+Expires: May 2001 [Page 70]
+
+C LDAP API C LDAP Application Program Interface 17 November 2000
+
+
+languages other than English.
+
+The limited permissions granted above are perpetual and will not be
+revoked by the Internet Society or its successors or assigns.
+
+This document and the information contained herein is provided on an "AS
+IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK
+FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT
+LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
+INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FIT-
+NESS FOR A PARTICULAR PURPOSE.
+
+
+21. Bibliography
+
+[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+ Levels", RFC 2119, March 1997.
+
+[2] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access Protocol
+ (v3)", RFC 2251, December 1997.
+
+[3] M. Wahl, A. Coulbeck, T. Howes, S. Kille, W. Yeong, C. Robbins,
+ "Lightweight Directory Access Protocol (v3): Attribute Syntax
+ Definitions", RFC 2252, December 1997.
+
+[4] The Directory: Selected Attribute Syntaxes. CCITT, Recommendation
+ X.520.
+
+[5] M. Wahl, S. Kille, T. Howes, "Lightweight Directory Access Protocol
+ (v3): A UTF-8 String Representation of Distinguished Names", RFC
+ 2253, December 1997.
+
+[6] F. Yergeau, "UTF-8, a transformation format of Unicode and ISO
+ 10646", RFC 2044, October 1996.
+
+[7] K. Simonsen, "Character Mnemonics and Character Sets," RFC 1345,
+ June 1992.
+
+[8] "Programming Languages - C", ANSI/ISO Standard 9899, revised 1997.
+
+[9] J. Hodges, R. Morgan, M. Wahl, "Lightweight Directory Access Proto-
+ col (v3): Extension for Transport Layer Security", INTERNET-DRAFT
+ (work in progress) <draft-ietf-ldapext-ldapv3-tls-05.txt>, June
+ 1999.
+
+[10] R. Hinden, S. Deering, "IP Version 6 Addressing Architecture," RFC
+ 1884, December 1995.
+
+
+
+
+Expires: May 2001 [Page 71]
+
+C LDAP API C LDAP Application Program Interface 17 November 2000
+
+
+[11] A. Herron, T. Howes, M. Wahl, A. Anantha, "LDAP Control Extension
+ for Server Side Sorting of Search Results", INTERNET-DRAFT (work in
+ progress) <draft-ietf-ldapext-sorting-02.txt>, 5 April 1999.
+
+[12] J. Meyers, "Simple Authentication and Security Layer (SASL)", RFC
+ 2222, October 1997.
+
+[13] T. Howes, "The String Representation of LDAP Search Filters," RFC
+ 2254, December 1997.
+
+[14] S. Kille, "Using the OSI Directory to Achieve User Friendly Nam-
+ ing," RFC 1781, March 1995.
+
+
+22. Authors' Addresses
+
+ Mark Smith (document editor)
+ Netscape Communications Corp.
+ 901 San Antonio Rd.
+ Palo Alto, CA 94303-4900
+ Mail Stop SCA17 - 201
+ USA
+ +1 650 937-3477
+ mcs at netscape.com
+
+ Tim Howes
+ Loudcloud, Inc.
+ 599 N. Mathilda Avenue
+ Sunnyvale, CA 94085
+ USA
+ +1 408 744-7300
+ howes at loudcloud.com
+
+ Andy Herron
+ Microsoft Corp.
+ 1 Microsoft Way
+ Redmond, WA 98052
+ USA
+ +1 425 882-8080
+ andyhe at microsoft.com
+
+ Mark Wahl
+ Sun Microsystems, Inc.
+ 8911 Capital of Texas Hwy, Suite 4140
+ Austin, TX 78759
+ USA
+ +1 626 919 3600
+ Mark.Wahl at sun.com
+
+
+
+Expires: May 2001 [Page 72]
+
+C LDAP API C LDAP Application Program Interface 17 November 2000
+
+
+ Anoop Anantha
+ Microsoft Corp.
+ 1 Microsoft Way
+ Redmond, WA 98052
+ USA
+ +1 425 882-8080
+ anoopa at microsoft.com
+
+
+23. Appendix A - Sample C LDAP API Code
+
+ #include <stdio.h>
+ #include <ldap.h>
+
+ main()
+ {
+ LDAP *ld;
+ LDAPMessage *res, *e;
+ int i, rc;
+ char *a, *dn;
+ BerElement *ptr;
+ char **vals;
+
+ /* open an LDAP session */
+ if ( (ld = ldap_init( "dotted.host.name", LDAP_PORT )) == NULL )
+ return 1;
+
+ /* authenticate as nobody */
+ if (( rc = ldap_simple_bind_s( ld, NULL, NULL )) != LDAP_SUCCESS ) {
+ fprintf( stderr, "ldap_simple_bind_s: %s\n",
+ ldap_err2string( rc ));
+ ldap_unbind( ld );
+ return 1;
+ }
+
+ /* search for entries with cn of "Babs Jensen", return all attrs */
+ if (( rc = ldap_search_s( ld, "o=University of Michigan, c=US",
+ LDAP_SCOPE_SUBTREE, "(cn=Babs Jensen)", NULL, 0, &res ))
+ != LDAP_SUCCESS ) {
+ fprintf( stderr, "ldap_search_s: %s\n",
+ ldap_err2string( rc ));
+ if ( res == NULL ) {
+ ldap_unbind( ld );
+ return 1;
+ }
+ }
+
+ /* step through each entry returned */
+
+
+
+Expires: May 2001 [Page 73]
+
+C LDAP API C LDAP Application Program Interface 17 November 2000
+
+
+ for ( e = ldap_first_entry( ld, res ); e != NULL;
+ e = ldap_next_entry( ld, e ) ) {
+ /* print its name */
+ dn = ldap_get_dn( ld, e );
+ printf( "dn: %s\n", dn );
+ ldap_memfree( dn );
+
+ /* print each attribute */
+ for ( a = ldap_first_attribute( ld, e, &ptr ); a != NULL;
+ a = ldap_next_attribute( ld, e, ptr ) ) {
+ printf( "\tattribute: %s\n", a );
+
+ /* print each value */
+ vals = ldap_get_values( ld, e, a );
+ for ( i = 0; vals[i] != NULL; i++ ) {
+ printf( "\t\tvalue: %s\n", vals[i] );
+ }
+ ldap_value_free( vals );
+ ldap_memfree( a );
+ }
+ if ( ptr != NULL ) {
+ ber_free( ptr, 0 );
+ }
+ }
+ /* free the search results */
+ ldap_msgfree( res );
+
+ /* close and free connection resources */
+ ldap_unbind( ld );
+
+ return 0;
+ }
+
+
+24. Appendix B - Namespace Consumed By This Specification
+
+The following 2 prefixes are used in this specification to name func-
+tions:
+ ldap_
+ ber_
+
+The following 6 prefixes are used in this specification to name struc-
+tures, unions, and typedefs:
+ ldap
+ LDAP
+ mod_vals_u
+ ber
+ Ber
+
+
+
+Expires: May 2001 [Page 74]
+
+C LDAP API C LDAP Application Program Interface 17 November 2000
+
+
+ timeval
+
+The following 3 prefixes are used in this specification to name #defined
+macros:
+ LDAP
+ LBER_
+ mod_
+
+
+25. Appendix C - Summary of Requirements for API Extensions
+
+As the LDAP protocol is extended, this C LDAP API will need to be
+extended as well. For example, an LDAPv3 control extension has already
+been defined for server-side sorting of search results [7]. This appen-
+dix summarizes the requirements for extending this API.
+
+25.1. Compatibility
+
+Extensions to this document SHOULD NOT, by default, alter the behavior
+of any of the APIs specified in this document. If an extension option-
+ally changes the behavior of any existing C LDAP API function calls, the
+behavior change MUST be well documented. If an extension that operates
+on an LDAP session affects a chain of messages that was previously
+obtained by a call to ldap_result() or by calling a synchronous search
+routine, this MUST be well documented.
+
+25.2. Style
+
+Extensions to this API SHOULD follow the general style and naming con-
+ventions used in this document. For example, function names SHOULD
+start with "ldap_" or "ber_" and consist entirely of lowercase letters,
+digits, and underscore ('_') characters. It is RECOMMENDED that private
+and experimental extensions use only the following prefixes for macros,
+types, and function names:
+ LDAP_X_
+ LBER_X_
+ ldap_x_
+ ber_x_
+and that these prefixes not be used by standard extensions.
+
+25.3. Dependence on Externally Defined Types
+
+Extensions to this API SHOULD minimize dependencies on types and macros
+that are defined in system headers and generally use only intrinsic
+types that are part of the C language, types defined in this specifica-
+tion, or types defined in the extension document itself.
+
+
+
+
+
+Expires: May 2001 [Page 75]
+
+C LDAP API C LDAP Application Program Interface 17 November 2000
+
+
+25.4. Compile Time Information
+
+Extensions to this API SHOULD conform to the requirements contained in
+the "Retrieving Information at Compile Time" section of this document.
+That is, extensions SHOULD define a macro of the form:
+
+ #define LDAP_API_FEATURE_x level
+
+so that applications can detect the presence or absence of the extension
+at compile time and also test the version or level of the extension pro-
+vided by an API implementation.
+
+25.5. Runtime Information
+
+Extensions to this API SHOULD conform to the requirements contained in
+the "Retrieving Information During Execution" section of this document.
+That is, each extension SHOULD be given a character string name and that
+name SHOULD appear in the ldapai_extensions array field of the LDAPAPI-
+Info structure following a successful call to ldap_get_option() with an
+option parameter value of LDAP_OPT_API_INFO. In addition, information
+about the extension SHOULD be available via a call to ldap_get_option()
+with an option parameter value of LDAP_OPT_API_FEATURE_INFO.
+
+25.6. Values Used for Session Handle Options
+
+Extensions to this API that add new session options (for use with the
+ldap_get_option() and ldap_set_option() functions) SHOULD meet the
+requirements contained in the last paragraph of the "LDAP Session Handle
+Options" section of this document. Specifically, standards track docu-
+ments MUST use values for option macros that are between 0x1000 and
+0x3FFF inclusive and private and experimental extensions MUST use values
+for the option macros that are between 0x4000 and 0x7FFF inclusive.
+
+
+26. Appendix D - Known Incompatibilities with RFC 1823
+
+This appendix lists known incompatibilities between this API specifica-
+tion and the one contained in RFC 1823, beyond the additional API func-
+tions added in support of LDAPv3.
+
+
+26.1. Opaque LDAP Structure
+
+In RFC 1823, some fields in the LDAP structure were exposed to applica-
+tion programmers. To provide a cleaner interface and to make it easier
+for implementations to evolve over time without sacrificing binary com-
+patibility with older applications, the LDAP structure is now entirely
+opaque. The new ldap_set_option() and ldap_get_option() calls can be
+
+
+
+Expires: May 2001 [Page 76]
+
+C LDAP API C LDAP Application Program Interface 17 November 2000
+
+
+used to manipulate per-session and global options.
+
+
+26.2. Additional Result Codes
+
+The following new result code macros were introduced to support LDAPv3:
+ LDAP_REFERRAL
+ LDAP_ADMINLIMIT_EXCEEDED
+ LDAP_UNAVAILABLE_CRITICAL_EXTENSION
+ LDAP_CONFIDENTIALITY_REQUIRED
+ LDAP_SASL_BIND_IN_PROGRESS
+ LDAP_AFFECTS_MULTIPLE_DSAS
+ LDAP_CONNECT_ERROR
+ LDAP_NOT_SUPPORTED
+ LDAP_CONTROL_NOT_FOUND
+ LDAP_NO_RESULTS_RETURNED
+ LDAP_MORE_RESULTS_TO_RETURN
+ LDAP_CLIENT_LOOP
+ LDAP_REFERRAL_LIMIT_EXCEEDED
+
+
+26.3. Freeing of String Data with ldap_memfree()
+
+All strings received from the API (e.g., those returned by the
+ldap_get_dn() or ldap_dn2ufn() functions) SHOULD be freed by calling
+ldap_memfree() not free(). RFC 1823 did not define an ldap_memfree()
+function.
+
+
+26.4. Changes to ldap_result()
+
+The meaning of the all parameter to ldap_result has changed slightly.
+Nonzero values from RFC 1823 correspond to LDAP_MSG_ALL (0x01). There
+is also a new possible value, LDAP_MSG_RECEIVED (0x02).
+
+The result type LDAP_RES_MODDN is now returned where RFC 1823 returned
+LDAP_RES_MODRDN. The actual value for these two macros is the same
+(0x6D).
+
+
+26.5. Changes to ldap_first_attribute() and ldap_next_attribute
+
+Each non-NULL return value SHOULD be freed by calling ldap_memfree()
+after use. In RFC 1823, these two functions returned a pointer to a
+per-session buffer, which was not very thread-friendly.
+
+After the last call to ldap_first_attribute() or ldap_next_attribute(),
+the value set in the ptr parameter SHOULD be freed by calling ber_free(
+
+
+
+Expires: May 2001 [Page 77]
+
+C LDAP API C LDAP Application Program Interface 17 November 2000
+
+
+ptr, 0 ). RFC 1823 did not mention that the ptr value SHOULD be freed.
+
+The type of the ptr parameter was changed from void * to BerElement *.
+
+
+26.6. Changes to ldap_modrdn() and ldap_modrdn_s() Functions
+
+In RFC 1823, the ldap_modrdn() and ldap_modrdn_s() functions include a
+parameter called deleteoldrdn. This does not match the great majority
+of implementations, so in this specification the deleteoldrdn parameter
+was removed from ldap_modrdn() and ldap_modrdn_s(). Two additional
+functions that support deleteoldrdn and are widely implemented as well
+were added to this specification: ldap_modrdn2() and ldap_modrdn2_s().
+
+
+26.7. Changes to the berval structure
+
+In RFC 1823, the bv_len element of the berval structure was defined as
+an `unsigned long'. In this specification, the type is implementation-
+specific, although it MUST be an unsigned integral type that is at least
+32 bits in size. See the appendix "Data Types and Legacy Implementa-
+tions" for additional considerations.
+
+
+26.8. API Specification Clarified
+
+RFC 1823 left many things unspecified, including behavior of various
+memory disposal functions when a NULL pointer is presented, requirements
+for headers, values of many macros, and so on. This specification is
+more complete and generally tighter than the one in RFC 1823.
+
+
+26.9. Deprecated Functions
+
+A number of functions that are in RFC 1823 are labeled as "deprecated"
+in this specification. In most cases, a replacement that provides
+equivalent functionality has been defined. The deprecated functions
+are:
+
+ ldap_bind()
+ Use ldap_simple_bind() or ldap_sasl_bind() instead.
+
+ ldap_bind_s()
+ Use ldap_simple_bind_s() or ldap_sasl_bind_s() instead.
+
+ ldap_kerberos_bind() and ldap_kerberos_bind_s()
+ No equivalent functions are provided.
+
+
+
+
+Expires: May 2001 [Page 78]
+
+C LDAP API C LDAP Application Program Interface 17 November 2000
+
+
+ ldap_modrdn() and ldap_modrdn2()
+ Use ldap_rename() instead.
+
+ ldap_modrdn_s() and ldap_modrdn2_s()
+ Use ldap_rename_s() instead.
+
+ ldap_open()
+ Use ldap_init() instead.
+
+ ldap_perror()
+ Use ldap_get_option( ld, LDAP_OPT_RESULT_CODE, &rc ) followed
+ by fprintf( stderr, "%s: %s", msg, ldap_err2string( rc ))
+ instead.
+
+ ldap_result2error()
+ Use ldap_parse_result() instead.
+
+
+27. Appendix E - Data Types and Legacy Implementations
+
+The data types associated with the length of a ber value (ber_len_t),
+and the tag (ber_tag_t) have been defined in this specification as
+unsigned integral types of implementation-specific size. The data type
+used for encoding and decoding ber integer, enumerated, and boolean
+values has been defined in this specification as a signed integral type
+of implementation-specific size. This was done so that source and
+binary compatibility of the C LDAP API can be maintained across ILP32
+environments (where int, long, and pointers are all 32 bits in size) and
+LP64 environments (where ints remain 32 bits but longs and pointers grow
+to 64 bits).
+
+In older implementations of the C LDAP API, such as those based on RFC
+1823, implementors may have chosen to use an `unsigned long' for length
+and tag values. If a long data type was used for either of these items,
+a port of an application to a 64-bit operating system using the LP64
+data model would find the size of the types used by the C LDAP API to
+increase. Also, if the legacy implementation had chosen to implement
+the tag and types as an unsigned int, adoption of a specification that
+mandated use of unsigned longs would cause a source incompatibility in
+an LP64 application. By using implementation-specific data types, the C
+LDAP API implementation is free to choose the correct data type and the
+ability to maintain source compatibility.
+
+For example, suppose a legacy implementation chose to define the return
+value of ber_skip_tag() as an unsigned long but wishes to have the
+library return a 32-bit quantity in both ILP32 and LP64 data models.
+The following typedefs for ber_tag_t will provide a fixed sized data
+structure while preserving existing ILP32 source -- all without
+
+
+
+Expires: May 2001 [Page 79]
+
+C LDAP API C LDAP Application Program Interface 17 November 2000
+
+
+generating compiler warnings:
+ #include <limits.h> /* provides UINT_MAX in ISO C */
+ #if UINT_MAX >= 0xffffffffU
+ typedef unsigned int ber_tag_t;
+ #else
+ typedef unsigned long ber_tag_t;
+ #endif
+
+Similar code can be used to define appropriate ber_len_t, ber_int_t,
+ber_slen_t and ber_uint_t types.
+
+
+28. Appendix F - Changes Made Since Last Document Revision
+
+The previous version of this document was draft-ietf-ldapext-ldap-c-
+api-04.txt, dated 8 October 1999. This appendix lists all of the
+changes made to that document to produce this one.
+
+28.1. API Changes
+
+ "Header Requirements" section: added requirement that the simple pro-
+ gram provided must execute as well as compile without errors.
+
+ "LDAP Session Handle Options" section: changed the name of the
+ LDAP_OPT_ERROR_NUMBER option to LDAP_OPT_RESULT_CODE. Allow
+ LDAP_OPT_ON to be defined as an implementation specific value (to
+ avoid problems on architectures where the value ((void *)1) is not
+ usable).
+
+ "Initializing an LDAP Session" section: allow use of the value zero
+ for the `portno' parameter to mean "use port 389."
+
+ "Searching" section: added LDAP_DEFAULT_SIZELIMIT (-1) to allow
+ application programmers to use the sizelimit from the LDAP session
+ handle with ldap_search_ext() and ldap_search_ext_s().
+
+ "Modifying an entry" section: moved mod_vals union out of LDAPMod and
+ added mod_vals_u_t typedef so users of the API can declare variables
+ using the union type. "Handling Errors and Parsing Results" section:
+ added text to require that ldap_err2string() MUST NOT return NULL.
+
+ "A Client Control That Governs Referral Processing" section: modified
+ the text to specify that a ber_uint_t value should be used to hold
+ the flags.
+
+
+
+
+
+
+
+Expires: May 2001 [Page 80]
+
+C LDAP API C LDAP Application Program Interface 17 November 2000
+
+
+28.2. Editorial Changes and Clarifications
+
+ "Overview of LDAP API Use and General Requirements" section: added
+ text to clarify our use of the term "asynchronous."
+
+ "Retrieving Information During Execution" section: added text
+ describing the `ldapai_vendor_name' and `ldapai_vendor_version'
+ fields (text was accidently deleted during a previous round of
+ edits).
+
+ "LDAP Session Handle Options" section: improved the text that
+ describes the LDAP_OPT_TIMELIMIT, LDAP_OPT_SIZELIMIT, and
+ LDAP_OPT_RESULT_CODE options. Provided details and an example of the
+ correct LDAP_OPT_HOST_NAME string to return when the `portno' passed
+ to ldap_init() is not zero or 389.
+
+ "Result Codes" section: renamed section (was "LDAP Error Codes").
+
+ "Authenticating to the directory" section: clarified that the `dn',
+ `cred', and `passwd' parameters can be NULL. Added text indicate
+ that the `servercredp' is set to NULL if an API error occurs.
+
+ "Performing LDAP Operations" section: replaced "All functions take a
+ session handle" with "Most functions...."
+
+ "Search" section: removed the detailed discussion of the session han-
+ dle options (already covered in the "Retrieving Information During
+ Execution" section). Also removed the word "global" when discussing
+ the session default value for the `timeout' parameter. Also clari-
+ fied that a NULL `base' parameter means use a zero-length string for
+ the base DN.
+
+ "Comparing a Value Against an Entry" section: corrected the "success-
+ ful" return codes for ldap_compare_ext_s() and ldap_compare_s() (was
+ LDAP_SUCCESS; changed to LDAP_COMPARE_TRUE or LDAP_COMPARE_FALSE).
+
+ "Extended Operations" section: added text to indicate that the
+ `retoidp' and `retdatap' result parameters are set to NULL if an API
+ error occurs in ldap_extended_operation_s().
+
+ "Handling Errors and Parsing Results" section: added text to say that
+ the `matcheddnp' result parameter will be set to NULL if the server
+ does not return a matched DN string. Added text to indicate that
+ serverctrlsp can be NULL. Added text to indicate that *retoidpp,
+ *retdatap, *referralsp, and *serverctrlsp will be set to NULL if no
+ items of that type are returned. Removed specific reference to
+ LDAP_NO_SUCH_OBJECT result code when discussing the `matcheddnp'
+ result parameter and added clarifying note about "" vs. NULL.
+
+
+
+Expires: May 2001 [Page 81]
+
+C LDAP API C LDAP Application Program Interface 17 November 2000
+
+
+ "Parsing References" section: added text to indicate that *refer-
+ ralsp, and *serverctrlsp will be set to NULL if no items of that type
+ are returned.
+
+ "Obtaining Results and Peeking Inside LDAP Messages" section: added
+ text to say that LDAPMessage chains MAY be tied to a session handle.
+
+ "BER Data Structures and Types" section: removed note about
+ ber_uint_t not being used in this document (it is now). Changed text
+ to simplify the description of ber_slen_t. Removed misleading sen-
+ tence about the width of ber_uint_t.
+
+ "Encoded ASN.1 Value Manipulation / Encoding" section: added note
+ that 'X' is reserved. Also fixed a few small bugs in the example
+ code.
+
+ "Encoded ASN.1 Value Manipulation / Decoding" section: clarified the
+ requirements for LBER_ERROR and LBER_DEFAULT (expressed using octets
+ instead of bits). Also fixed a few small bugs in the example code.
+
+ Added the following text to all descriptions of the `serverctrls' and
+ `clientctrls' parameters: ", or NULL if no <server/client> controls
+ are to be used."
+
+ Added the following text to the description of all `dn' and `rdn'
+ parameters: "If NULL, a zero length DN is sent to the server."
+
+ Replaced many occurrences of the phrase "error code" with "result
+ code" throughout the document.
+
+ Added text to indicate that the value of the `msgidp' result parame-
+ ter is undefined if an error occurs in the following functions:
+ ldap_sasl_bind(), ldap_search_ext(), ldap_compare_ext(),
+ ldap_modify_ext(), ldap_add_ext(), ldap_delete_ext(),
+ ldap_extended_operation().
+
+ Added text to indicate that the `res' result parameter is set to NULL
+ if an API error occurs in the following functions: ldap_result(),
+ ldap_search_s(), ldap_search_st().
+
+ Added text to indicate that all result parameters have undefined
+ values if an API error is returned by the following functions:
+ ldap_parse_result(), ldap_parse_sasl_bind_result(),
+ ldap_parse_extended_result(), ldap_parse_reference(), ber_scanf().
+
+ Added angle brackets around ficticious impl_XXX_t types to make it
+ more obvious that these are not real "C" types, e.g., typedef
+ <impl_len_t> ber_len_t'.
+
+
+
+Expires: May 2001 [Page 82]
+
+C LDAP API C LDAP Application Program Interface 17 November 2000
+
+
+ Appendix B: Added mod_vals_u and removed PLDAP from the struct,
+ unions, and typedefs prefix list.
+
+ Appendix C: Added note in "Compatibility" section about extensions
+ possible affecting chains of messages and the fact that that must be
+ well documented. Appendix D: Improved text for ldap_perror() (what
+ to use instead).
+
+ "Authors" section: updated contact information for Mark Smith, Tim
+ Howes, and Mark Wahl.
+
+ Fixed a few obvious typos, improved indentation, added missing blank
+ lines, and so on.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Expires: May 2001 [Page 83]
+
Added: openldap/vendor/openldap-release/doc/drafts/draft-ietf-ldapext-ldapv3-dupent-xx.txt
===================================================================
--- openldap/vendor/openldap-release/doc/drafts/draft-ietf-ldapext-ldapv3-dupent-xx.txt (rev 0)
+++ openldap/vendor/openldap-release/doc/drafts/draft-ietf-ldapext-ldapv3-dupent-xx.txt 2007-09-15 10:38:52 UTC (rev 844)
@@ -0,0 +1,522 @@
+
+
+LDAPEXT Working Group J. Sermersheim
+Internet Draft Novell, Inc
+Document: draft-ietf-ldapext-ldapv3-dupent-08.txt Sept 2002
+Intended Category: Standard Track
+
+
+ LDAP Control for a Duplicate Entry Representation of Search Results
+
+
+1. Status of this Memo
+
+ This document is an Internet-Draft and is in full conformance with
+ all provisions of Section 10 of RFC2026 [1].
+
+ Internet-Drafts are working documents of the Internet Engineering
+ Task Force (IETF), its areas, and its working groups. Note that
+ other groups may also distribute working documents as Internet-
+ Drafts. Internet-Drafts are draft documents valid for a maximum of
+ six months and may be updated, replaced, or obsoleted by other
+ documents at any time. It is inappropriate to use Internet- Drafts
+ as reference material or to cite them other than as "work in
+ progress."
+
+ The list of current Internet-Drafts can be accessed at
+ http://www.ietf.org/ietf/1id-abstracts.txt
+
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html.
+
+2. Abstract
+
+ This document describes a Duplicate Entry Representation control
+ extension for the LDAP Search operation. By using the control with
+ an LDAP search, a client requests that the server return separate
+ entries for each value held in the specified attribute(s). For
+ instance, if a specified attribute of an entry holds multiple
+ values, the search operation will return multiple instances of that
+ entry, each instance holding a separate single value in that
+ attribute.
+
+3. Introduction
+
+ This document describes controls, which allow duplicate entries to
+ be returned in the result set of search operation. Each duplicated
+ entry represents a distinct value (or combination of values) of the
+ set of specified multi-valued attributes.
+
+ For example, an application may need to produce an ordered list of
+ entries, sorted by a multi-valued attribute, where each attribute
+ value is represented in the list. The Server-Side Sorting control
+ [RFC2891] allows the server to order search result entries based on
+ attribute values (sort keys). But it does not allow one to specify
+ behavior when an attribute contains multiple values. The default
+
+
+Sermersheim Internet-Draft - Expires Mar 2003 Page 1
+LDAP Control for a Duplicate Entry Representation of Search Results
+
+
+ behavior, as outlined in 7.9 of [X.511], is to use the smallest
+ order value as the sort key.
+
+ In order to produce an ordered list, where each value of a multi-
+ valued attribute is sorted into the list, a separate control is
+ needed which causes the set of entries to be expanded sufficiently
+ to represent each attribute value prior to sorting.
+
+
+
+ An example of this would be a sorted list of all telephone numbers
+ in an organization. Because any entry may have multiple telephone
+ numbers, and the list is to be sorted by telephone number, the list
+ must be able to contain duplicate entries, each with its own unique
+ telephone number.
+
+ Another example would be an application that needs to display an
+ ordered list of all members of a group. It would use this control
+ to create a result set of duplicate groupOfNames entries, each with
+ a single, unique value in its member attribute.
+
+4. Conventions
+
+ The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
+ used in this document carry the meanings described in [RFC2119].
+
+ All controlValue data is represented as ASN.1 in this document, and
+ is to be BER encoded as stated in Section 5.1 of [RFC2251].
+
+5. The Controls
+
+ Support for the controls is advertised by the presence of their OID
+ in the supportedControl attribute of a server's root DSE. The OID
+ for the request control is "2.16.840.1.113719.1.27.101.1" and the
+ OIDs for the response controls are "2.16.840.1.113719.1.27.101.2"
+ and "2.16.840.1.113719.1.27.101.3".
+
+5.1 Request Control
+
+ This control is included in the searchRequest message as part of the
+ controls field of the LDAPMessage, as defined in Section 4.1.12 of
+ [RFC2251].
+
+ The controlType is set to "2.16.840.1.113719.1.27.101.1". The
+ criticality MAY be set to either TRUE or FALSE. The controlValue is
+ defined as the following DuplicateEntryRequest:
+
+ DuplicateEntryRequest ::= SEQUENCE {
+ AttributeDescriptionList, -- from [RFC2251]
+ PartialApplicationAllowed BOOLEAN DEFAULT TRUE }
+
+
+5.1.1 AttributeDescriptionList Semantics
+
+Sermersheim Internet-Draft - Expires Mar 2003 Page 2
+LDAP Control for a Duplicate Entry Representation of Search Results
+
+
+
+ The AttributeDescriptionList data type is described in 4.1.5 of
+ [RFC2251] and describes a list of zero or more AttributeDescription
+ types as also described in 4.1.5 of [RFC2251]. Both definitions are
+ repeated here for convenience:
+
+ AttributeDescriptionList ::= SEQUENCE OF
+ AttributeDescription
+
+ AttributeDescription ::= LDAPString
+
+ A value of AttributeDescription is based on the following BNF:
+
+ attributeDescription = AttributeType [ ";" <options> ]
+
+ While processing a search request, a server implementation examines
+ this list. If a specified attribute or attribute subtype exists in
+ an entry to be returned by the search operation, and that attribute
+ holds multiple values, the server treats the entry as if it were
+ multiple, duplicate entries -- the specified attributes each holding
+ a single, unique value from the original set of values of that
+ attribute. Note that this may result in search result entries that
+ no longer match the search filter.
+
+ Specifying an attribute supertype has the effect of treating all
+ values of that attribute's subtypes as if they were values of the
+ specified attribute supertype. See Section 6.2 for an example of
+ this.
+
+ When attribute descriptions contain subtyping options, they are
+ treated in the same manner as is described in Section 4.1.5 of
+ [RFC2251]. Semantics are undefined if an attribute description
+ contains a non-subtyping option, and SHOULD NOT be specified by
+ clients.
+
+ When two or more attributes are specified by this control, the
+ number of duplicate entries is the combination of all values in each
+ attribute. Because of the potential complexity involved in servicing
+ multiple attributes, server implementations MAY choose to support a
+ limited number of attributes in the control.
+
+ There is a special case where either no attributes are specified, or
+ an attribute description value of "*" is specified. In this case,
+ all attributes are used. (The "*" allows the client to request all
+ user attributes in addition to specific operational attributes).
+
+ If an attribute is unrecognized, that attribute is ignored when
+ processing the control.
+
+5.1.2 PartialApplicationAllowed Semantics
+
+ The PartialApplicationAllowed field is used to specify whether the
+ client will allow the server to apply this control to a subset of
+
+Sermersheim Internet-Draft - Expires Mar 2003 Page 3
+LDAP Control for a Duplicate Entry Representation of Search Results
+
+
+ the search result set. If TRUE, the server is free to arbitrarily
+ apply this control to no, any, or all search results. If FALSE, the
+ server MUST either apply the control to all search results or fail
+ to support the control at all.
+
+ Client implementations use the DuplicateSearchResult control to
+ discover which search results have been affected by this control.
+
+5.2 Response Controls
+
+ Two response controls are defined to provide feedback while the
+ search results are being processed; DuplicateSearchResult and
+ DuplicateEntryResponseDone.
+
+ The DuplicateSearchResult control is sent with all SearchResultEntry
+ operations that contain search results which have been modified by
+ the DuplicateEntryRequest control.
+
+ The DuplicateEntryResponseDone control is sent with the
+ SearchResultDone operation in order to convey completion
+ information.
+
+5.2.1 The DuplicateSearchResult control
+
+ This control is included in the SearchResultEntry message of any
+ search result that holds an entry that has been modified by the
+ DuplicateEntryRequest control as part of the controls field of the
+ LDAPMessage, as defined in Section 4.1.12 of [RFC2251]. This control
+ is absent on search results that are unaffected by
+ DuplicateEntryRequest control.
+
+ The controlType is set to "2.16.840.1.113719.1.27.101.2". The
+ controlValue is not included.
+
+5.2.2 The DuplicateEntryResponseDone control
+
+ This control is included in the searchResultDone message as part of
+ the controls field of the LDAPMessage, as defined in Section 4.1.12
+ of [RFC2251].
+
+ The controlType is set to "2.16.840.1.113719.1.27.101.3". The
+ controlValue is defined as the following DuplicateEntryResponseDone:
+
+ DuplicateEntryResponseDone ::= SEQUENCE {
+ resultCode, -- From [RFC2251]
+ errorMessage [0] LDAPString OPTIONAL,
+ attribute [1] AttributeDescription OPTIONAL }
+
+ A resultCode field is provided here to allow the server to convey to
+ the client that an error resulted due to the control being serviced.
+ For example, a search that would ordinarily complete successfully
+ may fail with a sizeLimitExceeded error due to this control being
+
+
+Sermersheim Internet-Draft - Expires Mar 2003 Page 4
+LDAP Control for a Duplicate Entry Representation of Search Results
+
+
+ processed. If the operation is successfull, the value will be
+ success (0).
+
+ The errorMessage field MAY be populated with a human-readable string
+ in the event of an erroneous result code.
+
+ The attribute field MAY be set to the value of the first attribute
+ specified by the DuplicateEntryRequest that was in error. The
+ client MUST ignore the attribute field if the result is success.
+
+6. Protocol Examples
+
+6.1 Simple example
+
+ This example will show this control being used to produce a list of
+ all telephone numbers in the dc=example,dc=net container. Let's say
+ the following three entries exist in this container;
+
+ dn: cn=User1,dc=example,dc=net
+ telephoneNumber: 555-0123
+
+ dn: cn=User2,dc=example,dc=net
+ telephoneNumber: 555-8854
+ telephoneNumber: 555-4588
+ telephoneNumber: 555-5884
+
+ dn: cn=User3,dc=example,dc=net
+ telephoneNumber: 555-9425
+ telephoneNumber: 555-7992
+
+ First an LDAP search is specified with a baseDN of
+ "dc=example,dc=net", subtree scope, filter set to
+ "(telephoneNumber=*)". A DuplicateEntryRequest control is attached
+ to the search, specifying "telephoneNumber" as the attribute
+ description, and the search request is sent to the server.
+
+ The set of search results returned by the server would then consist
+ of the following entries:
+
+ dn: cn=User1,dc=example,dc=net
+ telephoneNumber: 555-0123
+ <no DuplicateSearchResult control sent with search result>
+
+ dn: cn=User2,dc=example,dc=net
+ telephoneNumber: 555-8854
+ control: 2.16.840.1.113719.1.27.101.2
+
+ dn: cn=User2,dc=example,dc=net
+ telephoneNumber: 555-4588
+ control: 2.16.840.1.113719.1.27.101.2
+
+ dn: cn=User2,dc=example,dc=net
+ telephoneNumber: 555-5884
+
+Sermersheim Internet-Draft - Expires Mar 2003 Page 5
+LDAP Control for a Duplicate Entry Representation of Search Results
+
+
+ control: 2.16.840.1.113719.1.27.101.2
+
+ dn: cn=User3,dc=example,dc=net
+ telephoneNumber: 555-9425
+ control: 2.16.840.1.113719.1.27.101.2
+
+ dn: cn=User3,dc=example,dc=net
+ telephoneNumber: 555-7992
+ control: 2.16.840.1.113719.1.27.101.2
+
+ All but the first entry are accompanied by the DuplicateSearchResult
+ control when sent from the server.
+
+ Note that it is not necessary to use an attribute in this control
+ that is specified in the search filter. This example only does so,
+ because the result was to obtain a list of telephone numbers.
+
+6.2 Specifying multiple attributes
+
+ A more complicated example involving multiple attributes will result
+ in more entries. If we assume these entries in the directory:
+
+ dn: cn=User1,dc=example,dc=net
+ cn: User1
+ givenName: User One
+ mail: user1 at example.net
+
+ dn: cn=User2,dc=example,dc=net
+ cn: User2
+ givenName: User Two
+ mail: user2 at example.net
+ mail: usertwo at example.net
+
+ In this example, we specify mail and name in the attribute list. By
+ specifying name, all attribute subtypes of name will also be
+ considered. Following is the resulting set of entries:
+
+ dn: cn=User1,dc=example,dc=net
+ cn: User1
+ mail: user1 at example.net
+ control: 2.16.840.1.113719.1.27.101.2
+
+ dn: cn=User1,dc=example,dc=net
+ givenName: User One
+ mail: user1 at example.net
+ control: 2.16.840.1.113719.1.27.101.2
+
+ dn: cn=User2,dc=example,dc=net
+ cn: User2
+ mail: user2 at example.net
+ control: 2.16.840.1.113719.1.27.101.2
+
+ dn: cn=User2,dc=example,dc=net
+
+Sermersheim Internet-Draft - Expires Mar 2003 Page 6
+LDAP Control for a Duplicate Entry Representation of Search Results
+
+
+ cn: User2
+ mail: usertwo at example.net
+ control: 2.16.840.1.113719.1.27.101.2
+
+ dn: cn=User2,dc=example,dc=net
+ givenName: User Two
+ mail: user2 at example.net
+ control: 2.16.840.1.113719.1.27.101.2
+
+ dn: cn=User2,dc=example,dc=net
+ givenName: User Two
+ mail: usertwo at example.net
+ control: 2.16.840.1.113719.1.27.101.2
+
+6.3 Listing the members of a groupOfNames
+
+ This example shows how the controls can be used to turn a single
+ groupOfNames entry into multiple duplicate entries. Let's say this
+ is our groupOfNames entry:
+
+ dn: cn=Administrators,dc=example,dc=net
+ cn: Administrators
+ member: cn=aBaker,dc=example,dc=net
+ member: cn=cDavis,dc=example,dc=net
+ member: cn=bChilds,dc=example,dc=net
+ member: cn=dEvans,dc=example,dc=net
+
+ We could set our search base to "cn=Administrators,dc=example,dc=net
+ ", filter to "(objectClass=*)", use an object scope (to restrict it
+ to this entry) and send the duplicateEntryRequest control with
+ "member" as its attribute value. The resulting set would look like
+ this:
+
+ dn: cn=Administrators,dc=example,dc=net
+ member: cn=aBaker,dc=example,dc=net
+ control: 2.16.840.1.113719.1.27.101.2
+
+ dn: cn=Administrators,dc=example,dc=net
+ member: cn=cDavis,dc=example,dc=net
+ control: 2.16.840.1.113719.1.27.101.2
+
+ dn: cn=Administrators,dc=example,dc=net
+ member: cn=bChilds,dc=example,dc=net
+ control: 2.16.840.1.113719.1.27.101.2
+
+ dn: cn=Administrators,dc=example,dc=net
+ member: cn=dEvans,dc=example,dc=net
+ control: 2.16.840.1.113719.1.27.101.2
+
+ This list can then be sorted by member and displayed (also by
+ member) in a list.
+
+7. Relationship to other controls
+
+Sermersheim Internet-Draft - Expires Mar 2003 Page 7
+LDAP Control for a Duplicate Entry Representation of Search Results
+
+
+
+ This control is intended (but not limited) to be used with the
+ Server Side Sorting control [RFC2891]. By pairing this control with
+ the Server Side Sorting control, One can produce a set of entries,
+ sorted by attribute values, where each attribute value is
+ represented in the sorted set. Server implementations MUST ensure
+ that this control is processed before sorting the result of a
+ search, as this control alters the result set of search.
+
+ This control MAY also be used with the Virtual List View [VLV]
+ control (which has a dependency on the Server Side Sort control).
+ The nature of the dependency between the VLV control and the Sort
+ control is such that the Sorting takes place first. Because the sort
+ happens first, and because this control is processed before the sort
+ control, the impact of this control on the VLV control is minimal.
+ Some server implementations may need to carefully consider how to
+ handle the typedown functionality of the VLV control when paired
+ with this control. The details of this are heavily implementation
+ dependent and are beyond the scope of this document.
+
+8. Notes for Implementers
+
+ Both client and server implementations MUST be aware that using this
+ control could potentially result in a very large set of search
+ results. Servers MAY return an adminLimitExceeded result in the
+ response control due to inordinate consumption of resources. This
+ may be due to some a priori knowledge such as a server restriction
+ of the number of attributes in the request control that it's willing
+ to service, or it may be due to the server attempting to service the
+ control and running out of resources.
+
+ Client implementations MUST be aware that when using this control,
+ search entries returned will contain a subset of the values of any
+ specified attribute.
+
+ If this control is used in a chained environment, servers SHOULD NOT
+ pass this control to other servers. Instead they SHOULD gather
+ results and apply this control themselves.
+
+9. Security Considerations
+
+ This control allows finer control of the result set returned by an
+ LDAP search operation and as such may be used in a denial of service
+ attack. See Section 8 for more information on how this is detected
+ and handled.
+
+10. Acknowledgments
+
+ The author gratefully thanks the input and support of participants
+ of the LDAP-EXT working group.
+
+11. References
+
+
+Sermersheim Internet-Draft - Expires Mar 2003 Page 8
+LDAP Control for a Duplicate Entry Representation of Search Results
+
+
+ [RFC2251]
+ Wahl, M, S. Kille and T. Howes, "Lightweight Directory Access
+ Protocol (v3)", Internet RFC, December, 1997.
+ Available as RFC 2251.
+
+ [RFC2891]
+ Wahl, M, A. Herron and T. Howes, "LDAP Control Extension for Server
+ Side Sorting of Search Results", Internet RFC, August, 2000.
+ Available as RFC 2891.
+
+ [VLV]
+ Boreham, D, Sermersheim, J, Anantha, A, Armijo, M, "LDAP Extensions
+ for Scrolling View Browsing of Search Results", Internet Draft,
+ April, 2000.
+ Available as draft-ietf-ldapext-ldapv3-vlv-xx.txt.
+
+ [X.511]
+ ITU-T Rec. X.511, "The Directory: Abstract Service Definition",
+ 1993.
+
+ [RFC2119]
+ Bradner, Scott, "Key Words for use in RFCs to Indicate Requirement
+ Levels", Internet Draft, March, 1997.
+ Available as RFC 2119.
+
+12. Author's Address
+
+ Jim Sermersheim
+ Novell, Inc.
+ 1800 South Novell Place
+ Provo, Utah 84606, USA
+ jimse at novell.com
+ +1 801 861-3088
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sermersheim Internet-Draft - Expires Mar 2003 Page 9
Added: openldap/vendor/openldap-release/doc/drafts/draft-ietf-ldapext-ldapv3-vlv-xx.txt
===================================================================
--- openldap/vendor/openldap-release/doc/drafts/draft-ietf-ldapext-ldapv3-vlv-xx.txt (rev 0)
+++ openldap/vendor/openldap-release/doc/drafts/draft-ietf-ldapext-ldapv3-vlv-xx.txt 2007-09-15 10:38:52 UTC (rev 844)
@@ -0,0 +1,625 @@
+
+Internet-Draft D. Boreham, Bozeman Pass
+LDAPext Working Group J. Sermersheim, Novell
+Intended Category: Standards Track A. Kashi, Microsoft
+<draft-ietf-ldapext-ldapv3-vlv-06.txt>
+Expires: Nov 2002 May 2002
+
+
+ LDAP Extensions for Scrolling View Browsing of Search Results
+
+
+1. Status of this Memo
+
+ This document is an Internet-Draft and is in full conformance with
+ all provisions of Section 10 of RFC2026.
+
+ Internet-Drafts are working documents of the Internet Engineering
+ Task Force (IETF), its areas, and its working groups. Note that other
+ groups may also distribute working documents as Internet-Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference
+ material or to cite them other than as "work in progress."
+
+ The list of current Internet-Drafts can be accessed at
+ http://www.ietf.org/ietf/1id-abstracts.txt
+
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html.
+
+ This document is intended to be submitted, after review and revision,
+ as a Standards Track document. Distribution of this memo is
+ unlimited.
+ Please send comments to the authors.
+
+
+2. Abstract
+
+ This document describes a Virtual List View control extension for the
+ Lightweight Directory Access Protocol (LDAP) Search operation. This
+ control is designed to allow the "virtual list box" feature, common
+ in existing commercial e-mail address book applications, to be
+ supported efficiently by LDAP servers. LDAP servers' inability to
+ support this client feature is a significant impediment to LDAP
+ replacing proprietary protocols in commercial e-mail systems.
+
+ The control allows a client to specify that the server return, for a
+ given LDAP search with associated sort keys, a contiguous subset of
+ the search result set. This subset is specified in terms of offsets
+ into the ordered list, or in terms of a greater than or equal
+ comparison value.
+
+
+ Boreham et al Internet-Draft 1
+
+ LDAP Extensions for Scrolling View May 2002
+ Browsing of Search Results
+
+3. Conventions used in this document
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY" in this document are
+ to be interpreted as described in RFC 2119 [Bradner97].
+
+
+4. Background
+
+ A Virtual List is a graphical user interface technique employed where
+ ordered lists containing a large number of entries need to be
+ displayed. A window containing a small number of visible list entries
+ is drawn. The visible portion of the list may be relocated to
+ different points within the list by means of user input. This input
+ can be to a scroll bar slider; from cursor keys; from page up/down
+ keys; from alphanumeric keys for "typedown". The user is given the
+ impression that they may browse the complete list at will, even
+ though it may contain millions of entries. It is the fact that the
+ complete list contents are never required at any one time that
+ characterizes Virtual List View. Rather than fetch the complete list
+ from wherever it is stored (typically from disk or a remote server),
+ only that information which is required to display the part of the
+ list currently in view is fetched. The subject of this document is
+ the interaction between client and server required to implement this
+ functionality in the context of the results from a sorted LDAP search
+ request.
+
+ For example, suppose an e-mail address book application displays a
+ list view onto the list containing the names of all the holders of e-
+ mail accounts at a large university. The list is sorted
+ alphabetically. While there may be tens of thousands of entries in
+ this list, the address book list view displays only 20 such accounts
+ at any one time. The list has an accompanying scroll bar and text
+ input window for type-down. When first displayed, the list view shows
+ the first 20 entries in the list, and the scroll bar slider is
+ positioned at the top of its range. Should the user drag the slider
+ to the bottom of its range, the displayed contents of the list view
+ should be updated to show the last 20 entries in the list. Similarly,
+ if the slider is positioned somewhere in the middle of its travel,
+ the displayed contents of the list view should be updated to contain
+ the 20 entries located at that relative position within the complete
+ list. Starting from any display point, if the user uses the cursor
+ keys or clicks on the scroll bar to request that the list be scrolled
+ up or down by one entry, the displayed contents should be updated to
+ reflect this. Similarly the list should be displayed correctly when
+ the user requests a page scroll up or down. Finally, when the user
+ types characters in the type-down window, the displayed contents of
+ the list should "jump" or "seek" to the appropriate point within the
+ list. For example, if the user types "B", the displayed list could
+ center around the first user with a name beginning with the letter
+ "B". When this happens, the scroll bar slider should also be updated
+ to reflect the new relative location within the list.
+
+ Boreham et al Internet-Draft 2
+
+ LDAP Extensions for Scrolling View May 2002
+ Browsing of Search Results
+
+
+ This document defines a request control which extends the LDAP search
+ operation. Always used in conjunction with the server side sorting
+ control [SSS], this allows a client to retrieve selected portions of
+ large search result set in a fashion suitable for the implementation
+ of a virtual list view.
+
+
+5. Client-Server Interaction
+
+ The Virtual List View control extends a regular LDAP Search operation
+ which must also include a server-side sorting control [SSS]. Rather
+ than returning the complete set of appropriate SearchResultEntry
+ messages, the server is instructed to return a contiguous subset of
+ those entries, taken from the sorted result set, centered around a
+ particular target entry. Henceforth, in the interests of brevity, the
+ sorted search result set will be referred to as "the list".
+
+ The sort control MAY contain any sort specification valid for the
+ server. The attributeType field in the first SortKeyList sequence
+ element has special significance for "typedown".
+
+ The desired target entry and the number of entries to be returned,
+ both before and after that target entry in the list, are determined
+ by the client's VirtualListViewRequest control.
+
+ When the server returns the set of entries to the client, it attaches
+ a VirtualListViewResponse control to the SearchResultDone message.
+ The server returns in this control: its current estimate for the list
+ content count, the location within the list corresponding to the
+ target entry, any error codes, and optionally a context identifier.
+
+ The target entry is specified in the VirtualListViewRequest control
+ by one of two methods. The first method is for the client to indicate
+ the target entry's offset within the list. The second way is for the
+ client to supply an attribute assertion value. The value is compared
+ against the values of the attribute specified as the primary sort key
+ in the sort control attached to the search operation. The first sort
+ key in the SortKeyList is the primary sort key. The target entry is
+ the first entry in the list with value greater than or equal to (in
+ the primary sort order), the presented value. The order is determined
+ by rules defined in [SSS]. Selection of the target entry by this
+ means is designed to implement "typedown". Note that it is possible
+ that no entry satisfies these conditions, in which case there is no
+ target entry. This condition is indicated by the server returning the
+ special value contentCount + 1 in the target position field.
+
+ Because the server may not have an accurate estimate of the number of
+ entries in the list, and to take account of cases where the list size
+ is changing during the time the user browses the list, and because
+ the client needs a way to indicate specific list targets "beginning"
+
+ Boreham et al Internet-Draft 3
+
+ LDAP Extensions for Scrolling View May 2002
+ Browsing of Search Results
+
+ and "end", offsets within the list are transmitted between client and
+ server as ratios---offset to content count. The server sends its
+ latest estimate as to the number of entries in the list (content
+ count) to the client in every response control. The client sends its
+ assumed value for the content count in every request control. The
+ server examines the content count and offsets presented by the client
+ and computes the corresponding offsets within the list, based on its
+ own idea of the content count.
+
+ Si = Sc * (Ci / Cc)
+
+ Where:
+ Si is the actual list offset used by the server
+ Sc is the server's estimate for content count
+ Ci is the client's submitted offset
+ Cc is the client's submitted content count
+ The result is rounded to the nearest integer.
+
+ If the content count is stable, and the client returns to the server
+ the content count most recently received, Cc = Sc and the offsets
+ transmitted become the actual server list offsets.
+
+ The following special cases exist when the client is specifying the
+ offset and content count:
+ - an offset of one and a content count of non-one (Ci = 1, Cc != 1)
+ indicates that the target is the first entry in the list.
+ - equivalent values (Ci = Cc) indicate that the target is the last
+ entry in the list.
+ - a content count of zero, and a non-zero offset (Cc = 0, Ci != 0)
+ means the client has no idea what the content count is, the server
+ MUST use its own content count estimate in place of the client's.
+
+ Because the server always returns contentCount and targetPosition,
+ the client can always determine which of the returned entries is the
+ target entry. Where the number of entries returned is the same as the
+ number requested, the client is able to identify the target by simple
+ arithmetic. Where the number of entries returned is not the same as
+ the number requested (because the requested range crosses the
+ beginning or end of the list, or both), the client must use the
+ target position and content count values returned by the server to
+ identify the target entry. For example, suppose that 10 entries
+ before and 10 after the target were requested, but the server returns
+ 13 entries, a content count of 100 and a target position of 3. The
+ client can determine that the first entry must be entry number 1 in
+ the list, therefore the 13 entries returned are the first 13 entries
+ in the list, and the target is the third one.
+
+ A server-generated context identifier MAY be returned to clients. A
+ client receiving a context identifier SHOULD return it unchanged in a
+ subsequent request which relates to the same list. The purpose of
+
+
+ Boreham et al Internet-Draft 4
+
+ LDAP Extensions for Scrolling View May 2002
+ Browsing of Search Results
+
+ this interaction is to enhance the performance and effectiveness of
+ servers which employ approximate positioning.
+
+
+6. The Controls
+
+ Support for the virtual list view control extension is indicated by
+ the presence of the OID "2.16.840.1.113730.3.4.9" in the
+ supportedControl attribute of a server's root DSE.
+
+6.1. Request Control
+
+ This control is included in the SearchRequest message as part of the
+ controls field of the LDAPMessage, as defined in Section 4.1.12 of
+ [LDAPv3]. The controlType is set to "2.16.840.1.113730.3.4.9". The
+ criticality SHOULD be set to TRUE. If this control is included in a
+ SearchRequest message, a Server Side Sorting request control [SSS]
+ MUST also be present in the message. The controlValue is an OCTET
+ STRING whose value is the BER-encoding of the following SEQUENCE:
+
+ VirtualListViewRequest ::= SEQUENCE {
+ beforeCount INTEGER (0..maxInt),
+ afterCount INTEGER (0..maxInt),
+ CHOICE {
+ byoffset [0] SEQUENCE {
+ offset INTEGER (0 .. maxInt),
+ contentCount INTEGER (0 .. maxInt) },
+ greaterThanOrEqual [1] AssertionValue },
+ contextID OCTET STRING OPTIONAL }
+
+ beforeCount indicates how many entries before the target entry the
+ client wants the server to send. afterCount indicates the number of
+ entries after the target entry the client wants the server to send.
+ offset and contentCount identify the target entry as detailed in
+ section 4. greaterThanOrEqual is an attribute assertion value defined
+ in [LDAPv3]. If present, the value supplied in greaterThanOrEqual is
+ used to determine the target entry by comparison with the values of
+ the attribute specified as the primary sort key. The first list entry
+ who's value is no less than (less than or equal to when the sort
+ order is reversed) the supplied value is the target entry. If
+ present, the contextID field contains the value of the most recently
+ received contextID field from a VirtualListViewResponse control. The
+ type AssertionValue and value maxInt are defined in [LDAPv3].
+ contextID values have no validity outwith the connection on which
+ they were received. That is, a client should not submit a contextID
+ which it received from another connection, a connection now closed,
+ or a different server.
+
+
+6.2. Response Control
+
+
+ Boreham et al Internet-Draft 5
+
+ LDAP Extensions for Scrolling View May 2002
+ Browsing of Search Results
+
+ This control is included in the SearchResultDone message as part of
+ the controls field of the LDAPMessage, as defined in Section 4.1.12
+ of [LDAPv3].
+
+ The controlType is set to "2.16.840.1.113730.3.4.10". The criticality
+ is FALSE (MAY be absent). The controlValue is an OCTET STRING, whose
+ value is the BER encoding of a value of the following SEQUENCE:
+
+ VirtualListViewResponse ::= SEQUENCE {
+ targetPosition INTEGER (0 .. maxInt),
+ contentCount INTEGER (0 .. maxInt),
+ virtualListViewResult ENUMERATED {
+ success (0),
+ operationsError (1),
+ unwillingToPerform (53),
+ insufficientAccessRights (50),
+ busy (51),
+ timeLimitExceeded (3),
+ adminLimitExceeded (11),
+ sortControlMissing (60),
+ offsetRangeError (61),
+ other (80) },
+ contextID OCTET STRING OPTIONAL }
+
+ targetPosition gives the list offset for the target entry.
+ contentCount gives the server's estimate of the current number of
+ entries in the list. Together these give sufficient information for
+ the client to update a list box slider position to match the newly
+ retrieved entries and identify the target entry. The contentCount
+ value returned SHOULD be used in a subsequent VirtualListViewRequest
+ control. contextID is a server-defined octet string. If present, the
+ contents of the contextID field SHOULD be returned to the server by a
+ client in a subsequent VirtualListViewRequest control.
+
+ The virtualListViewResult codes which are common to the LDAP
+ searchResponse (adminLimitExceeded, timeLimitExceeded, busy,
+ operationsError, unwillingToPerform, insufficientAccessRights) have
+ the same meanings as defined in [LDAPv3], but they pertain
+ specifically to the VLV operation. For example, the server could
+ exceed an administration limit processing a SearchRequest with a
+ VirtualListViewRequest control. However, the same administration
+ limit would not be exceeded should the same SearchRequest be
+ submitted by the client without the VirtualListViewRequest control.
+ In this case, the client can determine that an administration limit
+ has been exceeded in servicing the VLV request, and can if it chooses
+ resubmit the SearchRequest without the VirtualListViewRequest
+ control.
+
+ insufficientAccessRights means that the server denied the client
+ permission to perform the VLV operation.
+
+
+ Boreham et al Internet-Draft 6
+
+ LDAP Extensions for Scrolling View May 2002
+ Browsing of Search Results
+
+ If the server determines that the results of the search presented
+ exceed the range specified in INTEGER values, it MUST return
+ offsetRangeError.
+
+6.2.1 virtualListViewError
+
+ A new LDAP error is introduced called virtualListViewError. Its value
+ is 76.
+ [Note to the IESG/IANA/RFC Editor: the value 76 has been suggested by
+ experts, had expert review, and is currently being used by some
+ implementations. The intent is to have this number designated as an
+ official IANA assigned LDAP Result Code (see draft-ietf-ldapbis-iana-
+ xx.txt, Section 3.5)]
+
+ If the server returns any code other than success (0) for
+ virtualListViewResult, then the server SHOULD return
+ virtualListViewError as the resultCode of the SearchResultDone
+ message.
+
+
+7. Protocol Example
+
+ Here we walk through the client-server interaction for a specific
+ virtual list view example: The task is to display a list of all 78564
+ people in the US company "Ace Industry". This will be done by
+ creating a graphical user interface object to display the list
+ contents, and by repeatedly sending different versions of the same
+ virtual list view search request to the server. The list view
+ displays 20 entries on the screen at a time.
+
+ We form a search with baseDN "o=Ace Industry, c=us"; search scope
+ subtree; filter "objectClass=inetOrgPerson". We attach a server sort
+ order control to the search, specifying ascending sort on attribute
+ "cn". To this base search, we attach a virtual list view request
+ control with contents determined by the user activity and send the
+ search to the server. We display the results from each search in the
+ list window and update the slider position.
+
+ When the list view is first displayed, we want to initialize the
+ contents showing the beginning of the list. Therefore, we set
+ beforeCount = 0, afterCount = 19, contentCount = 0, offset = 1 and
+ send the request to the server. The server duly returns the first 20
+ entries in the list, plus the content count = 78564 and
+ targetPosition = 1. We therefore leave the scroll bar slider at its
+ current location (the top of its range).
+
+ Say that next the user drags the scroll bar slider down to the bottom
+ of its range. We now wish to display the last 20 entries in the list,
+ so we set beforeCount = 19, afterCount = 0, contentCount = 78564,
+ offset = 78564 and send the request to the server. The server returns
+
+
+ Boreham et al Internet-Draft 7
+
+ LDAP Extensions for Scrolling View May 2002
+ Browsing of Search Results
+
+ the last 20 entries in the list, plus the content count = 78564 and
+ targetPosition = 78564.
+
+ Next the user presses a page up key. Our page size is 20, so we set
+ beforeCount = 0, afterCount = 19, contentCount = 78564, offset =
+ 78564-19-20 and send the request to the server. The server returns
+ the preceding 20 entries in the list, plus the content count = 78564
+ and targetPosition = 78525.
+
+ Now the user grabs the scroll bar slider and drags it to 68% of the
+ way down its travel. 68% of 78564 is 53424 so we set beforeCount = 9,
+ afterCount = 10, contentCount = 78564, offset = 53424 and send the
+ request to the server. The server returns the preceding 20 entries in
+ the list, plus the content count = 78564 and targetPosition = 53424.
+
+ Lastly, the user types the letter "B". We set beforeCount = 9,
+ afterCount = 10 and greaterThanOrEqual = "B". The server finds the
+ first entry in the list not less than "B", let's say "Babs Jensen",
+ and returns the nine preceding entries, the target entry, and the
+ proceeding 10 entries. The server returns content count = 78564 and
+ targetPosition = 5234 and so the client updates its scroll bar slider
+ to 6.7% of full scale.
+
+
+8. Notes for Implementers
+
+ While the feature is expected to be generally useful for arbitrary
+ search and sort specifications, it is specifically designed for those
+ cases where the result set is very large. The intention is that this
+ feature be implemented efficiently by means of pre-computed indices
+ pertaining to a set of specific cases. For example, an offset
+ relating to "all the employees in the local organization, sorted by
+ surname" would be a common case.
+
+ The intention for client software is that the feature should fit
+ easily with the host platform's graphical user interface facilities
+ for the display of scrolling lists. Thus the task of the client
+ implementers should be one of reformatting up the requests for
+ information received from the list view code to match the format of
+ the virtual list view request and response controls.
+
+ Client implementers should note that any offset value returned by the
+ server may be approximate. Do not design clients > which only operate
+ correctly when offsets are exact.
+
+ Server implementers using indexing technology which features
+ approximate positioning should consider returning context identifiers
+ to clients. The use of a context identifier will allow the server to
+ distinguish between client requests which relate to different
+ displayed lists on the client. Consequently the server can decide
+ more intelligently whether to reposition an existing database cursor
+
+ Boreham et al Internet-Draft 8
+
+ LDAP Extensions for Scrolling View May 2002
+ Browsing of Search Results
+
+ accurately to within a short distance of its current position, or to
+ reposition to an approximate position. Thus the client will see
+ precise offsets for "short" repositioning (e.g. paging up or down),
+ but approximate offsets for a "long" reposition (e.g. a slider
+ movement).
+
+ Server implementers are free to return status code unwillingToPerform
+ should their server be unable to service any particular VLV search.
+ This might be because the resolution of the search is computationally
+ infeasible, or because excessive server resources would be required
+ to service the search.
+
+ Client implementers should note that this control is only defined on
+ a client interaction with a single server. If a server returns
+ referrals as a part of its response to the search request, the client
+ is responsible for deciding when and how to apply this control to the
+ referred-to servers, and how to collate the results from multiple
+ servers.
+
+
+9. Relationship to "Simple Paged Results"
+
+ These controls are designed to support the virtual list view, which
+ has proved hard to implement with the Simple Paged Results mechanism
+ [SPaged]. However, the controls described here support any operation
+ possible with the Simple Paged Results mechanism. The two mechanisms
+ are not complementary; rather one has a superset of the other's
+ features. One area where the mechanism presented here is not a strict
+ superset of the Simple Paged Results scheme is that here we require a
+ sort order to be specified. No such requirement is made for paged
+ results.
+
+
+10. Security Considerations
+
+ Server implementers may wish to consider whether clients are able to
+ consume excessive server resources in requesting virtual list
+ operations. Access control to the feature itself; configuration
+ options limiting the featureÆs use to certain predetermined search
+ base DNs and filters; throttling mechanisms designed to limit the
+ ability for one client to soak up server resources, may be
+ appropriate.
+
+ Consideration should be given as to whether a client will be able to
+ retrieve the complete contents, or a significant subset of the
+ complete contents of the directory using this feature. This may be
+ undesirable in some circumstances and consequently it may be
+ necessary to enforce some access control.
+
+
+
+
+ Boreham et al Internet-Draft 9
+
+ LDAP Extensions for Scrolling View May 2002
+ Browsing of Search Results
+
+ Clients can, using this control, determine how many entries are
+ contained within a portion of the DIT. This may constitute a security
+ hazard. Again, access controls may be appropriate.
+
+ Server implementers SHOULD exercise caution concerning the content of
+ the contextID. Should the contextID contain internal server state, it
+ may be possible for a malicious client to use that information to
+ gain unauthorized access to information.
+
+
+11. Acknowledgements
+
+ Chris Weider, Anoop Anantha, and Michael Armijo of Microsoft co-
+ authored previous versions of this document.
+
+
+12. References
+
+
+ [LDAPv3] Wahl, M., Kille, S. and T. Howes, "Lightweight Directory
+ Access Protocol (v3)", Internet Standard, RFC 2251,
+ December, 1997.
+
+ [SPaged] Weider, C., Herron, A., Anantha, A. and T. Howes, "LDAP
+ Control Extension for Simple Paged Results Manipulation",
+ RFC2696, September 1999.
+
+ [SSS] Wahl, M., Herron, A. and T. Howes, "LDAP Control
+ Extension for Server Side Sorting of Search Results",
+ RFC 2891, August, 2000.
+
+ [Bradner97] Bradner, S., "Key Words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Boreham et al Internet-Draft 10
+
+ LDAP Extensions for Scrolling View May 2002
+ Browsing of Search Results
+
+13. Authors' Addresses
+
+ David Boreham
+ Bozeman Pass, Inc
+ +1 406 222 7093
+ david at bozemanpass.com
+
+ Jim Sermersheim
+ Novell, Inc
+ 1800 South Novell Place
+ Provo, Utah 84606, USA
+ jimse at novell.com
+
+ Asaf Kashi
+ Microsoft Corporation
+ 1 Microsoft Way
+ Redmond, WA 98052, USA
+ +1 425 882-8080
+ asafk at microsoft.com
+
+
+14. Full Copyright Statement
+
+ Copyright (C) The Internet Society (2002). All Rights Reserved.
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English. The limited permissions granted above are perpetual and will
+ not be revoked by the Internet Society or its successors or assigns.
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE
+ INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
+ IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
+ THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
+
+
+
+
+
+
+
+
+ Boreham et al Internet-Draft 11
\ No newline at end of file
Added: openldap/vendor/openldap-release/doc/drafts/draft-ietf-ldapext-locate-xx.txt
===================================================================
--- openldap/vendor/openldap-release/doc/drafts/draft-ietf-ldapext-locate-xx.txt (rev 0)
+++ openldap/vendor/openldap-release/doc/drafts/draft-ietf-ldapext-locate-xx.txt 2007-09-15 10:38:52 UTC (rev 844)
@@ -0,0 +1,362 @@
+
+
+INTERNET-DRAFT Michael P. Armijo
+<draft-ietf-ldapext-locate-08.txt> Levon Esibov
+June 5, 2002 Paul Leach
+Expires: December 5, 2002 Microsoft Corporation
+ R.L. Morgan
+ University of Washington
+
+ Discovering LDAP Services with DNS
+
+Status of this Memo
+
+ This document is an Internet-Draft and is in full conformance with
+ all provisions of Section 10 of RFC2026.
+
+ Internet-Drafts are working documents of the Internet Engineering
+ Task Force (IETF), its areas, and its working groups. Note that
+ other groups may also distribute working documents as Internet-
+ Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet- Drafts as reference
+ material or to cite them other than as "work in progress."
+
+ The list of current Internet-Drafts can be accessed at
+ http://www.ietf.org/ietf/1id-abstracts.txt
+
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html.
+
+ Distribution of this memo is unlimited. It is filed as <draft-
+ ietf-ldapext-locate-08.txt>, and expires on December 5, 2002.
+ Please send comments to the authors.
+
+ Copyright Notice
+
+ Copyright (C) The Internet Society (2001). All Rights Reserved.
+
+
+Abstract
+
+ A Lightweight Directory Access Protocol (LDAP) request must be
+ directed to an appropriate server for processing. This document
+ specifies a method for discovering such servers using information in
+ the Domain Name System.
+
+
+
+
+
+
+
+
+
+Armijo, Esibov, Leach and Morgan [Page 1]
+
+INTERNET-DRAFT Discovering LDAP Services with DNS June 5, 2002
+
+
+
+1. Introduction
+
+ The LDAPv3 protocol [1] is designed to be a lightweight access
+ protocol for directory services supporting X.500 models. As a
+ distributed directory service, the complete set of directory
+ information (known as the Directory Information Base) is spread
+ across many different servers. Hence there is the need to
+ determine, when initiating or processing a request, which servers
+ hold the relevant information. In LDAP, the Search, Modify, Add,
+ Delete, ModifyDN, and Compare operations all specify a Distinguished
+ Name (DN) [2] on which the operation is performed. A client, or a
+ server acting on behalf of a client, must be able to determine the
+ server(s) that hold the naming context containing that DN, since
+ that server (or one of that set of servers) must receive and process
+ the request. This determination process is called "server
+ location". To support dynamic distributed operation, the
+ information needed to support server location must be available via
+ lookups done at request processing time, rather than, for example,
+ as static data configured into each client or server.
+
+ It is possible to maintain the information needed to support server
+ location in the directory itself, and X.500 directory deployments
+ typically do so. In practice, however, this only permits location
+ of servers within a limited X.500-connected set. LDAP-specific
+ methods of maintaining server location information in the directory
+ have not yet been standardized. This document defines an
+ alternative method of managing server location information using the
+ Domain Name System. This method takes advantage of the global
+ deployment of the DNS, by allowing LDAP server location information
+ for any existing DNS domain to be published by creating the records
+ described below. A full discussion of the benefits and drawbacks of
+ the various directory location and naming methods is beyond the
+ scope of this document.
+
+ RFC 2247[3] defines an algorithm for mapping DNS domain names into
+ DNs. This document defines the inverse mapping, from DNs to DNS
+ domain names, based on the conventions in [3], for use in this
+ server location method. The server location method described in
+ this document is only defined for DNs that can be so mapped, i.e.,
+ those DNs that are based on domain names. In practice this is
+ reasonable because many objects of interest are named with domain
+ names, and use of domain-name-based DNs is becoming common.
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in RFC 2119 [9].
+
+
+
+
+
+
+Armijo, Esibov, Leach and Morgan [Page 2]
+
+INTERNET-DRAFT Discovering LDAP Services with DNS June 5, 2002
+
+
+2. Mapping Distinguished Names into Domain Names
+
+ This section defines a method of converting a DN into a DNS domain
+ name for use in the server location method described below. Some
+ DNs cannot be converted into a domain name. Converted DNs result
+ in a fully qualified domain name.
+
+
+ The output domain name is initially empty. The DN is processed in
+ right-to-left order (i.e., beginning with the first RDN in the
+ sequence of RDNs). An RDN is able to be converted if it (1)
+ consists of a single AttributeTypeAndValue; (2) the attribute type
+ is "DC"; and (3) the attribute value is non-null. If it can be
+ converted, the attribute value is used as a domain name component
+ (label). The first such value becomes the rightmost (i.e., most
+ significant) domain name component, and successive converted RDN
+ values extend to the left. If an RDN cannot be converted,
+ processing stops. If the output domain name is empty when
+ processing stops, the DN cannot be converted into a domain name.
+
+ For DN:
+
+ cn=John Doe,ou=accounting,dc=example,dc=net
+
+ The client would convert the DC components as defined above into
+ DNS name:
+
+ example.net
+
+ The determined DNS name will be submitted as a DNS query using the
+ algorithm defined in section 3.
+
+
+
+3. Locating LDAPv3 servers through DNS
+
+ LDAPv3 server location information is to be stored using DNS Service
+ Location Record (SRV)[5]. The data in a SRV record contains the DNS
+ name of the server that provides the LDAP service, corresponding
+ Port number, and parameters that enable the client to choose an
+ appropriate server from multiple servers according to the algorithm
+ described in [5]. The name of this record has the following format:
+
+ _<Service>._<Proto>.<Domain>.
+
+ where <Service> is "ldap", and <Proto> is "tcp". <Domain> is the
+ domain name formed by converting the DN of a naming context mastered
+ by the LDAP Server into a domain name using the algorithm in
+ Section 2. Note that "ldap" is the symbolic name for the LDAP
+ service in Assigned Numbers[6], as required by [5].
+
+
+
+Armijo, Esibov, Leach and Morgan [Page 3]
+
+INTERNET-DRAFT Discovering LDAP Services with DNS June 5, 2002
+
+
+ Presence of such records enables clients to find the LDAP servers
+ using standard DNS query [4]. A client (or server) seeking an LDAP
+ server for a particular DN converts that DN to a domain name using
+ the algorithm of Section 2, does a SRV record query using the DNS
+ name formed as described in the preceding paragraph, and interprets
+ the response as described in [5] to determine a host (or hosts) to
+ contact. As an example, a client that searches for an LDAP server
+ for the DN "ou=foo,dc=example,dc=net" that supports the TCP protocol
+ will submit a DNS query for a set of SRV records with owner name:
+
+ _ldap._tcp.example.net.
+
+ The client will receive the list of SRV records published in DNS
+ that satisfy the requested criteria. The following is an example of
+ such a record:
+
+ _ldap._tcp.example.net. IN SRV 0 0 389 phoenix.example.net.
+
+ The set of returned records may contain multiple records in the case
+ where multiple LDAP servers serve the same domain. If there are no
+ matching SRV records available for the converted DN the client SHOULD
+ NOT attempt to 'walk the tree' by removing the least significant
+ portion of the constructed fully qualified domain name.
+
+
+4. IANA Considerations
+
+ This document does not require any IANA actions.
+
+
+5. Security Considerations
+
+ DNS responses can typically be easily spoofed. Clients using this
+ location method SHOULD ensure, via use of strong security
+ mechanisms, that the LDAP server they contact is the one they
+ intended to contact. See [7] for more information on security
+ threats and security mechanisms.
+
+ When using LDAP with TLS the client MUST check the server's name,
+ as described in section 3.6 of [RFC 2830]. As specified there, the
+ name the client checks for is the server's name before any
+ potentially insecure transformations, including the SRV record
+ lookup specified in this memo. Thus the name the client MUST check
+ for is the name obtained by doing the mapping step defined in
+ section 2 above. For example, if the DN "cn=John
+ Doe,ou=accounting,dc=example,dc=net" is converted to the DNS name
+ "example.net", the server's name MUST match "example.net".
+
+ This document describes a method that uses DNS SRV records to
+ discover LDAP servers. All security considerations related to DNS
+ SRV records are inherited by this document. See the security
+ considerations section in [5] for more details.
+
+Armijo, Esibov, Leach and Morgan [Page 4]
+
+INTERNET-DRAFT Discovering LDAP Services with DNS June 5, 2002
+
+
+6. References
+
+ [1] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access
+ Protocol(v3)", RFC 2251, December 1997.
+
+ [2] Wahl, M., Kille, S. and T. Howes, "Lightweight Directory Access
+ Protocol (v3): UTF-8 String Representation of Distinguished
+ Names", RFC 2253, December 1997.
+
+ [3] Kille, S. and M. Wahl, "Using Domains in LDAP/X.500
+ Distinguished Names", RFC 2247, January 1998.
+
+ [4] Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES", RFC
+ 1034, STD 13, November 1987.
+
+ [5] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for
+ specifying the location of services (DNS SRV)", RFC 2782,
+ February 2000.
+
+ [6] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC
+ 1700, October 1994.
+
+ [7] Wahl, M., Alvestrand, H., Hodges, J. and Morgan, R.,
+ "Authentication Methods for LDAP", RFC 2829, May 2000.
+
+ [8] Hodges, J., Morgan, R., Wahl, M., "Lightweight Directory Access
+ Protocol (v3): Extension for Transport Layer Security",
+ RFC 2830, May 2000.
+
+ [9] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+ Levels", BCP 14, RFC 2119, March 1997.
+
+
+
+
+7. Authors' Addresses
+
+ Michael P. Armijo
+ One Microsoft Way
+ Redmond, WA 98052
+ micharm at microsoft.com
+
+ Paul Leach
+ One Microsoft Way
+ Redmond, WA 98052
+ paulle at microsoft.com
+
+ Levon Esibov
+ One Microsoft Way
+ Redmond, WA 98052
+ levone at microsoft.com
+
+
+Armijo, Esibov, Leach and Morgan [Page 5]
+
+INTERNET-DRAFT Discovering LDAP Services with DNS June 5, 2002
+
+ RL "Bob" Morgan
+ University of Washington
+ 4545 15th Ave NE
+ Seattle, WA 98105
+ US
+
+ Phone: +1 206 221 3307
+ EMail: rlmorgan at washington.edu
+ URI: http://staff.washington.edu/rlmorgan/
+
+
+8. Intellectual Property Statement
+
+The IETF takes no position regarding the validity or scope of any
+intellectual property or other rights that might be claimed to pertain
+to the implementation or use of the technology described in this
+document or the extent to which any license under such rights might or
+might not be available; neither does it represent that it has made any
+effort to identify any such rights. Information on the IETF's
+procedures with respect to rights in standards-track and standards-
+related documentation can be found in BCP-11. Copies of claims of
+rights made available for publication and any assurances of licenses to
+be made available, or the result of an attempt made to obtain a general
+license or permission for the use of such proprietary rights by
+implementors or users of this specification can be obtained from the
+IETF Secretariat.
+
+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.
+
+
+9. Full Copyright Statement
+
+Copyright (C) The Internet Society (2001). All Rights Reserved.
+This document and translations of it may be copied and furnished to
+others, and derivative works that comment on or otherwise explain it or
+assist in its implementation may be prepared, copied, published and
+distributed, in whole or in part, without restriction of any kind,
+provided that the above copyright notice and this paragraph are included
+on all such copies and derivative works. However, this document itself
+may not be modified in any way, such as by removing the copyright notice
+or references to the Internet Society or other Internet organizations,
+except as needed for the purpose of developing Internet standards in
+which case the procedures for copyrights defined in the Internet
+Standards process must be followed, or as required to translate it into
+languages other than English. The limited permissions granted above are
+perpetual and will not be revoked by the Internet Society or its
+successors or assigns. This document and the information contained
+herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE
+
+
+Armijo, Esibov, Leach and Morgan [Page 6]
+
+INTERNET-DRAFT Discovering LDAP Services with DNS June 5, 2002
+
+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."
+
+
+10. Expiration Date
+
+ This document is filed as <draft-ietf-ldapext-locate-08.txt>, and
+ expires December 5, 2002.
+
+Armijo, Esibov, Leach and Morgan [Page 7]
\ No newline at end of file
Added: openldap/vendor/openldap-release/doc/drafts/draft-joslin-config-schema-xx.txt
===================================================================
--- openldap/vendor/openldap-release/doc/drafts/draft-joslin-config-schema-xx.txt (rev 0)
+++ openldap/vendor/openldap-release/doc/drafts/draft-joslin-config-schema-xx.txt 2007-09-15 10:38:52 UTC (rev 844)
@@ -0,0 +1,1790 @@
+
+INTERNET-DRAFT M. Ansari
+draft-joslin-config-schema-10.txt Infoblox
+Category: Informational L. Howard
+Expires: September 2005 PADL Software Pty. Ltd.
+ B. Neal-Joslin, Editor
+ Hewlett-Packard Company
+ 4 March, 2005
+
+
+ A Configuration Schema for LDAP Based
+ Directory User Agents
+
+
+Status of this Memo
+
+ Copyright (C) The Internet Society (2005). This document is subject
+ to the rights, licenses and restrictions contained in BCP 78, and
+ except as set forth therein, the authors retain all their rights.
+
+ This document and the information contained herein are provided on
+ an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
+ REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
+ THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
+ EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
+ THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
+ ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
+ PARTICULAR PURPOSE.
+
+ Internet-Drafts are working documents of the Internet Engineering
+ Task Force (IETF), its areas, and its working groups. Note that
+ other groups may also distribute working documents as Internet-
+ Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of six
+ months and may be updated, replaced, or obsoleted by other
+ documents at any time. It is inappropriate to use Internet-Drafts
+ as reference material or to cite them other than as "work in
+ progress."
+
+ The list of current Internet-Drafts can be accessed at
+ http://www.ietf.org/1id-abstracts.html
+
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html
+
+IPR Statement
+
+ By submitting this Internet-Draft, I certify that any applicable
+
+
+
+Neal-Joslin [Page 1]
+
+Internet-Draft DUA Configuration Schema March 2005
+
+
+ patent or other IPR claims of which I am aware have been disclosed,
+ or will be disclosed, and any of which I become aware will be
+ disclosed, in accordance with RFC 3668.
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed
+ to pertain to the implementation or use of the technology described
+ in this document or the extent to which any license under such
+ rights might or might not be available; nor does it represent that
+ it has made any independent effort to identify any such rights.
+ Information on the procedures with respect to rights in RFC
+ documents can be found in BCP 78 and BCP 79.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr at ietf.org.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use
+ of such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository
+ at http://www.ietf.org/ipr.
+
+
+
+
+
+Abstract
+
+ This document describes a mechanism for distributed configuration
+ of similar directory user agents. This document defines a schema
+ for configuration of these DUAs that may be discovered using the
+ Lightweight Directory Access Protocol in RFC 2251[1]. A set of
+ attribute types and an objectclass are proposed, along with
+ specific guidelines for interpreting them. A proposal of using
+ attribute and objectclass mapping allows DUAs to re-configure their
+ schema to that of the end user's environment. This document is
+ intended to be a skeleton for future documents that describe
+ configuration of specific DUA services.
+
+
+
+
+
+
+
+
+
+Neal-Joslin [Page 2]
+
+Internet-Draft DUA Configuration Schema March 2005
+
+
+ Table of Contents
+
+ 1. Background & Motivation ...................................... 4
+ 2. General Issues ............................................... 5
+ 2.1 Terminology .................................................. 5
+ 2.2 Attributes ................................................... 5
+ 2.3 Object Classes ............................................... 6
+ 2.4 Syntax Definitions ........................................... 6
+ 3. Attribute Definitions ........................................ 6
+ 4. Class Definition ............................................. 8
+ 5. Implementation Details ....................................... 9
+ 5.1.1 Interpreting the preferredServerList attribute ............. 9
+ 5.1.2 Interpreting the defaultServerList attribute ............... 10
+ 5.1.3 Interpreting the defaultSearchBase attribute ............... 11
+ 5.1.4 Interpreting the authenticationMethod attribute ............ 12
+ 5.1.5 Interpreting the credentialLevel attribute ................. 13
+ 5.1.6 Interpreting the serviceSearchDescriptor attribute ......... 14
+ 5.1.7 Interpreting the attributeMap attribute .................... 17
+ 5.1.8 Interpreting the searchTimeLimit attribute ................. 20
+ 5.1.9 Interpreting the bindTimeLimit attribute ................... 20
+ 5.1.10 Interpreting the followReferrals attribute ................ 21
+ 5.1.11 Interpreting the dereferenceAliases attribute ............. 21
+ 5.1.12 Interpreting the profileTTL attribute ..................... 21
+ 5.1.13 Interpreting the objectclassMap attribute ................. 22
+ 5.1.14 Interpreting the defaultSearchScope attribute ............. 24
+ 5.1.15 Interpreting the serviceAuthenticationMethod attribute .... 24
+ 5.1.16 Interpreting the serviceCredentialLevel attribute ......... 25
+ 5.2 Binding to the Directory Server .............................. 26
+ 6. Security Considerations ...................................... 26
+ 7. Acknowledgments .............................................. 27
+ 8. References ................................................... 27
+ 8.1 Normative References ......................................... 27
+ 8.2 Informative References ....................................... 28
+ 9. Examples ..................................................... 29
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Neal-Joslin [Page 3]
+
+Internet-Draft DUA Configuration Schema March 2005
+
+
+1. Background & Motivation
+
+ The LDAP protocol has brought about a new and nearly ubiquitous
+ acceptance of the directory server. Many new client applications
+ (DUAs) are being created that use LDAP directories for many
+ different services. And although the LDAP protocol has eased the
+ development of these applications, some challenges still exist for
+ both developers and directory administrators.
+
+ The authors of this document are implementers of DUAs described by
+ RFC 2307 [2]. In developing these agents, we felt there are
+ several issues that still need to be addressed to ease the
+ deployment and configuration of a large network of these DUAs.
+
+ One of these challenges stems from the lack of a utopian schema. A
+ utopian schema would be one that every application developer could
+ agree upon and that would support every application. Unfortunately
+ today, many DUAs define their own schema (like RFC 2307 vs.
+ Microsoft's Services for Unix [3]) containing similar attributes,
+ but with different attribute names. This can lead to data
+ redundancy within directory entries and give directory
+ administrators unwanted challenges, updating schemas and
+ synchronizing data.
+
+ So, one goal of this document is to eliminate data redundancy by
+ having DUAs configure themselves to the schema of the deployed
+ directory, instead of forcing its own schema on the directory.
+
+ Another goal of this document is to provide the DUA with enough
+ configuration information so that it can discover how to retrieve
+ its data in the directory, such as what locations to search in the
+ directory tree.
+
+ Finally, this document intends to describe a configuration method
+ for DUAs that can be shared among many DUAs, on various platforms,
+ providing as such, a configuration profile, the purpose is to
+ centralize and simplify management of DUAs.
+
+ This document is intended to provide the skeleton framework for
+ future drafts, which will describe the individual implementation
+ details for the particular services provided by that DUA. The
+ authors of this document plan to develop such a document for the
+ Network Information Service DUA, described by RFC 2307 or its
+ successor.
+
+ We expect that as DUAs take advantage of this configuration scheme,
+ each DUA will require additional configuration parameters, not
+ specified by this document. Thus, we would expect that new
+
+
+
+Neal-Joslin [Page 4]
+
+Internet-Draft DUA Configuration Schema March 2005
+
+
+ auxiliary object classes, containing new configuration attributes
+ will be created, and then joined with the structural class defined
+ by this document to create a configuration profile for a particular
+ DUA service. And that by joining various auxiliary objectclasses
+ for different DUA services, that configuration of various DUA
+ services can be controlled by a single configuration profile entry.
+
+
+2. General Issues
+
+ The schema defined by this document is defined under the "DUA
+ Configuration Schema." This schema is derived from the OID: iso
+ (1) org (3) dod (6) internet (1) private (4) enterprises (1)
+ Hewlett-Packard Company (11) directory (1) LDAP-UX Integration
+ Project (3) DUA Configuration Schema (1). This OID is represented
+ in this document by the keystring "DUAConfSchemaOID"
+ (1.3.6.1.4.1.11.1.3.1).
+
+2.1 Terminology
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
+ this document are to be interpreted as described in BCP 14 (RFC
+ 2119) [4].
+
+2.2 Attributes
+
+ The attributes and classes defined in this document are summarized
+ below.
+
+ The following attributes are defined in this document:
+
+ preferredServerList
+ defaultServerList
+ defaultSearchBase
+ defaultSearchScope
+ authenticationMethod
+ credentialLevel
+ serviceSearchDescriptor
+ serviceCredentialLevel
+ serviceAuthenticationMethod
+ attributeMap
+ objectclassMap
+ searchTimeLimit
+ bindTimeLimit
+ followReferrals
+ dereferenceAliases
+ profileTTL
+
+
+
+Neal-Joslin [Page 5]
+
+Internet-Draft DUA Configuration Schema March 2005
+
+
+2.3 Object Classes
+
+ The following object class is defined in this document:
+
+ DUAConfigProfile
+
+2.4 Syntax Definitions
+
+ The following syntax definitions are used throughout this document.
+ This document does not define new syntaxes that must be supported
+ by the directory server. The string encoding used by the
+ attributes defined in this document can be found section 5.
+
+ keystring as defined by RFC 2252 [5]
+ descr as defined by RFC 2252 section 4.1
+ a as defined by RFC 2252 section 4.1
+ d as defined by RFC 2252 section 4.1
+ space as defined by RFC 2252 section 4.1
+ whsp as defined by RFC 2252 section 4.1
+ base as defined by RFC 2253 [6]
+ DistinguishedName as defined by RFC 2253 section 2
+ RelativeDistinguishedName as defined by RFC 2253 section 2
+ scope as defined by RFC 2255 [7]
+ host as defined by RFC 3986
+ section 3.2.2 [8]
+ hostport host [":" port ]
+ port as defined by RFC 3986
+ section 3.2.3 [8]
+ serviceID = keystring
+
+
+3. Attribute Definitions
+
+ This section contains attribute definitions to be used by DUAs when
+ discovering their configuration.
+
+ ( DUAConfSchemaOID.1.0 NAME 'defaultServerList'
+ DESC 'Default LDAP server host addresses used by a DUA'
+ EQUALITY caseIgnoreMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ SINGLE-VALUE )
+
+ ( DUAConfSchemaOID.1.1 NAME 'defaultSearchBase'
+ DESC 'Default LDAP base DN used by a DUA'
+ EQUALITY distinguishedNameMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
+ SINGLE-VALUE )
+
+
+
+
+Neal-Joslin [Page 6]
+
+Internet-Draft DUA Configuration Schema March 2005
+
+
+ ( DUAConfSchemaOID.1.2 NAME 'preferredServerList'
+ DESC 'Preferred LDAP server host addresses to be used by a
+ DUA'
+ EQUALITY caseIgnoreMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ SINGLE-VALUE )
+
+ ( DUAConfSchemaOID.1.3 NAME 'searchTimeLimit'
+ DESC 'Maximum time in seconds a DUA should allow for a
+ search to complete'
+ EQUALITY integerMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
+ SINGLE-VALUE )
+
+ ( DUAConfSchemaOID.1.4 NAME 'bindTimeLimit'
+ DESC 'Maximum time in seconds a DUA should allow for the
+ bind operation to complete'
+ EQUALITY integerMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
+ SINGLE-VALUE )
+
+ ( DUAConfSchemaOID.1.5 NAME 'followReferrals'
+ DESC 'Tells DUA if it should follow referrals
+ returned by a DSA result'
+ EQUALITY booleanMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
+ SINGLE-VALUE )
+
+ ( DUAConfSchemaOID.1.6 NAME 'authenticationMethod'
+ DESC 'A keystring which identifies the type of
+ authentication methods used to contact the DSA'
+ EQUALITY caseIgnoreMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ SINGLE-VALUE )
+
+ ( DUAConfSchemaOID.1.7 NAME 'profileTTL'
+ DESC 'Time to live, in seconds, before a client DUA
+ should re-read this configuration profile'
+ EQUALITY integerMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
+ SINGLE-VALUE )
+
+ ( DUAConfSchemaOID.1.9 NAME 'attributeMap'
+ DESC 'Attribute mappings used by a DUA'
+ EQUALITY caseIgnoreIA5Match
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
+
+ ( DUAConfSchemaOID.1.10 NAME 'credentialLevel'
+
+
+
+Neal-Joslin [Page 7]
+
+Internet-Draft DUA Configuration Schema March 2005
+
+
+ DESC 'Identifies type of credentials a DUA should
+ use when binding to the LDAP server'
+ EQUALITY caseIgnoreIA5Match
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
+ SINGLE-VALUE )
+
+ ( DUAConfSchemaOID.1.11 NAME 'objectclassMap'
+ DESC 'Objectclass mappings used by a DUA'
+ EQUALITY caseIgnoreIA5Match
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
+
+ ( DUAConfSchemaOID.1.12 NAME 'defaultSearchScope'
+ DESC 'Default search scope used by a DUA'
+ EQUALITY caseIgnoreIA5Match
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
+ SINGLE-VALUE )
+
+ ( DUAConfSchemaOID.1.13 NAME 'serviceCredentialLevel'
+ DESC 'Identifies type of credentials a DUA
+ should use when binding to the LDAP server for a
+ specific service'
+ EQUALITY caseIgnoreIA5Match
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
+
+ ( DUAConfSchemaOID.1.14 NAME 'serviceSearchDescriptor'
+ DESC 'LDAP search descriptor list used by a DUA'
+ EQUALITY caseExactMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+ ( DUAConfSchemaOID.1.15 NAME 'serviceAuthenticationMethod'
+ DESC 'Identifies type of authentication method a DUA
+ should use when binding to the LDAP server for a
+ specific service'
+ EQUALITY caseIgnoreMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+ ( DUAConfSchemaOID.1.16 NAME 'dereferenceAliases'
+ DESC 'Tells DUA if it should dereference aliases'
+ EQUALITY booleanMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
+ SINGLE-VALUE )
+
+
+4. Class Definition
+
+ The objectclass below is constructed from the attributes defined in
+ 3, with the exception of the cn attribute, which is defined in RFC
+ 2256 [9]. cn is used to represent the name of the DUA
+
+
+
+Neal-Joslin [Page 8]
+
+Internet-Draft DUA Configuration Schema March 2005
+
+
+ configuration profile.
+
+ ( DUAConfSchemaOID.2.5 NAME 'DUAConfigProfile'
+ SUP top STRUCTURAL
+ DESC 'Abstraction of a base configuration for a DUA'
+ MUST ( cn )
+ MAY ( defaultServerList $ preferredServerList $
+ defaultSearchBase $ defaultSearchScope $
+ searchTimeLimit $ bindTimeLimit $
+ credentialLevel $ authenticationMethod $
+ followReferrals $ dereferenceAliases $
+ serviceSearchDescriptor $ serviceCredentialLevel $
+ serviceAuthenticationMethod $ objectclassMap $
+ attributeMap $ profileTTL ) )
+
+
+5. Implementation Details
+
+5.1.1 Interpreting the preferredServerList attribute
+
+ Interpretation:
+
+ As described by the syntax, the preferredServerList parameter
+ is a white-space separated list of server addresses and
+ associated port numbers. When the DUA needs to contact a DSA,
+ the DUA MUST first attempt to contact one of the servers
+ listed in the preferredServerList attribute. The DUA MUST
+ contact the DSA specified by the first server address in the
+ list. If that DSA is unavailable, the remaining DSAs MUST be
+ queried in the order provided (left to right) until a
+ connection is established with a DSA. Once a connection with
+ a DSA is established, the DUA SHOULD NOT attempt to establish
+ a connection with the remaining DSAs. The purpose of
+ enumerating multiple DSAs is not for supplemental data, but
+ for high availability of replicated data. This is also the
+ main reason why an LDAP URL[10] syntax was not selected for
+ this document.
+
+ If the DUA is unable to contact any of the DSAs specified by
+ the preferredServerList, the defaultServerList attribute MUST
+ be examined, as described in 5.1.2. The servers identified by
+ the preferredServerList MUST be contacted before attempting to
+ contact any of the servers specified by the defaultServerList.
+
+ Syntax:
+
+ serverList = hostport *(space [hostport])
+
+
+
+
+Neal-Joslin [Page 9]
+
+Internet-Draft DUA Configuration Schema March 2005
+
+
+ Default Value:
+
+ The preferredServerList attribute does not have a default
+ value. Instead a DUA MUST examine the defaultServerList
+ attribute.
+
+ Other attribute notes:
+
+ This attribute is used in conjunction with the
+ defaultServerList attribute. Please see section 5.1.2 for
+ additional implementation notes. Determining how the DUA
+ should query the DSAs also depends on the additional
+ configuration attributes, credentialLevel,
+ serviceCredentialLevel, bindTimeLimit,
+ serviceAuthenticationMethod and authenticationMethod. Please
+ review section 5.2 for details on how a DUA should properly
+ bind to a DSA.
+
+ Example:
+
+ preferredServerList: 192.168.169.170 ldap1.mycorp.com
+ ldap2:1389 [1080::8:800:200C:417A]:389
+
+5.1.2 Interpreting the defaultServerList attribute
+
+ Interpretation:
+
+ The defaultServerList attribute MUST only be examined if the
+ preferredServerList attribute is not provided, or the DUA is
+ unable to establish a connection with one of the DSAs
+ specified by the preferredServerList.
+
+ If more than one address is provided, the DUA may choose to
+ either accept the order provided, or choose to create its own
+ order, based on what the DUA determines is the "best" order of
+ servers to query. For example, the DUA may choose to examine
+ the server list and choose to query the DSAs in order based on
+ the "closest" server or the server with the least amount of
+ "load." Interpretation of the "best" server order is entirely
+ up to the DUA, and not part of this document.
+
+ Once the order of server addresses is determined, the DUA
+ contacts the DSA specified by the first server address in the
+ list. If that DSA is unavailable, the remaining DSAs SHOULD
+ be queried until an available DSA is found or no more DSAs are
+ available. If a server address or port is invalid, the DUA
+ SHOULD proceed to the next server address as described just
+ above.
+
+
+
+Neal-Joslin [Page 10]
+
+Internet-Draft DUA Configuration Schema March 2005
+
+
+ Syntax:
+
+ serverList = hostport *(space [hostport])
+
+ Default Value:
+
+ If a defaultServerList attribute is not provided, the DUA MAY
+ attempt to contact the same DSA that provided the
+ configuration profile entry itself. The default DSA is
+ contacted only if the preferredServerList attribute is also
+ not provided.
+
+ Other attribute notes:
+
+ This attribute is used in conjunction with the
+ preferredServerList attribute. Please see section 5.1.1 for
+ additional implementation notes. Determining how the DUA
+ should query the DSAs also depends on the additional
+ configuration attributes, credentialLevel,
+ serviceCredentialLevel, bindTimeLimit,
+ serviceAuthenticationMethod and authenticationMethod. Please
+ review section 5.2 for details on how a DUA should properly
+ contact a DSA.
+
+ Example:
+
+ defaultServerList: 192.168.169.170 ldap1.mycorp.com
+ ldap2:1389 [1080::8:800:200C:417A]:5912
+
+5.1.3 Interpreting the defaultSearchBase attribute
+
+ Interpretation:
+
+ When a DUA needs to search the DSA for information, this
+ attribute provides the base for the search. This parameter
+ can be overridden or appended by the serviceSearchDescriptor
+ attribute. See section 5.1.6.
+
+ Syntax:
+
+ Defined by OID 1.3.6.1.4.1.1466.115.121.1.12 [5]
+
+ Default Value:
+
+ There is no default value for the defaultSearchBase. A DUA
+ MAY define its own method for determining the search base, if
+ the defaultSearchBase is not provided.
+
+
+
+
+Neal-Joslin [Page 11]
+
+Internet-Draft DUA Configuration Schema March 2005
+
+
+ Other attribute notes:
+
+ This attribute is used in conjunction with the
+ serviceSearchDescriptor attribute. See section 5.1.6.
+
+ Example:
+
+ defaultSearchBase: dc=mycompany,dc=com
+
+5.1.4 Interpreting the authenticationMethod attribute
+
+ Interpretation:
+
+ The authenticationMethod attribute defines an ordered list of
+ LDAP bind methods to be used when attempting to contact a
+ DSA[11]. The serviceAuthenticationMethod overrides this
+ value for a particular service (see 5.1.15.) Each method MUST
+ be attempted in the order provided by the attribute, until a
+ successful LDAP bind is performed ("none" is assumed to always
+ be successful.) However the DUA MAY skip over one or more
+ methods. See section 5.2 for more information.
+
+ none - The DUA does not perform an LDAP bind.
+ simple - The DUA performs an LDAP simple bind.
+ sasl - The DUA performs an LDAP SASL[12] bind using the
+ specified SASL mechanism and options.
+ tls - The DUA performs an LDAP StartTLS operation
+ followed by the specified bind method (for more
+ information refer to section 5.1 of RFC 2830 [13]).
+
+ Syntax:
+
+ authMethod = method *(";" method)
+ method = none | simple | sasl | tls
+ none = "none"
+ simple = "simple"
+ sasl = "sasl/" saslmech [ ":" sasloption ]
+ sasloption = "auth-conf" | "auth-int"
+ tls = "tls:" (none | simple | sasl)
+ saslmech = SASL mechanism name as defined in [18]
+
+ Note: Although multiple authentication methods may be
+ specified in the syntax, at most one of each type is allowed.
+ I.E. "simple;simple" is invalid.
+
+ Default Value:
+
+ If the authenticationMethod or serviceAuthenticationMethod
+
+
+
+Neal-Joslin [Page 12]
+
+Internet-Draft DUA Configuration Schema March 2005
+
+
+ (for that particular service) attributes are not provided, the
+ DUA MAY choose to bind to the DSA using any method defined by
+ the DUA. However, if either authenticationMethod or
+ serviceAuthenticationMethod are provided, the DUA MUST only
+ use the methods specified.
+
+ Other attribute notes:
+
+ When using TLS, the string "tls:sasl/EXTERNAL" implies that
+ two way (DSA and DUA) authentication is to be performed. Any
+ other TLS authentication method implies one way (DSA side
+ credential) authentication.
+
+ Determining how the DUA should bind to the DSAs also depends
+ on the additional configuration attributes, credentialLevel,
+ serviceCredentialLevel, serviceAuthenticationMethod and
+ bindTimeLimit. Please review section 5.2 for details on how
+ to properly bind to a DSA.
+
+ Example:
+
+ authenticationMethod: tls:simple;sasl/DIGEST-MD5
+ (see [14])
+
+5.1.5 Interpreting the credentialLevel attribute
+
+ Interpretation:
+
+ The credentialLevel attribute defines what type(s) of
+ credential(s) the DUA MUST use when contacting the DSA. The
+ serviceCredentialLevel overrides this value for a particular
+ service (5.1.16.) The credentialLevel can contain more than
+ one credential type, separated by white space.
+
+ anonymous - The DUA SHOULD NOT use a credential when binding
+ to the DSA.
+
+ proxy - The DUA SHOULD use a known proxy identity when binding
+ to the DSA. A proxy identity is a specific credential that
+ was created to represent the DUA. This document does not
+ define how the proxy user should be created, or how the DUA
+ should determine what the proxy user's credential is. This
+ functionality is up to each implementation.
+
+ self - When the DUA is acting on behalf of a known identity,
+ the DUA MUST attempt to bind to the DSA as that identity. The
+ DUA should contain methods to determine the identity of the
+ user such that that identity can be authenticated by the
+
+
+
+Neal-Joslin [Page 13]
+
+Internet-Draft DUA Configuration Schema March 2005
+
+
+ directory server using the defined authentication methods.
+
+ If the credentialLevel contains more than one credential type,
+ the DUA MUST use the credential types in the order specified.
+ However, the DUA MAY skip over one or more credential types.
+ As soon as the DUA is able to successfully bind to the DSA,
+ the DUA SHOULD NOT attempt to bind using the remaining
+ credential types.
+
+ Syntax:
+
+ credentialLevel = level *(space level)
+ level = self | proxy | anonymous
+ self = "self"
+ proxy = "proxy"
+ anonymous = "anonymous"
+
+ Note: Although multiple credential levels may be specified in
+ the syntax, at most one of each type is allowed. Refer to
+ implementation notes in section 5.2 for additional syntax
+ requirements for the credentialLevel attribute.
+
+ Default Value:
+
+ If the credentialLevel attribute is not defined, the DUA
+ SHOULD NOT use a credential when binding to the DSA (also
+ known as anonymous.)
+
+ Other attribute notes:
+
+ Determining how the DUA should bind to the DSAs also depends
+ on the additional configuration attributes,
+ authenticationMethod, serviceAuthenticationMethod,
+ serviceCredentialLevel and bindTimeLimit. Please review
+ section 5.2 for details on how to properly bind to a DSA.
+
+ Example:
+
+ credentialLevel: proxy anonymous
+
+5.1.6 Interpreting the serviceSearchDescriptor attribute
+
+ Interpretation:
+
+ The serviceSearchDescriptor attribute defines how and where a
+ DUA SHOULD search for information for a particular service.
+ The serviceSearchDescriptor contains a serviceID, followed by
+ one or more base-scope-filter triples. These base-scope-
+
+
+
+Neal-Joslin [Page 14]
+
+Internet-Draft DUA Configuration Schema March 2005
+
+
+ filter triples are used to define searches only for the
+ specific service. Multiple base-scope-filters allow the DUA
+ to search for data in multiple locations of the DIT. Although
+ this syntax is very similar to the LDAP URL[8], this draft
+ requires the ability to supply multiple hosts as part of the
+ configuration of the DSA. In addition, an ordered list of
+ search descriptors is required, which can not be specified by
+ the LDAP URL.
+
+ In addition to the triples, serviceSearchDescriptor might also
+ contain the DN of an entry that will contain an alternate
+ profile. The DSA SHOULD re-evaluate the alternate profile and
+ perform searches as specified by that profile.
+
+ If the base, as defined in the serviceSearchDescriptor, is
+ followed by the "," (ASCII 0x2C) character, this base is known
+ as a relative base. This relative base may be constructed of
+ one or more RDN components. The DUA MUST define the search
+ base by appending the relative base with the
+ defaultSearchBase.
+
+ Syntax:
+
+ serviceSearchList = serviceID ":" serviceSearchDesc
+ *(";" serviceSearchDesc)
+ serviceSearchDesc = confReferral | searchDescriptor
+ searchDescriptor = [base] ["?" [scope] ["?" [filter]]]
+ confReferral = "ref:" DistinguishedName
+ base = DistinguishedName |
+ RelativeBaseName
+ RelativeBaseName = 1*(RelativeDistinguishedName ",")
+ filter = UTF-8 encoded string
+
+ If the base or filter contains the ";" (ASCII 0x3B) "?" (ASCII
+ 0x3F) """ (ASCII 0x22) or "\" (ASCII 0x5C) characters, those
+ characters MUST be escaped (preceded with the "\" character.)
+ Alternately the DN may be surrounded by quotes (ASCII 0x22.)
+ Refer to RFC 2253, section 4. If the base or filter are
+ surrounded by quotes, only the """ character needs to be
+ escaped. Any character that is preceded by the "\" character,
+ which does not need to be escaped results in both "\"
+ character and the character itself.
+
+ The usage and syntax of the filter string MUST be defined by
+ the DUA service. A suggested syntax would be that as defined
+ by RFC 2254.
+
+ If a DUA is performing a search for a particular service,
+
+
+
+Neal-Joslin [Page 15]
+
+Internet-Draft DUA Configuration Schema March 2005
+
+
+ which has a serviceSearchDescriptor defined, the DUA MUST set
+ the base, scope and filter as defined. Each base-scope-filter
+ triple represents a single LDAP search operation. If multiple
+ base-scope-filter triples are provided in the
+ serviceSearchDescriptor, the DUA SHOULD perform multiple
+ search requests and in that case it MUST be in the order
+ specified by the serviceSearchDescriptor.
+
+ FYI: Service search descriptors do not exactly follow the LDAP
+ URL syntax [7]. The reasoning for this difference is to
+ separate the host name(s) from the filter. This allows the
+ DUA to have a more flexible solution in choosing its DSA.
+
+ Default Values:
+
+ If a serviceSearchDescriptor, or an element their-of, is not
+ defined for a particular service, the DUA SHOULD create the
+ base, scope and filter as follows:
+
+ base - Same as the defaultSearchBase or as
+ defined by the DUA service.
+ scope - Same as the defaultSearchScope or as
+ defined by the DUA service.
+ filter - Use defaults as defined by DUAs service.
+
+ If the defaultSearchBase or defaultSearchScope are not
+ defined, then the DUA service may use its own default.
+
+
+ Other attribute notes:
+
+ If a serviceSearchDescriptor exists for a given service, the
+ service MUST use at least one base-scope-filter triple in
+ performing searches. It SHOULD perform multiple searches per
+ service if multiple base-scope-filter triples are defined for
+ that service.
+
+ The details of how the "filter" is interpreted by each DUA's
+ service is defined by that service. This means the filter is
+ NOT REQUIRED to be a legal LDAP filter [15]. Furthermore,
+ determining how attribute and objectclass mapping affects that
+ search filter MUST be defined by the service. I.E. The DUA
+ SHOULD specify if the attributes in the filter have assumed to
+ already have been mapped, or if it is expected that attribute
+ mapping (see 5.1.7) would be applied to the filter. In
+ general practice, implementation and usability suggests that
+ attribute and objectclass mapping (sections 5.1.7 and 5.1.13)
+ SHOULD NOT be applied to the filter defined in the
+
+
+
+Neal-Joslin [Page 16]
+
+Internet-Draft DUA Configuration Schema March 2005
+
+
+ serviceSearchDescriptor.
+
+ It is assumed the serviceID is unique to a given service
+ within the scope of any DUA that might use the given profile.
+
+ Example:
+
+ defaultSearchBase: dc=mycompany,dc=com
+
+ serviceSearchDescriptor: email:ou=people,ou=org1,?
+ one;ou=contractor,?one;
+ ref:cn=profile,dc=mycompany,dc=com
+
+ In this example, the DUA MUST search in
+ "ou=people,ou=org1,dc=mycompany,dc=com" first. The DUA then
+ SHOULD search in "ou=contractor,dc=mycompany,dc=com", and
+ finally it SHOULD search other locations as specified in the
+ profile described at "cn=profile,dc=mycompany,dc=com". For
+ more examples, see section 9.
+
+
+5.1.7 Interpreting the attributeMap attribute
+
+ Interpretation:
+
+ A DUA SHOULD perform attribute mapping for all LDAP operations
+ performed for a service that has an attributeMap entry.
+ Because attribute mapping is specific to each service within
+ the DUA, a "serviceID" is required as part of the attributeMap
+ syntax. I.E. not all DUA services should necessarily perform
+ the same attribute mapping.
+
+ Attribute mapping in general is expected be used to map
+ attributes of similar syntaxes as specified by the service
+ supported by the DUA. However, a DUA is NOT REQUIRED to
+ verify syntaxes of mapped attributes. If the DUA does
+ discover that the syntax of the mapped attribute does not
+ match that of the original attribute, the DUA MAY perform
+ translation between the original syntax and the new syntax.
+ When DUAs do support attribute value translation, the list of
+ capable translations SHOULD be documented in a description of
+ the DUA service.
+
+ Syntax:
+
+ attributeMap = serviceID ":" origAttribute "="
+ attributes
+ origAttribute = attribute
+
+
+
+Neal-Joslin [Page 17]
+
+Internet-Draft DUA Configuration Schema March 2005
+
+
+ attributes = wattribute *( space wattribute )
+ wattribute = whsp newAttribute whsp
+ newAttribute = descr | "*NULL*"
+ attribute = descr
+
+ Values of the origAttribute are defined by and SHOULD be
+ documented for the DUA service, as a list of known supported
+ attributes.
+
+ Default Value:
+
+ By default, attributes that are used by a DUA service are not
+ mapped unless mapped by the attributeMap attributes. The DUA
+ MUST NOT map an attribute unless it is explicitly defined by
+ an attributeMap attribute.
+
+ Other attribute notes:
+
+ When an attribute is mapped to the special keystring "*NULL*",
+ the DUA SHOULD NOT request that attribute from the DSA, when
+ performing a search or compare request. If the DUA is also
+ capable of performing modification on the DSA, the DUA SHOULD
+ NOT attempt to modify any attribute which has been mapped to
+ "*NULL*".
+
+ It is assumed the serviceID is unique to a given service
+ within the scope of the DSA.
+
+ A DUA SHOULD support attribute mapping. If it does, the
+ following additional rules apply:
+
+ 1) The list of attributes that are allowed to be mapped SHOULD
+ defined by and documented for the service.
+
+ 2) Any supported translation of mapping from attributes of
+ dissimilar syntax SHOULD also be defined and documented.
+
+ 3) If an attribute may be mapped to multiple attributes the
+ DSA SHOULD define a syntax or usage statement for how the new
+ attribute value will be constructed. Furthermore, the
+ resulting translated syntax of the combined attributes MUST be
+ the same as the attribute being mapped.
+
+ 4) A DUA MUST support mapping of attributes using the
+ attribute OID. It SHOULD support attribute mapping based on
+ the attribute name.
+
+ 5) It is recommended that attribute mapping not be applied to
+
+
+
+Neal-Joslin [Page 18]
+
+Internet-Draft DUA Configuration Schema March 2005
+
+
+ parents of the target entries.
+
+ 6) Attribute mapping is not recursive. In other words, if an
+ attribute has been mapped to a target attribute, that new
+ target attribute MUST NOT be mapped to a third attribute.
+
+ 7) A given attribute MUST only be mapped once for a given
+ service.
+
+
+ Example:
+
+ Suppose a DUA is acting on behalf of an email service. By
+ default the "email" service uses the "mail", "cn" and "sn"
+ attributes to discover mail addresses. However, the email
+ service has been deployed in an environment that uses
+ "employeeName" instead of "cn." And also instead of using the
+ "mail" attribute for email addresses, the "email" attribute is
+ used for that purpose. In this case, the attribute "cn" can
+ be mapped to "employeeName," allowing the DUA to perform
+ searches using the "employeeName" attribute as part of the
+ search filter, instead of "cn". And "mail" can be mapped to
+ "email" when attempting to retrieve the email address. This
+ mapping is performed by adding the attributeMap attributes to
+ the configuration profile entry as follows (represented in
+ LDIF[16]):
+
+ attributeMap: email:cn=employeeName
+ attributeMap: email:mail=email
+
+ As described above, the DUA MAY also map a single attribute to
+ multiple attributes. When mapping a single attribute to more
+ than one attribute, the new syntax or usage of the mapped
+ attribute must be intrinsically defined by the DUAs service.
+
+ attributeMap: email:cn=firstName lastName
+
+ In the above example, the DUA creates the new value by
+ generating space separated string using the values of the
+ mapped attributes. In this case, a special mapping must be
+ defined so that a proper search filter can be created. For
+ further information on this example, please refer to section
+ 9.
+
+ Another possibility for multiple attribute mapping might come
+ in when constructing returned attributes. For example,
+ perhaps all email addresses are of a guaranteed syntax of
+ "uid at domain". And in this example, the uid and domain are
+
+
+
+Neal-Joslin [Page 19]
+
+Internet-Draft DUA Configuration Schema March 2005
+
+
+ separate attributes in the directory. The email service may
+ define that if the "mail" attribute is mapped to two different
+ attributes, it will construct the email address as a
+ concatenation of the uid and domain attributes, placing the
+ "@" character between them.
+
+ attributeMap: email:mail=uid domain
+
+
+5.1.8 Interpreting the searchTimeLimit attribute
+
+ Interpretation:
+
+ The searchTimeLimit attribute defines the maximum time, in
+ seconds, that a DUA SHOULD allow to perform a search request.
+
+ Syntax:
+
+ Defined by OID 1.3.6.1.4.1.1466.115.121.1.27. [5]
+
+ Default Value:
+
+ If the searchTimeLimit attribute is not defined or is zero,
+ the search time limit is not enforced by the DUA.
+
+ Other attribute notes:
+
+ This time limit only includes the amount of time required to
+ perform the LDAP search operation. If other operations are
+ required, those operations do not need to be considered part
+ of the search time. See bindTimeLimit for the LDAP bind
+ operation.
+
+5.1.9 Interpreting the bindTimeLimit attribute
+
+ Interpretation:
+
+ The bindTimeLimit attribute defines the maximum time, in
+ seconds, that a DUA SHOULD allow to perform an LDAP bind
+ request against each server on the preferredServerList or
+ defaultServerList.
+
+ Syntax:
+
+ Defined by OID 1.3.6.1.4.1.1466.115.121.1.27.
+
+ Default Value:
+
+
+
+
+Neal-Joslin [Page 20]
+
+Internet-Draft DUA Configuration Schema March 2005
+
+
+ If the bindTimeLimit attribute is not defined or is zero, the
+ bind time limit is not enforced by the DUA.
+
+ Other attribute notes:
+
+ This time limit only includes the amount of time required to
+ perform the LDAP bind operation. If other operations are
+ required, those operations do not need to be considered part
+ of the bind time. See searchTimeLimit for the LDAP search
+ operation.
+
+5.1.10 Interpreting the followReferrals attribute
+
+ Interpretation:
+
+ If set to TRUE, the DUA SHOULD follow any referrals if
+ discovered.
+
+ If set to FALSE, the DUA MUST NOT follow referrals.
+
+ Syntax:
+
+ Defined by OID 1.3.6.1.4.1.1466.115.121.1.7. [5]
+
+ Default Value:
+
+ If the followReferrals attribute is not set or set to an
+ invalid value the default value is TRUE.
+
+5.1.11 Interpreting the dereferenceAliases attribute
+
+ Interpretation:
+
+ If set to TRUE, the DUA SHOULD enable alias dereferencing.
+
+ If set to FALSE, the DUA MUST NOT enable alias dereferencing.
+
+ Syntax:
+
+ Defined by OID 1.3.6.1.4.1.1466.115.121.1.7.
+
+ Default Value:
+
+ If the dereferenceAliases attribute is not set or set to an
+ invalid value the default value is TRUE.
+
+5.1.12 Interpreting the profileTTL attribute
+
+
+
+
+Neal-Joslin [Page 21]
+
+Internet-Draft DUA Configuration Schema March 2005
+
+
+ Interpretation:
+
+ The profileTTL attribute defines how often the DUA SHOULD re-
+ load and reconfigure itself using the corresponding
+ configuration profile entry. The value is represented in
+ seconds. Once a DUA reloads the profile entry, it SHOULD re-
+ configure itself with the new values.
+
+ Syntax:
+
+ Defined by OID 1.3.6.1.4.1.1466.115.121.1.27.
+
+ Default Value:
+
+ If not specified the DUA MAY use its own reconfiguration
+ policy.
+
+ Other attribute notes:
+
+ If the profileTTL value is zero, the DUA SHOULD NOT
+ automatically re-load the configuration profile.
+
+5.1.13 Interpreting the objectclassMap attribute
+
+ Interpretation:
+
+ A DUA MAY perform objectclass mapping for all LDAP operations
+ performed for a service that has an objectclassMap entry.
+ Because objectclass mapping is specific for each service
+ within the DUA, a "serviceID" is required as part of the
+ objectclassMap syntax. I.E. Not all DUA services should
+ necessarily perform the same objectclass mapping.
+
+ Objectclass mapping SHOULD be used in conjunction with
+ attribute mapping to map the required schema by the service to
+ an equivalent schema that is available in the directory.
+
+ Objectclass mapping may or may not be required by a DUA.
+ Often, the objectclass attribute is used in search filters.
+ If a service search descriptor is provided, it is expected
+ that the search filter contains a "correct" search filter
+ (though this is not a requirement,) which does not need to be
+ re-mapped. However, when the service search descriptor is not
+ provided, and the default search filter for that service
+ contains the objectclass attribute, that search filter SHOULD
+ be re-defined by objectclass mapping. If a default search
+ filter is not used, it SHOULD be re-defined through the
+ serviceSearchDescriptor. If a serviceSearchDescriptor is
+
+
+
+Neal-Joslin [Page 22]
+
+Internet-Draft DUA Configuration Schema March 2005
+
+
+ defined for a particular service, it SHOULD NOT be re-mapped
+ by either the objectclassMap or attributeMap values.
+
+ One condition where the objectclassMap SHOULD be used is when
+ the DUA is providing gateway functionality. In this case, the
+ DUA is acting on behalf of another service, which may pass in
+ a search filter itself. In this type of DUA, the DUA may
+ alter the search filter according to the appropriate
+ attributeMap and objectclassMap values. And in this case, it
+ is also assumed that a serviceSearchDescriptor is not defined.
+
+ Syntax:
+
+ objectclassMap = serviceID ":" origObjectclass "="
+ objectclass
+ origObjectclass = objectclass
+ objectclass = keystring
+
+ Values of the origObjectclass depend on the type of DUA
+ Service using the objectclass mapping feature.
+
+ Default Value:
+
+ The DUA MUST NOT remap an objectclass unless it is explicitly
+ defined by an objectclassMap attribute.
+
+ Other attribute notes:
+
+ A DUA SHOULD support objectclass mapping. If it does, the DUA
+ MUST support mapping of objectclasses using the objectclass
+ OID. It SHOULD support objectclass mapping based on the
+ objectclass name.
+
+ It is assumed the serviceID is unique to a given service
+ within the scope of the DSA.
+
+ Example:
+
+ Suppose a DUA is acting on behalf of an email service. By
+ default the "email" service uses the "mail", "cn" and "sn"
+ attributes to discover mail addresses in entries created using
+ inetOrgPerson objectclass[17]. However, the email service has
+ been deployed in an environment that uses entries created
+ using "employee" objectclass. In this case, the attribute
+ "cn" can be mapped to "employeeName", and "inetOrgPerson" can
+ be mapped to "employee", allowing the DUA to perform LDAP
+ operations using the entries that exist in the directory.
+ This mapping is performed by adding attributeMap and
+
+
+
+Neal-Joslin [Page 23]
+
+Internet-Draft DUA Configuration Schema March 2005
+
+
+ objectclassMap attributes to the configuration profile entry
+ as follows (represented in LDIF[16]):
+
+ attributeMap: email:cn=employeeName
+ objectclassMap: email:inetOrgPerson=employee
+
+
+5.1.14 Interpreting the defaultSearchScope attribute
+
+ Interpretation:
+
+ When a DUA needs to search the DSA for information, this
+ attribute provides the "scope" for the search. This parameter
+ can be overridden by the serviceSearchDescriptor attribute.
+ See section 5.1.6.
+
+ Syntax:
+
+ scopeSyntax = "base" | "one" | "sub"
+
+ Default Value:
+
+ The default value for the defaultSearchScope SHOULD be defined
+ by the DUA service. If the default search scope for a service
+ is not defined then the scope SHOULD be for the DUA to perform
+ a subtree search.
+
+
+5.1.15 Interpreting the serviceAuthenticationMethod attribute
+
+ Interpretation:
+
+ The serviceAuthenticationMethod attribute defines an ordered
+ list of LDAP bind methods to be used when attempting to
+ contact a DSA for a particular service. Interpretation and
+ use of this attribute is the same as 5.1.4, but specific for
+ each service.
+
+ Syntax:
+
+ svAuthMethod = service ":" method *(";" method)
+
+ Note: Although multiple authentication methods may be
+ specified in the syntax, at most one of each type is allowed.
+
+ Default Value:
+
+ If the serviceAuthenticationMethod attribute is not provided,
+
+
+
+Neal-Joslin [Page 24]
+
+Internet-Draft DUA Configuration Schema March 2005
+
+
+ the authenticationMethod SHOULD be followed, or its default.
+
+ Other attribute notes:
+
+ Determining how the DUA should bind to the DSAs also depends
+ on the additional configuration attributes, credentialLevel,
+ serviceCredentialLevel and bindTimeLimit. Please review
+ section 5.2 for details on how to properly bind to a DSA.
+
+ Example:
+
+ serviceAuthenticationMethod: email:tls:simple;sasl/DIGEST-MD5
+
+
+5.1.16 Interpreting the serviceCredentialLevel attribute
+
+ Interpretation:
+
+ The serviceCredentialLevel attribute defines what type(s) of
+ credential(s) the DUA SHOULD use when contacting the DSA for a
+ particular service. Interpretation and used of this attribute
+ are the same as 5.1.5.
+
+ Syntax:
+
+ svCredentialLevel = service ":" level *(space level)
+
+ Refer to implementation notes in section 5.2 for additional
+ syntax requirements for the credentialLevel attribute.
+
+ Note: Although multiple credential levels may be specified in
+ the syntax, at most one of each type is allowed.
+
+ Default Value:
+
+ If the serviceCredentialLevel attribute is not defined, the
+ DUA MUST examine the credentialLevel attribute, or follow its
+ default if not provided.
+
+ Other attribute notes:
+
+ Determining how the DUA should bind to the DSAs also depends
+ on the additional configuration attributes,
+ serviceAuthenticationMethod, authenticationMethod and
+ bindTimeLimit. Please review section 5.2 for details on how
+ to properly bind to a DSA.
+
+ Example:
+
+
+
+Neal-Joslin [Page 25]
+
+Internet-Draft DUA Configuration Schema March 2005
+
+
+ serviceCredentialLevel: email:proxy anonymous
+
+
+5.2 Binding to the Directory Server
+
+ The DUA SHOULD use the following algorithm when binding to the
+ server:
+
+ for (clevel in credLevel) [see note 1]
+ if (clevel is "anonymous")
+ for (host in hostnames) [see note 2]
+ if (server is responding)
+ return success
+ return failure
+ else
+ for (amethod in authMethod) [see note 3]
+ if (amethod is none)
+ for (host in hostnames)
+ if (server is responding)
+ return success
+ return failure
+ else
+ for (host in hostnames)
+ authenticate using amethod and clevel
+ if (authentication passed)
+ return success
+ return failure
+
+ Note 1: The credLevel is a list of credential levels as defined
+ in serviceCredentialLevel (section 5.1.16) for a given
+ service. If the serviceCredentialLevel is not defined,
+ the DUA MUST examine the credentialLevel attribute.
+
+ Note 2: hostnames is the list of servers to contact as defined
+ in 5.1.1 & 5.1.2.
+
+ Note 3: The authMethod a list of authentication methods as defined
+ in serviceAuthenticationMethod (section 5.1.15) for a
+ given service. If the serviceAuthenticationMethod is not
+ defined, the DUA MUST examine the authenticationMethod
+ attribute.
+
+
+
+6. Security Considerations
+
+ The profile entries MUST be protected against unauthorized
+ modification. Each service needs to consider implications of
+
+
+
+Neal-Joslin [Page 26]
+
+Internet-Draft DUA Configuration Schema March 2005
+
+
+ providing its service configuration as part of this profile and
+ limit access to the profile entries accordingly.
+
+ The management of the authentication credentials for the DUA is
+ outside the scope of this document and needs to be handled by the
+ DUA.
+
+ Since the DUA needs to know how to properly bind to the directory
+ server, the access control configuration of the DSA MUST assure
+ that the DSA can view all the elements of the DUAConfigProfile
+ attributes. For example, if the credentialLevel attribute contains
+ "Self" but the DSA is unable to access the credentialLevel
+ attribute, the DUA will instead attempt an anonymous connection to
+ the directory server.
+
+ The algorithm described by section 5.2 also has security
+ considerations. Altering that design will alter the security
+ aspects of the configuration profile.
+
+
+7. Acknowledgments
+
+ There were several additional authors of this document. However we
+ chose to represent only one author per company in the heading.
+ From Sun we also would like to acknowledge Roberto Tam for his
+ design work on Sun's first LDAP name service product and his input
+ for this document. From Hewlett-Packard we'd like to acknowledge
+ Dave Binder for his work architecting Hewlett-Packard's LDAP name
+ service product as well as his design guidance on this document.
+ We'd also like to acknowledge Grace Lu from HP, for her input and
+ implementation of HP's configuration profile manager code.
+
+
+8. References
+
+8.1 Normative References
+
+
+[4] S. Bradner, "Key Words for use in RFCs to Indicate Requirement
+ Levels", RFC 2119, March 1997.
+
+
+[5] M. Wahl, A. Coulbeck, T. Howes, S. Kille, "Lightweight Directory
+ Access Protocol (v3): Attribute Syntax Definitions", RFC 2252,
+ December 1997.
+
+
+[6] M. Wahl, S. Kille, T. Howes, "Lightweight Directory Access Protocol
+
+
+
+Neal-Joslin [Page 27]
+
+Internet-Draft DUA Configuration Schema March 2005
+
+
+ (v3): UTF-8 String Representation of Distinguished Names", RFC
+ 2253, December 1997.
+
+
+[7] T. Howes, M. Smith, "The LDAP URL Format", RFC 2255, December 1997.
+
+
+[8] R. Hinden, B. Carpenter, L. Masinter, "Uniform Resource Identifier
+ (URI): Generic Syntax", RFC 3986, January 2005.
+
+
+[9] M. Wahl, "A Summary of the X.500(96) User Schema for use with
+ LDAPv3", RFC 2256, December 1997.
+
+
+[11] M. Wahl, H. Alvestrand, J. Hodges, R. Morgan, "Authentication
+ Methods for LDAP", RFC 2828, May 2000
+
+
+[13] J. Hodges, R. Morgan, M. Wahl, "Lightweight Directory Access
+ Protocol [v3]: Extension for Transport Layer Security", RFC 2830,
+ May 2000
+
+
+[18] IANA, "SIMPLE AUTHENTICATION AND SECURITY LAYER (SASL) MECHANISMS",
+ http://www.iana.org/assignments/sasl-mechanisms, April 2004
+
+
+8.2 Informative References
+
+
+[1] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access Protocol
+ (v3)", RFC 2251, December 1997.
+
+
+[2] L. Howard, "An Approach for Using LDAP as a Network Information
+ Service", RFC 2307, March 1998.
+
+
+[3] Microsoft Corporation, "Windows Services for Unix 3.5",
+ http://www.microsoft.com/windows/sfu/default.asp
+
+
+[12] J. Meyers, "Simple Authentication and Security Layer [SASL]", RFC
+ 2222, October 1997
+
+
+[14] P. Leach, C. Newman, "Using Digest Authentication as a SASL
+
+
+
+Neal-Joslin [Page 28]
+
+Internet-Draft DUA Configuration Schema March 2005
+
+
+ Mechanism", RFC 2831, May 2000
+
+
+[15] T. Howes, "The String Representation of LDAP Search Filters", RFC
+ 2254, December 1997.
+
+
+[16] G. Good, "The LDAP Data Interchange Format (LDIF) - Technical
+ Specification", RFC 2849, June 2000.
+
+
+[17] M. Smith, "Definition of the inetOrgPerson LDAP Object Class", RFC
+ 2789, April 2000
+
+
+9. Examples
+
+ In this section we will describe a fictional DUA which provides one
+ service, called the "email" service. This service would be similar
+ to an email client that uses an LDAP directory to discover email
+ addresses based on a textual representation of the recipient's
+ colloquial name.
+
+ This email service is defined by default to expect that users with
+ email addresses will be of the "inetOrgPerson" objectclass type
+ [17]. And by default, the "email" service expects the colloquial
+ name to be stored in the "cn" attribute, while it expects the email
+ address to be stored in the "mail" attribute (as one would expect
+ as defined by the inetOrgPerson objectclass.)
+
+ As a special feature, the "email" service will perform a special
+ type of attribute mapping, when performing searches. If the "cn"
+ attribute has been mapped to two or more attributes, the "email"
+ service will parse the requested search string and map each white-
+ space separated token into the mapped attributes, respectively.
+
+ The default search filter for the "email" service is
+ "(objectclass=inetOrgPerson)". The email service also defines that
+ when it performs a name to address discovery, it will wrap the
+ search filter inside a complex search filter as follows:
+
+ (&(<filter>)(cn~=<name string>)
+
+ or if "cn" has been mapped to multiple attributes, that wrapping
+ would appear as follows:
+
+ (&(<filter>)(attr1~=<token1>)(attr2~=<token2>)...)
+
+
+
+
+Neal-Joslin [Page 29]
+
+Internet-Draft DUA Configuration Schema March 2005
+
+
+ The below examples show how the "email" service builds it search
+ requests, based on the defined profile. In all cases, the
+ defaultSearchBase is "o=airius.com" and the defaultSearchScope is
+ undefined.
+
+ In addition, for all examples, we assume that the "email" service
+ has been requested to discover the email address for "Jane
+ Hernandez."
+
+
+ Example 1:
+
+ serviceSearchDescriptor: email:"ou=marketing,"
+
+ base: ou=marketing,o=airius.com
+ scope: sub
+ filter: (&(objectclass=inetOrgPerson)(cn~=Jane Hernandez))
+
+ Example 2:
+
+ serviceSearchDescriptor: email:"ou=marketing,"?one?
+ (&(objectclass=inetOrgPerson)(c=us))
+ attributeMap: email:cn=2.5.4.42 sn
+
+ Note: 2.5.4.42 is the OID that represents the "givenName"
+ attribute.
+
+ In this example, the email service performs <name string> parsing
+ as described above to generate a complex search filter. The above
+ example results in one search.
+
+ base: ou=marketing,o=airius.com
+ scope: one
+ filter: (&(&(objectclass=inetOrgPerson)(c=us))
+ (2.5.4.42~=Jane)(sn~=Hernandez))
+
+ Example 3:
+
+ serviceSearchDescriptor: email:ou=marketing,"?base
+ attributeMap: email:cn=name
+
+ This example is invalid, because either the quote should have been
+ escaped, or there should have been a leading quote.
+
+ Example 4:
+
+ serviceSearchDescriptor: email:ou=\mar\\keting,\"?base
+ attributeMap: email:cn=name
+
+
+
+Neal-Joslin [Page 30]
+
+Internet-Draft DUA Configuration Schema March 2005
+
+
+ base: ou=\mar\keting,"
+ scope: base
+ filter (&(objectclass=inetOrgPerson)(name~=Jane Hernandez))
+
+ Example 5:
+
+ serviceSearchDescriptor: email:ou="marketing",o=supercom
+
+ This example is invalid, since the quote was not a leading quote,
+ and thus should have been escaped.
+
+ Example 6:
+
+ serviceSearchDescriptor: email:??(&(objectclass=person)
+ (ou=Org1 \\(temporary\\)))
+
+ base: o=airius.com
+ scope: sub
+ filter: (&((&(objectclass=person)(ou=Org1 \(Temporary\)))
+ (cn~=Jane Henderson)))
+
+ Example 7:
+
+ serviceSearchDescriptor: email:"ou=funny?org,"
+
+ base: ou=funny?org,o=airius.com
+ scope: sub
+ filter (&(objectclass=inetOrgPerson)(cn~=Jane Hernandez))
+
+
+Author's Addresses
+
+ Luke Howard
+ PADL Software Pty. Ltd.
+ PO Box 59
+ Central Park Vic 3145
+ Australia
+
+ EMail: lukeh at padl.com
+
+
+ Bob Neal-Joslin
+ Hewlett-Packard Company
+ 19420 Homestead RD MS43-LF
+ Cupertino, CA 95014
+ USA
+
+ Phone: +1 408 447-3044
+
+
+
+Neal-Joslin [Page 31]
+
+Internet-Draft DUA Configuration Schema March 2005
+
+
+ EMail: bob_joslin at hp.com
+
+
+ Morteza Ansari
+ Infoblox
+ 475 Potrero Avenue
+ Sunnyvale, CA 94085
+ USA
+
+ Phone: +1 408-716-4300
+ EMail: morteza at infoblox.com
+
+ Expires September 2005
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Neal-Joslin [Page 32]
+
Added: openldap/vendor/openldap-release/doc/drafts/draft-lachman-laser-ldap-mail-routing-xx.txt
===================================================================
--- openldap/vendor/openldap-release/doc/drafts/draft-lachman-laser-ldap-mail-routing-xx.txt (rev 0)
+++ openldap/vendor/openldap-release/doc/drafts/draft-lachman-laser-ldap-mail-routing-xx.txt 2007-09-15 10:38:52 UTC (rev 844)
@@ -0,0 +1,661 @@
+INTERNET-DRAFT H. Lachman
+Intended Category: Informational Netscape Communications Corp.
+Filename: draft-lachman-laser-ldap-mail-routing-02.txt G. Shapiro
+ Sendmail, Inc.
+Expires: July 2001 January 2001
+
+ LDAP Schema for Intranet Mail Routing
+
+Status of this Memo
+
+ This document is an Internet-Draft and is in full conformance with
+ all provisions of Section 10 of RFC2026.
+
+ Internet-Drafts are working documents of the Internet Engineering
+ Task Force (IETF), its areas, and its working groups. Note that
+ other groups may also distribute working documents as Internet-
+ Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference
+ material or to cite them other than as "work in progress."
+
+ The list of current Internet-Drafts can be accessed at
+ http://www.ietf.org/ietf/1id-abstracts.txt
+
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html.
+
+ This draft is being discussed on the Laser mailing list at
+ <laser at sunroof.eng.sun.com>. Subscription requests can be sent to
+ <laser-request at sunroof.eng.sun.com> (send an email message with the
+ word "subscribe" in the body). More information on the mailing list
+ along with an archive of back messages is available at
+ <http://playground.sun.com/laser/>.
+
+ [[Section X will be removed before the document is submitted to the
+ IESG.]]
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (1999-2001). All Rights Reserved.
+
+Abstract
+
+ This document defines an LDAP [1] object class called
+ 'inetLocalMailRecipient' and associated attributes that provide a way
+ to designate an LDAP entry as one that represents a local (intra-
+ organizational) email recipient, to specify the recipient's email
+ address(es), and to provide routing information pertinent to the
+ recipient. This is intended to support SMTP [2] message transfer
+ agents in routing RFC 822-based email [3] within a private enterprise
+ only, and is not to be used in the process of routing email across
+ the public Internet.
+
+Lachman, et. al. [Page 1]
+
+INTERNET-DRAFT LDAP Schema for Intranet Mail Routing January 2001
+
+1. Conventions Used in this Document
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this
+ document are to be interpreted as described in [9].
+
+2. Background and Motivation
+
+ LDAP-based directory services are currently being used in many
+ organizations as a repository of information about users and other
+ network entities (such as groups of users, network resources, etc.).
+ In cases where LDAP entries are used to represent entities that are
+ email recipients (e.g., a mail user or a mailing list), the LDAP
+ entries provide a convenient place to store per-recipient data, such
+ as a recipient's email address.
+
+ In many organizations, an email recipient may have an email address
+ (e.g., "joe at example.com") that does not specify the host that
+ receives mail for that recipient (e.g., "host42.example.com"). A
+ message transfer agent (MTA) responsible for routing mail within the
+ organization needs some way to determine the appropriate target host
+ for such a recipient. A common solution is the sendmail "aliases"
+ database which may contain a record that provides the necessary per-
+ recipient routing information (e.g., "joe: joe at host42"). A drawback
+ of this solution is that if the organization hosts more than one DNS
+ domain (e.g., "example.com" and "example.org", with "joe" in each
+ domain being different recipients), a more explicit mapping is
+ desirable. The schema defined in this document provides a way to
+ represent such mappings in LDAP and X.500 [4] directory services.
+
+ An LDAP entry that represents an email recipient could conceivably
+ contain a variety of attributes related to email, such as disk quota
+ and delivery preferences. We consider here only attributes that
+ specify address information and routing information; these attributes
+ may be useful to multiple MTAs within the organization since one or
+ more MTAs may be responsible for intra-organizational routing. The
+ various MTAs in an organization may have been developed by different
+ implementors, so a common schema is desirable for such attributes.
+
+3. Overview
+
+ Email systems deployed in large organizations must scale to support
+ large numbers of users and email servers. This means using email
+ addresses that are independent of particular mailbox server hosts;
+ thus an "email routing server" that receives mail sent to the
+ host-independent (or high-level or top-level or domain ...) address
+ and routes it to the appropriate mailbox server. For scalability
+ there should be many routing servers providing identical service.
+ A set of such servers and the mailbox servers they route to form an
+ "email domain".
+
+Lachman, et. al. [Page 2]
+
+INTERNET-DRAFT LDAP Schema for Intranet Mail Routing January 2001
+
+ This specification describes the basic function of the routing
+ server, including data elements to support per-recipient routing
+ info, and use of LDAP-based directory service to support multiple
+ servers sharing the routing info data. The routing function is
+ distinguished from other MTA-transfer operations.
+
+ The 'inetLocalMailRecipient' object class and associated attributes
+ identify an LDAP entry as representing an SMTP mail recipient (in the
+ sense "recipient" is used in [2]). A recipient may be a mail user, a
+ mailing list, an auto-responder of some kind (e.g., a mailing list
+ subscription program), a network device such as a printer or fax
+ machine, or other recipient type. Address attributes and routing
+ attributes are provided to aid SMTP MTAs in routing mail within an
+ organization to the appropriate target MTA for each recipient.
+
+ Once on the target MTA, a message is handled according to local
+ conventions (which may be specified using other auxiliary object
+ classes and is outside the scope of this document). For example, the
+ message may be delivered to a user mailbox, or to a program or
+ network device, and/or forwarded to another recipient. Or, the
+ target MTA may be a gateway to a non-SMTP mail routing and delivery
+ system including non-SMTP MTAs. Note that, in this discussion,
+ "target MTA" refers to the final SMTP destination of messages for the
+ recipient in question, as we are considering routing of mail only
+ among the SMTP MTAs within an organization.
+
+ Any domain that uses LDAP-based routing MUST support LDAP-based
+ routing at all MTAs responsible for the domain. All other MTAs that
+ do not support LDAP-based routing MUST forward mail for that domain
+ to MTAs that do, using MX records or other local conventions.
+
+ The target MTA checks to see if the destination domain of the
+ recipient address is one that it is responsible for and that uses
+ LDAP-based routing. If so, the MTA checks for matching e-mail
+ addresses in LDAP by looking up the envelope recipient address in
+ LDAP using the object class described in section 4.1 and the
+ attribute discussed in section 4.2. If an unambiguous match is
+ returned, the MTA interprets the routing attributes as described in
+ section 4.3.
+
+ Routing of mail between different organizations across the public
+ Internet is outside the scope of this document, as the mechanism for
+ this is already standardized [5,6]. An 'inetLocalMailRecipient'
+ entry represents a mail recipient that is local to the organization
+ in question, not recipients in other organizations. This means that
+ the domain names that appear within the 'mailLocalAddress' and
+ 'mailHost' attribute values in an 'inetLocalMailRecipient' entry must
+ be DNS domain names that are local to the organization. (e.g.,
+ within the organization's Intranet or by deemed local by other local
+ conventions outside the scope of this standard). An MTA should not
+ look for or use 'inetLocalMailRecipient' entries or attributes if
+ that MTA is not authoritative for the right-hand side of the
+ recipient address in question.
+
+Lachman, et. al. [Page 3]
+
+INTERNET-DRAFT LDAP Schema for Intranet Mail Routing January 2001
+
+ LDAP entries that are not 'inetLocalMailRecipient' entries should be
+ ignored by MTAs for the purpose of routing. An example is a
+ conference room whose LDAP entry contains contact information (e.g.,
+ email address and telephone number) for the person who books
+ reservations for the room; the conference room is not a mail
+ recipient, and can safely be ignored by MTAs doing route
+ determination based on recipient address.
+
+4. Object Class and Attribute Definitions
+
+ The 'inetLocalMailRecipient' object class and associated attributes
+ are defined (using syntaxes given in [7]) as follows.
+
+ 4.1 The inetLocalMailRecipient Object Class
+
+ ( 2.16.840.1.113730.3.2.[[TBD]]
+ NAME 'inetLocalMailRecipient'
+ SUP top
+ AUXILIARY
+ MAY ( mailLocalAddress $
+ mailHost $ mailRoutingAddress
+ )
+ )
+
+ The 'inetLocalMailRecipient' object class signifies that the entry
+ represents an entity within the organization that can receive SMTP
+ mail, such as a mail user or a mailing list. In any case of an entry
+ containing the 'inetLocalMailRecipient' object class, attributes
+ defined in this document MUST be interpreted as specified in this
+ document.
+
+ 4.2 Address Attribute
+
+ ( 2.16.840.1.113730.3.1.13
+ NAME 'mailLocalAddress'
+ DESC 'RFC 822 email address of this recipient'
+ EQUALITY caseIgnoreIA5Match
+ SYNTAX '1.3.6.1.4.1.1466.115.121.1.26{256}'
+ )
+
+ The 'mailLocalAddress' attribute is used to specify email addresses,
+ for the recipient; for example, "nickname at example.com". The address
+ conforms to the syntax of an 'addr-spec' as defined in [3].
+
+ The 'mailLocalAddress' attribute MUST contain all local addresses
+ that represent each recipient of the target MTA. Commonly, the value
+ of the 'mail' attribute should also be among the addresses listed in
+ the 'mailLocalAddress' attribute if it is expected to be used for
+ LDAP mail routing.
+
+Lachman, et. al. [Page 4]
+
+INTERNET-DRAFT LDAP Schema for Intranet Mail Routing January 2001
+
+ When determining the disposition of a given message, MTAs using LDAP
+ (directly or indirectly) to route mail MUST search for an entry with
+ object class 'inetLocalMailRecipient' and a 'mailLocalAddress'
+ attribute matching the message's recipient address. If exactly one
+ matching entry is found, MTAs MUST regard the message as being
+ addressed to the entity that is represented by the directory entry.
+
+ If multiple entries are found, the results of the lookup MUST be
+ treated as unsuccessful and should be handled by the MTA in some
+ locally-appropriate way, such as returning a DSN [10] to the sender.
+
+ If there is no match found by the above, MTAs SHOULD have the
+ capability of searching for the recipient domain against the
+ 'mailLocalAddress' attribute using the "wildcard domain" address
+ "@<full-local-domain>" , e.g., "@example.org". In other words, if
+ mail arrives for "someone at example.org", and there is no recipient
+ with that address specified as 'mailLocalAddress', then the recipient
+ with the wildcard domain address should receive the mail.
+
+ MTAs MAY do other searches but only after the above are done.
+
+ In short, the address attribute 'mailLocalAddress' may be used by an
+ LDAP entry to answer the question "what is/are this account's email
+ address(es)?"
+
+ 4.3 Routing Attributes
+
+ ( 2.16.840.1.113730.3.1.18
+ NAME 'mailHost'
+ DESC 'fully-qualified hostname of the MTA that is the final
+ SMTP destination of messages to this recipient'
+ EQUALITY caseIgnoreIA5Match
+ SYNTAX '1.3.6.1.4.1.1466.115.121.1.26{256}'
+ SINGLE-VALUE
+ )
+
+ The 'mailHost' attribute indicates which SMTP MTA considers the
+ recipient's mail to be locally handleable. This information can be
+ used for routing, in that an intermediary MTA may take it to be the
+ destination for messages addressed to this recipient. Normal mail
+ routing requirements (i.e., use of MX records [5]) apply to the
+ specified hostname unless overridden by local conventions. In other
+ words, the mail should be sent to the specified host without changing
+ the recipient address. The hostname is specified as a
+ fully-qualified DNS hostname with no trailing dot (e.g.,
+ "host42.example.com").
+
+ If the 'inetLocalMailRecipient' object class is present, the
+ 'mailHost' attribute for each entry MAY contain a value. If it does,
+ that value MUST be the fully qualified name of the server containing
+ the host MTA for this person. If 'mailHost' is present then it MUST
+ be taken as the host for this user, and all mail to this user MUST be
+ routed to this machine.
+
+Lachman, et. al. [Page 5]
+
+INTERNET-DRAFT LDAP Schema for Intranet Mail Routing January 2001
+
+ ( 2.16.840.1.113730.3.1.47
+ NAME 'mailRoutingAddress'
+ DESC 'RFC 822 address to use when routing messages to
+ the SMTP MTA of this recipient'
+ EQUALITY caseIgnoreIA5Match
+ SYNTAX '1.3.6.1.4.1.1466.115.121.1.26{256}'
+ SINGLE-VALUE
+ )
+
+ The 'mailRoutingAddress' attribute indicates a routing address for
+ the recipient. The address MUST conform to the syntax of an
+ 'addr-spec' in [3]. An intermediary MTA MUST use this information to
+ route the message to the MTA that handles mail for this recipient,
+ e.g., the envelope address MUST be rewritten to this value. This is
+ useful in cases where, for a given recipient, the target MTA prefers
+ a particular address to appear as the recipient address in the SMTP
+ envelope. 'mailRoutingAddress' MAY be used as an alternative to
+ 'mailHost', and is intended to have the same effect as 'mailHost'
+ except that 'mailRoutingAddress' is an address for rewriting the
+ envelope. With 'mailHost', the envelope address either is not
+ rewritten, or is rewritten according to implementation-specific rules
+ and/or configuration.
+
+ If both 'mailHost' and 'mailRoutingAddress' are present, MTAs MUST
+ interpret it to mean that messages are to be routed to the host
+ indicated by 'mailHost', while rewriting the envelope as per
+ 'mailRoutingAddress'. In theory, there could be peculiar cases where
+ this is necessary, but this is not normally expected.
+
+ Absence of both 'mailHost' and 'mailRoutingAddress' MAY be considered
+ an error, unless "location-independent" recipient types are supported
+ by the various MTAs within the organization. This would allow any
+ MTA in the organization to handle the processing of mail for, say, a
+ mailing list. This presumes that the various MTAs all recognize the
+ recipient type in question, suggesting a need to standardize
+ recipient types that could be "location-independent".
+
+ In short, routing attributes may be used by an LDAP entry to answer
+ the question "how should MTAs route mail to this account?"
+ (analogous to using the sendmail "aliases" database for per-user
+ routing within an organization). This is in contrast with
+ "forwarding"; forwarding and delivery options may be specified in an
+ LDAP entry to answer the question "what happens to mail once it
+ arrives at this account?", which may include forwarding to some other
+ account within or outside the organization (analogous to using the
+ sendmail ".forward" file). Such options are outside the scope of the
+ 'inetLocalMailRecipient' schema definition.
+
+Lachman, et. al. [Page 6]
+
+INTERNET-DRAFT LDAP Schema for Intranet Mail Routing January 2001
+
+ The following possibilities exist as a result of an LDAP lookup on an
+ address:
+
+ mailHost is mailRoutingAddress is Results in
+ ----------- --------------------- ----------
+ set to a set mail routed to
+ "local" host mailRoutingAddress
+
+ set to a not set delivered to
+ "local" host original address
+
+ set to a set relay to mailHost
+ remote host using mailRoutingAddress
+
+ set to a not set original address
+ remote host relayed to mailHost
+
+ not set set mail routed to
+ mailRoutingAddress
+
+ not set not set error or
+ "location-independent"
+
+ The term "local" host above means the host specified is one that the
+ local (target) MTA considers to be a local delivery. The local MTA
+ MAY rewrite the original address when mailRoutingAddress is not set
+ if local conventions warrant the change.
+
+5. Examples
+
+ The following examples illustrate possible uses of the
+ 'inetLocalMailRecipient' object class. Note that the examples
+ include attributes defined outside of this document to demonstrate a
+ complete record. The existence of these attributes in the example is
+ not an indication that these attributes are used for LDAP-based mail
+ routing (e.g., the 'mail' is not used for mail routing).
+
+ Here is an example of an LDAP entry representing a mail user:
+
+ dn: uid=joe,o=Example Corp,c=US
+ objectClass: top
+ objectClass: person
+ objectClass: organizationalPerson
+ objectClass: inetOrgPerson
+ objectClass: inetLocalMailRecipient
+ objectClass: nsMessagingServerUser
+ cn: Joe User
+ sn: User
+ uid: joe
+ userPassword: {crypt}y2KxtbzMYnApU
+ mail: joe at example.com
+
+Lachman, et. al. [Page 7]
+
+INTERNET-DRAFT LDAP Schema for Intranet Mail Routing January 2001
+
+ mailLocalAddress: joe at example.com
+ mailLocalAddress: joe at another.example.com
+ mailHost: nsmail1.example.com
+ mailDeliveryOption: mailbox
+ mailQuota: 1000000
+ mailForwardingAddress: mary at example.com
+
+ Joe User is a user of a hypothetical mail system called NS Messaging.
+ Let's say mail arrives on an MTA called "mx.example.com", addressed
+ to "joe at example.com". That MTA searches the directory for a mail
+ recipient with that address, using an LDAP search filter [8] such as:
+
+ (&(objectClass=inetLocalMailRecipient)
+ (mailLocalAddress=joe at example.com))
+
+ It finds Joe's LDAP entry, and routes the message to the target MTA
+ "nsmail1.example.com", while not rewriting the SMTP envelope
+ recipient address. Then, "nsmail1.example.com" receives the message,
+ searches for and finds the recipient in the directory, ascertains
+ that it is the recipient's target MTA, and handles the message as per
+ other attributes in the recipient's entry and/or the MTA
+ configuration (in this case, the message is delivered to a mailbox,
+ and forwarded to another recipient).
+
+ Note that this document does not specify the rules an MTA is to use
+ to ascertain whether or not it is the target MTA for a given
+ recipient (it could check the recipient's 'mailHost' value against
+ its own hostname, or check the recipient's 'mailRoutingAddress', or
+ check the MTA configuration, or some combination of these).
+
+ Here is another example of an LDAP entry representing a mail user:
+
+ dn: uid=john,o=Example Corp,c=US
+ objectClass: top
+ objectClass: person
+ objectClass: organizationalPerson
+ objectClass: inetOrgPerson
+ objectClass: inetLocalMailRecipient
+ objectClass: xyzMailUser
+ cn: John Doe
+ sn: Doe
+ uid: john
+ userPassword: {crypt}y2KxtbzMYnApU
+ mail: john at example.com
+ mailLocalAddress: john at example.com
+ mailRoutingAddress: John_Doe at xyz-gw.example.com
+ xyzPostOfficeName: PO_1
+ xyzClusterNumber: 3
+ xyzMessageStoreId: 9
+
+Lachman, et. al. [Page 8]
+
+INTERNET-DRAFT LDAP Schema for Intranet Mail Routing January 2001
+
+ John Doe is a user of a hypothetical mail system called XYZ Mail.
+ Let's say mail arrives on an MTA called "mx.example.com", addressed
+ to "john at example.com". That MTA searches the directory for a mail
+ recipient with that address, and routes the message to "xyz-
+ gw.example.com", rewriting the SMTP envelope recipient address to
+ "John_Doe at xyz-gw.example.com", as per the 'mailRoutingAddress'. On
+ "xyz-gw.example.com", the message is gatewayed into the XYZ Mail
+ system and then dealt with as per other attributes.
+
+ Here is an example of an LDAP entry representing a mailing list:
+
+ dn: cn=Scuba Group,o=Example Corp,c=US
+ objectClass: top
+ objectClass: groupOfUniqueNames
+ objectClass: inetLocalMailRecipient
+ objectClass: mailGroup
+ cn: Scuba Group
+ mail: scuba at example.com
+ mailLocalAddress: scuba at example.com
+ mailHost: host42.example.com
+ mgrpRFC822MailMember: joe at example.com
+ mgrpRFC822MailMember: john at example.com
+
+ The Scuba Group is a mail group (mailing list) that includes two
+ members. A message addressed to "scuba at example.com" is routed to
+ "host42.example.com" where it is then resent to the mailing list
+ members.
+
+ Here is an example of an LDAP entry representing a forwarding alias:
+
+ dn: cn=Jane Roe Forwarding Alias,o=Example,c=US
+ objectClass: top
+ objectClass: inetLocalMailRecipient
+ objectClass: mailForwardingAlias
+ mail: janeroe at example.org
+ mailLocalAddress: janeroe at example.org
+ mailHost: mail.example.org
+ mailForwardingAddress: janeroe at elsewhere.example.com
+ cn: Jane Roe Forwarding Alias
+
+ This entry uses a hypothetical object class 'mailForwardingAlias'
+ that is not specified here, but is used as an example of how an LDAP
+ entry might represent such a recipient type. A message addressed to
+ "janeroe at example.org" is routed to "mail.example.org" where it is
+ then forwarded. In this case, Jane Roe may be a former member of the
+ Example Organization, and they are forwarding her mail to her new
+ address elsewhere.
+
+Lachman, et. al. [Page 9]
+
+INTERNET-DRAFT LDAP Schema for Intranet Mail Routing January 2001
+
+6. Security Considerations
+
+ As in all cases where account information is stored in an LDAP-based
+ directory service, network administrators must be careful to ensure
+ that their directory service controls users' access to the entries
+ and attributes stored therein, according to site policy. In
+ particular, mail routing information should not be accessible from
+ outside the organization, since it is intended for use only by MTAs
+ within the organization.
+
+7. Acknowledgments
+
+ The 'inetLocalMailRecipient' object class is based on an earlier
+ design done by the Netscape Messaging and Directory Server teams,
+ which was implemented and deployed to customers as part of Netscape
+ Messaging Server. Various team members contributed to the design,
+ including Bill Fitler, Bruce Steinback, Prabhat Keni, Mike Macgirvin,
+ John Myers, John Kristian, Tim Howes, Mark Smith, and Leif Hedstrom.
+ Thanks also to Jeff Hodges of Stanford for contributing to the early
+ design discussions, and to the other participants in the IETF LASER
+ BOF, including, from Sun Microsystems, John Beck, Anil Srivastava,
+ and Darryl Huff.
+
+8. References
+
+ [1] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access
+ Protocol (v3)", RFC 2251, December 1997.
+
+ [2] J. Postel, "Simple Mail Transfer Protocol", STD 10, RFC 821,
+ August 1982.
+
+ [3] D. Crocker, "Standard for the Format of ARPA Internet Text
+ Messages", STD 11, RFC 822, August 1982.
+
+ [4] "Information Processing Systems - Open Systems Interconnection -
+ The Directory: Overview of Concepts, Models and Service", ISO/IEC JTC
+ 1/SC21, International Standard 9594-1, 1988.
+
+ [5] C. Partridge, "Mail routing and the domain system", STD 14, RFC
+ 974, January 1986.
+
+ [6] R. Braden, "Requirements for Internet hosts - application and
+ support", STD 3, RFC 1123, October 1989.
+
+ [7] M. Wahl, A. Coulbeck, T. Howes, S. Kille, "Lightweight X.500
+ Directory Access Protocol (v3): Attribute Syntax Definitions", RFC
+ 2252, December 1997.
+
+ [8] T. Howes, "The String Representation of LDAP Search Filters",
+ RFC 2254, December 1997.
+
+Lachman, et. al. [Page 10]
+
+INTERNET-DRAFT LDAP Schema for Intranet Mail Routing January 2001
+
+ [9] S. Bradner, "Key words for use in RFCs to Indicate Requirement
+ Levels", BCP 14, RFC 2119, March 1997.
+
+ [10] K. Moore, "SMTP Service Extension for Delivery Status
+ Notifications", RCP 1891, January 1996.
+
+9. Authors' Addresses
+
+ Hans Lachman
+ Netscape Communications Corp.
+ 501 East Middlefield Road
+ Mountain View, CA 94043
+ Phone: (650) 254-1900
+ EMail: lachman at netscape.com
+
+ Gregory Neil Shapiro
+ Sendmail, Inc.
+ 6603 Shellmound Street
+ Emeryville, CA 94608-1042
+ Phone: +1 510-594-5522
+ Fax: +1 510-594-5411
+ EMail: gshapiro at sendmail.org
+
+X. Change Summary
+
+X.1.1 Substantive changes between
+ draft-lachman-laser-ldap-mail-routing-00.txt and
+ draft-lachman-laser-ldap-mail-routing-01.txt
+
+ (i) Added Gregory Neil Shapiro as another author.
+ (ii) Changed Draft heaer.
+ (iii) Added "Conventions Used in this Document" section.
+ (iv) Replaced RFC mentions with reference numbers.
+ (v) Add new MUST/SHOULD/MAY sections to bring more in line with
+ RFC documents.
+ (vi) Clarify job of MTA in Overview by adding third paragraph.
+ (vii) mailRoutingAddress can be outside of administrative control.
+ (viii) Eliminated use of 'mail' attribute for mail routing.
+ (ix) Changed name of 'mailAlternateAddress' to 'mailLocalAddress'.
+ (x) Remove "routable" from 'mailLocalAddress' description.
+ (xi) Clarify which addresses MUST be in 'mailLocalAddress'.
+ (xii) Allow for multiple responses if they all have the same
+ routing attribute values.
+ (xiii) Clarify use of MX records on routing attributes.
+ (xiv) Add a table to clarify use of 'mailHost' and
+ 'mailRoutingAddress'.
+ (xv) Remove document weakening statements from section 5.
+ (xvi) Only use reserved domains (example.com, example.org) in
+ examples.
+ (xvii) Clean up references
+ (xviii) Added section X to list the changes between draft versions.
+
+Lachman, et. al. [Page 11]
+
+INTERNET-DRAFT LDAP Schema for Intranet Mail Routing January 2001
+
+X.1.2 Substantive changes between
+ draft-lachman-laser-ldap-mail-routing-01.txt and
+ draft-lachman-laser-ldap-mail-routing-02.txt
+
+ (i) Changed Intended Category from Standard Track to Informational.
+ (ii) Removed references to mailGroup document which has expired.
+ (iii) Add additional Overview text from RL 'Bob' Morgan.
+ (iv) If a domain uses LDAP-based routing, require all MTAs in that
+ domain to either use LDAP for routing or forward mail to an
+ MTA which uses LDAP for routing.
+ (v) Add more text regarding "local" domain.
+ (vi) Tighten rules for better interoperability. Multiple,
+ matching results is now treated as an unsuccessful lookup.
+ (vii) Tighten rules for better interoperability. Change the action
+ for a lookup which returns both a 'mailHost' and
+ 'mailRoutingAddress' to a MUST (from a MAY).
+ (viii) Point out that examples contain attributes which are not part of
+ this spec and should not be used for mail routing
+ (specifically, 'mail').
+ (ix) Clean up text.
+ (x) NOTE: Still need vendor-neutral OIDs for the objectClass and
+ attributes.
+
+10. Full Copyright Statement
+
+ Copyright (C) The Internet Society (1999-2001). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished
+ to others, and derivative works that comment on or otherwise
+ explain it or assist in its implementation may be prepared, copied,
+ published and distributed, in whole or in part, without
+ restriction of any kind, provided that the above copyright notice
+ and this paragraph are included on all such copies and derivative
+ works. However, this document itself may not be modified in any
+ way, such as by removing the copyright notice or references to the
+ Internet Society or other Internet organizations, except as needed
+ for the purpose of developing Internet standards in which case the
+ procedures for copyrights defined in the Internet Standards
+ process must be followed, or as required to translate it into
+ languages other than English.
+
+ The limited permissions granted above are perpetual and will not
+ be revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on
+ an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
+ IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
+ THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Lachman, et. al. [Page 12]
Added: openldap/vendor/openldap-release/doc/drafts/draft-legg-ldap-acm-admin-xx.txt
===================================================================
--- openldap/vendor/openldap-release/doc/drafts/draft-legg-ldap-acm-admin-xx.txt (rev 0)
+++ openldap/vendor/openldap-release/doc/drafts/draft-legg-ldap-acm-admin-xx.txt 2007-09-15 10:38:52 UTC (rev 844)
@@ -0,0 +1,502 @@
+INTERNET-DRAFT S. Legg
+draft-legg-ldap-acm-admin-03.txt Adacel Technologies
+Intended Category: Standards Track June 16, 2004
+
+
+ Lightweight Directory Access Protocol (LDAP):
+ Access Control Administration
+
+ Copyright (C) The Internet Society (2004). All Rights Reserved.
+
+ Status of this Memo
+
+
+ This document is an Internet-Draft and is in full conformance with
+ all provisions of Section 10 of RFC2026.
+
+ Internet-Drafts are working documents of the Internet Engineering
+ Task Force (IETF), its areas, and its working groups. Note that
+ other groups may also distribute working documents as
+ Internet-Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference
+ material or to cite them other than as "work in progress".
+
+ The list of current Internet-Drafts can be accessed at
+ http://www.ietf.org/ietf/1id-abstracts.txt
+
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html.
+
+ Distribution of this document is unlimited. Comments should be sent
+ to the author.
+
+ This Internet-Draft expires on 16 December 2004.
+
+
+Abstract
+
+ This document adapts the X.500 directory administrative model, as it
+ pertains to access control administration, for use by the Lightweight
+ Directory Access Protocol. The administrative model partitions the
+ Directory Information Tree for various aspects of directory data
+ administration, e.g., subschema, access control and collective
+ attributes. This document provides the particular definitions that
+ support access control administration, but does not define a
+ particular access control scheme.
+
+
+
+Legg Expires 16 December 2004 [Page 1]
+
+INTERNET-DRAFT Access Control Administration June 16, 2004
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
+ 2. Conventions. . . . . . . . . . . . . . . . . . . . . . . . . . 2
+ 3. Access Control Administrative Areas. . . . . . . . . . . . . . 3
+ 4. Access Control Scheme Indication . . . . . . . . . . . . . . . 3
+ 5. Access Control Information . . . . . . . . . . . . . . . . . . 4
+ 6. Access Control Subentries. . . . . . . . . . . . . . . . . . . 4
+ 7. Applicable Access Control Information. . . . . . . . . . . . . 5
+ 8. Security Considerations. . . . . . . . . . . . . . . . . . . . 5
+ 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
+ 10. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 6
+ 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
+ 11.1. Normative References. . . . . . . . . . . . . . . . . . 6
+ 11.2. Informative References. . . . . . . . . . . . . . . . . 7
+ Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7
+ Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 7
+
+1. Introduction
+
+ This document adapts the X.500 directory administrative model [X501],
+ as it pertains to access control administration, for use by the
+ Lightweight Directory Access Protocol (LDAP) [RFC3377].
+
+ The administrative model [ADMIN] partitions the Directory Information
+ Tree (DIT) for various aspects of directory data administration,
+ e.g., subschema, access control and collective attributes. The parts
+ of the administrative model that apply to every aspect of directory
+ data administration are described in [ADMIN]. This document
+ describes the administrative framework for access control.
+
+ An access control scheme describes the means by which access to
+ directory information, and potentially to access rights themselves,
+ may be controlled. This document describes the framework for
+ employing access control schemes but does not define a particular
+ access control scheme. Two access control schemes known as Basic
+ Access Control and Simplified Access Control are defined by [BAC].
+ Other access control schemes may be defined by other documents.
+
+ This document is derived from, and duplicates substantial portions
+ of, Sections 4 and 8 of X.501 [X501].
+
+2. Conventions
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in BCP 14, RFC 2119
+ [RFC2119].
+
+
+
+Legg Expires 16 December 2004 [Page 2]
+
+INTERNET-DRAFT Access Control Administration June 16, 2004
+
+
+ Schema definitions are provided using LDAP description formats
+ [RFC2252]. Note that the LDAP descriptions have been rendered with
+ additional white-space and line breaks for the sake of readability.
+
+3. Access Control Administrative Areas
+
+ The specific administrative area [ADMIN] for access control is termed
+ an Access Control Specific Area (ACSA). The root of the ACSA is
+ termed an Access Control Specific Point (ACSP) and is represented in
+ the DIT by an administrative entry [ADMIN] which includes
+ accessControlSpecificArea as a value of its administrativeRole
+ operational attribute [SUBENTRY].
+
+ An ACSA MAY be partitioned into subtrees termed inner administrative
+ areas [ADMIN]. Each such inner area is termed an Access Control
+ Inner Area (ACIA). The root of the ACIA is termed an Access Control
+ Inner Point (ACIP) and is represented in the DIT by an administrative
+ entry which includes accessControlInnerArea as a value of its
+ administrativeRole operational attribute.
+
+ An administrative entry can never be both an ACSP and an ACIP. The
+ corresponding values can therefore never be present simultaneously in
+ the administrativeRole attribute.
+
+ Each entry necessarily falls within one and only one ACSA. Each such
+ entry may also fall within one or more ACIAs nested inside the ACSA
+ containing the entry.
+
+ An ACSP or ACIP has zero, one or more subentries that contain Access
+ Control Information (ACI).
+
+4. Access Control Scheme Indication
+
+ The access control scheme (e.g., Basic Access Control [BAC]) in force
+ in an ACSA is indicated by the accessControlScheme operational
+ attribute contained in the administrative entry for the relevant
+ ACSP.
+
+ The LDAP description [RFC2252] for the accessControlScheme
+ operational attribute is:
+
+ ( 2.5.24.1 NAME 'accessControlScheme'
+ EQUALITY objectIdentifierMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
+ SINGLE-VALUE USAGE directoryOperation )
+
+ An access control scheme conforming to the access control framework
+ described in this document MUST define a distinct OBJECT IDENTIFIER
+
+
+
+Legg Expires 16 December 2004 [Page 3]
+
+INTERNET-DRAFT Access Control Administration June 16, 2004
+
+
+ value to identify it through the accessControlScheme attribute.
+ Object Identifier Descriptors for access control scheme identifiers
+ may be registered with IANA [BCP64].
+
+ Only administrative entries for ACSPs are permitted to contain an
+ accessControlScheme attribute. If the accessControlScheme attribute
+ is absent from a given ACSP, the access control scheme in force in
+ the corresponding ACSA, and its effect on operations, results and
+ errors, is implementation defined.
+
+ Any entry or subentry in an ACSA is permitted to contain ACI if and
+ only if such ACI is permitted by, and consistent with, the access
+ control scheme identified by the value of the accessControlScheme
+ attribute of the ACSP.
+
+5. Access Control Information
+
+ There are three categories of Access Control Information (ACI):
+ entry, subentry and prescriptive.
+
+ Entry ACI applies to only the entry or subentry in which it appears,
+ and the contents thereof. Subject to the access control scheme, any
+ entry or subentry MAY hold entry ACI.
+
+ Subentry ACI applies to only the subentries of the administrative
+ entry in which it appears. Subject to the access control scheme, any
+ administrative entry, for any aspect of administration, MAY hold
+ subentry ACI.
+
+ Prescriptive ACI applies to all the entries within a subtree or
+ subtree refinement of an administrative area (either an ACSA or an
+ ACIA), as defined by the subtreeSpecification attribute of the
+ subentry in which it appears. Prescriptive ACI is only permitted in
+ subentries of an ACSP or ACIP. Prescriptive ACI in the subentries of
+ a particular administrative point never applies to the same or any
+ other subentry of that administrative point, but does apply to the
+ subentries of subordinate administrative points, where those
+ subentries are within the subtree or subtree refinement.
+
+6. Access Control Subentries
+
+ Each subentry which contains prescriptive ACI MUST have
+ accessControlSubentry as a value of its objectClass attribute. Such
+ a subentry is called an access control subentry.
+
+ The LDAP description [RFC2252] for the accessControlSubentry
+ auxiliary object class is:
+
+
+
+
+Legg Expires 16 December 2004 [Page 4]
+
+INTERNET-DRAFT Access Control Administration June 16, 2004
+
+
+ ( 2.5.17.1 NAME 'accessControlSubentry' AUXILIARY )
+
+ A subentry of this object class MUST contain at least one
+ prescriptive ACI attribute of a type consistent with the value of the
+ accessControlScheme attribute of the corresponding ACSP.
+
+ The subtree or subtree refinement for an access control subentry is
+ termed a Directory Access Control Domain (DACD). A DACD can contain
+ zero entries, and can encompass entries that have not yet been added
+ to the DIT, but does not extend beyond the scope of the ACSA or ACIA
+ with which it is associated.
+
+ Since a subtreeSpecification may define a subtree refinement, DACDs
+ within a given ACSA may arbitrarily overlap.
+
+7. Applicable Access Control Information
+
+ Although particular items of ACI may specify attributes or values as
+ the protected items, ACI is logically associated with entries.
+
+ The ACI that is considered in access control decisions regarding an
+ entry includes:
+
+ (1) Entry ACI from that particular entry.
+
+ (2) Prescriptive ACI from access control subentries whose DACDs
+ contain the entry. Each of these access control subentries is
+ necessarily either a subordinate of the ACSP for the ACSA
+ containing the entry, or a subordinate of the ACIP for an ACIA
+ that contains the entry.
+
+ The ACI that is considered in access control decisions regarding a
+ subentry includes:
+
+ (1) Entry ACI from that particular subentry.
+
+ (2) Prescriptive ACI from access control subentries whose DACDs
+ contain the subentry, excluding those belonging to the same
+ administrative point as the subentry for which the decision is
+ being made.
+
+ (3) Subentry ACI from the administrative point associated with the
+ subentry.
+
+8. Security Considerations
+
+ This document defines a framework for employing an access control
+ scheme, i.e., the means by which access to directory information and
+
+
+
+Legg Expires 16 December 2004 [Page 5]
+
+INTERNET-DRAFT Access Control Administration June 16, 2004
+
+
+ potentially to access rights themselves may be controlled, but does
+ not itself define any particular access control scheme. The degree
+ of protection provided, and any security risks, are determined by the
+ provisions of the access control schemes (defined elsewhere) making
+ use of this framework.
+
+ Security considerations that apply to directory administration in
+ general [ADMIN] also apply to access control administration.
+
+9. Acknowledgements
+
+ This document is derived from, and duplicates substantial portions
+ of, Sections 4 and 8 of X.501 [X501].
+
+10. IANA Considerations
+
+ The Internet Assigned Numbers Authority (IANA) is requested to update
+ the LDAP descriptors registry [BCP64] as indicated by the following
+ templates:
+
+ Subject: Request for LDAP Descriptor Registration
+ Descriptor (short name): accessControlScheme
+ Object Identifier: 2.5.24.1
+ Person & email address to contact for further information:
+ Steven Legg <steven.legg at adacel.com.au>
+ Usage: attribute type
+ Specification: RFC XXXX
+ Author/Change Controller: IESG
+
+ Subject: Request for LDAP Descriptor Registration
+ Descriptor (short name): accessControlSubentry
+ Object Identifier: 2.5.17.1
+ Person & email address to contact for further information:
+ Steven Legg <steven.legg at adacel.com.au>
+ Usage: object class
+ Specification: RFC XXXX
+ Author/Change Controller: IESG
+
+11. References
+
+11.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2252] Wahl, M., Coulbeck, A., Howes, T. and S. Kille,
+ "Lightweight Directory Access Protocol (v3): Attribute
+ Syntax Definitions", RFC 2252, December 1997.
+
+
+
+Legg Expires 16 December 2004 [Page 6]
+
+INTERNET-DRAFT Access Control Administration June 16, 2004
+
+
+ [RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access
+ Protocol (v3): Technical Specification", RFC 3377,
+ September 2002.
+
+ [BCP64] Zeilenga, K., "Internet Assigned Numbers Authority (IANA
+ Considerations for the Lightweight Directory Access
+ Protocol (LDAP)", BCP 64, RFC 3383, September 2002.
+
+ [SUBENTRY] Zeilenga, K. and S. Legg, "Subentries in the Lightweight
+ Directory Access Protocol (LDAP)", RFC 3672, December
+ 2003.
+
+ [ADMIN] Legg, S., "Lightweight Directory Access Protocol (LDAP):
+ Directory Administrative Model",
+ draft-legg-ldap-admin-xx.txt, a work in progress, June
+ 2004.
+
+11.2. Informative References
+
+ [COLLECT] Zeilenga, K., "Collective Attributes in the Lightweight
+ Directory Access Protocol (LDAP)", RFC 3671, December
+ 2003.
+
+ [BAC] Legg, S., "Lightweight Directory Access Protocol (LDAP):
+ Basic and Simplified Access Control",
+ draft-legg-ldap-acm-bac-xx.txt, a work in progress, June
+ 2004.
+
+ [X501] ITU-T Recommendation X.501 (02/01) | ISO/IEC 9594-2:2001,
+ Information technology - Open Systems Interconnection -
+ The Directory: Models
+
+Author's Address
+
+ Steven Legg
+ Adacel Technologies Ltd.
+ 250 Bay Street
+ Brighton, Victoria 3186
+ AUSTRALIA
+
+ Phone: +61 3 8530 7710
+ Fax: +61 3 8530 7888
+ EMail: steven.legg at adacel.com.au
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2004). This document is subject
+ to the rights, licenses and restrictions contained in BCP 78, and
+
+
+
+Legg Expires 16 December 2004 [Page 7]
+
+INTERNET-DRAFT Access Control Administration June 16, 2004
+
+
+ except as set forth therein, the authors retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr at ietf.org.
+
+Changes in Draft 01
+
+ Section 4 has been extracted to become a separate Internet draft,
+ draft-legg-ldap-admin-00.txt. The subsections of Section 5 have
+ become the new Sections 3 to 7. Editorial changes have been made to
+ accommodate this split. No technical changes have been introduced.
+
+Changes in Draft 02
+
+ RFC 3377 replaces RFC 2251 as the reference for LDAP.
+
+ An IANA Considerations section has been added.
+
+Changes in Draft 03
+
+
+
+Legg Expires 16 December 2004 [Page 8]
+
+INTERNET-DRAFT Access Control Administration June 16, 2004
+
+
+ The document has been reformatted in line with current practice.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Legg Expires 16 December 2004 [Page 9]
+
+
Added: openldap/vendor/openldap-release/doc/drafts/draft-legg-ldap-acm-bac-xx.txt
===================================================================
--- openldap/vendor/openldap-release/doc/drafts/draft-legg-ldap-acm-bac-xx.txt (rev 0)
+++ openldap/vendor/openldap-release/doc/drafts/draft-legg-ldap-acm-bac-xx.txt 2007-09-15 10:38:52 UTC (rev 844)
@@ -0,0 +1,2351 @@
+
+INTERNET-DRAFT S. Legg
+draft-legg-ldap-acm-bac-03.txt Adacel Technologies
+Intended Category: Standards Track June 16, 2004
+Updates: RFC 2252
+
+
+ Lightweight Directory Access Protocol (LDAP):
+ Basic and Simplified Access Control
+
+ Copyright (C) The Internet Society (2004). All Rights Reserved.
+
+ Status of this Memo
+
+
+ This document is an Internet-Draft and is in full conformance with
+ all provisions of Section 10 of RFC2026.
+
+ Internet-Drafts are working documents of the Internet Engineering
+ Task Force (IETF), its areas, and its working groups. Note that
+ other groups may also distribute working documents as
+ Internet-Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference
+ material or to cite them other than as "work in progress".
+
+ The list of current Internet-Drafts can be accessed at
+ http://www.ietf.org/ietf/1id-abstracts.txt
+
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html.
+
+ Distribution of this document is unlimited. Comments should be sent
+ to the author.
+
+ This Internet-Draft expires on 16 December 2004.
+
+
+Abstract
+
+ An access control scheme describes the means by which access to
+ directory information and potentially to access rights themselves may
+ be controlled. This document adapts the X.500 directory Basic Access
+ Control and Simplied Access Control schemes for use by the
+ Lightweight Directory Access Protocol.
+
+
+
+
+
+Legg Expires 16 December 2004 [Page 1]
+
+INTERNET-DRAFT Basic and Simplified Access Control June 16, 2004
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 2. Conventions. . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 3. Basic Access Control . . . . . . . . . . . . . . . . . . . . . 4
+ 3.1. Permissions. . . . . . . . . . . . . . . . . . . . . . . 5
+ 3.1.1. Read . . . . . . . . . . . . . . . . . . . . . . 5
+ 3.1.2. Compare. . . . . . . . . . . . . . . . . . . . . 6
+ 3.1.3. Browse . . . . . . . . . . . . . . . . . . . . . 6
+ 3.1.4. ReturnDN . . . . . . . . . . . . . . . . . . . . 6
+ 3.1.5. FilterMatch. . . . . . . . . . . . . . . . . . . 6
+ 3.1.6. Modify . . . . . . . . . . . . . . . . . . . . . 6
+ 3.1.7. Add. . . . . . . . . . . . . . . . . . . . . . . 6
+ 3.1.8. Remove . . . . . . . . . . . . . . . . . . . . . 7
+ 3.1.9. DiscloseOnError. . . . . . . . . . . . . . . . . 7
+ 3.1.10. Rename . . . . . . . . . . . . . . . . . . . . . 7
+ 3.1.11. Export . . . . . . . . . . . . . . . . . . . . . 7
+ 3.1.12. Import . . . . . . . . . . . . . . . . . . . . . 8
+ 3.1.13. Invoke . . . . . . . . . . . . . . . . . . . . . 8
+ 3.2. Representation of Access Control Information . . . . . . 8
+ 3.2.1. Identification Tag . . . . . . . . . . . . . . . 11
+ 3.2.2. Precedence . . . . . . . . . . . . . . . . . . . 11
+ 3.2.3. Authentication Level . . . . . . . . . . . . . . 11
+ 3.2.4. itemFirst and userFirst Components . . . . . . . 12
+ 3.2.5. Determining Group Membership . . . . . . . . . . 16
+ 3.3. ACI Operational Attributes . . . . . . . . . . . . . . . 17
+ 3.3.1. Prescriptive ACI . . . . . . . . . . . . . . . . 17
+ 3.3.2. Entry ACI. . . . . . . . . . . . . . . . . . . . 17
+ 3.3.3. Subentry ACI . . . . . . . . . . . . . . . . . . 18
+ 3.3.4. Protecting the ACI . . . . . . . . . . . . . . . 18
+ 3.4. Access Control Decision Points for LDAP Operations . . . 18
+ 3.4.1. Common Elements of Procedure . . . . . . . . . . 19
+ 3.4.1.1. Alias Dereferencing. . . . . . . . . . 19
+ 3.4.1.2. Return of Names in Errors. . . . . . . 19
+ 3.4.1.3. Non-disclosure of Entry Existence. . . 20
+ 3.4.2. Compare Operation Decision Points. . . . . . . . 20
+ 3.4.3. Search Operation Decision Points . . . . . . . . 20
+ 3.4.4. Add Operation Decision Points. . . . . . . . . . 23
+ 3.4.5. Delete Operation Decision Points . . . . . . . . 24
+ 3.4.6. Modify Operation Decision Points . . . . . . . . 24
+ 3.4.7. Modify DN Operation Decision Points. . . . . . . 25
+ 3.5. Access Control Decision Function . . . . . . . . . . . . 26
+ 3.5.1. Inputs . . . . . . . . . . . . . . . . . . . . . 26
+ 3.5.2. Tuples . . . . . . . . . . . . . . . . . . . . . 26
+ 3.5.3. Discarding Irrelevant Tuples . . . . . . . . . . 27
+ 3.5.4. Highest Precedence and Specificity . . . . . . . 28
+ 4. Simplified Access Control. . . . . . . . . . . . . . . . . . . 28
+ 5. Security Considerations. . . . . . . . . . . . . . . . . . . . 29
+
+
+
+Legg Expires 16 December 2004 [Page 2]
+
+INTERNET-DRAFT Basic and Simplified Access Control June 16, 2004
+
+
+ 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29
+ 7. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 29
+ Appendix A. LDAP Specific Encoding for the ACI Item Syntax . . . . 30
+ Normative References . . . . . . . . . . . . . . . . . . . . . . . 39
+ Informative References . . . . . . . . . . . . . . . . . . . . . . 40
+ Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 40
+ Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 40
+
+1. Introduction
+
+ An access control scheme describes the means by which access to
+ directory information and potentially to access rights themselves may
+ be controlled. Control of access to information means the prevention
+ of unauthorized detection, disclosure, or modification of that
+ information. The definition of an access control scheme in the
+ context of a Lightweight Directory Access Protocol (LDAP) [RFC3371]
+ directory includes methods to specify Access Control Information
+ (ACI), and to enforce access rights defined by that ACI.
+
+ This document adapts the X.500 Basic Access Control and Simplied
+ Access Control schemes [X501] for use in LDAP. Both schemes conform
+ to, and make use of, the access control administrative framework for
+ LDAP [ACA].
+
+ Section 3 describes the Basic Access Control scheme and defines how
+ it applies to LDAP operations [RFC2251].
+
+ Simplified Access Control is a functional subset of the Basic Access
+ Control scheme. This subset is described in Section 4.
+
+ As a matter of security policy, an implementation supporting Basic
+ Access Control or Simplified Access Control is permitted to grant or
+ deny any form of access to particular attributes (e.g., password
+ attributes) irrespective of access controls which may otherwise
+ apply. However, since such security policy has no standardized
+ representation, it cannot be propagated in replicated information.
+
+ This document is derived from, and duplicates substantial portions
+ of, Section 8 of X.501 [X501], and selected extracts from X.511
+ [X511].
+
+2. Conventions
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in BCP 14, RFC 2119
+ [RFC2119].
+
+
+
+
+Legg Expires 16 December 2004 [Page 3]
+
+INTERNET-DRAFT Basic and Simplified Access Control June 16, 2004
+
+
+ Schema definitions are provided using LDAP description formats
+ [RFC2252]. Note that the LDAP descriptions have been rendered with
+ additional white-space and line breaks for the sake of readability.
+
+3. Basic Access Control
+
+ This section describes the functionality of the Basic Access Control
+ scheme.
+
+ When Basic Access Control is used, the accessControlScheme
+ operational attribute [ACA] SHALL have the value basic-access-control
+ (2.5.28.1).
+
+ This LDAP profile for Basic Access Control defines, for every LDAP
+ operation, one or more points at which access control decisions take
+ place. An access control decision will involve a requestor,
+ protected items, and permissions.
+
+ A requestor is the user requesting the operation. Basic Access
+ Control requires a user's authorization identity to be represented as
+ a distinguished name (with an optional unique identifier). The
+ mapping of the authentication identity to an authorization identity,
+ and the mapping of the authorization identity to a distinguished name
+ and optional unique identifier, are outside the scope of this
+ document.
+
+ A protected item is the element of directory information being
+ accessed. The protected items are entries, attributes, attribute
+ values and distinguished names. Access to each protected item can be
+ separately controlled through ACI.
+
+ A permission is a particular right necessary to complete a portion of
+ the operation.
+
+ The Access Control Information, which is used to make access control
+ decisions, associates protected items and user classes with
+ permissions. ACI is represented in the directory as values of
+ operational attributes with the ACI Item syntax [RFC2252]. Each such
+ value is referred to as an ACI item.
+
+ The scope of access controls can be a single entry or a collection of
+ entries that are logically related by being within the scope of an
+ access control subentry of an administrative point (see [ACA]).
+
+ The Access Control Decision Function (ACDF) (Section 3.5) is used to
+ decide whether a particular requestor has a particular access right
+ by virtue of applicable ACI items.
+
+
+
+
+Legg Expires 16 December 2004 [Page 4]
+
+INTERNET-DRAFT Basic and Simplified Access Control June 16, 2004
+
+
+ Access to DSEs and operational attributes is controlled in the same
+ way as for entries and user attributes.
+
+ For query purposes, collective attributes [COLLECT] that are
+ associated with an entry are protected precisely as if they were
+ attributes actually stored in that entry.
+
+ For the purposes of modification, collective attributes are
+ associated with the subentry that holds them, not with entries within
+ the scope of the subentry. Modify-related access controls are
+ therefore not relevant to collective attributes, except when they
+ apply to the collective attribute and its values within the subentry.
+
+3.1. Permissions
+
+ Access is controlled by granting or denying permissions. Access is
+ allowed only when there is an explicitly provided grant present in
+ the ACI used to make the access control decision. The only default
+ access decision provided in the model is to deny access in the
+ absence of explicit ACI that grants access. All other factors being
+ equal, a denial specified in ACI always overrides a grant.
+
+ Certain combinations of grants or denials are illogical, but it is
+ the responsibility of directory clients, rather than the directory
+ server, to ensure that such combinations are absent.
+
+ The decision whether or not to permit access to an entry or its
+ contents is strictly determined by the position of the entry in the
+ Directory Information Tree (DIT), in terms of its distinguished name,
+ and is independent of how the directory server locates that entry.
+
+ The following sections introduce the permissions by indicating the
+ intent associated with the granting of each. The actual influence of
+ a particular granted permission on access control decisions are,
+ however, determined by the ACDF and the access control decision
+ points for each LDAP operation, described in detail in Section 3.4.
+
+3.1.1. Read
+
+ If granted for an entry, Read permits the entry to be accessed using
+ LDAP Compare and baseObject Search operations, but does not imply
+ access to all the attributes and values.
+
+ If granted for an attribute type, Read permits the attribute type to
+ be returned as entry information in a Search result. Read or Browse
+ permission for the entry is a prerequisite.
+
+ If granted for an attribute value, Read permits the attribute value
+
+
+
+Legg Expires 16 December 2004 [Page 5]
+
+INTERNET-DRAFT Basic and Simplified Access Control June 16, 2004
+
+
+ to be returned as entry information in a Search result. Read or
+ Browse permission for the entry and Read permission for the attribute
+ type are prerequisites.
+
+3.1.2. Compare
+
+ If granted for an attribute type, Compare permits the attribute type
+ to be tested by the assertion in an LDAP Compare operation. Read
+ permission for the entry is a prerequisite.
+
+ If granted for an attribute value, Compare permits the value to be
+ tested by the assertion in an LDAP Compare operation. Read
+ permission for the entry and Compare permission for the attribute
+ type are prerequisites.
+
+3.1.3. Browse
+
+ If granted for an entry, Browse permits the entry to be accessed by
+ the LDAP Search operation, including baseObject searches, but does
+ not imply access to all the attributes and values.
+
+3.1.4. ReturnDN
+
+ If granted for an entry, ReturnDN allows the distinguished name of
+ the entry to be disclosed in a search result.
+
+3.1.5. FilterMatch
+
+ If granted for an attribute type, Filtermatch permits the attribute
+ type to satisfy a Filter item.
+
+ If granted for an attribute value, Filtermatch permits the attribute
+ value to satisfy a Filter item. FilterMatch permission for the
+ attribute type is a prerequisite.
+
+3.1.6. Modify
+
+ If granted for an entry, Modify permits the information contained
+ within an entry to be modified by the LDAP Modify operation, subject
+ to controls on the attribute types and values.
+
+3.1.7. Add
+
+ If granted for an entry, Add permits creation of an entry in the DIT,
+ subject to being able to add all specified attributes and attribute
+ values. Add permission granted for an entry is ineffective if Add
+ permission is not also granted for at least the mandatory attributes
+ and their values. There is no specific "add subordinate permission".
+
+
+
+Legg Expires 16 December 2004 [Page 6]
+
+INTERNET-DRAFT Basic and Simplified Access Control June 16, 2004
+
+
+ Permission to add an entry is controlled using prescriptive ACI.
+
+ If granted for an attribute type, Add permits adding a new attribute,
+ subject to being able to add all specified attribute values. Add or
+ Modify permission for the entry is a prerequisite.
+
+ If granted for an attribute value, Add permits adding that value to
+ an existing attribute. Add or Modify permission for the entry is a
+ prerequisite.
+
+3.1.8. Remove
+
+ If granted for an entry, Remove permits the entry to be removed from
+ the DIT regardless of controls on attributes or attribute values
+ within the entry.
+
+ If granted for an attribute, Remove permits removing an attribute,
+ subject to being able to remove any explicitly specified attribute
+ values. Remove permission for values not explicitly specified is not
+ required.
+
+ If granted for an attribute value, Remove permits the attribute value
+ to be removed from an existing attribute.
+
+3.1.9. DiscloseOnError
+
+ If granted for an entry, DiscloseOnError permits the name of an entry
+ to be disclosed in an error result.
+
+ If granted for an attribute, DiscloseOnError permits the presence of
+ the attribute to be disclosed by an error.
+
+ If granted for an attribute value, DiscloseOnError permits the
+ presence of the attribute value to be disclosed by an error.
+
+3.1.10. Rename
+
+ If granted for an entry, Rename permits an entry to be renamed with a
+ new RDN. No permissions are required for the attributes and values
+ altered by the operation, even if they are added or removed as a
+ result of the changes to the RDN.
+
+3.1.11. Export
+
+ If granted for an entry, Export permits the entry and its
+ subordinates, if any, to be removed from the current location and
+ placed in a new location, subject to the granting of Import
+ permission at the destination.
+
+
+
+Legg Expires 16 December 2004 [Page 7]
+
+INTERNET-DRAFT Basic and Simplified Access Control June 16, 2004
+
+
+ If the last RDN is changed, Rename permission at the current location
+ is also required
+
+3.1.12. Import
+
+ If granted for an entry, Import permits an entry and its
+ subordinates, if any, to be placed at the location to which the
+ permission applies, subject to the granting of Export permission at
+ the source location.
+
+3.1.13. Invoke
+
+ Invoke, if granted for an operational attribute, or value thereof,
+ permits the directory server to carry out some function associated
+ with the operational attribute on behalf of the user. The specific
+ function carried out by invocation depends on the attribute. No
+ other permissions are required by user for the operational attribute,
+ or on the entry/subentry that holds it, in order for it to be
+ "invoked".
+
+3.2. Representation of Access Control Information
+
+ Access Control Information is represented as a set of ACI items,
+ where each ACI item grants or denies permissions in regard to certain
+ specified users and protected items.
+
+ An ACI item is represented as a value of an operational attribute
+ with the ACI Item syntax (1.3.6.1.4.1.1466.115.121.1.1) [RFC2252].
+
+ This document updates [RFC2252] by specifying a human-readable
+ LDAP-specific encoding for ACI items. The LDAP-specific encoding of
+ values of the ACI Item syntax is defined by the Generic String
+ Encoding Rules [GSER]. Appendix A provides an equivalent ABNF for
+ this syntax.
+
+ For convenience in specifying access control policies, the ACI Item
+ syntax provides the means to identify collections of related items,
+ such as attributes in an entry or all attribute values of a given
+ attribute, and to specify a common protection for them.
+
+ The ACI Item syntax corresponds to the ACIItem ASN.1 [ASN1] type
+ defined in X.501 [X501]. It is reproduced here for convenience:
+
+ ACIItem ::= SEQUENCE {
+ identificationTag DirectoryString { ub-tag },
+ precedence Precedence,
+ authenticationLevel AuthenticationLevel,
+ itemOrUserFirst CHOICE {
+
+
+
+Legg Expires 16 December 2004 [Page 8]
+
+INTERNET-DRAFT Basic and Simplified Access Control June 16, 2004
+
+
+ itemFirst [0] SEQUENCE {
+ protectedItems ProtectedItems,
+ itemPermissions SET OF ItemPermission },
+ userFirst [1] SEQUENCE {
+ userClasses UserClasses,
+ userPermissions SET OF UserPermission } } }
+
+ Precedence ::= INTEGER (0..255)
+
+ ProtectedItems ::= SEQUENCE {
+ entry [0] NULL OPTIONAL,
+ allUserAttributeTypes [1] NULL OPTIONAL,
+ attributeType [2] SET SIZE (1..MAX) OF
+ AttributeType OPTIONAL,
+ allAttributeValues [3] SET SIZE (1..MAX) OF
+ AttributeType OPTIONAL,
+ allUserAttributeTypesAndValues [4] NULL OPTIONAL,
+ attributeValue [5] SET SIZE (1..MAX) OF
+ AttributeTypeAndValue OPTIONAL,
+ selfValue [6] SET SIZE (1..MAX) OF
+ AttributeType OPTIONAL,
+ rangeOfValues [7] Filter OPTIONAL,
+ maxValueCount [8] SET SIZE (1..MAX) OF
+ MaxValueCount OPTIONAL,
+ maxImmSub [9] INTEGER OPTIONAL,
+ restrictedBy [10] SET SIZE (1..MAX) OF
+ RestrictedValue OPTIONAL,
+ contexts [11] SET SIZE (1..MAX) OF
+ ContextAssertion OPTIONAL,
+ classes [12] Refinement OPTIONAL }
+
+ MaxValueCount ::= SEQUENCE {
+ type AttributeType,
+ maxCount INTEGER }
+
+ RestrictedValue ::= SEQUENCE {
+ type AttributeType,
+ valuesIn AttributeType }
+
+ UserClasses ::= SEQUENCE {
+ allUsers [0] NULL OPTIONAL,
+ thisEntry [1] NULL OPTIONAL,
+ name [2] SET SIZE (1..MAX) OF NameAndOptionalUID OPTIONAL,
+ userGroup [3] SET SIZE (1..MAX) OF NameAndOptionalUID OPTIONAL,
+ -- dn component shall be the name of an
+ -- entry of GroupOfUniqueNames
+ subtree [4] SET SIZE (1..MAX) OF
+ SubtreeSpecification OPTIONAL }
+
+
+
+Legg Expires 16 December 2004 [Page 9]
+
+INTERNET-DRAFT Basic and Simplified Access Control June 16, 2004
+
+
+ NameAndOptionalUID ::= SEQUENCE {
+ dn DistinguishedName,
+ uid UniqueIdentifier OPTIONAL }
+
+ UniqueIdentifier ::= BIT STRING
+
+ ItemPermission ::= SEQUENCE {
+ precedence Precedence OPTIONAL,
+ -- defaults to precedence in ACIItem
+ userClasses UserClasses,
+ grantsAndDenials GrantsAndDenials }
+
+ UserPermission ::= SEQUENCE {
+ precedence Precedence OPTIONAL,
+ -- defaults to precedence in ACIItem
+ protectedItems ProtectedItems,
+ grantsAndDenials GrantsAndDenials }
+
+ AuthenticationLevel ::= CHOICE {
+ basicLevels SEQUENCE {
+ level ENUMERATED { none(0), simple(1), strong(2) },
+ localQualifier INTEGER OPTIONAL,
+ signed BOOLEAN DEFAULT FALSE },
+ other EXTERNAL }
+
+ GrantsAndDenials ::= BIT STRING {
+ -- permissions that may be used in conjunction
+ -- with any component of ProtectedItems
+ grantAdd (0),
+ denyAdd (1),
+ grantDiscloseOnError (2),
+ denyDiscloseOnError (3),
+ grantRead (4),
+ denyRead (5),
+ grantRemove (6),
+ denyRemove (7),
+ -- permissions that may be used only in conjunction
+ -- with the entry component
+ grantBrowse (8),
+ denyBrowse (9),
+ grantExport (10),
+ denyExport (11),
+ grantImport (12),
+ denyImport (13),
+ grantModify (14),
+ denyModify (15),
+ grantRename (16),
+ denyRename (17),
+
+
+
+Legg Expires 16 December 2004 [Page 10]
+
+INTERNET-DRAFT Basic and Simplified Access Control June 16, 2004
+
+
+ grantReturnDN (18),
+ denyReturnDN (19),
+ -- permissions that may be used in conjunction
+ -- with any component, except entry, of ProtectedItems
+ grantCompare (20),
+ denyCompare (21),
+ grantFilterMatch (22),
+ denyFilterMatch (23),
+ grantInvoke (24),
+ denyInvoke (25) }
+
+ AttributeTypeAndValue ::= SEQUENCE {
+ type ATTRIBUTE.&id ({SupportedAttributes}),
+ value ATTRIBUTE.&Type ({SupportedAttributes}{@type}) }
+
+ The SubtreeSpecification and Refinement ASN.1 types are defined in
+ X.501 [X501], and separately described for LDAP [SUBENTRY].
+
+ The following sections describe the components of ACIItem.
+
+3.2.1. Identification Tag
+
+ identificationTag is used to identify a particular ACI item. This is
+ used to discriminate among individual ACI items for the purposes of
+ protection and administration.
+
+3.2.2. Precedence
+
+ Precedence is used to control the relative order in which ACI items
+ are considered during the course of making an access control decision
+ using the ACDF. ACI items having higher precedence values prevail
+ over others with lower precedence values, other factors being equal.
+ Precedence values are integers and are compared as such.
+
+3.2.3. Authentication Level
+
+ AuthenticationLevel defines the minimum requestor authentication
+ level required for this ACI item. It has two forms:
+
+ 1) basicLevels: which indicates the level of authentication,
+ optionally qualified by positive or negative integer
+ localQualifier.
+
+ 2) other: an externally defined measure.
+
+ When basicLevels is used, an AuthenticationLevel consisting of a
+ level and optional localQualifier SHALL be assigned to the requestor
+ by the directory server according to local policy. For a requestor's
+
+
+
+Legg Expires 16 December 2004 [Page 11]
+
+INTERNET-DRAFT Basic and Simplified Access Control June 16, 2004
+
+
+ authentication level to meet or exceed the minimum requirement, the
+ requestor's level must meet or exceed that specified in the ACI item,
+ and in addition the requestor's localQualifier must be arithmetically
+ greater than or equal to that of the ACI item. Strong authentication
+ of the requestor is considered to exceed a requirement for simple or
+ no authentication, and simple authentication exceeds a requirement
+ for no authentication. For access control purposes, the "simple"
+ authentication level requires at least a password; the case of
+ identification only, with no password supplied, is considered "none".
+ If a localQualifier is not specified in the ACI item, then the
+ requestor need not have a corresponding value (if such a value is
+ present it is ignored).
+
+ The signed component of basicLevels is ignored for LDAP.
+
+ When other is used, an appropriate AuthenticationLevel shall be
+ assigned to the requestor by the directory server according to local
+ policy. The form of this AuthenticationLevel and the method by which
+ it is compared with the AuthenticationLevel in the ACI is a local
+ matter.
+
+ An authentication level associated with an explicit grant indicates
+ the minimum level to which a requestor shall be authenticated in
+ order to be granted access.
+
+ An authentication level associated with an explicit deny indicates
+ the minimum level to which a requestor shall be authenticated in
+ order not to be denied access. For example, an ACI item that denies
+ access to a particular user class and requires strong authentication
+ will deny access to all requestors who cannot prove, by means of a
+ strongly authenticated identity, that they are not in that user
+ class.
+
+ The directory server may base authentication level on factors other
+ than values received in protocol exchanges.
+
+3.2.4. itemFirst and userFirst Components
+
+ Each ACI item contains a choice of itemFirst or userFirst. The
+ choice allows grouping of permissions depending on whether they are
+ most conveniently grouped by user classes or by protected items. The
+ itemFirst and userFirst components are equivalent in the sense that
+ they capture the same access control information; however, they
+ organize that information differently. The choice between them is
+ based on administrative convenience. The subcomponents of itemFirst
+ and userFirst are described below.
+
+ a) ProtectedItems defines the items to which the specified access
+
+
+
+Legg Expires 16 December 2004 [Page 12]
+
+INTERNET-DRAFT Basic and Simplified Access Control June 16, 2004
+
+
+ controls apply. It is defined as a set selected from the
+ following:
+
+ - entry means the entry contents as a whole. It does not
+ necessarily include the information in these entries. This
+ element SHALL be ignored if the classes component is present,
+ since this latter element selects protected entries on the basis
+ of their object class.
+
+ - allUserAttributeTypes means all user attribute type information
+ associated with the entry, but not values associated with those
+ attributes.
+
+ - allUserAttributeTypesAndValues means all user attribute
+ information associated with the entry, including all values of
+ all user attributes.
+
+ The allUserAttributeTypes and allUserAttributeTypesAndValues
+ components do not include operational attributes, which MUST be
+ specified on a per attribute basis, using attributeType,
+ allAttributeValues or attributeValue.
+
+ - attributeType means attribute type information pertaining to
+ specific attributes but not values associated with the type.
+
+ - allAttributeValues means all attribute value information
+ pertaining to specific attributes.
+
+ - attributeValue means specific values of specific attribute
+ types.
+
+ - selfValue means the attribute values of the specified attribute
+ types that match the distinguished name (and unique identifier)
+ of the requestor. It can only apply in the specific case where
+ the attribute specified is of DN syntax
+ (1.3.6.1.4.1.1466.115.121.1.12) or Name And Optional UID syntax
+ (1.3.6.1.4.1.1466.115.121.1.34) [RFC2252].
+
+ - rangeOfValues means any attribute value which matches the
+ specified filter, i.e., for which the specified filter evaluated
+ on that attribute value would return TRUE. The filter is not
+ evaluated on any entries in the DIB, rather it is evaluated
+ using the semantics defined in 7.8 of [X511], operating on a
+ fictitious entry that contains only the single attribute value
+ which is the protected item. Note that the filter is an X.500
+ search Filter. It has a different syntax from the LDAP search
+ Filter, but the same semantics.
+
+
+
+
+Legg Expires 16 December 2004 [Page 13]
+
+INTERNET-DRAFT Basic and Simplified Access Control June 16, 2004
+
+
+ The following items provide constraints that may disable the
+ granting of certain permissions to protected items in the same
+ value of ProtectedItems:
+
+ - maxValueCount restricts the maximum number of attribute values
+ allowed for a specified attribute type. It is examined if the
+ protected item is an attribute value of the specified type and
+ the permission sought is Add. Values of that attribute in the
+ entry are counted, without regard to attribute options and
+ access control, as though the operation which is attempting to
+ add the values is successful. If the number of values in the
+ attribute exceeds maxCount, the ACI item is treated as not
+ granting Add permission.
+
+ - maxImmSub restricts the maximum number of immediate subordinates
+ of the superior entry to an entry being added or imported. It
+ is examined if the protected item is an entry, the permission
+ sought is Add or Import, and the immediate superior entry is in
+ the same server as the entry being added or imported. Immediate
+ subordinates of the superior entry are counted, without regard
+ to access control, as though the entry addition or importing is
+ successful. If the number of subordinates exceeds maxImmSub,
+ the ACI item is treated as not granting Add or Import
+ permission.
+
+ - restrictedBy restricts values added to the attribute type to
+ being values that are already present in the same entry as
+ values of the attribute identified by the valuesIn component.
+ It is examined if the protected item is an attribute value of
+ the specified type and the permission sought is Add. Values of
+ the valuesIn attribute are checked, without regard to attribute
+ options and access control, as though the operation which adds
+ the values is successful. If the value to be added is not
+ present in valuesIn the ACI item is treated as not granting Add
+ permission.
+
+ - contexts is not used in this version of the LDAP profile for
+ Basic Access Control.
+
+ - classes means the contents of entries that have object class
+ values that satisfy the predicate defined by Refinement (see
+ [SUBENTRY]).
+
+ b) UserClasses defines a set of zero or more users the permissions
+ apply to. The set of users is selected from the following:
+
+ - allUsers means every directory user (with possible requirements
+ for AuthenticationLevel).
+
+
+
+Legg Expires 16 December 2004 [Page 14]
+
+INTERNET-DRAFT Basic and Simplified Access Control June 16, 2004
+
+
+ - thisEntry means the user with the same distinguished name as the
+ entry being accessed.
+
+ - name is the set of users with the specified distinguished names
+ (each with an optional unique identifier).
+
+ - userGroup is the set of users who are members of the groups
+ (i.e., groupOfNames or groupOfUniqueNames entries [RFC2256])
+ identified by the specified distinguished names (each with an
+ optional unique identifier). Members of a group of unique names
+ are treated as individual user distinguished names, and not as
+ the names of other groups of unique names. How group membership
+ is determined is described in 5.2.5.
+
+ - subtree is the set of users whose distinguished names fall
+ within the scope of the unrefined subtrees (specificationFilter
+ components SHOULD NOT be used - they SHALL be ignored if
+ present).
+
+ c) SubtreeSpecification is used to specify a subtree relative to the
+ root DSE, and is not constrained by administrative areas. The
+ specificationFilter component SHOULD NOT be used. It SHALL be
+ ignored if present.
+
+ A subtree refinement is not allowed because membership in a
+ subtree whose specification includes only base and/or a
+ ChopSpecification can be evaluated in isolation, whereas
+ membership in a subtree definition using specificationFilter can
+ only be evaluated by obtaining information from the user's entry,
+ which is potentially in another directory server. Basic Access
+ Control is designed to avoid remote operations in the course of
+ making an access control decision.
+
+ d) ItemPermission contains a collection of users and their
+ permissions with respect to ProtectedItems within an itemFirst
+ specification. The permissions are specified in grantsAndDenials
+ as discussed in item f). Each of the permissions specified in
+ grantsAndDenials is considered to have the precedence level
+ specified in precedence for the purpose of the ACDF. If
+ precedence is omitted within ItemPermission, then precedence is
+ taken from the precedence specified for ACIItem.
+
+ e) UserPermission contains a collection of protected items and the
+ associated permissions with respect to userClasses within a
+ userFirst specification. The associated permissions are specified
+ in grantsAndDenials as discussed in item f). Each of the
+ permissions specified in grantsAndDenials is considered to have
+ the precedence level specified in precedence for the purpose of
+
+
+
+Legg Expires 16 December 2004 [Page 15]
+
+INTERNET-DRAFT Basic and Simplified Access Control June 16, 2004
+
+
+ the ACDF. If precedence is omitted within UserPermission, the
+ precedence is taken from the precedence specified for ACIItem.
+
+ f) GrantsAndDenials specify the access rights that are granted or
+ denied by the ACI item.
+
+ g) UniqueIdentifier may be used by the authentication mechanism to
+ distinguish between instances of distinguished name reuse. If
+ this component is present, then for a requestor's name to match
+ the UserClasses of an ACIItem that grants permissions, in addition
+ to the requirement that the requestor's distinguished name match
+ the specified distinguished name, the authentication of the
+ requestor shall yield an associated unique identifier, and that
+ value shall match for equality with the specified value.
+
+3.2.5. Determining Group Membership
+
+ Determining whether a given requestor is a group member requires
+ checking two criteria. The determination may also be constrained if
+ the group definition is not known locally. The criteria for
+ membership and the treatment of non-local groups are discussed below.
+
+ a) A directory server is not required to perform a remote operation
+ to determine whether the requestor belongs to a particular group
+ for the purposes of Basic Access Control. If membership in the
+ group cannot be evaluated, the server shall assume that the
+ requestor does not belong to the group if the ACI item grants the
+ permission sought, and does belong to the group if it denies the
+ permission sought.
+
+ Access control administrators should beware of basing access
+ controls on membership of non-locally available groups or groups
+ which are available only through replication (and which may,
+ therefore, be out of date).
+
+ b) In order to determine whether the requestor is a member of a
+ userGroup user class, the following criteria apply:
+
+ - The entry named by the userGroup specification is an instance of
+ the object class groupOfNames or groupOfUniqueNames.
+
+ - The name of the requestor is a value of the member or
+ uniqueMember attribute of that entry.
+
+ Values of the member or uniqueMember attribute that do not match
+ the name of the requestor are ignored, even if they represent the
+ names of groups of which the originator could be found to be a
+ member. Hence, nested groups are not supported when evaluating
+
+
+
+Legg Expires 16 December 2004 [Page 16]
+
+INTERNET-DRAFT Basic and Simplified Access Control June 16, 2004
+
+
+ access controls.
+
+3.3. ACI Operational Attributes
+
+ ACI is stored as values of operational attributes of entries and
+ subentries. The operational attributes are multi-valued, which
+ allows ACI to be represented as a set of ACI items.
+
+3.3.1. Prescriptive ACI
+
+ The prescriptiveACI attribute is defined as an operational attribute
+ of an access control subentry. It contains prescriptive ACI
+ applicable to entries within that subentry's scope.
+
+ The LDAP description [RFC2252] for the prescriptiveACI operational
+ attribute is:
+
+ ( 2.5.24.4 NAME 'prescriptiveACI'
+ EQUALITY directoryStringFirstComponentMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.1
+ USAGE directoryOperation )
+
+ The directoryStringFirstComponentMatch matching rule is described in
+ [SCHEMA].
+
+ Prescriptive ACI within the subentries of a particular administrative
+ point never applies to the same or any other subentry of that
+ administrative point, but can be applicable to the subentries of
+ subordinate administrative points.
+
+ Note that prescriptiveACI attributes are not collective attributes.
+ Although the values of a prescriptiveACI attribute contribute to
+ access control decisions for each entry within the scope of the
+ subentry that holds the attribute, the prescriptiveACI attribute does
+ not appear as part of those entries.
+
+3.3.2. Entry ACI
+
+ The entryACI attribute is defined as an operational attribute of an
+ entry or subentry (not just access control subentries). It contains
+ entry ACI applicable to the entry or subentry in which it appears,
+ and that (sub)entry's contents.
+
+ The LDAP description [RFC2252] for the entryACI operational attribute
+ is:
+
+ ( 2.5.24.5 NAME 'entryACI'
+ EQUALITY directoryStringFirstComponentMatch
+
+
+
+Legg Expires 16 December 2004 [Page 17]
+
+INTERNET-DRAFT Basic and Simplified Access Control June 16, 2004
+
+
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.1
+ USAGE directoryOperation )
+
+3.3.3. Subentry ACI
+
+ The subentryACI attribute is defined as an operational attribute of
+ administrative entries [ADMIN] (for any aspect of administration).
+ It contains subentry ACI that applies to each of the subentries of
+ the administrative entry in which it appears. Only administrative
+ entries are permitted to contain a subentryACI attribute.
+
+ The LDAP description [RFC2252] for the subentryACI operational
+ attribute is:
+
+ ( 2.5.24.6 NAME 'subentryACI'
+ EQUALITY directoryStringFirstComponentMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.1
+ USAGE directoryOperation )
+
+3.3.4. Protecting the ACI
+
+ ACI operational attributes are subject to the same protection
+ mechanisms as other attributes.
+
+ The identificationTag provides an identifier for each ACI item. This
+ tag can be used to remove a specific ACI item value, or to protect it
+ by prescriptive ACI, entry ACI or subentry ACI. Directory rules
+ ensure that only one ACI item per access control operational
+ attribute possesses any specific identificationTag value.
+
+ The creation of subentries for an administrative entry may be
+ controlled by means of the subentryACI operational attribute in the
+ administrative entry. The right to create prescriptive access
+ controls may also be governed directly by security policy; this
+ provision is required to create access controls in new autonomous
+ administrative areas [ADMIN].
+
+3.4. Access Control Decision Points for LDAP Operations
+
+ Each LDAP operation involves making a series of access control
+ decisions on the various protected items that the operation accesses.
+
+ For some operations (e.g., the Modify operation), each such access
+ control decision must grant access for the operation to succeed; if
+ access is denied to any protected item, the whole operation fails.
+ For other operations (e.g., the Search operation), protected items to
+ which access is denied are simply omitted from the operation result
+ and processing continues.
+
+
+
+Legg Expires 16 December 2004 [Page 18]
+
+INTERNET-DRAFT Basic and Simplified Access Control June 16, 2004
+
+
+ If the requested access is denied, further access control decisions
+ may be needed to determine if the user has DiscloseOnError
+ permissions to the protected item. Only if DiscloseOnError
+ permission is granted may the server respond with an error that
+ reveals the existence of the protected item. In all other cases, the
+ server MUST act so as to conceal the existence of the protected item.
+
+ The permissions required to access each protected item, are specified
+ for each operation in the following sections. The algorithm by which
+ a permission is determined to be granted or not granted is specified
+ in Section 3.5.
+
+3.4.1. Common Elements of Procedure
+
+ This section defines the elements of procedure that are common to all
+ LDAP operations when Basic Access Control is in effect.
+
+3.4.1.1. Alias Dereferencing
+
+ If, in the process of locating a target object entry (nominated in an
+ LDAP request), alias dereferencing is required, no specific
+ permissions are necessary for alias dereferencing to take place.
+ However, if alias dereferencing would result in a referral being
+ returned, the following sequence of access controls applies.
+
+ 1) Read permission is required to the alias entry. If permission is
+ not granted, the operation fails in accordance to the procedure
+ described in 5.4.1.3.
+
+ 2) Read permission is required to the aliasedEntryName attribute and
+ to the single value that it contains. If permission is not
+ granted, the operation fails and the resultCode
+ aliasDereferencingProblem SHALL be returned. The matchedDN field
+ of the LDAPResult SHALL contain the name of the alias entry.
+
+ In addition to the access controls described above, security policy
+ may prevent the disclosure of knowledge of other servers which would
+ otherwise be conveyed in a referral. If such a policy is in effect
+ the resultCode insufficientAccessRights SHALL be returned.
+
+3.4.1.2. Return of Names in Errors
+
+ Certain LDAP result codes, i.e., noSuchObject, aliasProblem,
+ invalidDNSyntax and aliasDereferencingProblem, provide the name of an
+ entry in the matchedDN field of an LDAPResult. The DN of an entry
+ SHALL only be provided in the matchedDN field if DiscloseOnError
+ permission is granted to that entry, otherwise, the matchedDN field
+ of the LDAPResult SHALL either contain the name of the next superior
+
+
+
+Legg Expires 16 December 2004 [Page 19]
+
+INTERNET-DRAFT Basic and Simplified Access Control June 16, 2004
+
+
+ entry to which DiscloseOnError permission is granted, or, if
+ DiscloseOnError permission is not granted to any superior entry, the
+ name of the root DSE (i.e., a zero-length LDAPDN).
+
+3.4.1.3. Non-disclosure of Entry Existence
+
+ If, while performing an LDAP operation, the necessary entry level
+ permission is not granted to the specified target object entry -
+ e.g., the entry to be modified - the operation fails; if
+ DiscloseOnError permission is granted to the target entry, the
+ resultCode insufficientAccessRights SHALL be returned, otherwise, the
+ resultCode noSuchObject SHALL be returned. The matchedDN field of
+ the LDAPResult SHALL either contain the name of the next superior
+ entry to which DiscloseOnError permission is granted, or, if
+ DiscloseOnError permission is not granted to any superior entry, the
+ name of the root DSE (i.e., a zero-length LDAPDN).
+
+ Additionally, whenever the server detects an operational error
+ (including a referral resultCode), it shall ensure that in returning
+ that error it does not compromise the existence of the named target
+ entry and any of its superiors. For example, before returning a
+ resultCode of timeLimitExceeded or notAllowedOnNonLeaf, the server
+ verifies that DiscloseOnError permission is granted to the target
+ entry. If it is not, the procedure described in the paragraph above
+ SHALL be followed.
+
+3.4.2. Compare Operation Decision Points
+
+ The following sequence of access controls applies for an entry being
+ compared.
+
+ 1) Read permission for the entry to be compared is required. If
+ permission is not granted, the operation fails in accordance with
+ 5.4.1.3.
+
+ 2) Compare permission for the attribute to be compared is required.
+ If permission is not granted, the operation fails: if
+ DiscloseOnError permission is granted to the attribute being
+ compared, a resultCode of insufficientAccessRight SHALL be
+ returned, otherwise, the resultCode noSuchAttribute SHALL be
+ returned.
+
+ 3) If there exists a value within the attribute being compared that
+ matches the purported argument and for which Compare permission is
+ granted, the operation returns the resultCode compareTrue,
+ otherwise the operation returns the resultCode compareFalse.
+
+3.4.3. Search Operation Decision Points
+
+
+
+Legg Expires 16 December 2004 [Page 20]
+
+INTERNET-DRAFT Basic and Simplified Access Control June 16, 2004
+
+
+ The following sequence of access controls applies for a portion of
+ the DIT being searched.
+
+ 1) No specific permission is required to the entry identified by the
+ baseObject argument in order to initiate a search. However, if
+ the baseObject is within the scope of the SearchArgument (i.e.,
+ when the subset argument specifies baseObject or wholeSubtree) the
+ access controls specified in 2) through 5) will apply.
+
+ 2) Browse or Read permission is required for the single entry within
+ the scope of a baseObject search. An entry for which neither of
+ these permissions is granted is ignored.
+
+ This differs from the X.500 DAP Search operation where the Browse
+ permission alone is required. An entry with Read permission but
+ not Browse permission cannot be searched but can still be examined
+ with an X.500 DAP Read operation. LDAP relies on baseObject
+ search operations to provide the functionality of the DAP Read
+ operation. Accepting Read permission for the target entry in a
+ baseObject search gives an LDAP baseObject search the same access
+ rights to the entry as the DAP Read operation.
+
+ 3) Browse permission is required for an entry within the scope of a
+ singleLevel or wholeSubtree search to be a candidate for
+ consideration. Entries for which this permission is not granted
+ are ignored.
+
+ 4) The filter argument is applied to each entry left to be considered
+ after taking 2) and 3) into account, in accordance with the
+ following:
+
+ a) For a present Filter item, if there exists an attribute value
+ such that the attribute type of the value (possibly a subtype
+ of the attribute type in the FilterItem) satisfies the Filter
+ item and FilterMatch permission is granted for the value and
+ for the attribute type then the FilterItem evaluates to TRUE,
+ otherwise, it evaluates to FALSE.
+
+ If a directory server does not support True/False filters
+ [FILTER] on LDAP searches, or if directory clients do not
+ exploit this capability, then access control administrators
+ SHOULD grant FilterMatch permission for the objectClass
+ attribute over entries where Read permission is also granted so
+ that an LDAP baseObject search with a filter testing for the
+ presence of the objectClass attribute will have the same access
+ rights to the target entry as the DAP Read operation. An LDAP
+ baseObject search with a True filter does not require
+ FilterMatch permission for any particular attribute type.
+
+
+
+Legg Expires 16 December 2004 [Page 21]
+
+INTERNET-DRAFT Basic and Simplified Access Control June 16, 2004
+
+
+ b) For an equalityMatch, substrings, greaterOrEqual, lessOrEqual,
+ approxMatch or extensibleMatch Filter item, if there exists an
+ attribute value such that the value satisfies the Filter item
+ and FilterMatch permission is granted for the value and for its
+ attribute type (possibly a subtype of the attribute type in the
+ FilterItem) then the FilterItem evaluates to TRUE, otherwise,
+ it evaluates to FALSE.
+
+ Once the access controls defined in 2) through 4) have been applied,
+ an entry is either selected or discarded.
+
+ 5) For each selected entry the information returned is as follows:
+
+ a) ReturnDN permission for an entry is required in order to return
+ its distinguished name in a SearchResultEntry response. If
+ this permission is not granted, the server SHALL either, return
+ the name of a valid alias to the entry, or, omit the entry from
+ the search result.
+
+ If the base entry of the search was located using an alias,
+ then that alias is known to be a valid alias. Otherwise, how
+ it is ensured that the alias is valid is outside the scope of
+ this specification.
+
+ Where a server has a choice of alias names available to it for
+ return, it is RECOMMENDED that where possible it choose the
+ same alias name for repeated requests by the same client, in
+ order to provide a consistent service.
+
+ b) If the typesOnly field of the SearchRequest is TRUE then, for
+ each attribute type that is to be returned, Read permission for
+ the attribute type and Read permission for at least one value
+ of the attribute is required. If permission is not granted,
+ the attribute type is omitted from the attribute list in the
+ SearchResultEntry. If as a consequence of applying these
+ controls no attribute type information is selected, the
+ SearchResultEntry is returned but no attribute type information
+ is conveyed with it (i.e., the attribute list is empty).
+
+ c) If the typesOnly field of the SearchRequest is FALSE then Read
+ permission is required for each attribute type and for each
+ attribute value that is to be returned. If permission to an
+ attribute type is not granted, the attribute is omitted from
+ the SearchResultEntry. If permission to an attribute value is
+ not granted, the value is omitted from its corresponding
+ attribute. If all values of an attribute are omitted then the
+ attribute type is omitted from the attribute list in the
+ SearchResultEntry. If as a consequence of applying these
+
+
+
+Legg Expires 16 December 2004 [Page 22]
+
+INTERNET-DRAFT Basic and Simplified Access Control June 16, 2004
+
+
+ controls no attribute information is selected, the
+ SearchResultEntry is returned but no attribute information is
+ conveyed with it (i.e., the attribute list is empty).
+
+ 6) If as a consequence of applying the above controls to the entire
+ scoped subtree the search result contains no entries (excluding
+ any SearchResultReferences) and if DiscloseOnError permission is
+ not granted to the entry identified by the baseObject argument,
+ the operation fails and the resultCode noSuchObject SHALL be
+ returned. The matchedDN field of the LDAPResult SHALL either
+ contain the name of the next superior entry to which
+ DiscloseOnError permission is granted, or the name of the root DSE
+ (i.e., a zero-length LDAPDN). Otherwise, the operation succeeds
+ but no subordinate information is conveyed with it.
+
+ Security policy may prevent the disclosure of knowledge of other
+ servers which would otherwise be conveyed as SearchResultReferences.
+ If such a policy is in effect SearchResultReferences are omitted from
+ the search result.
+
+ No specific permissions are necessary to allow alias dereferencing to
+ take place in the course of a search operation. However, for each
+ alias entry encountered, if alias dereferencing would result in a
+ SearchResultReference being returned, the following access controls
+ apply: Read permission is required to the alias entry, the
+ aliasedEntryName attribute and to the single value that it contains.
+ If any of these permissions is not granted, the SearchResultReference
+ SHALL be omitted from the search result.
+
+3.4.4. Add Operation Decision Points
+
+ The following sequence of access controls apply for an entry being
+ added.
+
+ 1) No specific permission is required for the immediate superior of
+ the entry identified by the entry field of the AddRequest.
+
+ 2) If an entry already exists with a distinguished name equal to the
+ entry field the operation fails; if DiscloseOnError or Add
+ permission is granted to the existing entry, the resultCode
+ entryAlreadyExists SHALL be returned, otherwise, the procedure
+ described in 5.4.1.3 is followed with respect to the entry being
+ added.
+
+ 3) Add permission is required for the new entry being added. If this
+ permission is not granted, the operation fails; the procedure
+ described in 5.4.1.3 is followed with respect to the entry being
+ added.
+
+
+
+Legg Expires 16 December 2004 [Page 23]
+
+INTERNET-DRAFT Basic and Simplified Access Control June 16, 2004
+
+
+ The Add permission is provided as prescriptive ACI when attempting
+ to add an entry and as prescriptive ACI or subentry ACI when
+ attempting to add a subentry. Any values of the entryACI
+ attribute in the entry being added SHALL be ignored.
+
+ 4) Add permission is required for each attribute type and for each
+ value that is to be added. If any permission is absent, the
+ operation fails and the resultCode insufficientAccessRights SHALL
+ be returned.
+
+3.4.5. Delete Operation Decision Points
+
+ The following sequence of access controls apply for an entry being
+ removed.
+
+ 1) Remove permission is required for the entry being removed. If
+ this permission is not granted, the operation fails in accordance
+ with 5.4.1.3.
+
+ 2) No specific permissions are required for any of the attributes and
+ attribute values present within the entry being removed.
+
+3.4.6. Modify Operation Decision Points
+
+ The following sequence of access controls apply for an entry being
+ modified.
+
+ 1) Modify permission is required for the entry being modified. If
+ this permission is not granted, the operation fails in accordance
+ with 5.4.1.3.
+
+ 2) For each of the specified modification arguments applied in
+ sequence, the following permissions are required:
+
+ a) Add permission is required for each of the attribute values
+ specified in an add modification. If the attribute does not
+ currently exist then Add permission for the attribute type is
+ also required. If these permissions are not granted, or any of
+ the attribute values already exist, the operation fails; if an
+ attribute value already exists and DiscloseOnError or Add is
+ granted to that attribute value, the resultCode
+ attributeOrValueExists SHALL be returned, otherwise, the
+ resultCode insufficientAccessRights SHALL be returned.
+
+ b) Remove permission is required for the attribute type specified
+ in a delete modification with no listed attribute values. If
+ this permission is not granted, the operation fails; if
+ DiscloseOnError permission is granted to the attribute being
+
+
+
+Legg Expires 16 December 2004 [Page 24]
+
+INTERNET-DRAFT Basic and Simplified Access Control June 16, 2004
+
+
+ removed and the attribute exists, the resultCode
+ insufficientAccessRights SHALL be returned, otherwise, the
+ resultCode noSuchAttribute SHALL be returned.
+
+ No specific permissions are required for any of the attribute
+ values present within the attribute being removed.
+
+ c) Remove permission is required for each of the values in a
+ delete modification with listed attribute values. If all
+ current values of the attribute are specified to be removed
+ (which causes the attribute itself to be removed), then Remove
+ permission for the attribute type is also required. If these
+ permissions are not granted, the operation fails; if
+ DiscloseOnError permission is granted to any of the attribute
+ values being removed, the resultCode insufficientAccessRights
+ SHALL be returned, otherwise, the resultCode noSuchAttribute
+ SHALL be returned.
+
+ d) Remove and Add permission is required for the attribute type,
+ and Add permission is required for each of the specified
+ attribute values, in a replace modification. If these
+ permissions are not granted the operation fails and the
+ resultCode insufficientAccessRights SHALL be returned.
+
+ No specific permissions are required to remove any existing
+ attribute values of the attribute being replaced.
+
+3.4.7. Modify DN Operation Decision Points
+
+ The following sequence of access controls apply for an entry having
+ its DN modified.
+
+ 1) If the effect of the operation is to change the RDN of the entry
+ then Rename permission (determined with respect to its original
+ name) is required for the entry. If this permission is not
+ granted, the operation fails; the procedure described in 5.4.1.3
+ is followed with respect to the entry being renamed (considered
+ with its original name).
+
+ No additional permissions are required even if, as a result of
+ modifying the RDN of the entry, a new distinguished value needs to
+ be added, or an old one removed. No specific permissions are
+ required for the subordinates of the renamed entry.
+
+ 2) If the effect of the operation is to move an entry to a new
+ superior in the DIT then Export permission (determined with
+ respect to its original name) and Import permission (determined
+ with respect to its new name) are required for the entry. If
+
+
+
+Legg Expires 16 December 2004 [Page 25]
+
+INTERNET-DRAFT Basic and Simplified Access Control June 16, 2004
+
+
+ either of these permissions is not granted, the operation fails;
+ the procedure described in 5.4.1.3 is followed with respect to the
+ entry being moved (considered with its original name).
+
+ The Import permission is provided as prescriptive ACI when
+ attempting to move an entry and as prescriptive ACI or subentry
+ ACI when attempting to move a subentry. Any values of the
+ entryACI attribute in the entry or subentry being moved SHALL be
+ ignored.
+
+ No specific permissions are required for the subordinates of the
+ moved entry.
+
+ Note that a single Modify DN Operation may simultaneously rename and
+ move an entry.
+
+3.5. Access Control Decision Function
+
+ This section describes how ACI items are processed in order to decide
+ whether to grant or deny a particular requestor a specified
+ permission to a given protected item.
+
+ Section 3.5.1 describes the inputs to the ACDF. Sections 3.5.2
+ through 3.5.4 describe the steps in the ACDF. The output is a
+ decision to grant or deny access to the protected item.
+
+3.5.1. Inputs
+
+ For each invocation of the ACDF, the inputs are:
+
+ a) the requestor's Distinguished Name, unique identifier, and
+ authentication level, or as many of these as are available;
+
+ b) the protected item (an entry, an attribute, or an attribute value)
+ being considered at the current decision point for which the ACDF
+ was invoked;
+
+ c) the requested permission specified for the current decision point;
+
+ d) the ACI items applicable to the entry containing (or which is) the
+ protected item.
+
+ In addition, if the ACI items include any of the protected item
+ constraints described in 5.2.1.4, the whole entry and the number of
+ immediate subordinates of its superior entry may also be required as
+ inputs.
+
+3.5.2. Tuples
+
+
+
+Legg Expires 16 December 2004 [Page 26]
+
+INTERNET-DRAFT Basic and Simplified Access Control June 16, 2004
+
+
+ For each ACI item, expand the item into a set of tuples, one tuple
+ for each element of the itemPermissions and userPermissions sets,
+ containing the following elements:
+
+ ( userClasses, authenticationLevel, protectedItems,
+ grantsAndDenials, precedence )
+
+ Collect all tuples from all ACI items into a single set.
+
+ For any tuple whose grantsAndDenials specify both grants and denials,
+ replace the tuple with two tuples - one specifying only grants and
+ the other specifying only denials.
+
+3.5.3. Discarding Irrelevant Tuples
+
+ Perform the following steps to discard all irrelevant tuples:
+
+ 1) Discard all tuples that do not include the requestor in the
+ tuple's userClasses as follows:
+
+ a) For tuples that grant access, discard all tuples that do not
+ include the requestor's identity in the tuples's userClasses
+ element, taking into account UniqueIdentifier elements if
+ relevant. Where a tuple's userClasses specifies a
+ UniqueIdentifier, a matching value shall be present in the
+ requestor's identity if the tuple is not to be discarded.
+ Discard tuples that specify an authentication level higher than
+ that associated with the requestor.
+
+ b) For tuples that deny access, retain all tuples that include the
+ requestor in the tuple's userClasses element, taking into
+ account uniqueIdentifier elements if relevant. Also retain all
+ tuples that deny access and which specify an authentication
+ level higher than that associated with the requestor. This
+ reflects the fact that the requestor has not adequately proved
+ non-membership in the user class for which the denial is
+ specified. All other tuples that deny access are discarded.
+
+ 2) Discard all tuples that do not include the protected item in
+ protectedItems.
+
+ 3) Examine all tuples that include maxValueCount, maxImmSub or
+ restrictedBy. Discard all such tuples which grant access and
+ which do not satisfy any of these constraints.
+
+ 4) Discard all tuples that do not include the requested permission as
+ one of the set bits in grantsAndDenials.
+
+
+
+
+Legg Expires 16 December 2004 [Page 27]
+
+INTERNET-DRAFT Basic and Simplified Access Control June 16, 2004
+
+
+ The order in which tuples are discarded does not change the output of
+ the ACDF.
+
+3.5.4. Highest Precedence and Specificity
+
+ Perform the following steps to select those tuples of highest
+ precedence and specificity:
+
+ 1) Discard all tuples having a precedence less than the highest
+ precedence among the remaining tuples.
+
+ 2) If more than one tuple remains, choose the tuples with the most
+ specific user class. If there are any tuples matching the
+ requestor with UserClasses element name or thisEntry, discard all
+ other tuples. Otherwise if there are any tuples matching
+ UserGroup, discard all other tuples. Otherwise if there are any
+ tuples matching subtree, discard all other tuples.
+
+ 3) If more than one tuple remains, choose the tuples with the most
+ specific protected item. If the protected item is an attribute
+ and there are tuples that specify the attribute type explicitly,
+ discard all other tuples. If the protected item is an attribute
+ value, and there are tuples that specify the attribute value
+ explicitly, discard all other tuples. A protected item which is a
+ rangeOfValues is to be treated as specifying an attribute value
+ explicitly.
+
+ Grant access if and only if one or more tuples remain and all grant
+ access. Otherwise deny access.
+
+4. Simplified Access Control
+
+ This section describes the functionality of the Simplified Access
+ Control scheme. It provides a subset of the functionality found in
+ Basic Access Control.
+
+ When Simplified Access Control is used, the accessControlScheme
+ operational attribute [ACA] SHALL have the value
+ simplified-access-control (2.5.28.2).
+
+ The functionality of Simplified Access Control is the same as Basic
+ Access Control except that:
+
+ 1) Access control decisions shall be made only on the basis of values
+ of prescriptiveACI and subentryACI operational attributes. Values
+ of the entryACI attribute, if present, SHALL NOT be used to make
+ access control decisions.
+
+
+
+
+Legg Expires 16 December 2004 [Page 28]
+
+INTERNET-DRAFT Basic and Simplified Access Control June 16, 2004
+
+
+ 2) Access Control Inner Areas are not used. Values of
+ prescriptiveACI attributes appearing in subentries of ACIPs SHALL
+ NOT be used to make access control decisions.
+
+ All other provisions SHALL be as defined for Basic Access Control.
+
+5. Security Considerations
+
+ Access control administrators should beware of basing access controls
+ on membership of non-locally available groups or groups which are
+ available only through replication (and which may, therefore, be out
+ of date).
+
+ A particular DSA might not have the ACI governing any data that it
+ caches. Administrators should be aware that a directory server with
+ the capability of caching may pose a significant security risk to
+ other directory servers, in that it may reveal information to
+ unauthorized users.
+
+6. Acknowledgements
+
+ This document is derived from, and duplicates substantial portions
+ of, Section 8 of X.501 [X501], and selected extracts from X.511
+ [X511].
+
+7. IANA Considerations
+
+ The Internet Assigned Numbers Authority (IANA) is requested to update
+ the LDAP descriptors registry [BCP64] as indicated by the following
+ templates:
+
+ Subject: Request for LDAP Descriptor Registration
+ Descriptor (short name): basic-access-control
+ Object Identifier: 2.5.28.1
+ Person & email address to contact for further information:
+ Steven Legg <steven.legg at adacel.com.au>
+ Usage: other (access control scheme)
+ Specification: RFC XXXX
+ Author/Change Controller: IESG
+
+ Subject: Request for LDAP Descriptor Registration
+ Descriptor (short name): simplified-access-control
+ Object Identifier: 2.5.28.2
+ Person & email address to contact for further information:
+ Steven Legg <steven.legg at adacel.com.au>
+ Usage: other (access control scheme)
+ Specification: RFC XXXX
+ Author/Change Controller: IESG
+
+
+
+Legg Expires 16 December 2004 [Page 29]
+
+INTERNET-DRAFT Basic and Simplified Access Control June 16, 2004
+
+
+ Subject: Request for LDAP Descriptor Registration
+ Descriptor (short name): prescriptiveACI
+ Object Identifier: 2.5.24.4
+ Person & email address to contact for further information:
+ Steven Legg <steven.legg at adacel.com.au>
+ Usage: attribute type
+ Specification: RFC XXXX
+ Author/Change Controller: IESG
+
+ Subject: Request for LDAP Descriptor Registration
+ Descriptor (short name): entryACI
+ Object Identifier: 2.5.24.5
+ Person & email address to contact for further information:
+ Steven Legg <steven.legg at adacel.com.au>
+ Usage: attribute type
+ Specification: RFC XXXX
+ Author/Change Controller: IESG
+
+ Subject: Request for LDAP Descriptor Registration
+ Descriptor (short name): subentryACI
+ Object Identifier: 2.5.24.6
+ Person & email address to contact for further information:
+ Steven Legg <steven.legg at adacel.com.au>
+ Usage: attribute type
+ Specification: RFC XXXX
+ Author/Change Controller: IESG
+
+Appendix A. LDAP Specific Encoding for the ACI Item Syntax
+
+ This appendix is non-normative.
+
+ The LDAP-specific encoding for the ACI Item syntax is specified by
+ the Generic String Encoding Rules [GSER]. The ABNF [RFC2234] in this
+ appendix for this syntax is provided only as a convenience and is
+ equivalent to the encoding specified by the application of GSER.
+ Since the ACI Item ASN.1 type may be extended in future editions of
+ X.501 [X501], the provided ABNF should be regarded as a snapshot in
+ time. The LDAP-specific encoding for any extension to the ACI Item
+ ASN.1 type can be determined from the rules of GSER.
+
+ In the event that there is a discrepancy between this ABNF and the
+ encoding determined by GSER, then GSER is to be taken as definitive.
+
+ ACIItem = "{" sp aci-identificationTag ","
+ sp aci-precedence ","
+ sp aci-authenticationLevel ","
+ sp aci-itemOrUserFirst
+ sp "}"
+
+
+
+Legg Expires 16 December 2004 [Page 30]
+
+INTERNET-DRAFT Basic and Simplified Access Control June 16, 2004
+
+
+ aci-identificationTag = id-identificationTag msp
+ DirectoryString
+ aci-precedence = id-precedence msp Precedence
+ aci-authenticationLevel = id-authenticationLevel msp
+ AuthenticationLevel
+ aci-itemOrUserFirst = id-itemOrUserFirst msp
+ ItemOrUserFirst
+ id-identificationTag = %x69.64.65.6E.74.69.66.69.63.61.74.69.6F
+ %x6E.54.61.67 ; "identificationTag"
+ id-precedence = %x70.72.65.63.65.64.65.6E.63.65
+ ; "precedence"
+ id-authenticationLevel = %x61.75.74.68.65.6E.74.69.63.61.74.69.6F
+ %x6E.4C.65.76.65.6C
+ ; "authenticationLevel"
+ id-itemOrUserFirst = %x69.74.65.6D.4F.72.55.73.65.72.46.69.72
+ %x73.74 ; "itemOrUserFirst"
+
+ Precedence = INTEGER-0-MAX ; MUST be less than 256
+
+ AuthenticationLevel = al-basicLevels / al-other
+ al-basicLevels = id-basicLevels ":" BasicLevels
+ al-other = id-other ":" EXTERNAL
+ id-basicLevels = %x62.61.73.69.63.4C.65.76.65.6C.73
+ ; "basicLevels"
+ id-other = %x6F.74.68.65.72 ; "other"
+
+ BasicLevels = "{" sp bl-level
+ [ "," sp bl-localQualifier ]
+ [ "," sp bl-signed ]
+ sp "}"
+
+ bl-level = id-level msp Level
+ bl-localQualifier = id-localQualifier msp INTEGER
+ bl-signed = id-signed msp BOOLEAN
+ Level = id-none / id-simple / id-strong
+ id-level = %x6C.65.76.65.6C ; "level"
+ id-localQualifier = %x6C.6F.63.61.6C.51.75.61.6C.69.66.69.65.72
+ ; "localQualifier"
+ id-signed = %x73.69.67.6E.65.64 ; "signed"
+ id-none = %x6E.6F.6E.65 ; "none"
+ id-simple = %x73.69.6D.70.6C.65 ; "simple"
+ id-strong = %x73.74.72.6F.6E.67 ; "strong"
+
+ ItemOrUserFirst = ( id-itemFirst ":" ItemFirst ) /
+ ( id-userFirst ":" UserFirst )
+ id-itemFirst = %x69.74.65.6D.46.69.72.73.74 ; "itemFirst"
+ id-userFirst = %x75.73.65.72.46.69.72.73.74 ; "userFirst"
+
+
+
+
+Legg Expires 16 December 2004 [Page 31]
+
+INTERNET-DRAFT Basic and Simplified Access Control June 16, 2004
+
+
+ ItemFirst = "{" sp if-protectedItems ","
+ sp if-itemPermissions
+ sp "}"
+ if-protectedItems = id-protectedItems msp ProtectedItems
+ if-itemPermissions = id-itemPermissions msp ItemPermissions
+ id-protectedItems = %x70.72.6F.74.65.63.74.65.64.49.74.65.6D.73
+ ; "protectedItems"
+ id-itemPermissions = %x69.74.65.6D.50.65.72.6D.69.73.73.69.6F.6E
+ %x73 ; "itemPermissions"
+
+ UserFirst = "{" sp uf-userClasses ","
+ sp uf-userPermissions
+ sp "}"
+ uf-userClasses = id-userClasses msp UserClasses
+ uf-userPermissions = id-userPermissions msp UserPermissions
+ id-userClasses = %x75.73.65.72.43.6C.61.73.73.65.73
+ ; "userClasses"
+ id-userPermissions = %x75.73.65.72.50.65.72.6D.69.73.73.69.6F.6E
+ %x73 ; "userPermissions"
+
+ ItemPermissions = "{" [ sp ItemPermission
+ *( "," sp ItemPermission ) ] sp "}"
+ ItemPermission = "{" [ sp ip-precedence "," ]
+ sp ip-userClasses ","
+ sp ip-grantsAndDenials
+ sp "}"
+ ip-precedence = id-precedence msp Precedence
+ ip-userClasses = id-userClasses msp UserClasses
+ ip-grantsAndDenials = id-grantsAndDenials msp GrantsAndDenials
+ id-grantsAndDenials = %x67.72.61.6E.74.73.41.6E.64.44.65.6E.69.61
+ %x6C.73 ; "grantsAndDenials"
+
+ UserClasses = "{" [ sp uc-allUsers ]
+ [ sep sp uc-thisEntry ]
+ [ sep sp uc-name ]
+ [ sep sp uc-userGroup ]
+ [ sep sp uc-subtree ]
+ sp "}"
+ uc-allUsers = id-allUsers msp NULL
+ uc-thisEntry = id-thisEntry msp NULL
+ uc-name = id-name msp NameAndOptionalUIDs
+ uc-userGroup = id-userGroup msp NameAndOptionalUIDs
+ uc-subtree = id-subtree msp SubtreeSpecifications
+ id-allUsers = %x61.6C.6C.55.73.65.72.73 ; "allUsers"
+ id-thisEntry = %x74.68.69.73.45.6E.74.72.79 ; "thisEntry"
+ id-name = %x6E.61.6D.65 ; "name"
+ id-userGroup = %x75.73.65.72.47.72.6F.75.70 ; "userGroup"
+ id-subtree = %x73.75.62.74.72.65.65 ; "subtree"
+
+
+
+Legg Expires 16 December 2004 [Page 32]
+
+INTERNET-DRAFT Basic and Simplified Access Control June 16, 2004
+
+
+ NameAndOptionalUIDs = "{" sp NameAndOptionalUID
+ *( "," sp NameAndOptionalUID ) sp "}"
+ NameAndOptionalUID = "{" sp nu-dn
+ [ "," sp nu-uid ]
+ sp "}"
+ nu-dn = id-dn msp DistinguishedName
+ nu-uid = id-uid msp UniqueIdentifier
+ UniqueIdentifier = BIT-STRING
+ id-dn = %x64.6E ; "dn"
+ id-uid = %x75.69.64 ; "uid"
+
+ SubtreeSpecifications = "{" sp SubtreeSpecification
+ *( "," sp SubtreeSpecification ) sp "}"
+
+ UserPermissions = "{" [ sp UserPermission
+ *( "," sp UserPermission ) ] sp "}"
+ UserPermission = "{" [ sp up-precedence "," ]
+ sp up-protectedItems ","
+ sp up-grantsAndDenials
+ sp "}"
+ up-precedence = id-precedence msp Precedence
+ up-protectedItems = id-protectedItems msp ProtectedItems
+ up-grantsAndDenials = id-grantsAndDenials msp GrantsAndDenials
+
+ ProtectedItems = "{" [ sp pi-entry ]
+ [ sep sp pi-allUserAttributeTypes ]
+ [ sep sp pi-attributeType ]
+ [ sep sp pi-allAttributeValues ]
+ [ sep sp pi-allUserTypesAndValues ]
+ [ sep sp pi-attributeValue ]
+ [ sep sp pi-selfValue ]
+ [ sep sp pi-rangeOfValues ]
+ [ sep sp pi-maxValueCount ]
+ [ sep sp pi-maxImmSub ]
+ [ sep sp pi-restrictedBy ]
+ ; contexts omitted
+ [ sep sp pi-classes ]
+ sp "}"
+
+ pi-entry = id-entry msp NULL
+ pi-allUserAttributeTypes = id-allUserAttributeTypes msp NULL
+ pi-attributeType = id-attributeType msp AttributeTypes
+ pi-allAttributeValues = id-allAttributeValues msp
+ AttributeTypes
+ pi-allUserTypesAndValues = id-allUserAttributeTypesAndValues msp
+ NULL
+ pi-attributeValue = id-attributeValue msp
+ AttributeTypeAndValues
+
+
+
+Legg Expires 16 December 2004 [Page 33]
+
+INTERNET-DRAFT Basic and Simplified Access Control June 16, 2004
+
+
+ pi-selfValue = id-selfValue msp AttributeTypes
+ pi-rangeOfValues = id-rangeOfValues msp Filter
+ pi-maxValueCount = id-maxValueCount msp MaxValueCounts
+ pi-maxImmSub = id-maxImmSub msp INTEGER
+ pi-restrictedBy = id-restrictedBy msp RestrictedValues
+ pi-classes = id-classes msp Refinement
+ id-entry = %x65.6E.74.72.79 ; "entry"
+ id-allUserAttributeTypes = %x61.6C.6C.55.73.65.72.41.74.74.72.69
+ %x62.75.74.65.54.79.70.65.73
+ ; "allUserAttributeTypes"
+ id-attributeType = %x61.74.74.72.69.62.75.74.65.54.79.70
+ %x65 ; "attributeType"
+ id-allAttributeValues = %x61.6C.6C.41.74.74.72.69.62.75.74.65
+ %x56.61.6C.75.65.73
+ ; "allAttributeValues"
+ id-attributeValue = %x61.74.74.72.69.62.75.74.65.56.61.6C
+ %x75.65 ; "attributeValue"
+ id-selfValue = %x73.65.6C.66.56.61.6C.75.65
+ ; "selfValue"
+ id-rangeOfValues = %x72.61.6E.67.65.4F.66.56.61.6C.75.65
+ %x73 ; "rangeOfValues"
+ id-maxValueCount = %x6D.61.78.56.61.6C.75.65.43.6F.75.6E
+ %x74 ; "maxValueCount"
+ id-maxImmSub = %x6D.61.78.49.6D.6D.53.75.62
+ ; "maxImmSub"
+ id-restrictedBy = %x72.65.73.74.72.69.63.74.65.64.42.79
+ ; "restrictedBy"
+ id-classes = %x63.6C.61.73.73.65.73 ; "classes"
+
+ id-allUserAttributeTypesAndValues = %x61.6C.6C.55.73.65.72.41.74
+ %x74.72.69.62.75.74.65.54.79.70.65.73
+ %x41.6E.64.56.61.6C.75.65.73
+ ; "allUserAttributeTypesAndValues"
+
+ AttributeTypes = "{" sp AttributeType
+ *( "," sp AttributeType ) sp "}"
+
+ AttributeTypeAndValues = "{" sp AttributeTypeAndValue
+ *( "," sp AttributeTypeAndValue )
+ sp "}"
+
+ AttributeTypeAndValue = "{" sp atav-type ","
+ sp atav-value
+ sp "}"
+ atav-type = id-type msp AttributeType
+ atav-value = id-value msp Value
+ id-type = %x74.79.70.65 ; "type"
+ id-value = %x76.61.6C.75.65 ; "value"
+
+
+
+Legg Expires 16 December 2004 [Page 34]
+
+INTERNET-DRAFT Basic and Simplified Access Control June 16, 2004
+
+
+ MaxValueCounts = "{" sp MaxValueCount
+ *( "," sp MaxValueCount ) sp "}"
+ MaxValueCount = "{" sp mvc-type ","
+ sp mvc-maxCount
+ sp "}"
+ mvc-type = id-type msp AttributeType
+ mvc-maxCount = id-maxCount msp INTEGER
+ id-maxCount = %x6D.61.78.43.6F.75.6E.74 ; "maxCount"
+
+ RestrictedValues = "{" sp RestrictedValue
+ *( "," sp RestrictedValue ) sp "}"
+ RestrictedValue = "{" sp rv-type ","
+ sp rv-valuesin
+ sp "}"
+ rv-type = id-type msp AttributeType
+ rv-valuesin = id-valuesin msp AttributeType
+ id-valuesin = %x76.61.6C.75.65.73.69.6E ; "valuesin"
+
+ GrantsAndDenials = "{" [ sp grantOrDeny
+ *( "," sp grantOrDeny ) ] sp "}"
+ grantOrDeny = id-grantAdd
+ / id-denyAdd
+ / id-grantDiscloseOnError
+ / id-denyDiscloseOnError
+ / id-grantRead
+ / id-denyRead
+ / id-grantRemove
+ / id-denyRemove
+ / id-grantBrowse
+ / id-denyBrowse
+ / id-grantExport
+ / id-denyExport
+ / id-grantImport
+ / id-denyImport
+ / id-grantModify
+ / id-denyModify
+ / id-grantRename
+ / id-denyRename
+ / id-grantReturnDN
+ / id-denyReturnDN
+ / id-grantCompare
+ / id-denyCompare
+ / id-grantFilterMatch
+ / id-denyFilterMatch
+ ; grantInvoke omitted
+ ; denyInvoke omitted
+
+ id-grantAdd = %x67.72.61.6E.74.41.64.64 ; "grantAdd"
+
+
+
+Legg Expires 16 December 2004 [Page 35]
+
+INTERNET-DRAFT Basic and Simplified Access Control June 16, 2004
+
+
+ id-denyAdd = %x64.65.6E.79.41.64.64 ; "denyAdd"
+ id-grantBrowse = %x67.72.61.6E.74.42.72.6F.77.73.65
+ ; "grantBrowse"
+ id-denyBrowse = %x64.65.6E.79.42.72.6F.77.73.65 ; "denyBrowse"
+ id-grantCompare = %x67.72.61.6E.74.43.6F.6D.70.61.72.65
+ ; "grantCompare"
+ id-denyCompare = %x64.65.6E.79.43.6F.6D.70.61.72.65
+ ; "denyCompare"
+
+ id-grantDiscloseOnError = %x67.72.61.6E.74.44.69.73.63.6C.6F.73.65
+ %x4F.6E.45.72.72.6F.72
+ ; "grantDiscloseOnError"
+ id-denyDiscloseOnError = %x64.65.6E.79.44.69.73.63.6C.6F.73.65.4F
+ %x6E.45.72.72.6F.72
+ ; "denyDiscloseOnError"
+
+ id-grantExport = %x67.72.61.6E.74.45.78.70.6F.72.74
+ ; "grantExport"
+ id-denyExport = %x64.65.6E.79.45.78.70.6F.72.74
+ ; "denyExport"
+ id-grantFilterMatch = %x67.72.61.6E.74.46.69.6C.74.65.72.4D.61.74
+ %x63.68 ; "grantFilterMatch"
+ id-denyFilterMatch = %x64.65.6E.79.46.69.6C.74.65.72.4D.61.74.63
+ %x68 ; "denyFilterMatch"
+ id-grantImport = %x67.72.61.6E.74.49.6D.70.6F.72.74
+ ; "grantImport"
+ id-denyImport = %x64.65.6E.79.49.6D.70.6F.72.74
+ ; "denyImport"
+ id-grantModify = %x67.72.61.6E.74.4D.6F.64.69.66.79
+ ; "grantModify"
+ id-denyModify = %x64.65.6E.79.4D.6F.64.69.66.79
+ ; "denyModify"
+ id-grantRead = %x67.72.61.6E.74.52.65.61.64 ; "grantRead"
+ id-denyRead = %x64.65.6E.79.52.65.61.64 ; "denyRead"
+ id-grantRemove = %x67.72.61.6E.74.52.65.6D.6F.76.65
+ ; "grantRemove"
+ id-denyRemove = %x64.65.6E.79.52.65.6D.6F.76.65
+ ; "denyRemove"
+ id-grantRename = %x67.72.61.6E.74.52.65.6E.61.6D.65
+ ; "grantRename"
+ id-denyRename = %x64.65.6E.79.52.65.6E.61.6D.65
+ ; "denyRename"
+ id-grantReturnDN = %x67.72.61.6E.74.52.65.74.75.72.6E.44.4E
+ ; "grantReturnDN"
+ id-denyReturnDN = %x64.65.6E.79.52.65.74.75.72.6E.44.4E
+ ; "denyReturnDN"
+
+ The <sp>, <msp>, <sep>, <AttributeType>, <BIT-STRING>, <BOOLEAN>,
+
+
+
+Legg Expires 16 December 2004 [Page 36]
+
+INTERNET-DRAFT Basic and Simplified Access Control June 16, 2004
+
+
+ <DirectoryString>, <DistinguishedName>, <EXTERNAL>, <INTEGER>,
+ <INTEGER-0-MAX> and <NULL> rules are described in [GCE].
+
+ The <SubtreeSpecification> and <Refinement> rules are described in
+ [SUBENTRY].
+
+ The <Value> rule is described in [GSER].
+
+ Filter = filter-item / filter-and / filter-or / filter-not
+ filter-item = id-item ":" FilterItem
+ filter-and = id-and ":" SetOfFilter
+ filter-or = id-or ":" SetOfFilter
+ filter-not = id-not ":" Filter
+ id-and = %x61.6E.64 ; "and"
+ id-item = %x69.74.65.6D ; "item"
+ id-not = %x6E.6F.74 ; "not"
+ id-or = %x6F.72 ; "or"
+
+ SetOfFilter = "{" [ sp Filter *( "," sp Filter ) ] sp "}"
+
+ FilterItem = fi-equality
+ / fi-substrings
+ / fi-greaterOrEqual
+ / fi-lessOrEqual
+ / fi-present
+ / fi-approximateMatch
+ / fi-extensibleMatch
+ ; contextPresent omitted
+
+ fi-equality = id-equality ":" AttributeValueAssertion
+ fi-substrings = id-substrings ":" SubstringsAssertion
+ fi-greaterOrEqual = id-greaterOrEqual ":"
+ AttributeValueAssertion
+ fi-lessOrEqual = id-lessOrEqual ":" AttributeValueAssertion
+ fi-present = id-present ":" AttributeType
+ fi-approximateMatch = id-approximateMatch ":"
+ AttributeValueAssertion
+ fi-extensibleMatch = id-extensibleMatch ":" MatchingRuleAssertion
+ id-equality = %x65.71.75.61.6C.69.74.79 ; "equality"
+ id-substrings = %x73.75.62.73.74.72.69.6E.67.73
+ ; "substrings"
+ id-greaterOrEqual = %x67.72.65.61.74.65.72.4F.72.45.71.75.61.6C
+ ; "greaterOrEqual"
+ id-lessOrEqual = %x6C.65.73.73.4F.72.45.71.75.61.6C
+ ; "lessOrEqual"
+ id-present = %x70.72.65.73.65.6E.74 ; "present"
+ id-approximateMatch = %x61.70.70.72.6F.78.69.6D.61.74.65.4D.61.74
+ %x63.68 ; "approximateMatch"
+
+
+
+Legg Expires 16 December 2004 [Page 37]
+
+INTERNET-DRAFT Basic and Simplified Access Control June 16, 2004
+
+
+ id-extensibleMatch = %x65.78.74.65.6E.73.69.62.6C.65.4D.61.74.63
+ %x68 ; "extensibleMatch"
+
+ AttributeValueAssertion = "{" sp ava-type ","
+ sp ava-assertion
+ ; assertedContexts omitted
+ sp "}"
+
+ ava-type = id-type msp AttributeType
+ ava-assertion = id-assertion msp Value
+ id-assertion = %x61.73.73.65.72.74.69.6F.6E ; "assertion"
+
+ SubstringsAssertion = "{" sp sa-type ","
+ sp sa-strings
+ sp "}"
+
+ sa-type = id-type msp AttributeType
+ sa-strings = id-strings msp Substrings
+ id-strings = %x73.74.72.69.6E.67.73 ; "strings"
+
+ Substrings = "{" [ sp Substring *( "," sp Substring ) ] sp "}"
+ Substring = ss-initial
+ / ss-any
+ / ss-final
+ ; control omitted
+ ss-initial = id-initial ":" Value
+ ss-any = id-any ":" Value
+ ss-final = id-final ":" Value
+ id-initial = %x69.6E.69.74.69.61.6C ; "initial"
+ id-any = %x61.6E.79 ; "any"
+ id-final = %x66.69.6E.61.6C ; "final"
+
+ MatchingRuleAssertion = "{" sp mra-matchingRule
+ [ "," sp mra-type ]
+ "," sp mra-matchValue
+ [ "," sp mra-dnAttributes ]
+ sp "}"
+
+ mra-matchingRule = id-matchingRule msp MatchingRuleIds
+ mra-type = id-type msp AttributeType
+ mra-matchValue = id-matchValue msp Value
+ mra-dnAttributes = id-dnAttributes msp BOOLEAN
+ id-matchingRule = %x6D.61.74.63.68.69.6E.67.52.75.6C.65
+ ; "matchingRule"
+ id-matchValue = %x6D.61.74.63.68.56.61.6C.75.65 ; "matchValue"
+ id-dnAttributes = %x64.6E.41.74.74.72.69.62.75.74.65.73
+ ; "dnAttributes"
+
+
+
+
+Legg Expires 16 December 2004 [Page 38]
+
+INTERNET-DRAFT Basic and Simplified Access Control June 16, 2004
+
+
+ MatchingRuleIds = "{" sp MatchingRuleId *( "," sp MatchingRuleId ) sp "}"
+ MatchingRuleId = OBJECT-IDENTIFIER
+
+ The <OBJECT-IDENTIFIER> rule is described in [GCE].
+
+Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2251] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory
+ Access Protocol (v3)", RFC 2251, December 1997.
+
+ [RFC2252] Wahl, M., Coulbeck, A., Howes, T. and S. Kille,
+ "Lightweight Directory Access Protocol (v3): Attribute
+ Syntax Definitions", RFC 2252, December 1997.
+
+ [RFC2256] Wahl, M., "A Summary of the X.500(96) User Schema for use
+ with LDAPv3", RFC 2256, December 1997.
+
+ [RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access
+ Protocol (v3): Technical Specification", RFC 3377,
+ September 2002.
+
+ [BCP64] Zeilenga, K., "Internet Assigned Numbers
+ Authority (IANA) Considerations for the Lightweight
+ Directory Access Protcol (LDAP)", BCP 64, RFC 3383,
+ September 2002.
+
+ [GSER] Legg, S., "Generic String Encoding Rules for ASN.1 Types",
+ RFC 3641, October 2003.
+
+ [COLLECT] Zeilenga, K., "Collective Attributes in the Lightweight
+ Directory Access Protocol (LDAP)", RFC 3671, December
+ 2003.
+
+ [SUBENTRY] Zeilenga, K. and S. Legg, "Subentries in the Lightweight
+ Directory Access Protocol (LDAP)", RFC 3672, December
+ 2003.
+
+ [SCHEMA] Zeilenga, K., "Lightweight Directory Access Protocol
+ (LDAP): Additional Matching Rules", RFC 3698, February
+ 2004.
+
+ [ADMIN] Legg, S., "Lightweight Directory Access Protocol (LDAP):
+ Directory Administrative Model",
+ draft-legg-ldap-admin-xx.txt, a work in progress, June
+ 2004.
+
+
+
+Legg Expires 16 December 2004 [Page 39]
+
+INTERNET-DRAFT Basic and Simplified Access Control June 16, 2004
+
+
+ [ACA] Legg, S., "Lightweight Directory Access Protocol (LDAP):
+ Access Control Administration",
+ draft-legg-ldap-acm-admin-xx.txt, a work in progress, June
+ 2004.
+
+ [FILTER] Zeilenga, K., "LDAP Absolute True and False Filters",
+ draft-zeilenga-ldap-t-f-xx.txt, a work in progress,
+ February 2004.
+
+ [ASN1] ITU-T Recommendation X.680 (07/02) | ISO/IEC 8824-1,
+ Information technology - Abstract Syntax Notation One
+ (ASN.1): Specification of basic notation
+
+Informative References
+
+ [RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
+ Specifications: ABNF", RFC 2234, November 1997.
+
+ [GCE] Legg, S., "Common Elements of Generic String Encoding
+ Rules (GSER) Encodings", RFC 3642, October 2003.
+
+ [X501] ITU-T Recommendation X.501 (02/01) | ISO/IEC 9594-2:2001,
+ Information technology - Open Systems Interconnection -
+ The Directory: Models
+
+ [X511] ITU-T Recommendation X.511 (02/01) | ISO/IEC 9594-3:2001,
+ Information technology - Open Systems Interconnection -
+ The Directory: Abstract service definition
+
+Author's Address
+
+ Steven Legg
+ Adacel Technologies Ltd.
+ 250 Bay Street
+ Brighton, Victoria 3186
+ AUSTRALIA
+
+ Phone: +61 3 8530 7710
+ Fax: +61 3 8530 7888
+ EMail: steven.legg at adacel.com.au
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2004). This document is subject
+ to the rights, licenses and restrictions contained in BCP 78, and
+ except as set forth therein, the authors retain all their rights.
+
+ This document and the information contained herein are provided on an
+
+
+
+Legg Expires 16 December 2004 [Page 40]
+
+INTERNET-DRAFT Basic and Simplified Access Control June 16, 2004
+
+
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr at ietf.org.
+
+Changes in Draft 01
+
+ The Internet draft draft-legg-ldap-acm-admin-00.txt has been split
+ into two drafts, draft-legg-ldap-admin-00.txt and
+ draft-legg-ldap-acm-admin-01.txt. Section 8 of
+ draft-legg-ldapext-component-matching-06.txt has been extracted to
+ become a separate Internet draft, draft-legg-ldap-gser-xx.txt. The
+ references in this document have been updated accordingly.
+
+ The term "native LDAP encoding" has been replaced by the term
+ "LDAP-specific encoding" to align with terminology anticipated to be
+ used in the revision of RFC 2252.
+
+ Changes have been made to the Search Operation Decision Points
+ (Section 3.4.3):
+
+ In 4) a), the assumed FilterMatch permission for a present match of
+
+
+
+Legg Expires 16 December 2004 [Page 41]
+
+INTERNET-DRAFT Basic and Simplified Access Control June 16, 2004
+
+
+ the objectClass attribute has been removed. An LDAP search with a
+ True filter [FILTER] is the best analogue of the DAP read operation.
+ A True filter does not filter any attribute type and therefore does
+ not require FilterMatch permissions to succeed.
+
+ In 5) b) and c), there is an additional requirement for Read
+ permission for at least one attribute value before an attribute type
+ can be returned in a search result. Without this change a search
+ result could, in some circumstances, disclose the existence of
+ particular hidden attribute values.
+
+Changes in Draft 02
+
+ RFC 3377 replaces RFC 2251 as the reference for LDAP.
+
+ An IANA Considerations section has been added.
+
+Changes in Draft 03
+
+ The document has been reformatted in line with current practice.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Legg Expires 16 December 2004 [Page 42]
+
+
Added: openldap/vendor/openldap-release/doc/drafts/draft-legg-ldap-admin-xx.txt
===================================================================
--- openldap/vendor/openldap-release/doc/drafts/draft-legg-ldap-admin-xx.txt (rev 0)
+++ openldap/vendor/openldap-release/doc/drafts/draft-legg-ldap-admin-xx.txt 2007-09-15 10:38:52 UTC (rev 844)
@@ -0,0 +1,390 @@
+INTERNET-DRAFT S. Legg
+draft-legg-ldap-admin-02.txt Adacel Technologies
+Intended Category: Standards Track June 16, 2004
+
+
+ Lightweight Directory Access Protocol (LDAP):
+ Directory Administrative Model
+
+ Copyright (C) The Internet Society (2004). All Rights Reserved.
+
+ Status of this Memo
+
+
+ This document is an Internet-Draft and is in full conformance with
+ all provisions of Section 10 of RFC2026.
+
+ Internet-Drafts are working documents of the Internet Engineering
+ Task Force (IETF), its areas, and its working groups. Note that
+ other groups may also distribute working documents as
+ Internet-Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference
+ material or to cite them other than as "work in progress".
+
+ The list of current Internet-Drafts can be accessed at
+ http://www.ietf.org/ietf/1id-abstracts.txt
+
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html.
+
+ Distribution of this document is unlimited. Comments should be sent
+ to the author.
+
+ This Internet-Draft expires on 16 December 2004.
+
+
+Abstract
+
+ This document adapts the X.500 directory administrative model for use
+ by the Lightweight Directory Access Protocol. The administrative
+ model partitions the Directory Information Tree for various aspects
+ of directory data administration, e.g., subschema, access control and
+ collective attributes. The generic framework that applies to every
+ aspect of administration is described in this document. The
+ definitions that apply for a specific aspect of administration, e.g.,
+ access control administration, are described in other documents.
+
+
+
+Legg Expires 16 December 2004 [Page 1]
+
+INTERNET-DRAFT Directory Administrative Model June 16, 2004
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
+ 2. Conventions. . . . . . . . . . . . . . . . . . . . . . . . . . 2
+ 3. Administrative Areas . . . . . . . . . . . . . . . . . . . . . 2
+ 4. Autonomous Administrative Areas. . . . . . . . . . . . . . . . 3
+ 5. Specific Administrative Areas. . . . . . . . . . . . . . . . . 3
+ 6. Inner Administrative Areas . . . . . . . . . . . . . . . . . . 4
+ 7. Administrative Entries . . . . . . . . . . . . . . . . . . . . 4
+ 8. Security Considerations. . . . . . . . . . . . . . . . . . . . 5
+ 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5
+ 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
+ 10.1. Normative References. . . . . . . . . . . . . . . . . . 5
+ 10.2. Informative References. . . . . . . . . . . . . . . . . 5
+ 11. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 6
+ Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 6
+
+1. Introduction
+
+ This document adapts the X.500 directory administrative model [X501]
+ for use by the Lightweight Directory Access Protocol (LDAP) [LDAP].
+ The administrative model partitions the Directory Information Tree
+ (DIT) for various aspects of directory data administration, e.g.,
+ subschema, access control and collective attributes. This document
+ provides the definitions for the generic parts of the administrative
+ model that apply to every aspect of directory data administration.
+
+ Sections 3 to 7, in conjunction with [SUBENTRY], describe the means
+ by which administrative authority is aportioned and exercised in the
+ DIT.
+
+ Aspects of administration that conform to the administrative model
+ described in this document are detailed elsewhere, e.g., access
+ control administration is described in [ACA] and collective attribute
+ administration is described in [COLLECT].
+
+ This document is derived from, and duplicates substantial portions
+ of, Sections 4 and 8 of X.501 [X501].
+
+2. Conventions
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in BCP 14, RFC 2119
+ [RFC2119].
+
+3. Administrative Areas
+
+
+
+
+Legg Expires 16 December 2004 [Page 2]
+
+INTERNET-DRAFT Directory Administrative Model June 16, 2004
+
+
+ An administrative area is a subtree of the DIT considered from the
+ perspective of administration. The root entry of the subtree is an
+ administrative point. An administrative point is represented by an
+ entry holding an administrativeRole attribute [SUBENTRY]. The values
+ of this attribute identify the kind of administrative point.
+
+4. Autonomous Administrative Areas
+
+ The DIT may be partitioned into one or more non-overlapping subtrees
+ termed autonomous administrative areas. It is expected that the
+ entries in an autonomous administrative area are all administered by
+ the same administrative authority.
+
+ An administrative authority may be responsible for several autonomous
+ administrative areas in separated parts of the DIT but it SHOULD NOT
+ arbitrarily partition the collection of entries under its control
+ into autonomous administrative areas (thus creating adjacent
+ autonomous areas administered by the same authority).
+
+ The root entry of an autonomous administrative area's subtree is
+ called an autonomous administrative point. An autonomous
+ administrative area extends from its autonomous administrative point
+ downwards until another autonomous administrative point is
+ encountered, at which point another autonomous administrative area
+ begins.
+
+5. Specific Administrative Areas
+
+ Entries in an administrative area may be considered in terms of a
+ specific administrative function. When viewed in this context, an
+ administrative area is termed a specific administrative area.
+
+ Examples of specific administrative areas are subschema specific
+ administrative areas, access control specific areas and collective
+ attribute specific areas.
+
+ An autonomous administrative area may be considered as implicitly
+ defining a single specific administrative area for each specific
+ aspect of administration. In this case, there is a precise
+ correspondence between each such specific administrative area and the
+ autonomous administrative area.
+
+ Alternatively, for each specific aspect of administration, the
+ autonomous administrative area may be partitioned into
+ non-overlapping specific administrative areas.
+
+ If so partitioned for a particular aspect of administration, each
+ entry of the autonomous administrative area is contained in one and
+
+
+
+Legg Expires 16 December 2004 [Page 3]
+
+INTERNET-DRAFT Directory Administrative Model June 16, 2004
+
+
+ only one specific administrative area for that aspect, i.e., specific
+ administrative areas do not overlap.
+
+ The root entry of a specific administrative area's subtree is called
+ a specific administrative point. A specific administrative area
+ extends from its specific administrative point downwards until
+ another specific administrative point of the same administrative
+ aspect is encountered, at which point another specific administrative
+ area begins. Specific administrative areas are always bounded by the
+ autonomous administrative area they partition.
+
+ Where an autonomous administrative area is not partitioned for a
+ specific aspect of administration, the specific administrative area
+ for that aspect coincides with the autonomous administrative area.
+ In this case, the autonomous administrative point is also the
+ specific administrative point for this aspect of administration. A
+ particular administrative point may be the root of an autonomous
+ administrative area and may be the root of one or more specific
+ administrative areas for different aspects of administration.
+
+ It is not necessary for an administrative point to represent each
+ specific aspect of administrative authority. For example, there
+ might be an administrative point, subordinate to the root of the
+ autonomous administrative area, which is used for access control
+ purposes only.
+
+6. Inner Administrative Areas
+
+ For some aspects of administration, e.g., access control or
+ collective attributes, inner administrative areas may be defined
+ within the specific administrative areas, to allow a limited form of
+ delegation, or for administrative or operational convenience.
+
+ An inner administrative area may be nested within another inner
+ administrative area. The rules for nested inner areas are defined as
+ part of the definition of the specific administrative aspect for
+ which they are allowed.
+
+ The root entry of an inner administrative area's subtree is called an
+ inner administrative point. An inner administrative area (within a
+ specific administrative area) extends from its inner administrative
+ point downwards until a specific administrative point of the same
+ administrative aspect is encountered. An inner administrative area
+ is bounded by the specific administrative area within which it is
+ defined.
+
+7. Administrative Entries
+
+
+
+
+Legg Expires 16 December 2004 [Page 4]
+
+INTERNET-DRAFT Directory Administrative Model June 16, 2004
+
+
+ An entry located at an administrative point is an administrative
+ entry. Administrative entries MAY have subentries [SUBENTRY] as
+ immediate subordinates. The administrative entry and its associated
+ subentries are used to control the entries encompassed by the
+ associated administrative area. Where inner administrative areas are
+ used, the scopes of these areas may overlap. Therefore, for each
+ specific aspect of administrative authority, a definition is required
+ of the method of combination of administrative information when it is
+ possible for entries to be included in more than one subtree or
+ subtree refinement associated with an inner area defined for that
+ aspect.
+
+8. Security Considerations
+
+ This document defines a generic framework for employing policy of
+ various kinds, e.g., access controls, to entries in the DIT. Such
+ policy can only be correctly enforced at a directory server holding a
+ replica of a portion of the DIT if the administrative entries for
+ administrative areas that overlap the portion of the DIT being
+ replicated, and the subentries of those administrative entries
+ relevant to any aspect of policy that is required to be enforced at
+ the replica, are included in the replicated information.
+
+ Administrative entries and subentries SHOULD be protected from
+ unauthorized examination or changes by appropriate access controls.
+
+9. Acknowledgements
+
+ This document is derived from, and duplicates substantial portions
+ of, Sections 4 and 8 of X.501 [X501].
+
+10. References
+
+10.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [LDAP] Hodges, J. and R. Morgan, "Lightweight Directory Access
+ Protocol (v3): Technical Specification", RFC 3377,
+ September 2002.
+
+ [SUBENTRY] Zeilenga, K. and S. Legg, "Subentries in the Lightweight
+ Directory Access Protocol (LDAP)", RFC 3672, December
+ 2003.
+
+10.2. Informative References
+
+
+
+
+Legg Expires 16 December 2004 [Page 5]
+
+INTERNET-DRAFT Directory Administrative Model June 16, 2004
+
+
+ [COLLECT] Zeilenga, K., "Collective Attributes in the Lightweight
+ Directory Access Protocol (LDAP)", RFC 3671, December
+ 2003.
+
+ [ACA] Legg, S., "Lightweight Directory Access Protocol (LDAP):
+ Access Control Administration",
+ draft-legg-ldap-acm-admin-xx.txt, a work in progress, June
+ 2004.
+
+ [X501] ITU-T Recommendation X.501 (02/01) | ISO/IEC 9594-2:2001,
+ Information technology - Open Systems Interconnection -
+ The Directory: Models
+
+11. Author's Address
+
+ Steven Legg
+ Adacel Technologies Ltd.
+ 250 Bay Street
+ Brighton, Victoria 3186
+ AUSTRALIA
+
+ Phone: +61 3 8530 7710
+ Fax: +61 3 8530 7888
+ EMail: steven.legg at adacel.com.au
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2004). This document is subject
+ to the rights, licenses and restrictions contained in BCP 78, and
+ except as set forth therein, the authors retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+
+
+
+Legg Expires 16 December 2004 [Page 6]
+
+INTERNET-DRAFT Directory Administrative Model June 16, 2004
+
+
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr at ietf.org.
+
+Changes in Draft 00
+
+ This document reproduces Section 4 from
+ draft-legg-ldap-acm-admin-00.txt as a standalone document. All
+ changes made are purely editorial. No technical changes have been
+ introduced.
+
+Changes in Draft 01
+
+ RFC 3377 replaces RFC 2251 as the reference for LDAP.
+
+Changes in Draft 02
+
+ The document has been reformatted in line with current practice.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Legg Expires 16 December 2004 [Page 7]
+
+
Added: openldap/vendor/openldap-release/doc/drafts/draft-legg-ldap-binary-xx.txt
===================================================================
--- openldap/vendor/openldap-release/doc/drafts/draft-legg-ldap-binary-xx.txt (rev 0)
+++ openldap/vendor/openldap-release/doc/drafts/draft-legg-ldap-binary-xx.txt 2007-09-15 10:38:52 UTC (rev 844)
@@ -0,0 +1,507 @@
+
+
+
+
+
+
+INTERNET-DRAFT S. Legg
+draft-legg-ldap-binary-04.txt eB2Bcom
+Intended Category: Standards Track 30 January 2006
+
+
+ Lightweight Directory Access Protocol (LDAP):
+ The Binary Encoding Option
+
+ Copyright (C) The Internet Society (2006).
+
+ Status of this Memo
+
+ By submitting this Internet-draft, each author represents that any
+ applicable patent or other IPR claims of which he or she is aware
+ have been or will be disclosed, and any of which he or she becomes
+ aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+ Internet-Drafts are working documents of the Internet Engineering
+ Task Force (IETF), its areas, and its working groups. Note that
+ other groups may also distribute working documents as
+ Internet-Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference
+ material or to cite them other than as "work in progress".
+
+ The list of current Internet-Drafts can be accessed at
+ http://www.ietf.org/1id-abstracts.html
+
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html
+
+ Technical discussion of this document should take place on the IETF
+ LDAP Revision Working Group (LDAPbis) mailing list
+ <ietf-ldapbis at openldap.org>. Please send editorial comments directly
+ to the editor <steven.legg at eb2bcom.com>.
+
+ This Internet-Draft expires on 30 July 2006.
+
+Abstract
+
+ Each attribute stored in a Lightweight Directory Access Protocol
+ (LDAP) directory has a defined syntax (i.e., data type). A syntax
+ definition specifies how attribute values conforming to the syntax
+ are normally represented when transferred in LDAP operations. This
+ representation is referred to as the LDAP-specific encoding to
+ distinguish it from other methods of encoding attribute values. This
+
+
+
+Legg Expires 30 July 2006 [Page 1]
+
+INTERNET-DRAFT LDAP: The Binary Encoding Option January 30, 2006
+
+
+ document defines an attribute option, the binary option, which can be
+ used to specify that the associated attribute values are instead
+ encoded according to the Basic Encoding Rules (BER) used by X.500
+ directories.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Legg Expires 30 July 2006 [Page 2]
+
+INTERNET-DRAFT LDAP: The Binary Encoding Option January 30, 2006
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 2. Conventions. . . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 3. The binary Option. . . . . . . . . . . . . . . . . . . . . . . 4
+ 4. Syntaxes Requiring Binary Transfer . . . . . . . . . . . . . . 4
+ 5. Attributes Returned in a Search. . . . . . . . . . . . . . . . 5
+ 6. All User Attributes. . . . . . . . . . . . . . . . . . . . . . 6
+ 7. Conflicting Requests . . . . . . . . . . . . . . . . . . . . . 6
+ 8. Security Considerations. . . . . . . . . . . . . . . . . . . . 6
+ 9. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 6
+ 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
+ 10.1. Normative References. . . . . . . . . . . . . . . . . . 7
+ 10.2. Informative References. . . . . . . . . . . . . . . . . 7
+ Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8
+ Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 8
+
+1. Introduction
+
+ Each attribute stored in a Lightweight Directory Access Protocol
+ (LDAP) directory [ROADMAP] has a defined syntax (i.e., data type)
+ which constrains the structure and format of its values.
+
+ The description of each syntax [SYNTAX] specifies how attribute or
+ assertion values [MODELS] conforming to the syntax are normally
+ represented when transferred in LDAP operations [PROT]. This
+ representation is referred to as the LDAP-specific encoding to
+ distinguish it from other methods of encoding attribute values.
+
+ This document defines an attribute option, the binary option, which
+ can be used in an attribute description [MODELS] in an LDAP operation
+ to specify that the associated attribute values or assertion values
+ are, or are requested to be, encoded according to the Basic Encoding
+ Rules (BER) [BER] as used by X.500 [X.500] directories, instead of
+ the usual LDAP-specific encoding.
+
+ The binary option was originally defined in RFC 2251 [RFC2251]. The
+ LDAP technical specification [ROADMAP] has obsoleted the previously
+ defined LDAP technical specification [RFC3377], which included RFC
+ 2251. The binary option was not included in the revised LDAP
+ technical specification for a variety of reasons including
+ implementation inconsistencies. No attempt is made here to resolve
+ the known inconsistencies.
+
+ This document reintroduces the binary option for use with certain
+ attribute syntaxes, such as certificate syntax [PKI], which
+ specifically require it. No attempt has been made to address use of
+ the binary option with attributes of syntaxes which do not require
+
+
+
+Legg Expires 30 July 2006 [Page 3]
+
+INTERNET-DRAFT LDAP: The Binary Encoding Option January 30, 2006
+
+
+ its use. Unless addressed in a future specification, this use is to
+ be avoided.
+
+
+2. Conventions
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in BCP 14, RFC 2119
+ [BCP14].
+
+3. The binary Option
+
+ The binary option is indicated with the attribute option string
+ "binary" in an attribute description. Note that, like all attribute
+ options, the string representing the binary option is case
+ insensitive.
+
+ Where the binary option is present in an attribute description the
+ associated attribute values or assertion values MUST be BER encoded
+ (otherwise the values are encoded according to the LDAP-specific
+ encoding [SYNTAX] for the attribute's syntax). Note that it is
+ possible for a syntax to be defined such that its LDAP-specific
+ encoding is exactly the same as its BER encoding.
+
+ In terms of the protocol [PROT], the binary option specifies that the
+ contents octets of the associated AttributeValue or AssertionValue
+ OCTET STRING are a complete BER encoding of the relevant value.
+
+ The binary option is not a tagging option [MODELS] so the presence of
+ the binary option does not specify an attribute subtype. An
+ attribute description containing the binary option references exactly
+ the same attribute as the attribute description without the binary
+ option. The supertype/subtype relationships of attributes with
+ tagging options are not altered in any way by the presence or absence
+ of the binary option.
+
+ An attribute description SHALL be treated as unrecognized if it
+ contains the binary option and the syntax of the attribute does not
+ have an associated ASN.1 type [SYNTAX], or the BER encoding of values
+ of that type is not supported.
+
+ The presence or absence of the binary option only affects the
+ transfer of attribute and assertion values in protocol; servers store
+ any particular attribute value in a format of their choosing.
+
+4. Syntaxes Requiring Binary Transfer
+
+
+
+
+Legg Expires 30 July 2006 [Page 4]
+
+INTERNET-DRAFT LDAP: The Binary Encoding Option January 30, 2006
+
+
+ The attribute values of certain attribute syntaxes are defined
+ without an LDAP-specific encoding and are required to be transferred
+ in the BER encoded form. For the purposes of this document, these
+ syntaxes are said to have a binary transfer requirement. The
+ Certificate, Certificate List, Certificate Pair and Supported
+ Algorithm syntaxes [PKI] are examples of syntaxes with a binary
+ transfer requirement. These syntaxes also have an additional
+ requirement that the exact BER encoding must be preserved. Note that
+ this is a property of the syntaxes themselves, and not a property of
+ the binary option. In the absence of this requirement, LDAP clients
+ would need to re-encode values using the Distinguished Encoding Rules
+ (DER).
+
+5. Attributes Returned in a Search
+
+ An LDAP search request [PROT] contains a list of the attributes (the
+ requested attributes list) to be returned from each entry matching
+ the search filter. An attribute description in the requested
+ attributes list also implicitly requests all subtypes of the
+ attribute type in the attribute description, whether through
+ attribute subtyping or attribute tagging option subtyping [MODELS].
+
+ The requested attributes list MAY contain attribute descriptions with
+ the binary option, but MUST NOT contain two attribute descriptions
+ with the same attribute type and the same tagging options (even if
+ only one of them has the binary option). The binary option in an
+ attribute description in the requested attributes list implicitly
+ applies to all the subtypes of the attribute type in the attribute
+ description (however, see Section 7).
+
+ Attributes of a syntax with the binary transfer requirement, if
+ returned, SHALL be returned in the binary form, i.e., with the binary
+ option in the attribute description and the associated attribute
+ values BER encoded, regardless of whether the binary option was
+ present in the request (for the attribute or for one of its
+ supertypes).
+
+ Attributes of a syntax without the binary transfer requirement, if
+ returned, SHOULD be returned in the form explicitly requested. That
+ is, if the attribute description in the requested attributes list
+ contains the binary option then the corresponding attribute in the
+ result SHOULD be in the binary form. If the attribute description in
+ the request does not contain the binary option then the corresponding
+ attribute in the result SHOULD NOT be in the binary form. A server
+ MAY omit an attribute from the result if it does not support the
+ requested encoding.
+
+ Regardless of the encoding chosen, a particular attribute value is
+
+
+
+Legg Expires 30 July 2006 [Page 5]
+
+INTERNET-DRAFT LDAP: The Binary Encoding Option January 30, 2006
+
+
+ returned at most once.
+
+6. All User Attributes
+
+ If the list of attributes in a search request is empty, or contains
+ the special attribute description string "*", then all user
+ attributes are requested to be returned.
+
+ Attributes of a syntax with the binary transfer requirement, if
+ returned, SHALL be returned in the binary form.
+
+ Attributes of a syntax without the binary transfer requirement and
+ having a defined LDAP-specific encoding SHOULD NOT be returned in the
+ binary form.
+
+ Attributes of a syntax without the binary transfer requirement and
+ without a defined LDAP-specific encoding may be returned in the
+ binary form or omitted from the result.
+
+7. Conflicting Requests
+
+ A particular attribute could be explicitly requested by an attribute
+ description and/or implicitly requested by the attribute descriptions
+ of one or more of its supertypes, or by the special attribute
+ description string "*". If the binary option is not present in all
+ these attribute descriptions, nor absent in all these attribute
+ descriptions, then the effect of the request with respect to binary
+ transfer is implementation defined.
+
+8. Security Considerations
+
+ When interpreting security-sensitive fields, and in particular fields
+ used to grant or deny access, implementations MUST ensure that any
+ matching rule comparisons are done on the underlying abstract value,
+ regardless of the particular encoding used.
+
+9. IANA Considerations
+
+ The Internet Assigned Numbers Authority (IANA) is requested to update
+ the LDAP attribute description option registry [BCP64] as indicated
+ by the following template:
+
+ Subject:
+ Request for LDAP Attribute Description Option Registration
+ Option Name: binary
+ Family of Options: NO
+ Person & email address to contact for further information:
+ Steven Legg <steven.legg at eb2bcom.com>
+
+
+
+Legg Expires 30 July 2006 [Page 6]
+
+INTERNET-DRAFT LDAP: The Binary Encoding Option January 30, 2006
+
+
+ Specification: RFC XXXX
+ Author/Change Controller: IESG
+ Comments: The existing registration for "binary"
+ should be updated to refer to RFC XXXX.
+
+10. References
+
+10.1. Normative References
+
+ [BCP14] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [BCP64] Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
+ Considerations for the Lightweight Directory Access
+ Protocol (LDAP)", BCP 64, RFC 3383, September 2002.
+
+ [ROADMAP] Zeilenga, K., "Lightweight Directory Access Protocol
+ (LDAP): Technical Specification Road Map",
+ draft-ietf-ldapbis-roadmap-xx.txt, a work in progress,
+ February 2005.
+
+ [MODELS] Zeilenga, K., "LDAP: Directory Information Models",
+ draft-ietf-ldapbis-models-xx.txt, a work in progress,
+ February 2005.
+
+ [PROT] Sermersheim, J., "LDAP: The Protocol",
+ draft-ietf-ldapbis-protocol-xx.txt, a work in progress,
+ October 2005.
+
+ [SYNTAX] Legg, S., "Lightweight Directory Access Protocol (LDAP):
+ Syntaxes and Matching Rules",
+ draft-ietf-ldapbis-syntaxes-xx.txt, a work in progress,
+ June 2005.
+
+ [PKI] Zeilenga, Kurt D., "Lightweight Directory Access Protocol
+ (LDAP) schema definitions for X.509 Certificates",
+ draft-zeilenga-ldap-x509-xx.txt, a work in progress, July
+ 2005.
+
+ [BER] ITU-T Recommendation X.690 (07/02) | ISO/IEC 8825-1,
+ Information Technology - ASN.1 encoding rules:
+ Specification of Basic Encoding Rules (BER), Canonical
+ Encoding Rules (CER) and Distinguished Encoding Rules
+ (DER).
+
+10.2. Informative References
+
+ [RFC2251] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory
+
+
+
+Legg Expires 30 July 2006 [Page 7]
+
+INTERNET-DRAFT LDAP: The Binary Encoding Option January 30, 2006
+
+
+ Access Protocol (v3)", RFC 2251, December 1997.
+
+ [RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access
+ Protocol (v3): Technical Specification", RFC 3377,
+ September 2002.
+
+ [X.500] ITU-T Recommendation X.500 (02/01) | ISO/IEC 9594-1:2001,
+ Information technology - Open Systems Interconnection -
+ The Directory: Overview of concepts, models and services
+
+Author's Address
+
+ Dr. Steven Legg
+ eB2Bcom
+ Suite 3, Woodhouse Corporate Centre
+ 935 Station Street
+ Box Hill North, Victoria 3129
+ AUSTRALIA
+
+ Phone: +61 3 9896 7830
+ Fax: +61 3 9896 7801
+ EMail: steven.legg at eb2bcom.com
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2006).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+
+
+
+Legg Expires 30 July 2006 [Page 8]
+
+INTERNET-DRAFT LDAP: The Binary Encoding Option January 30, 2006
+
+
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr at ietf.org.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Legg Expires 30 July 2006 [Page 9]
+
Added: openldap/vendor/openldap-release/doc/drafts/draft-legg-ldap-transfer-xx.txt
===================================================================
--- openldap/vendor/openldap-release/doc/drafts/draft-legg-ldap-transfer-xx.txt (rev 0)
+++ openldap/vendor/openldap-release/doc/drafts/draft-legg-ldap-transfer-xx.txt 2007-09-15 10:38:52 UTC (rev 844)
@@ -0,0 +1,614 @@
+INTERNET-DRAFT S. Legg
+draft-legg-ldap-transfer-03.txt Adacel Technologies
+Intended Category: Standards Track 16 June 2004
+Updates: RFC 2252bis
+
+
+ Lightweight Directory Access Protocol (LDAP):
+ Transfer Encoding Options
+
+ Copyright (C) The Internet Society (2004). All Rights Reserved.
+
+ Status of this Memo
+
+
+ This document is an Internet-Draft and is in full conformance with
+ all provisions of Section 10 of RFC2026.
+
+ Internet-Drafts are working documents of the Internet Engineering
+ Task Force (IETF), its areas, and its working groups. Note that
+ other groups may also distribute working documents as
+ Internet-Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference
+ material or to cite them other than as "work in progress".
+
+ The list of current Internet-Drafts can be accessed at
+ http://www.ietf.org/ietf/1id-abstracts.txt
+
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html.
+
+ This document is intended to be, after appropriate review and
+ revision, submitted to the RFC Editor as a Standard Track document.
+ Distribution of this document is unlimited. Technical discussion of
+ this document should take place on the IETF LDAP Revision Working
+ Group (LDAPbis) mailing list <ietf-ldapbis at openldap.org>. Please
+ send editorial comments directly to the editor
+ <steven.legg at adacel.com.au>.
+
+ This Internet-Draft expires on 16 December 2004.
+
+
+Abstract
+
+ Each attribute stored in a Lightweight Directory Access Protocol
+ (LDAP) directory has a defined syntax (i.e., data type). A syntax
+
+
+
+Legg Expires 16 December 2004 [Page 1]
+
+INTERNET-DRAFT LDAP: Transfer Encoding Options June 16, 2004
+
+
+ definition specifies how attribute values conforming to the syntax
+ are normally represented when transferred in LDAP operations. This
+ representation is referred to as the LDAP-specific encoding to
+ distinguish it from other methods of encoding attribute values. This
+ document introduces a new category of attribute options, called
+ transfer encoding options, which can be used to specify that the
+ associated attribute values are encoded according to one of these
+ other methods.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Legg Expires 16 December 2004 [Page 2]
+
+INTERNET-DRAFT LDAP: Transfer Encoding Options June 16, 2004
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 2. Conventions. . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 3. Transfer Encoding Options. . . . . . . . . . . . . . . . . . . 4
+ 4. Defined Transfer Encoding Options. . . . . . . . . . . . . . . 5
+ 5. Attributes Returned in a Search. . . . . . . . . . . . . . . . 6
+ 6. Syntaxes Requiring Binary Transfer . . . . . . . . . . . . . . 7
+ 7. Security Considerations. . . . . . . . . . . . . . . . . . . . 7
+ 8. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 8
+ 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
+ 9.1. Normative References . . . . . . . . . . . . . . . . . . 9
+ 9.2. Informative References . . . . . . . . . . . . . . . . . 10
+ Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10
+ Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 10
+
+1. Introduction
+
+ Each attribute stored in a Lightweight Directory Access Protocol
+ (LDAP) directory [ROADMAP] has a defined syntax (i.e., data type)
+ which constrains the structure and format of its values.
+
+ The description of each syntax [SYNTAX] specifies how attribute or
+ assertion values [MODELS] conforming to the syntax are normally
+ represented when transferred in LDAP operations [PROT]. This
+ representation is referred to as the LDAP-specific encoding to
+ distinguish it from other methods of encoding attribute values.
+
+ This document introduces a new category of attribute options
+ [MODELS], called transfer encoding options, that allow attribute and
+ assertion values to be transferred using an alternative method of
+ encoding. This document defines several transfer encoding options
+ which can be used in an attribute description [MODELS] in an LDAP
+ operation to specify that the associated attribute values or
+ assertion value are, or are requested to be, encoded according to
+ specific Abstract Syntax Notation One (ASN.1) [X680] encoding rules,
+ instead of the usual LDAP-specific encoding. One option in
+ particular allows Extensible Markup Language (XML) [XML] encodings.
+
+2. Conventions
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in BCP 14, RFC 2119
+ [KEYWORD].
+
+ This specification makes use of definitions from the XML Information
+ Set (Infoset) [ISET]. In particular, information item property names
+
+
+
+Legg Expires 16 December 2004 [Page 3]
+
+INTERNET-DRAFT LDAP: Transfer Encoding Options June 16, 2004
+
+
+ are presented per the Infoset, e.g., [local name].
+
+3. Transfer Encoding Options
+
+ Transfer encoding options enable attribute and assertion values to be
+ transferred using an alternative method of encoding to the default
+ LDAP-specific encoding. In fact, some attribute and assertion
+ syntaxes do not have a defined LDAP-specific encoding in which case
+ the only way values of those syntaxes can be transferred is by using
+ an alternative encoding.
+
+ The binary option [BINARY] is not formally regarded as a transfer
+ encoding option, though it has much in common with transfer encoding
+ options. The requirements governing the use of transfer encoding
+ options do not apply to the binary option. The requirements
+ governing the use of the binary option are described elsewhere
+ [BINARY].
+
+ In terms of the protocol [PROT], a transfer encoding option specifies
+ that the contents octets of an associated AttributeValue or
+ AssertionValue OCTET STRING are a complete encoding of the relevant
+ value according to the encoding method specified by the option.
+
+ Where a transfer encoding option is present in an attribute
+ description the associated attribute values or assertion value MUST
+ be encoded according to the encoding method corresponding to the
+ option. Note that it is possible for a syntax to be defined such
+ that its LDAP-specific encoding is exactly the same as its encoding
+ according to some transfer encoding option (e.g., the LDAP-specific
+ encoding might be defined to be the same as the BER encoding).
+
+ Transfer encoding options are mutually exclusive. An attribute
+ description SHALL NOT contain more than one transfer encoding option,
+ and SHALL NOT contain both a transfer encoding option and the binary
+ option.
+
+ Transfer encoding options are not tagging options [MODELS] so the
+ presence of a transfer encoding option does not specify an attribute
+ subtype. An attribute description containing a transfer encoding
+ option references exactly the same attribute as the same attribute
+ description without the transfer encoding option. The
+ supertype/subtype relationships of attributes with tagging options
+ are not altered in any way by the presence or absence of transfer
+ encoding options.
+
+ An attribute description SHALL be treated as unrecognized if it
+ contains a transfer encoding option and the syntax of the attribute
+ does not have an associated ASN.1 type [SYNTAX], or if the nominated
+
+
+
+Legg Expires 16 December 2004 [Page 4]
+
+INTERNET-DRAFT LDAP: Transfer Encoding Options June 16, 2004
+
+
+ encoding is not supported for that type.
+
+ The presence or absence of a transfer encoding option only affects
+ the transfer of attribute and assertion values in protocol; servers
+ store any particular attribute value in a single format of their
+ choosing.
+
+4. Defined Transfer Encoding Options
+
+ The attribute option string "transfer-ber" specifies that the
+ associated attribute values or assertion value are (to be) encoded
+ according to the Basic Encoding Rules [X690] of ASN.1. This option
+ is similar to the binary option [BINARY], however servers are more
+ restricted in when they can use "transfer-ber" which leads to more
+ predictability in the results returned to clients who request
+ "transfer-ber".
+
+ The attribute option string "transfer-der" specifies that the
+ associated attribute values or assertion value are (to be) encoded
+ according to the Distinguished Encoding Rules [X690] of ASN.1.
+
+ The attribute option string "transfer-gser" specifies that the
+ associated attribute values or assertion value are (to be) encoded
+ according to the Generic String Encoding Rules (GSER) [RFC3641].
+
+ The attribute option string "transfer-rxer" specifies that the
+ associated attribute values or assertion value are (to be) encoded as
+ an XML document [XML]. The [local name] of the [document element] of
+ the document information item representing the associated value SHALL
+ be the identifier of the NamedType [X680] in the LDAP ASN.1
+ specification [PROT] defining the associated attribute value or
+ assertion value, or "item" if the associated value isn't in a
+ NamedType. This means:
+
+ - for an AttributeValue the identifier is "value" in every case,
+
+ - for an AssertionValue in an AttributeValueAssertion the identifier
+ is "assertionValue",
+
+ - for an AssertionValue in a SubstringFilter the identifier is
+ "initial", "any" or "final", as appropriate,
+
+ - for an AssertionValue in a MatchingRuleAssertion the identifier is
+ "matchValue".
+
+ The [namespace name] of the [document element] SHALL have no value.
+ The content of the [document element] is the Robust XML Encoding
+ Rules (RXER) [RXER] encoding of the associated attribute or assertion
+
+
+
+Legg Expires 16 December 2004 [Page 5]
+
+INTERNET-DRAFT LDAP: Transfer Encoding Options June 16, 2004
+
+
+ value. Note that the enclosing element for the RXER encoding has the
+ form it would take in an XLDAP operation [XLDAP].
+
+ Note that, like all attribute options, the strings representing
+ transfer encoding options are case insensitive.
+
+ All future registrations of option strings for transfer encoding
+ options should use the "transfer-" prefix so that LDAP clients and
+ servers can recognize that an option is a transfer encoding option
+ even though the particular encoding rules may be unrecognized.
+
+5. Attributes Returned in a Search
+
+ An LDAP search request [PROT] contains a list of the attributes (the
+ requested attributes list) to be returned from each entry matching
+ the search filter. An attribute description in the requested
+ attributes list also implicitly requests all subtypes of the
+ attribute type in the attribute description, whether through
+ attribute subtyping or attribute tagging option subtyping [MODELS].
+
+ The requested attributes list MAY contain attribute descriptions with
+ a transfer encoding option, but MUST NOT contain two attribute
+ descriptions with the same attribute type and the same tagging
+ options (even if only one of them has a transfer encoding option). A
+ transfer encoding option in an attribute description in the requested
+ attributes list implicitly applies to the subtypes of the attribute
+ type in the attribute description.
+
+ If the list of attributes in a search request is empty, or contains
+ the special attribute description string "*", then all user
+ attributes are requested to be returned.
+
+ In general, it is possible for a particular attribute to be
+ explicitly requested by an attribute description and/or implicitly
+ requested by the attribute descriptions of one or more of its
+ supertypes. In such cases the effective transfer encoding being
+ requested for a particular attribute is determined by the transfer
+ encoding option (or lack thereof) in the most specific attribute
+ description in the requested attributes list that applies to the
+ attribute.
+
+ An applicable attribute description with an actual attribute type is
+ more specific than the special attribute description string "*".
+
+ If the attribute type of one applicable attribute description is a
+ direct or indirect subtype of the attribute type in another
+ applicable attribute description then the former attribute
+ description is more specific than the latter attribute description.
+
+
+
+Legg Expires 16 December 2004 [Page 6]
+
+INTERNET-DRAFT LDAP: Transfer Encoding Options June 16, 2004
+
+
+ If two applicable attribute descriptions have the same attribute type
+ and the tagging options of one attribute description are a superset
+ of the tagging options of the other attribute description then the
+ former attribute description is more specific than the latter
+ attribute description.
+
+ Attributes MUST either be returned in the effective transfer encoding
+ requested, be returned with no attribute values, or be omitted from
+ the results. An attribute SHALL NOT be returned using an encoding
+ other than the effective transfer encoding requested.
+
+ Regardless of the encoding chosen, a particular attribute value is
+ returned at most once.
+
+6. Syntaxes Requiring Binary Transfer
+
+ Certain syntaxes are required to be transferred in the BER encoded
+ form. These syntaxes are said to have a binary transfer requirement.
+ The Certificate, Certificate List, Certificate Pair and Supported
+ Algorithm syntaxes [PKI] are examples of syntaxes with a binary
+ transfer requirement. These syntaxes also have an additional
+ requirement that the exact BER encoding must be preserved. Note that
+ this is a property of the syntaxes themselves, and not a property of
+ the binary option or any of the transfer encoding options.
+
+ Transfer encoding options SHALL take precedence over the requirement
+ for binary transfer. For example, if the effective transfer encoding
+ requested is say "transfer-gser", then attribute values of a syntax
+ with a binary transfer requirement will be GSER encoded. In the
+ absence of a transfer encoding option the normal rules on binary
+ transfer and the use of the binary option SHALL apply.
+
+7. Security Considerations
+
+ There is a requirement on some attribute syntaxes that the exact BER
+ encoding of values of that syntax be preserved. In general, a
+ transformation from the BER encoding into some other encoding (e.g.,
+ GSER) and back into the BER encoding will not necessarily reproduce
+ exactly the octets of the original BER encoding.
+
+ Applications needing the original BER encoding to be preserved, e.g.,
+ for the verification of digital signatures, MUST NOT request
+ attributes with such a requirement using a transfer encoding option.
+ These attributes MUST be requested explicitly or implicitly with the
+ binary option, or implicitly without the binary option (or any
+ transfer encoding option).
+
+ When interpreting security-sensitive fields, and in particular fields
+
+
+
+Legg Expires 16 December 2004 [Page 7]
+
+INTERNET-DRAFT LDAP: Transfer Encoding Options June 16, 2004
+
+
+ used to grant or deny access, implementations MUST ensure that any
+ matching rule comparisons are done on the underlying abstract value,
+ regardless of the particular encoding used.
+
+8. IANA Considerations
+
+ The Internet Assigned Numbers Authority (IANA) is requested to update
+ the LDAP attribute description option registry [BCP64] as indicated
+ by the following templates:
+
+ Subject: Request for
+ LDAP Attribute Description Option Registration
+ Option Name: transfer-ber
+ Family of Options: NO
+ Person & email address to contact for further information:
+ Steven Legg <steven.legg at adacel.com.au>
+ Specification: RFC XXXX
+ Author/Change Controller: IESG
+ Comments:
+
+ Subject: Request for
+ LDAP Attribute Description Option Registration
+ Option Name: transfer-der
+ Family of Options: NO
+ Person & email address to contact for further information:
+ Steven Legg <steven.legg at adacel.com.au>
+ Specification: RFC XXXX
+ Author/Change Controller: IESG
+ Comments:
+
+ Subject: Request for
+ LDAP Attribute Description Option Registration
+ Option Name: transfer-gser
+ Family of Options: NO
+ Person & email address to contact for further information:
+ Steven Legg <steven.legg at adacel.com.au>
+ Specification: RFC XXXX
+ Author/Change Controller: IESG
+ Comments:
+
+ Subject: Request for
+ LDAP Attribute Description Option Registration
+ Option Name: transfer-rxer
+ Family of Options: NO
+ Person & email address to contact for further information:
+ Steven Legg <steven.legg at adacel.com.au>
+ Specification: RFC XXXX
+ Author/Change Controller: IESG
+
+
+
+Legg Expires 16 December 2004 [Page 8]
+
+INTERNET-DRAFT LDAP: Transfer Encoding Options June 16, 2004
+
+
+ Comments:
+
+9. References
+
+9.1. Normative References
+
+ [KEYWORD] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [BCP64] Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
+ Considerations for the Lightweight Directory Access
+ Protcol (LDAP)", BCP 64, RFC 3383, September 2002.
+
+ [ROADMAP] Zeilenga, K., "Lightweight Directory Access Protocol
+ (LDAP): Technical Specification Road Map",
+ draft-ietf-ldapbis-roadmap-xx.txt, a work in progress,
+ June 2004.
+
+ [MODELS] Zeilenga, K., "LDAP: Directory Information Models",
+ draft-ietf-ldapbis-models-xx.txt, a work in progress, June
+ 2004.
+
+ [PROT] Sermersheim, J., "LDAP: The Protocol",
+ draft-ietf-ldapbis-protocol-xx.txt, a work in progress,
+ May 2004.
+
+ [SYNTAX] Legg, S. and K. Dally, "Lightweight Directory Access
+ Protocol (LDAP): Syntaxes and Matching Rules",
+ draft-ietf-ldapbis-syntaxes-xx.txt, a work in progress,
+ May 2004.
+
+ [RFC3641] Legg, S., "Generic String Encoding Rules (GSER) for ASN.1
+ Types", RFC 3641, October 2003.
+
+ [BINARY] Legg, S., "Lightweight Directory Access Protocol (LDAP):
+ The Binary Encoding Option",
+ draft-legg-ldap-binary-xx.txt, a work in progress, June
+ 2004.
+
+ [RXER] Legg, S. and D. Prager, "Robust XML Encoding Rules for
+ ASN.1 Types", draft-legg-xed-rxer-00.txt, a work in
+ progress, June 2004.
+
+ [X680] ITU-T Recommendation X.680 (07/02) | ISO/IEC 8824-1,
+ Information technology - Abstract Syntax Notation One
+ (ASN.1): Specification of basic notation.
+
+ [X690] ITU-T Recommendation X.690 (07/02) | ISO/IEC 8825-1,
+
+
+
+Legg Expires 16 December 2004 [Page 9]
+
+INTERNET-DRAFT LDAP: Transfer Encoding Options June 16, 2004
+
+
+ Information Technology - ASN.1 encoding rules:
+ Specification of Basic Encoding Rules (BER), Canonical
+ Encoding Rules (CER) and Distinguished Encoding Rules
+ (DER).
+
+ [XML] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E. and
+ F. Yergeau, "Extensible Markup Language (XML) 1.0 (Third
+ Edition)", W3C Recommendation,
+ http://www.w3.org/TR/2004/REC-xml-20040204, February 2004.
+
+ [ISET] Cowan, J. and R. Tobin, "XML Information Set",
+ http://www.w3.org/TR/2001/REC-xml-infoset-20011024,
+ October 2001.
+
+9.2. Informative References
+
+ [XLDAP] Legg, S. and D. Prager, "The XML Enabled Directory:
+ Protocols", draft-legg-xed-protocols-xx.txt, a work in
+ progress, May 2004.
+
+Author's Address
+
+ Steven Legg
+ Adacel Technologies Ltd.
+ 250 Bay Street
+ Brighton, Victoria 3186
+ AUSTRALIA
+
+ Phone: +61 3 8530 7710
+ Fax: +61 3 8530 7888
+ Email: steven.legg at adacel.com.au
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2004). This document is subject
+ to the rights, licenses and restrictions contained in BCP 78, and
+ except as set forth therein, the authors retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+
+
+
+Legg Expires 16 December 2004 [Page 10]
+
+INTERNET-DRAFT LDAP: Transfer Encoding Options June 16, 2004
+
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr at ietf.org.
+
+Changes in Draft 01
+
+ A transfer encoding option for RXER has been added.
+
+Changes in Draft 02
+
+ The local name of the root element of the XML document representing
+ an attribute value encoded according to the transfer-rxer encoding
+ option has been changed from "item" to "value" to align with
+ revisions to the LDAP protocol specification [PROT].
+
+ The Directory XML Encoding Rules (DXER) have been renamed to the
+ Robust XML Encoding Rules (RXER).
+
+Changes in Draft 03
+
+ The special attribute description strings that consist of the
+ asterisk character followed by a transfer encoding option, e.g.,
+ "*;transfer-ber", "*;transfer-gser", have been removed from this
+ specification. An LDAP control will be defined in a separate
+ document to provide equivalent functionality.
+
+
+
+
+
+
+
+
+Legg Expires 16 December 2004 [Page 11]
+
+
Added: openldap/vendor/openldap-release/doc/drafts/draft-sermersheim-ldap-chaining-xx.txt
===================================================================
--- openldap/vendor/openldap-release/doc/drafts/draft-sermersheim-ldap-chaining-xx.txt (rev 0)
+++ openldap/vendor/openldap-release/doc/drafts/draft-sermersheim-ldap-chaining-xx.txt 2007-09-15 10:38:52 UTC (rev 844)
@@ -0,0 +1,406 @@
+
+Internet Draft J. Sermersheim
+Personal Submission R. Harrison
+Intended Category: Standard Track Novell, Inc
+Document: draft-sermersheim-ldap-chaining-02.txt Feb 2004
+
+
+
+ LDAP Control to Specify Chaining Behavior
+
+
+Status of this Memo
+
+ This document is an Internet-Draft and is in full conformance with
+ all provisions of Section 10 of RFC2026.
+
+ Internet-Drafts are working documents of the Internet Engineering
+ Task Force (IETF), its areas, and its working groups. Note that other
+ groups may also distribute working documents as Internet-Drafts.
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference
+ material or to cite them other than as "work in progress."
+
+ The list of current Internet-Drafts can be accessed at
+ http://www.ietf.org/ietf/1id-abstracts.txt
+
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html.
+
+ Distribution of this memo is unlimited. Technical discussion of this
+ document will take place on the IETF LDAP Extensions Working Group
+ mailing list <ldapext at ietf.org>. Editorial comments may be sent to
+ the author <jimse at novell.com>.
+
+
+Abstract
+
+ This document describes a Lightweight Directory Access Protocol
+ (LDAP) request control that allows specification of chaining behavior
+ for LDAP operations. By using the control with various LDAP
+ operations, a directory client (DUA), or directory server (DSA)
+ specifies whether or not a DSA or secondary DSA chains operations to
+ other DSAs or returns referrals and/or search result references to
+ the client.
+
+
+1. Introduction
+
+ Many directory servers have the ability through the use of various
+ mechanisms to participate in a distributed directory model. A
+ distributed directory is one where the DIT is distributed over
+ multiple DSAs. One operation completion mechanism used by DSAs in a
+ distributed directory is chaining. Chaining is defined in [X.518],
+ and is the act of one DSA communicating a directory operation that
+
+Sermersheim, Harrison Internet-Draft - Exp. Aug 2004 Page 1
+ LDAP Control to Specify Chaining Behavior
+
+ originated from a DUA to another DSA in a distributed directory.
+ Contrast this with the act of passing referrals (4.1.11 of [RFC2251])
+ and SearchResultReferences (4.5.2 of [RFC2251]) back to the client.
+ Chaining may happen during the name resolution part of an operation
+ or during other parts of operations like search which apply to a
+ number of entries in a subtree.
+
+ This document does not attempt to define the distributed directory
+ model, nor does it attempt to define the manner in which DSAs chain
+ requests. This document defines a request control that the client can
+ use to specify whether parts of an operation should or should not be
+ chained.
+
+
+2. Conventions
+
+ The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
+ used in this document carry the meanings described in [RFC2119].
+
+ The term chaining may apply to uni-chaining as well as multi-chaining
+ (see [X.518]) depending on the capabilities and configuration of the
+ DSAs.
+
+
+3. The Control
+
+ Support for the control is advertised by the presence of its
+ controlType in the supportedControl attribute of a server's root DSE.
+
+ This control MAY be included in any LDAP request operation except
+ abandon, unbind, and StartTLS as part of the controls field of the
+ LDAPMessage, as defined in Section 4.1.12 of [RFC2251]:
+
+ The controlType is set to <IANA-ASSIGNED-OID.1>. The criticality MAY
+ be set to either TRUE or FALSE. The controlValue is an OCTET STRING,
+ whose value is the following ChainingBehavior type, BER encoded
+ following the rules in Section 5.1 of [RFC2251]:
+
+ ChainingBehavior ::= SEQUENCE {
+ resolveBehavior Behavior OPTIONAL,
+ continuationBehavior Behavior OPTIONAL }
+
+ Behavior :: = ENUMERATED {
+ chainingPreferred (0),
+ chainingRequired (1),
+ referralsPreferred (2),
+ referralsRequired (3) }
+
+ resolveBehavior instructs the DSA what to do when a referral is
+ encountered during the local name resolution part of an operation. If
+ this field is not specified, other policy dictates the DSA's
+ behavior.
+
+
+
+Sermersheim, Harrison Internet-Draft - Exp. Aug 2004 Page 2
+ LDAP Control to Specify Chaining Behavior
+
+ continuationBehavior instructs the DSA what to do when a referral is
+ encountered after the name resolution part of an operation has
+ completed. This scenario occurs during search operations, and may
+ occur during yet to be defined future operations. If this field is
+ not specified, other policy dictates the DSA's behavior.
+
+ Behavior specifies whether the DSA should chain the operation or
+ return referrals when a target object is held by a remote service.
+
+ chainingPreferred indicates that the preference is that
+ chaining, rather than referrals, be used to provide the service.
+ When this value is set, the server attempts to chain the request
+ but if it can't it returns referrals.
+
+ chainingRequired indicates that chaining is to be used rather
+ than referrals to service the request. When this value is set,
+ the server MUST NOT return referrals. It either chains the
+ request or fails.
+
+ referralsPreferred indicates that the client wishes to receive
+ referrals rather than allow the server to chain the operation.
+ When this value is set, the server return referrals and search
+ references when possible, but may chain the operation otherwise.
+
+ referralsRequired indicates that chaining is prohibited. When
+ this value is set, the server MUST NOT chain the request to
+ other DSAs. Instead it returns referrals as necessary, or fails.
+
+ The following list assigns meanings to some of the result codes that
+ may occur due to this control being present:
+
+ - chainingRequired (IANA-ASSIGNED-1) Unable to process without
+ chaining.
+ - cannotChain (IANA-ASSIGNED-2) Unable to chain the request.
+
+
+4. Notes to Implementors
+
+ <todo: add some>
+
+
+4.1 Unbind and Abandon
+
+ Clients MUST NOT include the ChainingBehavior control with an Abandon
+ operation or an Unbind operation. Servers MUST ignore any chaining
+ control on the abandon and unbind requests. Servers that chain
+ operation are responsible to keep track of where an operation was
+ chained to for the purposes of unbind and abandon.
+
+
+4.2 StartTLS
+
+ This operation cannot be chained because the TLS handshake protocol
+ does not allow man-in-the-middle attacks.
+
+Sermersheim, Harrison Internet-Draft - Exp. Aug 2004 Page 3
+ LDAP Control to Specify Chaining Behavior
+
+
+
+5. Relationship with other Extensions
+
+ This control MAY be used with other controls or with extended
+ operations. When it is used with other controls or with extended
+ operations not listed here, server behavior is undefined unless
+ otherwise specified.
+
+
+5.1 Relationship with ManageDsaIT
+
+ When this control is used along with the ManageDsaIT control, the
+ resolveBehavior value is evaluated. If resolveBehavior is such that
+ chaining is allowed, the DSA is allowed to chain the operation as
+ necessary until the last RDN is found.
+
+ For example: DSA1 holds the naming context <dc=net> and a subordinate
+ reference to <dc=example,dc=net>, DSA2 holds the naming context
+ <dc=example,dc=net> and a subordinate reference to
+ <dc=hostc,dc=example,dc=net>.
+
+ A modify operation accompanied by the ManageDsaIT control alone is
+ sent to DSA1. The base object of the modify operation is set to
+ <dc=hostc,dc=example,dc=net>. Since DSA1 does not hold the
+ <dc=hostc,dc=example,dc=net> IT DSE, a referral is returned for
+ <dc=example,dc=net>.
+
+ Next, the same modify operation is accompanied by both the
+ ManageDsaIT and the ChainingBehavior control where the
+ ChainingBehavior.resolveBehavior is set to chainingPreferred. In this
+ case, DSA1 chains to DSA2 when it encounters <dc=example,dc=net> and
+ DSA2 continues the operation. Since DSA2 holds the IT DSE
+ <dc=hostc,dc=example,dc=net>, the resolve portion completes, and the
+ rest of the operation proceeds.
+
+
+6. Security Considerations
+
+ Because this control directs a DSA to chain requests to other DSAs,
+ it may be used in a denial of service attack. Implementers should be
+ cognizant of this possibility.
+
+ This control may be used to allow access to hosts and portions of the
+ DIT not normally available to clients. Servers supporting this
+ control should provide sufficient policy to prevent unwanted
+ occurrences of this.
+
+
+7. IANA Considerations
+
+ Registration of the following values is requested [RFC3383].
+
+
+
+Sermersheim, Harrison Internet-Draft - Exp. Aug 2004 Page 4
+ LDAP Control to Specify Chaining Behavior
+
+7.1. Object Identifiers
+
+ It is requested that IANA register upon Standards Action an LDAP
+ Object Identifier in identifying the protocol elements defined in
+ this technical specification. The following registration template is
+ suggested:
+
+ Subject: Request for LDAP OID Registration
+ Person & email address to contact for further information:
+ Jim Sermersheim
+ jimse at novell.com
+ Specification: RFCXXXX
+ Author/Change Controller: IESG
+ Comments:
+ One delegation will be made under the assigned OID:
+
+ IANA-ASSIGNED-OID.1 Chaining Behavior Request Control
+
+
+7.2. LDAP Protocol Mechanism
+
+ It is requested that IANA register upon Standards Action the LDAP
+ protocol mechanism described in this document. The following
+ registration template is suggested:
+
+ Subject: Request for LDAP Protocol Mechanism Registration
+ Object Identifier: IANA-ASSIGNED-OID.1
+ Description: Chaining Behavior Request Control
+ Person & email address to contact for further information:
+ Jim Sermersheim
+ jimse at novell.com
+ Usage: Control
+ Specification: RFCXXXX
+ Author/Change Controller: IESG
+ Comments: none
+
+
+7.3. LDAP Result Codes
+
+ It is requested that IANA register upon Standards Action the LDAP
+ result codes:
+
+ chainingRequired (IANA-ASSIGNED-1)
+ cannotChain (IANA-ASSIGNED-2)
+
+ The following registration template is suggested:
+
+ Subject: LDAP Result Code Registration
+ Person & email address to contact for further information:
+ Jim Sermersheim
+ jimse at novell.com
+ Result Code Name: chainingRequired
+ Result Code Name: cannotChain
+ Specification: RFCXXXX
+
+Sermersheim, Harrison Internet-Draft - Exp. Aug 2004 Page 5
+ LDAP Control to Specify Chaining Behavior
+
+ Author/Change Controller: IESG
+ Comments: request consecutive result codes be assigned
+
+
+8. Normative References
+
+ [X.518]
+ ITU-T Rec. X.511, "The Directory: Abstract Service Definition", 1993.
+
+ [RFC2119]
+ Bradner, Scott, "Key Words for use in RFCs to Indicate Requirement
+ Levels", Internet Draft, March 1997.
+ Available as RFC2119.
+
+ [RFC2251]
+ Wahl, M, S. Kille and T. Howes, "Lightweight Directory Access
+ Protocol (v3)", Internet Standard, December, 1997.
+ Available as RFC2251.
+
+
+9. Authors' Addresses
+
+ Jim Sermersheim
+ Novell, Inc.
+ 1800 South Novell Place
+ Provo, Utah 84606, USA
+ jimse at novell.com
+ +1 801 861-3088
+
+ Roger Harrison
+ Novell, Inc.
+ 1800 South Novell Place
+ Provo, Utah 84606, USA
+ rharrison at novell.com
+ +1 801 861-2642
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sermersheim, Harrison Internet-Draft - Exp. Aug 2004 Page 6
+ LDAP Control to Specify Chaining Behavior
+
+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 Statement
+
+ Copyright (C) The Internet Society (2004). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain
+ it or assist in its implementation may be prepared, copied,
+ published and distributed, in whole or in part, without restriction
+ of any kind, provided that the above copyright notice and this
+ paragraph are included on all such copies and derivative works.
+ However, this document itself may not be modified in any way, such
+ as by removing the copyright notice or references to the Internet
+ Society or other Internet organizations, except as needed for the
+ purpose of developing Internet standards in which case the
+ procedures for copyrights defined in the Internet Standards process
+ must be followed, or as required to translate it into languages
+ other than English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on
+ an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
+ IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
+ THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+
+
+Sermersheim, Harrison Internet-Draft - Exp. Aug 2004 Page 7
+
Added: openldap/vendor/openldap-release/doc/drafts/draft-sermersheim-ldap-csn-xx.txt
===================================================================
--- openldap/vendor/openldap-release/doc/drafts/draft-sermersheim-ldap-csn-xx.txt (rev 0)
+++ openldap/vendor/openldap-release/doc/drafts/draft-sermersheim-ldap-csn-xx.txt 2007-09-15 10:38:52 UTC (rev 844)
@@ -0,0 +1,898 @@
+
+
+
+
+Network Working Group J. Sermersheim
+Internet-Draft Novell, Inc
+Expires: August 5, 2005 H. Chu
+ Symas Corp.
+ February 2005
+
+
+ The LDAP Change Sequence Number
+ draft-sermersheim-ldap-csn-02.txt
+
+Status of this Memo
+
+ By submitting this Internet-Draft, each author represents that any
+ applicable patent or other IPR claims of which he or she is aware
+ have been or will be disclosed, and any of which he or she becomes
+ aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+ Internet-Drafts are working documents of the Internet Engineering
+ Task Force (IETF), its areas, and its working groups. Note that
+ other groups may also distribute working documents as Internet-
+ Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference
+ material or to cite them other than as "work in progress."
+
+ The list of current Internet-Drafts can be accessed at
+ http://www.ietf.org/ietf/1id-abstracts.txt.
+
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html.
+
+ This Internet-Draft will expire on August 5, 2005.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2005).
+
+Abstract
+
+ This document defines a syntax schema element for the Lightweight
+ Directory Access Protocol (LDAP) which is used to hold a Change
+ Sequence Number (CSN). In general, a change sequence number
+ represents the place and time that a directory entity was changed.
+ It may be used by various attributes for various LDAP replication,
+ and synchronization applications.
+
+
+
+
+Sermersheim & Chu Expires August 5, 2005 [Page 1]
+
+Internet-Draft LDAP CSN February 2005
+
+
+Discussion Forum
+
+ Technical discussion of this document will take place on the IETF
+ LDAP Extensions mailing list <ldapext at ietf.org>. Please send
+ editorial comments directly to the author(s).
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . 3
+ 2. Conventions . . . . . . . . . . . . . . . . . . . . . 4
+ 3. Syntaxes . . . . . . . . . . . . . . . . . . . . . . . 5
+ 3.1. ChangeSequenceNumber Syntax . . . . . . . . . . . . . 5
+ 3.2. UTF8String . . . . . . . . . . . . . . . . . . . . . . 6
+ 4. Matching Rules . . . . . . . . . . . . . . . . . . . . 7
+ 4.1. changeSequenceNumberMatch Matching Rule . . . . . . . 7
+ 4.2. utf8CodePointMatch Matching Rule . . . . . . . . . . . 7
+ 4.3. changeSequenceNumberOrderingMatch Matching Rule . . . 7
+ 4.4. utf8CodePointOrderingMatch Matching Rule . . . . . . . 8
+ 5. Attributes . . . . . . . . . . . . . . . . . . . . . . 9
+ 5.1. entryCSN Attribute . . . . . . . . . . . . . . . . . . 9
+ 6. Security Considerations . . . . . . . . . . . . . . . 10
+ 7. Normative References . . . . . . . . . . . . . . . . . 10
+ Appendix A. IANA Considerations . . . . . . . . . . . . . . . . . 11
+ A.1. LDAP Object Identifier Registrations . . . . . . . . . 11
+ A.2. LDAP Descriptor Registrations . . . . . . . . . . . . 11
+ Authors' Addresses . . . . . . . . . . . . . . . . . . 15
+ Intellectual Property and Copyright Statements . . . . 16
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sermersheim & Chu Expires August 5, 2005 [Page 2]
+
+Internet-Draft LDAP CSN February 2005
+
+
+1. Introduction
+
+ A number of technologies have been documented, implemented and
+ experimented with which in one way or another seek to replicate, or
+ synchronize directory data. A common need among these technologies
+ is to determine which of two copies of an element represents the
+ latest or most authoritative data. Part of meeting this need
+ involves associating a change sequence number to an element copy at
+ the time of an update to that element. When replication or
+ synchronization occurs, the change sequence numbers associated with
+ directory elements can be used to decide which element's data will be
+ copied to the other element(s).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sermersheim & Chu Expires August 5, 2005 [Page 3]
+
+Internet-Draft LDAP CSN February 2005
+
+
+2. Conventions
+
+ Imperative keywords defined in [RFC2119] are used in this document,
+ and carry the meanings described there.
+
+ The General Considerations of [I-D.ietf-ldapbis-syntaxes] apply to
+ the syntax definition in this document.
+
+ The terms "directory element" and "element" refer to data held in a
+ directory and may apply to an attribute value, attribute, entry, or
+ any other identifiable directory entity.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sermersheim & Chu Expires August 5, 2005 [Page 4]
+
+Internet-Draft LDAP CSN February 2005
+
+
+3. Syntaxes
+
+3.1. ChangeSequenceNumber Syntax
+
+ A value of the ChangeSequenceNumber syntax is the time of a change
+ along with a replicaID which represents the Directory System Agent
+ (DSA) holding the element when it was changed. There are also two
+ sequence numbers used to disambiguate directory entities that are
+ changed at the same time and place.
+
+ The Abstract Syntax Notation One (ASN.1)[X680] type corresponding to
+ this syntax is defined as follows:
+
+ ChangeSequenceNumber ::= SEQUENCE {
+
+ time GeneralizedTime,
+
+ timeCount INTEGER (0 .. MaxInt),
+
+ replicaID UTF8String,
+
+ changeCount INTEGER (0 .. MaxInt)}
+
+ MaxInt INTEGER ::= 2147483647 -- (2^^31 - 1) --
+
+ GeneralizedTime is defined in [X680]. Local time without a
+ differential SHALL NOT be used.
+
+ UTF8String is defined below.
+
+ The LDAP-specific encoding of a value of this syntax is the Generic
+ String Encoding Rules (GSER)[RFC3641] encoding of the ASN.1 type.
+
+ Example:
+
+ { time "196701160315-0700",
+
+ timeCount 0,
+
+ replicaID "DSA666",
+
+ changeCount 1 }
+
+ The following is an LDAP syntax description [RFC2252] suitable for
+ publication in the subschema.
+
+ ( IANA-ASSIGNED-OID.1 DESC 'ChangeSequenceNumber' )
+
+
+
+
+Sermersheim & Chu Expires August 5, 2005 [Page 5]
+
+Internet-Draft LDAP CSN February 2005
+
+
+3.2. UTF8String
+
+ The UTF8String syntax is used to express a string of characters from
+ the [ISO.10646-1.1993] character set (a superset of [Unicode]),
+ encoded following the [UTF-8] algorithm. Note that Unicode
+ characters U+0000 through U+007F are the same as ASCII 0 through 127,
+ respectively, and have the same single octet UTF-8 encoding. Other
+ Unicode characters have a multiple octet UTF-8 encoding.
+
+ UTF8String::= OCTET STRING -- UTF-8 encoded,
+
+ -- [ISO10646] characters
+
+ The LDAP-specific encoding of a value of this syntax are the UTF-8
+ encoded characters themselves.
+
+ The following is an LDAP syntax description [RFC2252] suitable for
+ publication in the subschema.
+
+ ( IANA-ASSIGNED-OID.2 DESC 'UTF8String' )
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sermersheim & Chu Expires August 5, 2005 [Page 6]
+
+Internet-Draft LDAP CSN February 2005
+
+
+4. Matching Rules
+
+4.1. changeSequenceNumberMatch Matching Rule
+
+ The changeSequenceNumberMatch rule compares an assertion value of the
+ ChangeSequenceNumber syntax to a value of a syntax (e.g the
+ ChangeSequenceNumber syntax) whose corresponding ASN.1 type is
+ ChangeSequenceNumber.
+
+ The rule evaluates to TRUE if and only if each of the components of
+ the two values evaluate to TRUE using the following rules:
+
+ o The time component uses generalizedTimeMatch.
+
+ o The timeCount and changeCount components use integerMatch.
+
+ o The replicaID component uses utf8CodePointMatch.
+
+ The following is a LDAP matching rule description [RFC2252] suitable
+ for publication in the subschema.
+
+ ( IANA-ASSIGNED-OID.3 NAME changeSequenceNumberMatch SYNTAX IANA-
+ ASSIGNED-OID.1 )
+
+4.2. utf8CodePointMatch Matching Rule
+
+ The utf8CodePointMatch rule compares an assertion value of the
+ UTF8String syntax to a value of a syntax (e.g the UTF8String syntax)
+ whose corresponding ASN.1 type is UTF8String. The rule evaluates to
+ TRUE if and only if the code points [Unicode] of each of the
+ characters is equal.
+
+ The following is a LDAP matching rule description [RFC2252] suitable
+ for publication in the subschema.
+
+ ( IANA-ASSIGNED-OID.4 NAME utf8CodePointMatch SYNTAX IANA-ASSIGNED-
+ OID.2 )
+
+4.3. changeSequenceNumberOrderingMatch Matching Rule
+
+ The changeSequenceNumberOrderingMatch rule compares the
+ ChangeSequenceNumber ordering of an assertion value of the
+ ChangeSequenceNumber syntax to a value of a syntax (e.g the
+ ChangeSequenceNumber syntax) whose corresponding ASN.1 type is
+ ChangeSequenceNumber.
+
+ When evaluating ChangeSequenceNumber values for ordering, the
+ components are evaluated in this order: time, timeCount, replicaID,
+
+
+
+Sermersheim & Chu Expires August 5, 2005 [Page 7]
+
+Internet-Draft LDAP CSN February 2005
+
+
+ changeCount. If a component evaluates to TRUE using the appropriate
+ ordering matching rule specified below, then the rule evaluates to
+ TRUE. Otherwise if the component evaluates to TRUE using the
+ equality matching rule specified below, the next component is
+ evaluated. Otherwise the changeSequenceNumberOrderingMatch rule
+ evaluates to FALSE or Undefined as appropriate.
+
+ o The time components of the two values are evaluated for ordering
+ using GeneralizedTimeOrderingMatch, and evaluated for equality
+ using GeneralizedTimeMatch.
+
+ o The timeCount and changeCount components of the two values are
+ evaluated for ordering using integerOrderingMatch, and evaluated
+ for equality using integerMatch.
+
+ o The replicaID components of the two values are evaluated for
+ ordering using utf8CodePointOrderingMatch and evaluated for
+ equality using utf8CodePointMatch.
+
+ The following is a LDAP matching rule description [RFC2252] suitable
+ for publication in the subschema.
+
+ ( IANA-ASSIGNED-OID.5 NAME changeSequenceNumberOrderingMatch SYNTAX
+ SYNTAX IANA-ASSIGNED-OID.1 )
+
+4.4. utf8CodePointOrderingMatch Matching Rule
+
+ The utf8CodePointOrderingMatch rule compares the ordering of an
+ assertion value of the UTF8String syntax to a stored value of a
+ syntax (e.g. the UTF8String syntax) whose corresponding ASN.1 type is
+ UTF8String.
+
+ The rule evaluates to TRUE if, and only if, in the code point
+ collation order, the stored value character string appears earlier
+ than the assertion value character string, i.e., the stored value is
+ "less than" the assertion value.
+
+ The following is a LDAP matching rule description [RFC2252] suitable
+ for publication in the subschema.
+
+ ( IANA-ASSIGNED-OID.6 NAME utf8CodePointOrderingMatch SYNTAX IANA-
+ ASSIGNED-OID.2 )
+
+
+
+
+
+
+
+
+
+Sermersheim & Chu Expires August 5, 2005 [Page 8]
+
+Internet-Draft LDAP CSN February 2005
+
+
+5. Attributes
+
+5.1. entryCSN Attribute
+
+ The entryCSN operational attribute provides the CSN of the last
+ update applied to the entry.
+
+ The following is a LDAP attribute type description [RFC2252] suitable
+ for publication in the subschema.
+
+ ( IANA-ASSIGNED-OID.7 NAME entryCSN DESC 'CSN of the entry content'
+ EQUALITY changeSequenceNumberMatch ORDERING
+ changeSequenceNumberOrderingMatch SYNTAX IANA-ASSIGNED-OID.1 SINGLE-
+ VALUE NO-USER-MODIFICATION USAGE directoryOperation )
+
+ Servers MAY assign a CSN to each entry upon its addition to the
+ directory and provide the entry's CSN as the value of the entryCSN
+ operational attribute. If the entryCSN attribute is assigned, the
+ attribute SHOULD be updated upon every update of the entry.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sermersheim & Chu Expires August 5, 2005 [Page 9]
+
+Internet-Draft LDAP CSN February 2005
+
+
+6. Security Considerations
+
+7. Normative References
+
+ [I-D.ietf-ldapbis-syntaxes]
+ Legg, S., "Lightweight Directory Access Protocol (LDAP):
+ Syntaxes and Matching Rules",
+ draft-ietf-ldapbis-syntaxes-11 (work in progress),
+ June 2005.
+
+ [ISO.10646-1.1993]
+ International Organization for Standardization,
+ "Information Technology - Universal Multiple-octet coded
+ Character Set (UCS) - Part 1: Architecture and Basic
+ Multilingual Plane", ISO Standard 10646-1, May 1993.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2252] Wahl, M., Coulbeck, A., Howes, T., and S. Kille,
+ "Lightweight Directory Access Protocol (v3): Attribute
+ Syntax Definitions", RFC 2252, December 1997.
+
+ [RFC3383] Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
+ Considerations for the Lightweight Directory Access
+ Protocol (LDAP)", BCP 64, RFC 3383, September 2002.
+
+ [RFC3641] Legg, S., "Generic String Encoding Rules (GSER) for ASN.1
+ Types", RFC 3641, October 2003.
+
+ [UTF-8] International Organization for Standardization,
+ "Information Technology - Universal Multiple-octet coded
+ Character Set (UCS) - Amendment 2: UCS Transformation
+ Format 8 (UTF-8)", ISO Standard 10646-1 Addendum 2,
+ October 1996.
+
+ [Unicode] The Unicode Consortium, "The Unicode Standard", 2004.
+
+ [X680] International Telecommunications Union, "Abstract Syntax
+ Notation One (ASN.1): Specification of basic notation",
+ ITU-T Recommendation X.680, July 2002.
+
+
+
+
+
+
+
+
+
+
+Sermersheim & Chu Expires August 5, 2005 [Page 10]
+
+Internet-Draft LDAP CSN February 2005
+
+
+Appendix A. IANA Considerations
+
+ Registration of the following values is requested [RFC3383].
+
+A.1. LDAP Object Identifier Registrations
+
+ It is requested that IANA register upon Standards Action an LDAP
+ Object Identifier in identifying the protocol elements defined in
+ this technical specification. The following registration template is
+ provided:
+
+ Subject: Request for LDAP OID Registration
+
+ Person & email address to contact for further information:
+
+ Jim Sermersheim
+
+ jimse at novell.com
+
+ Specification: RFCXXXX
+
+ Author/Change Controller: IESG
+
+ Comments:
+
+ Seven delegations will be made under the assigned OID:
+
+ IANA-ASSIGNED-OID.1 ChangeSequenceNumber: LDAP Syntax
+
+ IANA-ASSIGNED-OID.2 UTF8String: LDAP Syntax
+
+ IANA-ASSIGNED-OID.3 changeSequenceNumberMatch: LDAP Matching Rule
+
+ IANA-ASSIGNED-OID.4 utf8CodePointMatch: LDAP Matching Rule
+
+ IANA-ASSIGNED-OID.5 changeSequenceNumberOrderingMatch: LDAP
+ Matching Rule
+
+ IANA-ASSIGNED-OID.6 utf8CodePointOrderingMatch: LDAP Matching Rule
+
+ IANA-ASSIGNED-OID.7 entryCSN: LDAP Attribute Type
+
+A.2. LDAP Descriptor Registrations
+
+ It is requested that IANA register upon Standards Action the LDAP
+ descriptors described in this document. The following registration
+ templates are given:
+
+
+
+
+Sermersheim & Chu Expires August 5, 2005 [Page 11]
+
+Internet-Draft LDAP CSN February 2005
+
+
+ Subject: Request for LDAP Descriptor Registration
+
+ Descriptor (short name): ChangeSequenceNumber
+
+ Object Identifier: IANA-ASSIGNED-OID.1
+
+ Person & email address to contact for further information:
+
+ Jim Sermersheim
+
+ jimse at novell.com
+
+ Usage: other
+
+ Specification: RFCXXXX
+
+ Author/Change Controller: IESG
+
+ Comments: LDAP Syntax
+
+ Subject: Request for LDAP Descriptor Registration
+
+ Descriptor (short name): UTF8String
+
+ Object Identifier: IANA-ASSIGNED-OID.2
+
+ Person & email address to contact for further information:
+
+ Jim Sermersheim
+
+ jimse at novell.com
+
+ Usage: other
+
+ Specification: RFCXXXX
+
+ Author/Change Controller: IESG
+
+ Comments: LDAP Syntax
+
+ Subject: Request for LDAP Descriptor Registration
+
+ Descriptor (short name): changeSequenceNumberMatch
+
+ Object Identifier: IANA-ASSIGNED-OID.3
+
+ Person & email address to contact for further information:
+
+
+
+
+Sermersheim & Chu Expires August 5, 2005 [Page 12]
+
+Internet-Draft LDAP CSN February 2005
+
+
+ Jim Sermersheim
+
+ jimse at novell.com
+
+ Usage: other
+
+ Specification: RFCXXXX
+
+ Author/Change Controller: IESG
+
+ Comments: LDAP Matching Rule
+
+ Subject: Request for LDAP Descriptor Registration
+
+ Descriptor (short name): utf8CodePointMatch
+
+ Object Identifier: IANA-ASSIGNED-OID.4
+
+ Person & email address to contact for further information:
+
+ Jim Sermersheim
+
+ jimse at novell.com
+
+ Usage: other
+
+ Specification: RFCXXXX
+
+ Author/Change Controller: IESG
+
+ Comments: LDAP Matching Rule
+
+ Subject: Request for LDAP Descriptor Registration
+
+ Descriptor (short name): changeSequenceNumberOrderingMatch
+
+ Object Identifier: IANA-ASSIGNED-OID.5
+
+ Person & email address to contact for further information:
+
+ Jim Sermersheim
+
+ jimse at novell.com
+
+ Usage: other
+
+ Specification: RFCXXXX
+
+
+
+
+Sermersheim & Chu Expires August 5, 2005 [Page 13]
+
+Internet-Draft LDAP CSN February 2005
+
+
+ Author/Change Controller: IESG
+
+ Comments: LDAP Matching Rule
+
+ Subject: Request for LDAP Descriptor Registration
+
+ Descriptor (short name): utf8CodePointOrderingMatch
+
+ Object Identifier: IANA-ASSIGNED-OID.6
+
+ Person & email address to contact for further information:
+
+ Jim Sermersheim
+
+ jimse at novell.com
+
+ Usage: other
+
+ Specification: RFCXXXX
+
+ Author/Change Controller: IESG
+
+ Comments: LDAP Matching Rule
+
+ Subject: Request for LDAP Descriptor Registration
+
+ Descriptor (short name): entryCSN
+
+ Object Identifier: IANA-ASSIGNED-OID.7
+
+ Person & email address to contact for further information:
+
+ Jim Sermersheim
+
+ jimse at novell.com
+
+ Usage: Attribute Type
+
+ Specification: RFCXXXX
+
+ Author/Change Controller: IESG
+
+ Comments: LDAP Attribute Type
+
+
+
+
+
+
+
+
+Sermersheim & Chu Expires August 5, 2005 [Page 14]
+
+Internet-Draft LDAP CSN February 2005
+
+
+Authors' Addresses
+
+ Jim Sermersheim
+ Novell, Inc
+ 1800 South Novell Place
+ Provo, Utah 84606
+ USA
+
+ Phone: +1 801 861-3088
+ Email: jimse at novell.com
+
+
+ Howard Chu
+ Symas Corp.
+ 18740 Oxnard Street, Suite 313A
+ Tarzana, California 91356
+ USA
+
+ Phone: +1 818 757-7087
+ Email: hyc at symas.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sermersheim & Chu Expires August 5, 2005 [Page 15]
+
+Internet-Draft LDAP CSN February 2005
+
+
+Intellectual Property Statement
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr at ietf.org.
+
+
+Disclaimer of Validity
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+Copyright Statement
+
+ Copyright (C) The Internet Society (2005). This document is subject
+ to the rights, licenses and restrictions contained in BCP 78, and
+ except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+Sermersheim & Chu Expires August 5, 2005 [Page 16]
+
+
Added: openldap/vendor/openldap-release/doc/drafts/draft-sermersheim-ldap-distproc-xx.txt
===================================================================
--- openldap/vendor/openldap-release/doc/drafts/draft-sermersheim-ldap-distproc-xx.txt (rev 0)
+++ openldap/vendor/openldap-release/doc/drafts/draft-sermersheim-ldap-distproc-xx.txt 2007-09-15 10:38:52 UTC (rev 844)
@@ -0,0 +1,2541 @@
+
+Network Working Group J. Sermersheim
+Internet-Draft Novell, Inc
+Expires: August 26, 2005 February 22, 2005
+
+
+
+ Distributed Procedures for LDAP Operations
+ draft-sermersheim-ldap-distproc-02.txt
+
+
+Status of this Memo
+
+
+ This document is an Internet-Draft and is subject to all provisions
+ of Section 3 of RFC 3667. By submitting this Internet-Draft, each
+ author represents that any applicable patent or other IPR claims of
+ which he or she is aware have been or will be disclosed, and any of
+ which he or she become aware will be disclosed, in accordance with
+ RFC 3668.
+
+
+ Internet-Drafts are working documents of the Internet Engineering
+ Task Force (IETF), its areas, and its working groups. Note that
+ other groups may also distribute working documents as
+ Internet-Drafts.
+
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference
+ material or to cite them other than as "work in progress."
+
+
+ The list of current Internet-Drafts can be accessed at
+ http://www.ietf.org/ietf/1id-abstracts.txt.
+
+
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html.
+
+
+ This Internet-Draft will expire on August 26, 2005.
+
+
+Copyright Notice
+
+
+ Copyright (C) The Internet Society (2005).
+
+
+Abstract
+
+
+ This document provides the data types and procedures used while
+ servicing Lightweight Directory Access Protocol (LDAP) user
+ operations in order to participate in a distributed directory. In
+ particular, it describes the way in which an LDAP user operation in a
+ distributed directory environment finds its way to the proper DSA(s)
+ for servicing.
+
+
+
+
+
+Sermersheim Expires August 26, 2005 [Page 1]
+Internet-Draft Distributed Procedures for LDAP Operations February 2005
+
+
+
+Discussion Forum
+
+
+ Technical discussion of this document will take place on the IETF
+ LDAP Extensions mailing list <ldapext at ietf.org>. Please send
+ editorial comments directly to the author.
+
+
+Table of Contents
+
+
+ 1. Distributed Operations Overview . . . . . . . . . . . . . . 3
+ 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 3. Distributed Operation Data Types . . . . . . . . . . . . . . 5
+ 3.1 ContinuationReference . . . . . . . . . . . . . . . . . . . 5
+ 3.2 ChainedRequest . . . . . . . . . . . . . . . . . . . . . . . 9
+ 3.3 Chained Response . . . . . . . . . . . . . . . . . . . . . . 11
+ 4. Distributed Procedures . . . . . . . . . . . . . . . . . . . 14
+ 4.1 Name resolution . . . . . . . . . . . . . . . . . . . . . . 14
+ 4.2 Operation Evaluation . . . . . . . . . . . . . . . . . . . . 16
+ 4.3 Populating the ContinuationReference . . . . . . . . . . . . 19
+ 4.4 Sending a ChainedRequest . . . . . . . . . . . . . . . . . . 21
+ 4.5 Emulating the Sending of a ChainedRequest . . . . . . . . . 23
+ 4.6 Receiving a ChainedRequest . . . . . . . . . . . . . . . . . 24
+ 4.7 Returning a Chained Response . . . . . . . . . . . . . . . . 25
+ 4.8 Receiving a Chained Response . . . . . . . . . . . . . . . . 26
+ 4.9 Returning a Referral or Intermediate Referral . . . . . . . 27
+ 4.10 Acting on a Referral or Intermediate Referral . . . . . . . 30
+ 4.11 Ensuring non-existence of an entry under an nssr . . . . . . 31
+ 4.12 Mapping a referralURI to an LDAP URI . . . . . . . . . . . . 31
+ 4.13 Using the ManageDsaIT control . . . . . . . . . . . . . . . 32
+ 5. Security Considerations . . . . . . . . . . . . . . . . . . 33
+ 6. Normative References . . . . . . . . . . . . . . . . . . . . 33
+ Author's Address . . . . . . . . . . . . . . . . . . . . . . 34
+ A. IANA Considerations . . . . . . . . . . . . . . . . . . . . 35
+ A.1 LDAP Object Identifier Registrations . . . . . . . . . . . . 35
+ A.2 LDAP Protocol Mechanism Registrations . . . . . . . . . . . 35
+ A.3 LDAP Descriptor Registrations . . . . . . . . . . . . . . . 37
+ A.4 LDAP Result Code Registrations . . . . . . . . . . . . . . . 38
+ Intellectual Property and Copyright Statements . . . . . . . 39
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sermersheim Expires August 26, 2005 [Page 2]
+Internet-Draft Distributed Procedures for LDAP Operations February 2005
+
+
+
+1. Distributed Operations Overview
+
+
+ One characteristic of X.500-based directory systems [X500] is that,
+ given a distributed Directory Information Tree (DIT), a user should
+ potentially be able to have any service request satisfied (subject to
+ security, access control, and administrative policies) irrespective
+ of the Directory Service Agent (DSA) to which the request was sent.
+ To accommodate this requirement, it is necessary that any DSA
+ involved in satisfying a particular service request have some
+ knowledge (as specified in {TODO: Link to future Distributed Data
+ Model doc}) of where the requested information is located and either
+ return this knowledge to the requester or attempt to satisfy the
+ request satisfied on the behalf of the requester (the requester may
+ either be a Directory User Agent (DUA) or another DSA).
+
+
+ Two modes of operation distribution are defined to meet these
+ requirements, namely "chaining" and "returning referrals".
+ "Chaining" refers to the attempt by a DSA to satisfy a request by
+ sending one or more chained operations to other DSAs. "Returning
+ referrals", is the act of returning distributed knowledge information
+ to the requester, which may then itself interact with the DSA(s)
+ identified by the distributed knowledge information. It is a goal of
+ this document to provide the same level of service whether the
+ chaining or referral mechanism is used to distribute an operation.
+
+
+ The processing of an operation is talked about in two major phases,
+ namely "name resolution", and "operation evaluation". Name
+ resolution is the act of locating a local DSE held on a DSA given a
+ distinguished name (DN). Operation evaluation is the act of
+ performing the operation after the name resolution phase is complete.
+
+
+ While distributing an operation, a request operation may be
+ decomposed into several sub-operations.
+
+
+ The distributed directory operation procedures described in this
+ document assume the absense of the ManageDsaIT control defined in
+ [RFC3296] and described in Section 4.13.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sermersheim Expires August 26, 2005 [Page 3]
+Internet-Draft Distributed Procedures for LDAP Operations February 2005
+
+
+
+2. Conventions
+
+
+ Imperative keywords defined in [RFC2119] are used in this document,
+ and carry the meanings described there.
+
+
+ All Basic Encoding Rules (BER) [X690] encodings follow the
+ conventions found in Section 5.1 of [RFC2251].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sermersheim Expires August 26, 2005 [Page 4]
+Internet-Draft Distributed Procedures for LDAP Operations February 2005
+
+
+
+3. Distributed Operation Data Types
+
+
+ The data types in this section are used by the chaining and referral
+ distributed operation mechanisms described in Section 4
+
+
+3.1 ContinuationReference
+
+
+ As an operation is being processed by a DSA, it is useful to group
+ the information passed between various procedures as a collection of
+ data. The ContinuationReference data type is introduced for this
+ purpose. This data type is populated and consumed by various
+ procedures discussed in various sections of this document. In
+ general, a ContinuationReference is used when indicating that
+ directory information being acted on is not present locally, but may
+ be present elsewhere.
+
+
+ A ContinuationReference consists of one or more addresses which
+ identify remote DSAs along with other information pertaining both to
+ the distributed knowledge information held on the local DSA as well
+ as information relevant to the operation. This data type is
+ expressed here in Abstract Syntax Notation One (ASN.1) [X680].
+
+
+ ContinuationReference ::= SET {
+ referralURI [0] SET SIZE (1..MAX) OF URI,
+ localReference [2] LDAPDN,
+ referenceType [3] ReferenceType,
+ remainingName [4] RelativeLDAPDN OPTIONAL,
+ searchScope [5] SearchScope OPTIONAL,
+ searchedSubtrees [6] SearchedSubtrees OPTIONAL,
+ failedName [7] LDAPDN OPTIONAL,
+ ... }
+
+
+ <Editor's Note: Planned for addition is a searchCriteria field which
+ is used both for assuring that the remote object is in fact the
+ object originally pointed to (this mechanism provides a security
+ measure), and also to allow moved or renamed remote entries to be
+ found. Typically the search criteria would have a filter value of
+ (entryUUID=<something>)>
+
+
+ URI ::= LDAPString -- limited to characters permitted in URIs
+ [RFC2396].
+
+
+ ReferenceType ::= ENUMERATED {
+ superior (0),
+ subordinate (1),
+ cross (2),
+ nonSpecificSubordinate (3),
+
+
+
+
+
+Sermersheim Expires August 26, 2005 [Page 5]
+Internet-Draft Distributed Procedures for LDAP Operations February 2005
+
+
+
+ suplier (4),
+ master (5),
+ immediateSuperior (6),
+ self (7),
+ ... }
+ SearchScope ::= ENUMERATED {
+ baseObject (0),
+ singleLevel (1),
+ wholeSubtree (2),
+ subordinateSubtree (3),
+ ... }
+
+
+ SearchedSubtrees ::= SET OF RelativeLDAPDN
+
+
+ LDAPDN, RelativeLDAPDN, and LDAPString, are defined in [RFC2251].
+
+
+ The following subsections introduce the fields of the
+ ContinuationReference data type, but do not provide in-depth
+ semantics or instructions on the population and consumption of the
+ fields. These topics are discussed as part of the procedural
+ instructions.
+
+
+3.1.1 ContinuationReference.referralURI
+
+
+ The list of referralURI values is used by the receiver to progress
+ the operation. Each value specifies (at minimum) the protocol and
+ address of one or more remote DSA(s) holding the data sought after.
+ URI values which are placed in ContinuationReference.referralURI must
+ allow for certain elements of data to be conveyed. Section 3.1.1.1
+ describes these data elements. Furthermore, a mapping must exist
+ which relates the parts of a specified URI to these data elements.
+ This document provides such a mapping for the LDAP URL [RFC2255] in
+ Section 4.12.
+
+
+ In some cases, a referralURI will contain data which has a
+ counterpart in the fields of the ContinuationReference (an example is
+ where the referralURI is an LDAP URL, holds a <scope> value, and the
+ ContinuationReference.searchScope field is also present). In these
+ cases, the data held on the referralURI overrides the field in the
+ ContinuationReference. Specific examples of this are highlighted in
+ other sections. Providing a means for these values to exist as
+ fields of the ContinuationReference allows one value to be applied to
+ all values of referralURI (as opposed to populating duplicate data on
+ all referralURI values).
+
+
+ If a referralURI value identifies an LDAP-enabled DSA [RFC3377], the
+ LDAP URL form is used.
+
+
+
+
+
+Sermersheim Expires August 26, 2005 [Page 6]
+Internet-Draft Distributed Procedures for LDAP Operations February 2005
+
+
+
+3.1.1.1 Elements of referralURI Values
+
+
+ The following data elements must be allowed and identified for a
+ specified URI type to be used to convey referral information. Each
+ element is given a name which begins with 'referralURI.' for clarity
+ when referencing the elements conceptually in other parts of this
+ document.
+
+
+ o referralURI.protocolIdentifier. There must be an indication of
+ the protocol to be used to contact the DSA identified by the URI.
+ o referralURI.accessPoint. The URI must identify a DSA in a manner
+ that can be used to contact it using the protocol specified in
+ protocolIdentifier.
+ o referralURI.targetObject. Holds the name to be used as the base
+ DN of the operation being progressed. This field must be allowed
+ by the URI specification, but may be omitted in URI instances for
+ various reasons.
+ o referralURI.localReference. See Section 3.1.2. This field must
+ be allowed by the URI specification, but may be omitted in URI
+ instances for various reasons.
+ o referralURI.searchScope. See Section 3.1.5. This field must be
+ allowed by the URI specification, but may be omitted in URI
+ instances for various reasons.
+ o referralURI.searchedSubtrees. See Section 3.1.6. This field must
+ be allowed by the URI specification, but may be omitted in URI
+ instances for various reasons.
+ o referralURI.failedName. See Section 3.1.7. This field must be
+ allowed by the URI specification, but may be omitted in URI
+ instances for various reasons.
+
+
+3.1.2 ContinuationReference.localReference
+
+
+ This names the DSE which was found to hold distributed knowledge
+ information, and thus which caused the ContinuationReference to be
+ formed. This field is primarily used to help convey the new target
+ object name, but may also be used for purposes referential integrity
+ (not discussed here). In the event that the root object holds the
+ distributed knowledge information, this field is present and is
+ populated with an empty DN.
+
+
+3.1.3 ContinuationReference.referenceType
+
+
+ Indicates the DSE Type of the ContinuationReference.localReference.
+ This field may be used to determine how to progress an operations
+ (i.e. if the value is nonSpecificSubordinate, a search continuation
+ will exclude the ContinuationReference.referenceType).
+
+
+
+
+
+
+Sermersheim Expires August 26, 2005 [Page 7]
+Internet-Draft Distributed Procedures for LDAP Operations February 2005
+
+
+
+3.1.4 ContinuationReference.remainingName
+
+
+ In certain scenarios, the localReference does not completely name the
+ DSE to be used as the new target object name. In these cases,
+ remainingName is populated with the RDNSequence relative to the
+ localReference of the target object name being resolved. Some
+ examples of these scenarios include (but are not restricted to):
+
+
+ o During name resolution, the name is not fully resolved, but a DSE
+ holding distributed knowledge information is found, causing a
+ ContinuationReference to be generated.
+ o While searching, an alias is dereferenced. The aliasedObjectName
+ points to a DSE of type glue which is subordinate to a DSE holding
+ distributed knowledge information.
+
+
+3.1.5 ContinuationReference.searchScope
+
+
+ Under certain circumstances, when progressing a search operation, a
+ search scope different than that of the original search request must
+ be used. This field facilitates the conveyance of the proper search
+ scope to be used when progressing the distributed operation.
+
+
+ The scope of subordinateSubtree has been added to the values allowed
+ by the LDAP SearchRequest.scope field. This scope includes the
+ subtree of entries below the base DN, but does not include the base
+ DN itself. This is used here when progressing distributed search
+ operations caused by the existence of a DSE of type nssr.
+
+
+ If a referralURI.searchScope is present, it overrides this field
+ while that referralURI is being operated upon.
+
+
+3.1.6 ContinuationReference.searchedSubtrees
+
+
+ For ContinuationReferences generated while processing a search
+ operation with a scope of wholeSubtree, each value of this field
+ indicates that a particular subtree below the target object has
+ already been searched. Consumers of this data use it to cause the
+ progression of the search operation to exclude these subtrees as a
+ mechanism to avoid receiving duplicate entries.
+
+
+ If a referralURI.searchedSubtrees is present, it overrides this field
+ while that referralURI is being operated upon.
+
+
+3.1.7 ContinuationReference.failedName
+
+
+ When an operation requires that multiple names be resolved (as is the
+ case with the ModifyDN operation), this field is used to specify
+ which name was found to be non-local.
+
+
+
+
+Sermersheim Expires August 26, 2005 [Page 8]
+Internet-Draft Distributed Procedures for LDAP Operations February 2005
+
+
+
+ If a referralURI.failedName is present, it overrides this field while
+ that referralURI is being operated upon.
+
+
+3.2 ChainedRequest
+
+
+ The Chained Request is sent as an LDAP extended operation. The
+ requestName is IANA-ASSIGNED-OID.1. The requestValue is the BER
+ encoding of the following ChainedRequestValue ASN.1 definition:
+
+
+ ChainedRequestValue ::= SEQUENCE {
+
+
+ chainingArguments ChainingArguments,
+ operationRequest OperationRequest }
+
+
+ ChainingArguments ::= SEQUENCE {
+
+
+ targetObject [0] LDAPDN OPTIONAL,
+ referenceType [1] ReferenceType,
+ traceInformation [2] ChainingTraceInformation,
+ searchScope [3] SearchScope OPTIONAL,
+ searchedSubtrees [4] SearchedSubtrees OPTIONAL}
+
+
+ ChainingTraceInformation ::= SET OF LDAPURL
+
+
+ OperationRequest ::= SEQUENCE {
+
+
+ Request ::= CHOICE {
+
+
+ bindRequest BindRequest,
+ searchRequest SearchRequest,
+ modifyRequest ModifyRequest,
+ addRequest AddRequest,
+ delRequest DelRequest,
+ modDNRequest ModifyDNRequest,
+ compareRequest CompareRequest,
+ extendedReq ExtendedRequest,
+ ... },
+ controls [0] Controls COPTIONAL }
+
+
+ BindRequest, SearchRequest, ModifyRequest, AddRequest, DelRequest,
+ ModifyDNRequest, CompareRequest, ExtendedRequest and Controls are
+ defined in [RFC2251].
+
+
+3.2.1 ChainedRequestValue.chainingArguments
+
+
+ In general, these fields assist in refining the original operation as
+ it is to be executed on the receiving DSA.
+
+
+
+
+
+Sermersheim Expires August 26, 2005 [Page 9]
+Internet-Draft Distributed Procedures for LDAP Operations February 2005
+
+
+
+3.2.1.1 ChainedRequestValue.chainingArguments.targetObject
+
+
+ This field contains the new target (or base) DN for the operation.
+
+
+ The sending DSA populates this under different scenarios including
+ the case where an alias has been dereferenced while resolving the DN,
+ and also the case where a referral carries a target name different
+ from the reference object that caused the referral.
+
+
+ This field can be omitted only if it would be the the same value as
+ the object or base object parameter in the
+ ChainedRequestValue.operationRequest, in which case its implied value
+ is that value.
+
+
+ The receiving DSA examines this field and (if present) uses it rather
+ than the base DN held in the ChainedRequestValue.operationRequest.
+
+
+3.2.1.2 ChainedRequestValue.chainingArguments.referenceType
+
+
+ See Section 3.1.3.
+
+
+ If the receiver encounters a value of nonSpecificSubordinate in this
+ field, it indicates that the operation is being chained due to DSE of
+ type nssr. In this case, the receiver allows (and expects) the base
+ DN to name the immediate superior of a context prefix.
+
+
+3.2.1.3 ChainedRequestValue.chainingArguments.traceInformation
+
+
+ This contains a set of URIs. Each value represents the address of a
+ DSA and DN that has already been contacted while attempting to
+ service the operation. This field is used to detect looping while
+ servicing a distributed operation.
+
+
+ The sending DSA populates this with its own URI, and also the URIs of
+ any DSAs that have already been chained to. The receiving DSA
+ examines this list of URIs and returns a loopDetect error if it finds
+ that any of the addresses and DNs in the listed URI's represent it's
+ own.
+
+
+3.2.1.4 ChainedRequestValue.chainingArguments.searchScope
+
+
+ See Section 3.1.5.
+
+
+3.2.1.5 ChainedRequestValue.chainingArguments.searchedSubtrees
+
+
+ See Section 3.1.6.
+
+
+
+
+
+
+Sermersheim Expires August 26, 2005 [Page 10]
+Internet-Draft Distributed Procedures for LDAP Operations February 2005
+
+
+
+3.2.2 ChainedRequestValue.operationRequest
+
+
+ This holds the original LDAP operation request. This is restricted
+ to a subset of all LDAP operations. Namely, the following LDAP
+ operation types are not allowed:
+
+
+ o Abandon/Cancel operations. When an abandon or cancel operation
+ needs to be chained, it is sent to the remote DSA as-is. This is
+ because there is no need to track it for loop detection or pass on
+ any other information normally found in ChainingArguments.
+ o Unbind. Again, there is no need to send chaining-related
+ information to a DSA to perform an unbind. DSAs which chain
+ operations maintain connections as they see fit.
+ o Chained Operation. When a DSA receives a chained operation, and
+ must again chain that operation to a remote DSA, it sends a
+ ChainedRequest where the ChainedRequestValue.operationRequest is
+ that of the incoming ChainedRequestValue.operationRequest.
+
+
+3.3 Chained Response
+
+
+ The Chained Response is sent as an LDAP IntermediateResponse
+ [RFC3771], or LDAP ExtendedResponse [RFC2251], depending on whether
+ the operation is complete or not. In either case, the responseName
+ is omitted. For intermediate responses, the
+ IntermediateResponse.responseValue is the BER encoding of the
+ ChainedIntermediateResponseValue ASN.1 definition. For completed
+ operations, the ExtendedResponse.value is the BER encoding of the
+ ChainedFinalResponseValue ASN.1 definition.
+
+
+ ChainedIntermediateResponseValue ::= SEQUENCE {
+
+
+ chainedResults ChainingResults,
+ operationResponse IntermediateResponse }
+
+
+ ChainedFinalResponseValue ::= SEQUENCE {
+
+
+ chainedResults ChainingResults,
+ operationResponse FinalResponse }
+
+
+ ChainingResults ::= SEQUENCE {
+
+
+ searchedSubtrees [0] SearchedSubtrees OPTIONAL,
+ ... }
+
+
+ IntermediateResponse ::= SEQUENCE {
+
+
+ Response ::= CHOICE {
+
+
+
+
+
+Sermersheim Expires August 26, 2005 [Page 11]
+Internet-Draft Distributed Procedures for LDAP Operations February 2005
+
+
+
+
+ searchResEntry SearchResultEntry,
+ searchResRef SearchResultReference,
+ intermediateResponse IntermediateResponse
+ ... },
+ controls [0] Controls COPTIONAL }
+
+
+ FinalResponse ::= SEQUENCE {
+
+
+ Response ::= CHOICE {
+
+
+ bindResponse BindResponse,
+ searchResDone SearchResultDone,
+ modifyResponse ModifyResponse,
+ addResponse AddResponse,
+ delResponse DelResponse,
+ modDNResponse ModifyDNResponse,
+ compareResponse CompareResponse,
+ extendedResp ExtendedResponse,
+ ... },
+ controls [0] Controls COPTIONAL }
+
+
+ BindResponse, SearchResultEntry, SearchResultDone,
+ SearchResultReference, ModifyResponse, AddResponse, DelResponse,
+ ModifyDNResponse, CompareResponse, ExtendedResponse, and Controls are
+ defined in [RFC2251]. IntermediateResponse is defined in [RFC3771].
+
+
+3.3.1 ChainingResults
+
+
+ In general, this is used to convey additional information that may
+ needed in the event that the operation needs to be progressed
+ further.
+
+
+3.3.1.1 ChainingResults.searchedSubtrees
+
+
+ Each value of this field indicates that a particular subtree below
+ the target object has already been searched. This is particularly
+ useful while chaining search operations during operation evaluation
+ caused by the presence of a DSA of type nssr. Each DSA referenced by
+ the nssr holds one or more naming contexts subordinate to the nssr
+ DSE. The ChainingResults.searchedSubtrees field allows the DSA being
+ chained to, to inform the sending DSA which subordinate naming
+ contexts have been searched. This information may be passed to
+ further DSAs listed on the nssr in order to reduce the possibility of
+ duplicate entries being returned.
+
+
+
+
+
+
+
+Sermersheim Expires August 26, 2005 [Page 12]
+Internet-Draft Distributed Procedures for LDAP Operations February 2005
+
+
+
+3.3.2 ChainedIntermediateResponseValue.intermediateResponse and
+ ChainedFinalResponseValue.finalResponse
+
+
+ This holds the directory operation response message tied to the
+ ChainedRequestValue.operationRequest.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sermersheim Expires August 26, 2005 [Page 13]
+Internet-Draft Distributed Procedures for LDAP Operations February 2005
+
+
+
+4. Distributed Procedures
+
+
+ For the purposes of describing a distributed operation, operations
+ are said to consist of two major phases -- name resolution and
+ operation evaluation. These terms are adopted from [X518]. Name
+ resolution is the act of locating a DSE said to be held locally by a
+ DSA given a distinguished name (DN). Operation evaluation is the act
+ of performing the operation after the name resolution phase is
+ complete.
+
+
+ Furthermore, there are two modes of distributing an operation --
+ chaining, and returning referrals. Chaining is the act of forwarding
+ an unfinished operation to another DSA for completion (this may
+ happen during name resolution or operation evaluation). In this
+ case, the forwarding DSA sends a chained operation to a receiving
+ DSA, which attempts to complete the operation. Alternately, the DSA
+ may return a referral (or intermediate referral), and the client may
+ use that referral in order to forward the unfinished operation to
+ another DSA. Whether the operation is distributed via chaining or
+ referrals is a decision left to the DSA and or DUA.
+
+
+ The term 'intermediate referral' describes a referral returned during
+ the operation evaluation phase of an operation. These include
+ searchResultReferences, referrals returned with an
+ intermediateResponse [RFC3771], or future referrals which indicate
+ that they are intermediate referrals.
+
+
+ An operation which is distributed while in the operation evaluation
+ phase is termed a 'sub-operation'.
+
+
+ This document inserts a step between the two distributed operation
+ phases in order to commonize the data and processes followed prior to
+ chaining an operation or returning a referral. This step consists of
+ populating a ContinuationReference data type.
+
+
+4.1 Name resolution
+
+
+ Before evaluating (enacting) most directory operations, the DSE named
+ by the target (often called the base DN) of the operation must be
+ located . This is done by evaluating the RDNs of the target DN one
+ at a time, starting at the rootmost RDN. Each RDN is compared to the
+ DSEs held by the DSA until the set of RDNs is exhausted, or an RDN
+ cannot be found.
+
+
+ If the DSE named by the target is found to be local, the name
+ resolution phase of the operation completes and the operation
+ evaluation phase begins.
+
+
+
+
+
+Sermersheim Expires August 26, 2005 [Page 14]
+Internet-Draft Distributed Procedures for LDAP Operations February 2005
+
+
+
+ If it is found that the target does not name a local DSE nor a DSE
+ that may held by another DSA, it is said that the target does not
+ exist, and the operation fails with noSuchObject (subject to local
+ policy).
+
+
+ If it is found that the DSE named by the target is non-local to the
+ DSA, but may reside elsewhere, name resolution is said to be
+ incomplete. In this case, the operation may be distributed by
+ creating a ContinuationReference (Section 4.3) and either chaining
+ the operation (Section 4.4 and Section 4.5)or returning a referral
+ (Section 4.9).
+
+
+4.1.1 Determining that a named DSE is local to a DSA
+
+
+ If a DSE held by a DSA falls within a naming context held by the DSA,
+ or is the root DSE on a first-level DSA, it is said to be local to
+ that DSA
+
+
+4.1.2 Determining that a named DSE does not exist
+
+
+ A named DSE is said to not exist if, during name resolution the DSE
+ is not found, but if found it would fall within a naming context held
+ by the DSA.
+
+
+4.1.3 Determining that a named DSE is non-local
+
+
+ If a named DSE is niether found to be local to the DSA, nor found to
+ not exist, it is said to be non-local to a DSA. In this case, it is
+ indeterminate whether the named DSE exists.
+
+
+ When a named DSE is found to be non-local, there should be
+ distributed knowledge information available to be used to either
+ return a referral or chain the operation.
+
+
+4.1.3.1 Locating distributed knowledge information for a non-local
+ target
+
+
+ If it has been determined that a target names a non-local DSE,
+ distributed knowledge information may be found by first examining the
+ DSE named by the target, and subsequently all superior DSEs beginning
+ with the immediate superior and ending with the root, until an
+ examined DSE is one of types:
+
+
+ {TODO: should DSE types be all caps? It would be easier to read.}
+ o subr
+ o supr
+ o immsupr
+
+
+
+
+
+Sermersheim Expires August 26, 2005 [Page 15]
+Internet-Draft Distributed Procedures for LDAP Operations February 2005
+
+
+
+ o xr
+ o nssr
+
+
+ The examined DSE which is of one of these types holds the distributed
+ knowledge information for the non-local named target. This DSE is
+ said to be the found distributed knowledge information of the
+ non-local target. This found distributed knowledge information may
+ then be used to distribute the operation.
+
+
+ If no examined DSEs are of any of these types, the distributed
+ knowledge information is mis-configured, and the error
+ invalidReference is returned.
+
+
+4.1.4 Special case for the Add operation
+
+
+ During the name resolution phase of the Add operation, the immediate
+ parent of the base DN is resolved.
+
+
+ If the immediate parent of the entry to be added is a DSE of type
+ nssr, then further interrogation is needed to ensure that the entry
+ to be added does not exist. Methods for doing this are found in
+ Section 4.11. {TODO: don't make this mandatory. Also, it doesn't
+ work without transaction semantics. Same prob in the mod dn below.}.
+
+
+4.1.5 Special case for the ModifyDN operation
+
+
+ When the modifyDN operation includes a newSuperior name, it must be
+ resolved as well as the base DN being modified. If either of these
+ result in a non-local name, the name causing the operation to be
+ distributed should be conveyed (Section 4.3.5). {TODO: also mention
+ access control problems, and mention (impl detail) that
+ affectsmultidsa can be used.}
+
+
+ If during operation evaluation of a ModifyDN operation, the
+ newSuperior names a DSE type of nssr, then further interrogation is
+ needed to ensure that the entry to be added does not exist. Methods
+ for doing this are found in Section 4.11.
+
+
+4.2 Operation Evaluation
+
+
+ Once name resolution has completed. The DSE named in the target has
+ been found to be local to a DSA. At this point the operation can be
+ carried out. During operation evaluation distributed knowledge
+ information may be found that may cause the DSA to distribute the
+ operation. When this happens, the operation may be distributed by
+ creating a ContinuationReference (Section 4.3) and either chaining
+ the operation (Section 4.4 and Section 4.5)or returning a referral
+ (Section 4.9).
+
+
+
+
+Sermersheim Expires August 26, 2005 [Page 16]
+Internet-Draft Distributed Procedures for LDAP Operations February 2005
+
+
+
+ If, during the location of the distributed knowledge information, the
+ distributed knowledge information is found to be mis-configured,
+ operation semantics are followed (some operations may call for an
+ error to be returned, while others call for the error to be ignored).
+ {TODO: either make this more specific, or less specific, or just toss
+ it out.}
+
+
+4.2.1 Search operation
+
+
+ During operation evaluation of a search operation, the DSA must
+ determine whether there is distributed knowledge information in the
+ scope of the search. Any DSE in the search scope which is of the
+ following types is considered to be 'found distributed knowledge
+ information' {TODO: use a better term than found distributed
+ knowledge information} in the search scope:
+
+
+ o subr
+ o nssr (see nssr note)
+ o xr {TODO: I think xr only qualifies when an alias is dereferenced
+ to an xr. Otherwisw, there should always be a subr above the xr
+ if it falls in the search scope.}
+
+
+ Note that due to alias dereferencing, the search scope may expand to
+ include entries outside of the scope originally specified in the
+ search operation. {TODO: note that an aliased object may be glue
+ which needs to result in any subr or xr above it to be found}
+
+
+ Nssr Note: A DSE of type nssr is only considered to be found
+ distributed knowledge information when the scope of the search
+ includes entries below it. For example, when the search scope is
+ wholeSubtree or subordinateSubtree and a DSE of type nssr is found in
+ the scope, or if the search scope is singleLevel and the target
+ object names a DSE of type nsssr.
+
+
+ {TODO: The following sections are talking about how the continuation
+ reference is to be populated. Move to next secion. Can probably
+ just say that whole subtree or subordinare subtree encountering nssr,
+ and single level rooted at nssr result in a continuation reference.
+ base at, and single level above do not result in a continuation
+ reference.}
+
+
+4.2.1.1 Search operation with singleLevel scope
+
+
+ If distributed knowledge information is found during operation
+ evaluation of a search with a singleLevel scope, it will cause the
+ resulting ContinuationReference.searchScope to be set to baseObject.
+
+
+
+
+
+
+Sermersheim Expires August 26, 2005 [Page 17]
+Internet-Draft Distributed Procedures for LDAP Operations February 2005
+
+
+
+4.2.1.2 Search operation encountering nssr knowledge reference
+
+
+ When a search operation encounters distributed knowledge information
+ which is a DSE type of nssr during operation evaluation, the
+ following instructions are followed:
+
+
+ Note that when a search operation is being progressed due to nssr
+ knowledge information, the subsequent distributed progression of the
+ search is caused to be applied to each DSA listed as non-specific
+ knowledge information (This is talked about in Section 4.3.2). In
+ the event that multiple DSAs listed in the knowledge information hold
+ copies of the same directory entries, the 'already searched' and
+ 'duplicate elimination' mechanisms SHOULD be used to prevent
+ duplicate search result entries from ultimately being returned.
+
+
+4.2.1.2.1 wholeSubtree search scope
+
+
+ When the search scope is wholeSubtree, the
+ ContinuationReference.searchScope is set to subordinateSubtree.
+ Because the ContinuationReference.referrenceType is set to
+ nonSpecificSubordinate, the receiving protocol peer allows (and
+ expects) name resolution to stop at an immsupr DSE type which is
+ treated as a local DSE. The subordinateSubtree scope instructs the
+ receiving protocol peer to exclude the target object from the
+ sub-search.
+
+
+4.2.1.2.2 singleLevel search scope
+
+
+ When the search scope is singleLevel, and the base DN is resolved to
+ a DSE of type nssr, subsequent distributed progressions of the search
+ are caused to use the same base DN, and a scope of singleLevel.
+ Receiving protocol peers will only apply the search to entries below
+ the target object.
+
+
+ When the search scope is singleLevel and an evaluated DSE is of type
+ nssr, no special handling is required. The search is applied to that
+ DSE if it is of type entry.
+
+
+4.2.1.2.3 baseObject search scope
+
+
+ No special handling is needed when the search scope is baseObject and
+ the base DN is an nssr DSEType. The search is applied to that DSE if
+ it is of type entry.
+
+
+4.2.1.3 Search operation rooted at an nssr DSE type
+
+
+ (TODO: a subordinateSubtree scope needs to change to wholeSubtree if
+ references are found.)
+
+
+
+
+Sermersheim Expires August 26, 2005 [Page 18]
+Internet-Draft Distributed Procedures for LDAP Operations February 2005
+
+
+
+4.3 Populating the ContinuationReference
+
+
+ When an entry is found to be non-local to a DSA (whether during name
+ resolution or operation evaluation), the DSA prepares for operation
+ distribution by generating a ContinuationReference. This is a
+ conceptual step, given to help explain the interactions that occur
+ between discovering that an operation must be distributing, and
+ actually invoking the operation distribution mechanism.
+ Implementations are not required to perform this step, but will
+ effectively work with the same information.
+
+
+ After the ContinuationReference has been created, the DSA may choose
+ to chain the operation or return a referral (or intermediate
+ referral(s)).
+
+
+ the ContinuationReference is made up of data held on the found
+ distributed knowledge information, as well as state information
+ gained during name resolution or operation evaluation.
+
+
+4.3.1 Conveying the Target Object
+
+
+ The consumer of the ContinuationReference will examine various fields
+ in order to determine the target object name of the operation being
+ progressed. The fields examined are the localReference and
+ remainingName.
+
+
+ If name resolution did not complete, and the found distributed
+ knowledge information names the same DSE as the base DN of the
+ operation, the ContinuationReference MAY omit the localReference
+ and/or remainingName fields.
+
+
+ localReference is populated with the name of the found distributed
+ knowledge information DSE. In the event that the root object holds
+ the distributed knowledge information, this field will be populated
+ with an empty DN. Contrast this with the omission of this field.
+
+
+ referenceType is populated with a value reflecting the reference type
+ of the localReference DSE.
+
+
+ remainingName is populated with the RDNSequence which has not yet
+ been resolved. This is the difference between the localReference
+ value and the name of the DSE to be resolved.
+
+
+ In cases where the DSE named by the {TODO, use a dash or different
+ term to make 'found distributed knowledge' more like a single term}
+ found distributed knowledge is not the same as the base DN of the
+ operation, the ContinuationReference must contain the localReference
+ and/or remainingName fields. Such cases include but are not limited
+
+
+
+
+Sermersheim Expires August 26, 2005 [Page 19]
+Internet-Draft Distributed Procedures for LDAP Operations February 2005
+
+
+
+ to:
+
+
+ o Distributed knowledge information is found during operation
+ evaluation.
+ o Aliases were dereferenced during name resolution.
+ o Name resolution did not complete and there were remaining RDNs to
+ be resolved.
+
+
+4.3.2 Conveying the Remote DSA
+
+
+ The referralURI field must contain at least one value. Each
+ referralURI value must hold a referralURI.accessPoint. Other
+ requirements on this field as noted may also apply.
+
+
+ Note for nssr DSE types: During operation evaluation, if a DSE of
+ type nssr causes the operation to be distributed (the scenarios in
+ Section 4.2.1.2 are an example), then an intermediate referral {TODO:
+ this is talking about referral/intermediate referral, but this
+ section is only dealing with populating continuation reference} is
+ returned for each value of the ref attribute, where each intermediate
+ referral only holds a single referralURI value.
+
+
+4.3.3 Conveying new search scope
+
+
+ During the evaluation of the search operation, the instructions in
+ Section 4.2.1.2.1 and Section 4.2.1.2.2 are followed and the
+ searchScope field is updated with the new search scope.
+
+
+4.3.4 Preventing duplicates
+
+
+ In order to prevent duplicate entries from being evaluated while
+ progressing a search operation, the searchedSubtrees field is
+ populated with any naming context below the
+ ContinuationReference.targetObject which have been fully searched.
+
+
+ During the evaluation of the search operation, if the scope is
+ wholeSubtree, it is possible that the DSA may search the contents of
+ a naming context which is subordinate to another naming context which
+ is subordinate to the search base (See figure).
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sermersheim Expires August 26, 2005 [Page 20]
+Internet-Draft Distributed Procedures for LDAP Operations February 2005
+
+
+
+ O X
+ / \
+ / \
+ / \
+ / \
+ \_______O Y
+ /|\
+ / | \
+ / | \
+ / | \
+ A B O C
+ / \
+ / \
+ / \
+ / \
+ \_______/
+
+
+ In this figure, the DSA holds the naming context X and C,Y,X, but not
+ Y,X. If the search base was X, an intermediate referral would be
+ returned for Y,X. The DSA holding Y,X may also hold a copy of C,Y,X.
+ In this case, the receiver of the ContinuationReference benefits by
+ knowing that the DSA already searched C,Y,X so that it can prevent
+ other DSAs from returning those entries again.
+
+
+ Data already searched is in the form of an RDNSequence, consisting of
+ the RDNs relative to the target object.
+
+
+4.3.5 Conveying the Failed Name
+
+
+ At least one DS operation (modifyDN) requires that multiple DNs be
+ resolved (the entry being modified and the newSuperior entry). In
+ this case, the failedName field will be populated with the DN being
+ resolved which failed name resolution. This may aid in the
+ determination of how the operation is to be progressed. If both
+ names are found to be non-local, this field is omitted.
+
+
+4.4 Sending a ChainedRequest
+
+
+ When an entry is found to be non-local to a DSA (whether during name
+ resolution or operation evaluation), the DSA may progress the
+ operation by sending a chained operation to another DSA (or DSAs).
+ The instructions in this section assume that a ContinuationReference
+ has been generated which will be used to form the ChainedRequest. It
+ is also assumed that it can be determined whether the operation is
+ being progressed due to name resolution or due to operation
+ evaluation.
+
+
+ A DSA which is able to chain operations may advertise this by
+
+
+
+
+Sermersheim Expires August 26, 2005 [Page 21]
+Internet-Draft Distributed Procedures for LDAP Operations February 2005
+
+
+
+ returning a value of IANA-ASSIGNED-OID.2; in the supportedFeatures
+ attribute on the root DSE. {TODO: does this and discovery of the
+ extended op belong in a new 'discovery mechanisms' sections.}
+
+
+4.4.1 Forming a ChainedRequest
+
+
+ The following fields are populated as instructed:
+
+
+4.4.1.1 ChainedRequestValue.chainingArguments.targetObject
+
+
+ The ContinuationReference may convey a new target object. If
+ present, the ContinuationReference.localReference field becomes the
+ candidate target object. Otherwise the candidate target object is
+ assumed to be that of the original directory operation. Note that an
+ empty value in the ContinuationReference.localReference field denotes
+ the root object.
+
+
+ After performing the above determination as to the candidate target
+ object, any RDNSequence in ContinuationReference.remainingName is
+ prepended to the determined candidate target object. This value
+ becomes the ChainedRequestValue.chainingArguments.targetObject. If
+ this value matches the value of the original operation, this field
+ may be omitted.
+
+
+4.4.1.2 ChainedRequestValue.chainingArguments.referenceType
+
+
+ This is populated with the
+ ContinuationReference.referralURI.referenceType.
+
+
+4.4.1.3 ChainedRequestValue.chainingArguments.traceInformation
+
+
+ This is populated as specified in Section 3.2.1.3.
+
+
+4.4.1.4 ChainedRequestValue.chainingArguments.searchScope
+
+
+ This is populated with the
+ ContinuationReference.referralURI.searchScope if present, otherwise
+ by the ContinuationReference.searchScope if present, and not
+ populated otherwise.
+
+
+4.4.1.5 ChainedRequestValue.chainingArguments.searchedSubtrees
+
+
+ This is populated with ContinuationReference.searchedSubtrees, as
+ well as any previously received values of
+ ChainedFinalResponseValue.chainingResults.searchedSubtrees or
+ ChainedIntermediateResponseValue.chainingResults.searchedSubtrees
+ which are subordinate, relative to the target object. (If thsi is
+ relative to the target object, it can't contain non-relative
+
+
+
+
+Sermersheim Expires August 26, 2005 [Page 22]
+Internet-Draft Distributed Procedures for LDAP Operations February 2005
+
+
+
+ subtrees)
+
+
+4.4.1.6 ChainedRequestValue.operationRequest
+
+
+ This is populated with the original directory operation request.
+
+
+4.4.2 Attempting Each Referral URI
+
+
+ A ContinuationReference consists of one or more referralURIs which
+ represent(s a) remote DSA(s). The chaining DSA attempts to chain to
+ each of these DSAs until one succeeds in completing the operation.
+ An operation is considered to be completed if it reaches the remote
+ DSA and a response is sent back that indicates that the operation was
+ executed. Operations which are sent to the remote DSA, but don't
+ complete are indicated by a result code of unavailable or busy. A
+ result code of protocolError may indicate that the DSA does not
+ support the chained operation, and in this case, it is also treated
+ as an uncompleted operation. Other errors may in the future specify
+ that they also indicate non-completion. Note that the response may
+ itself contain referral(s), these are still considered completed
+ operations and thus would subsequently be handled and chained.
+ {TODO: could use soft/hard, or transient/permanent
+ referral/non-referral error terms here.}
+
+
+4.4.3 Loop Prevention
+
+
+ Prior to sending a ChainedRequest, the DSA may attempt to prevent
+ looping scenarios by comparing {TODO: what matching rule is used?
+ Suggest we don't convert dns names to ip addresses due to NATs} the
+ address of the remote DSA and target object to the values of
+ ChainedRequestValue.chainingArguments.traceInformation. If a match
+ is found, the DSA returns a loopDetect error. Note that while this
+ type of loop prevention aids in detecting loops prior to sending data
+ to a remote DSA, it is not a substitute for loop detection (Section
+ Section 4.6.2). This is because the sending DSA is only aware of a
+ single address on which the receiving DSA accepts connections.
+
+
+4.5 Emulating the Sending of a ChainedRequest
+
+
+ When it is determined that the operation cannot be distributed by
+ means of the ChainedRequest, the chaining DSA may instead emulate the
+ steps involved in chaining the operation. These steps consist of
+ performing loop prevention, forming a new directory operation request
+ from the original request and possibly updating the base DN, search
+ scope, and search filter(in order to emulate searchedSubtrees), and,
+ similar to the steps in Section 4.4.2, attempting to send the
+ operation request to each DSA listed in the
+ ContinuationReference.referralURI until one succeeds in completing
+
+
+
+
+Sermersheim Expires August 26, 2005 [Page 23]
+Internet-Draft Distributed Procedures for LDAP Operations February 2005
+
+
+
+ the operation.
+
+
+ {TODO: We need a way (control) to tell the receiver to allow name
+ resolution to end on the parent of a cp (typically an immsupr). This
+ would be sent when the ContinuationReference.referenceType is
+ nonSpecificSubordinate}
+
+
+4.5.1 Emulated Loop Detection
+
+
+ For this step, the loop prevention instructions in Section 4.4.3 are
+ followed. Note that this method of loop detection may actually allow
+ some looping to occur before the loop is detected.
+
+
+4.5.2 Forming the New Request
+
+
+ The new directory operation request is formed from the fields of the
+ original request, and the following fields may be updated:
+
+
+ o The base DN is formed from the new target object as determined by
+ following the instructions in Section 4.4.1.1 and using the value
+ which would have been placed in
+ ChainedRequestValue.chainingArguments.targetObject.
+ o For the search operation, the scope is populated with
+ ContinuationReference.searchScope if present, otherwise the scope
+ of the original operation request is used.
+ o For the search operation, if the
+ ContinuationReference.searchedSubtrees field is present, causes
+ the search filter to be augmented by adding a filter item of the
+ 'and' CHOICE. The filter consists of {TODO: weasel Kurt into
+ finishing his entryDN draft and reference the appropriate section
+ there. See
+ <http://www.openldap.org/lists/ietf-ldapext/200407/msg00000.html>
+ for context}
+ o Other fields (such as the messageID, and non-critical controls)
+ may also need to be updated or excluded.
+
+
+ If the service being chained to does not support directory
+ operations, other operations may be used as long as they provide the
+ same level as service as those provided by the analogous directory
+ operation.
+
+
+4.6 Receiving a ChainedRequest
+
+
+ A DSA which is able to receive and service a ChainedRequest may
+ advertise this feature by returning a value of IANA-ASSIGNED-OID.1 in
+ the supportedExtension attribute of the root DSE. {TODO: move?}
+
+
+ The ChainedRequestValue data type is the requestValue of an
+
+
+
+
+Sermersheim Expires August 26, 2005 [Page 24]
+Internet-Draft Distributed Procedures for LDAP Operations February 2005
+
+
+
+ extendedRequest.
+
+
+ In general, receiving and servicing a ChainedRequest consists of
+ performing loop detection and, using components of the
+ ChainedRequestType.chainingArguments along with the
+ ChainedRequestType.operationRequest, service the request.
+
+
+4.6.1 Target Object determination
+
+
+ Prior to checking for a loop condition, the target object must be
+ determined. If the ChainedRequestType.chainingArguments.targetObject
+ field is present, its value becomes the target object. Otherwise,
+ the base DN found in the ChainedRequestType.operationRequest becomes
+ the target object.
+
+
+4.6.2 Loop Detection
+
+
+ The loop detection check happens when a DSA receives a chained
+ operation, prior to acting on the operation. The DSA compares {TODO:
+ matching rule? DNS expansion?} each value of
+ ChainedRequestValue.traceInformation to the list of addresses at
+ which it accepts directory communications. A value of
+ ChainedRequestValue.traceInformation matches when the DSA accepts
+ directory communications on the address found in the
+ ChainedRequestValue.traceInformation value, and the target object (as
+ determined in Section 4.6.1 matches the DN {TODO: using DN matching?}
+ value found in the ChainedRequestValue.traceInformation value. If a
+ match is found the DSA returns a loopDetect result.
+
+
+4.6.3 Processing the ChainedRequestValue.operationRequest
+
+
+ In processing the operationRequest, the DSA uses the target object
+ determined in Section 4.6.1. For search operations, it uses the
+ scope found in ChainedRequestValue.chainingArguments.searchScope, and
+ excludes any subtrees relative to the target object indicated in
+ ChainedRequestValue.chainingArguments.searchedSubtrees.
+
+
+ Responses are returned in the form of a Chained Response.
+
+
+4.7 Returning a Chained Response
+
+
+ When returning responses to a ChainedRequest, the Chained Response as
+ documented in Section 3.3 is used. If the
+ ChainedFinalResponseValue.operationResponse is a searchResultDone,
+ the ChainedFinalResponseValue.chainingResults.searchedSubtrees field
+ is populated with values consisting of the RDNSequence relative to
+ the target object of naming contexts that the DSA searched. See
+ Section 3.3.1.1 for details on why this is done.
+
+
+
+
+Sermersheim Expires August 26, 2005 [Page 25]
+Internet-Draft Distributed Procedures for LDAP Operations February 2005
+
+
+
+4.7.1 Chained Response resultCode
+
+
+ The resultCode for the Chained Response is distinct from the result
+ code of the ChainedIntermediateResponseValue.intermediateResponse or
+ ChainedFinalResponseValue.finalResponse. If the act of chaining the
+ operation completed, then this value will be success. Other result
+ codes refer to the chained operation itself, and not the result of
+ the embedded operation.
+
+
+4.7.2 Returning referrals in the Chained Response
+
+
+ {TODO: it would be less complicated if rather than using the simple
+ LDAP URL, we used the ContinuationReference type to return referrals
+ and intermediate referrals.} {TODO: We need an example of why we
+ should allow referrals on a chained response. Why not just use the
+ referral field in the operation?}
+
+
+4.8 Receiving a Chained Response
+
+
+ Processing a received Chained Response is generally straight forward
+ -- typically the response is simply extracted and returned, but there
+ are some extra steps to be taken when chaining sub-operations.
+
+
+4.8.1 Handling Sub-operation controls and result codes
+
+
+ When sub-operations are chained, there is the possibility that
+ different result codes will be encountered. Similarly, if controls
+ which elicit response controls were attached to the operation, it's
+ possible that multiple response controls will be encountered. Both
+ of these possibilities require that the chaining DSA take appropriate
+ steps to ensure that the response being returned is correct.
+
+
+ In general, when a result code indicating an error is received, the
+ operation will terminate and the error will be returned. In cases
+ where multiple sub-operations are being concurrently serviced, the
+ operation will terminate and the most relevant, or first received
+ result code is returned -- determining the result code to be returned
+ in this case is a local matter.
+
+
+ A DSA which chains an operation having a control (or controls)
+ attached must ensure that a properly formed response is returned.
+ This requires that the DSA understand and know how to aggrigate the
+ results of all controls which it allows to remain attached to an
+ operation being chained. If the DSA does not understand or support a
+ control which is marked non-critical, it removes the control prior to
+ chaining the operation. The DSA may return
+ unavailableCriticalExtension for critical controls that it cannot or
+ will not chain. {TODO: give SSS as an example?}
+
+
+
+
+Sermersheim Expires August 26, 2005 [Page 26]
+Internet-Draft Distributed Procedures for LDAP Operations February 2005
+
+
+
+4.8.1.1 Handling referrals during sub-operations
+
+
+ If a referral is returned in response to a sub-operation, the sending
+ DSA may attempt to further chain the operation. In the event that
+ the DSA does not further chain the sub-operation, it will use the
+ referral to construct an intermediate referral, and return it
+ appropriately. When using a referral to construct an intermediate
+ referral, certain transformations may have to happen. For example,
+ when using a referral to construct a searchResultReference, it must
+ be assured that the <dn> field is present, and that the <scope> field
+ is properly updated.
+
+
+4.8.2 Duplicate Elimination
+
+
+ When search result references cause the DSA to chain a search, it is
+ possible that duplicate objects will be returned by different remote
+ DSAs. These duplicate objects must be sensed and not returned.
+
+
+ {TODO: Even though there are costs associated with returning
+ duplicates, is it a worthy exercise to build in an allowance for them
+ to be returned? In other words, do we want to add a way for a client
+ (or administrator) to say "it's ok, return the duplicates, let the
+ client deal with them"? Allowing is seen as a cost benefit to the
+ DSA.}
+
+
+4.9 Returning a Referral or Intermediate Referral
+
+
+ There are two ways in which the fields of the ContinuationReference
+ may be conveyed in a response containing or consisting of referral or
+ intermediate referral. A paired control is introduced for the
+ purpose of soliciting and returning a ContinuationReference. In
+ absence of this control, a referral or intermediate referral may be
+ returned which conveys the information present in the
+ ContinuationReference. A method of converting a
+ ContinuationReference to an LDAP URL is provided for referrals and
+ intermediate referrals which identify LDAP-enabled DSAs. Methods for
+ converting a ContinuationReference to URIs which identify non-LDAP
+ servers is not provided here, but may be specified in future
+ documents, as long as they can represent the data needed to provide
+ the same level of service.
+
+
+4.9.1 ReturnContinuationReference controls
+
+
+ This control is sent when a client wishes to receive a
+ ContinuationReference in the event that a referral or intermediate
+ referral is being returned. If returned, the ContinuationReference
+ will hold all data but the referralURI field. the referralURI values
+ will be held in the referral or intermediate referral (Referral,
+
+
+
+
+Sermersheim Expires August 26, 2005 [Page 27]
+Internet-Draft Distributed Procedures for LDAP Operations February 2005
+
+
+
+ SearchResultReference, etc.).
+
+
+4.9.1.1 ReturnContinuationReference request control
+
+
+ Solicits the return of a ReturnContinuationReference response control
+ on messages consisting of (or carrying) a referral or intermediate
+ referral. The controlType is IANA-ASSIGNED-OID.3, the criticality is
+ set at the sender's discretion, the controlValue is omitted.
+
+
+4.9.1.2 ReturnContinuationReference response control
+
+
+ In response to the ReturnContinuationReference request control, this
+ holds a ContinuationReference for messages consisting of (or
+ carrying) a referral or intermediate referral. The controlType is
+ IANA-ASSIGNED-OID.3, the controlValue is the BER-encoding of a
+ ContinuationReference. Note that the referralURI field is optionally
+ omitted when the ContinuationReference is sent in this control value.
+ In this event, the URI(s) found in the referral or intermediate
+ referral (Referral, SearchContinuationReference, etc.) are to be used
+ in its stead. {TODO: is returining the referralURI outside an
+ unneeded complication?}
+
+
+4.9.2 Converting a ContinuationReference to an LDAP URL
+
+
+ This section details the way in which an LDAP URL (from the referral
+ or intermediate referral) is used to convey the fields of a
+ ContinuationReference. Where existing LDAP URL fields are
+ insufficient, extensions are introduced. Note that further
+ extensions to the ContinuationReference type require further
+ specifications here. {TODO: explain that each ldap url in the
+ continuation refrerence is examined and converted}
+
+
+ These instructions must be applied to each LDAP URL value within the
+ referral or intermediate referral.
+
+
+4.9.2.1 Conveying the target name
+
+
+ If the <dn> part of the LDAP URL is already present, it is determined
+ to be the candidate target object. Otherwise, the candidate target
+ object comes from the ContinuationReference.localReference. Once the
+ candidate target object is determined, the value of
+ ContinuationReference.remainingName is prepended to the candidate
+ target object. This new value becomes the target object and its
+ string value (as specified by <distinguishedName> in [RFC2253]) is
+ placed in the <dn> part of the LDAP URL.
+
+
+
+
+
+
+
+Sermersheim Expires August 26, 2005 [Page 28]
+Internet-Draft Distributed Procedures for LDAP Operations February 2005
+
+
+
+4.9.2.2 ContinuationReference.localReference
+
+
+ This is conveyed as an extension. The extype is IANA-ASSIGNED-OID.4
+ or the descriptor 'localReference', and the exvalue is the string DN
+ encoding (as specified by <distinguishedName> in [RFC2253]) of the
+ ContinuationReference.localReference value.
+
+
+4.9.2.3 ContinuationReference.referenceType
+
+
+ This is conveyed as an extension. The extype is IANA-ASSIGNED-OID.5
+ or the descriptor 'referenceType'. If the
+ ContinuationReference.referenceType is one of superior, subordinate,
+ cross, nonSpecificSubordinate, suplier, master, immediateSuperior, or
+ self, the exvalue 'superior', 'subordinate', 'cross',
+ 'nonSpecificSubordinate', 'suplier', 'master', 'immediateSuperior',
+ or 'self' respectively.
+
+
+4.9.2.4 ContinuationReference.searchScope
+
+
+ If the search scope is one of baseObject, singleLevel, or
+ wholeSubtree, then it may be conveyed in the 'scope' part of the LDAP
+ URL as 'base', 'one', or 'sub' respectively. If the search scope is
+ subordinateSubtree, then it may be conveyed in the <extension> form
+ as documented in [LDAP-SUBORD]. If this extension is present, it
+ MUST be marked critical. This ensures that a receiver which is
+ unaware of this extension uses the proper search scope, or fails to
+ progress the operation.
+
+
+4.9.2.5 ContinuationReference.searchedSubtrees
+
+
+ This field is conveyed as an extension. The extype is
+ IANA-ASSIGNED-OID.6 or the descriptor 'searchedSubtrees', and the
+ exvalue is the ContinuationReference.searchedSubtree value encoded
+ according to the following searchedSubtrees ABNF:
+
+
+ searchedSubtrees = 1*(LANGLE searchedSubtree RANGLE)
+ searchedSubtree = <distinguishedName> from [RFC2253]
+ LANGLE = %x3C ; left angle bracket ("<")
+ RANGLE = %x3E ; right angle bracket (">")
+
+
+ Each searchedSubtree represents one RDNSequence value in the
+ ContinuationReference.searchedSubtree field. An example of a
+ searchedSubtrees value containing two searched subtrees is:
+ <dc=example,dc=com><cn=ralph,dc=users,dc=example,dc=com>.
+
+
+4.9.2.6 ContinuationReference.failedName
+
+
+ This field is conveyed as an extension. The extype is
+
+
+
+
+Sermersheim Expires August 26, 2005 [Page 29]
+Internet-Draft Distributed Procedures for LDAP Operations February 2005
+
+
+
+ IANA-ASSIGNED-OID.7 or the descriptor 'failedName', and the exvalue
+ is the string DN encoding (as specified in [RFC2253]) of the
+ ContinuationReference.failedName value.
+
+
+4.10 Acting on a Referral or Intermediate Referral
+
+
+ When a protocol peer receives a referral or intermediate referral, it
+ may distribute the operation either by sending a ChainedRequest, or
+ by emulating the ChainedRequest. Prior to taking these steps, the
+ protocol peer effectively converts the referral or intermediate
+ referral into a ContinuationReference. Then, acting in the same
+ manner as a DSA would, follows the directions in Section 4.4 if
+ sending a ChainedRequest, or Section 4.5 otherwise.
+
+
+4.10.1 Converting a Referral or Intermediate Referral to a
+ ContinuationReference
+
+
+ A referral or intermediate referral may be converted (or conceptually
+ converted) to a ContinuationReference type in order to follow the
+ distributed operation procedures in Section 4.4, or Section 4.5. The
+ following steps may only be used to convert a referral or
+ intermediate referral containing LDAP URL values. Converting other
+ types of URIs may be specified in future documents as long as the
+ conversion provides the same level of service found here.
+
+
+ o The ContinuationReference.referralURI is populated with all LDAP
+ URL values in the referral or intermediate referral.
+ o The ContinuationReference.localReference populate with the value
+ of the localReference extension value (Section 4.9.2.2) if one
+ exists. Otherwise it is omitted.
+ o The ContinuationReference.referenceType populate with the value of
+ the referenceType extension value (Section 4.9.2.3) if one exists.
+ Otherwise it is omitted.
+ o The ContinuationReference.remainingName is omitted.
+ o The ContinuationReference.searchScope is populated with
+ subordinateSubtree if the subordScope LDAP URL extension
+ [LDAP-SUBORD] is present. If the <scope> field contains te value
+ 'base', 'one', 'sub', or 'subordinates', this filed is populated
+ with baseObject, singleLevel, wholeSubtree, or subordinateSubtree
+ respectively. Otherwise this field is omitted.
+ o The ContinuationReference.searchedSubtrees is populated with any
+ searchedSubtrees LDAP URI extension Section 4.9.2.5 value found on
+ an LDAP URI in the referral or intermediate referral. If none
+ exist, this field is omitted.
+ o The ContinuationReference.failedName is populated with any
+ failedName LDAP URI extension Section 4.9.2.6 value found on an
+ LDAP URI in the referral or intermediate referral. If none exist,
+ this field is omitted.
+
+
+
+
+Sermersheim Expires August 26, 2005 [Page 30]
+Internet-Draft Distributed Procedures for LDAP Operations February 2005
+
+
+
+ Note that many fields are simply omitted. This is either because
+ they are conveyed within the LDAP URL values themselves, and
+ subsequent instructions will check for their presence, or because
+ they are not needed (they are redundant or not used in further
+ instructions).
+
+
+4.11 Ensuring non-existence of an entry under an nssr
+
+
+ {TODO: add a huge disclaimer here that says without transactional
+ semantics, you can never be sure that the entry didn't get added.
+ Maybe we should just punt on this and say it's a local matter} In
+ order to ensure there are no entries matching the name of the entry
+ to be added or renamed immediately subordinate to an nssr, these
+ steps may be followed.
+
+
+ If the DSA is able and allowed to chain operations, it may contact
+ each of the DSAs listed as access points in the nssr (in the ref
+ attribute) and using a base-level search operation it will determine
+ whether or not the object to be added exists. Note that access
+ control or other policies may hide the entry from the sending DSA.
+ If the entry does not exist on any of the DSAs listed in the nssr,
+ the operation may progress on the local DSA.
+
+
+ If the DSA cannot make this determination, the operation fails with
+ affectsMultipleDSAs.
+
+
+4.12 Mapping a referralURI to an LDAP URI
+
+
+ As with any URI specification which is intended to be used as a URI
+ which conveys referral information, the LDAP URI specification is
+ given a mapping to the elements of a referralURI as specified in.
+ Section 3.1.1.1. These mappings are given here using the ABNF
+ identifiers given in [RFC2255].
+
+
+ referralURI to LDAP URI mapping:
+
+
+ +---------------------------------+---------------------------------+
+ | referralURI element | LDAP URL element |
+ +---------------------------------+---------------------------------+
+ | protocolIdentifier | <scheme> |
+ | | |
+ | accessPoint | <hostport> |
+ | | |
+ | targetObject | <dn>. This must be encoded as a |
+ | | <distinguishedName> as |
+ | | specified in [RFC2253] |
+ | | |
+ | localReference | LDAP URL localReference |
+
+
+
+
+Sermersheim Expires August 26, 2005 [Page 31]
+Internet-Draft Distributed Procedures for LDAP Operations February 2005
+
+
+
+ | | extension as specified in |
+ | | Section 4.9.2.2 |
+ | | |
+ | referenceType | LDAP URL referenceType |
+ | | extension as specified in |
+ | | Section 4.9.2.3 |
+ | | |
+ | searchScope | <scope> or LDAP URL subordScope |
+ | | extension as specified in |
+ | | Section 4.9.2.4 |
+ | | |
+ | searchedSubtrees | LDAP URL searchedSubtrees |
+ | | extension as specified in |
+ | | Section 4.9.2.5 |
+ | | |
+ | failedName | LDAP URL failedName extension |
+ | | as specified in Section 4.9.2.6 |
+ +---------------------------------+---------------------------------+
+
+
+
+ 4.13 Using the ManageDsaIT control
+
+
+ This control, defined in [RFC3296], allows the management of the
+ distributed knowledge information held by a DSA, and thus overrides
+ the determinations made during name resolution and operation
+ evaluation. When this control is attached to an operation, all
+ resolved and acted upon DSEs are treated as being local to the DSA.
+ This is true regardless of the phase the operation is in. Thus
+ referrals are never returned and chaining never occurs.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sermersheim Expires August 26, 2005 [Page 32]
+Internet-Draft Distributed Procedures for LDAP Operations February 2005
+
+
+
+5. Security Considerations
+
+
+ This document introduces a mechanism (chaining) which can be used to
+ propagate directory operation requests to servers which may be
+ inaccessible otherwise. Implementers and deployers of this
+ technology should be aware of this and take appropriate steps such
+ that firewall mechanisms are not compromised.
+
+
+ This document introduces the ability to return auxiliary data when
+ returning referrals. Measures should be taken to ensure proper
+ protection of his data.
+
+
+ Implementers must ensure that any specified time, size, and
+ administrative limits are not circumvented due to the mechanisms
+ introduced here.
+
+
+6. Normative References
+
+
+ [LDAP-SUBORD]
+ Sermersheim, J., "Subordinate Subtree Search Scope for
+ LDAP",
+ Internet-Draft draft-sermersheim-ldap-subordinate-scope,
+ July 2004.
+
+
+ [RFC2079] Smith, M., "Definition of an X.500 Attribute Type and an
+ Object Class to Hold Uniform Resource Identifiers (URIs)",
+ RFC 2079, January 1997.
+
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+
+ [RFC2251] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory
+ Access Protocol (v3)", RFC 2251, December 1997.
+
+
+ [RFC2253] Wahl, M., Kille, S. and T. Howes, "Lightweight Directory
+ Access Protocol (v3): UTF-8 String Representation of
+ Distinguished Names", RFC 2253, December 1997.
+
+
+ [RFC2255] Howes, T. and M. Smith, "The LDAP URL Format", RFC 2255,
+ December 1997.
+
+
+ [RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
+ Resource Identifiers (URI): Generic Syntax", RFC 2396,
+ August 1998.
+
+
+ [RFC3296] Zeilenga, K., "Named Subordinate References in Lightweight
+ Directory Access Protocol (LDAP) Directories", RFC 3296,
+ July 2002.
+
+
+
+
+Sermersheim Expires August 26, 2005 [Page 33]
+Internet-Draft Distributed Procedures for LDAP Operations February 2005
+
+
+
+ [RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access
+ Protocol (v3): Technical Specification", RFC 3377,
+ September 2002.
+
+
+ [RFC3383] Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
+ Considerations for the Lightweight Directory Access
+ Protocol (LDAP)", BCP 64, RFC 3383, September 2002.
+
+
+ [RFC3771] Harrison, R. and K. Zeilenga, "The Lightweight Directory
+ Access Protocol (LDAP) Intermediate Response Message",
+ RFC 3771, April 2004.
+
+
+ [X500] International Telephone and Telegraph Consultative
+ Committee, "The Directory - overview of concepts, models
+ and services", ITU-T Recommendation X.500, November 1993.
+
+
+ [X518] International Telephone and Telegraph Consultative
+ Committee, "The Directory - The Directory: Procedures for
+ distributed operation", ITU-T Recommendation X.518,
+ November 1993.
+
+
+ [X680] International Telecommunications Union, "Abstract Syntax
+ Notation One (ASN.1): Specification of basic notation",
+ ITU-T Recommendation X.680, July 2002.
+
+
+ [X690] International Telecommunications Union, "Information
+ Technology - ASN.1 encoding rules: Specification of Basic
+ Encoding Rules (BER), Canonical Encoding Rules (CER) and
+ Distinguished Encoding Rules (DER)", ITU-T Recommendation
+ X.690, July 2002.
+
+
+
+Author's Address
+
+
+ Jim Sermersheim
+ Novell, Inc
+ 1800 South Novell Place
+ Provo, Utah 84606
+ USA
+
+
+ Phone: +1 801 861-3088
+ Email: jimse at novell.com
+
+
+
+
+
+
+
+
+
+
+Sermersheim Expires August 26, 2005 [Page 34]
+Internet-Draft Distributed Procedures for LDAP Operations February 2005
+
+
+
+Appendix A. IANA Considerations
+
+
+ Registration of the following values is requested [RFC3383].
+
+
+A.1 LDAP Object Identifier Registrations
+
+
+ It is requested that IANA register upon Standards Action an LDAP
+ Object Identifier in identifying the protocol elements defined in
+ this technical specification. The following registration template is
+ provided:
+
+
+ Subject: Request for LDAP OID Registration
+ Person & email address to contact for further information:
+ Jim Sermersheim
+ jimse at novell.com
+ Specification: RFCXXXX
+ Author/Change Controller: IESG
+ Comments:
+ Seven delegations will be made under the assigned OID:
+ IANA-ASSIGNED-OID.1 ChainedRequest LDAP Extended Operation
+ IANA-ASSIGNED-OID.2 Supported Feature: Can Chain Operations
+ IANA-ASSIGNED-OID.3 ReturnContinuationReference LDAP Controls
+ IANA-ASSIGNED-OID.4 localReference: LDAP URL Extension
+ IANA-ASSIGNED-OID.6 searchedSubtree: LDAP URL Extension
+ IANA-ASSIGNED-OID.7 failedName: LDAP URL Extension
+
+
+A.2 LDAP Protocol Mechanism Registrations
+
+
+ It is requested that IANA register upon Standards Action the LDAP
+ protocol mechanism described in this document. The following
+ registration templates are given:
+
+
+ Subject: Request for LDAP Protocol Mechanism Registration
+ Object Identifier: IANA-ASSIGNED-OID.1
+ Description: ChainedRequest LDAP Extended Operation
+ Person & email address to contact for further information:
+ Jim Sermersheim
+ jimse at novell.com
+ Usage: Extension
+ Specification: RFCXXXX
+ Author/Change Controller: IESG
+ Comments: none
+
+
+ Subject: Request for LDAP Protocol Mechanism Registration
+ Object Identifier: IANA-ASSIGNED-OID.2
+ Description: Can Chain Operations Supported Feature
+ Person & email address to contact for further information:
+
+
+
+
+
+Sermersheim Expires August 26, 2005 [Page 35]
+Internet-Draft Distributed Procedures for LDAP Operations February 2005
+
+
+
+ Jim Sermersheim
+ jimse at novell.com
+ Usage: Feature
+ Specification: RFCXXXX
+ Author/Change Controller: IESG
+ Comments: none
+
+
+ Subject: Request for LDAP Protocol Mechanism Registration
+ Object Identifier: IANA-ASSIGNED-OID.3
+ Description: ReturnContinuationReference LDAP Controls
+ Person & email address to contact for further information:
+ Jim Sermersheim
+ jimse at novell.com
+ Usage: Control
+ Specification: RFCXXXX
+ Author/Change Controller: IESG
+ Comments: none
+
+
+ Subject: Request for LDAP Protocol Mechanism Registration
+ Object Identifier: IANA-ASSIGNED-OID.4
+ Description: localReference LDAP URL Extension
+ Person & email address to contact for further information:
+ Jim Sermersheim
+ jimse at novell.com
+ Usage: Extension
+ Specification: RFCXXXX
+ Author/Change Controller: IESG
+ Comments: none
+
+
+ Subject: Request for LDAP Protocol Mechanism Registration
+ Object Identifier: IANA-ASSIGNED-OID.5
+ Description: referenceType LDAP URL Extension
+ Person & email address to contact for further information:
+ Jim Sermersheim
+ jimse at novell.com
+ Usage: Extension
+ Specification: RFCXXXX
+ Author/Change Controller: IESG
+ Comments: none
+
+
+ Subject: Request for LDAP Protocol Mechanism Registration
+ Object Identifier: IANA-ASSIGNED-OID.6
+ Description: searchedSubtree LDAP URL Extension
+ Person & email address to contact for further information:
+ Jim Sermersheim
+ jimse at novell.com
+ Usage: Extension
+
+
+
+
+
+Sermersheim Expires August 26, 2005 [Page 36]
+Internet-Draft Distributed Procedures for LDAP Operations February 2005
+
+
+
+ Specification: RFCXXXX
+ Author/Change Controller: IESG
+ Comments: none
+
+
+ Subject: Request for LDAP Protocol Mechanism Registration
+ Object Identifier: IANA-ASSIGNED-OID.7
+ Description: failedName LDAP URL Extension
+ Person & email address to contact for further information:
+ Jim Sermersheim
+ jimse at novell.com
+ Usage: Extension
+ Specification: RFCXXXX
+ Author/Change Controller: IESG
+ Comments: none
+
+
+A.3 LDAP Descriptor Registrations
+
+
+ It is requested that IANA register upon Standards Action the LDAP
+ descriptors described in this document. The following registration
+ templates are given:
+
+
+ Subject: Request for LDAP Descriptor Registration
+ Descriptor (short name): localReference
+ Object Identifier: IANA-ASSIGNED-OID.4
+ Person & email address to contact for further information:
+ Jim Sermersheim
+ jimse at novell.com
+ Usage: URL Extension
+ Specification: RFCXXXX
+ Author/Change Controller: IESG
+ Comments: none
+
+
+ Subject: Request for LDAP Descriptor Registration
+ Descriptor (short name): referenceType
+ Object Identifier: IANA-ASSIGNED-OID.5
+ Person & email address to contact for further information:
+ Jim Sermersheim
+ jimse at novell.com
+ Usage: URL Extension
+ Specification: RFCXXXX
+ Author/Change Controller: IESG
+ Comments: none
+
+
+ Subject: Request for LDAP Descriptor Registration
+ Descriptor (short name): searchedSubtree
+ Object Identifier: IANA-ASSIGNED-OID.6
+ Person & email address to contact for further information:
+
+
+
+
+
+Sermersheim Expires August 26, 2005 [Page 37]
+Internet-Draft Distributed Procedures for LDAP Operations February 2005
+
+
+
+ Jim Sermersheim
+ jimse at novell.com
+ Usage: URL Extension
+ Specification: RFCXXXX
+ Author/Change Controller: IESG
+ Comments: none
+
+
+ Subject: Request for LDAP Descriptor Registration
+ Descriptor (short name): failedName
+ Object Identifier: IANA-ASSIGNED-OID.7
+ Person & email address to contact for further information:
+ Jim Sermersheim
+ jimse at novell.com
+ Usage: URL Extension
+ Specification: RFCXXXX
+ Author/Change Controller: IESG
+ Comments: none
+
+
+A.4 LDAP Result Code Registrations
+
+
+ It is requested that IANA register upon Standards Action the LDAP
+ result codes described in this document. The following registration
+ templates are given:
+
+
+ Subject: Request for LDAP Result Code Registration
+ Result Code Name: invalidReference
+ Person & email address to contact for further information:
+ Jim Sermersheim
+ jimse at novell.com
+ Usage: URL Extension
+ Specification: RFCXXXX
+ Author/Change Controller: IESG
+ Comments: none
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sermersheim Expires August 26, 2005 [Page 38]
+Internet-Draft Distributed Procedures for LDAP Operations February 2005
+
+
+
+Intellectual Property Statement
+
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr at ietf.org.
+
+
+
+Disclaimer of Validity
+
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+Copyright Statement
+
+
+ Copyright (C) The Internet Society (2005). This document is subject
+ to the rights, licenses and restrictions contained in BCP 78, and
+ except as set forth therein, the authors retain all their rights.
+
+
+
+Acknowledgment
+
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+Sermersheim Expires August 26, 2005 [Page 39]
\ No newline at end of file
Added: openldap/vendor/openldap-release/doc/drafts/draft-sermersheim-ldap-subordinate-scope-xx.txt
===================================================================
--- openldap/vendor/openldap-release/doc/drafts/draft-sermersheim-ldap-subordinate-scope-xx.txt (rev 0)
+++ openldap/vendor/openldap-release/doc/drafts/draft-sermersheim-ldap-subordinate-scope-xx.txt 2007-09-15 10:38:52 UTC (rev 844)
@@ -0,0 +1,335 @@
+
+Network Working Group J;. Sermersheim
+Internet-Draft Novell, Inc
+Updates: 2251 (if approved) July 2004
+Expires: December 30, 2004
+
+
+ Subordinate Subtree Search Scope for LDAP
+ draft-sermersheim-ldap-subordinate-scope-00.txt
+
+Status of this Memo
+
+ This document is an Internet-Draft and is subject to all provisions
+ of section 3 of RFC 3667. By submitting this Internet-Draft, each
+ author represents that any applicable patent or other IPR claims of
+ which he or she is aware have been or will be disclosed, and any of
+ which he or she become aware will be disclosed, in accordance with
+ RFC 3668.
+
+ Internet-Drafts are working documents of the Internet Engineering
+ Task Force (IETF), its areas, and its working groups. Note that
+ other groups may also distribute working documents as
+ Internet-Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference
+ material or to cite them other than as "work in progress."
+
+ The list of current Internet-Drafts can be accessed at
+ http://www.ietf.org/ietf/1id-abstracts.txt.
+
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html.
+
+ This Internet-Draft will expire on December 30, 2004.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2004).
+
+Abstract
+
+ The Lightweight Directory Application Protocol (LDAP) specification
+ supports three scope values for the search operation -- namely:
+ baseObject, singleLevel, and wholeSubtree. This document introduces
+ a subordinateSubtree scope which constrains the search scope to all
+ subordinates of the named base object.
+
+Discussion Forum
+
+
+
+Sermersheim Expires December 30, 2004 [Page 1]
+
+Internet-Draft Subordinate Subtree Search Scope for LDAP July 2004
+
+
+ Technical discussion of this document will take place on the IETF
+ LDAP Extensions mailing list <ldapext at ietf.org>. Please send
+ editorial comments directly to the author.
+
+1. Overview
+
+ There are a number of reasons which have surfaced for introducing a
+ Lightweight Directory Application Protocol (LDAP) [RFC3377]
+ SearchRequest.scope [RFC2251] which constrains the search scope to
+ all subordinates of the named base object, and does not include the
+ base object (as wholeSubtree does). These reasons range from the
+ obvious utility of allowing an LDAP client application the ability to
+ exclude the base object from a wholeSubtree search scope, to
+ distributed operation applications which require this scope for
+ progressing search sub-operations resulting from an nssr DSE type
+ reference.
+
+ To meet these needs, the subordinateSubtree scope value is
+ introduced.
+
+ The subordinateSubtrees cope is applied to the SearchRequest.scope
+ field, the <scope> type and alternately the <extension> type of the
+ LDAP URL [RFC2255] and may be applied to other specifications which
+ include an LDAP search scope. A mechanism is also given which allows
+ LDAP Directory Server Agents (DSA)s to advertise support of this
+ search scope.
+
+2. Application to SearchRequest.scope
+
+ A new item is added to this ENUMERATED type. The identifier is
+ subordinateSubtree and the number is 4.
+
+ A DSA which receives and supports the subordinateSubtree
+ SearchRequest.scope constrains the search scope to all subordinate
+ objects.
+
+ A DSA which receives but does not support the subordinateSubtree
+ SearchRequest.scope returns a protocolError resultCode in the
+ SearchResultDone.
+
+3. LDAP URL applications
+
+ The LDAP URL [RFC2255] specification allows the conveyance of a
+ search scope. This section intoduces two ways in which the
+ subordinateScope search scope may be conveyed in an LDAP URL. One
+ way is by allowing a new "subord" scope in the <scope> part. Another
+ way is through the introduction of an LDAP URL extension. The LDAP
+ URL extension method is preferred for its criticality semantics.
+
+
+
+Sermersheim Expires December 30, 2004 [Page 2]
+
+Internet-Draft Subordinate Subtree Search Scope for LDAP July 2004
+
+
+3.1 Application to LDAP URL <scope>
+
+ A new <scope> value of "subord" is added. Using the <scope> type
+ from LDAP URL [RFC2255], the ABNF is as follows:
+
+ scope /= "subord"
+
+ Implementations processing but which do not understand or support the
+ "subord" <scope> of an LDAP URL raise an appropriate error.
+
+3.2 Application to LDAP URL <extension>
+
+ An LDAP URL <extension> mechanism is introduced here. The <extype>
+ is IANA-ASSIGNED-OID.1 or the descriptor 'subordScope', and the
+ exvalue is omitted. The extension may be marked as either critical
+ or non-critical.
+
+ If supported, the subordScope extension overrides any value set in
+ the <scope> field.
+
+4. DSA Advertisement of support
+
+ A DSA may advertise its support of the subordinateSubtree item in the
+ SearchRequest.scope by inclusion of IANA-ASSIGNED-OID.2 in the
+ 'supportedFeatures' attribute of the root DSE.
+
+5. Security Considerations
+
+ This specification introduces no security concerns above any
+ associated with the existing wholeSubtree search scope value.
+
+ As with the wholeSubtree search scope, this scope specifies that a
+ search be applied to an entire subtree hierarchy. Implementations
+ should be aware of the relative cost of using or allowing this scope.
+
+6 Normative References
+
+ [RFC2251] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory
+ Access Protocol (v3)", RFC 2251, December 1997.
+
+ [RFC2255] Howes, T. and M. Smith, "The LDAP URL Format", RFC 2255,
+ December 1997.
+
+ [RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access
+ Protocol (v3): Technical Specification", RFC 3377,
+ September 2002.
+
+ [RFC3383] Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
+
+
+
+Sermersheim Expires December 30, 2004 [Page 3]
+
+Internet-Draft Subordinate Subtree Search Scope for LDAP July 2004
+
+
+ Considerations for the Lightweight Directory Access
+ Protocol (LDAP)", BCP 64, RFC 3383, September 2002.
+
+
+Author's Address
+
+ Jim Sermersheim
+ Novell, Inc
+ 1800 South Novell Place
+ Provo, Utah 84606
+ USA
+
+ Phone: +1 801 861-3088
+ EMail: jimse at novell.com
+
+Appendix A. IANA Considerations
+
+ Registration of the following values is requested [RFC3383].
+
+A.1 LDAP Object Identifier Registrations
+
+ It is requested that IANA register upon Standards Action an LDAP
+ Object Identifier in identifying the protocol elements defined in
+ this technical specification. The following registration template is
+ provided:
+
+ Subject: Request for LDAP OID Registration
+ Person & email address to contact for further information:
+ Jim Sermersheim
+ jimse at novell.com
+ Specification: RFCXXXX
+ Author/Change Controller: IESG
+ Comments:
+ 2 delegations will be made under the assigned OID:
+ IANA-ASSIGNED-OID.1 subordScope LDAP URL extension
+ IANA-ASSIGNED-OID.2 subordinateScope Supported Feature
+
+A.2 LDAP Protocol Mechanism Registrations
+
+ It is requested that IANA register upon Standards Action the LDAP
+ protocol mechanism described in this document. The following
+ registration templates are given:
+
+ Subject: Request for LDAP Protocol Mechanism Registration
+ Object Identifier: IANA-ASSIGNED-OID.1
+ Description: subordScope LDAP URL extension
+ Person & email address to contact for further information:
+
+
+
+
+Sermersheim Expires December 30, 2004 [Page 4]
+
+Internet-Draft Subordinate Subtree Search Scope for LDAP July 2004
+
+
+ Jim Sermersheim
+ jimse at novell.com
+ Usage: Extension
+ Specification: RFCXXXX
+ Author/Change Controller: IESG
+ Comments: none
+
+A.3 LDAP Descriptor Registrations
+
+ It is requested that IANA register upon Standards Action the LDAP
+ descriptors described in this document. The following registration
+ templates are given:
+
+ Subject: Request for LDAP Descriptor Registration
+ Descriptor (short name): subordScope
+ Object Identifier: IANA-ASSIGNED-OID.1
+ Person & email address to contact for further information:
+ Jim Sermersheim
+ jimse at novell.com
+ Usage: URL Extension
+ Specification: RFCXXXX
+ Author/Change Controller: IESG
+ Comments: none
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sermersheim Expires December 30, 2004 [Page 5]
+
+Internet-Draft Subordinate Subtree Search Scope for LDAP July 2004
+
+
+Intellectual Property Statement
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr at ietf.org.
+
+
+Disclaimer of Validity
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+Copyright Statement
+
+ Copyright (C) The Internet Society (2004). This document is subject
+ to the rights, licenses and restrictions contained in BCP 78, and
+ except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+Sermersheim Expires December 30, 2004 [Page 6]
+
Added: openldap/vendor/openldap-release/doc/drafts/draft-zeilenga-ldap-adlist-xx.txt
===================================================================
--- openldap/vendor/openldap-release/doc/drafts/draft-zeilenga-ldap-adlist-xx.txt (rev 0)
+++ openldap/vendor/openldap-release/doc/drafts/draft-zeilenga-ldap-adlist-xx.txt 2007-09-15 10:38:52 UTC (rev 844)
@@ -0,0 +1,339 @@
+
+
+
+
+
+
+INTERNET-DRAFT Kurt D. Zeilenga
+Intended Category: Informational OpenLDAP Foundation
+Expires in six months 18 July 2005
+
+
+
+ Requesting Attributes by Object Class in the
+ Lightweight Directory Access Protocol
+ <draft-zeilenga-ldap-adlist-11.txt>
+
+
+Status of this Memo
+
+ This document is intended to be, after appropriate review and
+ revision, submitted to the RFC Editor as an Informational document.
+ Distribution of this memo is unlimited. Technical discussion of this
+ document will take place on the IETF LDAP Extensions mailing list
+ <ldapext at ietf.org>. Please send editorial comments directly to the
+ author <Kurt at OpenLDAP.org>.
+
+ By submitting this Internet-Draft, each author represents that any
+ applicable patent or other IPR claims of which he or she is aware have
+ been or will be disclosed, and any of which he or she becomes aware
+ will be disclosed, in accordance with Section 6 of BCP 79.
+
+ Internet-Drafts are working documents of the Internet Engineering Task
+ Force (IETF), its areas, and its working groups. Note that other
+ groups may also distribute working documents as Internet-Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference material
+ or to cite them other than as "work in progress."
+
+ The list of current Internet-Drafts can be accessed at
+ http://www.ietf.org/1id-abstracts.html
+
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html
+
+
+ Copyright (C) The Internet Society (2005). All Rights Reserved.
+
+ Please see the Full Copyright section near the end of this document
+ for more information.
+
+
+
+
+
+
+Zeilenga Requesting Attributes by Object Class [Page 1]
+
+INTERNET-DRAFT draft-zeilenga-ldap-adlist-11 18 July 2005
+
+
+Abstract
+
+ The Lightweight Directory Access Protocol (LDAP) search operation
+ provides mechanisms for clients to request all user application
+ attributes, all operational attributes, and/or attributes selected by
+ their description. This document extends LDAP to support a mechanism
+ that LDAP clients may use to request the return of all attributes of
+ an object class.
+
+
+1. Background and Intended Use
+
+ In the Lightweight Directory Access Protocol (LDAP) [Roadmap], the
+ search operation [Protocol] support requesting the return of a set of
+ attributes. This set is determined by a list of attribute
+ descriptions. Two special descriptors are defined to request all user
+ attributes ("*") [Protocol] and all operational attributes ("+")
+ [RFC3673]. However, there is no convenient mechanism for requesting
+ pre-defined sets of attributes such as the set of attributes used to
+ represent a particular class of object.
+
+ This document extends LDAP to allow an object class identifier to be
+ specified in attributes lists, such as in Search requests, to request
+ the return all attributes belonging to an object class. The
+ COMMERCIAL AT ("@", U+0040) character is used to distinguish an object
+ class identifier from an attribute descriptions.
+
+ For example, the attribute list of "@country" is equivalent to the
+ attribute list of 'c', 'searchGuide', 'description', and
+ 'objectClass'. This object class is described in [Schema].
+
+ This extension is intended primarily to be used where the user is in
+ direct control of the parameters of the LDAP search operation, for
+ instance when entering a LDAP URL [LDAPURL] into a web browser. For
+ example, <ldap:///dc=example,dc=com?@organization?base>.
+
+2. Terminology
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in BCP 14 [RFC2119].
+
+ DSA stands for Directory System Agent (or server).
+ DSE stands for DSA-specific Entry.
+
+
+3. Return of all Attributes of an Object Class
+
+
+
+
+Zeilenga Requesting Attributes by Object Class [Page 2]
+
+INTERNET-DRAFT draft-zeilenga-ldap-adlist-11 18 July 2005
+
+
+ This extension allows object class identifiers is to be provided in
+ the attributes field of the LDAP SearchRequest [Protocol] or other
+ request values of the AttributeSelection data type (e.g., attributes
+ field in pre/post read controls [ReadEntry]) and/or
+ <attributeSelector> production (e.g., attributes of an LDAP URL
+ [LDAPURL]). For each object class identified in the attributes field,
+ the request is to be treated as if each attribute allowed by that
+ class (by "MUST" or "MAY", directly or by "SUP"erior) [Models] was
+ itself listed.
+
+ This extension extends attributeSelector [Protocol] production as
+ indicated by the following ABNF [ABNF]:
+
+ attributeSelector /= objectclassdescription
+ objectclassdescription = ATSIGN oid options
+ ATSIGN = %x40 ; COMMERCIAL AT ("@" U+0040)
+
+ where <oid> and <options> productions are as defined in [Models].
+
+ The <oid> component of an <objectclassdescription> production
+ identifies the object class by short name (descr) or object identifier
+ (numericoid). If the value of the <oid> component is unrecognized or
+ does not refer to an object class, the object class description is be
+ treated an an unrecognized attribute description.
+
+ The <options> production is included in the grammar for extensibility
+ purposes. An object class description with an unrecognized or
+ inappropriate option is to be treated as an unrecognized.
+
+ While object class description options and attribute description
+ options share the same syntax, they are not semantically related.
+ This document does not define any object description option.
+
+ Servers supporting this feature SHOULD publish the object identifier
+ (OID) 1.3.6.1.4.1.4203.1.5.2 as a value of the 'supportedFeatures'
+ [Models] attribute in the root DSE. Clients supporting this feature
+ SHOULD NOT use the feature unless they have knowledge the server
+ supports it.
+
+
+3. Security Considerations
+
+ This extension provides a shorthand for requesting all attributes of
+ an object class. As these attributes which could have been listed
+ individually, introduction of this shorthand is not believed to raise
+ additional security considerations.
+
+ Implementors of this LDAP extension should be familiar with security
+
+
+
+Zeilenga Requesting Attributes by Object Class [Page 3]
+
+INTERNET-DRAFT draft-zeilenga-ldap-adlist-11 18 July 2005
+
+
+ considerations applicable to the LDAP search operation [Protocol], as
+ well as general LDAP security considerations [Roadmap].
+
+
+4. IANA Considerations
+
+ Registration of the LDAP Protocol Mechanism [BCP64bis] defined in
+ document is requested.
+
+ Subject: Request for LDAP Protocol Mechanism Registration
+ Object Identifier: 1.3.6.1.4.1.4203.1.5.2
+ Description: OC AD Lists
+ Person & email address to contact for further information:
+ Kurt Zeilenga <kurt at openldap.org>
+ Usage: Feature
+ Specification: RFC XXXX
+ Author/Change Controller: Kurt Zeilenga <kurt at openldap.org>
+ Comments: none
+
+ This OID was assigned [ASSIGN] by OpenLDAP Foundation, under its
+ IANA-assigned private enterprise allocation [PRIVATE], for use in this
+ specification.
+
+
+5. Author's Address
+
+ Kurt D. Zeilenga
+ OpenLDAP Foundation
+
+ Email: Kurt at OpenLDAP.org
+
+
+6. References
+
+ [[Note to the RFC Editor: please replace the citation tags used in
+ referencing Internet-Drafts with tags of the form RFCnnnn where
+ possible.]]
+
+
+6.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14 (also RFC 2119), March 1997.
+
+ [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
+ Specifications: ABNF", draft-crocker-abnf-rfc2234bis, a
+ work in progress.
+
+
+
+
+Zeilenga Requesting Attributes by Object Class [Page 4]
+
+INTERNET-DRAFT draft-zeilenga-ldap-adlist-11 18 July 2005
+
+
+ [Roadmap] Zeilenga, K. (editor), "LDAP: Technical Specification
+ Road Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in
+ progress.
+
+ [Protocol] Sermersheim, J. (editor), "LDAP: The Protocol",
+ draft-ietf-ldapbis-protocol-xx.txt, a work in progress.
+
+ [Models] Zeilenga, K. (editor), "LDAP: Directory Information
+ Models", draft-ietf-ldapbis-models-xx.txt, a work in
+ progress.
+
+ [LDAPURL] Smith, M. (editor), "LDAP: Uniform Resource Locator",
+ draft-ietf-ldapbis-url-xx.txt, a work in progress.
+
+ [X.680] International Telecommunication Union -
+ Telecommunication Standardization Sector, "Abstract
+ Syntax Notation One (ASN.1) - Specification of Basic
+ Notation", X.680(2002) (also ISO/IEC 8824-1:2002).
+
+
+6.2. Informative References
+
+ [RFC3673] Zeilenga, K., "LDAPv3: All Operational Attributes", RFC
+ 3673, December 2003.
+
+ [Schema] Dally, K. (editor), "LDAP: User Schema",
+ draft-ietf-ldapbis-user-schema-xx.txt, a work in
+ progress.
+
+ [BCP64bis] Zeilenga, K., "IANA Considerations for LDAP",
+ draft-ietf-ldapbis-bcp64-xx.txt, a work in progress.
+
+ [ReadEntry] Zeilenga, K., "LDAP Read Entry Controls",
+ draft-zeilenga-ldap-readentry-xx.txt, a work in
+ progress.
+
+ [ASSIGN] OpenLDAP Foundation, "OpenLDAP OID Delegations",
+ http://www.openldap.org/foundation/oid-delegate.txt.
+
+ [PRIVATE] IANA, "Private Enterprise Numbers",
+ http://www.iana.org/assignments/enterprise-numbers.
+
+
+
+Full Copyright
+
+ Copyright (C) The Internet Society (2005).
+
+
+
+
+Zeilenga Requesting Attributes by Object Class [Page 5]
+
+INTERNET-DRAFT draft-zeilenga-ldap-adlist-11 18 July 2005
+
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+Intellectual Property Rights
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be found
+ in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this specification
+ can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr at ietf.org.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga Requesting Attributes by Object Class [Page 6]
+
Added: openldap/vendor/openldap-release/doc/drafts/draft-zeilenga-ldap-assert-xx.txt
===================================================================
--- openldap/vendor/openldap-release/doc/drafts/draft-zeilenga-ldap-assert-xx.txt (rev 0)
+++ openldap/vendor/openldap-release/doc/drafts/draft-zeilenga-ldap-assert-xx.txt 2007-09-15 10:38:52 UTC (rev 844)
@@ -0,0 +1,340 @@
+
+
+
+
+
+INTERNET-DRAFT Kurt D. Zeilenga
+Intended Category: Standard Track OpenLDAP Foundation
+Expires in six months 10 February 2005
+
+
+
+ The LDAP Assertion Control
+ <draft-zeilenga-ldap-assert-05.txt>
+
+
+Status of this Memo
+
+ This document is intended to be, after appropriate review and
+ revision, submitted to the IESG for consideration as a Standard Track
+ document. Distribution of this memo is unlimited. Technical
+ discussion of this document will take place on the IETF LDAP
+ Extensions mailing list <ldapext at ietf.org>. Please send editorial
+ comments directly to the author <Kurt at OpenLDAP.org>.
+
+ By submitting this Internet-Draft, I accept the provisions of Section
+ 4 of RFC 3667. By submitting this Internet-Draft, I certify that any
+ applicable patent or other IPR claims of which I am aware have been
+ disclosed, or will be disclosed, and any of which I become aware will
+ be disclosed, in accordance with RFC 3668.
+
+ Internet-Drafts are working documents of the Internet Engineering Task
+ Force (IETF), its areas, and its working groups. Note that other
+ groups may also distribute working documents as Internet-Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference material
+ or to cite them other than as "work in progress."
+
+ The list of current Internet-Drafts can be accessed at
+ http://www.ietf.org/1id-abstracts.html
+
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html
+
+
+ Copyright (C) The Internet Society (2005). All Rights Reserved.
+
+ Please see the Full Copyright section near the end of this document
+ for more information.
+
+
+
+
+
+
+Zeilenga LDAP Assertion Control [Page 1]
+
+INTERNET-DRAFT draft-zeilenga-ldap-assert-05 10 February 2005
+
+
+Abstract
+
+ This document defines the Lightweight Directory Access Protocol (LDAP)
+ Assertion Control which allows a client to specify that a directory
+ operation should only be processed if an assertion applied to the
+ target entry of the operation is true. It can be used to construct
+ "test and set" and "test and clear" and other conditional operations.
+
+
+1. Overview
+
+ This document defines the Lightweight Directory Access Protocol (LDAP)
+ [Roadmap] assertion control. The assertion control allows the client
+ to specify a condition which must be true for the operation to be
+ processed normally. Otherwise the operation fails. For instance, the
+ control can be used with the Modify operation [Protocol] to perform
+ atomic "test and set" and "test and clear" operations.
+
+ The control may be attached to any update operation to support
+ conditional addition, deletion, modification, and renaming of the
+ target object. The asserted condition is evaluated as an integral
+ part the operation.
+
+ The control may also be used with the search operation. Here the
+ assertion is applied to the base object of the search before searching
+ for objects matching the search scope and filter.
+
+ The control may also be used with the compare operation. Here it
+ extends the compare operation to allow a more complex assertion.
+
+
+2. Terminology
+
+ Protocol elements are described using ASN.1 [X.680] with implicit
+ tags. The term "BER-encoded" means the element is to be encoded using
+ the Basic Encoding Rules [X.690] under the restrictions detailed in
+ Section 5.2 of [Protocol].
+
+ DSA stands for Directory System Agent (or server).
+ DSE stands for DSA-specific Entry.
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in BCP 14 [RFC2119].
+
+
+3. The Assertion Control
+
+
+
+
+Zeilenga LDAP Assertion Control [Page 2]
+
+INTERNET-DRAFT draft-zeilenga-ldap-assert-05 10 February 2005
+
+
+ The assertion control is an LDAP Control [Protocol] whose controlType
+ is IANA-ASSIGNED-OID and controlValue is a BER-encoded Filter
+ [Protocol, Section 4.5.1]. The criticality may be TRUE or FALSE.
+ There is no corresponding response control.
+
+ The control is appropriate for both LDAP interrogation and update
+ operations [Protocol] including Add, Compare, Delete, Modify, ModifyDN
+ (rename), and Search. It is inappropriate for Abandon, Bind nor
+ Unbind, and Start TLS operations.
+
+ When the control is attached to an LDAP request, the processing of the
+ request is conditional on the evaluation of the Filter as applied
+ against the target of the operation. If the Filter evaluates to TRUE,
+ then the request is processed normally. If the Filter evaluates to
+ FALSE or Undefined, then assertionFailed (IANA-ASSIGNED-CODE)
+ resultCode is returned and no further processing is performed.
+
+ For Add, Compare, and ModifyDN the target is indicated by the entry
+ field in the request. For Modify, the target is indicated by the
+ object field. For Delete, the target is indicated by the DelRequest
+ type. For the Compare operation and all update operations, the
+ evaluation of the assertion MUST be performed as an integral part of
+ the operation. That is, the evaluation of the assertion and the
+ normal processing of the operation SHALL be done as one atomic action.
+
+ For search operation, the target is indicated by the baseObject field
+ and the evaluation is done after "finding" but before "searching"
+ [Protocol]. Hence, no entries or continuations references are
+ returned if the assertion fails.
+
+ Servers implementing this technical specification SHOULD publish the
+ object identifier IANA-ASSIGNED-OID as a value of the
+ 'supportedControl' attribute [Models] in their root DSE. A server MAY
+ choose to advertise this extension only when the client is authorized
+ to use it.
+
+ Other documents may specify how this control applies to other LDAP
+ operations. In doing so, they must state how the target entry is
+ determined.
+
+
+4. Security Considerations
+
+ The filter may, like other components of the request, contain
+ sensitive information. When so, this information should be
+ appropriately protected.
+
+ As with any general assertion mechanism, the mechanism can be used to
+
+
+
+Zeilenga LDAP Assertion Control [Page 3]
+
+INTERNET-DRAFT draft-zeilenga-ldap-assert-05 10 February 2005
+
+
+ determine directory content. Hence, this mechanism SHOULD be subject
+ to appropriate access controls.
+
+ Some assertions may be very complex, requiring significant time and
+ resources to evaluate. Hence, this mechanism SHOULD be subject to
+ appropriate administrative controls.
+
+ Security considerations for the base operations [Protocol] extended by
+ this control, as well as general LDAP security considerations
+ [Roadmap], generally apply to implementation and use of this
+ extension.
+
+
+5. IANA Considerations
+
+5.1. Object Identifier
+
+ It is requested that IANA assign upon Standards Action an LDAP Object
+ Identifier [BCP64bis] to identify the LDAP Assertion Control defined
+ in this document.
+
+ Subject: Request for LDAP Object Identifier Registration
+ Person & email address to contact for further information:
+ Kurt Zeilenga <kurt at OpenLDAP.org>
+ Specification: RFC XXXX
+ Author/Change Controller: IESG
+ Comments:
+ Identifies the LDAP Assertion Control
+
+5.2 LDAP Protocol Mechanism
+
+ Registration of this protocol mechanism [BCP64bis] is requested.
+
+ Subject: Request for LDAP Protocol Mechanism Registration
+ Object Identifier: IANA-ASSIGNED-OID
+ Description: Assertion Control
+ Person & email address to contact for further information:
+ Kurt Zeilenga <kurt at openldap.org>
+ Usage: Control
+ Specification: RFC XXXX
+ Author/Change Controller: IESG
+ Comments: none
+
+
+5.3 LDAP Result Code
+
+ Assignment of an LDAP Result Code [BCP64bis] called 'assertionFailed'
+ is requested.
+
+
+
+Zeilenga LDAP Assertion Control [Page 4]
+
+INTERNET-DRAFT draft-zeilenga-ldap-assert-05 10 February 2005
+
+
+ Subject: LDAP Result Code Registration
+ Person & email address to contact for further information:
+ Kurt Zeilenga <kurt at OpenLDAP.org>
+ Result Code Name: assertionFailed
+ Specification: RFC XXXX
+ Author/Change Controller: IESG
+ Comments: none
+
+
+6. Acknowledgments
+
+ The assertion control concept is attributed to Morteza Ansari.
+
+
+7. Author's Address
+
+ Kurt D. Zeilenga
+ OpenLDAP Foundation
+
+ Email: Kurt at OpenLDAP.org
+
+
+8. References
+
+ [[Note to the RFC Editor: please replace the citation tags used in
+ referencing Internet-Drafts with tags of the form RFCnnnn where
+ possible.]]
+
+
+8.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14 (also RFC 2119), March 1997.
+
+ [Roadmap] Zeilenga, K. (editor), "LDAP: Technical Specification
+ Road Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in
+ progress.
+
+ [Protocol] Sermersheim, J. (editor), "LDAP: The Protocol",
+ draft-ietf-ldapbis-protocol-xx.txt, a work in progress.
+
+ [Models] Zeilenga, K. (editor), "LDAP: Directory Information
+ Models", draft-ietf-ldapbis-models-xx.txt, a work in
+ progress.
+
+
+8.2. Informative References
+
+
+
+
+Zeilenga LDAP Assertion Control [Page 5]
+
+INTERNET-DRAFT draft-zeilenga-ldap-assert-05 10 February 2005
+
+
+ [BCP64bis] Zeilenga, K., "IANA Considerations for LDAP",
+ draft-ietf-ldapbis-bcp64-xx.txt, a work in progress.
+
+
+
+Intellectual Property Rights
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be found
+ in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this specification
+ can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr at ietf.org.
+
+
+
+Full Copyright
+
+ Copyright (C) The Internet Society (2005). This document is subject
+ to the rights, licenses and restrictions contained in BCP 78, and
+ except as set forth therein, the authors retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+
+
+
+
+Zeilenga LDAP Assertion Control [Page 6]
+
+
+
Added: openldap/vendor/openldap-release/doc/drafts/draft-zeilenga-ldap-authzid-xx.txt
===================================================================
--- openldap/vendor/openldap-release/doc/drafts/draft-zeilenga-ldap-authzid-xx.txt (rev 0)
+++ openldap/vendor/openldap-release/doc/drafts/draft-zeilenga-ldap-authzid-xx.txt 2007-09-15 10:38:52 UTC (rev 844)
@@ -0,0 +1,445 @@
+INTERNET-DRAFT Kurt D. Zeilenga
+Intended Category: Standard Track OpenLDAP Foundation
+Expires in six months 19 November 2004
+
+
+
+ LDAP "Who am I?" Operation
+ <draft-zeilenga-ldap-authzid-10.txt>
+
+
+Status of this Memo
+
+ This document is intended to be, after appropriate review and
+ revision, submitted to the RFC Editor as a Standard Track document.
+ Distribution of this memo is unlimited. Technical discussion of this
+ document will take place on the IETF LDAP Extensions mailing list
+ <ldapext at ietf.org>. Please send editorial comments directly to the
+ author <Kurt at OpenLDAP.org>.
+
+ By submitting this Internet-Draft, I accept the provisions of Section
+ 4 of RFC 3667. By submitting this Internet-Draft, I certify that any
+ applicable patent or other IPR claims of which I am aware have been
+ disclosed, or will be disclosed, and any of which I become aware will
+ be disclosed, in accordance with RFC 3668.
+
+ Internet-Drafts are working documents of the Internet Engineering Task
+ Force (IETF), its areas, and its working groups. Note that other
+ groups may also distribute working documents as Internet-Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference material
+ or to cite them other than as "work in progress."
+
+ The list of current Internet-Drafts can be accessed at
+ <http://www.ietf.org/ietf/1id-abstracts.txt>. The list of
+ Internet-Draft Shadow Directories can be accessed at
+ <http://www.ietf.org/shadow.html>.
+
+ Copyright (C) The Internet Society (2004). All Rights Reserved.
+
+ Please see the Full Copyright section near the end of this document
+ for more information.
+
+
+Abstract
+
+ This specification provides a mechanism for Lightweight Directory
+
+
+
+Zeilenga LDAP "Who am I?" [Page 1]
+
+INTERNET-DRAFT draft-zeilenga-ldap-authzid-10 19 November 2004
+
+
+ Access Protocol (LDAP) clients to obtain the authorization identity
+ which the server has associated with the user or application entity.
+ This mechanism is specified as an LDAP extended operation called the
+ LDAP "Who am I?" operation.
+
+
+Conventions
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in BCP 14 [RFC2119].
+
+
+1. Background and Intent of Use
+
+ This specification describes a Lightweight Directory Access Protocol
+ (LDAP) [RFC3377] operation which clients can use to obtain the primary
+ authorization identity in its primary form which the server has
+ associated with the user or application entity. The operation is
+ called the "Who am I?" operation.
+
+ This specification is intended to replace the existing [AUTHRESP]
+ mechanism which uses Bind request and response controls to request and
+ return the authorization identity. Bind controls are not protected by
+ the security layers established by the Bind operation which includes
+ them. While it is possible to establish security layers using Start
+ TLS [RFC2830] prior to the Bind operation, it is often desirable to
+ use security layers established by the Bind operation. An extended
+ operation sent after a Bind operation is protected by the security
+ layers established by the Bind operation.
+
+ There are other cases where it is desirable to request the
+ authorization identity which the server associated with the client
+ separately from the Bind operation. For example, the "Who am I?"
+ operation can be augmented with a Proxied Authorization Control
+ [PROXYAUTH] to determine the authorization identity which the server
+ associates with the identity asserted in the Proxied Authorization
+ Control. The "Who am I?" operation can also be used prior to the Bind
+ operation.
+
+ Servers often associate multiple authorization identities with the
+ client and each authorization identity may be represented by multiple
+ authzId [RFC2829] strings. This operation requests and returns the
+ authzId the server considers to be primary. In the specification, the
+ term "the authorization identity" and "the authzId" are generally to
+ be read as "the primary authorization identity" and the "the primary
+ authzId", respectively.
+
+
+
+
+Zeilenga LDAP "Who am I?" [Page 2]
+
+INTERNET-DRAFT draft-zeilenga-ldap-authzid-10 19 November 2004
+
+
+2. The "Who am I?" Operation
+
+ The "Who am I?" operation is defined as an LDAP Extended Operation
+ [RFC2251, Section 4.12] identified by the whoamiOID Object Identifier
+ (OID). This section details the syntax of the operation's whoami
+ request and response messages.
+
+ whoamiOID ::= "1.3.6.1.4.1.4203.1.11.3"
+
+
+2.1. The whoami Request
+
+ The whoami request is an ExtendedRequest with the requestName field
+ containing the whoamiOID OID and an absent requestValue field. For
+ example, a whoami request could be encoded as the sequence of octets
+ (in hex):
+
+ 30 1e 02 01 02 77 19 80 17 31 2e 33 2e 36 2e 31
+ 2e 34 2e 31 2e 34 32 30 33 2e 31 2e 31 31 2e 33
+
+
+2.2. The whoami Response
+
+ The whoami response is an ExtendedResponse where the responseName
+ field is absent and the response field, if present, is empty or an
+ authzId [RFC2829]. For example, a whoami response returning the
+ authzId "u:xxyyz at EXAMPLE.NET" (in response to the example request)
+ would be encoded as the sequence of octets (in hex):
+
+ 30 21 02 01 02 78 1c 0a 01 00 04 00 04 00 8b 13
+ 75 3a 78 78 79 79 7a 40 45 58 41 4d 50 4c 45 2e
+ 4e 45 54
+
+
+3. Operational Semantics
+
+ The "Who am I?" operation provides a mechanism, a whoami Request, for
+ the client to request that the server returns the authorization
+ identity it currently associates with the client and provides a
+ mechanism, a whoami Response, for the server to respond to that
+ request.
+
+ Servers indicate their support for this extended operation by
+ providing whoamiOID object identifier as a value of the
+ 'supportedExtension' attribute type in their root DSE. Server SHOULD
+ advertise this extension only when the client is willing and able to
+ perform this operation.
+
+
+
+
+Zeilenga LDAP "Who am I?" [Page 3]
+
+INTERNET-DRAFT draft-zeilenga-ldap-authzid-10 19 November 2004
+
+
+ If the server is willing and able to provide the authorization
+ identity it associates with the client, the server SHALL return a
+ whoami Response with a success resultCode. If the server is treating
+ the client as an anonymous entity, the response field is present but
+ empty. Otherwise the server provides the authzId [RFC2829]
+ representing the authorization identity it currently associates with
+ the client in the response field.
+
+ If the server is unwilling or unable to provide the authorization
+ identity it associates with the client, the server SHALL return a
+ whoami Response with an appropriate non-success resultCode (such as
+ operationsError, protocolError, confidentialityRequired,
+ insufficientAccessRights, busy, unavailable, unwillingToPerform, or
+ other) and an absent response field.
+
+ As described in [RFC2251] and [RFC2829], an LDAP session has an
+ "anonymous" association until the client has been successfully
+ authenticated using the Bind operation. Clients MUST NOT invoke the
+ "Who Am I?" operation while any Bind operation is in progress,
+ including between two Bind requests made as part of a multi-stage Bind
+ operation. Where a whoami Request is received in violation of this
+ absolute prohibition, the server should return a whoami Response with
+ an operationsError resultCode.
+
+
+4. Extending the "Who am I?" operation with controls
+
+ Future specifications may extend the "Who am I?" operation using the
+ control mechanism [RFC2251]. When extended by controls, the "Who am
+ I?" operation requests and returns the authorization identity the
+ server associates with the client in a particular context indicated by
+ the controls.
+
+
+4.1. Proxied Authorization Control
+
+ The Proxied Authorization Control [PROXYAUTH] is used by clients to
+ request that the operation it is attached to operates under the
+ authorization of an assumed identity. The client provides the
+ identity to assume in the Proxied Authorization request control. If
+ the client is authorized to assume the requested identity, the server
+ executes the operation as if the requested identity had issued the
+ operation.
+
+ As servers often map the asserted authzId to another identity
+ [RFC2829], it is desirable to request the server provide the authzId
+ it associates with the assumed identity.
+
+
+
+
+Zeilenga LDAP "Who am I?" [Page 4]
+
+INTERNET-DRAFT draft-zeilenga-ldap-authzid-10 19 November 2004
+
+
+ When a Proxied Authorization Control is be attached to the "Who Am I?"
+ operation, the operation requests the return of the authzId the server
+ associates with the identity asserted in the Proxied Authorization
+ Control. The TBD result code is used to indicate that the server does
+ not allow the client to assume the asserted identity. [[Note to RFC
+ Editor: TBD is to be replaced with the name/code assigned by IANA for
+ [PROXYAUTH] use.]]
+
+
+5. Security Considerations
+
+ Identities associated with users may be sensitive information. When
+ so, security layers [RFC2829][RFC2830] should be established to
+ protect this information. This mechanism is specifically designed to
+ allow security layers established by a Bind operation to protect the
+ integrity and/or confidentiality of the authorization identity.
+
+ Servers may place access control or other restrictions upon the use of
+ this operation. As stated in Section 3, the server SHOULD advertise
+ this extension when it is willing and able to perform the operation.
+
+ As with any other extended operations, general LDAP security
+ considerations [RFC3377] apply.
+
+
+6. IANA Considerations
+
+ The OID 1.3.6.1.4.1.4203.1.11.3 is used to identify the LDAP "Who Am
+ I?" extended operation. This OID was assigned [ASSIGN] by OpenLDAP
+ Foundation, under its IANA-assigned private enterprise allocation
+ [PRIVATE], for use in this specification.
+
+ Registration of this protocol mechanism [RFC3383] is requested.
+
+ Subject: Request for LDAP Protocol Mechanism Registration
+ Object Identifier: 1.3.6.1.4.1.4203.1.11.3
+ Description: Who am I?
+ Person & email address to contact for further information:
+ Kurt Zeilenga <kurt at openldap.org>
+ Usage: Extended Operation
+ Specification: RFC XXXX
+ Author/Change Controller: IESG
+ Comments: none
+
+
+7. Acknowledgment
+
+ This document borrows from prior work in this area including
+
+
+
+Zeilenga LDAP "Who am I?" [Page 5]
+
+INTERNET-DRAFT draft-zeilenga-ldap-authzid-10 19 November 2004
+
+
+ "Authentication Response Control" [AUTHRESP] by Rob Weltman, Mark
+ Smith and Mark Wahl.
+
+ The LDAP "Who am I?" operation takes it name from the UNIX whoami(1)
+ command. The whoami(1) command displays the effective user id.
+
+
+8. Author's Address
+
+ Kurt D. Zeilenga
+ OpenLDAP Foundation
+
+ Email: Kurt at OpenLDAP.org
+
+
+9. References
+
+ [[Note to the RFC Editor: please replace the citation tags used in
+ referencing Internet-Drafts with tags of the form RFCnnnn where
+ possible.]]
+
+
+9.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14 (also RFC 2119), March 1997.
+
+ [RFC2251] Wahl, M., T. Howes and S. Kille, "Lightweight Directory
+ Access Protocol (v3)", RFC 2251, December 1997.
+
+ [RFC2829] Wahl, M., H. Alvestrand, and J. Hodges, RL "Bob" Morgan,
+ "Authentication Methods for LDAP", RFC 2829, June 2000.
+
+ [RFC2830] Hodges, J., R. Morgan, and M. Wahl, "Lightweight
+ Directory Access Protocol (v3): Extension for Transport
+ Layer Security", RFC 2830, May 2000.
+
+ [RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access
+ Protocol (v3): Technical Specification", RFC 3377,
+ September 2002.
+
+ [PROXYAUTH] Weltman, R., "LDAP Proxy Authentication Control",
+ draft-weltman-ldapv3-proxy-xx.txt, a work in progress.
+
+
+9.2. Informative References
+
+ [RFC3383] Zeilenga, K., "IANA Considerations for LDAP", BCP 64
+
+
+
+Zeilenga LDAP "Who am I?" [Page 6]
+
+INTERNET-DRAFT draft-zeilenga-ldap-authzid-10 19 November 2004
+
+
+ (also RFC 3383), September 2002.
+
+ [AUTHRESP] Weltman, R., M. Smith and M. Wahl, "LDAP Authorization
+ Identity Response and Request Controls",
+ draft-weltman-ldapv3-auth-response-xx.txt, a work in
+ progress.
+
+ [ASSIGN] OpenLDAP Foundation, "OpenLDAP OID Delegations",
+ http://www.openldap.org/foundation/oid-delegate.txt.
+
+ [PRIVATE] IANA, "Private Enterprise Numbers",
+ http://www.iana.org/assignments/enterprise-numbers.
+
+
+
+Intellectual Property Rights
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be found
+ in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this specification
+ can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr at ietf.org.
+
+
+
+Full Copyright
+
+ Copyright (C) The Internet Society (2004). This document is subject
+ to the rights, licenses and restrictions contained in BCP 78, and
+ except as set forth therein, the authors retain all their rights.
+
+ This document and the information contained herein are provided on an
+
+
+
+Zeilenga LDAP "Who am I?" [Page 7]
+
+INTERNET-DRAFT draft-zeilenga-ldap-authzid-10 19 November 2004
+
+
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga LDAP "Who am I?" [Page 8]
+
Added: openldap/vendor/openldap-release/doc/drafts/draft-zeilenga-ldap-cosine-xx.txt
===================================================================
--- openldap/vendor/openldap-release/doc/drafts/draft-zeilenga-ldap-cosine-xx.txt (rev 0)
+++ openldap/vendor/openldap-release/doc/drafts/draft-zeilenga-ldap-cosine-xx.txt 2007-09-15 10:38:52 UTC (rev 844)
@@ -0,0 +1,1403 @@
+
+
+
+
+
+
+INTERNET-DRAFT Editor: Kurt D. Zeilenga
+Intended Category: Standard Track OpenLDAP Foundation
+Expires in six months 23 October 2005
+Obsoletes: RFC 1274, RFC 2247
+Updates: RFC 2798
+
+
+ COSINE LDAP/X.500 Schema
+ <draft-zeilenga-ldap-cosine-01.txt>
+
+
+Status of this Memo
+
+ This document is intended to be, after appropriate review and
+ revision, submitted to the RFC Editor as a Standard Track document.
+ Distribution of this memo is unlimited. Technical discussion of this
+ document will take place on the IETF LDAPEXT mailing list
+ <ldapext at ietf.org>. Please send editorial comments directly to the
+ author <Kurt at OpenLDAP.org>.
+
+ By submitting this Internet-Draft, each author represents that any
+ applicable patent or other IPR claims of which he or she is aware have
+ been or will be disclosed, and any of which he or she becomes aware
+ will be disclosed, in accordance with Section 6 of BCP 79.
+
+ Internet-Drafts are working documents of the Internet Engineering Task
+ Force (IETF), its areas, and its working groups. Note that other
+ groups may also distribute working documents as Internet-Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference material
+ or to cite them other than as "work in progress."
+
+ The list of current Internet-Drafts can be accessed at
+ http://www.ietf.org/1id-abstracts.html
+
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html
+
+
+ Copyright (C) The Internet Society (2005). All Rights Reserved.
+
+ Please see the Full Copyright section near the end of this document
+ for more information.
+
+
+Abstract
+
+
+
+Zeilenga draft-zeilenga-ldap-cosine-01 [Page 1]
+
+INTERNET-DRAFT COSINE Schema 23 October 2005
+
+
+ This document provides a collection of schema elements for use with
+ the Lightweight Directory Access Protocol (LDAP) from the COSINE and
+ Internet X.500 pilot projects.
+
+ This document obsoletes RFC 1274 and RFC 2247.
+
+
+Table of Contents
+
+ Status of this Memo 1
+ Abstract 2
+ Table of Contents
+ 1. Background and Intended Use 3
+ 1.1. Relationship with Other Documents
+ 1.2. Terminology and Conventions
+ 2. COSINE Attribute Types 4
+ 2.1. associatedDomain
+ 2.2. associatedName
+ 2.3. buildingName
+ 2.3. co
+ 2.5. documentAuthor
+ 2.6. documentIdentifier
+ 2.7. documentLocation
+ 2.8. documentPublisher
+ 2.9. documentTitle
+ 2.10. documentVersion
+ 2.11. drink
+ 2.12. homePhone
+ 2.13. homePostalAddress
+ 2.14. host
+ 2.16. info
+ 2.17. mail
+ 2.18. manager
+ 2.19. mobile
+ 2.20. organizationalStatus
+ 2.21. pager
+ 2.22. personalTitle
+ 2.23. roomNumber
+ 2.24. secretary
+ 2.26. uniqueIdentifier
+ 2.27. userClass
+ 3. COSINE Object Classes 14
+ 3.1. account
+ 3.2. document
+ 3.3. documentSeries
+ 3.4. domain
+ 3.5. domainRelatedObject
+ 3.6. friendlyCountry
+
+
+
+Zeilenga draft-zeilenga-ldap-cosine-01 [Page 2]
+
+INTERNET-DRAFT COSINE Schema 23 October 2005
+
+
+ 3.7. rFC822LocalPart
+ 3.8. room
+ 3.9. simpleSecurityObject
+ 4. Security Considerations 19
+ 5. IANA Considerations 20
+ 6. Acknowledgments 21
+ 7. Editor's Address
+ 8. References
+ A. Changes Since RFC 1274 23
+ Intellectual Property Rights 24
+ Full Copyright
+
+
+1. Background and Intended Use
+
+ In the late 1980s, X.500 Directory Services were standardised by the
+ CCITT (Commite' Consultatif International de Telegraphique et
+ Telephonique), now a part of the ITU (International Telephone Union).
+ This lead to Directory Service piloting activities in the early 1990s,
+ including the COSINE (Co-operation and Open Systems Interconnection in
+ Europe) PARADISE Project pilot [COSINEpilot] in Europe. Motivated by
+ needs large scale directory pilots, RFC 1274 was published to
+ standardize directory schema and naming architecture for use in the
+ COSINE and other Internet X.500 pilots [RFC1274].
+
+ In the years that followed, X.500 Directory Services have evolved to
+ incorporate new capabilities and even new protocols. In particular,
+ the Lightweight Directory Access Protocol (LDAP) [Roadmap] was
+ introduced in the early 1990s [RFC1487], with Version 3 of LDAP
+ introduced in the late 1990s [RFC2251] and subsequently revised in the
+ 2005 [Roadmap].
+
+ While much of the material in RFC 1274 has been superceed by
+ subsequently published ITU-T Recommendations and IETF RFCs, many of
+ the schema elements lack standardized schema descriptions for use in
+ modern X.500 and LDAP directory services despite the fact that these
+ schema elements are in wide use today. As the old schema descriptions
+ cannot be used without adaptation, interoperabilty issues may arise
+ due to lack of standardized modern schema descriptions.
+
+ This document addresses these issues by offering standardized schema
+ descriptions, where needed, for widely-used COSINE schema elements.
+
+1.1. Relationship to Other Documents
+
+ This document, together with [Schema] and [Syntaxes], obsoletes RFC
+ 1274 in its entirety. [Schema] replaces Sections 9.3.1 (Userid) and
+ Section 9.3.21 (Domain Component) of RFC 1274. [Syntaxes] replaces
+
+
+
+Zeilenga draft-zeilenga-ldap-cosine-01 [Page 3]
+
+INTERNET-DRAFT COSINE Schema 23 October 2005
+
+
+ section 9.4 (Generally useful syntaxes) of RFC 1274.
+
+ This document replaces the remainder of RFC 1274. Appendix A.
+ discusses changes since RFC 1274, as well as why certain schema
+ elements were not brought forward in this revision of the COSINE
+ schema. All elements not brought are to be regarded as Historic.
+
+ This document, together with [NamingPlan] and [Schema], obsoletes RFC
+ 2247 in its entirety. [Schema] replaces Section 4 (Attribute Type
+ Definition) and Section 5.1 (The dcObject object class) of RFC 2247.
+ This document replaces Section 5.2 (The domain object class) of RFC
+ 2247. The remainder of RFC 2247 is replaced by [NamingPlan].
+
+ Some of these items were described in RFC 2798 (inetOrgPerson schema).
+ This document supersedes these descriptions. This document, together
+ with [Schema], replaces section 9.1.3 of RFC 2798.
+
+
+1.2. Terminology and Conventions
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in BCP 14 [RFC2119].
+
+ DIT stands for Directory Information Tree.
+ DN stands for Distinguished Name.
+ DSA stands for Directory System Agent, a server.
+ DSE stands for DSA-Specific Entry.
+ DUA stands for Directory User Agent, a client.
+
+ These terms are discussed in [Models].
+
+ Schema definitions are provided using LDAP description formats
+ [Models]. Definitions provided here are formatted (line wrapped) for
+ readability.
+
+
+2. COSINE Attribute Types
+
+ This section details COSINE attribute types for use in LDAP.
+
+
+2.1. associatedDomain
+
+ The 'associatedDomain' attribute specifies DNS domains [RFC1034] which
+ are associated with an object. For example, the entry in the DIT with
+ a DN <DC=example,DC=com> might have an associated domain of
+ "example.com".
+
+
+
+Zeilenga draft-zeilenga-ldap-cosine-01 [Page 4]
+
+INTERNET-DRAFT COSINE Schema 23 October 2005
+
+
+ ( 0.9.2342.19200300.100.1.37 NAME 'associatedDomain'
+ EQUALITY caseIgnoreIA5Match
+ SUBSTR caseIgnoreIA5SubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
+
+ The IA5String (1.3.6.1.4.1.1466.115.121.1.26) syntax and the
+ 'caseIgnoreIA5Match' and 'caseIgnoreIA5SubstringsMatch' rules are
+ described in [Syntaxes].
+
+ It is noted that the directory will not ensure that values of this
+ attribute conform to the <domain> production [RFC1034]. It is the
+ application responsibility to ensure domains it stores in this
+ attribute are appropriately represented.
+
+ It is also noted that applications supporting Internationalized Domain
+ Names SHALL use the ToASCII method [RFC3490] to produce <label>
+ components of the <domain> production.
+
+
+2.2. associatedName
+
+ The 'associatedName' attribute specifies names of entries in the
+ organizational DIT associated with a DNS domain [RFC1034].
+
+ ( 0.9.2342.19200300.100.1.38 NAME 'associatedName'
+ EQUALITY distinguishedNameMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
+
+ The DistinguishedName (1.3.6.1.4.1.1466.115.121.1.12) syntax and the
+ 'distinguishedNameMatch' rule are described in [Syntaxes].
+
+
+2.3. buildingName
+
+ The 'buildingName' attribute specifies names of the buildings where an
+ organization or organizational unit is based. For example, "The White
+ House".
+
+ ( 0.9.2342.19200300.100.1.48 NAME 'buildingName'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
+
+ The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the
+ 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described
+ in [Syntaxes].
+
+
+
+
+
+Zeilenga draft-zeilenga-ldap-cosine-01 [Page 5]
+
+INTERNET-DRAFT COSINE Schema 23 October 2005
+
+
+2.3. co
+
+ The 'co' (Friendly Country Name) attribute specifies names of
+ countries in human-readable format. For example, "Germany" and
+ "Federal Republic of Germany". It is commonly used in conjunction
+ with the 'c' (Country Name) [Schema] attribute (whose values are
+ restricted to the two-letter codes defined in [ISO3166]).
+
+ ( 0.9.2342.19200300.100.1.43 NAME 'co'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+ The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the
+ 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described
+ in [Syntaxes].
+
+
+2.5. documentAuthor
+
+ The 'documentAuthor' attribute specifies the distinguished name of
+ authors (or editors) of a document. For example,
+
+ ( 0.9.2342.19200300.100.1.14 NAME 'documentAuthor'
+ EQUALITY distinguishedNameMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
+
+ The DistinguishedName (1.3.6.1.4.1.1466.115.121.1.12) syntax and the
+ 'distinguishedNameMatch' rule are described in [Syntaxes].
+
+
+2.6. documentIdentifier
+
+ The 'documentIdentifier' attribute specifies unique identifiers for a
+ document. A document may be identified by more than one unique
+ identifier. For example, RFC 3383 and BCP 64 are unique identifers
+ which (presently) refer to the same document.
+
+ ( 0.9.2342.19200300.100.1.11 NAME 'documentIdentifier'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
+
+ The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the
+ 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described
+ in [Syntaxes].
+
+
+
+
+
+Zeilenga draft-zeilenga-ldap-cosine-01 [Page 6]
+
+INTERNET-DRAFT COSINE Schema 23 October 2005
+
+
+2.7. documentLocation
+
+ The 'documentLocation' attribute specifies locations of the document
+ original.
+
+ ( 0.9.2342.19200300.100.1.15 NAME 'documentLocation'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
+
+ The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the
+ 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described
+ in [Syntaxes].
+
+
+2.8. documentPublisher
+
+ The 'documentPublisher' attribute is the persons and/or organizations
+ that published the document. Documents which are jointly published
+ have one value for each publisher.
+
+ ( 0.9.2342.19200300.100.1.56 NAME 'documentPublisher'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+ The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the
+ 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described
+ in [Syntaxes].
+
+
+2.9. documentTitle
+
+ The 'documentTitle' attribute specifies the titles of a document.
+ Multiple values are allowed to accomadate both long and short titles,
+ or other situations where a document has multiple titles. For
+ example, "The Lightweight Directory Access Protocol Technical
+ Specification" and "The LDAP Technical Specification".
+
+ ( 0.9.2342.19200300.100.1.12 NAME 'documentTitle'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
+
+ The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the
+ 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described
+ in [Syntaxes].
+
+
+
+
+Zeilenga draft-zeilenga-ldap-cosine-01 [Page 7]
+
+INTERNET-DRAFT COSINE Schema 23 October 2005
+
+
+2.10. documentVersion
+
+ The 'documentVersion' attribute specifies the version information of a
+ document.
+
+ ( 0.9.2342.19200300.100.1.13 NAME 'documentVersion'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
+
+ The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the
+ 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described
+ in [Syntaxes].
+
+
+2.11. drink
+
+ The 'drink' (favoriteDrink) attribute specifies favorite drinks of an
+ object (or person). For instance, "cola" and "beer".
+
+ ( 0.9.2342.19200300.100.1.5 NAME 'drink'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
+
+ The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the
+ 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described
+ in [Syntaxes].
+
+
+2.12. homePhone
+
+ The 'homePhone' (Home Telephone Number) attribute specifies home
+ telephone numbers (e.g., "+1 775 555 1234") associated with a person.
+
+ ( 0.9.2342.19200300.100.1.20 NAME 'homePhone'
+ EQUALITY telephoneNumberMatch
+ SUBSTR telephoneNumberSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 )
+
+ The telephoneNumber (1.3.6.1.4.1.1466.115.121.1.50) syntax and the
+ 'telephoneNumberMatch' and 'telephoneNumberSubstringsMatch' rules are
+ described in [Syntaxes].
+
+
+2.13. homePostalAddress
+
+ The 'homePostalAddress' attribute specifies home postal addresses for
+
+
+
+Zeilenga draft-zeilenga-ldap-cosine-01 [Page 8]
+
+INTERNET-DRAFT COSINE Schema 23 October 2005
+
+
+ an object. Each value should be limited to up to 6 directory strings
+ of 30 characters each. (Note: it is not intended that the directory
+ service enforce these limits.)
+
+
+ ( 0.9.2342.19200300.100.1.39 NAME 'homePostalAddress'
+ EQUALITY caseIgnoreListMatch
+ SUBSTR caseIgnoreListSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 )
+
+ The PostalAddress (1.3.6.1.4.1.1466.115.121.1.41) syntax and the
+ 'caseIgnoreListMatch' and 'caseIgnoreListSubstringsMatch' rules are
+ described in [Syntaxes].
+
+
+2.14. host
+
+ The 'host' attribute specifies host computers, generally by their
+ primary fully-qualified domain name (e.g., my-host.example.com).
+
+ ( 0.9.2342.19200300.100.1.9 NAME 'host'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
+
+ The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the
+ 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described
+ in [Syntaxes].
+
+
+2.16. info
+
+ The 'info' attribute specifies any general information pertinent to an
+ object. This information is not necessarily descriptive of the
+ object.
+
+ Applications should not attach specific semantics to values of this
+ attribute. The 'description' attribute [Schema] is available for
+ specifying descriptive information pertinent to an object.
+
+ ( 0.9.2342.19200300.100.1.4 NAME 'info'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{2048} )
+
+ The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the
+ 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described
+ in [Syntaxes].
+
+
+
+Zeilenga draft-zeilenga-ldap-cosine-01 [Page 9]
+
+INTERNET-DRAFT COSINE Schema 23 October 2005
+
+
+2.17. mail
+
+ The 'mail' (rfc822mailbox) attribute type holds Internet mail
+ addresses in Mailbox [RFC2821] form (e.g.: user at example.com).
+
+ ( 0.9.2342.19200300.100.1.3 NAME 'mail'
+ EQUALITY caseIgnoreIA5Match
+ SUBSTR caseIgnoreIA5SubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} )
+
+ The IA5String (1.3.6.1.4.1.1466.115.121.1.26) syntax and the
+ 'caseIgnoreIA5Match' and 'caseIgnoreIA5SubstringsMatch' rules are
+ described in [Syntaxes].
+
+ It is noted that the directory will not ensure that values of this
+ attribute conform to the <Mailbox> production [RFC2821]. It is the
+ application responsibility to ensure domains it stores in this
+ attribute are appropriately represented.
+
+ Additionally, the directory will compare values per the matching rules
+ named in the above attribute type description. As these rules differ
+ from rules which normally apply to <Mailbox> comparisons, operational
+ issues may arise. For example, the assertion (mail=joe at example.com)
+ will match "JOE at example.com" even though the <local-parts> differ.
+ Also, where a user has two <Mailbox>es which whose addresses differ
+ only by case of the <local-part>, both cannot be listed as values of
+ the user's mail attribute (as they are considered by the
+ 'caseIgnoreIA5Match' rule to be equal).
+
+ It is also noted that applications supporting internationalized domain
+ names SHALL use the ToASCII method [RFC3490] to produce <sub-domain>
+ components of the <Mailbox> production.
+
+
+2.18. manager
+
+ The 'manager' attribute specifies managers, by distinguished name, of
+ the person (or entity).
+
+ ( 0.9.2342.19200300.100.1.10 NAME 'manager'
+ EQUALITY distinguishedNameMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
+
+ The DistinguishedName (1.3.6.1.4.1.1466.115.121.1.12) syntax and the
+ 'distinguishedNameMatch' rule are described in [Syntaxes].
+
+
+2.19. mobile
+
+
+
+Zeilenga draft-zeilenga-ldap-cosine-01 [Page 10]
+
+INTERNET-DRAFT COSINE Schema 23 October 2005
+
+
+ The 'mobile' (mobileTelephoneNumber) attribute specifies mobile
+ telephone numbers (e.g., "+1 775 555 6789") associated with a person
+ (or entity).
+
+ ( 0.9.2342.19200300.100.1.41 NAME 'mobile'
+ EQUALITY telephoneNumberMatch
+ SUBSTR telephoneNumberSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 )
+
+ The telephoneNumber (1.3.6.1.4.1.1466.115.121.1.50) syntax and the
+ 'telephoneNumberMatch' and 'telephoneNumberSubstringsMatch' rules are
+ described in [Syntaxes].
+
+
+2.20. organizationalStatus
+
+ The 'organizationalStatus' attribute specifies categories by which a
+ person is often referred to in an organization. Examples of usage in
+ academia might include "undergraduate student", "researcher",
+ "professor", "staff", etc.. Multiple values are allowed were the
+ person is in multiple categories.
+
+ Directory administrators and application designers SHOULD consider
+ carefully the distinctions between this and the 'title' and
+ 'userClass' attributes.
+
+ ( 0.9.2342.19200300.100.1.45 NAME 'organizationalStatus'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
+
+ The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the
+ 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described
+ in [Syntaxes].
+
+
+2.21. pager
+
+ The 'pager' (pagerTelephoneNumber) attribute specifies pager telephone
+ numbers (e.g., "+1 775 555 5555") for an object.
+
+ ( 0.9.2342.19200300.100.1.42 NAME 'pager'
+ EQUALITY telephoneNumberMatch
+ SUBSTR telephoneNumberSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 )
+
+ The telephoneNumber (1.3.6.1.4.1.1466.115.121.1.50) syntax and the
+ 'telephoneNumberMatch' and 'telephoneNumberSubstringsMatch' rules are
+
+
+
+Zeilenga draft-zeilenga-ldap-cosine-01 [Page 11]
+
+INTERNET-DRAFT COSINE Schema 23 October 2005
+
+
+ described in [Syntaxes].
+
+
+2.22. personalTitle
+
+ The 'personalTitle' attribute specifies personal titles for a person.
+ Examples of personal titles are "Frau", "Dr.", "Herr", and
+ "Professor".
+
+ ( 0.9.2342.19200300.100.1.40 NAME 'personalTitle'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
+
+ The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the
+ 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described
+ in [Syntaxes].
+
+
+2.23. roomNumber
+
+ The 'roomNumber' attribute specifies the room number of an object.
+ During periods of renumbering or in other circumstances where a room
+ has multiple valid room numbers associated with it, multiple values
+ may be provided. Note that the 'cn' (commonName) attribute type
+ SHOULD be used for naming room objects.
+
+ ( 0.9.2342.19200300.100.1.6 NAME 'roomNumber'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
+
+ The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the
+ 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described
+ in [Syntaxes].
+
+
+2.24. secretary
+
+ The 'secretary' attribute specifies secretaries and/or administrative
+ assistants, by distinguish name, of a person.
+
+ ( 0.9.2342.19200300.100.1.21 NAME 'secretary'
+ EQUALITY distinguishedNameMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
+
+ The DistinguishedName (1.3.6.1.4.1.1466.115.121.1.12) syntax and the
+ 'distinguishedNameMatch' rule are described in [Syntaxes].
+
+
+
+Zeilenga draft-zeilenga-ldap-cosine-01 [Page 12]
+
+INTERNET-DRAFT COSINE Schema 23 October 2005
+
+
+2.26. uniqueIdentifier
+
+ The 'uniqueIdentifier' attribute specifies a unique identifier for an
+ object represented in the Directory. The domain within which the
+ identifier is unique, and the exact semantics of the identifier, are
+ for local definition. For a person, this might be an institution-wide
+ payroll number. For an organizational unit, it might be a department
+ code.
+
+ ( 0.9.2342.19200300.100.1.44 NAME 'uniqueIdentifier'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
+
+ The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the
+ 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described
+ in [Syntaxes].
+
+ Note: X.520 also describes an attribute called 'uniqueIdentifier'
+ (2.5.4.45) which is called 'x500UniqueIdentifier' in LDAP
+ [Schema]. The attribute detailed here ought not be confused
+ with 'x500UniqueIdentifier'.
+
+
+2.27. userClass
+
+ The 'userClass' attribute specifies categories of computer or
+ application user. The semantics placed on this attribute are for
+ local interpretation. Examples of current usage of this attribute in
+ academia are "student", "staff", "faculty", etc.. Note that the
+ 'organizationalStatus' attribute type is now often be preferred as it
+ makes no distinction between persons as opposed to users.
+
+ ( 0.9.2342.19200300.100.1.8 NAME 'userClass'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
+
+ The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the
+ 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described
+ in [Syntaxes].
+
+
+3. COSINE Object Classes
+
+ This section details COSINE object classes for use in LDAP.
+
+
+
+
+
+Zeilenga draft-zeilenga-ldap-cosine-01 [Page 13]
+
+INTERNET-DRAFT COSINE Schema 23 October 2005
+
+
+3.1. account
+
+ The 'account' object class is used to define entries representing
+ computer accounts. The 'uid' attribute SHOULD be used for naming
+ entries of this object class.
+
+ ( 0.9.2342.19200300.100.4.5 NAME 'account'
+ SUP top STRUCTURAL
+ MUST uid
+ MAY ( description $ seeAlso $ l $ o $ ou $ host ) )
+
+ The 'top' object class is described in [Models]. The 'description',
+ 'seeAlso', 'l', 'o', 'ou', and 'uid' attribute types are described in
+ [Schema]. The 'host' attribute type is described in Section 2 of this
+ document.
+
+ Example:
+
+ dn: uid=kdz,cn=Accounts,dc=Example,dc=COM
+ objectClass: account
+ uid: kdz
+ seeAlso: cn=Kurt D. Zeilenga,cn=Persons,dc=Example,dc=COM
+
+
+3.2. document
+
+ The 'document' object class is used to define entries which represent
+ documents.
+
+ ( 0.9.2342.19200300.100.4.6 NAME 'document'
+ SUP top STRUCTURAL
+ MUST documentIdentifier
+ MAY ( cn $ description $ seeAlso $ l $ o $ ou $
+ documentTitle $ documentVersion $ documentAuthor $
+ documentLocation $ documentPublisher ) )
+
+ The 'top' object class is described in [Models]. The 'cn',
+ 'description', 'seeAlso', 'l', 'o', and 'ou' attribute types are
+ described in [Schema]. The 'documentIdentifier', 'documentTitle',
+ 'documentVersion', 'documentAuthor', 'documentLocation', and
+ 'documentPublisher' attribute types are described in Section 2 of this
+ document.
+
+ Example:
+
+ dn: documentIdentifier=RFCXXXX,cn=RFC,dc=Example,dc=COM
+ objectClass: document
+ documentIdentifier: RFC XXXXX
+
+
+
+Zeilenga draft-zeilenga-ldap-cosine-01 [Page 14]
+
+INTERNET-DRAFT COSINE Schema 23 October 2005
+
+
+ documentTitle: COSINE LDAP/X.500 Schema
+ documentAuthor: cn=Kurt D. Zeilenga,cn=Persons,dc=Example,dc=COM
+ documentLocation: http://www.rfc-editor.org/rfc/rfcXXXX.txt
+ documentPublisher: Internet Engineering Task Force
+ description: A collection of schema elements for use in LDAP
+ description: Obsoletes RFC 1274
+ seeAlso: documentIdentifier=[Roadmap],cn=RFC,dc=Example,dc=COM
+ seeAlso: documentIdentifier=RFC 1274,cn=RFC,dc=Example,dc=COM
+
+
+3.3. documentSeries
+
+ The documentSeries object class is used to define an entry which
+ represents a series of documents (e.g., The Request For Comments
+ memos).
+
+ ( 0.9.2342.19200300.100.4.9 NAME 'documentSeries'
+ SUP top STRUCTURAL
+ MUST cn
+ MAY ( description $ l $ o $ ou $ seeAlso $
+ telephonenumber ) )
+
+ The 'top' object class is described in [Models]. The 'description',
+ 'l', 'o', 'ou', 'seeAlso', and 'telephoneNumber' attribute types are
+ described in [Schema].
+
+ Example:
+
+ dn: cn=RFC,dc=Example,dc=COM
+ objectClass: documentSeries
+ cn: Request for Comments
+ cn: RFC
+ description: a series of memos about the Internet
+
+
+3.4. domain
+
+ The 'domain' object class is used to define entries which represent
+ DNS domains for objects which are not organizations, organizational
+ units, or other kinds of objects more approproiately defined using an
+ object class specific to the kind of object being defined (e.g.,
+ 'organization', 'organizationUnit', etc.).
+
+ The 'dc' attribute should be used for naming entries of 'domain'
+ object class.
+
+ ( 0.9.2342.19200300.100.4.13 NAME 'domain'
+ SUP top STRUCTURAL
+
+
+
+Zeilenga draft-zeilenga-ldap-cosine-01 [Page 15]
+
+INTERNET-DRAFT COSINE Schema 23 October 2005
+
+
+ MUST dc
+ MAY ( userPassword $ searchGuide $ seeAlso $ businessCategory $
+ x121Address $ registeredAddress $ destinationIndicator $
+ preferredDeliveryMethod $ telexNumber $
+ teletexTerminalIdentifier $ telephoneNumber $
+ internationaliSDNNumber $ facsimileTelephoneNumber $ street $
+ postOfficeBox $ postalCode $ postalAddress $
+ physicalDeliveryOfficeName $ st $ l $ description $ o $
+ associatedName ) )
+
+ The 'top' object class and the 'dc', 'userPassword', 'searchGuide
+ 'seeAlso', 'businessCategory', 'x121Address', 'registeredAddress
+ 'destinationIndicator', 'preferredDeliveryMethod', 'telexNumber',
+ 'teletexTerminalIdentifier', 'telephoneNumber',
+ 'internationaliSDNNumber', 'facsimileTelephoneNumber', 'street',
+ 'postOfficeBox', 'postalCode', 'postalAddress',
+ 'physicalDeliveryOfficeName', 'st', 'l', 'description', 'o', types are
+ described in [Schema]. The 'associatedName' attribute type is
+ described in Section 2 of this document.
+
+ Example:
+ dn: dc=com
+ objectClass: domain
+ dc: com
+ description: the .COM TLD
+
+
+3.5. domainRelatedObject
+
+ The 'domainRelatedObject' object class is used to define entries which
+ represent DNS domains which are "equivalent" to an X.500 domain: e.g.,
+ an organization or organizational unit.
+
+ ( 0.9.2342.19200300.100.4.17 NAME 'domainRelatedObject'
+ SUP top AUXILIARY
+ MUST associatedDomain )
+
+ The 'top' object class is described in [Models]. The
+ 'associatedDomain' attribute type is described in Section 2 of this
+ document.
+
+ Example:
+
+ dn: dc=example,dc=com
+ objectClass: organization
+ objectClass: dcObject
+ objectClass: domainRelatedObject
+ dc: example
+
+
+
+Zeilenga draft-zeilenga-ldap-cosine-01 [Page 16]
+
+INTERNET-DRAFT COSINE Schema 23 October 2005
+
+
+ associatedDomain: example.com
+ o: Example Organization
+
+ The 'organization' and 'dcObject' object classes and the 'dc' and 'o'
+ attribute types are described in [Schema].
+
+
+3.5. friendlyCountry
+
+ The 'friendlyCountry' object class is used to define entries
+ representing countries in the DIT. The object class is used to allow
+ friendlier naming of countries than that allowed by the object class
+ 'country' [Schema].
+
+ ( 0.9.2342.19200300.100.4.18 NAME 'friendlyCountry'
+ SUP country STRUCTURAL
+ MUST co )
+
+ The 'country' object class is described in [Schema]. The 'co'
+ attribute type is described in Section 2 of this document.
+
+ Example:
+
+ dn: c=DE
+ objectClass: country
+ objectClass: friendlyCountry
+ c: DE
+ co: Deutschland
+ co: Germany
+ co: Federal Republic of Germany
+ co: FRG
+
+ The 'c' attribute type is described in [Schema].
+
+
+3.6. rFC822LocalPart
+
+ The 'rFC822LocalPart' object class is used to define entries which
+ represent the local part of Internet mail addresses [RFC2822]. This
+ treats the local part of the address as a 'domain' object.
+
+ ( 0.9.2342.19200300.100.4.14 NAME 'rFC822localPart'
+ SUP domain STRUCTURAL
+ MAY ( cn $ description $ destinationIndicator $
+ facsimileTelephoneNumber $ internationaliSDNNumber $
+ physicalDeliveryOfficeName $ postalAddress $ postalCode $
+ postOfficeBox $ preferredDeliveryMethod $ registeredAddress $
+ seeAlso $ sn $ street $ telephoneNumber $
+
+
+
+Zeilenga draft-zeilenga-ldap-cosine-01 [Page 17]
+
+INTERNET-DRAFT COSINE Schema 23 October 2005
+
+
+ teletexTerminalIdentifier $ telexNumber $ x121Address ) )
+
+ The 'domain' object class is described in Section 3.4 of this
+ document. The 'cn', 'description', 'destinationIndicator',
+ 'facsimileTelephoneNumber', 'internationaliSDNNumber,
+ 'physicalDeliveryOfficeName', 'postalAddress', 'postalCode',
+ 'postOfficeBox', 'preferredDeliveryMethod', 'registeredAddress',
+ 'seeAlso', 'sn, 'street', 'telephoneNumber',
+ 'teletexTerminalIdentifier', 'telexNumber' and 'x121Address' attribute
+ types are described in [Schema].
+
+
+ Example:
+
+ dn: dc=kdz,dc=example,dc=com
+ objectClass: domain
+ objectClass: rFC822LocalPart
+ dc: kdz
+ associatedName: cn=Kurt D. Zeilenga,cn=Persons,dc=Example,dc=COM
+
+ The 'dc' attribute type is described in [Schema].
+
+
+3.7. room
+
+ The 'room' object class is used to define entries representing rooms.
+ The 'cn' (commonName) attribute SHOULD be used for naming entries of
+ this object class.
+
+ ( 0.9.2342.19200300.100.4.7 NAME 'room'
+ SUP top STRUCTURAL
+ MUST cn
+ MAY ( roomNumber $ description $ seeAlso $ telephoneNumber ) )
+
+ The 'top' object class is described in [Models]. The 'cn',
+ 'description', 'seeAlso' and 'telephoneNumber' attribute types are
+ described in [Schema]. The 'roomNumber' attribute type is described
+ in Section 2 of this document.
+
+ dn: cn=conference room,dc=example,dc=com
+ objectClass: room
+ cn: conference room
+ telephoneNumber: +1 755 555 1111
+
+
+3.8. simpleSecurityObject
+
+ The 'simpleSecurityObject' object class is used to require an entry to
+
+
+
+Zeilenga draft-zeilenga-ldap-cosine-01 [Page 18]
+
+INTERNET-DRAFT COSINE Schema 23 October 2005
+
+
+ have an 'userPassword' attribute when the entry's structural object
+ class does not require (or allow) the 'userPassword attribute'.
+
+ ( 0.9.2342.19200300.100.4.19 NAME 'simpleSecurityObject'
+ SUP top AUXILIARY
+ MUST userPassword )
+
+ The 'top' object class is described in [Models]. The 'userPassword'
+ attribute type is described in [Schema].
+
+ dn: dc=kdz,dc=Example,dc=COM
+ objectClass: account
+ objectClass: simpleSecurityObject
+ uid: kdz
+ userPassword: My Password
+ seeAlso: cn=Kurt D. Zeilenga,cn=Persons,dc=Example,dc=COM
+
+
+4. Security Considerations
+
+ General LDAP security considerations [Roadmap] is applicable to the
+ use of this schema. Additional considerations are noted above where
+ appropriate.
+
+ Directories administrators should ensure that access to sensitive
+ information is restricted to authorized entities, but ensure that
+ appropriate data security services, including data integrity and data
+ confidentiality, are used to protect against eavesdropping.
+
+ Simple authentication (e.g., plain text passwords) mechanisms should
+ only be used when adequate data security services are in place. LDAP
+ offers reasonable strong authentication and data security services
+ [AuthMeth].
+
+
+
+5. IANA Considerations
+
+ It is requested that the Internet Assigned Numbers Authority (IANA)
+ update upon Standard Action the LDAP descriptors registry [BCP64bis]
+ as indicated the following template:
+
+ Subject: Request for LDAP Descriptor Registration Update
+ Descriptor (short name): see comment
+ Object Identifier: see comments
+ Person & email address to contact for further information:
+ Kurt Zeilenga <kurt at OpenLDAP.org>
+ Usage: see comments
+
+
+
+Zeilenga draft-zeilenga-ldap-cosine-01 [Page 19]
+
+INTERNET-DRAFT COSINE Schema 23 October 2005
+
+
+ Specification: RFC XXXX
+ Author/Change Controller: IESG
+ Comments:
+
+ The following descriptors should be updated to refer to RFC XXXX.
+
+ NAME Type OID
+ ------------------------ ---- --------------------------
+ account O 0.9.2342.19200300.100.4.5
+ associatedDomain A 0.9.2342.19200300.100.1.37
+ associatedName A 0.9.2342.19200300.100.1.38
+ buildingName A 0.9.2342.19200300.100.1.48
+ co A 0.9.2342.19200300.100.1.43
+ document O 0.9.2342.19200300.100.4.6
+ documentAuthor A 0.9.2342.19200300.100.1.14
+ documentIdentifier A 0.9.2342.19200300.100.1.11
+ documentLocation A 0.9.2342.19200300.100.1.15
+ documentPublisher A 0.9.2342.19200300.100.1.56
+ documentSeries O 0.9.2342.19200300.100.4.8
+ documentTitle A 0.9.2342.19200300.100.1.12
+ documentVersion A 0.9.2342.19200300.100.1.13
+ domain O 0.9.2342.19200300.100.4.13
+ domainRelatedObject O 0.9.2342.19200300.100.4.17
+ drink A 0.9.2342.19200300.100.1.5
+ favouriteDrink A* 0.9.2342.19200300.100.1.5
+ friendlyCountry O 0.9.2342.19200300.100.4.18
+ friendlyCountryName A* 0.9.2342.19200300.100.1.43
+ homePhone A 0.9.2342.19200300.100.1.20
+ homePostalAddress A 0.9.2342.19200300.100.1.39
+ homeTelephone A* 0.9.2342.19200300.100.1.20
+ host A 0.9.2342.19200300.100.1.9
+ info A 0.9.2342.19200300.100.1.4
+ mail A 0.9.2342.19200300.100.1.3
+ manager A 0.9.2342.19200300.100.1.10
+ mobile A 0.9.2342.19200300.100.1.41
+ mobileTelephoneNumber A* 0.9.2342.19200300.100.1.41
+ organizationalStatus A 0.9.2342.19200300.100.1.45
+ pager A 0.9.2342.19200300.100.1.42
+ pagerTelephoneNumber A* 0.9.2342.19200300.100.1.42
+ personalTitle A 0.9.2342.19200300.100.1.40
+ rFC822LocalPart O 0.9.2342.19200300.100.4.14
+ rfc822Mailbox A* 0.9.2342.19200300.100.1.3
+ room O 0.9.2342.19200300.100.4.7
+ roomNumber A 0.9.2342.19200300.100.1.6
+ secretary A 0.9.2342.19200300.100.1.21
+ simpleSecurityObject O 0.9.2342.19200300.100.4.19
+ singleLevelQuality A 0.9.2342.19200300.100.1.50
+ uniqueIdentifier A 0.9.2342.19200300.100.1.44
+
+
+
+Zeilenga draft-zeilenga-ldap-cosine-01 [Page 20]
+
+INTERNET-DRAFT COSINE Schema 23 October 2005
+
+
+ userClass A 0.9.2342.19200300.100.1.8
+
+ where Type A is Attribute and Type O is ObjectClass, and *
+ indicates the registration is historic in nature.
+
+
+6. Acknowledgments
+
+ This document is based upon RFC 1274 by Paul Barker and Steve Kille,
+ as well as RFC 2247 by Steve Kill, Mark Wahl, Al Grimstad, Rick Huber,
+ and Sri Satulari.
+
+
+7. Editor's Address
+
+ Kurt D. Zeilenga
+ OpenLDAP Foundation
+
+ Email: Kurt at OpenLDAP.org
+
+
+8. References
+
+ [[Note to the RFC Editor: please replace the citation tags used in
+ referencing Internet-Drafts with tags of the form RFCnnnn where
+ possible.]]
+
+8.1. Normative References
+
+ [RFC1034] Mockapetris, P., "Domain names - concepts
+ and facilities", STD 13 (also RFC 1034), November 1987.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14 (also RFC 2119), March 1997.
+
+ [RFC2247] Kille, S., M. Wahl, A. Grimstad, R. Huber and S.
+ Sataluri, "Using Domains in LDAP/X.500 Distinguished
+ Names", January 1998.
+
+ [RFC2821] Klensin, J. (editor), "Simple Mail Transfer Protocol",
+ RFC 2822, April 2001.
+
+ [RFC3490] Faltstrom, P., P. Hoffman, and A. Costello,
+ "Internationalizing Domain Names in Applications
+ (INDA)", RFC 3490, March 2003.
+
+ [Roadmap] Zeilenga, K. (editor), "LDAP: Technical Specification
+ Road Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in
+
+
+
+Zeilenga draft-zeilenga-ldap-cosine-01 [Page 21]
+
+INTERNET-DRAFT COSINE Schema 23 October 2005
+
+
+ progress.
+
+ [Models] Zeilenga, K. (editor), "LDAP: Directory Information
+ Models", draft-ietf-ldapbis-models-xx.txt, a work in
+ progress.
+
+ [Syntaxes] Legg, S. (editor), "LDAP: Syntaxes and Matching Rules",
+ draft-ietf-ldapbis-syntaxes-xx.txt, a work in progress.
+
+ [Schema] Dally, K. (editor), "LDAP: User Schema",
+ draft-ietf-ldapbis-user-schema-xx.txt, a work in
+ progress.
+
+ [AuthMeth] Harrison, R. (editor), "LDAP: Authentication Methods and
+ Connection Level Security Mechanisms",
+ draft-ietf-ldapbis-authmeth-xx.txt, a work in progress.
+
+
+8.2. Informative References
+
+ [COSINEpilot]
+
+ [NamingPlan] Zeilenga, K., "The Internet Naming Plan for LDAP/X.500
+ Directories", draft-zeilenga-ldap-namingplan-xx.txt, a
+ work in progress.
+
+ [ISO3166] International Organization for Standardization, "Codes
+ for the representation of names of countries", ISO 3166.
+
+ [RFC1274] Barker, P. and S. Kille, "The COSINE and Internet X.500
+ Schema", November 1991.
+
+ [RFC2798] Smith, M., "The LDAP inetOrgPerson Object Class", RFC
+ 2798, April 2000.
+
+ [BCP64bis] Zeilenga, K., "IANA Considerations for LDAP",
+ draft-ietf-ldapbis-bcp64-xx.txt, a work in progress.
+
+
+Appendix A. Changes since RFC 1274
+
+ This document represents a substantial rewrite of RFC 1274. The
+ following sections summarize the substantive changes.
+
+A.1. LDAP Short Names
+
+ A number of COSINE attribute types have short names in LDAP.
+
+
+
+
+Zeilenga draft-zeilenga-ldap-cosine-01 [Page 22]
+
+INTERNET-DRAFT COSINE Schema 23 October 2005
+
+
+ X.500 Name LDAP Short Name
+ ------------- ---------------
+ domainComponent dc
+ favoriteDrink drink
+ friendCountryName co
+ homeTelephoneNumber homePhone
+ mobileTelephoneNumber mobile
+ pagerTelephoneNumber pager
+ rfc822Mailbox mail
+ userid uid
+
+ While the LDAP short names are generally used in LDAP, some
+ implementations may (for legacy reasons [Historic]) recognize the
+ attribute type by its X.500 name. Hence, the X.500 names have been
+ reserved solely for this purpose.
+
+ Note: 'uid' and 'dc' are described in [Schema].
+
+
+A.2. pilotObject
+
+ The 'pilotObject' object class was not brought forward as its function
+ is largely replaced by operational attributes introduced in X.500(93)
+ [X.501] and version 3 of LDAP [Models]. For instance, the function
+ of the 'lastModifiedBy' and 'lastModifiedTime' attribute types is now
+ served by the 'creatorsName', 'createTimestamp', 'modifiersName', and
+ 'modifyTimestamp' operational attributes [Models].
+
+
+A.3. pilotPerson
+
+ The 'pilotPerson' object class was not brought forward as its function
+ is largely replaced by the 'organizationalPerson' [Models] object
+ class and its subclasses, such as 'inetOrgPerson' [RFC2798].
+
+ Most of the related attribute types (e.g., 'mail', 'manager', etc.)
+ were brought forward as they are used in other object classes.
+
+
+A.4. dNSDomain
+
+ The 'dNSDomain' object class and related attribute types were not
+ brought forward as its use is primarily experimental [RFC1279].
+
+
+A.5. pilotDSA and qualityLabelledData
+
+ The 'pilotDSA' and 'qualityLabelledData' object classes, as well as
+
+
+
+Zeilenga draft-zeilenga-ldap-cosine-01 [Page 23]
+
+INTERNET-DRAFT COSINE Schema 23 October 2005
+
+
+ related attribute types, were not brought forward as it as its use is
+ primarily experimental [QoS].
+
+
+A.6. Attribute syntaxes
+
+ RFC 1274 defined and used caseIgnoreIA5StringSyntax attribute syntax.
+ This has been replaced with the IA5String syntax and approrpiate
+ matching rules in 'mail' and 'associatedDomain'.
+
+ RFC 1274 restricted 'mail' to have non-zero length values. This
+ restriction is not reflected in the IA5String syntax used in the
+ definitions provided in this specification. However, as values are
+ to conform to the <Mailbox> production, the 'mail' should not contain
+ zero-length values. Unfornuately, the directory service will not
+ enforce this restriction.
+
+
+Appendix B. Changes since RFC 2247
+
+ The 'domainNameForm' name form was not brought forward as
+ specification of name forms used in LDAP is left to a future
+ specification.
+
+
+
+Intellectual Property Rights
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be found
+ in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this specification
+ can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+
+
+
+Zeilenga draft-zeilenga-ldap-cosine-01 [Page 24]
+
+INTERNET-DRAFT COSINE Schema 23 October 2005
+
+
+ ietf-ipr at ietf.org.
+
+
+
+Full Copyright
+
+ Copyright (C) The Internet Society (2005).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga draft-zeilenga-ldap-cosine-01 [Page 25]
+
Added: openldap/vendor/openldap-release/doc/drafts/draft-zeilenga-ldap-dontusecopy-xx.txt
===================================================================
--- openldap/vendor/openldap-release/doc/drafts/draft-zeilenga-ldap-dontusecopy-xx.txt (rev 0)
+++ openldap/vendor/openldap-release/doc/drafts/draft-zeilenga-ldap-dontusecopy-xx.txt 2007-09-15 10:38:52 UTC (rev 844)
@@ -0,0 +1,283 @@
+
+
+
+
+
+
+INTERNET-DRAFT Kurt D. Zeilenga
+Intended Category: Standard Track OpenLDAP Foundation
+Expires in six months 5 March 2006
+
+
+
+ The LDAP Don't Use Copy Control
+ <draft-zeilenga-ldap-dontusecopy-02.txt>
+
+
+Status of this Memo
+
+ This document is intended to be, after appropriate review and
+ revision, submitted to the IESG for consideration as a Standard Track
+ document. Distribution of this memo is unlimited. Technical
+ discussion of this document will take place on the IETF LDAP
+ Extensions mailing list <ldapext at ietf.org>. Please send editorial
+ comments directly to the author <Kurt at OpenLDAP.org>.
+
+ By submitting this Internet-Draft, each author represents that any
+ applicable patent or other IPR claims of which he or she is aware have
+ been or will be disclosed, and any of which he or she becomes aware
+ will be disclosed, in accordance with Section 6 of BCP 79.
+
+ Internet-Drafts are working documents of the Internet Engineering Task
+ Force (IETF), its areas, and its working groups. Note that other
+ groups may also distribute working documents as Internet-Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference material
+ or to cite them other than as "work in progress."
+
+ The list of current Internet-Drafts can be accessed at
+ http://www.ietf.org/1id-abstracts.html
+
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html
+
+
+ Copyright (C) The Internet Society (2006). All Rights Reserved.
+
+ Please see the Full Copyright section near the end of this document
+ for more information.
+
+
+
+
+
+
+
+Zeilenga LDAP Don't Use Copy Control [Page 1]
+
+INTERNET-DRAFT draft-zeilenga-ldap-dontusecopy-02 5 March 2006
+
+
+Abstract
+
+ This document defines the Lightweight Directory Access Protocol (LDAP)
+ Don't Use Copy control extension which allows a client to specify that
+ copied information should not be used in providing service. This
+ control is based upon the X.511 dontUseCopy service control option.
+
+
+1. Background and Intended Usage
+
+ This document defines the Lightweight Directory Access Protocol (LDAP)
+ [Roadmap] Don't Use Copy control extension. The control may be
+ attached to request messages to indicate that copied (replicated or
+ cached) information [X.500] should not be used in providing service.
+ This control is based upon the X.511 [X.511] dontUseCopy service
+ control option.
+
+ The Don't Use Copy control is intended to be used where the client
+ requires the service be provided using original (master) information
+ [X.500].
+
+
+2. Terminology
+
+ DSA stands for Directory System Agent (or server).
+ DSE stands for DSA-specific Entry.
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in BCP 14 [RFC2119].
+
+
+3. The Don't Use Copy Control
+
+ The Don't Use Copy control is an LDAP Control [Protocol] whose
+ controlType is IANA-ASSIGNED-OID and controlValue is absent. The
+ criticality MUST be TRUE. There is no corresponding response control.
+
+ The control is appropriate for both LDAP interrogation operations,
+ including Compare and Search operations [Protocol]. It is
+ inappropriate for all other operations, including Abandon, Bind,
+ Delete, Modify, ModifyDN, StartTLS, and Unbind operations [Protocol].
+
+ When the control is attached to an LDAP request, the requested
+ operation MUST NOT be performed on copied information. That is, the
+ requested operation MUST be performed on original information.
+
+ If original information for the target or base object of the operation
+
+
+
+Zeilenga LDAP Don't Use Copy Control [Page 2]
+
+INTERNET-DRAFT draft-zeilenga-ldap-dontusecopy-02 5 March 2006
+
+
+ is not available (either locally or through chaining), the server MUST
+ either return a referral directing the client to a server believed to
+ be better able to service the request or return an appropriate result
+ code (e.g., unwillingToPerform).
+
+
+4. Security Considerations
+
+ This control is intended to be provided where providing service using
+ copied information might lead to unexpected application behavior.
+ Designers of directory applications should consider where it is
+ appropriate for clients to provide this control. Designers should
+ consider whether use of copied information, in particular security and
+ policy information, may result insecure behavior.
+
+ Security considerations for the base operations [Protocol] extended by
+ this control, as well as general LDAP security considerations
+ [Roadmap], generally apply to implementation and use of this
+ extension.
+
+
+5. IANA Considerations
+
+5.1. Object Identifier
+
+ It is requested that IANA assign upon Standards Action an LDAP Object
+ Identifier [BCP64bis] to identify the LDAP Don't Use Copy Control
+ defined in this document.
+
+ Subject: Request for LDAP Object Identifier Registration
+ Person & email address to contact for further information:
+ Kurt Zeilenga <kurt at OpenLDAP.org>
+ Specification: RFC XXXX
+ Author/Change Controller: IESG
+ Comments:
+ Identifies the LDAP Don't Use Copy Control
+
+5.2 LDAP Protocol Mechanism
+
+ Registration of this protocol mechanism [BCP64bis] is requested.
+
+ Subject: Request for LDAP Protocol Mechanism Registration
+ Object Identifier: IANA-ASSIGNED-OID
+ Description: Don't Use Copy Control
+ Person & email address to contact for further information:
+ Kurt Zeilenga <kurt at openldap.org>
+ Usage: Control
+ Specification: RFC XXXX
+
+
+
+Zeilenga LDAP Don't Use Copy Control [Page 3]
+
+INTERNET-DRAFT draft-zeilenga-ldap-dontusecopy-02 5 March 2006
+
+
+ Author/Change Controller: IESG
+ Comments: none
+
+
+
+6. Author's Address
+
+ Kurt D. Zeilenga
+ OpenLDAP Foundation
+
+ Email: Kurt at OpenLDAP.org
+
+
+7. References
+
+ [[Note to the RFC Editor: please replace the citation tags used in
+ referencing Internet-Drafts with tags of the form RFCnnnn where
+ possible.]]
+
+
+7.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14 (also RFC 2119), March 1997.
+
+ [Roadmap] Zeilenga, K. (editor), "LDAP: Technical Specification
+ Road Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in
+ progress.
+
+ [Protocol] Sermersheim, J. (editor), "LDAP: The Protocol",
+ draft-ietf-ldapbis-protocol-xx.txt, a work in progress.
+
+
+7.2. Informative References
+
+ [X.500] International Telecommunication Union -
+ Telecommunication Standardization Sector, "The Directory
+ -- Overview of concepts, models and services,"
+ X.500(1993) (also ISO/IEC 9594-1:1994).
+
+ [X.511] International Telecommunication Union -
+ Telecommunication Standardization Sector, "The
+ Directory: Abstract Service Definition", X.511(1993)
+ (also ISO/IEC 9594-3:1993).
+
+ [BCP64bis] Zeilenga, K., "IANA Considerations for LDAP",
+ draft-ietf-ldapbis-bcp64-xx.txt, a work in progress.
+
+
+
+
+Zeilenga LDAP Don't Use Copy Control [Page 4]
+
+INTERNET-DRAFT draft-zeilenga-ldap-dontusecopy-02 5 March 2006
+
+
+Intellectual Property Rights
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be found
+ in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this specification
+ can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr at ietf.org.
+
+
+
+Full Copyright
+
+ Copyright (C) The Internet Society (2006).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+
+
+
+
+
+
+
+Zeilenga LDAP Don't Use Copy Control [Page 5]
+
Added: openldap/vendor/openldap-release/doc/drafts/draft-zeilenga-ldap-incr.txt
===================================================================
--- openldap/vendor/openldap-release/doc/drafts/draft-zeilenga-ldap-incr.txt (rev 0)
+++ openldap/vendor/openldap-release/doc/drafts/draft-zeilenga-ldap-incr.txt 2007-09-15 10:38:52 UTC (rev 844)
@@ -0,0 +1,340 @@
+
+
+
+
+
+INTERNET-DRAFT Kurt D. Zeilenga
+Intended Category: Experimental OpenLDAP Foundation
+Expires in six months 10 February 2005
+
+
+
+ LDAP Modify-Increment Extension
+ <draft-zeilenga-ldap-incr-01.txt>
+
+
+Status of this Memo
+
+ This document is intended to be, after appropriate review and
+ revision, submitted to the RFC Editor as an Experimental document.
+ Distribution of this memo is unlimited. Technical discussion of this
+ document will take place on the IETF LDAP Extensions mailing list
+ <ldapext at ietf.org>. Please send editorial comments directly to the
+ author <Kurt at OpenLDAP.org>.
+
+ By submitting this Internet-Draft, I accept the provisions of Section
+ 4 of RFC 3667. By submitting this Internet-Draft, I certify that any
+ applicable patent or other IPR claims of which I am aware have been
+ disclosed, or will be disclosed, and any of which I become aware will
+ be disclosed, in accordance with RFC 3668.
+
+ Internet-Drafts are working documents of the Internet Engineering Task
+ Force (IETF), its areas, and its working groups. Note that other
+ groups may also distribute working documents as Internet-Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference material
+ or to cite them other than as "work in progress."
+
+ The list of current Internet-Drafts can be accessed at
+ http://www.ietf.org/1id-abstracts.html
+
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html
+
+
+ Copyright (C) The Internet Society (2005). All Rights Reserved.
+
+ Please see the Full Copyright section near the end of this document
+ for more information.
+
+
+
+
+
+
+Zeilenga LDAP Modify-Increment Extension [Page 1]
+
+INTERNET-DRAFT draft-zeilenga-ldap-incr-01.txt 10 February 2005
+
+
+Abstract
+
+ This document describes an extension to the Lightweight Directory
+ Access Protocol (LDAP) Modify operation to support an increment
+ capability. This extension is useful in provisioning applications,
+ especially when combined with the assertion control and/or the
+ pre-read or post-read control extension.
+
+
+1. Background and Intended Use
+
+ The Lightweight Directory Access Protocol [Roadmap] does not currently
+ provide an operation to increment values of an attribute. A client
+ must read the values of the attribute, then modify those values to
+ increment them by the desired amount. As the values may be updated by
+ other clients between this add and modify, the client must be careful
+ to construct the modify request so that it fails in this case, and
+ upon failure, re-read the values and construct a new modify request.
+
+ This document extends the LDAP Modify Operation [Protocol] to support
+ an increment values capability. This feature is intended to be used
+ with either the LDAP pre-read or post-read control extension
+ [ReadEntry]. This feature may also be used with the LDAP assertion
+ control [Assertion] to provide test-and-increment functionality.
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in BCP 14 [RFC2119].
+
+
+2. The Modify-Increment Extension
+
+ This document extends the LDAP Modify request to support a increment
+ values capability. Implementations of this extension SHALL support an
+ additional ModifyRequest operation enumeration value increment (IANA-
+ ASSIGNED-TYPE) as described herein. Implementations not supporting
+ this extension will treat this value as they would an unlisted value,
+ e.g., as a protocol error.
+
+ The increment (IANA-ASSIGNED-TYPE) operation value specifies that an
+ increment values modification is requested. All existing values of
+ the modification attribute are to be incremented by the listed value.
+ The modification attribute must be appropriate for request, e.g., must
+ have INTEGER or other increment-able values, and the modification must
+ provide one and only value. If the attribute is not appropriate for
+ the request, a constraintViolation or other appropriate error is to be
+ returned. If multiple values are provided, a protocolError is to be
+ returned.
+
+
+
+Zeilenga LDAP Modify-Increment Extension [Page 2]
+
+INTERNET-DRAFT draft-zeilenga-ldap-incr-01.txt 10 February 2005
+
+
+ Servers supporting this feature SHOULD publish the object identifier
+ (OID) IANA-ASSIGNED-OID as a value of the 'supportedFeatures'
+ [RFC3674] attribute in the root DSE. Clients supporting this feature
+ SHOULD NOT use the feature unless they have knowledge the server
+ supports it.
+
+
+ 3. LDIF Support
+
+ To represent Modify-Increment requests in LDAP Data Interchange Format
+ [RFC2849], the ABNF [RFC2234] production <mod-spec> is extended as
+ follows:
+
+ mod-spec /= "increment:" FILL AttributeDescription SEP
+ attrval-spec "-" SEP
+
+ For example,
+
+ # Increment uidNumber
+ dn: cn=max-assigned uidNumber,dc=example,dc=com
+ changetype: modify
+ increment: uidNumber
+ uidNumber: 1
+ -
+
+ This LDIF fragment represents a Modify request to increment the
+ value(s) of uidNumber by 1.
+
+
+4. Security Considerations
+
+ General LDAP security considerations [Roadmap], as well as those
+ specific to the LDAP Modify [Protocol], apply to this Modify-Increment
+ extension. Beyond these considerations, it is noted that introduction
+ of this extension should reduce application complexity (by provide one
+ operation what presently requires multiple operation) and, hence, may
+ aide in the production of correct and secure implementations.
+
+
+5. IANA Considerations
+
+ Registration of the following values [BCP64bis] is requested.
+
+
+5.1. Object Identifier
+
+ It is requested that IANA assign an LDAP Object Identifier to identify
+ the LDAP Modify-Increment feature as defined in this document.
+
+
+
+Zeilenga LDAP Modify-Increment Extension [Page 3]
+
+INTERNET-DRAFT draft-zeilenga-ldap-incr-01.txt 10 February 2005
+
+
+ Subject: Request for LDAP Object Identifier Registration
+ Person & email address to contact for further information:
+ Kurt Zeilenga <kurt at OpenLDAP.org>
+ Specification: RFC XXXX
+ Author/Change Controller: Author
+ Comments:
+ Identifies the LDAP Modify-Increment feature
+
+
+
+5.2. LDAP Protocol Mechanism
+
+ It is requested that the following LDAP Protocol Mechanism be
+ registered.
+
+ Subject: Request for LDAP Protocol Mechanism Registration
+ Object Identifier: IANA-ASSIGNED-OID
+ Description: Modify-Increment
+ Person & email address to contact for further information:
+ Kurt Zeilenga <kurt at openldap.org>
+ Usage: Feature
+ Specification: RFC XXXX
+ Author/Change Controller: Kurt Zeilenga <kurt at openldap.org>
+ Comments: none
+
+
+5.3. LDAP Protocol Mechanism
+
+ It is requested that IANA assign an LDAP ModifyRequest Operation Type
+ [BCP64bis] for use in this document.
+
+ Subject: Request for LDAP Protocol Mechanism Registration
+ ModifyRequest Operation Name: increment
+ Description: Modify-Increment
+ Person & email address to contact for further information:
+ Kurt Zeilenga <kurt at openldap.org>
+ Usage: Feature
+ Specification: RFC XXXX
+ Author/Change Controller: Kurt Zeilenga <kurt at openldap.org>
+ Comments: none
+
+
+6. Author's Address
+
+ Kurt D. Zeilenga
+ OpenLDAP Foundation
+ <Kurt at OpenLDAP.org>
+
+
+
+
+Zeilenga LDAP Modify-Increment Extension [Page 4]
+
+INTERNET-DRAFT draft-zeilenga-ldap-incr-01.txt 10 February 2005
+
+
+7. References
+
+ [[Note to the RFC Editor: please replace the citation tags used in
+ referencing Internet-Drafts with tags of the form RFCnnnn where
+ possible.]]
+
+
+7.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14 (also RFC 2119), March 1997.
+
+ [RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
+ Specifications: ABNF", RFC 2234, November 1997.
+
+ [RFC2849] Good, G., "The LDAP Data Interchange Format (LDIF) -
+ Technical Specification", RFC 2849, June 2000.
+
+ [Features] Zeilenga, K., "Feature Discovery in LDAP", RFC 3674,
+ December 2003.
+
+ [Roadmap] Zeilenga, K. (editor), "LDAP: Technical Specification
+ Road Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in
+ progress.
+
+ [Protocol] Sermersheim, J. (editor), "LDAP: The Protocol",
+ draft-ietf-ldapbis-protocol-xx.txt, a work in progress.
+
+
+7.2. Informative References
+
+ [BCP64bis] Zeilenga, K., "IANA Considerations for LDAP",
+ draft-ietf-ldapbis-bcp64-xx.txt, a work in progress.
+
+ [ReadEntry] Zeilenga, K., "LDAP Read Entry Controls",
+ draft-zeilenga-ldap-readentry-xx.txt, a work in
+ progress.
+
+ [Assertion] Zeilenga, K., "LDAP Assertion Control",
+ draft-zeilenga-ldap-assert-xx.txt, a work in progress.
+
+ [ASSIGN] OpenLDAP Foundation, "OpenLDAP OID Delegations",
+ http://www.openldap.org/foundation/oid-delegate.txt.
+
+ [PRIVATE] IANA, "Private Enterprise Numbers",
+ http://www.iana.org/assignments/enterprise-numbers.
+
+
+
+
+
+Zeilenga LDAP Modify-Increment Extension [Page 5]
+
+INTERNET-DRAFT draft-zeilenga-ldap-incr-01.txt 10 February 2005
+
+
+Intellectual Property Rights
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be found
+ in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this specification
+ can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr at ietf.org.
+
+
+
+Full Copyright
+
+ Copyright (C) The Internet Society (2005). This document is subject
+ to the rights, licenses and restrictions contained in BCP 78, and
+ except as set forth therein, the authors retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga LDAP Modify-Increment Extension [Page 6]
+
+
+
Added: openldap/vendor/openldap-release/doc/drafts/draft-zeilenga-ldap-managedit-xx.txt
===================================================================
--- openldap/vendor/openldap-release/doc/drafts/draft-zeilenga-ldap-managedit-xx.txt (rev 0)
+++ openldap/vendor/openldap-release/doc/drafts/draft-zeilenga-ldap-managedit-xx.txt 2007-09-15 10:38:52 UTC (rev 844)
@@ -0,0 +1,675 @@
+
+
+
+
+
+
+INTERNET-DRAFT Kurt D. Zeilenga
+Intended Category: Experimental OpenLDAP Foundation
+Expires in six months 27 February 2006
+
+
+
+ The LDAP Manage Directory Information Tree Control
+ <draft-zeilenga-ldap-managedit-00.txt>
+
+
+Status of this Memo
+
+ This document is intended to be, after appropriate review and
+ revision, submitted to the RFC Editor for publication as an
+ Experimental document. Distribution of this memo is unlimited.
+ Technical discussion of this document will take place on the IETF LDAP
+ Extensions mailing list <ldapext at ietf.org>. Please send editorial
+ comments directly to the author <Kurt at OpenLDAP.org>.
+
+ By submitting this Internet-Draft, each author represents that any
+ applicable patent or other IPR claims of which he or she is aware have
+ been or will be disclosed, and any of which he or she becomes aware
+ will be disclosed, in accordance with Section 6 of BCP 79.
+
+ Internet-Drafts are working documents of the Internet Engineering Task
+ Force (IETF), its areas, and its working groups. Note that other
+ groups may also distribute working documents as Internet-Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference material
+ or to cite them other than as "work in progress."
+
+ The list of current Internet-Drafts can be accessed at
+ http://www.ietf.org/1id-abstracts.html
+
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html
+
+
+ Copyright (C) The Internet Society (2006). All Rights Reserved.
+
+ Please see the Full Copyright section near the end of this document
+ for more information.
+
+
+
+
+
+
+
+Zeilenga LDAP Manage DIT Control [Page 1]
+
+INTERNET-DRAFT draft-zeilenga-ldap-managedit-00 27 February 2006
+
+
+Abstract
+
+ This document defines the Lightweight Directory Access Protocol (LDAP)
+ Manage Directory Information Tree (DIT) Control which allows a
+ directory user agent (a client) to request the directory service
+ temporarily relax enforcement of constraints of the X.500 models.
+
+
+1. Background and Intended Use
+
+ Directory servers accessible via Lightweight Directory Access Protocol
+ (LDAP) [Roadmap] are expected to act in accordance with the X.500
+ series of ITU-T Recommendations. In particular, servers are expected
+ to ensure the X.500 data and service models are not violated.
+
+ An LDAP server is expected to prevent modification of the structural
+ object class of an object [Models]. That is, the X.500 models do not
+ allow a 'person' object to be transformed into an
+ 'organizationalPerson' object through modification of the object.
+ Instead, the 'person' object must be deleted and then a new
+ 'organizationalPerson' object created in its place. This approach,
+ aside from being inconvient, is problematic for a number reasons.
+ First, as LDAP does not have a standardized method for performing the
+ two operations in a single transaction, the intermediate directory
+ state (after the delete, before the add) is visible to other clients,
+ which may lead to undesirable client behavior. Second, attributes
+ such as entryUUID [entryUUID] will reflect the object was replaced,
+ not transformed.
+
+ An LDAP server is expected to prevent clients from modifying values of
+ NO-USER-MODIFICATION attributes [Models]. For instance, an entry is
+ not allowed to assign or modify the value of the entryUUID attribute.
+ However, where an administrator is restoring a previously existing
+ object, for instance when repartitioning data between directory
+ servers or when migrating from one vendor server product to another,
+ it may be desirable to allow the client to assign or modify the value
+ of the entryUUID attribute.
+
+ This document specifies the Manage Directory Information Tree (DIT)
+ control. The Manage DIT control may be attached to LDAP requests to
+ update the DIT to request DIT restrictions be temporarily relaxed
+ during the performance of the requested DIT update. The server is
+ however to ensure the resulting directory state is valid.
+
+ Use of this control is expected that use of this extension will be
+ restricted by administrative and/or access controls. It is intended
+ to be used by directory administrators.
+
+
+
+
+Zeilenga LDAP Manage DIT Control [Page 2]
+
+INTERNET-DRAFT draft-zeilenga-ldap-managedit-00 27 February 2006
+
+
+ This extension is considered experimental as it is not yet clear
+ whether it adequately addresses directory administrators' needs for
+ flexible mechanisms for managing directory objects. It is hoped that
+ after suitable amount of time, either this extension or a suitable
+ replacement will be standardization.
+
+
+1.1. Terminology
+
+ Protocol elements are described using ASN.1 [X.680] with implicit
+ tags. The term "BER-encoded" means the element is to be encoded using
+ the Basic Encoding Rules [X.690] under the restrictions detailed in
+ Section 5.2 of [Protocol].
+
+ 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, a server. DSE stands for DSA-
+ specific Entry.
+
+
+2. The Manage DIT Control
+
+ The Manage DIT control is an LDAP Control [Protocol] whose controlType
+ is IANA-ASSIGNED-OID, controlValue is empty, and the criticality of
+ TRUE.
+
+ There is no corresponding response control.
+
+ The control is appropriate for all LDAP update requests, including
+ add, delete, modify, and modifyDN (rename) [Protocol].
+
+ The presence of the Manage DIT control in an LDAP update request
+ indicates the server temporarily relax X.500 model contraints during
+ performance of the directory update.
+
+ The server may restrict use of this control and/or limit the extent of
+ the relaxation provided based upon local policy or factors.
+
+ The server is obligated to ensure the resulting directory state is
+ consistent with the X.500 models. For instance, the server ensure
+ that values of attributes conform to the value syntax.
+
+ It is noted that while this extension may be used to add or modify
+ objects in a manner which violate the controlling subschema, the
+ presence of objects in the DIT is not inconsistent with the X.500
+ models. For instance, an object created prior to establshment of a
+
+
+
+Zeilenga LDAP Manage DIT Control [Page 3]
+
+INTERNET-DRAFT draft-zeilenga-ldap-managedit-00 27 February 2006
+
+
+ DIT content rule may contain an attribute now precluded by the current
+ controlling DIT Content Rule.
+
+ Servers implementing this technical specification SHOULD publish the
+ object identifier IANA-ASSIGNED-OID as a value of the
+ 'supportedControl' attribute [Models] in their root DSE. A server MAY
+ choose to advertise this extension only when the client is authorized
+ to use it.
+
+
+3. Use Cases
+
+3.1. Object metamorphism
+
+ In absence of this control, an attempt to modify an object's
+ 'objectClass' in a manner which cause a change in the structural
+ object class of the object would normally lead to an
+ objectClassModsProhibited error [Protocol]. The presence of the
+ Manage DIT control in the modify request requests the change be
+ allowed. If the server is willing and able to allow the change in the
+ structural object class of the object.
+
+ For instance, to change an 'organization' object into an
+ 'organizationalUnit' object, a client could issue the following LDAP
+ request:
+
+ dn: o=Unit,dc=example,dc=net
+ control: IANA-ASSIGNED-OID
+ changetype: modify
+ delete: objectClass
+ objectClass: organization
+ -
+ add: objectClass
+ objectClass: organizationalUnit
+ -
+
+ In this case, the server is expected to either effect the requested
+ change in the structural object class, including updating of the value
+ of the structural object class, or fail the operation.
+
+
+3.2. Inactive Attribute Types
+
+ In absence of the Manage DIT control, an attempt to add or modify
+ values to an attribute whose type has been marked inactive in the
+ controlling subschema (its attribute type description contains the
+ OBSOLETE field) [Models] normally results in a failure.
+
+
+
+
+Zeilenga LDAP Manage DIT Control [Page 4]
+
+INTERNET-DRAFT draft-zeilenga-ldap-managedit-00 27 February 2006
+
+
+ In the presence of the Manage DIT control, the server performs the
+ update operation as if the attribute's type is marked active in the
+ controlling subschema (its attribute type description does not contain
+ the OBSOLETE field).
+
+
+3.3. DIT Content Rules
+
+ In absence of the Manage DIT control, an attempt to include the name
+ (or OID) of an auxiliary class to an object's 'objectClass' which is
+ not allowed by the controlling DIT Content Rule would be disallowed
+ [Models]. Additionally, an attempt to add values of an attribute not
+ allowed (or explicitly precluded) by the DIT Content Rule would fail.
+
+ In presence of the Manage DIT control, the server performs the update
+ operation as if the controlling DIT Content Rule allowed any and all
+ known auxiliary classses to be present and allowed any and all known
+ attributes to be present (and precluded no attributes).
+
+
+3.4. DIT Structure Rules and Name Forms
+
+ In absence of the Manage DIT control, the service enforces DIT
+ structure rules and name form requirements of the controlling
+ subschema [Models].
+
+ In the presence of the Manage DIT control, the server performs the
+ update operation ignoring all DIT structure rules and name forms in
+ the controlling subschema.
+
+
+3.5. Modification of Nonconformant Objects
+
+ It is also noted that in absense of this control, modification of an
+ object which presently violates the controlling subschema will fail
+ unless the modification would result in the object conforming to the
+ controlling subschema. That is, modifications of an non-conformant
+ object should result in a conformant object.
+
+ In the presence of this control, modifications of a non-conformant
+ object need not result in a conformant object.
+
+
+3.6. NO-USER-MODIFICATION attribute modification
+
+ In absence of this control, an attempt to modify values of a
+ NO-USER-MODIFICATION attribute would normally lead to a
+ constraintViolation or other appropriate error [Protocol]. In the
+
+
+
+Zeilenga LDAP Manage DIT Control [Page 5]
+
+INTERNET-DRAFT draft-zeilenga-ldap-managedit-00 27 February 2006
+
+
+ presence of the Manage DIT control in the update request requests the
+ modification be allowed.
+
+ Relaxation of the NO-USER-MODIFICATION constraint is not appropriate
+ for some operational attribute types. For instance, as the value of
+ the 'structuralObjectClass' is derived by the values of the
+ 'objectClass' attribute, the 'structuralObjectClass' attribute type's
+ NO-USER-MODIFICATION contraint MUST NOT be relaxed. To effect a
+ change in the structuralObjectClass class, values of objectClass
+ should be changed as discussed in Section 3.1. Other attributes for
+ which the NO-USER-MODIFICATION constraint should not be relaxed
+ include 'entryDN' [EntryDN], 'subschemaSubentry' [Models], and
+ 'collectiveAttributeSubentries' [RFC3671].
+
+ The subsections of this section discuss modification of various
+ operational attributes where their NO-USER-MODIFICATION constraint may
+ be relaxed. Future documents may specify where NO-USER-MODIFICATION
+ constraints on other operational attribute may be relaxed. In absence
+ of a document detailing that the NO-USER-MODIFICATION constraint on a
+ particular operational attribute may be relaxed, implementors SHOULD
+ assume relaxation of the constraint is not appropriate for that
+ attribute.
+
+
+3.1.1. entryUUID
+
+ To provide a value for the 'entryUUID' attribute on entry creation,
+ the client should issue an LDAP Add request with a Manage DIT control
+ providing the desired value. For instance:
+
+ dn: ou=Unit,dc=example,dc=net
+ control: IANA-ASSIGNED-OID
+ changetype: add
+ objectClass: organizationalUnit
+ ou: Unit
+ entryUUID: 597ae2f6-16a6-1027-98f4-d28b5365dc14
+
+ In this case, the server is either to add the entry using the
+ provided 'entryUUID' value or fail the request.
+
+ To provide a replacement value for the 'entryUUID' after entry
+ creation, the client should issue an LDAP Modify request with a
+ Manage DIT control including an approrpiate change. For instance:
+
+ dn: ou=Unit,dc=example,dc=net
+ control: IANA-ASSIGNED-OID
+ changetype: modify
+ replace: entryUUID
+
+
+
+Zeilenga LDAP Manage DIT Control [Page 6]
+
+INTERNET-DRAFT draft-zeilenga-ldap-managedit-00 27 February 2006
+
+
+ entryUUID: 597ae2f6-16a6-1027-98f4-d28b5365dc14
+ -
+
+ In this case, the server is either to replace the 'entryUUID' value
+ as requested or fail the request.
+
+
+3.2.2. createTimestamp
+
+ To provide a value for the 'createTimestamp' attribute on entry
+ creation, the client should issue an LDAP Add request with a Manage
+ DIT control providing the desired 'createTimestamp' value. For
+ instance:
+
+ dn: ou=Unit,dc=example,dc=net
+ control: IANA-ASSIGNED-OID
+ changetype: add
+ objectClass: organizationalUnit
+ ou: Unit
+ createTimestamp: 20060101000000Z
+
+ In this case, the server is either to add the entry using the
+ provided 'createTimestamp' value or fail the request.
+
+ To provide a replacement value for the 'createTimestamp' after
+ entry creation, the client should issue an LDAP Modify request with
+ a Manage DIT control including an approrpiate change. For instance:
+
+ dn: ou=Unit,dc=example,dc=net
+ control: IANA-ASSIGNED-OID
+ changetype: modify
+ replace: createTimestamp
+ createTimestamp: 20060101000000Z
+ -
+
+ In this case, the server is either to replace the 'createTimestamp'
+ value as requested or fail the request.
+
+ The server should ensure the requested 'createTimestamp' value is
+ appropriate. In particular, it should fail the request if the
+ requested 'createTimestamp' value is in the future or is greater
+ than the value of the 'modifyTimestamp' attribute.
+
+
+3.2.3. modifyTimestamp
+
+ To provide a value for the 'modifyTimestamp' attribute on entry
+ creation, the client should issue an LDAP Add request with a Manage
+
+
+
+Zeilenga LDAP Manage DIT Control [Page 7]
+
+INTERNET-DRAFT draft-zeilenga-ldap-managedit-00 27 February 2006
+
+
+ DIT control providing the desired 'modifyTimestamp' value. For
+ instance:
+
+ dn: ou=Unit,dc=example,dc=net
+ control: IANA-ASSIGNED-OID
+ changetype: add
+ objectClass: organizationalUnit
+ ou: Unit
+ modifyTimestamp: 20060101000000Z
+
+ In this case, the server is either to add the entry using
+ the provided 'modifyTimestamp' value or fail the request.
+
+ To provide a replacement value for the 'modifyTimestamp' after
+ entry creation, the client should issue an LDAP Modify
+ request with a Manage DIT control including an approrpiate
+ change. For instance:
+
+ dn: ou=Unit,dc=example,dc=net
+ control: IANA-ASSIGNED-OID
+ changetype: modify
+ replace: modifyTimestamp
+ modifyTimestamp: 20060101000000Z
+ -
+
+ In this case, the server is either to replace the 'modifyTimestamp'
+ value as requested or fail the request.
+
+ The server should ensure the requested 'modifyTimestamp' value is
+ appropriate. In particular, it should fail the request if the
+ requested 'modifyTimestamp' value is in the future or is less than
+ the value of the 'createTimestamp' attribute.
+
+
+ 3.2.3. creatorsName and modifiersName
+
+ To provide a value for the 'creatorsName' and/or 'modifiersName'
+ attribute on entry creation, the client should issue an LDAP Add
+ request with a Manage DIT control providing the desired values.
+ For instance:
+
+ dn: ou=Unit,dc=example,dc=net
+ control: IANA-ASSIGNED-OID
+ changetype: add
+ objectClass: organizationalUnit
+ ou: Unit
+ creatorsName: cn=Jane Doe,dc=example,net
+ modifiersName: cn=Jane Doe,dc=example,net
+
+
+
+Zeilenga LDAP Manage DIT Control [Page 8]
+
+INTERNET-DRAFT draft-zeilenga-ldap-managedit-00 27 February 2006
+
+
+ In this case, the server is either to add the entry using
+ the provided values or fail the request.
+
+ To provide a replacement values after entry creation for either of
+ the 'creatorsName' or 'modifiersName' attributes or both, the
+ client should issue an LDAP Modify request with a Manage DIT control
+ including the approrpiate changes. For instance:
+
+ dn: ou=Unit,dc=example,dc=net
+ control: IANA-ASSIGNED-OID
+ changetype: modify
+ replace: creatorsName
+ creatorsName: cn=Jane Doe,dc=example,net
+ -
+ replace: modifiersName
+ modifiersName: cn=Jane Doe,dc=example,net
+ -
+
+ In this case, the server is either to replace the provided
+ values as requested or fail the request.
+
+
+4. Security Considerations
+
+ Use of this extension should be subject to appropriate administrative
+ and access controls. Use of this mechanism is intended to be
+ restricted to directory administrators.
+
+ Security considerations for the base operations [Protocol] extended
+ by this control, as well as general LDAP security considerations
+ [Roadmap], generally apply to implementation and use of this
+ extension.
+
+
+5. IANA Considerations
+
+5.1. Object Identifier
+
+ It is requested that IANA assign a LDAP Object Identifier [BCP64bis]
+ to identify the LDAP Assertion Control defined in this document.
+
+ Subject: Request for LDAP Object Identifier Registration
+ Person & email address to contact for further information:
+ Kurt Zeilenga <kurt at OpenLDAP.org>
+ Specification: RFC XXXX
+ Author/Change Controller: Kurt Zeilenga <kurt at openldap.org>
+ Comments: Identifies the LDAP Manage DIT Control
+
+
+
+
+Zeilenga LDAP Manage DIT Control [Page 9]
+
+INTERNET-DRAFT draft-zeilenga-ldap-managedit-00 27 February 2006
+
+
+5.2 LDAP Protocol Mechanism
+
+ Registration of this protocol mechanism [BCP64bis] is requested.
+
+ Subject: Request for LDAP Protocol Mechanism Registration
+ Object Identifier: IANA-ASSIGNED-OID
+ Description: Manage DIT Control
+ Person & email address to contact for further information:
+ Kurt Zeilenga <kurt at openldap.org>
+ Usage: Control
+ Specification: RFC XXXX
+ Author/Change Controller: Kurt Zeilenga <kurt at openldap.org>
+ Comments: none
+
+
+6. Author's Address
+
+ Kurt D. Zeilenga
+ OpenLDAP Foundation
+
+ Email: Kurt at OpenLDAP.org
+
+
+7. References
+
+ [[Note to the RFC Editor: please replace the citation tags used in
+ referencing Internet-Drafts with tags of the form RFCnnnn where
+ possible.]]
+
+
+7.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14 (also RFC 2119), March 1997.
+
+ [Roadmap] Zeilenga, K. (editor), "LDAP: Technical Specification
+ Road Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in
+ progress.
+
+ [Models] Zeilenga, K. (editor), "LDAP: Directory Information
+ Models", draft-ietf-ldapbis-models-xx.txt, a work in
+ progress.
+
+
+
+7.2. Informative References
+
+ [BCP64bis] Zeilenga, K., "IANA Considerations for LDAP",
+
+
+
+Zeilenga LDAP Manage DIT Control [Page 10]
+
+INTERNET-DRAFT draft-zeilenga-ldap-managedit-00 27 February 2006
+
+
+ draft-ietf-ldapbis-bcp64-xx.txt, a work in progress.
+
+ [EntryUUID] Zeilenga, K., "The LDAP EntryUUID Operational
+ Attribute", draft-zeilenga-ldap-uuid-xx.txt, a work in
+ progress.
+
+ [RFC2849] Good, G., "The LDAP Data Interchange Format (LDIF) -
+ Technical Specification", RFC 2849, June 2000.
+
+
+
+Intellectual Property Rights
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be found
+ in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this specification
+ can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr at ietf.org.
+
+
+
+Full Copyright
+
+ Copyright (C) The Internet Society (2006).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+
+
+
+Zeilenga LDAP Manage DIT Control [Page 11]
+
+INTERNET-DRAFT draft-zeilenga-ldap-managedit-00 27 February 2006
+
+
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga LDAP Manage DIT Control [Page 12]
+
Added: openldap/vendor/openldap-release/doc/drafts/draft-zeilenga-ldap-noop-xx.txt
===================================================================
--- openldap/vendor/openldap-release/doc/drafts/draft-zeilenga-ldap-noop-xx.txt (rev 0)
+++ openldap/vendor/openldap-release/doc/drafts/draft-zeilenga-ldap-noop-xx.txt 2007-09-15 10:38:52 UTC (rev 844)
@@ -0,0 +1,339 @@
+
+
+
+
+
+
+INTERNET-DRAFT Kurt D. Zeilenga
+Intended Category: Standard Track OpenLDAP Foundation
+Expires in six months 5 March 2006
+
+
+
+ The LDAP No-Op Control
+ <draft-zeilenga-ldap-noop-08.txt>
+
+
+Status of this Memo
+
+ This document is intended to be, after appropriate review and
+ revision, submitted to the IESG for consideration as a Standard Track
+ document. Distribution of this memo is unlimited. Technical
+ discussion of this document will take place on the IETF LDAP
+ Extensions mailing list <ldapext at ietf.org>. Please send editorial
+ comments directly to the author <Kurt at OpenLDAP.org>.
+
+ By submitting this Internet-Draft, each author represents that any
+ applicable patent or other IPR claims of which he or she is aware have
+ been or will be disclosed, and any of which he or she becomes aware
+ will be disclosed, in accordance with Section 6 of BCP 79.
+
+ Internet-Drafts are working documents of the Internet Engineering Task
+ Force (IETF), its areas, and its working groups. Note that other
+ groups may also distribute working documents as Internet-Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference material
+ or to cite them other than as "work in progress."
+
+ The list of current Internet-Drafts can be accessed at
+ http://www.ietf.org/1id-abstracts.html
+
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html
+
+
+ Copyright (C) The Internet Society (2006). All Rights Reserved.
+
+ Please see the Full Copyright section near the end of this document
+ for more information.
+
+
+
+
+
+
+
+Zeilenga LDAP No-Op Control [Page 1]
+
+INTERNET-DRAFT draft-zeilenga-ldap-noop-08 5 March 2006
+
+
+Abstract
+
+ This document defines the Lightweight Directory Access Protocol (LDAP)
+ No-Op control which can be used to disable the normal effect of an
+ operation. The control can be used to discover how a server might
+ react to a particular update request without updating the directory.
+
+
+1. Overview
+
+ It is often desirable to be able to determine if a directory operation
+ [Protocol] would successful complete or not without having the normal
+ effect of the operation take place. For example, an administrative
+ client might want to verify that new user could update their entry
+ (and not other entries) without the directory actually being updated.
+ The mechanism could be used to build more sophisticated security
+ auditing tools.
+
+ This document defines the Lightweight Directory Access Protocol (LDAP)
+ [Roadmap] No-Op control extension. The presence of the No-Op control
+ in an operation request message disables its normal effect upon the
+ directory which operation would otherwise have. Instead of updating
+ the directory and returning the normal indication of success, the
+ server does not update the directory and indicates so by returning the
+ noOperation resultCode (introduced below).
+
+ For example, when the No-Op control is present in a LDAP modify
+ operation [Protocol], the server is do all processing necessary to
+ perform the operation without actually updating the directory. If it
+ detects an error during this processing, it returns a non-success
+ (other than noOperation) resultCode as it normally would. Otherwise,
+ it returns the noOperation. In either case, the directory is left
+ unchanged.
+
+ This No-Op control is not intended to be to an "effective access"
+ mechanism [RFC2820, U12].
+
+
+1.1. Terminology
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in BCP 14 [RFC2119].
+
+ DN stands for Distinguished Name.
+ DSA stands for Directory System Agent.
+ DSE stands for DSA-specific entry.
+
+
+
+
+Zeilenga LDAP No-Op Control [Page 2]
+
+INTERNET-DRAFT draft-zeilenga-ldap-noop-08 5 March 2006
+
+
+2. No-Op Control
+
+ The No-Op control is an LDAP Control [Protocol] whose controlType is
+ IANA-ASSIGNED-OID and controlValue is absent. Clients MUST provide a
+ criticality value of TRUE to prevent unintended modification of the
+ directory.
+
+ The control is appropriate for request messages of LDAP Add, Delete,
+ Modify and ModifyDN operations [Protocol]. The control is also
+ appropriate for requests of extended operations which update the
+ directory (or other data stores), such as Password Modify Extended
+ Operation [RFC3062]. There is no corresponding response control.
+
+ When the control is attached to an LDAP request, the server does all
+ normal processing possible for the operation without modification of
+ the directory. That is, when the control is attached to an LDAP
+ request, the directory SHALL NOT be updated and the response SHALL NOT
+ have a resultCode of success (0).
+
+ A result code other than noOperation (IANA-ASSIGNED-CODE) means that
+ the server is unable or unwilling to complete the processing for the
+ reason indicated by the result code. A result code of noOperation
+ (IANA-ASSIGNED-CODE) indicates that the server discovered no reason
+ why the operation would fail if submitted without the No-Op control.
+ It is noted that there may be reasons why the operation may fail which
+ are only discoverable when submitting without the No-Op control.
+
+ Servers SHOULD indicate their support for this control by providing
+ IANA-ASSIGNED-OID as a value of the 'supportedControl' attribute type
+ [Models] in their root DSE entry. A server MAY choose to advertise
+ this extension only when the client is authorized to use this
+ operation.
+
+
+3. Security Considerations
+
+ The No-Op control mechanism allows directory administrators and users
+ to verify that access control and other administrative policy controls
+ are properly configured. The mechanism may also lead to the
+ development (and deployment) of more effective security auditing
+ tools.
+
+ Implementors of this LDAP extension should be familiar with security
+ considerations applicable to the LDAP operations [Protocol] extended
+ by this control, as well as general LDAP security considerations
+ [Roadmap].
+
+
+
+
+
+Zeilenga LDAP No-Op Control [Page 3]
+
+INTERNET-DRAFT draft-zeilenga-ldap-noop-08 5 March 2006
+
+
+4. IANA Considerations
+
+4.1. Object Identifier
+
+ It is requested that IANA assign an LDAP Object Identifier [BCP64bis]
+ to identify the LDAP No-Op Control defined in this document.
+
+ Subject: Request for LDAP Object Identifier Registration
+ Person & email address to contact for further information:
+ Kurt Zeilenga <kurt at OpenLDAP.org>
+ Specification: RFC XXXX
+ Author/Change Controller: IESG
+ Comments:
+ Identifies the LDAP No-Op Control
+
+
+4.2 LDAP Protocol Mechanism
+
+ Registration of this protocol mechanism is requested [RFC3383].
+
+ Subject: Request for LDAP Protocol Mechanism Registration
+ Object Identifier: IANA-ASSIGNED-OID
+ Description: No-Op Control
+ Person & email address to contact for further information:
+ Kurt Zeilenga <kurt at openldap.org>
+ Usage: Control
+ Specification: RFC XXXX
+ Author/Change Controller: IESG
+ Comments: none
+
+
+4.3 LDAP Result Code
+
+ Assignment of an LDAP Result Code called 'noOperation' is requested.
+
+ Subject: LDAP Result Code Registration
+ Person & email address to contact for further information:
+ Kurt Zeilenga <kurt at OpenLDAP.org>
+ Result Code Name: noOperation
+ Specification: RFC XXXX
+ Author/Change Controller: IESG
+ Comments: none
+
+
+5. Author's Address
+
+ Kurt D. Zeilenga
+ OpenLDAP Foundation
+
+
+
+Zeilenga LDAP No-Op Control [Page 4]
+
+INTERNET-DRAFT draft-zeilenga-ldap-noop-08 5 March 2006
+
+
+ Email: Kurt at OpenLDAP.org
+
+
+6. References
+
+ [[Note to the RFC Editor: please replace the citation tags used in
+ referencing Internet-Drafts with tags of the form RFCnnnn where
+ possible.]]
+
+
+6.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14 (also RFC 2119), March 1997.
+
+ [Protocol] Sermersheim, J. (editor), "LDAP: The Protocol",
+ draft-ietf-ldapbis-protocol-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.
+
+ [Models] Zeilenga, K. (editor), "LDAP: Directory Information
+ Models", draft-ietf-ldapbis-models-xx.txt, a work in
+ progress.
+
+
+6.2. Informative References
+
+ [X.500] International Telecommunication Union -
+ Telecommunication Standardization Sector, "The Directory
+ -- Overview of concepts, models and services,"
+ X.500(1993) (also ISO/IEC 9594-1:1994).
+
+ [RFC2820] Stokes, E., et. al., "Access Control Requirements for
+ LDAP", RFC 2820, May 2000.
+
+ [RFC3062] Zeilenga, K., "LDAP Password Modify Extended Operation",
+ RFC 3062, February 2000.
+
+ [BCP64bis] Zeilenga, K., "IANA Considerations for LDAP",
+ draft-ietf-ldapbis-bcp64-xx.txt, a work in progress.
+
+
+
+Intellectual Property Rights
+
+ The IETF takes no position regarding the validity or scope of any
+
+
+
+Zeilenga LDAP No-Op Control [Page 5]
+
+INTERNET-DRAFT draft-zeilenga-ldap-noop-08 5 March 2006
+
+
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be found
+ in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this specification
+ can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr at ietf.org.
+
+
+
+Full Copyright
+
+ Copyright (C) The Internet Society (2006).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga LDAP No-Op Control [Page 6]
+
Added: openldap/vendor/openldap-release/doc/drafts/draft-zeilenga-ldap-readentry-xx.txt
===================================================================
--- openldap/vendor/openldap-release/doc/drafts/draft-zeilenga-ldap-readentry-xx.txt (rev 0)
+++ openldap/vendor/openldap-release/doc/drafts/draft-zeilenga-ldap-readentry-xx.txt 2007-09-15 10:38:52 UTC (rev 844)
@@ -0,0 +1,452 @@
+
+
+
+
+
+INTERNET-DRAFT Kurt D. Zeilenga
+Intended Category: Standard Track OpenLDAP Foundation
+Expires in six months 10 February 2005
+
+
+
+ LDAP Read Entry Controls
+ <draft-zeilenga-ldap-readentry-04.txt>
+
+
+1. Status of this Memo
+
+ This document is intended to be, after appropriate review and
+ revision, submitted to the RFC Editor as a Standard Track document.
+ Distribution of this memo is unlimited. Technical discussion of this
+ document will take place on the IETF LDAP Extensions mailing list
+ <ldapext at ietf.org>. Please send editorial comments directly to the
+ author <Kurt at OpenLDAP.org>.
+
+ By submitting this Internet-Draft, I accept the provisions of Section
+ 4 of RFC 3667. By submitting this Internet-Draft, I certify that any
+ applicable patent or other IPR claims of which I am aware have been
+ disclosed, or will be disclosed, and any of which I become aware will
+ be disclosed, in accordance with RFC 3668.
+
+ Internet-Drafts are working documents of the Internet Engineering Task
+ Force (IETF), its areas, and its working groups. Note that other
+ groups may also distribute working documents as Internet-Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference material
+ or to cite them other than as "work in progress."
+
+ The list of current Internet-Drafts can be accessed at
+ http://www.ietf.org/1id-abstracts.html
+
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html
+
+
+ Copyright (C) The Internet Society (2005). All Rights Reserved.
+
+ Please see the Full Copyright section near the end of this document
+ for more information.
+
+
+
+
+
+
+Zeilenga LDAP Read Entry Controls [Page 1]
+
+INTERNET-DRAFT draft-zeilenga-ldap-readentry-04 10 February 2005
+
+
+Abstract
+
+ This document specifies an extension to the Lightweight Directory
+ Access Protocol (LDAP) to allow the client to read the target entry of
+ an update operation. The client may request to read the entry before
+ and/or after the modifications are applied. These reads are done as
+ an atomic part of the update operation.
+
+
+1. Background and Intent of Use
+
+ This document specifies an extension to the Lightweight Directory
+ Access Protocol (LDAP) [Roadmap] to allow the client to read the
+ target entry of an update operation (e.g., Add, Delete, Modify,
+ ModifyDN). The extension utilizes controls [Protocol] attached to
+ update requests to request and return copies of the target entry. One
+ request control, called the Pre-Read request control, indicates that a
+ copy of the entry before application of update is to be returned.
+ Another control, called the Post-Read request control, indicates that
+ a copy of the entry after application of the update is to be returned.
+ Each request control has a corresponding response control used to
+ return the entry.
+
+ To ensure proper isolation, the controls are processed as an atomic
+ part of the update operation.
+
+ The functionality offered by these controls is based upon similar
+ functionality in the X.500 Directory Access Protocol (DAP) [X.511].
+
+ The Pre-Read controls may be used to obtain replaced or deleted values
+ of modified attributes or a copy of the entry being deleted.
+
+ The Post-Read controls may be used to obtain values of operational
+ attributes, such as the 'entryUUID' [EntryUUID] and 'modifyTimestamp'
+ [Models] attributes, updated by the server as part of the update
+ operation.
+
+
+2. Terminology
+
+ Protocol elements are described using ASN.1 [X.680] with implicit
+ tags. The term "BER-encoded" means the element is to be encoded using
+ the Basic Encoding Rules [X.690] under the restrictions detailed in
+ Section 5.2 of [Protocol].
+
+ DN stands for Distinguished Name.
+ DSA stands for Directory System Agent (i.e., a directory server).
+ DSE stands for DSA-specific Entry.
+
+
+
+Zeilenga LDAP Read Entry Controls [Page 2]
+
+INTERNET-DRAFT draft-zeilenga-ldap-readentry-04 10 February 2005
+
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in BCP 14 [RFC2119].
+
+
+3. Read Entry Controls
+
+3.1. The Pre-Read Controls
+
+ The Pre-Read request and response controls are identified by the
+ IANA-ASSIGNED-OID.1 object identifier. Servers implementing these
+ controls SHOULD publish IANA-ASSIGNED-OID.1 as a value of the
+ 'supportedControl' [Models] in their root DSE.
+
+ The Pre-Read request control is an LDAP Control [Protocol] whose
+ controlType is IANA-ASSIGNED-OID.1 and whose controlValue is a
+ BER-encoded AttributeSelection [Protocol], as extended by [RFC3673].
+ The criticality may be TRUE or FALSE. This control is appropriate for
+ the modifyRequest, delRequest, and modDNRequest LDAP messages.
+
+ The corresponding response control is a LDAP Control whose controlType
+ is IANA-ASSIGNED-OID.1 and whose the controlValue, an OCTET STRING,
+ contains a BER-encoded SearchResultEntry. The criticality may be TRUE
+ or FALSE. This control is appropriate for the modifyResponse,
+ delResponse, and modDNResponse LDAP messages with a resultCode of
+ success (0).
+
+ When the request control is attached to an appropriate update LDAP
+ request, the control requests the return of a copy of target entry
+ prior to the application of the update. The AttributeSelection
+ indicates, as discussed in [Protocol][RFC3673] which attributes are
+ requested to appear in the copy. The server is to return a
+ SearchResultEntry containing, subject to access controls and other
+ constraints, values of the requested attributes.
+
+ The normal processing of the update operation and the processing of
+ this control MUST be performed as one atomic action isolated from
+ other update operations.
+
+ If the update operation fails (in either normal or control
+ processing), no response control is provided.
+
+
+3.2. The Post-Read Controls
+
+ The Post-Read request and response controls are identified by the
+ IANA-ASSIGNED-OID.2 object identifier. Servers implementing these
+ controls SHOULD publish IANA-ASSIGNED-OID.2 as a value of the
+
+
+
+Zeilenga LDAP Read Entry Controls [Page 3]
+
+INTERNET-DRAFT draft-zeilenga-ldap-readentry-04 10 February 2005
+
+
+ 'supportedControl' [Models] in their root DSE.
+
+ The Post-Read request control is an LDAP Control [Protocol] whose
+ controlType is IANA-ASSIGNED-OID.2 and whose controlValue, an OCTET
+ STRING, contains a BER-encoded AttributeSelection [Protocol], as
+ extended by [RFC3673]. The criticality may be TRUE or FALSE. This
+ control is appropriate for the addRequest, modifyRequest, and
+ modDNRequest LDAP messages.
+
+ The corresponding response control is a LDAP Control whose controlType
+ is IANA-ASSIGNED-OID.2 and whose controlValue is a BER-encoded
+ SearchResultEntry. The criticality may be TRUE or FALSE. This
+ control is appropriate for the addResponse, modifyResponse, and
+ modDNResponse LDAP messages with a resultCode of success (0).
+
+ When the request control is attached to an appropriate update LDAP
+ request, the control requests the return of a copy of target entry
+ after the application of the update. The AttributeSelection
+ indicates, as discussed in [Protocol][RFC3673], which attributes are
+ requested to appear in the copy. The server is to return a
+ SearchResultEntry containing, subject to access controls and other
+ constraints, values of the requested attributes.
+
+ The normal processing of the update operation and the processing of
+ this control MUST be performed as one atomic action isolated from
+ other update operations.
+
+ If the update operation fails (in either normal or control
+ processing), no response control is provided.
+
+
+4. Interaction with other controls
+
+ The Pre-Read and Post-Read controls may be combined with each other
+ and/or with a variety of other controls. When combined with the
+ assertion control [Assertion] and/or the manageDsaIT control
+ [RFC3296], the semantics of each control included in the combination
+ apply. The Pre-Read and Post-Read controls may be combined with other
+ controls as detailed in other technical specifications.
+
+
+5. Security Considerations
+
+ The controls defined in this document extend update operations to
+ support read capabilities. Servers MUST ensure that the client is
+ authorized both for reading of the information provided in this
+ control in addition to ensuring the client is authorized to perform
+ the requested directory update.
+
+
+
+Zeilenga LDAP Read Entry Controls [Page 4]
+
+INTERNET-DRAFT draft-zeilenga-ldap-readentry-04 10 February 2005
+
+
+ Security considerations for the update operations [Protocol] extended
+ by this control, as well as general LDAP security considerations
+ [Roadmap], generally apply to implementation and use of this extension
+
+
+6. IANA Considerations
+
+ Registration of the following protocol values [BCP64bis] is requested.
+
+
+6.1. Object Identifier
+
+ It is requested that IANA register an LDAP Object Identifier to
+ identify LDAP protocol elements defined in this document.
+
+ Subject: Request for LDAP Object Identifier Registration
+ Person & email address to contact for further information:
+ Kurt Zeilenga <kurt at OpenLDAP.org>
+ Specification: RFC XXXX
+ Author/Change Controller: IESG
+ Comments:
+ Identifies the LDAP Read Entry Controls
+
+
+6.2. LDAP Protocol Mechanisms
+
+ It is requested that IANA register the LDAP Protocol Mechanism
+ described in this document.
+
+ Subject: Request for LDAP Protocol Mechanism Registration
+ Object Identifier: IANA-ASSIGNED-OID.1
+ Description: LDAP Pre-read Control
+ Person & email address to contact for further information:
+ Kurt Zeilenga <kurt at openldap.org>
+ Usage: Control
+ Specification: RFC XXXX
+ Author/Change Controller: IESG
+ Comments: none
+ in 2
+
+ Subject: Request for LDAP Protocol Mechanism Registration
+ Object Identifier: IANA-ASSIGNED-OID.2
+ Description: LDAP Post-read Control
+ Person & email address to contact for further information:
+ Kurt Zeilenga <kurt at openldap.org>
+ Usage: Control
+ Specification: RFC XXXX
+ Author/Change Controller: IESG
+
+
+
+Zeilenga LDAP Read Entry Controls [Page 5]
+
+INTERNET-DRAFT draft-zeilenga-ldap-readentry-04 10 February 2005
+
+
+ Comments: none
+
+
+7. Acknowledgment
+
+ The LDAP Pre-Read and Post-Read controls are modeled after similar
+ capabilities offered in the DAP [X.511].
+
+
+8. References
+
+ [[Note to the RFC Editor: please replace the citation tags used in
+ referencing Internet-Drafts with tags of the form RFCnnnn where
+ possible.]]
+
+
+8.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14 (also RFC 2119), March 1997.
+
+ [Roadmap] Zeilenga, K. (editor), "LDAP: Technical Specification
+ Road Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in
+ progress.
+
+ [Protocol] Sermersheim, J. (editor), "LDAP: The Protocol",
+ draft-ietf-ldapbis-protocol-xx.txt, a work in progress.
+
+ [Models] Zeilenga, K. (editor), "LDAP: Directory Information
+ Models", draft-ietf-ldapbis-models-xx.txt, a work in
+ progress.
+
+ [RFC3296] Zeilenga, K., "Named Subordinate References in
+ Lightweight Directory Access Protocol (LDAP)
+ Directories", RFC 3296, July 2002.
+
+ [RFC3673] Zeilenga, K., "LDAPv3: All Operational Attributes", RFC
+ 3673, December 2003.
+
+ [Assertion] Zeilenga, K., "LDAP Assertion Control",
+ draft-zeilenga-ldap-assert-xx.txt, a work in progress.
+
+ [X.680] International Telecommunication Union -
+ Telecommunication Standardization Sector, "Abstract
+ Syntax Notation One (ASN.1) - Specification of Basic
+ Notation", X.680(1997) (also ISO/IEC 8824-1:1998).
+
+ [X.690] International Telecommunication Union -
+
+
+
+Zeilenga LDAP Read Entry Controls [Page 6]
+
+INTERNET-DRAFT draft-zeilenga-ldap-readentry-04 10 February 2005
+
+
+ Telecommunication Standardization Sector, "Specification
+ of ASN.1 encoding rules: Basic Encoding Rules (BER),
+ Canonical Encoding Rules (CER), and Distinguished
+ Encoding Rules (DER)", X.690(1997) (also ISO/IEC
+ 8825-1:1998).
+
+
+8.2. Informative References
+
+ [BCP64bis] Zeilenga, K., "IANA Considerations for LDAP",
+ draft-ietf-ldapbis-bcp64-xx.txt, a work in progress.
+
+ [EntryUUID] Zeilenga, K., "The LDAP EntryUUID Operational
+ Attribute", draft-zeilenga-ldap-uuid-xx.txt, a work in
+ progress.
+
+ [X.511] International Telecommunication Union -
+ Telecommunication Standardization Sector, "The
+ Directory: Abstract Service Definition", X.511(1993)
+ (also ISO/IEC 9594-3:1993).
+
+
+10. Author's Address
+
+ Kurt D. Zeilenga
+ OpenLDAP Foundation
+
+ Email: Kurt at OpenLDAP.org
+
+
+
+Intellectual Property Rights
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be found
+ in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this specification
+ can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+
+
+Zeilenga LDAP Read Entry Controls [Page 7]
+
+INTERNET-DRAFT draft-zeilenga-ldap-readentry-04 10 February 2005
+
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr at ietf.org.
+
+
+
+Full Copyright
+
+ Copyright (C) The Internet Society (2005). This document is subject
+ to the rights, licenses and restrictions contained in BCP 78, and
+ except as set forth therein, the authors retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga LDAP Read Entry Controls [Page 8]
+
+
+
Added: openldap/vendor/openldap-release/doc/drafts/draft-zeilenga-ldap-t-f-xx.txt
===================================================================
--- openldap/vendor/openldap-release/doc/drafts/draft-zeilenga-ldap-t-f-xx.txt (rev 0)
+++ openldap/vendor/openldap-release/doc/drafts/draft-zeilenga-ldap-t-f-xx.txt 2007-09-15 10:38:52 UTC (rev 844)
@@ -0,0 +1,340 @@
+
+
+
+
+
+INTERNET-DRAFT Kurt D. Zeilenga
+Intended Category: Standard Track OpenLDAP Foundation
+Expires in six months 10 February 2005
+
+
+
+ LDAP Absolute True and False Filters
+ <draft-zeilenga-ldap-t-f-10.txt>
+
+
+Status of this Memo
+
+ This document is intended to be, after appropriate review and
+ revision, submitted to the RFC Editor as a Standard Track document.
+ Distribution of this memo is unlimited. Technical discussion of this
+ document will take place on the IETF LDAP Extensions mailing list
+ <ldapext at ietf.org>. Please send editorial comments directly to the
+ author <Kurt at OpenLDAP.org>.
+
+ By submitting this Internet-Draft, I accept the provisions of Section
+ 4 of RFC 3667. By submitting this Internet-Draft, I certify that any
+ applicable patent or other IPR claims of which I am aware have been
+ disclosed, or will be disclosed, and any of which I become aware will
+ be disclosed, in accordance with RFC 3668.
+
+ Internet-Drafts are working documents of the Internet Engineering Task
+ Force (IETF), its areas, and its working groups. Note that other
+ groups may also distribute working documents as Internet-Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference material
+ or to cite them other than as "work in progress."
+
+ The list of current Internet-Drafts can be accessed at
+ http://www.ietf.org/1id-abstracts.html
+
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html
+
+
+ Copyright (C) The Internet Society (2005). All Rights Reserved.
+
+ Please see the Full Copyright section near the end of this document
+ for more information.
+
+
+
+
+
+
+Zeilenga LDAP True & False Filters [Page 1]
+
+INTERNET-DRAFT draft-zeilenga-ldap-t-f-10.txt 10 February 2005
+
+
+Abstract
+
+ This document extends the Lightweight Directory Access Protocol (LDAP)
+ to support absolute True and False filters based upon similar
+ capabilities found in X.500 directory systems. The document also
+ extends the String Representation of LDAP Search Filters to support
+ these filters.
+
+
+1. Background
+
+ The X.500 Directory Access Protocol (DAP) [X.511] supports absolute
+ True and False assertions. An 'and' filter with zero elements always
+ evaluates to True. An 'or' filter with zero elements always evaluates
+ to False. These filters are commonly used when requesting DSA-
+ specific Entries (DSEs) which do not necessarily have 'objectClass'
+ attributes. That is, where "(objectClass=*)" may evaluate to False.
+
+ While LDAPv2 [RFC1777][RFC3494] placed no restriction on the number of
+ elements in 'and' and 'or' filter sets, the LDAPv2 string
+ representation [RFC1960][RFC3494] could not represent empty 'and' and
+ 'or' filter sets. Due to this, absolute True or False filters were
+ (unfortunately) eliminated from LDAPv3 [Roadmap].
+
+ This documents extends LDAPv3 to support absolute True and False
+ assertions by allowing empty 'and' and 'or' in Search filters
+ [Protocol] and extends the filter string representation [Filters] to
+ allow empty filter lists.
+
+ It is noted that certain search operations, such as those used to
+ retrieve subschema information [Models], require use of particular
+ filters. This document does not change these requirements.
+
+ This feature is intended to allow a more direct mapping between DAP
+ and LDAP (as needed to implement DAP-to-LDAP gateways).
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in BCP 14 [RFC2119].
+
+
+2. Absolute True and False Filters
+
+ Implementations of this extension SHALL allow 'and' and 'or' choices
+ with zero filter elements.
+
+ An 'and' filter consisting of an empty set of filters SHALL evaluate
+ to True. This filter is represented by the string "(&)".
+
+
+
+Zeilenga LDAP True & False Filters [Page 2]
+
+INTERNET-DRAFT draft-zeilenga-ldap-t-f-10.txt 10 February 2005
+
+
+ An 'or' filter consisting of an empty set of filters SHALL evaluate to
+ False. This filter is represented by the string "(|)".
+
+ Servers supporting this feature SHOULD publish the Object Identifier
+ 1.3.6.1.4.1.4203.1.5.3 as a value of the 'supportedFeatures' [RFC3674]
+ attribute in the root DSE.
+
+ Clients supporting this feature SHOULD NOT use the feature unless they
+ have knowledge the server supports it.
+
+
+3. Security Considerations
+
+ The (re)introduction of absolute True and False filters is not
+ believed to raise any new security considerations.
+
+ Implementors of this (or any) LDAPv3 extension should be familiar with
+ general LDAPv3 security considerations [Roadmap].
+
+
+4. IANA Considerations
+
+ Registration of this feature is requested [BCP64bis].
+
+ Subject: Request for LDAP Protocol Mechanism Registration
+ Object Identifier: 1.3.6.1.4.1.4203.1.5.3
+ Description: True/False filters
+ Person & email address to contact for further information:
+ Kurt Zeilenga <kurt at openldap.org>
+ Usage: Feature
+ Specification: RFC XXXX
+ Author/Change Controller: IESG
+ Comments: none
+
+ This OID was assigned [ASSIGN] by OpenLDAP Foundation, under its
+ IANA-assigned private enterprise allocation [PRIVATE], for use in this
+ specification.
+
+
+5. Author's Address
+
+ Kurt D. Zeilenga
+ OpenLDAP Foundation
+ <Kurt at OpenLDAP.org>
+
+
+6. References
+
+
+
+
+Zeilenga LDAP True & False Filters [Page 3]
+
+INTERNET-DRAFT draft-zeilenga-ldap-t-f-10.txt 10 February 2005
+
+
+ [[Note to the RFC Editor: please replace the citation tags used in
+ referencing Internet-Drafts with tags of the form RFCnnnn where
+ possible.]]
+
+
+6.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14 (also RFC 2119), March 1997.
+
+ [Roadmap] Zeilenga, K. (editor), "LDAP: Technical Specification
+ Road Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in
+ progress.
+
+ [Protocol] Sermersheim, J. (editor), "LDAP: The Protocol",
+ draft-ietf-ldapbis-protocol-xx.txt, a work in progress.
+
+ [Models] Zeilenga, K. (editor), "LDAP: Directory Information
+ Models", draft-ietf-ldapbis-models-xx.txt, a work in
+ progress.
+
+ [Filters] Smith, M. (editor), LDAPbis WG, "LDAP: String
+ Representation of Search Filters",
+ draft-ietf-ldapbis-filter-xx.txt, a work in progress.
+
+ [Features] Zeilenga, K., "Feature Discovery in LDAP", RFC 3674,
+ December 2003.
+
+
+6.2. Informative References
+
+ [RFC1777] Yeong, W., Howes, T., and S. Kille, "Lightweight
+ Directory Access Protocol", RFC 1777, March 1995.
+
+ [RFC1960] Howes, T., "A String Representation of LDAP Search
+ Filters", RFC 1960, June 1996.
+
+ [BCP64bis] Zeilenga, K., "IANA Considerations for LDAP",
+ draft-ietf-ldapbis-bcp64-xx.txt, a work in progress.
+
+ [RFC3494] Zeilenga, K., "Lightweight Directory Access Protocol
+ version 2 (LDAPv2) to Historic Status", RFC 3494, March
+ 2003.
+
+ [X.500] International Telecommunication Union -
+ Telecommunication Standardization Sector, "The Directory
+ -- Overview of concepts, models and services,"
+ X.500(1993) (also ISO/IEC 9594-1:1994).
+
+
+
+Zeilenga LDAP True & False Filters [Page 4]
+
+INTERNET-DRAFT draft-zeilenga-ldap-t-f-10.txt 10 February 2005
+
+
+ [X.501] International Telecommunication Union -
+ Telecommunication Standardization Sector, "The Directory
+ -- Models," X.501(1993) (also ISO/IEC 9594-2:1994).
+
+ [X.511] International Telecommunication Union -
+ Telecommunication Standardization Sector, "The
+ Directory: Abstract Service Definition", X.511(1993)
+ (also ISO/IEC 9594-3:1993).
+
+ [ASSIGN] OpenLDAP Foundation, "OpenLDAP OID Delegations",
+ http://www.openldap.org/foundation/oid-delegate.txt.
+
+ [PRIVATE] IANA, "Private Enterprise Numbers",
+ http://www.iana.org/assignments/enterprise-numbers.
+
+
+
+Intellectual Property Rights
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be found
+ in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this specification
+ can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr at ietf.org.
+
+
+
+Full Copyright
+
+ Copyright (C) The Internet Society (2005). This document is subject
+ to the rights, licenses and restrictions contained in BCP 78, and
+ except as set forth therein, the authors retain all their rights.
+
+
+
+Zeilenga LDAP True & False Filters [Page 5]
+
+INTERNET-DRAFT draft-zeilenga-ldap-t-f-10.txt 10 February 2005
+
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga LDAP True & False Filters [Page 6]
+
+
+
Added: openldap/vendor/openldap-release/doc/drafts/draft-zeilenga-ldap-turn-xx.txt
===================================================================
--- openldap/vendor/openldap-release/doc/drafts/draft-zeilenga-ldap-turn-xx.txt (rev 0)
+++ openldap/vendor/openldap-release/doc/drafts/draft-zeilenga-ldap-turn-xx.txt 2007-09-15 10:38:52 UTC (rev 844)
@@ -0,0 +1,507 @@
+
+
+
+
+
+
+INTERNET-DRAFT Kurt D. Zeilenga
+Intended Category: Experimental OpenLDAP Foundation
+Expires in six months 28 October 2005
+
+
+
+ LDAP Turn Operation
+ <draft-zeilenga-ldap-turn-03.txt>
+
+
+1. Status of this Memo
+
+ This document is intended to be, after appropriate review and
+ revision, submitted to the RFC Editor for publication as an
+ Experimental document. Distribution of this memo is unlimited.
+ Technical discussion of this document will take place on the IETF LDAP
+ Extensions mailing list <ldapext at ietf.org>. Please send editorial
+ comments directly to the author <Kurt at OpenLDAP.org>.
+
+ By submitting this Internet-Draft, each author represents that any
+ applicable patent or other IPR claims of which he or she is aware have
+ been or will be disclosed, and any of which he or she becomes aware
+ will be disclosed, in accordance with Section 6 of BCP 79.
+
+ Internet-Drafts are working documents of the Internet Engineering Task
+ Force (IETF), its areas, and its working groups. Note that other
+ groups may also distribute working documents as Internet-Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference material
+ or to cite them other than as "work in progress."
+
+ The list of current Internet-Drafts can be accessed at
+ http://www.ietf.org/1id-abstracts.html
+
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html
+
+
+ Copyright (C) The Internet Society (2005). All Rights Reserved.
+
+ Please see the Full Copyright section near the end of this document
+ for more information.
+
+
+Abstract
+
+
+
+
+Zeilenga LDAP Turn Op [Page 1]
+
+INTERNET-DRAFT draft-zeilenga-ldap-turn-03 28 October 2005
+
+
+ This specification describes a Lightweight Directory Access Protocol
+ (LDAP) extended operation to reverse (or "turn") the roles of client
+ and server for subsequent protocol exchanges in the session, or to
+ enable each peer to act as both client and server with respect to the
+ other.
+
+
+1. Background and Intent of Use
+
+ The Lightweight Directory Access Protocol (LDAP) [Roadmap][Protocol]
+ is a client-server protocol which typically operates over reliable
+ octet-stream transports such as the Transport Control Protocol (TCP).
+ Generally, the client initiates the stream by connecting to the
+ server's listener at some well-known address.
+
+ There are cases where it is desirable for the server to initiate the
+ stream. While it certainly is possible to write a technical
+ specification detailing how to implement server-initiated LDAP
+ sessions, this would require the design of new authentication and
+ other security mechanisms to support server-initiated LDAP sessions.
+
+ Instead, this document introduces an operation, the Turn operation,
+ which may be used to reverse the client-servers roles of the protocol
+ peers. This allows the initiating protocol peer to become server
+ (after the reversal).
+
+ As an additional feature, the Turn operation may be used to allow both
+ peers to act in both roles. This is useful where both peers are
+ directory servers that desire to request, as LDAP clients, operations
+ be performed by the other. This may be useful in replicated and/or
+ distributed environments.
+
+ This operation is intended to be used between protocol peers which
+ have established a mutual agreement, by means outside of the protocol,
+ which requires reversal of client-server roles, or allows both peers
+ to act both as client and server.
+
+
+1.1 Terminology
+
+ Protocol elements are described using ASN.1 [X.680] with implicit
+ tags. The term "BER-encoded" means the element is to be encoded using
+ the Basic Encoding Rules [X.690] under the restrictions detailed in
+ Section 5.2 of [Protocol].
+
+
+2. Turn Operation
+
+
+
+
+Zeilenga LDAP Turn Op [Page 2]
+
+INTERNET-DRAFT draft-zeilenga-ldap-turn-03 28 October 2005
+
+
+ The Turn operation is defined as a LDAP Extended Operation [Protocol,
+ Section 4.12] identified by the IANA-ASSIGNED-OID. The function of
+ the Turn Operation is to request that the client-server roles be
+ reversed, or, optionally to request that both protocol peers to be
+ able to act both as client and server in respect to the other.
+
+
+2.1. Turn Request
+
+ The Turn request is an ExtendedRequest with the requestName field
+ containing the IANA-ASSIGNED-OID and a requestValue field is a
+ BER-encoded turnValue:
+
+ turnValue ::= SEQUENCE {
+ mutual BOOLEAN DEFAULT FALSE,
+ identifier LDAPString
+ }
+
+ A TRUE mutual field value indicates a request to allow both peers to
+ act both as client and server. A FALSE mutual field value indicates a
+ request to reserve the client and server roles.
+
+ The value of the identifier field is a locally-defined policy
+ identifier (typically associated with a mutual agreement for which
+ this turn is be executed as part of).
+
+
+2.2. Turn Response
+
+ A Turn response is an ExtendedResponse where the responseName and
+ responseValue fields are absent. A resultCode of success is returned
+ if and only if the responder is willing and able to turn the session
+ as requested. Otherwise, a different resultCode is returned.
+
+
+3. Authentication
+
+ This extension's authentication model assumes separate authentication
+ of the peers in each of their roles. A separate Bind exchange is
+ expected between the peers in their new roles to establish identities
+ in these roles.
+
+ Upon completion of the Turn, the responding peer in its new client
+ role has an anonymous association at the initiating peer in its new
+ server role. If the turn was mutual, the authentication association
+ of the initiating peer in its pre-existing client role is left intact
+ at the responding peer in its pre-existing server role. If the turn
+ was not mutual, this association is void.
+
+
+
+Zeilenga LDAP Turn Op [Page 3]
+
+INTERNET-DRAFT draft-zeilenga-ldap-turn-03 28 October 2005
+
+
+ The responding peer may establish its identity in its client role by
+ requesting and successfully completing a Bind operation.
+
+ The remainder of this section discuss some authentication scenarios.
+ In the protocol exchange illustrations, A refers to the initiating
+ peer (the original client) and B refers to the responding peer (the
+ original server).
+
+3.1. Use with TLS and Simple Authentication
+
+ A->B: StartTLS Request
+ B->A: StartTLS(success) Response
+ A->B: Bind(Simple(cn=B,dc=example,dc=net,B's secret)) Request
+ B->A: Bind(success) Response
+ A->B: Turn(TRUE,"XXYYZ") Request
+ B->A: Turn(success) Response
+ A->B: Bind(Simple(DN/Password)) Request
+ B->A: Bind(Simple(cn=A,dc=example,dc=net,A's secret)) Request
+ A->B: Bind(success) Response
+
+ In this scenario, TLS (Transport Layer Security) [TLS] is started and
+ the initiating peer (the original client) establishes its identity
+ with the responding peer prior to the Turn using the the DN/password
+ mechanism of the Simple method of the Bind operation. After the turn,
+ the responding peer in its new client role establishes its identity
+ with the initiating peer in its new server role.
+
+
+3.2. Use with TLS and SASL EXTERNAL
+
+ A->B: StartTLS Request
+ B->A: StartTLS(success) Response
+ A->B: Bind(SASL(EXTERNAL)) Request
+ B->A: Bind(success) Response
+ A->B: Turn(TRUE,"XXYYZ") Request
+ B->A: Turn(success) Response
+ B->A: Bind(SASL(EXTERNAL)) Request
+ A->B: Bind(success) Response
+
+ In this scenario, TLS is started prior with each peer providing a
+ valid certificate and the initiating peer (the original client)
+ establishes its identity through the use of the EXTERNAL mechanism of
+ the SASL (Simple Authentication and Security Layer) [SASL] method of
+ the Bind operation prior to the Turn. After the turn, the responding
+ peer in its new client role establishes its identity with the
+ initiating peer in its new server role.
+
+
+
+
+
+Zeilenga LDAP Turn Op [Page 4]
+
+INTERNET-DRAFT draft-zeilenga-ldap-turn-03 28 October 2005
+
+
+3.3. Use of mutual authentication and SASL EXTERNAL
+
+ A number of SASL mechanisms, such as GSSAPI [GSSAPI] and DIGEST-MD5
+ [DIGEST-MD5], support mutual authentication. The initiating peer, it
+ its new server role, may use the identity of the responding peer
+ established by a prior authentication exchange, as its source for
+ "external" identity in subsequent EXTERNAL exchange.
+
+ A->B: Bind(SASL(GSSAPI)) Request
+ <intermediate messages>
+ B->A: Bind(success) Response
+ A->B: Turn(TRUE,"XXYYZ") Request
+ B->A: Turn(success) Response
+ B->A: Bind(SASL(EXTERNAL)) Request
+ A->B: Bind(success) Response
+
+ In this scenario, a GSSAPI mutual-authentication exchange is completed
+ between the initiating peer (the original client) and the the
+ responding server (the original server) prior to the turn. After the
+ turn, the responding peer in its new client role requests the
+ initiating peer utilize an "external" identity to establish its LDAP
+ authorization identity.
+
+
+4. TLS and SASL security layers
+
+ As described in [Protocol], LDAP supports both Transport Layer
+ Security (TLS) [TLS] and Simple Authentication and Security Layer
+ (SASL) [SASL] security frameworks. The following table illustrates
+ the relationship between the LDAP message layer, SASL layer, TLS
+ layer, and transport connection within an LDAP session.
+
+ +----------------------+
+ | LDAP message layer |
+ +----------------------+ > LDAP PDUs
+ +----------------------+ < data
+ | SASL layer |
+ +----------------------+ > SASL-protected data
+ +----------------------+ < data
+ | TLS layer |
+ Application +----------------------+ > TLS-protected data
+ ------------+----------------------+ < data
+ Transport | transport connection |
+ +----------------------+
+
+ This extension does not alter this relationship, nor does it remove
+ the general restriction against multiple TLS layers, nor does it
+ remove the general restriction against multiple SASL layers.
+
+
+
+Zeilenga LDAP Turn Op [Page 5]
+
+INTERNET-DRAFT draft-zeilenga-ldap-turn-03 28 October 2005
+
+
+ As specified in [Protocol], the StartTLS operation is used to initiate
+ negotiation of a TLS layer. If a TLS is already installed, the
+ StartTLS operation must fail. Upon establishment of the TLS layer,
+ regardless of which peer issued the request to start TLS, the peer
+ which initiated the LDAP session (the original client) performs the
+ "server identity check" as described in Section 3.1.5 of [AuthMeth]
+ treating itself as the "client" and its peer as the "server".
+
+ As specified in [SASL], newly negotiated SASL security layer replace
+ the installed SASL security layer. Though the client/server roles in
+ LDAP, and hence SASL, may be reversed in subsequent exchanges, only
+ one SASL security layer may be installed at any instance.
+
+
+5. Security Considerations
+
+ Implementors should be aware that the reversing of client/server roles
+ and/or allowing both peers to act as client and server likely
+ introduces security considerations not foreseen by the authors of this
+ document. In particular, the security implications of the design
+ choices made in the authentication and data security models for this
+ extension (discussed in sections 3 and 4, respectively) are not fully
+ studied. It is hoped that experimentation with this extension will
+ lead to better understanding of the security implications of these
+ models and other aspects of this extension, and that appropriate
+ considerations will be documented in a future document. The following
+ security considerations are apparent at this time.
+
+ Implementors should take special care to process LDAP, SASL, TLS, and
+ other events the appropriate roles for the peers. It is noted that
+ while the Turn reverses the client/server roles with LDAP, and in SASL
+ authentication exchanges, it does not reverse the roles within the TLS
+ layer or the transport connection.
+
+ The responding server (the original server) should restrict use of
+ this operation to authorized clients. Client knowledge of a valid
+ identifier should not be the sole factor in determining authorization
+ to turn.
+
+ Where the peers except to establish TLS, TLS should be started prior
+ to the Turn and any request to authenticate via the Bind operation.
+
+ LDAP security considerations [Protocol][AuthMeth] generally apply to
+ this extension.
+
+
+6. IANA Considerations
+
+
+
+
+Zeilenga LDAP Turn Op [Page 6]
+
+INTERNET-DRAFT draft-zeilenga-ldap-turn-03 28 October 2005
+
+
+ Registration of the following values [BCP64bis] is requested.
+
+
+6.1. Object Identifier
+
+ It is requested that IANA assign an LDAP Object Identifier to identify
+ the LDAP Turn Operation as defined in this document.
+
+ Subject: Request for LDAP Object Identifier Registration
+ Person & email address to contact for further information:
+ Kurt Zeilenga <kurt at OpenLDAP.org>
+ Specification: RFC XXXX
+ Author/Change Controller: Author
+ Comments:
+ Identifies the LDAP Turn Operation
+
+
+6.2. LDAP Protocol Mechanism
+
+ It is requested that IANA register the LDAP Protocol Mechanism
+ described in this document.
+
+ Subject: Request for LDAP Protocol Mechanism Registration
+ Object Identifier: IANA-ASSIGNED-OID
+ Description: LDAP Turn Operation
+ Person & email address to contact for further information:
+ Kurt Zeilenga <kurt at openldap.org>
+ Usage: Extended Operation
+ Specification: RFC XXXX
+ Author/Change Controller: Author
+ Comments: none
+
+
+7. Author's Address
+
+ Kurt D. Zeilenga
+ OpenLDAP Foundation
+
+ Email: Kurt at OpenLDAP.org
+
+
+8. References
+
+ [[Note to the RFC Editor: please replace the citation tags used in
+ referencing Internet-Drafts with tags of the form RFCnnnn where
+ possible.]]
+
+
+
+
+
+Zeilenga LDAP Turn Op [Page 7]
+
+INTERNET-DRAFT draft-zeilenga-ldap-turn-03 28 October 2005
+
+
+8.1. Normative References
+
+ [Roadmap] Zeilenga, K. (editor), "LDAP: Technical Specification
+ Road Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in
+ progress.
+
+ [Protocol] Sermersheim, J. (editor), "LDAP: The Protocol",
+ draft-ietf-ldapbis-protocol-xx.txt, a work in progress.
+
+ [AuthMeth] Harrison, R. (editor), "LDAP: Authentication Methods and
+ Connection Level Security Mechanisms",
+ draft-ietf-ldapbis-authmeth-xx.txt, a work in progress.
+
+ [SASL] Melnikov, A. (Editor), "Simple Authentication and
+ Security Layer (SASL)",
+ draft-ietf-sasl-rfc2222bis-xx.txt, a work in progress.
+
+ [TLS] Dierks, T. and, E. Rescorla, "The TLS Protocol Version
+ 1.1", draft-ietf-tls-rfc2246-bis-xx.txt, a work in
+ progress.
+
+ [X.680] International Telecommunication Union -
+ Telecommunication Standardization Sector, "Abstract
+ Syntax Notation One (ASN.1) - Specification of Basic
+ Notation", X.680(2002) (also ISO/IEC 8824-1:2002).
+
+ [X.690] International Telecommunication Union -
+ Telecommunication Standardization Sector, "Specification
+ of ASN.1 encoding rules: Basic Encoding Rules (BER),
+ Canonical Encoding Rules (CER), and Distinguished
+ Encoding Rules (DER)", X.690(2002) (also ISO/IEC
+ 8825-1:2002).
+
+
+8.2. Informative References
+
+ [BCP64bis] Zeilenga, K., "IANA Considerations for LDAP",
+ draft-ietf-ldapbis-bcp64-xx.txt, a work in progress.
+
+ [GSSAPI] Linn, J., "Generic Security Service
+ Application Program Interface, Version 2, Update 1", RFC
+ 2743, January 2000.
+
+ [DIGEST-MD5] Leach, P., C. Newman, and A. Melnikov, "Using Digest
+ Authentication as a SASL Mechanism",
+ draft-ietf-sasl-rfc2831bis-xx.txt, a work in progress.
+
+
+
+
+
+Zeilenga LDAP Turn Op [Page 8]
+
+INTERNET-DRAFT draft-zeilenga-ldap-turn-03 28 October 2005
+
+
+Intellectual Property Rights
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be found
+ in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this specification
+ can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr at ietf.org.
+
+
+
+Full Copyright
+
+ Copyright (C) The Internet Society (2005).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+
+
+
+
+
+
+
+Zeilenga LDAP Turn Op [Page 9]
+
Added: openldap/vendor/openldap-release/doc/drafts/draft-zeilenga-ldap-txn-xx.txt
===================================================================
--- openldap/vendor/openldap-release/doc/drafts/draft-zeilenga-ldap-txn-xx.txt (rev 0)
+++ openldap/vendor/openldap-release/doc/drafts/draft-zeilenga-ldap-txn-xx.txt 2007-09-15 10:38:52 UTC (rev 844)
@@ -0,0 +1,507 @@
+
+
+
+
+
+
+INTERNET-DRAFT Kurt D. Zeilenga
+Intended Category: Standard Track OpenLDAP Foundation
+Expires in six months 5 March 2006
+
+
+ LDAP Transactions
+ <draft-zeilenga-ldap-txn-07.txt>
+
+
+Status of Memo
+
+ This document is intended to be, after appropriate review and
+ revision, submitted to the IESG for consideration as a Proposed
+ Standard. Distribution of this memo is unlimited. Technical
+ discussion of this document will take place on the IETF LDAP
+ Extensions mailing list <ldapext at ietf.org>. Please send editorial
+ comments directly to the author <Kurt at OpenLDAP.org>.
+
+ By submitting this Internet-Draft, each author represents that any
+ applicable patent or other IPR claims of which he or she is aware have
+ been or will be disclosed, and any of which he or she becomes aware
+ will be disclosed, in accordance with Section 6 of BCP 79.
+
+ Internet-Drafts are working documents of the Internet Engineering Task
+ Force (IETF), its areas, and its working groups. Note that other
+ groups may also distribute working documents as Internet-Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference material
+ or to cite them other than as "work in progress."
+
+ The list of current Internet-Drafts can be accessed at
+ http://www.ietf.org/1id-abstracts.html
+
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html
+
+
+ Copyright (C) The Internet Society (2006). All Rights Reserved.
+
+ Please see the Full Copyright section near the end of this document
+ for more information.
+
+
+Abstract
+
+ Lightweight Directory Access Protocol (LDAP) update operations, such
+
+
+
+Zeilenga LDAP Transactions [Page 1]
+
+INTERNET-DRAFT draft-zeilenga-ldap-txn-07 5 March 2006
+
+
+ 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.
+
+
+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.
+
+ 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
+ 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.
+
+
+1.1. Conventions and 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].
+
+ Protocol elements are described using ASN.1 [X.680] with implicit
+ tags. The term "BER-encoded" means the element is to be encoded using
+ the Basic Encoding Rules [X.690] under the restrictions detailed in
+ Section 5.2 of [Protocol].
+
+ DSA stands for "Directory System Agent" (a server). DSE stands for
+ "DSA-specific entry".
+
+
+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
+
+
+ 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.
+
+
+2.2. Transaction Specification Control
+
+ 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
+ for update requests including Add, Delete, Modify, and ModifyDN
+ requests [Protocol].
+
+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.
+
+ settlementValue ::= SEQUENCE {
+ commit BOOLEAN DEFAULT TRUE,
+ identifier OCTET STRING }
+
+ A commit value of TRUE indicates a request to commit the transaction
+ identified by the identifier. A commit value of FALSE indicates a
+ request to abort the identified transaction.
+
+ 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.
+
+
+2.5. Aborted Transaction Notice
+
+ The Aborted Transaction Notice is an Unsolicited Notification message
+ where the responseName is IANA-ASSIGNED-OID.4 and responseValue is
+ present and contains a transaction identifier.
+
+
+3. An LDAP Transaction
+
+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.
+
+ A server MAY choose to advertise this extension only when the client
+ is authorized to use it.
+
+
+3.2. Starting an Transactions
+
+ A client wishing to preform 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
+ 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.
+
+
+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.
+
+ If the server becomes unwilling or unable to continue the
+ specification of a transaction, the server issues an Aborted
+ Transaction Notice with a non-success resultCode indicating the nature
+ of the failure. All operations that were to be processed as part of
+ the transaction are implicitly abandoned. Upon receipt of an Aborted
+ Transaction Notice, the client is to discontinue all use of the
+ transaction identifier as the transaction is null and void. Any
+ future use of identifier by the client will result in a response
+ 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
+ Transaction request for the transaction indicating whether it desires
+ the transaction to be committed or aborted.
+
+ 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.
+
+ 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.
+
+ There is no requirement that a server serialize transactions, or
+ updates requested outside of a transaction. That is, a server MAY
+ process multiple commit requests (from one or more clients) acting
+ upon different sets of entries concurrently. A server MUST avoid
+ deadlock.
+
+
+4. Distributed Directory Considerations
+
+ The LDAP/X.500 models provide for distributed directory operations
+ including server-side chaining and client-side chasing of operations.
+
+ This document does not preclude servers from chaining operations which
+ are part of a transaction. However, if a server does allow such
+ chaining, it MUST ensure that transaction semantics are provided.
+
+ This mechanism defined by this document does not support client-side
+ chasing. Grouping cookies used to identify the transaction are
+ 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
+
+
+
+Zeilenga LDAP Transactions [Page 5]
+
+INTERNET-DRAFT draft-zeilenga-ldap-txn-07 5 March 2006
+
+
+ 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.
+
+
+5. Security Considerations
+
+ 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.
+
+
+6. IANA Considerations
+
+ In accordance with [BCP64bis], it is requested that Internet Assigned
+ Numbers Authority (IANA) make the following assignments.
+
+
+6.1. Object Identifier
+
+ Assignment of an LDAP Object Identifier 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 at OpenLDAP.org>
+ Specification: RFC XXXX
+ Author/Change Controller: IESG
+ Comments: Identifies protocol elements for LDAP Transactions
+
+
+6.2. LDAP Protocol Mechanism
+
+ Registration of the protocol mechanisms 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:
+
+
+
+Zeilenga LDAP Transactions [Page 6]
+
+INTERNET-DRAFT draft-zeilenga-ldap-txn-07 5 March 2006
+
+
+ Kurt Zeilenga <kurt at openldap.org>
+ 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
+ IANA-ASSIGNED-OID.3 E End Transaction Extended Request
+
+
+7. Acknowledgments
+
+ The author gratefully acknowledges the contributions made by members
+ of the Internet Engineering Task Force.
+
+
+8. Author's Address
+
+ Kurt D. Zeilenga
+ OpenLDAP Foundation
+
+ Email: Kurt at OpenLDAP.org
+
+
+9. References
+
+ [[Note to the RFC Editor: please replace the citation tags used in
+ referencing Internet-Drafts with tags of the form RFCnnnn where
+ possible.]]
+
+
+9.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14 (also RFC 2119), March 1997.
+
+ [Roadmap] Zeilenga, K. (editor), "LDAP: Technical Specification
+ Road Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in
+ progress.
+
+ [Protocol] Sermersheim, J. (editor), "LDAP: The Protocol",
+ draft-ietf-ldapbis-protocol-xx.txt, a work in progress.
+
+ [Models] Zeilenga, K. (editor), "LDAP: Directory Information
+ Models", draft-ietf-ldapbis-models-xx.txt, a work in
+ progress.
+
+
+
+Zeilenga LDAP Transactions [Page 7]
+
+INTERNET-DRAFT draft-zeilenga-ldap-txn-07 5 March 2006
+
+
+ [X.680] International Telecommunication Union -
+ Telecommunication Standardization Sector, "Abstract
+ Syntax Notation One (ASN.1) - Specification of Basic
+ Notation", X.680(2002) (also ISO/IEC 8824-1:2002).
+
+ [X.690] International Telecommunication Union -
+ Telecommunication Standardization Sector, "Specification
+ of ASN.1 encoding rules: Basic Encoding Rules (BER),
+ Canonical Encoding Rules (CER), and Distinguished
+ Encoding Rules (DER)", X.690(2002) (also ISO/IEC
+ 8825-1:2002).
+
+
+9.2. Informative References
+
+ [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.
+
+ [X.500] International Telecommunication Union -
+ Telecommunication Standardization Sector, "The Directory
+ -- Overview of concepts, models and services,"
+ X.500(1993) (also ISO/IEC 9594-1:1994).
+
+ [X.501] International Telecommunication Union -
+ Telecommunication Standardization Sector, "The Directory
+ -- Models," X.501(1993) (also ISO/IEC 9594-2:1994).
+
+
+
+Intellectual Property Rights
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be found
+ in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this specification
+ can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+
+
+Zeilenga LDAP 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
+ this standard. Please address the information to the IETF at
+ ietf-ipr at ietf.org.
+
+
+
+Full Copyright
+
+ Copyright (C) The Internet Society (2006).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga LDAP Transactions [Page 9]
+
Added: openldap/vendor/openldap-release/doc/drafts/draft-zeilenga-ldap-uuid-xx.txt
===================================================================
--- openldap/vendor/openldap-release/doc/drafts/draft-zeilenga-ldap-uuid-xx.txt (rev 0)
+++ openldap/vendor/openldap-release/doc/drafts/draft-zeilenga-ldap-uuid-xx.txt 2007-09-15 10:38:52 UTC (rev 844)
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+INTERNET-DRAFT Kurt D. Zeilenga
+Intended Category: Standard Track OpenLDAP Foundation
+Expires in six months 18 July 2005
+
+
+
+ The LDAP entryUUID operational attribute
+ <draft-zeilenga-ldap-uuid-06.txt>
+
+
+
+Status of this Memo
+
+ This document is intended to be, after appropriate review and
+ revision, submitted to the RFC Editor as an Standard Track document.
+ Distribution of this memo is unlimited. Technical discussion of this
+ document will take place on the IETF LDAP Extensions mailing list
+ <ldapext at ietf.org>. Please send editorial comments directly to the
+ author <Kurt at OpenLDAP.org>.
+
+ By submitting this Internet-Draft, each author represents that any
+ applicable patent or other IPR claims of which he or she is aware have
+ been or will be disclosed, and any of which he or she becomes aware
+ will be disclosed, in accordance with Section 6 of BCP 79.
+
+ Internet-Drafts are working documents of the Internet Engineering Task
+ Force (IETF), its areas, and its working groups. Note that other
+ groups may also distribute working documents as Internet-Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference material
+ or to cite them other than as "work in progress."
+
+ The list of current Internet-Drafts can be accessed at
+ http://www.ietf.org/1id-abstracts.html
+
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html
+
+
+ Copyright (C) The Internet Society (2005). All Rights Reserved.
+
+ Please see the Full Copyright section near the end of this document
+ for more information.
+
+
+Abstract
+
+
+
+Zeilenga draft-zeilenga-ldap-uuid-06 [Page 1]
+
+INTERNET-DRAFT LDAP entryUUID 18 July 2005
+
+
+ This document describes the LDAP/X.500 'entryUUID' operational
+ attribute and associated matching rules and syntax. The attribute
+ holds a server-assigned Universally Unique Identifier (UUID) for the
+ object. Directory clients may use this attribute to distinguish
+ objects identified by a distinguished name or to locate an object
+ after renaming.
+
+
+1. Background and Intended Use
+
+ In X.500 Directory Services [X.501], such as those accessible using
+ the Lightweight Directory Access Protocol (LDAP) [Roadmap], an object
+ is identified by its distinguished name (DN). However, DNs are not
+ stable identifiers. That is, a new object may be identified by a DN
+ which previously identified another (now renamed or deleted) object.
+
+ A Universally Unique Identifier (UUID) is "an identifier unique across
+ both space and time, with respect to the space of all UUIDs"
+ [UUIDURN]. UUIDs are used in a wide range of systems.
+
+ This document describes the 'entryUUID' operational attribute which
+ holds the UUID assigned to the object by the server. Clients may use
+ this attribute to distinguish objects identified by a particular
+ distinguished name or to locate a particular object after renaming.
+
+ This document defines the UUID syntax, the 'uuidMatch' and
+ 'uuidOrderingMatch' matching rules, and the 'entryUUID' attribute
+ type.
+
+ Schema definitions are provided using LDAP description formats
+ [Models]. Definitions provided here are formatted (line wrapped) for
+ readability.
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in BCP 14 [RFC2119].
+
+
+2. UUID Schema Elements
+
+2.1 UUID Syntax
+
+ A Universally Unique Identifier (UUID) [UUIDURN] is a 16-octet
+ (128-bit) value which identifies an object. The ASN.1 [X.680] type
+ UUID is defined to represent UUIDs as follows:
+
+ UUID ::= OCTET STRING (SIZE(16))
+ -- constrained to an UUID [UUIDURN]
+
+
+
+Zeilenga draft-zeilenga-ldap-uuid-06 [Page 2]
+
+INTERNET-DRAFT LDAP entryUUID 18 July 2005
+
+
+ In LDAP, UUID values are encoded using the [ASCII] character string
+ representation described in [UUIDURN]. For example,
+ "597ae2f6-16a6-1027-98f4-d28b5365dc14".
+
+ The following is a LDAP syntax description suitable for publication in
+ subschema subentries.
+
+ ( IANA-ASSIGNED-OID.1 DESC 'UUID' )
+
+
+2.2 'uuidMatch' Matching Rule
+
+ The 'uuidMatch' matching rule compares an asserted UUID with a stored
+ UUID for equality. Its semantics are same as the 'octetStringMatch'
+ [X.520][Syntaxes] matching rule. The rule differs from
+ 'octetStringMatch' in that the assertion value is encoded using the
+ UUID string representation instead of the normal OCTET STRING string
+ representation.
+
+ The following is a LDAP matching rule description suitable for
+ publication in subschema subentries.
+
+ ( IANA-ASSIGNED-OID.2 NAME 'uuidMatch'
+ SYNTAX IANA-ASSIGNED-OID.1 )
+
+
+2.3 'uuidOrderingMatch' Matching Rule
+
+ The 'uuidOrderingMatch' matching rule compares an asserted UUID
+ with a stored UUID for ordering. Its semantics are the same as the
+ 'octetStringOrderingMatch' [X.520][Syntaxes] matching rule. The
+ rule differs from 'octetStringOrderingMatch' in that the assertion
+ value is encoded using the UUID string representation instead of
+ the normal OCTET STRING string representation.
+
+ The following is a LDAP matching rule description suitable for
+ publication in subschema subentries.
+
+ ( IANA-ASSIGNED-OID.3 NAME 'uuidOrderingMatch'
+ SYNTAX IANA-ASSIGNED-OID.1 )
+
+ It is noted that not all UUID variants have a defined ordering and,
+ even where so, servers are not obligated to assign UUIDs in any
+ particular order. This matching rule is provided for completeness.
+
+
+2.4. 'entryUUID' attribute
+
+
+
+
+Zeilenga draft-zeilenga-ldap-uuid-06 [Page 3]
+
+INTERNET-DRAFT LDAP entryUUID 18 July 2005
+
+
+ The 'entryUUID' operational attribute provides the Universally Unique
+ Identifier (UUID) assigned to the entry.
+
+ The following is a LDAP attribute type description suitable for
+ publication in subschema subentries.
+
+ ( IANA-ASSIGNED-OID.4 NAME 'entryUUID'
+ DESC 'UUID of the entry'
+ EQUALITY uuidMatch
+ ORDERING uuidOrderingMatch
+ SYNTAX IANA-ASSIGNED-OID.1
+ SINGLE-VALUE
+ NO-USER-MODIFICATION
+ USAGE directoryOperation )
+
+ Servers SHALL generate and assign a new UUID to each entry upon its
+ addition to the directory and provide that UUID as the value of the
+ 'entryUUID' operational attribute. An entry's UUID is immutable.
+
+ UUID are to be generated in accordance with Section 4 of [UUIDURN].
+ In particular, servers MUST ensure that each generated UUID is unique
+ in space and time.
+
+
+3. Security Considerations
+
+ An entry's relative distinguish name (RDN) is composed from attribute
+ values of the entry, values which are commonly descriptive of the
+ object the entry represents. While deployers are encouraged to use
+ naming attributes whose values are widely disclosable [LDAPDN],
+ entries are often named using information which cannot be disclosed to
+ all parties. As UUIDs do not contain any descriptive information of
+ the object they identify, UUIDs may be used to identify a particular
+ entry without disclosure of its contents.
+
+ General UUID security considerations [UUIDURN] apply.
+
+ General LDAP security considerations [RFC3377] apply.
+
+
+4. IANA Considerations
+
+ It is requested that IANA register upon Standards Action the LDAP
+ values specified in this document.
+
+
+4.1. Object Identifier Registration
+
+
+
+
+Zeilenga draft-zeilenga-ldap-uuid-06 [Page 4]
+
+INTERNET-DRAFT LDAP entryUUID 18 July 2005
+
+
+ Subject: Request for LDAP OID Registration
+ Person & email address to contact for further information:
+ Kurt Zeilenga <kurt at OpenLDAP.org>
+ Specification: RFC XXXX
+ Author/Change Controller: IESG
+ Comments:
+ Identifies the UUID schema elements
+
+
+4.2. UUID Syntax Registration
+
+ Subject: Request for LDAP Syntax Registration
+ Object Identifier: IANA-ASSIGNED-OID.1
+ Description: UUID
+ Person & email address to contact for further information:
+ Kurt Zeilenga <kurt at OpenLDAP.org>
+ Specification: RFC XXXX
+ Author/Change Controller: IESG
+ Comments:
+ Identifies the UUID syntax
+
+
+4.3. 'uuidMatch' Descriptor Registration
+
+ Subject: Request for LDAP Descriptor Registration
+ Descriptor (short name): uuidMatch
+ Object Identifier: IANA-ASSIGNED-OID.2
+ Person & email address to contact for further information:
+ Kurt Zeilenga <kurt at OpenLDAP.org>
+ Usage: Matching Rule
+ Specification: RFC XXXX
+ Author/Change Controller: IESG
+
+
+4.3. 'uuidOrderingMatch' Descriptor Registration
+
+ Subject: Request for LDAP Descriptor Registration
+ Descriptor (short name): uuidOrderingMatch
+ Object Identifier: IANA-ASSIGNED-OID.3
+ Person & email address to contact for further information:
+ Kurt Zeilenga <kurt at OpenLDAP.org>
+ Usage: Matching Rule
+ Specification: RFC XXXX
+ Author/Change Controller: IESG
+
+
+5.4. 'entryUUID' Descriptor Registration
+
+
+
+
+Zeilenga draft-zeilenga-ldap-uuid-06 [Page 5]
+
+INTERNET-DRAFT LDAP entryUUID 18 July 2005
+
+
+ It is requested that IANA register upon Standards Action the LDAP
+ 'entryUUID' descriptor.
+
+ Subject: Request for LDAP Descriptor Registration
+ Descriptor (short name): entryUUID
+ Object Identifier: IANA-ASSIGNED-OID.4
+ Person & email address to contact for further information:
+ Kurt Zeilenga <kurt at OpenLDAP.org>
+ Usage: Attribute Type
+ Specification: RFC XXXX
+ Author/Change Controller: IESG
+
+
+6. Acknowledgments
+
+ This document is based upon discussions in the LDAP Update and
+ Duplication Protocols (LDUP) WG. Members of the LDAP Directorate
+ provided review.
+
+
+7. Author's Address
+
+ Kurt D. Zeilenga
+ OpenLDAP Foundation
+
+ Email: Kurt at OpenLDAP.org
+
+
+8. References
+
+ [[Note to the RFC Editor: please replace the citation tags used in
+ referencing Internet-Drafts with tags of the form RFCnnnn where
+ possible.]]
+
+
+8.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14 (also RFC 2119), March 1997.
+
+ [Roadmap] Zeilenga, K. (editor), "LDAP: Technical Specification
+ Road Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in
+ progress.
+
+ [UUIDURN] Leach, P, M. Mealling, R. Salz, "A UUID URN Namespace",
+ a work in progress.
+
+ [Models] Zeilenga, K. (editor), "LDAP: Directory Information
+
+
+
+Zeilenga draft-zeilenga-ldap-uuid-06 [Page 6]
+
+INTERNET-DRAFT LDAP entryUUID 18 July 2005
+
+
+ Models", draft-ietf-ldapbis-models-xx.txt, a work in
+ progress.
+
+ [Syntaxes] Legg, S. (editor), "LDAP: Syntaxes and Matching Rules",
+ draft-ietf-ldapbis-syntaxes-xx.txt, a work in progress.
+
+ [ASCII] Coded Character Set--7-bit American Standard Code for
+ Information Interchange, ANSI X3.4-1986.
+
+ [X.501] International Telecommunication Union -
+ Telecommunication Standardization Sector, "The Directory
+ -- Models," X.501(1993) (also ISO/IEC 9594-2:1994).
+
+ [X.520] International Telecommunication Union -
+ Telecommunication Standardization Sector, "The
+ Directory: Selected Attribute Types", X.520(1993) (also
+ ISO/IEC 9594-6:1994).
+
+ [X.680] International Telecommunication Union -
+ Telecommunication Standardization Sector, "Abstract
+ Syntax Notation One (ASN.1) - Specification of Basic
+ Notation", X.680(2002) (also ISO/IEC 8824-1:2002).
+
+
+
+8.2. Informative References
+
+ [LDAPDN] Zeilenga, K. (editor), "LDAP: String Representation of
+ Distinguished Names", draft-ietf-ldapbis-dn-xx.txt, a
+ work in progress.
+
+ [BCP64bis] Zeilenga, K., "IANA Considerations for LDAP",
+ draft-ietf-ldapbis-bcp64-xx.txt, a work in progress.
+
+
+
+Intellectual Property Rights
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be found
+ in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+
+
+
+Zeilenga draft-zeilenga-ldap-uuid-06 [Page 7]
+
+INTERNET-DRAFT LDAP entryUUID 18 July 2005
+
+
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this specification
+ can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr at ietf.org.
+
+
+
+Full Copyright
+
+ Copyright (C) The Internet Society (2005).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga draft-zeilenga-ldap-uuid-06 [Page 8]
+
Added: openldap/vendor/openldap-release/doc/drafts/draft-zeilenga-ldap-x509-xx.txt
===================================================================
--- openldap/vendor/openldap-release/doc/drafts/draft-zeilenga-ldap-x509-xx.txt (rev 0)
+++ openldap/vendor/openldap-release/doc/drafts/draft-zeilenga-ldap-x509-xx.txt 2007-09-15 10:38:52 UTC (rev 844)
@@ -0,0 +1,1403 @@
+
+
+
+
+
+
+INTERNET-DRAFT Kurt D. Zeilenga
+Intended Category: Standard Track OpenLDAP Foundation
+Expires in six months 18 July 2005
+Obsoletes: RFC 2252, RFC 2256, RFC 2587
+
+
+ Lightweight Directory Access Protocol (LDAP) schema
+ definitions for X.509 Certificates
+ <draft-zeilenga-ldap-x509-02.txt>
+
+
+Status of this Memo
+
+ This document is intended to be, after appropriate review and
+ revision, submitted to the RFC Editor as an Standard Track document.
+ Distribution of this memo is unlimited. Technical discussion of this
+ document will take place on the IETF LDAP Extensions mailing list
+ <ldapext at ietf.org>. Please send editorial comments directly to the
+ author <Kurt at OpenLDAP.org>.
+
+ This document is intended to be published in conjunction to the
+ revised LDAP TS [Roadmap]. Together, this document and the revised
+ LDAP TS obsoletes RFC 2252 and RFC 2256 in their entirety.
+
+ By submitting this Internet-Draft, each author represents that any
+ applicable patent or other IPR claims of which he or she is aware have
+ been or will be disclosed, and any of which he or she becomes aware
+ will be disclosed, in accordance with Section 6 of BCP 79.
+
+ Internet-Drafts are working documents of the Internet Engineering Task
+ Force (IETF), its areas, and its working groups. Note that other
+ groups may also distribute working documents as Internet-Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference material
+ or to cite them other than as "work in progress."
+
+ The list of current Internet-Drafts can be accessed at
+ http://www.ietf.org/1id-abstracts.html
+
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html
+
+
+ Copyright (C) The Internet Society (2005). All Rights Reserved.
+
+ Please see the Full Copyright section near the end of this document
+
+
+
+Zeilenga draft-zeilenga-ldap-x509-02 [Page 1]
+
+INTERNET-DRAFT LDAP X.509 Schema 18 July 2005
+
+
+ for more information.
+
+
+Abstract
+
+ This document describes schema for representing X.509 certificates,
+ X.521 security information, and related elements in directories
+ accessible using the Lightweight Directory Access Protocol (LDAP).
+ The LDAP definitions for these X.509 and X.521 schema elements
+ replaces those provided in RFC 2252 and RFC 2256.
+
+
+1. Background and Intended Use
+
+ This document provides LDAP [Roadmap] schema definitions [Models] for
+ a subset of elements specified in X.509 [X.509] and X.521 [X.521],
+ including attribute types for certificates, cross certificate pairs,
+ and certificate revocation lists; matching rules to be used with these
+ attribute types; and related object classes. LDAP syntax definitions
+ are also provided for associated assertion and attribute values.
+
+ As the semantics of these elements are as defined in X.509 and X.521,
+ knowledge of X.509 and X.521 is necessary to make use of the LDAP
+ schema definitions provided herein.
+
+ This document, together with [Roadmap], obsoletes RFC 2252 and RFC
+ 2256 in their entirety. The changes (in this document) made since RFC
+ 2252 and RFC 2256 include:
+ - addition of pkiUser, pkiCA, and deltaCRL classes;
+ - update of attribute types to include equality matching rules in
+ accordance with their X.500 specifications;
+ - addition of certificate, certificate pair, certificate list, and
+ algorithm identifer matching rules; and
+ - addition of LDAP syntax for assertion syntaxes for these matching
+ rules.
+
+ This document obsoletes RFC 2587. The X.509 schema descriptions for
+ LDAPv2 [RFC1777] are Historic, as is LDAPv2 [RFC3494].
+
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in BCP 14 [RFC2119].
+
+ Schema definitions are provided using LDAP description formats
+ [Models]. Definitions provided here are formatted (line wrapped) for
+ readability.
+
+
+
+
+Zeilenga draft-zeilenga-ldap-x509-02 [Page 2]
+
+INTERNET-DRAFT LDAP X.509 Schema 18 July 2005
+
+
+2. Syntaxes
+
+ This section describes various syntaxes used in LDAP to transfer
+ certificates and related data types.
+
+
+2.1. Certificate
+
+ ( 1.3.6.1.4.1.1466.115.121.1.8 DESC 'X.509 Certificate' )
+
+ A value of this syntax is an X.509 Certificate [X.509, clause 7].
+
+ Due to changes made to the definition of a Certificate made through
+ time, no LDAP-specific encoding is defined for this syntax. Values of
+ this syntax SHOULD be encoded using Distinguished Encoding Rules (DER)
+ [X.690] and MUST only be transferred using the ;binary transfer option
+ [Binary]. That is, by requesting and returning values using attribute
+ descriptions such as "userCertificate;binary".
+
+ As values of this syntax contain digitally-signed data, values of this
+ syntax, and the form of the value, MUST be preserved as presented.
+
+
+2.2. CertificateList
+
+ ( 1.3.6.1.4.1.1466.115.121.1.9 DESC 'X.509 Certificate List' )
+
+ A value of this syntax is an X.509 CertificateList [X.509, clause
+ 7.3].
+
+ Due to changes made to the definition of a CertificateList made
+ through time, no LDAP-specific encoding is defined for this syntax.
+ Values of this syntax SHOULD be encoded using DER [X.690] and MUST
+ only be transferred using the ;binary transfer option [Binary]. That
+ is, by requesting and returning values using attribute descriptions
+ such as "certificateRevocationList;binary".
+
+ As values of this syntax contain digitally-signed data, values of this
+ syntax, and the form of the value, MUST be preserved as presented.
+
+
+2.3. CertificatePair
+
+ ( 1.3.6.1.4.1.1466.115.121.1.10 DESC 'X.509 Certificate Pair' )
+
+ A value of this syntax is an X.509 CertificatePair [X.509, clause
+ 11.2.3].
+
+
+
+
+Zeilenga draft-zeilenga-ldap-x509-02 [Page 3]
+
+INTERNET-DRAFT LDAP X.509 Schema 18 July 2005
+
+
+ Due to changes made to the definition of an X.509 CertificatePair made
+ through time, no LDAP-specific encoding is defined for this syntax.
+ Values of this syntax SHOULD be encoded using DER [X.690] and MUST
+ only be transferred using the ;binary transfer option [Binary]. That
+ is, by requesting and returning values using attribute descriptions
+ such as "crossCertificatePair;binary".
+
+ As values of this syntax contain digitally-signed data, values of this
+ syntax, and the form of the value, MUST be preserved as presented.
+
+2.4 SupportedAlgorithm
+
+ ( 1.3.6.1.4.1.1466.115.121.1.49
+ DESC 'X.509 Supported Algorithm' )
+
+ A value of this syntax is an X.509 SupportedAlgorithm [X.509, clause
+ 11.2.7].
+
+ Due to changes made to the definition of an X.509 SupportedAlgorithm
+ made through time, no LDAP-specific encoding is defined for this
+ syntax. Values of this syntax SHOULD be encoded using DER [X.690] and
+ MUST only be transferred using the ;binary transfer option [Binary].
+ That is, by requesting and returning values using attribute
+ descriptions such as "supportedAlgorithms;binary".
+
+ As values of this syntax contain digitally-signed data, values of this
+ syntax, and the form of the value, MUST be preserved as presented.
+
+
+2.5. CertificateExactAssertion
+
+ ( IANA-ASSIGNED-OID.1 DESC 'X.509 Certificate Exact Assertion' )
+
+ A value of this syntax is an X.509 CertificateExactAssertion [X.509,
+ clause 11.3.1]. Values of this syntax MUST be encoded using the
+ Generic String Encoding Rules (GSER) [RFC3641]. Appendix A.1 provides
+ an equivalent Augmented Backus-Naur Form (ABNF) [ABNF] grammar for
+ this syntax.
+
+
+2.6. CertificateAssertion
+
+ ( IANA-ASSIGNED-OID.2 DESC 'X.509 Certificate Assertion' )
+
+ A value of this syntax is an X.509 CertificateAssertion [X.509, clause
+ 11.3.2]. Values of this syntax MUST be encoded using GSER [RFC3641].
+ Appendix A.2 provides an equivalent ABNF [ABNF] grammar for this
+ syntax.
+
+
+
+Zeilenga draft-zeilenga-ldap-x509-02 [Page 4]
+
+INTERNET-DRAFT LDAP X.509 Schema 18 July 2005
+
+
+2.7. CertificatePairExactAssertion
+
+ ( IANA-ASSIGNED-OID.3
+ DESC 'X.509 Certificate Pair Exact Assertion' )
+
+ A value of this syntax is an X.509 CertificatePairExactAssertion
+ [X.509, clause 11.3.3]. Values of this syntax MUST be encoded using
+ GSER [RFC3641]. Appendix A.3 provides an equivalent ABNF [ABNF]
+ grammar for this syntax.
+
+
+2.8. CertificatePairAssertion
+
+ ( IANA-ASSIGNED-OID.4 DESC 'X.509 Certificate Pair Assertion' )
+
+ A value of this syntax is an X.509 CertificatePairAssertion [X.509,
+ clause 11.3.4]. Values of this syntax MUST be encoded using GSER
+ [RFC3641]. Appendix A.4 provides an equivalent ABNF [ABNF] grammar
+ for this syntax.
+
+
+2.9. CertificateListExactAssertion
+
+ ( IANA-ASSIGNED-OID.5
+ DESC 'X.509 Certificate List Exact Assertion' )
+
+ A value of this syntax is an X.509 CertificateListExactAssertion
+ [X.509, clause 11.3.5]. Values of this syntax MUST be encoded using
+ GSER [RFC3641]. Appendix A.5 provides an equivalent ABNF grammar for
+ this syntax.
+
+
+2.10. CertificateListAssertion
+
+ ( IANA-ASSIGNED-OID.6 DESC 'X.509 Certificate List Assertion' )
+
+ A value of this syntax is an X.509 CertificateListAssertion [X.509,
+ clause 11.3.6]. Values of this syntax MUST be encoded using GSER
+ [RFC3641]. Appendix A.6 provides an equivalent ABNF [ABNF] grammar
+ for this syntax.
+
+
+2.11 AlgorithmIdentifier
+
+ ( IANA-ASSIGNED-OID.7 DESC 'X.509 Algorithm Identifier' )
+
+ A value of this syntax is an X.509 AlgorithmIdentifier [X.509, Clause
+ 7]. Values of this syntax MUST be encoded using GSER [RFC3641].
+
+
+
+Zeilenga draft-zeilenga-ldap-x509-02 [Page 5]
+
+INTERNET-DRAFT LDAP X.509 Schema 18 July 2005
+
+
+ Appendix A.7 provides an equivalent ABNF [ABNF] grammar for this
+ syntax.
+
+
+3. Matching Rules
+
+ This section introduces a set of certificate and related matching
+ rules for use in LDAP. These rules are intended to act in accordance
+ with their X.500 counterparts.
+
+
+3.1. certificateExactMatch
+
+ The certificateExactMatch matching rule compares the presented
+ certificate exact assertion value with an attribute value of the
+ certificate syntax as described in clause 11.3.1 of [X.509].
+
+ ( 2.5.13.34 NAME 'certificateExactMatch'
+ DESC 'X.509 Certificate Exact Match'
+ SYNTAX IANA-ASSIGNED-OID.1 )
+
+
+3.2. certificateMatch
+
+ The certificateMatch matching rule compares the presented certificate
+ assertion value with an attribute value of the certificate syntax as
+ described in clause 11.3.2 of [X.509].
+
+ ( 2.5.13.35 NAME 'certificateMatch'
+ DESC 'X.509 Certificate Match'
+ SYNTAX IANA-ASSIGNED-OID.2 )
+
+
+3.3. certificatePairExactMatch
+
+ The certificatePairExactMatch matching rule compares the presented
+ certificate pair exact assertion value with an attribute value of the
+ certificate pair syntax as described in clause 11.3.3 of [X.509].
+
+ ( 2.5.13.36 NAME 'certificatePairExactMatch'
+ DESC 'X.509 Certificate Pair Exact Match'
+ SYNTAX IANA-ASSIGNED-OID.3 )
+
+
+3.4. certificatePairMatch
+
+ The certificatePairMatch matching rule compares the presented
+ certificate pair assertion value with an attribute value of the
+
+
+
+Zeilenga draft-zeilenga-ldap-x509-02 [Page 6]
+
+INTERNET-DRAFT LDAP X.509 Schema 18 July 2005
+
+
+ certificate pair syntax as described in clause 11.3.4 of [X.509].
+
+ ( 2.5.13.37 NAME 'certificatePairMatch'
+ DESC 'X.509 Certificate Pair Match'
+ SYNTAX IANA-ASSIGNED-OID.4 )
+
+
+3.5. certificateListExactMatch
+
+ The certificateListExactMatch matching rule compares the presented
+ certificate list exact assertion value with an attribute value of the
+ certificate pair syntax as described in clause 11.3.5 of [X.509].
+
+ ( 2.5.13.38 NAME 'certificateListExactMatch'
+ DESC 'X.509 Certificate List Exact Match'
+ SYNTAX IANA-ASSIGNED-OID.5 )
+
+
+3.6. certificateListMatch
+
+ The certificateListMatch matching rule compares the presented
+ certificate list assertion value with an attribute value of the
+ certificate pair syntax as described in clause 11.3.6 of [X.509].
+
+ ( 2.5.13.39 NAME 'certificateListMatch'
+ DESC 'X.509 Certificate List Match'
+ SYNTAX IANA-ASSIGNED-OID.6 )
+
+
+3.7. algorithmIdentifierMatch
+
+ The algorithmIdentifierMatch mating rule compares a presented
+ algorithm identifier with an attribute value of supported algorithm as
+ described in clause 11.3.7 of [X.509].
+
+ ( 2.5.13.40 NAME 'algorithmIdentifier'
+ DESC 'X.509 Algorithm Identifier Match'
+ SYNTAX IANA-ASSIGNED-OID.7 )
+
+
+4. Attribute Types
+
+ This section details a set of certificate and related attribute types
+ for use in LDAP.
+
+
+4.1. userCertificate
+
+
+
+
+Zeilenga draft-zeilenga-ldap-x509-02 [Page 7]
+
+INTERNET-DRAFT LDAP X.509 Schema 18 July 2005
+
+
+ The userCertificate attribute holds the X.509 certificates issued to
+ the user by one or more certificate authorities, as discussed in
+ clause 11.2.1 of [X.509].
+
+ ( 2.5.4.36 NAME 'userCertificate'
+ DESC 'X.509 user certificate'
+ EQUALITY certificateExactMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.8 )
+
+ As required by this attribute type's syntax, values of this attribute
+ are requested and transferred using the attribute description
+ "userCertificate;binary".
+
+
+4.2. cACertificate
+
+ The cACertificate attribute holds the X.509 certificates issued to the
+ certificate authority (CA), as discussed in clause 11.2.2 of [X.509].
+
+ ( 2.5.4.37 NAME 'cACertificate'
+ DESC 'X.509 CA certificate'
+ EQUALITY certificateExactMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.8 )
+
+ As required by this attribute type's syntax, values of this attribute
+ are requested and transferred using the attribute description
+ "cACertificate;binary".
+
+
+4.3. crossCertificatePair
+
+ The crossCertificatePair attribute holds an X.509 certificate pair, as
+ discussed in clause 11.2.3 of [X.509].
+
+ ( 2.5.4.40 NAME 'crossCertificatePair'
+ DESC 'X.509 cross certificate pair'
+ EQUALITY certificatePairExactMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.10 )
+
+ As required by this attribute type's syntax, values of this attribute
+ are requested and transferred using the attribute description
+ "crossCertificatePair;binary".
+
+
+4.4. certificateRevocationList
+
+ The certificateRevocationList attribute holds certificate lists, as
+ discussed in 11.2.4 of [X.509].
+
+
+
+Zeilenga draft-zeilenga-ldap-x509-02 [Page 8]
+
+INTERNET-DRAFT LDAP X.509 Schema 18 July 2005
+
+
+ ( 2.5.4.39 NAME 'certificateRevocationList'
+ DESC 'X.509 certificate revocation list'
+ EQUALITY certificateListExactMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.9 )
+
+ As required by this attribute type's syntax, values of this attribute
+ are requested and transferred using the attribute description
+ "certificateRevocationList;binary".
+
+
+4.5. authorityRevocationList
+
+ The authorityRevocationList attribute holds certificate lists, as
+ discussed in 11.2.5 of [X.509].
+
+ ( 2.5.4.38 NAME 'authorityRevocationList'
+ DESC 'X.509 authority revocation list'
+ EQUALITY certificateListExactMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.9 )
+
+ As required by this attribute type's syntax, values of this attribute
+ are requested and transferred using the attribute description
+ "authorityRevocationList;binary".
+
+
+4.6. deltaRevocationList
+
+ The deltaRevocationList attribute holds certificate lists, as
+ discussed in 11.2.6 of [X.509].
+
+ ( 2.5.4.53 NAME 'deltaRevocationList'
+ DESC 'X.509 delta revocation list'
+ EQUALITY certificateListExactMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.9 )
+
+ As required by this attribute type's syntax, values of this attribute
+ MUST be requested and transferred using the attribute description
+ "deltaRevocationList;binary".
+
+
+4.7. supportedAlgorithms
+
+ The supportedAlgorithms attribute holds supported algorithms, as
+ discussed in 11.2.7 of [X.509].
+
+ ( 2.5.4.52 NAME 'supportedAlgorithms'
+ DESC 'X.509 supported algorithms'
+ EQUALITY algorithmIdentifierMatch
+
+
+
+Zeilenga draft-zeilenga-ldap-x509-02 [Page 9]
+
+INTERNET-DRAFT LDAP X.509 Schema 18 July 2005
+
+
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.49 )
+
+ As required by this attribute type's syntax, values of this attribute
+ MUST be requested and transferred using the attribute description
+ "supportedAlgorithms;binary".
+
+
+5. Object Classes
+
+ This section details a set of certificate-related object classes for
+ use in LDAP.
+
+
+5.1. pkiUser
+
+ This object class is used in augment entries for objects that may be
+ subject to certificates, as defined in clause 11.1.1 of [X.509].
+
+ ( 2.5.6.21 NAME 'pkiUser'
+ DESC 'X.509 PKI User'
+ SUP top AUXILIARY
+ MAY userCertificate )
+
+
+5.2. pkiCA
+
+ This object class is used to augment entries for objects which act as
+ certificate authorities, as defined in clause 11.1.2 of [X.509]
+
+ ( 2.5.6.22 NAME 'pkiCA'
+ DESC 'X.509 PKI Certificate Authority'
+ SUP top AUXILIARY
+ MAY ( cACertificate $ certificateRevocationList $
+ authorityRevocationList $ crossCertificatePair ) )
+
+
+5.3. cRLDistributionPoint
+
+ This class is used to represent objects which act as CRL distribution
+ points, as discussed in clause 11.1.3 of [X.509].
+
+ ( 2.5.6.19 NAME 'cRLDistributionPoint'
+ DESC 'X.509 CRL distribution point'
+ SUP top STRUCTURAL
+ MUST cn
+ MAY ( certificateRevocationList $
+ authorityRevocationList $ deltaRevocationList ) )
+
+
+
+
+Zeilenga draft-zeilenga-ldap-x509-02 [Page 10]
+
+INTERNET-DRAFT LDAP X.509 Schema 18 July 2005
+
+
+5.4 deltaCRL
+
+ The deltaCRL object class is used to augment entries to hold delta
+ revocation lists, as discussed in clause 11.1.4 of [X.509].
+
+ ( 2.5.6.23 NAME 'deltaCRL'
+ DESC 'X.509 delta CRL'
+ SUP top AUXILIARY
+ MAY deltaRevocationList )
+
+
+5.5. strongAuthenticationUser
+
+ This object class is used to augment entries for objects participating
+ in certificate-based authentication, as defined in clause 6.15 of
+ [X.521]. This object class is deprecated in favor of pkiUser.
+
+ ( 2.5.6.15 NAME 'strongAuthenticationUser'
+ DESC 'X.521 strong authentication user'
+ SUP top AUXILIARY
+ MUST userCertificate )
+
+
+5.6. userSecurityInformation
+
+ This object class is used to augment entries with needed additional
+ associated security information, as defined in clause 6.16 of [X.521].
+
+ ( 2.5.6.18 NAME 'userSecurityInformation'
+ DESC 'X.521 user security information'
+ SUP top AUXILIARY
+ MAY ( supportedAlgorithms ) )
+
+
+5.7. certificationAuthority
+
+ This object class is used to augment entries for objects which act as
+ certificate authorities, as defined in clause 6.17 of [X.521]. This
+ object class is deprecated in favor of pkiCA.
+
+ ( 2.5.6.16 NAME 'certificationAuthority'
+ DESC 'X.509 certificate authority'
+ SUP top AUXILIARY
+ MUST ( authorityRevocationList $
+ certificateRevocationList $ cACertificate )
+ MAY crossCertificatePair )
+
+
+
+
+
+Zeilenga draft-zeilenga-ldap-x509-02 [Page 11]
+
+INTERNET-DRAFT LDAP X.509 Schema 18 July 2005
+
+
+5.8. certificationAuthority-V2
+
+ This object class is used to augment entries for objects which act as
+ certificate authorities, as defined in clause 6.18 of [X.521]. This
+ object class is deprecated in favor of pkiCA.
+
+ ( 2.5.6.16.2 NAME 'certificationAuthority-V2'
+ DESC 'X.509 certificate authority, version 2'
+ SUP certificationAuthority AUXILIARY
+ MAY deltaRevocationList )
+
+
+6. Security Considerations
+
+ General certificate considerations [RFC3280] apply to LDAP-aware
+ certificate applications. General LDAP security considerations
+ [Roadmap] apply as well.
+
+ While elements of certificate information are commonly signed, these
+ signatures only protect the integrity of the signed information. In
+ the absence of a data integrity protections in LDAP (or lower layer,
+ e.g. IPsec), a server is not assured that client certificate request
+ (or other request) was unaltered in transit. Likewise, a client
+ cannot be assured that the results of the query were unaltered in
+ transit. Hence, it is generally recommended implementations make use
+ of authentication and data integrity services in LDAP
+ [AuthMeth][Protocol].
+
+
+7. IANA Considerations
+
+7.1. Object Identifier Registration
+
+ It is requested that IANA register upon Standards Action an LDAP
+ Object Identifier for use in this technical specification.
+
+ Subject: Request for LDAP OID Registration
+ Person & email address to contact for further information:
+ Kurt Zeilenga <kurt at OpenLDAP.org>
+ Specification: RFC XXXX
+ Author/Change Controller: IESG
+ Comments:
+ Identifies the LDAP X.509 Certificate schema elements
+ introduced in this document.
+
+
+7.2. Registration of the descriptor
+
+
+
+
+Zeilenga draft-zeilenga-ldap-x509-02 [Page 12]
+
+INTERNET-DRAFT LDAP X.509 Schema 18 July 2005
+
+
+ It is requested that IANA update upon Standards Action the LDAP
+ Descriptor registry as indicated below.
+
+ Subject: Request for LDAP Descriptor Registration
+ Descriptor (short name): see table
+ Object Identifier: see table
+ Person & email address to contact for further information:
+ Kurt Zeilenga <kurt at OpenLDAP.org>
+ Usage: see table
+ Specification: RFC XXXX
+ Author/Change Controller: IESG
+
+ algorithmIdentifierMatch R 2.5.13.40
+ authorityRevocationList A 2.5.4.38 *
+ cACertificate A 2.5.4.37 *
+ cRLDistributionPoint O 2.5.6.19 *
+ certificateExactMatch R 2.5.13.34
+ certificateListExactMatch R 2.5.13.38
+ certificateListMatch R 2.5.13.39
+ certificateMatch R 2.5.13.35
+ certificatePairExactMatch R 2.5.13.36
+ certificatePairMatch R 2.5.13.37
+ certificateRevocationList A 2.5.4.39 *
+ certificationAuthority O 2.5.6.16 *
+ certificationAuthority-V2 O 2.5.6.16.2 *
+ crossCertificatePair A 2.5.4.40 *
+ deltaCRL O 2.5.6.23 *
+ deltaRevocationList A 2.5.4.53 *
+ pkiCA O 2.5.6.22 *
+ pkiUser O 2.5.6.21 *
+ strongAuthenticationUser O 2.5.6.15 *
+ supportedAlgorithms A 2.5.4.52 *
+ userCertificate A 2.5.4.36 *
+ userSecurityInformation O 2.5.6.18 *
+
+ * Updates previous registration
+
+
+8. Acknowledgments
+
+ This document is based upon X.509, a product of the ITU-T. A number
+ of LDAP schema definitions were based on those found in RFC 2252 and
+ RFC 2256, both products of the IETF ASID WG. The ABNF productions in
+ Appendix A were provided by Steven Legg. Additional material was
+ borrowed from prior works by David Chadwick and Steven Legg to refine
+ the LDAP X.509 schema.
+
+
+
+
+
+Zeilenga draft-zeilenga-ldap-x509-02 [Page 13]
+
+INTERNET-DRAFT LDAP X.509 Schema 18 July 2005
+
+
+9. Author's Address
+
+ Kurt D. Zeilenga
+ OpenLDAP Foundation
+
+ Email: Kurt at OpenLDAP.org
+
+
+10. References
+
+ [[Note to the RFC Editor: please replace the citation tags used in
+ referencing Internet-Drafts with tags of the form RFCnnnn where
+ possible.]]
+
+
+10.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14 (also RFC 2119), March 1997.
+
+ [RFC3641] Legg, S., "Generic String Encoding Rules for ASN.1
+ Types", RFC 3641, October 2003.
+
+ [Roadmap] Zeilenga, K. (editor), "LDAP: Technical Specification
+ Road Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in
+ progress.
+
+ [Models] Zeilenga, K. (editor), "LDAP: Directory Information
+ Models", draft-ietf-ldapbis-models-xx.txt, a work in
+ progress.
+
+ [Binary] Legg, S., "Lightweight Directory Access Protocol (LDAP):
+ The Binary Encoding Option",
+ draft-legg-ldap-binary-xx.txt, a work in progress.
+
+ [X.509] International Telecommunication Union -
+ Telecommunication Standardization Sector, "The
+ Directory: Authentication Framework", X.509(2000).
+
+ [X.521] International Telecommunication Union -
+ Telecommunication Standardization Sector, "The
+ Directory: Selected Object Classes", X.521(2000).
+
+ [X.680] International Telecommunication Union -
+ Telecommunication Standardization Sector, "Abstract
+ Syntax Notation One (ASN.1) - Specification of Basic
+ Notation", X.680(2002) (also ISO/IEC 8824-1:2002).
+
+
+
+
+Zeilenga draft-zeilenga-ldap-x509-02 [Page 14]
+
+INTERNET-DRAFT LDAP X.509 Schema 18 July 2005
+
+
+ [X.690] International Telecommunication Union -
+ Telecommunication Standardization Sector, "Specification
+ of ASN.1 encoding rules: Basic Encoding Rules (BER),
+ Canonical Encoding Rules (CER), and Distinguished
+ Encoding Rules (DER)", X.690(2002) (also ISO/IEC
+ 8825-1:2002).
+
+
+11.2. Informative References
+
+ [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
+ Specifications: ABNF", draft-crocker-abnf-rfc2234bis, a
+ work in progress.
+
+ [AuthMeth] Harrison, R. (editor), "LDAP: Authentication Methods and
+ Connection Level Security Mechanisms",
+ draft-ietf-ldapbis-authmeth-xx.txt, a work in progress.
+
+ [Protocol] Sermersheim, J. (editor), "LDAP: The Protocol",
+ draft-ietf-ldapbis-protocol-xx.txt, a work in progress.
+
+ [RFC2156] Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay):
+ Mapping between X.400 and RFC 822/MIME", RFC 2156,
+ January 1998.
+
+ [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
+ X.509 Public Key Infrastructure Certificate and
+ Certificate Revocation List (CRL) Profile", RFC 3280,
+ April 2002.
+
+ [RFC3383] Zeilenga, K., "IANA Considerations for LDAP", BCP 64
+ (also RFC 3383), September 2002.
+
+ [RFC3642] Legg, S., "Common Elements of GSER Encodings", RFC 3642,
+ October 2003.
+
+ [RFC3687] Legg, S., "Lightweight Directory Access Protocol (LDAP)
+ and X.500 Component Matching Rules", RFC 3687, February
+ 2004.
+
+ [BCP64bis] Zeilenga, K., "IANA Considerations for LDAP",
+ draft-ietf-ldapbis-bcp64-xx.txt, a work in progress.
+
+
+Appendix A.
+
+ This appendix is informative.
+
+
+
+
+Zeilenga draft-zeilenga-ldap-x509-02 [Page 15]
+
+INTERNET-DRAFT LDAP X.509 Schema 18 July 2005
+
+
+ This appendix provides ABNF [ABNF] grammars for GSER-based [RFC3687]
+ LDAP-specific encodings specified in this document. These grammars
+ where produced using, and relying on, Common Elements for GSER
+ Encodings [RFC3342].
+
+
+A.1. CertificateExactAssertion
+
+ CertificateExactAssertion = "{" sp cea-serialNumber ","
+ sp cea-issuer sp "}"
+
+ cea-serialNumber = id-serialNumber msp CertificateSerialNumber
+ cea-issuer = id-issuer msp Name
+
+ id-serialNumber =
+ %x73.65.72.69.61.6C.4E.75.6D.62.65.72 ; 'serialNumber'
+ id-issuer = %x69.73.73.75.65.72 ; 'issuer'
+
+ Name = id-rdnSequence ":" RDNSequence
+ id-rdnSequence = %x72.64.6E.53.65.71.75.65.6E.63.65 ; 'rdnSequence'
+
+ CertificateSerialNumber = INTEGER
+
+
+A.2. CertificateAssertion
+
+ CertificateAssertion = "{" [ sp ca-serialNumber ]
+ [ sep sp ca-issuer ]
+ [ sep sp ca-subjectKeyIdentifier ]
+ [ sep sp ca-authorityKeyIdentifier ]
+ [ sep sp ca-certificateValid ]
+ [ sep sp ca-privateKeyValid ]
+ [ sep sp ca-subjectPublicKeyAlgID ]
+ [ sep sp ca-keyUsage ]
+ [ sep sp ca-subjectAltName ]
+ [ sep sp ca-policy ]
+ [ sep sp ca-pathToName ]
+ [ sep sp ca-subject ]
+ [ sep sp ca-nameConstraints ] sp "}"
+
+ ca-serialNumber = id-serialNumber msp CertificateSerialNumber
+ ca-issuer = id-issuer msp Name
+ ca-subjectKeyIdentifier = id-subjectKeyIdentifier msp
+ SubjectKeyIdentifier
+ ca-authorityKeyIdentifier = id-authorityKeyIdentifier msp
+ AuthorityKeyIdentifier
+ ca-certificateValid = certificateValid msp Time
+ ca-privateKeyValid = id-privateKeyValid msp GeneralizedTime
+
+
+
+Zeilenga draft-zeilenga-ldap-x509-02 [Page 16]
+
+INTERNET-DRAFT LDAP X.509 Schema 18 July 2005
+
+
+ ca-subjectPublicKeyAlgID = id-subjectPublicKeyAlgID msp
+ OBJECT-IDENTIFIER
+ ca-keyUsage = id-keyUsage msp KeyUsage
+ ca-subjectAltName = id-subjectAltName msp AltNameType
+ ca-policy = id-policy msp CertPolicySet
+ ca-pathToName = id-pathToName msp Name
+ ca-subject = id-subject msp Name
+ ca-nameConstraints = id-nameConstraints msp NameConstraintsSyntax
+
+ id-subjectKeyIdentifier =
+ %x73.75.62.6A.65.63.74.4B.65.79.49.64.65.6E.74.69.66.69.65.72
+ ; 'subjectKeyIdentifier'
+ id-authorityKeyIdentifier =
+ %x61.75.74.68.6F.72.69.74.79.4B.65.79.49.64.65.6E.74.69.66.69.65.72
+ ; 'authorityKeyIdentifier'
+ id-certificateValid = %x63.65.72.74.69.66.69.63.61.74.65.56.61.6C.69.64
+ ; 'certificateValid'
+ id-privateKeyValid = %x70.72.69.76.61.74.65.4B.65.79.56.61.6C.69.64
+ ; 'privateKeyValid'
+ id-subjectPublicKeyAlgID =
+ %x73.75.62.6A.65.63.74.50.75.62.6C.69.63.4B.65.79.41.6C.67.49.44
+ ; 'subjectPublicKeyAlgID'
+ id-keyUsage = %x6B.65.79.55.73.61.67.65 ; 'keyUsage'
+ id-subjectAltName = %x73.75.62.6A.65.63.74.41.6C.74.4E.61.6D.65
+ ; 'subjectAltName'
+ id-policy = %x70.6F.6C.69.63.79 ; 'policy'
+ id-pathToName = %x70.61.74.68.54.6F.4E.61.6D.65 ; 'pathToName'
+ id-subject = %x73.75.62.6A.65.63.74 ; 'subject'
+ id-nameConstraints = %x6E.61.6D.65.43.6F.6E.73.74.72.61.69.6E.74.73
+ ; 'nameConstraints'
+
+ SubjectKeyIdentifier = KeyIdentifier
+
+ KeyIdentifier = OCTET-STRING
+
+ AuthorityKeyIdentifier = "{" [ sp aki-keyIdentifier ]
+ [ sep sp aki-authorityCertIssuer ]
+ [ sep sp aki-authorityCertSerialNumber ] sp "}"
+
+ aki-keyIdentifier = id-keyIdentifier msp KeyIdentifier
+ aki-authorityCertIssuer = id-authorityCertIssuer msp GeneralNames
+
+ GeneralNames = "{" sp GeneralName *( "," sp GeneralName ) sp "}"
+ GeneralName = gn-otherName
+ / gn-rfc822Name
+ / gn-dNSName
+ / gn-x400Address
+ / gn-directoryName
+
+
+
+Zeilenga draft-zeilenga-ldap-x509-02 [Page 17]
+
+INTERNET-DRAFT LDAP X.509 Schema 18 July 2005
+
+
+ / gn-ediPartyName
+ / gn-uniformResourceIdentifier
+ / gn-iPAddress
+ / gn-registeredID
+
+ gn-otherName = id-otherName ":" OtherName
+ gn-rfc822Name = id-rfc822Name ":" IA5String
+ gn-dNSName = id-dNSName ":" IA5String
+ gn-x400Address = id-x400Address ":" ORAddress
+ gn-directoryName = id-directoryName ":" Name
+ gn-ediPartyName = id-ediPartyName ":" EDIPartyName
+ gn-iPAddress = id-iPAddress ":" OCTET-STRING
+ gn-registeredID = gn-id-registeredID ":" OBJECT-IDENTIFIER
+
+ gn-uniformResourceIdentifier = id-uniformResourceIdentifier
+ ":" IA5String
+
+ id-otherName = %x6F.74.68.65.72.4E.61.6D.65 ; 'otherName'
+ gn-id-registeredID = %x72.65.67.69.73.74.65.72.65.64.49.44
+ ; 'registeredID'
+
+ OtherName = "{" sp on-type-id "," sp on-value sp "}"
+ on-type-id = id-type-id msp OBJECT-IDENTIFIER
+ on-value = id-value msp Value
+ ;; <Value> as defined in Section 8 of [RFC3786]
+
+ id-type-id = %x74.79.70.65.2D.69.64 ; 'type-id'
+ id-value = %x76.61.6C.75.65 ; 'value'
+
+ ORAddress = dquote *SafeIA5Character dquote
+ SafeIA5Character = %x01-21 / %x23-7F / ; ASCII minus dquote
+ dquote dquote ; escaped double quote
+ dquote = %x22 ; '"' (double quote)
+
+ ;; Note: The <ORAddress> rule encodes the x400Address component
+ ;; of a GeneralName as a character string between double quotes.
+ ;; The character string is first derived according to Section 4.1
+ ;; of [RFC2156], and then any embedded double quotes are escaped
+ ;; by being repeated. This resulting string is output between
+ ;; double quotes.
+
+ EDIPartyName = "{" [ sp nameAssigner "," ] sp partyName sp "}"
+ nameAssigner = id-nameAssigner msp DirectoryString
+ partyName = id-partyName msp DirectoryString
+ id-nameAssigner = %x6E.61.6D.65.41.73.73.69.67.6E.65.72
+ ; 'nameAssigner'
+ id-partyName = %x70.61.72.74.79.4E.61.6D.65 ; 'partyName'
+
+
+
+
+Zeilenga draft-zeilenga-ldap-x509-02 [Page 18]
+
+INTERNET-DRAFT LDAP X.509 Schema 18 July 2005
+
+
+ aki-authorityCertSerialNumber = id-authorityCertSerialNumber
+ msp CertificateSerialNumber
+
+ id-keyIdentifier = %x6B.65.79.49.64.65.6E.74.69.66.69.65.72
+ ; 'keyIdentifier'
+ id-authorityCertIssuer =
+ %x61.75.74.68.6F.72.69.74.79.43.65.72.74.49.73.73.75.65.72
+ ; 'authorityCertIssuer'
+
+ id-authorityCertSerialNumber = %x61.75.74.68.6F.72.69.74.79.43
+ %x65.72.74.53.65.72.69.61.6C.4E.75.6D.62.65.72
+ ; 'authorityCertSerialNumber'
+
+ Time = time-utcTime / time-generalizedTime
+ time-utcTime = id-utcTime ":" UTCTime
+ time-generalizedTime = id-generalizedTime ":" GeneralizedTime
+ id-utcTime = %x75.74.63.54.69.6D.65 ; 'utcTime'
+ id-generalizedTime = %x67.65.6E.65.72.61.6C.69.7A.65.64.54.69.6D.65
+ ; 'generalizedTime'
+
+ KeyUsage = BIT-STRING / key-usage-bit-list
+ key-usage-bit-list = "{" [ sp key-usage *( "," sp key-usage ) ] sp "}"
+
+ ;; Note: The <key-usage-bit-list> rule encodes the one bits in
+ ;; a KeyUsage value as a comma separated list of identifiers.
+
+ key-usage = id-digitalSignature
+ / id-nonRepudiation
+ / id-keyEncipherment
+ / id-dataEncipherment
+ / id-keyAgreement
+ / id-keyCertSign
+ / id-cRLSign
+ / id-encipherOnly
+ / id-decipherOnly
+
+ id-digitalSignature = %x64.69.67.69.74.61.6C.53.69.67.6E.61.74
+ %x75.72.65 ; 'digitalSignature'
+ id-nonRepudiation = %x6E.6F.6E.52.65.70.75.64.69.61.74.69.6F.6E
+ ; 'nonRepudiation'
+ id-keyEncipherment = %x6B.65.79.45.6E.63.69.70.68.65.72.6D.65.6E.74
+ ; 'keyEncipherment'
+ id-dataEncipherment = %x64.61.74.61.45.6E.63.69.70.68.65.72.6D.65.6E
+ %x74 ; "dataEncipherment'
+ id-keyAgreement = %x6B.65.79.41.67.72.65.65.6D.65.6E.74
+ ; 'keyAgreement'
+ id-keyCertSign = %x6B.65.79.43.65.72.74.53.69.67.6E
+ ; 'keyCertSign'
+
+
+
+Zeilenga draft-zeilenga-ldap-x509-02 [Page 19]
+
+INTERNET-DRAFT LDAP X.509 Schema 18 July 2005
+
+
+ id-cRLSign = %x63.52.4C.53.69.67.6E ; "cRLSign"
+ id-encipherOnly = %x65.6E.63.69.70.68.65.72.4F.6E.6C.79
+ ; 'encipherOnly'
+ id-decipherOnly = %x64.65.63.69.70.68.65.72.4F.6E.6C.79
+ ; 'decipherOnly'
+
+ AltNameType = ant-builtinNameForm / ant-otherNameForm
+
+ ant-builtinNameForm = id-builtinNameForm ":" BuiltinNameForm
+ ant-otherNameForm = id-otherNameForm ":" OBJECT-IDENTIFIER
+
+ id-builtinNameForm = %x62.75.69.6C.74.69.6E.4E.61.6D.65.46.6F.72.6D
+ ; 'builtinNameForm'
+ id-otherNameForm = %x6F.74.68.65.72.4E.61.6D.65.46.6F.72.6D
+ ; 'otherNameForm'
+
+ BuiltinNameForm = id-rfc822Name
+ / id-dNSName
+ / id-x400Address
+ / id-directoryName
+ / id-ediPartyName
+ / id-uniformResourceIdentifier
+ / id-iPAddress
+ / id-registeredId
+
+ id-rfc822Name = %x72.66.63.38.32.32.4E.61.6D.65 ; 'rfc822Name'
+ id-dNSName = %x64.4E.53.4E.61.6D.65 ; 'dNSName'
+ id-x400Address = %x78.34.30.30.41.64.64.72.65.73.73 ; 'x400Address'
+ id-directoryName = %x64.69.72.65.63.74.6F.72.79.4E.61.6D.65
+ ; 'directoryName'
+ id-ediPartyName = %x65.64.69.50.61.72.74.79.4E.61.6D.65
+ ; 'ediPartyName'
+ id-iPAddress = %x69.50.41.64.64.72.65.73.73 ; 'iPAddress'
+ id-registeredId = %x72.65.67.69.73.74.65.72.65.64.49.64
+ ; 'registeredId'
+
+ id-uniformResourceIdentifier = %x75.6E.69.66.6F.72.6D.52.65.73.6F.75
+ %x72.63.65.49.64.65.6E.74.69.66.69.65.72
+ ; 'uniformResourceIdentifier'
+
+ CertPolicySet = "{" sp CertPolicyId *( "," sp CertPolicyId ) sp "}"
+ CertPolicyId = OBJECT-IDENTIFIER
+
+ NameConstraintsSyntax = "{" [ sp ncs-permittedSubtrees ]
+ [ sep sp ncs-excludedSubtrees ] sp "}"
+
+ ncs-permittedSubtrees = id-permittedSubtrees msp GeneralSubtrees
+ ncs-excludedSubtrees = id-excludedSubtrees msp GeneralSubtrees
+
+
+
+Zeilenga draft-zeilenga-ldap-x509-02 [Page 20]
+
+INTERNET-DRAFT LDAP X.509 Schema 18 July 2005
+
+
+ id-permittedSubtrees =
+ %x70.65.72.6D.69.74.74.65.64.53.75.62.74.72.65.65.73
+ ; 'permittedSubtrees'
+ id-excludedSubtrees =
+ %x65.78.63.6C.75.64.65.64.53.75.62.74.72.65.65.73
+ ; 'excludedSubtrees'
+
+ GeneralSubtrees = "{" sp GeneralSubtree
+ *( "," sp GeneralSubtree ) sp "}"
+ GeneralSubtree = "{" sp gs-base
+ [ "," sp gs-minimum ]
+ [ "," sp gs-maximum ] sp "}"
+
+ gs-base = id-base msp GeneralName
+ gs-minimum = id-minimum msp BaseDistance
+ gs-maximum = id-maximum msp BaseDistance
+
+ id-base = %x62.61.73.65 ; 'base'
+ id-minimum = %x6D.69.6E.69.6D.75.6D ; 'minimum'
+ id-maximum = %x6D.61.78.69.6D.75.6D ; 'maximum'
+
+ BaseDistance = INTEGER-0-MAX
+
+
+A.3. CertificatePairExactAssertion
+
+ CertificatePairExactAssertion = "{" [ sp cpea-issuedTo ]
+ [sep sp cpea-issuedBy ] sp "}"
+ ;; At least one of <cpea-issuedTo> or <cpea-issuedBy> MUST be present.
+
+ cpea-issuedTo = id-issuedToThisCAAssertion msp
+ CertificateExactAssertion
+ cpea-issuedBy = id-issuedByThisCAAssertion msp
+ CertificateExactAssertion
+
+ id-issuedToThisCAAssertion = %x69.73.73.75.65.64.54.6F.54.68.69.73
+ %x43.41.41.73.73.65.72.74.69.6F.6E ; 'issuedToThisCAAssertion'
+ id-issuedByThisCAAssertion = %x69.73.73.75.65.64.42.79.54.68.69.73
+ %x43.41.41.73.73.65.72.74.69.6F.6E ; 'issuedByThisCAAssertion'
+
+
+A.4. CertificatePairAssertion
+
+ CertificatePairAssertion = "{" [ sp cpa-issuedTo ]
+ [sep sp cpa-issuedBy ] sp "}"
+ ;; At least one of <cpa-issuedTo> and <cpa-issuedBy> MUST be present.
+
+ cpa-issuedTo = id-issuedToThisCAAssertion msp CertificateAssertion
+
+
+
+Zeilenga draft-zeilenga-ldap-x509-02 [Page 21]
+
+INTERNET-DRAFT LDAP X.509 Schema 18 July 2005
+
+
+ cpa-issuedBy = id-issuedByThisCAAssertion msp CertificateAssertion
+
+
+A.5. CertificateListExactAssertion
+
+ CertificateListExactAssertion = "{" sp clea-issuer ","
+ sp clea-thisUpdate
+ [ "," sp clea-distributionPoint ] sp "}"
+
+ clea-issuer = id-issuer msp Name
+ clea-thisUpdate = id-thisUpdate msp Time
+ clea-distributionPoint = id-distributionPoint msp
+ DistributionPointName
+
+ id-thisUpdate = %x74.68.69.73.55.70.64.61.74.65 ; 'thisUpdate'
+ id-distributionPoint =
+ %x64.69.73.74.72.69.62.75.74.69.6F.6E.50.6F.69.6E.74
+ ; 'distributionPoint'
+
+ DistributionPointName = dpn-fullName / dpn-nameRelativeToCRLIssuer
+
+ dpn-fullName = id-fullName ":" GeneralNames
+ dpn-nameRelativeToCRLIssuer = id-nameRelativeToCRLIssuer ":"
+ RelativeDistinguishedName
+
+ id-fullName = %x66.75.6C.6C.4E.61.6D.65 ; 'fullName'
+ id-nameRelativeToCRLIssuer = %x6E.61.6D.65.52.65.6C.61.74.69.76.65
+ %x54.6F.43.52.4C.49.73.73.75.65.72 ; 'nameRelativeToCRLIssuer'
+
+
+A.6. CertificateListAssertion
+
+ CertificateListAssertion = "{" [ sp cla-issuer ]
+ [ sep sp cla-minCRLNumber ]
+ [ sep sp cla-maxCRLNumber ]
+ [ sep sp cla-reasonFlags ]
+ [ sep sp cla-dateAndTime ]
+ [ sep sp cla-distributionPoint ]
+ [ sep sp cla-authorityKeyIdentifier ] sp "}"
+
+ cla-issuer = id-issuer msp Name
+ cla-minCRLNumber = id-minCRLNumber msp CRLNumber
+ cla-maxCRLNumber = id-maxCRLNumber msp CRLNumber
+ cla-reasonFlags = id-reasonFlags msp ReasonFlags
+ cla-dateAndTime = id-dateAndTime msp Time
+
+ cla-distributionPoint = id-distributionPoint msp
+ DistributionPointName
+
+
+
+Zeilenga draft-zeilenga-ldap-x509-02 [Page 22]
+
+INTERNET-DRAFT LDAP X.509 Schema 18 July 2005
+
+
+ cla-authorityKeyIdentifier = id-authorityKeyIdentifier msp
+ AuthorityKeyIdentifier
+
+ id-minCRLNumber = %x6D.69.6E.43.52.4C.4E.75.6D.62.65.72
+ ; 'minCRLNumber'
+ id-maxCRLNumber = %x6D.61.78.43.52.4C.4E.75.6D.62.65.72
+ ; 'maxCRLNumber'
+ id-reasonFlags = %x72.65.61.73.6F.6E.46.6C.61.67.73 ; 'reasonFlags'
+ id-dateAndTime = %x64.61.74.65.41.6E.64.54.69.6D.65 ; 'dateAndTime'
+
+ CRLNumber = INTEGER-0-MAX
+
+ ReasonFlags = BIT-STRING
+ / "{" [ sp reason-flag *( "," sp reason-flag ) ] sp "}"
+
+ reason-flag = id-unused
+ / id-keyCompromise
+ / id-cACompromise
+ / id-affiliationChanged
+ / id-superseded
+ / id-cessationOfOperation
+ / id-certificateHold
+ / id-privilegeWithdrawn
+ / id-aACompromise
+
+ id-unused = %x75.6E.75.73.65.64 ; 'unused'
+ id-keyCompromise = %x6B.65.79.43.6F.6D.70.72.6F.6D.69.73.65
+ ; 'keyCompromise'
+ id-cACompromise = %x63.41.43.6F.6D.70.72.6F.6D.69.73.65
+ ; 'cACompromise'
+ id-affiliationChanged =
+ %x61.66.66.69.6C.69.61.74.69.6F.6E.43.68.61.6E.67.65.64
+ ; 'affiliationChanged'
+ id-superseded = %x73.75.70.65.72.73.65.64.65.64 ; 'superseded'
+ id-cessationOfOperation =
+ %x63.65.73.73.61.74.69.6F.6E.4F.66.4F.70.65.72.61.74.69.6F.6E
+ ; 'cessationOfOperation'
+ id-certificateHold = %x63.65.72.74.69.66.69.63.61.74.65.48.6F.6C.64
+ ; 'certificateHold'
+ id-privilegeWithdrawn =
+ %x70.72.69.76.69.6C.65.67.65.57.69.74.68.64.72.61.77.6E
+ ; 'privilegeWithdrawn'
+ id-aACompromise = %x61.41.43.6F.6D.70.72.6F.6D.69.73.65
+ ; 'aACompromise'
+
+
+A.7. AlgorithmIdentifier
+
+
+
+
+Zeilenga draft-zeilenga-ldap-x509-02 [Page 23]
+
+INTERNET-DRAFT LDAP X.509 Schema 18 July 2005
+
+
+ AlgorithmIdentifier = "{" sp ai-algorithm
+ [ "," sp ai-parameters ] sp "}"
+
+ ai-algorithm = id-algorithm msp OBJECT-IDENTIFIER
+ ai-parameters = id-parameters msp Value
+ id-algorithm = %x61.6C.67.6F.72.69.74.68.6D ; 'algorithm'
+ id-parameters = %x70.61.72.61.6D.65.74.65.72.73 ; 'parameters'
+
+
+
+Intellectual Property Rights
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be found
+ in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this specification
+ can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr at ietf.org.
+
+
+
+Full Copyright
+
+ Copyright (C) The Internet Society (2005).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+
+
+
+Zeilenga draft-zeilenga-ldap-x509-02 [Page 24]
+
+INTERNET-DRAFT LDAP X.509 Schema 18 July 2005
+
+
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga draft-zeilenga-ldap-x509-02 [Page 25]
+
Added: openldap/vendor/openldap-release/doc/drafts/draft-zeilenga-ldup-sync-xx.txt
===================================================================
--- openldap/vendor/openldap-release/doc/drafts/draft-zeilenga-ldup-sync-xx.txt (rev 0)
+++ openldap/vendor/openldap-release/doc/drafts/draft-zeilenga-ldup-sync-xx.txt 2007-09-15 10:38:52 UTC (rev 844)
@@ -0,0 +1,1792 @@
+
+
+INTERNET-DRAFT Kurt D. Zeilenga
+Intended Category: Experimental OpenLDAP Foundation
+Expires in six months Jong Hyuk Choi
+ IBM Corporation
+
+ 3 February 2004
+
+
+
+
+ The LDAP Content Synchronization Operation
+ <draft-zeilenga-ldup-sync-05.txt>
+
+
+
+
+Status of this Memo
+
+ This document is an Internet-Draft and is in full conformance with all
+ provisions of Section 10 of RFC2026.
+
+ Distribution of this memo is unlimited. Technical discussion of this
+ document will take place on the IETF LDUP Working Group mailing list
+ at <ietf-ldup at imc.org>. Please send editorial comments directly to
+ the document editor at <Kurt at OpenLDAP.org>.
+
+ Internet-Drafts are working documents of the Internet Engineering Task
+ Force (IETF), its areas, and its working groups. Note that other
+ groups may also distribute working documents as Internet-Drafts.
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference
+ material or to cite them other than as ``work in progress.''
+
+ The list of current Internet-Drafts can be accessed at
+ <http://www.ietf.org/ietf/1id-abstracts.txt>. The list of
+ Internet-Draft Shadow Directories can be accessed at
+ <http://www.ietf.org/shadow.html>.
+
+ Copyright (C) The Internet Society (2004). All Rights Reserved.
+
+ Please see the Full Copyright section near the end of this document
+ for more information.
+
+
+
+
+
+
+
+
+Zeilenga LDAP Content Sync Operation [Page 1]
+
+INTERNET-DRAFT draft-zeilenga-ldup-sync-05 3 February 2004
+
+
+Abstract
+
+ This specification describes the LDAP (Lightweight Directory Access
+ Protocol) Content Synchronization Operation. The operation allows a
+ client to maintain a copy of a fragment of directory information tree.
+ It supports both polling for changes and listening for changes. The
+ operation is defined as an extension of the LDAP Search Operation.
+
+
+Table of Contents
+
+ Status of this Memo 1
+ Abstract 2
+ Table of Contents
+ 1. Introduction 3
+ 1.1. Background
+ 1.2. Intended Usage 4
+ 1.3. Overview 5
+ 1.4. Conventions
+ 2. Elements of the Sync Operation 8
+ 2.1. Common ASN.1 Elements 9
+ 2.2. Sync Request Control
+ 2.3. Sync State Control
+ 2.4. Sync Done Control 10
+ 2.5. Sync Info Message
+ 2.6. Sync Result Codes 11
+ 3. Content Synchronization
+ 3.1. Synchronization Session
+ 3.2. Content Determination 12
+ 3.3. refreshOnly Mode 13
+ 3.4. refreshAndPersist Mode 16
+ 3.5. Search Request Parameters 17
+ 3.6. objectName Issues 18
+ 3.7. Canceling the Sync Operation 19
+ 3.8. Refresh Required
+ 3.9. Chattiness Considerations 20
+ 3.10. Operation Multiplexing 21
+ 4. Meta Information Considerations 22
+ 4.1. Entry DN
+ 4.2. Operational Attributes
+ 4.3. Collective Attributes 23
+ 4.4. Access and Other Administrative Controls
+ 5. Interaction with Other Controls
+ 5.1. ManageDsaIT Control 24
+ 5.2. Subentries Control
+ 6. Shadowing Considerations
+ 7. Security Considerations 25
+ 8. IANA Considerations
+
+
+
+Zeilenga LDAP Content Sync Operation [Page 2]
+
+INTERNET-DRAFT draft-zeilenga-ldup-sync-05 3 February 2004
+
+
+ 8.1. Object Identifier 26
+ 8.2. LDAP Protocol Mechanism
+ 8.3. LDAP Result Codes
+ 9. Acknowledgments
+ 10. Normative References 27
+ 11. Informative References 28
+ 12. Authors' Addresses 29
+ Appendix A. CSN-based Implementation Considerations
+ Intellectual Property Rights 31
+ Full Copyright
+
+
+1. Introduction
+
+ The Lightweight Directory Access Protocol (LDAP) [RFC3377] provides a
+ mechanism, the search operation [RFC2251], which allows a client to
+ request directory content matching a complex set of assertions and for
+ the server to return this content, subject to access control and other
+ restrictions, to the client. However, LDAP does not provide (despite
+ the introduction of numerous extensions in this area) an effective and
+ efficient mechanism for maintaining synchronized copies of directory
+ content. This document introduces a new mechanism specifically
+ designed to met the content synchronization requirements of
+ sophisticated directory applications.
+
+ This document defines the LDAP Content Synchronization Operation, or
+ Sync Operation for short, which allows a client to maintain a
+ synchronized copy of a fragment of a Directory Information Tree (DIT).
+ The Sync Operation is defined as a set of controls and other protocol
+ elements which extend the Search Operation.
+
+
+1.1. Background
+
+ Over the years, a number of content synchronization approaches have
+ been suggested for use in LDAP directory services. These approaches
+ are inadequate for one or more of the following reasons:
+
+ - fail to ensure a reasonable level of convergence;
+ - fail to detect that convergence cannot be achieved (without
+ reload);
+ - require pre-arranged synchronization agreements;
+ - require the server to maintain histories of past changes to DIT
+ content and/or meta information;
+ - require the server to maintain synchronization state on a per
+ client basis; and/or
+ - are overly chatty.
+
+
+
+
+Zeilenga LDAP Content Sync Operation [Page 3]
+
+INTERNET-DRAFT draft-zeilenga-ldup-sync-05 3 February 2004
+
+
+ The Sync Operation provides eventual convergence of synchronized
+ content when possible and, when not, notification that a full reload
+ is required.
+
+ The Sync Operation does not require pre-arranged synchronization
+ agreements.
+
+ The Sync Operation does not require servers to maintain nor to use any
+ history of past changes to the DIT or to meta information. However,
+ servers may maintain and use histories (e.g., change logs, tombstones,
+ DIT snapshots) to reduce the number of messages generated and to
+ reduce their size. As it is not always feasible to maintain and use
+ histories, the operation may be implemented using purely (current)
+ state-based approaches. The Sync Operation allows use of either the
+ state-based approach or the history-based approach in an operation by
+ operation basis to balance the size of history and the amount of
+ traffic. The Sync Operation also allows the combined use of the
+ state-based and the history-based approaches.
+
+ The Sync Operation does not require servers to maintain
+ synchronization state on a per client basis. However, servers may
+ maintain and use per client state information to reduce the number of
+ messages generated and the size of such messages.
+
+ A synchronization mechanism can be considered overly chatty when
+ synchronization traffic is not reasonably bounded. The Sync Operation
+ traffic is bounded by the size of updated (or new) entries and the
+ number of unchanged entries in the content. The operation is designed
+ to avoid full content exchanges even in the case that the history
+ information available to the server is insufficient to determine the
+ client's state. The operation is also designed to avoid transmission
+ of out-of-content history information, as its size is not bounded by
+ the content and it is not always feasible to transmit such history
+ information due to security reasons.
+
+ This document includes a number of non-normative appendices providing
+ additional information to server implementors.
+
+
+1.2. Intended Usage
+
+ The Sync Operation is intended to be used in applications requiring
+ eventually-convergent content synchronization. Upon completion of
+ each synchronization stage of the operation, all information to
+ construct a synchronized client copy of the content has been provided
+ to the client or the client has been notified that a complete content
+ reload is necessary. Except for transient inconsistencies due to
+ concurrent operation (or other) processing at the server, the client
+
+
+
+Zeilenga LDAP Content Sync Operation [Page 4]
+
+INTERNET-DRAFT draft-zeilenga-ldup-sync-05 3 February 2004
+
+
+ copy is an accurate reflection of the content held by the server.
+ Transient inconsistencies will be resolved by subsequent
+ synchronization operations.
+
+ Possible uses include:
+ - White page service applications may use the Sync Operation to
+ maintain current copy of a DIT fragment. For example, a mail user
+ agent which uses the sync operation to maintain a local copy of an
+ enterprise address book.
+
+ - Meta-information engines may use the Sync Operation to maintain a
+ copy of a DIT fragment.
+
+ - Caching proxy services may use the Sync Operation to maintain a
+ coherent content cache.
+
+ - Lightweight master-slave replication between heterogeneous
+ directory servers. For example, the Sync Operation can be used by
+ a slave server to maintain a shadow copy of a DIT fragment.
+ (Note: The International Telephone Union (ITU) has defined the
+ X.500 Directory [X.500] Information Shadowing Protocol (DISP)
+ [X.525] which may be used for master-slave replication between
+ directory servers. Other experimental LDAP replication protocols
+ also exist.)
+
+ This protocol is not intended to be used in applications requiring
+ transactional data consistency.
+
+ As this protocol transfers all visible values of entries belonging to
+ the content upon change instead of change deltas, this protocol is not
+ appropriate for bandwidth-challenged applications or deployments.
+
+
+1.3. Overview
+
+ This section provides an overview of basic ways the Sync Operation can
+ be used to maintain a synchronized client copy of a DIT fragment.
+
+ - Polling for Changes: refreshOnly mode
+ - Listening for Changes: refreshAndPersist mode
+
+
+1.3.1. Polling for Changes (refreshOnly)
+
+ To obtain its initial client copy, the client issues a Sync request: a
+ search request with the Sync Request Control with mode set to
+ refreshOnly. The server, much like it would with a normal search
+ operation, returns (subject to access controls and other restrictions)
+
+
+
+Zeilenga LDAP Content Sync Operation [Page 5]
+
+INTERNET-DRAFT draft-zeilenga-ldup-sync-05 3 February 2004
+
+
+ the content matching the search criteria (baseObject, scope, filter,
+ attributes). Additionally, with each entry returned, the server
+ provides a Sync State Control indicating state add. This control
+ contains the Universally Unique Identifier (UUID) [UUID] of the entry
+ [EntryUUID]. Unlike the Distinguished Name (DN), which may change
+ over time, an entry's UUID is stable. The initial content is followed
+ by a SearchResultDone with a Sync Done Control. The Sync Done Control
+ provides a syncCookie. The syncCookie represents session state.
+
+ To poll for updates to the client copy, the client reissues the Sync
+ Operation with the syncCookie previously returned. The server, much
+ as it would with a normal search operation, determines which content
+ would be returned as if the operation was a normal search operation.
+ However, using the syncCookie as an indicator of what content the
+ client was sent previously, the server sends copies of entries which
+ have changed with a Sync State Control indicating state add. For each
+ changed entry, all (modified or unmodified) attributes belonging to
+ the content are sent.
+
+ The server may perform either or both of the two distinct
+ synchronization phases which are distinguished by how to synchronize
+ entries deleted from the content: the present and the delete phases.
+ When the server uses a single phase for the refresh stage, each phase
+ is marked as ended by a SearchResultDone with a Sync Done Control. A
+ present phase is identified by a FALSE refreshDeletes value in the
+ Sync Done Control. A delete phase is identified by a TRUE
+ refreshDeletes value. The present phase may be followed by a delete
+ phase. The two phases are delimited by a refreshPresent Sync Info
+ Message having a FALSE refreshDone value. In the case that both the
+ phases are used, the present phase is used to bring the client copy up
+ to the state at which the subsequent delete phase can begin.
+
+ In the present phase, the server sends an empty entry (i.e., no
+ attributes) with a Sync State Control indicating state present for
+ each unchanged entry.
+
+ The delete phase may be used when the server can reliably determine
+ which entries in the prior client copy are no longer present in the
+ content and the number of such entries is less than or equal to the
+ number of unchanged entries. In the delete mode, the server sends an
+ empty entry with a Sync State Control indicating state delete for each
+ entry which is no longer in the content, instead of returning an empty
+ entry with state present for each present entry.
+
+ The server may send syncIdSet Sync Info Messages containing the set of
+ UUIDs of either unchanged present entries or deleted entries, instead
+ of sending multiple individual messages. If refreshDeletes of
+ syncIdSet is set to FALSE, the UUIDs of unchanged present entries are
+
+
+
+Zeilenga LDAP Content Sync Operation [Page 6]
+
+INTERNET-DRAFT draft-zeilenga-ldup-sync-05 3 February 2004
+
+
+ contained in the syncUUIDs set; if refreshDeletes of syncIdSet is set
+ to TRUE, the UUIDs of the entries no longer present in the content are
+ contained in the syncUUIDs set. An optional cookie can be included in
+ the syncIdSet to represent the state of the content after
+ synchronizing the presence or the absence of the entries contained in
+ the syncUUIDs set.
+
+ The synchronized copy of the DIT fragment is constructed by the
+ client.
+
+ If refreshDeletes of syncDoneValue is FALSE, the new copy includes all
+ changed entries returned by the reissued Sync Operation as well as all
+ unchanged entries identified as being present by the reissued Sync
+ Operation, but whose content is provided by the previous Sync
+ Operation. The unchanged entries not identified as being present are
+ deleted from the client content. They had been either deleted, moved,
+ or otherwise scoped-out from the content.
+
+ If refreshDeletes of syncDoneValue is TRUE, the new copy includes all
+ changed entries returned by the reissued Sync Operation as well as all
+ other entries of the previous copy except for those which are
+ identified as having been deleted from the content.
+
+ The client can, at some later time, re-poll for changes to this
+ synchronized client copy.
+
+
+1.3.2. Listening for Changes (refreshAndPersist)
+
+ Polling for changes can be expensive in terms of server, client, and
+ network resources. The refreshAndPersist mode allows for active
+ updates of changed entries in the content.
+
+ By selecting the refreshAndPersist mode, the client requests the
+ server to send updates of entries that are changed after the initial
+ refresh content is determined. Instead of sending a SearchResultDone
+ Message as in polling, the server sends a Sync Info Message to the
+ client indicating that the refresh stage is complete and then enters
+ the persist stage. After receipt of this Sync Info Message, the
+ client will construct a synchronized copy as described in Section
+ 1.3.1.
+
+ The server may then send change notifications as the result of the
+ original Sync search request which now remains persistent in the
+ server. For entries to be added to the returned content, the server
+ sends a SearchResultEntry (with attributes) with a Sync State Control
+ indicating state add. For entries to be deleted from the content, the
+ server sends a SearchResultEntry containing no attributes and a Sync
+
+
+
+Zeilenga LDAP Content Sync Operation [Page 7]
+
+INTERNET-DRAFT draft-zeilenga-ldup-sync-05 3 February 2004
+
+
+ State Control indicating state delete. For entries to be modified in
+ the return content, the server sends a SearchResultEntry (with
+ attributes) with a Sync State Control indicating state modify. Upon
+ modification of an entry, all (modified or unmodified) attributes
+ belonging to the content are sent.
+
+ Note that renaming an entry of the DIT may cause an add state change
+ where the entry is renamed into the content, a delete state change
+ where the entry is renamed out of the content, and a modify state
+ change where the entry remains in the content. Also note that a
+ modification of an entry of the DIT may cause an add, delete, or
+ modify state change to the content.
+
+ Upon receipt of a change notification, the client updates its copy of
+ the content.
+
+ If the server desires to update the syncCookie during the persist
+ stage, it may include the syncCookie in any Sync State Control or Sync
+ Info Message returned.
+
+ The operation persists until canceled [CANCEL] by the client or
+ terminated by the server. A Sync Done Control shall be attached to
+ SearchResultDone Message to provide a new syncCookie.
+
+
+1.4. Conventions
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in BCP 14 [RFC2119].
+
+ Protocol elements are described using ASN.1 [X.680] with implicit
+ tags. The term "BER-encoded" means the element is to be encoded using
+ the Basic Encoding Rules [X.690] under the restrictions detailed in
+ Section 5.1 of [RFC2251].
+
+
+2. Elements of the Sync Operation
+
+ The Sync Operation is defined as an extension to the LDAP Search
+ Operation [RFC2251] where the directory user agent (DUA or client)
+ submits a SearchRequest Message with a Sync Request Control and the
+ directory system agent (DSA or server) responses with zero or more
+ SearchResultEntry Messages, each with a Sync State Control; zero or
+ more SearchResultReference Messages, each with a Sync State Control;
+ zero or more Sync Info Intermediate Response Messages; and a
+ SearchResultDone Message with a Sync Done Control.
+
+
+
+
+Zeilenga LDAP Content Sync Operation [Page 8]
+
+INTERNET-DRAFT draft-zeilenga-ldup-sync-05 3 February 2004
+
+
+ To allow clients to discover support for this operation, servers
+ implementing this operation SHOULD publish the
+ 1.3.6.1.4.1.4203.1.9.1.1 as a value of 'supportedControl' attribute
+ [RFC2252] of the root DSA-specific entry (DSE). A server MAY choose
+ to advertise this extension only when the client is authorized to use
+ it.
+
+
+2.1 Common ASN.1 Elements
+
+2.1.1 syncUUID
+
+ The syncUUID data type is an OCTET STRING holding a 128-bit (16-octet)
+ Universally Unique Identifier (UUID) [UUID].
+
+ syncUUID ::= OCTET STRING (SIZE(16))
+ -- constrained to UUID
+
+
+2.1.2 syncCookie
+
+ The syncCookie is a notational convenience to indicate that, while the
+ syncCookie type is encoded as an OCTET STRING, its value is an opaque
+ value containing information about the synchronization session and its
+ state. Generally, the session information would include a hash of the
+ operation parameters which the server requires not be changed and the
+ synchronization state information would include a commit (log)
+ sequence number, a change sequence number, or a time stamp. For
+ convenience of description, the term no cookie refers either to null
+ cookie or to a cookie with pre-initialized synchronization state.
+
+ syncCookie ::= OCTET STRING
+
+
+2.2 Sync Request Control
+
+ The Sync Request Control is an LDAP Control [RFC2251, Section 4.1.2]
+ where the controlType is the object identifier
+ 1.3.6.1.4.1.4203.1.9.1.1 and the controlValue, an OCTET STRING,
+ contains a BER-encoded syncRequestValue. The criticality field is
+ either TRUE or FALSE.
+
+ syncRequestValue ::= SEQUENCE {
+ mode ENUMERATED {
+ -- 0 unused
+ refreshOnly (1),
+ -- 2 reserved
+ refreshAndPersist (3)
+
+
+
+Zeilenga LDAP Content Sync Operation [Page 9]
+
+INTERNET-DRAFT draft-zeilenga-ldup-sync-05 3 February 2004
+
+
+ },
+ cookie syncCookie OPTIONAL,
+ reloadHint BOOLEAN DEFAULT FALSE
+ }
+
+ The Sync Request Control is only applicable to the SearchRequest
+ Message.
+
+
+2.3 Sync State Control
+
+ The Sync State Control is an LDAP Control [RFC2251, Section 4.1.2]
+ where the controlType is the object identifier
+ 1.3.6.1.4.1.4203.1.9.1.2 and the controlValue, an OCTET STRING,
+ contains a BER-encoded syncStateValue. The criticality is FALSE.
+
+ syncStateValue ::= SEQUENCE {
+ state ENUMERATED {
+ present (0),
+ add (1),
+ modify (2),
+ delete (3)
+ },
+ entryUUID syncUUID,
+ cookie syncCookie OPTIONAL
+ }
+
+ The Sync State Control is only applicable to SearchResultEntry and
+ SearchResultReference Messages.
+
+
+2.4 Sync Done Control
+
+ The Sync Done Control is an LDAP Control [RFC2251, Section 4.1.2]
+ where the controlType is the object identifier
+ 1.3.6.1.4.1.4203.1.9.1.3 and the controlValue contains a BER-encoded
+ syncDoneValue. The criticality is FALSE (and hence absent).
+
+ syncDoneValue ::= SEQUENCE {
+ cookie syncCookie OPTIONAL,
+ refreshDeletes BOOLEAN DEFAULT FALSE
+ }
+
+ The Sync Done Control is only applicable to SearchResultDone Message.
+
+
+2.5 Sync Info Message
+
+
+
+
+Zeilenga LDAP Content Sync Operation [Page 10]
+
+INTERNET-DRAFT draft-zeilenga-ldup-sync-05 3 February 2004
+
+
+ The Sync Info Message is an LDAP Intermediate Response Message
+ [LDAPIRM] where responseName is the object identifier
+ 1.3.6.1.4.1.4203.1.9.1.4 and responseValue contains a BER-encoded
+ syncInfoValue. The criticality is FALSE (and hence absent).
+
+ syncInfoValue ::= CHOICE {
+ newcookie [0] syncCookie,
+ refreshDelete [1] SEQUENCE {
+ cookie syncCookie OPTIONAL,
+ refreshDone BOOLEAN DEFAULT TRUE
+ },
+ refreshPresent [2] SEQUENCE {
+ cookie syncCookie OPTIONAL,
+ refreshDone BOOLEAN DEFAULT TRUE
+ },
+ syncIdSet [3] SEQUENCE {
+ cookie syncCookie OPTIONAL,
+ refreshDeletes BOOLEAN DEFAULT FALSE,
+ syncUUIDs SET OF syncUUID
+ }
+ }
+
+
+2.6 Sync Result Codes
+
+ The following LDAP resultCode [RFC2251] is defined:
+
+ e-syncRefreshRequired (IANA-ASSIGNED-CODE)
+
+
+3. Content Synchronization
+
+ The Sync Operation is invoked by the client sending a SearchRequest
+ Message with a Sync Request Control.
+
+ The absence of a cookie or an initialized synchronization state in a
+ cookie indicates a request for initial content while the presence of a
+ cookie representing a state of a client copy indicates a request for
+ content update. Synchronization Sessions are discussed in Section
+ 3.1. Content Determination is discussed in Section 3.2.
+
+ The mode is either refreshOnly or refreshAndPersist. The refreshOnly
+ and refreshAndPersist modes are discussed in Section 3.3 and Section
+ 3.4, respectively. The refreshOnly mode consists only of a refresh
+ stage, while the refreshAndPersist mode consists of a refresh stage
+ and a subsequent persist stage.
+
+
+
+
+
+Zeilenga LDAP Content Sync Operation [Page 11]
+
+INTERNET-DRAFT draft-zeilenga-ldup-sync-05 3 February 2004
+
+
+3.1. Synchronization Session
+
+ A sequence of Sync Operations where the last cookie returned by the
+ server for one operation is provided by the client in the next
+ operation are said to belong to the same Synchronization Session.
+
+ The client MUST specify the same content controlling parameters (see
+ Section 3.5) in each Search Request of the session. The client SHOULD
+ also issue each Sync request of a session under the same
+ authentication and authorization associations with equivalent
+ integrity and protections. If the server does not recognize the
+ request cookie or the request is made under different associations or
+ non-equivalent protections, the server SHALL return the initial
+ content as if no cookie had been provided or return an empty content
+ with the e-syncRefreshRequired LDAP result code. The decision between
+ the return of the initial content and the return of the empty content
+ with the e-syncRefreshRequired result code MAY be based on reloadHint
+ in the Sync Request Control from the client. If the server recognizes
+ the request cookie as representing empty or initial synchronization
+ state of the client copy, the server SHALL return the initial content.
+
+ A Synchronization Session may span multiple LDAP sessions between the
+ client and the server. The client SHOULD issue each Sync request of a
+ session to the same server. (Note: Shadowing considerations are
+ discussed in Section 6.)
+
+
+3.2. Content Determination
+
+ The content to be provided is determined by parameters of the Search
+ Request, as described in [RFC2251], and possibly other controls. The
+ same content parameters SHOULD be used in each Sync request of a
+ session. If different content is requested and the server is
+ unwilling or unable to process the request, the server SHALL return
+ the initial content as if no cookie had been provided or return an
+ empty content with the e-syncRefreshRequired LDAP result code. The
+ decision between the return of the initial content and the return of
+ the empty content with the e-syncRefreshRequired result code MAY be
+ based on reloadHint in the Sync Request Control from the client.
+
+ The content may not necessarily include all entries or references
+ which would be returned by a normal search operation nor, for those
+ entries included, not all attributes returned by a normal search.
+ When the server is unwilling or unable to provide synchronization for
+ any attribute for a set of entries, the server MUST treat all filter
+ components matching against these attributes as Undefined and MUST NOT
+ return these attributes in SearchResultEntry responses.
+
+
+
+
+Zeilenga LDAP Content Sync Operation [Page 12]
+
+INTERNET-DRAFT draft-zeilenga-ldup-sync-05 3 February 2004
+
+
+ Servers SHOULD support synchronization for all non-collective
+ user-application attributes for all entries.
+
+ The server may also return continuation references to other servers or
+ to itself. The latter is allowed as the server may partition the
+ entries it holds into separate synchronization contexts.
+
+ The client may chase all or some of these continuations, each as a
+ separate content synchronization session.
+
+
+3.3. refreshOnly Mode
+
+ A Sync request with mode refreshOnly and with no cookie is a poll for
+ initial content. A Sync request with mode refreshOnly and with a
+ cookie representing a synchronization state is a poll for content
+ update.
+
+
+3.3.1. Initial Content Poll
+
+ Upon receipt of the request, the server provides the initial content
+ using a set of zero or more SearchResultEntry and
+ SearchResultReference Messages followed by a SearchResultDone Message.
+
+ Each SearchResultEntry Message SHALL include a Sync State Control of
+ state add, entryUUID containing the entry's UUID, and no cookie. Each
+ SearchResultReference Message SHALL include a Sync State Control of
+ state add, entryUUID containing the UUID associated with the reference
+ (normally the UUID of the associated named referral [RFC3296] object),
+ and no cookie. The SearchResultDone Message SHALL include a Sync Done
+ Control having refreshDeletes set to FALSE.
+
+ A resultCode value of success indicates the operation successfully
+ completed. Otherwise, the result code indicates the nature of
+ failure. The server may return e-syncRefreshRequired result code on
+ the initial content poll if it is safe to do so when it is unable to
+ perform the operation due to various reasons. reloadHint is set to
+ FALSE in the SearchRequest Message requesting the initial content
+ poll.
+
+ If the operation is successful, a cookie representing the
+ synchronization state of the current client copy SHOULD be returned
+ for use in subsequent Sync Operations.
+
+
+3.3.2. Content Update Poll
+
+
+
+
+Zeilenga LDAP Content Sync Operation [Page 13]
+
+INTERNET-DRAFT draft-zeilenga-ldup-sync-05 3 February 2004
+
+
+ Upon receipt of the request the server provides the content refresh
+ using a set of zero or more SearchResultEntry and
+ SearchResultReference Messages followed by a SearchResultDone Message.
+
+ The server is REQUIRED to either:
+ a) provide the sequence of messages necessary for eventual
+ convergence of the client's copy of the content to the server's
+ copy,
+
+ b) treat the request as an initial content request (e.g., ignore
+ the cookie or the synchronization state represented in the
+ cookie),
+
+ c) indicate that the incremental convergence is not possible by
+ returning e-syncRefreshRequired,
+
+ d) return a resultCode other than success or
+ e-syncRefreshRequired.
+
+ A Sync Operation may consist of a single present phase, a single
+ delete phase, or a present phase followed by a delete phase.
+
+ In each phase, for each entry or reference which has been added to the
+ content or been changed since the previous Sync Operation indicated by
+ the cookie, the server returns a SearchResultEntry or
+ SearchResultReference Message, respectively, each with a Sync State
+ Control consisting of state add, entryUUID containing the UUID of the
+ entry or reference, and no cookie. Each SearchResultEntry Message
+ represents the current state of a changed entry. Each
+ SearchResultReference Message represents the current state of a
+ changed reference.
+
+ In the present phase, for each entry which has not been changed since
+ the previous Sync Operation, an empty SearchResultEntry is returned
+ whose objectName reflects the entry's current DN, the attributes field
+ is empty, and a Sync State Control consisting of state present,
+ entryUUID containing the UUID of the entry, and no cookie. For each
+ reference which has not been changed since the previous Sync
+ Operation, an empty SearchResultReference containing an empty SEQUENCE
+ OF LDAPURL is returned with a Sync State Control consisting of state
+ present, entryUUID containing the UUID of the entry, and no cookie.
+ No messages are sent for entries or references which are no longer in
+ the content.
+
+ Multiple empty entries with a Sync State Control of state present
+ SHOULD be coalesced into one or more Sync Info Messages of syncIdSet
+ value with refreshDeletes set to FALSE. syncUUIDs contain a set of
+ UUIDs of the entries and references unchanged since the last Sync
+
+
+
+Zeilenga LDAP Content Sync Operation [Page 14]
+
+INTERNET-DRAFT draft-zeilenga-ldup-sync-05 3 February 2004
+
+
+ Operation. syncUUIDs may be empty. The Sync Info Message of
+ syncIdSet may contain cookie to represent the state of the content
+ after performing the synchronization of the entries in the set.
+
+ In the delete phase, for each entry no longer in the content, the
+ server returns a SearchResultEntry whose objectName reflects a past DN
+ of the entry or is empty, the attributes field is empty, and a Sync
+ State Control consisting of state delete, entryUUID containing the
+ UUID of the deleted entry, and no cookie. For each reference no
+ longer in the content, a SearchResultReference containing an empty
+ SEQUENCE OF LDAPURL is returned with a Sync State Control consisting
+ of state delete, entryUUID containing the UUID of the deleted
+ reference, and no cookie.
+
+ Multiple empty entries with a Sync State Control of state delete
+ SHOULD be coalesced into one or more Sync Info Messages of syncIdSet
+ value with refreshDeletes set to TRUE. syncUUIDs contain a set of
+ UUIDs of the entries and references which has been deleted from the
+ content since the last Sync Operation. syncUUIDs may be empty. The
+ Sync Info Message of syncIdSet may contain cookie to represent the
+ state of the content after performing the synchronization of the
+ entries in the set.
+
+ When a present phase is followed by a delete phase, the two phases are
+ delimited by a Sync Info Message containing syncInfoValue of
+ refreshPresent, which may contain cookie representing the state after
+ completing the present phase. The refreshPresent contains refreshDone
+ which is always FALSE in the refreshOnly mode of Sync Operation
+ because it is followed by a delete phase.
+
+ If a Sync Operation consists of a single phase, each phase and hence
+ the Sync Operation are marked ended by a SearchResultDone Message with
+ Sync Done Control which SHOULD contain cookie representing the state
+ of the content after completing the Sync Operation. The Sync Done
+ Control contains refreshDeletes which is set to FALSE for the present
+ phase and set to TRUE for the delete phase.
+
+ If a Sync Operation consists of a present phase followed by a delete
+ phase, the Sync Operation are marked ended at the end of the delete
+ phase by a SearchResultDone Message with Sync Done Control which
+ SHOULD contain cookie representing the state of the content after
+ completing the Sync Operation. The Sync Done Control contains
+ refreshDeletes which is set to TRUE.
+
+ The client can specify whether it prefers to receive an initial
+ content by supplying reloadHint of TRUE or to receive a
+ e-syncRefreshRequired resultCode by supplying reloadHint of FALSE
+ (hence absent), in the case that the server determines that it is
+
+
+
+Zeilenga LDAP Content Sync Operation [Page 15]
+
+INTERNET-DRAFT draft-zeilenga-ldup-sync-05 3 February 2004
+
+
+ impossible or inefficient to achieve the eventual convergence by
+ continuing the current incremental synchronization thread.
+
+ A resultCode value of success indicates the operation is successfully
+ completed. A resultCode value of e-syncRefreshRequired indicates that
+ a full or partial refresh is needed. Otherwise, the result code
+ indicates the nature of failure. A cookie is provided in the Sync
+ Done Control for use in subsequent Sync Operations for incremental
+ synchronization.
+
+
+3.4. refreshAndPersist Mode
+
+ A Sync request with mode refreshAndPersist asks for initial content or
+ content update (during the refresh stage) followed by change
+ notifications (during the persist stage).
+
+
+3.4.1. refresh Stage
+
+ The content refresh is provided as described in Section 3.3 excepting
+ that the successful completion of content refresh is indicated by
+ sending a Sync Info Message of refreshDelete or refreshPresent with a
+ refreshDone value set to TRUE instead of a SearchResultDone Message
+ with resultCode success. A cookie SHOULD be returned in the Sync Info
+ Message to represent the state of the content after finishing the
+ refresh stage of the Sync Operation.
+
+
+3.4.2. persist Stage
+
+ Change notifications are provided during the persist stage.
+
+ As updates are made to the DIT the server notifies the client of
+ changes to the content. DIT updates may cause entries and references
+ to be added to the content, deleted from the content, or modified
+ within the content. DIT updates may also cause references to be
+ added, deleted, or modified within the content.
+
+ Where DIT updates cause an entry to be added to the content, the
+ server provides a SearchResultEntry Message which represents the entry
+ as it appears in the content. The message SHALL include a Sync State
+ Control with state of add, entryUUID containing the entry's UUID, and
+ an optional cookie.
+
+ Where DIT updates cause a reference to be added to the content, the
+ server provides a SearchResultReference Message which represents the
+ reference in the content. The message SHALL include a Sync State
+
+
+
+Zeilenga LDAP Content Sync Operation [Page 16]
+
+INTERNET-DRAFT draft-zeilenga-ldup-sync-05 3 February 2004
+
+
+ Control with state of add, entryUUID containing the UUID associated
+ with the reference, and an optional cookie.
+
+ Where DIT updates cause an entry to be modified within the content,
+ the server provides a SearchResultEntry Message which represents the
+ entry as it appears in the content. The message SHALL include a Sync
+ State Control with state of modify, entryUUID containing the entry's
+ UUID, and an optional cookie.
+
+ Where DIT updates cause a reference to be modified within the content,
+ the server provides a SearchResultEntry Message which represents the
+ reference in the content. The message SHALL include a Sync State
+ Control with state of modify, entryUUID containing the UUID associated
+ with the reference, and an optional cookie.
+
+ Where DIT updates cause an entry to be deleted from the content, the
+ server provides a SearchResultReference Message with an empty SEQUENCE
+ OF LDAPURL. The message SHALL include a Sync State Control with state
+ of delete, entryUUID containing the UUID associated with the
+ reference, and an optional cookie.
+
+ Where DIT updates cause a reference to be deleted from the content,
+ the server provides a SearchResultEntry Message with no attributes.
+ The message SHALL include a Sync State Control with state of delete,
+ entryUUID containing the entry's UUID, and an optional cookie.
+
+ Multiple empty entries with a Sync State Control of state delete
+ SHOULD be coalesced into one or more Sync Info Messages of syncIdSet
+ value with refreshDeletes set to TRUE. syncUUIDs contain a set of
+ UUIDs of the entries and references which has been deleted from the
+ content. The Sync Info Message of syncIdSet may contain cookie to
+ represent the state of the content after performing the
+ synchronization of the entries in the set.
+
+ With each of these messages, the server may provide a new cookie to be
+ used in subsequent Sync Operations. Additionally, the server may also
+ return Sync Info Messages of choice newCookie to provide a new cookie.
+ The client SHOULD use the newest (last) cookie it received from the
+ server in subsequent Sync Operations.
+
+
+3.5. Search Request Parameters
+
+ As stated in Section 3.1, the client SHOULD specify the same content
+ controlling parameters in each Search Request of the session. All
+ fields of the SearchRequest Message are considered content controlling
+ parameters except for sizeLimit and timeLimit.
+
+
+
+
+Zeilenga LDAP Content Sync Operation [Page 17]
+
+INTERNET-DRAFT draft-zeilenga-ldup-sync-05 3 February 2004
+
+
+3.5.1. baseObject
+
+ As with the normal search operation, the refresh and persist stages
+ are not isolated from DIT changes. It is possible that the entry
+ referred to by the baseObject is deleted, renamed, or moved. It is
+ also possible that alias object used in finding the entry referred to
+ by the baseObject is changed such that the baseObject refers to a
+ different entry.
+
+ If the DIT is updated during processing of the Sync Operation in a
+ manner that causes the baseObject to no longer refer to any entry or
+ in a manner that changes the entry the baseObject refers to, the
+ server SHALL return an appropriate non-success result code such as
+ noSuchObject, aliasProblem, aliasDereferencingProblem, referral, or
+ e-syncRefreshRequired.
+
+
+3.5.2. derefAliases
+
+ This operation does not support alias dereferencing during searching.
+ The client SHALL specify neverDerefAliases or derefFindingBaseObj for
+ the SearchRequest derefAliases parameter. The server SHALL treat
+ other values (e.g., derefInSearching, derefAlways) as protocol errors.
+
+
+3.5.3. sizeLimit
+
+ The sizeLimit applies only to entries (regardless of their state in
+ Sync State Control) returned during the refreshOnly operation or the
+ refresh stage of the refreshAndPersist operation.
+
+
+3.5.4. timeLimit
+
+ For a refreshOnly Sync Operation, the timeLimit applies to the whole
+ operation. For a refreshAndPersist operation, the timeLimit applies
+ only to the refresh stage including the generation of the Sync Info
+ Message with a refreshDone value of TRUE.
+
+
+3.5.5. filter
+
+ The client SHOULD avoid filter assertions which apply to the values of
+ the attributes likely to be considered by the server as ones holding
+ meta-information. See Section 4.
+
+
+3.6. objectName
+
+
+
+Zeilenga LDAP Content Sync Operation [Page 18]
+
+INTERNET-DRAFT draft-zeilenga-ldup-sync-05 3 February 2004
+
+
+ The Sync Operation uses entryUUID values provided in the Sync State
+ Control as the primary keys to entries. The client MUST use these
+ entryUUIDs to correlate synchronization messages.
+
+ In some circumstances the DN returned may not reflect the entry's
+ current DN. In particular, when the entry is being deleted from the
+ content, the server may provide an empty DN if the server does not
+ wish to disclose the entry's current DN (or, if deleted from the DIT,
+ the entry's last DN).
+
+ It should also be noted that the entry's DN may be viewed as meta
+ information (see Section 4.1).
+
+
+3.7. Canceling the Sync Operation
+
+ Servers MUST implement the LDAP Cancel [CANCEL] Operation and support
+ cancellation of outstanding Sync Operations as described here.
+
+ To cancel an outstanding Sync Operation, the client issues an LDAP
+ Cancel [CANCEL] Operation.
+
+ If at any time the server becomes unwilling or unable to continue
+ processing a Sync Operation, the server SHALL return a
+ SearchResultDone with a non-success resultCode indicating the reason
+ for the termination of the operation.
+
+ Whether the client or the server initiated the termination, the server
+ may provide a cookie in the Sync Done Control for use in subsequent
+ Sync Operations.
+
+
+3.8. Refresh Required
+
+ In order to achieve the eventually-convergent synchronization, the
+ server may terminate the Sync Operation in the refresh or the persist
+ stage by returning a e-syncRefreshRequired resultCode to the client.
+ If no cookie is provided, a full refresh is needed. If a cookie
+ representing a synchronization state is provided in this response, an
+ incremental refresh is needed.
+
+ To obtain a full refresh, the client then issues a new synchronization
+ request with no cookie. To obtain an incremental reload, the client
+ issues a new synchronization with the provided cookie.
+
+ The server may choose to provide a full copy in the refresh stage
+ (e.g., ignore the cookie or the synchronization state represented in
+ the cookie) instead of providing an incremental refresh in order to
+
+
+
+Zeilenga LDAP Content Sync Operation [Page 19]
+
+INTERNET-DRAFT draft-zeilenga-ldup-sync-05 3 February 2004
+
+
+ achieve the eventual convergence.
+
+ The decision between the return of the initial content and the return
+ of the e-syncRefreshRequired result code may be based on reloadHint in
+ the Sync Request Control from the client.
+
+ In the case of persist stage Sync, the server returns the resultCode
+ of e-syncRefreshRequired to the client to indicate that the client
+ needs to issue a new Sync Operation in order to obtain a synchronized
+ copy of the content. If no cookie is provided, a full refresh is
+ needed. If a cookie representing a synchronization state is provided,
+ an incremental refresh is needed.
+
+ The server may also return e-syncRefreshRequired if it determines that
+ a refresh would be more efficient than sending all the messages
+ required for convergence.
+
+ It is noted that the client may receive one or more of
+ SearchResultEntry, SearchResultReference, and/or Sync Info Messages
+ before it receives SearchResultDone Message with the
+ e-syncRefreshRequired result code.
+
+
+3.9. Chattiness Considerations
+
+ The server MUST ensure that the number of entry messages generated to
+ refresh the client content does not exceed the number of entries
+ presently in the content. While there is no requirement for servers
+ to maintain history information, if the server has sufficient history
+ to allow it to reliably determine which entries in the prior client
+ copy are no longer present in the content and the number of such
+ entries is less than or equal to the number of unchanged entries, the
+ server SHOULD generate delete entry messages instead of present entry
+ messages (see Section 3.3.2).
+
+ When the amount of history information maintained in the server is not
+ enough for the clients to perform infrequent refreshOnly Sync
+ Operations, it is likely that the server has incomplete history
+ information (e.g. due to truncation) by the time those clients connect
+ again.
+
+ The server SHOULD NOT resort to full reload when the history
+ information is not enough to generate delete entry messages. The
+ server SHOULD generate either present entry messages only or present
+ entry messages followed by delete entry messages to bring the client
+ copy to the current state. In the latter case, the present entry
+ messages bring the client copy to a state covered by the history
+ information maintained in the server.
+
+
+
+Zeilenga LDAP Content Sync Operation [Page 20]
+
+INTERNET-DRAFT draft-zeilenga-ldup-sync-05 3 February 2004
+
+
+ The server SHOULD maintain enough (current or historical) state
+ information (such as a context-wide last modify time stamp) to
+ determine if no changes were made in the context since the content
+ refresh was provided and, and when no changes were made, generate zero
+ delete entry messages instead of present messages.
+
+ The server SHOULD NOT use the history information when its use does
+ not reduce the synchronization traffic or when its use can expose
+ sensitive information not allowed to be received by the client.
+
+ The server implementor should also consider chattiness issues which
+ span multiple Sync Operations of a session. As noted in Section 3.8,
+ the server may return e-syncRefreshRequired if it determines that a
+ reload would be more efficient than continuing under the current
+ operation. If reloadHint in the Sync Request is TRUE, the server may
+ initiate a reload without directing the client to request a reload.
+
+ The server SHOULD transfer a new cookie frequently to avoid having to
+ transfer information already provided to the client. Even where DIT
+ changes do not cause content synchronization changes to be
+ transferred, it may be advantageous to provide a new cookie using a
+ Sync Info Message. However, the server SHOULD avoid overloading the
+ client or network with Sync Info Messages.
+
+ During persist mode, the server SHOULD coalesce multiple outstanding
+ messages updating the same entry. The server MAY delay generation of
+ an entry update in anticipation of subsequent changes to that entry
+ which could be coalesced. The length of the delay should be long
+ enough to allow coalescing of update requests issued back to back but
+ short enough that the transient inconsistency induced by the delay is
+ corrected in a timely manner.
+
+ The server SHOULD use syncIdSet Sync Info Message when there are
+ multiple delete or present messages to reduce the amount of
+ synchronization traffic.
+
+ It is also noted that there may be many clients interested in a
+ particular directory change, and servers attempting to service all of
+ these at once may cause congestion on the network. The congestion
+ issues are magnified when the change requires a large transfer to each
+ interested client. Implementors and deployers of servers should take
+ steps to prevent and manage network congestion.
+
+
+3.10. Operation Multiplexing
+
+ The LDAP protocol model [RFC2251] allows operations to be multiplexed
+ over a single LDAP session. Clients SHOULD NOT maintain multiple LDAP
+
+
+
+Zeilenga LDAP Content Sync Operation [Page 21]
+
+INTERNET-DRAFT draft-zeilenga-ldup-sync-05 3 February 2004
+
+
+ sessions with the same server. Servers SHOULD ensure that responses
+ from concurrently processed operations are interleaved fairly.
+
+ Clients SHOULD combine Sync Operations whose result set is largely
+ overlapping. This avoids having to return multiple messages, once for
+ each overlapping session, for changes to entries in the overlap.
+
+ Clients SHOULD NOT combine Sync Operations whose result sets are
+ largely non-overlapping with each other. This ensures that an event
+ requiring a e-syncRefreshRequired response can be limited to as few
+ result sets as possible.
+
+
+4. Meta Information Considerations
+
+4.1. Entry DN
+
+ As an entry's DN is constructed from its relative DN (RDN) and the
+ entry's parent's DN, it is often viewed as meta information.
+
+ While renaming or moving to a new superior causes the entry's DN to
+ change, that change SHOULD NOT, by itself, cause synchronization
+ messages to be sent for that entry. However, if the renaming or the
+ moving could cause the entry to be added or deleted from the content,
+ appropriate synchronization messages should be generated to indicate
+ this to the client.
+
+ When a server treats the entry's DN as meta information, the server
+ SHALL either
+
+ - evaluate all MatchingRuleAssertions [RFC2251] to TRUE if
+ matching a value of an attribute of the entry and otherwise
+ Undefined, or
+ - evaluate all MatchingRuleAssertion with dnAttributes of TRUE as
+ Undefined.
+
+ The latter choice is offered for ease of server implementation.
+
+
+4.2. Operational Attributes
+
+ Where values of an operational attribute is determined by values not
+ held as part of the entry it appears in, the operational attribute
+ SHOULD NOT support synchronization of that operational attribute.
+
+ For example, in servers which implement X.501 subschema model [X.501],
+ servers should not support synchronization of the subschemaSubentry
+ attribute as its value is determined by values held and administrated
+
+
+
+Zeilenga LDAP Content Sync Operation [Page 22]
+
+INTERNET-DRAFT draft-zeilenga-ldup-sync-05 3 February 2004
+
+
+ in subschema subentries.
+
+ As a counter example, servers which implement aliases [RFC2256][X.501]
+ can support synchronization of the aliasedObjectName attribute as its
+ values are held and administrated as part of the alias entries.
+
+ Servers SHOULD support synchronization of the following operational
+ attributes: createTimestamp, modifyTimestamp, creatorsName,
+ modifiersName [RFC2252]. Servers MAY support synchronization of other
+ operational attributes.
+
+
+4.3. Collective Attributes
+
+ A collective attribute is "a user attribute whose values are the same
+ for each member of an entry collection" [X.501]. Use of collective
+ attributes in LDAP is discussed in [RFC3371].
+
+ Modification of a collective attribute generally affects the content
+ of multiple entries, which are the members of the collection. It is
+ inefficient to include values of collective attributes visible in
+ entries of the collection, as a single modification of a collective
+ attribute requires transmission of multiple SearchResultEntry (one for
+ each entry of the collection which the modification affected) to be
+ transmitted.
+
+ Servers SHOULD NOT synchronize collective attributes appearing in
+ entries of any collection. Servers MAY support synchronization of
+ collective attributes appearing in collective attribute subentries.
+
+
+4.4. Access and Other Administrative Controls
+
+ Entries are commonly subject to access and other administrative
+ Controls. While portions of the policy information governing a
+ particular entry may be held in the entry, policy information is often
+ held elsewhere (in superior entries, in subentries, in the root DSE,
+ in configuration files etc.). Because of this, changes to policy
+ information make it difficult to ensure eventual convergence during
+ incremental synchronization.
+
+ Where it is impractical or infeasible to generate content changes
+ resulting from a change to policy information, servers may opt to
+ return e-syncRefreshRequired or treat the Sync Operation as an initial
+ content request (e.g., ignore the cookie or the synchronization state
+ represented in the cookie).
+
+
+
+
+
+Zeilenga LDAP Content Sync Operation [Page 23]
+
+INTERNET-DRAFT draft-zeilenga-ldup-sync-05 3 February 2004
+
+
+5. Interaction with Other Controls
+
+ The Sync Operation may be used with:
+
+ - ManageDsaIT Control [RFC3296]
+ - Subentries Control [RFC3672]
+
+ as described below. The Sync Operation may be used with other LDAP
+ extensions as detailed in other documents.
+
+
+5.1. ManageDsaIT Control
+
+ The ManageDsaIT Control [RFC3296] indicates that the operation acts
+ upon the DSA Information Tree and causes referral and other special
+ entries to be treated as object entries with respect to the operation.
+
+
+5.2. Subentries Control
+
+ The Subentries Control is used with the search operation "to control
+ the visibility of entries and subentries which are within scope"
+ [RFC3672]. When used with the Sync Operation, the subentries control
+ and other factors (search scope, filter, etc.) are used to determine
+ whether an entry or subentry appear in the content or not.
+
+
+6. Shadowing Considerations
+
+ As noted in [RFC2251], some servers may hold shadow copies of entries
+ which can be used to answer search and comparison queries. Such
+ servers may also support content synchronization requests. This
+ section discusses considerations for implementors and deployers for
+ the implementation and deployment of the Sync operation in shadowed
+ directories.
+
+ While a client may know of multiple servers which are equally capable
+ of being used to obtain particular directory content from, a client
+ SHOULD NOT assume that each of these server is equally capable of
+ continuing a content synchronization session. As stated in Section
+ 3.1, the client SHOULD issue each Sync request of a Sync session to
+ the same server.
+
+ However, through domain naming or IP address redirection or other
+ techniques, multiple physical servers can be made to appear as one
+ logical server to a client. Only servers which are equally capable in
+ regards to their support for the Sync operation and which hold equally
+ complete copies of the entries should be made to appear as one logical
+
+
+
+Zeilenga LDAP Content Sync Operation [Page 24]
+
+INTERNET-DRAFT draft-zeilenga-ldup-sync-05 3 February 2004
+
+
+ server. In particular, each physical server acting as one logical
+ server SHOULD be equally capable of continuing a content
+ synchronization based upon cookies provided by any of the other
+ physical servers without requiring a full reload. Because there is no
+ standard LDAP shadowing mechanism, the specification of how to
+ independently implement equally capable servers (as well as the
+ precise definition of "equally capable") is left to future documents.
+
+ It is noted that it may be difficult for the server to reliably
+ determine what content was provided to the client by another server,
+ especially in the shadowing environments which allow shadowing events
+ to be coalesced. Where so, the use of the delete phase discussed in
+ Section 3.3.2 may not be applicable.
+
+
+7. Security Considerations
+
+ In order to maintain a synchronized copy of the content, a client is
+ to delete information from its copy of the content as described above.
+ However, the client may maintain knowledge of information disclosed to
+ it by the server separate from its copy of the content used for
+ synchronization. Management of this knowledge is beyond the scope of
+ this document. Servers should be careful not to disclose information
+ for content which the client is not authorized to have knowledge of
+ and/or about.
+
+ While the information provided by a series of refreshOnly Sync
+ Operations is similar to that provided by a series of Search
+ Operations, persist stage may disclose additional information. A
+ client may be able to discern information about the particular
+ sequence of update operations which caused content change.
+
+ Implementors should take precautions against malicious cookie content,
+ including malformed cookies or valid cookies used with different
+ security associations and/or protections in attempt to obtain
+ unauthorized access to information. Servers may include a digital
+ signature in the cookie to detect tampering.
+
+ The operation may be the target of direct denial of service attacks.
+ Implementors should provide safeguards to ensure the operation is not
+ abused. Servers may place access control or other restrictions upon
+ the use of this operation.
+
+ It is noted that even small updates to the directory may cause
+ significant amount of traffic to be generated to clients using this
+ operation. A user could abuse its update privileges to mount an
+ indirect denial of service to these clients, other clients, and/or
+ portions of the network. Servers should provide safeguards to ensure
+
+
+
+Zeilenga LDAP Content Sync Operation [Page 25]
+
+INTERNET-DRAFT draft-zeilenga-ldup-sync-05 3 February 2004
+
+
+ update operations are not abused.
+
+ Implementors of this (or any) LDAP extension should be familiar with
+ general LDAP security considerations [RFC3377].
+
+
+8. IANA Considerations
+
+ Registration of the following values is requested.
+
+ The OID arc 1.3.6.1.4.1.4203.1.9.1 was assigned [ASSIGN] by OpenLDAP
+ Foundation, under its IANA-assigned private enterprise allocation
+ [PRIVATE], for use in this specification.
+
+
+8.2. LDAP Protocol Mechanism
+
+ It is requested that IANA register the LDAP Protocol Mechanism
+ described in this document.
+
+ Subject: Request for LDAP Protocol Mechanism Registration
+ Object Identifier: 1.3.6.1.4.1.4203.1.9.1.1
+ Description: LDAP Content Synchronization Control
+ Person & email address to contact for further information:
+ Kurt Zeilenga <kurt at openldap.org>
+ Usage: Control
+ Specification: RFC XXXX
+ Author/Change Controller: IESG
+ Comments: none
+
+
+8.3. LDAP Result Codes
+
+ It is requested that IANA register the LDAP Result Code described in
+ this document.
+
+ Subject: LDAP Result Code Registration
+ Person & email address to contact for further information:
+ Kurt Zeilenga <kurt at OpenLDAP.org>
+ Result Code Name: e-syncRefreshRequired (IANA-ASSIGNED-CODE)
+ Specification: RFC XXXX
+ Author/Change Controller: IESG
+ Comments: none
+
+
+9. Acknowledgments
+
+ This document borrows significantly from the LDAP Client Update
+
+
+
+Zeilenga LDAP Content Sync Operation [Page 26]
+
+INTERNET-DRAFT draft-zeilenga-ldup-sync-05 3 February 2004
+
+
+ Protocol [LCUP], a product of the IETF LDUP working group. This
+ document also benefited from Persistent Search [PSEARCH], Triggered
+ Search [TSEARCH], and Directory Synchronization [DIRSYNC] works. This
+ document also borrows from "Lightweight Directory Access Protocol
+ (v3)" [RFC2251].
+
+
+10. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14 (also RFC 2119), March 1997.
+
+ [RFC2251] Wahl, M., T. Howes and S. Kille, "Lightweight Directory
+ Access Protocol (v3)", RFC 2251, December 1997.
+
+ [RFC2252] Wahl, M., A. Coulbeck, T. Howes, and S. Kille,
+ "Lightweight Directory Access Protocol (v3): Attribute
+ Syntax Definitions", RFC 2252, December 1997.
+
+ [RFC3296] Zeilenga, K., "Named Subordinate References in
+ Lightweight Directory Access Protocol (LDAP)
+ Directories", RFC 3296, July 2002.
+
+ [RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access
+ Protocol (v3): Technical Specification", RFC 3377,
+ September 2002.
+
+ [RFC3671] Zeilenga, K., "Collective Attributes in LDAP", RFC 3671,
+ December 2003.
+
+ [RFC3672] Zeilenga, K. and S. Legg, "Subentries in LDAP", RFC
+ 3672, December 2003.
+
+ [CANCEL] Zeilenga, K., "LDAP Cancel Extended Operation",
+ draft-zeilenga-ldap-cancel-xx.txt, a work in progress.
+ [EntryUUID] Zeilenga, K., "The LDAP EntryUUID Operational
+ Attribute", draft-zeilenga-ldap-uuid-xx.txt, a work in
+ progress.
+
+ [LDAPIRM] Harrison, R. and Zeilenga, K., "LDAP Intermediate
+ Response",
+ draft-rharrison-ldap-intermediate-resp-00.txt, a work in
+ progress.
+
+ [UUID] International Organization for Standardization (ISO),
+ "Information technology - Open Systems Interconnection -
+ Remote Procedure Call", ISO/IEC 11578:1996
+
+
+
+
+Zeilenga LDAP Content Sync Operation [Page 27]
+
+INTERNET-DRAFT draft-zeilenga-ldup-sync-05 3 February 2004
+
+
+ [X.680] International Telecommunication Union -
+ Telecommunication Standardization Sector, "Abstract
+ Syntax Notation One (ASN.1) - Specification of Basic
+ Notation", X.680(1997) (also ISO/IEC 8824-1:1998).
+
+ [X.690] International Telecommunication Union -
+ Telecommunication Standardization Sector, "Specification
+ of ASN.1 encoding rules: Basic Encoding Rules (BER),
+ Canonical Encoding Rules (CER), and Distinguished
+ Encoding Rules (DER)", X.690(1997) (also ISO/IEC
+ 8825-1:1998).
+
+
+11. Informative References
+
+ [RFC2256] Wahl, M., "A Summary of the X.500(96) User Schema for
+ use with LDAPv3", RFC 2256, December 1997.
+
+ [RFC3383] Zeilenga, K., "IANA Considerations for LDAP", BCP 64
+ (also RFC 3383), September 2002.
+
+ [PRIVATE] IANA, "Private Enterprise Numbers",
+ http://www.iana.org/assignments/enterprise-numbers.
+
+ [ASSIGN] OpenLDAP Foundation, "OpenLDAP OID Delegations",
+ http://www.openldap.org/foundation/oid-delegate.txt.
+
+ [X.500] International Telecommunication Union -
+ Telecommunication Standardization Sector, "The Directory
+ -- Overview of concepts, models and services,"
+ X.500(1993) (also ISO/IEC 9594-1:1994).
+
+ [X.511] International Telecommunication Union -
+ Telecommunication Standardization Sector, "The
+ Directory: Abstract Service Definition", X.511(1993).
+
+ [X.525] International Telecommunication Union -
+ Telecommunication Standardization Sector, "The
+ Directory: Replication", X.525(1993).
+
+ [UUIDinfo] The Open Group, "Universally Unique Identifier" appendix
+ of the CAE Specification "DCE 1.1: Remote Procedure
+ Calls", Document Number C706,
+ <http://www.opengroup.org/products/publications/
+ catalog/c706.htm> (appendix available at:
+ <http://www.opengroup.org/onlinepubs/9629399/
+ apdxa.htm>), August 1997.
+
+
+
+
+Zeilenga LDAP Content Sync Operation [Page 28]
+
+INTERNET-DRAFT draft-zeilenga-ldup-sync-05 3 February 2004
+
+
+ [DIRSYNC] Armijo, M., "Microsoft LDAP Control for Directory
+ Synchronization", draft-armijo-ldap-dirsync-xx.txt, a
+ work in progress.
+
+ [LCUP] Megginson, R., et. al., "LDAP Client Update Protocol",
+ draft-ietf-ldup-lcup-xx.txt, a work in progress.
+
+ [PSEARCH] Smith, M., et. al., "Persistent Search: A Simple LDAP
+ Change Notification Mechanism",
+ draft-ietf-ldapext-psearch-xx.txt, a work in progress.
+
+ [TSEARCH] Wahl, M., "LDAPv3 Triggered Search Control",
+ draft-ietf-ldapext-trigger-xx.txt, a work in progress.
+
+
+12. Authors' Addresses
+
+ Kurt D. Zeilenga
+ OpenLDAP Foundation
+ <Kurt at OpenLDAP.org>
+
+ Jong Hyuk Choi
+ IBM Corporation
+ <jongchoi at us.ibm.com>
+
+
+
+Appendix A. CSN-based Implementation Considerations
+
+ This appendix is provided for informational purposes only, it is not a
+ normative part of the LDAP Content Synchronization Operation's
+ technical specification.
+
+ This appendix discusses LDAP Content Synchronization Operation server
+ implementation considerations associated with a Change Sequence Number
+ based approaches.
+
+ Change Sequence Number based approaches are targeted for use in
+ servers which do not maintain history information (e.g., change logs,
+ state snapshots, etc.) about changes made to the Directory and hence,
+ must rely on current directory state and minimal synchronization state
+ information embedded in Sync Cookie. Servers which maintain history
+ information should consider other approaches which exploit the history
+ information.
+
+ A Change Sequence Number is effectively a time stamp which has
+ sufficient granularity to ensure that the precedence relationship in
+ time of two updates to the same object can be determined. Change
+
+
+
+Zeilenga LDAP Content Sync Operation [Page 29]
+
+INTERNET-DRAFT draft-zeilenga-ldup-sync-05 3 February 2004
+
+
+ Sequence Numbers are not to be confused with Commit Sequence Numbers
+ or Commit Log Record Numbers. A Commit Sequence Number allows one to
+ determine how two commits (to the same object or different objects)
+ relate to each other in time. Change Sequence Number associated with
+ different entries may be committed out of order. In the remainder of
+ this Appendix, the term CSN refers to a Change Sequence Number.
+
+ In these approaches, the server not only maintains a CSN for each
+ directory entry (the entry CSN), but also maintains a value which we
+ will call the context CSN. The context CSN is the greatest committed
+ entry CSN which is not greater than any outstanding (uncommitted)
+ entry CSNs for all entries in a directory context. The values of
+ context CSN are used in syncCookie values as synchronization state
+ indicators.
+
+ As search operations are not isolated from individual directory update
+ operations and individual update operations cannot be assumed to be
+ serialized, one cannot assume that the returned content incorporates
+ all relevant changes whose change sequence number is less than or
+ equal to the greatest entry CSN in the content. The content
+ incorporates all the relevant changes whose change sequence number is
+ less than or equal to context CSN before search processing. The
+ content may also incorporate any subset of the changes whose change
+ sequence number is greater than context CSN before search processing
+ but less than or equal to the context CSN after search processing.
+ The content does not incorporate any of the changes whose CSN is
+ greater than the context CSN after search processing.
+
+ A simple server implementation could use value of the context CSN
+ before search processing to indicate state. Such an implementation
+ would embed this value into each SyncCookie returned. We'll call this
+ the cookie CSN. When a refresh was requested, the server would simply
+ generate "update" messages for all entries in the content whose CSN is
+ greater than the supplied cookie CSN and generate "present" messages
+ for all other entries in the content. However, if the current context
+ CSN is the same as the cookie CSN, the server should instead generate
+ zero "updates" and zero "delete" messages, and indicate refreshDeletes
+ of TRUE as the directory has not changed.
+
+ The implementation should also consider the impact of changes to meta
+ information, such as access controls, which affects content
+ determination. One approach is for the server to maintain a context
+ wide meta information CSN or meta CSN. This meta CSN would be updated
+ whenever meta information affecting content determination was changed.
+ If the value of the meta CSN is greater than cookie CSN, the server
+ should ignore the cookie and treat the request as an initial request
+ for content.
+
+
+
+
+Zeilenga LDAP Content Sync Operation [Page 30]
+
+INTERNET-DRAFT draft-zeilenga-ldup-sync-05 3 February 2004
+
+
+ Additionally, servers may want to consider maintaining some
+ per-session history information to reduce the number of messages
+ needed to be transferred during incremental refreshes. Specifically,
+ a server could record information about entries as they leave the
+ scope of a disconnected sync session and later use this information to
+ generate delete messages instead of present messages.
+
+ When the history information is truncated, the CSN of the latest
+ truncated history information entry may be recorded as the truncated
+ CSN of the history information. The truncated CSN may be used to
+ determine whether a client copy can be covered by the history
+ information by comparing it to the synchronization state contained in
+ the cookie supplied by the client.
+
+ When there are a large number of sessions, it may make sense to
+ maintain such history only for the selected clients. Also, servers
+ taking this approach need to consider resource consumption issues to
+ ensure reasonable server operation and to protect against abuse. It
+ may be appropriate to restrict this mode of operation by policy.
+
+
+
+
+Intellectual Property Rights
+
+ The IETF takes no position regarding the validity or scope of any
+ intellectual property or other rights that might be claimed to pertain
+ to the implementation or use of the technology described in this
+ document or the extent to which any license under such rights might or
+ might not be available; neither does it represent that it has made any
+ effort to identify any such rights. Information on the IETF's
+ procedures with respect to rights in standards-track and
+ standards-related documentation can be found in BCP-11. Copies of
+ claims of rights made available for publication and any assurances of
+ licenses to be made available, or the result of an attempt made to
+ obtain a general license or permission for the use of such proprietary
+ rights by implementors or users of this specification can be obtained
+ from the IETF Secretariat.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights which may cover technology that may be required to practice
+ this standard. Please address the information to the IETF Executive
+ Director.
+
+
+
+Full Copyright
+
+
+
+Zeilenga LDAP Content Sync Operation [Page 31]
+
+INTERNET-DRAFT draft-zeilenga-ldup-sync-05 3 February 2004
+
+
+ Copyright (C) The Internet Society (2004). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published and
+ distributed, in whole or in part, without restriction of any kind,
+ provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be followed,
+ or as required to translate it into languages other than English.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga LDAP Content Sync Operation [Page 32]
+
+
Modified: openldap/vendor/openldap-release/doc/guide/admin/guide.html
===================================================================
--- openldap/vendor/openldap-release/doc/guide/admin/guide.html 2007-09-15 10:30:38 UTC (rev 843)
+++ openldap/vendor/openldap-release/doc/guide/admin/guide.html 2007-09-15 10:38:52 UTC (rev 844)
@@ -23,7 +23,7 @@
<DIV CLASS="title">
<H1 CLASS="doc-title">OpenLDAP Software 2.3 Administrator's Guide</H1>
<ADDRESS CLASS="doc-author">The OpenLDAP Project <<A HREF="http://www.openldap.org/">http://www.openldap.org/</A>></ADDRESS>
-<ADDRESS CLASS="doc-modified">9 April 2007</ADDRESS>
+<ADDRESS CLASS="doc-modified">20 August 2007</ADDRESS>
<BR CLEAR="All">
</DIV>
<DIV CLASS="contents">
Modified: openldap/vendor/openldap-release/doc/man/man1/ldapsearch.1
===================================================================
--- openldap/vendor/openldap-release/doc/man/man1/ldapsearch.1 2007-09-15 10:30:38 UTC (rev 843)
+++ openldap/vendor/openldap-release/doc/man/man1/ldapsearch.1 2007-09-15 10:38:52 UTC (rev 844)
@@ -1,5 +1,5 @@
.TH LDAPSEARCH 1 "RELEASEDATE" "OpenLDAP LDVERSION"
-.\" $OpenLDAP: pkg/ldap/doc/man/man1/ldapsearch.1,v 1.49.2.11 2007/01/02 21:43:44 kurt Exp $
+.\" $OpenLDAP: pkg/ldap/doc/man/man1/ldapsearch.1,v 1.49.2.13 2007/08/06 15:44:51 ghenry Exp $
.\" Copyright 1998-2007 The OpenLDAP Foundation All Rights Reserved.
.\" Copying restrictions apply. See COPYRIGHT/LICENSE.
.SH NAME
@@ -21,6 +21,8 @@
[\c
.BR \-A ]
[\c
+.BR \-C ]
+[\c
.BR \-L[L[L]] ]
[\c
.BR \-M[M] ]
@@ -132,6 +134,9 @@
see if an attribute is present in an entry and are not interested in the
specific values.
.TP
+.B \-C
+Chase referrals (anonymously).
+.TP
.B \-L
Search results are display in LDAP Data Interchange Format detailed in
.BR ldif (5).
@@ -166,7 +171,7 @@
Read a series of lines from \fIfile\fP, performing one LDAP search for
each line. In this case, the \fIfilter\fP given on the command line
is treated as a pattern where the first and only occurrence of \fB%s\fP
-is replaced with a line from \fIfile\fP. Any other occurence of the
+is replaced with a line from \fIfile\fP. Any other occurrence of the
the \fB%\fP character in the pattern will be regarded as an error.
Where it is desired that the search filter include a \fB%\fP character,
the character should be encoded as \fB\\25\fP (see RFC 4515).
Modified: openldap/vendor/openldap-release/doc/man/man5/slapd-bdb.5
===================================================================
--- openldap/vendor/openldap-release/doc/man/man5/slapd-bdb.5 2007-09-15 10:30:38 UTC (rev 843)
+++ openldap/vendor/openldap-release/doc/man/man5/slapd-bdb.5 2007-09-15 10:38:52 UTC (rev 844)
@@ -1,7 +1,7 @@
.TH SLAPD-BDB 5 "RELEASEDATE" "OpenLDAP LDVERSION"
.\" Copyright 1998-2007 The OpenLDAP Foundation All Rights Reserved.
.\" Copying restrictions apply. See COPYRIGHT/LICENSE.
-.\" $OpenLDAP: pkg/ldap/doc/man/man5/slapd-bdb.5,v 1.20.2.10 2007/01/02 21:43:45 kurt Exp $
+.\" $OpenLDAP: pkg/ldap/doc/man/man5/slapd-bdb.5,v 1.20.2.11 2007/08/06 15:45:52 ghenry Exp $
.SH NAME
\fBslapd-bdb\fP, \fBslapd-hdb\fP \- Berkeley DB backends to \fBslapd\fP
.SH SYNOPSIS
@@ -12,7 +12,7 @@
is the recommended primary backend for a normal
.B slapd
database.
-It uses the Sleepycat Berkeley DB (BDB) package to store data.
+It uses the Oracle Berkeley DB (BDB) package to store data.
It makes extensive use of indexing and caching to speed data access.
.LP
\fBhdb\fP is a variant of the \fBbdb\fP backend that uses a
Modified: openldap/vendor/openldap-release/doc/man/man5/slapd.conf.5
===================================================================
--- openldap/vendor/openldap-release/doc/man/man5/slapd.conf.5 2007-09-15 10:30:38 UTC (rev 843)
+++ openldap/vendor/openldap-release/doc/man/man5/slapd.conf.5 2007-09-15 10:38:52 UTC (rev 844)
@@ -1,7 +1,7 @@
.TH SLAPD.CONF 5 "RELEASEDATE" "OpenLDAP LDVERSION"
.\" Copyright 1998-2007 The OpenLDAP Foundation All Rights Reserved.
.\" Copying restrictions apply. See COPYRIGHT/LICENSE.
-.\" $OpenLDAP: pkg/ldap/doc/man/man5/slapd.conf.5,v 1.191.2.28 2007/04/02 20:33:57 hyc Exp $
+.\" $OpenLDAP: pkg/ldap/doc/man/man5/slapd.conf.5,v 1.191.2.31 2007/08/06 15:46:33 ghenry Exp $
.SH NAME
slapd.conf \- configuration file for slapd, the stand-alone LDAP daemon
.SH SYNOPSIS
@@ -417,7 +417,7 @@
disables forcing session to anonymous status (see also
.BR tls_authc ) upon StartTLS operation receipt.
.B tls_authc
-dissallow the StartTLS operation if authenticated (see also
+disallow the StartTLS operation if authenticated (see also
.BR tls_2_anon ).
.HP
.hy 0
@@ -526,7 +526,7 @@
trace function calls
.TP
.B 2
-.B (0x2 packet)
+.B (0x2 packets)
debug packet handling
.TP
.B 4
@@ -607,10 +607,11 @@
.BR none ,
or the equivalent integer representation, causes those messages
that are logged regardless of the configured loglevel to be logged.
-In fact, if no loglevel (or a 0 level) is defined, no logging occurs,
+In fact, if loglevel is set to 0, no logging occurs,
so at least the
.B none
level is required to have high priority messages logged.
+The loglevel defaults to \fBstats\fP.
.RE
.TP
.B moduleload <filename>
@@ -1682,7 +1683,7 @@
.B bdb
This is the recommended primary backend for a normal slapd database.
It takes care to configure it properly.
-It uses the transactional database interface of the Sleepycat Berkeley
+It uses the transactional database interface of the Oracle Berkeley
DB (BDB) package to store data.
.TP
.B config
Modified: openldap/vendor/openldap-release/doc/man/man5/slapo-dynlist.5
===================================================================
--- openldap/vendor/openldap-release/doc/man/man5/slapo-dynlist.5 2007-09-15 10:30:38 UTC (rev 843)
+++ openldap/vendor/openldap-release/doc/man/man5/slapo-dynlist.5 2007-09-15 10:38:52 UTC (rev 844)
@@ -1,7 +1,7 @@
.TH SLAPO-DYNLIST 5 "RELEASEDATE" "OpenLDAP LDVERSION"
.\" Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved.
.\" Copying restrictions apply. See the COPYRIGHT file.
-.\" $OpenLDAP: pkg/ldap/doc/man/man5/slapo-dynlist.5,v 1.1.2.8 2007/02/03 09:06:46 ando Exp $
+.\" $OpenLDAP: pkg/ldap/doc/man/man5/slapo-dynlist.5,v 1.1.2.9 2007/08/06 15:49:54 ghenry Exp $
.SH NAME
slapo-dynlist \- Dynamic List overlay
.SH SYNOPSIS
@@ -58,7 +58,7 @@
The value
.B <URL-ad>
-is the name of the attributeDescription that cointains the URI that is
+is the name of the attributeDescription that contains the URI that is
expanded by the overlay; if none is present, no expansion occurs.
If the intersection of the attributes requested by the search operation
(or the asserted attribute for compares) and the attributes listed
Modified: openldap/vendor/openldap-release/doc/man/man5/slapo-ppolicy.5
===================================================================
--- openldap/vendor/openldap-release/doc/man/man5/slapo-ppolicy.5 2007-09-15 10:30:38 UTC (rev 843)
+++ openldap/vendor/openldap-release/doc/man/man5/slapo-ppolicy.5 2007-09-15 10:38:52 UTC (rev 844)
@@ -1,4 +1,4 @@
-.\" $OpenLDAP: pkg/ldap/doc/man/man5/slapo-ppolicy.5,v 1.4.2.7 2007/01/02 21:43:45 kurt Exp $
+.\" $OpenLDAP: pkg/ldap/doc/man/man5/slapo-ppolicy.5,v 1.4.2.8 2007/05/23 21:29:17 ghenry Exp $
.\" Copyright 2004-2007 The OpenLDAP Foundation All Rights Reserved.
.\" Copying restrictions apply. See COPYRIGHT/LICENSE.
.TH SLAPO_PPOLICY 5 "RELEASEDATE" "OpenLDAP LDVERSION"
@@ -559,7 +559,7 @@
If the account has been locked, the password may no longer be used to
authenticate the user to the directory. If
.B pwdAccountLockedTime
-is set to zero (0), the user's account has been permanently locked
+is set to 000001010000Z, the user's account has been permanently locked
and may only be unlocked by an administrator.
.LP
.RS 4
Modified: openldap/vendor/openldap-release/doc/man/man8/slapadd.8
===================================================================
--- openldap/vendor/openldap-release/doc/man/man8/slapadd.8 2007-09-15 10:30:38 UTC (rev 843)
+++ openldap/vendor/openldap-release/doc/man/man8/slapadd.8 2007-09-15 10:38:52 UTC (rev 844)
@@ -1,5 +1,5 @@
.TH SLAPADD 8C "RELEASEDATE" "OpenLDAP LDVERSION"
-.\" $OpenLDAP: pkg/ldap/doc/man/man8/slapadd.8,v 1.23.2.9 2007/01/02 21:43:46 kurt Exp $
+.\" $OpenLDAP: pkg/ldap/doc/man/man8/slapadd.8,v 1.23.2.10 2007/04/20 20:00:58 quanah Exp $
.\" Copyright 1998-2007 The OpenLDAP Foundation All Rights Reserved.
.\" Copying restrictions apply. See COPYRIGHT/LICENSE.
.SH NAME
@@ -12,6 +12,7 @@
.B [\-u]
.B [\-q]
.B [\-w]
+.B [\-s]
.B [\-d level]
.B [\-b suffix]
.B [\-n dbnum]
@@ -67,6 +68,12 @@
After all entries are added, the contextCSN
will be updated with the greatest CSN in the database.
.TP
+.BI \-s
+disable schema checking. This option is intended to be used when loading
+databases containing special objects, such as fractional objects on a
+partial replica. Loading normal objects which do not conform to
+schema may result in unexpected and ill behavior.
+.TP
.BI \-d " level"
enable debugging messages as defined by the specified
.IR level .
Added: openldap/vendor/openldap-release/doc/rfc/INDEX
===================================================================
--- openldap/vendor/openldap-release/doc/rfc/INDEX (rev 0)
+++ openldap/vendor/openldap-release/doc/rfc/INDEX 2007-09-15 10:38:52 UTC (rev 844)
@@ -0,0 +1,67 @@
+This is an index of RFC contained in this directory:
+
+rfc1274.txt COSINE and Internet X.500 Schema (PS)
+rfc2079.txt X.500 Attribute Type and an Object Class to Hold URIs (PS)
+rfc2247.txt Using Domains in LDAP DNs (PS)
+rfc2251.txt LDAPv3 Protocol (PS)
+rfc2252.txt LDAPv3 Attribute Types (PS)
+rfc2253.txt LDAPv3 Disinguished Name (PS)
+rfc2254.txt LDAPv3 Search Filters (PS)
+rfc2255.txt LDAPv3 URL Format (PS)
+rfc2256.txt X.500(96) Schema for LDAPv3 (PS)
+rfc2293.txt Tables and Subtrees in the X.500 Directory (PS)
+rfc2294.txt O/R Address hierarchy in the X.500 DIT (PS)
+rfc2307.txt LDAP Network Information Services Schema (E)
+rfc2377.txt LDAP Naming Plan (I)
+rfc2587.txt Internet X.509 PKI LDAPv2 Schema (PS)
+rfc2589.txt LDAPv3: Dynamic Directory Services Extensions (PS)
+rfc2649.txt LDAPv3 Operational Signatures (E)
+rfc2696.txt LDAP Simple Paged Result Control (I)
+rfc2713.txt LDAP Java schema (I)
+rfc2714.txt LDAP CORBA schema (I)
+rfc2798.txt LDAP inetOrgPerson schema (I)
+rfc2829.txt LDAPv3: Authentication Methods (PS)
+rfc2830.txt LDAPv3: Start TLS (PS)
+rfc2849.txt LDIFv1 (PS)
+rfc2891.txt LDAPv3: Server Side Sorting of Search Results (PS)
+rfc2926.txt LDAP: Conversion of LDAP Schemas to and from SLP Templates (I)
+rfc3045.txt Storing Vendor Information in the LDAP root DSE (I)
+rfc3062.txt LDAP Password Modify Extended Operation (PS)
+rfc3088.txt OpenLDAP Root Service (E)
+rfc3112.txt LDAP Authentication Password Schema (I)
+rfc3296.txt Named Subordinate References in LDAP (PS)
+rfc3377.txt LDAP(v3): Technical Specification (PS)
+rfc3383.txt IANA Considerations for LDAP (BCP)
+rfc3663.txt Domain Administrative Data in LDAP (E)
+rfc3671.txt Collective Attributes in LDAP (PS)
+rfc3672.txt Subentries in LDAP (PS)
+rfc3673.txt LDAPv3: All Operational Attributes (PS)
+rfc3674.txt Feature Discovery in LDAP (PS)
+rfc3687.txt LDAP Component Matching Rules (PS)
+rfc3698.txt LDAP: Additional Matching Rules (PS)
+rfc3703.txt LDAP: Schema for Policy Core (PS)
+rfc3712.txt LDAP: Schema for Printer Services (I)
+rfc3727.txt ASN.1 Module for LDAP Component Matching Rules (PS)
+rfc3771.txt LDAP: Intermediate Response Message (PS)
+rfc3829.txt LDAP Authorization Identity Controls (I)
+rfc3866.txt Language Tag and Ranges in LDAP (PS)
+rfc3876.txt Returning Matched Values with LDAP (PS)
+rfc3909.txt LDAP Cancel Operation (PS)
+rfc3928.txt LDAP Client Update Protocol (PS)
+rfc4013.txt SASLprep (PS)
+rfc4370.txt LDAP Proxied Authorization Control (PS)
+rfc4373.txt LBURP (I)
+rfc4404.txt LDAP Schema for UDDI (I)
+
+Legend:
+STD Standard
+DS Draft Standard
+PS Proposed Standard
+I Information
+E Experimental
+FYI For Your Information
+BCP Best Common Practice
+
+Please see http://www.rfc-editor.org/ for up-to-date status information.
+
+$OpenLDAP: pkg/ldap/doc/rfc/INDEX,v 1.38.2.4 2006/04/04 01:12:38 kurt Exp $
Added: openldap/vendor/openldap-release/doc/rfc/rfc1274.txt
===================================================================
--- openldap/vendor/openldap-release/doc/rfc/rfc1274.txt (rev 0)
+++ openldap/vendor/openldap-release/doc/rfc/rfc1274.txt 2007-09-15 10:38:52 UTC (rev 844)
@@ -0,0 +1,3363 @@
+
+
+
+
+
+
+Network Working Group P. Barker
+Request for Comments: 1274 S. Kille
+ University College London
+ November 1991
+
+
+ The COSINE and Internet X.500 Schema
+
+Status of this Memo
+
+ This RFC specifies an IAB standards track protocol for the Internet
+ community, and requests discussion and suggestions for improvements.
+ Please refer to the current edition of the "IAB Official Protocol
+ Standards" for the standardization state and status of this protocol.
+ Distribution of this memo is unlimited.
+
+Abstract
+
+ This document suggests an X.500 Directory Schema, or Naming
+ Architecture, for use in the COSINE and Internet X.500 pilots. The
+ schema is independent of any specific implementation. As well as
+ indicating support for the standard object classes and attributes, a
+ large number of generally useful object classes and attributes are
+ also defined. An appendix to this document includes a machine
+ processable version of the schema.
+
+ This document also proposes a mechanism for allowing the schema to
+ evolve in line with emerging requirements. Proformas to support this
+ process are included.
+
+ Corrections and additions to the schema should be sent to na-
+ update at cs.ucl.ac.uk list, as described within.
+
+1. Introduction
+
+ Directory Services are a fundamental requirement of both human and
+ computer communications' systems. Human users need to be able to
+ look up various details about other people: for example, telephone
+ numbers, facsimile numbers and paper mail addresses. Computing
+ systems also need Directory Services for several purposes: for
+ example, to support address look-ups for a variety of services, and
+ to support user-friendly naming and distribution lists in electronic
+ mail systems.
+
+ Directory Services have recently been standardised and published as
+ the 1988 CCITT X.500 / ISO IS9594 recommendations [1]. The standard
+ provides a good basis for the provision of real services, and a
+ considerable amount of Directory Service piloting activity is
+
+
+
+Barker & Kille [Page 1]
+
+RFC 1274 COSINE and Internet X.500 Schema November 1991
+
+
+ currently underway. In the U.S., the PSI White Pages Pilot [4] has
+ stimulated use of X.500 on the Internet. In Britain, the U.K.
+ Academic Community Directory Pilot [5] is similarly promoting use of
+ X.500.
+
+2. Motivation and aims of this document
+
+ In a number of areas the X.500 standard only provides a basis for
+ services. One such area is the Directory's Schema or Naming
+ Architecture. The standard defines a number of useful object
+ classes, in X.521, and attribute types, in X.520. These are intended
+ to be generally useful across a range of directory applications.
+ However, while these standard definitions are a useful starting
+ point, they are insufficient as a basis for a large scale pilot
+ directory.
+
+ While it is possible for directory administrators to define their own
+ sets of additional attribute types and object classes, this is
+ undesirable for some common attributes and objects. The same objects
+ and attribute types would be privately defined many times over. This
+ would result in the directory's generality being diminished as remote
+ systems would be unable to determine the semantics of these privately
+ defined data types.
+
+ A number of useful additions to the standard definitions were made in
+ this note's forerunner, "The THORN and RARE Naming Architecture" [2].
+ These have been heavily used in early X.500 piloting activities.
+ Furthermore, both the THORN and Quipu X.500 implementations have made
+ use of these definitions.
+
+ Since the afore-mentioned note was issued, a number of further
+ requirements have come to light as the volume and variety of piloting
+ activity has increased. Yet further requirements seem likely as the
+ scale of X.500 pilot services increases. Thus, it is argued that it
+ is not sufficient to merely reissue an updated version of the
+ original note. The schema is a "living document" that needs
+ procedures for:
+
+ - Allowing submission of requests for new attributes and
+ object classes to be added into the schema;
+
+ - Allowing groups of object classes and attribute types
+ defined elsewhere to be integrated into the schema.
+
+ - Checking for the redundancy of any previously defined
+ attribute types and object classes.
+
+ This document attempts to establish procedures to allow for the
+
+
+
+Barker & Kille [Page 2]
+
+RFC 1274 COSINE and Internet X.500 Schema November 1991
+
+
+ continual updating of the schema. Two proformas are set out for this
+ purpose. In addition, descriptive detail is provided for the
+ additional object classes and attribute types defined in the schema.
+ These descriptions follow the style used in X.520 and X.521.
+ Finally, also following the style adopted in the standards documents,
+ appendices will include the entire schema. Plain text versions of
+ the document's appendices are intended to be machine processable to
+ allow derivation of a system's schema tables. Appendix C lists all
+ the schema's object classes and attribute types in their respective
+ ASN.1 macro formats.
+
+ The scope and intended remit of this coordination activity should be
+ clearly understood.
+
+ - Esoteric and local, highly experimental requirements should
+ continue to be met by private definitions.
+
+ - Requirements which have support from more than one site will
+ usually be integrated into the schema. Put in other words,
+ the tendency will be for the inclusion, as opposed to the
+ exclusion, of useful additions to the schema.
+
+ - An attempt will be made to avoid duplication of object
+ classes and attribute types for essentially similar real
+ world objects.
+
+3. What conformance to this schema means
+
+ It is not reasonable to require that a DSA which supports this schema
+ has specific code to handle each of the defined syntaxes. However,
+ the following requirements are made of a system which claims
+ conformance to this specification:
+
+ 1. A DSA shall be able to store all of the attributes and
+ object class values specified. (Note that this implies
+ support for all the object classes and attribute types
+ required by strong authentication as defined in X.509.)
+
+ 2. A DUA shall be able to identify each attribute type and
+ object class to the user, with an appropriate representation
+ (e.g., a string).
+
+ 3. These statement are qualified for large attributes values
+ (>1kbyte). A conforming DSA does not have to store such
+ attribute values, and a DUA does not have to display such
+ values, although it must indicate their presence.
+
+ The following are desirable, but not required:
+
+
+
+Barker & Kille [Page 3]
+
+RFC 1274 COSINE and Internet X.500 Schema November 1991
+
+
+ 1. For a DSA to match correctly on the basis of all attribute
+ syntaxes defined
+
+ 2. For a DSA to enforce the Object Class schema implied by
+ these definitions
+
+ 3. For a DUA to correctly display the attribute values
+ (syntaxes) defined
+
+ 4. For DUAs and DSAs to maintain compatibility with a previous
+ version of the schema.
+
+4. Requesting new object classes and attribute types
+
+ This section defines procedures for requesting new object classes and
+ attribute types to be added to the schema. Proformas for object
+ classes and attribute types are specified, and examples given of how
+ to use them. A mechanism for making requests for large groups of new
+ object classes and attribute types is described in the next section.
+
+ As stated earlier, it is anticipated that the schema will evolve
+ considerably over time. As X.500 is used to support a widening range
+ of applications, there will be requirements for extensions to the
+ schema. This document proposes formalising this procedure by
+ requiring requests for additions to the schema to be submitted as
+ completed proformas. This stipulation will greatly simplify
+ subsequent revisions of the schema.
+
+ There is one qualification to the above with respect to requests for
+ modifications to an existing object class. If a modification to an
+ object class merely involves additional, optional attributes, the
+ object class will be enhanced as requested. Systems are expected to
+ be resilient to such changes to the schema. However, requests to
+ modify an object class, such that the mandatory attribute types
+ require altering, will not be met. Instead, a new object class will
+ be created, and the original object class expired following the
+ scheme described in the next main section.
+
+ It is anticipated that most requests for modifications to the schema
+ will be met without any need for editorial intervention. Sometimes,
+ however, some discussion between the submitter of a request and the
+ schema's editor may be required. For example, the editor may have to
+ judge the relative merits of two very similar requests and, as a
+ result, one of the parties may not get quite what they want. In
+ cases such as this where the submitter of a request feels aggrieved
+ about an editorial decision, the requestor may appeal to a broader
+ community by explaining their views to the mailing list osi-
+ ds at cs.ucl.ac.uk. Heed will be paid to any consensus that emerges
+
+
+
+Barker & Kille [Page 4]
+
+RFC 1274 COSINE and Internet X.500 Schema November 1991
+
+
+ from discussions on the schema on this list. If it proves that this
+ list is used almost solely for discussions on schema issues, a
+ separate discussion list will be created.
+
+ To facilitate the production of the afore-mentioned proformas, tools
+ are included in Appendix B which will verify that a proforma has been
+ correctly formatted.
+
+ Completed proformas should be mailed to na-update at cs.ucl.ac.uk
+
+4.1. Object Class proforma
+
+ This section gives an example, completed proforma for a new object
+ class, alcoholic drink. A proforma for object class specified in BNF
+ is included in Appendix A.
+
+ Object Class: Alcoholic Drink
+
+ Description: The Alcoholic Drink object class is used to define
+ entries representing intoxicating beverages.
+
+ ASN1OCMacro: alcoholicDrink OBJECT-CLASS
+ SUBCLASS OF drink
+ MUST CONTAIN {
+ percentAlcohol}
+ MAY CONTAIN {
+ normalServing,
+ hue}
+
+ An object class description consists of three fields, separated by
+ blank lines. The keywords Object Class, Description and ASN1OCMacro,
+ and their suffixed colons, must be included exactly as above.
+
+ The Object Class field should be used for a textual description of
+ the object class. This will be at most three or four words.
+
+ The Description field should contain some explanatory text about the
+ intended use of the object class. This can run to a number of lines.
+
+ The ASN1OCMacro field should follow the definition of the object
+ class macro as specified in X.501. The above example shows the main
+ features. There are many more examples which can studied in the
+ section defining the Pilot Object Classes.
+
+4.2. Attribute type proforma
+
+ This section gives an example completed proforma for a new attribute
+ type, hue (one of the attribute types in the alcoholic drink object
+
+
+
+Barker & Kille [Page 5]
+
+RFC 1274 COSINE and Internet X.500 Schema November 1991
+
+
+ class).
+
+ Attribute Type: Hue
+
+ Description: The Hue attribute type specifies the hue of
+ an object. (Note that a description may run to several
+ lines.)
+
+ OCMust:
+
+ OCMay: alcoholicDrink
+
+ ASN1ATMacro:hue ATTRIBUTE
+ WITH ATTRIBUTE SYNTAX
+ caseIgnoreStringSyntax
+ (SIZE (1 .. ub-hue))
+
+ ub-hue INTEGER ::= 256
+
+ An attribute type description consists of five fields, separated by
+ blank lines. The keywords Attribute Type, Description, OCMust, OCMay
+ and ASN1ATMacro, and their suffixed colons, must be included exactly
+ as above.
+
+ The Attribute Type field should be used for a textual description of
+ the attribute type. This will be at most three or four words.
+
+ The Description field should contain some explanatory text about the
+ intended use of the attribute type. This can run to a number of
+ lines.
+
+ The OCMust field should contain a comma-separated list of object
+ classes for which this attribute is mandatory.
+
+ The OCMay field should contain a comma-separated list of object
+ classes for which this attribute is optional.
+
+ The ASN1ATMacro field should follow the definition of the attribute
+ macro as specified in X.501. The above example shows some of the
+ features. In particular, please note the format for specifying size
+ constraints.
+
+5. Integrating groups of object classes and attribute types.
+
+ This section describes two mechanisms that may be employed to allow
+ the integration of a substantial number of new object classes and
+ attribute types into the schema.
+
+
+
+
+Barker & Kille [Page 6]
+
+RFC 1274 COSINE and Internet X.500 Schema November 1991
+
+
+ The first mechanism allows for the transition of groups of related,
+ privately defined object classes and attribute types into the schema.
+ An example of when such a transition might be appropriate is when
+ some experimental use of the Directory is widely adopted within the
+ pilot. Such a transition will be made if the following conditions
+ hold:
+
+ - The definitions are well structured: i.e., they are not
+ scattered over a multiplicity of object identifier subtrees.
+
+ - The definitions are in use at a number of sites, and having
+ to adopt new object identifiers would be unnecessarily
+ disruptive.
+
+ A second mechanism allows for the allocation of an object subtree for
+ a group of new definitions. A pilotGroups object identifier has been
+ defined for this purpose. This method will be suitable for an
+ experiment requiring a considerable number of new object identifiers
+ to be defined. This approach allows for flexibility during
+ experimentation and should simplify both the management and the
+ coherence of the pilot's object identifiers.
+
+ In both cases, the object classes, attribute types and syntaxes
+ should be defined and described in an RFC. It is suggested that such
+ documents should follow the style used in this document for object
+ class and attribute type definitions. A reference will be given in
+ this schema to the document containing the definitions.
+
+6. Removing "old" object classes and attribute types.
+
+ It is also important that object classes and attribute types which
+ are no longer used or useful are removed from the schema. Some
+ object classes and attribute types initially defined as pilot
+ extensions may be included as standard definitions in future versions
+ of the standard. In such a case, it is important that there should
+ be a fairly rapid transition to the standard definitions. Another
+ possibility is that newer, more specific definitions obviate the
+ original definitions.
+
+ Two things are essential. First, it is crucial that "old"
+ definitions are retired as gracefully as possible. The intention to
+ retire a definition will be sent to the osi-ds at cs.ucl.ac.uk mail
+ list. In the absence of objections, the definition will be marked
+ for expiry with a given expiry date. The definition will remain in
+ the schema until the expiry date. Users of the schema should ensure
+ that they make the transition to new, alternative definitions in the
+ interim.
+
+
+
+
+Barker & Kille [Page 7]
+
+RFC 1274 COSINE and Internet X.500 Schema November 1991
+
+
+ Second, users of the schema must have the right to argue for the
+ retention of definitions which they regard as necessary, there being
+ no other definitions which closely meet their requirements. It is
+ clearly impossible to lay down hard and fast rules on this point, as
+ no two instances will ever be quite the same. It is intended that
+ the refereeing on these matters will be sympathetic! As for requests
+ for additions, an aggrieved user can "go to arbitration" by
+ initiating a discussion on the osi-ds at cs.ucl.ac.uk mail list.
+
+7. Object Identifiers
+
+ Some additional object identifiers are defined for this schema.
+ These are also reproduced in Appendix C.
+
+ data OBJECT IDENTIFIER ::= {ccitt 9}
+ pss OBJECT IDENTIFIER ::= {data 2342}
+ ucl OBJECT IDENTIFIER ::= {pss 19200300}
+ pilot OBJECT IDENTIFIER ::= {ucl 100}
+
+ pilotAttributeType OBJECT IDENTIFIER ::= {pilot 1}
+ pilotAttributeSyntax OBJECT IDENTIFIER ::= {pilot 3}
+ pilotObjectClass OBJECT IDENTIFIER ::= {pilot 4}
+ pilotGroups OBJECT IDENTIFIER ::= {pilot 10}
+
+ iA5StringSyntax OBJECT IDENTIFIER ::= {pilotAttributeSyntax 4}
+ caseIgnoreIA5StringSyntax OBJECT IDENTIFIER ::=
+ {pilotAttributeSyntax 5}
+
+8. Object Classes
+
+8.1. X.500 standard object classes
+
+ A number of generally useful object classes are defined in X.521, and
+ these are supported. Refer to that document for descriptions of the
+ suggested usage of these object classes. The ASN.1 for these object
+ classes is reproduced for completeness in Appendix C.
+
+8.2. X.400 standard object classes
+
+ A number of object classes defined in X.400 are supported. Refer to
+ X.402 for descriptions of the usage of these object classes. The
+ ASN.1 for these object classes is reproduced for completeness in
+ Appendix C.
+
+8.3. COSINE/Internet object classes
+
+ This section attempts to fuse together the object classes designed
+ for use in the COSINE and Internet pilot activities. Descriptions
+
+
+
+Barker & Kille [Page 8]
+
+RFC 1274 COSINE and Internet X.500 Schema November 1991
+
+
+ are given of the suggested usage of these object classes. The ASN.1
+ for these object classes is also reproduced in Appendix C.
+
+8.3.1. Pilot Object
+
+ The PilotObject object class is used as a sub-class to allow some
+ common, useful attributes to be assigned to entries of all other
+ object classes.
+
+ pilotObject OBJECT-CLASS
+ SUBCLASS OF top
+ MAY CONTAIN {
+ info,
+ photo,
+ manager,
+ uniqueIdentifier,
+ lastModifiedTime,
+ lastModifiedBy,
+ dITRedirect,
+ audio}
+ ::= {pilotObjectClass 3}
+
+8.3.2. Pilot Person
+
+ The PilotPerson object class is used as a sub-class of person, to
+ allow the use of a number of additional attributes to be assigned to
+ entries of object class person.
+
+ pilotPerson OBJECT-CLASS
+ SUBCLASS OF person
+ MAY CONTAIN {
+ userid,
+ textEncodedORAddress,
+ rfc822Mailbox,
+ favouriteDrink,
+ roomNumber,
+ userClass,
+ homeTelephoneNumber,
+ homePostalAddress,
+ secretary,
+ personalTitle,
+ preferredDeliveryMethod,
+ businessCategory,
+ janetMailbox,
+ otherMailbox,
+ mobileTelephoneNumber,
+ pagerTelephoneNumber,
+ organizationalStatus,
+
+
+
+Barker & Kille [Page 9]
+
+RFC 1274 COSINE and Internet X.500 Schema November 1991
+
+
+ mailPreferenceOption,
+ personalSignature}
+ ::= {pilotObjectClass 4}
+
+8.3.3. Account
+
+ The Account object class is used to define entries representing
+ computer accounts. The userid attribute should be used for naming
+ entries of this object class.
+
+ account OBJECT-CLASS
+ SUBCLASS OF top
+ MUST CONTAIN {
+ userid}
+ MAY CONTAIN {
+ description,
+ seeAlso,
+ localityName,
+ organizationName,
+ organizationalUnitName,
+ host}
+ ::= {pilotObjectClass 5}
+
+8.3.4. Document
+
+ The Document object class is used to define entries which represent
+ documents.
+
+ document OBJECT-CLASS
+ SUBCLASS OF top
+ MUST CONTAIN {
+ documentIdentifier}
+ MAY CONTAIN {
+ commonName,
+ description,
+ seeAlso,
+ localityName,
+ organizationName,
+ organizationalUnitName,
+ documentTitle,
+ documentVersion,
+ documentAuthor,
+ documentLocation,
+ documentPublisher}
+ ::= {pilotObjectClass 6}
+
+
+
+
+
+
+Barker & Kille [Page 10]
+
+RFC 1274 COSINE and Internet X.500 Schema November 1991
+
+
+8.3.5. Room
+
+ The Room object class is used to define entries representing rooms.
+ The commonName attribute should be used for naming pentries of this
+ object class.
+
+ room OBJECT-CLASS
+ SUBCLASS OF top
+ MUST CONTAIN {
+ commonName}
+ MAY CONTAIN {
+ roomNumber,
+ description,
+ seeAlso,
+ telephoneNumber}
+ ::= {pilotObjectClass 7}
+
+8.3.6. Document Series
+
+ The Document Series object class is used to define an entry which
+ represents a series of documents (e.g., The Request For Comments
+ papers).
+
+ documentSeries OBJECT-CLASS
+ SUBCLASS OF top
+ MUST CONTAIN {
+ commonName}
+ MAY CONTAIN {
+ description,
+ seeAlso,
+ telephoneNumber,
+ localityName,
+ organizationName,
+ organizationalUnitName}
+ ::= {pilotObjectClass 9}
+
+8.3.7. Domain
+
+ The Domain object class is used to define entries which represent DNS
+ or NRS domains. The domainComponent attribute should be used for
+ naming entries of this object class. The usage of this object class
+ is described in more detail in [3].
+
+ domain OBJECT-CLASS
+ SUBCLASS OF top
+ MUST CONTAIN {
+ domainComponent}
+ MAY CONTAIN {
+
+
+
+Barker & Kille [Page 11]
+
+RFC 1274 COSINE and Internet X.500 Schema November 1991
+
+
+ associatedName,
+ organizationName,
+ organizationalAttributeSet}
+ ::= {pilotObjectClass 13}
+
+8.3.8. RFC822 Local Part
+
+ The RFC822 Local Part object class is used to define entries which
+ represent the local part of RFC822 mail addresses. This treats this
+ part of an RFC822 address as a domain. The usage of this object
+ class is described in more detail in [3].
+
+ rFC822localPart OBJECT-CLASS
+ SUBCLASS OF domain
+ MAY CONTAIN {
+ commonName,
+ surname,
+ description,
+ seeAlso,
+ telephoneNumber,
+ postalAttributeSet,
+ telecommunicationAttributeSet}
+ ::= {pilotObjectClass 14}
+
+8.3.9. DNS Domain
+
+ The DNS Domain (Domain NameServer) object class is used to define
+ entries for DNS domains. The usage of this object class is described
+ in more detail in [3].
+
+ dNSDomain OBJECT-CLASS
+ SUBCLASS OF domain
+ MAY CONTAIN {
+ ARecord,
+ MDRecord,
+ MXRecord,
+ NSRecord,
+ SOARecord,
+ CNAMERecord}
+ ::= {pilotObjectClass 15}
+
+8.3.10. Domain Related Object
+
+ The Domain Related Object object class is used to define entries
+ which represent DNS/NRS domains which are "equivalent" to an X.500
+ domain: e.g., an organisation or organisational unit. The usage of
+ this object class is described in more detail in [3].
+
+
+
+
+Barker & Kille [Page 12]
+
+RFC 1274 COSINE and Internet X.500 Schema November 1991
+
+
+ domainRelatedObject OBJECT-CLASS
+ SUBCLASS OF top
+ MUST CONTAIN {
+ associatedDomain}
+ ::= {pilotObjectClass 17}
+
+8.3.11. Friendly Country
+
+ The Friendly Country object class is used to define country entries
+ in the DIT. The object class is used to allow friendlier naming of
+ countries than that allowed by the object class country. The naming
+ attribute of object class country, countryName, has to be a 2 letter
+ string defined in ISO 3166.
+
+ friendlyCountry OBJECT-CLASS
+ SUBCLASS OF country
+ MUST CONTAIN {
+ friendlyCountryName}
+ ::= {pilotObjectClass 18}
+
+8.3.12. Simple Security Object
+
+ The Simple Security Object object class is used to allow an entry to
+ have a userPassword attribute when an entry's principal object
+ classes do not allow userPassword as an attribute type.
+
+ simpleSecurityObject OBJECT-CLASS
+ SUBCLASS OF top
+ MUST CONTAIN {
+ userPassword }
+ ::= {pilotObjectClass 19}
+
+8.3.13. Pilot Organization
+
+ The PilotOrganization object class is used as a sub-class of
+ organization and organizationalUnit to allow a number of additional
+ attributes to be assigned to entries of object classes organization
+ and organizationalUnit.
+
+ pilotOrganization OBJECT-CLASS
+ SUBCLASS OF organization, organizationalUnit
+ MAY CONTAIN {
+ buildingName}
+ ::= {pilotObjectClass 20}
+
+
+
+
+
+
+
+Barker & Kille [Page 13]
+
+RFC 1274 COSINE and Internet X.500 Schema November 1991
+
+
+8.3.14. Pilot DSA
+
+ The PilotDSA object class is used as a sub-class of the dsa object
+ class to allow additional attributes to be assigned to entries for
+ DSAs.
+
+ pilotDSA OBJECT-CLASS
+ SUBCLASS OF dsa
+ MUST CONTAIN {
+ dSAQuality}
+ ::= {pilotObjectClass 21}
+
+8.3.15. Quality Labelled Data
+
+ The Quality Labelled Data object class is used to allow the
+ assignment of the data quality attributes to subtrees in the DIT.
+
+ See [8] for more details.
+
+ qualityLabelledData OBJECT-CLASS
+ SUBCLASS OF top
+ MUST CONTAIN {
+ dSAQuality}
+ MAY CONTAIN {
+ subtreeMinimumQuality,
+ subtreeMaximumQuality}
+ ::= {pilotObjectClass 22}
+
+9. Attribute Types
+
+9.1. X.500 standard attribute types
+
+ A number of generally useful attribute types are defined in X.520,
+ and these are supported. Refer to that document for descriptions of
+ the suggested usage of these attribute types. The ASN.1 for these
+ attribute types is reproduced for completeness in Appendix C.
+
+9.2. X.400 standard attribute types
+
+ The standard X.400 attribute types are supported. See X.402 for full
+ details. The ASN.1 for these attribute types is reproduced in
+ Appendix C.
+
+9.3. COSINE/Internet attribute types
+
+ This section describes all the attribute types defined for use in the
+ COSINE and Internet pilots. Descriptions are given as to the
+ suggested usage of these attribute types. The ASN.1 for these
+
+
+
+Barker & Kille [Page 14]
+
+RFC 1274 COSINE and Internet X.500 Schema November 1991
+
+
+ attribute types is reproduced in Appendix C.
+
+9.3.1. Userid
+
+ The Userid attribute type specifies a computer system login name.
+
+ userid ATTRIBUTE
+ WITH ATTRIBUTE-SYNTAX
+ caseIgnoreStringSyntax
+ (SIZE (1 .. ub-user-identifier))
+ ::= {pilotAttributeType 1}
+
+9.3.2. Text Encoded O/R Address
+
+ The Text Encoded O/R Address attribute type specifies a text encoding
+ of an X.400 O/R address, as specified in RFC 987. The use of this
+ attribute is deprecated as the attribute is intended for interim use
+ only. This attribute will be the first candidate for the attribute
+ expiry mechanisms!
+
+ textEncodedORAddress ATTRIBUTE
+ WITH ATTRIBUTE-SYNTAX
+ caseIgnoreStringSyntax
+ (SIZE (1 .. ub-text-encoded-or-address))
+ ::= {pilotAttributeType 2}
+
+9.3.3. RFC 822 Mailbox
+
+ The RFC822 Mailbox attribute type specifies an electronic mailbox
+ attribute following the syntax specified in RFC 822. Note that this
+ attribute should not be used for greybook or other non-Internet order
+ mailboxes.
+
+ rfc822Mailbox ATTRIBUTE
+ WITH ATTRIBUTE-SYNTAX
+ caseIgnoreIA5StringSyntax
+ (SIZE (1 .. ub-rfc822-mailbox))
+ ::= {pilotAttributeType 3}
+
+9.3.4. Information
+
+ The Information attribute type specifies any general information
+ pertinent to an object. It is recommended that specific usage of
+ this attribute type is avoided, and that specific requirements are
+ met by other (possibly additional) attribute types.
+
+ info ATTRIBUTE
+ WITH ATTRIBUTE-SYNTAX
+
+
+
+Barker & Kille [Page 15]
+
+RFC 1274 COSINE and Internet X.500 Schema November 1991
+
+
+ caseIgnoreStringSyntax
+ (SIZE (1 .. ub-information))
+ ::= {pilotAttributeType 4}
+
+9.3.5. Favourite Drink
+
+ The Favourite Drink attribute type specifies the favourite drink of
+ an object (or person).
+
+ favouriteDrink ATTRIBUTE
+ WITH ATTRIBUTE-SYNTAX
+ caseIgnoreStringSyntax
+ (SIZE (1 .. ub-favourite-drink))
+ ::= {pilotAttributeType 5}
+
+9.3.6. Room Number
+
+ The Room Number attribute type specifies the room number of an
+ object. Note that the commonName attribute should be used for naming
+ room objects.
+
+ roomNumber ATTRIBUTE
+ WITH ATTRIBUTE-SYNTAX
+ caseIgnoreStringSyntax
+ (SIZE (1 .. ub-room-number))
+ ::= {pilotAttributeType 6}
+
+9.3.7. Photo
+
+ The Photo attribute type specifies a "photograph" for an object.
+ This should be encoded in G3 fax as explained in recommendation T.4,
+ with an ASN.1 wrapper to make it compatible with an X.400 BodyPart as
+ defined in X.420.
+
+ IMPORT G3FacsimileBodyPart FROM { mhs-motis ipms modules
+ information-objects }
+
+ photo ATTRIBUTE
+ WITH ATTRIBUTE-SYNTAX
+ CHOICE {
+ g3-facsimile [3] G3FacsimileBodyPart
+ }
+ (SIZE (1 .. ub-photo))
+ ::= {pilotAttributeType 7}
+
+
+
+
+
+
+
+Barker & Kille [Page 16]
+
+RFC 1274 COSINE and Internet X.500 Schema November 1991
+
+
+9.3.8. User Class
+
+ The User Class attribute type specifies a category of computer user.
+ The semantics placed on this attribute are for local interpretation.
+ Examples of current usage od this attribute in academia are
+ undergraduate student, researcher, lecturer, etc. Note that the
+ organizationalStatus attribute may now often be preferred as it makes
+ no distinction between computer users and others.
+
+ userClass ATTRIBUTE
+ WITH ATTRIBUTE-SYNTAX
+ caseIgnoreStringSyntax
+ (SIZE (1 .. ub-user-class))
+ ::= {pilotAttributeType 8}
+
+9.3.9. Host
+
+ The Host attribute type specifies a host computer.
+
+ host ATTRIBUTE
+ WITH ATTRIBUTE-SYNTAX
+ caseIgnoreStringSyntax
+ (SIZE (1 .. ub-host))
+ ::= {pilotAttributeType 9}
+
+9.3.10. Manager
+
+ The Manager attribute type specifies the manager of an object
+ represented by an entry.
+
+ manager ATTRIBUTE
+ WITH ATTRIBUTE-SYNTAX
+ distinguishedNameSyntax
+ ::= {pilotAttributeType 10}
+
+9.3.11. Document Identifier
+
+ The Document Identifier attribute type specifies a unique identifier
+ for a document.
+
+ documentIdentifier ATTRIBUTE
+ WITH ATTRIBUTE-SYNTAX
+ caseIgnoreStringSyntax
+ (SIZE (1 .. ub-document-identifier))
+ ::= {pilotAttributeType 11}
+
+
+
+
+
+
+Barker & Kille [Page 17]
+
+RFC 1274 COSINE and Internet X.500 Schema November 1991
+
+
+9.3.12. Document Title
+
+ The Document Title attribute type specifies the title of a document.
+
+ documentTitle ATTRIBUTE
+ WITH ATTRIBUTE-SYNTAX
+ caseIgnoreStringSyntax
+ (SIZE (1 .. ub-document-title))
+ ::= {pilotAttributeType 12}
+
+9.3.13. Document Version
+
+ The Document Version attribute type specifies the version number of a
+ document.
+
+ documentVersion ATTRIBUTE
+ WITH ATTRIBUTE-SYNTAX
+ caseIgnoreStringSyntax
+ (SIZE (1 .. ub-document-version))
+ ::= {pilotAttributeType 13}
+
+9.3.14. Document Author
+
+ The Document Author attribute type specifies the distinguished name
+ of the author of a document.
+
+ documentAuthor ATTRIBUTE
+ WITH ATTRIBUTE-SYNTAX
+ distinguishedNameSyntax
+ ::= {pilotAttributeType 14}
+
+9.3.15. Document Location
+
+ The Document Location attribute type specifies the location of the
+ document original.
+
+ documentLocation ATTRIBUTE
+ WITH ATTRIBUTE-SYNTAX
+ caseIgnoreStringSyntax
+ (SIZE (1 .. ub-document-location))
+ ::= {pilotAttributeType 15}
+
+9.3.16. Home Telephone Number
+
+ The Home Telephone Number attribute type specifies a home telephone
+ number associated with a person. Attribute values should follow the
+ agreed format for international telephone numbers: i.e., "+44 71 123
+ 4567".
+
+
+
+Barker & Kille [Page 18]
+
+RFC 1274 COSINE and Internet X.500 Schema November 1991
+
+
+ homeTelephoneNumber ATTRIBUTE
+ WITH ATTRIBUTE-SYNTAX
+ telephoneNumberSyntax
+ ::= {pilotAttributeType 20}
+
+9.3.17. Secretary
+
+ The Secretary attribute type specifies the secretary of a person.
+ The attribute value for Secretary is a distinguished name.
+
+ secretary ATTRIBUTE
+ WITH ATTRIBUTE-SYNTAX
+ distinguishedNameSyntax
+ ::= {pilotAttributeType 21}
+
+9.3.18. Other Mailbox
+
+ The Other Mailbox attribute type specifies values for electronic
+ mailbox types other than X.400 and rfc822.
+
+ otherMailbox ATTRIBUTE
+ WITH ATTRIBUTE-SYNTAX
+ SEQUENCE {
+ mailboxType PrintableString, -- e.g. Telemail
+ mailbox IA5String -- e.g. X378:Joe
+ }
+ ::= {pilotAttributeType 22}
+
+9.3.19. Last Modified Time
+
+ The Last Modified Time attribute type specifies the last time, in UTC
+ time, that an entry was modified. Ideally, this attribute should be
+ maintained by the DSA.
+
+ lastModifiedTime ATTRIBUTE
+ WITH ATTRIBUTE-SYNTAX
+ uTCTimeSyntax
+ ::= {pilotAttributeType 23}
+
+9.3.20. Last Modified By
+
+ The Last Modified By attribute specifies the distinguished name of
+ the last user to modify the associated entry. Ideally, this
+ attribute should be maintained by the DSA.
+
+ lastModifiedBy ATTRIBUTE
+ WITH ATTRIBUTE-SYNTAX
+ distinguishedNameSyntax
+
+
+
+Barker & Kille [Page 19]
+
+RFC 1274 COSINE and Internet X.500 Schema November 1991
+
+
+ ::= {pilotAttributeType 24}
+
+9.3.21. Domain Component
+
+ The Domain Component attribute type specifies a DNS/NRS domain. For
+ example, "uk" or "ac".
+
+ domainComponent ATTRIBUTE
+ WITH ATTRIBUTE-SYNTAX
+ caseIgnoreIA5StringSyntax
+ SINGLE VALUE
+ ::= {pilotAttributeType 25}
+
+ 9.3.22. DNS ARecord
+
+ The A Record attribute type specifies a type A (Address) DNS resource
+ record [6] [7].
+
+ aRecord ATTRIBUTE
+ WITH ATTRIBUTE-SYNTAX
+ DNSRecordSyntax
+ ::= {pilotAttributeType 26}
+
+9.3.23. MX Record
+
+ The MX Record attribute type specifies a type MX (Mail Exchange) DNS
+ resource record [6] [7].
+
+ mXRecord ATTRIBUTE
+ WITH ATTRIBUTE-SYNTAX
+ DNSRecordSyntax
+ ::= {pilotAttributeType 28}
+
+9.3.24. NS Record
+
+ The NS Record attribute type specifies an NS (Name Server) DNS
+ resource record [6] [7].
+
+ nSRecord ATTRIBUTE
+ WITH ATTRIBUTE-SYNTAX
+ DNSRecordSyntax
+ ::= {pilotAttributeType 29}
+
+9.3.25. SOA Record
+
+ The SOA Record attribute type specifies a type SOA (Start of
+ Authority) DNS resorce record [6] [7].
+
+
+
+
+Barker & Kille [Page 20]
+
+RFC 1274 COSINE and Internet X.500 Schema November 1991
+
+
+ sOARecord ATTRIBUTE
+ WITH ATTRIBUTE-SYNTAX
+ DNSRecordSyntax
+ ::= {pilotAttributeType 30}
+
+9.3.26. CNAME Record
+
+ The CNAME Record attribute type specifies a type CNAME (Canonical
+ Name) DNS resource record [6] [7].
+
+ cNAMERecord ATTRIBUTE
+ WITH ATTRIBUTE-SYNTAX
+ iA5StringSyntax
+ ::= {pilotAttributeType 31}
+
+9.3.27. Associated Domain
+
+ The Associated Domain attribute type specifies a DNS or NRS domain
+ which is associated with an object in the DIT. For example, the entry
+ in the DIT with a distinguished name "C=GB, O=University College
+ London" would have an associated domain of "UCL.AC.UK. Note that all
+ domains should be represented in rfc822 order. See [3] for more
+ details of usage of this attribute.
+
+ associatedDomain ATTRIBUTE
+ WITH ATTRIBUTE-SYNTAX
+ caseIgnoreIA5StringSyntax
+ ::= {pilotAttributeType 37}
+
+9.3.28. Associated Name
+
+ The Associated Name attribute type specifies an entry in the
+ organisational DIT associated with a DNS/NRS domain. See [3] for
+ more details of usage of this attribute.
+
+ associatedName ATTRIBUTE
+ WITH ATTRIBUTE-SYNTAX
+ distinguishedNameSyntax
+ ::= {pilotAttributeType 38}
+
+9.3.29. Home postal address
+
+ The Home postal address attribute type specifies a home postal
+ address for an object. This should be limited to up to 6 lines of 30
+ characters each.
+
+ homePostalAddress ATTRIBUTE
+ WITH ATTRIBUTE-SYNTAX
+
+
+
+Barker & Kille [Page 21]
+
+RFC 1274 COSINE and Internet X.500 Schema November 1991
+
+
+ postalAddress
+ MATCHES FOR EQUALITY
+ ::= {pilotAttributeType 39}
+
+9.3.30. Personal Title
+
+ The Personal Title attribute type specifies a personal title for a
+ person. Examples of personal titles are "Ms", "Dr", "Prof" and "Rev".
+
+ personalTitle ATTRIBUTE
+ WITH ATTRIBUTE-SYNTAX
+ caseIgnoreStringSyntax
+ (SIZE (1 .. ub-personal-title))
+ ::= {pilotAttributeType 40}
+
+9.3.31. Mobile Telephone Number
+
+ The Mobile Telephone Number attribute type specifies a mobile
+ telephone number associated with a person. Attribute values should
+ follow the agreed format for international telephone numbers: i.e.,
+ "+44 71 123 4567".
+
+ mobileTelephoneNumber ATTRIBUTE
+ WITH ATTRIBUTE-SYNTAX
+ telephoneNumberSyntax
+ ::= {pilotAttributeType 41}
+
+9.3.32. Pager Telephone Number
+
+ The Pager Telephone Number attribute type specifies a pager telephone
+ number for an object. Attribute values should follow the agreed
+ format for international telephone numbers: i.e., "+44 71 123 4567".
+
+ pagerTelephoneNumber ATTRIBUTE
+ WITH ATTRIBUTE-SYNTAX
+ telephoneNumberSyntax
+ ::= {pilotAttributeType 42}
+
+9.3.33. Friendly Country Name
+
+ The Friendly Country Name attribute type specifies names of countries
+ in human readable format. The standard attribute country name must
+ be one of the two-letter codes defined in ISO 3166.
+
+ friendlyCountryName ATTRIBUTE
+ WITH ATTRIBUTE-SYNTAX
+ caseIgnoreStringSyntax
+ ::= {pilotAttributeType 43}
+
+
+
+Barker & Kille [Page 22]
+
+RFC 1274 COSINE and Internet X.500 Schema November 1991
+
+
+9.3.34. Unique Identifier
+
+ The Unique Identifier attribute type specifies a "unique identifier"
+ for an object represented in the Directory. The domain within which
+ the identifier is unique, and the exact semantics of the identifier,
+ are for local definition. For a person, this might be an
+ institution-wide payroll number. For an organisational unit, it
+ might be a department code.
+
+ uniqueIdentifier ATTRIBUTE
+ WITH ATTRIBUTE-SYNTAX
+ caseIgnoreStringSyntax
+ (SIZE (1 .. ub-unique-identifier))
+ ::= {pilotAttributeType 44}
+
+9.3.35. Organisational Status
+
+ The Organisational Status attribute type specifies a category by
+ which a person is often referred to in an organisation. Examples of
+ usage in academia might include undergraduate student, researcher,
+ lecturer, etc.
+
+ A Directory administrator should probably consider carefully the
+ distinctions between this and the title and userClass attributes.
+
+ organizationalStatus ATTRIBUTE
+ WITH ATTRIBUTE-SYNTAX
+ caseIgnoreStringSyntax
+ (SIZE (1 .. ub-organizational-status))
+ ::= {pilotAttributeType 45}
+
+9.3.36. Janet Mailbox
+
+ The Janet Mailbox attribute type specifies an electronic mailbox
+ attribute following the syntax specified in the Grey Book of the
+ Coloured Book series. This attribute is intended for the convenience
+ of U.K users unfamiliar with rfc822 and little-endian mail addresses.
+ Entries using this attribute MUST also include an rfc822Mailbox
+ attribute.
+
+ janetMailbox ATTRIBUTE
+ WITH ATTRIBUTE-SYNTAX
+ caseIgnoreIA5StringSyntax
+ (SIZE (1 .. ub-janet-mailbox))
+ ::= {pilotAttributeType 46}
+
+
+
+
+
+
+Barker & Kille [Page 23]
+
+RFC 1274 COSINE and Internet X.500 Schema November 1991
+
+
+9.3.37. Mail Preference Option
+
+ An attribute to allow users to indicate a preference for inclusion of
+ their names on mailing lists (electronic or physical). The absence
+ of such an attribute should be interpreted as if the attribute was
+ present with value "no-list-inclusion". This attribute should be
+ interpreted by anyone using the directory to derive mailing lists,
+ and its value respected.
+
+ mailPreferenceOption ATTRIBUTE
+ WITH ATTRIBUTE-SYNTAX ENUMERATED {
+ no-list-inclusion(0),
+ any-list-inclusion(1), -- may be added to any lists
+ professional-list-inclusion(2)
+ -- may be added to lists
+ -- which the list provider
+ -- views as related to the
+ -- users professional inter-
+ -- ests, perhaps evaluated
+ -- from the business of the
+ -- organisation or keywords
+ -- in the entry.
+ }
+ ::= {pilotAttributeType 47}
+
+9.3.38. Building Name
+
+ The Building Name attribute type specifies the name of the building
+ where an organisation or organisational unit is based.
+
+ buildingName ATTRIBUTE
+ WITH ATTRIBUTE-SYNTAX
+ caseIgnoreStringSyntax
+ (SIZE (1 .. ub-building-name))
+ ::= {pilotAttributeType 48}
+
+9.3.39. DSA Quality
+
+ The DSA Quality attribute type specifies the purported quality of a
+ DSA. It allows a DSA manager to indicate the expected level of
+ availability of the DSA. See [8] for details of the syntax.
+
+ dSAQuality ATTRIBUTE
+ WITH ATTRIBUTE-SYNTAX DSAQualitySyntax
+ SINGLE VALUE
+ ::= {pilotAttributeType 49}
+
+
+
+
+
+Barker & Kille [Page 24]
+
+RFC 1274 COSINE and Internet X.500 Schema November 1991
+
+
+9.3.40. Single Level Quality
+
+ The Single Level Quality attribute type specifies the purported data
+ quality at the level immediately below in the DIT. See [8] for
+ details of the syntax.
+
+ singleLevelQuality ATTRIBUTE
+ WITH ATTRIBUTE-SYNTAX DataQualitySyntax
+ SINGLE VALUE
+ ::= {pilotAttributeType 50}
+
+9.3.41. Subtree Minimum Quality
+
+ The Subtree Minimum Quality attribute type specifies the purported
+ minimum data quality for a DIT subtree. See [8] for more discussion
+ and details of the syntax.
+
+ subtreeMinimumQuality ATTRIBUTE
+ WITH ATTRIBUTE-SYNTAX DataQualitySyntax
+ SINGLE VALUE
+ -- Defaults to singleLevelQuality
+ ::= {pilotAttributeType 51}
+
+9.3.42. Subtree Maximum Quality
+
+ The Subtree Maximum Quality attribute type specifies the purported
+ maximum data quality for a DIT subtree. See [8] for more discussion
+ and details of the syntax.
+
+ subtreeMaximumQuality ATTRIBUTE
+ WITH ATTRIBUTE-SYNTAX DataQualitySyntax
+ SINGLE VALUE
+ -- Defaults to singleLevelQuality
+ ::= {pilotAttributeType 52}
+
+9.3.43. Personal Signature
+
+ The Personal Signature attribute type allows for a representation of
+ a person's signature. This should be encoded in G3 fax as explained
+ in recommendation T.4, with an ASN.1 wrapper to make it compatible
+ with an X.400 BodyPart as defined in X.420.
+
+ IMPORT G3FacsimileBodyPart FROM { mhs-motis ipms modules
+ information-objects }
+
+ personalSignature ATTRIBUTE
+ WITH ATTRIBUTE-SYNTAX
+ CHOICE {
+
+
+
+Barker & Kille [Page 25]
+
+RFC 1274 COSINE and Internet X.500 Schema November 1991
+
+
+ g3-facsimile [3] G3FacsimileBodyPart
+ }
+ (SIZE (1 .. ub-personal-signature))
+ ::= {pilotAttributeType 53}
+
+9.3.44. DIT Redirect
+
+ The DIT Redirect attribute type is used to indicate that the object
+ described by one entry now has a newer entry in the DIT. The entry
+ containing the redirection attribute should be expired after a
+ suitable grace period. This attribute may be used when an individual
+ changes his/her place of work, and thus acquires a new organisational
+ DN.
+
+ dITRedirect ATTRIBUTE
+ WITH ATTRIBUTE-SYNTAX
+ distinguishedNameSyntax
+ ::= {pilotAttributeType 54}
+
+9.3.45. Audio
+
+ The Audio attribute type allows the storing of sounds in the
+ Directory. The attribute uses a u-law encoded sound file as used by
+ the "play" utility on a Sun 4. This is an interim format.
+
+ audio ATTRIBUTE
+ WITH ATTRIBUTE-SYNTAX
+ Audio
+ (SIZE (1 .. ub-audio))
+ ::= {pilotAttributeType 55}
+
+9.3.46. Publisher of Document
+
+
+ The Publisher of Document attribute is the person and/or organization
+ that published a document.
+
+ documentPublisher ATTRIBUTE
+ WITH ATTRIBUTE SYNTAX caseIgnoreStringSyntax
+ ::= {pilotAttributeType 56}
+
+9.4. Generally useful syntaxes
+
+ caseIgnoreIA5StringSyntax ATTRIBUTE-SYNTAX
+ IA5String
+ MATCHES FOR EQUALITY SUBSTRINGS
+
+
+
+
+
+Barker & Kille [Page 26]
+
+RFC 1274 COSINE and Internet X.500 Schema November 1991
+
+
+ iA5StringSyntax ATTRIBUTE-SYNTAX
+ IA5String
+ MATCHES FOR EQUALITY SUBSTRINGS
+
+
+ -- Syntaxes to support the DNS attributes
+
+ DNSRecordSyntax ATTRIBUTE-SYNTAX
+ IA5String
+ MATCHES FOR EQUALITY
+
+
+ NRSInformationSyntax ATTRIBUTE-SYNTAX
+ NRSInformation
+ MATCHES FOR EQUALITY
+
+
+ NRSInformation ::= SET {
+ [0] Context,
+ [1] Address-space-id,
+ routes [2] SEQUENCE OF SEQUENCE {
+ Route-cost,
+ Addressing-info }
+ }
+
+
+9.5. Upper bounds on length of attribute values
+
+
+ ub-document-identifier INTEGER ::= 256
+
+ ub-document-location INTEGER ::= 256
+
+ ub-document-title INTEGER ::= 256
+
+ ub-document-version INTEGER ::= 256
+
+ ub-favourite-drink INTEGER ::= 256
+
+ ub-host INTEGER ::= 256
+
+ ub-information INTEGER ::= 2048
+
+ ub-unique-identifier INTEGER ::= 256
+
+ ub-personal-title INTEGER ::= 256
+
+ ub-photo INTEGER ::= 250000
+
+
+
+Barker & Kille [Page 27]
+
+RFC 1274 COSINE and Internet X.500 Schema November 1991
+
+
+ ub-rfc822-mailbox INTEGER ::= 256
+
+ ub-room-number INTEGER ::= 256
+
+ ub-text-or-address INTEGER ::= 256
+
+ ub-user-class INTEGER ::= 256
+
+ ub-user-identifier INTEGER ::= 256
+
+ ub-organizational-status INTEGER ::= 256
+
+ ub-janet-mailbox INTEGER ::= 256
+
+ ub-building-name INTEGER ::= 256
+
+ ub-personal-signature ::= 50000
+
+ ub-audio INTEGER ::= 250000
+
+References
+
+ [1] CCITT/ISO, "X.500, The Directory - overview of concepts,
+ models and services, CCITT /ISO IS 9594.
+
+ [2] Kille, S., "The THORN and RARE X.500 Naming Architecture, in
+ University College London, Department of Computer Science
+ Research Note 89/48, May 1989.
+
+ [3] Kille, S., "X.500 and Domains", RFC 1279, University College
+ London, November 1991.
+
+ [4] Rose, M., "PSI/NYSERNet White Pages Pilot Project: Status
+ Report", Technical Report 90-09-10-1, published by NYSERNet
+ Inc, 1990.
+
+ [5] Craigie, J., "UK Academic Community Directory Service Pilot
+ Project, pp. 305-310 in Computer Networks and ISDN Systems
+ 17 (1989), published by North Holland.
+
+ [6] Mockapetris, P., "Domain Names - Concepts and Facilities",
+ RFC 1034, USC/Information Sciences Institute, November 1987.
+
+ [7] Mockapetris, P., "Domain Names - Implementation and
+ Specification, RFC 1035, USC/Information Sciences Institute,
+ November 1987.
+
+ [8] Kille, S., "Handling QOS (Quality of service) in the
+
+
+
+Barker & Kille [Page 28]
+
+RFC 1274 COSINE and Internet X.500 Schema November 1991
+
+
+ Directory," publication in process, March 1991.
+
+APPENDIX A - Object Class and Attribute Type proformas
+
+ These are specified in BNF. First some useful definitions, common to
+ both proformas.
+
+ EOL ::= -- the end of line character(s)
+
+ BlankLine ::= -- a line consisting solely of an EOL character
+
+ String ::= <anychar> | <String> <anychar>
+
+ anychar ::= --any character occurring in general text, excluding
+ -- the end of line character
+
+ lString ::= <lowercase> <otherstring>
+
+ lowercase ::= [a-z]
+
+ UString ::= <uppercase> <otherstring>
+
+ uppercase ::= [A-Z]
+
+ otherstring ::= <otherchar> | <otherstring> <otherchar>
+
+ otherchar ::= <lowercase> | <uppercase> | <digit>
+
+ Integer ::= <digit> | <Integer> <digit>
+
+ digit ::= [0-9]
+
+1. Object Class
+
+
+ OCProforma ::= <ObjectClassName> <BlankLine> <Description> \
+ <BlankLine> <OCMacro>
+
+ ObjectClassName ::= "ObjectClass:" <String> <EOL>
+
+ Description ::= "Description:" <DescriptiveText> <EOL>
+
+ DescriptiveText ::= <String> | <DescriptiveText> <EOL> <String>
+
+ OCMacro ::= "ASN1OCMacro:" <ObjectClassMacro>
+
+ -- The definition of ObjectClassMacro is adapted from
+ -- that given in X.501
+
+
+
+Barker & Kille [Page 29]
+
+RFC 1274 COSINE and Internet X.500 Schema November 1991
+
+
+ ObjectClassMacro ::= <OCname> "OBJECT-CLASS" <SubclassOf> \
+ <MandatoryAttributes> <OptionalAttributes>
+
+ OCName ::= <lString>
+
+ SubclassOf ::= "SUBCLASS OF" Subclasses | <empty>
+
+ Subclasses ::= <Subclass> | <Subclass> "," <Subclasses>
+
+ Subclass ::= <OCName>
+
+ MandatoryAttributes ::= "MUST CONTAIN {" <Attributes> "}" \
+ | <empty>
+ OptionalAttributes ::= "MAY CONTAIN {" <Attributes> "}" | <empty>
+
+ Attributes ::= <AttributeTerm> | <AttributeTerm> "," <Attributes>
+
+ AttributeTerm ::= <Attribute> | <AttributeSet>
+
+ Attribute ::= <lString>
+
+ AttributeSet ::= <lString>
+
+2. Attribute Type
+
+
+ ATProforma ::= <AttributeTypeName> <BlankLine> <Description> \
+ <BlankLine> <OCMust> <Blankline> <OCMay> \
+ <BlankLine> <ATMacro>
+
+ AttributeTypeName ::= "Attribute Type:" <String> <EOL>
+
+ Description ::= "Description:" <DescriptiveText> <EOL>
+
+ DescriptiveText ::= <String> | <DescriptiveText> <EOL> <String>
+
+ OCMust ::= "OCMust:" <OCList> <EOL>
+
+ OCList ::= <OCName> | <OCList> "," <OCName> | <empty>
+
+ OCMay ::= "OCMay:" <OCList> <EOL>
+
+ ATMacro ::= "ASN1ATMacro:" <AttributeTypeMacro>
+
+ -- The definition of AttributeTypeMacro is adapted from that
+ -- given in X.501
+
+ AttributeTypeMacro ::= <ATname> "ATTRIBUTE" <AttributeSyntax> \
+
+
+
+Barker & Kille [Page 30]
+
+RFC 1274 COSINE and Internet X.500 Schema November 1991
+
+
+ <Multivalued> | <empty>
+
+ ATName ::= <lString>
+
+ AttributeSyntax ::= "WITH ATTRIBUTE SYNTAX" SyntaxChoice
+
+ SyntaxChoice ::= <Syntax> <Constraint> | <ASN1Type> <MatchTypes>
+
+ Syntax ::= <lString>
+
+ Constraint ::= "(" ConstraintAlternative ")" | <empty>
+
+ ConstraintAlternative ::= StringConstraint | IntegerConstraint
+
+ StringConstraint ::= "SIZE" "(" SizeConstraint ")"
+
+ SizeConstraint ::= SingleValue | Range
+
+ SingleValue ::= <Integer>
+
+ Range ::= <Integer> ".." <Integer>
+
+ IntegerConstraint ::= Range
+
+ ASN1Type ::= <UString>
+ -- one of ASN.1's base types: e.g. PrintableString,
+ -- NumericString, etc.
+
+ MatchTypes ::= "MATCHES FOR" Matches | <empty>
+
+ Matches ::= Match | Matches Match
+
+ Match ::= "EQUALITY" | "SUBSTRINGS" | "ORDERING"
+
+ Multivalued ::= "SINGLE VALUE" | "MULTI VALUE" | <empty>
+
+APPENDIX B - Format checking tools
+
+ This section includes the source for format checking tools for the
+ two proformas. The tools are written as Bourne shell scripts for
+ UNIX systems.
+
+1. Object class format checker
+
+
+ sed 's/ *: */:/' |
+ awk '
+ BEGIN {
+
+
+
+Barker & Kille [Page 31]
+
+RFC 1274 COSINE and Internet X.500 Schema November 1991
+
+
+ state = "initial"
+ }
+
+ /^$/ {
+ next
+ }
+
+ /^Object Class:/ {
+ n = index($0, ":")
+ if (state != "initial")
+ {
+ print "Already got object class " oc
+ print "Got another object class " substr($0, n+1)
+ state = "notOK"
+ exit 1
+ }
+ oc = substr($0, n+1)
+ state = "gotOC"
+ next
+ }
+
+ /^Description:/ {
+ n = index($0, ":")
+ if (state != "gotOC")
+ {
+ print "Got Description: " substr($0, n+1)
+ for (i = 0; i < 2 && getline > 0; i++)
+ print $0
+ print "..."
+ if (state == "initial")
+ print "Expecting Object Class:"
+ else
+ print "Expecting ASN1OCMacro:"
+ state = "notOK"
+ exit 1
+ }
+ while (getline > 0)
+ if (length($0) > 0)
+ continue
+ else
+ break
+ state = "gotDesc"
+ next
+ }
+
+ /^ASN1OCMacro:/ {
+ n = index($0, ":")
+ if (state != "gotDesc")
+
+
+
+Barker & Kille [Page 32]
+
+RFC 1274 COSINE and Internet X.500 Schema November 1991
+
+
+ {
+ print "Got ASN1Macro: " substr($0, n+1)
+ for (i = 0; i < 2 && getline > 0; i++)
+ print $0
+ print "..."
+ if (state == "initial")
+ print "Expecting Object Class:"
+ else
+ print "Expecting Description:"
+ state = "notOK"
+ exit 1
+ }
+ state = "OK"
+ exit 0
+ }
+
+ {
+ print "Parsing has got confused on seeing line: " $0
+ state = "notOK"
+ exit 1
+ }
+
+ END {
+ if (state == "OK")
+ print "Input looks OK"
+ }
+
+
+2. Attribute Type format checker
+
+
+ sed 's/ *: */:/' |
+ awk '
+ BEGIN {
+ state = "initial"
+ }
+
+ /^$/ {
+ next
+ }
+
+ /^Attribute Type:/ {
+ n = index($0, ":")
+ if (state != "initial")
+ {
+ got = "Attribute Type:"
+ exit 1
+ }
+
+
+
+Barker & Kille [Page 33]
+
+RFC 1274 COSINE and Internet X.500 Schema November 1991
+
+
+ state = "gotAT"
+ next
+ }
+
+ /^Description:/ {
+ n = index($0, ":")
+ if (state != "gotAT")
+ {
+ got = "Description:"
+ exit 1
+ }
+ while (getline > 0)
+ if (length($0) > 0)
+ continue
+ else
+ break
+ state = "gotDesc"
+ next
+ }
+
+ /^OCMust:/ {
+ n = index($0, ":")
+ if (state != "gotDesc")
+ {
+ got = "OCMust:"
+ exit 1
+ }
+ state = "gotOCMust"
+ next
+ }
+
+ /^OCMay:/ {
+ n = index($0, ":")
+ if (state != "gotOCMust")
+ {
+ got = "OCMay:"
+ exit 1
+ }
+ state = "gotOCMay"
+ next
+ }
+
+ /^ASN1ATMacro:/ {
+ n = index($0, ":")
+ if (state != "gotOCMay")
+ {
+ got = "ASN1ATMacro:"
+ exit 1
+
+
+
+Barker & Kille [Page 34]
+
+RFC 1274 COSINE and Internet X.500 Schema November 1991
+
+
+ }
+ state = "OK"
+ exit 0
+ }
+
+ {
+ print "Parsing has got confused on seeing line: " $0
+ state = "notOK"
+ exit 1
+ }
+
+ END {
+ if (state == "initial")
+ print "Expecting Attribute Type:"
+ else if (state == "gotAT")
+ print "Expecting Description:"
+ else if (state == "gotDesc")
+ print "Expecting OCMust:"
+ else if (state == "gotOCMust")
+ print "Expecting OCMay:"
+ else if (state == "gotOCMay")
+ print "Expecting ASN1ATMacro:"
+ if (state != "OK")
+ print "Got " got
+ else
+ print "Input looks OK"
+ }
+
+
+APPENDIX C - Summary of all Object Classes and Attribute Types
+
+ -- Some Important Object Identifiers
+
+ data OBJECT IDENTIFIER ::= {ccitt 9}
+ pss OBJECT IDENTIFIER ::= {data 2342}
+ ucl OBJECT IDENTIFIER ::= {pss 19200300}
+ pilot OBJECT IDENTIFIER ::= {ucl 100}
+
+ pilotAttributeType OBJECT IDENTIFIER ::= {pilot 1}
+ pilotAttributeSyntax OBJECT IDENTIFIER ::= {pilot 3}
+ pilotObjectClass OBJECT IDENTIFIER ::= {pilot 4}
+ pilotGroups OBJECT IDENTIFIER ::= {pilot 10}
+
+ iA5StringSyntax OBJECT IDENTIFIER ::= {pilotAttributeSyntax 4}
+ caseIgnoreIA5StringSyntax OBJECT IDENTIFIER ::=
+ {pilotAttributeSyntax 5}
+
+
+
+
+
+Barker & Kille [Page 35]
+
+RFC 1274 COSINE and Internet X.500 Schema November 1991
+
+
+ -- Standard Object Classes
+
+ top OBJECT-CLASS
+ MUST CONTAIN {
+ objectClass}
+ ::= {objectClass 0}
+
+
+ alias OBJECT-CLASS
+ SUBCLASS OF top
+ MUST CONTAIN {
+ aliasedObjectName}
+ ::= {objectClass 1}
+
+
+ country OBJECT-CLASS
+ SUBCLASS OF top
+ MUST CONTAIN {
+ countryName}
+ MAY CONTAIN {
+ description,
+ searchGuide}
+ ::= {objectClass 2}
+
+
+ locality OBJECT-CLASS
+ SUBCLASS OF top
+ MAY CONTAIN {
+ description,
+ localityName,
+ stateOrProvinceName,
+ searchGuide,
+ seeAlso,
+ streetAddress}
+ ::= {objectClass 3}
+
+
+ organization OBJECT-CLASS
+ SUBCLASS OF top
+ MUST CONTAIN {
+ organizationName}
+ MAY CONTAIN {
+ organizationalAttributeSet}
+ ::= {objectClass 4}
+
+
+
+
+
+
+
+Barker & Kille [Page 36]
+
+RFC 1274 COSINE and Internet X.500 Schema November 1991
+
+
+ organizationalUnit OBJECT-CLASS
+ SUBCLASS OF top
+ MUST CONTAIN {
+ organizationalUnitName}
+ MAY CONTAIN {
+ organizationalAttributeSet}
+ ::= {objectClass 5}
+
+
+ person OBJECT-CLASS
+ SUBCLASS OF top
+ MUST CONTAIN {
+ commonName,
+ surname}
+ MAY CONTAIN {
+ description,
+ seeAlso,
+ telephoneNumber,
+ userPassword}
+ ::= {objectClass 6}
+
+
+ organizationalPerson OBJECT-CLASS
+ SUBCLASS OF person
+ MAY CONTAIN {
+ localeAttributeSet,
+ organizationalUnitName,
+ postalAttributeSet,
+ telecommunicationAttributeSet,
+ title}
+ ::= {objectClass 7}
+
+
+ organizationalRole OBJECT-CLASS
+ SUBCLASS OF top
+ MUST CONTAIN {
+ commonName}
+ MAY CONTAIN {
+ description,
+ localeAttributeSet,
+ organizationalUnitName,
+ postalAttributeSet,
+ preferredDeliveryMethod,
+ roleOccupant,
+ seeAlso,
+ telecommunicationAttributeSet}
+ ::= {objectClass 8}
+
+
+
+
+Barker & Kille [Page 37]
+
+RFC 1274 COSINE and Internet X.500 Schema November 1991
+
+
+ groupOfNames OBJECT-CLASS
+ SUBCLASS OF top
+ MUST CONTAIN {
+ commonName,
+ member}
+ MAY CONTAIN {
+ description,
+ organizationName,
+ organizationalUnitName,
+ owner,
+ seeAlso,
+ businessCategory}
+ ::= {objectClass 9}
+
+
+ residentialPerson OBJECT-CLASS
+ SUBCLASS OF person
+ MUST CONTAIN {
+ localityName}
+ MAY CONTAIN {
+ localeAttributeSet,
+ postalAttributeSet,
+ preferredDeliveryMethod,
+ telecommunicationAttributeSet,
+ businessCategory}
+ ::= {objectClass 10}
+
+
+ applicationProcess OBJECT-CLASS
+ SUBCLASS OF top
+ MUST CONTAIN {
+ commonName}
+ MAY CONTAIN {
+ description,
+ localityName,
+ organizationalUnitName,
+ seeAlso}
+ ::= {objectClass 11}
+
+
+ applicationEntity OBJECT-CLASS
+ SUBCLASS OF top
+ MUST CONTAIN {
+ commonName,
+ presentationAddress}
+ MAY CONTAIN {
+ description,
+ localityName,
+
+
+
+Barker & Kille [Page 38]
+
+RFC 1274 COSINE and Internet X.500 Schema November 1991
+
+
+ organizationName,
+ organizationalUnitName,
+ seeAlso,
+ supportedApplicationContext}
+ ::= {objectClass 12}
+
+
+ dSA OBJECT-CLASS
+ SUBCLASS OF applicationEntity
+ MAY CONTAIN {
+ knowledgeInformation}
+ ::= {objectClass 13}
+
+
+ device OBJECT-CLASS
+ SUBCLASS OF top
+ MUST CONTAIN {
+ commonName}
+ MAY CONTAIN {
+ description,
+ localityName,
+ organizationName,
+ organizationalUnitName,
+ owner,
+ seeAlso,
+ serialNumber}
+ ::= {objectClass 14}
+
+
+ strongAuthenticationUser OBJECT-CLASS
+ SUBCLASS OF top
+ MUST CONTAIN {
+ userCertificate}
+ ::= {objectClass 15}
+
+
+ certificationAuthority OBJECT-CLASS
+ SUBCLASS OF top
+ MUST CONTAIN {
+ cACertificate,
+ certificateRevocationList,
+ authorityRevocationList}
+ MAY CONTAIN {
+ crossCertificatePair}
+ ::= {objectClass 16}
+
+
+
+
+
+
+Barker & Kille [Page 39]
+
+RFC 1274 COSINE and Internet X.500 Schema November 1991
+
+
+ -- Standard MHS Object Classes
+
+ mhsDistributionList OBJECT-CLASS
+ SUBCLASS OF top
+ MUST CONTAIN {
+ commonName,
+ mhsDLSubmitPermissions,
+ mhsORAddresses}
+ MAY CONTAIN {
+ description,
+ organizationName,
+ organizationalUnitName,
+ owner,
+ seeAlso,
+ mhsDeliverableContentTypes,
+ mhsdeliverableEits,
+ mhsDLMembers,
+ mhsPreferredDeliveryMethods}
+ ::= {mhsObjectClass 0}
+
+
+ mhsMessageStore OBJECT-CLASS
+ SUBCLASS OF applicationEntity
+ MAY CONTAIN {
+ description,
+ owner,
+ mhsSupportedOptionalAttributes,
+ mhsSupportedAutomaticActions,
+ mhsSupportedContentTypes}
+ ::= {mhsObjectClass 1}
+
+
+ mhsMessageTransferAgent OBJECT-CLASS
+ SUBCLASS OF applicationEntity
+ MAY CONTAIN {
+ description,
+ owner,
+ mhsDeliverableContentLength}
+ ::= {mhsObjectClass 2}
+
+
+ mhsOrganizationalUser OBJECT-CLASS
+ SUBCLASS OF organizationalPerson
+ MUST CONTAIN {
+ mhsORAddresses}
+ MAY CONTAIN {
+ mhsDeliverableContentLength,
+ mhsDeliverableContentTypes,
+
+
+
+Barker & Kille [Page 40]
+
+RFC 1274 COSINE and Internet X.500 Schema November 1991
+
+
+ mhsDeliverableEits,
+ mhsMessageStoreName,
+ mhsPreferredDeliveryMethods }
+ ::= {mhsObjectClass 3}
+
+
+ mhsResidentialUser OBJECT-CLASS
+ SUBCLASS OF residentialPerson
+ MUST CONTAIN {
+ mhsORAddresses}
+ MAY CONTAIN {
+ mhsDeliverableContentLength,
+ mhsDeliverableContentTypes,
+ mhsDeliverableEits,
+ mhsMessageStoreName,
+ mhsPreferredDeliveryMethods }
+ ::= {mhsObjectClass 4}
+
+
+ mhsUserAgent OBJECT-CLASS
+ SUBCLASS OF applicationEntity
+ MAY CONTAIN {
+ mhsDeliverableContentLength,
+ mhsDeliverableContentTypes,
+ mhsDeliverableEits,
+ mhsORAddresses,
+ owner}
+ ::= {mhsObjectClass 5}
+
+
+
+
+ -- Pilot Object Classes
+
+ pilotObject OBJECT-CLASS
+ SUBCLASS OF top
+ MAY CONTAIN {
+ info,
+ photo,
+ manager,
+ uniqueIdentifier,
+ lastModifiedTime,
+ lastModifiedBy,
+ dITRedirect,
+ audio}
+ ::= {pilotObjectClass 3}
+
+
+
+
+
+Barker & Kille [Page 41]
+
+RFC 1274 COSINE and Internet X.500 Schema November 1991
+
+
+ pilotPerson OBJECT-CLASS
+ SUBCLASS OF person
+ MAY CONTAIN {
+ userid,
+ textEncodedORAddress,
+ rfc822Mailbox,
+ favouriteDrink,
+ roomNumber,
+ userClass,
+ homeTelephoneNumber,
+ homePostalAddress,
+ secretary,
+ personalTitle,
+ preferredDeliveryMethod,
+ businessCategory,
+ janetMailbox,
+ otherMailbox,
+ mobileTelephoneNumber,
+ pagerTelephoneNumber,
+ organizationalStatus,
+ mailPreferenceOption,
+ personalSignature}
+ ::= {pilotObjectClass 4}
+
+
+ account OBJECT-CLASS
+ SUBCLASS OF top
+ MUST CONTAIN {
+ userid}
+ MAY CONTAIN {
+ description,
+ seeAlso,
+ localityName,
+ organizationName,
+ organizationalUnitName,
+ host}
+ ::= {pilotObjectClass 5}
+
+
+ document OBJECT-CLASS
+ SUBCLASS OF top
+ MUST CONTAIN {
+ documentIdentifier}
+ MAY CONTAIN {
+ commonName,
+ description,
+ seeAlso,
+ localityName,
+
+
+
+Barker & Kille [Page 42]
+
+RFC 1274 COSINE and Internet X.500 Schema November 1991
+
+
+ organizationName,
+ organizationalUnitName,
+ documentTitle,
+ documentVersion,
+ documentAuthor,
+ documentLocation,
+ documentPublisher}
+ ::= {pilotObjectClass 6}
+
+
+ room OBJECT-CLASS
+ SUBCLASS OF top
+ MUST CONTAIN {
+ commonName}
+ MAY CONTAIN {
+ roomNumber,
+ description,
+ seeAlso,
+ telephoneNumber}
+ ::= {pilotObjectClass 7}
+
+
+ documentSeries OBJECT-CLASS
+ SUBCLASS OF top
+ MUST CONTAIN {
+ commonName}
+ MAY CONTAIN {
+ description,
+ seeAlso,
+ telephoneNumber,
+ localityName,
+ organizationName,
+ organizationalUnitName}
+ ::= {pilotObjectClass 9}
+
+
+ domain OBJECT-CLASS
+ SUBCLASS OF top
+ MUST CONTAIN {
+ domainComponent}
+ MAY CONTAIN {
+ associatedName,
+ organizationName,
+ organizationalAttributeSet}
+ ::= {pilotObjectClass 13}
+
+
+
+
+
+
+Barker & Kille [Page 43]
+
+RFC 1274 COSINE and Internet X.500 Schema November 1991
+
+
+ rFC822localPart OBJECT-CLASS
+ SUBCLASS OF domain
+ MAY CONTAIN {
+ commonName,
+ surname,
+ description,
+ seeAlso,
+ telephoneNumber,
+ postalAttributeSet,
+ telecommunicationAttributeSet}
+ ::= {pilotObjectClass 14}
+
+
+ dNSDomain OBJECT-CLASS
+ SUBCLASS OF domain
+ MAY CONTAIN {
+ ARecord,
+ MDRecord,
+ MXRecord,
+ NSRecord,
+ SOARecord,
+ CNAMERecord}
+ ::= {pilotObjectClass 15}
+
+
+ domainRelatedObject OBJECT-CLASS
+ SUBCLASS OF top
+ MUST CONTAIN {
+ associatedDomain}
+ ::= {pilotObjectClass 17}
+
+
+ friendlyCountry OBJECT-CLASS
+ SUBCLASS OF country
+ MUST CONTAIN {
+ friendlyCountryName}
+ ::= {pilotObjectClass 18}
+
+
+ simpleSecurityObject OBJECT-CLASS
+ SUBCLASS OF top
+ MUST CONTAIN {
+ userPassword }
+ ::= {pilotObjectClass 19}
+
+
+ pilotOrganization OBJECT-CLASS
+ SUBCLASS OF organization, organizationalUnit
+
+
+
+Barker & Kille [Page 44]
+
+RFC 1274 COSINE and Internet X.500 Schema November 1991
+
+
+ MAY CONTAIN {
+ buildingName}
+ ::= {pilotObjectClass 20}
+
+
+ pilotDSA OBJECT-CLASS
+ SUBCLASS OF dsa
+ MUST CONTAIN {
+ dSAQuality}
+ ::= {pilotObjectClass 21}
+
+
+ qualityLabelledData OBJECT-CLASS
+ SUBCLASS OF top
+ MUST CONTAIN {
+ dSAQuality}
+ MAY CONTAIN {
+ subtreeMinimumQuality,
+ subtreeMaximumQuality}
+ ::= {pilotObjectClass 22}
+
+
+
+
+ -- Standard Attribute Types
+
+ objectClass ObjectClass
+ ::= {attributeType 0}
+
+
+ aliasedObjectName AliasedObjectName
+ ::= {attributeType 1}
+
+
+ knowledgeInformation ATTRIBUTE
+ WITH ATTRIBUTE-SYNTAX caseIgnoreString
+ ::= {attributeType 2}
+
+
+ commonName ATTRIBUTE
+ WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax
+ (SIZE (1..ub-common-name))
+ ::= {attributeType 3}
+
+
+ surname ATTRIBUTE
+ WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax
+ (SIZE (1..ub-surname))
+
+
+
+Barker & Kille [Page 45]
+
+RFC 1274 COSINE and Internet X.500 Schema November 1991
+
+
+ ::= {attributeType 4}
+
+
+ serialNumber ATTRIBUTE
+ WITH ATTRIBUTE-SYNTAX printableStringSyntax
+ (SIZE (1..ub-serial-number))
+ ::= {attributeType 5}
+
+
+ countryName ATTRIBUTE
+ WITH ATTRIBUTE-SYNTAX PrintableString
+ (SIZE (1..ub-country-code))
+ SINGLE VALUE
+ ::= {attributeType 6}
+
+
+ localityName ATTRIBUTE
+ WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax
+ (SIZE (1..ub-locality-name))
+ ::= {attributeType 7}
+
+
+ stateOrProvinceName ATTRIBUTE
+ WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax
+ (SIZE (1..ub-state-name))
+ ::= {attributeType 8}
+
+
+ streetAddress ATTRIBUTE
+ WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax
+ (SIZE (1..ub-street-address))
+ ::= {attributeType 9}
+
+
+ organizationName ATTRIBUTE
+ WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax
+ (SIZE (1..ub-organization-name))
+ ::= {attributeType 10}
+
+
+ organizationalUnitName ATTRIBUTE
+ WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax
+ (SIZE (1..ub-organizational-unit-name))
+ ::= {attributeType 11}
+
+
+ title ATTRIBUTE
+ WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax
+
+
+
+Barker & Kille [Page 46]
+
+RFC 1274 COSINE and Internet X.500 Schema November 1991
+
+
+ (SIZE (1..ub-title))
+ ::= {attributeType 12}
+
+
+ description ATTRIBUTE
+ WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax
+ (SIZE (1..ub-description))
+ ::= {attributeType 13}
+
+
+ searchGuide ATTRIBUTE
+ WITH ATTRIBUTE-SYNTAX Guide
+ ::= {attributeType 14}
+
+
+ businessCategory ATTRIBUTE
+ WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax
+ (SIZE (1..ub-business-category))
+ ::= {attributeType 15}
+
+
+ postalAddress ATTRIBUTE
+ WITH ATTRIBUTE-SYNTAX PostalAddress
+ MATCHES FOR EQUALITY
+ ::= {attributeType 16}
+
+
+ postalCode ATTRIBUTE
+ WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax
+ (SIZE (1..ub-postal-code))
+ ::= {attributeType 17}
+
+
+ postOfficeBox ATTRIBUTE
+ WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax
+ (SIZE (1..ub-post-office-box))
+ ::= {attributeType 18}
+
+
+ physicalDeliveryOfficeName ATTRIBUTE
+ WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax
+ (SIZE (1..ub-physical-office-name))
+ ::= {attributeType 19}
+
+
+ telephoneNumber ATTRIBUTE
+ WITH ATTRIBUTE-SYNTAX telephoneNumberSyntax
+ (SIZE (1..ub-telephone-number))
+
+
+
+Barker & Kille [Page 47]
+
+RFC 1274 COSINE and Internet X.500 Schema November 1991
+
+
+ ::= {attributeType 20}
+
+
+ telexNumber ATTRIBUTE
+ WITH ATTRIBUTE-SYNTAX TelexNumber
+ (SIZE (1..ub-telex))
+ ::= {attributeType 21}
+
+
+ teletexTerminalIdentifier ATTRIBUTE
+ WITH ATTRIBUTE-SYNTAX TeletexTerminalIdentifier
+ (SIZE (1..ub-teletex-terminal-id))
+ ::= {attributeType 22}
+
+
+ facsimileTelephoneNumber ATTRIBUTE
+ WITH ATTRIBUTE-SYNTAX FacsimileTelephoneNumber
+ ::= {attributeType 23}
+
+
+ x121Address ATTRIBUTE
+ WITH ATTRIBUTE-SYNTAX NumericString
+ (SIZE (1..ub-x121-address))
+ ::= {attributeType 24}
+
+
+ internationaliSDNNumber ATTRIBUTE
+ WITH ATTRIBUTE-SYNTAX NumericString
+ (SIZE (1..ub-isdn-address))
+ ::= {attributeType 25}
+
+
+ registeredAddress ATTRIBUTE
+ WITH ATTRIBUTE-SYNTAX PostalAddress
+ ::= {attributeType 26}
+
+
+ destinationIndicator ATTRIBUTE
+ WITH ATTRIBUTE-SYNTAX PrintableString
+ (SIZE (1..ub-destination-indicator))
+ MATCHES FOR EQUALITY SUBSTRINGS
+ ::= {attributeType 27}
+
+
+ preferredDeliveryMethod ATTRIBUTE
+ WITH ATTRIBUTE-SYNTAX deliveryMethod
+ ::= {attributeType 28}
+
+
+
+
+Barker & Kille [Page 48]
+
+RFC 1274 COSINE and Internet X.500 Schema November 1991
+
+
+ presentationAddress ATTRIBUTE
+ WITH ATTRIBUTE-SYNTAX PresentationAddress
+ MATCHES FOR EQUALITY
+ ::= {attributeType 29}
+
+
+ supportedApplicationContext ATTRIBUTE
+ WITH ATTRIBUTE-SYNTAX objectIdentifierSyntax
+ ::= {attributeType 30}
+
+
+ member ATTRIBUTE
+ WITH ATTRIBUTE-SYNTAX distinguishedNameSyntax
+ ::= {attributeType 31}
+
+
+ owner ATTRIBUTE
+ WITH ATTRIBUTE-SYNTAX distinguishedNameSyntax
+ ::= {attributeType 32}
+
+
+ roleOccupant ATTRIBUTE
+ WITH ATTRIBUTE-SYNTAX distinguishedNameSyntax
+ ::= {attributeType 33}
+
+
+ seeAlso ATTRIBUTE
+ WITH ATTRIBUTE-SYNTAX distinguishedNameSyntax
+ ::= {attributeType 34}
+
+
+ userPassword ATTRIBUTE
+ WITH ATTRIBUTE-SYNTAX Userpassword
+ ::= {attributeType 35}
+
+
+ userCertificate ATTRIBUTE
+ WITH ATTRIBUTE-SYNTAX UserCertificate
+ ::= {attributeType 36}
+
+
+ cACertificate ATTRIBUTE
+ WITH ATTRIBUTE-SYNTAX cACertificate
+ ::= {attributeType 37}
+
+
+ authorityRevocationList ATTRIBUTE
+ WITH ATTRIBUTE-SYNTAX AuthorityRevocationList
+
+
+
+Barker & Kille [Page 49]
+
+RFC 1274 COSINE and Internet X.500 Schema November 1991
+
+
+ ::= {attributeType 38}
+
+
+ certificateRevocationList ATTRIBUTE
+ WITH ATTRIBUTE-SYNTAX CertificateRevocationList
+ ::= {attributeType 39}
+
+
+ crossCertificatePair ATTRIBUTE
+ WITH ATTRIBUTE-SYNTAX CrossCertificatePair
+ ::= {attributeType 40}
+
+
+
+
+ -- Standard MHS Attribute Types
+
+ mhsDeliverableContentLength ATTRIBUTE
+ WITH ATTRIBUTE-SYNTAX integer
+ ::= {mhsAttributeType 0}
+
+
+ mhsDeliverableContentTypes ATTRIBUTE
+ WITH ATTRIBUTE-SYNTAX oID
+ ::= {mhsAttributeType 1}
+
+
+ mhsDeliverableEits ATTRIBUTE
+ WITH ATTRIBUTE-SYNTAX oID
+ ::= {mhsAttributeType 2}
+
+
+ mhsDLMembers ATTRIBUTE
+ WITH ATTRIBUTE-SYNTAX oRName
+ ::= {mhsAttributeType 3}
+
+
+ mhsDLSubmitPermissions ATTRIBUTE
+ WITH ATTRIBUTE-SYNTAX dLSubmitPermission
+ ::= {mhsAttributeType 4}
+
+
+ mhsMessageStoreName ATTRIBUTE
+ WITH ATTRIBUTE-SYNTAX dN
+ ::= {mhsAttributeType 5}
+
+
+
+
+
+
+Barker & Kille [Page 50]
+
+RFC 1274 COSINE and Internet X.500 Schema November 1991
+
+
+ mhsORAddresses ATTRIBUTE
+ WITH ATTRIBUTE-SYNTAX oRAddress
+ ::= {mhsAttributeType 6}
+
+
+ mhsPreferredDeliveryMethods ATTRIBUTE
+ WITH ATTRIBUTE-SYNTAX deliveryMethod
+ ::= {mhsAttributeType 7}
+
+
+ mhsSupportedAutomaticActions ATTRIBUTE
+ WITH ATTRIBUTE-SYNTAX oID
+ ::= {mhsAttributeType 8}
+
+
+ mhsSupportedContentTypes ATTRIBUTE
+
+ WITH ATTRIBUTE-SYNTAX oID
+ ::= {mhsAttributeType 9}
+
+
+ mhsSupportedOptionalAttributes ATTRIBUTE
+ WITH ATTRIBUTE-SYNTAX oID
+ ::= {mhsAttributeType 10}
+
+
+
+
+ -- Pilot Attribute Types
+
+ userid ATTRIBUTE
+ WITH ATTRIBUTE-SYNTAX
+ caseIgnoreStringSyntax
+ (SIZE (1 .. ub-user-identifier))
+ ::= {pilotAttributeType 1}
+
+
+ textEncodedORAddress ATTRIBUTE
+ WITH ATTRIBUTE-SYNTAX
+ caseIgnoreStringSyntax
+ (SIZE (1 .. ub-text-encoded-or-address))
+ ::= {pilotAttributeType 2}
+
+
+ rfc822Mailbox ATTRIBUTE
+ WITH ATTRIBUTE-SYNTAX
+ caseIgnoreIA5StringSyntax
+ (SIZE (1 .. ub-rfc822-mailbox))
+
+
+
+Barker & Kille [Page 51]
+
+RFC 1274 COSINE and Internet X.500 Schema November 1991
+
+
+ ::= {pilotAttributeType 3}
+
+
+ info ATTRIBUTE
+ WITH ATTRIBUTE-SYNTAX
+ caseIgnoreStringSyntax
+ (SIZE (1 .. ub-information))
+ ::= {pilotAttributeType 4}
+
+
+ favouriteDrink ATTRIBUTE
+ WITH ATTRIBUTE-SYNTAX
+ caseIgnoreStringSyntax
+ (SIZE (1 .. ub-favourite-drink))
+ ::= {pilotAttributeType 5}
+
+
+ roomNumber ATTRIBUTE
+ WITH ATTRIBUTE-SYNTAX
+ caseIgnoreStringSyntax
+ (SIZE (1 .. ub-room-number))
+ ::= {pilotAttributeType 6}
+
+
+ photo ATTRIBUTE
+ WITH ATTRIBUTE-SYNTAX
+ CHOICE {
+ g3-facsimile [3] G3FacsimileBodyPart
+ }
+ (SIZE (1 .. ub-photo))
+ ::= {pilotAttributeType 7}
+
+
+ userClass ATTRIBUTE
+ WITH ATTRIBUTE-SYNTAX
+ caseIgnoreStringSyntax
+ (SIZE (1 .. ub-user-class))
+ ::= {pilotAttributeType 8}
+
+
+ host ATTRIBUTE
+ WITH ATTRIBUTE-SYNTAX
+ caseIgnoreStringSyntax
+ (SIZE (1 .. ub-host))
+ ::= {pilotAttributeType 9}
+
+
+
+
+
+
+Barker & Kille [Page 52]
+
+RFC 1274 COSINE and Internet X.500 Schema November 1991
+
+
+ manager ATTRIBUTE
+ WITH ATTRIBUTE-SYNTAX
+ distinguishedNameSyntax
+ ::= {pilotAttributeType 10}
+
+
+ documentIdentifier ATTRIBUTE
+ WITH ATTRIBUTE-SYNTAX
+ caseIgnoreStringSyntax
+ (SIZE (1 .. ub-document-identifier))
+ ::= {pilotAttributeType 11}
+
+
+ documentTitle ATTRIBUTE
+ WITH ATTRIBUTE-SYNTAX
+ caseIgnoreStringSyntax
+ (SIZE (1 .. ub-document-title))
+ ::= {pilotAttributeType 12}
+
+
+ documentVersion ATTRIBUTE
+ WITH ATTRIBUTE-SYNTAX
+ caseIgnoreStringSyntax
+ (SIZE (1 .. ub-document-version))
+ ::= {pilotAttributeType 13}
+
+
+ documentAuthor ATTRIBUTE
+ WITH ATTRIBUTE-SYNTAX
+ distinguishedNameSyntax
+ ::= {pilotAttributeType 14}
+
+
+ documentLocation ATTRIBUTE
+ WITH ATTRIBUTE-SYNTAX
+ caseIgnoreStringSyntax
+ (SIZE (1 .. ub-document-location))
+ ::= {pilotAttributeType 15}
+
+
+ homeTelephoneNumber ATTRIBUTE
+ WITH ATTRIBUTE-SYNTAX
+ telephoneNumberSyntax
+ ::= {pilotAttributeType 20}
+
+
+ secretary ATTRIBUTE
+ WITH ATTRIBUTE-SYNTAX
+
+
+
+Barker & Kille [Page 53]
+
+RFC 1274 COSINE and Internet X.500 Schema November 1991
+
+
+ distinguishedNameSyntax
+ ::= {pilotAttributeType 21}
+
+
+ otherMailbox ATTRIBUTE
+ WITH ATTRIBUTE-SYNTAX
+ SEQUENCE {
+ mailboxType PrintableString, -- e.g. Telemail
+ mailbox IA5String -- e.g. X378:Joe
+ }
+ ::= {pilotAttributeType 22}
+
+
+ lastModifiedTime ATTRIBUTE
+ WITH ATTRIBUTE-SYNTAX
+ uTCTimeSyntax
+ ::= {pilotAttributeType 23}
+
+
+ lastModifiedBy ATTRIBUTE
+ WITH ATTRIBUTE-SYNTAX
+ distinguishedNameSyntax
+ ::= {pilotAttributeType 24}
+
+
+ domainComponent ATTRIBUTE
+ WITH ATTRIBUTE-SYNTAX
+ caseIgnoreIA5StringSyntax
+ SINGLE VALUE
+ ::= {pilotAttributeType 25}
+
+
+ aRecord ATTRIBUTE
+ WITH ATTRIBUTE-SYNTAX
+ DNSRecordSyntax
+ ::= {pilotAttributeType 26}
+
+
+ mXRecord ATTRIBUTE
+ WITH ATTRIBUTE-SYNTAX
+ DNSRecordSyntax
+ ::= {pilotAttributeType 28}
+
+
+ nSRecord ATTRIBUTE
+ WITH ATTRIBUTE-SYNTAX
+ DNSRecordSyntax
+ ::= {pilotAttributeType 29}
+
+
+
+Barker & Kille [Page 54]
+
+RFC 1274 COSINE and Internet X.500 Schema November 1991
+
+
+ sOARecord ATTRIBUTE
+ WITH ATTRIBUTE-SYNTAX
+ DNSRecordSyntax
+ ::= {pilotAttributeType 30}
+
+
+ cNAMERecord ATTRIBUTE
+ WITH ATTRIBUTE-SYNTAX
+ iA5StringSyntax
+ ::= {pilotAttributeType 31}
+
+
+ associatedDomain ATTRIBUTE
+ WITH ATTRIBUTE-SYNTAX
+ caseIgnoreIA5StringSyntax
+ ::= {pilotAttributeType 37}
+
+
+ associatedName ATTRIBUTE
+ WITH ATTRIBUTE-SYNTAX
+ distinguishedNameSyntax
+ ::= {pilotAttributeType 38}
+
+
+ homePostalAddress ATTRIBUTE
+ WITH ATTRIBUTE-SYNTAX
+ postalAddress
+ MATCHES FOR EQUALITY
+ ::= {pilotAttributeType 39}
+
+
+ personalTitle ATTRIBUTE
+ WITH ATTRIBUTE-SYNTAX
+ caseIgnoreStringSyntax
+ (SIZE (1 .. ub-personal-title))
+ ::= {pilotAttributeType 40}
+
+
+ mobileTelephoneNumber ATTRIBUTE
+ WITH ATTRIBUTE-SYNTAX
+ telephoneNumberSyntax
+ ::= {pilotAttributeType 41}
+
+
+ pagerTelephoneNumber ATTRIBUTE
+ WITH ATTRIBUTE-SYNTAX
+ telephoneNumberSyntax
+ ::= {pilotAttributeType 42}
+
+
+
+Barker & Kille [Page 55]
+
+RFC 1274 COSINE and Internet X.500 Schema November 1991
+
+
+ friendlyCountryName ATTRIBUTE
+ WITH ATTRIBUTE-SYNTAX
+ caseIgnoreStringSyntax
+ ::= {pilotAttributeType 43}
+
+
+ uniqueIdentifier ATTRIBUTE
+ WITH ATTRIBUTE-SYNTAX
+ caseIgnoreStringSyntax
+ (SIZE (1 .. ub-unique-identifier))
+ ::= {pilotAttributeType 44}
+
+
+ organizationalStatus ATTRIBUTE
+ WITH ATTRIBUTE-SYNTAX
+ caseIgnoreStringSyntax
+ (SIZE (1 .. ub-organizational-status))
+ ::= {pilotAttributeType 45}
+
+
+ janetMailbox ATTRIBUTE
+ WITH ATTRIBUTE-SYNTAX
+ caseIgnoreIA5StringSyntax
+ (SIZE (1 .. ub-janet-mailbox))
+ ::= {pilotAttributeType 46}
+
+
+ mailPreferenceOption ATTRIBUTE
+ WITH ATTRIBUTE-SYNTAX ENUMERATED {
+ no-list-inclusion(0),
+ any-list-inclusion(1), -- may be added to any lists
+ professional-list-inclusion(2)
+ -- may be added to lists
+ -- which the list provider
+ -- views as related to the
+ -- users professional inter-
+ -- ests, perhaps evaluated
+ -- from the business of the
+ -- organisation or keywords
+ -- in the entry.
+ }
+ ::= {pilotAttributeType 47}
+
+
+ buildingName ATTRIBUTE
+ WITH ATTRIBUTE-SYNTAX
+ caseIgnoreStringSyntax
+ (SIZE (1 .. ub-building-name))
+
+
+
+Barker & Kille [Page 56]
+
+RFC 1274 COSINE and Internet X.500 Schema November 1991
+
+
+ ::= {pilotAttributeType 48}
+
+
+ dSAQuality ATTRIBUTE
+ WITH ATTRIBUTE-SYNTAX DSAQualitySyntax
+ SINGLE VALUE
+ ::= {pilotAttributeType 49}
+
+
+ singleLevelQuality ATTRIBUTE
+ WITH ATTRIBUTE-SYNTAX DataQualitySyntax
+ SINGLE VALUE
+
+
+ subtreeMinimumQuality ATTRIBUTE
+ WITH ATTRIBUTE-SYNTAX DataQualitySyntax
+ SINGLE VALUE
+ -- Defaults to singleLevelQuality
+ ::= {pilotAttributeType 51}
+
+
+ subtreeMaximumQuality ATTRIBUTE
+ WITH ATTRIBUTE-SYNTAX DataQualitySyntax
+ SINGLE VALUE
+ -- Defaults to singleLevelQuality
+ ::= {pilotAttributeType 52}
+
+
+ personalSignature ATTRIBUTE
+ WITH ATTRIBUTE-SYNTAX
+ CHOICE {
+ g3-facsimile [3] G3FacsimileBodyPart
+ }
+ (SIZE (1 .. ub-personal-signature))
+ ::= {pilotAttributeType 53}
+
+
+ dITRedirect ATTRIBUTE
+ WITH ATTRIBUTE-SYNTAX
+ distinguishedNameSyntax
+ ::= {pilotAttributeType 54}
+
+
+ audio ATTRIBUTE
+ WITH ATTRIBUTE-SYNTAX
+ Audio
+ (SIZE (1 .. ub-audio))
+ ::= {pilotAttributeType 55}
+
+
+
+Barker & Kille [Page 57]
+
+RFC 1274 COSINE and Internet X.500 Schema November 1991
+
+
+ documentPublisher ATTRIBUTE
+ WITH ATTRIBUTE SYNTAX caseIgnoreStringSyntax
+ ::= {pilotAttributeType 56}
+
+
+
+ -- Generally useful syntaxes
+
+
+ caseIgnoreIA5StringSyntax ATTRIBUTE-SYNTAX
+ IA5String
+ MATCHES FOR EQUALITY SUBSTRINGS
+
+
+ iA5StringSyntax ATTRIBUTE-SYNTAX
+ IA5String
+ MATCHES FOR EQUALITY SUBSTRINGS
+
+
+ -- Syntaxes to support the DNS attributes
+
+ DNSRecordSyntax ATTRIBUTE-SYNTAX
+ IA5String
+ MATCHES FOR EQUALITY
+
+
+ NRSInformationSyntax ATTRIBUTE-SYNTAX
+ NRSInformation
+ MATCHES FOR EQUALITY
+
+
+ NRSInformation ::= SET {
+ [0] Context,
+ [1] Address-space-id,
+ routes [2] SEQUENCE OF SEQUENCE {
+ Route-cost,
+ Addressing-info }
+ }
+
+
+
+
+
+
+
+
+
+
+
+
+
+Barker & Kille [Page 58]
+
+RFC 1274 COSINE and Internet X.500 Schema November 1991
+
+
+ -- Upper bounds on length of attribute values
+
+
+ ub-document-identifier INTEGER ::= 256
+
+ ub-document-location INTEGER ::= 256
+
+ ub-document-title INTEGER ::= 256
+
+ ub-document-version INTEGER ::= 256
+
+ ub-favourite-drink INTEGER ::= 256
+
+ ub-host INTEGER ::= 256
+
+ ub-information INTEGER ::= 2048
+
+ ub-unique-identifier INTEGER ::= 256
+
+ ub-personal-title INTEGER ::= 256
+
+ ub-photo INTEGER ::= 250000
+
+ ub-rfc822-mailbox INTEGER ::= 256
+
+ ub-room-number INTEGER ::= 256
+
+ ub-text-or-address INTEGER ::= 256
+
+ ub-user-class INTEGER ::= 256
+
+ ub-user-identifier INTEGER ::= 256
+
+ ub-organizational-status INTEGER ::= 256
+
+ ub-janet-mailbox INTEGER ::= 256
+
+ ub-building-name INTEGER ::= 256
+
+ ub-personal-signature ::= 50000
+
+ ub-audio INTEGER ::= 250000
+
+
+
+
+
+
+
+
+
+Barker & Kille [Page 59]
+
+RFC 1274 COSINE and Internet X.500 Schema November 1991
+
+
+Security Considerations
+
+ Security issues are not discussed in this memo.
+
+10. Authors' Addresses
+
+ Paul Barker
+ Department of Computer Science
+ University College London
+ Gower Street
+ London WC1E 6BT
+ England
+
+ Phone: +44 71-380-7366
+ EMail: P.Barker at cs.ucl.ac.uk
+
+
+ Steve Kille
+ Department of Computer Science
+ University College London
+ Gower Street
+ London WC1E 6BT
+ England
+
+ Phone: +44 71-380-7294
+ EMail: S.Kille at cs.ucl.ac.uk
+
+ Or send comments to the discussion group: <osi-ds at cs.ucl.ac.uk>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Barker & Kille [Page 60]
+
\ No newline at end of file
Added: openldap/vendor/openldap-release/doc/rfc/rfc2079.txt
===================================================================
--- openldap/vendor/openldap-release/doc/rfc/rfc2079.txt (rev 0)
+++ openldap/vendor/openldap-release/doc/rfc/rfc2079.txt 2007-09-15 10:38:52 UTC (rev 844)
@@ -0,0 +1,283 @@
+
+
+
+
+
+
+Network Working Group M. Smith
+Request for Comments: 2079 Netscape Communications
+Category: Standards Track January 1997
+
+
+ Definition of an X.500 Attribute Type and an Object Class to Hold
+ Uniform Resource Identifiers (URIs)
+
+Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Abstract
+
+ Uniform Resource Locators (URLs) are being widely used to specify the
+ location of Internet resources. There is an urgent need to be able
+ to include URLs in directories that conform to the LDAP and X.500
+ information models, and a desire to include other types of Uniform
+ Resource Identifiers (URIs) as they are defined. A number of
+ independent groups are already experimenting with the inclusion of
+ URLs in LDAP and X.500 directories. This document builds on the
+ experimentation to date and defines a new attribute type and an
+ auxiliary object class to allow URIs, including URLs, to be stored in
+ directory entries in a standard way.
+
+Background and Intended Usage
+
+ Uniform Resource Locators (URLs) as defined by [1] are the first of
+ several types of Uniform Resource Identifiers (URIs) being defined by
+ the IETF. URIs are widely used on the Internet, most notably within
+ Hypertext Markup Language [2] documents. This document defines an
+ X.500 [3,4] attribute type called labeledURI and an auxiliary object
+ class called labeledURIObject to hold all types of URIs, including
+ URLs. These definitions are designed for use in LDAP and X.500
+ directories, and may be used in other contexts as well.
+
+
+
+
+
+
+
+
+
+
+
+
+Smith Standards Track [Page 1]
+
+RFC 2079 URI Attribute Type and Object Class January 1997
+
+
+Schema Definition of the labeledURI Attribute Type
+
+ Name: labeledURI
+ ShortName: None
+ Description: Uniform Resource Identifier with optional label
+ OID: umichAttributeType.57 (1.3.6.1.4.1.250.1.57)
+ Syntax: caseExactString
+ SizeRestriction: None
+ SingleValued: False
+
+Discussion of the labeledURI Attribute Type
+
+ The labeledURI attribute type has the caseExactString syntax (since
+ URIs are case-sensitive) and it is multivalued. Values placed in the
+ attribute should consist of a URI (at the present time, a URL)
+ optionally followed by one or more space characters and a label.
+ Since space characters are not allowed to appear un-encoded in URIs,
+ there is no ambiguity about where the label begins. At the present
+ time, the URI portion must comply with the URL specification [1].
+ Multiple labeledURI values will generally indicate different
+ resources that are all related to the X.500 object, but may indicate
+ different locations for the same resource.
+
+ The label is used to describe the resource to which the URI points,
+ and is intended as a friendly name fit for human consumption. This
+ document does not propose any specific syntax for the label part. In
+ some cases it may be helpful to include in the label some indication
+ of the kind and/or size of the resource referenced by the URI.
+
+ Note that the label may include any characters allowed by the
+ caseExactString syntax, but that the use of non-IA5 (non-ASCII)
+ characters is discouraged as not all directory clients may handle
+ them in the same manner. If non-IA5 characters are included, they
+ should be represented using the X.500 conventions, not the HTML
+ conventions (e.g., the character that is an "a" with a ring above it
+ should be encoded using the T.61 sequence 0xCA followed by an "a"
+ character; do not use the HTML escape sequence "å").
+
+Examples of labeledURI Attribute Values
+
+ An example of a labeledURI attribute value that does not include a
+ label:
+
+ ftp://ds.internic.net/rfc/rfc822.txt
+
+
+
+
+
+
+
+Smith Standards Track [Page 2]
+
+RFC 2079 URI Attribute Type and Object Class January 1997
+
+
+ An example of a labeledURI attribute value that contains a tilde
+ character in the URL (special characters in a URL must be encoded as
+ specified by the URL document [1]). The label is "LDAP Home Page":
+
+ http://www.umich.edu/%7Ersug/ldap/ LDAP Home Page
+
+ Another example. This one includes a hint in the label to help the
+ user realize that the URL points to a photo image.
+
+ http://champagne.inria.fr/Unites/rennes.gif Rennes [photo]
+
+Schema Definition of the labeledURIObject Object Class
+
+ Name: labeledURIObject
+ Description: object that contains the URI attribute type
+ OID: umichObjectClass.15 (1.3.6.1.4.1.250.3.15)
+ SubclassOf: top
+ MustContain:
+ MayContain: labeledURI
+
+Discussion of the labeledURIObject Object Class
+
+ The labeledURIObject class is a subclass of top and may contain the
+ labeledURI attribute. The intent is that this object class can be
+ added to existing directory objects to allow for inclusion of URI
+ values. This approach does not preclude including the labeledURI
+ attribute type directly in other object classes as appropriate.
+
+Security Considerations
+
+ Security considerations are not discussed in this memo, except to
+ note that blindly inserting the label portion of a labeledURI
+ attribute value into an HTML document is not recommended, as this may
+ allow a malicious individual to include HTML tags in the label that
+ mislead viewers of the entire document in which the labeledURI value
+ was inserted.
+
+Acknowledgments
+
+ Paul-Andre Pays, Martijn Koster, Tim Howes, Rakesh Patel, Russ
+ Wright, and Hallvard Furuseth provided invaluable assistance in the
+ creation of this document.
+
+ This material is based in part upon work supported by the National
+ Science Foundation under Grant No. NCR-9416667.
+
+
+
+
+
+
+Smith Standards Track [Page 3]
+
+RFC 2079 URI Attribute Type and Object Class January 1997
+
+
+Appendix: The labeledURL Attribute Type (Deprecated)
+
+ An earlier draft of this document defined an additional attribute
+ type called labeledURL. This attribute type is deprecated, and
+ should not be used when adding new values to directory entries. The
+ original motivation for including a separate attribute type to hold
+ URLs was that this would better enable efficient progammatic access
+ to specific types of URIs. After some deliberation, the IETF-ASID
+ working group concluded that it was better to simply have one
+ attribute than two.
+
+ The schema definition for labeledURL is included here for historical
+ reference only. Directory client software may want to support this
+ schema definition (in addition to labeledURI) to ease the transition
+ away from labeledURL for those sites that are using it.
+
+ Name: labeledURL
+ ShortName: None
+ Description: Uniform Resource Locator with optional label
+ OID: umichAttributeType.41 (1.3.6.1.4.1.250.1.41)
+ Syntax: caseExactString
+ SizeRestriction: None
+ SingleValued: False
+ OID: umichAttributeType.41 (1.3.6.1.4.1.250.1.41)
+
+References
+
+ [1] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform
+ Resource Locators (URL)", RFC 1738, CERN, Xerox Corporation,
+ University of Minnesota, December 1994.
+ <URL:ftp://ds.internic.net/rfc/rfc1738.txt>
+
+ [2] Berners-Lee, T., and D. Connolly, "Hypertext Markup Language -
+ 2.0", RFC 1866, <URL:ftp://ds.internic.net/rfc/rfc1866.txt>
+
+ [3] The Directory: Overview of Concepts, Models and Service. CCITT
+ Recommendation X.500, 1988.
+
+ [4] Information Processing Systems -- Open Systems Interconnection --
+ The Directory: Overview of Concepts, Models and Service. ISO/IEC JTC
+ 1/SC21; International Standard 9594-1, 1988.
+
+
+
+
+
+
+
+
+
+
+Smith Standards Track [Page 4]
+
+RFC 2079 URI Attribute Type and Object Class January 1997
+
+
+Author's Address
+
+ Mark Smith
+ Netscape Communications Corp.
+ 501 E. Middlefield Rd.
+ Mountain View, CA 94043, USA
+
+ Phone: +1 415 937-3477
+ EMail: mcs at netscape.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Smith Standards Track [Page 5]
+
Added: openldap/vendor/openldap-release/doc/rfc/rfc2247.txt
===================================================================
--- openldap/vendor/openldap-release/doc/rfc/rfc2247.txt (rev 0)
+++ openldap/vendor/openldap-release/doc/rfc/rfc2247.txt 2007-09-15 10:38:52 UTC (rev 844)
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+Network Working Group S. Kille
+Request for Comments: 2247 Isode Ltd.
+Category: Standards Track M. Wahl
+ Critical Angle Inc.
+ A. Grimstad
+ AT&T
+ R. Huber
+ AT&T
+ S. Sataluri
+ AT&T
+ January 1998
+
+
+
+ Using Domains in LDAP/X.500 Distinguished Names
+
+
+Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (1998). All Rights Reserved.
+
+1. Abstract
+
+ The Lightweight Directory Access Protocol (LDAP) uses X.500-
+ compatible distinguished names [3] for providing unique
+ identification of entries.
+
+ This document defines an algorithm by which a name registered with
+ the Internet Domain Name Service [2] can be represented as an LDAP
+ distinguished name.
+
+2. Background
+
+ The Domain (Nameserver) System (DNS) provides a hierarchical resource
+ labeling system. A name is made up of an ordered set of components,
+ each of which are short strings. An example domain name with two
+ components would be "CRITICAL-ANGLE.COM".
+
+
+
+
+
+
+Kille, et. al. Standards Track [Page 1]
+
+RFC 2247 Using Domains in LDAP/X.500 January 1998
+
+
+ LDAP-based directories provide a more general hierarchical naming
+ framework. A primary difference in specification of distinguished
+ names from domain names is that each component of an distinguished
+ name has an explicit attribute type indication.
+
+ X.500 does not mandate any particular naming structure. It does
+ contain suggested naming structures which are based on geographic and
+ national regions, however there is not currently an established
+ registration infrastructure in many regions which would be able to
+ assign or ensure uniqueness of names.
+
+ The mechanism described in this document automatically provides an
+ enterprise a distinguished name for each domain name it has obtained
+ for use in the Internet. These distinguished names may be used to
+ identify objects in an LDAP directory.
+
+ An example distinguished name represented in the LDAP string format
+ [3] is "DC=CRITICAL-ANGLE,DC=COM". As with a domain name, the most
+ significant component, closest to the root of the namespace, is
+ written last.
+
+ This document does not define how to represent objects which do not
+ have domain names. Nor does this document define the procedure to
+ locate an enterprise's LDAP directory server, given their domain
+ name. Such procedures may be defined in future RFCs.
+
+3. Mapping Domain Names into Distinguished Names
+
+ This section defines a subset of the possible distinguished name
+ structures for use in representing names allocated in the Internet
+ Domain Name System. It is possible to algorithmically transform any
+ Internet domain name into a distinguished name, and to convert these
+ distinguished names back into the original domain names.
+
+ The algorithm for transforming a domain name is to begin with an
+ empty distinguished name (DN) and then attach Relative Distinguished
+ Names (RDNs) for each component of the domain, most significant (e.g.
+ rightmost) first. Each of these RDNs is a single
+ AttributeTypeAndValue, where the type is the attribute "DC" and the
+ value is an IA5 string containing the domain name component.
+
+ Thus the domain name "CS.UCL.AC.UK" can be transformed into
+
+ DC=CS,DC=UCL,DC=AC,DC=UK
+
+
+
+
+
+
+
+Kille, et. al. Standards Track [Page 2]
+
+RFC 2247 Using Domains in LDAP/X.500 January 1998
+
+
+ Distinguished names in which there are one or more RDNs, all
+ containing only the attribute type DC, can be mapped back into domain
+ names. Note that this document does not define a domain name
+ equivalence for any other distinguished names.
+
+4. Attribute Type Definition
+
+ The DC (short for domainComponent) attribute type is defined as
+ follows:
+
+ ( 0.9.2342.19200300.100.1.25 NAME 'dc' EQUALITY caseIgnoreIA5Match
+ SUBSTR caseIgnoreIA5SubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
+
+ The value of this attribute is a string holding one component of a
+ domain name. The encoding of IA5String for use in LDAP is simply the
+ characters of the string itself. The equality matching rule is case
+ insensitive, as is today's DNS.
+
+5. Object Class Definitions
+
+ An object with a name derived from its domain name using the
+ algorithm of section 3 is represented as an entry in the directory.
+ The "DC" attribute is present in the entry and used as the RDN.
+
+ An attribute can only be present in an entry held by an LDAP server
+ when that attribute is permitted by the entry's object class.
+
+ This section defines two object classes. The first, dcObject, is
+ intended to be used in entries for which there is an appropriate
+ structural object class. For example, if the domain represents a
+ particular organization, the entry would have as its structural
+ object class 'organization', and the 'dcObject' class would be an
+ auxiliary class. The second, domain, is a structural object class
+ used for entries in which no other information is being stored. The
+ domain object class is typically used for entries that are
+ placeholders or whose domains do not correspond to real-world
+ entities.
+
+5.1. The dcObject object class
+
+ The dcObject object class permits the dc attribute to be present in
+ an entry. This object class is defined as auxiliary, as it would
+ typically be used in conjunction with an existing structural object
+ class, such as organization, organizationalUnit or locality.
+
+ The following object class, along with the dc attribute, can be added
+ to any entry.
+
+
+
+Kille, et. al. Standards Track [Page 3]
+
+RFC 2247 Using Domains in LDAP/X.500 January 1998
+
+
+ ( 1.3.6.1.4.1.1466.344 NAME 'dcObject' SUP top AUXILIARY MUST dc )
+
+ An example entry would be:
+
+ dn: dc=critical-angle,dc=com
+ objectClass: top
+ objectClass: organization
+ objectClass: dcObject
+ dc: critical-angle
+ o: Critical Angle Inc.
+
+5.2. The domain object class
+
+ If the entry does not correspond to an organization, organizational
+ unit or other type of object for which an object class has been
+ defined, then the "domain" object class can be used. The "domain"
+ object class requires that the "DC" attribute be present, and permits
+ several other attributes to be present in the entry.
+
+ The entry will have as its structural object class the "domain"
+ object class.
+
+( 0.9.2342.19200300.100.4.13 NAME 'domain' SUP top STRUCTURAL
+ MUST dc
+ MAY ( userPassword $ searchGuide $ seeAlso $ businessCategory $
+ x121Address $ registeredAddress $ destinationIndicator $
+ preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $
+ telephoneNumber $ internationaliSDNNumber $ facsimileTelephoneNumber $
+ street $ postOfficeBox $ postalCode $ postalAddress $
+ physicalDeliveryOfficeName $ st $ l $ description $ o $
+ associatedName ) )
+
+ The optional attributes of the domain class are used for describing
+ the object represented by this domain, and may also be useful when
+ searching. These attributes are already defined for use with LDAP
+ [4].
+
+ An example entry would be:
+
+ dn: dc=tcp,dc=critical-angle,dc=com
+ objectClass: top
+ objectClass: domain
+ dc: tcp
+ description: a placeholder entry used with SRV records
+
+ The DC attribute is used for naming entries of the domain class, and
+ this can be represented in X.500 servers by the following name form
+ rule.
+
+
+
+Kille, et. al. Standards Track [Page 4]
+
+RFC 2247 Using Domains in LDAP/X.500 January 1998
+
+
+ ( 1.3.6.1.4.1.1466.345 NAME 'domainNameForm' OC domain MUST ( dc ) )
+
+6. References
+
+ [1] The Directory: Selected Attribute Types. ITU-T Recommendation
+ X.520, 1993.
+
+ [2] Mockapetris, P., " Domain Names - Concepts and Facilities,"
+ STD 13, RFC 1034, November 1987.
+
+ [3] Kille, S., and M. Wahl, " Lightweight Directory Access Protocol
+ (v3): UTF-8 String Representation of Distinguished Names", RFC
+ 2253, December 1997.
+
+ [4] Wahl, M., "A Summary of the X.500(96) User Schema for use with
+ LDAP", RFC 2256, December 1997.
+
+7. Security Considerations
+
+ This memo describes how attributes of objects may be discovered and
+ retrieved. Servers should ensure that an appropriate security policy
+ is maintained.
+
+ An enterprise is not restricted in the information which it may store
+ in DNS or LDAP servers. A client which contacts an untrusted server
+ may have incorrect or misleading information returned (e.g. an
+ organization's server may claim to hold naming contexts representing
+ domain names which have not been delegated to that organization).
+
+8. Authors' Addresses
+
+ Steve Kille
+ Isode Ltd.
+ The Dome
+ The Square
+ Richmond, Surrey
+ TW9 1DT
+ England
+
+ Phone: +44-181-332-9091
+ EMail: S.Kille at ISODE.COM
+
+
+
+
+
+
+
+
+
+
+Kille, et. al. Standards Track [Page 5]
+
+RFC 2247 Using Domains in LDAP/X.500 January 1998
+
+
+ Mark Wahl
+ Critical Angle Inc.
+ 4815 W. Braker Lane #502-385
+ Austin, TX 78759
+ USA
+
+ Phone: (1) 512 372 3160
+ EMail: M.Wahl at critical-angle.com
+
+
+ Al Grimstad
+ AT&T
+ Room 1C-429, 101 Crawfords Corner Road
+ Holmdel, NJ 07733-3030
+ USA
+
+ EMail: alg at att.com
+
+
+ Rick Huber
+ AT&T
+ Room 1B-433, 101 Crawfords Corner Road
+ Holmdel, NJ 07733-3030
+ USA
+
+ EMail: rvh at att.com
+
+
+ Sri Sataluri
+ AT&T
+ Room 4G-202, 101 Crawfords Corner Road
+ Holmdel, NJ 07733-3030
+ USA
+
+ EMail: sri at att.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kille, et. al. Standards Track [Page 6]
+
+RFC 2247 Using Domains in LDAP/X.500 January 1998
+
+
+9. Full Copyright Statement
+
+ Copyright (C) The Internet Society (1998). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kille, et. al. Standards Track [Page 7]
+
Added: openldap/vendor/openldap-release/doc/rfc/rfc2251.txt
===================================================================
--- openldap/vendor/openldap-release/doc/rfc/rfc2251.txt (rev 0)
+++ openldap/vendor/openldap-release/doc/rfc/rfc2251.txt 2007-09-15 10:38:52 UTC (rev 844)
@@ -0,0 +1,2803 @@
+
+
+
+
+
+
+Network Working Group M. Wahl
+Request for Comments: 2251 Critical Angle Inc.
+Category: Standards Track T. Howes
+ Netscape Communications Corp.
+ S. Kille
+ Isode Limited
+ December 1997
+
+
+ Lightweight Directory Access Protocol (v3)
+
+1. Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (1997). All Rights Reserved.
+
+IESG Note
+
+ This document describes a directory access protocol that provides
+ both read and update access. Update access requires secure
+ authentication, but this document does not mandate implementation of
+ any satisfactory authentication mechanisms.
+
+ In accordance with RFC 2026, section 4.4.1, this specification is
+ being approved by IESG as a Proposed Standard despite this
+ limitation, for the following reasons:
+
+ a. to encourage implementation and interoperability testing of
+ these protocols (with or without update access) before they
+ are deployed, and
+
+ b. to encourage deployment and use of these protocols in read-only
+ applications. (e.g. applications where LDAPv3 is used as
+ a query language for directories which are updated by some
+ secure mechanism other than LDAP), and
+
+ c. to avoid delaying the advancement and deployment of other Internet
+ standards-track protocols which require the ability to query, but
+ not update, LDAPv3 directory servers.
+
+
+
+
+
+Wahl, et. al. Standards Track [Page 1]
+
+RFC 2251 LDAPv3 December 1997
+
+
+ Readers are hereby warned that until mandatory authentication
+ mechanisms are standardized, clients and servers written according to
+ this specification which make use of update functionality are
+ UNLIKELY TO INTEROPERATE, or MAY INTEROPERATE ONLY IF AUTHENTICATION
+ IS REDUCED TO AN UNACCEPTABLY WEAK LEVEL.
+
+ Implementors are hereby discouraged from deploying LDAPv3 clients or
+ servers which implement the update functionality, until a Proposed
+ Standard for mandatory authentication in LDAPv3 has been approved and
+ published as an RFC.
+
+Table of Contents
+
+ 1. Status of this Memo .................................... 1
+ Copyright Notice ....................................... 1
+ IESG Note .............................................. 1
+ 2. Abstract ............................................... 3
+ 3. Models ................................................. 4
+ 3.1. Protocol Model ........................................ 4
+ 3.2. Data Model ............................................ 5
+ 3.2.1. Attributes of Entries ............................... 5
+ 3.2.2. Subschema Entries and Subentries .................... 7
+ 3.3. Relationship to X.500 ................................. 8
+ 3.4. Server-specific Data Requirements ..................... 8
+ 4. Elements of Protocol ................................... 9
+ 4.1. Common Elements ....................................... 9
+ 4.1.1. Message Envelope .................................... 9
+ 4.1.1.1. Message ID ........................................ 11
+ 4.1.2. String Types ........................................ 11
+ 4.1.3. Distinguished Name and Relative Distinguished Name .. 11
+ 4.1.4. Attribute Type ...................................... 12
+ 4.1.5. Attribute Description ............................... 13
+ 4.1.5.1. Binary Option ..................................... 14
+ 4.1.6. Attribute Value ..................................... 14
+ 4.1.7. Attribute Value Assertion ........................... 15
+ 4.1.8. Attribute ........................................... 15
+ 4.1.9. Matching Rule Identifier ............................ 15
+ 4.1.10. Result Message ..................................... 16
+ 4.1.11. Referral ........................................... 18
+ 4.1.12. Controls ........................................... 19
+ 4.2. Bind Operation ........................................ 20
+ 4.2.1. Sequencing of the Bind Request ...................... 21
+ 4.2.2. Authentication and Other Security Services .......... 22
+ 4.2.3. Bind Response ....................................... 23
+ 4.3. Unbind Operation ...................................... 24
+ 4.4. Unsolicited Notification .............................. 24
+ 4.4.1. Notice of Disconnection ............................. 24
+ 4.5. Search Operation ...................................... 25
+
+
+
+Wahl, et. al. Standards Track [Page 2]
+
+RFC 2251 LDAPv3 December 1997
+
+
+ 4.5.1. Search Request ...................................... 25
+ 4.5.2. Search Result ....................................... 29
+ 4.5.3. Continuation References in the Search Result ........ 31
+ 4.5.3.1. Example ........................................... 31
+ 4.6. Modify Operation ...................................... 32
+ 4.7. Add Operation ......................................... 34
+ 4.8. Delete Operation ...................................... 35
+ 4.9. Modify DN Operation ................................... 36
+ 4.10. Compare Operation .................................... 37
+ 4.11. Abandon Operation .................................... 38
+ 4.12. Extended Operation ................................... 38
+ 5. Protocol Element Encodings and Transfer ................ 39
+ 5.1. Mapping Onto BER-based Transport Services ............. 39
+ 5.2. Transfer Protocols .................................... 40
+ 5.2.1. Transmission Control Protocol (TCP) ................. 40
+ 6. Implementation Guidelines .............................. 40
+ 6.1. Server Implementations ................................ 40
+ 6.2. Client Implementations ................................ 40
+ 7. Security Considerations ................................ 41
+ 8. Acknowledgements ....................................... 41
+ 9. Bibliography ........................................... 41
+ 10. Authors' Addresses ..................................... 42
+ Appendix A - Complete ASN.1 Definition ..................... 44
+ Full Copyright Statement ................................... 50
+
+2. Abstract
+
+ The protocol described in this document is designed to provide access
+ to directories supporting the X.500 models, while not incurring the
+ resource requirements of the X.500 Directory Access Protocol (DAP).
+ This protocol is specifically targeted at management applications and
+ browser applications that provide read/write interactive access to
+ directories. When used with a directory supporting the X.500
+ protocols, it is intended to be a complement to the X.500 DAP.
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY" in this document
+ are to be interpreted as described in RFC 2119 [10].
+
+ Key aspects of this version of LDAP are:
+
+ - All protocol elements of LDAPv2 (RFC 1777) are supported. The
+ protocol is carried directly over TCP or other transport, bypassing
+ much of the session/presentation overhead of X.500 DAP.
+
+ - Most protocol data elements can be encoded as ordinary strings
+ (e.g., Distinguished Names).
+
+
+
+
+Wahl, et. al. Standards Track [Page 3]
+
+RFC 2251 LDAPv3 December 1997
+
+
+ - Referrals to other servers may be returned.
+
+ - SASL mechanisms may be used with LDAP to provide association
+ security services.
+
+ - Attribute values and Distinguished Names have been
+ internationalized through the use of the ISO 10646 character set.
+
+ - The protocol can be extended to support new operations, and
+ controls may be used to extend existing operations.
+
+ - Schema is published in the directory for use by clients.
+
+3. Models
+
+ Interest in X.500 [1] directory technologies in the Internet has led
+ to efforts to reduce the high cost of entry associated with use of
+ these technologies. This document continues the efforts to define
+ directory protocol alternatives, updating the LDAP [2] protocol
+ specification.
+
+3.1. Protocol Model
+
+ The general model adopted by this protocol is one of clients
+ performing protocol operations against servers. In this model, a
+ client transmits a protocol request describing the operation to be
+ performed to a server. The server is then responsible for performing
+ the necessary operation(s) in the directory. Upon completion of the
+ operation(s), the server returns a response containing any results or
+ errors to the requesting client.
+
+ In keeping with the goal of easing the costs associated with use of
+ the directory, it is an objective of this protocol to minimize the
+ complexity of clients so as to facilitate widespread deployment of
+ applications capable of using the directory.
+
+ Note that although servers are required to return responses whenever
+ such responses are defined in the protocol, there is no requirement
+ for synchronous behavior on the part of either clients or servers.
+ Requests and responses for multiple operations may be exchanged
+ between a client and server in any order, provided the client
+ eventually receives a response for every request that requires one.
+
+ In LDAP versions 1 and 2, no provision was made for protocol servers
+ returning referrals to clients. However, for improved performance
+ and distribution this version of the protocol permits servers to
+ return to clients referrals to other servers. This allows servers to
+ offload the work of contacting other servers to progress operations.
+
+
+
+Wahl, et. al. Standards Track [Page 4]
+
+RFC 2251 LDAPv3 December 1997
+
+
+ Note that the core protocol operations defined in this document can
+ be mapped to a strict subset of the X.500(1997) directory abstract
+ service, so it can be cleanly provided by the DAP. However there is
+ not a one-to-one mapping between LDAP protocol operations and DAP
+ operations: server implementations acting as a gateway to X.500
+ directories may need to make multiple DAP requests.
+
+3.2. Data Model
+
+ This section provides a brief introduction to the X.500 data model,
+ as used by LDAP.
+
+ The LDAP protocol assumes there are one or more servers which jointly
+ provide access to a Directory Information Tree (DIT). The tree is
+ made up of entries. Entries have names: one or more attribute values
+ from the entry form its relative distinguished name (RDN), which MUST
+ be unique among all its siblings. The concatenation of the relative
+ distinguished names of the sequence of entries from a particular
+ entry to an immediate subordinate of the root of the tree forms that
+ entry's Distinguished Name (DN), which is unique in the tree. An
+ example of a Distinguished Name is
+
+ CN=Steve Kille, O=Isode Limited, C=GB
+
+ Some servers may hold cache or shadow copies of entries, which can be
+ used to answer search and comparison queries, but will return
+ referrals or contact other servers if modification operations are
+ requested.
+
+ Servers which perform caching or shadowing MUST ensure that they do
+ not violate any access control constraints placed on the data by the
+ originating server.
+
+ The largest collection of entries, starting at an entry that is
+ mastered by a particular server, and including all its subordinates
+ and their subordinates, down to the entries which are mastered by
+ different servers, is termed a naming context. The root of the DIT
+ is a DSA-specific Entry (DSE) and not part of any naming context:
+ each server has different attribute values in the root DSE. (DSA is
+ an X.500 term for the directory server).
+
+3.2.1. Attributes of Entries
+
+ Entries consist of a set of attributes. An attribute is a type with
+ one or more associated values. The attribute type is identified by a
+ short descriptive name and an OID (object identifier). The attribute
+
+
+
+
+
+Wahl, et. al. Standards Track [Page 5]
+
+RFC 2251 LDAPv3 December 1997
+
+
+ type governs whether there can be more than one value of an attribute
+ of that type in an entry, the syntax to which the values must
+ conform, the kinds of matching which can be performed on values of
+ that attribute, and other functions.
+
+ An example of an attribute is "mail". There may be one or more values
+ of this attribute, they must be IA5 (ASCII) strings, and they are
+ case insensitive (e.g. "foo at bar.com" will match "FOO at BAR.COM").
+
+ Schema is the collection of attribute type definitions, object class
+ definitions and other information which a server uses to determine
+ how to match a filter or attribute value assertion (in a compare
+ operation) against the attributes of an entry, and whether to permit
+ add and modify operations. The definition of schema for use with
+ LDAP is given in [5] and [6]. Additional schema elements may be
+ defined in other documents.
+
+ Each entry MUST have an objectClass attribute. The objectClass
+ attribute specifies the object classes of an entry, which along with
+ the system and user schema determine the permitted attributes of an
+ entry. Values of this attribute may be modified by clients, but the
+ objectClass attribute cannot be removed. Servers may restrict the
+ modifications of this attribute to prevent the basic structural class
+ of the entry from being changed (e.g. one cannot change a person into
+ a country). When creating an entry or adding an objectClass value to
+ an entry, all superclasses of the named classes are implicitly added
+ as well if not already present, and the client must supply values for
+ any mandatory attributes of new superclasses.
+
+ Some attributes, termed operational attributes, are used by servers
+ for administering the directory system itself. They are not returned
+ in search results unless explicitly requested by name. Attributes
+ which are not operational, such as "mail", will have their schema and
+ syntax constraints enforced by servers, but servers will generally
+ not make use of their values.
+
+ Servers MUST NOT permit clients to add attributes to an entry unless
+ those attributes are permitted by the object class definitions, the
+ schema controlling that entry (specified in the subschema - see
+ below), or are operational attributes known to that server and used
+ for administrative purposes. Note that there is a particular
+ objectClass 'extensibleObject' defined in [5] which permits all user
+ attributes to be present in an entry.
+
+ Entries MAY contain, among others, the following operational
+ attributes, defined in [5]. These attributes are maintained
+ automatically by the server and are not modifiable by clients:
+
+
+
+
+Wahl, et. al. Standards Track [Page 6]
+
+RFC 2251 LDAPv3 December 1997
+
+
+ - creatorsName: the Distinguished Name of the user who added this
+ entry to the directory.
+
+ - createTimestamp: the time this entry was added to the directory.
+
+ - modifiersName: the Distinguished Name of the user who last modified
+ this entry.
+
+ - modifyTimestamp: the time this entry was last modified.
+
+ - subschemaSubentry: the Distinguished Name of the subschema entry
+ (or subentry) which controls the schema for this entry.
+
+3.2.2. Subschema Entries and Subentries
+
+ Subschema entries are used for administering information about the
+ directory schema, in particular the object classes and attribute
+ types supported by directory servers. A single subschema entry
+ contains all schema definitions used by entries in a particular part
+ of the directory tree.
+
+ Servers which follow X.500(93) models SHOULD implement subschema
+ using the X.500 subschema mechanisms, and so these subschemas are not
+ ordinary entries. LDAP clients SHOULD NOT assume that servers
+ implement any of the other aspects of X.500 subschema. A server
+ which masters entries and permits clients to modify these entries
+ MUST implement and provide access to these subschema entries, so that
+ its clients may discover the attributes and object classes which are
+ permitted to be present. It is strongly recommended that all other
+ servers implement this as well.
+
+ The following four attributes MUST be present in all subschema
+ entries:
+
+ - cn: this attribute MUST be used to form the RDN of the subschema
+ entry.
+
+ - objectClass: the attribute MUST have at least the values "top" and
+ "subschema".
+
+ - objectClasses: each value of this attribute specifies an object
+ class known to the server.
+
+ - attributeTypes: each value of this attribute specifies an attribute
+ type known to the server.
+
+ These are defined in [5]. Other attributes MAY be present in
+ subschema entries, to reflect additional supported capabilities.
+
+
+
+Wahl, et. al. Standards Track [Page 7]
+
+RFC 2251 LDAPv3 December 1997
+
+
+ These include matchingRules, matchingRuleUse, dITStructureRules,
+ dITContentRules, nameForms and ldapSyntaxes.
+
+ Servers SHOULD provide the attributes createTimestamp and
+ modifyTimestamp in subschema entries, in order to allow clients to
+ maintain their caches of schema information.
+
+ Clients MUST only retrieve attributes from a subschema entry by
+ requesting a base object search of the entry, where the search filter
+ is "(objectClass=subschema)". (This will allow LDAPv3 servers which
+ gateway to X.500(93) to detect that subentry information is being
+ requested.)
+
+3.3. Relationship to X.500
+
+ This document defines LDAP in terms of X.500 as an X.500 access
+ mechanism. An LDAP server MUST act in accordance with the
+ X.500(1993) series of ITU recommendations when providing the service.
+ However, it is not required that an LDAP server make use of any X.500
+ protocols in providing this service, e.g. LDAP can be mapped onto any
+ other directory system so long as the X.500 data and service model as
+ used in LDAP is not violated in the LDAP interface.
+
+3.4. Server-specific Data Requirements
+
+ An LDAP server MUST provide information about itself and other
+ information that is specific to each server. This is represented as
+ a group of attributes located in the root DSE (DSA-Specific Entry),
+ which is named with the zero-length LDAPDN. These attributes are
+ retrievable if a client performs a base object search of the root
+ with filter "(objectClass=*)", however they are subject to access
+ control restrictions. The root DSE MUST NOT be included if the
+ client performs a subtree search starting from the root.
+
+ Servers may allow clients to modify these attributes.
+
+ The following attributes of the root DSE are defined in section 5 of
+ [5]. Additional attributes may be defined in other documents.
+
+ - namingContexts: naming contexts held in the server. Naming contexts
+ are defined in section 17 of X.501 [6].
+
+ - subschemaSubentry: subschema entries (or subentries) known by this
+ server.
+
+ - altServer: alternative servers in case this one is later
+ unavailable.
+
+
+
+
+Wahl, et. al. Standards Track [Page 8]
+
+RFC 2251 LDAPv3 December 1997
+
+
+ - supportedExtension: list of supported extended operations.
+
+ - supportedControl: list of supported controls.
+
+ - supportedSASLMechanisms: list of supported SASL security features.
+
+ - supportedLDAPVersion: LDAP versions implemented by the server.
+
+ If the server does not master entries and does not know the locations
+ of schema information, the subschemaSubentry attribute is not present
+ in the root DSE. If the server masters directory entries under one
+ or more schema rules, there may be any number of values of the
+ subschemaSubentry attribute in the root DSE.
+
+4. Elements of Protocol
+
+ The LDAP protocol is described using Abstract Syntax Notation 1
+ (ASN.1) [3], and is typically transferred using a subset of ASN.1
+ Basic Encoding Rules [11]. In order to support future extensions to
+ this protocol, clients and servers MUST ignore elements of SEQUENCE
+ encodings whose tags they do not recognize.
+
+ Note that unlike X.500, each change to the LDAP protocol other than
+ through the extension mechanisms will have a different version
+ number. A client will indicate the version it supports as part of
+ the bind request, described in section 4.2. If a client has not sent
+ a bind, the server MUST assume that version 3 is supported in the
+ client (since version 2 required that the client bind first).
+
+ Clients may determine the protocol version a server supports by
+ reading the supportedLDAPVersion attribute from the root DSE. Servers
+ which implement version 3 or later versions MUST provide this
+ attribute. Servers which only implement version 2 may not provide
+ this attribute.
+
+4.1. Common Elements
+
+ This section describes the LDAPMessage envelope PDU (Protocol Data
+ Unit) format, as well as data type definitions which are used in the
+ protocol operations.
+
+4.1.1. Message Envelope
+
+ For the purposes of protocol exchanges, all protocol operations are
+ encapsulated in a common envelope, the LDAPMessage, which is defined
+ as follows:
+
+ LDAPMessage ::= SEQUENCE {
+
+
+
+Wahl, et. al. Standards Track [Page 9]
+
+RFC 2251 LDAPv3 December 1997
+
+
+ messageID MessageID,
+ protocolOp CHOICE {
+ bindRequest BindRequest,
+ bindResponse BindResponse,
+ unbindRequest UnbindRequest,
+ searchRequest SearchRequest,
+ searchResEntry SearchResultEntry,
+ searchResDone SearchResultDone,
+ searchResRef SearchResultReference,
+ modifyRequest ModifyRequest,
+ modifyResponse ModifyResponse,
+ addRequest AddRequest,
+ addResponse AddResponse,
+ delRequest DelRequest,
+ delResponse DelResponse,
+ modDNRequest ModifyDNRequest,
+ modDNResponse ModifyDNResponse,
+ compareRequest CompareRequest,
+ compareResponse CompareResponse,
+ abandonRequest AbandonRequest,
+ extendedReq ExtendedRequest,
+ extendedResp ExtendedResponse },
+ controls [0] Controls OPTIONAL }
+
+ MessageID ::= INTEGER (0 .. maxInt)
+
+ maxInt INTEGER ::= 2147483647 -- (2^^31 - 1) --
+
+ The function of the LDAPMessage is to provide an envelope containing
+ common fields required in all protocol exchanges. At this time the
+ only common fields are the message ID and the controls.
+
+ If the server receives a PDU from the client in which the LDAPMessage
+ SEQUENCE tag cannot be recognized, the messageID cannot be parsed,
+ the tag of the protocolOp is not recognized as a request, or the
+ encoding structures or lengths of data fields are found to be
+ incorrect, then the server MUST return the notice of disconnection
+ described in section 4.4.1, with resultCode protocolError, and
+ immediately close the connection. In other cases that the server
+ cannot parse the request received by the client, the server MUST
+ return an appropriate response to the request, with the resultCode
+ set to protocolError.
+
+ If the client receives a PDU from the server which cannot be parsed,
+ the client may discard the PDU, or may abruptly close the connection.
+
+ The ASN.1 type Controls is defined in section 4.1.12.
+
+
+
+
+Wahl, et. al. Standards Track [Page 10]
+
+RFC 2251 LDAPv3 December 1997
+
+
+4.1.1.1. Message ID
+
+ All LDAPMessage envelopes encapsulating responses contain the
+ messageID value of the corresponding request LDAPMessage.
+
+ The message ID of a request MUST have a value different from the
+ values of any other requests outstanding in the LDAP session of which
+ this message is a part.
+
+ A client MUST NOT send a second request with the same message ID as
+ an earlier request on the same connection if the client has not
+ received the final response from the earlier request. Otherwise the
+ behavior is undefined. Typical clients increment a counter for each
+ request.
+
+ A client MUST NOT reuse the message id of an abandonRequest or of the
+ abandoned operation until it has received a response from the server
+ for another request invoked subsequent to the abandonRequest, as the
+ abandonRequest itself does not have a response.
+
+4.1.2. String Types
+
+ The LDAPString is a notational convenience to indicate that, although
+ strings of LDAPString type encode as OCTET STRING types, the ISO
+ 10646 [13] character set (a superset of Unicode) is used, encoded
+ following the UTF-8 algorithm [14]. Note that in the UTF-8 algorithm
+ characters which are the same as ASCII (0x0000 through 0x007F) are
+ represented as that same ASCII character in a single byte. The other
+ byte values are used to form a variable-length encoding of an
+ arbitrary character.
+
+ LDAPString ::= OCTET STRING
+
+ The LDAPOID is a notational convenience to indicate that the
+ permitted value of this string is a (UTF-8 encoded) dotted-decimal
+ representation of an OBJECT IDENTIFIER.
+
+ LDAPOID ::= OCTET STRING
+
+ For example,
+
+ 1.3.6.1.4.1.1466.1.2.3
+
+4.1.3. Distinguished Name and Relative Distinguished Name
+
+ An LDAPDN and a RelativeLDAPDN are respectively defined to be the
+ representation of a Distinguished Name and a Relative Distinguished
+ Name after encoding according to the specification in [4], such that
+
+
+
+Wahl, et. al. Standards Track [Page 11]
+
+RFC 2251 LDAPv3 December 1997
+
+
+ <distinguished-name> ::= <name>
+
+ <relative-distinguished-name> ::= <name-component>
+
+ where <name> and <name-component> are as defined in [4].
+
+ LDAPDN ::= LDAPString
+
+ RelativeLDAPDN ::= LDAPString
+
+ Only Attribute Types can be present in a relative distinguished name
+ component; the options of Attribute Descriptions (next section) MUST
+ NOT be used in specifying distinguished names.
+
+4.1.4. Attribute Type
+
+ An AttributeType takes on as its value the textual string associated
+ with that AttributeType in its specification.
+
+ AttributeType ::= LDAPString
+
+ Each attribute type has a unique OBJECT IDENTIFIER which has been
+ assigned to it. This identifier may be written as decimal digits
+ with components separated by periods, e.g. "2.5.4.10".
+
+ A specification may also assign one or more textual names for an
+ attribute type. These names MUST begin with a letter, and only
+ contain ASCII letters, digit characters and hyphens. They are case
+ insensitive. (These ASCII characters are identical to ISO 10646
+ characters whose UTF-8 encoding is a single byte between 0x00 and
+ 0x7F.)
+
+ If the server has a textual name for an attribute type, it MUST use a
+ textual name for attributes returned in search results. The dotted-
+ decimal OBJECT IDENTIFIER is only used if there is no textual name
+ for an attribute type.
+
+ Attribute type textual names are non-unique, as two different
+ specifications (neither in standards track RFCs) may choose the same
+ name.
+
+ A server which masters or shadows entries SHOULD list all the
+ attribute types it supports in the subschema entries, using the
+ attributeTypes attribute. Servers which support an open-ended set of
+ attributes SHOULD include at least the attributeTypes value for the
+ 'objectClass' attribute. Clients MAY retrieve the attributeTypes
+ value from subschema entries in order to obtain the OBJECT IDENTIFIER
+ and other information associated with attribute types.
+
+
+
+Wahl, et. al. Standards Track [Page 12]
+
+RFC 2251 LDAPv3 December 1997
+
+
+ Some attribute type names which are used in this version of LDAP are
+ described in [5]. Servers may implement additional attribute types.
+
+4.1.5. Attribute Description
+
+ An AttributeDescription is a superset of the definition of the
+ AttributeType. It has the same ASN.1 definition, but allows
+ additional options to be specified. They are also case insensitive.
+
+ AttributeDescription ::= LDAPString
+
+ A value of AttributeDescription is based on the following BNF:
+
+ <AttributeDescription> ::= <AttributeType> [ ";" <options> ]
+
+ <options> ::= <option> | <option> ";" <options>
+
+ <option> ::= <opt-char> <opt-char>*
+
+ <opt-char> ::= ASCII-equivalent letters, numbers and hyphen
+
+ Examples of valid AttributeDescription:
+
+ cn
+ userCertificate;binary
+
+ One option, "binary", is defined in this document. Additional
+ options may be defined in IETF standards-track and experimental RFCs.
+ Options beginning with "x-" are reserved for private experiments.
+ Any option could be associated with any AttributeType, although not
+ all combinations may be supported by a server.
+
+ An AttributeDescription with one or more options is treated as a
+ subtype of the attribute type without any options. Options present
+ in an AttributeDescription are never mutually exclusive.
+ Implementations MUST generate the <options> list sorted in ascending
+ order, and servers MUST treat any two AttributeDescription with the
+ same AttributeType and options as equivalent. A server will treat an
+ AttributeDescription with any options it does not implement as an
+ unrecognized attribute type.
+
+ The data type "AttributeDescriptionList" describes a list of 0 or
+ more attribute types. (A list of zero elements has special
+ significance in the Search request.)
+
+ AttributeDescriptionList ::= SEQUENCE OF
+ AttributeDescription
+
+
+
+
+Wahl, et. al. Standards Track [Page 13]
+
+RFC 2251 LDAPv3 December 1997
+
+
+4.1.5.1. Binary Option
+
+ If the "binary" option is present in an AttributeDescription, it
+ overrides any string-based encoding representation defined for that
+ attribute in [5]. Instead the attribute is to be transferred as a
+ binary value encoded using the Basic Encoding Rules [11]. The syntax
+ of the binary value is an ASN.1 data type definition which is
+ referenced by the "SYNTAX" part of the attribute type definition.
+
+ The presence or absence of the "binary" option only affects the
+ transfer of attribute values in protocol; servers store any
+ particular attribute in a single format. If a client requests that a
+ server return an attribute in the binary format, but the server
+ cannot generate that format, the server MUST treat this attribute
+ type as an unrecognized attribute type. Similarly, clients MUST NOT
+ expect servers to return an attribute in binary format if the client
+ requested that attribute by name without the binary option.
+
+ This option is intended to be used with attributes whose syntax is a
+ complex ASN.1 data type, and the structure of values of that type is
+ needed by clients. Examples of this kind of syntax are "Certificate"
+ and "CertificateList".
+
+4.1.6. Attribute Value
+
+ A field of type AttributeValue takes on as its value either a string
+ encoding of a AttributeValue data type, or an OCTET STRING containing
+ an encoded binary value, depending on whether the "binary" option is
+ present in the companion AttributeDescription to this AttributeValue.
+
+ The definition of string encodings for different syntaxes and types
+ may be found in other documents, and in particular [5].
+
+ AttributeValue ::= OCTET STRING
+
+ Note that there is no defined limit on the size of this encoding;
+ thus protocol values may include multi-megabyte attributes (e.g.
+ photographs).
+
+ Attributes may be defined which have arbitrary and non-printable
+ syntax. Implementations MUST NEITHER simply display nor attempt to
+ decode as ASN.1 a value if its syntax is not known. The
+ implementation may attempt to discover the subschema of the source
+ entry, and retrieve the values of attributeTypes from it.
+
+ Clients MUST NOT send attribute values in a request which are not
+ valid according to the syntax defined for the attributes.
+
+
+
+
+Wahl, et. al. Standards Track [Page 14]
+
+RFC 2251 LDAPv3 December 1997
+
+
+4.1.7. Attribute Value Assertion
+
+ The AttributeValueAssertion type definition is similar to the one in
+ the X.500 directory standards. It contains an attribute description
+ and a matching rule assertion value suitable for that type.
+
+ AttributeValueAssertion ::= SEQUENCE {
+ attributeDesc AttributeDescription,
+ assertionValue AssertionValue }
+
+ AssertionValue ::= OCTET STRING
+
+ If the "binary" option is present in attributeDesc, this signals to
+ the server that the assertionValue is a binary encoding of the
+ assertion value.
+
+ For all the string-valued user attributes described in [5], the
+ assertion value syntax is the same as the value syntax. Clients may
+ use attribute values as assertion values in compare requests and
+ search filters.
+
+ Note however that the assertion syntax may be different from the
+ value syntax for other attributes or for non-equality matching rules.
+ These may have an assertion syntax which contains only part of the
+ value. See section 20.2.1.8 of X.501 [6] for examples.
+
+4.1.8. Attribute
+
+ An attribute consists of a type and one or more values of that type.
+ (Though attributes MUST have at least one value when stored, due to
+ access control restrictions the set may be empty when transferred in
+ protocol. This is described in section 4.5.2, concerning the
+ PartialAttributeList type.)
+
+ Attribute ::= SEQUENCE {
+ type AttributeDescription,
+ vals SET OF AttributeValue }
+
+ Each attribute value is distinct in the set (no duplicates). The
+ order of attribute values within the vals set is undefined and
+ implementation-dependent, and MUST NOT be relied upon.
+
+4.1.9. Matching Rule Identifier
+
+ A matching rule is a means of expressing how a server should compare
+ an AssertionValue received in a search filter with an abstract data
+ value. The matching rule defines the syntax of the assertion value
+ and the process to be performed in the server.
+
+
+
+Wahl, et. al. Standards Track [Page 15]
+
+RFC 2251 LDAPv3 December 1997
+
+
+ An X.501(1993) Matching Rule is identified in the LDAP protocol by
+ the printable representation of its OBJECT IDENTIFIER, either as one
+ of the strings given in [5], or as decimal digits with components
+ separated by periods, e.g. "caseIgnoreIA5Match" or
+ "1.3.6.1.4.1.453.33.33".
+
+ MatchingRuleId ::= LDAPString
+
+ Servers which support matching rules for use in the extensibleMatch
+ search filter MUST list the matching rules they implement in
+ subschema entries, using the matchingRules attributes. The server
+ SHOULD also list there, using the matchingRuleUse attribute, the
+ attribute types with which each matching rule can be used. More
+ information is given in section 4.4 of [5].
+
+4.1.10. Result Message
+
+ The LDAPResult is the construct used in this protocol to return
+ success or failure indications from servers to clients. In response
+ to various requests servers will return responses containing fields
+ of type LDAPResult to indicate the final status of a protocol
+ operation request.
+
+ LDAPResult ::= SEQUENCE {
+ resultCode ENUMERATED {
+ success (0),
+ operationsError (1),
+ protocolError (2),
+ timeLimitExceeded (3),
+ sizeLimitExceeded (4),
+ compareFalse (5),
+ compareTrue (6),
+
+ authMethodNotSupported (7),
+ strongAuthRequired (8),
+ -- 9 reserved --
+ referral (10), -- new
+ adminLimitExceeded (11), -- new
+ unavailableCriticalExtension (12), -- new
+ confidentialityRequired (13), -- new
+ saslBindInProgress (14), -- new
+ noSuchAttribute (16),
+ undefinedAttributeType (17),
+ inappropriateMatching (18),
+ constraintViolation (19),
+ attributeOrValueExists (20),
+ invalidAttributeSyntax (21),
+ -- 22-31 unused --
+
+
+
+Wahl, et. al. Standards Track [Page 16]
+
+RFC 2251 LDAPv3 December 1997
+
+
+ noSuchObject (32),
+ aliasProblem (33),
+ invalidDNSyntax (34),
+ -- 35 reserved for undefined isLeaf --
+ aliasDereferencingProblem (36),
+ -- 37-47 unused --
+ inappropriateAuthentication (48),
+ invalidCredentials (49),
+ insufficientAccessRights (50),
+ busy (51),
+ unavailable (52),
+ unwillingToPerform (53),
+ loopDetect (54),
+ -- 55-63 unused --
+ namingViolation (64),
+ objectClassViolation (65),
+ notAllowedOnNonLeaf (66),
+ notAllowedOnRDN (67),
+ entryAlreadyExists (68),
+ objectClassModsProhibited (69),
+ -- 70 reserved for CLDAP --
+ affectsMultipleDSAs (71), -- new
+ -- 72-79 unused --
+ other (80) },
+ -- 81-90 reserved for APIs --
+ matchedDN LDAPDN,
+ errorMessage LDAPString,
+ referral [3] Referral OPTIONAL }
+
+ All the result codes with the exception of success, compareFalse and
+ compareTrue are to be treated as meaning the operation could not be
+ completed in its entirety.
+
+ Most of the result codes are based on problem indications from X.511
+ error data types. Result codes from 16 to 21 indicate an
+ AttributeProblem, codes 32, 33, 34 and 36 indicate a NameProblem,
+ codes 48, 49 and 50 indicate a SecurityProblem, codes 51 to 54
+ indicate a ServiceProblem, and codes 64 to 69 and 71 indicates an
+ UpdateProblem.
+
+ If a client receives a result code which is not listed above, it is
+ to be treated as an unknown error condition.
+
+ The errorMessage field of this construct may, at the server's option,
+ be used to return a string containing a textual, human-readable
+ (terminal control and page formatting characters should be avoided)
+ error diagnostic. As this error diagnostic is not standardized,
+
+
+
+
+Wahl, et. al. Standards Track [Page 17]
+
+RFC 2251 LDAPv3 December 1997
+
+
+ implementations MUST NOT rely on the values returned. If the server
+ chooses not to return a textual diagnostic, the errorMessage field of
+ the LDAPResult type MUST contain a zero length string.
+
+ For result codes of noSuchObject, aliasProblem, invalidDNSyntax and
+ aliasDereferencingProblem, the matchedDN field is set to the name of
+ the lowest entry (object or alias) in the directory that was matched.
+ If no aliases were dereferenced while attempting to locate the entry,
+ this will be a truncated form of the name provided, or if aliases
+ were dereferenced, of the resulting name, as defined in section 12.5
+ of X.511 [8]. The matchedDN field is to be set to a zero length
+ string with all other result codes.
+
+4.1.11. Referral
+
+ The referral error indicates that the contacted server does not hold
+ the target entry of the request. The referral field is present in an
+ LDAPResult if the LDAPResult.resultCode field value is referral, and
+ absent with all other result codes. It contains a reference to
+ another server (or set of servers) which may be accessed via LDAP or
+ other protocols. Referrals can be returned in response to any
+ operation request (except unbind and abandon which do not have
+ responses). At least one URL MUST be present in the Referral.
+
+ The referral is not returned for a singleLevel or wholeSubtree search
+ in which the search scope spans multiple naming contexts, and several
+ different servers would need to be contacted to complete the
+ operation. Instead, continuation references, described in section
+ 4.5.3, are returned.
+
+ Referral ::= SEQUENCE OF LDAPURL -- one or more
+
+ LDAPURL ::= LDAPString -- limited to characters permitted in URLs
+
+ If the client wishes to progress the operation, it MUST follow the
+ referral by contacting any one of servers. All the URLs MUST be
+ equally capable of being used to progress the operation. (The
+ mechanisms for how this is achieved by multiple servers are outside
+ the scope of this document.)
+
+ URLs for servers implementing the LDAP protocol are written according
+ to [9]. If an alias was dereferenced, the <dn> part of the URL MUST
+ be present, with the new target object name. If the <dn> part is
+ present, the client MUST use this name in its next request to
+ progress the operation, and if it is not present the client will use
+ the same name as in the original request. Some servers (e.g.
+ participating in distributed indexing) may provide a different filter
+ in a referral for a search operation. If the filter part of the URL
+
+
+
+Wahl, et. al. Standards Track [Page 18]
+
+RFC 2251 LDAPv3 December 1997
+
+
+ is present in an LDAPURL, the client MUST use this filter in its next
+ request to progress this search, and if it is not present the client
+ MUST use the same filter as it used for that search. Other aspects
+ of the new request may be the same or different as the request which
+ generated the referral.
+
+ Note that UTF-8 characters appearing in a DN or search filter may not
+ be legal for URLs (e.g. spaces) and MUST be escaped using the %
+ method in RFC 1738 [7].
+
+ Other kinds of URLs may be returned, so long as the operation could
+ be performed using that protocol.
+
+4.1.12. Controls
+
+ A control is a way to specify extension information. Controls which
+ are sent as part of a request apply only to that request and are not
+ saved.
+
+ Controls ::= SEQUENCE OF Control
+
+ Control ::= SEQUENCE {
+ controlType LDAPOID,
+ criticality BOOLEAN DEFAULT FALSE,
+ controlValue OCTET STRING OPTIONAL }
+
+ The controlType field MUST be a UTF-8 encoded dotted-decimal
+ representation of an OBJECT IDENTIFIER which uniquely identifies the
+ control. This prevents conflicts between control names.
+
+ The criticality field is either TRUE or FALSE.
+
+ If the server recognizes the control type and it is appropriate for
+ the operation, the server will make use of the control when
+ performing the operation.
+
+ If the server does not recognize the control type and the criticality
+ field is TRUE, the server MUST NOT perform the operation, and MUST
+ instead return the resultCode unsupportedCriticalExtension.
+
+ If the control is not appropriate for the operation and criticality
+ field is TRUE, the server MUST NOT perform the operation, and MUST
+ instead return the resultCode unsupportedCriticalExtension.
+
+ If the control is unrecognized or inappropriate but the criticality
+ field is FALSE, the server MUST ignore the control.
+
+
+
+
+
+Wahl, et. al. Standards Track [Page 19]
+
+RFC 2251 LDAPv3 December 1997
+
+
+ The controlValue contains any information associated with the
+ control, and its format is defined for the control. The server MUST
+ be prepared to handle arbitrary contents of the controlValue octet
+ string, including zero bytes. It is absent only if there is no value
+ information which is associated with a control of its type.
+
+ This document does not define any controls. Controls may be defined
+ in other documents. The definition of a control consists of:
+
+ - the OBJECT IDENTIFIER assigned to the control,
+
+ - whether the control is always noncritical, always critical, or
+ critical at the client's option,
+
+ - the format of the controlValue contents of the control.
+
+ Servers list the controls which they recognize in the
+ supportedControl attribute in the root DSE.
+
+4.2. Bind Operation
+
+ The function of the Bind Operation is to allow authentication
+ information to be exchanged between the client and server.
+
+ The Bind Request is defined as follows:
+
+ BindRequest ::= [APPLICATION 0] SEQUENCE {
+ version INTEGER (1 .. 127),
+ name LDAPDN,
+ authentication AuthenticationChoice }
+
+ AuthenticationChoice ::= CHOICE {
+ simple [0] OCTET STRING,
+ -- 1 and 2 reserved
+ sasl [3] SaslCredentials }
+
+ SaslCredentials ::= SEQUENCE {
+ mechanism LDAPString,
+ credentials OCTET STRING OPTIONAL }
+
+ Parameters of the Bind Request are:
+
+ - version: A version number indicating the version of the protocol to
+ be used in this protocol session. This document describes version
+ 3 of the LDAP protocol. Note that there is no version negotiation,
+ and the client just sets this parameter to the version it desires.
+ If the client requests protocol version 2, a server that supports
+ the version 2 protocol as described in [2] will not return any v3-
+
+
+
+Wahl, et. al. Standards Track [Page 20]
+
+RFC 2251 LDAPv3 December 1997
+
+
+ specific protocol fields. (Note that not all LDAP servers will
+ support protocol version 2, since they may be unable to generate
+ the attribute syntaxes associated with version 2.)
+
+ - name: The name of the directory object that the client wishes to
+ bind as. This field may take on a null value (a zero length
+ string) for the purposes of anonymous binds, when authentication
+ has been performed at a lower layer, or when using SASL credentials
+ with a mechanism that includes the LDAPDN in the credentials.
+
+ - authentication: information used to authenticate the name, if any,
+ provided in the Bind Request.
+
+ Upon receipt of a Bind Request, a protocol server will authenticate
+ the requesting client, if necessary. The server will then return a
+ Bind Response to the client indicating the status of the
+ authentication.
+
+ Authorization is the use of this authentication information when
+ performing operations. Authorization MAY be affected by factors
+ outside of the LDAP Bind request, such as lower layer security
+ services.
+
+4.2.1. Sequencing of the Bind Request
+
+ For some SASL authentication mechanisms, it may be necessary for the
+ client to invoke the BindRequest multiple times. If at any stage the
+ client wishes to abort the bind process it MAY unbind and then drop
+ the underlying connection. Clients MUST NOT invoke operations
+ between two Bind requests made as part of a multi-stage bind.
+
+ A client may abort a SASL bind negotiation by sending a BindRequest
+ with a different value in the mechanism field of SaslCredentials, or
+ an AuthenticationChoice other than sasl.
+
+ If the client sends a BindRequest with the sasl mechanism field as an
+ empty string, the server MUST return a BindResponse with
+ authMethodNotSupported as the resultCode. This will allow clients to
+ abort a negotiation if it wishes to try again with the same SASL
+ mechanism.
+
+ Unlike LDAP v2, the client need not send a Bind Request in the first
+ PDU of the connection. The client may request any operations and the
+ server MUST treat these as unauthenticated. If the server requires
+ that the client bind before browsing or modifying the directory, the
+ server MAY reject a request other than binding, unbinding or an
+ extended request with the "operationsError" result.
+
+
+
+
+Wahl, et. al. Standards Track [Page 21]
+
+RFC 2251 LDAPv3 December 1997
+
+
+ If the client did not bind before sending a request and receives an
+ operationsError, it may then send a Bind Request. If this also fails
+ or the client chooses not to bind on the existing connection, it will
+ close the connection, reopen it and begin again by first sending a
+ PDU with a Bind Request. This will aid in interoperating with
+ servers implementing other versions of LDAP.
+
+ Clients MAY send multiple bind requests on a connection to change
+ their credentials. A subsequent bind process has the effect of
+ abandoning all operations outstanding on the connection. (This
+ simplifies server implementation.) Authentication from earlier binds
+ are subsequently ignored, and so if the bind fails, the connection
+ will be treated as anonymous. If a SASL transfer encryption or
+ integrity mechanism has been negotiated, and that mechanism does not
+ support the changing of credentials from one identity to another,
+ then the client MUST instead establish a new connection.
+
+4.2.2. Authentication and Other Security Services
+
+ The simple authentication option provides minimal authentication
+ facilities, with the contents of the authentication field consisting
+ only of a cleartext password. Note that the use of cleartext
+ passwords is not recommended over open networks when there is no
+ authentication or encryption being performed by a lower layer; see
+ the "Security Considerations" section.
+
+ If no authentication is to be performed, then the simple
+ authentication option MUST be chosen, and the password be of zero
+ length. (This is often done by LDAPv2 clients.) Typically the DN is
+ also of zero length.
+
+ The sasl choice allows for any mechanism defined for use with SASL
+ [12]. The mechanism field contains the name of the mechanism. The
+ credentials field contains the arbitrary data used for
+ authentication, inside an OCTET STRING wrapper. Note that unlike
+ some Internet application protocols where SASL is used, LDAP is not
+ text-based, thus no base64 transformations are performed on the
+ credentials.
+
+ If any SASL-based integrity or confidentiality services are enabled,
+ they take effect following the transmission by the server and
+ reception by the client of the final BindResponse with resultCode
+ success.
+
+ The client can request that the server use authentication information
+ from a lower layer protocol by using the SASL EXTERNAL mechanism.
+
+
+
+
+
+Wahl, et. al. Standards Track [Page 22]
+
+RFC 2251 LDAPv3 December 1997
+
+
+4.2.3. Bind Response
+
+ The Bind Response is defined as follows.
+
+ BindResponse ::= [APPLICATION 1] SEQUENCE {
+ COMPONENTS OF LDAPResult,
+ serverSaslCreds [7] OCTET STRING OPTIONAL }
+
+ BindResponse consists simply of an indication from the server of he
+ status of the client's request for authentication.
+
+ f the bind was successful, the resultCode will be success, therwise
+ it will be one of:
+
+ - operationsError: server encountered an internal error,
+
+ - protocolError: unrecognized version number or incorrect PDU
+ structure,
+
+ - authMethodNotSupported: unrecognized SASL mechanism name,
+
+ - strongAuthRequired: the server requires authentication be
+ performed with a SASL mechanism,
+
+ - referral: this server cannot accept this bind and the client
+ should try another,
+
+ - saslBindInProgress: the server requires the client to send a
+ new bind request, with the same sasl mechanism, to continue the
+ authentication process,
+
+ - inappropriateAuthentication: the server requires the client
+ which had attempted to bind anonymously or without supplying
+ credentials to provide some form of credentials,
+
+ - invalidCredentials: the wrong password was supplied or the SASL
+ credentials could not be processed,
+
+ - unavailable: the server is shutting down.
+
+ If the server does not support the client's requested protocol
+ version, it MUST set the resultCode to protocolError.
+
+ If the client receives a BindResponse response where the resultCode
+ was protocolError, it MUST close the connection as the server will be
+ unwilling to accept further operations. (This is for compatibility
+ with earlier versions of LDAP, in which the bind was always the first
+ operation, and there was no negotiation.)
+
+
+
+Wahl, et. al. Standards Track [Page 23]
+
+RFC 2251 LDAPv3 December 1997
+
+
+ The serverSaslCreds are used as part of a SASL-defined bind mechanism
+ to allow the client to authenticate the server to which it is
+ communicating, or to perform "challenge-response" authentication. If
+ the client bound with the password choice, or the SASL mechanism does
+ not require the server to return information to the client, then this
+ field is not to be included in the result.
+
+4.3. Unbind Operation
+
+ The function of the Unbind Operation is to terminate a protocol
+ session. The Unbind Operation is defined as follows:
+
+ UnbindRequest ::= [APPLICATION 2] NULL
+
+ The Unbind Operation has no response defined. Upon transmission of an
+ UnbindRequest, a protocol client may assume that the protocol session
+ is terminated. Upon receipt of an UnbindRequest, a protocol server
+ may assume that the requesting client has terminated the session and
+ that all outstanding requests may be discarded, and may close the
+ connection.
+
+4.4. Unsolicited Notification
+
+ An unsolicited notification is an LDAPMessage sent from the server to
+ the client which is not in response to any LDAPMessage received by
+ the server. It is used to signal an extraordinary condition in the
+ server or in the connection between the client and the server. The
+ notification is of an advisory nature, and the server will not expect
+ any response to be returned from the client.
+
+ The unsolicited notification is structured as an LDAPMessage in which
+ the messageID is 0 and protocolOp is of the extendedResp form. The
+ responseName field of the ExtendedResponse is present. The LDAPOID
+ value MUST be unique for this notification, and not be used in any
+ other situation.
+
+ One unsolicited notification is defined in this document.
+
+4.4.1. Notice of Disconnection
+
+ This notification may be used by the server to advise the client that
+ the server is about to close the connection due to an error
+ condition. Note that this notification is NOT a response to an
+ unbind requested by the client: the server MUST follow the procedures
+ of section 4.3. This notification is intended to assist clients in
+ distinguishing between an error condition and a transient network
+
+
+
+
+
+Wahl, et. al. Standards Track [Page 24]
+
+RFC 2251 LDAPv3 December 1997
+
+
+ failure. As with a connection close due to network failure, the
+ client MUST NOT assume that any outstanding requests which modified
+ the directory have succeeded or failed.
+
+ The responseName is 1.3.6.1.4.1.1466.20036, the response field is
+ absent, and the resultCode is used to indicate the reason for the
+ disconnection.
+
+ The following resultCode values are to be used in this notification:
+
+ - protocolError: The server has received data from the client in
+ which
+ the LDAPMessage structure could not be parsed.
+
+ - strongAuthRequired: The server has detected that an established
+ underlying security association protecting communication between
+ the client and server has unexpectedly failed or been compromised.
+
+ - unavailable: This server will stop accepting new connections and
+ operations on all existing connections, and be unavailable for an
+ extended period of time. The client may make use of an alternative
+ server.
+
+ After sending this notice, the server MUST close the connection.
+ After receiving this notice, the client MUST NOT transmit any further
+ on the connection, and may abruptly close the connection.
+
+4.5. Search Operation
+
+ The Search Operation allows a client to request that a search be
+ performed on its behalf by a server. This can be used to read
+ attributes from a single entry, from entries immediately below a
+ particular entry, or a whole subtree of entries.
+
+4.5.1. Search Request
+
+ The Search Request is defined as follows:
+
+ SearchRequest ::= [APPLICATION 3] SEQUENCE {
+ baseObject LDAPDN,
+ scope ENUMERATED {
+ baseObject (0),
+ singleLevel (1),
+ wholeSubtree (2) },
+ derefAliases ENUMERATED {
+ neverDerefAliases (0),
+ derefInSearching (1),
+ derefFindingBaseObj (2),
+
+
+
+Wahl, et. al. Standards Track [Page 25]
+
+RFC 2251 LDAPv3 December 1997
+
+
+ derefAlways (3) },
+ sizeLimit INTEGER (0 .. maxInt),
+ timeLimit INTEGER (0 .. maxInt),
+ typesOnly BOOLEAN,
+ filter Filter,
+ attributes AttributeDescriptionList }
+
+ Filter ::= CHOICE {
+ and [0] SET OF Filter,
+ or [1] SET OF Filter,
+ not [2] Filter,
+ equalityMatch [3] AttributeValueAssertion,
+ substrings [4] SubstringFilter,
+ greaterOrEqual [5] AttributeValueAssertion,
+ lessOrEqual [6] AttributeValueAssertion,
+ present [7] AttributeDescription,
+ approxMatch [8] AttributeValueAssertion,
+ extensibleMatch [9] MatchingRuleAssertion }
+
+ SubstringFilter ::= SEQUENCE {
+ type AttributeDescription,
+ -- at least one must be present
+ substrings SEQUENCE OF CHOICE {
+ initial [0] LDAPString,
+ any [1] LDAPString,
+ final [2] LDAPString } }
+
+ MatchingRuleAssertion ::= SEQUENCE {
+ matchingRule [1] MatchingRuleId OPTIONAL,
+ type [2] AttributeDescription OPTIONAL,
+ matchValue [3] AssertionValue,
+ dnAttributes [4] BOOLEAN DEFAULT FALSE }
+
+ Parameters of the Search Request are:
+
+ - baseObject: An LDAPDN that is the base object entry relative to
+ which the search is to be performed.
+
+ - scope: An indicator of the scope of the search to be performed. The
+ semantics of the possible values of this field are identical to the
+ semantics of the scope field in the X.511 Search Operation.
+
+ - derefAliases: An indicator as to how alias objects (as defined in
+ X.501) are to be handled in searching. The semantics of the
+ possible values of this field are:
+
+ neverDerefAliases: do not dereference aliases in searching
+ or in locating the base object of the search;
+
+
+
+Wahl, et. al. Standards Track [Page 26]
+
+RFC 2251 LDAPv3 December 1997
+
+
+ derefInSearching: dereference aliases in subordinates of
+ the base object in searching, but not in locating the
+ base object of the search;
+
+ derefFindingBaseObj: dereference aliases in locating
+ the base object of the search, but not when searching
+ subordinates of the base object;
+
+ derefAlways: dereference aliases both in searching and in
+ locating the base object of the search.
+
+ - sizelimit: A sizelimit that restricts the maximum number of entries
+ to be returned as a result of the search. A value of 0 in this
+ field indicates that no client-requested sizelimit restrictions are
+ in effect for the search. Servers may enforce a maximum number of
+ entries to return.
+
+ - timelimit: A timelimit that restricts the maximum time (in seconds)
+ allowed for a search. A value of 0 in this field indicates that no
+ client-requested timelimit restrictions are in effect for the
+ search.
+
+ - typesOnly: An indicator as to whether search results will contain
+ both attribute types and values, or just attribute types. Setting
+ this field to TRUE causes only attribute types (no values) to be
+ returned. Setting this field to FALSE causes both attribute types
+ and values to be returned.
+
+ - filter: A filter that defines the conditions that must be fulfilled
+ in order for the search to match a given entry.
+
+ The 'and', 'or' and 'not' choices can be used to form combinations of
+ filters. At least one filter element MUST be present in an 'and' or
+ 'or' choice. The others match against individual attribute values of
+ entries in the scope of the search. (Implementor's note: the 'not'
+ filter is an example of a tagged choice in an implicitly-tagged
+ module. In BER this is treated as if the tag was explicit.)
+
+ A server MUST evaluate filters according to the three-valued logic
+ of X.511(93) section 7.8.1. In summary, a filter is evaluated to
+ either "TRUE", "FALSE" or "Undefined". If the filter evaluates
+ to TRUE for a particular entry, then the attributes of that entry
+ are returned as part of the search result (subject to any applicable
+ access control restrictions). If the filter evaluates to FALSE or
+ Undefined, then the entry is ignored for the search.
+
+
+
+
+
+
+Wahl, et. al. Standards Track [Page 27]
+
+RFC 2251 LDAPv3 December 1997
+
+
+ A filter of the "and" choice is TRUE if all the filters in the SET
+ OF evaluate to TRUE, FALSE if at least one filter is FALSE, and
+ otherwise Undefined. A filter of the "or" choice is FALSE if all
+ of the filters in the SET OF evaluate to FALSE, TRUE if at least
+ one filter is TRUE, and Undefined otherwise. A filter of the "not"
+ choice is TRUE if the filter being negated is FALSE, FALSE if it is
+ TRUE, and Undefined if it is Undefined.
+
+ The present match evaluates to TRUE where there is an attribute or
+ subtype of the specified attribute description present in an entry,
+ and FALSE otherwise (including a presence test with an unrecognized
+ attribute description.)
+
+ The extensibleMatch is new in this version of LDAP. If the
+ matchingRule field is absent, the type field MUST be present, and
+ the equality match is performed for that type. If the type field is
+ absent and matchingRule is present, the matchValue is compared
+ against all attributes in an entry which support that matchingRule,
+ and the matchingRule determines the syntax for the assertion value
+ (the filter item evaluates to TRUE if it matches with at least
+ one attribute in the entry, FALSE if it does not match any attribute
+ in the entry, and Undefined if the matchingRule is not recognized
+ or the assertionValue cannot be parsed.) If the type field is
+ present and matchingRule is present, the matchingRule MUST be one
+ permitted for use with that type, otherwise the filter item is
+ undefined. If the dnAttributes field is set to TRUE, the match is
+ applied against all the attributes in an entry's distinguished name
+ as well, and also evaluates to TRUE if there is at least one
+ attribute in the distinguished name for which the filter item
+ evaluates to TRUE. (Editors note: The dnAttributes field is present
+ so that there does not need to be multiple versions of generic
+ matching rules such as for word matching, one to apply to entries
+ and another to apply to entries and dn attributes as well).
+
+ A filter item evaluates to Undefined when the server would not
+ be able to determine whether the assertion value matches an
+ entry. If an attribute description in an equalityMatch, substrings,
+ greaterOrEqual, lessOrEqual, approxMatch or extensibleMatch
+ filter is not recognized by the server, a matching rule id in the
+ extensibleMatch is not recognized by the server, the assertion
+ value cannot be parsed, or the type of filtering requested is not
+ implemented, then the filter is Undefined. Thus for example if a
+ server did not recognize the attribute type shoeSize, a filter of
+ (shoeSize=*) would evaluate to FALSE, and the filters (shoeSize=12),
+ (shoeSize>=12) and (shoeSize<=12) would evaluate to Undefined.
+
+
+
+
+
+
+Wahl, et. al. Standards Track [Page 28]
+
+RFC 2251 LDAPv3 December 1997
+
+
+ Servers MUST NOT return errors if attribute descriptions or matching
+ rule ids are not recognized, or assertion values cannot be parsed.
+ More details of filter processing are given in section 7.8 of X.511
+ [8].
+
+ - attributes: A list of the attributes to be returned from each entry
+ which matches the search filter. There are two special values which
+ may be used: an empty list with no attributes, and the attribute
+ description string "*". Both of these signify that all user
+ attributes are to be returned. (The "*" allows the client to
+ request all user attributes in addition to specific operational
+ attributes).
+
+ Attributes MUST be named at most once in the list, and are returned
+ at most once in an entry. If there are attribute descriptions in
+ the list which are not recognized, they are ignored by the server.
+
+ If the client does not want any attributes returned, it can specify
+ a list containing only the attribute with OID "1.1". This OID was
+ chosen arbitrarily and does not correspond to any attribute in use.
+
+ Client implementors should note that even if all user attributes are
+ requested, some attributes of the entry may not be included in
+ search results due to access control or other restrictions.
+ Furthermore, servers will not return operational attributes, such
+ as objectClasses or attributeTypes, unless they are listed by name,
+ since there may be extremely large number of values for certain
+ operational attributes. (A list of operational attributes for use
+ in LDAP is given in [5].)
+
+ Note that an X.500 "list"-like operation can be emulated by the client
+ requesting a one-level LDAP search operation with a filter checking
+ for the existence of the objectClass attribute, and that an X.500
+ "read"-like operation can be emulated by a base object LDAP search
+ operation with the same filter. A server which provides a gateway to
+ X.500 is not required to use the Read or List operations, although it
+ may choose to do so, and if it does must provide the same semantics
+ as the X.500 search operation.
+
+4.5.2. Search Result
+
+ The results of the search attempted by the server upon receipt of a
+ Search Request are returned in Search Responses, which are LDAP
+ messages containing either SearchResultEntry, SearchResultReference,
+ ExtendedResponse or SearchResultDone data types.
+
+ SearchResultEntry ::= [APPLICATION 4] SEQUENCE {
+ objectName LDAPDN,
+
+
+
+Wahl, et. al. Standards Track [Page 29]
+
+RFC 2251 LDAPv3 December 1997
+
+
+ attributes PartialAttributeList }
+
+ PartialAttributeList ::= SEQUENCE OF SEQUENCE {
+ type AttributeDescription,
+ vals SET OF AttributeValue }
+ -- implementors should note that the PartialAttributeList may
+ -- have zero elements (if none of the attributes of that entry
+ -- were requested, or could be returned), and that the vals set
+ -- may also have zero elements (if types only was requested, or
+ -- all values were excluded from the result.)
+
+ SearchResultReference ::= [APPLICATION 19] SEQUENCE OF LDAPURL
+ -- at least one LDAPURL element must be present
+
+ SearchResultDone ::= [APPLICATION 5] LDAPResult
+
+ Upon receipt of a Search Request, a server will perform the necessary
+ search of the DIT.
+
+ If the LDAP session is operating over a connection-oriented transport
+ such as TCP, the server will return to the client a sequence of
+ responses in separate LDAP messages. There may be zero or more
+ responses containing SearchResultEntry, one for each entry found
+ during the search. There may also be zero or more responses
+ containing SearchResultReference, one for each area not explored by
+ this server during the search. The SearchResultEntry and
+ SearchResultReference PDUs may come in any order. Following all the
+ SearchResultReference responses and all SearchResultEntry responses
+ to be returned by the server, the server will return a response
+ containing the SearchResultDone, which contains an indication of
+ success, or detailing any errors that have occurred.
+
+ Each entry returned in a SearchResultEntry will contain all
+ attributes, complete with associated values if necessary, as
+ specified in the attributes field of the Search Request. Return of
+ attributes is subject to access control and other administrative
+ policy. Some attributes may be returned in binary format (indicated
+ by the AttributeDescription in the response having the binary option
+ present).
+
+ Some attributes may be constructed by the server and appear in a
+ SearchResultEntry attribute list, although they are not stored
+ attributes of an entry. Clients MUST NOT assume that all attributes
+ can be modified, even if permitted by access control.
+
+ LDAPMessage responses of the ExtendedResponse form are reserved for
+ returning information associated with a control requested by the
+ client. These may be defined in future versions of this document.
+
+
+
+Wahl, et. al. Standards Track [Page 30]
+
+RFC 2251 LDAPv3 December 1997
+
+
+4.5.3. Continuation References in the Search Result
+
+ If the server was able to locate the entry referred to by the
+ baseObject but was unable to search all the entries in the scope at
+ and under the baseObject, the server may return one or more
+ SearchResultReference, each containing a reference to another set of
+ servers for continuing the operation. A server MUST NOT return any
+ SearchResultReference if it has not located the baseObject and
+ thus has not searched any entries; in this case it would return a
+ SearchResultDone containing a referral resultCode.
+
+ In the absence of indexing information provided to a server from
+ servers holding subordinate naming contexts, SearchResultReference
+ responses are not affected by search filters and are always returned
+ when in scope.
+
+ The SearchResultReference is of the same data type as the Referral.
+ URLs for servers implementing the LDAP protocol are written according
+ to [9]. The <dn> part MUST be present in the URL, with the new target
+ object name. The client MUST use this name in its next request.
+ Some servers (e.g. part of a distributed index exchange system) may
+ provide a different filter in the URLs of the SearchResultReference.
+ If the filter part of the URL is present in an LDAP URL, the client
+ MUST use the new filter in its next request to progress the search,
+ and if the filter part is absent the client will use again the same
+ filter. Other aspects of the new search request may be the same or
+ different as the search which generated the continuation references.
+
+ Other kinds of URLs may be returned so long as the operation could be
+ performed using that protocol.
+
+ The name of an unexplored subtree in a SearchResultReference need not
+ be subordinate to the base object.
+
+ In order to complete the search, the client MUST issue a new search
+ operation for each SearchResultReference that is returned. Note that
+ the abandon operation described in section 4.11 applies only to a
+ particular operation sent on a connection between a client and server,
+ and if the client has multiple outstanding search operations to
+ different servers, it MUST abandon each operation individually.
+
+4.5.3.1. Example
+
+ For example, suppose the contacted server (hosta) holds the entry
+ "O=MNN,C=WW" and the entry "CN=Manager,O=MNN,C=WW". It knows that
+ either LDAP-capable servers (hostb) or (hostc) hold
+ "OU=People,O=MNN,C=WW" (one is the master and the other server a
+
+
+
+
+Wahl, et. al. Standards Track [Page 31]
+
+RFC 2251 LDAPv3 December 1997
+
+
+ shadow), and that LDAP-capable server (hostd) holds the subtree
+ "OU=Roles,O=MNN,C=WW". If a subtree search of "O=MNN,C=WW" is
+ requested to the contacted server, it may return the following:
+
+ SearchResultEntry for O=MNN,C=WW
+ SearchResultEntry for CN=Manager,O=MNN,C=WW
+ SearchResultReference {
+ ldap://hostb/OU=People,O=MNN,C=WW
+ ldap://hostc/OU=People,O=MNN,C=WW
+ }
+ SearchResultReference {
+ ldap://hostd/OU=Roles,O=MNN,C=WW
+ }
+ SearchResultDone (success)
+
+ Client implementors should note that when following a
+ SearchResultReference, additional SearchResultReference may be
+ generated. Continuing the example, if the client contacted the
+ server (hostb) and issued the search for the subtree
+ "OU=People,O=MNN,C=WW", the server might respond as follows:
+
+ SearchResultEntry for OU=People,O=MNN,C=WW
+ SearchResultReference {
+ ldap://hoste/OU=Managers,OU=People,O=MNN,C=WW
+ }
+ SearchResultReference {
+ ldap://hostf/OU=Consultants,OU=People,O=MNN,C=WW
+ }
+ SearchResultDone (success)
+
+ If the contacted server does not hold the base object for the search,
+ then it will return a referral to the client. For example, if the
+ client requests a subtree search of "O=XYZ,C=US" to hosta, the server
+ may return only a SearchResultDone containing a referral.
+
+ SearchResultDone (referral) {
+ ldap://hostg/
+ }
+
+4.6. Modify Operation
+
+ The Modify Operation allows a client to request that a modification
+ of an entry be performed on its behalf by a server. The Modify
+ Request is defined as follows:
+
+ ModifyRequest ::= [APPLICATION 6] SEQUENCE {
+ object LDAPDN,
+ modification SEQUENCE OF SEQUENCE {
+
+
+
+Wahl, et. al. Standards Track [Page 32]
+
+RFC 2251 LDAPv3 December 1997
+
+
+ operation ENUMERATED {
+ add (0),
+ delete (1),
+ replace (2) },
+ modification AttributeTypeAndValues } }
+
+ AttributeTypeAndValues ::= SEQUENCE {
+ type AttributeDescription,
+ vals SET OF AttributeValue }
+
+ Parameters of the Modify Request are:
+
+ - object: The object to be modified. The value of this field contains
+ the DN of the entry to be modified. The server will not perform
+ any alias dereferencing in determining the object to be modified.
+
+ - modification: A list of modifications to be performed on the entry.
+ The entire list of entry modifications MUST be performed
+ in the order they are listed, as a single atomic operation. While
+ individual modifications may violate the directory schema, the
+ resulting entry after the entire list of modifications is performed
+ MUST conform to the requirements of the directory schema. The
+ values that may be taken on by the 'operation' field in each
+ modification construct have the following semantics respectively:
+
+ add: add values listed to the given attribute, creating
+ the attribute if necessary;
+
+ delete: delete values listed from the given attribute,
+ removing the entire attribute if no values are listed, or
+ if all current values of the attribute are listed for
+ deletion;
+
+ replace: replace all existing values of the given attribute
+ with the new values listed, creating the attribute if it
+ did not already exist. A replace with no value will delete
+ the entire attribute if it exists, and is ignored if the
+ attribute does not exist.
+
+ The result of the modify attempted by the server upon receipt of a
+ Modify Request is returned in a Modify Response, defined as follows:
+
+ ModifyResponse ::= [APPLICATION 7] LDAPResult
+
+ Upon receipt of a Modify Request, a server will perform the necessary
+ modifications to the DIT.
+
+
+
+
+
+Wahl, et. al. Standards Track [Page 33]
+
+RFC 2251 LDAPv3 December 1997
+
+
+ The server will return to the client a single Modify Response
+ indicating either the successful completion of the DIT modification,
+ or the reason that the modification failed. Note that due to the
+ requirement for atomicity in applying the list of modifications in
+ the Modify Request, the client may expect that no modifications of
+ the DIT have been performed if the Modify Response received indicates
+ any sort of error, and that all requested modifications have been
+ performed if the Modify Response indicates successful completion of
+ the Modify Operation. If the connection fails, whether the
+ modification occurred or not is indeterminate.
+
+ The Modify Operation cannot be used to remove from an entry any of
+ its distinguished values, those values which form the entry's
+ relative distinguished name. An attempt to do so will result in the
+ server returning the error notAllowedOnRDN. The Modify DN Operation
+ described in section 4.9 is used to rename an entry.
+
+ If an equality match filter has not been defined for an attribute type,
+ clients MUST NOT attempt to delete individual values of that attribute
+ from an entry using the "delete" form of a modification, and MUST
+ instead use the "replace" form.
+
+ Note that due to the simplifications made in LDAP, there is not a
+ direct mapping of the modifications in an LDAP ModifyRequest onto the
+ EntryModifications of a DAP ModifyEntry operation, and different
+ implementations of LDAP-DAP gateways may use different means of
+ representing the change. If successful, the final effect of the
+ operations on the entry MUST be identical.
+
+4.7. Add Operation
+
+ The Add Operation allows a client to request the addition of an entry
+ into the directory. The Add Request is defined as follows:
+
+ AddRequest ::= [APPLICATION 8] SEQUENCE {
+ entry LDAPDN,
+ attributes AttributeList }
+
+ AttributeList ::= SEQUENCE OF SEQUENCE {
+ type AttributeDescription,
+ vals SET OF AttributeValue }
+
+ Parameters of the Add Request are:
+
+ - entry: the Distinguished Name of the entry to be added. Note that
+ the server will not dereference any aliases in locating the entry
+ to be added.
+
+
+
+
+Wahl, et. al. Standards Track [Page 34]
+
+RFC 2251 LDAPv3 December 1997
+
+
+ - attributes: the list of attributes that make up the content of the
+ entry being added. Clients MUST include distinguished values
+ (those forming the entry's own RDN) in this list, the objectClass
+ attribute, and values of any mandatory attributes of the listed
+ object classes. Clients MUST NOT supply the createTimestamp or
+ creatorsName attributes, since these will be generated
+ automatically by the server.
+
+ The entry named in the entry field of the AddRequest MUST NOT exist
+ for the AddRequest to succeed. The parent of the entry to be added
+ MUST exist. For example, if the client attempted to add
+ "CN=JS,O=Foo,C=US", the "O=Foo,C=US" entry did not exist, and the
+ "C=US" entry did exist, then the server would return the error
+ noSuchObject with the matchedDN field containing "C=US". If the
+ parent entry exists but is not in a naming context held by the
+ server, the server SHOULD return a referral to the server holding the
+ parent entry.
+
+ Servers implementations SHOULD NOT restrict where entries can be
+ located in the directory. Some servers MAY allow the administrator
+ to restrict the classes of entries which can be added to the
+ directory.
+
+ Upon receipt of an Add Request, a server will attempt to perform the
+ add requested. The result of the add attempt will be returned to the
+ client in the Add Response, defined as follows:
+
+ AddResponse ::= [APPLICATION 9] LDAPResult
+
+ A response of success indicates that the new entry is present in the
+ directory.
+
+4.8. Delete Operation
+
+ The Delete Operation allows a client to request the removal of an
+ entry from the directory. The Delete Request is defined as follows:
+
+ DelRequest ::= [APPLICATION 10] LDAPDN
+
+ The Delete Request consists of the Distinguished Name of the entry to
+ be deleted. Note that the server will not dereference aliases while
+ resolving the name of the target entry to be removed, and that only
+ leaf entries (those with no subordinate entries) can be deleted with
+ this operation.
+
+ The result of the delete attempted by the server upon receipt of a
+ Delete Request is returned in the Delete Response, defined as
+ follows:
+
+
+
+Wahl, et. al. Standards Track [Page 35]
+
+RFC 2251 LDAPv3 December 1997
+
+
+ DelResponse ::= [APPLICATION 11] LDAPResult
+
+ Upon receipt of a Delete Request, a server will attempt to perform
+ the entry removal requested. The result of the delete attempt will be
+ returned to the client in the Delete Response.
+
+4.9. Modify DN Operation
+
+ The Modify DN Operation allows a client to change the leftmost (least
+ significant) component of the name of an entry in the directory, or
+ to move a subtree of entries to a new location in the directory. The
+ Modify DN Request is defined as follows:
+
+ ModifyDNRequest ::= [APPLICATION 12] SEQUENCE {
+ entry LDAPDN,
+ newrdn RelativeLDAPDN,
+ deleteoldrdn BOOLEAN,
+ newSuperior [0] LDAPDN OPTIONAL }
+
+ Parameters of the Modify DN Request are:
+
+ - entry: the Distinguished Name of the entry to be changed. This
+ entry may or may not have subordinate entries.
+
+ - newrdn: the RDN that will form the leftmost component of the new
+ name of the entry.
+
+ - deleteoldrdn: a boolean parameter that controls whether the old RDN
+ attribute values are to be retained as attributes of the entry, or
+ deleted from the entry.
+
+ - newSuperior: if present, this is the Distinguished Name of the entry
+ which becomes the immediate superior of the existing entry.
+
+ The result of the name change attempted by the server upon receipt of
+ a Modify DN Request is returned in the Modify DN Response, defined
+ as follows:
+
+ ModifyDNResponse ::= [APPLICATION 13] LDAPResult
+
+ Upon receipt of a ModifyDNRequest, a server will attempt to
+ perform the name change. The result of the name change attempt will
+ be returned to the client in the Modify DN Response.
+
+ For example, if the entry named in the "entry" parameter was
+ "cn=John Smith,c=US", the newrdn parameter was "cn=John Cougar Smith",
+ and the newSuperior parameter was absent, then this operation would
+
+
+
+
+Wahl, et. al. Standards Track [Page 36]
+
+RFC 2251 LDAPv3 December 1997
+
+
+ attempt to rename the entry to be "cn=John Cougar Smith,c=US". If
+ there was already an entry with that name, the operation would fail
+ with error code entryAlreadyExists.
+
+ If the deleteoldrdn parameter is TRUE, the values forming the old
+ RDN are deleted from the entry. If the deleteoldrdn parameter is
+ FALSE, the values forming the old RDN will be retained as
+ non-distinguished attribute values of the entry. The server may
+ not perform the operation and return an error code if the setting of
+ the deleteoldrdn parameter would cause a schema inconsistency in the
+ entry.
+
+ Note that X.500 restricts the ModifyDN operation to only affect
+ entries that are contained within a single server. If the LDAP
+ server is mapped onto DAP, then this restriction will apply, and the
+ resultCode affectsMultipleDSAs will be returned if this error
+ occurred. In general clients MUST NOT expect to be able to perform
+ arbitrary movements of entries and subtrees between servers.
+
+4.10. Compare Operation
+
+ The Compare Operation allows a client to compare an assertion
+ provided with an entry in the directory. The Compare Request is
+ defined as follows:
+
+ CompareRequest ::= [APPLICATION 14] SEQUENCE {
+ entry LDAPDN,
+ ava AttributeValueAssertion }
+
+ Parameters of the Compare Request are:
+
+ - entry: the name of the entry to be compared with.
+
+ - ava: the assertion with which an attribute in the entry is to be
+ compared.
+
+ The result of the compare attempted by the server upon receipt of a
+ Compare Request is returned in the Compare Response, defined as
+ follows:
+
+ CompareResponse ::= [APPLICATION 15] LDAPResult
+
+ Upon receipt of a Compare Request, a server will attempt to perform
+ the requested comparison. The result of the comparison will be
+ returned to the client in the Compare Response. Note that errors and
+ the result of comparison are all returned in the same construct.
+
+
+
+
+
+Wahl, et. al. Standards Track [Page 37]
+
+RFC 2251 LDAPv3 December 1997
+
+
+ Note that some directory systems may establish access controls which
+ permit the values of certain attributes (such as userPassword) to be
+ compared but not read. In a search result, it may be that an
+ attribute of that type would be returned, but with an empty set of
+ values.
+
+4.11. Abandon Operation
+
+ The function of the Abandon Operation is to allow a client to request
+ that the server abandon an outstanding operation. The Abandon
+ Request is defined as follows:
+
+ AbandonRequest ::= [APPLICATION 16] MessageID
+
+ The MessageID MUST be that of a an operation which was requested
+ earlier in this connection.
+
+ (The abandon request itself has its own message id. This is distinct
+ from the id of the earlier operation being abandoned.)
+
+ There is no response defined in the Abandon Operation. Upon
+ transmission of an Abandon Operation, a client may expect that the
+ operation identified by the Message ID in the Abandon Request has
+ been abandoned. In the event that a server receives an Abandon
+ Request on a Search Operation in the midst of transmitting responses
+ to the search, that server MUST cease transmitting entry responses to
+ the abandoned request immediately, and MUST NOT send the
+ SearchResponseDone. Of course, the server MUST ensure that only
+ properly encoded LDAPMessage PDUs are transmitted.
+
+ Clients MUST NOT send abandon requests for the same operation
+ multiple times, and MUST also be prepared to receive results from
+ operations it has abandoned (since these may have been in transit
+ when the abandon was requested).
+
+ Servers MUST discard abandon requests for message IDs they do not
+ recognize, for operations which cannot be abandoned, and for
+ operations which have already been abandoned.
+
+4.12. Extended Operation
+
+ An extension mechanism has been added in this version of LDAP, in
+ order to allow additional operations to be defined for services not
+ available elsewhere in this protocol, for instance digitally signed
+ operations and results.
+
+
+
+
+
+
+Wahl, et. al. Standards Track [Page 38]
+
+RFC 2251 LDAPv3 December 1997
+
+
+ The extended operation allows clients to make requests and receive
+ responses with predefined syntaxes and semantics. These may be
+ defined in RFCs or be private to particular implementations. Each
+ request MUST have a unique OBJECT IDENTIFIER assigned to it.
+
+ ExtendedRequest ::= [APPLICATION 23] SEQUENCE {
+ requestName [0] LDAPOID,
+ requestValue [1] OCTET STRING OPTIONAL }
+
+ The requestName is a dotted-decimal representation of the OBJECT
+ IDENTIFIER corresponding to the request. The requestValue is
+ information in a form defined by that request, encapsulated inside an
+ OCTET STRING.
+
+ The server will respond to this with an LDAPMessage containing the
+ ExtendedResponse.
+
+ ExtendedResponse ::= [APPLICATION 24] SEQUENCE {
+ COMPONENTS OF LDAPResult,
+ responseName [10] LDAPOID OPTIONAL,
+ response [11] OCTET STRING OPTIONAL }
+
+ If the server does not recognize the request name, it MUST return
+ only the response fields from LDAPResult, containing the
+ protocolError result code.
+
+5. Protocol Element Encodings and Transfer
+
+ One underlying service is defined here. Clients and servers SHOULD
+ implement the mapping of LDAP over TCP described in 5.2.1.
+
+5.1. Mapping Onto BER-based Transport Services
+
+ The protocol elements of LDAP are encoded for exchange using the
+ Basic Encoding Rules (BER) [11] of ASN.1 [3]. However, due to the
+ high overhead involved in using certain elements of the BER, the
+ following additional restrictions are placed on BER-encodings of LDAP
+ protocol elements:
+
+ (1) Only the definite form of length encoding will be used.
+
+ (2) OCTET STRING values will be encoded in the primitive form only.
+
+ (3) If the value of a BOOLEAN type is true, the encoding MUST have
+ its contents octets set to hex "FF".
+
+
+
+
+
+
+Wahl, et. al. Standards Track [Page 39]
+
+RFC 2251 LDAPv3 December 1997
+
+
+ (4) If a value of a type is its default value, it MUST be absent.
+ Only some BOOLEAN and INTEGER types have default values in this
+ protocol definition.
+
+ These restrictions do not apply to ASN.1 types encapsulated inside of
+ OCTET STRING values, such as attribute values, unless otherwise
+ noted.
+
+5.2. Transfer Protocols
+
+ This protocol is designed to run over connection-oriented, reliable
+ transports, with all 8 bits in an octet being significant in the data
+ stream.
+
+5.2.1. Transmission Control Protocol (TCP)
+
+ The LDAPMessage PDUs are mapped directly onto the TCP bytestream. It
+ is recommended that server implementations running over the TCP MAY
+ provide a protocol listener on the assigned port, 389. Servers may
+ instead provide a listener on a different port number. Clients MUST
+ support contacting servers on any valid TCP port.
+
+6. Implementation Guidelines
+
+ This document describes an Internet protocol.
+
+6.1. Server Implementations
+
+ The server MUST be capable of recognizing all the mandatory attribute
+ type names and implement the syntaxes specified in [5]. Servers MAY
+ also recognize additional attribute type names.
+
+6.2. Client Implementations
+
+ Clients which request referrals MUST ensure that they do not loop
+ between servers. They MUST NOT repeatedly contact the same server for
+ the same request with the same target entry name, scope and filter.
+ Some clients may be using a counter that is incremented each time
+ referral handling occurs for an operation, and these kinds of clients
+ MUST be able to handle a DIT with at least ten layers of naming
+ contexts between the root and a leaf entry.
+
+ In the absence of prior agreements with servers, clients SHOULD NOT
+ assume that servers support any particular schemas beyond those
+ referenced in section 6.1. Different schemas can have different
+ attribute types with the same names. The client can retrieve the
+ subschema entries referenced by the subschemaSubentry attribute in
+ the server's root DSE or in entries held by the server.
+
+
+
+Wahl, et. al. Standards Track [Page 40]
+
+RFC 2251 LDAPv3 December 1997
+
+
+7. Security Considerations
+
+ When used with a connection-oriented transport, this version of the
+ protocol provides facilities for the LDAP v2 authentication
+ mechanism, simple authentication using a cleartext password, as well
+ as any SASL mechanism [12]. SASL allows for integrity and privacy
+ services to be negotiated.
+
+ It is also permitted that the server can return its credentials to
+ the client, if it chooses to do so.
+
+ Use of cleartext password is strongly discouraged where the
+ underlying transport service cannot guarantee confidentiality and may
+ result in disclosure of the password to unauthorized parties.
+
+ When used with SASL, it should be noted that the name field of the
+ BindRequest is not protected against modification. Thus if the
+ distinguished name of the client (an LDAPDN) is agreed through the
+ negotiation of the credentials, it takes precedence over any value in
+ the unprotected name field.
+
+ Implementations which cache attributes and entries obtained via LDAP
+ MUST ensure that access controls are maintained if that information
+ is to be provided to multiple clients, since servers may have access
+ control policies which prevent the return of entries or attributes in
+ search results except to particular authenticated clients. For
+ example, caches could serve result information only to the client
+ whose request caused it to be cache.
+
+8. Acknowledgements
+
+ This document is an update to RFC 1777, by Wengyik Yeong, Tim Howes,
+ and Steve Kille. Design ideas included in this document are based on
+ those discussed in ASID and other IETF Working Groups. The
+ contributions of individuals in these working groups is gratefully
+ acknowledged.
+
+9. Bibliography
+
+ [1] ITU-T Rec. X.500, "The Directory: Overview of Concepts, Models
+ and Service", 1993.
+
+ [2] Yeong, W., Howes, T., and S. Kille, "Lightweight Directory Access
+ Protocol", RFC 1777, March 1995.
+
+ [3] ITU-T Rec. X.680, "Abstract Syntax Notation One (ASN.1) -
+ Specification of Basic Notation", 1994.
+
+
+
+
+Wahl, et. al. Standards Track [Page 41]
+
+RFC 2251 LDAPv3 December 1997
+
+
+ [4] Kille, S., Wahl, M., and T. Howes, "Lightweight Directory Access
+ Protocol (v3): UTF-8 String Representation of Distinguished
+ Names", RFC 2253, December 1997.
+
+ [5] Wahl, M., Coulbeck, A., Howes, T., and S. Kille, "Lightweight
+ Directory Access Protocol (v3): Attribute Syntax Definitions",
+ RFC 2252, December 1997.
+
+ [6] ITU-T Rec. X.501, "The Directory: Models", 1993.
+
+ [7] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform
+ Resource Locators (URL)", RFC 1738, December 1994.
+
+ [8] ITU-T Rec. X.511, "The Directory: Abstract Service Definition",
+ 1993.
+
+ [9] Howes, T., and M. Smith, "The LDAP URL Format", RFC 2255,
+ December 1997.
+
+ [10] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+ Levels", RFC 2119, March 1997.
+
+ [11] ITU-T Rec. X.690, "Specification of ASN.1 encoding rules: Basic,
+ Canonical, and Distinguished Encoding Rules", 1994.
+
+ [12] Meyers, J., "Simple Authentication and Security Layer",
+ RFC 2222, October 1997.
+
+ [13] Universal Multiple-Octet Coded Character Set (UCS) -
+ Architecture and Basic Multilingual Plane, ISO/IEC 10646-1 :
+ 1993.
+
+ [14] Yergeau, F., "UTF-8, a transformation format of Unicode and ISO
+ 10646", RFC 2044, October 1996.
+
+10. Authors' Addresses
+
+ Mark Wahl
+ Critical Angle Inc.
+ 4815 W Braker Lane #502-385
+ Austin, TX 78759
+ USA
+
+ Phone: +1 512 372-3160
+ EMail: M.Wahl at critical-angle.com
+
+
+
+
+
+
+Wahl, et. al. Standards Track [Page 42]
+
+RFC 2251 LDAPv3 December 1997
+
+
+ Tim Howes
+ Netscape Communications Corp.
+ 501 E. Middlefield Rd., MS MV068
+ Mountain View, CA 94043
+ USA
+
+ Phone: +1 650 937-3419
+ EMail: howes at netscape.com
+
+ Steve Kille
+ Isode Limited
+ The Dome, The Square
+ Richmond
+ TW9 1DT
+ UK
+
+ Phone: +44-181-332-9091
+ EMail: S.Kille at isode.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wahl, et. al. Standards Track [Page 43]
+
+RFC 2251 LDAPv3 December 1997
+
+
+Appendix A - Complete ASN.1 Definition
+
+ Lightweight-Directory-Access-Protocol-V3 DEFINITIONS
+ IMPLICIT TAGS ::=
+
+ BEGIN
+
+ LDAPMessage ::= SEQUENCE {
+ messageID MessageID,
+ protocolOp CHOICE {
+ bindRequest BindRequest,
+ bindResponse BindResponse,
+ unbindRequest UnbindRequest,
+ searchRequest SearchRequest,
+ searchResEntry SearchResultEntry,
+ searchResDone SearchResultDone,
+ searchResRef SearchResultReference,
+ modifyRequest ModifyRequest,
+ modifyResponse ModifyResponse,
+ addRequest AddRequest,
+ addResponse AddResponse,
+ delRequest DelRequest,
+ delResponse DelResponse,
+ modDNRequest ModifyDNRequest,
+ modDNResponse ModifyDNResponse,
+ compareRequest CompareRequest,
+ compareResponse CompareResponse,
+ abandonRequest AbandonRequest,
+ extendedReq ExtendedRequest,
+ extendedResp ExtendedResponse },
+ controls [0] Controls OPTIONAL }
+
+ MessageID ::= INTEGER (0 .. maxInt)
+
+ maxInt INTEGER ::= 2147483647 -- (2^^31 - 1) --
+
+ LDAPString ::= OCTET STRING
+
+ LDAPOID ::= OCTET STRING
+
+ LDAPDN ::= LDAPString
+
+ RelativeLDAPDN ::= LDAPString
+
+ AttributeType ::= LDAPString
+
+ AttributeDescription ::= LDAPString
+
+
+
+
+Wahl, et. al. Standards Track [Page 44]
+
+RFC 2251 LDAPv3 December 1997
+
+
+ AttributeDescriptionList ::= SEQUENCE OF
+ AttributeDescription
+
+ AttributeValue ::= OCTET STRING
+
+ AttributeValueAssertion ::= SEQUENCE {
+ attributeDesc AttributeDescription,
+ assertionValue AssertionValue }
+
+ AssertionValue ::= OCTET STRING
+
+ Attribute ::= SEQUENCE {
+ type AttributeDescription,
+ vals SET OF AttributeValue }
+
+ MatchingRuleId ::= LDAPString
+
+ LDAPResult ::= SEQUENCE {
+ resultCode ENUMERATED {
+ success (0),
+ operationsError (1),
+ protocolError (2),
+ timeLimitExceeded (3),
+ sizeLimitExceeded (4),
+ compareFalse (5),
+ compareTrue (6),
+ authMethodNotSupported (7),
+ strongAuthRequired (8),
+ -- 9 reserved --
+ referral (10), -- new
+ adminLimitExceeded (11), -- new
+ unavailableCriticalExtension (12), -- new
+ confidentialityRequired (13), -- new
+ saslBindInProgress (14), -- new
+ noSuchAttribute (16),
+ undefinedAttributeType (17),
+ inappropriateMatching (18),
+ constraintViolation (19),
+ attributeOrValueExists (20),
+ invalidAttributeSyntax (21),
+ -- 22-31 unused --
+ noSuchObject (32),
+ aliasProblem (33),
+ invalidDNSyntax (34),
+ -- 35 reserved for undefined isLeaf --
+ aliasDereferencingProblem (36),
+ -- 37-47 unused --
+ inappropriateAuthentication (48),
+
+
+
+Wahl, et. al. Standards Track [Page 45]
+
+RFC 2251 LDAPv3 December 1997
+
+
+ invalidCredentials (49),
+ insufficientAccessRights (50),
+ busy (51),
+ unavailable (52),
+ unwillingToPerform (53),
+ loopDetect (54),
+ -- 55-63 unused --
+ namingViolation (64),
+ objectClassViolation (65),
+ notAllowedOnNonLeaf (66),
+ notAllowedOnRDN (67),
+ entryAlreadyExists (68),
+ objectClassModsProhibited (69),
+ -- 70 reserved for CLDAP --
+ affectsMultipleDSAs (71), -- new
+ -- 72-79 unused --
+ other (80) },
+ -- 81-90 reserved for APIs --
+ matchedDN LDAPDN,
+ errorMessage LDAPString,
+ referral [3] Referral OPTIONAL }
+
+ Referral ::= SEQUENCE OF LDAPURL
+
+ LDAPURL ::= LDAPString -- limited to characters permitted in URLs
+
+ Controls ::= SEQUENCE OF Control
+
+ Control ::= SEQUENCE {
+ controlType LDAPOID,
+ criticality BOOLEAN DEFAULT FALSE,
+ controlValue OCTET STRING OPTIONAL }
+
+ BindRequest ::= [APPLICATION 0] SEQUENCE {
+ version INTEGER (1 .. 127),
+ name LDAPDN,
+ authentication AuthenticationChoice }
+
+ AuthenticationChoice ::= CHOICE {
+ simple [0] OCTET STRING,
+ -- 1 and 2 reserved
+ sasl [3] SaslCredentials }
+
+ SaslCredentials ::= SEQUENCE {
+ mechanism LDAPString,
+ credentials OCTET STRING OPTIONAL }
+
+ BindResponse ::= [APPLICATION 1] SEQUENCE {
+
+
+
+Wahl, et. al. Standards Track [Page 46]
+
+RFC 2251 LDAPv3 December 1997
+
+
+ COMPONENTS OF LDAPResult,
+ serverSaslCreds [7] OCTET STRING OPTIONAL }
+
+ UnbindRequest ::= [APPLICATION 2] NULL
+
+ SearchRequest ::= [APPLICATION 3] SEQUENCE {
+ baseObject LDAPDN,
+ scope ENUMERATED {
+ baseObject (0),
+ singleLevel (1),
+ wholeSubtree (2) },
+ derefAliases ENUMERATED {
+ neverDerefAliases (0),
+ derefInSearching (1),
+ derefFindingBaseObj (2),
+ derefAlways (3) },
+ sizeLimit INTEGER (0 .. maxInt),
+ timeLimit INTEGER (0 .. maxInt),
+ typesOnly BOOLEAN,
+ filter Filter,
+ attributes AttributeDescriptionList }
+
+ Filter ::= CHOICE {
+ and [0] SET OF Filter,
+ or [1] SET OF Filter,
+ not [2] Filter,
+ equalityMatch [3] AttributeValueAssertion,
+ substrings [4] SubstringFilter,
+ greaterOrEqual [5] AttributeValueAssertion,
+ lessOrEqual [6] AttributeValueAssertion,
+ present [7] AttributeDescription,
+ approxMatch [8] AttributeValueAssertion,
+ extensibleMatch [9] MatchingRuleAssertion }
+
+ SubstringFilter ::= SEQUENCE {
+ type AttributeDescription,
+ -- at least one must be present
+ substrings SEQUENCE OF CHOICE {
+ initial [0] LDAPString,
+ any [1] LDAPString,
+ final [2] LDAPString } }
+
+ MatchingRuleAssertion ::= SEQUENCE {
+ matchingRule [1] MatchingRuleId OPTIONAL,
+ type [2] AttributeDescription OPTIONAL,
+ matchValue [3] AssertionValue,
+ dnAttributes [4] BOOLEAN DEFAULT FALSE }
+
+
+
+
+Wahl, et. al. Standards Track [Page 47]
+
+RFC 2251 LDAPv3 December 1997
+
+
+ SearchResultEntry ::= [APPLICATION 4] SEQUENCE {
+ objectName LDAPDN,
+ attributes PartialAttributeList }
+
+ PartialAttributeList ::= SEQUENCE OF SEQUENCE {
+ type AttributeDescription,
+ vals SET OF AttributeValue }
+
+ SearchResultReference ::= [APPLICATION 19] SEQUENCE OF LDAPURL
+
+ SearchResultDone ::= [APPLICATION 5] LDAPResult
+
+ ModifyRequest ::= [APPLICATION 6] SEQUENCE {
+ object LDAPDN,
+ modification SEQUENCE OF SEQUENCE {
+ operation ENUMERATED {
+ add (0),
+ delete (1),
+ replace (2) },
+ modification AttributeTypeAndValues } }
+
+ AttributeTypeAndValues ::= SEQUENCE {
+ type AttributeDescription,
+ vals SET OF AttributeValue }
+
+ ModifyResponse ::= [APPLICATION 7] LDAPResult
+
+ AddRequest ::= [APPLICATION 8] SEQUENCE {
+ entry LDAPDN,
+ attributes AttributeList }
+
+ AttributeList ::= SEQUENCE OF SEQUENCE {
+ type AttributeDescription,
+ vals SET OF AttributeValue }
+
+ AddResponse ::= [APPLICATION 9] LDAPResult
+
+ DelRequest ::= [APPLICATION 10] LDAPDN
+
+ DelResponse ::= [APPLICATION 11] LDAPResult
+
+ ModifyDNRequest ::= [APPLICATION 12] SEQUENCE {
+ entry LDAPDN,
+ newrdn RelativeLDAPDN,
+ deleteoldrdn BOOLEAN,
+ newSuperior [0] LDAPDN OPTIONAL }
+
+ ModifyDNResponse ::= [APPLICATION 13] LDAPResult
+
+
+
+Wahl, et. al. Standards Track [Page 48]
+
+RFC 2251 LDAPv3 December 1997
+
+
+ CompareRequest ::= [APPLICATION 14] SEQUENCE {
+ entry LDAPDN,
+ ava AttributeValueAssertion }
+
+ CompareResponse ::= [APPLICATION 15] LDAPResult
+
+ AbandonRequest ::= [APPLICATION 16] MessageID
+
+ ExtendedRequest ::= [APPLICATION 23] SEQUENCE {
+ requestName [0] LDAPOID,
+ requestValue [1] OCTET STRING OPTIONAL }
+
+ ExtendedResponse ::= [APPLICATION 24] SEQUENCE {
+ COMPONENTS OF LDAPResult,
+ responseName [10] LDAPOID OPTIONAL,
+ response [11] OCTET STRING OPTIONAL }
+
+ END
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wahl, et. al. Standards Track [Page 49]
+
+RFC 2251 LDAPv3 December 1997
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (1997). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wahl, et. al. Standards Track [Page 50]
+
Added: openldap/vendor/openldap-release/doc/rfc/rfc2252.txt
===================================================================
--- openldap/vendor/openldap-release/doc/rfc/rfc2252.txt (rev 0)
+++ openldap/vendor/openldap-release/doc/rfc/rfc2252.txt 2007-09-15 10:38:52 UTC (rev 844)
@@ -0,0 +1,1795 @@
+
+
+
+
+
+
+Network Working Group M. Wahl
+Request for Comments: 2252 Critical Angle Inc.
+Category: Standards Track A. Coulbeck
+ Isode Inc.
+ T. Howes
+ Netscape Communications Corp.
+ S. Kille
+ Isode Limited
+ December 1997
+
+
+ Lightweight Directory Access Protocol (v3):
+ Attribute Syntax Definitions
+
+1. Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (1997). All Rights Reserved.
+
+IESG Note
+
+ This document describes a directory access protocol that provides
+ both read and update access. Update access requires secure
+ authentication, but this document does not mandate implementation of
+ any satisfactory authentication mechanisms.
+
+ In accordance with RFC 2026, section 4.4.1, this specification is
+ being approved by IESG as a Proposed Standard despite this
+ limitation, for the following reasons:
+
+ a. to encourage implementation and interoperability testing of
+ these protocols (with or without update access) before they
+ are deployed, and
+
+ b. to encourage deployment and use of these protocols in read-only
+ applications. (e.g. applications where LDAPv3 is used as
+ a query language for directories which are updated by some
+ secure mechanism other than LDAP), and
+
+
+
+
+
+
+Wahl, et. al. Standards Track [Page 1]
+
+RFC 2252 LADPv3 Attributes December 1997
+
+
+ c. to avoid delaying the advancement and deployment of other Internet
+ standards-track protocols which require the ability to query, but
+ not update, LDAPv3 directory servers.
+
+ Readers are hereby warned that until mandatory authentication
+ mechanisms are standardized, clients and servers written according to
+ this specification which make use of update functionality are
+ UNLIKELY TO INTEROPERATE, or MAY INTEROPERATE ONLY IF AUTHENTICATION
+ IS REDUCED TO AN UNACCEPTABLY WEAK LEVEL.
+
+ Implementors are hereby discouraged from deploying LDAPv3 clients or
+ servers which implement the update functionality, until a Proposed
+ Standard for mandatory authentication in LDAPv3 has been approved and
+ published as an RFC.
+
+2. Abstract
+
+ The Lightweight Directory Access Protocol (LDAP) [1] requires that
+ the contents of AttributeValue fields in protocol elements be octet
+ strings. This document defines a set of syntaxes for LDAPv3, and the
+ rules by which attribute values of these syntaxes are represented as
+ octet strings for transmission in the LDAP protocol. The syntaxes
+ defined in this document are referenced by this and other documents
+ that define attribute types. This document also defines the set of
+ attribute types which LDAP servers should support.
+
+3. Overview
+
+ This document defines the framework for developing schemas for
+ directories accessible via the Lightweight Directory Access Protocol.
+
+ Schema is the collection of attribute type definitions, object class
+ definitions and other information which a server uses to determine
+ how to match a filter or attribute value assertion (in a compare
+ operation) against the attributes of an entry, and whether to permit
+ add and modify operations.
+
+ Section 4 states the general requirements and notations for attribute
+ types, object classes, syntax and matching rule definitions.
+
+ Section 5 lists attributes, section 6 syntaxes and section 7 object
+ classes.
+
+ Additional documents define schemas for representing real-world
+ objects as directory entries.
+
+
+
+
+
+
+Wahl, et. al. Standards Track [Page 2]
+
+RFC 2252 LADPv3 Attributes December 1997
+
+
+4. General Issues
+
+ This document describes encodings used in an Internet protocol.
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in RFC 2119 [4].
+
+ Attribute Type and Object Class definitions are written in a string
+ representation of the AttributeTypeDescription and
+ ObjectClassDescription data types defined in X.501(93) [3].
+ Implementors are strongly advised to first read the description of
+ how schema is represented in X.500 before reading the rest of this
+ document.
+
+4.1. Common Encoding Aspects
+
+ For the purposes of defining the encoding rules for attribute
+ syntaxes, the following BNF definitions will be used. They are based
+ on the BNF styles of RFC 822 [13].
+
+ a = "a" / "b" / "c" / "d" / "e" / "f" / "g" / "h" / "i" /
+ "j" / "k" / "l" / "m" / "n" / "o" / "p" / "q" / "r" /
+ "s" / "t" / "u" / "v" / "w" / "x" / "y" / "z" / "A" /
+ "B" / "C" / "D" / "E" / "F" / "G" / "H" / "I" / "J" /
+ "K" / "L" / "M" / "N" / "O" / "P" / "Q" / "R" / "S" /
+ "T" / "U" / "V" / "W" / "X" / "Y" / "Z"
+
+ d = "0" / "1" / "2" / "3" / "4" /
+ "5" / "6" / "7" / "8" / "9"
+
+ hex-digit = d / "a" / "b" / "c" / "d" / "e" / "f" /
+ "A" / "B" / "C" / "D" / "E" / "F"
+
+ k = a / d / "-" / ";"
+
+ p = a / d / """ / "(" / ")" / "+" / "," /
+ "-" / "." / "/" / ":" / "?" / " "
+
+ letterstring = 1*a
+
+ numericstring = 1*d
+
+ anhstring = 1*k
+
+ keystring = a [ anhstring ]
+
+ printablestring = 1*p
+
+
+
+Wahl, et. al. Standards Track [Page 3]
+
+RFC 2252 LADPv3 Attributes December 1997
+
+
+ space = 1*" "
+
+ whsp = [ space ]
+
+ utf8 = <any sequence of octets formed from the UTF-8 [9]
+ transformation of a character from ISO10646 [10]>
+
+ dstring = 1*utf8
+
+ qdstring = whsp "'" dstring "'" whsp
+
+ qdstringlist = [ qdstring *( qdstring ) ]
+
+ qdstrings = qdstring / ( whsp "(" qdstringlist ")" whsp )
+
+ In the following BNF for the string representation of OBJECT
+ IDENTIFIERs, descr is the syntactic representation of an object
+ descriptor, which consists of letters and digits, starting with a
+ letter. An OBJECT IDENTIFIER in the numericoid format should not
+ have leading zeroes (e.g. "0.9.3" is permitted but "0.09.3" should
+ not be generated).
+
+ When encoding 'oid' elements in a value, the descr encoding option
+ SHOULD be used in preference to the numericoid. An object descriptor
+ is a more readable alias for a number OBJECT IDENTIFIER, and these
+ (where assigned and known by the implementation) SHOULD be used in
+ preference to numeric oids to the greatest extent possible. Examples
+ of object descriptors in LDAP are attribute type, object class and
+ matching rule names.
+
+ oid = descr / numericoid
+
+ descr = keystring
+
+ numericoid = numericstring *( "." numericstring )
+
+ woid = whsp oid whsp
+
+ ; set of oids of either form
+ oids = woid / ( "(" oidlist ")" )
+
+ oidlist = woid *( "$" woid )
+
+ ; object descriptors used as schema element names
+ qdescrs = qdescr / ( whsp "(" qdescrlist ")" whsp )
+
+ qdescrlist = [ qdescr *( qdescr ) ]
+
+
+
+
+Wahl, et. al. Standards Track [Page 4]
+
+RFC 2252 LADPv3 Attributes December 1997
+
+
+ qdescr = whsp "'" descr "'" whsp
+
+4.2. Attribute Types
+
+ The attribute types are described by sample values for the subschema
+ "attributeTypes" attribute, which is written in the
+ AttributeTypeDescription syntax. While lines have been folded for
+ readability, the values transferred in protocol would not contain
+ newlines.
+
+ The AttributeTypeDescription is encoded according to the following
+ BNF, and the productions for oid, qdescrs and qdstring are given in
+ section 4.1. Implementors should note that future versions of this
+ document may have expanded this BNF to include additional terms.
+ Terms which begin with the characters "X-" are reserved for private
+ experiments, and MUST be followed by a <qdstrings>.
+
+ AttributeTypeDescription = "(" whsp
+ numericoid whsp ; AttributeType identifier
+ [ "NAME" qdescrs ] ; name used in AttributeType
+ [ "DESC" qdstring ] ; description
+ [ "OBSOLETE" whsp ]
+ [ "SUP" woid ] ; derived from this other
+ ; AttributeType
+ [ "EQUALITY" woid ; Matching Rule name
+ [ "ORDERING" woid ; Matching Rule name
+ [ "SUBSTR" woid ] ; Matching Rule name
+ [ "SYNTAX" whsp noidlen whsp ] ; see section 4.3
+ [ "SINGLE-VALUE" whsp ] ; default multi-valued
+ [ "COLLECTIVE" whsp ] ; default not collective
+ [ "NO-USER-MODIFICATION" whsp ]; default user modifiable
+ [ "USAGE" whsp AttributeUsage ]; default userApplications
+ whsp ")"
+
+ AttributeUsage =
+ "userApplications" /
+ "directoryOperation" /
+ "distributedOperation" / ; DSA-shared
+ "dSAOperation" ; DSA-specific, value depends on server
+
+ Servers are not required to provide the same or any text in the
+ description part of the subschema values they maintain. Servers
+ SHOULD provide at least one of the "SUP" and "SYNTAX" fields for each
+ AttributeTypeDescription.
+
+ Servers MUST implement all the attribute types referenced in sections
+ 5.1, 5.2 and 5.3.
+
+
+
+
+Wahl, et. al. Standards Track [Page 5]
+
+RFC 2252 LADPv3 Attributes December 1997
+
+
+ Servers MAY recognize additional names and attributes not listed in
+ this document, and if they do so, MUST publish the definitions of the
+ types in the attributeTypes attribute of their subschema entries.
+
+ Schema developers MUST NOT create attribute definitions whose names
+ conflict with attributes defined for use with LDAP in existing
+ standards-track RFCs.
+
+ An AttributeDescription can be used as the value in a NAME part of an
+ AttributeTypeDescription. Note that these are case insensitive.
+
+ Note that the AttributeTypeDescription does not list the matching
+ rules which can can be used with that attribute type in an
+ extensibleMatch search filter. This is done using the
+ matchingRuleUse attribute described in section 4.5.
+
+ This document refines the schema description of X.501 by requiring
+ that the syntax field in an AttributeTypeDescription be a string
+ representation of an OBJECT IDENTIFIER for the LDAP string syntax
+ definition, and an optional indication of the maximum length of a
+ value of this attribute (defined in section 4.3.2).
+
+4.3. Syntaxes
+
+ This section defines general requirements for LDAP attribute value
+ syntax encodings. All documents defining attribute syntax encodings
+ for use with LDAP are expected to conform to these requirements.
+
+ The encoding rules defined for a given attribute syntax must produce
+ octet strings. To the greatest extent possible, encoded octet
+ strings should be usable in their native encoded form for display
+ purposes. In particular, encoding rules for attribute syntaxes
+ defining non-binary values should produce strings that can be
+ displayed with little or no translation by clients implementing LDAP.
+ There are a few cases (e.g. audio) however, when it is not sensible
+ to produce a printable representation, and clients MUST NOT assume
+ that an unrecognized syntax is a string representation.
+
+ In encodings where an arbitrary string, not a Distinguished Name, is
+ used as part of a larger production, and other than as part of a
+ Distinguished Name, a backslash quoting mechanism is used to escape
+ the following separator symbol character (such as "'", "$" or "#") if
+ it should occur in that string. The backslash is followed by a pair
+ of hexadecimal digits representing the next character. A backslash
+ itself in the string which forms part of a larger syntax is always
+ transmitted as '\5C' or '\5c'. An example is given in section 6.27.
+
+
+
+
+
+Wahl, et. al. Standards Track [Page 6]
+
+RFC 2252 LADPv3 Attributes December 1997
+
+
+ Syntaxes are also defined for matching rules whose assertion value
+ syntax is different from the attribute value syntax.
+
+4.3.1 Binary Transfer of Values
+
+ This encoding format is used if the binary encoding is requested by
+ the client for an attribute, or if the attribute syntax name is
+ "1.3.6.1.4.1.1466.115.121.1.5". The contents of the LDAP
+ AttributeValue or AssertionValue field is a BER-encoded instance of
+ the attribute value or a matching rule assertion value ASN.1 data
+ type as defined for use with X.500. (The first byte inside the OCTET
+ STRING wrapper is a tag octet. However, the OCTET STRING is still
+ encoded in primitive form.)
+
+ All servers MUST implement this form for both generating attribute
+ values in search responses, and parsing attribute values in add,
+ compare and modify requests, if the attribute type is recognized and
+ the attribute syntax name is that of Binary. Clients which request
+ that all attributes be returned from entries MUST be prepared to
+ receive values in binary (e.g. userCertificate;binary), and SHOULD
+ NOT simply display binary or unrecognized values to users.
+
+4.3.2. Syntax Object Identifiers
+
+ Syntaxes for use with LDAP are named by OBJECT IDENTIFIERs, which are
+ dotted-decimal strings. These are not intended to be displayed to
+ users.
+
+ noidlen = numericoid [ "{" len "}" ]
+
+ len = numericstring
+
+ The following table lists some of the syntaxes that have been defined
+ for LDAP thus far. The H-R column suggests whether a value in that
+ syntax would likely be a human readable string. Clients and servers
+ need not implement all the syntaxes listed here, and MAY implement
+ other syntaxes.
+
+ Other documents may define additional syntaxes. However, the
+ definition of additional arbitrary syntaxes is strongly deprecated
+ since it will hinder interoperability: today's client and server
+ implementations generally do not have the ability to dynamically
+ recognize new syntaxes. In most cases attributes will be defined
+ with the syntax for directory strings.
+
+
+
+
+
+
+
+Wahl, et. al. Standards Track [Page 7]
+
+RFC 2252 LADPv3 Attributes December 1997
+
+
+ Value being represented H-R OBJECT IDENTIFIER
+ =================================================================
+ ACI Item N 1.3.6.1.4.1.1466.115.121.1.1
+ Access Point Y 1.3.6.1.4.1.1466.115.121.1.2
+ Attribute Type Description Y 1.3.6.1.4.1.1466.115.121.1.3
+ Audio N 1.3.6.1.4.1.1466.115.121.1.4
+ Binary N 1.3.6.1.4.1.1466.115.121.1.5
+ Bit String Y 1.3.6.1.4.1.1466.115.121.1.6
+ Boolean Y 1.3.6.1.4.1.1466.115.121.1.7
+ Certificate N 1.3.6.1.4.1.1466.115.121.1.8
+ Certificate List N 1.3.6.1.4.1.1466.115.121.1.9
+ Certificate Pair N 1.3.6.1.4.1.1466.115.121.1.10
+ Country String Y 1.3.6.1.4.1.1466.115.121.1.11
+ DN Y 1.3.6.1.4.1.1466.115.121.1.12
+ Data Quality Syntax Y 1.3.6.1.4.1.1466.115.121.1.13
+ Delivery Method Y 1.3.6.1.4.1.1466.115.121.1.14
+ Directory String Y 1.3.6.1.4.1.1466.115.121.1.15
+ DIT Content Rule Description Y 1.3.6.1.4.1.1466.115.121.1.16
+ DIT Structure Rule Description Y 1.3.6.1.4.1.1466.115.121.1.17
+ DL Submit Permission Y 1.3.6.1.4.1.1466.115.121.1.18
+ DSA Quality Syntax Y 1.3.6.1.4.1.1466.115.121.1.19
+ DSE Type Y 1.3.6.1.4.1.1466.115.121.1.20
+ Enhanced Guide Y 1.3.6.1.4.1.1466.115.121.1.21
+ Facsimile Telephone Number Y 1.3.6.1.4.1.1466.115.121.1.22
+ Fax N 1.3.6.1.4.1.1466.115.121.1.23
+ Generalized Time Y 1.3.6.1.4.1.1466.115.121.1.24
+ Guide Y 1.3.6.1.4.1.1466.115.121.1.25
+ IA5 String Y 1.3.6.1.4.1.1466.115.121.1.26
+ INTEGER Y 1.3.6.1.4.1.1466.115.121.1.27
+ JPEG N 1.3.6.1.4.1.1466.115.121.1.28
+ LDAP Syntax Description Y 1.3.6.1.4.1.1466.115.121.1.54
+ LDAP Schema Definition Y 1.3.6.1.4.1.1466.115.121.1.56
+ LDAP Schema Description Y 1.3.6.1.4.1.1466.115.121.1.57
+ Master And Shadow Access Points Y 1.3.6.1.4.1.1466.115.121.1.29
+ Matching Rule Description Y 1.3.6.1.4.1.1466.115.121.1.30
+ Matching Rule Use Description Y 1.3.6.1.4.1.1466.115.121.1.31
+ Mail Preference Y 1.3.6.1.4.1.1466.115.121.1.32
+ MHS OR Address Y 1.3.6.1.4.1.1466.115.121.1.33
+ Modify Rights Y 1.3.6.1.4.1.1466.115.121.1.55
+ Name And Optional UID Y 1.3.6.1.4.1.1466.115.121.1.34
+ Name Form Description Y 1.3.6.1.4.1.1466.115.121.1.35
+ Numeric String Y 1.3.6.1.4.1.1466.115.121.1.36
+ Object Class Description Y 1.3.6.1.4.1.1466.115.121.1.37
+ Octet String Y 1.3.6.1.4.1.1466.115.121.1.40
+ OID Y 1.3.6.1.4.1.1466.115.121.1.38
+ Other Mailbox Y 1.3.6.1.4.1.1466.115.121.1.39
+ Postal Address Y 1.3.6.1.4.1.1466.115.121.1.41
+ Protocol Information Y 1.3.6.1.4.1.1466.115.121.1.42
+
+
+
+Wahl, et. al. Standards Track [Page 8]
+
+RFC 2252 LADPv3 Attributes December 1997
+
+
+ Presentation Address Y 1.3.6.1.4.1.1466.115.121.1.43
+ Printable String Y 1.3.6.1.4.1.1466.115.121.1.44
+ Substring Assertion Y 1.3.6.1.4.1.1466.115.121.1.58
+ Subtree Specification Y 1.3.6.1.4.1.1466.115.121.1.45
+ Supplier Information Y 1.3.6.1.4.1.1466.115.121.1.46
+ Supplier Or Consumer Y 1.3.6.1.4.1.1466.115.121.1.47
+ Supplier And Consumer Y 1.3.6.1.4.1.1466.115.121.1.48
+ Supported Algorithm N 1.3.6.1.4.1.1466.115.121.1.49
+ Telephone Number Y 1.3.6.1.4.1.1466.115.121.1.50
+ Teletex Terminal Identifier Y 1.3.6.1.4.1.1466.115.121.1.51
+ Telex Number Y 1.3.6.1.4.1.1466.115.121.1.52
+ UTC Time Y 1.3.6.1.4.1.1466.115.121.1.53
+
+ A suggested minimum upper bound on the number of characters in value
+ with a string-based syntax, or the number of bytes in a value for all
+ other syntaxes, may be indicated by appending this bound count inside
+ of curly braces following the syntax name's OBJECT IDENTIFIER in an
+ Attribute Type Description. This bound is not part of the syntax
+ name itself. For instance, "1.3.6.4.1.1466.0{64}" suggests that
+ server implementations should allow a string to be 64 characters
+ long, although they may allow longer strings. Note that a single
+ character of the Directory String syntax may be encoded in more than
+ one byte since UTF-8 is a variable-length encoding.
+
+4.3.3. Syntax Description
+
+ The following BNF may be used to associate a short description with a
+ syntax OBJECT IDENTIFIER. Implementors should note that future
+ versions of this document may expand this definition to include
+ additional terms. Terms whose identifier begins with "X-" are
+ reserved for private experiments, and MUST be followed by a
+ <qdstrings>.
+
+ SyntaxDescription = "(" whsp
+ numericoid whsp
+ [ "DESC" qdstring ]
+ whsp ")"
+
+4.4. Object Classes
+
+ The format for representation of object classes is defined in X.501
+ [3]. In general every entry will contain an abstract class ("top" or
+ "alias"), at least one structural object class, and zero or more
+ auxiliary object classes. Whether an object class is abstract,
+ structural or auxiliary is defined when the object class identifier
+ is assigned. An object class definition should not be changed
+ without having a new identifier assigned to it.
+
+
+
+
+Wahl, et. al. Standards Track [Page 9]
+
+RFC 2252 LADPv3 Attributes December 1997
+
+
+ Object class descriptions are written according to the following BNF.
+ Implementors should note that future versions of this document may
+ expand this definition to include additional terms. Terms whose
+ identifier begins with "X-" are reserved for private experiments, and
+ MUST be followed by a <qdstrings> encoding.
+
+ ObjectClassDescription = "(" whsp
+ numericoid whsp ; ObjectClass identifier
+ [ "NAME" qdescrs ]
+ [ "DESC" qdstring ]
+ [ "OBSOLETE" whsp ]
+ [ "SUP" oids ] ; Superior ObjectClasses
+ [ ( "ABSTRACT" / "STRUCTURAL" / "AUXILIARY" ) whsp ]
+ ; default structural
+ [ "MUST" oids ] ; AttributeTypes
+ [ "MAY" oids ] ; AttributeTypes
+ whsp ")"
+
+ These are described as sample values for the subschema
+ "objectClasses" attribute for a server which implements the LDAP
+ schema. While lines have been folded for readability, the values
+ transferred in protocol would not contain newlines.
+
+ Servers SHOULD implement all the object classes referenced in section
+ 7, except for extensibleObject, which is optional. Servers MAY
+ implement additional object classes not listed in this document, and
+ if they do so, MUST publish the definitions of the classes in the
+ objectClasses attribute of their subschema entries.
+
+ Schema developers MUST NOT create object class definitions whose
+ names conflict with attributes defined for use with LDAP in existing
+ standards-track RFCs.
+
+4.5. Matching Rules
+
+ Matching rules are used by servers to compare attribute values
+ against assertion values when performing Search and Compare
+ operations. They are also used to identify the value to be added or
+ deleted when modifying entries, and are used when comparing a
+ purported distinguished name with the name of an entry.
+
+ Most of the attributes given in this document will have an equality
+ matching rule defined.
+
+ Matching rule descriptions are written according to the following
+ BNF. Implementors should note that future versions of this document
+ may have expanded this BNF to include additional terms. Terms whose
+ identifier begins with "X-" are reserved for private experiments, and
+
+
+
+Wahl, et. al. Standards Track [Page 10]
+
+RFC 2252 LADPv3 Attributes December 1997
+
+
+ MUST be followed by a <qdstrings> encoding.
+
+ MatchingRuleDescription = "(" whsp
+ numericoid whsp ; MatchingRule identifier
+ [ "NAME" qdescrs ]
+ [ "DESC" qdstring ]
+ [ "OBSOLETE" whsp ]
+ "SYNTAX" numericoid
+ whsp ")"
+
+ Values of the matchingRuleUse list the attributes which are suitable
+ for use with an extensible matching rule.
+
+ MatchingRuleUseDescription = "(" whsp
+ numericoid whsp ; MatchingRule identifier
+ [ "NAME" qdescrs ]
+ [ "DESC" qdstring ]
+ [ "OBSOLETE" ]
+ "APPLIES" oids ; AttributeType identifiers
+ whsp ")"
+
+ Servers which support matching rules and the extensibleMatch SHOULD
+ implement all the matching rules in section 8.
+
+ Servers MAY implement additional matching rules not listed in this
+ document, and if they do so, MUST publish the definitions of the
+ matching rules in the matchingRules attribute of their subschema
+ entries. If the server supports the extensibleMatch, then the server
+ MUST publish the relationship between the matching rules and
+ attributes in the matchingRuleUse attribute.
+
+ For example, a server which implements a privately-defined matching
+ rule for performing sound-alike matches on Directory String-valued
+ attributes would include the following in the subschema entry
+ (1.2.3.4.5 is an example, the OID of an actual matching rule would be
+ different):
+
+ matchingRule: ( 1.2.3.4.5 NAME 'soundAlikeMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+ If this matching rule could be used with the attributes 2.5.4.41 and
+ 2.5.4.15, the following would also be present:
+
+ matchingRuleUse: ( 1.2.3.4.5 APPLIES (2.5.4.41 $ 2.5.4.15) )
+
+
+
+
+
+
+
+Wahl, et. al. Standards Track [Page 11]
+
+RFC 2252 LADPv3 Attributes December 1997
+
+
+ A client could then make use of this matching rule by sending a
+ search operation in which the filter is of the extensibleMatch
+ choice, the matchingRule field is "soundAlikeMatch", and the type
+ field is "2.5.4.41" or "2.5.4.15".
+
+5. Attribute Types
+
+ All LDAP server implementations MUST recognize the attribute types
+ defined in this section.
+
+ Servers SHOULD also recognize all the attributes from section 5 of
+ [12].
+
+5.1. Standard Operational Attributes
+
+ Servers MUST maintain values of these attributes in accordance with
+ the definitions in X.501(93).
+
+5.1.1. createTimestamp
+
+ This attribute SHOULD appear in entries which were created using the
+ Add operation.
+
+ ( 2.5.18.1 NAME 'createTimestamp' EQUALITY generalizedTimeMatch
+ ORDERING generalizedTimeOrderingMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
+ SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation )
+
+5.1.2. modifyTimestamp
+
+ This attribute SHOULD appear in entries which have been modified
+ using the Modify operation.
+
+ ( 2.5.18.2 NAME 'modifyTimestamp' EQUALITY generalizedTimeMatch
+ ORDERING generalizedTimeOrderingMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
+ SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation )
+
+5.1.3. creatorsName
+
+ This attribute SHOULD appear in entries which were created using the
+ Add operation.
+
+ ( 2.5.18.3 NAME 'creatorsName' EQUALITY distinguishedNameMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
+ SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation )
+
+
+
+
+
+Wahl, et. al. Standards Track [Page 12]
+
+RFC 2252 LADPv3 Attributes December 1997
+
+
+5.1.4. modifiersName
+
+ This attribute SHOULD appear in entries which have been modified
+ using the Modify operation.
+
+ ( 2.5.18.4 NAME 'modifiersName' EQUALITY distinguishedNameMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
+ SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation )
+
+5.1.5. subschemaSubentry
+
+ The value of this attribute is the name of a subschema entry (or
+ subentry if the server is based on X.500(93)) in which the server
+ makes available attributes specifying the schema.
+
+ ( 2.5.18.10 NAME 'subschemaSubentry'
+ EQUALITY distinguishedNameMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 NO-USER-MODIFICATION
+ SINGLE-VALUE USAGE directoryOperation )
+
+5.1.6. attributeTypes
+
+ This attribute is typically located in the subschema entry.
+
+ ( 2.5.21.5 NAME 'attributeTypes'
+ EQUALITY objectIdentifierFirstComponentMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.3 USAGE directoryOperation )
+
+5.1.7. objectClasses
+
+ This attribute is typically located in the subschema entry.
+
+ ( 2.5.21.6 NAME 'objectClasses'
+ EQUALITY objectIdentifierFirstComponentMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.37 USAGE directoryOperation )
+
+5.1.8. matchingRules
+
+ This attribute is typically located in the subschema entry.
+
+ ( 2.5.21.4 NAME 'matchingRules'
+ EQUALITY objectIdentifierFirstComponentMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.30 USAGE directoryOperation )
+
+
+
+
+
+
+
+
+Wahl, et. al. Standards Track [Page 13]
+
+RFC 2252 LADPv3 Attributes December 1997
+
+
+5.1.9. matchingRuleUse
+
+ This attribute is typically located in the subschema entry.
+
+ ( 2.5.21.8 NAME 'matchingRuleUse'
+ EQUALITY objectIdentifierFirstComponentMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.31 USAGE directoryOperation )
+
+5.2. LDAP Operational Attributes
+
+ These attributes are only present in the root DSE (see [1] and [3]).
+
+ Servers MUST recognize these attribute names, but it is not required
+ that a server provide values for these attributes, when the attribute
+ corresponds to a feature which the server does not implement.
+
+5.2.1. namingContexts
+
+ The values of this attribute correspond to naming contexts which this
+ server masters or shadows. If the server does not master any
+ information (e.g. it is an LDAP gateway to a public X.500 directory)
+ this attribute will be absent. If the server believes it contains
+ the entire directory, the attribute will have a single value, and
+ that value will be the empty string (indicating the null DN of the
+ root). This attribute will allow a client to choose suitable base
+ objects for searching when it has contacted a server.
+
+ ( 1.3.6.1.4.1.1466.101.120.5 NAME 'namingContexts'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 USAGE dSAOperation )
+
+5.2.2. altServer
+
+ The values of this attribute are URLs of other servers which may be
+ contacted when this server becomes unavailable. If the server does
+ not know of any other servers which could be used this attribute will
+ be absent. Clients may cache this information in case their preferred
+ LDAP server later becomes unavailable.
+
+ ( 1.3.6.1.4.1.1466.101.120.6 NAME 'altServer'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 USAGE dSAOperation )
+
+5.2.3. supportedExtension
+
+ The values of this attribute are OBJECT IDENTIFIERs identifying the
+ supported extended operations which the server supports.
+
+ If the server does not support any extensions this attribute will be
+ absent.
+
+
+
+Wahl, et. al. Standards Track [Page 14]
+
+RFC 2252 LADPv3 Attributes December 1997
+
+
+ ( 1.3.6.1.4.1.1466.101.120.7 NAME 'supportedExtension'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 USAGE dSAOperation )
+
+5.2.4. supportedControl
+
+ The values of this attribute are the OBJECT IDENTIFIERs identifying
+ controls which the server supports. If the server does not support
+ any controls, this attribute will be absent.
+
+ ( 1.3.6.1.4.1.1466.101.120.13 NAME 'supportedControl'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 USAGE dSAOperation )
+
+5.2.5. supportedSASLMechanisms
+
+ The values of this attribute are the names of supported SASL
+ mechanisms which the server supports. If the server does not support
+ any mechanisms this attribute will be absent.
+
+ ( 1.3.6.1.4.1.1466.101.120.14 NAME 'supportedSASLMechanisms'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 USAGE dSAOperation )
+
+5.2.6. supportedLDAPVersion
+
+ The values of this attribute are the versions of the LDAP protocol
+ which the server implements.
+
+ ( 1.3.6.1.4.1.1466.101.120.15 NAME 'supportedLDAPVersion'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 USAGE dSAOperation )
+
+5.3. LDAP Subschema Attribute
+
+ This attribute is typically located in the subschema entry.
+
+5.3.1. ldapSyntaxes
+
+ Servers MAY use this attribute to list the syntaxes which are
+ implemented. Each value corresponds to one syntax.
+
+ ( 1.3.6.1.4.1.1466.101.120.16 NAME 'ldapSyntaxes'
+ EQUALITY objectIdentifierFirstComponentMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.54 USAGE directoryOperation )
+
+5.4. X.500 Subschema attributes
+
+ These attributes are located in the subschema entry. All servers
+ SHOULD recognize their name, although typically only X.500 servers
+ will implement their functionality.
+
+
+
+
+Wahl, et. al. Standards Track [Page 15]
+
+RFC 2252 LADPv3 Attributes December 1997
+
+
+5.4.1. dITStructureRules
+
+ ( 2.5.21.1 NAME 'dITStructureRules' EQUALITY integerFirstComponentMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.17 USAGE directoryOperation )
+
+5.4.2. nameForms
+
+ ( 2.5.21.7 NAME 'nameForms'
+ EQUALITY objectIdentifierFirstComponentMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.35 USAGE directoryOperation )
+
+5.4.3. ditContentRules
+
+ ( 2.5.21.2 NAME 'dITContentRules'
+ EQUALITY objectIdentifierFirstComponentMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.16 USAGE directoryOperation )
+
+6. Syntaxes
+
+ Servers SHOULD recognize all the syntaxes described in this section.
+
+6.1. Attribute Type Description
+
+ ( 1.3.6.1.4.1.1466.115.121.1.3 DESC 'Attribute Type Description' )
+
+ Values in this syntax are encoded according to the BNF given at the
+ start of section 4.2. For example,
+
+ ( 2.5.4.0 NAME 'objectClass'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
+
+6.2. Binary
+
+ ( 1.3.6.1.4.1.1466.115.121.1.5 DESC 'Binary' )
+
+ Values in this syntax are encoded as described in section 4.3.1.
+
+6.3. Bit String
+
+ ( 1.3.6.1.4.1.1466.115.121.1.6 DESC 'Bit String' )
+
+ Values in this syntax are encoded according to the following BNF:
+
+ bitstring = "'" *binary-digit "'B"
+
+ binary-digit = "0" / "1"
+
+
+
+
+
+Wahl, et. al. Standards Track [Page 16]
+
+RFC 2252 LADPv3 Attributes December 1997
+
+
+ Example:
+
+ '0101111101'B
+
+6.4. Boolean
+
+ ( 1.3.6.1.4.1.1466.115.121.1.7 DESC 'Boolean' )
+
+ Values in this syntax are encoded according to the following BNF:
+
+ boolean = "TRUE" / "FALSE"
+
+ Boolean values have an encoding of "TRUE" if they are logically true,
+ and have an encoding of "FALSE" otherwise.
+
+6.5. Certificate
+
+ ( 1.3.6.1.4.1.1466.115.121.1.8 DESC 'Certificate' )
+
+ Because of the changes from X.509(1988) and X.509(1993) and
+ additional changes to the ASN.1 definition to support certificate
+ extensions, no string representation is defined, and values in this
+ syntax MUST only be transferred using the binary encoding, by
+ requesting or returning the attributes with descriptions
+ "userCertificate;binary" or "caCertificate;binary". The BNF notation
+ in RFC 1778 for "User Certificate" is not recommended to be used.
+
+6.6. Certificate List
+
+ ( 1.3.6.1.4.1.1466.115.121.1.9 DESC 'Certificate List' )
+
+ Because of the incompatibility of the X.509(1988) and X.509(1993)
+ definitions of revocation lists, values in this syntax MUST only be
+ transferred using a binary encoding, by requesting or returning the
+ attributes with descriptions "certificateRevocationList;binary" or
+ "authorityRevocationList;binary". The BNF notation in RFC 1778 for
+ "Authority Revocation List" is not recommended to be used.
+
+6.7. Certificate Pair
+
+ ( 1.3.6.1.4.1.1466.115.121.1.10 DESC 'Certificate Pair' )
+
+ Because the Certificate is being carried in binary, values in this
+ syntax MUST only be transferred using a binary encoding, by
+ requesting or returning the attribute description
+ "crossCertificatePair;binary". The BNF notation in RFC 1778 for
+ "Certificate Pair" is not recommended to be used.
+
+
+
+
+Wahl, et. al. Standards Track [Page 17]
+
+RFC 2252 LADPv3 Attributes December 1997
+
+
+6.8. Country String
+
+ ( 1.3.6.1.4.1.1466.115.121.1.11 DESC 'Country String' )
+
+ A value in this syntax is encoded the same as a value of Directory
+ String syntax. Note that this syntax is limited to values of exactly
+ two printable string characters, as listed in ISO 3166 [14].
+
+ CountryString = p p
+
+ Example:
+ US
+
+6.9. DN
+
+ ( 1.3.6.1.4.1.1466.115.121.1.12 DESC 'DN' )
+
+ Values in the Distinguished Name syntax are encoded to have the
+ representation defined in [5]. Note that this representation is not
+ reversible to an ASN.1 encoding used in X.500 for Distinguished
+ Names, as the CHOICE of any DirectoryString element in an RDN is no
+ longer known.
+
+ Examples (from [5]):
+ CN=Steve Kille,O=Isode Limited,C=GB
+ OU=Sales+CN=J. Smith,O=Widget Inc.,C=US
+ CN=L. Eagle,O=Sue\, Grabbit and Runn,C=GB
+ CN=Before\0DAfter,O=Test,C=GB
+ 1.3.6.1.4.1.1466.0=#04024869,O=Test,C=GB
+ SN=Lu\C4\8Di\C4\87
+
+6.10. Directory String
+
+ ( 1.3.6.1.4.1.1466.115.121.1.15 DESC 'Directory String' )
+
+ A string in this syntax is encoded in the UTF-8 form of ISO 10646 (a
+ superset of Unicode). Servers and clients MUST be prepared to
+ receive encodings of arbitrary Unicode characters, including
+ characters not presently assigned to any character set.
+
+ For characters in the PrintableString form, the value is encoded as
+ the string value itself.
+
+ If it is of the TeletexString form, then the characters are
+ transliterated to their equivalents in UniversalString, and encoded
+ in UTF-8 [9].
+
+
+
+
+
+Wahl, et. al. Standards Track [Page 18]
+
+RFC 2252 LADPv3 Attributes December 1997
+
+
+ If it is of the UniversalString or BMPString forms [10], UTF-8 is
+ used to encode them.
+
+ Note: the form of DirectoryString is not indicated in protocol unless
+ the attribute value is carried in binary. Servers which convert to
+ DAP MUST choose an appropriate form. Servers MUST NOT reject values
+ merely because they contain legal Unicode characters outside of the
+ range of printable ASCII.
+
+ Example:
+
+ This is a string of DirectoryString containing #!%#@
+
+6.11. DIT Content Rule Description
+
+
+ ues in this syntax are encoded according to the following BNF.
+ lementors should note that future versions of this document
+ have expanded this BNF to include additional terms.
+
+ 0
+
+ DITContentRuleDescription = "("
+ numericoid ; Structural ObjectClass identifier
+ [ "NAME" qdescrs ]
+ [ "DESC" qdstring ]
+ [ "OBSOLETE" ]
+ [ "AUX" oids ] ; Auxiliary ObjectClasses
+ [ "MUST" oids ] ; AttributeType identifiers
+ [ "MAY" oids ] ; AttributeType identifiers
+ [ "NOT" oids ] ; AttributeType identifiers
+ ")"
+
+ 0 2. Facsimile Telephone Number
+
+ 3
+
+ ( 1.3.6.1.4.1.1466.115.121.1.22 DESC 'Facsimile Telephone Number' )
+
+ Values in this syntax are encoded according to the following BNF:
+
+ fax-number = printablestring [ "$" faxparameters ]
+
+ faxparameters = faxparm / ( faxparm "$" faxparameters )
+
+ faxparm = "twoDimensional" / "fineResolution" /
+ "unlimitedLength" /
+ "b4Length" / "a3Width" / "b4Width" / "uncompressed"
+
+
+
+Wahl, et. al. Standards Track [Page 19]
+
+RFC 2252 LADPv3 Attributes December 1997
+
+
+ In the above, the first printablestring is the telephone number,
+ based on E.123 [15], and the faxparm tokens represent fax parameters.
+
+6.13. Fax
+
+ ( 1.3.6.1.4.1.1466.115.121.1.23 DESC 'Fax' )
+
+ Values in this syntax are encoded as if they were octet strings
+ containing Group 3 Fax images as defined in [7].
+
+6.14. Generalized Time
+
+ ( 1.3.6.1.4.1.1466.115.121.1.24 DESC 'Generalized Time' )
+
+ Values in this syntax are encoded as printable strings, represented
+ as specified in X.208. Note that the time zone must be specified.
+ It is strongly recommended that GMT time be used. For example,
+
+ 199412161032Z
+
+6.15. IA5 String
+
+ ( 1.3.6.1.4.1.1466.115.121.1.26 DESC 'IA5 String' )
+
+ The encoding of a value in this syntax is the string value itself.
+
+6.16. INTEGER
+
+ ( 1.3.6.1.4.1.1466.115.121.1.27 DESC 'INTEGER' )
+
+ Values in this syntax are encoded as the decimal representation of
+ their values, with each decimal digit represented by the its
+ character equivalent. So the number 1321 is represented by the
+ character string "1321".
+
+6.17. JPEG
+
+ ( 1.3.6.1.4.1.1466.115.121.1.28 DESC 'JPEG' )
+
+ Values in this syntax are encoded as strings containing JPEG images
+ in the JPEG File Interchange Format (JFIF), as described in [8].
+
+6.18. Matching Rule Description
+
+ ( 1.3.6.1.4.1.1466.115.121.1.30 DESC 'Matching Rule Description' )
+
+ Values of type matchingRules are encoded as strings according to the
+ BNF given in section 4.5.
+
+
+
+Wahl, et. al. Standards Track [Page 20]
+
+RFC 2252 LADPv3 Attributes December 1997
+
+
+6.19. Matching Rule Use Description
+
+ ( 1.3.6.1.4.1.1466.115.121.1.31 DESC 'Matching Rule Use Description'
+ )
+
+ Values of type matchingRuleUse are encoded as strings according to
+ the BNF given in section 4.5.
+
+6.20. MHS OR Address
+
+ ( 1.3.6.1.4.1.1466.115.121.1.33 DESC 'MHS OR Address' )
+
+ Values in this syntax are encoded as strings, according to the format
+ defined in [11].
+
+6.21. Name And Optional UID
+
+ ( 1.3.6.1.4.1.1466.115.121.1.34 DESC 'Name And Optional UID' )
+
+ Values in this syntax are encoded according to the following BNF:
+
+ NameAndOptionalUID = DistinguishedName [ "#" bitstring ]
+
+ Although the '#' character may occur in a string representation of a
+ distinguished name, no additional special quoting is done. This
+ syntax has been added subsequent to RFC 1778.
+
+ Example:
+
+ 1.3.6.1.4.1.1466.0=#04024869,O=Test,C=GB#'0101'B
+
+6.22. Name Form Description
+
+ ( 1.3.6.1.4.1.1466.115.121.1.35 DESC 'Name Form Description' )
+
+ Values in this syntax are encoded according to the following BNF.
+ Implementors should note that future versions of this document may
+ have expanded this BNF to include additional terms.
+
+ NameFormDescription = "(" whsp
+ numericoid whsp ; NameForm identifier
+ [ "NAME" qdescrs ]
+ [ "DESC" qdstring ]
+ [ "OBSOLETE" whsp ]
+ "OC" woid ; Structural ObjectClass
+ "MUST" oids ; AttributeTypes
+ [ "MAY" oids ] ; AttributeTypes
+ whsp ")"
+
+
+
+Wahl, et. al. Standards Track [Page 21]
+
+RFC 2252 LADPv3 Attributes December 1997
+
+
+6.23. Numeric String
+
+ ( 1.3.6.1.4.1.1466.115.121.1.36 DESC 'Numeric String' )
+
+ The encoding of a string in this syntax is the string value itself.
+ Example:
+
+ 1997
+
+6.24. Object Class Description
+
+ ( 1.3.6.1.4.1.1466.115.121.1.37 DESC 'Object Class Description' )
+
+ Values in this syntax are encoded according to the BNF in section
+ 4.4.
+
+6.25. OID
+
+ ( 1.3.6.1.4.1.1466.115.121.1.38 DESC 'OID' )
+
+ Values in the Object Identifier syntax are encoded according to
+ the BNF in section 4.1 for "oid".
+
+ Example:
+
+ 1.2.3.4
+ cn
+
+6.26. Other Mailbox
+
+ ( 1.3.6.1.4.1.1466.115.121.1.39 DESC 'Other Mailbox' )
+
+ Values in this syntax are encoded according to the following BNF:
+
+ otherMailbox = mailbox-type "$" mailbox
+
+ mailbox-type = printablestring
+
+ mailbox = <an encoded IA5 String>
+
+ In the above, mailbox-type represents the type of mail system in
+ which the mailbox resides, for example "MCIMail"; and mailbox is the
+ actual mailbox in the mail system defined by mailbox-type.
+
+6.27. Postal Address
+
+ ( 1.3.6.1.4.1.1466.115.121.1.41 DESC 'Postal Address' )
+
+
+
+
+Wahl, et. al. Standards Track [Page 22]
+
+RFC 2252 LADPv3 Attributes December 1997
+
+
+ Values in this syntax are encoded according to the following BNF:
+
+ postal-address = dstring *( "$" dstring )
+
+ In the above, each dstring component of a postal address value is
+ encoded as a value of type Directory String syntax. Backslashes and
+ dollar characters, if they occur in the component, are quoted as
+ described in section 4.3. Many servers limit the postal address to
+ six lines of up to thirty characters.
+
+ Example:
+
+ 1234 Main St.$Anytown, CA 12345$USA
+ \241,000,000 Sweepstakes$PO Box 1000000$Anytown, CA 12345$USA
+
+6.28. Presentation Address
+
+ ( 1.3.6.1.4.1.1466.115.121.1.43 DESC 'Presentation Address' )
+
+ Values in this syntax are encoded with the representation described
+ in RFC 1278 [6].
+
+6.29. Printable String
+
+ ( 1.3.6.1.4.1.1466.115.121.1.44 DESC 'Printable String' )
+
+ The encoding of a value in this syntax is the string value itself.
+ PrintableString is limited to the characters in production p of
+ section 4.1.
+
+ Example:
+
+ This is a PrintableString
+
+6.30. Telephone Number
+
+ ( 1.3.6.1.4.1.1466.115.121.1.50 DESC 'Telephone Number' )
+
+ Values in this syntax are encoded as if they were Printable String
+ types. Telephone numbers are recommended in X.520 to be in
+ international form, as described in E.123 [15].
+
+ Example:
+
+ +1 512 305 0280
+
+
+
+
+
+
+Wahl, et. al. Standards Track [Page 23]
+
+RFC 2252 LADPv3 Attributes December 1997
+
+
+6.31. UTC Time
+
+ ( 1.3.6.1.4.1.1466.115.121.1.53 DESC 'UTC Time' )
+
+ Values in this syntax are encoded as if they were printable strings
+ with the strings containing a UTCTime value. This is historical; new
+ attribute definitions SHOULD use GeneralizedTime instead.
+
+6.32. LDAP Syntax Description
+
+ ( 1.3.6.1.4.1.1466.115.121.1.54 DESC 'LDAP Syntax Description' )
+
+ Values in this syntax are encoded according to the BNF in section
+ 4.3.3.
+
+6.33. DIT Structure Rule Description
+
+ ( 1.3.6.1.4.1.1466.115.121.1.17 DESC 'DIT Structure Rule Description'
+ )
+
+ Values with this syntax are encoded according to the following BNF:
+
+ DITStructureRuleDescription = "(" whsp
+ ruleidentifier whsp ; DITStructureRule identifier
+ [ "NAME" qdescrs ]
+ [ "DESC" qdstring ]
+ [ "OBSOLETE" whsp ]
+ "FORM" woid whsp ; NameForm
+ [ "SUP" ruleidentifiers whsp ] ; superior DITStructureRules
+ ")"
+
+ ruleidentifier = integer
+
+ ruleidentifiers = ruleidentifier |
+ "(" whsp ruleidentifierlist whsp ")"
+
+ ruleidentifierlist = [ ruleidentifier *( ruleidentifier ) ]
+
+7. Object Classes
+
+ Servers SHOULD recognize all the names of standard classes from
+ section 7 of [12].
+
+7.1. Extensible Object Class
+
+ The extensibleObject object class, if present in an entry, permits
+ that entry to optionally hold any attribute. The MAY attribute list
+ of this class is implicitly the set of all attributes.
+
+
+
+Wahl, et. al. Standards Track [Page 24]
+
+RFC 2252 LADPv3 Attributes December 1997
+
+
+ ( 1.3.6.1.4.1.1466.101.120.111 NAME 'extensibleObject'
+ SUP top AUXILIARY )
+
+ The mandatory attributes of the other object classes of this entry
+ are still required to be present.
+
+ Note that not all servers will implement this object class, and those
+ which do not will reject requests to add entries which contain this
+ object class, or modify an entry to add this object class.
+
+7.2. subschema
+
+ This object class is used in the subschema entry.
+
+ ( 2.5.20.1 NAME 'subschema' AUXILIARY
+ MAY ( dITStructureRules $ nameForms $ ditContentRules $
+ objectClasses $ attributeTypes $ matchingRules $
+ matchingRuleUse ) )
+
+ The ldapSyntaxes operational attribute may also be present in
+ subschema entries.
+
+8. Matching Rules
+
+ Servers which implement the extensibleMatch filter SHOULD allow all
+ the matching rules listed in this section to be used in the
+ extensibleMatch. In general these servers SHOULD allow matching
+ rules to be used with all attribute types known to the server, when
+ the assertion syntax of the matching rule is the same as the value
+ syntax of the attribute.
+
+ Servers MAY implement additional matching rules.
+
+8.1. Matching Rules used in Equality Filters
+
+ Servers SHOULD be capable of performing the following matching rules.
+
+ For all these rules, the assertion syntax is the same as the value
+ syntax.
+
+ ( 2.5.13.0 NAME 'objectIdentifierMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
+
+ If the client supplies a filter using an objectIdentifierMatch whose
+ matchValue oid is in the "descr" form, and the oid is not recognized
+ by the server, then the filter is Undefined.
+
+ ( 2.5.13.1 NAME 'distinguishedNameMatch'
+
+
+
+Wahl, et. al. Standards Track [Page 25]
+
+RFC 2252 LADPv3 Attributes December 1997
+
+
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
+
+ ( 2.5.13.2 NAME 'caseIgnoreMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+ ( 2.5.13.8 NAME 'numericStringMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 )
+
+ ( 2.5.13.11 NAME 'caseIgnoreListMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 )
+
+ ( 2.5.13.14 NAME 'integerMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )
+
+ ( 2.5.13.16 NAME 'bitStringMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 )
+
+ ( 2.5.13.20 NAME 'telephoneNumberMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 )
+
+ ( 2.5.13.22 NAME 'presentationAddressMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.43 )
+
+ ( 2.5.13.23 NAME 'uniqueMemberMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.34 )
+
+ ( 2.5.13.24 NAME 'protocolInformationMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.42 )
+
+ ( 2.5.13.27 NAME 'generalizedTimeMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 )
+
+ ( 1.3.6.1.4.1.1466.109.114.1 NAME 'caseExactIA5Match'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
+
+ ( 1.3.6.1.4.1.1466.109.114.2 NAME 'caseIgnoreIA5Match'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
+
+ When performing the caseIgnoreMatch, caseIgnoreListMatch,
+ telephoneNumberMatch, caseExactIA5Match and caseIgnoreIA5Match,
+ multiple adjoining whitespace characters are treated the same as an
+ individual space, and leading and trailing whitespace is ignored.
+
+ Clients MUST NOT assume that servers are capable of transliteration
+ of Unicode values.
+
+
+
+
+
+
+Wahl, et. al. Standards Track [Page 26]
+
+RFC 2252 LADPv3 Attributes December 1997
+
+
+8.2. Matching Rules used in Inequality Filters
+
+ Servers SHOULD be capable of performing the following matching rules,
+ which are used in greaterOrEqual and lessOrEqual filters.
+
+ ( 2.5.13.28 NAME 'generalizedTimeOrderingMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 )
+
+ ( 2.5.13.3 NAME 'caseIgnoreOrderingMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+ The sort ordering for a caseIgnoreOrderingMatch is implementation-
+ dependent.
+
+8.3. Syntax and Matching Rules used in Substring Filters
+
+ The Substring Assertion syntax is used only as the syntax of
+ assertion values in the extensible match. It is not used as the
+ syntax of attributes, or in the substring filter.
+
+ ( 1.3.6.1.4.1.1466.115.121.1.58 DESC 'Substring Assertion' )
+
+ The Substring Assertion is encoded according to the following BNF:
+
+ substring = [initial] any [final]
+ initial = value
+ any = "*" *(value "*")
+ final = value
+
+ The <value> production is UTF-8 encoded string. Should the backslash
+ or asterix characters be present in a production of <value>, they are
+ quoted as described in section 4.3.
+
+ Servers SHOULD be capable of performing the following matching rules,
+ which are used in substring filters.
+
+ ( 2.5.13.4 NAME 'caseIgnoreSubstringsMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
+
+ ( 2.5.13.21 NAME 'telephoneNumberSubstringsMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
+
+ ( 2.5.13.10 NAME 'numericStringSubstringsMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
+
+
+
+
+
+
+
+Wahl, et. al. Standards Track [Page 27]
+
+RFC 2252 LADPv3 Attributes December 1997
+
+
+8.4. Matching Rules for Subschema Attributes
+
+ Servers which allow subschema entries to be modified by clients MUST
+ support the following matching rules, as they are the equality
+ matching rules for several of the subschema attributes.
+
+ ( 2.5.13.29 NAME 'integerFirstComponentMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )
+
+ ( 2.5.13.30 NAME 'objectIdentifierFirstComponentMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
+
+ Implementors should note that the assertion syntax of these matching
+ rules, an INTEGER or OID, is different from the value syntax of
+ attributes for which this is the equality matching rule.
+
+ If the client supplies an extensible filter using an
+ objectIdentifierFirstComponentMatch whose matchValue is in the
+ "descr" form, and the OID is not recognized by the server, then the
+ filter is Undefined.
+
+9. Security Considerations
+
+9.1. Disclosure
+
+ Attributes of directory entries are used to provide descriptive
+ information about the real-world objects they represent, which can be
+ people, organizations or devices. Most countries have privacy laws
+ regarding the publication of information about people.
+
+9.2. Use of Attribute Values in Security Applications
+
+ The transformations of an AttributeValue value from its X.501 form to
+ an LDAP string representation are not always reversible back to the
+ same BER or DER form. An example of a situation which requires the
+ DER form of a distinguished name is the verification of an X.509
+ certificate.
+
+ For example, a distinguished name consisting of one RDN with one AVA,
+ in which the type is commonName and the value is of the TeletexString
+ choice with the letters 'Sam' would be represented in LDAP as the
+ string CN=Sam. Another distinguished name in which the value is
+ still 'Sam' but of the PrintableString choice would have the same
+ representation CN=Sam.
+
+ Applications which require the reconstruction of the DER form of the
+ value SHOULD NOT use the string representation of attribute syntaxes
+ when converting a value to LDAP format. Instead it SHOULD use the
+
+
+
+Wahl, et. al. Standards Track [Page 28]
+
+RFC 2252 LADPv3 Attributes December 1997
+
+
+ Binary syntax.
+
+10. Acknowledgements
+
+ This document is based substantially on RFC 1778, written by Tim
+ Howes, Steve Kille, Wengyik Yeong and Colin Robbins.
+
+ Many of the attribute syntax encodings defined in this and related
+ documents are adapted from those used in the QUIPU and the IC R3
+ X.500 implementations. The contributions of the authors of both these
+ implementations in the specification of syntaxes are gratefully
+ acknowledged.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wahl, et. al. Standards Track [Page 29]
+
+RFC 2252 LADPv3 Attributes December 1997
+
+
+11. Authors' Addresses
+
+ Mark Wahl
+ Critical Angle Inc.
+ 4815 West Braker Lane #502-385
+ Austin, TX 78759
+ USA
+
+ Phone: +1 512 372-3160
+ EMail: M.Wahl at critical-angle.com
+
+ Andy Coulbeck
+ Isode Inc.
+ 9390 Research Blvd Suite 305
+ Austin, TX 78759
+ USA
+
+ Phone: +1 512 231-8993
+ EMail: A.Coulbeck at isode.com
+
+ Tim Howes
+ Netscape Communications Corp.
+ 501 E. Middlefield Rd, MS MV068
+ Mountain View, CA 94043
+ USA
+
+ Phone: +1 650 937-3419
+ EMail: howes at netscape.com
+
+ Steve Kille
+ Isode Limited
+ The Dome, The Square
+ Richmond
+ TW9 1DT
+ UK
+
+ Phone: +44-181-332-9091
+ EMail: S.Kille at isode.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wahl, et. al. Standards Track [Page 30]
+
+RFC 2252 LADPv3 Attributes December 1997
+
+
+12. Bibliography
+
+ [1] Wahl, M., Howes, T., and S. Kille, "Lightweight Directory Access
+ Protocol (v3)", RFC 2251, December 1997.
+
+ [2] The Directory: Selected Attribute Types. ITU-T Recommendation
+ X.520, 1993.
+
+ [3] The Directory: Models. ITU-T Recommendation X.501, 1993.
+
+ [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+ Levels", RFC 2119, March 1997.
+
+ [5] Wahl, M., Kille, S., and T. Howes, "Lightweight Directory Access
+ Protocol (v3): UTF-8 String Representation of
+ Distinguished Names", RFC 2253, December 1997.
+
+ [6] Kille, S., "A String Representation for Presentation Addresses",
+ RFC 1278, November 1991.
+
+ [7] Terminal Equipment and Protocols for Telematic Services -
+ Standardization of Group 3 facsimile apparatus for document
+ transmission. CCITT, Recommendation T.4.
+
+ [8] JPEG File Interchange Format (Version 1.02). Eric Hamilton,
+ C-Cube Microsystems, Milpitas, CA, September 1, 1992.
+
+ [9] Yergeau, F., "UTF-8, a transformation format of Unicode and ISO
+ 10646", RFC 2044, October 1996.
+
+ [10] Universal Multiple-Octet Coded Character Set (UCS) -
+ Architecture and Basic Multilingual Plane, ISO/IEC 10646-1 :
+ 1993 (With amendments).
+
+ [11] Hardcastle-Kille, S., "Mapping between X.400(1988) / ISO 10021
+ and RFC 822", RFC 1327, May 1992.
+
+ [12] Wahl, M., "A Summary of the X.500(96) User Schema for use
+ with LDAPv3", RFC 2256, December 1997.
+
+ [13] Crocker, D., "Standard of the Format of ARPA-Internet Text
+ Messages", STD 11, RFC 822, August 1982.
+
+ [14] ISO 3166, "Codes for the representation of names of countries".
+
+ [15] ITU-T Rec. E.123, Notation for national and international
+ telephone numbers, 1988.
+
+
+
+
+Wahl, et. al. Standards Track [Page 31]
+
+RFC 2252 LADPv3 Attributes December 1997
+
+
+13. Full Copyright Statement
+
+ Copyright (C) The Internet Society (1997). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wahl, et. al. Standards Track [Page 32]
+
Added: openldap/vendor/openldap-release/doc/rfc/rfc2253.txt
===================================================================
--- openldap/vendor/openldap-release/doc/rfc/rfc2253.txt (rev 0)
+++ openldap/vendor/openldap-release/doc/rfc/rfc2253.txt 2007-09-15 10:38:52 UTC (rev 844)
@@ -0,0 +1,563 @@
+
+
+
+
+
+
+Network Working Group M. Wahl
+Request for Comments: 2253 Critical Angle Inc.
+Obsoletes: 1779 S. Kille
+Category: Standards Track Isode Ltd.
+ T. Howes
+ Netscape Communications Corp.
+ December 1997
+
+
+ Lightweight Directory Access Protocol (v3):
+ UTF-8 String Representation of Distinguished Names
+
+Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (1997). All Rights Reserved.
+
+IESG Note
+
+ This document describes a directory access protocol that provides
+ both read and update access. Update access requires secure
+ authentication, but this document does not mandate implementation of
+ any satisfactory authentication mechanisms.
+
+ In accordance with RFC 2026, section 4.4.1, this specification is
+ being approved by IESG as a Proposed Standard despite this
+ limitation, for the following reasons:
+
+ a. to encourage implementation and interoperability testing of
+ these protocols (with or without update access) before they
+ are deployed, and
+
+ b. to encourage deployment and use of these protocols in read-only
+ applications. (e.g. applications where LDAPv3 is used as
+ a query language for directories which are updated by some
+ secure mechanism other than LDAP), and
+
+ c. to avoid delaying the advancement and deployment of other Internet
+ standards-track protocols which require the ability to query, but
+ not update, LDAPv3 directory servers.
+
+
+
+
+Wahl, et. al. Proposed Standard [Page 1]
+
+RFC 2253 LADPv3 Distinguished Names December 1997
+
+
+ Readers are hereby warned that until mandatory authentication
+ mechanisms are standardized, clients and servers written according to
+ this specification which make use of update functionality are
+ UNLIKELY TO INTEROPERATE, or MAY INTEROPERATE ONLY IF AUTHENTICATION
+ IS REDUCED TO AN UNACCEPTABLY WEAK LEVEL.
+
+ Implementors are hereby discouraged from deploying LDAPv3 clients or
+ servers which implement the update functionality, until a Proposed
+ Standard for mandatory authentication in LDAPv3 has been approved and
+ published as an RFC.
+
+Abstract
+
+ The X.500 Directory uses distinguished names as the primary keys to
+ entries in the directory. Distinguished Names are encoded in ASN.1
+ in the X.500 Directory protocols. In the Lightweight Directory
+ Access Protocol, a string representation of distinguished names is
+ transferred. This specification defines the string format for
+ representing names, which is designed to give a clean representation
+ of commonly used distinguished names, while being able to represent
+ any distinguished name.
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in RFC 2119 [6].
+
+1. Background
+
+ This specification assumes familiarity with X.500 [1], and the
+ concept of Distinguished Name. It is important to have a common
+ format to be able to unambiguously represent a distinguished name.
+ The primary goal of this specification is ease of encoding and
+ decoding. A secondary goal is to have names that are human readable.
+ It is not expected that LDAP clients with a human user interface
+ would display these strings directly to the user, but would most
+ likely be performing translations (such as expressing attribute type
+ names in one of the local national languages).
+
+2. Converting DistinguishedName from ASN.1 to a String
+
+ In X.501 [2] the ASN.1 structure of distinguished name is defined as:
+
+ DistinguishedName ::= RDNSequence
+
+ RDNSequence ::= SEQUENCE OF RelativeDistinguishedName
+
+
+
+
+
+
+Wahl, et. al. Proposed Standard [Page 2]
+
+RFC 2253 LADPv3 Distinguished Names December 1997
+
+
+ RelativeDistinguishedName ::= SET SIZE (1..MAX) OF
+ AttributeTypeAndValue
+
+ AttributeTypeAndValue ::= SEQUENCE {
+ type AttributeType,
+ value AttributeValue }
+
+ The following sections define the algorithm for converting from an
+ ASN.1 structured representation to a UTF-8 string representation.
+
+2.1. Converting the RDNSequence
+
+ If the RDNSequence is an empty sequence, the result is the empty or
+ zero length string.
+
+ Otherwise, the output consists of the string encodings of each
+ RelativeDistinguishedName in the RDNSequence (according to 2.2),
+ starting with the last element of the sequence and moving backwards
+ toward the first.
+
+ The encodings of adjoining RelativeDistinguishedNames are separated
+ by a comma character (',' ASCII 44).
+
+2.2. Converting RelativeDistinguishedName
+
+ When converting from an ASN.1 RelativeDistinguishedName to a string,
+ the output consists of the string encodings of each
+ AttributeTypeAndValue (according to 2.3), in any order.
+
+ Where there is a multi-valued RDN, the outputs from adjoining
+ AttributeTypeAndValues are separated by a plus ('+' ASCII 43)
+ character.
+
+2.3. Converting AttributeTypeAndValue
+
+ The AttributeTypeAndValue is encoded as the string representation of
+ the AttributeType, followed by an equals character ('=' ASCII 61),
+ followed by the string representation of the AttributeValue. The
+ encoding of the AttributeValue is given in section 2.4.
+
+ If the AttributeType is in a published table of attribute types
+ associated with LDAP [4], then the type name string from that table
+ is used, otherwise it is encoded as the dotted-decimal encoding of
+ the AttributeType's OBJECT IDENTIFIER. The dotted-decimal notation is
+ described in [3]. As an example, strings for a few of the attribute
+ types frequently seen in RDNs include:
+
+
+
+
+
+Wahl, et. al. Proposed Standard [Page 3]
+
+RFC 2253 LADPv3 Distinguished Names December 1997
+
+
+ String X.500 AttributeType
+ ------------------------------
+ CN commonName
+ L localityName
+ ST stateOrProvinceName
+ O organizationName
+ OU organizationalUnitName
+ C countryName
+ STREET streetAddress
+ DC domainComponent
+ UID userid
+
+2.4. Converting an AttributeValue from ASN.1 to a String
+
+ If the AttributeValue is of a type which does not have a string
+ representation defined for it, then it is simply encoded as an
+ octothorpe character ('#' ASCII 35) followed by the hexadecimal
+ representation of each of the bytes of the BER encoding of the X.500
+ AttributeValue. This form SHOULD be used if the AttributeType is of
+ the dotted-decimal form.
+
+ Otherwise, if the AttributeValue is of a type which has a string
+ representation, the value is converted first to a UTF-8 string
+ according to its syntax specification (see for example section 6 of
+ [4]).
+
+ If the UTF-8 string does not have any of the following characters
+ which need escaping, then that string can be used as the string
+ representation of the value.
+
+ o a space or "#" character occurring at the beginning of the
+ string
+
+ o a space character occurring at the end of the string
+
+ o one of the characters ",", "+", """, "\", "<", ">" or ";"
+
+ Implementations MAY escape other characters.
+
+ If a character to be escaped is one of the list shown above, then it
+ is prefixed by a backslash ('\' ASCII 92).
+
+ Otherwise the character to be escaped is replaced by a backslash and
+ two hex digits, which form a single byte in the code of the
+ character.
+
+ Examples of the escaping mechanism are shown in section 5.
+
+
+
+
+Wahl, et. al. Proposed Standard [Page 4]
+
+RFC 2253 LADPv3 Distinguished Names December 1997
+
+
+3. Parsing a String back to a Distinguished Name
+
+ The structure of the string is specified in a BNF grammar, based on
+ the grammar defined in RFC 822 [5]. Server implementations parsing a
+ DN string generated by an LDAPv2 client MUST also accept (and ignore)
+ the variants given in section 4 of this document.
+
+distinguishedName = [name] ; may be empty string
+
+name = name-component *("," name-component)
+
+name-component = attributeTypeAndValue *("+" attributeTypeAndValue)
+
+attributeTypeAndValue = attributeType "=" attributeValue
+
+attributeType = (ALPHA 1*keychar) / oid
+keychar = ALPHA / DIGIT / "-"
+
+oid = 1*DIGIT *("." 1*DIGIT)
+
+attributeValue = string
+
+string = *( stringchar / pair )
+ / "#" hexstring
+ / QUOTATION *( quotechar / pair ) QUOTATION ; only from v2
+
+quotechar = <any character except "\" or QUOTATION >
+
+special = "," / "=" / "+" / "<" / ">" / "#" / ";"
+
+pair = "\" ( special / "\" / QUOTATION / hexpair )
+stringchar = <any character except one of special, "\" or QUOTATION >
+
+hexstring = 1*hexpair
+hexpair = hexchar hexchar
+
+hexchar = DIGIT / "A" / "B" / "C" / "D" / "E" / "F"
+ / "a" / "b" / "c" / "d" / "e" / "f"
+
+ALPHA = <any ASCII alphabetic character>
+ ; (decimal 65-90 and 97-122)
+DIGIT = <any ASCII decimal digit> ; (decimal 48-57)
+QUOTATION = <the ASCII double quotation mark character '"' decimal 34>
+
+
+
+
+
+
+
+
+Wahl, et. al. Proposed Standard [Page 5]
+
+RFC 2253 LADPv3 Distinguished Names December 1997
+
+
+4. Relationship with RFC 1779 and LDAPv2
+
+ The syntax given in this document is more restrictive than the syntax
+ in RFC 1779. Implementations parsing a string generated by an LDAPv2
+ client MUST accept the syntax of RFC 1779. Implementations MUST NOT,
+ however, generate any of the RFC 1779 encodings which are not
+ described above in section 2.
+
+ Implementations MUST allow a semicolon character to be used instead
+ of a comma to separate RDNs in a distinguished name, and MUST also
+ allow whitespace characters to be present on either side of the comma
+ or semicolon. The whitespace characters are ignored, and the
+ semicolon replaced with a comma.
+
+ Implementations MUST allow an oid in the attribute type to be
+ prefixed by one of the character strings "oid." or "OID.".
+
+ Implementations MUST allow for space (' ' ASCII 32) characters to be
+ present between name-component and ',', between attributeTypeAndValue
+ and '+', between attributeType and '=', and between '=' and
+ attributeValue. These space characters are ignored when parsing.
+
+ Implementations MUST allow a value to be surrounded by quote ('"'
+ ASCII 34) characters, which are not part of the value. Inside the
+ quoted value, the following characters can occur without any
+ escaping:
+
+ ",", "=", "+", "<", ">", "#" and ";"
+
+5. Examples
+
+ This notation is designed to be convenient for common forms of name.
+ This section gives a few examples of distinguished names written
+ using this notation. First is a name containing three relative
+ distinguished names (RDNs):
+
+ CN=Steve Kille,O=Isode Limited,C=GB
+
+ Here is an example name containing three RDNs, in which the first RDN
+ is multi-valued:
+
+ OU=Sales+CN=J. Smith,O=Widget Inc.,C=US
+
+ This example shows the method of quoting of a comma in an
+ organization name:
+
+ CN=L. Eagle,O=Sue\, Grabbit and Runn,C=GB
+
+
+
+
+Wahl, et. al. Proposed Standard [Page 6]
+
+RFC 2253 LADPv3 Distinguished Names December 1997
+
+
+ An example name in which a value contains a carriage return
+ character:
+
+ CN=Before\0DAfter,O=Test,C=GB
+
+ An example name in which an RDN was of an unrecognized type. The
+ value is the BER encoding of an OCTET STRING containing two bytes
+ 0x48 and 0x69.
+
+ 1.3.6.1.4.1.1466.0=#04024869,O=Test,C=GB
+
+ Finally, an example of an RDN surname value consisting of 5 letters:
+
+ Unicode Letter Description 10646 code UTF-8 Quoted
+ =============================== ========== ====== =======
+ LATIN CAPITAL LETTER L U0000004C 0x4C L
+ LATIN SMALL LETTER U U00000075 0x75 u
+ LATIN SMALL LETTER C WITH CARON U0000010D 0xC48D \C4\8D
+ LATIN SMALL LETTER I U00000069 0x69 i
+ LATIN SMALL LETTER C WITH ACUTE U00000107 0xC487 \C4\87
+
+ Could be written in printable ASCII (useful for debugging purposes):
+
+ SN=Lu\C4\8Di\C4\87
+
+6. References
+
+ [1] The Directory -- overview of concepts, models and services.
+ ITU-T Rec. X.500(1993).
+
+ [2] The Directory -- Models. ITU-T Rec. X.501(1993).
+
+ [3] Wahl, M., Howes, T., and S. Kille, "Lightweight Directory
+ Access Protocol (v3)", RFC 2251, December 1997.
+
+ [4] Wahl, M., Coulbeck, A., Howes, T. and S. Kille, "Lightweight
+ Directory Access Protocol (v3): Attribute Syntax Definitions",
+ RFC 2252, December 1997.
+
+ [5] Crocker, D., "Standard of the Format of ARPA-Internet Text
+ Messages", STD 11, RFC 822, August 1982.
+
+ [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+ Levels", RFC 2119.
+
+
+
+
+
+
+
+Wahl, et. al. Proposed Standard [Page 7]
+
+RFC 2253 LADPv3 Distinguished Names December 1997
+
+
+7. Security Considerations
+
+7.1. Disclosure
+
+ Distinguished Names typically consist of descriptive information
+ about the entries they name, which can be people, organizations,
+ devices or other real-world objects. This frequently includes some
+ of the following kinds of information:
+
+ - the common name of the object (i.e. a person's full name)
+ - an email or TCP/IP address
+ - its physical location (country, locality, city, street address)
+ - organizational attributes (such as department name or affiliation)
+
+ Most countries have privacy laws regarding the publication of
+ information about people.
+
+7.2. Use of Distinguished Names in Security Applications
+
+ The transformations of an AttributeValue value from its X.501 form to
+ an LDAP string representation are not always reversible back to the
+ same BER or DER form. An example of a situation which requires the
+ DER form of a distinguished name is the verification of an X.509
+ certificate.
+
+ For example, a distinguished name consisting of one RDN with one AVA,
+ in which the type is commonName and the value is of the TeletexString
+ choice with the letters 'Sam' would be represented in LDAP as the
+ string CN=Sam. Another distinguished name in which the value is
+ still 'Sam' but of the PrintableString choice would have the same
+ representation CN=Sam.
+
+ Applications which require the reconstruction of the DER form of the
+ value SHOULD NOT use the string representation of attribute syntaxes
+ when converting a distinguished name to the LDAP format. Instead,
+ they SHOULD use the hexadecimal form prefixed by the octothorpe ('#')
+ as described in the first paragraph of section 2.4.
+
+8. Authors' Addresses
+
+ Mark Wahl
+ Critical Angle Inc.
+ 4815 W. Braker Lane #502-385
+ Austin, TX 78759
+ USA
+
+ EMail: M.Wahl at critical-angle.com
+
+
+
+
+Wahl, et. al. Proposed Standard [Page 8]
+
+RFC 2253 LADPv3 Distinguished Names December 1997
+
+
+ Steve Kille
+ Isode Ltd.
+ The Dome
+ The Square
+ Richmond, Surrey
+ TW9 1DT
+ England
+
+ Phone: +44-181-332-9091
+ EMail: S.Kille at ISODE.COM
+
+
+ Tim Howes
+ Netscape Communications Corp.
+ 501 E. Middlefield Rd, MS MV068
+ Mountain View, CA 94043
+ USA
+
+ Phone: +1 650 937-3419
+ EMail: howes at netscape.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wahl, et. al. Proposed Standard [Page 9]
+
+RFC 2253 LADPv3 Distinguished Names December 1997
+
+
+9. Full Copyright Statement
+
+ Copyright (C) The Internet Society (1997). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wahl, et. al. Proposed Standard [Page 10]
+
Added: openldap/vendor/openldap-release/doc/rfc/rfc2254.txt
===================================================================
--- openldap/vendor/openldap-release/doc/rfc/rfc2254.txt (rev 0)
+++ openldap/vendor/openldap-release/doc/rfc/rfc2254.txt 2007-09-15 10:38:52 UTC (rev 844)
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+Network Working Group T. Howes
+Request for Comments: 2254 Netscape Communications Corp.
+Category: Standards Track December 1997
+
+
+ The String Representation of LDAP Search Filters
+
+1. Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (1997). All Rights Reserved.
+
+IESG Note
+
+ This document describes a directory access protocol that provides
+ both read and update access. Update access requires secure
+ authentication, but this document does not mandate implementation of
+ any satisfactory authentication mechanisms.
+
+ In accordance with RFC 2026, section 4.4.1, this specification is
+ being approved by IESG as a Proposed Standard despite this
+ limitation, for the following reasons:
+
+ a. to encourage implementation and interoperability testing of
+ these protocols (with or without update access) before they
+ are deployed, and
+
+ b. to encourage deployment and use of these protocols in read-only
+ applications. (e.g. applications where LDAPv3 is used as
+ a query language for directories which are updated by some
+ secure mechanism other than LDAP), and
+
+ c. to avoid delaying the advancement and deployment of other Internet
+ standards-track protocols which require the ability to query, but
+ not update, LDAPv3 directory servers.
+
+
+
+
+
+
+
+
+
+Howes Standards Track [Page 1]
+
+RFC 2254 String Representation of LDAP December 1997
+
+
+ Readers are hereby warned that until mandatory authentication
+ mechanisms are standardized, clients and servers written according to
+ this specification which make use of update functionality are
+ UNLIKELY TO INTEROPERATE, or MAY INTEROPERATE ONLY IF AUTHENTICATION
+ IS REDUCED TO AN UNACCEPTABLY WEAK LEVEL.
+
+ Implementors are hereby discouraged from deploying LDAPv3 clients or
+ servers which implement the update functionality, until a Proposed
+ Standard for mandatory authentication in LDAPv3 has been approved and
+ published as an RFC.
+
+2. Abstract
+
+ The Lightweight Directory Access Protocol (LDAP) [1] defines a
+ network representation of a search filter transmitted to an LDAP
+ server. Some applications may find it useful to have a common way of
+ representing these search filters in a human-readable form. This
+ document defines a human-readable string format for representing LDAP
+ search filters.
+
+ This document replaces RFC 1960, extending the string LDAP filter
+ definition to include support for LDAP version 3 extended match
+ filters, and including support for representing the full range of
+ possible LDAP search filters.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Howes Standards Track [Page 2]
+
+RFC 2254 String Representation of LDAP December 1997
+
+
+3. LDAP Search Filter Definition
+
+ An LDAPv3 search filter is defined in Section 4.5.1 of [1] as
+ follows:
+
+ Filter ::= CHOICE {
+ and [0] SET OF Filter,
+ or [1] SET OF Filter,
+ not [2] Filter,
+ equalityMatch [3] AttributeValueAssertion,
+ substrings [4] SubstringFilter,
+ greaterOrEqual [5] AttributeValueAssertion,
+ lessOrEqual [6] AttributeValueAssertion,
+ present [7] AttributeDescription,
+ approxMatch [8] AttributeValueAssertion,
+ extensibleMatch [9] MatchingRuleAssertion
+ }
+
+ SubstringFilter ::= SEQUENCE {
+ type AttributeDescription,
+ SEQUENCE OF CHOICE {
+ initial [0] LDAPString,
+ any [1] LDAPString,
+ final [2] LDAPString
+ }
+ }
+
+ AttributeValueAssertion ::= SEQUENCE {
+ attributeDesc AttributeDescription,
+ attributeValue AttributeValue
+ }
+
+ MatchingRuleAssertion ::= SEQUENCE {
+ matchingRule [1] MatchingRuleID OPTIONAL,
+ type [2] AttributeDescription OPTIONAL,
+ matchValue [3] AssertionValue,
+ dnAttributes [4] BOOLEAN DEFAULT FALSE
+ }
+
+ AttributeDescription ::= LDAPString
+
+ AttributeValue ::= OCTET STRING
+
+ MatchingRuleID ::= LDAPString
+
+ AssertionValue ::= OCTET STRING
+
+ LDAPString ::= OCTET STRING
+
+
+
+Howes Standards Track [Page 3]
+
+RFC 2254 String Representation of LDAP December 1997
+
+
+ where the LDAPString above is limited to the UTF-8 encoding of the
+ ISO 10646 character set [4]. The AttributeDescription is a string
+ representation of the attribute description and is defined in [1].
+ The AttributeValue and AssertionValue OCTET STRING have the form
+ defined in [2]. The Filter is encoded for transmission over a
+ network using the Basic Encoding Rules defined in [3], with
+ simplifications described in [1].
+
+4. String Search Filter Definition
+
+ The string representation of an LDAP search filter is defined by the
+ following grammar, following the ABNF notation defined in [5]. The
+ filter format uses a prefix notation.
+
+ filter = "(" filtercomp ")"
+ filtercomp = and / or / not / item
+ and = "&" filterlist
+ or = "|" filterlist
+ not = "!" filter
+ filterlist = 1*filter
+ item = simple / present / substring / extensible
+ simple = attr filtertype value
+ filtertype = equal / approx / greater / less
+ equal = "="
+ approx = "~="
+ greater = ">="
+ less = "<="
+ extensible = attr [":dn"] [":" matchingrule] ":=" value
+ / [":dn"] ":" matchingrule ":=" value
+ present = attr "=*"
+ substring = attr "=" [initial] any [final]
+ initial = value
+ any = "*" *(value "*")
+ final = value
+ attr = AttributeDescription from Section 4.1.5 of [1]
+ matchingrule = MatchingRuleId from Section 4.1.9 of [1]
+ value = AttributeValue from Section 4.1.6 of [1]
+
+ The attr, matchingrule, and value constructs are as described in the
+ corresponding section of [1] given above.
+
+
+
+
+
+
+
+
+
+
+
+Howes Standards Track [Page 4]
+
+RFC 2254 String Representation of LDAP December 1997
+
+
+ If a value should contain any of the following characters
+
+ Character ASCII value
+ ---------------------------
+ * 0x2a
+ ( 0x28
+ ) 0x29
+ \ 0x5c
+ NUL 0x00
+
+ the character must be encoded as the backslash '\' character (ASCII
+ 0x5c) followed by the two hexadecimal digits representing the ASCII
+ value of the encoded character. The case of the two hexadecimal
+ digits is not significant.
+
+ This simple escaping mechanism eliminates filter-parsing ambiguities
+ and allows any filter that can be represented in LDAP to be
+ represented as a NUL-terminated string. Other characters besides the
+ ones listed above may be escaped using this mechanism, for example,
+ non-printing characters.
+
+ For example, the filter checking whether the "cn" attribute contained
+ a value with the character "*" anywhere in it would be represented as
+ "(cn=*\2a*)".
+
+ Note that although both the substring and present productions in the
+ grammar above can produce the "attr=*" construct, this construct is
+ used only to denote a presence filter.
+
+5. Examples
+
+ This section gives a few examples of search filters written using
+ this notation.
+
+ (cn=Babs Jensen)
+ (!(cn=Tim Howes))
+ (&(objectClass=Person)(|(sn=Jensen)(cn=Babs J*)))
+ (o=univ*of*mich*)
+
+ The following examples illustrate the use of extensible matching.
+
+ (cn:1.2.3.4.5:=Fred Flintstone)
+ (sn:dn:2.4.6.8.10:=Barney Rubble)
+ (o:dn:=Ace Industry)
+ (:dn:2.4.6.8.10:=Dino)
+
+
+
+
+
+
+Howes Standards Track [Page 5]
+
+RFC 2254 String Representation of LDAP December 1997
+
+
+ The second example illustrates the use of the ":dn" notation to
+ indicate that matching rule "2.4.6.8.10" should be used when making
+ comparisons, and that the attributes of an entry's distinguished name
+ should be considered part of the entry when evaluating the match.
+
+ The third example denotes an equality match, except that DN
+ components should be considered part of the entry when doing the
+ match.
+
+ The fourth example is a filter that should be applied to any
+ attribute supporting the matching rule given (since the attr has been
+ left off). Attributes supporting the matching rule contained in the
+ DN should also be considered.
+
+ The following examples illustrate the use of the escaping mechanism.
+
+ (o=Parens R Us \28for all your parenthetical needs\29)
+ (cn=*\2A*)
+ (filename=C:\5cMyFile)
+ (bin=\00\00\00\04)
+ (sn=Lu\c4\8di\c4\87)
+
+ The first example shows the use of the escaping mechanism to
+ represent parenthesis characters. The second shows how to represent a
+ "*" in a value, preventing it from being interpreted as a substring
+ indicator. The third illustrates the escaping of the backslash
+ character.
+
+ The fourth example shows a filter searching for the four-byte value
+ 0x00000004, illustrating the use of the escaping mechanism to
+ represent arbitrary data, including NUL characters.
+
+ The final example illustrates the use of the escaping mechanism to
+ represent various non-ASCII UTF-8 characters.
+
+6. Security Considerations
+
+ This memo describes a string representation of LDAP search filters.
+ While the representation itself has no known security implications,
+ LDAP search filters do. They are interpreted by LDAP servers to
+ select entries from which data is retrieved. LDAP servers should
+ take care to protect the data they maintain from unauthorized access.
+
+
+
+
+
+
+
+
+
+Howes Standards Track [Page 6]
+
+RFC 2254 String Representation of LDAP December 1997
+
+
+7. References
+
+ [1] Wahl, M., Howes, T., and S. Kille, "Lightweight Directory Access
+ Protocol (v3)", RFC 2251, December 1997.
+
+ [2] Wahl, M., Coulbeck, A., Howes, T., and S. Kille, "Lightweight
+ Directory Access Protocol (v3): Attribute Syntax Definitions", RFC
+ 2252, December 1997.
+
+ [3] Specification of ASN.1 encoding rules: Basic, Canonical, and
+ Distinguished Encoding Rules, ITU-T Recommendation X.690, 1994.
+
+ [4] Yergeau, F., "UTF-8, a transformation format of Unicode and ISO
+ 10646", RFC 2044, October 1996.
+
+ [5] Crocker, D., "Standard for the Format of ARPA Internet Text
+ Messages", STD 11, RFC 822, August 1982.
+
+8. Author's Address
+
+ Tim Howes
+ Netscape Communications Corp.
+ 501 E. Middlefield Road
+ Mountain View, CA 94043
+ USA
+
+ Phone: +1 415 937-3419
+ EMail: howes at netscape.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Howes Standards Track [Page 7]
+
+RFC 2254 String Representation of LDAP December 1997
+
+
+9. Full Copyright Statement
+
+ Copyright (C) The Internet Society (1997). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Howes Standards Track [Page 8]
+
Added: openldap/vendor/openldap-release/doc/rfc/rfc2255.txt
===================================================================
--- openldap/vendor/openldap-release/doc/rfc/rfc2255.txt (rev 0)
+++ openldap/vendor/openldap-release/doc/rfc/rfc2255.txt 2007-09-15 10:38:52 UTC (rev 844)
@@ -0,0 +1,563 @@
+
+
+
+
+
+
+Network Working Group T. Howes
+Request for Comments: 2255 M. Smith
+Category: Standards Track Netscape Communications Corp.
+ December 1997
+
+
+ The LDAP URL Format
+
+1. Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (1997). All Rights Reserved.
+
+IESG NOTE
+
+ This document describes a directory access protocol that provides
+ both read and update access. Update access requires secure
+ authentication, but this document does not mandate implementation of
+ any satisfactory authentication mechanisms.
+
+ In accordance with RFC 2026, section 4.4.1, this specification is
+ being approved by IESG as a Proposed Standard despite this
+ limitation, for the following reasons:
+
+ a. to encourage implementation and interoperability testing of
+ these protocols (with or without update access) before they
+ are deployed, and
+
+ b. to encourage deployment and use of these protocols in read-only
+ applications. (e.g. applications where LDAPv3 is used as
+ a query language for directories which are updated by some
+ secure mechanism other than LDAP), and
+
+ c. to avoid delaying the advancement and deployment of other Internet
+ standards-track protocols which require the ability to query, but
+ not update, LDAPv3 directory servers.
+
+
+
+
+
+
+
+
+Howes & Smith Standards Track [Page 1]
+
+RFC 2255 LDAP URL Format December 1997
+
+
+ Readers are hereby warned that until mandatory authentication
+ mechanisms are standardized, clients and servers written according to
+ this specification which make use of update functionality are
+ UNLIKELY TO INTEROPERATE, or MAY INTEROPERATE ONLY IF AUTHENTICATION
+ IS REDUCED TO AN UNACCEPTABLY WEAK LEVEL.
+
+ Implementors are hereby discouraged from deploying LDAPv3 clients or
+ servers which implement the update functionality, until a Proposed
+ Standard for mandatory authentication in LDAPv3 has been approved and
+ published as an RFC.
+
+2. Abstract
+
+ LDAP is the Lightweight Directory Access Protocol, defined in [1],
+ [2] and [3]. This document describes a format for an LDAP Uniform
+ Resource Locator. The format describes an LDAP search operation to
+ perform to retrieve information from an LDAP directory. This document
+ replaces RFC 1959. It updates the LDAP URL format for version 3 of
+ LDAP and clarifies how LDAP URLs are resolved. This document also
+ defines an extension mechanism for LDAP URLs, so that future
+ documents can extend their functionality, for example, to provide
+ access to new LDAPv3 extensions as they are defined.
+
+ The key words "MUST", "MAY", and "SHOULD" used in this document are
+ to be interpreted as described in [6].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Howes & Smith Standards Track [Page 2]
+
+RFC 2255 LDAP URL Format December 1997
+
+
+3. URL Definition
+
+ An LDAP URL begins with the protocol prefix "ldap" and is defined by
+ the following grammar.
+
+ ldapurl = scheme "://" [hostport] ["/"
+ [dn ["?" [attributes] ["?" [scope]
+ ["?" [filter] ["?" extensions]]]]]]
+ scheme = "ldap"
+ attributes = attrdesc *("," attrdesc)
+ scope = "base" / "one" / "sub"
+ dn = distinguishedName from Section 3 of [1]
+ hostport = hostport from Section 5 of RFC 1738 [5]
+ attrdesc = AttributeDescription from Section 4.1.5 of [2]
+ filter = filter from Section 4 of [4]
+ extensions = extension *("," extension)
+ extension = ["!"] extype ["=" exvalue]
+ extype = token / xtoken
+ exvalue = LDAPString from section 4.1.2 of [2]
+ token = oid from section 4.1 of [3]
+ xtoken = ("X-" / "x-") token
+
+ The "ldap" prefix indicates an entry or entries residing in the LDAP
+ server running on the given hostname at the given portnumber. The
+ default LDAP port is TCP port 389. If no hostport is given, the
+ client must have some apriori knowledge of an appropriate LDAP server
+ to contact.
+
+ The dn is an LDAP Distinguished Name using the string format
+ described in [1]. It identifies the base object of the LDAP search.
+
+ ldapurl = scheme "://" [hostport] ["/"
+ [dn ["?" [attributes] ["?" [scope]
+ ["?" [filter] ["?" extensions]]]]]]
+ scheme = "ldap"
+ attributes = attrdesc *("," attrdesc)
+ scope = "base" / "one" / "sub"
+ dn = distinguishedName from Section 3 of [1]
+ hostport = hostport from Section 5 of RFC 1738 [5]
+ attrdesc = AttributeDescription from Section 4.1.5 of [2]
+ filter = filter from Section 4 of [4]
+ extensions = extension *("," extension)
+ extension = ["!"] extype ["=" exvalue]
+ extype = token / xtoken
+ exvalue = LDAPString from section 4.1.2 of [2]
+ token = oid from section 4.1 of [3]
+ xtoken = ("X-" / "x-") token
+
+
+
+
+Howes & Smith Standards Track [Page 3]
+
+RFC 2255 LDAP URL Format December 1997
+
+
+ The "ldap" prefix indicates an entry or entries residing in the LDAP
+ server running on the given hostname at the given portnumber. The
+ default LDAP port is TCP port 389. If no hostport is given, the
+ client must have some apriori knowledge of an appropriate LDAP server
+ to contact.
+
+ The dn is an LDAP Distinguished Name using the string format
+ described in [1]. It identifies the base object of the LDAP search.
+
+ The attributes construct is used to indicate which attributes should
+ be returned from the entry or entries. Individual attrdesc names are
+ as defined for AttributeDescription in [2]. If the attributes part
+ is omitted, all user attributes of the entry or entries should be
+ requested (e.g., by setting the attributes field
+ AttributeDescriptionList in the LDAP search request to a NULL list,
+ or (in LDAPv3) by requesting the special attribute name "*").
+
+ The scope construct is used to specify the scope of the search to
+ perform in the given LDAP server. The allowable scopes are "base"
+ for a base object search, "one" for a one-level search, or "sub" for
+ a subtree search. If scope is omitted, a scope of "base" is assumed.
+
+ The filter is used to specify the search filter to apply to entries
+ within the specified scope during the search. It has the format
+ specified in [4]. If filter is omitted, a filter of
+ "(objectClass=*)" is assumed.
+
+ The extensions construct provides the LDAP URL with an extensibility
+ mechanism, allowing the capabilities of the URL to be extended in the
+ future. Extensions are a simple comma-separated list of type=value
+ pairs, where the =value portion MAY be omitted for options not
+ requiring it. Each type=value pair is a separate extension. These
+ LDAP URL extensions are not necessarily related to any of the LDAPv3
+ extension mechanisms. Extensions may be supported or unsupported by
+ the client resolving the URL. An extension prefixed with a '!'
+ character (ASCII 33) is critical. An extension not prefixed with a '
+ !' character is non-critical.
+
+ If an extension is supported by the client, the client MUST obey the
+ extension if the extension is critical. The client SHOULD obey
+ supported extensions that are non-critical.
+
+ If an extension is unsupported by the client, the client MUST NOT
+ process the URL if the extension is critical. If an unsupported
+ extension is non-critical, the client MUST ignore the extension.
+
+
+
+
+
+
+Howes & Smith Standards Track [Page 4]
+
+RFC 2255 LDAP URL Format December 1997
+
+
+ If a critical extension cannot be processed successfully by the
+ client, the client MUST NOT process the URL. If a non-critical
+ extension cannot be processed successfully by the client, the client
+ SHOULD ignore the extension.
+
+ Extension types prefixed by "X-" or "x-" are reserved for use in
+ bilateral agreements between communicating parties. Other extension
+ types MUST be defined in this document, or in other standards-track
+ documents.
+
+ One LDAP URL extension is defined in this document in the next
+ section. Other documents or a future version of this document MAY
+ define other extensions.
+
+ Note that any URL-illegal characters (e.g., spaces), URL special
+ characters (as defined in section 2.2 of RFC 1738) and the reserved
+ character '?' (ASCII 63) occurring inside a dn, filter, or other
+ element of an LDAP URL MUST be escaped using the % method described
+ in RFC 1738 [5]. If a comma character ',' occurs inside an extension
+ value, the character MUST also be escaped using the % method.
+
+4. The Bindname Extension
+
+ This section defines an LDAP URL extension for representing the
+ distinguished name for a client to use when authenticating to an LDAP
+ directory during resolution of an LDAP URL. Clients MAY implement
+ this extension.
+
+ The extension type is "bindname". The extension value is the
+ distinguished name of the directory entry to authenticate as, in the
+ same form as described for dn in the grammar above. The dn may be the
+ NULL string to specify unauthenticated access. The extension may be
+ either critical (prefixed with a '!' character) or non-critical (not
+ prefixed with a '!' character).
+
+ If the bindname extension is critical, the client resolving the URL
+ MUST authenticate to the directory using the given distinguished name
+ and an appropriate authentication method. Note that for a NULL
+ distinguished name, no bind MAY be required to obtain anonymous
+ access to the directory. If the extension is non-critical, the client
+ MAY bind to the directory using the given distinguished name.
+
+5. URL Processing
+
+ This section describes how an LDAP URL SHOULD be resolved by a
+ client.
+
+
+
+
+
+Howes & Smith Standards Track [Page 5]
+
+RFC 2255 LDAP URL Format December 1997
+
+
+ First, the client obtains a connection to the LDAP server referenced
+ in the URL, or an LDAP server of the client's choice if no LDAP
+ server is explicitly referenced. This connection MAY be opened
+ specifically for the purpose of resolving the URL or the client MAY
+ reuse an already open connection. The connection MAY provide
+ confidentiality, integrity, or other services, e.g., using TLS. Use
+ of security services is at the client's discretion if not specified
+ in the URL.
+
+ Next, the client authenticates itself to the LDAP server. This step
+ is optional, unless the URL contains a critical bindname extension
+ with a non-NULL value. If a bindname extension is given, the client
+ proceeds according to the section above.
+
+ If a bindname extension is not specified, the client MAY bind to the
+ directory using a appropriate dn and authentication method of its own
+ choosing (including NULL authentication).
+
+ Next, the client performs the LDAP search operation specified in the
+ URL. Additional fields in the LDAP protocol search request, such as
+ sizelimit, timelimit, deref, and anything else not specified or
+ defaulted in the URL specification, MAY be set at the client's
+ discretion.
+
+ Once the search has completed, the client MAY close the connection to
+ the LDAP server, or the client MAY keep the connection open for
+ future use.
+
+6. Examples
+
+ The following are some example LDAP URLs using the format defined
+ above. The first example is an LDAP URL referring to the University
+ of Michigan entry, available from an LDAP server of the client's
+ choosing:
+
+ ldap:///o=University%20of%20Michigan,c=US
+
+ The next example is an LDAP URL referring to the University of
+ Michigan entry in a particular ldap server:
+
+ ldap://ldap.itd.umich.edu/o=University%20of%20Michigan,c=US
+
+ Both of these URLs correspond to a base object search of the
+ "o=University of Michigan, c=US" entry using a filter of
+ "(objectclass=*)", requesting all attributes.
+
+ The next example is an LDAP URL referring to only the postalAddress
+ attribute of the University of Michigan entry:
+
+
+
+Howes & Smith Standards Track [Page 6]
+
+RFC 2255 LDAP URL Format December 1997
+
+
+ ldap://ldap.itd.umich.edu/o=University%20of%20Michigan,
+ c=US?postalAddress
+
+ The corresponding LDAP search operation is the same as in the
+ previous example, except that only the postalAddress attribute is
+ requested.
+
+ The next example is an LDAP URL referring to the set of entries found
+ by querying the given LDAP server on port 6666 and doing a subtree
+ search of the University of Michigan for any entry with a common name
+ of "Babs Jensen", retrieving all attributes:
+
+ ldap://host.com:6666/o=University%20of%20Michigan,
+ c=US??sub?(cn=Babs%20Jensen)
+
+ The next example is an LDAP URL referring to all children of the c=GB
+ entry:
+
+ ldap://ldap.itd.umich.edu/c=GB?objectClass?one
+
+ The objectClass attribute is requested to be returned along with the
+ entries, and the default filter of "(objectclass=*)" is used.
+
+ The next example is an LDAP URL to retrieve the mail attribute for
+ the LDAP entry named "o=Question?,c=US" is given below, illustrating
+ the use of the escaping mechanism on the reserved character '?'.
+
+ ldap://ldap.question.com/o=Question%3f,c=US?mail
+
+ The next example illustrates the interaction between LDAP and URL
+ quoting mechanisms.
+
+ ldap://ldap.netscape.com/o=Babsco,c=US??(int=%5c00%5c00%5c00%5c04)
+
+ The filter in this example uses the LDAP escaping mechanism of \ to
+ encode three zero or null bytes in the value. In LDAP, the filter
+ would be written as (int=\00\00\00\04). Because the \ character must
+ be escaped in a URL, the \'s are escaped as %5c in the URL encoding.
+
+ The final example shows the use of the bindname extension to specify
+ the dn a client should use for authentication when resolving the URL.
+
+ ldap:///??sub??bindname=cn=Manager%2co=Foo
+ ldap:///??sub??!bindname=cn=Manager%2co=Foo
+
+ The two URLs are the same, except that the second one marks the
+ bindname extension as critical. Notice the use of the % encoding
+ method to encode the comma in the distinguished name value in the
+
+
+
+Howes & Smith Standards Track [Page 7]
+
+RFC 2255 LDAP URL Format December 1997
+
+
+ bindname extension.
+
+7. Security Considerations
+
+ General URL security considerations discussed in [5] are relevant for
+ LDAP URLs.
+
+ The use of security mechanisms when processing LDAP URLs requires
+ particular care, since clients may encounter many different servers
+ via URLs, and since URLs are likely to be processed automatically,
+ without user intervention. A client SHOULD have a user-configurable
+ policy about which servers to connect to using which security
+ mechanisms, and SHOULD NOT make connections that are inconsistent
+ with this policy.
+
+ Sending authentication information, no matter the mechanism, may
+ violate a user's privacy requirements. In the absence of specific
+ policy permitting authentication information to be sent to a server,
+ a client should use an anonymous connection. (Note that clients
+ conforming to previous LDAP URL specifications, where all connections
+ are anonymous and unprotected, are consistent with this
+ specification; they simply have the default security policy.)
+
+ Some authentication methods, in particular reusable passwords sent to
+ the server, may reveal easily-abused information to the remote server
+ or to eavesdroppers in transit, and should not be used in URL
+ processing unless explicitly permitted by policy. Confirmation by
+ the human user of the use of authentication information is
+ appropriate in many circumstances. Use of strong authentication
+ methods that do not reveal sensitive information is much preferred.
+
+ The LDAP URL format allows the specification of an arbitrary LDAP
+ search operation to be performed when evaluating the LDAP URL.
+ Following an LDAP URL may cause unexpected results, for example, the
+ retrieval of large amounts of data, the initiation of a long-lived
+ search, etc. The security implications of resolving an LDAP URL are
+ the same as those of resolving an LDAP search query.
+
+8. Acknowledgements
+
+ The LDAP URL format was originally defined at the University of
+ Michigan. This material is based upon work supported by the National
+ Science Foundation under Grant No. NCR-9416667. The support of both
+ the University of Michigan and the National Science Foundation is
+ gratefully acknowledged.
+
+
+
+
+
+
+Howes & Smith Standards Track [Page 8]
+
+RFC 2255 LDAP URL Format December 1997
+
+
+ Several people have made valuable comments on this document. In
+ particular RL "Bob" Morgan and Mark Wahl deserve special thanks for
+ their contributions.
+
+9. References
+
+ [1] Wahl, M., Kille, S., and T. Howes, "Lightweight Directory Access
+ Protocol (v3): UTF-8 String Representation of Distinguished Names",
+ RFC 2253, December 1997.
+
+ [2] Wahl, M., Howes, T., and S. Kille, "Lightweight Directory Access
+ Protocol (v3)", RFC 2251, December 1997.
+
+ [3] Wahl, M., Coulbeck, A., Howes, T. and S. Kille, "Lightweight
+ Directory Access Protocol (v3): Attribute Syntax Definitions", RFC
+ 2252, December 1997.
+
+ [4] Howes, T., "A String Representation of LDAP Search Filters", RFC
+ 2254, December 1997.
+
+ [5] Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform Resource
+ Locators (URL)," RFC 1738, December 1994.
+
+ [6] Bradner, S., "Key Words for use in RFCs to Indicate Requirement
+ Levels," RFC 2119, March 1997.
+
+Authors' Addresses
+
+ Tim Howes
+ Netscape Communications Corp.
+ 501 E. Middlefield Rd.
+ Mountain View, CA 94043
+ USA
+
+ Phone: +1 415 937-3419
+ EMail: howes at netscape.com
+
+
+ Mark Smith
+ Netscape Communications Corp.
+ 501 E. Middlefield Rd.
+ Mountain View, CA 94043
+ USA
+
+ Phone: +1 415 937-3477
+ EMail: mcs at netscape.com
+
+
+
+
+
+Howes & Smith Standards Track [Page 9]
+
+RFC 2255 LDAP URL Format December 1997
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (1997). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Howes & Smith Standards Track [Page 10]
+
Added: openldap/vendor/openldap-release/doc/rfc/rfc2256.txt
===================================================================
--- openldap/vendor/openldap-release/doc/rfc/rfc2256.txt (rev 0)
+++ openldap/vendor/openldap-release/doc/rfc/rfc2256.txt 2007-09-15 10:38:52 UTC (rev 844)
@@ -0,0 +1,1123 @@
+
+
+
+
+
+
+Network Working Group M. Wahl
+Request for Comments: 2256 Critical Angle Inc.
+Category: Standards Track December 1997
+
+
+ A Summary of the X.500(96) User Schema for use with LDAPv3
+
+1. Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (1997). All Rights Reserved.
+
+IESG Note
+
+ This document describes a directory access protocol that provides
+ both read and update access. Update access requires secure
+ authentication, but this document does not mandate implementation of
+ any satisfactory authentication mechanisms.
+
+ In accordance with RFC 2026, section 4.4.1, this specification is
+ being approved by IESG as a Proposed Standard despite this
+ limitation, for the following reasons:
+
+ a. to encourage implementation and interoperability testing of
+ these protocols (with or without update access) before they
+ are deployed, and
+
+ b. to encourage deployment and use of these protocols in read-only
+ applications. (e.g. applications where LDAPv3 is used as
+ a query language for directories which are updated by some
+ secure mechanism other than LDAP), and
+
+ c. to avoid delaying the advancement and deployment of other Internet
+ standards-track protocols which require the ability to query, but
+ not update, LDAPv3 directory servers.
+
+ Readers are hereby warned that until mandatory authentication
+ mechanisms are standardized, clients and servers written according to
+ this specification which make use of update functionality are
+ UNLIKELY TO INTEROPERATE, or MAY INTEROPERATE ONLY IF AUTHENTICATION
+ IS REDUCED TO AN UNACCEPTABLY WEAK LEVEL.
+
+
+
+Wahl Standards Track [Page 1]
+
+RFC 2256 LDAPv3 Schema December 1997
+
+
+ Implementors are hereby discouraged from deploying LDAPv3 clients or
+ servers which implement the update functionality, until a Proposed
+ Standard for mandatory authentication in LDAPv3 has been approved and
+ published as an RFC.
+
+2. Abstract
+
+ This document provides an overview of the attribute types and object
+ classes defined by the ISO and ITU-T committees in the X.500
+ documents, in particular those intended for use by directory clients.
+ This is the most widely used schema for LDAP/X.500 directories, and
+ many other schema definitions for white pages objects use it as a
+ basis. This document does not cover attributes used for the
+ administration of X.500 directory servers, nor does it include
+ attributes defined by other ISO/ITU-T documents.
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in RFC 2119 [6].
+
+3. General Issues
+
+ This document references syntaxes given in section 6 of this document
+ and section 6 of [1]. Matching rules are listed in section 8 of this
+ document and section 8 of [1].
+
+ The attribute type and object class definitions are written using the
+ BNF form of AttributeTypeDescription and ObjectClassDescription given
+ in [1]. Lines have been folded for readability.
+
+4. Source
+
+ The schema definitions in this document are based on those found in
+ X.500 [2],[3],[4],[5], and updates to these documents, specifically:
+
+ Sections Source
+ ============ ============
+ 5.1 - 5.2 X.501(93)
+ 5.3 - 5.36 X.520(88)
+ 5.37 - 5.41 X.509(93)
+ 5.42 - 5.52 X.520(93)
+ 5.53 - 5.54 X.509(96)
+ 5.55 X.520(96)
+ 6.1 RFC 1274
+ 6.2 (new syntax)
+ 6.3 - 6.6 RFC 1274
+ 7.1 - 7.2 X.501(93)
+ 7.3 - 7.18 X.521(93)
+
+
+
+Wahl Standards Track [Page 2]
+
+RFC 2256 LDAPv3 Schema December 1997
+
+
+ 7.19 - 7.21 X.509(96)
+ 7.22 X.521(96)
+
+ Some attribute names are different from those found in X.520(93).
+
+ Three new attributes supportedAlgorithms, deltaRevocationList and
+ dmdName, and the objectClass dmd, are defined in the X.500(96)
+ documents.
+
+5. Attribute Types
+
+ An LDAP server implementation SHOULD recognize the attribute types
+ described in this section.
+
+5.1. objectClass
+
+ The values of the objectClass attribute describe the kind of object
+ which an entry represents. The objectClass attribute is present in
+ every entry, with at least two values. One of the values is either
+ "top" or "alias".
+
+ ( 2.5.4.0 NAME 'objectClass' EQUALITY objectIdentifierMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
+
+5.2. aliasedObjectName
+
+ The aliasedObjectName attribute is used by the directory service if
+ the entry containing this attribute is an alias.
+
+ ( 2.5.4.1 NAME 'aliasedObjectName' EQUALITY distinguishedNameMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE )
+
+5.3. knowledgeInformation
+
+ This attribute is no longer used.
+
+ ( 2.5.4.2 NAME 'knowledgeInformation' EQUALITY caseIgnoreMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} )
+
+5.4. cn
+
+ This is the X.500 commonName attribute, which contains a name of an
+ object. If the object corresponds to a person, it is typically the
+ person's full name.
+
+ ( 2.5.4.3 NAME 'cn' SUP name )
+
+
+
+
+
+Wahl Standards Track [Page 3]
+
+RFC 2256 LDAPv3 Schema December 1997
+
+
+5.5. sn
+
+ This is the X.500 surname attribute, which contains the family name
+ of a person.
+
+ ( 2.5.4.4 NAME 'sn' SUP name )
+
+5.6. serialNumber
+
+ This attribute contains the serial number of a device.
+
+ ( 2.5.4.5 NAME 'serialNumber' EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.44{64} )
+
+5.7. c
+
+ This attribute contains a two-letter ISO 3166 country code
+ (countryName).
+
+ ( 2.5.4.6 NAME 'c' SUP name SINGLE-VALUE )
+
+5.8. l
+
+ This attribute contains the name of a locality, such as a city,
+ county or other geographic region (localityName).
+
+ ( 2.5.4.7 NAME 'l' SUP name )
+
+5.9. st
+
+ This attribute contains the full name of a state or province
+ (stateOrProvinceName).
+
+ ( 2.5.4.8 NAME 'st' SUP name )
+
+5.10. street
+
+ This attribute contains the physical address of the object to which
+ the entry corresponds, such as an address for package delivery
+ (streetAddress).
+
+ ( 2.5.4.9 NAME 'street' EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{128} )
+
+
+
+
+
+
+Wahl Standards Track [Page 4]
+
+RFC 2256 LDAPv3 Schema December 1997
+
+
+5.11. o
+
+ This attribute contains the name of an organization
+ (organizationName).
+
+ ( 2.5.4.10 NAME 'o' SUP name )
+
+5.12. ou
+
+ This attribute contains the name of an organizational unit
+ (organizationalUnitName).
+
+ ( 2.5.4.11 NAME 'ou' SUP name )
+
+5.13. title
+
+ This attribute contains the title, such as "Vice President", of a
+ person in their organizational context. The "personalTitle"
+ attribute would be used for a person's title independent of their job
+ function.
+
+ ( 2.5.4.12 NAME 'title' SUP name )
+
+5.14. description
+
+ This attribute contains a human-readable description of the object.
+
+ ( 2.5.4.13 NAME 'description' EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{1024} )
+
+5.15. searchGuide
+
+ This attribute is for use by X.500 clients in constructing search
+ filters. It is obsoleted by enhancedSearchGuide, described below in
+ 5.48.
+
+ ( 2.5.4.14 NAME 'searchGuide'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.25 )
+
+5.16. businessCategory
+
+ This attribute describes the kind of business performed by an
+ organization.
+
+ ( 2.5.4.15 NAME 'businessCategory' EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{128} )
+
+
+
+Wahl Standards Track [Page 5]
+
+RFC 2256 LDAPv3 Schema December 1997
+
+
+5.17. postalAddress
+
+ ( 2.5.4.16 NAME 'postalAddress' EQUALITY caseIgnoreListMatch
+ SUBSTR caseIgnoreListSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 )
+
+5.18. postalCode
+
+ ( 2.5.4.17 NAME 'postalCode' EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{40} )
+
+5.19. postOfficeBox
+
+ ( 2.5.4.18 NAME 'postOfficeBox' EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{40} )
+
+5.20. physicalDeliveryOfficeName
+
+ ( 2.5.4.19 NAME 'physicalDeliveryOfficeName' EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{128} )
+
+5.21. telephoneNumber
+
+ ( 2.5.4.20 NAME 'telephoneNumber' EQUALITY telephoneNumberMatch
+ SUBSTR telephoneNumberSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.50{32} )
+
+5.22. telexNumber
+
+ ( 2.5.4.21 NAME 'telexNumber'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.52 )
+
+5.23. teletexTerminalIdentifier
+
+ ( 2.5.4.22 NAME 'teletexTerminalIdentifier'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.51 )
+
+5.24. facsimileTelephoneNumber
+
+ ( 2.5.4.23 NAME 'facsimileTelephoneNumber'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.22 )
+
+
+
+
+
+
+
+Wahl Standards Track [Page 6]
+
+RFC 2256 LDAPv3 Schema December 1997
+
+
+5.25. x121Address
+
+ ( 2.5.4.24 NAME 'x121Address' EQUALITY numericStringMatch
+ SUBSTR numericStringSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.36{15} )
+
+5.26. internationaliSDNNumber
+
+ ( 2.5.4.25 NAME 'internationaliSDNNumber' EQUALITY numericStringMatch
+ SUBSTR numericStringSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.36{16} )
+
+5.27. registeredAddress
+
+ This attribute holds a postal address suitable for reception of
+ telegrams or expedited documents, where it is necessary to have the
+ recipient accept delivery.
+
+ ( 2.5.4.26 NAME 'registeredAddress' SUP postalAddress
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 )
+
+5.28. destinationIndicator
+
+ This attribute is used for the telegram service.
+
+ ( 2.5.4.27 NAME 'destinationIndicator' EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.44{128} )
+
+5.29. preferredDeliveryMethod
+
+ ( 2.5.4.28 NAME 'preferredDeliveryMethod'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.14
+ SINGLE-VALUE )
+
+5.30. presentationAddress
+
+ This attribute contains an OSI presentation address.
+
+ ( 2.5.4.29 NAME 'presentationAddress'
+ EQUALITY presentationAddressMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.43
+ SINGLE-VALUE )
+
+
+
+
+
+
+
+
+Wahl Standards Track [Page 7]
+
+RFC 2256 LDAPv3 Schema December 1997
+
+
+5.31. supportedApplicationContext
+
+ This attribute contains the identifiers of OSI application contexts.
+
+ ( 2.5.4.30 NAME 'supportedApplicationContext'
+ EQUALITY objectIdentifierMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
+
+5.32. member
+
+ ( 2.5.4.31 NAME 'member' SUP distinguishedName )
+
+5.33. owner
+
+ ( 2.5.4.32 NAME 'owner' SUP distinguishedName )
+
+5.34. roleOccupant
+
+ ( 2.5.4.33 NAME 'roleOccupant' SUP distinguishedName )
+
+5.35. seeAlso
+
+ ( 2.5.4.34 NAME 'seeAlso' SUP distinguishedName )
+
+5.36. userPassword
+
+ ( 2.5.4.35 NAME 'userPassword' EQUALITY octetStringMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.40{128} )
+
+ Passwords are stored using an Octet String syntax and are not
+ encrypted. Transfer of cleartext passwords are strongly discouraged
+ where the underlying transport service cannot guarantee
+ confidentiality and may result in disclosure of the password to
+ unauthorized parties.
+
+5.37. userCertificate
+
+ This attribute is to be stored and requested in the binary form, as
+ 'userCertificate;binary'.
+
+ ( 2.5.4.36 NAME 'userCertificate'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.8 )
+
+5.38. cACertificate
+
+ This attribute is to be stored and requested in the binary form, as
+ 'cACertificate;binary'.
+
+
+
+
+Wahl Standards Track [Page 8]
+
+RFC 2256 LDAPv3 Schema December 1997
+
+
+ ( 2.5.4.37 NAME 'cACertificate'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.8 )
+
+5.39. authorityRevocationList
+
+ This attribute is to be stored and requested in the binary form, as
+ 'authorityRevocationList;binary'.
+
+ ( 2.5.4.38 NAME 'authorityRevocationList'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.9 )
+
+5.40. certificateRevocationList
+
+ This attribute is to be stored and requested in the binary form, as
+ 'certificateRevocationList;binary'.
+
+ ( 2.5.4.39 NAME 'certificateRevocationList'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.9 )
+
+5.41. crossCertificatePair
+
+ This attribute is to be stored and requested in the binary form, as
+ 'crossCertificatePair;binary'.
+
+ ( 2.5.4.40 NAME 'crossCertificatePair'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.10 )
+
+5.42. name
+
+ The name attribute type is the attribute supertype from which string
+ attribute types typically used for naming may be formed. It is
+ unlikely that values of this type itself will occur in an entry. LDAP
+ server implementations which do not support attribute subtyping need
+ not recognize this attribute in requests. Client implementations
+ MUST NOT assume that LDAP servers are capable of performing attribute
+ subtyping.
+
+ ( 2.5.4.41 NAME 'name' EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} )
+
+5.43. givenName
+
+ The givenName attribute is used to hold the part of a person's name
+ which is not their surname nor middle name.
+
+ ( 2.5.4.42 NAME 'givenName' SUP name )
+
+
+
+
+Wahl Standards Track [Page 9]
+
+RFC 2256 LDAPv3 Schema December 1997
+
+
+5.44. initials
+
+ The initials attribute contains the initials of some or all of an
+ individuals names, but not the surname(s).
+
+ ( 2.5.4.43 NAME 'initials' SUP name )
+
+5.45. generationQualifier
+
+ The generationQualifier attribute contains the part of the name which
+ typically is the suffix, as in "IIIrd".
+
+ ( 2.5.4.44 NAME 'generationQualifier' SUP name )
+
+5.46. x500UniqueIdentifier
+
+ The x500UniqueIdentifier attribute is used to distinguish between
+ objects when a distinguished name has been reused. This is a
+ different attribute type from both the "uid" and "uniqueIdentifier"
+ types.
+
+ ( 2.5.4.45 NAME 'x500UniqueIdentifier' EQUALITY bitStringMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 )
+
+5.47. dnQualifier
+
+ The dnQualifier attribute type specifies disambiguating information
+ to add to the relative distinguished name of an entry. It is
+ intended for use when merging data from multiple sources in order to
+ prevent conflicts between entries which would otherwise have the same
+ name. It is recommended that the value of the dnQualifier attribute
+ be the same for all entries from a particular source.
+
+ ( 2.5.4.46 NAME 'dnQualifier' EQUALITY caseIgnoreMatch
+ ORDERING caseIgnoreOrderingMatch SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 )
+
+5.48. enhancedSearchGuide
+
+ This attribute is for use by X.500 clients in constructing search
+ filters.
+
+ ( 2.5.4.47 NAME 'enhancedSearchGuide'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.21 )
+
+
+
+
+
+
+
+Wahl Standards Track [Page 10]
+
+RFC 2256 LDAPv3 Schema December 1997
+
+
+5.49. protocolInformation
+
+ This attribute is used in conjunction with the presentationAddress
+ attribute, to provide additional information to the OSI network
+ service.
+
+ ( 2.5.4.48 NAME 'protocolInformation'
+ EQUALITY protocolInformationMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.42 )
+
+5.50. distinguishedName
+
+ This attribute type is not used as the name of the object itself, but
+ it is instead a base type from which attributes with DN syntax
+ inherit.
+
+ It is unlikely that values of this type itself will occur in an
+ entry. LDAP server implementations which do not support attribute
+ subtyping need not recognize this attribute in requests. Client
+ implementations MUST NOT assume that LDAP servers are capable of
+ performing attribute subtyping.
+
+ ( 2.5.4.49 NAME 'distinguishedName' EQUALITY distinguishedNameMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
+
+5.51. uniqueMember
+
+ ( 2.5.4.50 NAME 'uniqueMember' EQUALITY uniqueMemberMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.34 )
+
+5.52. houseIdentifier
+
+ This attribute is used to identify a building within a location.
+
+ ( 2.5.4.51 NAME 'houseIdentifier' EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} )
+
+5.53. supportedAlgorithms
+
+ This attribute is to be stored and requested in the binary form, as
+ 'supportedAlgorithms;binary'.
+
+ ( 2.5.4.52 NAME 'supportedAlgorithms'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.49 )
+
+
+
+
+
+
+Wahl Standards Track [Page 11]
+
+RFC 2256 LDAPv3 Schema December 1997
+
+
+5.54. deltaRevocationList
+
+ This attribute is to be stored and requested in the binary form, as
+ 'deltaRevocationList;binary'.
+
+ ( 2.5.4.53 NAME 'deltaRevocationList'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.9 )
+
+5.55. dmdName
+
+ The value of this attribute specifies a directory management domain
+ (DMD), the administrative authority which operates the directory
+ server.
+
+ ( 2.5.4.54 NAME 'dmdName' SUP name )
+
+6. Syntaxes
+
+ Servers SHOULD recognize the syntaxes defined in this section. Each
+ syntax begins with a sample value of the ldapSyntaxes attribute which
+ defines the OBJECT IDENTIFIER of the syntax. The descriptions of
+ syntax names are not carried in protocol, and are not guaranteed to
+ be unique.
+
+6.1. Delivery Method
+
+ ( 1.3.6.1.4.1.1466.115.121.1.14 DESC 'Delivery Method' )
+
+ Values in this syntax are encoded according to the following BNF:
+
+ delivery-value = pdm / ( pdm whsp "$" whsp delivery-value )
+
+ pdm = "any" / "mhs" / "physical" / "telex" / "teletex" /
+ "g3fax" / "g4fax" / "ia5" / "videotex" / "telephone"
+
+ Example:
+
+ telephone
+
+6.2. Enhanced Guide
+
+ ( 1.3.6.1.4.1.1466.115.121.1.21 DESC 'Enhanced Guide' )
+
+ Values in this syntax are encoded according to the following BNF:
+
+ EnhancedGuide = woid whsp "#" whsp criteria whsp "#" whsp subset
+
+ subset = "baseobject" / "oneLevel" / "wholeSubtree"
+
+
+
+Wahl Standards Track [Page 12]
+
+RFC 2256 LDAPv3 Schema December 1997
+
+
+ The criteria production is defined in the Guide syntax below. This
+ syntax has been added subsequent to RFC 1778.
+
+ Example:
+
+ person#(sn)#oneLevel
+
+6.3. Guide
+
+ ( 1.3.6.1.4.1.1466.115.121.1.25 DESC 'Guide' )
+
+ Values in this syntax are encoded according to the following BNF:
+
+ guide-value = [ object-class "#" ] criteria
+
+ object-class = woid
+
+ criteria = criteria-item / criteria-set / ( "!" criteria )
+
+ criteria-set = ( [ "(" ] criteria "&" criteria-set [ ")" ] ) /
+ ( [ "(" ] criteria "|" criteria-set [ ")" ] )
+
+ criteria-item = [ "(" ] attributetype "$" match-type [ ")" ]
+
+ match-type = "EQ" / "SUBSTR" / "GE" / "LE" / "APPROX"
+
+ This syntax should not be used for defining new attributes.
+
+6.4. Octet String
+
+ ( 1.3.6.1.4.1.1466.115.121.1.40 DESC 'Octet String' )
+
+ Values in this syntax are encoded as octet strings.
+
+
+ Example:
+
+ secret
+
+6.5. Teletex Terminal Identifier
+
+ ( 1.3.6.1.4.1.1466.115.121.1.51 DESC 'Teletex Terminal Identifier' )
+
+ Values in this syntax are encoded according to the following BNF:
+
+ teletex-id = ttx-term 0*("$" ttx-param)
+
+ ttx-term = printablestring
+
+
+
+Wahl Standards Track [Page 13]
+
+RFC 2256 LDAPv3 Schema December 1997
+
+
+ ttx-param = ttx-key ":" ttx-value
+
+ ttx-key = "graphic" / "control" / "misc" / "page" / "private"
+
+ ttx-value = octetstring
+
+ In the above, the first printablestring is the encoding of the first
+ portion of the teletex terminal identifier to be encoded, and the
+ subsequent 0 or more octetstrings are subsequent portions of the
+ teletex terminal identifier.
+
+6.6. Telex Number
+
+ ( 1.3.6.1.4.1.1466.115.121.1.52 DESC 'Telex Number' )
+
+ Values in this syntax are encoded according to the following BNF:
+
+ telex-number = actual-number "$" country "$" answerback
+
+ actual-number = printablestring
+
+ country = printablestring
+
+ answerback = printablestring
+
+ In the above, actual-number is the syntactic representation of the
+ number portion of the TELEX number being encoded, country is the
+ TELEX country code, and answerback is the answerback code of a TELEX
+ terminal.
+
+6.7. Supported Algorithm
+
+ ( 1.3.6.1.4.1.1466.115.121.1.49 DESC 'Supported Algorithm' )
+
+ No printable representation of values of the supportedAlgorithms
+ attribute is defined in this document. Clients which wish to store
+ and retrieve this attribute MUST use "supportedAlgorithms;binary", in
+ which the value is transferred as a binary encoding.
+
+7. Object Classes
+
+ LDAP servers MUST recognize the object classes "top" and "subschema".
+ LDAP servers SHOULD recognize all the other object classes listed
+ here as values of the objectClass attribute.
+
+7.1. top
+
+ ( 2.5.6.0 NAME 'top' ABSTRACT MUST objectClass )
+
+
+
+Wahl Standards Track [Page 14]
+
+RFC 2256 LDAPv3 Schema December 1997
+
+
+7.2. alias
+
+ ( 2.5.6.1 NAME 'alias' SUP top STRUCTURAL MUST aliasedObjectName )
+
+7.3. country
+
+ ( 2.5.6.2 NAME 'country' SUP top STRUCTURAL MUST c
+ MAY ( searchGuide $ description ) )
+
+7.4. locality
+
+ ( 2.5.6.3 NAME 'locality' SUP top STRUCTURAL
+ MAY ( street $ seeAlso $ searchGuide $ st $ l $ description ) )
+
+7.5. organization
+
+ ( 2.5.6.4 NAME 'organization' SUP top STRUCTURAL MUST o
+ MAY ( userPassword $ searchGuide $ seeAlso $ businessCategory $
+ x121Address $ registeredAddress $ destinationIndicator $
+ preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $
+ telephoneNumber $ internationaliSDNNumber $
+ facsimileTelephoneNumber $
+ street $ postOfficeBox $ postalCode $ postalAddress $
+ physicalDeliveryOfficeName $ st $ l $ description ) )
+
+7.6. organizationalUnit
+
+ ( 2.5.6.5 NAME 'organizationalUnit' SUP top STRUCTURAL MUST ou
+ MAY ( userPassword $ searchGuide $ seeAlso $ businessCategory $
+ x121Address $ registeredAddress $ destinationIndicator $
+ preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $
+ telephoneNumber $ internationaliSDNNumber $
+ facsimileTelephoneNumber $
+ street $ postOfficeBox $ postalCode $ postalAddress $
+ physicalDeliveryOfficeName $ st $ l $ description ) )
+
+7.7. person
+
+ ( 2.5.6.6 NAME 'person' SUP top STRUCTURAL MUST ( sn $ cn )
+ MAY ( userPassword $ telephoneNumber $ seeAlso $ description ) )
+
+7.8. organizationalPerson
+
+ ( 2.5.6.7 NAME 'organizationalPerson' SUP person STRUCTURAL
+ MAY ( title $ x121Address $ registeredAddress $
+ destinationIndicator $
+ preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $
+ telephoneNumber $ internationaliSDNNumber $
+
+
+
+Wahl Standards Track [Page 15]
+
+RFC 2256 LDAPv3 Schema December 1997
+
+
+ facsimileTelephoneNumber $
+ street $ postOfficeBox $ postalCode $ postalAddress $
+ physicalDeliveryOfficeName $ ou $ st $ l ) )
+
+7.9. organizationalRole
+
+ ( 2.5.6.8 NAME 'organizationalRole' SUP top STRUCTURAL MUST cn
+ MAY ( x121Address $ registeredAddress $ destinationIndicator $
+ preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $
+ telephoneNumber $ internationaliSDNNumber $
+ facsimileTelephoneNumber $
+ seeAlso $ roleOccupant $ preferredDeliveryMethod $ street $
+ postOfficeBox $ postalCode $ postalAddress $
+ physicalDeliveryOfficeName $ ou $ st $ l $ description ) )
+
+7.10. groupOfNames
+
+ ( 2.5.6.9 NAME 'groupOfNames' SUP top STRUCTURAL MUST ( member $ cn )
+ MAY ( businessCategory $ seeAlso $ owner $ ou $ o $ description ) )
+
+7.11. residentialPerson
+
+ ( 2.5.6.10 NAME 'residentialPerson' SUP person STRUCTURAL MUST l
+ MAY ( businessCategory $ x121Address $ registeredAddress $
+ destinationIndicator $ preferredDeliveryMethod $ telexNumber $
+ teletexTerminalIdentifier $ telephoneNumber $
+ internationaliSDNNumber $
+ facsimileTelephoneNumber $ preferredDeliveryMethod $ street $
+ postOfficeBox $ postalCode $ postalAddress $
+ physicalDeliveryOfficeName $ st $ l ) )
+
+7.12. applicationProcess
+
+ ( 2.5.6.11 NAME 'applicationProcess' SUP top STRUCTURAL MUST cn
+ MAY ( seeAlso $ ou $ l $ description ) )
+
+7.13. applicationEntity
+
+ ( 2.5.6.12 NAME 'applicationEntity' SUP top STRUCTURAL
+ MUST ( presentationAddress $ cn )
+ MAY ( supportedApplicationContext $ seeAlso $ ou $ o $ l $
+ description ) )
+
+7.14. dSA
+
+ ( 2.5.6.13 NAME 'dSA' SUP applicationEntity STRUCTURAL
+ MAY knowledgeInformation )
+
+
+
+
+Wahl Standards Track [Page 16]
+
+RFC 2256 LDAPv3 Schema December 1997
+
+
+7.15. device
+
+ ( 2.5.6.14 NAME 'device' SUP top STRUCTURAL MUST cn
+ MAY ( serialNumber $ seeAlso $ owner $ ou $ o $ l $ description ) )
+
+7.16. strongAuthenticationUser
+
+ ( 2.5.6.15 NAME 'strongAuthenticationUser' SUP top AUXILIARY
+ MUST userCertificate )
+
+7.17. certificationAuthority
+
+ ( 2.5.6.16 NAME 'certificationAuthority' SUP top AUXILIARY
+ MUST ( authorityRevocationList $ certificateRevocationList $
+ cACertificate ) MAY crossCertificatePair )
+
+7.18. groupOfUniqueNames
+
+ ( 2.5.6.17 NAME 'groupOfUniqueNames' SUP top STRUCTURAL
+ MUST ( uniqueMember $ cn )
+ MAY ( businessCategory $ seeAlso $ owner $ ou $ o $ description ) )
+
+7.19. userSecurityInformation
+
+ ( 2.5.6.18 NAME 'userSecurityInformation' SUP top AUXILIARY
+ MAY ( supportedAlgorithms ) )
+
+7.20. certificationAuthority-V2
+
+ ( 2.5.6.16.2 NAME 'certificationAuthority-V2' SUP
+ certificationAuthority
+ AUXILIARY MAY ( deltaRevocationList ) )
+
+7.21. cRLDistributionPoint
+
+ ( 2.5.6.19 NAME 'cRLDistributionPoint' SUP top STRUCTURAL
+ MUST ( cn ) MAY ( certificateRevocationList $
+ authorityRevocationList $
+ deltaRevocationList ) )
+
+7.22. dmd
+
+ ( 2.5.6.20 NAME 'dmd' SUP top STRUCTURAL MUST ( dmdName )
+ MAY ( userPassword $ searchGuide $ seeAlso $ businessCategory $
+ x121Address $ registeredAddress $ destinationIndicator $
+ preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $
+ telephoneNumber $ internationaliSDNNumber $
+ facsimileTelephoneNumber $
+
+
+
+Wahl Standards Track [Page 17]
+
+RFC 2256 LDAPv3 Schema December 1997
+
+
+ street $ postOfficeBox $ postalCode $ postalAddress $
+ physicalDeliveryOfficeName $ st $ l $ description ) )
+
+8. Matching Rules
+
+ Servers MAY implement additional matching rules.
+
+8.1. octetStringMatch
+
+ Servers which implement the extensibleMatch filter SHOULD allow the
+ matching rule listed in this section to be used in the
+ extensibleMatch. In general these servers SHOULD allow matching
+ rules to be used with all attribute types known to the server, when
+ the assertion syntax of the matching rule is the same as the value
+ syntax of the attribute.
+
+ ( 2.5.13.17 NAME 'octetStringMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )
+
+9. Security Considerations
+
+ Attributes of directory entries are used to provide descriptive
+ information about the real-world objects they represent, which can be
+ people, organizations or devices. Most countries have privacy laws
+ regarding the publication of information about people.
+
+ Transfer of cleartext passwords are strongly discouraged where the
+ underlying transport service cannot guarantee confidentiality and may
+ result in disclosure of the password to unauthorized parties.
+
+10. Acknowledgements
+
+ The definitions on which this document have been developed by
+ committees for telecommunications and international standards. No
+ new attribute definitions have been added. The syntax definitions
+ are based on the ISODE "QUIPU" implementation of X.500.
+
+11. Bibliography
+
+ [1] Wahl, M., Coulbeck, A., Howes, T., and S. Kille,
+ "Lightweight X.500 Directory Access Protocol (v3): Attribute
+ Syntax Definitions", RFC 2252, December 1997.
+
+ [2] The Directory: Models. ITU-T Recommendation X.501, 1996.
+
+ [3] The Directory: Authentication Framework. ITU-T Recommendation
+ X.509, 1996.
+
+
+
+
+Wahl Standards Track [Page 18]
+
+RFC 2256 LDAPv3 Schema December 1997
+
+
+ [4] The Directory: Selected Attribute Types. ITU-T Recommendation
+ X.520, 1996.
+
+ [5] The Directory: Selected Object Classes. ITU-T Recommendation
+ X.521, 1996.
+
+ [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+ Levels", RFC 2119, March 1997.
+
+12. Author's Address
+
+ Mark Wahl
+ Critical Angle Inc.
+ 4815 West Braker Lane #502-385
+ Austin, TX 78759
+ USA
+
+ Phone: +1 512 372 3160
+ EMail: M.Wahl at critical-angle.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wahl Standards Track [Page 19]
+
+RFC 2256 LDAPv3 Schema December 1997
+
+
+13. Full Copyright Statement
+
+ Copyright (C) The Internet Society (1997). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wahl Standards Track [Page 20]
+
Added: openldap/vendor/openldap-release/doc/rfc/rfc2293.txt
===================================================================
--- openldap/vendor/openldap-release/doc/rfc/rfc2293.txt (rev 0)
+++ openldap/vendor/openldap-release/doc/rfc/rfc2293.txt 2007-09-15 10:38:52 UTC (rev 844)
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+Network Working Group S. Kille
+Request for Comments: 2293 Isode Ltd.
+Obsoletes: 1837 March 1998
+Category: Standards Track
+
+
+ Representing Tables and Subtrees in the X.500 Directory
+
+Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (1998). All Rights Reserved.
+
+Abstract
+
+ This document defines techniques for representing two types of
+ information mapping in the OSI Directory [1].
+
+ 1. Mapping from a key to a value (or set of values), as might
+ be done in a table lookup.
+
+ 2. Mapping from a distinguished name to an associated
+ value (or values), where the values are not defined by the owner
+ of the entry. This is achieved by use of a directory subtree.
+
+ These techniques were developed for supporting MHS use of Directory
+ [2], but are specified separately as they have more general
+ applicability.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kille Standards Track [Page 1]
+
+RFC 2293 Table and Subtrees in the X.500 March 1998
+
+
+1 Representing Flat Tables
+
+ Before considering specific function, a general purpose technique for
+ representing tables in the directory is introduced. The schema for
+ this is given in Figure 1. A table can be considered as an unordered
+ set of key to (single or multiple) value mappings, where the key
+ cannot be represented as a global name. There are four reasons why
+ this may occur:
+
+ 1. The object does not have a natural global name.
+
+ 2. The object can only be named effectively in the context of
+ being a key to a binding. In this case, the object will be given
+ a natural global name by the table.
+
+ 3. The object has a global name, and the table is being used
+ to associate parameters with this object, in cases where they
+ cannot be placed in the objects global entry. Reasons why they
+ might not be so placed include:
+
+ o The object does not have a directory entry
+
+ o There is no authority to place the parameters in the
+ global entry
+
+ o The parameters are not global --- they only make sense
+ in the context of the table.
+
+ 4. It is desirable to group information together as a
+ performance optimization, so that the block of information may be
+ widely replicated.
+
+ A table is represented as a single level subtree. The root of the
+ subtree is an entry of object class Table. This is named with a
+ common name descriptive of the table. The table will be located
+ somewhere appropriate to its function. If a table is private to an
+ MTA, it will be below the MTA's entry. If it is shared by MTA's in
+ an organization, it will be located under the organization.
+
+ The generic table entry contains only a description. All instances
+ will be subclassed, and the subclass will define the naming
+ attribute. Two subclasses are defined:
+
+
+
+
+
+
+
+
+
+Kille Standards Track [Page 2]
+
+RFC 2293 Table and Subtrees in the X.500 March 1998
+
+
+table OBJECT-CLASS ::= {
+ SUBCLASS OF {top}
+ MUST CONTAIN {commonName}
+ MAY CONTAIN {manager}
+ ID oc-table}
+
+
+tableEntry OBJECT-CLASS ::= {
+ SUBCLASS OF {top}
+ MAY CONTAIN {description} 10
+ ID oc-table-entry}
+
+textTableEntry OBJECT-CLASS ::= {
+ SUBCLASS OF {tableEntry}
+ MUST CONTAIN {textTableKey}
+ MAY CONTAIN {textTableValue}
+ ID oc-text-table-entry}
+
+textTableKey ATTRIBUTE ::= {
+ SUBTYPE OF name 20
+ WITH SYNTAX DirectoryString {ub-name}
+ ID at-text-table-key}
+
+textTableValue ATTRIBUTE ::= {
+ SUBTYPE OF name
+ WITH SYNTAX DirectoryString {ub-description}
+ ID at-text-table-value}
+
+distinguishedNameTableEntry OBJECT-CLASS ::= {
+ SUBCLASS OF {tableEntry} 30
+ MUST CONTAIN {distinguishedNameTableKey}
+ ID oc-distinguished-name-table-entry}
+
+distinguishedNameTableKey ATTRIBUTE ::= {
+ SUBTYPE OF distinguishedName
+ ID at-distinguished-name-table-key}
+
+ Figure 1: Representing Tables
+
+
+ 1. TextEntry, which define table entries with text keys,
+ which may have single or multiple values of any type. An
+ attribute is defined to allow a text value, to support the
+ frequent text key to text value mapping. Additional values may
+ be defined.
+
+
+
+
+
+
+Kille Standards Track [Page 3]
+
+RFC 2293 Table and Subtrees in the X.500 March 1998
+
+
+ 2. DistinguishedNameEntry. This is used for associating
+ information with globally defined objects. This approach should
+ be used where the number of objects in the table is small or very
+ sparsely spread over the DIT. In other cases where there are many
+ objects or the objects are tightly clustered in the DIT, the
+ subtree approach defined in Section 2 will be preferable. No
+ value attributes are defined for this type of entry. An
+ application of this will make appropriate subtyping to define the
+ needed values.
+
+ This is best illustrated by example. Consider the MTA:
+
+ CN=Bells, OU=Computer Science,
+ O=University College London, C=GB
+
+ Suppose that the MTA needs a table mapping from private keys to fully
+ qualified domain names (this example is fictitious). The table might
+ be named as:
+
+ CN=domain-nicknames,
+ CN=Bells, OU=Computer Science,
+ O=University College London, C=GB
+
+ To represent a mapping in this table from "euclid" to
+ "bloomsbury.ac.uk", the entry:
+
+ TextTableKey=euclid, CN=domain-nicknames,
+ CN=Bells, OU=Computer Science,
+ O=University College London, C=GB
+
+ will contain the attribute:
+
+ TextTableValue=bloomsbury.ac.uk
+
+ A second example, showing the use of DistinguishedNameEntry is now
+ given. Consider again the MTA:
+
+ CN=Bells, OU=Computer Science,
+ O=University College London, C=GB
+
+ Suppose that the MTA needs a table mapping from MTA Name to bilateral
+ agreement information of that MTA. The table might be named as:
+
+ CN=MTA Bilateral Agreements,
+ CN=Bells, OU=Computer Science,
+ O=University College London, C=GB
+
+
+
+
+
+Kille Standards Track [Page 4]
+
+RFC 2293 Table and Subtrees in the X.500 March 1998
+
+
+ To represent information on the MTA which has the Distinguished Name:
+
+ CN=Q3T21, ADMD=Gold 400, C=GB
+
+ There would be an entry in this table with the Relative Distinguished
+ Name of the table entry being the Distinguished Name of the MTA being
+ referred to. The MTA Bilateral information would be an attribute in
+ this entry. Using a non-standard notation, the Distinguished Name of
+ the table entry is:
+
+ DistinguishedNameTableKey=<CN=Q3T21, ADMD=Gold 400, C=GB>,
+ CN=MTA Bilateral Agreements,
+ CN=Bells, OU=Computer Science,
+ O=University College London, C=GB
+
+2 Representing Subtrees
+
+ A subtree is similar to a table, except that the keys are constructed
+ as a distinguished name hierarchy relative to the location of the
+ subtree in the DIT. The subtree effectively starts a private "root",
+ and has distinguished names relative to this root. Typically, this
+ approach is used to associate local information with global objects.
+ The schema used is defined in Figure 2. Functionally, this is
+ equivalent to a table with distinguished name keys. The table
+ approach is best when the tree is very sparse. This approach is
+ better for subtrees which are more populated.
+
+ The subtree object class defines the root for a subtree in an
+ analogous means to the table. Information within the subtree will
+ generally be defined in the same way as for the global object, and so
+
+ subtree OBJECT-CLASS ::= {
+ SUBCLASS OF {top}
+ MUST CONTAIN {commonName}
+ MAY CONTAIN {manager}
+ ID oc-subtree}
+
+ Figure 2: Representing Subtrees
+
+
+ no specific object classes for subtree entries are needed.
+
+ For example consider University College London.
+
+ O=University College London, C=GB
+
+
+
+
+
+
+Kille Standards Track [Page 5]
+
+RFC 2293 Table and Subtrees in the X.500 March 1998
+
+
+ Suppose that the UCL needs a private subtree, with interesting
+ information about directory objects. The table might be named as:
+
+ CN=private subtree,
+ O=University College London, C=GB
+
+ UCL specific information on Inria might be stored in the entry:
+
+ O=Inria, C=FR,
+ CN=private subtree,
+ O=University College London, C=GB
+
+ Practical examples of this mapping are given in [2].
+
+3 Acknowledgments
+
+ Acknowledgments for work on this document are given in [2].
+
+References
+
+ [1] The Directory --- overview of concepts, models and services,
+ 1993. CCITT X.500 Series Recommendations.
+
+ [2] Kille, S.E., "X.400-MHS use of the X.500 directory to support
+ X.400-MHS routing," RFC 1801, June 1995.
+
+4 Security Considerations
+
+ Security considerations are not discussed in this memo.
+
+5 Author's Address
+
+ Steve Kille
+ Isode Ltd
+ The Dome
+ The Square
+ Richmond
+ TW9 1DT
+ England
+
+ Phone: +44-181-332-9091
+ EMail: S.Kille at ISODE.COM
+
+
+
+
+
+
+
+
+
+Kille Standards Track [Page 6]
+
+RFC 2293 Table and Subtrees in the X.500 March 1998
+
+
+A Object Identifier Assignment
+
+
+mhs-ds OBJECT IDENTIFIER ::= {iso(1) org(3) dod(6) internet(1)
+ private(4) enterprises(1) isode-consortium (453) mhs-ds (7)}
+
+tables OBJECT IDENTIFIER ::= {mhs-ds 1}
+
+oc OBJECT IDENTIFIER ::= {tables 1}
+at OBJECT IDENTIFIER ::= {tables 2}
+
+oc-subtree OBJECT IDENTIFIER ::= {oc 1}
+oc-table OBJECT IDENTIFIER ::= {oc 2} 10
+oc-table-entry OBJECT IDENTIFIER ::= {oc 3}
+oc-text-table-entry OBJECT IDENTIFIER ::= {oc 4}
+oc-distinguished-name-table-entry OBJECT IDENTIFIER ::= {oc 5}
+
+at-text-table-key OBJECT IDENTIFIER ::= {at 1}
+at-text-table-value OBJECT IDENTIFIER ::= {at 2}
+at-distinguished-name-table-key OBJECT IDENTIFIER ::= {at 3}
+
+ Figure 3: Object Identifier Assignment
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kille Standards Track [Page 7]
+
+RFC 2293 Table and Subtrees in the X.500 March 1998
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (1998). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kille Standards Track [Page 8]
+
Added: openldap/vendor/openldap-release/doc/rfc/rfc2294.txt
===================================================================
--- openldap/vendor/openldap-release/doc/rfc/rfc2294.txt (rev 0)
+++ openldap/vendor/openldap-release/doc/rfc/rfc2294.txt 2007-09-15 10:38:52 UTC (rev 844)
@@ -0,0 +1,731 @@
+
+
+
+
+
+
+Network Working Group S. Kille
+Request for Comments: 2294 Isode Ltd.
+Obsoletes: 1836 March 1998
+Category: Standards Track
+
+
+ Representing the O/R Address hierarchy in the
+ X.500 Directory Information Tree
+
+Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (1998). All Rights Reserved.
+
+Abstract
+
+ This document defines a representation of the O/R Address hierarchy
+ in the Directory Information Tree [6, 1]. This is useful for a range
+ of purposes, including:
+
+ o Support for MHS Routing [4].
+
+ o Support for X.400/RFC 822 address mappings [2, 5].
+
+ Please send comments to the author or to the discussion group <mhs-
+ ds at mercury.udev.cdc.com>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kille Standards Track [Page 1]
+
+RFC 2294 Directory Information Tree March 1998
+
+
+ Object Class Mandatory
+ ------------ ---------
+ mHSCountry M
+ aDMD M
+ pRMD O
+ mHSX121 O
+ mHSNumericUserIdentifier O
+ mHSOrganization O
+ mHSOrganizationalUnit O
+ mHSPerson O
+ mHSNamedObject O
+ mHSTerminalID O
+ mHSDomainDefinedAttribute O
+
+ Table 1: Order of O/R Address Directory Components
+
+1 The O/R Address Hierarchy
+
+ An O/R Address hierarchy is represented in the X.500 directory by
+ associating directory name components with O/R Address components.
+ An example of this is given in Figure 1. The object classes and
+ attributes required to support this representation are defined in
+ Figure 2. The schema, which defines the hierarchy in which these
+ objects are represented in the directory information tree is
+ specified in Table 1. A given object class defined in the table will
+ always be higher in the DIT than an object class defined lower down
+ the table. Valid combinations of O/R Address components are defined
+ in X.400.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kille Standards Track [Page 2]
+
+RFC 2294 Directory Information Tree March 1998
+
+
+ /\
+ / \
+ C=GB / \ Numeric-C=234
+ / \
+ / \
+ / \
+ +------------+<----------------+----+
+ | Country | | |
+ +------------+ +----+
+ /\
+ / \
+ / \
+ / \
+ ADMD=" " / \ ADMD=Gold 400
+ +-------------+ +------------+
+ | ADMD | | ADMD |
+ +-------------+ +------------+
+ \ \
+ \ \
+ \ PRMD=UK.AC \ PRMD=UK.AC
+ \ \
+ +----------+ +----+
+ | PRMD |< -----------| |
+ +----------+ +----+
+ /
+ /
+ O=UCL
+ /
+ /
+ +------------+
+ | MHS-Org |
+ +------------+
+ \
+ \ OU=CS
+ \
+ \
+ +-----------+
+ | MHS-OU |
+ +-----------+
+
+
+ Figure 1: Example O/R Address Tree
+
+
+
+
+
+
+
+
+
+Kille Standards Track [Page 3]
+
+RFC 2294 Directory Information Tree March 1998
+
+
+IMPORTS
+ ub-domain-name-length, ub-organization-name-length,
+ ub-organizational-unit-name-length, ub-common-name-length,
+ ub-x121-address-length, ub-domain-defined-attribute-type-length,
+ ub-domain-defined-attribute-value-length, ub-terminal-id-length,
+ ub-numeric-user-id-length, ub-country-name-numeric-length,
+ ub-surname-length, ub-given-name-length, ub-initials-length,
+ ub-generation-qualifier-length
+
+ FROM MTSUpperBounds {joint-iso-ccitt mhs-motis(6) mts(3) 10
+ modules(0) upper-bounds(3) };
+
+mHSCountry OBJECT-CLASS ::= {
+ SUBCLASS OF {country}
+ MAY CONTAIN {mHSNumericCountryName}
+ ID oc-mhs-country}
+
+mHSNumericCountryName ATTRIBUTE ::= {
+ WITH SYNTAX NumericString (SIZE (1..ub-country-name-numeric-length))
+ SINGLE VALUE 20
+ ID at-mhs-numeric-country-name}
+
+aDMD OBJECT-CLASS ::= {
+ SUBCLASS OF {top}
+ MUST CONTAIN {aDMDName}
+ ID oc-admd}
+
+aDMDName ATTRIBUTE ::= {
+ SUBTYPE OF name
+ WITH SYNTAX DirectoryString {ub-domain-name-length} 30
+ ID at-admd-name}
+
+pRMD OBJECT-CLASS ::= {
+ SUBCLASS OF {top}
+ MUST CONTAIN {pRMDName}
+ ID oc-prmd}
+
+pRMDName ATTRIBUTE ::= {
+ SUBTYPE OF name
+ WITH SYNTAX DirectoryString {ub-domain-name-length} 40
+ ID at-prmd-name}
+
+mHSOrganization OBJECT-CLASS ::= {
+ SUBCLASS OF {top}
+ MUST CONTAIN {mHSOrganizationName }
+ ID oc-mhs-organization}
+
+
+
+
+
+Kille Standards Track [Page 4]
+
+RFC 2294 Directory Information Tree March 1998
+
+
+mHSOrganizationName ATTRIBUTE ::= {
+ SUBTYPE OF organizationName
+ WITH SYNTAX DirectoryString {ub-organization-name-length} 50
+ ID at-mhs-organization-name}
+
+mHSOrganizationalUnit OBJECT-CLASS ::= {
+ SUBCLASS OF {top}
+ MUST CONTAIN {mHSOrganizationalUnitName}
+ ID oc-mhs-organizational-unit}
+
+mHSOrganizationalUnitName ATTRIBUTE ::= {
+ SUBTYPE OF organizationalUnitName 60
+ WITH SYNTAX DirectoryString {ub-organizational-unit-name-length}
+ ID at-mhs-organizational-unit-name}
+
+mHSPerson OBJECT-CLASS ::= {
+ SUBCLASS OF {top}
+ MUST CONTAIN {mHSSurname}
+ MAY CONTAIN {mHSGivenName|
+ mHSInitials|
+ mHSGenerationalQualifier}
+ ID oc-mhs-person} 70
+
+mHSSurname ATTRIBUTE ::= {
+ SUBTYPE OF surname
+ WITH SYNTAX DirectoryString {ub-surname-length}
+ ID at-mhs-surname}
+
+mHSGivenName ATTRIBUTE ::= {
+ SUBTYPE OF givenName
+ WITH SYNTAX DirectoryString {ub-given-name-length}
+ ID at-mhs-given-name} 80
+
+mHSInitials ATTRIBUTE ::= {
+ SUBTYPE OF initials
+ WITH SYNTAX DirectoryString {ub-initials-length}
+ ID at-mhs-initials}
+
+mHSGenerationQualifier ATTRIBUTE ::= {
+ SUBTYPE OF generationQualifier
+ WITH SYNTAX DirectoryString {ub-generation-qualifier-length}
+ ID at-mhs-generation-qualifier} 90
+
+mHSNamedObject OBJECT-CLASS ::= {
+ SUBCLASS OF {top}
+ MUST CONTAIN {mHSCommonName}
+ ID oc-mhs-named-object}
+
+
+
+
+Kille Standards Track [Page 5]
+
+RFC 2294 Directory Information Tree March 1998
+
+
+mHSCommonName ATTRIBUTE ::= {
+ SUBTYPE OF commonName
+ WITH SYNTAX DirectoryString {ub-common-name-length}
+ ID at-mhs-common-name} 100
+
+mHSX121 OBJECT-CLASS ::= {
+ SUBCLASS OF {top}
+ MUST CONTAIN {mHSX121Address}
+ ID oc-mhs-x121}
+
+mHSX121Address ATTRIBUTE ::= {
+ SUBTYPE OF name
+ WITH SYNTAX DirectoryString {ub-x121-address-length}
+ ID at-x121-address} 110
+
+mHSDomainDefinedAttribute OBJECT-CLASS ::= {
+ SUBCLASS OF {top}
+ MUST CONTAIN {
+ mHSDomainDefinedAttributeType|
+ mHSDomainDefinedAttributeValue}
+ ID oc-mhs-domain-defined-attribute}
+
+mHSDomainDefinedAttributeType ATTRIBUTE ::= {
+ SUBTYPE OF name 120
+ WITH SYNTAX DirectoryString {ub-domain-defined-attribute-type-length}
+ SINGLE VALUE
+ ID at-mhs-domain-defined-attribute-type}
+
+mHSDomainDefinedAttributeValue ATTRIBUTE ::= {
+ SUBTYPE OF name
+ WITH SYNTAX DirectoryString {ub-domain-defined-attribute-value-length}
+ SINGLE VALUE
+ ID at-mhs-domain-defined-attribute-value}
+ 130
+
+mHSTerminalID OBJECT-CLASS ::= {
+ SUBCLASS OF {top}
+ MUST CONTAIN {mHSTerminalIDName}
+ ID oc-mhs-terminal-id}
+
+mHSTerminalIDName ATTRIBUTE ::= {
+ SUBTYPE OF name
+ WITH SYNTAX DirectoryString {ub-terminal-id-length}
+ ID at-mhs-terminal-id-name} 140
+
+
+
+
+
+
+
+Kille Standards Track [Page 6]
+
+RFC 2294 Directory Information Tree March 1998
+
+
+mHSNumericUserIdentifier OBJECT-CLASS ::= {
+ SUBCLASS OF {top}
+ MUST CONTAIN {mHSNumericUserIdentifierName}
+ ID oc-mhs-numeric-user-id}
+
+mHSNumericeUserIdentifierName ATTRIBUTE ::= {
+ SUBTYPE OF name
+ WITH SYNTAX DirectoryString {ub-numeric-user-id-length} 150
+ ID at-mhs-numeric-user-id-name}
+
+ Figure 2: O/R Address Hierarchy
+
+ The hierarchy is defined so that:
+
+ 1. The representation is defined so that it is straightforward to
+ make a mechanical transformation in either direction. This
+ requires that each node is named by an attribute whose type can
+ determine the mapping.
+
+ 2. Where there are multiple domain defined attributes, the first
+ in the sequence is the most significant.
+
+ 3. Physical Delivery (postal) addresses are not represented in
+ this hierarchy. This is primarily because physical delivery can
+ be handled by the Access Unit routing mechanisms defined in [4],
+ and there is no need for this representation.
+
+ 4. Terminal and network forms of address are not handled, except
+ for X.121 form, which is useful for addressing faxes.
+
+ 5. MHSCountry is defined as a subclass of Country, and so the
+ same entry will be used for MHS Routing as for the rest of the
+ DIT.
+
+ 6. The numeric country code will be an alias.
+
+ 7. ADMD will always be present in the hierarchy. This is true
+ in the case of " " and of "0". This facilitates an easy
+ mechanical transformation between the two forms of address.
+
+ 8. Each node is named by the relevant part of the O/R Address.
+
+ 9. Aliases may be used in other parts of the tree, in order to
+ normalize alternate values. Where an alias is used, the value of
+ the alias should be present as an alternate value in the node
+ aliased to. Aliases may not be used for domain defined
+ attributes.
+
+
+
+
+Kille Standards Track [Page 7]
+
+RFC 2294 Directory Information Tree March 1998
+
+
+ 10. Domain Defined Attributes are named by a multi-valued RDN
+ (Relative Distinguished Name), consisting of the type and value.
+ This is done so that standard attribute syntaxes can be used.
+
+ 11. Where an O/R Address has a valid Printable String and T.61 form,
+ both must be present, with one as an alias for the other. This
+ is so that direct lookup of the name will work, independent of
+ the variant used. When both are present in an O/R Address being
+ looked up, either may be used to construct the distinguished
+ name.
+
+ 12. Personal name is handled by use of the mHSPerson object class.
+ Each of the components of the personal name will be present in
+ the relative distinguished name, which will usually be multi-
+ valued.
+
+ The relationship between X.400 O/R Addresses and the X.400 Entries
+ (Attribute Type and Object Class) are given in Table 2. Where there
+ are multiple Organizational Units or Domain Defined Attributes, each
+ component is mapped onto a single X.500 entry.
+
+ Note: When an X.121 address is used for addressing fax transmission,
+ this may only be done relative to the PRMD or ADMD. This is in
+ line with the current X.400 standards position. This means that
+ it is not possible to use this form of addressing for an
+ organizational or departmental fax gateway service.
+
+O/R Address Object Class Naming Attribute
+----------- ------------ ----------------
+C mHSCountry countryName
+ or
+ mHSNumericCountryName
+A aDMD aDMDName
+P pRMD pRMDName
+O mHSOrganization mHSOrganizationName
+OU/OU1/OU2 mHSOrganizationalUnit mHSOrganizationalUnitName
+OU3/OU4
+PN mHSPerson personName
+CN mHSNamedObject mHSCommonName
+X121 mHSX121 mHSX121Address
+T-ID mHSTerminalID mHSTerminalIDName
+UA-ID mHSNumericUserIdentifier mHSNumericUserIdentifierName
+DDA mHSDomainDefinedAttribute mHSDomainDefinedAttributeType
+ and
+ mHSDomainDefinedAttributeValue
+
+
+ Table 2: O/R Address relationship to Directory Name
+
+
+
+Kille Standards Track [Page 8]
+
+RFC 2294 Directory Information Tree March 1998
+
+
+2 Notation
+
+ O/R Addresses are written in the standard X.400 Notation.
+ Distinguished Names use the string representation of distinguished
+ names defined in [3]. The keywords used for the attributes defined
+ in this specification are given in Table 3.
+
+3 Example Representation
+
+ The O/R Address:
+
+ I=S; S=Kille; OU1=CS; O=UCL,
+ P=UK.AC; A=Gold 400; C=GB;
+
+
+ would be represented in the directory as:
+
+ MHS-I=S + MHS-S=Kille, MHS-OU=CS, MHS-O=UCL,
+
+
+ Attribute Keyword
+ --------- -------
+ mHSNumericCountryName MHS-Numeric-Country
+ aDMDName ADMD
+ pRMDName PRMD
+ mHSOrganizationName MHS-O
+ mHSOrganizationalUnitName MHS-OU
+ mHSSurname MHS-S
+ mHSGivenName MHS-G
+ mHSInitials MHS-I
+ mHSGenerationalQualifier MHS-GQ
+ mHSCommonName MHS-CN
+ mHSX121Address MHS-X121
+ mHSDomainDefinedAttributeType MHS-DDA-Type
+ mHSDomainDefinedAttributeValue MHS-DDA-Value
+ mHSTerminalIDName MHS-T-ID
+ mHSNumericeUserIdentifierName MHS-UA-ID
+
+ Table 3: Keywords for String DN Representation
+
+
+ PRMD=UK.AC, ADMD=Gold 400, C=GB
+
+4 Mapping from O/R Address to Directory Name
+
+ The primary application of this mapping is to take an X.400 encoded
+ O/R Address and to generate an equivalent directory name. This
+ mapping is only used for selected types of O/R Address:
+
+
+
+Kille Standards Track [Page 9]
+
+RFC 2294 Directory Information Tree March 1998
+
+
+ o Mnemonic form
+
+ o Numeric form
+
+ o Terminal form, where country is present and X121 addressing
+ is used
+
+ Other forms of O/R address are handled by Access Unit mechanisms.
+ The O/R Address is treated as an ordered list, with the order as
+ defined in Table 1. For each O/R Address attribute, generate the
+ equivalent directory naming attribute. In most cases, the mapping is
+ mechanical. Printable String or Teletex encodings are chosen as
+ appropriate. Where both forms are present in the O/R Address, either
+ form may be used to generate the distinguished name. Both will be
+ represented in the DIT. There are two special cases:
+
+ 1. A DDA generates a multi-valued RDN
+
+ 2. The Personal Name is mapped to a multi-valued RDN
+
+ In many cases, an O/R Address will be provided, and only the higher
+ components of the address will be represented in the DIT. In this
+ case, the "longest possible match" should be returned.
+
+5 Mapping from Directory Name to O/R Address
+
+ The reverse mapping is also needed in some cases. All of the naming
+ attributes are unique, so the mapping is mechanically reversible.
+
+6 Acknowledgments
+
+ Acknowledgments for work on this document are given in [4].
+
+References
+
+ [1] The Directory --- overview of concepts, models and services,
+ 1993. CCITT X.500 Series Recommendations.
+
+ [2] Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay): Mapping
+ between X.400 and RFC 822/MIME", RFC 2156, January 1998.
+
+ [3] Kille, S., "A String Representation of Distinguished Names",
+ RFC 1779, March 1995.
+
+ [4] Kille, S., "Use of an X.500/LDAP directory to support MIXER address
+ mapping", RFC 2164, January 1998.
+
+
+
+
+
+Kille Standards Track [Page 10]
+
+RFC 2294 Directory Information Tree March 1998
+
+
+ [5] Kille, S., "X.400-MHS use of the X.500 directory to support
+ X.400-MHS routing", RFC 1801, June 1995.
+
+ [6] CCITT recommendations X.400 / ISO 10021, April 1988. CCITT
+ SG 5/VII / ISO/IEC JTC1, Message Handling: System and Service
+ Overview.
+
+7 Security Considerations
+
+ This protocol introduces no known security risks.
+
+8 Author's Address
+
+ Steve Kille
+ Isode Ltd.
+ The Dome
+ The Square
+ Richmond
+ TW9 1DT
+ England
+
+ Phone: +44-181-332-9091
+ EMail: S.Kille at ISODE.COM
+
+ X.400: I=S; S=Kille; P=ISODE; A=Mailnet; C=FI;
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kille Standards Track [Page 11]
+
+RFC 2294 Directory Information Tree March 1998
+
+
+A Object Identifier Assignment
+
+mhs-ds OBJECT IDENTIFIER ::= {iso(1) org(3) dod(6) internet(1) private(4)
+ enterprises(1) isode-consortium (453) mhs-ds (7)}
+
+
+tree OBJECT IDENTIFIER ::= {mhs-ds 2}
+
+oc OBJECT IDENTIFIER ::= {tree 1}
+at OBJECT IDENTIFIER ::= {tree 2}
+
+oc-admd OBJECT IDENTIFIER ::= {oc 1} 10
+oc-mhs-country OBJECT IDENTIFIER ::= {oc 2}
+oc-mhs-domain-defined-attribute OBJECT IDENTIFIER ::= {oc 3}
+oc-mhs-named-object OBJECT IDENTIFIER ::= {oc 4}
+oc-mhs-organization OBJECT IDENTIFIER ::= {oc 5}
+oc-mhs-organizational-unit OBJECT IDENTIFIER ::= {oc 6}
+oc-mhs-person OBJECT IDENTIFIER ::= {oc 7}
+oc-mhs-x121 OBJECT IDENTIFIER ::= {oc 8}
+oc-prmd OBJECT IDENTIFIER ::= {oc 9}
+oc-mhs-terminal-id OBJECT IDENTIFIER ::= {oc 10}
+oc-mhs-numeric-user-id OBJECT IDENTIFIER ::= {oc 11} 20
+
+at-admd-name OBJECT IDENTIFIER ::= {at 1}
+at-mhs-common-name OBJECT IDENTIFIER ::= {at 2}
+at-mhs-domain-defined-attribute-type OBJECT IDENTIFIER ::= {at 3}
+at-mhs-domain-defined-attribute-value OBJECT IDENTIFIER ::= {at 4}
+at-mhs-numeric-country-name OBJECT IDENTIFIER ::= {at 5}
+at-mhs-organization-name OBJECT IDENTIFIER ::= {at 6}
+at-mhs-organizational-unit-name OBJECT IDENTIFIER ::= {at 7}
+at-prmd-name OBJECT IDENTIFIER ::= {at 10}
+at-x121-address OBJECT IDENTIFIER ::= {at 12} 30
+at-mhs-terminal-id-name OBJECT IDENTIFIER ::= {at 13}
+at-mhs-numeric-user-id-name OBJECT IDENTIFIER ::= {at 14}
+at-mhs-surname OBJECT IDENTIFIER ::= {at 15}
+at-mhs-given-name OBJECT IDENTIFIER ::= {at 16}
+at-mhs-initials OBJECT IDENTIFIER ::= {at 17}
+at-mhs-generation-qualifier OBJECT IDENTIFIER ::= {at 18}
+
+ Figure 3: Object Identifier Assignment
+
+
+
+
+
+
+
+
+
+
+
+Kille Standards Track [Page 12]
+
+RFC 2294 Directory Information Tree March 1998
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (1998). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kille Standards Track [Page 13]
+
Added: openldap/vendor/openldap-release/doc/rfc/rfc2307.txt
===================================================================
--- openldap/vendor/openldap-release/doc/rfc/rfc2307.txt (rev 0)
+++ openldap/vendor/openldap-release/doc/rfc/rfc2307.txt 2007-09-15 10:38:52 UTC (rev 844)
@@ -0,0 +1,1179 @@
+
+
+
+
+
+
+Network Working Group L. Howard
+Request for Comments: 2307 Independent Consultant
+Category: Experimental March 1998
+
+
+ An Approach for Using LDAP as a Network Information Service
+
+Status of this Memo
+
+ This memo defines an Experimental Protocol for the Internet
+ community. It does not specify an Internet standard of any kind.
+ Discussion and suggestions for improvement are requested.
+ Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (1998). All Rights Reserved.
+
+Abstract
+
+ This document describes an experimental mechanism for mapping
+ entities related to TCP/IP and the UNIX system into X.500 [X500]
+ entries so that they may be resolved with the Lightweight Directory
+ Access Protocol [RFC2251]. A set of attribute types and object
+ classes are proposed, along with specific guidelines for interpreting
+ them.
+
+ The intention is to assist the deployment of LDAP as an
+ organizational nameservice. No proposed solutions are intended as
+ standards for the Internet. Rather, it is hoped that a general
+ consensus will emerge as to the appropriate solution to such
+ problems, leading eventually to the adoption of standards. The
+ proposed mechanism has already been implemented with some success.
+
+1. Background and Motivation
+
+ The UNIX (R) operating system, and its derivatives (specifically,
+ those which support TCP/IP and conform to the X/Open Single UNIX
+ specification [XOPEN]) require a means of looking up entities, by
+ matching them against search criteria or by enumeration. (Other
+ operating systems that support TCP/IP may provide some means of
+ resolving some of these entities. This schema is applicable to those
+ environments also.)
+
+ These entities include users, groups, IP services (which map names to
+ IP ports and protocols, and vice versa), IP protocols (which map
+ names to IP protocol numbers and vice versa), RPCs (which map names
+ to ONC Remote Procedure Call [RFC1057] numbers and vice versa), NIS
+
+
+
+Howard Experimental [Page 1]
+
+RFC 2307 Using LDAP as a Network Information Service March 1998
+
+
+ netgroups, booting information (boot parameters and MAC address
+ mappings), filesystem mounts, IP hosts and networks, and RFC822 mail
+ aliases.
+
+ Resolution requests are made through a set of C functions, provided
+ in the UNIX system's C library. For example, the UNIX system utility
+ "ls", which enumerates the contents of a filesystem directory, uses
+ the C library function getpwuid() in order to map user IDs to login
+ names. Once the request is made, it is resolved using a "nameservice"
+ which is supported by the client library. The nameservice may be, at
+ its simplest, a collection of files in the local filesystem which are
+ opened and searched by the C library. Other common nameservices
+ include the Network Information Service (NIS) and the Domain Name
+ System (DNS). (The latter is typically used for resolving hosts,
+ services and networks.) Both these nameservices have the advantage of
+ being distributed and thus permitting a common set of entities to be
+ shared amongst many clients.
+
+ LDAP is a distributed, hierarchical directory service access protocol
+ which is used to access repositories of users and other network-
+ related entities. Because LDAP is often not tightly integrated with
+ the host operating system, information such as users may need to be
+ kept both in LDAP and in an operating system supported nameservice
+ such as NIS. By using LDAP as the the primary means of resolving
+ these entities, these redundancy issues are minimized and the
+ scalability of LDAP can be exploited. (By comparison, NIS services
+ based on flat files do not have the scalability or extensibility of
+ LDAP or X.500.)
+
+ The object classes and attributes defined below are suitable for
+ representing the aforementioned entities in a form compatible with
+ LDAP and X.500 directory services.
+
+2. General Issues
+
+2.1. Terminology
+
+ The key words "MUST", "SHOULD", and "MAY" used in this document are
+ to be interpreted as described in [RFC2119].
+
+ For the purposes of this document, the term "nameservice" refers to a
+ service, such as NIS or flat files, that is used by the operating
+ system to resolve entities within a single, local naming context.
+ Contrast this with a "directory service" such as LDAP, which supports
+ extensible schema and multiple naming contexts.
+
+
+
+
+
+
+Howard Experimental [Page 2]
+
+RFC 2307 Using LDAP as a Network Information Service March 1998
+
+
+ The term "NIS-related entities" broadly refers to entities which are
+ typically resolved using the Network Information Service. (NIS was
+ previously known as YP.) Deploying LDAP for resolving these entities
+ does not imply that NIS be used, as a gateway or otherwise. In
+ particular, the host and network classes are generically applicable,
+ and may be implemented on any system that wishes to use LDAP or X.500
+ for host and network resolution.
+
+ The "DUA" (directory user agent) refers to the LDAP client querying
+ these entities, such as an LDAP to NIS gateway or the C library. The
+ "client" refers to the application which ultimately makes use of the
+ information returned by the resolution. It is irrelevant whether the
+ DUA and the client reside within the same address space. The act of
+ the DUA making this information to the client is termed
+ "republishing".
+
+ To avoid confusion, the term "login name" refers to the user's login
+ name (being the value of the uid attribute) and the term "user ID"
+ refers to he user's integer identification number (being the value of
+ the uidNumber attribute).
+
+ The phrases "resolving an entity" and "resolution of entities" refer
+ respectively to enumerating NIS-related entities of a given type, and
+ matching them against a given search criterion. One or more entities
+ are returned as a result of successful "resolutions" (a "match"
+ operation will only return one entity).
+
+ The use of the term UNIX does not confer upon this schema the
+ endorsement of owners of the UNIX trademark. Where necessary, the
+ term "TCP/IP entity" is used to refer to protocols, services, hosts,
+ and networks, and the term "UNIX entity" to its complement. (The
+ former category does not mandate the host operating system supporting
+ the interfaces required for resolving UNIX entities.)
+
+ The OIDs defined below are derived from iso(1) org(3) dod(6)
+ internet(1) directory(1) nisSchema(1).
+
+2.2. Attributes
+
+ The attributes and classes defined in this document are summarized
+ below.
+
+ The following attributes are defined in this document:
+
+ uidNumber
+ gidNumber
+ gecos
+ homeDirectory
+
+
+
+Howard Experimental [Page 3]
+
+RFC 2307 Using LDAP as a Network Information Service March 1998
+
+
+ loginShell
+ shadowLastChange
+ shadowMin
+ shadowMax
+ shadowWarning
+ shadowInactive
+ shadowExpire
+ shadowFlag
+ memberUid
+ memberNisNetgroup
+ nisNetgroupTriple
+ ipServicePort
+ ipServiceProtocol
+ ipProtocolNumber
+ oncRpcNumber
+ ipHostNumber
+ ipNetworkNumber
+ ipNetmaskNumber
+ macAddress
+ bootParameter
+ bootFile
+ nisMapName
+ nisMapEntry
+
+ Additionally, some of the attributes defined in [RFC2256] are
+ required.
+
+2.3. Object classes
+
+ The following object classes are defined in this document:
+
+ posixAccount
+ shadowAccount
+ posixGroup
+ ipService
+ ipProtocol
+ oncRpc
+ ipHost
+ ipNetwork
+ nisNetgroup
+ nisMap
+ nisObject
+ ieee802Device
+ bootableDevice
+
+ Additionally, some of the classes defined in [RFC2256] are required.
+
+
+
+
+
+Howard Experimental [Page 4]
+
+RFC 2307 Using LDAP as a Network Information Service March 1998
+
+
+2.4. Syntax definitions
+
+ The following syntax definitions [RFC2252] are used by this schema.
+ The nisNetgroupTripleSyntax represents NIS netgroup triples:
+
+ ( nisSchema.0.0 NAME 'nisNetgroupTripleSyntax'
+ DESC 'NIS netgroup triple' )
+
+ Values in this syntax are represented by the following:
+
+ nisnetgrouptriple = "(" hostname "," username "," domainname ")"
+ hostname = "" / "-" / keystring
+ username = "" / "-" / keystring
+ domainname = "" / "-" / keystring
+
+ X.500 servers may use the following representation of the above
+ syntax:
+
+ nisNetgroupTripleSyntax ::= SEQUENCE {
+ hostname [0] IA5String OPTIONAL,
+ username [1] IA5String OPTIONAL,
+ domainname [2] IA5String OPTIONAL
+ }
+
+ The bootParameterSyntax syntax represents boot parameters:
+
+ ( nisSchema.0.1 NAME 'bootParameterSyntax'
+ DESC 'Boot parameter' )
+
+ where:
+
+ bootparameter = key "=" server ":" path
+ key = keystring
+ server = keystring
+ path = keystring
+
+ X.500 servers may use the following representation of the above
+ syntax:
+
+ bootParameterSyntax ::= SEQUENCE {
+ key IA5String,
+ server IA5String,
+ path IA5String
+ }
+
+ Values adhering to these syntaxes are encoded as strings by LDAP
+ servers.
+
+
+
+
+Howard Experimental [Page 5]
+
+RFC 2307 Using LDAP as a Network Information Service March 1998
+
+
+3. Attribute definitions
+
+ This section contains attribute definitions to be implemented by DUAs
+ supporting this schema.
+
+ ( nisSchema.1.0 NAME 'uidNumber'
+ DESC 'An integer uniquely identifying a user in an
+ administrative domain'
+ EQUALITY integerMatch SYNTAX 'INTEGER' SINGLE-VALUE )
+
+ ( nisSchema.1.1 NAME 'gidNumber'
+ DESC 'An integer uniquely identifying a group in an
+ administrative domain'
+ EQUALITY integerMatch SYNTAX 'INTEGER' SINGLE-VALUE )
+
+ ( nisSchema.1.2 NAME 'gecos'
+ DESC 'The GECOS field; the common name'
+ EQUALITY caseIgnoreIA5Match
+ SUBSTRINGS caseIgnoreIA5SubstringsMatch
+ SYNTAX 'IA5String' SINGLE-VALUE )
+
+ ( nisSchema.1.3 NAME 'homeDirectory'
+ DESC 'The absolute path to the home directory'
+ EQUALITY caseExactIA5Match
+ SYNTAX 'IA5String' SINGLE-VALUE )
+
+ ( nisSchema.1.4 NAME 'loginShell'
+ DESC 'The path to the login shell'
+ EQUALITY caseExactIA5Match
+ SYNTAX 'IA5String' SINGLE-VALUE )
+
+ ( nisSchema.1.5 NAME 'shadowLastChange'
+ EQUALITY integerMatch
+ SYNTAX 'INTEGER' SINGLE-VALUE )
+
+ ( nisSchema.1.6 NAME 'shadowMin'
+ EQUALITY integerMatch
+ SYNTAX 'INTEGER' SINGLE-VALUE )
+
+ ( nisSchema.1.7 NAME 'shadowMax'
+ EQUALITY integerMatch
+ SYNTAX 'INTEGER' SINGLE-VALUE )
+
+ ( nisSchema.1.8 NAME 'shadowWarning'
+ EQUALITY integerMatch
+ SYNTAX 'INTEGER' SINGLE-VALUE )
+
+ ( nisSchema.1.9 NAME 'shadowInactive'
+
+
+
+Howard Experimental [Page 6]
+
+RFC 2307 Using LDAP as a Network Information Service March 1998
+
+
+ EQUALITY integerMatch
+ SYNTAX 'INTEGER' SINGLE-VALUE )
+
+ ( nisSchema.1.10 NAME 'shadowExpire'
+ EQUALITY integerMatch
+ SYNTAX 'INTEGER' SINGLE-VALUE )
+
+ ( nisSchema.1.11 NAME 'shadowFlag'
+ EQUALITY integerMatch
+ SYNTAX 'INTEGER' SINGLE-VALUE )
+
+ ( nisSchema.1.12 NAME 'memberUid'
+ EQUALITY caseExactIA5Match
+ SUBSTRINGS caseExactIA5SubstringsMatch
+ SYNTAX 'IA5String' )
+
+ ( nisSchema.1.13 NAME 'memberNisNetgroup'
+ EQUALITY caseExactIA5Match
+ SUBSTRINGS caseExactIA5SubstringsMatch
+ SYNTAX 'IA5String' )
+
+ ( nisSchema.1.14 NAME 'nisNetgroupTriple'
+ DESC 'Netgroup triple'
+ SYNTAX 'nisNetgroupTripleSyntax' )
+
+ ( nisSchema.1.15 NAME 'ipServicePort'
+ EQUALITY integerMatch
+ SYNTAX 'INTEGER' SINGLE-VALUE )
+
+ ( nisSchema.1.16 NAME 'ipServiceProtocol'
+ SUP name )
+
+ ( nisSchema.1.17 NAME 'ipProtocolNumber'
+ EQUALITY integerMatch
+ SYNTAX 'INTEGER' SINGLE-VALUE )
+
+ ( nisSchema.1.18 NAME 'oncRpcNumber'
+ EQUALITY integerMatch
+ SYNTAX 'INTEGER' SINGLE-VALUE )
+
+ ( nisSchema.1.19 NAME 'ipHostNumber'
+ DESC 'IP address as a dotted decimal, eg. 192.168.1.1,
+ omitting leading zeros'
+ EQUALITY caseIgnoreIA5Match
+ SYNTAX 'IA5String{128}' )
+
+ ( nisSchema.1.20 NAME 'ipNetworkNumber'
+ DESC 'IP network as a dotted decimal, eg. 192.168,
+
+
+
+Howard Experimental [Page 7]
+
+RFC 2307 Using LDAP as a Network Information Service March 1998
+
+
+ omitting leading zeros'
+ EQUALITY caseIgnoreIA5Match
+ SYNTAX 'IA5String{128}' SINGLE-VALUE )
+
+ ( nisSchema.1.21 NAME 'ipNetmaskNumber'
+ DESC 'IP netmask as a dotted decimal, eg. 255.255.255.0,
+ omitting leading zeros'
+ EQUALITY caseIgnoreIA5Match
+ SYNTAX 'IA5String{128}' SINGLE-VALUE )
+
+ ( nisSchema.1.22 NAME 'macAddress'
+ DESC 'MAC address in maximal, colon separated hex
+ notation, eg. 00:00:92:90:ee:e2'
+ EQUALITY caseIgnoreIA5Match
+ SYNTAX 'IA5String{128}' )
+
+ ( nisSchema.1.23 NAME 'bootParameter'
+ DESC 'rpc.bootparamd parameter'
+ SYNTAX 'bootParameterSyntax' )
+
+ ( nisSchema.1.24 NAME 'bootFile'
+ DESC 'Boot image name'
+ EQUALITY caseExactIA5Match
+ SYNTAX 'IA5String' )
+
+ ( nisSchema.1.26 NAME 'nisMapName'
+ SUP name )
+
+ ( nisSchema.1.27 NAME 'nisMapEntry'
+ EQUALITY caseExactIA5Match
+ SUBSTRINGS caseExactIA5SubstringsMatch
+ SYNTAX 'IA5String{1024}' SINGLE-VALUE )
+
+4. Class definitions
+
+ This section contains class definitions to be implemented by DUAs
+ supporting the schema.
+
+ The rfc822MailGroup object class MAY be used to represent a mail
+ group for the purpose of alias expansion. Several alternative schemes
+ for mail routing and delivery using LDAP directories, which are
+ outside the scope of this document.
+
+ ( nisSchema.2.0 NAME 'posixAccount' SUP top AUXILIARY
+ DESC 'Abstraction of an account with POSIX attributes'
+ MUST ( cn $ uid $ uidNumber $ gidNumber $ homeDirectory )
+ MAY ( userPassword $ loginShell $ gecos $ description ) )
+
+
+
+
+Howard Experimental [Page 8]
+
+RFC 2307 Using LDAP as a Network Information Service March 1998
+
+
+ ( nisSchema.2.1 NAME 'shadowAccount' SUP top AUXILIARY
+ DESC 'Additional attributes for shadow passwords'
+ MUST uid
+ MAY ( userPassword $ shadowLastChange $ shadowMin
+ shadowMax $ shadowWarning $ shadowInactive $
+ shadowExpire $ shadowFlag $ description ) )
+
+ ( nisSchema.2.2 NAME 'posixGroup' SUP top STRUCTURAL
+ DESC 'Abstraction of a group of accounts'
+ MUST ( cn $ gidNumber )
+ MAY ( userPassword $ memberUid $ description ) )
+
+ ( nisSchema.2.3 NAME 'ipService' SUP top STRUCTURAL
+ DESC 'Abstraction an Internet Protocol service.
+ Maps an IP port and protocol (such as tcp or udp)
+ to one or more names; the distinguished value of
+ the cn attribute denotes the service's canonical
+ name'
+ MUST ( cn $ ipServicePort $ ipServiceProtocol )
+ MAY ( description ) )
+
+ ( nisSchema.2.4 NAME 'ipProtocol' SUP top STRUCTURAL
+ DESC 'Abstraction of an IP protocol. Maps a protocol number
+ to one or more names. The distinguished value of the cn
+ attribute denotes the protocol's canonical name'
+ MUST ( cn $ ipProtocolNumber $ description )
+ MAY description )
+
+ ( nisSchema.2.5 NAME 'oncRpc' SUP top STRUCTURAL
+ DESC 'Abstraction of an Open Network Computing (ONC)
+ [RFC1057] Remote Procedure Call (RPC) binding.
+ This class maps an ONC RPC number to a name.
+ The distinguished value of the cn attribute denotes
+ the RPC service's canonical name'
+ MUST ( cn $ oncRpcNumber $ description )
+ MAY description )
+
+ ( nisSchema.2.6 NAME 'ipHost' SUP top AUXILIARY
+
+ DESC 'Abstraction of a host, an IP device. The distinguished
+ value of the cn attribute denotes the host's canonical
+ name. Device SHOULD be used as a structural class'
+ MUST ( cn $ ipHostNumber )
+ MAY ( l $ description $ manager ) )
+
+ ( nisSchema.2.7 NAME 'ipNetwork' SUP top STRUCTURAL
+ DESC 'Abstraction of a network. The distinguished value of
+ the cn attribute denotes the network's canonical name'
+
+
+
+Howard Experimental [Page 9]
+
+RFC 2307 Using LDAP as a Network Information Service March 1998
+
+
+ MUST ( cn $ ipNetworkNumber )
+ MAY ( ipNetmaskNumber $ l $ description $ manager ) )
+
+ ( nisSchema.2.8 NAME 'nisNetgroup' SUP top STRUCTURAL
+ DESC 'Abstraction of a netgroup. May refer to other netgroups'
+ MUST cn
+ MAY ( nisNetgroupTriple $ memberNisNetgroup $ description ) )
+
+ ( nisSchema.2.09 NAME 'nisMap' SUP top STRUCTURAL
+ DESC 'A generic abstraction of a NIS map'
+ MUST nisMapName
+ MAY description )
+
+ ( nisSchema.2.10 NAME 'nisObject' SUP top STRUCTURAL
+ DESC 'An entry in a NIS map'
+ MUST ( cn $ nisMapEntry $ nisMapName )
+ MAY description )
+
+ ( nisSchema.2.11 NAME 'ieee802Device' SUP top AUXILIARY
+ DESC 'A device with a MAC address; device SHOULD be
+ used as a structural class'
+ MAY macAddress )
+
+ ( nisSchema.2.12 NAME 'bootableDevice' SUP top AUXILIARY
+ DESC 'A device with boot parameters; device SHOULD be
+ used as a structural class'
+ MAY ( bootFile $ bootParameter ) )
+
+5. Implementation details
+
+5.1. Suggested resolution methods
+
+ The preferred means of directing a client application (one using the
+ shared services of the C library) to use LDAP as its information
+ source for the functions listed in 5.2 is to modify the source code
+ to directly query LDAP. As the source to commercial C libraries and
+ applications is rarely available to the end-user, one could emulate a
+ supported nameservice (such as NIS). (This is also an appropriate
+ opportunity to perform caching of entries across process address
+ spaces.) In the case of NIS, reference implementations are widely
+ available and the RPC interface is well known.
+
+ The means by which the operating system is directed to use LDAP is
+ implementation dependent. For example, some operating systems and C
+ libraries support end-user extensible resolvers using dynamically
+ loadable libraries and a nameservice "switch". The means in which the
+ DUA locates LDAP servers is also implementation dependent.
+
+
+
+
+Howard Experimental [Page 10]
+
+RFC 2307 Using LDAP as a Network Information Service March 1998
+
+
+5.2. Affected library functions
+
+ The following functions are typically found in the C libraries of
+ most UNIX and POSIX compliant systems. An LDAP search filter
+ [RFC2254] which may be used to satisfy the function call is included
+ alongside each function name. Parameters are denoted by %s and %d for
+ string and integer arguments, respectively. Long lines are broken.
+
+ getpwnam() (&(objectClass=posixAccount)(uid=%s))
+ getpwuid() (&(objectClass=posixAccount)
+ (uidNumber=%d))
+ getpwent() (objectClass=posixAccount)
+
+ getspnam() (&(objectClass=shadowAccount)(uid=%s))
+ getspent() (objectClass=shadowAccount)
+
+ getgrnam() (&(objectClass=posixGroup)(cn=%s))
+ getgrgid() (&(objectClass=posixGroup)
+ (gidNumber=%d))
+ getgrent() (objectClass=posixGroup)
+
+ getservbyname() (&(objectClass=ipService)
+ (cn=%s)(ipServiceProtocol=%s))
+ getservbyport() (&(objectClass=ipService)
+ (ipServicePort=%d)
+ (ipServiceProtocol=%s))
+ getservent() (objectClass=ipService)
+
+ getrpcbyname() (&(objectClass=oncRpc)(cn=%s))
+ getrpcbynumber() (&(objectClass=oncRpc)(oncRpcNumber=%d))
+ getrpcent() (objectClass=oncRpc)
+
+ getprotobyname() (&(objectClass=ipProtocol)(cn=%s))
+ getprotobynumber() (&(objectClass=ipProtocol)
+ (ipProtocolNumber=%d))
+ getprotoent() (objectClass=ipProtocol)
+
+ gethostbyname() (&(objectClass=ipHost)(cn=%s))
+ gethostbyaddr() (&(objectClass=ipHost)(ipHostNumber=%s))
+ gethostent() (objectClass=ipHost)
+
+ getnetbyname() (&(objectClass=ipNetwork)(cn=%s))
+ getnetbyaddr() (&(objectClass=ipNetwork)
+ (ipNetworkNumber=%s))
+ getnetent() (objectClass=ipNetwork)
+
+ setnetgrent() (&(objectClass=nisNetgroup)(cn=%s))
+
+
+
+
+Howard Experimental [Page 11]
+
+RFC 2307 Using LDAP as a Network Information Service March 1998
+
+
+5.3. Interpreting user and group entries
+
+ User and group resolution is initiated by the functions prefixed by
+ getpw and getgr respectively. The uid attribute contains the user's
+ login name. The cn attribute, in posixGroup entries, contains the
+ group's name.
+
+ The account object class provides a convenient structural class for
+ posixAccount, and SHOULD be used where additional attributes are not
+ required.
+
+ It is suggested that uid and cn are used as the RDN attribute type
+ for posixAccount and posixGroup entries, respectively.
+
+ An account's GECOS field is preferably determined by a value of the
+ gecos attribute. If no gecos attribute exists, the value of the cn
+ attribute MUST be used. (The existence of the gecos attribute allows
+ information embedded in the GECOS field, such as a user's telephone
+ number, to be returned to the client without overloading the cn
+ attribute. It also accommodates directories where the common name
+ does not contain the user's full name.)
+
+ An entry of class posixAccount, posixGroup, or shadowAccount without
+ a userPassword attribute MUST NOT be used for authentication. The
+ client should be returned a non-matchable password such as "x".
+
+ userPassword values MUST be represented by following syntax:
+
+ passwordvalue = schemeprefix encryptedpassword
+ schemeprefix = "{" scheme "}"
+ scheme = "crypt" / "md5" / "sha" / altscheme
+ altscheme = "x-" keystring
+ encryptedpassword = encrypted password
+
+ The encrypted password contains of a plaintext key hashed using the
+ algorithm scheme.
+
+ userPassword values which do not adhere to this syntax MUST NOT be
+ used for authentication. The DUA MUST iterate through the values of
+ the attribute until a value matching the above syntax is found. Only
+ if encryptedpassword is an empty string does the user have no
+ password. DUAs are not required to consider encryption schemes which
+ the client will not recognize; in most cases, it may be sufficient to
+ consider only "crypt".
+
+ Below is an example of a userPassword attribute:
+
+ userPassword: {crypt}X5/DBrWPOQQaI
+
+
+
+Howard Experimental [Page 12]
+
+RFC 2307 Using LDAP as a Network Information Service March 1998
+
+
+ A future standard may specify LDAP v3 attribute descriptions to
+ represent hashed userPasswords, as noted below. This schema MUST NOT
+ be used with LDAP v2 DUAs and DSAs.
+
+ attributetype = attributename sep attributeoption
+ attributename = "userPassword"
+ sep = ";"
+ attributeoption = schemeclass "-" scheme
+ schemeclass = "hash" / altschemeclass
+ scheme = "crypt" / "md5" / "sha" / altscheme
+ altschemeclass = "x-" keystring
+ altscheme = keystring
+
+
+ Below is an example of a userPassword attribute, represented with an
+ LDAP v3 attribute description:
+
+ userPassword;hash-crypt: X5/DBrWPOQQaI
+
+
+ A DUA MAY utilise the attributes in the shadowAccount class to
+ provide shadow password service (getspnam() and getspent()). In such
+ cases, the DUA MUST NOT make use of the userPassword attribute for
+ getpwnam() et al, and MUST return a non-matchable password (such as
+ "x") to the client instead.
+
+5.4. Interpreting hosts and networks
+
+ The ipHostNumber and ipNetworkNumber attributes are defined in
+ preference to dNSRecord (defined in [RFC1279]), in order to simplify
+ the DUA's role in interpreting entries in the directory. A dNSRecord
+ expresses a complete resource record, including time to live and
+ class data, which is extraneous to this schema.
+
+ Additionally, the ipHost and ipNetwork classes permit a host or
+ network (respectively) and all its aliases to be represented by a
+ single entry in the directory. This is not necessarily possible if a
+ DNS resource record is mapped directly to an LDAP entry.
+ Implementations that wish to use LDAP to master DNS zone information
+ are not precluded from doing so, and may simply avoid the ipHost and
+ ipNetwork classes.
+
+ This document redefines, although not exclusively, the ipNetwork
+ class defined in [RFC1279], in order to achieve consistent naming
+ with ipHost. The ipNetworkNumber attribute is also used in the
+ siteContact object class [ROSE].
+
+
+
+
+
+Howard Experimental [Page 13]
+
+RFC 2307 Using LDAP as a Network Information Service March 1998
+
+
+ The trailing zeros in a network address MUST be omitted. CIDR-style
+ network addresses (eg. 192.168.1/24) MAY be used.
+
+ Hosts with IPv6 addresses MUST be written in their "preferred" form
+ as defined in section 2.2.1 of [RFC1884], such that all components of
+ the address are indicated and leading zeros are omitted. This
+ provides a consistent means of resolving ipHosts by address.
+
+5.5. Interpreting other entities
+
+ In general, a one-to-one mapping between entities and LDAP entries is
+ proposed, in that each entity has exactly one representation in the
+ DIT. In some cases this is not feasible; for example, a service which
+ is represented in more than one protocol domain. Consider the
+ following entry:
+
+ dn: cn=domain, dc=aja, dc=com
+ cn: domain
+ cn: nameserver
+ objectClass: top
+ objectClass: ipService
+ ipServicePort: 53
+ ipServiceProtocol: tcp
+ ipServiceProtocol: udp
+
+ This entry MUST map to the following two (2) services entities:
+
+ domain 53/tcp nameserver
+ domain 53/udp nameserver
+
+ While the above two entities may be represented as separate LDAP
+ entities, with different distinguished names (such as
+ cn=domain+ipServiceProtocol=tcp, ... and
+ cn=domain+ipServiceProtocol=udp, ...) it is convenient to represent
+ them as a single entry. (If a service is represented in multiple
+ protocol domains with different ports, then multiple entries are
+ required; multivalued RDNs may be used to distinguish them.)
+
+ With the exception of userPassword values, which are parsed according
+ to the syntax considered in section 5.2, any empty values (consisting
+ of a zero length string) are returned by the DUA to the client. The
+ DUA MUST reject any entries which do not conform to the schema
+ (missing mandatory attributes). Non-conforming entries SHOULD be
+ ignored while enumerating entries.
+
+ The nisObject object class MAY be used as a generic means of
+ representing NIS entities. Its use is not encouraged; where support
+ for entities not described in this schema is desired, an appropriate
+
+
+
+Howard Experimental [Page 14]
+
+RFC 2307 Using LDAP as a Network Information Service March 1998
+
+
+ schema should be devised. Implementors are strongly advised to
+ support end-user extensible mappings between NIS entities and object
+ classes. (Where the nisObject class is used, the nisMapName attribute
+ may be used as a RDN.)
+
+5.6. Canonicalizing entries with multi-valued naming attributes
+
+ For entities such as hosts, services, networks, protocols, and RPCs,
+ where there may be one or more aliases, the respective entry's
+ relative distinguished name SHOULD be used to determine the canonical
+ name. Any other values for the same attribute are used as aliases.
+ For example, the service described in section 5.5 has the canonical
+ name "domain" and exactly one alias, "nameserver".
+
+ The schema in this document generally only defines one attribute per
+ class which is suitable for distinguishing an entity (excluding any
+ attributes with integer syntax; it is assumed that entries will be
+ distinguished on name). Usually, this is the common name (cn)
+ attribute. This aids the DUA in determining the canonical name of an
+ entity, as it can examine the value of the relative distinguished
+ name. Aliases are thus any values of the distinguishing attribute
+ (such as cn) which do not match the canonical name of the entity.
+
+ In the event that a different attribute is used to distinguish the
+ entry, as may be the case where these object classes are used as
+ auxiliary classes, the entry's canonical name may not be present in
+ the RDN. In this case, the DUA MUST choose one of the non-
+ distinguished values to represent the entity's canonical name. As the
+ directory server guarantees no ordering of attribute values, it may
+ not be possible to distinguish an entry deterministically. This
+ ambiguity SHOULD NOT be resolved by mapping one directory entry into
+ multiple entities.
+
+6. Implementation focus
+
+ A NIS server which uses LDAP instead of local files has been
+ developed which supports the schema defined in this document.
+
+ A reference implementation of the C library resolution code has been
+ written for the Free Software Foundation. It may support other C
+ libraries which support the Name Service Switch (NSS) or the
+ Information Retrieval Service (IRS).
+
+ The author has made available a freely distributable set of scripts
+ which parses local databases such as /etc/passwd and /etc/hosts into
+ a form suitable for loading into an LDAP server.
+
+
+
+
+
+Howard Experimental [Page 15]
+
+RFC 2307 Using LDAP as a Network Information Service March 1998
+
+
+7. Security Considerations
+
+ The entirety of related security considerations are outside the scope
+ of this document. It is noted that making passwords encrypted with a
+ widely understood hash function (such as crypt()) available to non-
+ privileged users is dangerous because it exposes them to dictionary
+ and brute-force attacks. This is proposed only for compatibility
+ with existing UNIX system implementations. Sites where security is
+ critical SHOULD consider using a strong authentication service for
+ user authentication.
+
+ Alternatively, the encrypted password could be made available only to
+ a subset of privileged DUAs, which would provide "shadow" password
+ service to client applications. This may be difficult to enforce.
+
+ Because the schema represents operating system-level entities, access
+ to these entities SHOULD be granted on a discretionary basis. (There
+ is little point in restricting access to data which will be
+ republished without restriction, however.) It is particularly
+ important that only administrators can modify entries defined in this
+ schema, with the exception of allowing a principal to change their
+ password (which may be done on behalf of the user by a client bound
+ as a superior principal, such that password restrictions may be
+ enforced). For example, if a user were allowed to change the value of
+ their uidNumber attribute, they could subvert security by
+ equivalencing their account with the superuser account.
+
+ A subtree of the DIT which is to be republished by a DUA (such as a
+ NIS gateway) SHOULD be within the same administrative domain that the
+ republishing DUA represents. (For example, principals outside an
+ organization, while conceivably part of the DIT, should not be
+ considered with the same degree of authority as those within the
+ organization.)
+
+ Finally, care should be exercised with integer attributes of a
+ sensitive nature (particularly the uidNumber and gidNumber
+ attributes) which contain zero-length values. DUAs MAY treat such
+ values as corresponding to the "nobody" or "nogroup" user and group,
+ respectively.
+
+8. Acknowledgements
+
+ Thanks to Leif Hedstrom of Netscape Communications Corporation,
+ Michael Grant and Rosanna Lee of Sun Microsystems Inc., Ed Reed of
+ Novell Inc., and Mark Wahl of Critical Angle Inc. for their valuable
+ contributions to the development of this schema. Thanks to Andrew
+ Josey of The Open Group for clarifying the use of the UNIX trademark,
+ and to Tim Howes and Peter J. Cherny for their support.
+
+
+
+Howard Experimental [Page 16]
+
+RFC 2307 Using LDAP as a Network Information Service March 1998
+
+
+ UNIX is a registered trademark of The Open Group.
+
+9. References
+
+ [RFC1057]
+ Sun Microsystems, Inc., "RPC: Remote Procedure Call: Protocol
+ Specification Version 2", RFC 1057, June 1988.
+
+ [RFC1279]
+ Kille, S., "X.500 and Domains", RFC 1279, November 1991.
+
+ [RFC1884]
+ Hinden, R., and S. Deering, "IP Version 6 Addressing
+ Architecture", RFC 1884, December 1995.
+
+ [RFC2119]
+ Bradner, S., "Key Words for use in RFCs to Indicate Requirement
+ Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2251]
+ Wahl, M., Howes, T., and S. Kille, "Lightweight Directory Access
+ Protocol (v3)", RFC 2251, December 1997.
+
+ [RFC2252]
+ Wahl, M., Coulbeck, A., Howes, T., and S. Kille, "Lightweight
+ Directory Access Protocol (v3): Attribute Syntax Definitions",
+ RFC 2252, December 1997.
+
+ [RFC2254]
+ Howes, T., "The String Representation of LDAP Search Filters",
+ RFC 2254, December 1997.
+
+ [RFC2256]
+ Wahl, M., "A Summary of the X.500(96) User Schema for use with
+ LDAPv3", RFC 2256, December 1997.
+
+ [ROSE]
+ M. T. Rose, "The Little Black Book: Mail Bonding with OSI
+ Directory Services", ISBN 0-13-683210-5, Prentice-Hall, Inc.,
+ 1992.
+
+ [X500]
+ "Information Processing Systems - Open Systems Interconnection -
+ The Directory: Overview of Concepts, Models and Service",
+ ISO/IEC JTC 1/SC21, International Standard 9594-1, 1988.
+
+
+
+
+
+
+Howard Experimental [Page 17]
+
+RFC 2307 Using LDAP as a Network Information Service March 1998
+
+
+ [XOPEN]
+ ISO/IEC 9945-1:1990, Information Technology - Portable Operating
+ Systems Interface (POSIX) - Part 1: Systems Application
+ Programming Interface (API) [C Language]
+
+10. Author's Address
+
+ Luke Howard
+ PO Box 59
+ Central Park Vic 3145
+ Australia
+
+ EMail: lukeh at xedoc.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Howard Experimental [Page 18]
+
+RFC 2307 Using LDAP as a Network Information Service March 1998
+
+
+A. Example entries
+
+ The examples described in this section are provided to illustrate the
+ schema described in this memo. They are not meant to be exhaustive.
+
+ The following entry is an example of the posixAccount class:
+
+ dn: uid=lester, dc=aja, dc=com
+ objectClass: top
+ objectClass: account
+ objectClass: posixAccount
+ uid: lester
+ cn: Lester the Nightfly
+ userPassword: {crypt}X5/DBrWPOQQaI
+ gecos: Lester
+ loginShell: /bin/csh
+ uidNumber: 10
+ gidNumber: 10
+ homeDirectory: /home/lester
+
+
+ This corresponds the UNIX system password file entry:
+
+ lester:X5/DBrWPOQQaI:10:10:Lester:/home/lester:/bin/sh
+
+ The following entry is an example of the ipHost class:
+
+ dn: cn=peg.aja.com, dc=aja, dc=com
+ objectClass: top
+ objectClass: device
+ objectClass: ipHost
+ objectClass: bootableDevice
+ objectClass: ieee802Device
+ cn: peg.aja.com
+ cn: www.aja.com
+ ipHostNumber: 10.0.0.1
+ macAddress: 00:00:92:90:ee:e2
+ bootFile: mach
+ bootParameter: root=fs:/nfsroot/peg
+ bootParameter: swap=fs:/nfsswap/peg
+ bootParameter: dump=fs:/nfsdump/peg
+
+ This entry represents the host canonically peg.aja.com, also known as
+ www.aja.com. The Ethernet address and four boot parameters are also
+ specified.
+
+
+
+
+
+
+Howard Experimental [Page 19]
+
+RFC 2307 Using LDAP as a Network Information Service March 1998
+
+
+ An example of the nisNetgroup class:
+
+ dn: cn=nightfly, dc=aja, dc=com
+ objectClass: top
+ objectClass: nisNetgroup
+ cn: nightfly
+ nisNetgroupTriple: (charlemagne,peg,dunes.aja.com)
+ nisNetgroupTriple: (lester,-,)
+ memberNisNetgroup: kamakiriad
+
+ This entry represents the netgroup nightfly, which contains two
+ triples (the user charlemagne, the host peg, and the domain
+ dunes.aja.com; and, the user lester, no host, and any domain) and one
+ netgroup (kamakiriad).
+
+ Finally, an example of the nisObject class:
+
+ dn: nisMapName=tracks, dc=dunes, dc=aja, dc=com
+ objectClass: top
+ objectClass: nisMap
+ nisMapName: tracks
+
+ dn: cn=Maxine, nisMapName=tracks, dc=dunes, dc=aja, dc=com
+ objectClass: top
+ objectClass: nisObject
+ cn: Maxine
+ nisMapName: tracks
+ nisMapEntry: Nightfly$4
+
+ This entry represents the NIS map tracks, and a single map entry.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Howard Experimental [Page 20]
+
+RFC 2307 Using LDAP as a Network Information Service March 1998
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (1998). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Howard Experimental [Page 21]
+
Added: openldap/vendor/openldap-release/doc/rfc/rfc2377.txt
===================================================================
--- openldap/vendor/openldap-release/doc/rfc/rfc2377.txt (rev 0)
+++ openldap/vendor/openldap-release/doc/rfc/rfc2377.txt 2007-09-15 10:38:52 UTC (rev 844)
@@ -0,0 +1,1011 @@
+
+
+
+
+
+
+Network Working Group A. Grimstad
+Request for Comments: 2377 R. Huber
+Category: Informational AT&T
+ S. Sataluri
+ Lucent Technologies
+ M. Wahl
+ Critical Angle Inc.
+ September 1998
+
+
+ Naming Plan for Internet Directory-Enabled Applications
+
+Status of this Memo
+
+ This memo provides information for the Internet community. It does
+ not specify an Internet standard of any kind. Distribution of this
+ memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (1998). All Rights Reserved.
+
+Abstract
+
+ Application of the conventional X.500 approach to naming has
+ heretofore, in the experience of the authors, proven to be an
+ obstacle to the wide deployment of directory-enabled applications on
+ the Internet. We propose a new directory naming plan that leverages
+ the strengths of the most popular and successful Internet naming
+ schemes for naming objects in a hierarchical directory. This plan
+ can, we believe, by extending the X.500 approach to naming,
+ facilitate the creation of an Internet White Pages Service (IWPS) and
+ other directory-enabled applications by overcoming the problems
+ encountered by those using the conventional X.500 approach.
+
+1.0 Executive Summary
+
+ Application of the conventional X.500 approach to naming has
+ heretofore, in the experience of the authors, proven to be an
+ obstacle to the wide deployment of directory-enabled applications on
+ the Internet. The required registration infrastructure is either
+ non-existent or largely ignored. The infrastructure that does exist
+ is cumbersome to use and tends to produce counterproductive results.
+ The attributes used for naming have been confusing for users and
+ inflexible to managers and operators of directory servers.
+
+
+
+
+
+
+Grimstad, et. al. Informational [Page 1]
+
+RFC 2377 A Directory Naming Plan September 1998
+
+
+ This paper describes a directory naming plan for the construction of
+ an Internet directory infrastructure to support directory-enabled
+ applications that can serve as an alternative (or extension) to the
+ conventional X.500 approach.
+
+ The plan has the following two main features. First, it bases the
+ root and upper portions of the name hierarchy on the existing
+ infrastructure of names from the Domain Name System (DNS). This
+ component of the plan makes use of the ideas described in the
+ companion paper to this plan, "Using Domains in LDAP Distinguished
+ Names" [1]. And second, it provides a number of options for the
+ assignment of names to directory leaf objects such as person objects,
+ including an option that allows the reuse of existing Internet
+ identifiers for people.
+
+ Just as the conventional X.500 style of naming is not a formal
+ standard, use of the naming plan described here is not obligatory for
+ directory-enabled applications on the Internet. Other approaches are
+ permissible. However, we believe widespread use of this plan will
+ largely eliminate naming as a typically thorny issue when
+ administrators set up an LDAP-based directory service. Further, we
+ strongly encourage developers of directory-enabled products,
+ especially LDAP clients and user interfaces, to assume that this
+ naming plan will see widespread use and design their products
+ accordingly.
+
+ Here, in summary, is our proposal.
+
+ The upper portions of the hierarchical directory tree should be
+ constructed using the components of registered DNS names using the
+ domain component attribute "dc". The directory name for the
+ organization having the domain name "acme.com" will then be, e.g.,
+
+ dc=acme, dc=com
+
+ Organizations can add additional directory structure, for example to
+ support implementation of access control lists or partitioning of
+ their directory information, by using registered subdomains of DNS
+ names, e.g., the subdomain "corporate.acme.com" can be used as the
+ basis for the directory name
+
+ dc=corporate, dc=acme, dc=com
+
+ For naming directory leaf objects such as persons, groups, server
+ applications and certification authorities in a hierarchical
+ directory, we propose the use of either the "uid" (user identifier)
+ or the "cn" (common name) attribute for the relative distinguished
+ name. This plan does not constrain how these two attributes are used.
+
+
+
+Grimstad, et. al. Informational [Page 2]
+
+RFC 2377 A Directory Naming Plan September 1998
+
+
+ One approach to their use, for example, is to employ the uid
+ attribute as the RDN when reusing an existing store of identifiers
+ and the cn attribute as the RDN when creating new identifiers
+ specifically for the directory. A convenient existing identification
+ scheme for person objects is the RFC822 mailbox identifier. So an RDN
+ for person employing this store of identifiers would be, e.g.,
+
+ uid=John.Smith at acme.com
+
+ For leaf objects not conveniently identified with such a scheme, the
+ "cn" attribute is used, e.g.,
+
+ cn=Reading Room
+
+ Directory distinguished names will thus have the following structure,
+ e.g.,
+
+ uid=John.Smith at acme.com, dc=acme, dc=com
+ uid=Mary.Jones at acme.com, dc=corporate, dc=acme, dc=com
+ uid=J.Smith at worldnet.att.net, dc=legal, dc=acme, dc=com
+ cn=Reading Room, dc=physics, dc=national-lab, dc=edu
+
+2.0 The Problem
+
+ The X.500 Directory model [2] can be used to create a world-wide
+ distributed directory. The Internet X.500 Directory Pilot has been
+ operational for several years and has grown to a size of about 1.5
+ million entries of varying quality. The rate of growth of the pilot
+ is far lower than the rate of growth of the Internet during the pilot
+ period.
+
+ There are a substantial number of contributing factors that have
+ inhibited the growth of this pilot. The common X.500 approach to
+ naming, while not the preponderant problem, has contributed in
+ several ways to limit the growth of an Internet White Pages Service
+ based on X.500.
+
+ The conventional way to construct names in the X.500 community is
+ documented as an informative (i.e., not officially standardized)
+ Annex B to X.521. The relative distinguished name (RDN) of a user
+ consists of a common name (cn) attribute. This is meant to be what --
+ in the user's particular society -- is customarily understood to be
+ the name of that user. The distinguished name of a user is the
+ combination of the name of some general object, such as an
+ organization or a geographical unit, with the common name. There are
+ two main problems with this style of name construction.
+
+
+
+
+
+Grimstad, et. al. Informational [Page 3]
+
+RFC 2377 A Directory Naming Plan September 1998
+
+
+ First, the common name attribute, while seeming to be user-friendly,
+ cannot be used generally as an RDN in practice. In any significant
+ set of users to be named under the same Directory Information Tree
+ (DIT) node there will be collisions on common name. There is no way
+ to overcome this other than either by forcing uniqueness on common
+ names, something they do not possess, or by using an additional
+ attribute to prevent collisions. This additional attribute normally
+ needs to be unique in a much larger context to have any practical
+ value. The end result is a RDN that is very long and unpopular with
+ users.
+
+ Second, and more serious, X.500 has not been able to use any
+ significant number of pre-existing names. Since X.500 naming models
+ typically use organization names as part of the hierarchy [2, 3],
+ organization names must be registered. As organization names are
+ frequently tied to trademarks and are used in sales and promotions,
+ registration can be a difficult and acrimonious process.
+
+ The North American Directory Forum (NADF, now the North Atlantic
+ Directory Forum but still the NADF) proposed to avoid the problem of
+ registration by using names that were already registered in the
+ "civil naming infrastructure" [4][5]. Directory distinguished names
+ would be based on an organization's legal name as recognized by some
+ governmental agency (county clerk, state secretary of state, etc.) or
+ other registering entity such as ANSI.
+
+ This scheme has the significant advantage of keeping directory
+ service providers out of disputes about the right to use a particular
+ name, but it leads to rather obscure names. Among these obscurities,
+ the legal name almost invariably takes a form that is less familiar
+ and longer than what users typically associate with the organization.
+ For example, in the US a large proportion of legal organization names
+ end with the text ", Inc." as in "Acme, Inc." Moreover, in the case
+ of the US, the civil naming infrastructure does not operate
+ nationally, so the organization names it provides must be located
+ under state and regional DIT nodes, making them difficult to find
+ while browsing the directory. NADF proposes a way to algorithmically
+ derive multi-attribute RDNs which would allow placement of entries or
+ aliases in more convenient places in the DIT, but these derived names
+ are cumbersome and unpopular. For example, suppose Nadir is an
+ organization that is registered in New Jersey civil naming
+ infrastructure under the name "Nadir Networks, Inc." Its civil
+ distinguished name (DN) would then be
+
+ o="Nadir Networks, Inc.", st=New Jersey, c=US
+
+
+
+
+
+
+Grimstad, et. al. Informational [Page 4]
+
+RFC 2377 A Directory Naming Plan September 1998
+
+
+ while its derived name which is unambiguous under c=US directly is
+
+ o="Nadir Networks, Inc." + st=New Jersey, c=US
+
+ More generally, the requirement for registration of organizations in
+ X.500 naming has led to the establishment of national registration
+ authorities whose function is mainly limited to assignment of X.500
+ organization names. Because of the very limited attraction of X.500,
+ interest in registering an organization with one of these national
+ authorities has been minimal. Finally, multi-national organizations
+ are frustrated by a lack of an international registration authority.
+
+3.0 Requirements
+
+ A directory naming plan must provide a guide for the construction of
+ names (identifiers, labels) for directory objects that are
+ unambiguous (identify only one directory object) within some context
+ (namespace), at a minimum within one isolated directory server.
+
+ A directory object is simply a set of attribute values. The
+ association between a real-world object and a directory object is
+ made by directory-enabled applications and is, in the general case,
+ one to many.
+
+ The following additional naming characteristics are requirements that
+ this naming plan seeks to satisfy:
+
+ a) hierarchical
+
+ The Internet, consisting of a very large number of objects and
+ management domains, requires hierarchical names. Such names permit
+ delegation in the name assignment process and partitioning of
+ directory information among directory servers.
+
+ b) friendly to loose coupling of directory servers
+
+ One purpose of this naming plan is to define a naming pattern that
+ will facilitate one form or another of loose coupling of potentially
+ autonomous directory servers into a larger system.
+
+ A name in such a loosely-coupled system should unambiguously identify
+ one real-world object. The real-world object may, however, be
+ represented differently (i.e. by different directory objects having
+ different attributes but the same DN) in different (e.g.
+ independently managed) servers in the loosely-coupled system. The
+ plan does not attempt to produce names to overcome this likely
+ scenario. That is, it does not attempt to produce a single namespace
+ for all directory objects. (This issue is considered in more detail
+
+
+
+Grimstad, et. al. Informational [Page 5]
+
+RFC 2377 A Directory Naming Plan September 1998
+
+
+ in Section 5.1.)
+
+ c) readily usable by LDAP clients and servers
+
+ As of this writing, a substantial number of the Lightweight Directory
+ Access Protocol (LDAP) [6][7] implementations are currently available
+ or soon will be. The names specified by this naming plan should be
+ readily usable by these implementations and applications based on
+ them.
+
+ d) friendly to re-use of existing Internet name registries
+
+ As described in Section 2 above, creation of new global name
+ registries has been highly problematic. Therefore, a fundamental
+ requirement this plan addresses is to enable the reuse of existing
+ Internet name registries such as DNS names and RFC822 mailbox
+ identifiers when constructing directory names.
+
+ e) minimally user-friendly
+
+ Although we expect that user interfaces of directory-enabled
+ applications will avoid exposing users to DNs, it is unlikely that
+ users can be totally insulated from them. For this reason, the
+ naming plan should permit use of familiar information in name
+ construction. Minimally, a user should be capable of recognizing the
+ information encoded in his/her own DN. Names that are totally opaque
+ to users cannot meet this requirement.
+
+4.0 Name Construction
+
+ The paper assumes familiarity with the terminology and concepts
+ behind the terms distinguished name (DN) and relative distinguished
+ name (RDN) [2][8][9].
+
+ We describe how DNs can be constructed using three attribute types,
+ domainComponent (dc), userID (uid) and commonName (cn). They are
+ each described in turn.
+
+4.1 Domain Component (dc)
+
+ The domain component attribute is defined and registered in RFC1274
+ [3][10]. It is used in the construction of a DN from a domain name.
+ Details of the construction algorithm is described in "Using Domains
+ in LDAP Distinguished Names" [1].
+
+ An organization wishing to deploy a directory following this naming
+ plan would proceed as follows. Consider an organization, for example
+ "Acme, Inc.", having the registered domain name "acme.com". It would
+
+
+
+Grimstad, et. al. Informational [Page 6]
+
+RFC 2377 A Directory Naming Plan September 1998
+
+
+ construct the DN
+
+ dc=acme, dc=com
+
+ from its domain name. It would then use this DN as the root of its
+ subtree of directory information.
+
+ The DN itself can be used to identify a directory organization object
+ that represents information about the organization. The directory
+ schema required to enable this is described below in section 5.2.
+
+ The subordinates of the DN will be directory objects related to the
+ organization. The domain component attribute can be used to name
+ subdivisions of the organization such as organizational units and
+ localities. Acme, for example, might use the domain names
+ "corporate.acme.com" and "richmond.acme.com" to construct the names
+
+ dc=corporate, dc=acme, dc=com
+ dc=richmond, dc=acme, dc=com
+
+ under which to place its directory objects. The directory schema
+ required to name organizationalUnit and locality objects in this way
+ is described below in section 5.2.
+
+ Note that subdivisions of the organization such as organizational
+ units and localities could also be assigned RDNs using the
+ conventional X.500 naming attributes, e.g.
+
+ ou=corporate, dc=acme, dc=com
+ l=richmond, dc=acme, dc=com.
+
+ Use of the dc attribute for the RDN of directory objects of class
+ "domain" is also possible [1].
+
+4.2 User ID (uid)
+
+ The userid (uid) attribute is defined and registered in RFC1274
+ [3][10].
+
+ This attribute may be used to construct the RDN for directory objects
+ subordinate to objects named according to the procedure described in
+ Section 4.1. This plan does not constrain how this attribute is
+ used.
+
+4.3 Common Name (cn)
+
+ The commonName (cn) attribute is defined and registered in X.500
+ [3][11].
+
+
+
+Grimstad, et. al. Informational [Page 7]
+
+RFC 2377 A Directory Naming Plan September 1998
+
+
+ This attribute may be used to construct the RDN for directory objects
+ subordinate to objects named according to the procedure described in
+ Section 4.1. This plan does not constrain how this attribute is
+ used.
+
+4.4 Examples of uid and cn Usage
+
+ Although this plan places no constraints on the use of the uid and cn
+ attributes for name construction, we would like to offer some
+ suggestions by way of examples.
+
+ In practice, we have used uid for the RDN for person objects were we
+ could make use of an existing registry of names and cn for other
+ objects.
+
+ Examples of existing registries of identifiers for person objects are
+ RFC822 mailbox identifiers, employee numbers and employee "handles".
+ Aside from the convenience to administrators of re-use of an existing
+ store of identifiers, if it is ever necessary to display to a user
+ his/her DN, there is some hope that it will be recognizable when such
+ identifiers are used.
+
+ We have found RFC822 mailbox identifiers a particularly convenient
+ source for name construction. When a person has several e-mail
+ addresses, one will be selected for the purpose of user
+ identification. We call this the "distinguished" e-mail address or
+ the "distinguished" RFC822 mailbox identifier for the user.
+
+ For example, if there is a user affiliated with the organization Acme
+ having distinguished e-mail address J.Smith at acme.com, the uid
+ attribute will be:
+
+ uid=J.Smith at acme.com
+
+ The domain component attributes of a user's DN will normally be
+ constructed from the domain name of his/her distinguished e-mail
+ address. That is, for the user uid=J.Smith at acme.com the domain
+ component attributes would typically be:
+
+ dc=acme, dc=com
+
+ The full LDAP DN for this user would then be:
+
+ uid=J.Smith at acme.com, dc=acme, dc=com
+
+ Directory administrators having several RFC822 identifiers to choose
+ from when constructing a DN for a user should consider the following
+ factors:
+
+
+
+Grimstad, et. al. Informational [Page 8]
+
+RFC 2377 A Directory Naming Plan September 1998
+
+
+ o Machine-independent addresses are likely to be more stable,
+ resulting in directory names that change less. Thus an
+ identifier such as:
+
+ js at acme.com
+
+ may well be preferable to one such as:
+
+ js at blaster.third-floor.acme.com.
+
+ o Use of some form of "handle" for the "local" part that is
+ distinct from a user's real name may result in fewer collisions
+ and thereby lessen user pain and suffering. Thus the
+ identifier:
+
+ js at acme.com
+
+ may well be preferable to one such as:
+
+ J.Smith at acme.com
+
+ Practical experience with use of the RFC822 mailbox identifier scheme
+ described here has shown that there are situations where it is
+ convenient to use such identifies for all users in a particular
+ population, although a few users do not, in fact, possess working
+ mailboxes. For example, an organization may have a existing unique
+ identification scheme for all employees that is used as a alias to
+ the employees' real mailboxes -- which may be quite heterogeneous in
+ structure. The identification scheme works for all employees to
+ identify unambiguously each employee; it only works as an e-mail
+ alias for those employees having real mailboxes. For this reason it
+ would be a bad assumption for directory-enabled applications to
+ assume the uid to be a valid mailbox; the value(s) of the mail
+ attribute should always be checked.
+
+ It is important to emphasize that the elements of the domain name of
+ an RFC822 identifier may, BUT NEED NOT, be the same as the domain
+ components of the DN. This means that the domain components provide
+ a degree of freedom to support access control or other directory
+ structuring requirements that need not be mechanically reflected in
+ the user's e-mail address. We do not want under any condition to
+ force the user's e-mail address to change just to facilitate a new
+ system requirement such as a modification in an access control
+ structure. It should also be noted that while we do not require that
+ the domain components match the RFC822 identifier, we DO require that
+ the concatenated domain components form a registered domain name,
+ that is, one that is represented in the DNS. This automatically
+ avoids name conflicts in the directory hierarchy.
+
+
+
+Grimstad, et. al. Informational [Page 9]
+
+RFC 2377 A Directory Naming Plan September 1998
+
+
+ To provide an example of a DN which deviates from what might be
+ considered the default structure, consider the following scenario.
+
+ Suppose that J.Smith needs to be granted special permissions to
+ information in the dc=acme, dc=com part of the LDAP DIT. Since it
+ will be, in general, easier to organize special users by their name
+ structure than via groups (an arbitrary collection of DNs), we use
+ subdomains for this purpose. Suppose the special permissions were
+ required by users in the MIS organizational unit. A subdomain
+ "mis.acme.com" is established, if it does not already exist,
+ according to normal DNS procedures. The special permissions will be
+ granted to users with the name structure:
+
+ uid=*, dc=mis, dc=acme, dc=com
+
+ The DN of J.Smith in this case will be:
+
+ uid=J.Smith at acme.com, dc=mis, dc=acme, dc=com
+
+ In principal, there is nothing to prevent the domain name elements of
+ the RFC822 identifier from being completely different from the domain
+ components of the DN. For instance, the DN for a J.Smith could be:
+
+ uid=J.Smith at worldnet.att.net, dc=mis, dc=acme, dc=com
+
+ While we do not REQUIRE that the domain name part of the uid match
+ the dc components of the directory distinguished name, we suggest
+ that this be done where possible. At a minimum, if the most
+ significant pieces of the DN and the uid are the same (i.e.,
+ "dc=acme, dc=com" and "acme.com") the likelihood, based on a
+ knowledge of a user's e-mail address, of discovering an appropriate
+ directory system to contact to find information about the user is
+ greatly enhanced.
+
+ The example above represents a situation where this suggestion isn't
+ possible because some of the users in a population have mailbox
+ identifiers that differ from the pattern of the rest of the users,
+ e.g., most mailboxes are of the form local at acme.com, but a
+ subpopulation have mailboxes from an ISP and therefore mailboxes of
+ the form local at worldnet.att.net.
+
+5.0 Naming Plan and Directories
+
+5.1 Directory Services Considerations
+
+ We envision the deployment of LDAP-based directory services on the
+ Internet to take the form of loosely coupled LDAP servers. This
+ coupling will occur at two levels.
+
+
+
+Grimstad, et. al. Informational [Page 10]
+
+RFC 2377 A Directory Naming Plan September 1998
+
+
+ Firstly, LDAP servers will be loosely connected into islands (i.e. a
+ set of servers sharing a single DN namespace). The glue connecting
+ the islands will be LDAP referral [12] information configured into
+ the LDAP servers. An LDAP search directed to any server in such an
+ island can be answered, if the information is not available to that
+ server, by an LDAP referral to another, more appropriate server
+ within the same island.
+
+ Secondly, various techniques will be used span LDAP islands. The
+ concept that enables such techniques is the LDAP URL [13]. By
+ combining a DNS host name and port (corresponding to one or more LDAP
+ servers) with a DN, the LDAP URL provides unified high-level
+ identification scheme (an LDAP URL namespace) for directory objects.
+
+ Because an LDAP referral is expressed as one or more LDAP URL, these
+ two levels of coupling may not sharply distinguished in practice.
+
+ We do not envision the X.500 model of a single DIT (i.e. a single DN
+ namespace) to be viable in an environment of competing service
+ providers. This naming plan does not attempt to produce DNs to hide
+ the possibility that a given real-world object may have independently
+ managed directory objects with the same DN associated with it.
+
+5.2 Directory Schema Implications of the Naming Plan
+
+ The traditional directory schema(s) developed for the X.500 standard
+ and its application to the Internet [4] require extension to be used
+ with the naming plan developed here. The extensions described below
+ attempt to reuse existing schema elements as much as possible. The
+ directory objects for which extensions are required are:
+ organization, organizational unit, and various classes of leaf
+ objects. We describe the schema modifications below for organization,
+ organizationalUnit and selected leaf classes.
+
+ So as to continue to use existing structural object classes to the
+ extent possible, we propose supplementing entries based on these
+ classes with additional information from two new auxiliary object
+ classes, dcObject and uidObject. They are specified using the
+ notation in Section 4 of [14].
+
+ The auxiliary object class dcObject is defined in "Using Domains in
+ LDAP Distinguished Names" [1].
+
+
+
+
+
+
+
+
+
+Grimstad, et. al. Informational [Page 11]
+
+RFC 2377 A Directory Naming Plan September 1998
+
+
+ The auxiliary object class uidObject is defined as:
+
+ ( 1.3.6.1.1.3.1
+ NAME uidObject
+ SUP top
+ AUXILIARY
+ MUST uid )
+
+5.2.1 Organization Schema
+
+ The dc attribute is employed to construct the RDN of an organization
+ object. This is enabled by adding the auxiliary class dcObject to
+ the organization's objectClass attribute.
+
+5.2.2 Organizational Unit Schema
+
+ The dc attribute is employed to construct the RDN of an
+ organizationalUnit object (which is subordinate in the DIT to either
+ an organization or an organizationalUnit object). This is enabled by
+ adding the auxiliary class dcObject to the organizational unit's
+ objectClass attribute.
+
+5.2.3 Person Schema
+
+ No schema extensions are required for person objects if either the
+ inetOrgPerson [15] (preferred) or the newPilotPerson object classes
+ are used. The attribute uid is permissible in each class. For
+ consistency, the uidObject could be added to person entry objectClass
+ attributes to assist applications filtering on this object class
+ attribute value. Use of other classes for person objects with RDN
+ constructed with the uid attribute such as organizationalPerson
+ requires the use of the uidObject class.
+
+ It has been traditional in X.500 and LDAP directory services to
+ employ the common name (cn) attribute in naming. While this naming
+ plan doesn't require use of the cn attribute in naming, it should be
+ stressed that it is a required attribute in any class derived from
+ the person class and is still quite important. It will play a
+ significant role in enabling searches to find user entries of
+ interest.
+
+5.2.4 Certification Authority Schema
+
+ The certification authority (CA) object class is an auxiliary class,
+ meaning it is essentially a set of additional attributes for a base
+ class such as organizationalRole, organization, organizationalUnit or
+ person. Except in the case where the base structural class is
+ inetOrgPerson, use of the uid attribute to construct the RDN of a CA
+
+
+
+Grimstad, et. al. Informational [Page 12]
+
+RFC 2377 A Directory Naming Plan September 1998
+
+
+ will require the auxiliary class uidObject to permit the uid
+ attribute to be used. In the cases where organizationalUnit or
+ organization is the base class for a CA, use of the auxiliary class
+ dcObject will permit the RDN of the CA to be a domain component.
+
+5.2.5 Server and Server Application Schema
+
+ Servers and server applications are typically represented, for want
+ of anything better, by entries of the object class applicationProcess
+ (or a class derived from it). Sometimes the class applicationEntity
+ is used. In either case, the uid attribute should probably not be
+ employed to construct the RDN of a server or server application
+ object. The standard schema uses the attribute cn for such RDNs.
+
+ Suppose one wants to use this naming plan both in the construction of
+ DNs for SSL server certificates and for their storage in a directory.
+ It is customary for clients connecting via SSL to compare the
+ server's domain name (e.g. from the URL used to contact the server)
+ with the value of the cn attribute in the subject field (i.e.
+ subject's DN) of the server's certificate. For this reason, it is
+ common practice to set the cn attribute to the server's domain name.
+
+ The naming and schema to handle this situation is best explained by
+ an example. Consider the server "host.acme.com". Following the
+ algorithm in "Using Domains in LDAP Distinguished Names" [1], the DN
+ dc=host, dc=acme, dc=com is constructed. To conform to the existing
+ practices just described, the server's subject DN for the SSL server
+ certificate should be cn=host.acme.com, dc=host, dc=acme, dc=com and
+ the server's certificate should be stored in a directory entry with
+ this name. This entry should use application process or application
+ entity as its structural object class and strong authentication user
+ as is auxiliary class.
+
+5.2.6 Name Forms
+
+ For X.500 servers or LDAP servers following the X.500 model, our
+ schema requires the definition of new name forms, structure rules,
+ and DIT content rules. Structure rules and DIT content rules are
+ locally defined, and do not involve a globally significant object
+ identifier.
+
+ The following name forms are defined using the syntax of section 6.22
+ of [14] for the convenience of those using such servers.
+
+ Note that since the structural object classes organization,
+ organizationalUnit, locality and organizationalPerson do not permit
+ inclusion of the dc attribute, an auxiliary object class such as
+ dcObject [1] must be used for instances of these classes.)
+
+
+
+Grimstad, et. al. Informational [Page 13]
+
+RFC 2377 A Directory Naming Plan September 1998
+
+
+5.2.6.1 Name Form for Domain Objects
+
+ The OIDs in this group are under the
+ iso.org.dod.internet.directory.NameForm branch of the OID tree
+ (1.3.6.1.1.2).
+
+ ( 1.3.6.1.1.2.1
+ NAME domainNameForm
+ OC domain
+ MUST dc )
+
+ The domainNameForm name form indicates that objects of structural
+ object class domain have their RDN constructed from a value of the
+ attribute dc.
+
+5.2.6.2 Name Form for Organization Objects
+
+ ( 1.3.6.1.1.2.2
+ NAME dcOrganizationNameForm
+ OC organization
+ MUST dc )
+
+ The dcOrganizationNameForm name form indicates that objects of
+ structural object class organization have their RDN constructed from
+ a value of the attribute dc.
+
+5.2.6.3 Name Form for Organizational Unit Objects
+
+ ( 1.3.6.1.1.2.3
+ NAME dcOrganizationalUnitNameForm
+ OC organizationalUnit
+ MUST dc )
+
+ The dcOrganizationalUnitNameForm name form indicates that objects of
+ structural object class organizationalUnit have their RDN constructed
+ from a value of the attribute dc.
+
+5.2.6.4 Name Form for Locality Objects
+
+ ( 1.3.6.1.1.2.4
+ NAME dcLocalityNameForm
+ OC locality
+ MUST dc )
+
+ The dcLocalityNameForm name form indicates that objects of structural
+ object class locality have their RDN constructed from a value of the
+ attribute dc.
+
+
+
+
+Grimstad, et. al. Informational [Page 14]
+
+RFC 2377 A Directory Naming Plan September 1998
+
+
+5.2.6.5 Name Form for Organizational Person Objects
+
+ ( 1.3.6.1.1.2.5
+ NAME uidOrganizationalPersonNameForm
+ OC organizationalPerson
+ MUST uid )
+
+ The uidOrganizationalPersonNameForm name form indicates that objects
+ of structural object class organizationalPerson have their RDN
+ constructed from a value of the attribute uid.
+
+6.0 Security Considerations
+
+ Although access controls may be placed on portions of the DIT to deny
+ browse access to unauthorized clients, it may be possible to infer
+ directory names and DIT structure in such sensitive portions of the
+ DIT from the results of DNS queries. Providing public visibility to
+ some portions of the DIT may assist those make such inferences.
+
+7.0 Acknowledgments
+
+ This plan has emerged in the course of a number of fruitful
+ discussions, especially with David Chadwick, John Dale, Joe Gajewski,
+ Mark Jackson, Ryan Moats, Tom Spencer and Chris Tzu.
+
+8.0 References
+
+ [1] Kille, S., Wahl, M., Grimstad, A., Huber, R., and S.
+ Sataluri, "Using Domains in LDAP Distinguished Names", RFC
+ 2247, January 1998.
+
+ [2] X.500: The Directory -- Overview of Concepts, Models, and
+ Service, CCITT Recommendation X.500, December, 1988.
+
+ [3] Barker, P., and S. Kille, "The COSINE and Internet X.500
+ Schema", RFC 1274, November 1991.
+
+ [4] The North American Directory Forum, "A Naming Scheme for
+ c=US", RFC 1255, September 1991.
+
+ [5] The North American Directory Forum, "NADF Standing Documents:
+ A Brief Overview", RFC 1417, February 1993.
+
+ [6] Yeong, W., Howes, T., and S. Kille, "Lightweight Directory
+ Access Protocol", RFC 1777, March 1995.
+
+ [7] Wahl, M., Howes, T., and S. Kille, "Lightweight Directory
+ Access Protocol (v3)", RFC 2251, December 1997.
+
+
+
+Grimstad, et. al. Informational [Page 15]
+
+RFC 2377 A Directory Naming Plan September 1998
+
+
+ [8] Kille, S., "A String Representation of Distinguished Names",
+ RFC 1779, March 1995.
+
+ [9] Wahl, M., Kille, S., and T. Howes, "Lightweight Directory
+ Access Protocol (v3): UTF-8 String Representation of
+ Distinguished Names", RFC 2253, December 1997.
+
+ [10] Wahl, M., "A Summary of the Pilot X.500 Schema for use
+ in LDAPv3", Work in Progress.
+
+ [11] Wahl, M., "A Summary of the X.500 User Schema for use with
+ LDAPv3", RFC 2256, December 1997.
+
+ [12] Howes, T., and M. Wahl, "Referrals and Knowledge References
+ in LDAP Directories", Work in Progress.
+
+ [13] Howes, T., and M. Smith, "The LDAP URL Format", RFC 2255,
+ December 1997.
+
+ [14] Wahl, M., Coulbeck, A., Howes, T., and S. Kille,
+ "Lightweight Directory Access Protocol (v3): Attribute Syntax
+ Definitions", RFC 2252, December 1997.
+
+ [15] Smith, M., "Definition of the inetOrgPerson Object Class",
+ Work in Progress.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Grimstad, et. al. Informational [Page 16]
+
+RFC 2377 A Directory Naming Plan September 1998
+
+
+12. Authors' Addresses
+
+ Al Grimstad
+ AT&T
+ Room 1C-429, 101 Crawfords Corner Road
+ Holmdel, NJ 07733-3030
+ USA
+
+ EMail: alg at att.com
+
+
+ Rick Huber
+ AT&T
+ Room 1B-433, 101 Crawfords Corner Road
+ Holmdel, NJ 07733-3030
+ USA
+
+ EMail: rvh at att.com
+
+
+ Sri Sataluri
+ Lucent Technologies
+ Room 4D-335, 101 Crawfords Corner Road
+ Holmdel, NJ 07733-3030
+ USA
+
+ EMail: srs at lucent.com
+
+
+ Mark Wahl
+ Critical Angle Inc.
+ 4815 W Braker Lane #502-385
+ Austin, TX 78759
+ USA
+
+ EMail: M.Wahl at critical-angle.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Grimstad, et. al. Informational [Page 17]
+
+RFC 2377 A Directory Naming Plan September 1998
+
+
+13. Full Copyright Statement
+
+ Copyright (C) The Internet Society (1998). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Grimstad, et. al. Informational [Page 18]
+
Added: openldap/vendor/openldap-release/doc/rfc/rfc2587.txt
===================================================================
--- openldap/vendor/openldap-release/doc/rfc/rfc2587.txt (rev 0)
+++ openldap/vendor/openldap-release/doc/rfc/rfc2587.txt 2007-09-15 10:38:52 UTC (rev 844)
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+Network Working Group S. Boeyen
+Request for Comments: 2587 Entrust
+Category: Standards Track T. Howes
+ Netscape
+ P. Richard
+ Xcert
+ June 1999
+
+
+
+ Internet X.509 Public Key Infrastructure
+ LDAPv2 Schema
+
+Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (1999). All Rights Reserved.
+
+1. Abstract
+
+ The schema defined in this document is a minimal schema to support
+ PKIX in an LDAPv2 environment, as defined in RFC 2559. Only PKIX-
+ specific components are specified here. LDAP servers, acting as PKIX
+ repositories should support the auxiliary object classes defined in
+ this specification and integrate this schema specification with the
+ generic and other application-specific schemas as appropriate,
+ depending on the services to be supplied by that server.
+
+ The key words 'MUST', 'SHALL', 'REQUIRED', 'SHOULD', 'RECOMMENDED',
+ and 'MAY' in this document are to be interpreted as described in RFC
+ 2119.
+
+2. Introduction
+
+ This specification is part of a multi-part standard for development
+ of a Public Key Infrastructure (PKI) for the Internet. LDAPv2 is one
+ mechanism defined for access to a PKI repository. Other mechanisms,
+ such as http, are also defined. If an LDAP server, accessed by LDAPv2
+ is used to provide a repository, the minimum requirement is that the
+ repository support the addition of X.509 certificates to directory
+
+
+
+
+Boeyen, et al. Standards Track [Page 1]
+
+RFC 2587 PKIX LDAPv2 Schema June 1999
+
+
+ entries. Certificate Revocation List (CRL)is one mechanism for
+ publishing revocation information in a repository. Other mechanisms,
+ such as http, are also defined.
+
+ This specification defines the attributes and object classes to be
+ used by LDAP servers acting as PKIX repositories and to be understood
+ by LDAP clients communicating with such repositories to query, add,
+ modify and delete PKI information. Some object classes and attributes
+ defined in X.509 are duplicated here for completeness. For end
+ entities and Certification Authorities (CA), the earlier X.509
+ defined object classes mandated inclusion of attributes which are
+ optional for PKIX. Also, because of the mandatory attribute
+ specification, this would have required dynamic modification of the
+ object class attribute should the attributes not always be present in
+ entries. For these reasons, alternative object classes are defined in
+ this document for use by LDAP servers acting as PKIX repositories.
+
+3. PKIX Repository Objects
+
+ The primary PKIX objects to be represented in a repository are:
+
+ - End Entities
+ - Certification Authorities (CA)
+
+ These objects are defined in RFC 2459.
+
+3.1. End Entities
+
+ For purposes of PKIX schema definition, the role of end entities as
+ subjects of certificates is the major aspect relevant to this
+ specification. End entities may be human users, or other types of
+ entities to which certificates may be issued. In some cases, the
+ entry for the end entity may already exist and the PKI-specific
+ information is added to the existing entry. In other cases the entry
+ may not exist prior to the issuance of a certificate, in which case
+ the entity adding the certificate may also need to create the entry.
+ Schema elements used to represent the non PKIX aspects of an entry,
+ such as the structural object class used to represent organizational
+ persons, may vary, depending on the particular environment and set of
+ applications served and are outside the scope of this specification.
+
+ The following auxiliary object class MAY be used to represent
+ certificate subjects:
+
+
+
+
+
+
+
+
+Boeyen, et al. Standards Track [Page 2]
+
+RFC 2587 PKIX LDAPv2 Schema June 1999
+
+
+pkiUser OBJECT-CLASS ::= {
+ SUBCLASS OF { top}
+ KIND auxiliary
+ MAY CONTAIN {userCertificate}
+ ID joint-iso-ccitt(2) ds(5) objectClass(6) pkiUser(21)}
+
+userCertificate ATTRIBUTE ::= {
+ WITH SYNTAX Certificate
+ EQUALITY MATCHING RULE certificateExactMatch
+ ID joint-iso-ccitt(2) ds(5) attributeType(4) userCertificate(36) }
+
+ An end entity may obtain one or more certificates from one or more
+ Certification Authorities. The userCertificate attribute MUST be
+ used to represent these certificates in the directory entry
+ representing that user.
+
+3.2. Certification Authorities
+
+ As with end entities, Certification Authorities are typically
+ represented in directories as auxiliary components of entries
+ representing a more generic object, such as organizations,
+ organizational units etc. The non PKIX-specific schema elements for
+ these entries, such as the structural object class of the object, are
+ outside the scope of this specification.
+
+ The following auxiliary object class MAY be used to represent
+ Certification Authorities:
+
+pkiCA OBJECT-CLASS ::= {
+ SUBCLASS OF { top}
+ KIND auxiliary
+ MAY CONTAIN {cACertificate |
+ certificateRevocationList |
+ authorityRevocationList |
+ crossCertificatePair }
+ ID joint-iso-ccitt(2) ds(5) objectClass(6) pkiCA(22)}
+
+cACertificate ATTRIBUTE ::= {
+ WITH SYNTAX Certificate
+ EQUALITY MATCHING RULE certificateExactMatch
+ ID joint-iso-ccitt(2) ds(5) attributeType(4) cACertificate(37) }
+
+crossCertificatePairATTRIBUTE::={
+ WITH SYNTAX CertificatePair
+ EQUALITY MATCHING RULE certificatePairExactMatch
+ ID joint-iso-ccitt(2) ds(5) attributeType(4) crossCertificatePair(40)}
+
+
+
+
+
+Boeyen, et al. Standards Track [Page 3]
+
+RFC 2587 PKIX LDAPv2 Schema June 1999
+
+
+ The cACertificate attribute of a CA's directory entry shall be used
+ to store self-issued certificates (if any) and certificates issued to
+ this CA by CAs in the same realm as this CA.
+
+ The forward elements of the crossCertificatePair attribute of a CA's
+ directory entry shall be used to store all, except self-issued
+ certificates issued to this CA. Optionally, the reverse elements of
+ the crossCertificatePair attribute, of a CA's directory entry may
+ contain a subset of certificates issued by this CA to other CAs.
+ When both the forward and the reverse elements are present in a
+ single attribute value, issuer name in one certificate shall match
+ the subject name in the other and vice versa, and the subject public
+ key in one certificate shall be capable of verifying the digital
+ signature on the other certificate and vice versa.
+
+ When a reverse element is present, the forward element value and the
+ reverse element value need not be stored in the same attribute value;
+ in other words, they can be stored in either a single attribute value
+ or two attribute values.
+
+ In the case of V3 certificates, none of the above CA certificates
+ shall include a basicConstraints extension with the cA value set to
+ FALSE.
+
+ The definition of realm is purely a matter of local policy.
+
+ certificateRevocationListATTRIBUTE::={
+ WITH SYNTAX CertificateList
+ EQUALITY MATCHING RULE certificateListExactMatch
+ ID joint-iso-ccitt(2) ds(5) attributeType(4)
+ certificateRevocationList(39)}
+
+ The certificateRevocationList attribute, if present in a particular
+ CA's entry, contains CRL(s) as defined in RFC 2459.
+
+ authorityRevocationListATTRIBUTE::={
+ WITH SYNTAX CertificateList
+ EQUALITY MATCHING RULE certificateListExactMatch
+ ID joint-iso-ccitt(2) ds(5) attributeType(4)
+ authorityRevocationList(38)}
+
+ The authorityRevocationList attribute, if present in a particular
+ CA's entry, includes revocation information regarding certificates
+ issued to other CAs.
+
+
+
+
+
+
+
+Boeyen, et al. Standards Track [Page 4]
+
+RFC 2587 PKIX LDAPv2 Schema June 1999
+
+
+3.2.1. CRL distribution points
+
+ CRL distribution points are an optional mechanism, specified in RFC
+ 2459, which MAY be used to distribute revocation information.
+
+ A patent statement regarding CRL distribution points can be found at
+ the end of this document.
+
+ If a CA elects to use CRL distribution points, the following object
+ class is used to represent these.
+
+ cRLDistributionPoint OBJECT-CLASS::= {
+ SUBCLASS OF { top }
+ KIND structural
+ MUST CONTAIN { commonName }
+ MAY CONTAIN { certificateRevocationList |
+ authorityRevocationList |
+ deltaRevocationList }
+ ID joint-iso-ccitt(2) ds(5) objectClass(6) cRLDistributionPoint(19) }
+
+ The certificateRevocationList and authorityRevocationList attributes
+ are as defined above.
+
+ The commonName attribute and deltaRevocationList attributes, defined
+ in X.509, are duplicated below.
+
+ commonName ATTRIBUTE::={
+ SUBTYPE OF name
+ WITH SYNTAX DirectoryString
+ ID joint-iso-ccitt(2) ds(5) attributeType(4) commonName(3) }
+
+ deltaRevocationList ATTRIBUTE ::= {
+ WITH SYNTAX CertificateList
+ EQUALITY MATCHING RULE certificateListExactMatch
+ ID joint-iso-ccitt(2) ds(5) attributeType(4)
+ deltaRevocationList(53) }
+
+3.2.2. Delta CRLs
+
+ Delta CRLs are an optional mechanism, specified in RFC 2459, which
+ MAY be used to enhance the distribution of revocation information.
+
+ If a CA elects to use delta CRLs, the following object class is used
+ to represent these.
+
+
+
+
+
+
+
+Boeyen, et al. Standards Track [Page 5]
+
+RFC 2587 PKIX LDAPv2 Schema June 1999
+
+
+ deltaCRL OBJECT-CLASS::= {
+ SUBCLASS OF { top }
+ KIND auxiliary
+ MAY CONTAIN { deltaRevocationList }
+ ID joint-iso-ccitt(2) ds(5) objectClass(6) deltaCRL(23) }
+
+4. Security Considerations
+
+ Since the elements of information which are key to the PKI service
+ (certificates and CRLs) are both digitally signed pieces of
+ information, no additional integrity service is REQUIRED.
+
+ Security considerations with respect to retrieval, addition,
+ deletion, and modification of the information supported by this
+ schema definition are addressed in RFC 2559.
+
+5. References
+
+ [1] Yeong, Y., Howes, T. and S. Kille, "Lightweight Directory Access
+ Protocol", RFC 1777, March 1995.
+
+ [2] Bradner, S., "Key Words for use in RFCs to Indicate Requirement
+ Levels", BCP 14, RFC 2119, March 1997.
+
+6 Intellectual Property Rights
+
+ The IETF has been notified of intellectual property rights claimed in
+ regard to some or all of the specification contained in this
+ document. For more information consult the online list of claimed
+ rights.
+
+ The IETF takes no position regarding the validity or scope of any
+ intellectual property or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; neither does it represent that it
+ has made any effort to identify any such rights. Information on the
+ IETF's procedures with respect to rights in standards-track and
+ standards-related documentation can be found in BCP-11. Copies of
+ claims of rights made available for publication and any assurances of
+ licenses to be made available, or the result of an attempt made to
+ obtain a general license or permission for the use of such
+ proprietary rights by implementors or users of this specification can
+ be obtained from the IETF Secretariat.
+
+
+
+
+
+
+
+Boeyen, et al. Standards Track [Page 6]
+
+RFC 2587 PKIX LDAPv2 Schema June 1999
+
+
+7. Authors' Addresses
+
+ Sharon Boeyen
+ Entrust Technologies Limited
+ 750 Heron Road
+ Ottawa, Ontario
+ Canada K1V 1A7
+
+ EMail: sharon.boeyen at entrust.com
+
+
+ Tim Howes
+ Netscape Communications Corp.
+ 501 E. Middlefield Rd.
+ Mountain View, CA 94043
+ USA
+
+ EMail: howes at netscape.com
+
+
+ Patrick Richard
+ Xcert Software Inc.
+ Suite 1001, 701 W. Georgia Street
+ P.O. Box 10145
+ Pacific Centre
+ Vancouver, B.C.
+ Canada V7Y 1C6
+
+ EMail: patr at xcert.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Boeyen, et al. Standards Track [Page 7]
+
+RFC 2587 PKIX LDAPv2 Schema June 1999
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (1999). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Boeyen, et al. Standards Track [Page 8]
+
Added: openldap/vendor/openldap-release/doc/rfc/rfc2589.txt
===================================================================
--- openldap/vendor/openldap-release/doc/rfc/rfc2589.txt (rev 0)
+++ openldap/vendor/openldap-release/doc/rfc/rfc2589.txt 2007-09-15 10:38:52 UTC (rev 844)
@@ -0,0 +1,675 @@
+
+
+
+
+
+
+Network Working Group Y. Yaacovi
+Request for Comments: 2589 Microsoft
+Category: Standards Track M. Wahl
+ Innosoft International, Inc.
+ T. Genovese
+ Microsoft
+ May 1999
+
+
+ Lightweight Directory Access Protocol (v3):
+ Extensions for Dynamic Directory Services
+
+Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (1999). All Rights Reserved.
+
+1. Abstract
+
+ This document defines the requirements for dynamic directory services
+ and specifies the format of request and response extended operations
+ for supporting client-server interoperation in a dynamic directories
+ environment.
+
+ The Lightweight Directory Access Protocol (LDAP) [1] supports
+ lightweight access to static directory services, allowing relatively
+ fast search and update access. Static directory services store
+ information about people that persists in its accuracy and value over
+ a long period of time.
+
+ Dynamic directory services are different in that they store
+ information that only persists in its accuracy and value when it is
+ being periodically refreshed. This information is stored as dynamic
+ entries in the directory. A typical use will be a client or a person
+ that is either online - in which case it has an entry in the
+ directory, or is offline - in which case its entry disappears from
+ the directory. Though the protocol operations and attributes used by
+ dynamic directory services are similar to the ones used for static
+ directory services, clients that store dynamic information in the
+ directory need to periodically refresh this information, in order to
+ prevent it from disappearing. If dynamic entries are not refreshed
+
+
+
+Yaacovi, et al. Standards Track [Page 1]
+
+RFC 2589 LDAPv3 Extensions for Dynamic Directory Services May 1999
+
+
+ within a given timeout, they will be removed from the directory. For
+ example, this will happen if the client that set them goes offline.
+
+ A flow control mechanism from the server is also described that
+ allows a server to inform clients how often they should refresh their
+ presence.
+
+2. Requirements
+
+ The protocol extensions must allow accessing dynamic information in a
+ directory in a standard LDAP manner, to allow clients to access
+ static and dynamic information in the same way.
+
+ By definition, dynamic entries are not persistent and clients may go
+ away gracefully or not. The proposed extensions must offer a way for
+ a server to tell if entries are still valid, and to do this in a way
+ that is scalable. There also must be a mechanism for clients to
+ reestablish their entry with the server.
+
+ There must be a way for clients to find out, in a standard LDAP
+ manner, if servers support the dynamic extensions.
+
+ Finally, to allow clients to broadly use the dynamic extensions, the
+ extensions need to be registered as standard LDAP extended
+ operations.
+
+3. Description of Approach
+
+ The Lightweight Directory Access Protocol (LDAP) [1] permits
+ additional operation requests and responses to be added to the
+ protocol. This proposal takes advantage of these to support
+ directories which contain dynamic information in a manner which is
+ fully integrated with LDAP.
+
+ The approach described in this proposal defines dynamic entries in
+ order to allow implementing directories with dynamic information. An
+ implementation of dynamic directories, must be able to support
+ dynamic directory entries.
+
+3.1. Dynamic Entries and the dynamicObject object class
+
+ A dynamic entry is an object in the directory tree which has a time-
+ to-live associated with it. This time-to-live is set when the entry
+ is created. The time-to-live is automatically decremented, and when
+ it expires the dynamic entry disappears. By invoking the refresh
+ extended operation (defined below) to re-set the time-to-live, a
+ client can cause the entry to remain present a while longer.
+
+
+
+
+Yaacovi, et al. Standards Track [Page 2]
+
+RFC 2589 LDAPv3 Extensions for Dynamic Directory Services May 1999
+
+
+ A dynamic entry is created by including the objectClass value given
+ in section 5 in the list of attributes when adding an entry. This
+ method is subject to standard access control restrictions.
+
+ The extended operation covered here, allows a client to refresh a
+ dynamic entry by invoking, at intervals, refresh operations
+ containing that entry's name. Dynamic entries will be treated the
+ same as non-dynamic entries when processing search, compare, add,
+ delete, modify and modifyDN operations. However if clients stop
+ sending refresh operations for an entry, then the server will
+ automatically and without notification remove that entry from the
+ directory. This removal will be treated the same as if the entry had
+ been deleted by an LDAP protocol operation.
+
+ There is no way to change a static entry into a dynamic one and
+ vice-versa. If the client is using Modify with an objectClass of
+ dynamicObject on a static entry, the server must return a service
+ error either "objectClassModsProhibited" (if the server does not
+ allow objectClass modifications at all) or "objectClassViolation" (if
+ the server does allow objectClass modifications in general).
+
+ A dynamic entry may be removed by the client using the delete
+ operation. This operation will be subject to access control
+ restrictions.
+
+ A non-dynamic entry cannot be added subordinate to a dynamic entry:
+ the server must return an appropriate update or service error if this
+ is attempted.
+
+ The support of dynamic attributes of an otherwise static object, are
+ outside the scope of this document.
+
+3.2 Dynamic meetings (conferences)
+
+ The way dynamicObject is defined, it has a time-to-live associated
+ with it, and that's about it. Though the most common dynamic object
+ is a person object, there is no specific type associated with the
+ dynamicObject as defined here. By the use of the dynamic object's
+ attributes, one can make this object represent practically anything.
+
+ Specifically, Meetings (conferences) can be represented by dynamic
+ objects. While full-featured meeting support requires special
+ semantics and handling by the server (and is not in the scope of this
+ document), the extensions described here, provide basic meetings
+ support. A meeting object can be refreshed by the meeting
+ participants, and when it is not, the meeting entry disappears. The
+ one meeting type that is naturally supported by the dynamic
+ extensions is creator-owned meeting.
+
+
+
+Yaacovi, et al. Standards Track [Page 3]
+
+RFC 2589 LDAPv3 Extensions for Dynamic Directory Services May 1999
+
+
+3.2.1 Creator-owned meetings
+
+ Creator-owned meetings are created by a client that sets the time-
+ to-live attribute for the entry, and it is this client's
+ responsibility to refresh the meeting entry, so that it will not
+ disappear. Others might join the meeting, by modifying the
+ appropriate attribute, but they are not allowed to refresh the entry.
+ When the client that created the entry goes away, it can delete the
+ meeting entry, or it might disappear when its time-to-live expires.
+ This is consistent with the common model for dynamicObject as
+ described above.
+
+4. Protocol Additions
+
+4.1 Refresh Request
+
+ Refresh is a protocol operation sent by a client to tell the server
+ that the client is still alive and the dynamic directory entry is
+ still accurate and valuable. The client sends a Refresh request
+ periodically based on the value of the client refresh period (CRP).
+ The server can request that the client change this value. As long as
+ the server receives a Refresh request within the timeout period, the
+ directory entry is guaranteed to persist on the server. Client
+ implementers should be aware that since the intervening network
+ between the client and server is unreliable, a Refresh request packet
+ may be delayed or lost while in transit. If this occurs, the entry
+ may disappear, and the client will need to detect this and re-add the
+ entry.
+
+ A client may request this operation by transmitting an LDAP PDU
+ containing an ExtendedRequest. An LDAP ExtendedRequest is defined as
+ follows:
+
+ ExtendedRequest ::= [APPLICATION 23] SEQUENCE {
+ requestName [0] LDAPOID,
+ requestValue [1] OCTET STRING OPTIONAL }
+
+ The requestName field must be set to the string
+ "1.3.6.1.4.1.1466.101.119.1".
+
+ The requestValue field will contain as a value the DER-encoding of
+ the following ASN.1 data type:
+
+ SEQUENCE {
+ entryName [0] LDAPDN,
+ requestTtl [1] INTEGER
+ }
+
+
+
+
+Yaacovi, et al. Standards Track [Page 4]
+
+RFC 2589 LDAPv3 Extensions for Dynamic Directory Services May 1999
+
+
+ The entryName field is the UTF-8 string representation of the name of
+ the dynamic entry [3]. This entry must already exist.
+
+ The requestTtl is a time in seconds (between 1 and 31557600) that the
+ client requests that the entry exists in the directory before being
+ automatically removed. Servers are not required to accept this value
+ and might return a different TTL value to the client. Clients must
+ be able to use this server-dictated value as their CRP.
+
+4.2 Refresh Response
+
+ If a server implements this extension, then when the request is made
+ it will return an LDAP PDU containing an ExtendedResponse. An LDAP
+ ExtendedResponse is defined as follows:
+
+ ExtendedResponse ::= [APPLICATION 24] SEQUENCE {
+ COMPONENTS OF LDAPResult,
+ responseName [10] LDAPOID OPTIONAL,
+ response [11] OCTET STRING OPTIONAL }
+
+ The responseName field contains the same string as that present in
+ the request.
+
+ The response field will contain as a value the DER-encoding of the
+ following ASN.1 data type:
+
+ SEQUENCE {
+ responseTtl [1] INTEGER
+ }
+
+ The responseTtl field is the time in seconds which the server chooses
+ to have as the time-to-live field for that entry. It must not be any
+ smaller than that which the client requested, and it may be larger.
+ However, to allow servers to maintain a relatively accurate
+ directory, and to prevent clients from abusing the dynamic
+ extensions, servers are permitted to shorten a client-requested
+ time-to-live value, down to a minimum of 86400 seconds (one day).
+
+ If the operation was successful, the errorCode field in the
+ standardResponse part of an ExtendedResponse will be set to success.
+
+ In case of an error, the responseTtl field will have the value 0, and
+ the errorCode field will contain an appropriate value, as follows: If
+ the entry named by entryName could not be located, the errorCode
+ field will contain "noSuchObject". If the entry is not dynamic, the
+ errorCode field will contain "objectClassViolation". If the
+ requester does not have permission to refresh the entry, the
+
+
+
+
+Yaacovi, et al. Standards Track [Page 5]
+
+RFC 2589 LDAPv3 Extensions for Dynamic Directory Services May 1999
+
+
+ errorCode field will contain "insufficientAccessRights". If the
+ requestTtl field is too large, the errorCode field will contain
+ "sizeLimitExceeded".
+
+ If a server does not implement this extension, it will return an LDAP
+ PDU containing an ExtendedResponse, which contains only the
+ standardResponse element (the responseName and response elements will
+ be absent). The LDAPResult element will indicate the protocolError
+ result code.
+
+ This request is permitted to be invoked when LDAP is carried by a
+ connectionless transport.
+
+ When using a connection-oriented transport, there is no requirement
+ that this operation be on the same particular connection as any
+ other. A client may open multiple connections, or close and then
+ reopen a connection.
+
+4.3 X.500/DAP Modify(97)
+
+ X.500/DAP servers can map the Refresh request and response operations
+ into the X.500/DAP Modify(97) operation.
+
+5. Schema Additions
+
+ All dynamic entries must have the dynamicObject value in their
+ objectClass attribute. This object class is defined as follows
+ (using the ObjectClassDescription notation of [2]):
+
+ ( 1.3.6.1.4.1.1466.101.119.2 NAME 'dynamicObject'
+ DESC 'This class, if present in an entry, indicates that this entry
+ has a limited lifetime and may disappear automatically when
+ its time-to-live has reached 0. There are no mandatory
+ attributes of this class, however if the client has not
+ supplied a value for the entryTtl attribute, the server will
+ provide one.'
+ SUP top AUXILIARY )
+
+ Furthermore, the dynamic entry must have the following operational
+ attribute. It is described using the AttributeTypeDescription
+ notation of [2]:
+
+ ( 1.3.6.1.4.1.1466.101.119.3 NAME 'entryTtl'
+ DESC 'This operational attribute is maintained by the server and
+ appears to be present in every dynamic entry. The attribute
+ is not present when the entry does not contain the
+ dynamicObject object class. The value of this attribute is
+ the time in seconds that the entry will continue to exist
+
+
+
+Yaacovi, et al. Standards Track [Page 6]
+
+RFC 2589 LDAPv3 Extensions for Dynamic Directory Services May 1999
+
+
+ before disappearing from the directory. In the absence of
+ intervening refresh operations, the values returned by
+ reading the attribute in two successive searches are
+ guaranteed to be nonincreasing. The smallest permissible
+ value is 0, indicating that the entry may disappear without
+ warning. The attribute is marked NO-USER-MODIFICATION since
+ it may only be changed using the refresh operation.'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE
+ NO-USER-MODIFICATION USAGE dSAOperation )
+
+ To allow servers to support dynamic entries in only a part of the
+ DIT, the following operational attribute is defined. It is
+ described using the AttributeTypeDescription notation of [2]:
+
+ ( 1.3.6.1.4.1.1466.101.119.4 NAME 'dynamicSubtrees'
+ DESC 'This operational attribute is maintained by the server and is
+ present in the Root DSE, if the server supports the dynamic
+ extensions described in this memo. The attribute contains a
+ list of all the subtrees in this directory for which the
+ server supports the dynamic extensions.'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 NO-USER-MODIFICATION
+ USAGE dSAOperation )
+
+6. Client and Server Requirements
+
+6.1 Client Requirements
+
+ Clients can find out if a server supports the dynamic extensions by
+ checking the supportedExtension field in the root DSE, to see if the
+ OBJECT IDENTIFIER described in section 4 is present. Since servers
+ may select to support the dynamic extensions in only some of the
+ subtrees of the DIT, clients must check the dynamicSubtrees
+ operational attribute in the root DSE to find out if the dynamic
+ extensions are supported on a specific subtree.
+
+ Once a dynamic entry has been created, clients are responsible for
+ invoking the refresh extended operation, in order to keep that entry
+ present in the directory.
+
+ Clients must not expect that a dynamic entry will be present in the
+ DIT after it has timed out, however it must not require that the
+ server remove the entry immediately (some servers may only process
+ timing out entries at intervals). If the client wishes to ensure the
+ entry does not exist it should issue a RemoveRequest for that entry.
+
+ Initially, a client needs to know how often it should send refresh
+ requests to the server. This value is defined as the CRP (Client
+ Refresh Period) and is set by the server based on the entryTtl.
+
+
+
+Yaacovi, et al. Standards Track [Page 7]
+
+RFC 2589 LDAPv3 Extensions for Dynamic Directory Services May 1999
+
+
+ Since the LDAP AddRequest operation is left unchanged and is not
+ modified in this proposal to return this value, a client must issue a
+ Refresh extended operation immediately after an Add that created a
+ dynamic entry. The Refresh Response will return the CRP (in
+ responseTtl) to the client.
+
+ Clients must not issue the refresh request for dynamic entries which
+ they have not created. If an anonymous client attempts to do so, a
+ server is permitted to return insufficientAccessRights (50) in the
+ RefreshResponse, enforcing the client to bind first. Please note that
+ servers which allow anonymous clients to create and refresh dynamic
+ entries will not be able to enforce the above.
+
+ Clients should always be ready to handle the case in which their
+ entry timed out. In such a case, the Refresh operation will fail
+ with an error code such as noSuchObject, and the client is expected
+ to re-create its entry.
+
+ Clients should be prepared to experience refresh operations failing
+ with protocolError, even though the add and any previous refresh
+ requests succeeded. This might happen if a proxy between the client
+ and the server goes down, and another proxy is used which does not
+ support the Refresh extended operation.
+
+6.2 Server Requirements
+
+ Servers are responsible for removing dynamic entries when they time
+ out. Servers are not required to do this immediately.
+
+ Servers must enforce the structural rules listed in above section 3.
+
+ Servers must ensure that the operational attribute described in
+ section 5 is present in dynamic entries
+
+ Servers may permit anonymous users to refresh entries. However, to
+ eliminate the possibility of a malicious use of the Refresh
+ operation, servers may require the refreshing client to bind first. A
+ server implementation can achieve this by presenting ACLs on the
+ entryTtl attribute, and returning insufficientAccessRights (50) in
+ the RefreshResponse, if the client is not allowed to refresh the
+ entry. Doing this, though, might have performance implications on the
+ server and might impact the server's scalability.
+
+ Servers may require that a client which attempts to create a dynamic
+ entry have a remove permission for that entry.
+
+ Servers which implement the dynamic extensions must have the OBJECT
+ IDENTIFIER, described above in section 4 for the request and
+
+
+
+Yaacovi, et al. Standards Track [Page 8]
+
+RFC 2589 LDAPv3 Extensions for Dynamic Directory Services May 1999
+
+
+ response, present as a value of the supportedExtension field in the
+ root DSE. They must also have as values in the attributeTypes and
+ objectClasses attributes of their subschema subentries, the
+ AttributeTypeDescription and ObjectClassDescription from section 5.
+
+ Servers can limit the support of the dynamic extensions to only some
+ of the subtrees in the DIT. Servers indicate for which subtrees they
+ support the extensions, by specifying the OIDs for the supported
+ subtrees in the dynamicSubtrees attribute described in section 5. If
+ a server supports the dynamic extensions for all naming contexts it
+ holds, the dynamicSubtrees attribute may be absent.
+
+7. Implementation issues
+
+7.1 Storage of dynamic information
+
+ Dynamic information is expected to change very often. In addition,
+ Refresh requests are expected to arrive at the server very often.
+ Disk-based databases that static directory services often use are
+ likely inappropriate for storing dynamic information. We recommend
+ that server implementations store dynamic entries in memory
+ sufficient to avoid paging. This is not a requirement.
+
+ We expect LDAP servers to be able to store static and dynamic
+ entries. If an LDAP server does not support dynamic entries, it
+ should respond with an error code such as objectClassViolation.
+
+7.2 Client refresh behavior
+
+ In some cases, the client might not get a Refresh response. This may
+ happen as a result of a server crash after receiving the Refresh
+ request, the TCP/IP socket timing out in the connection case, or the
+ UDP packet getting lost in the connection-less case.
+
+ It is recommended that in such a case, the client will retry the
+ Refresh operation immediately, and if this Refresh request does not
+ get a response as well, it will resort to its original Refresh cycle,
+ i.e. send a Refresh request at its Client Refresh Period (CRP).
+
+7.3 Configuration of refresh times
+
+ We recommend that servers will provide administrators with the
+ ability to configure the default client refresh period (CRP), and
+ also a minimum and maximum CRP values. This, together with allowing
+ administrators to request that the server will not change the CRP
+ dynamically, will allow administrators to set CRP values which will
+ enforce a low refresh traffic, or - on the other extreme, an highly
+ up-to-date directory.
+
+
+
+Yaacovi, et al. Standards Track [Page 9]
+
+RFC 2589 LDAPv3 Extensions for Dynamic Directory Services May 1999
+
+
+8. Replication
+
+ Replication is only partially addressed in this memo. There is a
+ separate effort in progress at the IETF on replication of static and
+ dynamic directories.
+
+ it is allowed to replicate a dynamic entry or a static entry with
+ dynamic attributes. Since the entryTtl is expressed as a relative
+ time (how many seconds till the entry will expire), replicating it
+ means that the replicated entry will be "off" by the replication
+ time.
+
+9. Localization
+
+ The are no localization issues for this extended operation.
+
+10. Security Considerations
+
+ Standard LDAP security rules and support apply for the extensions
+ described in this document, and there are no special security issues
+ for these extensions. Please note, though, that servers may permit
+ anonymous clients to refresh entries which they did not create.
+ Servers are also permitted to control a refresh access to an entry by
+ requiring clients to bind before issuing a RefreshRequest. This will
+ have implications on the server performance and scalability.
+
+ Also, Care should be taken in making use of information obtained from
+ directory servers that has been supplied by client, as it may now be
+ out of date. In many networks, for example, IP addresses are
+ automatically assigned when a host connects to the network, and may
+ be reassigned if that host later disconnects. An IP address obtained
+ from the directory may no longer be assigned to the host that placed
+ the address in the directory. This issue is not specific to LDAP or
+ dynamic directories.
+
+11. Acknowledgments
+
+ Design ideas included in this document are based on those discussed
+ in ASID and other IETF Working Groups.
+
+
+
+
+
+
+
+
+
+
+
+
+Yaacovi, et al. Standards Track [Page 10]
+
+RFC 2589 LDAPv3 Extensions for Dynamic Directory Services May 1999
+
+
+12. Authors' Addresses
+
+ Yoram Yaacovi
+ Microsoft
+ One Microsoft way
+ Redmond, WA 98052
+ USA
+
+ Phone: +1 206-936-9629
+ EMail: yoramy at microsoft.com
+
+
+ Mark Wahl
+ Innosoft International, Inc.
+ 8911 Capital of Texas Hwy #4140
+ Austin, TX 78759
+ USA
+
+ Email: M.Wahl at innosoft.com
+
+
+ Tony Genovese
+ Microsoft
+ One Microsoft way
+ Redmond, WA 98052
+ USA
+
+ Phone: +1 206-703-0852
+ EMail: tonyg at microsoft.com
+
+13. Bibliography
+
+ [1] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access
+ Protocol (Version 3)", RFC 2251, December 1997.
+
+ [2] Wahl, M. Coulbeck, A., Howes, T. and S. Kille, "Lightweight
+ Directory Access Protocol (v3): Attribute Syntax Definitions",
+ RFC 2252, December 1997.
+
+ [3] Wahl, M. and S. Kille, "Lightweight Directory Access Protocol
+ (v3): UTF-8 String Representation of Distinguished Names", RFC
+ 2253, December 1997.
+
+
+
+
+
+
+
+
+
+Yaacovi, et al. Standards Track [Page 11]
+
+RFC 2589 LDAPv3 Extensions for Dynamic Directory Services May 1999
+
+
+14. Full Copyright Statement
+
+ Copyright (C) The Internet Society (1999). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Yaacovi, et al. Standards Track [Page 12]
+
Added: openldap/vendor/openldap-release/doc/rfc/rfc2649.txt
===================================================================
--- openldap/vendor/openldap-release/doc/rfc/rfc2649.txt (rev 0)
+++ openldap/vendor/openldap-release/doc/rfc/rfc2649.txt 2007-09-15 10:38:52 UTC (rev 844)
@@ -0,0 +1,563 @@
+
+
+
+
+
+
+Network Working Group B. Greenblatt
+Request for Comments: 2649 P. Richard
+Category: Experimental August 1999
+
+
+ An LDAP Control and Schema for Holding Operation Signatures
+
+Status of this Memo
+
+ This memo defines an Experimental Protocol for the Internet
+ community. It does not specify an Internet standard of any kind.
+ Discussion and suggestions for improvement are requested.
+ Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (1999). All Rights Reserved.
+
+Abstract
+
+ In many environments clients require the ability to validiate the
+ source and integrity of information provided by the directory. This
+ document describes an LDAP message control which allows for the
+ retrieval of digitally signed information. This document defines an
+ LDAP v3 based mechanism for signing directory operations in order to
+ create a secure journal of changes that have been made to each
+ directory entry. Both client and server based signatures are
+ supported. An object class for subsequent retrieval are "journal
+ entries" is also defined. This document specifies LDAP v3 controls
+ that enable this functionality. It also defines an LDAP v3 schema
+ that allows for subsequent browsing of the journal information.
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
+ 1.1 Audit Trail Mechanism . . . . . . . . . . . . . . . . . . . 2
+ 1.2. Handling the Delete Operation . . . . . . . . . . . . . . . 5
+ 2. Signed Results Mechanism . . . . . . . . . . . . . . . . . . 6
+ 3. Security Considerations and Other Notes . . . . . . . . . . 7
+ 4. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
+ 5. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 9
+ 6. Full Copyright Statement . . . . . . . . . . . . . . . . . . 10
+
+
+
+
+
+
+
+
+
+Greenblatt & Richard Experimental [Page 1]
+
+RFC 2649 LDAP Control and Schema August 1999
+
+
+1. Introduction
+
+ In many environments clients require the ability to validiate the
+ source and integrity of information provided by the directory. This
+ document describes an LDAP message control which allows for the
+ retrieval of digitally signed information. The perspective of this
+ document is that the origin of the information that is stored in LDAP
+ v3 accessible directories is the LDAP v3 client that creates the
+ information. The source and integrity of the information is
+ guaranteed by allowing for the digital signing of the operations that
+ make changes to entries in the directory. The source and integrity
+ of an individual LDAP connection can be guaranteed by making use of
+ an underlying session layer that provides such services, such as TLS.
+ Note that the integrity of an individual connection does not, in and
+ of itself guarantee the integrity of the data that comes across the
+ connection. This is due to the fact that the LDAP server is only
+ capable of providing information that it has stored. In distributed
+ and replicated environments, the fact that an entry has been
+ successfully retrieved from a server may not be completely
+ reassuring, if the entry in question was replicated from an untrusted
+ domain.
+
+ By making use of public key technology, and creating digitally signed
+ transactions that are created by the LDAP v3 client as entries are
+ created and modified, a complete journal of the history of the entry
+ is available. Since each entry in the journal has been digitally
+ signed with the private key of the creator, or modifier of the entry,
+ the source and integrity of the directory entry can be validated by
+ verifying the signature of each entry in the journal. Note that not
+ all of the journal entries will have been signed by the same user.
+
+1.1. Audit Trail Mechanism
+
+ Signed directory operations is a straightforward application of
+ S/MIME technology that also leverages the extensible framework that
+ is provided by LDAP version 3. LDAP version 3 is defined in [4], and
+ S/MIME is defined in [2]. The security used in S/MIME is based in
+ the definitions in [1]. The basic idea is that the submitter of an
+ LDAP operation that changes the directory information includes an
+ LDAP version 3 control that includes either a signature of the
+ operation, or a request that the LDAP server sign the operation on
+ the behalf of the LDAP client. The result of the operation (in
+ addition to the change of the directory information), is additional
+ information that is attached to directory objects, that includes the
+ audit trail of signed operations. The LDAP control is (OID =
+ 1.2.840.113549.6.0.0):
+
+
+
+
+
+Greenblatt & Richard Experimental [Page 2]
+
+RFC 2649 LDAP Control and Schema August 1999
+
+
+ SignedOperation ::= CHOICE {
+ signbyServer NULL,
+ signatureIncluded OCTET STRING
+ }
+
+ If the SignatureIncluded CHOICE is used, then the OCTET string is
+ just an S/MIME message of the multipart/signed variety, that is
+ composed of a single piece, that is the signature of the directory
+ operation. Multipart/signed MIME objects are defined in [3]. If the
+ SignbyServer CHOICE us used, then the LDAP server creates the
+ signature on behalf of the client, using its own identity and not the
+ identity of the client, in order to produce the audit trail entry.
+ In either case the successful result of processing the control is the
+ creation of additional information in the directory entry that is
+ being modified or created. The signature of the LDAP operation is
+ computed on the LDAPMessage prior to the inclusion of the
+ SignedOperation control. The procedure is as follows:
+
+ - Build LDAPMessage without the SignedOperation control
+ - Compute signature on the above LDAPMessage
+ - Create new LDAPMessage that includes the old MessageID,
+ protocolOp and any control fields from the previous LDAPMessage,
+ plus the computed signature formatted as an S/MIME message.
+
+ No control is defined for the server to return in the LDAPResult as
+ defined in [4]. The LDAP server MAY attempt to parse and verify the
+ signature included in the SignedOperation control, but is not
+ required to. The server can accept the signed operation without
+ verifying the signature. Signature verification can be quite a
+ lengthy operation, requiring complex certificate chain traversals.
+ This allows a more timely creation of the audit trail by the server.
+ Any LDAP client browsing the directory that retrieves the 'Changes'
+ (defined in the following paragraphs) attributes, should verify the
+ signature of each value according to the local signature verification
+ policies. Even if the LDAP server verifies the signature contained
+ in the singed operation, the LDAP client has no way of knowing what
+ policies were followed by the server in order to verify the
+ signature.
+
+ If the LDAP server is unable to verify the signature and wishes to
+ return an error then the error code unwillingToPerform(53) should be
+ returned, and the entire LDAP operation fails. In this situation, an
+ appropriate message (e.g. "Unable to verify signature") MAY be
+ included in the errorMessage of the LDAPResult. The SignedOperation
+ Control MAY be marked CRITICAL, and if it is CRITICAL then if the
+ LDAP Server performs the LDAP operation, then must include the
+ signature in the signedAuditTrail information.
+
+
+
+
+Greenblatt & Richard Experimental [Page 3]
+
+RFC 2649 LDAP Control and Schema August 1999
+
+
+ The schema definition for the signedAuditTrail information is:
+
+ ( 1.2.840.113549.6.1.0
+ NAME 'signedAuditTrail'
+ SUP top
+ AUXILIARY
+ MUST (
+ Changes
+ )
+ )
+
+ The format of the Changes attribute is:
+
+ ( 1.2.840.113549.6.2.0
+ NAME 'Changes'
+ DESC 'a set of changes applied to an entry'
+ SYNTAX 'Binary' )
+
+ The actual format of the Changes attribute is:
+
+ Changes ::= SEQUENCE {
+ sequenceNumber [0] INTEGER (0 .. maxInt),
+ signedOperation [1] OCTET STRING }
+
+ The SignedOperation attribute is a multipart/signed S/MIME message.
+ Part 1 of the message is the directory operation, and part 2 is the
+ signature. Sequence number 0 (if present) always indicates the
+ starting point directory object as represented by the definitions in
+ "A MIME Content-Type for Directory Information", as defined in [5].
+ Subsequent sequence numbers indicate the sequence of changes that
+ have been made to this directory object. Note that the sequence of
+ the changes can be verified due to the fact that the signed directory
+ object will have a timestamp as part of the signature object, and
+ that the sequence numbering as part of the change attribute should be
+ considered to be an unverified aid to the LDAP client. Sequence
+ numbers are meaningful only within the context of a single directory
+ entry, and LDAP servers are not expected to maintain these sequence
+ numbers across all entries in the directory.
+
+ Some LDAP servers will only allow operations that include the
+ SignedOperation control. This is indicated by the inclusion of a
+ 'signedDirectoryOperationSupport' attribute in the rootDSE. This
+ attribute is defined as:
+
+
+
+
+
+
+
+
+Greenblatt & Richard Experimental [Page 4]
+
+RFC 2649 LDAP Control and Schema August 1999
+
+
+ 1.2.840.113549.6.2.2
+ NAME 'signedDirectoryOperationSupport'
+ DESC 'how many of the LDAP operations must be signed'
+ SYNTAX 'Integer' SINGLE-VALUE )
+
+ The 'signedDirectoryOperationSupport' attribute above may have one of
+ the values, '0', '1' or '2' with the following meanings:
+
+ - '0' Directory Operations may be signed
+ - '1' Directory Operations must always be signed
+ - '2' Directory Operations must never be signed
+
+ Some LDAP servers will desire that the audit trail be continuous, and
+ not contain any gaps that would result from unsigned operations.
+ Such server will include a signature on each LDAP operation that
+ changes a directory entry, even when the LDAP client does not include
+ a signed-Operation control.
+
+1.2. Handling the Delete Operation
+
+ The LDAP Delete operation represents an interesting case for Signed
+ Directory Operations. This is due to the case that subsequent to the
+ successful completion of the Delete Operation, the object that would
+ have held the latest 'Changes' attribute no longer exists. In order
+ to handle this situation, a new object class is defined to represent
+ a directory object that has been deleted.
+
+ ( 1.2.840.113549.6.1.2
+ NAME 'zombieObject'
+ SUP top
+ STRUCTURAL
+ MUST (
+ Cn $ Changes $ OriginalObject
+ )
+ )
+
+ The format of the OriginalObject attribute is:
+
+ ( 1.2.840.113549.6.2.1
+ NAME OriginalObject
+ DESC 'The LDAP URL of an object that has been deleted from the
+ directory' SYNTAX 'Binary' )
+
+ The OriginalObject attribute contains the URL of the object that was
+ deleted from the directory. It is formatted in accordance with RFC
+ 2255. Directory servers that comply with this specification SHOULD
+ create a zombieObject when performing the delete Operation that
+ contains a SignedOperation LDAPControl. The Cn attribute of the
+
+
+
+Greenblatt & Richard Experimental [Page 5]
+
+RFC 2649 LDAP Control and Schema August 1999
+
+
+ zombieObject is synthesized by the LDAP server, and may or may not be
+ related to the original name of the directory entry that was deleted.
+ All changes attributes that were attached to the original entry are
+ copied over to the zombieObject. In addition the LDAP Server MUST
+ attach the signature of the Delete operation as the last successful
+ change that was made to the entry.
+
+2. Signed Results Mechanism
+
+ A control is also defined that allows the LDAP v3 client to request
+ that the server sign the results that it returns. It is intended
+ that this control is primarily used in concert with the LDAPSearch
+ operation. This control MAY be marked as CRITICAL. If it is marked
+ as CRITICAL and the LDAP Server supports this operation, then all
+ search results MUST be returned with a signature as attached in the
+ SignedResult control if it is willing to sign results for this user.
+ If the server supports this control but does not wish to sign the
+ results for this user then the error code unwillingToPerform(53)
+ should be returned, and the LDAP search will have failed. In this
+ situation, an appropriate message (e.g. "Unwilling to sign results
+ for you!") MUST be included in the errorMessage of the LDAPResult.
+ If the LDAPSigType has the value FALSE then the client is requesting
+ that the server not sign this operation. This may be done in
+ situations where servers are configured to always sign their
+ operations.
+
+ The LDAP control to include in the LDAP request is (OID =
+ 1.2.840.113549.6.0.1):
+
+ DemandSignedResult ::= LDAPSigType
+
+ LDAPSigType ::= BOOLEAN
+
+ In response to a DemandSignedResult control, the LDAP v3 server will
+ return a SignedResult control in addition to the normal result as
+ defined by the operation (assuming that the server understands the
+ con- trol, and is willing to perform it). The SignedResult control
+ MUST NOT be marked CRITICAL. Some LDAP v3 servers may be configured
+ to sign all of their operations. In this situation the server always
+ returns a SignedResult control, unless instructed otherwise by the
+ DemandSigne-dResult Control. Since the SignedResult control is not
+ marked critical, the LDAP client is allowed to ignore it. The
+ signature field below includes the signature of the enitre LDAPResult
+ formatted as an S/MIME pkcs-7/signature object, as defined in [2].
+
+
+
+
+
+
+
+Greenblatt & Richard Experimental [Page 6]
+
+RFC 2649 LDAP Control and Schema August 1999
+
+
+ The procedure for creating the signature of the signedResult control
+ is the same as the procedure for the creation of the signedOperation
+ control. The LDAP control in the LDAP response is (OID =
+ 1.2.840.113549.6.0.2):
+
+ SignedResult ::= CHOICE {
+ signature OCTET STRING }
+
+3. Security Considerations and Other Notes
+
+ The base OIDs are:
+
+ rsadsiLdap ::= {1 2 840 113549 6}
+ rsadsiLdapControls ::= {1 2 840 113549 6 0}
+ rsadsiLdapObjectClasses ::= {1 2 840 113549 6 1}
+ rsadsiLdapAttributes ::= {1 2 840 113549 6 2}
+
+
+ The complete ASN.1 module for this specification is:
+
+ SIGNEDOPERATIONS DEFINITIONS ::=
+ BEGIN
+
+ SignedOperation ::= CHOICE {
+ signbyServer NULL,
+ signatureIncluded OCTET STRING
+ }
+
+ Changes ::= SEQUENCE {
+ sequenceNumber [0] INTEGER (0 .. maxInt),
+ signedOperation [1] OCTET STRING }
+
+ DemandSignedResult ::= LDAPSigType
+
+ LDAPSigType ::= BOOLEAN
+
+ SignedResult ::= CHOICE {
+ signature OCTET STRING }
+
+
+ END
+
+
+
+
+
+
+
+
+
+
+Greenblatt & Richard Experimental [Page 7]
+
+RFC 2649 LDAP Control and Schema August 1999
+
+
+ If any of the controls in this specification are supported by an LDAP
+ v3 server then that server MUST make available its certificate (if
+ any) in the userCertificate attribute of its rootDSE object. The
+ UserCertificate attribute is defined in [6], and contains the public
+ key of the server that is used in the creation of the various
+ signatures defined in this specification.
+
+ It is not the intention of this specification to provide a mechanism
+ that guarantees the origin and integrity of LDAP v3 operations. Such
+ a service is best provided by the use of an underlying protocol such
+ as TLS [8]. TLS defines additional features such as encryption and
+ compression. This specification does not define support for
+ encrypted operations.
+
+ This memo proposes protocol elements for transmission and storage of
+ the digital signatures of LDAP operations. Though the LDAP server
+ may have verified the operation signatures prior to their storage and
+ subsequent retrieval, it is prudent for LDAP clients to verify the
+ signatures contained in the chained attribute upon their retrieval.
+ The issuing Certification Authorities of the signer's certificate
+ should also be consulted in order to determine if the signer's
+ private key has been compromised or the certificate has been
+ otherwise revoked. Security considerations are discussed throughout
+ this memo.
+
+4. References
+
+ [1] Kaliski, B., "PKCS 7: Cryptographic Message Syntax Version 1-5",
+ RFC 2315, March 1998.
+
+ [2] Dusse, S., Hoffman, P., Ramsdell, B., Lundblade, L. and L.
+ Repka., "S/MIME Version 2 Message Specification", RFC 2311, March
+ 1998.
+
+ [3] Galvin, J., Murphy, S., Crocker, S. and N. Freed, "Security
+ Multiparts for MIME: Multipart/Signed and Multipart/Encrypted",
+ RFC 1847, October 1995.
+
+ [4] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access
+ Protocol (v3)", RFC 2251, December 1997.
+
+ [5] Howes, T., Smith, M. and F. Dawson, "A MIME Content-Type for
+ Directory Information", RFC 2425, September 1998.
+
+ [6] Wahl, M., "A Summary of the X.500(96) User Schema for use with
+ LDAPv3", RFC 2256, December 1997.
+
+
+
+
+
+Greenblatt & Richard Experimental [Page 8]
+
+RFC 2649 LDAP Control and Schema August 1999
+
+
+ [7] Howes, T. and M. Smith, "The LDAP URL Format", RFC 2255, December
+ 1997.
+
+ [8] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
+ 2246, January 1999.
+
+5. Authors' Addresses
+
+ Bruce Greenblatt
+ San Jose, CA 95119
+ USA
+
+ Phone: +1-408-224-5349
+ EMail: bgreenblatt at directory-applications.com
+
+
+ Pat Richard
+ Xcert Software, Inc.
+ Suite 1001 - 701 W. Georgia
+ Vancouver, BC
+ CANADA V6G 1C9
+
+ EMail: patr at xcert.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Greenblatt & Richard Experimental [Page 9]
+
+RFC 2649 LDAP Control and Schema August 1999
+
+
+6. Full Copyright Statement
+
+ Copyright (C) The Internet Society (1999). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Greenblatt & Richard Experimental [Page 10]
+
Added: openldap/vendor/openldap-release/doc/rfc/rfc2696.txt
===================================================================
--- openldap/vendor/openldap-release/doc/rfc/rfc2696.txt (rev 0)
+++ openldap/vendor/openldap-release/doc/rfc/rfc2696.txt 2007-09-15 10:38:52 UTC (rev 844)
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+Network Working Group C. Weider
+Request for Comments: 2696 A. Herron
+Category: Informational A. Anantha
+ Microsoft
+ T. Howes
+ Netscape
+ September 1999
+
+
+ LDAP Control Extension for Simple Paged Results Manipulation
+
+Status of this Memo
+
+ This memo provides information for the Internet community. It does
+ not specify an Internet standard of any kind. Distribution of this
+ memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (1999). All Rights Reserved.
+
+1. Abstract
+
+ This document describes an LDAPv3 control extension for simple paging
+ of search results. This control extension allows a client to control
+ the rate at which an LDAP server returns the results of an LDAP
+ search operation. This control may be useful when the LDAP client has
+ limited resources and may not be able to process the entire result
+ set from a given LDAP query, or when the LDAP client is connected
+ over a low-bandwidth connection. Other operations on the result set
+ are not defined in this extension. This extension is not designed to
+ provide more sophisticated result set management.
+
+ The key words "MUST", "SHOULD", and "MAY" used in this document are
+ to be interpreted as described in [bradner97].
+
+2. The Control
+
+ This control is included in the searchRequest and searchResultDone
+ messages as part of the controls field of the LDAPMessage, as defined
+ in Section 4.1.12 of [LDAPv3]. The structure of this control is as
+ follows:
+
+
+
+
+
+
+
+
+
+Weider, et al. Informational [Page 1]
+
+RFC 2696 LDAP Control Ext. for Simple Paged Results September 1999
+
+
+pagedResultsControl ::= SEQUENCE {
+ controlType 1.2.840.113556.1.4.319,
+ criticality BOOLEAN DEFAULT FALSE,
+ controlValue searchControlValue
+}
+
+The searchControlValue is an OCTET STRING wrapping the BER-encoded
+version of the following SEQUENCE:
+
+realSearchControlValue ::= SEQUENCE {
+ size INTEGER (0..maxInt),
+ -- requested page size from client
+ -- result set size estimate from server
+ cookie OCTET STRING
+}
+
+3. Client-Server Interaction
+
+ An LDAP client application that needs to control the rate at which
+ results are returned MAY specify on the searchRequest a
+ pagedResultsControl with size set to the desired page size and cookie
+ set to the zero-length string. The page size specified MAY be greater
+ than zero and less than the sizeLimit value specified in the
+ searchRequest.
+
+ If the page size is greater than or equal to the sizeLimit value, the
+ server should ignore the control as the request can be satisfied in a
+ single page. If the server does not support this control, the server
+ MUST return an error of unsupportedCriticalExtension if the client
+ requested it as critical, otherwise the server SHOULD ignore the
+ control. The remainder of this section assumes the server does not
+ ignore the client's pagedResultsControl.
+
+ Each time the server returns a set of results to the client when
+ processing a search request containing the pagedResultsControl, the
+ server includes the pagedResultsControl control in the
+ searchResultDone message. In the control returned to the client, the
+ size MAY be set to the server's estimate of the total number of
+ entries in the entire result set. Servers that cannot provide such an
+ estimate MAY set this size to zero (0). The cookie MUST be set to an
+ empty value if there are no more entries to return (i.e., the page of
+ search results returned was the last), or, if there are more entries
+ to return, to an octet string of the server's choosing,used to resume
+ the search.
+
+ The client MUST consider the cookie to be an opaque structure and
+ make no assumptions about its internal organization or value. When
+ the client wants to retrieve more entries for the result set, it MUST
+
+
+
+Weider, et al. Informational [Page 2]
+
+RFC 2696 LDAP Control Ext. for Simple Paged Results September 1999
+
+
+ send to the server a searchRequest with all values identical to the
+ initial request with the exception of the messageID, the cookie, and
+ optionally a modified pageSize. The cookie MUST be the octet string
+ on the last searchResultDone response returned by the server.
+ Returning cookies from previous searchResultDone responses besides
+ the last one is undefined, as the server implementation may restrict
+ cookies from being reused.
+
+ The server will then return the next set of results from the whole
+ result set. This interaction will continue until the client has
+ retrieved all the results, in which case the cookie in the
+ searchResultDone field will be empty, or until the client abandons
+ the search sequence as described below. Once the paged search
+ sequence has been completed, the cookie is no longer valid and MUST
+ NOT be used.
+
+ A sequence of paged search requests is abandoned by the client
+ sending a search request containing a pagedResultsControl with the
+ size set to zero (0) and the cookie set to the last cookie returned
+ by the server. A client MAY use the LDAP Abandon operation to
+ abandon one paged search request in progress, but this is discouraged
+ as it MAY invalidate the client's cookie.
+
+ If, for any reason, the server cannot resume a paged search operation
+ for a client, then it SHOULD return the appropriate error in a
+ searchResultDone entry. If this occurs, both client and server should
+ assume the paged result set is closed and no longer resumable.
+
+ A client may have any number of outstanding search requests pending,
+ any of which may have used the pagedResultsControl. A server
+ implementation which requires a limit on the number of outstanding
+ paged search requests from a given client MAY either return
+ unwillingToPerform when the client attempts to create a new paged
+ search request, or age out an older result set. If the server
+ implementation ages out an older paged search request, it SHOULD
+ return "unwilling to perform" if the client attempts to resume the
+ paged search that was aged out.
+
+ A client may safely assume that all entries that satisfy a given
+ search query are returned once and only once during the set of paged
+ search requests/responses necessary to enumerate the entire result
+ set, unless the result set for that query has changed since the
+ searchRequest starting the request/response sequence was processed.
+ In that case, the client may receive a given entry multiple times
+ and/or may not receive all entries matching the given search
+ criteria.
+
+
+
+
+
+Weider, et al. Informational [Page 3]
+
+RFC 2696 LDAP Control Ext. for Simple Paged Results September 1999
+
+
+4. Example
+
+ The following example illustrates the client-server interaction
+ between a client doing a search requesting a page size limit of 3.
+ The entire result set returned by the server contains 5 entries.
+
+ Lines beginning with "C:" indicate requests sent from client to
+ server. Lines beginning with "S:" indicate responses sent from server
+ to client. Lines beginning with "--" are comments to help explain the
+ example.
+
+ -- Client sends a search request asking for paged results
+ -- with a page size of 3.
+ C: SearchRequest + pagedResultsControl(3,"")
+ -- Server responds with three entries plus an indication
+ -- of 5 total entries in the search result and an opaque
+ -- cooking to be used by the client when retrieving subsequent
+ -- pages.
+ S: SearchResultEntry
+ S: SearchResultEntry
+ S: SearchResultEntry
+ S: SearchResultDone + pagedResultsControl(5, "opaque")
+ -- Client sends an identical search request (except for
+ -- message id), returning the opaque cooking, asking for
+ -- the next page.
+ C: SearchRequest + PagedResultsControl(3, "opaque")
+ -- Server responds with two entries plus an indication
+ -- that there are no more entries (null cookie).
+ S: SearchResultEntry
+ S: SearchResultEntry
+ S: SearchResultDone + pagedResultsControl(5,"")
+
+5. Relationship to X.500
+
+ For LDAP servers providing a front end to X.500 (93) directories, the
+ paged results control defined in this document may be mapped directly
+ onto the X.500 (93) PagedResultsRequest defined in X.511 [x500]. The
+ size parameter may be mapped onto pageSize. The cookie parameter may
+ be mapped onto queryReference. The sortKeys and reverse fields in
+ the X.500 PagedResultsRequest are excluded.
+
+
+
+
+
+
+
+
+
+
+
+Weider, et al. Informational [Page 4]
+
+RFC 2696 LDAP Control Ext. for Simple Paged Results September 1999
+
+
+6. Security Considerations
+
+ Server implementors should consider the resources used when clients
+ send searches with the simple paged control, to ensure that a
+ client's misuse of this control does not lock out other legitimate
+ operations.
+
+ Servers implementations may enforce an overriding sizelimit, to
+ prevent the retrieval of large portions of a publically-accessible
+ directory.
+
+ Clients can, using this control, determine how many entries match a
+ particular filter, before the entries are returned to the client.
+ This may require special processing in servers which perform access
+ control checks on entries to determine whether the existence of the
+ entry can be disclosed to the client.
+
+7. References
+
+ [LDAPv3] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory
+ Access Protocol (v3)", RFC 2251, December 1997.
+
+ [Bradner97] Bradner, S., "Key Words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Weider, et al. Informational [Page 5]
+
+RFC 2696 LDAP Control Ext. for Simple Paged Results September 1999
+
+
+8. Authors' Addresses
+
+ Chris Weider
+ Microsoft Corp.
+ 1 Microsoft Way
+ Redmond, WA 98052
+ USA
+
+ Phone: +1 425 882-8080
+ EMail: cweider at microsoft.com
+
+
+ Andy Herron
+ Microsoft Corp.
+ 1 Microsoft Way
+ Redmond, WA 98052
+ USA
+
+ Phone: +1 425 882-8080
+ EMail: andyhe at microsoft.com
+
+
+ Anoop Anantha
+ Microsoft Corp.
+ 1 Microsoft Way
+ Redmond, WA 98052
+ USA
+
+ Phone: +1 425 882-8080
+ EMail: anoopa at microsoft.com
+
+
+ Tim Howes
+ Netscape Communications Corp.
+ 501 E. Middlefield Road
+ Mountain View, CA 94043
+ USA
+
+ Phone: +1 415 937-2600
+ EMail: howes at netscape.com
+
+
+
+
+
+
+
+
+
+
+
+Weider, et al. Informational [Page 6]
+
+RFC 2696 LDAP Control Ext. for Simple Paged Results September 1999
+
+
+9. Full Copyright Statement
+
+ Copyright (C) The Internet Society (1999). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Weider, et al. Informational [Page 7]
+
Added: openldap/vendor/openldap-release/doc/rfc/rfc2713.txt
===================================================================
--- openldap/vendor/openldap-release/doc/rfc/rfc2713.txt (rev 0)
+++ openldap/vendor/openldap-release/doc/rfc/rfc2713.txt 2007-09-15 10:38:52 UTC (rev 844)
@@ -0,0 +1,1179 @@
+
+
+
+
+
+
+Network Working Group V. Ryan
+Request for Comments: 2713 S. Seligman
+Category: Informational R. Lee
+ Sun Microsystems, Inc.
+ October 1999
+
+
+ Schema for Representing Java(tm) Objects in an LDAP Directory
+
+Status of this Memo
+
+ This memo provides information for the Internet community. It does
+ not specify an Internet standard of any kind. Distribution of this
+ memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (1999). All Rights Reserved.
+
+Abstract
+
+ This document defines the schema for representing Java(tm) objects in
+ an LDAP directory [LDAPv3]. It defines schema elements to represent
+ a Java serialized object [Serial], a Java marshalled object [RMI], a
+ Java remote object [RMI], and a JNDI reference [JNDI].
+
+1. Introduction
+
+ This document assumes that the reader has a general knowledge of the
+ Java programming language [Java]. For brevity we use the term "Java
+ object" in place of "object in the Java programming language"
+ throughout this text.
+
+ Traditionally, LDAP directories have been used to store data. Users
+ and programmers think of the directory as a hierarchy of directory
+ entries, each containing a set of attributes. You look up an entry
+ from the directory and extract the attribute(s) of interest. For
+ example, you can look up a person's telephone number from the
+ directory. Alternatively, you can search the directory for entries
+ with a particular set of attributes. For example, you can search for
+ all persons in the directory with the surname "Smith".
+
+ For applications written in the Java programming language, a kind of
+ data that is typically shared are Java objects themselves. For such
+ applications, it makes sense to be able to use the directory as a
+ repository for Java objects. The directory provides a centrally
+ administered, and possibly replicated, service for use by Java
+ applications distributed across the network.
+
+
+
+Ryan, et al. Informational [Page 1]
+
+RFC 2713 Schema for Java Objects October 1999
+
+
+ For example, an application server might use the directory for
+ "registering" objects representing the services that it manages, so
+ that a client can later search the directory to locate those services
+ as it needs.
+
+ The motivation for this document is to define a common way for
+ applications to store and retrieve Java objects from the directory.
+ Using this common schema, any Java application that needs to read or
+ store Java objects in the directory can do so in an interoperable
+ way.
+
+2 Representation of Java Objects
+
+ This document defines schema elements to represent three types of
+ Java objects: a Java serialized object, a Java marshalled object,
+ and a JNDI reference. A Java remote object is stored as either a Java
+ marshalled object or a JNDI reference.
+
+2.1 Common Representations
+
+ A Java object is stored in the LDAP directory by using the object
+ class javaObject. This is the base class from which other Java object
+ related classes derive: javaSerializedObject, javaMarshalledObject,
+ and javaNamingReference. javaObject is an abstract object class,
+ which means that a javaObject cannot exist by itself in the
+ directory; only auxiliary or structural subclasses of it can exist in
+ the directory.
+
+ The object class javaContainer represents a directory entry dedicated
+ to storing a Java object. It is a structural object class. In cases
+ where a subclass of javaObject is mixed in with another structural
+ object class, javaContainer is not required.
+
+ The definitions for the object classes javaObject and javaContainer
+ are presented in Section 4.
+
+ The javaObject class has one mandatory attribute (javaClassName) and
+ four optional attributes (javaClassNames, javaCodebase, javaDoc,
+ description). javaClassName is a single valued attribute that is
+ used to store the fully qualified name of the object's Java class
+ (for example, "java.lang.String"). This may be the object's most
+ derived class's name, but does not have to be; that of a superclass
+ or interface in some cases might be most appropriate. This attribute
+ is intended for storing the name of the object's "distinguished"
+ class, that is, the class or interface with which the object should
+ be identified.
+
+
+
+
+
+Ryan, et al. Informational [Page 2]
+
+RFC 2713 Schema for Java Objects October 1999
+
+
+ javaClassNames is a multivalued attribute that is used to store the
+ fully qualified names of the object's Java classes and interfaces
+ (for example, "java.lang.Byte"). Like all multivalued attributes, the
+ javaClassNames attribute's values are unordered and so no one value
+ is more "distinguished" than the others. This attribute is intended
+ for storing an object's class and interface names and those of its
+ ancestor classes and interfaces, although the list of values does not
+ have to be complete. If the javaClassNames attribute is present, it
+ should include the value of javaClassName.
+
+ For example, suppose an object is stored in the directory with a
+ javaClassName attribute of "java.io.FilePermission", and a
+ javaClassNames attribute of {"java.security.Permission",
+ "java.io.FilePermission", "java.security.Guard",
+ "java.io.Serializable"}. An application searching a directory for
+ Java objects might use javaClassName to produce a summary of the
+ names and types of Java objects in that directory. Another
+ application might use the javaClassNames attribute to find, for
+ example, all java.security.Permission objects.
+
+ javaCodebase is a multivalued attribute that is used to store the
+ location(s) of the object's class definition. javaDoc is used to
+ store a pointer (URL) to the Java documentation for the class.
+ description is used to store a textual description of a Java object
+ and is defined in [v3Schema]. The definitions of these attributes are
+ presented in Section 3.
+
+2.2 Serialized Objects
+
+ To "serialize" an object means to convert its state into a byte
+ stream in such a way that the byte stream can be converted back into
+ a copy of the object. A Java object is "serializable" if its class
+ or any of its superclasses implements either the java.io.Serializable
+ interface or its subinterface java.io.Externalizable.
+ "Deserialization" is the process of converting the serialized form of
+ an object back into a copy of the object. When an object is
+ serialized, the entire tree of objects rooted at the object is also
+ serialized. When it is deserialized, the tree is reconstructed. For
+ example, suppose a serializable Book object contains (a serializable
+ field of) an array of Page objects. When a Book object is
+ serialized, so is the array of Page objects.
+
+ The Java platform specifies a default algorithm by which serializable
+ objects are serialized. A Java class can also override this default
+ serialization with its own algorithm. [Serial] describes object
+ serialization in detail.
+
+
+
+
+
+Ryan, et al. Informational [Page 3]
+
+RFC 2713 Schema for Java Objects October 1999
+
+
+ When an object is serialized, information that identifies its class
+ is recorded in the serialized stream. However, the class's definition
+ ("class file") itself is not recorded. It is the responsibility of
+ the system that is deserializing the object to determine the
+ mechanism to use for locating and loading the associated class
+ definitions. For example, the Java application might include in its
+ classpath a JAR file containing the class definitions of the
+ serialized object, or load the class definitions using information
+ from the directory, as explained below.
+
+2.2.1 Representation in the Directory
+
+ A serialized object is represented in the directory by the attributes
+ javaClassName, javaClassNames, javaCodebase, and javaSerializedData,
+ as defined in Section 3. The mandatory attribute,
+ javaSerializedData, contains the serialized form of the object.
+ Although the serialized form already contains the class name, the
+ mandatory javaClassName attribute also records the class name of the
+ serialized object so that applications can determined class
+ information without having to first deserialize the object. The
+ optional javaClassNames attribute is used to record additional class
+ information about the serialized object. The optional javaCodebase
+ attribute is used to record the locations of the class definitions
+ needed to deserialize the serialized object.
+
+ A directory entry that contains a serialized object is represented by
+ the object class javaSerializedObject, which is a subclass of
+ javaObject. javaSerializedObject is an auxiliary object class, which
+ means that it needs to be mixed in with a structural object class.
+ javaSerializedObject's definition is given in Section 4.
+
+2.3 Marshalled Objects
+
+ To "marshal" an object means to record its state and codebase(s) in
+ such a way that when the marshalled object is "unmarshalled," a copy
+ of the original object is obtained, possibly by automatically loading
+ the class definitions of the object. You can marshal any object that
+ is serializable or remote (that is, implements the java.rmi.Remote
+ interface). Marshalling is like serialization, except marshalling
+ also records codebases. Marshalling is different from serialization
+ in that marshalling treats remote objects specially. If an object is
+ a java.rmi.Remote object, marshalling records the remote object's
+ "stub" (see Section 2.5), instead of the remote object itself. Like
+ serialization, when an object is marshalled, the entire tree of
+ objects rooted at the object is marshalled. When it is unmarshalled,
+ the tree is reconstructed.
+
+
+
+
+
+Ryan, et al. Informational [Page 4]
+
+RFC 2713 Schema for Java Objects October 1999
+
+
+ A "marshalled" object is the represented by the
+ java.rmi.MarshalledObject class. Here's an example of how to create
+ MarshalledObjects for serializable and remote objects:
+
+ java.io.Serializable sobj = ...;
+ java.rmi.MarshalledObject mobj1 =
+ new java.rmi.MarshalledObject(sobj);
+
+ java.rmi.Remote robj = ...;
+ java.rmi.MarshalledObject mobj2 =
+ new java.rmi.MarshalledObject(robj);
+
+ Then, to retrieve the original objects from the MarshalledObjects, do
+ as follows:
+
+ java.io.Serializable sobj = (java.io.Serializable) mobj1.get();
+ java.io.Remote rstub = (java.io.Remote) mobj2.get();
+
+ MarshalledObject is available only on the Java 2 Platform, Standard
+ Edition, v1.2, and higher releases.
+
+2.3.1 Representation in the Directory
+
+ A marshalled object is represented in the directory by the attributes
+ javaClassName, javaClassNames, and javaSerializedData, as defined in
+ Section 3. The mandatory attribute, javaSerializedData, contains the
+ serialized form of the marshalled object (that is, the serialized
+ form of a MarshalledObject instance). The mandatory javaClassName
+ attribute records the distinguished class name of the object before
+ it has been marshalled. The optional javaClassNames attribute is
+ used to record additional class information about the object before
+ it has been marshalled.
+
+ A directory entry that contains a marshalled object is represented by
+ the object class javaMarshalledObject, which is a subclass of
+ javaObject. javaMarshalledObject is an auxiliary object class, which
+ means that it needs to be mixed in with a structural object class.
+ javaMarshalledObject's definition is given in Section 4.
+
+ As evident in this description, a javaMarshalledObject differs from a
+ javaSerializedObject only in the interpretation of the javaClassName
+ and javaClassNames attributes.
+
+
+
+
+
+
+
+
+
+Ryan, et al. Informational [Page 5]
+
+RFC 2713 Schema for Java Objects October 1999
+
+
+2.4 JNDI References
+
+ Java Naming and Directory Interface(tm) (JNDI) is a directory access
+ API specified in the Java programming language [JNDI]. It provides
+ an object-oriented view of the directory, allowing Java objects to be
+ added to and retrieved from the directory without requiring the
+ client to manage data representation issues.
+
+ JNDI defines the notion of a "reference" for use when an object
+ cannot be stored in the directory directly, or when it is
+ inappropriate or undesirable to do so. An object with an associated
+ reference is stored in the directory indirectly, by storing its
+ reference instead.
+
+2.4.1 Contents of a Reference
+
+ A JNDI reference is a Java object of class javax.naming.Reference.
+ It consists of class information about the object being referenced
+ and an ordered list of addresses. An address is a Java object of
+ class javax.naming.RefAddr. Each address contains information on how
+ to construct the object.
+
+ A common use for JNDI references is to represent connections to a
+ network service such as a database, directory, or file system. Each
+ address may then identify a "communications endpoint" for that
+ service, containing information on how to contact the service.
+ Multiple addresses may arise for various reasons, such as replication
+ or the object offering interfaces over more than one communication
+ mechanism.
+
+ A reference also contains information to assist in the creation of an
+ instance of the object to which the reference refers. It contains
+ the Java class name of that object, and the class name and location
+ of the object factory to be used to create the object. The
+ procedures for creating an object given its reference and the reverse
+ are described in [JNDI].
+
+2.4.2 Representation in the Directory
+
+ A JNDI reference is stored in the directory by using the attributes
+ javaClassName, javaClassNames, javaCodebase, javaReferenceAddress,
+ and javaFactory, defined in Section 3. These attributes store
+ information corresponding to the contents of a reference described
+ above. javaReferenceAddress is a multivalued optional attribute for
+ storing reference addresses. javaFactory is the optional attribute
+ for storing the object factory's fully qualified class name. The
+ mandatory javaClassName attribute is used to store the name of the
+ distinguished class of the object. The optional javaClassNames
+
+
+
+Ryan, et al. Informational [Page 6]
+
+RFC 2713 Schema for Java Objects October 1999
+
+
+ attribute is used to record additional class and interface names.
+ The optional javaCodebase attribute is used to store the locations of
+ the object factory's and the object's class definitions.
+
+ A directory entry containing a JNDI reference is represented by the
+ object class javaNamingReference, which is a subclass of javaObject.
+ javaNamingReference is an auxiliary object class, which means that it
+ needs to be mixed in with a structural object class.
+ javaNamingReference's definition is given in Section 4.
+
+2.5 Remote Objects
+
+ The Java Remote Method Invocation (RMI) system [RMI] is a mechanism
+ that enables an object on one Java virtual machine to invoke methods
+ on an object in another Java virtual machine. Any object whose
+ methods can be invoked in this way must implement the java.rmi.Remote
+ interface. When such an object is invoked, its arguments are
+ marshalled and sent from the local virtual machine to the remote one,
+ where the arguments are unmarshalled and used. When the method
+ terminates, the results are marshalled from the remote machine and
+ sent to the caller's virtual machine.
+
+ To make a remote object accessible to other virtual machines, a
+ program typically registers it with the RMI registry. The program
+ supplies to the RMI registry the string name of the remote object and
+ the remote object itself. When a program wants to access a remote
+ object, it supplies the object's string name to the RMI registry on
+ the same machine as the remote object. The RMI registry returns to
+ the caller a reference (called "stub") to the remote object. When
+ the program receives the stub for the remote object, it can invoke
+ methods on the remote object (through the stub). A program can also
+ obtain references to remote objects as a result of remote calls to
+ other remote objects or from other naming services. For example, the
+ program can look up a reference to a remote object from an LDAP
+ server that supports the schema defined in this document.
+
+ The string name accepted by the RMI registry has the syntax
+ "rmi://hostname:port/remoteObjectName", where "hostname" and "port"
+ identify the machine and port on which the RMI registry is running,
+ respectively, and "remoteObjectName" is the string name of the remote
+ object. "hostname", "port", and the prefix, "rmi:", are optional. If
+ "hostname" is not specified, it defaults to the local host. If
+ "port" is not specified, it defaults to 1099. If "remoteObjectName"
+ is not specified, then the object being named is the RMI registry
+ itself. See [RMI] for details.
+
+
+
+
+
+
+Ryan, et al. Informational [Page 7]
+
+RFC 2713 Schema for Java Objects October 1999
+
+
+ RMI can be supported using different protocols: the Java Remote
+ Method Protocol (JRMP) and the Internet Inter-ORB Protocol (IIOP).
+ The JRMP is a specialized protocol designed for RMI; the IIOP is the
+ standard protocol for communication between CORBA objects [CORBA].
+ RMI over IIOP allows Java remote objects to communicate with CORBA
+ objects which might be written in a non-Java programming language
+ [RMI-IIOP].
+
+2.5.1 Representation in the Directory
+
+ Remote objects that use the IIOP are represented in the directory as
+ CORBA object references [CORBA-LDAP]. Remote objects that use the
+ JRMP are represented in the directory in one of two ways: as a
+ marshalled object, or as a JNDI reference.
+
+ A marshalled object records the codebases of the remote object's stub
+ and any serializable or remote objects that it references, and
+ replaces remote objects with their stubs. To store a Remote object
+ as a marshalled object (java.rmi.MarshalledObject), you first create
+ a java.rmi.MarshalledObject instance for it.
+
+ java.rmi.Remote robj = ...;
+ java.rmi.MarshalledObject mobj =
+ new java.rmi.MarshalledObject(robj);
+
+ You can then store the MarshalledObject instance as a
+ javaMarshalledObject. The javaClassName attribute should contain the
+ fully qualified name of the distinguished class of the remote object.
+ The javaClassNames attribute should contain the names of the classes
+ and interfaces of the remote object. To read the remote object back
+ from the directory, first deserialize the contents of the
+ javaSerializedData to get a MarshalledObject (mobj), then retrieve it
+ from the MarshalledObject as follows:
+
+ java.rmi.Remote robj = (java.rmi.Remote)mobj.get();
+
+ This returns the remote stub, which you can then use to invoke remote
+ methods.
+
+ MarshalledObject is available only on the Java 2 Platform, Standard
+ Edition, v1.2 and higher releases. Therefore, a remote object stored
+ as a MarshalledObject can only be read by clients using the the Java
+ 2 Platform, Standard Edition, v1.2 or higher releases.
+
+
+
+
+
+
+
+
+Ryan, et al. Informational [Page 8]
+
+RFC 2713 Schema for Java Objects October 1999
+
+
+ To store a remote object as a JNDI reference, you first create a
+ javax.naming.Reference object instance for it using the remote
+ object's string name as it has been, or will be, recorded with the
+ RMI registry, with the additional restriction that the "rmi:" prefix
+ must be present. Here's an example:
+
+ javax.naming.Reference ref = new javax.naming.Reference(
+ obj.getClass().getName(),
+ new javax.naming.StringRefAddr("URL",
+ "rmi://rserver/AppRemoteObjectX"));
+
+ You then store the javax.naming.Reference instance as a
+ javaNamingReference. The advantage of using a JNDI reference is that
+ this can be done without a reference to the remote object. In fact,
+ the remote object does not have to exist at the time that this
+ recording in the directory is made. The remote object needs to exist
+ and be bound with the RMI registry when the object is looked up from
+ the directory.
+
+2.6 Serialized Objects Vs. Marshalled Objects Vs. References
+
+ The object classes defined in this document store different aspects
+ of the Java objects.
+
+ A javaSerializedObject or a serializable object stored as a
+ javaMarshalledObject represents the object itself, while a
+ javaNamingReference or a remote object stored as a
+ javaMarshalledObject represents a "pointer" to the object.
+
+ When storing a serializable object in the directory, you have a
+ choice of storing it as a javaSerializedObject or a
+ javaMarshalledObject. The javaSerializedObject object class provides
+ the basic way in which to store serializable objects. When you create
+ an LDAP entry using the javaSerializableObject object class, you must
+ explicitly set the javaCodebase attribute if you want readers of that
+ entry to know where to load the class definitions of the object. When
+ you create an LDAP entry using the javaMarshalledObject object class,
+ you use the MarshalledObject class. The MarshalledObject class uses
+ the RMI infrastructure available on the Java platform to automate how
+ codebase information is gathered and recorded, thus freeing you from
+ having to set the javaCodebase attribute. On the other hand, the
+ javaCodebase attribute is human-readable and can be updated easily by
+ using text-based tools without having to change other parts of the
+ entry. This allows you, for instance, to move the class definitions
+ to another location and then update the javaCodebase attribute to
+ reflect the move without having to update the serialized object
+ itself.
+
+
+
+
+Ryan, et al. Informational [Page 9]
+
+RFC 2713 Schema for Java Objects October 1999
+
+
+ A javaNamingReference provides a way of recording address information
+ about an object which itself is not directly stored in the directory.
+ A remote object stored as a javaMarshalledObject also records address
+ information (the object's "stub") of an object which itself is not
+ directory stored in the directory. In other words, you can think of
+ these as compact representations of the information required to
+ access the object.
+
+ A javaNamingReference typically consists of a small number of human-
+ readable strings. Standard text-based tools for directory
+ administration may therefore be used to add, read, or modify
+ reference entries -- if so desired -- quite easily. Serialized and
+ marshalled objects are not intended to be read or manipulated
+ directly by humans.
+
+3 Attribute Type Definitions
+
+ The following attribute types are defined in this document:
+
+ javaClassName
+ javaClassNames
+ javaCodebase
+ javaSerializedData
+ javaFactory
+ javaReferenceAddress
+ javaDoc
+
+3.1 javaClassName
+
+ This attribute stores the fully qualified name of the Java object's
+ "distinguished" class or interface (for example, "java.lang.String").
+ It is a single-valued attribute. This attribute's syntax is '
+ Directory String' and its case is significant.
+
+ ( 1.3.6.1.4.1.42.2.27.4.1.6
+ NAME 'javaClassName'
+ DESC 'Fully qualified name of distinguished Java class or
+ interface'
+ EQUALITY caseExactMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ SINGLE-VALUE
+ )
+
+
+
+
+
+
+
+
+
+Ryan, et al. Informational [Page 10]
+
+RFC 2713 Schema for Java Objects October 1999
+
+
+3.2 javaCodebase
+
+ This attribute stores the Java class definition's locations. It
+ specifies the locations from which to load the class definition for
+ the class specified by the javaClassName attribute. Each value of
+ the attribute contains an ordered list of URLs, separated by spaces.
+ For example, a value of "url1 url2 url3" means that the three
+ (possibly interdependent) URLs (url1, url2, and url3) form the
+ codebase for loading in the Java class definition.
+
+ If the javaCodebase attribute contains more than one value, each
+ value is an independent codebase. That is, there is no relationship
+ between the URLs in one value and those in another; each value can be
+ viewed as an alternate source for loading the Java class definition.
+ See [Java] for information regarding class loading.
+
+ This attribute's syntax is 'IA5 String' and its case is significant.
+
+ ( 1.3.6.1.4.1.42.2.27.4.1.7
+ NAME 'javaCodebase'
+ DESC 'URL(s) specifying the location of class definition'
+ EQUALITY caseExactIA5Match
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
+ )
+
+3.3 javaClassNames
+
+ This attribute stores the Java object's fully qualified class or
+ interface names (for example, "java.lang.String"). It is a
+ multivalued attribute. When more than one value is present, each is
+ the name of a class or interface, or ancestor class or interface, of
+ this object.
+
+ This attribute's syntax is 'Directory String' and its case is
+ significant.
+
+ ( 1.3.6.1.4.1.42.2.27.4.1.13
+ NAME 'javaClassNames'
+ DESC 'Fully qualified Java class or interface name'
+ EQUALITY caseExactMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ )
+
+
+
+
+
+
+
+
+
+Ryan, et al. Informational [Page 11]
+
+RFC 2713 Schema for Java Objects October 1999
+
+
+3.4 javaSerializedData
+
+ This attribute stores the serialized form of a Java object. The
+ serialized form is described in [Serial].
+
+ This attribute's syntax is 'Octet String'.
+
+ ( 1.3.6.1.4.1.42.2.27.4.1.8
+ NAME 'javaSerializedData
+ DESC 'Serialized form of a Java object'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.40
+ SINGLE-VALUE
+ )
+
+3.5 javaFactory
+
+ This attribute stores the fully qualified class name of the object
+ factory (for example, "com.wiz.jndi.WizObjectFactory") that can be
+ used to create an instance of the object identified by the
+ javaClassName attribute.
+
+ This attribute's syntax is 'Directory String' and its case is
+ significant.
+
+ ( 1.3.6.1.4.1.42.2.27.4.1.10
+ NAME 'javaFactory'
+ DESC 'Fully qualified Java class name of a JNDI object factory'
+ EQUALITY caseExactMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ SINGLE-VALUE
+ )
+
+3.6 javaReferenceAddress
+
+ This attribute represents the sequence of addresses of a JNDI
+ reference. Each of its values represents one address, a Java object
+ of type javax.naming.RefAddr. Its value is a concatenation of the
+ address type and address contents, preceded by a sequence number (the
+ order of addresses in a JNDI reference is significant). For example:
+
+ #0#TypeA#ValA
+ #1#TypeB#ValB
+ #2#TypeC##rO0ABXNyABpq...
+
+ In more detail, the value is encoded as follows:
+
+
+
+
+
+
+Ryan, et al. Informational [Page 12]
+
+RFC 2713 Schema for Java Objects October 1999
+
+
+ The delimiter is the first character of the value. For readability
+ the character '#' is recommended when it is not otherwise used
+ anywhere in the value, but any character may be used subject to
+ restrictions given below.
+
+ The first delimiter is followed by the sequence number. The sequence
+ number of an address is its position in the JNDI reference, with the
+ first address being numbered 0. It is represented by its shortest
+ string form, in decimal notation.
+
+ The sequence number is followed by a delimiter, then by the address
+ type, and then by another delimiter. If the address is of Java class
+ javax.naming.StringRefAddr, then this delimiter is followed by the
+ value of the address contents (which is a string). Otherwise, this
+ delimiter is followed immediately by another delimiter, and then by
+ the Base64 encoding of the serialized form of the entire address.
+
+ The delimiter may be any character other than a digit or a character
+ contained in the address type. In addition, if the address contents
+ is a string, the delimiter may not be the first character of that
+ string.
+
+ This attribute's syntax is 'Directory String' and its case is
+ significant. It can contain multiple values.
+
+ ( 1.3.6.1.4.1.42.2.27.4.1.11
+ NAME 'javaReferenceAddress'
+ DESC 'Addresses associated with a JNDI Reference'
+ EQUALITY caseExactMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ )
+
+3.7 javaDoc
+
+ This attribute stores a pointer to the Java documentation for the
+ class. It's value is a URL. For example, the following URL points to
+ the specification of the java.lang.String class:
+ http://java.sun.com/products/jdk/1.2/docs/api/java/lang/String.html
+
+ This attribute's syntax is 'IA5 String' and its case is significant.
+
+ ( 1.3.6.1.4.1.42.2.27.4.1.12
+ NAME 'javaDoc'
+ DESC 'The Java documentation for the class'
+ EQUALITY caseExactIA5Match
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
+ )
+
+
+
+
+Ryan, et al. Informational [Page 13]
+
+RFC 2713 Schema for Java Objects October 1999
+
+
+4 Object Class Definitions
+
+ The following object classes are defined in this document:
+
+ javaContainer
+ javaObject
+ javaSerializedObject
+ javaMarshalledObject
+ javaNamingReference
+
+4.1 javaContainer
+
+ This structural object class represents a container for a Java
+ object.
+
+ ( 1.3.6.1.4.1.42.2.27.4.2.1
+ NAME 'javaContainer'
+ DESC 'Container for a Java object'
+ SUP top
+ STRUCTURAL
+ MUST ( cn )
+ )
+
+4.2 javaObject
+
+ This abstract object class represents a Java object. A javaObject
+ cannot exist in the directory; only auxiliary or structural
+ subclasses of it can exist in the directory.
+
+ ( 1.3.6.1.4.1.42.2.27.4.2.4
+ NAME 'javaObject'
+ DESC 'Java object representation'
+ SUP top
+ ABSTRACT
+ MUST ( javaClassName )
+ MAY ( javaClassNames $
+ javaCodebase $
+ javaDoc $
+ description )
+ )
+
+
+
+
+
+
+
+
+
+
+
+Ryan, et al. Informational [Page 14]
+
+RFC 2713 Schema for Java Objects October 1999
+
+
+4.3 javaSerializedObject
+
+ This auxiliary object class represents a Java serialized object. It
+ must be mixed in with a structural object class.
+
+ ( 1.3.6.1.4.1.42.2.27.4.2.5
+ NAME 'javaSerializedObject'
+ DESC 'Java serialized object'
+ SUP javaObject
+ AUXILIARY
+ MUST ( javaSerializedData )
+ )
+
+4.4 javaMarshalledObject
+
+ This auxiliary object class represents a Java marshalled object. It
+ must be mixed in with a structural object class.
+
+ ( 1.3.6.1.4.1.42.2.27.4.2.8
+ NAME 'javaMarshalledObject'
+ DESC 'Java marshalled object'
+ SUP javaObject
+ AUXILIARY
+ MUST ( javaSerializedData )
+ )
+
+4.5 javaNamingReference
+
+ This auxiliary object class represents a JNDI reference. It must be
+ mixed in with a structural object class.
+
+ ( 1.3.6.1.4.1.42.2.27.4.2.7
+ NAME 'javaNamingReference'
+ DESC 'JNDI reference'
+ SUP javaObject
+ AUXILIARY
+ MAY ( javaReferenceAddress $
+ javaFactory )
+ )
+
+
+
+
+
+
+
+
+
+
+
+
+Ryan, et al. Informational [Page 15]
+
+RFC 2713 Schema for Java Objects October 1999
+
+
+5. Security Considerations
+
+ Serializing an object and storing it into the directory enables (a
+ copy of) the object to be examined and used outside the environment
+ in which it was originally created. The directory entry containing
+ the serialized object could be read and modified within the
+ constraints imposed by the access control mechanisms of the
+ directory. If an object contains sensitive information or
+ information that could be misused outside of the context in which it
+ was created, the object should not be stored in the directory. For
+ more details on security issues relating to serialization in general,
+ see [Serial].
+
+6. Acknowledgements
+
+ We would like to thank Joseph Fialli, Peter Jones, Roger Riggs, Bob
+ Scheifler, and Ann Wollrath of Sun Microsystems for their comments
+ and suggestions.
+
+7. References
+
+ [CORBA] The Object Management Group, "Common Object Request
+ Broker Architecture Specification 2.0,"
+ http://www.omg.org
+
+ [CORBA-LDAP] Ryan, V., Lee, R. and S. Seligman, "Schema for
+ Representing CORBA Object References in an LDAP
+ Directory", RFC 2714, October 1999.
+
+ [Java] Ken Arnold and James Gosling, "The Java(tm) Programming
+ Language," Second Edition, ISBN 0-201-31006-6.
+
+ [JNDI] Java Software, Sun Microsystems, Inc., "The Java(tm)
+ Naming and Directory Interface (tm) Specification,"
+ February 1998. http://java.sun.com/products/jndi/
+
+ [LDAPv3] Wahl, M., Howes, T. and S. Kille, "Lightweight
+ Directory Access Protocol (v3)", RFC 2251, December
+ 1997.
+
+ [RMI] Java Software, Sun Microsystems, Inc., "Remote Method
+ Invocation," November 1998.
+ http://java.sun.com/products/jdk/1.2/docs/guide/rmi
+
+
+
+
+
+
+
+
+Ryan, et al. Informational [Page 16]
+
+RFC 2713 Schema for Java Objects October 1999
+
+
+ [RMI-IIOP] IBM and Java Software, Sun Microsystems, Inc., "RMI over
+ IIOP", June 1999.
+ http://java.sun.com/products/rmi-iiop/
+
+ [Serial] Java Software, Sun Microsystems, Inc., "Object
+ Serialization Specification," November 1998.
+ http://java.sun.com/products/jdk/1.2/docs/guide/
+ serialization
+
+ [v3Schema] Wahl, M., "A Summary of the X.500(96) User Schema for
+ use with LDAPv3", RFC 2256, December 1997.
+
+8. Authors' Addresses
+
+ Vincent Ryan
+ Sun Microsystems, Inc.
+ Mail Stop EDUB03
+ 901 San Antonio Road
+ Palo Alto, CA 94303
+ USA
+
+ Phone: +353 1 819 9151
+ EMail: vincent.ryan at ireland.sun.com
+
+
+ Scott Seligman
+ Sun Microsystems, Inc.
+ Mail Stop UCUP02-209
+ 901 San Antonio Road
+ Palo Alto, CA 94303
+ USA
+
+ Phone: +1 408 863 3222
+ EMail: scott.seligman at eng.sun.com
+
+
+ Rosanna Lee
+ Sun Microsystems, Inc.
+ Mail Stop UCUP02-206
+ 901 San Antonio Road
+ Palo Alto, CA 94303
+ USA
+
+ Phone: +1 408 863 3221
+ EMail: rosanna.lee at eng.sun.com
+
+
+
+
+
+
+Ryan, et al. Informational [Page 17]
+
+RFC 2713 Schema for Java Objects October 1999
+
+
+Appendix - LDAP Schema
+
+ -- Attribute types --
+
+ ( 1.3.6.1.4.1.42.2.27.4.1.6
+ NAME 'javaClassName'
+ DESC 'Fully qualified name of distinguished Java class or interface'
+ EQUALITY caseExactMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ SINGLE-VALUE
+ )
+
+ ( 1.3.6.1.4.1.42.2.27.4.1.7
+ NAME 'javaCodebase'
+ DESC 'URL(s) specifying the location of class definition'
+ EQUALITY caseExactIA5Match
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
+ )
+
+ ( 1.3.6.1.4.1.42.2.27.4.1.8
+ NAME 'javaSerializedData'
+ DESC 'Serialized form of a Java object'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.40
+ SINGLE-VALUE
+ )
+
+ ( 1.3.6.1.4.1.42.2.27.4.1.10
+ NAME 'javaFactory'
+ DESC 'Fully qualified Java class name of a JNDI object factory'
+ EQUALITY caseExactMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ SINGLE-VALUE
+ )
+
+ ( 1.3.6.1.4.1.42.2.27.4.1.11
+ NAME 'javaReferenceAddress'
+ DESC 'Addresses associated with a JNDI Reference'
+ EQUALITY caseExactMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ )
+
+ ( 1.3.6.1.4.1.42.2.27.4.1.12
+ NAME 'javaDoc'
+ DESC 'The Java documentation for the class'
+ EQUALITY caseExactIA5Match
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
+ )
+
+
+
+
+Ryan, et al. Informational [Page 18]
+
+RFC 2713 Schema for Java Objects October 1999
+
+
+ ( 1.3.6.1.4.1.42.2.27.4.1.13
+ NAME 'javaClassNames'
+ DESC 'Fully qualified Java class or interface name'
+ EQUALITY caseExactMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ )
+
+ -- from RFC-2256 --
+
+ ( 2.5.4.13
+ NAME 'description'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{1024}
+ )
+
+ -- Object classes --
+
+ ( 1.3.6.1.4.1.42.2.27.4.2.1
+ NAME 'javaContainer'
+ DESC 'Container for a Java object'
+ SUP top
+ STRUCTURAL
+ MUST ( cn )
+ )
+
+ ( 1.3.6.1.4.1.42.2.27.4.2.4
+ NAME 'javaObject'
+ DESC 'Java object representation'
+ SUP top
+ ABSTRACT
+ MUST ( javaClassName )
+ MAY ( javaClassNames $ javaCodebase $ javaDoc $ description )
+ )
+
+ ( 1.3.6.1.4.1.42.2.27.4.2.5
+ NAME 'javaSerializedObject'
+ DESC 'Java serialized object'
+ SUP javaObject
+ AUXILIARY
+ MUST ( javaSerializedData )
+ )
+
+
+
+
+
+
+
+
+
+Ryan, et al. Informational [Page 19]
+
+RFC 2713 Schema for Java Objects October 1999
+
+
+ ( 1.3.6.1.4.1.42.2.27.4.2.7
+ NAME 'javaNamingReference'
+ DESC 'JNDI reference'
+ SUP javaObject
+ AUXILIARY
+ MAY ( javaReferenceAddress $ javaFactory )
+ )
+
+ ( 1.3.6.1.4.1.42.2.27.4.2.8
+ NAME 'javaMarshalledObject'
+ DESC 'Java marshalled object'
+ SUP javaObject
+ AUXILIARY
+ MUST ( javaSerializedData )
+ )
+
+ -- Matching rule from ISO X.520 --
+
+ ( 2.5.13.5
+ NAME 'caseExactMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ )
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ryan, et al. Informational [Page 20]
+
+RFC 2713 Schema for Java Objects October 1999
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (1999). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ryan, et al. Informational [Page 21]
+
Added: openldap/vendor/openldap-release/doc/rfc/rfc2714.txt
===================================================================
--- openldap/vendor/openldap-release/doc/rfc/rfc2714.txt (rev 0)
+++ openldap/vendor/openldap-release/doc/rfc/rfc2714.txt 2007-09-15 10:38:52 UTC (rev 844)
@@ -0,0 +1,563 @@
+
+
+
+
+
+
+Network Working Group V. Ryan
+Request for Comments: 2714 R. Lee
+Category: Informational S. Seligman
+ Sun Microsystems, Inc.
+ October 1999
+
+
+ Schema for Representing CORBA Object References in an LDAP Directory
+
+Status of this Memo
+
+ This memo provides information for the Internet community. It does
+ not specify an Internet standard of any kind. Distribution of this
+ memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (1999). All Rights Reserved.
+
+Abstract
+
+ CORBA [CORBA] is the Common Object Request Broker Architecture
+ defined by the Object Management Group. This document defines the
+ schema for representing CORBA object references in an LDAP directory
+ [LDAPv3].
+
+1. Introduction
+
+ This document assumes that the reader has a general understanding of
+ CORBA.
+
+ Traditionally, LDAP directories have been used to store data. Users
+ and programmers think of the directory as a hierarchy of directory
+ entries, each containing a set of attributes. You look up an entry
+ from the directory and extract the attribute(s) of interest. For
+ example, you can look up a person's telephone number from the
+ directory. Alternatively, you can search the directory for entries
+ with a particular set of attributes. For example, you can search for
+ all persons in the directory with the surname "Smith".
+
+ CORBA applications require access to CORBA objects. Traditionally,
+ CORBA applications have used the COS Naming service for storage and
+ retrieval of CORBA object references. When deployed in environments
+ with a directory, CORBA applications should be able to use the
+ directory as a repository for CORBA object references. The directory
+ provides a centrally administered, and possibly replicated, service
+ for use by CORBA applications distributed across the network.
+
+
+
+
+Ryan, et al. Informational [Page 1]
+
+RFC 2714 Schema for CORBA Object References October 1999
+
+
+ For example, an application server may use the directory for
+ "registering" CORBA objects representing the services that it
+ manages, so that a client can later search the directory to locate
+ those services as it needs.
+
+ The motivation for this document is to define a common way for
+ applications to store and retrieve CORBA object references from the
+ directory. Using this common schema, any CORBA application that
+ needs to read or store CORBA object references in the directory can
+ do so in an interoperable way.
+
+ Note that this schema is defined for storing CORBA "object
+ references," not CORBA objects in general. There might be other ways
+ to store CORBA objects in an LDAP directory but they are not covered
+ by this schema.
+
+2. Representation of CORBA Object References
+
+ This document defines schema elements to represent a CORBA object
+ reference in LDAP directory. Applications in possession of a
+ reference to an object can invoke calls on that object. Such a
+ reference is termed an "interoperable object reference," or IOR.
+ Access to CORBA objects by using IORs is achieved transparently to
+ the application, by means of the General Inter-ORB Protocol.
+
+ A CORBA object reference is represented in the directory by the
+ object class corbaObjectReference. corbaObjectReference is a subclass
+ of the abstract corbaObject object class. corbaObjectReference is an
+ auxiliary object class, which means that it needs to be mixed in with
+ a structural object class.
+
+ The object class corbaContainer is used in a directory entry which
+ represents a CORBA object or object reference. It is a structural
+ object class, and when representing an object reference, the
+ corbaObjectReference object class would also need to be present in
+ the entry. corbaContainer is not required when a subclass of
+ corbaObject (such as corbaObjectReference) is mixed in with another
+ structural object class.
+
+ The definitions for the object classes corbaObject,
+ corbaObjectReference, and corbaContainer are presented in Section 4.
+
+ The corbaObject class has two optional attributes: corbaRepositoryId
+ and description. corbaRepositoryId is a multivalued attribute that
+ is used to store the repository ids of the interfaces implemented by
+ a CORBA object. description is used to store a textual description
+ of a CORBA object.
+
+
+
+
+Ryan, et al. Informational [Page 2]
+
+RFC 2714 Schema for CORBA Object References October 1999
+
+
+ The corbaObjectReference class has one mandatory attribute: corbaIor.
+ corbaIor is used to store the object's stringified IOR.
+
+ corbaIor and corbaRepositoryId are defined in Section 3; description
+ is defined in [v3Schema].
+
+3. Attribute Type Definitions
+
+ The following attribute types are defined in this document:
+
+ corbaIor
+ corbaRepositoryId
+
+3.1 corbaIor
+
+ This attribute stores the string representation of the interoperable
+ object reference (IOR) for a CORBA object. An IOR is an opaque handle
+ for the object which contains the information necessary to locate the
+ object, even if the object is in another ORB.
+
+ This attribute's syntax is 'IA5 String' and its case is
+ insignificant.
+
+ ( 1.3.6.1.4.1.42.2.27.4.1.14
+ NAME 'corbaIor'
+ DESC 'Stringified interoperable object reference of a CORBA object'
+ EQUALITY caseIgnoreIA5Match
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
+ SINGLE-VALUE
+ )
+
+3.2 corbaRepositoryId
+
+ Each CORBA interface has a unique "repository id" (also called "type
+ id") that identifies the interface. A CORBA object has one or more
+ repository ids, one for each interface that it implements.
+
+ The format of a repository id can be any string, but the OMG
+ specifies four standard formats:
+
+ a. IDL-style
+
+ IDL:Prefix/ModuleName/InterfaceName:VersionNumber
+
+
+
+
+
+
+
+
+Ryan, et al. Informational [Page 3]
+
+RFC 2714 Schema for CORBA Object References October 1999
+
+
+ For example, the repository id for the "NamingContext" in OMG's COS
+ Naming module is: "IDL:omg.org/CosNaming/NamingContext:1.0".
+
+ b. RMI-style
+
+ RMI:ClassName:HashCode[:SUID]
+
+ This format is used by RMI-IIOP remote objects [RMI-IIOP].
+ "ClassName" is the fully qualified name of the class (for example,
+ "java.lang.String"). "HashCode" is the object's hash code (that is,
+ that obtained by invoking the "hashCode()" method). "SUID" is the
+ "stream unique identifier", which is a 64-bit number that uniquely
+ identifies the serialization version of the class; SUID is optional
+ in the repository id.
+
+ c. DCE-style
+
+ DCE:UUID
+
+ This format is used for DCE/CORBA interoperability [CORBA-DCE].
+ "UUID" represents a DCE UUID.
+
+ d. "local"
+
+ This format is defined by the local Object Request Broker (ORB).
+
+ The corbaRepositoryId attribute is a multivalued attribute; each
+ value records a single repository id of an interface implemented by
+ the CORBA object. This attribute need not contain a complete list of
+ the interfaces implemented by the CORBA object.
+
+ This attribute's syntax is 'Directory String' and its case is
+ significant. The values of this attribute are encoded using UTF-8.
+ Some values may require translation from their native representation
+ in order to be correctly encoded using UTF-8.
+
+ ( 1.3.6.1.4.1.42.2.27.4.1.15
+ NAME 'corbaRepositoryId'
+ DESC 'Repository ids of interfaces implemented by a CORBA object'
+ EQUALITY caseExactMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ )
+
+
+
+
+
+
+
+
+
+Ryan, et al. Informational [Page 4]
+
+RFC 2714 Schema for CORBA Object References October 1999
+
+
+4. Object Class Definitions
+
+ The following object classes are defined in this document:
+
+ corbaContainer
+ corbaObject
+ corbaObjectReference
+
+4.1 corbaContainer
+
+ This structural object class represents a container for a CORBA
+ object.
+
+ ( 1.3.6.1.4.1.42.2.27.4.2.10
+ NAME 'corbaContainer'
+ DESC 'Container for a CORBA object'
+ SUP top
+ STRUCTURAL
+ MUST ( cn )
+ )
+
+4.2 corbaObject
+
+ This abstract object class is the root class for representing a CORBA
+ object.
+
+ ( 1.3.6.1.4.1.42.2.27.4.2.9
+ NAME 'corbaObject'
+ DESC 'CORBA object representation'
+ SUP top
+ ABSTRACT
+ MAY ( corbaRepositoryId $ description )
+ )
+
+4.3 corbaObjectReference
+
+ This auxiliary object class represents a CORBA object reference. It
+ must be mixed in with a structural object class.
+
+ ( 1.3.6.1.4.1.42.2.27.4.2.11
+ NAME 'corbaObjectReference'
+ DESC 'CORBA interoperable object reference'
+ SUP corbaObject
+ AUXILIARY
+ MUST ( corbaIor )
+ )
+
+
+
+
+
+Ryan, et al. Informational [Page 5]
+
+RFC 2714 Schema for CORBA Object References October 1999
+
+
+5. Security Considerations
+
+ Obtaining a reference to an object and storing it in the directory
+ may make a handle to the object available to a wider audience. This
+ may have security implications.
+
+6. Acknowledgements
+
+ We would like to thank Sanjeev Krishnan of Sun Microsystems, Simon
+ Nash of IBM, and Jeffrey Spirn of Oracle for their comments and
+ suggestions.
+
+7. References
+
+ [CORBA] The Object Management Group, "Common Object Request
+ Broker Architecture Specification 2.2",
+ http://www.omg.org
+
+ [CORBA-DCE] Distributed Systems Technology Center and Digital
+ Equipment Corporation, "DCE/CORBA Interworking
+ Specification", May 1998.
+ http://www.omg.org/library/schedule/
+ DCE_CORBA_Interworking_RFP.html
+
+ [LDAPv3] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory
+ Access Protocol (v3)", RFC 2251, December 1997.
+
+ [RMI-IIOP] IBM and Java Software, Sun Microsystems, Inc., "RMI over
+ IIOP", June 1999. http://java.sun.com/products/rmi-
+ iiop/index.html
+
+ [v3Schema] Wahl, M., "A Summary of the X.500(96) User Schema for use
+ with LDAPv3", RFC 2256, December 1997.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ryan, et al. Informational [Page 6]
+
+RFC 2714 Schema for CORBA Object References October 1999
+
+
+8. Authors' Addresses
+
+ Vincent Ryan
+ Sun Microsystems, Inc.
+ Mail Stop EDUB03
+ 901 San Antonio Road
+ Palo Alto, CA 94303
+ USA
+
+ Phone: +353 1 819 9151
+ EMail: vincent.ryan at ireland.sun.com
+
+
+ Rosanna Lee
+ Sun Microsystems, Inc.
+ Mail Stop UCUP02-206
+ 901 San Antonio Road
+ Palo Alto, CA 94303
+ USA
+
+ Phone: +1 408 863 3221
+ EMail: rosanna.lee at eng.sun.com
+
+
+ Scott Seligman
+ Sun Microsystems, Inc.
+ Mail Stop UCUP02-209
+ 901 San Antonio Road
+ Palo Alto, CA 94303
+ USA
+
+ Phone: +1 408 863 3222
+ EMail: scott.seligman at eng.sun.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ryan, et al. Informational [Page 7]
+
+RFC 2714 Schema for CORBA Object References October 1999
+
+
+9. Appendix - LDAP Schema
+
+ -- Attribute types --
+
+ ( 1.3.6.1.4.1.42.2.27.4.1.14
+ NAME 'corbaIor'
+ DESC 'Stringified interoperable object reference of a CORBA object'
+ EQUALITY caseIgnoreIA5Match
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
+ SINGLE-VALUE
+ )
+
+ ( 1.3.6.1.4.1.42.2.27.4.1.15
+ NAME 'corbaRepositoryId'
+ DESC 'Repository ids of interfaces implemented by a CORBA object'
+ EQUALITY caseExactMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ )
+
+ -- from RFC-2256 --
+
+ ( 2.5.4.13
+ NAME 'description'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{1024}
+ )
+
+ -- Object classes --
+
+ ( 1.3.6.1.4.1.42.2.27.4.2.9
+ NAME 'corbaObject'
+ DESC 'CORBA object representation'
+ SUP top
+ ABSTRACT
+ MAY ( corbaRepositoryId $ description )
+ )
+
+ ( 1.3.6.1.4.1.42.2.27.4.2.10
+ NAME 'corbaContainer'
+ DESC 'Container for a CORBA object'
+ SUP top
+ STRUCTURAL
+ MUST ( cn )
+ )
+
+
+
+
+
+
+Ryan, et al. Informational [Page 8]
+
+RFC 2714 Schema for CORBA Object References October 1999
+
+
+ ( 1.3.6.1.4.1.42.2.27.4.2.11
+ NAME 'corbaObjectReference'
+ DESC 'CORBA interoperable object reference'
+ SUP corbaObject
+ AUXILIARY
+ MUST ( corbaIor )
+ )
+
+ -- Matching rule from ISO X.520 --
+
+ ( 2.5.13.5
+ NAME 'caseExactMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ )
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ryan, et al. Informational [Page 9]
+
+RFC 2714 Schema for CORBA Object References October 1999
+
+
+10. Full Copyright Statement
+
+ Copyright (C) The Internet Society (1999). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ryan, et al. Informational [Page 10]
+
Added: openldap/vendor/openldap-release/doc/rfc/rfc2798.txt
===================================================================
--- openldap/vendor/openldap-release/doc/rfc/rfc2798.txt (rev 0)
+++ openldap/vendor/openldap-release/doc/rfc/rfc2798.txt 2007-09-15 10:38:52 UTC (rev 844)
@@ -0,0 +1,1123 @@
+
+
+
+
+
+
+Network Working Group M. Smith
+Request for Comments: 2798 Netscape Communications
+Category: Informational April 2000
+
+
+ Definition of the inetOrgPerson LDAP Object Class
+
+Status of this Memo
+
+ This memo provides information for the Internet community. It does
+ not specify an Internet standard of any kind. Distribution of this
+ memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2000). All Rights Reserved.
+
+Abstract
+
+ While the X.500 standards define many useful attribute types [X520]
+ and object classes [X521], they do not define a person object class
+ that meets the requirements found in today's Internet and Intranet
+ directory service deployments. We define a new object class called
+ inetOrgPerson for use in LDAP and X.500 directory services that
+ extends the X.521 standard organizationalPerson class to meet these
+ needs.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Smith Informational [Page 1]
+
+RFC 2798 The LDAP inetOrgPerson Object Class April 2000
+
+
+Table of Contents
+
+ 1. Background and Intended Usage...............................2
+ 2. New Attribute Types Used in the inetOrgPerson Object Class..3
+ 2.1. Vehicle license or registration plate....................3
+ 2.2. Department number........................................3
+ 2.3. Display Name.............................................4
+ 2.4. Employee Number..........................................4
+ 2.5. Employee Type............................................4
+ 2.6. JPEG Photograph..........................................5
+ 2.7. Preferred Language.......................................5
+ 2.8. User S/MIME Certificate..................................5
+ 2.9. User PKCS #12............................................6
+ 3. Definition of the inetOrgPerson Object Class................6
+ 4. Example of an inetOrgPerson Entry...........................7
+ 5. Security Considerations.....................................8
+ 6. Acknowledgments.............................................8
+ 7. Bibliography................................................8
+ 8. Author's Address............................................9
+ 9. Appendix A - inetOrgPerson Schema Summary..................10
+ 9.1. Attribute Types..........................................10
+ 9.1.1. New attribute types that are defined in this document.10
+ 9.1.2. Attribute types from RFC 2256.........................12
+ 9.1.3. Attribute types from RFC 1274.........................15
+ 9.1.4. Attribute type from RFC 2079..........................16
+ 9.2. Syntaxes.................................................17
+ 9.2.1. Syntaxes from RFC 2252................................17
+ 9.2.2. Syntaxes from RFC 2256................................17
+ 9.3. Matching Rules...........................................17
+ 9.3.1. Matching rules from RFC 2252..........................17
+ 9.3.2. Matching rule from RFC 2256...........................18
+ 9.3.3. Additional matching rules from X.520..................18
+ 9.3.4. Matching rules not defined in any referenced document.19
+ 10. Full Copyright Statement...................................20
+
+1. Background and Intended Usage
+
+ The inetOrgPerson object class is a general purpose object class that
+ holds attributes about people. The attributes it holds were chosen
+ to accommodate information requirements found in typical Internet and
+ Intranet directory service deployments. The inetOrgPerson object
+ class is designed to be used within directory services based on the
+ LDAP [RFC2251] and the X.500 family of protocols, and it should be
+ useful in other contexts as well. There is no requirement for
+ directory services implementors to use the inetOrgPerson object
+ class; it is simply presented as well-documented class that
+ implementors can choose to use if they find it useful.
+
+
+
+
+Smith Informational [Page 2]
+
+RFC 2798 The LDAP inetOrgPerson Object Class April 2000
+
+
+ The attribute type and object class definitions in this document are
+ written using the BNF form of AttributeTypeDescription and
+ ObjectClassDescription given in [RFC2252]. In some cases lines have
+ been folded for readability.
+
+ Attributes that are referenced but not defined in this document are
+ included in one of the following documents:
+
+ The COSINE and Internet X.500 Schema [RFC1274]
+
+ Definition of an X.500 Attribute Type and an Object Class to Hold
+ Uniform Resource Identifiers (URIs) [RFC2079]
+
+ A Summary of the X.500(96) User Schema for use with LDAPv3
+ [RFC2256]
+
+ See Appendix A for a summary of the attribute types, associated
+ syntaxes, and matching rules used in this document.
+
+2. New Attribute Types Used in the inetOrgPerson Object Class
+
+2.1. Vehicle license or registration plate.
+
+ This multivalued field is used to record the values of the license or
+ registration plate associated with an individual.
+
+ ( 2.16.840.1.113730.3.1.1 NAME 'carLicense'
+ DESC 'vehicle license or registration plate'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+2.2. Department number
+
+ Code for department to which a person belongs. This can also be
+ strictly numeric (e.g., 1234) or alphanumeric (e.g., ABC/123).
+
+ ( 2.16.840.1.113730.3.1.2
+ NAME 'departmentNumber'
+ DESC 'identifies a department within an organization'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+
+
+
+
+
+
+
+Smith Informational [Page 3]
+
+RFC 2798 The LDAP inetOrgPerson Object Class April 2000
+
+
+2.3. Display Name
+
+ When displaying an entry, especially within a one-line summary list,
+ it is useful to be able to identify a name to be used. Since other
+ attribute types such as 'cn' are multivalued, an additional attribute
+ type is needed. Display name is defined for this purpose.
+
+ ( 2.16.840.1.113730.3.1.241
+ NAME 'displayName'
+ DESC 'preferred name of a person to be used when displaying entries'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ SINGLE-VALUE )
+
+2.4. Employee Number
+
+ Numeric or alphanumeric identifier assigned to a person, typically
+ based on order of hire or association with an organization. Single
+ valued.
+
+ ( 2.16.840.1.113730.3.1.3
+ NAME 'employeeNumber'
+ DESC 'numerically identifies an employee within an organization'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ SINGLE-VALUE )
+
+2.5. Employee Type
+
+ Used to identify the employer to employee relationship. Typical
+ values used will be "Contractor", "Employee", "Intern", "Temp",
+ "External", and "Unknown" but any value may be used.
+
+ ( 2.16.840.1.113730.3.1.4
+ NAME 'employeeType'
+ DESC 'type of employment for a person'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+
+
+
+
+
+
+
+
+
+Smith Informational [Page 4]
+
+RFC 2798 The LDAP inetOrgPerson Object Class April 2000
+
+
+2.6. JPEG Photograph
+
+ Used to store one or more images of a person using the JPEG File
+ Interchange Format [JFIF].
+
+ ( 0.9.2342.19200300.100.1.60
+ NAME 'jpegPhoto'
+ DESC 'a JPEG image'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.28 )
+
+ Note that the jpegPhoto attribute type was defined for use in the
+ Internet X.500 pilots but no referencable definition for it could be
+ located.
+
+2.7. Preferred Language
+
+ Used to indicate an individual's preferred written or spoken
+ language. This is useful for international correspondence or human-
+ computer interaction. Values for this attribute type MUST conform to
+ the definition of the Accept-Language header field defined in
+ [RFC2068] with one exception: the sequence "Accept-Language" ":"
+ should be omitted. This is a single valued attribute type.
+
+ ( 2.16.840.1.113730.3.1.39
+ NAME 'preferredLanguage'
+ DESC 'preferred written or spoken language for a person'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ SINGLE-VALUE )
+ )
+
+2.8. User S/MIME Certificate
+
+ A PKCS#7 [RFC2315] SignedData, where the content that is signed is
+ ignored by consumers of userSMIMECertificate values. It is
+ recommended that values have a `contentType' of data with an absent
+ `content' field. Values of this attribute contain a person's entire
+ certificate chain and an smimeCapabilities field [RFC2633] that at a
+ minimum describes their SMIME algorithm capabilities. Values for
+ this attribute are to be stored and requested in binary form, as
+ 'userSMIMECertificate;binary'. If available, this attribute is
+ preferred over the userCertificate attribute for S/MIME applications.
+
+ ( 2.16.840.1.113730.3.1.40
+ NAME 'userSMIMECertificate'
+ DESC 'PKCS#7 SignedData used to support S/MIME'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.5 )
+
+
+
+Smith Informational [Page 5]
+
+RFC 2798 The LDAP inetOrgPerson Object Class April 2000
+
+
+2.9. User PKCS #12
+
+ PKCS #12 [PKCS12] provides a format for exchange of personal identity
+ information. When such information is stored in a directory service,
+ the userPKCS12 attribute should be used. This attribute is to be
+ stored and requested in binary form, as 'userPKCS12;binary'. The
+ attribute values are PFX PDUs stored as binary data.
+
+( 2.16.840.1.113730.3.1.216
+ NAME 'userPKCS12'
+ DESC 'PKCS #12 PFX PDU for exchange of personal identity information'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.5 )
+
+3. Definition of the inetOrgPerson Object Class
+
+ The inetOrgPerson represents people who are associated with an
+ organization in some way. It is a structural class and is derived
+ from the organizationalPerson class which is defined in X.521 [X521].
+
+( 2.16.840.1.113730.3.2.2
+ NAME 'inetOrgPerson'
+ SUP organizationalPerson
+ STRUCTURAL
+ MAY (
+ audio $ businessCategory $ carLicense $ departmentNumber $
+ displayName $ employeeNumber $ employeeType $ givenName $
+ homePhone $ homePostalAddress $ initials $ jpegPhoto $
+ labeledURI $ mail $ manager $ mobile $ o $ pager $
+ photo $ roomNumber $ secretary $ uid $ userCertificate $
+ x500uniqueIdentifier $ preferredLanguage $
+ userSMIMECertificate $ userPKCS12
+ )
+)
+
+ For reference, we list the following additional attribute types that
+ are part of the inetOrgPerson object class. These attribute types
+ are inherited from organizationalPerson (which in turn is derived
+ from the person object class):
+
+
+
+
+
+
+
+
+
+
+
+
+
+Smith Informational [Page 6]
+
+RFC 2798 The LDAP inetOrgPerson Object Class April 2000
+
+
+ MUST (
+ cn $ objectClass $ sn
+ )
+ MAY (
+ description $ destinationIndicator $ facsimileTelephoneNumber $
+ internationaliSDNNumber $ l $ ou $ physicalDeliveryOfficeName $
+ postalAddress $ postalCode $ postOfficeBox $
+ preferredDeliveryMethod $ registeredAddress $ seeAlso $
+ st $ street $ telephoneNumber $ teletexTerminalIdentifier $
+ telexNumber $ title $ userPassword $ x121Address
+ )
+
+4. Example of an inetOrgPerson Entry
+
+ The following example is expressed using the LDIF notation defined in
+ [LDIF].
+
+ version: 1
+ dn: cn=Barbara Jensen,ou=Product Development,dc=siroe,dc=com
+ objectClass: top
+ objectClass: person
+ objectClass: organizationalPerson
+ objectClass: inetOrgPerson
+ cn: Barbara Jensen
+ cn: Babs Jensen
+ displayName: Babs Jensen
+ sn: Jensen
+ givenName: Barbara
+ initials: BJJ
+ title: manager, product development
+ uid: bjensen
+ mail: bjensen at siroe.com
+ telephoneNumber: +1 408 555 1862
+ facsimileTelephoneNumber: +1 408 555 1992
+ mobile: +1 408 555 1941
+ roomNumber: 0209
+ carLicense: 6ABC246
+ o: Siroe
+ ou: Product Development
+ departmentNumber: 2604
+ employeeNumber: 42
+ employeeType: full time
+ preferredLanguage: fr, en-gb;q=0.8, en;q=0.7
+ labeledURI: http://www.siroe.com/users/bjensen My Home Page
+
+
+
+
+
+
+
+Smith Informational [Page 7]
+
+RFC 2798 The LDAP inetOrgPerson Object Class April 2000
+
+
+5. Security Considerations
+
+ Attributes of directory entries are used to provide descriptive
+ information about the real-world objects they represent, which can be
+ people, organizations or devices. Most countries have privacy laws
+ regarding the publication of information about people.
+
+ Transfer of cleartext passwords are strongly discouraged where the
+ underlying transport service cannot guarantee confidentiality and may
+ result in disclosure of the password to unauthorized parties.
+
+6. Acknowledgments
+
+ The Netscape Directory Server team created the inetOrgPerson object
+ class based on experience and customer requirements. Anil Bhavnani
+ and John Kristian in particular deserve credit for all of the early
+ design work.
+
+ Many members of the Internet community, in particular those in the
+ IETF ASID and LDAPEXT groups, also contributed to the design of this
+ object class.
+
+7. Bibliography
+
+ [JFIF] E. Hamilton, "JPEG File Interchange Format (Version 1.02)",
+ C-Cube Microsystems, Milpitas, CA, September 1, 1992.
+
+ [LDIF] G. Good, "The LDAP Data Interchange Format (LDIF) -
+ Technical Specification", Work in Progress.
+
+ [PKCS12] "PKCS #12: Personal Information Exchange Standard", Version
+ 1.0 Draft, 30 April 1997.
+
+ [RFC1274] Barker, P. and S. Kille, "The COSINE and Internet X.500
+ Schema", RFC 1274, November 1991.
+
+ [RFC1847] Galvin, J., Murphy, S., Crocker, S. and N. Freed, "Security
+ Multiparts for MIME: Multipart/Signed and
+ Multipart/Encrypted", RFC 1847, October 1995.
+
+ [RFC2068] Fielding, R., Gettys, J., Mogul, J., Frystyk, H. and T.
+ Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC
+ 2068, January 1997.
+
+ [RFC2079] Smith, M., "Definition of an X.500 Attribute Type and an
+ Object Class to Hold Uniform Resource Identifiers (URIs)",
+ RFC 2079, January 1997.
+
+
+
+
+Smith Informational [Page 8]
+
+RFC 2798 The LDAP inetOrgPerson Object Class April 2000
+
+
+ [RFC2251] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory
+ Access Protocol (v3)", RFC 2251, December 1997.
+
+ [RFC2252] Wahl, M., Coulbeck, A., Howes, T., Kille, S., Yeong, W. and
+ C. Robbins, "Lightweight Directory Access Protocol (v3):
+ Attribute Syntax Definitions", RFC 2252, December 1997.
+
+ [RFC2256] Wahl, M., "A Summary of the X.500(96) User Schema for use
+ with LDAPv3", RFC 2256, December 1997.
+
+ [RFC2315] Kaliski, B., "PKCS #7: Cryptographic Message Syntax Version
+ 1.5", RFC 2315, March 1998.
+
+ [RFC2633] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC
+ 2633, June 1999.
+
+ [X520] ITU-T Rec. X.520, "The Directory: Selected Attribute
+ Types", 1996.
+
+ [X521] ITU-T Rec. X.521, "The Directory: Selected Object Classes",
+ 1996.
+
+8. Author's Address
+
+ Mark Smith
+ Netscape Communications Corp.
+ 501 E. Middlefield Rd., Mailstop MV068
+ Mountain View, CA 94043, USA
+
+ Phone: +1 650 937-3477
+ EMail: mcs at netscape.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Smith Informational [Page 9]
+
+RFC 2798 The LDAP inetOrgPerson Object Class April 2000
+
+
+9. Appendix A - inetOrgPerson Schema Summary
+
+ This appendix provides definitions of all the attribute types
+ included in the inetOrgPerson object class along with their
+ associated syntaxes and matching rules.
+
+9.1. Attribute Types
+
+9.1.1. New attribute types that are defined in this document
+
+ ( 2.16.840.1.113730.3.1.1 NAME 'carLicense'
+ DESC 'vehicle license or registration plate'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+ ( 2.16.840.1.113730.3.1.2
+ NAME 'departmentNumber'
+ DESC 'identifies a department within an organization'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+ ( 2.16.840.1.113730.3.1.241
+ NAME 'displayName'
+ DESC 'preferred name of a person to be used when displaying entries'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ SINGLE-VALUE )
+
+ ( 2.16.840.1.113730.3.1.3
+ NAME 'employeeNumber'
+ DESC 'numerically identifies an employee within an organization'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ SINGLE-VALUE )
+
+ ( 2.16.840.1.113730.3.1.4
+ NAME 'employeeType'
+ DESC 'type of employment for a person'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+
+
+
+
+
+Smith Informational [Page 10]
+
+RFC 2798 The LDAP inetOrgPerson Object Class April 2000
+
+
+ ( 0.9.2342.19200300.100.1.60
+ NAME 'jpegPhoto'
+ DESC 'a JPEG image'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.28 )
+ Note: The jpegPhoto attribute type was defined for use in the
+ Internet X.500 pilots but no referencable definition for it
+ could be located.
+
+ ( 2.16.840.1.113730.3.1.39
+ NAME 'preferredLanguage'
+ DESC 'preferred written or spoken language for a person'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ SINGLE-VALUE )
+
+ ( 2.16.840.1.113730.3.1.40
+ NAME 'userSMIMECertificate'
+ DESC 'signed message used to support S/MIME'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.5 )
+
+ ( 2.16.840.1.113730.3.1.216
+ NAME 'userPKCS12'
+ DESC 'PKCS #12 PFX PDU for exchange of personal identity information'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.5 )
+
+9.1.2. Attribute types from RFC 2256
+
+ Note that the original definitions of these types can be found in
+ X.520.
+
+ ( 2.5.4.15
+ NAME 'businessCategory'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{128} )
+
+ ( 2.5.4.3
+ NAME 'cn'
+ SUP name )
+
+ ( 2.5.4.13
+ NAME 'description'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{1024} )
+
+
+
+
+
+Smith Informational [Page 11]
+
+RFC 2798 The LDAP inetOrgPerson Object Class April 2000
+
+
+ ( 2.5.4.27
+ NAME 'destinationIndicator'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.44{128} )
+
+ ( 2.5.4.23
+ NAME 'facsimileTelephoneNumber'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.22 )
+
+ ( 2.5.4.42
+ NAME 'givenName'
+ SUP name )
+
+ ( 2.5.4.43
+ NAME 'initials'
+ SUP name )
+
+ ( 2.5.4.25
+ NAME 'internationaliSDNNumber'
+ EQUALITY numericStringMatch
+ SUBSTR numericStringSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.36{16} )
+
+ ( 2.5.4.7
+ NAME 'l'
+ SUP name )
+
+ ( 2.5.4.0
+ NAME 'objectClass'
+ EQUALITY objectIdentifierMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
+
+ ( 2.5.4.10
+ NAME 'o'
+ SUP name )
+
+ ( 2.5.4.11
+ NAME 'ou'
+ SUP name )
+
+ ( 2.5.4.19
+ NAME 'physicalDeliveryOfficeName'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{128} )
+
+
+
+
+
+Smith Informational [Page 12]
+
+RFC 2798 The LDAP inetOrgPerson Object Class April 2000
+
+
+ ( 2.5.4.18
+ NAME 'postOfficeBox'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{40} )
+
+ ( 2.5.4.16
+ NAME 'postalAddress'
+ EQUALITY caseIgnoreListMatch
+ SUBSTR caseIgnoreListSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 )
+
+ ( 2.5.4.17
+ NAME 'postalCode'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{40} )
+
+ ( 2.5.4.28
+ NAME 'preferredDeliveryMethod'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.14
+ SINGLE-VALUE )
+
+ ( 2.5.4.26
+ NAME 'registeredAddress'
+ SUP postalAddress
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 )
+
+ ( 2.5.4.34
+ NAME 'seeAlso'
+ SUP distinguishedName )
+
+ ( 2.5.4.4
+ NAME 'sn'
+ SUP name )
+
+ ( 2.5.4.8
+ NAME 'st'
+ SUP name )
+
+ ( 2.5.4.9
+ NAME 'street'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{128} )
+
+
+
+
+
+
+Smith Informational [Page 13]
+
+RFC 2798 The LDAP inetOrgPerson Object Class April 2000
+
+
+ ( 2.5.4.20
+ NAME 'telephoneNumber'
+ EQUALITY telephoneNumberMatch
+ SUBSTR telephoneNumberSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.50{32} )
+
+ ( 2.5.4.22
+ NAME 'teletexTerminalIdentifier'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.51 )
+
+ ( 2.5.4.21
+ NAME 'telexNumber'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.52 )
+
+ ( 2.5.4.12
+ NAME 'title'
+ SUP name )
+
+ ( 2.5.4.36
+ NAME 'userCertificate'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.8 )
+
+ ( 2.5.4.35
+ NAME 'userPassword'
+ EQUALITY octetStringMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.40{128} )
+
+ ( 2.5.4.24
+ NAME 'x121Address'
+ EQUALITY numericStringMatch
+ SUBSTR numericStringSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.36{15} )
+
+ ( 2.5.4.45
+ NAME 'x500UniqueIdentifier'
+ EQUALITY bitStringMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 )
+
+ Some attribute types included in inetOrgPerson are derived from the
+ 'name' and 'distinguishedName' attribute supertypes:
+
+ ( 2.5.4.41
+ NAME 'name'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} )
+
+
+
+
+
+Smith Informational [Page 14]
+
+RFC 2798 The LDAP inetOrgPerson Object Class April 2000
+
+
+ ( 2.5.4.49
+ NAME 'distinguishedName'
+ EQUALITY distinguishedNameMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
+
+9.1.3. Attribute types from RFC 1274
+
+ ( 0.9.2342.19200300.100.1.55
+ NAME 'audio'
+ EQUALITY octetStringMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.40{250000} )
+ Note: The syntax used here for the audio attribute type is Octet
+ String. RFC 1274 uses a syntax called audio which is not defined
+ in RFC 1274.
+
+ ( 0.9.2342.19200300.100.1.20
+ NAME 'homePhone'
+ EQUALITY telephoneNumberMatch
+ SUBSTR telephoneNumberSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 )
+ Note: RFC 1274 uses the longer name 'homeTelephoneNumber'.
+
+ ( 0.9.2342.19200300.100.1.39
+ NAME 'homePostalAddress'
+ EQUALITY caseIgnoreListMatch
+ SUBSTR caseIgnoreListSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 )
+
+ ( 0.9.2342.19200300.100.1.3
+ NAME 'mail'
+ EQUALITY caseIgnoreIA5Match
+ SUBSTR caseIgnoreIA5SubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} )
+ Note: RFC 1274 uses the longer name 'rfc822Mailbox' and syntax OID
+ of 0.9.2342.19200300.100.3.5. All recent LDAP documents and most
+ deployed LDAP implementations refer to this attribute as 'mail'
+ and define the IA5 String syntax using using the OID
+ 1.3.6.1.4.1.1466.115.121.1.26, as is done here.
+
+ ( 0.9.2342.19200300.100.1.10
+ NAME 'manager'
+ EQUALITY distinguishedNameMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
+
+
+
+
+
+
+
+
+Smith Informational [Page 15]
+
+RFC 2798 The LDAP inetOrgPerson Object Class April 2000
+
+
+ ( 0.9.2342.19200300.100.1.41
+ NAME 'mobile'
+ EQUALITY telephoneNumberMatch
+ SUBSTR telephoneNumberSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 )
+ Note: RFC 1274 uses the longer name 'mobileTelephoneNumber'.
+
+ ( 0.9.2342.19200300.100.1.42
+ NAME 'pager'
+ EQUALITY telephoneNumberMatch
+ SUBSTR telephoneNumberSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 )
+ Note: RFC 1274 uses the longer name 'pagerTelephoneNumber'.
+
+ ( 0.9.2342.19200300.100.1.7
+ NAME 'photo' )
+ Note: Photo attribute values are encoded in G3 fax format with an
+ ASN.1 wrapper. Please refer to RFC 1274 section 9.3.7 for
+ detailed syntax information for this attribute.
+
+ ( 0.9.2342.19200300.100.1.6
+ NAME 'roomNumber'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
+
+ ( 0.9.2342.19200300.100.1.21
+ NAME 'secretary'
+ EQUALITY distinguishedNameMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
+
+ ( 0.9.2342.19200300.100.1.1
+ NAME 'uid'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
+ Note: RFC 1274 uses the longer name 'userid'.
+
+9.1.4. Attribute type from RFC 2079
+
+ ( 1.3.6.1.4.1.250.1.57
+ NAME 'labeledURI'
+ EQUALITY caseExactMatch
+ SUBSTR caseExactSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+
+
+
+
+
+Smith Informational [Page 16]
+
+RFC 2798 The LDAP inetOrgPerson Object Class April 2000
+
+
+9.2. Syntaxes
+
+9.2.1. Syntaxes from RFC 2252
+
+ ( 1.3.6.1.4.1.1466.115.121.1.5 DESC 'Binary' )
+
+ ( 1.3.6.1.4.1.1466.115.121.1.6 DESC 'Bit String' )
+
+ ( 1.3.6.1.4.1.1466.115.121.1.8 DESC 'Certificate' )
+
+ ( 1.3.6.1.4.1.1466.115.121.1.12 DESC 'DN' )
+
+ ( 1.3.6.1.4.1.1466.115.121.1.15 DESC 'Directory String' )
+
+ ( 1.3.6.1.4.1.1466.115.121.1.22 DESC 'Facsimile Telephone Number' )
+
+ ( 1.3.6.1.4.1.1466.115.121.1.26 DESC 'IA5 String' )
+
+ ( 1.3.6.1.4.1.1466.115.121.1.28 DESC 'JPEG' )
+
+ ( 1.3.6.1.4.1.1466.115.121.1.36 DESC 'Numeric String' )
+
+ ( 1.3.6.1.4.1.1466.115.121.1.38 DESC 'OID' )
+
+ ( 1.3.6.1.4.1.1466.115.121.1.41 DESC 'Postal Address' )
+
+ ( 1.3.6.1.4.1.1466.115.121.1.44 DESC 'Printable String' )
+
+ ( 1.3.6.1.4.1.1466.115.121.1.50 DESC 'Telephone Number' )
+
+9.2.2. Syntaxes from RFC 2256
+
+ ( 1.3.6.1.4.1.1466.115.121.1.14 DESC 'Delivery Method' )
+
+ ( 1.3.6.1.4.1.1466.115.121.1.40 DESC 'Octet String' )
+
+ ( 1.3.6.1.4.1.1466.115.121.1.51 DESC 'Teletex Terminal Identifier' )
+
+ ( 1.3.6.1.4.1.1466.115.121.1.52 DESC 'Telex Number' )
+
+9.3. Matching Rules
+
+9.3.1. Matching rules from RFC 2252
+
+ Note that the original definition of many of these matching rules can
+ be found in X.520.
+
+
+
+
+
+Smith Informational [Page 17]
+
+RFC 2798 The LDAP inetOrgPerson Object Class April 2000
+
+
+ ( 2.5.13.16 NAME 'bitStringMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 )
+
+ ( 1.3.6.1.4.1.1466.109.114.2 NAME 'caseIgnoreIA5Match'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
+
+ ( 2.5.13.11 NAME 'caseIgnoreListMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 )
+
+ ( 2.5.13.2 NAME 'caseIgnoreMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+ ( 2.5.13.1 NAME 'distinguishedNameMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
+
+ ( 2.5.13.8 NAME 'numericStringMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 )
+
+ ( 2.5.13.0 NAME 'objectIdentifierMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
+
+ ( 2.5.13.20 NAME 'telephoneNumberMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 )
+
+9.3.2. Matching rule from RFC 2256
+
+ Note that the original definition of this matching rule can be found
+ in X.520.
+
+ ( 2.5.13.17 NAME 'octetStringMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )
+
+9.3.3. Additional matching rules from X.520
+
+ caseExactMatch
+
+ ( 2.5.13.5 NAME 'caseExactMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+ This rule determines whether a presented string exactly matches an
+ attribute value of syntax DirectoryString. It is identical to
+ caseIgnoreMatch except that case is not ignored. Multiple adjoining
+ whitespace characters are treated the same as an individual space,
+ and leading and trailing whitespace is ignored.
+
+
+
+
+
+
+
+Smith Informational [Page 18]
+
+RFC 2798 The LDAP inetOrgPerson Object Class April 2000
+
+
+ caseExactSubstringsMatch
+
+ ( 2.5.13.7 NAME 'caseExactSubstringsMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
+
+ This rules determines whether the initial, any and final substring
+ elements in a presented value are present in an attribute value of
+ syntax DirectoryString. It is identical to caseIgnoreSubstringsMatch
+ except that case is not ignored.
+
+ caseIgnoreListSubstringsMatch
+
+ ( 2.5.13.12 NAME 'caseIgnoreListSubstringsMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
+
+ This rule compares a presented substring with an attribute value
+ which is a sequence of DirectoryStrings, but where the case of
+ letters is not significant for comparison purposes. A presented
+ value matches a stored value if and only if the presented value
+ matches the string formed by concatenating the strings of the stored
+ value. Matching is done according to the caseIgnoreSubstringsMatch
+ rule except that none of the initial, final, or any values of the
+ presented value match a substring of the concatenated string which
+ spans more than one of the strings of the stored value.
+
+9.3.4. Matching rules not defined in any referenced document
+
+ caseIgnoreIA5SubstringsMatch
+
+ ( 1.3.6.1.4.1.1466.109.114.3 NAME 'caseIgnoreIA5SubstringsMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
+
+ This rules determines whether the initial, any and final substring
+ elements in a presented value are present in an attribute value of
+ syntax IA5 String without regard to the case of the letters in the
+ strings. It is expected that this matching rule will be added to an
+ update of RFC 2252.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Smith Informational [Page 19]
+
+RFC 2798 The LDAP inetOrgPerson Object Class April 2000
+
+
+10. Full Copyright Statement
+
+ Copyright (C) The Internet Society (2000). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Smith Informational [Page 20]
+
Added: openldap/vendor/openldap-release/doc/rfc/rfc2829.txt
===================================================================
--- openldap/vendor/openldap-release/doc/rfc/rfc2829.txt (rev 0)
+++ openldap/vendor/openldap-release/doc/rfc/rfc2829.txt 2007-09-15 10:38:52 UTC (rev 844)
@@ -0,0 +1,899 @@
+
+
+
+
+
+
+Network Working Group M. Wahl
+Request for Comments: 2829 Sun Microsystems, Inc.
+Category: Standards Track H. Alvestrand
+ EDB Maxware
+ J. Hodges
+ Oblix, Inc.
+ R. Morgan
+ University of Washington
+ May 2000
+
+
+ Authentication Methods for LDAP
+
+Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2000). All Rights Reserved.
+
+Abstract
+
+ This document specifies particular combinations of security
+ mechanisms which are required and recommended in LDAP [1]
+ implementations.
+
+1. Introduction
+
+ LDAP version 3 is a powerful access protocol for directories.
+
+ It offers means of searching, fetching and manipulating directory
+ content, and ways to access a rich set of security functions.
+
+ In order to function for the best of the Internet, it is vital that
+ these security functions be interoperable; therefore there has to be
+ a minimum subset of security functions that is common to all
+ implementations that claim LDAPv3 conformance.
+
+ Basic threats to an LDAP directory service include:
+
+ (1) Unauthorized access to data via data-fetching operations,
+
+
+
+
+
+Wahl, et al. Standards Track [Page 1]
+
+RFC 2829 Authentication Methods for LDAP May 2000
+
+
+ (2) Unauthorized access to reusable client authentication
+ information by monitoring others' access,
+
+ (3) Unauthorized access to data by monitoring others' access,
+
+ (4) Unauthorized modification of data,
+
+ (5) Unauthorized modification of configuration,
+
+ (6) Unauthorized or excessive use of resources (denial of
+ service), and
+
+ (7) Spoofing of directory: Tricking a client into believing that
+ information came from the directory when in fact it did not,
+ either by modifying data in transit or misdirecting the
+ client's connection.
+
+ Threats (1), (4), (5) and (6) are due to hostile clients. Threats
+ (2), (3) and (7) are due to hostile agents on the path between client
+ and server, or posing as a server.
+
+ The LDAP protocol suite can be protected with the following security
+ mechanisms:
+
+ (1) Client authentication by means of the SASL [2] mechanism
+ set, possibly backed by the TLS credentials exchange
+ mechanism,
+
+ (2) Client authorization by means of access control based on the
+ requestor's authenticated identity,
+
+ (3) Data integrity protection by means of the TLS protocol or
+ data-integrity SASL mechanisms,
+
+ (4) Protection against snooping by means of the TLS protocol or
+ data-encrypting SASL mechanisms,
+
+ (5) Resource limitation by means of administrative limits on
+ service controls, and
+
+ (6) Server authentication by means of the TLS protocol or SASL
+ mechanism.
+
+ At the moment, imposition of access controls is done by means outside
+ the scope of the LDAP protocol.
+
+ In this document, the term "user" represents any application which is
+ an LDAP client using the directory to retrieve or store information.
+
+
+
+Wahl, et al. Standards Track [Page 2]
+
+RFC 2829 Authentication Methods for LDAP May 2000
+
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in RFC 2119 [3].
+
+2. Example deployment scenarios
+
+ The following scenarios are typical for LDAP directories on the
+ Internet, and have different security requirements. (In the
+ following, "sensitive" means data that will cause real damage to the
+ owner if revealed; there may be data that is protected but not
+ sensitive). This is not intended to be a comprehensive list, other
+ scenarios are possible, especially on physically protected networks.
+
+ (1) A read-only directory, containing no sensitive data,
+ accessible to "anyone", and TCP connection hijacking or IP
+ spoofing is not a problem. This directory requires no
+ security functions except administrative service limits.
+
+ (2) A read-only directory containing no sensitive data; read
+ access is granted based on identity. TCP connection
+ hijacking is not currently a problem. This scenario requires
+ a secure authentication function.
+
+ (3) A read-only directory containing no sensitive data; and the
+ client needs to ensure that the directory data is
+ authenticated by the server and not modified while being
+ returned from the server.
+
+ (4) A read-write directory, containing no sensitive data; read
+ access is available to "anyone", update access to properly
+ authorized persons. TCP connection hijacking is not
+ currently a problem. This scenario requires a secure
+ authentication function.
+
+ (5) A directory containing sensitive data. This scenario
+ requires session confidentiality protection AND secure
+ authentication.
+
+3. Authentication and Authorization: Definitions and Concepts
+
+ This section defines basic terms, concepts, and interrelationships
+ regarding authentication, authorization, credentials, and identity.
+ These concepts are used in describing how various security approaches
+ are utilized in client authentication and authorization.
+
+
+
+
+
+
+
+Wahl, et al. Standards Track [Page 3]
+
+RFC 2829 Authentication Methods for LDAP May 2000
+
+
+3.1. Access Control Policy
+
+ An access control policy is a set of rules defining the protection of
+ resources, generally in terms of the capabilities of persons or other
+ entities accessing those resources. A common expression of an access
+ control policy is an access control list. Security objects and
+ mechanisms, such as those described here, enable the expression of
+ access control policies and their enforcement. Access control
+ policies are typically expressed in terms of access control
+ attributes as described below.
+
+3.2. Access Control Factors
+
+ A request, when it is being processed by a server, may be associated
+ with a wide variety of security-related factors (section 4.2 of [1]).
+ The server uses these factors to determine whether and how to process
+ the request. These are called access control factors (ACFs). They
+ might include source IP address, encryption strength, the type of
+ operation being requested, time of day, etc. Some factors may be
+ specific to the request itself, others may be associated with the
+ connection via which the request is transmitted, others (e.g. time of
+ day) may be "environmental".
+
+ Access control policies are expressed in terms of access control
+ factors. E.g., a request having ACFs i,j,k can perform operation Y
+ on resource Z. The set of ACFs that a server makes available for such
+ expressions is implementation-specific.
+
+3.3. Authentication, Credentials, Identity
+
+ Authentication credentials are the evidence supplied by one party to
+ another, asserting the identity of the supplying party (e.g. a user)
+ who is attempting to establish an association with the other party
+ (typically a server). Authentication is the process of generating,
+ transmitting, and verifying these credentials and thus the identity
+ they assert. An authentication identity is the name presented in a
+ credential.
+
+ There are many forms of authentication credentials -- the form used
+ depends upon the particular authentication mechanism negotiated by
+ the parties. For example: X.509 certificates, Kerberos tickets,
+ simple identity and password pairs. Note that an authentication
+ mechanism may constrain the form of authentication identities used
+ with it.
+
+
+
+
+
+
+
+Wahl, et al. Standards Track [Page 4]
+
+RFC 2829 Authentication Methods for LDAP May 2000
+
+
+3.4. Authorization Identity
+
+ An authorization identity is one kind of access control factor. It
+ is the name of the user or other entity that requests that operations
+ be performed. Access control policies are often expressed in terms
+ of authorization identities; e.g., entity X can perform operation Y
+ on resource Z.
+
+ The authorization identity bound to an association is often exactly
+ the same as the authentication identity presented by the client, but
+ it may be different. SASL allows clients to specify an authorization
+ identity distinct from the authentication identity asserted by the
+ client's credentials. This permits agents such as proxy servers to
+ authenticate using their own credentials, yet request the access
+ privileges of the identity for which they are proxying [2]. Also,
+ the form of authentication identity supplied by a service like TLS
+ may not correspond to the authorization identities used to express a
+ server's access control policy, requiring a server-specific mapping
+ to be done. The method by which a server composes and validates an
+ authorization identity from the authentication credentials supplied
+ by a client is implementation-specific.
+
+4. Required security mechanisms
+
+ It is clear that allowing any implementation, faced with the above
+ requirements, to pick and choose among the possible alternatives is
+ not a strategy that is likely to lead to interoperability. In the
+ absence of mandates, clients will be written that do not support any
+ security function supported by the server, or worse, support only
+ mechanisms like cleartext passwords that provide clearly inadequate
+ security.
+
+ Active intermediary attacks are the most difficult for an attacker to
+ perform, and for an implementation to protect against. Methods that
+ protect only against hostile client and passive eavesdropping attacks
+ are useful in situations where the cost of protection against active
+ intermediary attacks is not justified based on the perceived risk of
+ active intermediary attacks.
+
+ Given the presence of the Directory, there is a strong desire to see
+ mechanisms where identities take the form of a Distinguished Name and
+ authentication data can be stored in the directory; this means that
+ either this data is useless for faking authentication (like the Unix
+ "/etc/passwd" file format used to be), or its content is never passed
+ across the wire unprotected - that is, it's either updated outside
+ the protocol or it is only updated in sessions well protected against
+ snooping. It is also desirable to allow authentication methods to
+
+
+
+
+Wahl, et al. Standards Track [Page 5]
+
+RFC 2829 Authentication Methods for LDAP May 2000
+
+
+ carry authorization identities based on existing forms of user
+ identities for backwards compatibility with non-LDAP-based
+ authentication services.
+
+ Therefore, the following implementation conformance requirements are
+ in place:
+
+ (1) For a read-only, public directory, anonymous authentication,
+ described in section 5, can be used.
+
+ (2) Implementations providing password-based authenticated
+ access MUST support authentication using the DIGEST-MD5 SASL
+ mechanism [4], as described in section 6.1. This provides
+ client authentication with protection against passive
+ eavesdropping attacks, but does not provide protection
+ against active intermediary attacks.
+
+ (3) For a directory needing session protection and
+ authentication, the Start TLS extended operation [5], and
+ either the simple authentication choice or the SASL EXTERNAL
+ mechanism, are to be used together. Implementations SHOULD
+ support authentication with a password as described in
+ section 6.2, and SHOULD support authentication with a
+ certificate as described in section 7.1. Together, these
+ can provide integrity and disclosure protection of
+ transmitted data, and authentication of client and server,
+ including protection against active intermediary attacks.
+
+ If TLS is negotiated, the client MUST discard all information about
+ the server fetched prior to the TLS negotiation. In particular, the
+ value of supportedSASLMechanisms MAY be different after TLS has been
+ negotiated (specifically, the EXTERNAL mechanism or the proposed
+ PLAIN mechanism are likely to only be listed after a TLS negotiation
+ has been performed).
+
+ If a SASL security layer is negotiated, the client MUST discard all
+ information about the server fetched prior to SASL. In particular,
+ if the client is configured to support multiple SASL mechanisms, it
+ SHOULD fetch supportedSASLMechanisms both before and after the SASL
+ security layer is negotiated and verify that the value has not
+ changed after the SASL security layer was negotiated. This detects
+ active attacks which remove supported SASL mechanisms from the
+ supportedSASLMechanisms list, and allows the client to ensure that it
+ is using the best mechanism supported by both client and server
+ (additionally, this is a SHOULD to allow for environments where the
+ supported SASL mechanisms list is provided to the client through a
+ different trusted source, e.g. as part of a digitally signed object).
+
+
+
+
+Wahl, et al. Standards Track [Page 6]
+
+RFC 2829 Authentication Methods for LDAP May 2000
+
+
+5. Anonymous authentication
+
+ Directory operations which modify entries or access protected
+ attributes or entries generally require client authentication.
+ Clients which do not intend to perform any of these operations
+ typically use anonymous authentication.
+
+ LDAP implementations MUST support anonymous authentication, as
+ defined in section 5.1.
+
+ LDAP implementations MAY support anonymous authentication with TLS,
+ as defined in section 5.2.
+
+ While there MAY be access control restrictions to prevent access to
+ directory entries, an LDAP server SHOULD allow an anonymously-bound
+ client to retrieve the supportedSASLMechanisms attribute of the root
+ DSE.
+
+ An LDAP server MAY use other information about the client provided by
+ the lower layers or external means to grant or deny access even to
+ anonymously authenticated clients.
+
+5.1. Anonymous authentication procedure
+
+ An LDAP client which has not successfully completed a bind operation
+ on a connection is anonymously authenticated.
+
+ An LDAP client MAY also specify anonymous authentication in a bind
+ request by using a zero-length OCTET STRING with the simple
+ authentication choice.
+
+5.2. Anonymous authentication and TLS
+
+ An LDAP client MAY use the Start TLS operation [5] to negotiate the
+ use of TLS security [6]. If the client has not bound beforehand,
+ then until the client uses the EXTERNAL SASL mechanism to negotiate
+ the recognition of the client's certificate, the client is
+ anonymously authenticated.
+
+ Recommendations on TLS ciphersuites are given in section 10.
+
+ An LDAP server which requests that clients provide their certificate
+ during TLS negotiation MAY use a local security policy to determine
+ whether to successfully complete TLS negotiation if the client did
+ not present a certificate which could be validated.
+
+
+
+
+
+
+Wahl, et al. Standards Track [Page 7]
+
+RFC 2829 Authentication Methods for LDAP May 2000
+
+
+6. Password-based authentication
+
+ LDAP implementations MUST support authentication with a password
+ using the DIGEST-MD5 SASL mechanism for password protection, as
+ defined in section 6.1.
+
+ LDAP implementations SHOULD support authentication with the "simple"
+ password choice when the connection is protected against
+ eavesdropping using TLS, as defined in section 6.2.
+
+6.1. Digest authentication
+
+ An LDAP client MAY determine whether the server supports this
+ mechanism by performing a search request on the root DSE, requesting
+ the supportedSASLMechanisms attribute, and checking whether the
+ string "DIGEST-MD5" is present as a value of this attribute.
+
+ In the first stage of authentication, when the client is performing
+ an "initial authentication" as defined in section 2.1 of [4], the
+ client sends a bind request in which the version number is 3, the
+ authentication choice is sasl, the sasl mechanism name is "DIGEST-
+ MD5", and the credentials are absent. The client then waits for a
+ response from the server to this request.
+
+ The server will respond with a bind response in which the resultCode
+ is saslBindInProgress, and the serverSaslCreds field is present. The
+ contents of this field is a string defined by "digest-challenge" in
+ section 2.1.1 of [4]. The server SHOULD include a realm indication
+ and MUST indicate support for UTF-8.
+
+ The client will send a bind request with a distinct message id, in
+ which the version number is 3, the authentication choice is sasl, the
+ sasl mechanism name is "DIGEST-MD5", and the credentials contain the
+ string defined by "digest-response" in section 2.1.2 of [4]. The
+ serv-type is "ldap".
+
+ The server will respond with a bind response in which the resultCode
+ is either success, or an error indication. If the authentication is
+ successful and the server does not support subsequent authentication,
+ then the credentials field is absent. If the authentication is
+ successful and the server supports subsequent authentication, then
+ the credentials field contains the string defined by "response-auth"
+ in section 2.1.3 of [4]. Support for subsequent authentication is
+ OPTIONAL in clients and servers.
+
+
+
+
+
+
+
+Wahl, et al. Standards Track [Page 8]
+
+RFC 2829 Authentication Methods for LDAP May 2000
+
+
+6.2. "simple" authentication choice under TLS encryption
+
+ A user who has a directory entry containing a userPassword attribute
+ MAY authenticate to the directory by performing a simple password
+ bind sequence following the negotiation of a TLS ciphersuite
+ providing connection confidentiality [6].
+
+ The client will use the Start TLS operation [5] to negotiate the use
+ of TLS security [6] on the connection to the LDAP server. The client
+ need not have bound to the directory beforehand.
+
+ For this authentication procedure to be successful, the client and
+ server MUST negotiate a ciphersuite which contains a bulk encryption
+ algorithm of appropriate strength. Recommendations on cipher suites
+ are given in section 10.
+
+ Following the successful completion of TLS negotiation, the client
+ MUST send an LDAP bind request with the version number of 3, the name
+ field containing the name of the user's entry, and the "simple"
+ authentication choice, containing a password.
+
+ The server will, for each value of the userPassword attribute in the
+ named user's entry, compare these for case-sensitive equality with
+ the client's presented password. If there is a match, then the
+ server will respond with resultCode success, otherwise the server
+ will respond with resultCode invalidCredentials.
+
+6.3. Other authentication choices with TLS
+
+ It is also possible, following the negotiation of TLS, to perform a
+ SASL authentication which does not involve the exchange of plaintext
+ reusable passwords. In this case the client and server need not
+ negotiate a ciphersuite which provides confidentiality if the only
+ service required is data integrity.
+
+7. Certificate-based authentication
+
+ LDAP implementations SHOULD support authentication via a client
+ certificate in TLS, as defined in section 7.1.
+
+7.1. Certificate-based authentication with TLS
+
+ A user who has a public/private key pair in which the public key has
+ been signed by a Certification Authority may use this key pair to
+ authenticate to the directory server if the user's certificate is
+ requested by the server. The user's certificate subject field SHOULD
+ be the name of the user's directory entry, and the Certification
+ Authority must be sufficiently trusted by the directory server to
+
+
+
+Wahl, et al. Standards Track [Page 9]
+
+RFC 2829 Authentication Methods for LDAP May 2000
+
+
+ have issued the certificate in order that the server can process the
+ certificate. The means by which servers validate certificate paths
+ is outside the scope of this document.
+
+ A server MAY support mappings for certificates in which the subject
+ field name is different from the name of the user's directory entry.
+ A server which supports mappings of names MUST be capable of being
+ configured to support certificates for which no mapping is required.
+
+ The client will use the Start TLS operation [5] to negotiate the use
+ of TLS security [6] on the connection to the LDAP server. The client
+ need not have bound to the directory beforehand.
+
+ In the TLS negotiation, the server MUST request a certificate. The
+ client will provide its certificate to the server, and MUST perform a
+ private key-based encryption, proving it has the private key
+ associated with the certificate.
+
+ As deployments will require protection of sensitive data in transit,
+ the client and server MUST negotiate a ciphersuite which contains a
+ bulk encryption algorithm of appropriate strength. Recommendations
+ of cipher suites are given in section 10.
+
+ The server MUST verify that the client's certificate is valid. The
+ server will normally check that the certificate is issued by a known
+ CA, and that none of the certificates on the client's certificate
+ chain are invalid or revoked. There are several procedures by which
+ the server can perform these checks.
+
+ Following the successful completion of TLS negotiation, the client
+ will send an LDAP bind request with the SASL "EXTERNAL" mechanism.
+
+8. Other mechanisms
+
+ The LDAP "simple" authentication choice is not suitable for
+ authentication on the Internet where there is no network or transport
+ layer confidentiality.
+
+ As LDAP includes native anonymous and plaintext authentication
+ methods, the "ANONYMOUS" and "PLAIN" SASL mechanisms are not used
+ with LDAP. If an authorization identity of a form different from a
+ DN is requested by the client, a mechanism that protects the password
+ in transit SHOULD be used.
+
+ The following SASL-based mechanisms are not considered in this
+ document: KERBEROS_V4, GSSAPI and SKEY.
+
+
+
+
+
+Wahl, et al. Standards Track [Page 10]
+
+RFC 2829 Authentication Methods for LDAP May 2000
+
+
+ The "EXTERNAL" SASL mechanism can be used to request the LDAP server
+ make use of security credentials exchanged by a lower layer. If a TLS
+ session has not been established between the client and server prior
+ to making the SASL EXTERNAL Bind request and there is no other
+ external source of authentication credentials (e.g. IP-level
+ security [8]), or if, during the process of establishing the TLS
+ session, the server did not request the client's authentication
+ credentials, the SASL EXTERNAL bind MUST fail with a result code of
+ inappropriateAuthentication. Any client authentication and
+ authorization state of the LDAP association is lost, so the LDAP
+ association is in an anonymous state after the failure.
+
+9. Authorization Identity
+
+ The authorization identity is carried as part of the SASL credentials
+ field in the LDAP Bind request and response.
+
+ When the "EXTERNAL" mechanism is being negotiated, if the credentials
+ field is present, it contains an authorization identity of the
+ authzId form described below.
+
+ Other mechanisms define the location of the authorization identity in
+ the credentials field.
+
+ The authorization identity is a string in the UTF-8 character set,
+ corresponding to the following ABNF [7]:
+
+ ; Specific predefined authorization (authz) id schemes are
+ ; defined below -- new schemes may be defined in the future.
+
+ authzId = dnAuthzId / uAuthzId
+
+ ; distinguished-name-based authz id.
+ dnAuthzId = "dn:" dn
+ dn = utf8string ; with syntax defined in RFC 2253
+
+ ; unspecified userid, UTF-8 encoded.
+ uAuthzId = "u:" userid
+ userid = utf8string ; syntax unspecified
+
+ A utf8string is defined to be the UTF-8 encoding of one or more ISO
+ 10646 characters.
+
+ All servers which support the storage of authentication credentials,
+ such as passwords or certificates, in the directory MUST support the
+ dnAuthzId choice.
+
+
+
+
+
+Wahl, et al. Standards Track [Page 11]
+
+RFC 2829 Authentication Methods for LDAP May 2000
+
+
+ The uAuthzId choice allows for compatibility with client applications
+ which wish to authenticate to a local directory but do not know their
+ own Distinguished Name or have a directory entry. The format of the
+ string is defined as only a sequence of UTF-8 encoded ISO 10646
+ characters, and further interpretation is subject to prior agreement
+ between the client and server.
+
+ For example, the userid could identify a user of a specific directory
+ service, or be a login name or the local-part of an RFC 822 email
+ address. In general a uAuthzId MUST NOT be assumed to be globally
+ unique.
+
+ Additional authorization identity schemes MAY be defined in future
+ versions of this document.
+
+10. TLS Ciphersuites
+
+ The following ciphersuites defined in [6] MUST NOT be used for
+ confidentiality protection of passwords or data:
+
+ TLS_NULL_WITH_NULL_NULL
+ TLS_RSA_WITH_NULL_MD5
+ TLS_RSA_WITH_NULL_SHA
+
+ The following ciphersuites defined in [6] can be cracked easily (less
+ than a week of CPU time on a standard CPU in 1997). The client and
+ server SHOULD carefully consider the value of the password or data
+ being protected before using these ciphersuites:
+
+ TLS_RSA_EXPORT_WITH_RC4_40_MD5
+ TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5
+ TLS_RSA_EXPORT_WITH_DES40_CBC_SHA
+ TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA
+ TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA
+ TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA
+ TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA
+ TLS_DH_anon_EXPORT_WITH_RC4_40_MD5
+ TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA
+
+ The following ciphersuites are vulnerable to man-in-the-middle
+ attacks, and SHOULD NOT be used to protect passwords or sensitive
+ data, unless the network configuration is such that the danger of a
+ man-in-the-middle attack is tolerable:
+
+
+
+
+
+
+
+
+Wahl, et al. Standards Track [Page 12]
+
+RFC 2829 Authentication Methods for LDAP May 2000
+
+
+ TLS_DH_anon_EXPORT_WITH_RC4_40_MD5
+ TLS_DH_anon_WITH_RC4_128_MD5
+ TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA
+ TLS_DH_anon_WITH_DES_CBC_SHA
+ TLS_DH_anon_WITH_3DES_EDE_CBC_SHA
+
+ A client or server that supports TLS MUST support at least
+ TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA.
+
+11. SASL service name for LDAP
+
+ For use with SASL [2], a protocol must specify a service name to be
+ used with various SASL mechanisms, such as GSSAPI. For LDAP, the
+ service name is "ldap", which has been registered with the IANA as a
+ GSSAPI service name.
+
+12. Security Considerations
+
+ Security issues are discussed throughout this memo; the
+ (unsurprising) conclusion is that mandatory security is important,
+ and that session encryption is required when snooping is a problem.
+
+ Servers are encouraged to prevent modifications by anonymous users.
+ Servers may also wish to minimize denial of service attacks by timing
+ out idle connections, and returning the unwillingToPerform result
+ code rather than performing computationally expensive operations
+ requested by unauthorized clients.
+
+ A connection on which the client has not performed the Start TLS
+ operation or negotiated a suitable SASL mechanism for connection
+ integrity and encryption services is subject to man-in-the-middle
+ attacks to view and modify information in transit.
+
+ Additional security considerations relating to the EXTERNAL mechanism
+ to negotiate TLS can be found in [2], [5] and [6].
+
+13. Acknowledgements
+
+ This document is a product of the LDAPEXT Working Group of the IETF.
+ The contributions of its members is greatly appreciated.
+
+
+
+
+
+
+
+
+
+
+
+Wahl, et al. Standards Track [Page 13]
+
+RFC 2829 Authentication Methods for LDAP May 2000
+
+
+14. Bibliography
+
+ [1] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access
+ Protocol (v3)", RFC 2251, December 1997.
+
+ [2] Myers, J., "Simple Authentication and Security Layer (SASL)", RFC
+ 2222, October 1997.
+
+ [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+ Levels", BCP 14, RFC 2119, March 1997.
+
+ [4] Leach, P. and C. Newman, "Using Digest Authentication as a SASL
+ Mechanism", RFC 2831, May 2000.
+
+ [5] Hodges, J., Morgan, R. and M. Wahl, "Lightweight Directory Access
+ Protocol (v3): Extension for Transport Layer Security", RFC 2830,
+ May 2000.
+
+ [6] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
+ 2246, January 1999.
+
+ [7] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
+ Specifications: ABNF", RFC 2234, November 1997.
+
+ [8] Kent, S. and R. Atkinson, "Security Architecture for the Internet
+ Protocol", RFC 2401, November 1998.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wahl, et al. Standards Track [Page 14]
+
+RFC 2829 Authentication Methods for LDAP May 2000
+
+
+15. Authors' Addresses
+
+ Mark Wahl
+ Sun Microsystems, Inc.
+ 8911 Capital of Texas Hwy #4140
+ Austin TX 78759
+ USA
+
+ EMail: M.Wahl at innosoft.com
+
+
+ Harald Tveit Alvestrand
+ EDB Maxware
+ Pirsenteret
+ N-7462 Trondheim, Norway
+
+ Phone: +47 73 54 57 97
+ EMail: Harald at Alvestrand.no
+
+
+ Jeff Hodges
+ Oblix, Inc.
+ 18922 Forge Drive
+ Cupertino, CA 95014
+ USA
+
+ Phone: +1-408-861-6656
+ EMail: JHodges at oblix.com
+
+
+ RL "Bob" Morgan
+ Computing and Communications
+ University of Washington
+ Seattle, WA 98105
+ USA
+
+ Phone: +1-206-221-3307
+ EMail: rlmorgan at washington.edu
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wahl, et al. Standards Track [Page 15]
+
+RFC 2829 Authentication Methods for LDAP May 2000
+
+
+16. Full Copyright Statement
+
+ Copyright (C) The Internet Society (2000). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wahl, et al. Standards Track [Page 16]
+
Added: openldap/vendor/openldap-release/doc/rfc/rfc2830.txt
===================================================================
--- openldap/vendor/openldap-release/doc/rfc/rfc2830.txt (rev 0)
+++ openldap/vendor/openldap-release/doc/rfc/rfc2830.txt 2007-09-15 10:38:52 UTC (rev 844)
@@ -0,0 +1,675 @@
+
+
+
+
+
+
+Network Working Group J. Hodges
+Request for Comments: 2830 Oblix Inc.
+Category: Standards Track R. Morgan
+ Univ of Washington
+ M. Wahl
+ Sun Microsystems, Inc.
+ May 2000
+
+
+ Lightweight Directory Access Protocol (v3):
+ Extension for Transport Layer Security
+
+Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2000). All Rights Reserved.
+
+Abstract
+
+ This document defines the "Start Transport Layer Security (TLS)
+ Operation" for LDAP [LDAPv3, TLS]. This operation provides for TLS
+ establishment in an LDAP association and is defined in terms of an
+ LDAP extended request.
+
+1. Conventions Used in this Document
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in [ReqsKeywords].
+
+2. The Start TLS Request
+
+ This section describes the Start TLS extended request and extended
+ response themselves: how to form the request, the form of the
+ response, and enumerates the various result codes the client MUST be
+ prepared to handle.
+
+ The section following this one then describes how to sequence an
+ overall Start TLS Operation.
+
+
+
+
+
+Hodges, et al. Standards Track [Page 1]
+
+RFC 2830 LDAPv3: Extension for Transport Layer Security May 2000
+
+
+2.1. Requesting TLS Establishment
+
+ A client may perform a Start TLS operation by transmitting an LDAP
+ PDU containing an ExtendedRequest [LDAPv3] specifying the OID for the
+ Start TLS operation:
+
+ 1.3.6.1.4.1.1466.20037
+
+ An LDAP ExtendedRequest is defined as follows:
+
+ ExtendedRequest ::= [APPLICATION 23] SEQUENCE {
+ requestName [0] LDAPOID,
+ requestValue [1] OCTET STRING OPTIONAL }
+
+ A Start TLS extended request is formed by setting the requestName
+ field to the OID string given above. The requestValue field is
+ absent. The client MUST NOT send any PDUs on this connection
+ following this request until it receives a Start TLS extended
+ response.
+
+ When a Start TLS extended request is made, the server MUST return an
+ LDAP PDU containing a Start TLS extended response. An LDAP
+ ExtendedResponse is defined as follows:
+
+ ExtendedResponse ::= [APPLICATION 24] SEQUENCE {
+ COMPONENTS OF LDAPResult,
+ responseName [10] LDAPOID OPTIONAL,
+ response [11] OCTET STRING OPTIONAL }
+
+ A Start TLS extended response MUST contain a responseName field which
+ MUST be set to the same string as that in the responseName field
+ present in the Start TLS extended request. The response field is
+ absent. The server MUST set the resultCode field to either success or
+ one of the other values outlined in section 2.3.
+
+2.2. "Success" Response
+
+ If the ExtendedResponse contains a resultCode of success, this
+ indicates that the server is willing and able to negotiate TLS. Refer
+ to section 3, below, for details.
+
+2.3. Response other than "success"
+
+ If the ExtendedResponse contains a resultCode other than success,
+ this indicates that the server is unwilling or unable to negotiate
+ TLS.
+
+
+
+
+
+Hodges, et al. Standards Track [Page 2]
+
+RFC 2830 LDAPv3: Extension for Transport Layer Security May 2000
+
+
+ If the Start TLS extended request was not successful, the resultCode
+ will be one of:
+
+ operationsError (operations sequencing incorrect; e.g. TLS already
+ established)
+
+ protocolError (TLS not supported or incorrect PDU structure)
+
+ referral (this server doesn't do TLS, try this one)
+
+ unavailable (e.g. some major problem with TLS, or server is
+ shutting down)
+
+ The server MUST return operationsError if the client violates any of
+ the Start TLS extended operation sequencing requirements described in
+ section 3, below.
+
+ If the server does not support TLS (whether by design or by current
+ configuration), it MUST set the resultCode to protocolError (see
+ section 4.1.1 of [LDAPv3]), or to referral. The server MUST include
+ an actual referral value in the LDAP Result if it returns a
+ resultCode of referral. The client's current session is unaffected if
+ the server does not support TLS. The client MAY proceed with any LDAP
+ operation, or it MAY close the connection.
+
+ The server MUST return unavailable if it supports TLS but cannot
+ establish a TLS connection for some reason, e.g. the certificate
+ server not responding, it cannot contact its TLS implementation, or
+ if the server is in process of shutting down. The client MAY retry
+ the StartTLS operation, or it MAY proceed with any other LDAP
+ operation, or it MAY close the connection.
+
+3. Sequencing of the Start TLS Operation
+
+ This section describes the overall procedures clients and servers
+ MUST follow for TLS establishment. These procedures take into
+ consideration various aspects of the overall security of the LDAP
+ association including discovery of resultant security level and
+ assertion of the client's authorization identity.
+
+ Note that the precise effects, on a client's authorization identity,
+ of establishing TLS on an LDAP association are described in detail in
+ section 5.
+
+
+
+
+
+
+
+
+Hodges, et al. Standards Track [Page 3]
+
+RFC 2830 LDAPv3: Extension for Transport Layer Security May 2000
+
+
+3.1. Requesting to Start TLS on an LDAP Association
+
+ The client MAY send the Start TLS extended request at any time after
+ establishing an LDAP association, except that in the following cases
+ the client MUST NOT send a Start TLS extended request:
+
+ - if TLS is currently established on the connection, or
+ - during a multi-stage SASL negotiation, or
+ - if there are any LDAP operations outstanding on the connection.
+
+ The result of violating any of these requirements is a resultCode of
+ operationsError, as described above in section 2.3.
+
+ The client MAY have already performed a Bind operation when it sends
+ a Start TLS request, or the client might have not yet bound.
+
+ If the client did not establish a TLS connection before sending any
+ other requests, and the server requires the client to establish a TLS
+ connection before performing a particular request, the server MUST
+ reject that request with a confidentialityRequired or
+ strongAuthRequired result. The client MAY send a Start TLS extended
+ request, or it MAY choose to close the connection.
+
+3.2. Starting TLS
+
+ The server will return an extended response with the resultCode of
+ success if it is willing and able to negotiate TLS. It will return
+ other resultCodes, documented above, if it is unable.
+
+ In the successful case, the client, which has ceased to transfer LDAP
+ requests on the connection, MUST either begin a TLS negotiation or
+ close the connection. The client will send PDUs in the TLS Record
+ Protocol directly over the underlying transport connection to the
+ server to initiate TLS negotiation [TLS].
+
+3.3. TLS Version Negotiation
+
+ Negotiating the version of TLS or SSL to be used is a part of the TLS
+ Handshake Protocol, as documented in [TLS]. Please refer to that
+ document for details.
+
+3.4. Discovery of Resultant Security Level
+
+ After a TLS connection is established on an LDAP association, both
+ parties MUST individually decide whether or not to continue based on
+ the privacy level achieved. Ascertaining the TLS connection's privacy
+ level is implementation dependent, and accomplished by communicating
+ with one's respective local TLS implementation.
+
+
+
+Hodges, et al. Standards Track [Page 4]
+
+RFC 2830 LDAPv3: Extension for Transport Layer Security May 2000
+
+
+ If the client or server decides that the level of authentication or
+ privacy is not high enough for it to continue, it SHOULD gracefully
+ close the TLS connection immediately after the TLS negotiation has
+ completed (see sections 4.1 and 5.2, below).
+
+ The client MAY attempt to Start TLS again, or MAY send an unbind
+ request, or send any other LDAP request.
+
+3.5. Assertion of Client's Authorization Identity
+
+ The client MAY, upon receipt of a Start TLS extended response
+ indicating success, assert that a specific authorization identity be
+ utilized in determining the client's authorization status. The client
+ accomplishes this via an LDAP Bind request specifying a SASL
+ mechanism of "EXTERNAL" [SASL]. See section 5.1.2, below.
+
+3.6. Server Identity Check
+
+ The client MUST check its understanding of the server's hostname
+ against the server's identity as presented in the server's
+ Certificate message, in order to prevent man-in-the-middle attacks.
+
+ Matching is performed according to these rules:
+
+ - The client MUST use the server hostname it used to open the LDAP
+ connection as the value to compare against the server name as
+ expressed in the server's certificate. The client MUST NOT use the
+ server's canonical DNS name or any other derived form of name.
+
+ - If a subjectAltName extension of type dNSName is present in the
+ certificate, it SHOULD be used as the source of the server's
+ identity.
+
+ - Matching is case-insensitive.
+
+ - The "*" wildcard character is allowed. If present, it applies only
+ to the left-most name component.
+
+ E.g. *.bar.com would match a.bar.com, b.bar.com, etc. but not
+ bar.com. If more than one identity of a given type is present in the
+ certificate (e.g. more than one dNSName name), a match in any one of
+ the set is considered acceptable.
+
+ If the hostname does not match the dNSName-based identity in the
+ certificate per the above check, user-oriented clients SHOULD either
+ notify the user (clients MAY give the user the opportunity to
+
+
+
+
+
+Hodges, et al. Standards Track [Page 5]
+
+RFC 2830 LDAPv3: Extension for Transport Layer Security May 2000
+
+
+ continue with the connection in any case) or terminate the connection
+ and indicate that the server's identity is suspect. Automated clients
+ SHOULD close the connection, returning and/or logging an error
+ indicating that the server's identity is suspect.
+
+ Beyond the server identity checks described in this section, clients
+ SHOULD be prepared to do further checking to ensure that the server
+ is authorized to provide the service it is observed to provide. The
+ client MAY need to make use of local policy information.
+
+3.7. Refresh of Server Capabilities Information
+
+ The client MUST refresh any cached server capabilities information
+ (e.g. from the server's root DSE; see section 3.4 of [LDAPv3]) upon
+ TLS session establishment. This is necessary to protect against
+ active-intermediary attacks which may have altered any server
+ capabilities information retrieved prior to TLS establishment. The
+ server MAY advertise different capabilities after TLS establishment.
+
+4. Closing a TLS Connection
+
+4.1. Graceful Closure
+
+ Either the client or server MAY terminate the TLS connection on an
+ LDAP association by sending a TLS closure alert. This will leave the
+ LDAP association intact.
+
+ Before closing a TLS connection, the client MUST either wait for any
+ outstanding LDAP operations to complete, or explicitly abandon them
+ [LDAPv3].
+
+ After the initiator of a close has sent a closure alert, it MUST
+ discard any TLS messages until it has received an alert from the
+ other party. It will cease to send TLS Record Protocol PDUs, and
+ following the receipt of the alert, MAY send and receive LDAP PDUs.
+
+ The other party, if it receives a closure alert, MUST immediately
+ transmit a TLS closure alert. It will subsequently cease to send TLS
+ Record Protocol PDUs, and MAY send and receive LDAP PDUs.
+
+4.2. Abrupt Closure
+
+ Either the client or server MAY abruptly close the entire LDAP
+ association and any TLS connection established on it by dropping the
+ underlying TCP connection. A server MAY beforehand send the client a
+ Notice of Disconnection [LDAPv3] in this case.
+
+
+
+
+
+Hodges, et al. Standards Track [Page 6]
+
+RFC 2830 LDAPv3: Extension for Transport Layer Security May 2000
+
+
+5. Effects of TLS on a Client's Authorization Identity
+
+ This section describes the effects on a client's authorization
+ identity brought about by establishing TLS on an LDAP association.
+ The default effects are described first, and next the facilities for
+ client assertion of authorization identity are discussed including
+ error conditions. Lastly, the effects of closing the TLS connection
+ are described.
+
+ Authorization identities and related concepts are defined in
+ [AuthMeth].
+
+5.1. TLS Connection Establishment Effects
+
+5.1.1. Default Effects
+
+ Upon establishment of the TLS connection onto the LDAP association,
+ any previously established authentication and authorization
+ identities MUST remain in force, including anonymous state. This
+ holds even in the case where the server requests client
+ authentication via TLS -- e.g. requests the client to supply its
+ certificate during TLS negotiation (see [TLS]).
+
+5.1.2. Client Assertion of Authorization Identity
+
+ A client MAY either implicitly request that its LDAP authorization
+ identity be derived from its authenticated TLS credentials or it MAY
+ explicitly provide an authorization identity and assert that it be
+ used in combination with its authenticated TLS credentials. The
+ former is known as an implicit assertion, and the latter as an
+ explicit assertion.
+
+5.1.2.1. Implicit Assertion
+
+ An implicit authorization identity assertion is accomplished after
+ TLS establishment by invoking a Bind request of the SASL form using
+ the "EXTERNAL" mechanism name [SASL, LDAPv3] that SHALL NOT include
+ the optional credentials octet string (found within the
+ SaslCredentials sequence in the Bind Request). The server will derive
+ the client's authorization identity from the authentication identity
+ supplied in the client's TLS credentials (typically a public key
+ certificate) according to local policy. The underlying mechanics of
+ how this is accomplished are implementation specific.
+
+
+
+
+
+
+
+
+Hodges, et al. Standards Track [Page 7]
+
+RFC 2830 LDAPv3: Extension for Transport Layer Security May 2000
+
+
+5.1.2.2. Explicit Assertion
+
+ An explicit authorization identity assertion is accomplished after
+ TLS establishment by invoking a Bind request of the SASL form using
+ the "EXTERNAL" mechanism name [SASL, LDAPv3] that SHALL include the
+ credentials octet string. This string MUST be constructed as
+ documented in section 9 of [AuthMeth].
+
+5.1.2.3. Error Conditions
+
+ For either form of assertion, the server MUST verify that the
+ client's authentication identity as supplied in its TLS credentials
+ is permitted to be mapped to the asserted authorization identity. The
+ server MUST reject the Bind operation with an invalidCredentials
+ resultCode in the Bind response if the client is not so authorized.
+
+ Additionally, with either form of assertion, if a TLS session has not
+ been established between the client and server prior to making the
+ SASL EXTERNAL Bind request and there is no other external source of
+ authentication credentials (e.g. IP-level security [IPSEC]), or if,
+ during the process of establishing the TLS session, the server did
+ not request the client's authentication credentials, the SASL
+ EXTERNAL bind MUST fail with a result code of
+ inappropriateAuthentication.
+
+ After the above Bind operation failures, any client authentication
+ and authorization state of the LDAP association is lost, so the LDAP
+ association is in an anonymous state after the failure. TLS
+ connection state is unaffected, though a server MAY end the TLS
+ connection, via a TLS close_notify message, based on the Bind failure
+ (as it MAY at any time).
+
+5.2. TLS Connection Closure Effects
+
+ Closure of the TLS connection MUST cause the LDAP association to move
+ to an anonymous authentication and authorization state regardless of
+ the state established over TLS and regardless of the authentication
+ and authorization state prior to TLS connection establishment.
+
+6. Security Considerations
+
+ The goals of using the TLS protocol with LDAP are to ensure
+ connection confidentiality and integrity, and to optionally provide
+ for authentication. TLS expressly provides these capabilities, as
+ described in [TLS].
+
+
+
+
+
+
+Hodges, et al. Standards Track [Page 8]
+
+RFC 2830 LDAPv3: Extension for Transport Layer Security May 2000
+
+
+ All security gained via use of the Start TLS operation is gained by
+ the use of TLS itself. The Start TLS operation, on its own, does not
+ provide any additional security.
+
+ The use of TLS does not provide or ensure for confidentiality and/or
+ non-repudiation of the data housed by an LDAP-based directory server.
+ Nor does it secure the data from inspection by the server
+ administrators. Once established, TLS only provides for and ensures
+ confidentiality and integrity of the operations and data in transit
+ over the LDAP association, and only if the implementations on the
+ client and server support and negotiate it.
+
+ The level of security provided though the use of TLS depends directly
+ on both the quality of the TLS implementation used and the style of
+ usage of that implementation. Additionally, an active-intermediary
+ attacker can remove the Start TLS extended operation from the
+ supportedExtension attribute of the root DSE. Therefore, both parties
+ SHOULD independently ascertain and consent to the security level
+ achieved once TLS is established and before beginning use of the TLS
+ connection. For example, the security level of the TLS connection
+ might have been negotiated down to plaintext.
+
+ Clients SHOULD either warn the user when the security level achieved
+ does not provide confidentiality and/or integrity protection, or be
+ configurable to refuse to proceed without an acceptable level of
+ security.
+
+ Client and server implementors SHOULD take measures to ensure proper
+ protection of credentials and other confidential data where such
+ measures are not otherwise provided by the TLS implementation.
+
+ Server implementors SHOULD allow for server administrators to elect
+ whether and when connection confidentiality and/or integrity is
+ required, as well as elect whether and when client authentication via
+ TLS is required.
+
+7. Acknowledgements
+
+ The authors thank Tim Howes, Paul Hoffman, John Kristian, Shirish
+ Rai, Jonathan Trostle, Harald Alvestrand, and Marcus Leech for their
+ contributions to this document.
+
+
+
+
+
+
+
+
+
+
+Hodges, et al. Standards Track [Page 9]
+
+RFC 2830 LDAPv3: Extension for Transport Layer Security May 2000
+
+
+8. References
+
+ [AuthMeth] Wahl, M., Alvestrand, H., Hodges, J. and R. Morgan,
+ "Authentication Methods for LDAP", RFC 2829, May 2000.
+
+ [IPSEC] Kent, S. and R. Atkinson, "Security Architecture for
+ the Internet Protocol", RFC 2401, November 1998.
+
+ [LDAPv3] Wahl, M., Kille S. and T. Howes, "Lightweight
+ Directory Access Protocol (v3)", RFC 2251, December
+ 1997.
+
+ [ReqsKeywords] Bradner, S., "Key Words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [SASL] Myers, J., "Simple Authentication and Security Layer
+ (SASL)", RFC 2222, October 1997.
+
+ [TLS] Dierks, T. and C. Allen. "The TLS Protocol Version
+ 1.0", RFC 2246, January 1999.
+
+9. Authors' Addresses
+
+ Jeff Hodges
+ Oblix, Inc.
+ 18922 Forge Drive
+ Cupertino, CA 95014
+ USA
+
+ Phone: +1-408-861-6656
+ EMail: JHodges at oblix.com
+
+ RL "Bob" Morgan
+ Computing and Communications
+ University of Washington
+ Seattle, WA
+ USA
+
+ Phone: +1-206-221-3307
+ EMail: rlmorgan at washington.edu
+
+ Mark Wahl
+ Sun Microsystems, Inc.
+ 8911 Capital of Texas Hwy #4140
+ Austin TX 78759
+ USA
+
+ EMail: M.Wahl at innosoft.com
+
+
+
+Hodges, et al. Standards Track [Page 10]
+
+RFC 2830 LDAPv3: Extension for Transport Layer Security May 2000
+
+
+10. Intellectual Property Rights Notices
+
+ The IETF takes no position regarding the validity or scope of any
+ intellectual property or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; neither does it represent that it
+ has made any effort to identify any such rights. Information on the
+ IETF's procedures with respect to rights in standards-track and
+ standards-related documentation can be found in BCP-11. Copies of
+ claims of rights made available for publication and any assurances of
+ licenses to be made available, or the result of an attempt made to
+ obtain a general license or permission for the use of such
+ proprietary rights by implementors or users of this specification can
+ be obtained from the IETF Secretariat.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights which may cover technology that may be required to practice
+ this standard. Please address the information to the IETF Executive
+ Director.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hodges, et al. Standards Track [Page 11]
+
+RFC 2830 LDAPv3: Extension for Transport Layer Security May 2000
+
+
+11. Full Copyright Statement
+
+ Copyright (C) The Internet Society (2000). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hodges, et al. Standards Track [Page 12]
+
Added: openldap/vendor/openldap-release/doc/rfc/rfc2849.txt
===================================================================
--- openldap/vendor/openldap-release/doc/rfc/rfc2849.txt (rev 0)
+++ openldap/vendor/openldap-release/doc/rfc/rfc2849.txt 2007-09-15 10:38:52 UTC (rev 844)
@@ -0,0 +1,787 @@
+
+
+
+
+
+
+Network Working Group G. Good
+Request for Comments: 2849 iPlanet e-commerce Solutions
+Category: Standards Track June 2000
+
+
+ The LDAP Data Interchange Format (LDIF) - Technical Specification
+
+Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2000). All Rights Reserved.
+
+Abstract
+
+ This document describes a file format suitable for describing
+ directory information or modifications made to directory information.
+ The file format, known as LDIF, for LDAP Data Interchange Format, is
+ typically used to import and export directory information between
+ LDAP-based directory servers, or to describe a set of changes which
+ are to be applied to a directory.
+
+Background and Intended Usage
+
+ There are a number of situations where a common interchange format is
+ desirable. For example, one might wish to export a copy of the
+ contents of a directory server to a file, move that file to a
+ different machine, and import the contents into a second directory
+ server.
+
+ Additionally, by using a well-defined interchange format, development
+ of data import tools from legacy systems is facilitated. A fairly
+ simple set of tools written in awk or perl can, for example, convert
+ a database of personnel information into an LDIF file. This file can
+ then be imported into a directory server, regardless of the internal
+ database representation the target directory server uses.
+
+ The LDIF format was originally developed and used in the University
+ of Michigan LDAP implementation. The first use of LDIF was in
+ describing directory entries. Later, the format was expanded to
+ allow representation of changes to directory entries.
+
+
+
+
+Good Standards Track [Page 1]
+
+RFC 2849 LDAP Data Interchange Format June 2000
+
+
+ Relationship to the application/directory MIME content-type:
+
+ The application/directory MIME content-type [1] is a general
+ framework and format for conveying directory information, and is
+ independent of any particular directory service. The LDIF format is
+ a simpler format which is perhaps easier to create, and may also be
+ used, as noted, to describe a set of changes to be applied to a
+ directory.
+
+ The key words "MUST", "MUST NOT", "MAY", "SHOULD", and "SHOULD NOT"
+ used in this document are to be interpreted as described in [7].
+
+Definition of the LDAP Data Interchange Format
+
+ The LDIF format is used to convey directory information, or a
+ description of a set of changes made to directory entries. An LDIF
+ file consists of a series of records separated by line separators. A
+ record consists of a sequence of lines describing a directory entry,
+ or a sequence of lines describing a set of changes to a directory
+ entry. An LDIF file specifies a set of directory entries, or a set
+ of changes to be applied to directory entries, but not both.
+
+ There is a one-to-one correlation between LDAP operations that modify
+ the directory (add, delete, modify, and modrdn), and the types of
+ changerecords described below ("add", "delete", "modify", and
+ "modrdn" or "moddn"). This correspondence is intentional, and
+ permits a straightforward translation from LDIF changerecords to
+ protocol operations.
+
+Formal Syntax Definition of LDIF
+
+ The following definition uses the augmented Backus-Naur Form
+ specified in RFC 2234 [2].
+
+ldif-file = ldif-content / ldif-changes
+
+ldif-content = version-spec 1*(1*SEP ldif-attrval-record)
+
+ldif-changes = version-spec 1*(1*SEP ldif-change-record)
+
+ldif-attrval-record = dn-spec SEP 1*attrval-spec
+
+ldif-change-record = dn-spec SEP *control changerecord
+
+version-spec = "version:" FILL version-number
+
+
+
+
+
+
+Good Standards Track [Page 2]
+
+RFC 2849 LDAP Data Interchange Format June 2000
+
+
+version-number = 1*DIGIT
+ ; version-number MUST be "1" for the
+ ; LDIF format described in this document.
+
+dn-spec = "dn:" (FILL distinguishedName /
+ ":" FILL base64-distinguishedName)
+
+distinguishedName = SAFE-STRING
+ ; a distinguished name, as defined in [3]
+
+base64-distinguishedName = BASE64-UTF8-STRING
+ ; a distinguishedName which has been base64
+ ; encoded (see note 10, below)
+
+rdn = SAFE-STRING
+ ; a relative distinguished name, defined as
+ ; <name-component> in [3]
+
+base64-rdn = BASE64-UTF8-STRING
+ ; an rdn which has been base64 encoded (see
+ ; note 10, below)
+
+control = "control:" FILL ldap-oid ; controlType
+ 0*1(1*SPACE ("true" / "false")) ; criticality
+ 0*1(value-spec) ; controlValue
+ SEP
+ ; (See note 9, below)
+
+ldap-oid = 1*DIGIT 0*1("." 1*DIGIT)
+ ; An LDAPOID, as defined in [4]
+
+attrval-spec = AttributeDescription value-spec SEP
+
+value-spec = ":" ( FILL 0*1(SAFE-STRING) /
+ ":" FILL (BASE64-STRING) /
+ "<" FILL url)
+ ; See notes 7 and 8, below
+
+url = <a Uniform Resource Locator,
+ as defined in [6]>
+ ; (See Note 6, below)
+
+AttributeDescription = AttributeType [";" options]
+ ; Definition taken from [4]
+
+AttributeType = ldap-oid / (ALPHA *(attr-type-chars))
+
+options = option / (option ";" options)
+
+
+
+Good Standards Track [Page 3]
+
+RFC 2849 LDAP Data Interchange Format June 2000
+
+
+option = 1*opt-char
+
+attr-type-chars = ALPHA / DIGIT / "-"
+
+opt-char = attr-type-chars
+
+changerecord = "changetype:" FILL
+ (change-add / change-delete /
+ change-modify / change-moddn)
+
+change-add = "add" SEP 1*attrval-spec
+
+change-delete = "delete" SEP
+
+change-moddn = ("modrdn" / "moddn") SEP
+ "newrdn:" ( FILL rdn /
+ ":" FILL base64-rdn) SEP
+ "deleteoldrdn:" FILL ("0" / "1") SEP
+ 0*1("newsuperior:"
+ ( FILL distinguishedName /
+ ":" FILL base64-distinguishedName) SEP)
+
+change-modify = "modify" SEP *mod-spec
+
+mod-spec = ("add:" / "delete:" / "replace:")
+ FILL AttributeDescription SEP
+ *attrval-spec
+ "-" SEP
+
+SPACE = %x20
+ ; ASCII SP, space
+
+FILL = *SPACE
+
+SEP = (CR LF / LF)
+
+CR = %x0D
+ ; ASCII CR, carriage return
+
+LF = %x0A
+ ; ASCII LF, line feed
+
+ALPHA = %x41-5A / %x61-7A
+ ; A-Z / a-z
+
+DIGIT = %x30-39
+ ; 0-9
+
+
+
+
+Good Standards Track [Page 4]
+
+RFC 2849 LDAP Data Interchange Format June 2000
+
+
+UTF8-1 = %x80-BF
+
+UTF8-2 = %xC0-DF UTF8-1
+
+UTF8-3 = %xE0-EF 2UTF8-1
+
+UTF8-4 = %xF0-F7 3UTF8-1
+
+UTF8-5 = %xF8-FB 4UTF8-1
+
+UTF8-6 = %xFC-FD 5UTF8-1
+
+SAFE-CHAR = %x01-09 / %x0B-0C / %x0E-7F
+ ; any value <= 127 decimal except NUL, LF,
+ ; and CR
+
+SAFE-INIT-CHAR = %x01-09 / %x0B-0C / %x0E-1F /
+ %x21-39 / %x3B / %x3D-7F
+ ; any value <= 127 except NUL, LF, CR,
+ ; SPACE, colon (":", ASCII 58 decimal)
+ ; and less-than ("<" , ASCII 60 decimal)
+
+SAFE-STRING = [SAFE-INIT-CHAR *SAFE-CHAR]
+
+UTF8-CHAR = SAFE-CHAR / UTF8-2 / UTF8-3 /
+ UTF8-4 / UTF8-5 / UTF8-6
+
+UTF8-STRING = *UTF8-CHAR
+
+BASE64-UTF8-STRING = BASE64-STRING
+ ; MUST be the base64 encoding of a
+ ; UTF8-STRING
+
+BASE64-CHAR = %x2B / %x2F / %x30-39 / %x3D / %x41-5A /
+ %x61-7A
+ ; +, /, 0-9, =, A-Z, and a-z
+ ; as specified in [5]
+
+BASE64-STRING = [*(BASE64-CHAR)]
+
+
+ Notes on LDIF Syntax
+
+ 1) For the LDIF format described in this document, the version
+ number MUST be "1". If the version number is absent,
+ implementations MAY choose to interpret the contents as an
+ older LDIF file format, supported by the University of
+ Michigan ldap-3.3 implementation [8].
+
+
+
+Good Standards Track [Page 5]
+
+RFC 2849 LDAP Data Interchange Format June 2000
+
+
+ 2) Any non-empty line, including comment lines, in an LDIF file
+ MAY be folded by inserting a line separator (SEP) and a SPACE.
+ Folding MUST NOT occur before the first character of the line.
+ In other words, folding a line into two lines, the first of
+ which is empty, is not permitted. Any line that begins with a
+ single space MUST be treated as a continuation of the previous
+ (non-empty) line. When joining folded lines, exactly one space
+ character at the beginning of each continued line must be
+ discarded. Implementations SHOULD NOT fold lines in the middle
+ of a multi-byte UTF-8 character.
+
+ 3) Any line that begins with a pound-sign ("#", ASCII 35) is a
+ comment line, and MUST be ignored when parsing an LDIF file.
+
+ 4) Any dn or rdn that contains characters other than those
+ defined as "SAFE-UTF8-CHAR", or begins with a character other
+ than those defined as "SAFE-INIT-UTF8-CHAR", above, MUST be
+ base-64 encoded. Other values MAY be base-64 encoded. Any
+ value that contains characters other than those defined as
+ "SAFE-CHAR", or begins with a character other than those
+ defined as "SAFE-INIT-CHAR", above, MUST be base-64 encoded.
+ Other values MAY be base-64 encoded.
+
+ 5) When a zero-length attribute value is to be included directly
+ in an LDIF file, it MUST be represented as
+ AttributeDescription ":" FILL SEP. For example, "seeAlso:"
+ followed by a newline represents a zero-length "seeAlso"
+ attribute value. It is also permissible for the value
+ referred to by a URL to be of zero length.
+
+ 6) When a URL is specified in an attrval-spec, the following
+ conventions apply:
+
+ a) Implementations SHOULD support the file:// URL format. The
+ contents of the referenced file are to be included verbatim
+ in the interpreted output of the LDIF file.
+ b) Implementations MAY support other URL formats. The
+ semantics associated with each supported URL will be
+ documented in an associated Applicability Statement.
+
+ 7) Distinguished names, relative distinguished names, and
+ attribute values of DirectoryString syntax MUST be valid UTF-8
+ strings. Implementations that read LDIF MAY interpret files
+ in which these entities are stored in some other character set
+ encoding, but implementations MUST NOT generate LDIF content
+ which does not contain valid UTF-8 data.
+
+
+
+
+
+Good Standards Track [Page 6]
+
+RFC 2849 LDAP Data Interchange Format June 2000
+
+
+ 8) Values or distinguished names that end with SPACE SHOULD be
+ base-64 encoded.
+
+ 9) When controls are included in an LDIF file, implementations
+ MAY choose to ignore some or all of them. This may be
+ necessary if the changes described in the LDIF file are being
+ sent on an LDAPv2 connection (LDAPv2 does not support
+ controls), or the particular controls are not supported by the
+ remote server. If the criticality of a control is "true", then
+ the implementation MUST either include the control, or MUST
+ NOT send the operation to a remote server.
+
+ 10) When an attrval-spec, distinguishedName, or rdn is base64-
+ encoded, the encoding rules specified in [5] are used with the
+ following exceptions: a) The requirement that base64 output
+ streams must be represented as lines of no more than 76
+ characters is removed. Lines in LDIF files may only be folded
+ according to the folding rules described in note 2, above. b)
+ Base64 strings in [5] may contain characters other than those
+ defined in BASE64-CHAR, and are ignored. LDIF does not permit
+ any extraneous characters, other than those used for line
+ folding.
+
+Examples of LDAP Data Interchange Format
+
+Example 1: An simple LDAP file with two entries
+
+version: 1
+dn: cn=Barbara Jensen, ou=Product Development, dc=airius, dc=com
+objectclass: top
+objectclass: person
+objectclass: organizationalPerson
+cn: Barbara Jensen
+cn: Barbara J Jensen
+cn: Babs Jensen
+sn: Jensen
+uid: bjensen
+telephonenumber: +1 408 555 1212
+description: A big sailing fan.
+
+dn: cn=Bjorn Jensen, ou=Accounting, dc=airius, dc=com
+objectclass: top
+objectclass: person
+objectclass: organizationalPerson
+cn: Bjorn Jensen
+sn: Jensen
+telephonenumber: +1 408 555 1212
+
+
+
+
+Good Standards Track [Page 7]
+
+RFC 2849 LDAP Data Interchange Format June 2000
+
+
+Example 2: A file containing an entry with a folded attribute value
+
+version: 1
+dn:cn=Barbara Jensen, ou=Product Development, dc=airius, dc=com
+objectclass:top
+objectclass:person
+objectclass:organizationalPerson
+cn:Barbara Jensen
+cn:Barbara J Jensen
+cn:Babs Jensen
+sn:Jensen
+uid:bjensen
+telephonenumber:+1 408 555 1212
+description:Babs is a big sailing fan, and travels extensively in sea
+ rch of perfect sailing conditions.
+title:Product Manager, Rod and Reel Division
+
+Example 3: A file containing a base-64-encoded value
+
+version: 1
+dn: cn=Gern Jensen, ou=Product Testing, dc=airius, dc=com
+objectclass: top
+objectclass: person
+objectclass: organizationalPerson
+cn: Gern Jensen
+cn: Gern O Jensen
+sn: Jensen
+uid: gernj
+telephonenumber: +1 408 555 1212
+description:: V2hhdCBhIGNhcmVmdWwgcmVhZGVyIHlvdSBhcmUhICBUaGlzIHZhbHVl
+IGlzIGJhc2UtNjQtZW5jb2RlZCBiZWNhdXNlIGl0IGhhcyBhIGNvbnRyb2wgY2hhcmFjdG
+VyIGluIGl0IChhIENSKS4NICBCeSB0aGUgd2F5LCB5b3Ugc2hvdWxkIHJlYWxseSBnZXQg
+b3V0IG1vcmUu
+
+Example 4: A file containing an entries with UTF-8-encoded attribute
+values, including language tags. Comments indicate the contents
+of UTF-8-encoded attributes and distinguished names.
+
+version: 1
+dn:: b3U95Za25qWt6YOoLG89QWlyaXVz
+# dn:: ou=<JapaneseOU>,o=Airius
+objectclass: top
+objectclass: organizationalUnit
+ou:: 5Za25qWt6YOo
+# ou:: <JapaneseOU>
+ou;lang-ja:: 5Za25qWt6YOo
+# ou;lang-ja:: <JapaneseOU>
+ou;lang-ja;phonetic:: 44GI44GE44GO44KH44GG44G2
+
+
+
+Good Standards Track [Page 8]
+
+RFC 2849 LDAP Data Interchange Format June 2000
+
+
+# ou;lang-ja:: <JapaneseOU_in_phonetic_representation>
+ou;lang-en: Sales
+description: Japanese office
+
+dn:: dWlkPXJvZ2FzYXdhcmEsb3U95Za25qWt6YOoLG89QWlyaXVz
+# dn:: uid=<uid>,ou=<JapaneseOU>,o=Airius
+userpassword: {SHA}O3HSv1MusyL4kTjP+HKI5uxuNoM=
+objectclass: top
+objectclass: person
+objectclass: organizationalPerson
+objectclass: inetOrgPerson
+uid: rogasawara
+mail: rogasawara at airius.co.jp
+givenname;lang-ja:: 44Ot44OJ44OL44O8
+# givenname;lang-ja:: <JapaneseGivenname>
+sn;lang-ja:: 5bCP56yg5Y6f
+# sn;lang-ja:: <JapaneseSn>
+cn;lang-ja:: 5bCP56yg5Y6fIOODreODieODi+ODvA==
+# cn;lang-ja:: <JapaneseCn>
+title;lang-ja:: 5Za25qWt6YOoIOmDqOmVtw==
+# title;lang-ja:: <JapaneseTitle>
+preferredlanguage: ja
+givenname:: 44Ot44OJ44OL44O8
+# givenname:: <JapaneseGivenname>
+sn:: 5bCP56yg5Y6f
+# sn:: <JapaneseSn>
+cn:: 5bCP56yg5Y6fIOODreODieODi+ODvA==
+# cn:: <JapaneseCn>
+title:: 5Za25qWt6YOoIOmDqOmVtw==
+# title:: <JapaneseTitle>
+givenname;lang-ja;phonetic:: 44KN44Gp44Gr44O8
+# givenname;lang-ja;phonetic::
+<JapaneseGivenname_in_phonetic_representation_kana>
+sn;lang-ja;phonetic:: 44GK44GM44GV44KP44KJ
+# sn;lang-ja;phonetic:: <JapaneseSn_in_phonetic_representation_kana>
+cn;lang-ja;phonetic:: 44GK44GM44GV44KP44KJIOOCjeOBqeOBq+ODvA==
+# cn;lang-ja;phonetic:: <JapaneseCn_in_phonetic_representation_kana>
+title;lang-ja;phonetic:: 44GI44GE44GO44KH44GG44G2IOOBtuOBoeOCh+OBhg==
+# title;lang-ja;phonetic::
+# <JapaneseTitle_in_phonetic_representation_kana>
+givenname;lang-en: Rodney
+sn;lang-en: Ogasawara
+cn;lang-en: Rodney Ogasawara
+title;lang-en: Sales, Director
+
+
+
+
+
+
+
+Good Standards Track [Page 9]
+
+RFC 2849 LDAP Data Interchange Format June 2000
+
+
+Example 5: A file containing a reference to an external file
+
+version: 1
+dn: cn=Horatio Jensen, ou=Product Testing, dc=airius, dc=com
+objectclass: top
+objectclass: person
+objectclass: organizationalPerson
+cn: Horatio Jensen
+
+cn: Horatio N Jensen
+sn: Jensen
+uid: hjensen
+telephonenumber: +1 408 555 1212
+jpegphoto:< file:///usr/local/directory/photos/hjensen.jpg
+
+Example 6: A file containing a series of change records and comments
+
+version: 1
+# Add a new entry
+dn: cn=Fiona Jensen, ou=Marketing, dc=airius, dc=com
+changetype: add
+objectclass: top
+objectclass: person
+objectclass: organizationalPerson
+cn: Fiona Jensen
+sn: Jensen
+uid: fiona
+telephonenumber: +1 408 555 1212
+jpegphoto:< file:///usr/local/directory/photos/fiona.jpg
+
+# Delete an existing entry
+dn: cn=Robert Jensen, ou=Marketing, dc=airius, dc=com
+changetype: delete
+
+# Modify an entry's relative distinguished name
+dn: cn=Paul Jensen, ou=Product Development, dc=airius, dc=com
+changetype: modrdn
+newrdn: cn=Paula Jensen
+deleteoldrdn: 1
+
+# Rename an entry and move all of its children to a new location in
+# the directory tree (only implemented by LDAPv3 servers).
+dn: ou=PD Accountants, ou=Product Development, dc=airius, dc=com
+changetype: modrdn
+newrdn: ou=Product Development Accountants
+deleteoldrdn: 0
+newsuperior: ou=Accounting, dc=airius, dc=com
+
+
+
+
+Good Standards Track [Page 10]
+
+RFC 2849 LDAP Data Interchange Format June 2000
+
+
+# Modify an entry: add an additional value to the postaladdress
+# attribute, completely delete the description attribute, replace
+# the telephonenumber attribute with two values, and delete a specific
+# value from the facsimiletelephonenumber attribute
+dn: cn=Paula Jensen, ou=Product Development, dc=airius, dc=com
+changetype: modify
+add: postaladdress
+postaladdress: 123 Anystreet $ Sunnyvale, CA $ 94086
+-
+
+delete: description
+-
+replace: telephonenumber
+telephonenumber: +1 408 555 1234
+telephonenumber: +1 408 555 5678
+-
+delete: facsimiletelephonenumber
+facsimiletelephonenumber: +1 408 555 9876
+-
+
+# Modify an entry: replace the postaladdress attribute with an empty
+# set of values (which will cause the attribute to be removed), and
+# delete the entire description attribute. Note that the first will
+# always succeed, while the second will only succeed if at least
+# one value for the description attribute is present.
+dn: cn=Ingrid Jensen, ou=Product Support, dc=airius, dc=com
+changetype: modify
+replace: postaladdress
+-
+delete: description
+-
+
+Example 7: An LDIF file containing a change record with a control
+version: 1
+# Delete an entry. The operation will attach the LDAPv3
+# Tree Delete Control defined in [9]. The criticality
+# field is "true" and the controlValue field is
+# absent, as required by [9].
+dn: ou=Product Development, dc=airius, dc=com
+control: 1.2.840.113556.1.4.805 true
+changetype: delete
+
+
+
+
+
+
+
+
+
+
+Good Standards Track [Page 11]
+
+RFC 2849 LDAP Data Interchange Format June 2000
+
+
+Security Considerations
+
+ Given typical directory applications, an LDIF file is likely to
+ contain sensitive personal data. Appropriate measures should be
+ taken to protect the privacy of those persons whose data is contained
+ in an LDIF file.
+
+ Since ":<" directives can cause external content to be included when
+ processing an LDIF file, one should be cautious of accepting LDIF
+ files from external sources. A "trojan" LDIF file could name a file
+ with sensitive contents and cause it to be included in a directory
+ entry, which a hostile entity could read via LDAP.
+
+ LDIF does not provide any method for carrying authentication
+ information with an LDIF file. Users of LDIF files must take care to
+ verify the integrity of an LDIF file received from an external
+ source.
+
+Acknowledgments
+
+ The LDAP Interchange Format was developed as part of the University
+ of Michigan LDAP reference implementation, and was developed by Tim
+ Howes, Mark Smith, and Gordon Good. It is based in part upon work
+ supported by the National Science Foundation under Grant No. NCR-
+ 9416667.
+
+ Members of the IETF LDAP Extensions Working group provided many
+ helpful suggestions. In particular, Hallvard B. Furuseth of the
+ University of Oslo made many significant contributions to this
+ document, including a thorough review and rewrite of the BNF.
+
+References
+
+ [1] Howes, T. and M. Smith, "A MIME Content-Type for Directory
+ Information", RFC 2425, September 1998.
+
+ [2] Crocker, D., and P. Overell, "Augmented BNF for Syntax
+ Specifications: ABNF", RFC 2234, November 1997.
+
+ [3] Wahl, M., Kille, S. and T. Howes, "A String Representation of
+ Distinguished Names", RFC 2253, December 1997.
+
+ [4] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access
+ Protocol (v3)", RFC 2251, July 1997.
+
+ [5] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+ Extensions (MIME) Part One: Format of Internet Message Bodies",
+ RFC 2045, November 1996.
+
+
+
+Good Standards Track [Page 12]
+
+RFC 2849 LDAP Data Interchange Format June 2000
+
+
+ [6] Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform
+ Resource Locators (URL)", RFC 1738, December 1994.
+
+ [7] Bradner, S., "Key Words for use in RFCs to Indicate Requirement
+ Levels", BCP 14, RFC 2119, March 1997.
+
+ [8] The SLAPD and SLURPD Administrators Guide. University of
+ Michigan, April 1996. <URL:
+ http://www.umich.edu/~dirsvcs/ldap/doc/guides/slapd/toc.html>
+
+ [9] M. P. Armijo, "Tree Delete Control", Work in Progress.
+
+Author's Address
+
+ Gordon Good
+ iPlanet e-commerce Solutions
+ 150 Network Circle
+ Mailstop USCA17-201
+ Santa Clara, CA 95054, USA
+
+ Phone: +1 408 276 4351
+ EMail: ggood at netscape.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Good Standards Track [Page 13]
+
+RFC 2849 LDAP Data Interchange Format June 2000
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2000). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Good Standards Track [Page 14]
+
Added: openldap/vendor/openldap-release/doc/rfc/rfc2891.txt
===================================================================
--- openldap/vendor/openldap-release/doc/rfc/rfc2891.txt (rev 0)
+++ openldap/vendor/openldap-release/doc/rfc/rfc2891.txt 2007-09-15 10:38:52 UTC (rev 844)
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+Network Working Group T. Howes
+Request for Comments: 2891 Loudcloud
+Category: Standards Track M. Wahl
+ Sun Microsystems
+ A. Anantha
+ Microsoft
+ August 2000
+
+
+ LDAP Control Extension for Server Side Sorting of Search Results
+
+Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2000). All Rights Reserved.
+
+Abstract
+
+ This document describes two LDAPv3 control extensions for server side
+ sorting of search results. These controls allows a client to specify
+ the attribute types and matching rules a server should use when
+ returning the results to an LDAP search request. The controls may be
+ useful when the LDAP client has limited functionality or for some
+ other reason cannot sort the results but still needs them sorted.
+ Other permissible controls on search operations are not defined in
+ this extension.
+
+ The sort controls allow a server to return a result code for the
+ sorting of the results that is independent of the result code
+ returned for the search operation.
+
+ The key words "MUST", "SHOULD", and "MAY" used in this document are
+ to be interpreted as described in [bradner97].
+
+
+
+
+
+
+
+
+
+
+
+Howes, et al. Standards Track [Page 1]
+
+RFC 2891 LDAP Control Extension for Server Side Sorting August 2000
+
+
+1. The Controls
+
+1.1 Request Control
+
+ This control is included in the searchRequest message as part of the
+ controls field of the LDAPMessage, as defined in Section 4.1.12 of
+ [LDAPv3].
+
+ The controlType is set to "1.2.840.113556.1.4.473". The criticality
+ MAY be either TRUE or FALSE (where absent is also equivalent to
+ FALSE) at the client's option. The controlValue is an OCTET STRING,
+ whose value is the BER encoding of a value of the following SEQUENCE:
+
+ SortKeyList ::= SEQUENCE OF SEQUENCE {
+ attributeType AttributeDescription,
+ orderingRule [0] MatchingRuleId OPTIONAL,
+ reverseOrder [1] BOOLEAN DEFAULT FALSE }
+
+ The SortKeyList sequence is in order of highest to lowest sort key
+ precedence.
+
+ The MatchingRuleId, as defined in section 4.1.9 of [LDAPv3], SHOULD
+ be one that is valid for the attribute type it applies to. If it is
+ not, the server will return inappropriateMatching.
+
+ Each attributeType should only occur in the SortKeyList once. If an
+ attributeType is included in the sort key list multiple times, the
+ server should return an error in the sortResult of
+ unwillingToPerform.
+
+ If the orderingRule is omitted, the ordering MatchingRule defined for
+ use with this attribute MUST be used.
+
+ Any conformant implementation of this control MUST allow a sort key
+ list with at least one key.
+
+1.2 Response Control
+
+ This control is included in the searchResultDone message as part of
+ the controls field of the LDAPMessage, as defined in Section 4.1.12
+ of [LDAPv3].
+
+ The controlType is set to "1.2.840.113556.1.4.474". The criticality
+ is FALSE (MAY be absent). The controlValue is an OCTET STRING, whose
+ value is the BER encoding of a value of the following SEQUENCE:
+
+
+
+
+
+
+Howes, et al. Standards Track [Page 2]
+
+RFC 2891 LDAP Control Extension for Server Side Sorting August 2000
+
+
+ SortResult ::= SEQUENCE {
+ sortResult ENUMERATED {
+ success (0), -- results are sorted
+ operationsError (1), -- server internal failure
+ timeLimitExceeded (3), -- timelimit reached before
+ -- sorting was completed
+ strongAuthRequired (8), -- refused to return sorted
+ -- results via insecure
+ -- protocol
+ adminLimitExceeded (11), -- too many matching entries
+ -- for the server to sort
+ noSuchAttribute (16), -- unrecognized attribute
+ -- type in sort key
+ inappropriateMatching (18), -- unrecognized or
+ -- inappropriate matching
+ -- rule in sort key
+ insufficientAccessRights (50), -- refused to return sorted
+ -- results to this client
+ busy (51), -- too busy to process
+ unwillingToPerform (53), -- unable to sort
+ other (80)
+ },
+ attributeType [0] AttributeDescription OPTIONAL }
+
+2. Client-Server Interaction
+
+ The sortKeyRequestControl specifies one or more attribute types and
+ matching rules for the results returned by a search request. The
+ server SHOULD return all results for the search request in the order
+ specified by the sort keys. If the reverseOrder field is set to TRUE,
+ then the entries will be presented in reverse sorted order for the
+ specified key.
+
+ There are six possible scenarios that may occur as a result of the
+ sort control being included on the search request:
+
+ 1 - If the server does not support this sorting control and the
+ client specified TRUE for the control's criticality field, then
+ the server MUST return unavailableCriticalExtension as a return
+ code in the searchResultDone message and not send back any other
+ results. This behavior is specified in section 4.1.12 of
+ [LDAPv3].
+
+ 2 - If the server does not support this sorting control and the
+ client specified FALSE for the control's criticality field, then
+ the server MUST ignore the sort control and process the search
+ request as if it were not present. This behavior is specified in
+ section 4.1.12 of [LDAPv3].
+
+
+
+Howes, et al. Standards Track [Page 3]
+
+RFC 2891 LDAP Control Extension for Server Side Sorting August 2000
+
+
+ 3 - If the server supports this sorting control but for some reason
+ cannot sort the search results using the specified sort keys and
+ the client specified TRUE for the control's criticality field,
+ then the server SHOULD do the following: return
+ unavailableCriticalExtension as a return code in the
+ searchResultDone message; include the sortKeyResponseControl in
+ the searchResultDone message, and not send back any search result
+ entries.
+
+ 4 - If the server supports this sorting control but for some reason
+ cannot sort the search results using the specified sort keys and
+ the client specified FALSE for the control's criticality field,
+ then the server should return all search results unsorted and
+ include the sortKeyResponseControl in the searchResultDone
+ message.
+
+ 5 - If the server supports this sorting control and can sort the
+ search results using the specified sort keys, then it should
+ include the sortKeyResponseControl in the searchResultDone
+ message with a sortResult of success.
+
+ 6 - If the search request failed for any reason and/or there are no
+ searchResultEntry messages returned for the search response, then
+ the server SHOULD omit the sortKeyResponseControl from the
+ searchResultDone message.
+
+ The client application is assured that the results are sorted in the
+ specified key order if and only if the result code in the
+ sortKeyResponseControl is success. If the server omits the
+ sortKeyResponseControl from the searchResultDone message, the client
+ SHOULD assume that the sort control was ignored by the server.
+
+ The sortKeyResponseControl, if included by the server in the
+ searchResultDone message, should have the sortResult set to either
+ success if the results were sorted in accordance with the keys
+ specified in the sortKeyRequestControl or set to the appropriate
+ error code as to why it could not sort the data (such as
+ noSuchAttribute or inappropriateMatching). Optionally, the server MAY
+ set the attributeType to the first attribute type specified in the
+ SortKeyList that was in error. The client SHOULD ignore the
+ attributeType field if the sortResult is success.
+
+ The server may not be able to sort the results using the specified
+ sort keys because it may not recognize one of the attribute types,
+ the matching rule associated with an attribute type is not
+ applicable, or none of the attributes in the search response are of
+ these types. Servers may also restrict the number of keys allowed in
+ the control, such as only supporting a single key.
+
+
+
+Howes, et al. Standards Track [Page 4]
+
+RFC 2891 LDAP Control Extension for Server Side Sorting August 2000
+
+
+ Servers that chain requests to other LDAP servers should ensure that
+ the server satisfying the client's request sort the entire result set
+ prior to sending back the results.
+
+2.1 Behavior in a chained environment
+
+ If a server receives a sort request, the client expects to receive a
+ set of sorted results. If a client submits a sort request to a server
+ which chains the request and gets entries from multiple servers, and
+ the client has set the criticality of the sort extension to TRUE, the
+ server MUST merge sort the results before returning them to the
+ client or MUST return unwillingToPerform.
+
+2.2 Other sort issues
+
+ An entry that meets the search criteria may be missing one or more of
+ the sort keys. In that case, the entry is considered to have a value
+ of NULL for that key. This standard considers NULL to be a larger
+ value than all other valid values for that key. For example, if only
+ one key is specified, entries which meet the search criteria but do
+ not have that key collate after all the entries which do have that
+ key. If the reverseOrder flag is set, and only one key is specified,
+ entries which meet the search criteria but do not have that key
+ collate BEFORE all the entries which do have that key.
+
+ If a sort key is a multi-valued attribute, and an entry happens to
+ have multiple values for that attribute and no other controls are
+ present that affect the sorting order, then the server SHOULD use the
+ least value (according to the ORDERING rule for that attribute).
+
+3. Interaction with other search controls
+
+ When the sortKeyRequestControl control is included with the
+ pagedResultsControl control as specified in [LdapPaged], then the
+ server should send the searchResultEntry messages sorted according to
+ the sort keys applied to the entire result set. The server should not
+ simply sort each page, as this will give erroneous results to the
+ client.
+
+ The sortKeyList must be present on each searchRequest message for the
+ paged result. It also must not change between searchRequests for the
+ same result set. If the server has sorted the data, then it SHOULD
+ send back a sortKeyResponseControl control on every searchResultDone
+ message for each page. This will allow clients to quickly determine
+ if the result set is sorted, rather than waiting to receive the
+ entire result set.
+
+
+
+
+
+Howes, et al. Standards Track [Page 5]
+
+RFC 2891 LDAP Control Extension for Server Side Sorting August 2000
+
+
+4. Security Considerations
+
+ Implementors and administrators should be aware that allowing sorting
+ of results could enable the retrieval of a large number of records
+ from a given directory service, regardless of administrative limits
+ set on the maximum number of records to return.
+
+ A client that desired to pull all records out of a directory service
+ could use a combination of sorting and updating of search filters to
+ retrieve all records in a database in small result sets, thus
+ circumventing administrative limits.
+
+ This behavior can be overcome by the judicious use of permissions on
+ the directory entries by the administrator and by intelligent
+ implementations of administrative limits on the number of records
+ retrieved by a client.
+
+5. References
+
+ [LDAPv3] Wahl, M, Kille, S. and T. Howes, "Lightweight Directory
+ Access Protocol (v3)", RFC 2251, December 1997.
+
+ [Bradner97] Bradner, S., "Key Words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [LdapPaged] Weider, C., Herron, A., Anantha, A. and T. Howes, "LDAP
+ Control Extension for Simple Paged Results Manipulation",
+ RFC 2696, September 1999.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Howes, et al. Standards Track [Page 6]
+
+RFC 2891 LDAP Control Extension for Server Side Sorting August 2000
+
+
+6. Authors' Addresses
+
+ Anoop Anantha
+ Microsoft Corp.
+ 1 Microsoft Way
+ Redmond, WA 98052
+ USA
+
+ Phone: +1 425 882-8080
+ EMail: anoopa at microsoft.com
+
+
+ Tim Howes
+ Loudcloud, Inc.
+ 615 Tasman Dr.
+ Sunnyvale, CA 94089
+ USA
+
+ EMail: howes at loudcloud.com
+
+
+ Mark Wahl
+ Sun Microsystems, Inc.
+ 8911 Capital of Texas Hwy Suite 4140
+ Austin, TX 78759
+ USA
+
+ EMail: Mark.Wahl at sun.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Howes, et al. Standards Track [Page 7]
+
+RFC 2891 LDAP Control Extension for Server Side Sorting August 2000
+
+
+7. Full Copyright Statement
+
+ Copyright (C) The Internet Society (2000). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Howes, et al. Standards Track [Page 8]
+
Added: openldap/vendor/openldap-release/doc/rfc/rfc2926.txt
===================================================================
--- openldap/vendor/openldap-release/doc/rfc/rfc2926.txt (rev 0)
+++ openldap/vendor/openldap-release/doc/rfc/rfc2926.txt 2007-09-15 10:38:52 UTC (rev 844)
@@ -0,0 +1,1515 @@
+
+
+
+
+
+
+Network Working Group J. Kempf
+Request for Comments: 2926 Sun Microsystems, Inc.
+Category: Informational R. Moats
+ Coreon, Inc.
+ P. St. Pierre
+ Sun Microsystems, Inc.
+ September 2000
+
+
+ Conversion of LDAP Schemas to and from SLP Templates
+
+Status of this Memo
+
+ This memo provides information for the Internet community. It does
+ not specify an Internet standard of any kind. Distribution of this
+ memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2000). All Rights Reserved.
+
+Abstract
+
+ This document describes a procedure for mapping between Service
+ Location Protocol (SLP) service advertisements and lightweight
+ directory access protocol (LDAP) descriptions of services. The
+ document covers two aspects of the mapping. One aspect is mapping
+ between SLP service type templates and LDAP directory schema.
+ Because the SLP service type template grammar is relatively simple,
+ mapping from service type templates to LDAP types is straightforward.
+ Mapping in the other direction is straightforward if the attributes
+ are restricted to use just a few of the syntaxes defined in RFC 2252.
+ If arbitrary ASN.1 types occur in the schema, then the mapping is
+ more complex and may even be impossible. The second aspect is
+ representation of service information in an LDAP directory. The
+ recommended representation simplifies interoperability with SLP by
+ allowing SLP directory agents to backend into LDAP directory servers.
+ The resulting system allows service advertisements to propagate
+ easily between SLP and LDAP.
+
+
+
+
+
+
+
+
+
+
+
+
+Kempf, et al. Informational [Page 1]
+
+RFC 2926 Conversion of LDAP Schemas September 2000
+
+
+Table of Contents
+
+ 1.0 Introduction ................................................ 2
+ 2.0 Mapping SLP Templates to LDAP Schema ........................ 3
+ 2.1 Mapping from SLP Attribute Types to LDAP Attribute Types .. 8
+ 2.1.1 Integer ............................................... 8
+ 2.1.2 String ................................................ 8
+ 2.1.3 Boolean ............................................... 9
+ 2.1.4 Opaque ................................................ 9
+ 2.2 Keyword Attributes ........................................ 9
+ 2.3 Template Flags ............................................ 9
+ 2.3.1 Multi-valued .......................................... 9
+ 2.3.2 Optional .............................................. 10
+ 2.3.3 Literal ............................................... 10
+ 2.3.4 Explicit Matching ..................................... 10
+ 2.4 Default and Allowed Value Lists ........................... 10
+ 2.5 Descriptive Text .......................................... 11
+ 2.6 Generating LDAP Attribute OIDs ............................ 11
+ 2.7 Example ................................................... 11
+ 3.0 Attribute Name Conflicts .................................... 15
+ 4.0 Mapping from Schema to Templates ............................ 15
+ 4.1 Mapping LDAP Attribute Types to SLP Attribute Types ....... 16
+ 4.2 Mapping ASN.1 Types to SLP Types .......................... 17
+ 4.2.1 Integer ............................................... 18
+ 4.2.2 Boolean ............................................... 18
+ 4.2.3 Enumerated ............................................ 18
+ 4.2.4 Object Identifier ..................................... 19
+ 4.2.5 Octet String .......................................... 19
+ 4.2.6 Real .................................................. 19
+ 4.3 Example ASN.1 Schema ...................................... 19
+ 5.0 Representing SLP Service Advertisements in an LDAP DIT ...... 22
+ 6.0 Internationalization Considerations ......................... 24
+ 7.0 Security Considerations ..................................... 24
+ 8.0 References .................................................. 25
+ 9.0 Authors' Addresses .......................................... 26
+ 10.0 Full Copyright Statement ................................... 27
+
+1.0 Introduction
+
+ SLP templates [1] are intended to create a simple encoding of the
+ syntactic and semantic conventions for individual service types,
+ their attributes, and conventions. They can easily be generated,
+ transmitted, read by humans and parsed by programs, as it is a string
+ based syntax with required comments. Directory schemas serve to
+ formalize directory entry structures for use with LDAP [2] These
+ directories serve to store information about many types of entities.
+ Network services are an example of one such entity.
+
+
+
+
+Kempf, et al. Informational [Page 2]
+
+RFC 2926 Conversion of LDAP Schemas September 2000
+
+
+ Interoperability between SLP and LDAP is important so clients using
+ one protocol derive benefit from services registered through the
+ other. In addition, LDAP directory servers can serve as the backend
+ for SLP directory agents (DAs) if interoperability is possible In
+ order to facilitate interoperability, this document creates mappings
+ between the SLP template grammar and LDAP directory schema, and
+ establishes some conventions for representing service advertisements
+ in LDAP directories. The goal of the translation is to allow SLPv2
+ queries (which are syntactically and semantically equivalent to
+ LDAPv3 string queries [7]) to be submitted to an LDAP directory
+ server by an SLP DA backended into LDAP without extensive processing
+ by the DA.
+
+ The simple notation and syntactic/semantic attribute capabilities of
+ SLP templates map easily into directory schemas, and are easily
+ converted into directory schemas, even by automated means. The
+ reverse may not be true. If the LDAP schema contains attributes with
+ unrecognized or complex syntaxes, the translation may be difficult or
+ impossible. If, however, the LDAP schema only uses a few of the
+ common syntaxes defined in RFC 2252 [8], then the translation is more
+ straightforward. In addition, to foster complete bidirectionality,
+ the mapping must follow a very specific representation in its DESC
+ attributes.
+
+ This document outlines the correct mappings for SLP templates into
+ the syntactic representation specified for LDAP directory schema by
+ RFC 2252 [8]. This syntax is a subset of the ASN.1/BER described in
+ the X.209 specification [9], and is used by the LDAPv3 [2] directory
+ schema. Likewise, rules and guidelines are proposed to facilitate
+ consistent mapping of ASN.1 based schemas to be translated in the SLP
+ template grammar. Finally, a proposal for a representation of service
+ advertisements in LDAP directory services is made that facilitates
+ SLP interoperability.
+
+ Except when used as elements in the definition of LDAP schemas, the
+ key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in RFC 2119 [16].
+
+2.0 Mapping SLP Templates to LDAP Schema
+
+ We define the following abstract object class as the parent class for
+ all services. Any specific service type is a subclass of this, with
+ its own attributes:
+
+
+
+
+
+
+
+Kempf, et al. Informational [Page 3]
+
+RFC 2926 Conversion of LDAP Schemas September 2000
+
+
+ ( 1.3.6.1.4.1.6252.2.27.6.2.1
+ NAME 'slpService'
+ DESC 'parent superclass for SLP services'
+ ABSTRACT
+ SUP top
+ MUST ( template-major-version-number $
+ template-minor-version-number $
+ description $
+ template-url-syntax $
+ service-advert-service-type $
+ service-advert-scopes )
+ MAY ( service-advert-url-authenticator $
+ service-advert-attribute-authenticator ) )
+
+ The attributes correspond to various parts of the SLP service
+ template and SLP service advertisement.
+
+ SLP service type templates begin with four definitions that set the
+ context of the template:
+
+ template-type - This defines the service type of the template. The
+ service type can be a simple service type, like "service:ftp", an
+ abstract service type, like "service:printer" or a concrete
+ service type, like "service:printer:lpr". The type name can
+ additionally include a naming authority, for example
+ "service:printer.sun:local". The name that appears in this field
+ omits the "service:" prefix.
+
+ template-version - A string containing a major and minor version
+ number, separated by a period.
+
+ template-description - A block of human readable text describing
+ what the service type does.
+
+ template-url-syntax - An ABNF [6] grammar describing the service
+ type specific part of the service URL.
+
+ The SLP template-type definition is used as the name of the LDAP
+ object class for the template, a subclass of the "slpService" class,
+ together with the "service" prefix to indicate that the name is for a
+ service. In the translating service type name, colons and the period
+ separating the naming authority are converted into hyphens. If the
+ template defines an SLP concrete type, the concrete type name is
+ used; the abstract type name is never used. For example, the
+ template for "service:printer:lpr" is translated into an LDAP object
+ class called "service-printer-lpr". Furthermore, if the type name
+ contains a naming authority, the naming authority name must be
+
+
+
+
+Kempf, et al. Informational [Page 4]
+
+RFC 2926 Conversion of LDAP Schemas September 2000
+
+
+ included. For example, the service type name
+ "service:printer.sun:local" becomes "service-printer-sun-local". The
+ LDAP object class is always "STRUCTURAL".
+
+ The template-version definition is partitioned into two attributes,
+ template-major-version-number and template-minor-version-number. The
+ LDAP definition for these attributes is:
+
+ ( 1.3.6.1.4.1.6252.2.27.6.1.1
+ NAME 'template-major-version-number'
+ DESC 'The major version number of the service type template'
+ EQUALITY integerMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
+ SINGLE-VALUE
+ )
+
+ ( 1.3.6.1.4.1.6252.2.27.6.1.2
+ NAME 'template-minor-version-number'
+ DESC 'The minor version number of the service type template'
+ EQUALITY integerMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
+ SINGLE-VALUE
+ )
+
+ The template-url-syntax definition in the SLP template is described
+ by the following attribute:
+
+ ( 1.3.6.1.4.1.6252.2.27.6.1.3
+ NAME 'template-url-syntax'
+ DESC 'An ABNF grammar describing the service type
+ specific part of the service URL'
+ EQUALITY caseExactIA5Match
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
+ SINGLE-VALUE
+ )
+
+ The template-description attribute is translated into the X.520
+ standard attribute "description" [3].
+
+ We further establish the convention that SLP template characteristics
+ that can't be translated into LDAP are inserted into the DESC field
+ of the object class definition. The items are separated by empty
+ lines (consisting of two "LINE FEED" characters), are preceded by a
+ LINE FEED character, and are tagged at the beginning of the line to
+ indicate what they represent. This allows the template to be
+ reconstructed from the schema by properly parsing the comments.
+
+
+
+
+
+Kempf, et al. Informational [Page 5]
+
+RFC 2926 Conversion of LDAP Schemas September 2000
+
+
+ The bulk of an SLP template consists of attribute definitions. There
+ are four items in an SLP template attribute definition that need to
+ be mapped into LDAP:
+
+ Attribute Name - Since SLPv2 attribute names are defined to be
+ compatible with LDAPv3, SLP attributes map directly into LDAP
+ attributes with no change. Similarly, LDAP attributes map directly
+ to SLP attributes.
+
+ Attribute Type - The SLP attribute type is mapped into the LDAP
+ attribute type.
+
+ Attribute Flags - The SLP attribute flags are mapped into
+ characteristics of the LDAP attribute definition, or into the DESC
+ field if no equivalent LDAP attribute definition characteristic
+ occurs.
+
+ Default and Allowed Values - These must be handled by the client
+ or a DA enabled to handle templates, as in SLP. For reference,
+ however, they should be included in the DESC field of the LDAP
+ attribute definition.
+
+ Descriptive Text - The SLP template descriptive text should be
+ mapped into the DESC field.
+
+ We discuss mapping of types, flags, default and allowed values, and
+ descriptive text in the subsections below.
+
+ OIDs for SLP template conversion schema elements are standardized
+ under the enterprise number of SrvLoc.Org (6252) [18].
+
+ For purposes of representing an SLP entry, we also define two
+ standardized LDAP syntaxes and attributes with standardized OIDs.
+
+ ( 1.3.6.1.4.1.6252.2.27.6.2.2
+ DESC 'SLP Service Type'
+ )
+
+ Defines the syntax for the service type name. The syntax is defined
+ in the BNF for the service URL in RFC 2609 Section 2.1 [1].
+
+ ( 1.3.6.1.4.1.6252.2.27.6.2.3
+ DESC 'SLP Scope'
+ )
+
+ Defines the syntax for the scope name. The syntax is defined in the
+ BNF for scope names in RFC 2608 Section 6.4.1 [5].
+
+
+
+
+Kempf, et al. Informational [Page 6]
+
+RFC 2926 Conversion of LDAP Schemas September 2000
+
+
+ ( 1.3.6.1.4.1.6252.2.27.6.1.4
+ NAME 'service-advert-service-type'
+ DESC 'The service type of the service advertisement, including
+ the "service:" prefix.'
+ EQUALITY caseExactIA5Match
+ SYNTAX 1.3.6.1.4.1.6252.2.27.6.2.2
+ SINGLE-VALUE
+ )
+
+ Defines an attribute for the service type name.
+
+ ( 1.3.6.1.4.1.6252.2.27.6.1.5
+ NAME 'service-advert-scopes'
+ DESC 'A list of scopes for a service advertisement.'
+ EQUALITY caseExactIA5Match
+ SYNTAX 1.3.6.1.4.1.6252.2.27.6.2.3
+ )
+
+ Defines a multivalued attribute for the scopes.
+
+ Searches for abstract types can be made with an LDAP query that
+ wildcards the concrete type. For example, a search for all service
+ advertisements of the printer abstract type can be made with the
+ following query:
+
+ (service-advert-service-type=service:printer:*)
+
+ SLP specifies that service URLs and attribute lists can be
+ accompanied by a structured authenticator consisting of a digital
+ signature and information necessary to verify the signature. A
+ syntax and two standardized SLP attributes are defined for this
+ purpose:
+
+ ( 1.3.6.1.4.1.6252.2.27.6.2.3 DESC 'SLP Authenticator')
+
+ The syntax of an SLP authenticator is the bytes of the
+ authenticator in network byte order, see RFC 2608, Section 9.2
+ [5].
+
+ ( 1.3.6.1.4.1.6252.2.27.6.1.6
+ NAME 'service-advert-url-authenticator'
+ DESC 'The authenticator for the URL, null if none.'
+ SYNTAX 1.3.6.1.4.1.6252.2.27.6.2.3
+ SINGLE-VALUE
+ )
+
+ This attribute contains the SLP URL authenticator, as defined in
+ RFC 2608, Section 9.2 [5].
+
+
+
+Kempf, et al. Informational [Page 7]
+
+RFC 2926 Conversion of LDAP Schemas September 2000
+
+
+ ( 1.3.6.1.4.1.6252.2.27.6.1.7
+ NAME 'service-advert-attribute-authenticator'
+ DESC 'The authenticator for the attribute list, null if none.'
+ SYNTAX 1.3.6.1.4.1.6252.2.27.6.2.3
+ SINGLE_VALUE
+ )
+
+ This attribute contains the SLP attribute authenticator, as
+ defined in RFC 2608, Section 9.2 [5].
+
+2.1 Mapping from SLP Attribute Types to LDAP Attribute Types
+
+ We define the mapping from SLP attribute types to LDAP as follows:
+
+ SLP Type ASN.1 Type LDAP Type
+ ---------------------------------------------------
+ Integer INTEGER INTEGER
+ String DirectoryString Directory String
+ Boolean BOOLEAN Boolean
+ Opaque OCTET STRING Octet String
+ Keyword (N/A) IA5 String
+
+ The following subsections discuss further details of the mapping.
+
+2.1.1 Integer
+
+ SLP integers compare as integers when performing a query. LDAP
+ integers behave similarly. Consequently, the mapping from the SLP
+ integer type to LDAP is INTEGER, with the integerMatch matching rule.
+
+2.1.2 String
+
+ SLP strings are encoded as described in the SLP protocol
+ specification [5]. All value strings are considered case insensitive
+ for matching operations. SLP strings are not null terminated and are
+ encoded in UTF-8.
+
+ SLP strings are mapped to the LDAP Directory String type. The
+ Directory String type exactly matches the SLP string type, i.e. it is
+ a non-null terminated UTF-8 string. The caseIgnoreMatch equality
+ rule, caseIgnoreOrderingMatch ordering rule, and
+ caseIgnoreSubstringsMatch substring rule are used for comparing
+ string attribute values.
+
+
+
+
+
+
+
+
+Kempf, et al. Informational [Page 8]
+
+RFC 2926 Conversion of LDAP Schemas September 2000
+
+
+2.1.3 Boolean
+
+ Boolean attributes may have one of two possible values. In SLP,
+ these values are represented as strings, TRUE and FALSE. In SLP's
+ string encoding of a boolean value, case does not matter.
+
+ The SLP Boolean type maps directly into an LDAP BOOLEAN. The
+ caseIgnoreMatch rule is used for equality matching.
+
+2.1.4 Opaque
+
+ SLP attribute values of type Opaque are represented as OCTET STRING
+ in LDAP, and the octetStringMatch matching rule is used to compare
+ them.
+
+2.2 Keyword Attributes
+
+ SLP service type templates allow the definition of keyword
+ attributes. Keyword attributes are attributes whose only
+ characteristic is their presence. Keyword attributes have no flag
+ information, nor any default or allowed values (since, by definition,
+ they have no values).
+
+ ASN.1 has no concept of keyword attributes. Keyword attributes are
+ translated into a "May" clause in the ASN.1 class definition for the
+ service type. If the keyword attribute is present, then its value is
+ of no consequence, but for consistency we make it simply the NUL
+ character, "\00".
+
+2.3 Template Flags
+
+ SLP template flags can be handled as described in the following
+ subsections.
+
+2.3.1 Multi-valued
+
+ Multi-valued attributes are defined in an SLP template using the one
+ value. All values for a given attribute must be of the same type.
+
+ LDAP attribute definitions require that a single valued attribute
+ include the SINGLE-VALUE tag if the attribute is single valued.
+ Otherwise, the attribute is assumed to be multivalued by default.
+
+
+
+
+
+
+
+
+
+Kempf, et al. Informational [Page 9]
+
+RFC 2926 Conversion of LDAP Schemas September 2000
+
+
+2.3.2 Optional
+
+ SLP uses the 'O' flag to indicate an attribute may or may not be
+ present. These optional attributes are defined using the "May"
+ clause in the ASN.1 definition class definition for the service type.
+ All other attributes must be defined as a "Must".
+
+2.3.3 Literal
+
+ ASN.1 does not have a mechanism to indicate that the values of an
+ attribute may not be translated from one language to another, since
+ ASN.1 schema are not typically translated. This flag is dropped when
+ translating a template, but presence of the flag should be noted in
+ the DESC field. It should be placed on a separate line and tagged
+ with "Literal:" so the template can be reconstructed from the schema.
+
+2.3.4 Explicit Matching
+
+ The SLP template syntax uses a flag of 'X' to indicate that an
+ attribute must be present in order for the query to be properly
+ satisfied. There is no provision for requiring that particular
+ attributes be in a query. Consequently, this flag is dropped when
+ translating a template, but presence of the flag should be noted in
+ the DESC field. It should be placed on a separate line and tagged
+ with "Explicit:" so the template can be reconstructed from the
+ schema.
+
+2.4 Default and Allowed Value Lists
+
+ The SLP template grammar provides the capability to define default
+ and allowed values for an attribute. The SLP protocol does not
+ enforce these restrictions on registered attributes, however. The
+ default and allowed values may be used by client side applications,
+ or alternatively it may also be used by DAs to initialize
+ registrations having no attributes and to limit attribute values to
+ the template allowed values.
+
+ LDAP servers also do not support default and allowed values on
+ attributes. Therefore, enforcement of default and allowed values in
+ SLP templates is left up to the clients or a DA, if the DA is
+ backending into LDAP. The default and allowed values should be
+ included in the DESC field. The comments should be placed on separate
+ lines and labeled with the "Default:" and "Allowed:" tags to allow
+ reconstruction of the template.
+
+
+
+
+
+
+
+Kempf, et al. Informational [Page 10]
+
+RFC 2926 Conversion of LDAP Schemas September 2000
+
+
+2.5 Descriptive Text
+
+ The descriptive text associated with an attribute definition should
+ be included in the DESC field. It should start on a separate line and
+ begin with the "Description:" tag.
+
+2.6 Generating LDAP Attribute OIDs
+
+ LDAP attributes require an OID. In general, there is no a priori way
+ that an algorithm can be defined for generating OIDs, because it will
+ depend on the conventions used by the organization developing the
+ template. In some cases, an organization's procedure for generating
+ OIDs may be regular enough that a template developer can
+ algorithmically generate OIDs off of an assigned root. Whatever means
+ is used, the template developer should assure that unique OIDs are
+ assigned to each SLP attribute that is translated into an LDAP
+ attribute.
+
+2.7 Example
+
+ The template included below is a hypothetical abstract printer
+ service template, similar to that described in [10].
+
+ template-type = printer
+
+ template-version = 0.0
+
+ template-description =
+ The printer service template describes the attributes supported by
+ network printing devices. Devices may be either directly
+ connected to a network, or connected to a printer spooler that
+ understands the a network queuing protocol such as IPP, lpr or the
+ Salutation Architecture.
+
+ template-url-syntax =
+ ;The URL syntax is specific to the printing protocol being
+ ;employed
+
+ description = STRING
+ # This attribute is a free form string that can contain any
+ # site-specific descriptive information about this printer.
+
+ printer-security-mechanisms-supported = STRING L M
+ none
+ # This attribute indicates the security mechanisms supported
+ tls, ssl, http-basic, http-digest, none
+
+
+
+
+
+Kempf, et al. Informational [Page 11]
+
+RFC 2926 Conversion of LDAP Schemas September 2000
+
+
+ printer-operator = STRING O L M
+ # A person, or persons responsible for maintaining a
+ # printer on a day-to-day basis, including such tasks
+ # as filling empty media trays, emptying full output
+ # trays, replacing toner cartridges, clearing simple
+ # paper jams, etc.
+
+ printer-location-address = STRING O
+ # Physical/Postal address for this device. Useful for
+ # nailing down a group of printers in a very large corporate
+ # network. For example: 960 Main Street, San Jose, CA 95130
+
+ printer-priority-queue = BOOLEAN O
+ FALSE
+ # TRUE indicates this printer or print queue is a priority
+ # queuing device.
+
+ printer-number-up = INTEGER O
+ 1
+ # This job attribute specifies the number of source
+ # page-images to impose upon a single side of an instance
+ # of a selected medium.
+ 1, 2, 4
+
+ printer-paper-output = STRING M L O
+ standard
+ # This attribute describes the mode in which pages output
+ # are arranged.
+
+ standard, noncollated sort, collated sort, stack, unknown
+
+ We assume that the concrete type "service:printer:lpr" for printers
+ that speak the LPR protocol [4] has the following template
+ definition:
+
+ template-type = printer:lpr
+
+ template-version = 0.0
+
+ template-description =
+ The printer:lpr service template describes the attributes
+ supported by network printing devices that speak the
+ LPR protocol. No new attributes are included.
+
+ template-url-syntax = queue
+ queue = ;The queue name, see RFC 1179.
+
+
+
+
+
+Kempf, et al. Informational [Page 12]
+
+RFC 2926 Conversion of LDAP Schemas September 2000
+
+
+ The LDAP class definition for the "service:printer:lpr" concrete
+ service type is translated as follows:
+
+ ( ---place the assigned OID here---
+ NAME 'service-printer-lpr'
+ DESC 'Description: The printer:lpr service template
+ describes the attributes supported by network printing
+ devices that speak the LPR protocol. No new attributes
+ are included.
+
+ URL Syntax: queue
+ queue = ;The queue name, see RFC 1179.'
+ SUP slpService
+ MUST ( description $ security-mechanisms-supported $
+ labeledURI)
+ MAY ( operator $ location-address $ priority-queue $
+ number-up $ paper-output)
+ )
+
+ The attribute definitions are translated as follows:
+
+ ( ---place the assigned OID here---
+ NAME 'printer-security-mechanisms-supported'
+ DESC 'Description: This attribute indicates the security mechanisms
+ supported.
+
+ Default: value
+
+ Allowed: tls, ssl, http-basic, http-digest, none
+
+ Literal:'
+ EQUALITY caseIgnoreMatch
+ ORDERING caseIgnoreOrderingMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ )
+
+ ( ---place the assigned OID here---
+ NAME 'printer-operator'
+ DESC 'Description: A person, or persons responsible for
+ maintaining a printer on a day-to-day basis, including
+ such tasks as filling empty media trays, emptying full
+ output trays, replacing toner cartridges, clearing simple
+ paper jams, etc.
+
+
+
+
+
+
+
+Kempf, et al. Informational [Page 13]
+
+RFC 2926 Conversion of LDAP Schemas September 2000
+
+
+ Literal:'
+ EQUALITY caseIgnoreMatch
+ ORDERING caseIgnoreOrderingMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ )
+
+ ( --place the assigned OID here---
+ NAME 'printer-location-address'
+ DESC 'Description Physical/Postal address for this device.
+ Useful for nailing down a group of printers in a very
+ large corporate network. For example: 960 Main Street,
+ San Jose, CA 95130.'
+ EQUALITY caseIgnoreMatch
+ ORDERING caseIgnoreOrderingMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ SINGLE-VALUE
+ )
+
+ ( ---place the assigned OID here---
+ NAME 'printer-priority-queue'
+ DESC 'Description: TRUE indicates this printer or print
+ queue is a priority queuing device.'
+ EQUALITY booleanMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
+ SINGLE-VALUE
+ )
+
+ ( ---place the assigned OID here---
+ NAME 'printer-number-up'
+ DESC 'Description: This job attribute specifies the number
+ of source page-images to impose upon a single side of
+ an instance of a selected medium. This attribute is
+ INTEGER.
+
+ Default: 1
+
+ Allowed: 1, 2, 3, 4'
+ EQUALITY integerMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
+ SINGLE-VALUE
+ )
+
+
+
+
+
+
+
+
+Kempf, et al. Informational [Page 14]
+
+RFC 2926 Conversion of LDAP Schemas September 2000
+
+
+ ( ---place the assigned OID here---
+ NAME 'printer-paper-output'
+ DESC 'Description: This attribute describes the mode in
+ which pages output are arranged. Default value is
+ standard.
+
+ Default: standard
+
+ Allowed: standard, noncollated sort, collated sort,
+ stack, unknown.
+ Literal:'
+ EQUALITY caseIgnoreMatch
+ ORDERING caseIgnoreOrderingMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ )
+
+3.0 Attribute Name Conflicts
+
+ LDAP has a flat name space, and attribute names and OIDs must be
+ unique in a directory server. In order to avoid name conflicts in the
+ translation of SLP templates to LDAP schemas, template developers may
+ want to consider prepending the name of the service type to the
+ attribute. Postprocessing attribute names to make them unique when
+ translated is not possible, because it would require the DA to
+ rewrite queries before submitting them to the directory server. In
+ addition, developers should use standard LDAP attributes when such
+ attributes are available.
+
+ In the above example template, the abstract type name "printer" is
+ prepended to attributes to avoid conflicts. The standard
+ "description" attribute defined by X.520 [3] is used to translate the
+ template description attribute.
+
+4.0 Mapping from Schema to Templates
+
+ The reverse mapping from LDAP schema to SLP service type templates
+ requires dealing with both LDAP and ASN.1 data types. RFC 2252
+ defines 33 attribute syntaxes that should be supported by LDAP
+ directory servers. These syntaxes are defined using BNF for strings
+ or using ASN.1 for binary valued attributes defined by X.520.
+
+ Mapping of the LDAP data types into SLP template types is fairly
+ straightforward, but mapping arbitrary ASN.1 data types is somewhat
+ more complicated and requires encoding the ASN.1 data type into a
+ string. To a certain extent, this masks the ASN.1 data type because
+ it becomes impossible to distinguish between a native string having
+
+
+
+
+Kempf, et al. Informational [Page 15]
+
+RFC 2926 Conversion of LDAP Schemas September 2000
+
+
+ content equivalent to an encoded ASN.1 string. However, inclusion of
+ the ASN.1 data type in the comment provides additional information
+ should a reverse transformation from SLP to ASN.1 be required.
+
+ The following subsections deal with both LDAP and ASN.1 attribute
+ data type mappings.
+
+4.1 Mapping LDAP Attribute Syntaxes to SLP Attribute Types
+
+ The following table contains the mappings for LDAP syntaxes to SLP
+ data types:
+
+ LDAP Type SLP Type
+ --------------------------------------------------------
+ ACI Item NA
+ Access Point NA
+ Attribute Type Description NA
+ Audio Opaque
+ Binary ASN.1 escape
+ Bit String String
+ Boolean Boolean
+ Certificate Opaque
+ Certificate List Opaque
+ Certificate Pair Opaque
+ Country String String
+ DN String
+ Data Quality Syntax NA
+ Delivery Method NA
+ Directory String String
+ DIT Content Rule Description NA
+ DIT Structure Rule Description NA
+ DL Submit Permission NA
+ DSA Quality Syntax NA
+ Enhanced Guide NA
+ Facsimile Telephone Number String
+ Fax Opaque
+ Generalized Time String
+ Guide NA
+ IA5 String String
+ INTEGER Integer
+ JPEG Opaque
+ LDAP Syntax Description NA
+ LDAP Schema Definition NA
+ LDAP Schema Description NA
+ Master and Shadow Access Points NA
+ Matching Rule Description NA
+ Matching Rule Use Description NA
+ Mail Preference NA
+
+
+
+Kempf, et al. Informational [Page 16]
+
+RFC 2926 Conversion of LDAP Schemas September 2000
+
+
+ MHS OR Address String
+ Modify Rights NA
+ Name and Optional UID NA
+ Name Form Description NA
+ Numeric String String
+ Object Class Description NA
+ Octet String Opaque
+ OID String
+ Other Mailbox String
+ Postal Address String
+ Protocol Information NA
+ Presentation Address String
+ Printable String String
+ Substring Assertion NA
+ Subtree Specification NA
+ Supplier Information NA
+ Supplier or Consumer NA
+ Supplier And Consumer NA
+ Supported Algorithm NA
+ DSE Type NA
+ Telephone Number String
+ Teletex Terminal Identifier String
+ Telex Number String
+ UTC Time String
+
+4.2 Mapping ASN.1 Types to SLP Types
+
+ ASN.1 employs a much richer set of data types than provided by SLP.
+ The table below show the mapping of selected ASN.1 data type to their
+ nearest SLP equivalent. Because of the complexity and flexibility of
+ ASN.1, a complete list cannot be provided.
+
+ As sample of some ASN.1 encodings and their mappings to SLP:
+
+ ASN.1 type SLP type
+ -----------------------------------------
+ INTEGER Integer
+ BOOLEAN Boolean
+ ENUMERATED String
+ OBJECT IDENTIFIER String
+ OCTET STRING Opaque
+ REAL String
+
+ Data types that do not map directly to SLP data types should be
+ defined as either a String, or as Opaque. ASN.1 types that may only
+ contain valid characters for Strings, as defined in X.680 [9] should
+ be encoded as strings. ASN.1 types such as GraphicString that change
+ their character set encoding in part way through a value should not
+
+
+
+Kempf, et al. Informational [Page 17]
+
+RFC 2926 Conversion of LDAP Schemas September 2000
+
+
+ be encoded as strings, however, If such types are required, the SLP
+ Opaque type should be used. In either case, the first line of the
+ help text is used to indicate the original ASN.1 data type.
+
+ The following subsections describe how to convert from the ASN.1 BER
+ [9] to the SLP template for the different types in the table above.
+
+4.2.1 Integer
+
+ Both SLP templates and ASN.1 support Integers, so there is a one to
+ one mapping between an SLP Integer attribute and an ASN.1 Integer
+ attribute. Details on the encoding of integers is summarized in the
+ SLP template to ASN.1 section above.
+
+4.2.2 Boolean
+
+ Boolean values are supported by both SLP and ASN.1, though on wire
+ encodings differ. X.680 [9] specifies zero and non-zero encoding for
+ booleans, where SLP encodes booleans using the strings TRUE and
+ FALSE. In general, most LDAP servers will use the LDAP Boolean type
+ (which is a string), so again the ASN.1 type should be recorded in
+ the comment or it will be lost.
+
+4.2.3 Enumerated
+
+ SLP templates support the concept of enumerations through the listing
+ of allowed values in the attribute definition. These enumerations
+ are not strictly binding on clients or DAs, but they are similar to
+ the ASN.1 definition of enumerations. BER encodes the ASN.1
+ enumeration by passing the number of the element's position in the
+ enumeration. This requires both sides to have knowledge of the
+ specific enumeration prior to decoding an enumeration's value. SLP
+ provides no specific support for transmitting enumerations. They are
+ simply String types. Information on the ASN.1 type and ASN.1 encoding
+ of the enumeration values is recorded in the comment.
+
+ Example:
+
+ color-supported = STRING M
+ none
+ # ASN.1: Enumeration.
+ # ASN.1 Mapping: none = 0, highlight = 1, three color = 2,
+ # four color = 4, monochromatic = 5
+ #This attribute specifies whether the Printer supports
+ # color and, if so, what type.
+ none,highlight,three color,four color,monochromatic
+
+
+
+
+
+Kempf, et al. Informational [Page 18]
+
+RFC 2926 Conversion of LDAP Schemas September 2000
+
+
+4.2.4 Object Identifier
+
+ Object identifiers(OIDs) are commonly used in the ASN.1 world to
+ identify object and attributes. OIDs are a numerical representation
+ of an element's place in the naming hierarchy. Each element at a
+ particular level of a hierarchy has a unique number assigned within
+ that level of the hierarchy. A sample OID would be the naming tree
+ for SNMP MIBs: iso(1) org(3) dod(6) internet(1) mgmt(2) mib(1) would
+ be written as the string "1.3.6.1.2.1".
+
+ Because this representation reduces down to a string of dot separated
+ numbers, this maps easily to the SLP String type. The help text for
+ this element should indicate it is an ASN.1 OID
+
+ identifier = STRING
+ # ASN.1: OID
+ # The object identifier for this SNMP agent.
+
+4.2.5 Octet String
+
+ An ASN.1 octet string should be mapped to an Opaque in an SLP
+ template. An octet string is a sequence of bytes, whereas an Opaque
+ is a a string that encodes a sequence of bytes. Again, the ASN.1 type
+ is lost unless recorded in the comment.
+
+4.2.6 Real
+
+ There is no direct mapping between floating point numbers and any SLP
+ data types. Attributes having the ASN.1 type of Real are mapped to
+ SLP type String. Comments are added to the attribute help text
+ indicating the value was originally an ASN.1 real. For example:
+
+ weight = STRING
+ # ASN.1: Real
+ # The objects weight in pounds.
+
+4.3 Example ASN.1 Schema
+
+ The following is an example schema for an exported filesystem. The
+ section presents it as in ASN.1 and the following section shows the
+ SLP template translation. The template translation does not capture
+ the actual attribute format for the Set type, that would be done in
+ the LDAP client software making the translation. Note that even
+ though the class definition does not conform with the previously
+ defined conventions for SLP classes, the schema can still be
+ translated into an SLP template. The syntax used in this example
+ follows
+
+
+
+
+Kempf, et al. Informational [Page 19]
+
+RFC 2926 Conversion of LDAP Schemas September 2000
+
+
+ -- Abstraction of a fstab entry (a "mount").
+ -- These lookups would likely be performed by an
+ -- an automounter type application.
+ mount OBJECT-CLASS ::= {
+ SUBCLASS OF { top }
+ MUST CONTAIN { mountHost |
+ mountDirectory |
+ mountType
+ }
+ MAY CONTAIN { mountOption |
+ mountDumpFrequency |
+ mountPassNo
+ }
+ ID { <oid1> }
+ }
+
+
+ - The mount host.
+ mountHost ATTRIBUTE ::= {
+ WITH SYNTAX caseIgnoreString
+ EQUALITY MATCHING RULE caseIgnoreMatch
+ SINGLE VALUE
+ ID { <oid2> }
+ }
+
+
+ - The file system to mount.
+ mountDirectory ATTRIBUTE ::= {
+ WITH SYNTAX caseIgnoreString
+ EQUALITY MATCHING RULE caseIgnoreMatch
+ SINGLE VALUE
+ ID { <oid3> }
+ }
+
+ - The type of file system being mounted.
+ mountType ATTRIBUTE ::= {
+ WITH SYNTAX INTEGER { ufs(1),
+ hsfs(2),
+ nfs(3),
+ rfs(4)
+ }
+ EQUALITY MATCHING RULE integerMatch
+ SINGLE VALUE
+ ID { <oid4> }
+ }
+
+
+
+
+
+
+Kempf, et al. Informational [Page 20]
+
+RFC 2926 Conversion of LDAP Schemas September 2000
+
+
+ - Options for the mount operation.
+ mountOption ATTRIBUTE ::= {
+ WITH SYNTAX caseIgnoreString
+ EQUALITY MATCHING RULE caseIgnoreString
+ ID { <oid5> }
+ }
+
+
+ - How often to dump the file system.
+ mountDumpFrequency ATTRIBUTE :: = {
+ WITH SYNTAX INTEGER (0..9)
+ EQUALITY MATCHING RULE integerMatch
+ SINGLE VALUE
+ ID { <oid6> }
+ }
+
+ - Boot time mount pass number.
+ mountPassNo ATTRIBUTE ::= {
+ WITH SYNTAX INTEGER
+ EQUALITY MATCHING RULE integerMatch
+ SINGLE VALUE
+ ID { <oid7> }
+ }
+
+ The translated SLP template is:
+
+ template-type = mount
+
+ template-version = 1.0
+
+ template-description = "Describes a remote filesystem access
+ protocol"
+
+ template-url-syntax =
+ filesystem = 1*[ DIGIT / ALPHA ]
+ urlpath = "/" filesystem
+
+ mountHost = STRING L
+ # ASN.1: Case Ignore String, Single Value
+ # The mount host
+
+ mountDirectory = STRING L
+ # ASN.1: Case Ignore String, Single Value
+ # The filesystem to mount
+
+
+
+
+
+
+
+Kempf, et al. Informational [Page 21]
+
+RFC 2926 Conversion of LDAP Schemas September 2000
+
+
+ mountType = STRING L
+ ufs
+ # ASN.1: Enumeration, Single Value
+ # ASN.1 Mapping: ufs = 1, hsfs = 2, nfs = 3, rfs = 4
+ # The type of the filesystem being mounted
+ ufs, hsfs, nfs, rfs
+
+ mountOption = STRING M O L
+ # ASN.1: Case Ignore String
+ # mount options for this filesystem
+
+ mountDumpFrequency = INTEGER O
+ 0
+ # ASN.1: Integer Range, Single Value
+ # How often to dump this filesystem
+ 0, 1, 2, 3, 4, 5, 6, 7, 8, 9
+
+ mountPassNo = INTEGER O
+ # ASN.1: Integer, Single Value
+ # Boot time mount pass number
+
+5.0 Representing SLP Service Advertisements in an LDAP DIT
+
+ In addition to translating between SLP templates and LDAP schema,
+ another area requiring compatibility is the representation of SLP
+ service advertisements in an LDAP DIT. A standardized representation
+ for service information allows SLP DAs to store service
+ advertisements in LDAP, and for LDAP clients to query the DIT for
+ those services. Similarly, if LDAP clients represent service
+ information in the same form, SLP clients can benefit from
+ interoperability.
+
+ A service advertisement contains the service URL in a 'labeledURI'
+ attribute [11]. The labeledURI attribute in a service advertisement
+ should only contain the service URL for the service, with no
+ additional label. It is recommended that the labeledURI be used as
+ the RDN for the service object in the DIT.
+
+ Although service advertisements can appear anywhere within the DIT,
+ it is recommended that all services be stored under a single common
+ point, or root node, to facilitate searching in a domain. This allows
+ a client to search for all of advertisements of a particular service
+ type, say, for all printers. The recommended parent entry is one
+ named "ou=service" below the entry which is the representation of the
+ domain, as described in RFC 2247.
+
+
+
+
+
+
+Kempf, et al. Informational [Page 22]
+
+RFC 2926 Conversion of LDAP Schemas September 2000
+
+
+ For example, a printer service with labeledURI of
+ "service:lpr://printsrv/queue1" in the domain foobar.com advertised
+ in the LDAP server that holds the entry "dc=foobar,dc=com" tree has
+ the following DN:
+
+ "labeledURI=service:lpr://printsrv/queue1, ou=service, dc=foobar,
+ dc=com"
+
+ While this leads to a flat space of service storage, since SLP uses
+ search filters from LDAP for searches, these filters can be used for
+ one-level searches from the root node.
+
+ The following example illustrates how an advertisement having a
+ simple service type is represented. The advertisement (in conceptual
+ form) for a printer is:
+
+ Service Type: service:lpr://printsrv/queue1
+ Scopes: eng,corp
+ Attributes:
+ description = A general printer for all to use.
+ security-mechanisms-supported = none
+ Authentication: none
+
+ The RDN of the object is labeledURI=service:lpr://printsrv/queue1,
+ and the following LDAP search filter will return this object, along
+ with any others of the service type "service:lpr" that match the
+ other attributes:
+
+ (&(service-advert-service-type=service:lpr)
+ (service-advert-scopes=eng)
+ (service-advert-scopes=corp)
+ (description=A general printer for all to use.)
+ (security-mechanisms-supported=none))
+
+ Service advertisements in SLP also have a lease time associated with
+ them. In LDAP servers that support the extensions for dynamic
+ directory services [12], the service advertisement entry objectClass
+ should be extended with the dynamicObject class. This allows the
+ service advertisement to time out within the LDAP directory server.
+ If the LDAP directory server does not support the dynamic directory
+ services extension, then advertisement lease timeouts must be handled
+ by the SLP agent.
+
+ While the service advertisement schema outlined in this section is
+ primarily for SLP DAs that use LDAP as a backing store, if LDAP
+ agents register services using the same format, complete
+ interoperability with SLP is achieved.
+
+
+
+
+Kempf, et al. Informational [Page 23]
+
+RFC 2926 Conversion of LDAP Schemas September 2000
+
+
+6.0 Internationalization Considerations
+
+ SLP specifies that an RFC 1766 [13] language code accompanies every
+ service advertisement. Language codes for service advertisements in
+ LDAP must be represented according to RFC 2596 [14].
+
+ RFC 2596 prohibits language codes in DNs, and specifies that a
+ directory server which does not support language codes must treat an
+ attribute with a language code as an unrecognized attributes.
+ According to RFC 2596, language codes are appended to attribute names
+ with a semicolon (";"). For example, the following attribute/value
+ pair is in the German locale:
+
+ (address;lang-de=44 Bahnhofstrasse, 2365 Weibstadt, Deutschland)
+
+ An attribute with a language tag in a specific locale is considered a
+ separate attribute from attributes in other locales.
+
+ If the service advertisement is in the default SLP locale ("en", no
+ dialect), then the language code need not be appended to the
+ attribute name.
+
+ SLP queries in locales other than the default need not be rewritten
+ to include language tags before being submitted to the directory
+ server. RFC 2596 specifies that all entries that match are returned,
+ including those with language tags, without requiring the language
+ tags to be explicitly present in the query. The SLP DA can then
+ postprocess the result to select the entries from the required
+ locale.
+
+7.0 Security Considerations
+
+ SLP authenticators are stored with the service advertisement in the
+ DIT, as discussed in Section~7ef{slpdit}. LDAP clients need to use
+ LDAP authentication [15] to assure that they are connecting with a
+ secure server. In particular, SLP DAs that use LDAP as a back end
+ store and that implement SLP authentication MUST use LDAP
+ authentication to assure that the LDAP entries for their service
+ registrations are secure.
+
+Acknowledgements
+
+ Many thanks are due to Mark Wahl whose detailed and insightful
+ comments were instrumental in helping improve the technical accuracy
+ of this document with respect to LDAP.
+
+
+
+
+
+
+Kempf, et al. Informational [Page 24]
+
+RFC 2926 Conversion of LDAP Schemas September 2000
+
+
+8.0 References
+
+ [1] Guttman, E., Perkins, C. and J. Kempf, "Service Templates and
+ service: Schemes", RFC 2609, April 1999.
+
+ [2] Wahl, W., Howes, T. and S. Kille, "Lightweight Directory Access
+ Protocol (v3)", RFC 2251, December 1997.
+
+ [3] International Telecommunications Union. The Directory:Selected
+ Attribute Types. ITU Recommendation X.520. August, 1997.
+
+ [4] McLaughlin, L., "Line Printer Daemon Protocol, RFC 1179, August
+ 1990.
+
+ [5] Guttman, E., Perkins, C., Veizades, J. and M. Day, "Service
+ Location Protocol Version 2", RFC 2608, April 1999.
+
+ [6] Crocker, D. and P. Overell, "Augmented BNF for Syntax
+ Specifications: ABNF", RFC 2234, November 1997.
+
+ [7] Howes, T., "The String Representation of LDAP Search Filters",
+ RFC 2254, December 1997.
+
+ [8] Wahl, W., Coulbeck, A., Howe, T. and S. Kille, "Lightweight
+ Directory Access Protocol (v3): Attribute Syntax Definition",
+ RFC 2252, December 1997.
+
+ [9] ITU-T Rec. X.680. Abstract Syntax Notation One (ASN.1) -
+ Specification of Basic Notation. 1994.
+
+ [10] Fleming, P., Jones, K., Lewis, H., and McDonald, I., "Internet
+ Printing Protocol (IPP): LDAP Schema for Printer Services", Work
+ in Progress.
+
+ [11] Smith, M., "Definition of an X.500 Attribute Type and an Object
+ Class to Hold Uniform Resource Identifiers (URIs)", RFC 2079,
+ January 1997.
+
+ [12] Yaacovi, Y., Wahl, M. and T. Genovese, "Lightweight Directory
+ Access Protocol (v3): Extensions for Dynamic Directory
+ Services", RFC 2589, May 1999.
+
+ [13] Alvestrand, H., "Tags for the Identification of Languages", RFC
+ 1766, December 1997.
+
+ [14] Wahl, M. and T. Howes, "Use of Language Codes in LDAP", RFC
+ 2596, May 1999.
+
+
+
+
+Kempf, et al. Informational [Page 25]
+
+RFC 2926 Conversion of LDAP Schemas September 2000
+
+
+ [15] Wahl, M., Alvestrand, H., Hodges, J. and R. Morgan,
+ "Authentication Methods for LDAP", RFC 2829, May 2000.
+
+ [16] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement
+ Levels", BCP 14, RFC 2119, March 1997.
+
+ [17] Dubuisson, O. ASN.1: Communication between Heterogeneous
+ Systems. OSS Nokalva, 2000.
+
+ [18] http://www.srvloc.org
+
+9.0 Authors' Addresses
+
+ James Kempf
+ Sun Microsystems
+ 901 San Antonio Avenue
+ Palo Alto, CA 94303
+ USA
+
+ Phone: +1 650 786-5890
+ EMail: james.kempf at sun.com
+
+
+ Ryan Moats
+ Coreon, Inc.
+ 15621 Drexel Circle
+ Omaha, NE, 68135
+ USA
+
+ EMail: rmoats at coreon.net
+
+
+ Pete St. Pierre
+ Sun Microsystems
+ 901 San Antonio Avenue
+ Palo Alto, CA 94303
+ USA
+
+ Phone: +1 415 786-5790
+ EMail: Pete.StPierre at Eng.Sun.COM
+
+
+
+
+
+
+
+
+
+
+
+Kempf, et al. Informational [Page 26]
+
+RFC 2926 Conversion of LDAP Schemas September 2000
+
+
+10. Full Copyright Statement
+
+ Copyright (C) The Internet Society (2000). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kempf, et al. Informational [Page 27]
+
Added: openldap/vendor/openldap-release/doc/rfc/rfc3045.txt
===================================================================
--- openldap/vendor/openldap-release/doc/rfc/rfc3045.txt (rev 0)
+++ openldap/vendor/openldap-release/doc/rfc/rfc3045.txt 2007-09-15 10:38:52 UTC (rev 844)
@@ -0,0 +1,339 @@
+
+
+
+
+
+
+Network Working Group M. Meredith
+Request for Comments: 3045 Novell Inc.
+Category: Informational January 2001
+
+
+ Storing Vendor Information in the LDAP root DSE
+
+Status of this Memo
+
+ This memo provides information for the Internet community. It does
+ not specify an Internet standard of any kind. Distribution of this
+ memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2001). All Rights Reserved.
+
+Abstract
+
+ This document specifies two Lightweight Directory Access Protocol
+ (LDAP) attributes, vendorName and vendorVersion that MAY be included
+ in the root DSA-specific Entry (DSE) to advertise vendor-specific
+ information. These two attributes supplement the attributes defined
+ in section 3.4 of RFC 2251.
+
+ The information held in these attributes MAY be used for display and
+ informational purposes and MUST NOT be used for feature advertisement
+ or discovery.
+
+Conventions used in this document
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in [RFC2219]
+
+1. Overview
+
+ LDAP clients discover server-specific data--such as available
+ controls, extensions, etc.--by reading the root DSE. See section 3.4
+ of [RFC2251] for details.
+
+ For display, information, and limited function discovery, it is
+ desirable to be able to query an LDAP server to determine the vendor
+ name of that server and also to see what version of that vendor's
+ code is currently installed.
+
+
+
+
+
+
+Meredith Informational [Page 1]
+
+RFC 3045 LDAP Root DSE to Display Vendor Information January 2001
+
+
+1.1 Function discovery
+
+ There are many ways in which a particular version of a vendor's LDAP
+ server implementation may be functionally incomplete, or may contain
+ software anomalies. It is impossible to identify every known
+ shortcoming of an LDAP server with the given set of server data
+ advertisement attributes. Furthermore, often times, the anomalies of
+ an implementation are not found until after the implementation has
+ been distributed, deployed, and is in use.
+
+ The attributes defined in this document MAY be used by client
+ implementations in order to identify a particular server
+ implementation so that it can 'work around' such anomalies.
+
+ The attributes defined in this document MUST NOT be used to gather
+ information related to supported features of an LDAP implementation.
+ All LDAP features, mechanisms, and capabilities--if advertised--MUST
+ be advertised through other mechanisms, preferably advertisement
+ mechanisms defined in concert with said features, mechanisms, and
+ capabilities.
+
+2. Attribute Types
+
+ These attributes are an addition to the Server-specific Data
+ Requirements defined in section 3.4 of [RFC2251]. The associated
+ syntaxes are defined in section 4 of [RFC2252].
+
+ Servers MAY restrict access to vendorName or vendorVersion and
+ clients MUST NOT expect these attributes to be available.
+
+2.1 vendorName
+
+ This attribute contains a single string, which represents the name of
+ the LDAP server implementer.
+
+ All LDAP server implementations SHOULD maintain a vendorName, which
+ is generally the name of the company that wrote the LDAP Server code
+ like "Novell, Inc."
+
+ ( 1.3.6.1.1.4 NAME 'vendorName' EQUALITY
+ 1.3.6.1.4.1.1466.109.114.1 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ SINGLE-VALUE NO-USER-MODIFICATION USAGE dSAOperation )
+
+2.2 vendorVersion
+
+ This attribute contains a string which represents the version of the
+ LDAP server implementation.
+
+
+
+
+Meredith Informational [Page 2]
+
+RFC 3045 LDAP Root DSE to Display Vendor Information January 2001
+
+
+ All LDAP server implementations SHOULD maintain a vendorVersion.
+ Note that this value is typically a release value--comprised of a
+ string and/or a string of numbers--used by the developer of the LDAP
+ server product (as opposed to the supportedLDAPVersion, which
+ specifies the version of the LDAP protocol supported by this server).
+ This is single-valued so that it will only have one version value.
+ This string MUST be unique between two versions, but there are no
+ other syntactic restrictions on the value or the way it is formatted.
+
+ ( 1.3.6.1.1.5 NAME 'vendorVersion' EQUALITY
+ 1.3.6.1.4.1.1466.109.114.1 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ SINGLE-VALUE NO-USER-MODIFICATION USAGE dSAOperation )
+
+ The intent behind the equality match on vendorVersion is to not allow
+ a less than or greater than type of query. Say release "LDAPv3 8.0"
+ has a problem that is fixed in the next release "LDAPv3 8.5", but in
+ the mean time there is also an update release say version "LDAPv3
+ 8.01" that fixes the problem. This will hopefully stop the client
+ from saying it will not work with a version less than "LDAPv3 8.5"
+ when it would also work with "LDAPv3 8.01". With the equality match
+ the client would have to exactly match what it is looking for.
+
+3. Notes to Server Implementers
+
+ Server implementers may consider tying the vendorVersion attribute
+ value to the build mechanism so that it is automatically updated when
+ the version value changes.
+
+4. Notes to Client Developers
+
+ As mentioned in section 2.1, the use of vendorName and vendorVersion
+ MUST NOT be used to discover features.
+
+ It should be noted that an anomalies often on affect subset of
+ implementations reporting the same version information. Most
+ implementations support multiple platforms, have numerous
+ configuration options, and often support plug-ins.
+
+ Client implementations SHOULD be written in such a way as to accept
+ any value in the vendorName and vendorVersion attributes. If a
+ client implementation does not recognize the specific vendorName or
+ vendorVersion as one it recognizes, then for the purposes of 'working
+ around' anomalies, the client MUST assume that the server is complete
+ and correct. The client MUST work with implementations that do not
+ publish these attributes.
+
+
+
+
+
+
+Meredith Informational [Page 3]
+
+RFC 3045 LDAP Root DSE to Display Vendor Information January 2001
+
+
+5. Security Considerations
+
+ The vendorName and vendorVersion attributes are provided only as
+ display or informational mechanisms, or as anomaly identifying
+ mechanisms. Client and application implementers must consider that
+ the existence of a given value in the vendorName or vendorVersion
+ attribute is no guarantee that the server was actually built by the
+ asserted vendor or that its version is the asserted version and
+ should act accordingly.
+
+ Server implementers should be aware that this information could be
+ used to exploit a security hole a server provides either by feature
+ or flaw.
+
+6. IANA Considerations
+
+ This document seeks to create two attributes, vendorName and
+ vendorVersion, which the IANA will primarily be responsible. This is
+ a one time effort; there is no need for any recurring assignment
+ after this stage.
+
+7. References
+
+ [RFC2219] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
+ 3", BCP 9, RFC 2026, October 1996.
+
+ [RFC2251] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory
+ Access Protocol (v3)", RFC 2251, December 1997.
+
+ [RFC2252] Wahl, M., Coulbeck, A., Howes, T. and S. Kille,
+ "Lightweight Directory Access Protocol (v3): Attribute
+ Syntax Definitions", RFC 2252, December 1997.
+
+8. Acknowledgments
+
+ The author would like to thank the generous input and review by
+ individuals at Novell including but not limited to Jim Sermersheim,
+ Mark Hinckley, Renea Campbell, and Roger Harrison. Also IETF
+ contributors Kurt Zeilenga, Mark Smith, Mark Wahl, Peter Strong,
+ Thomas Salter, Gordon Good, Paul Leach, Helmut Volpers.
+
+
+
+
+
+
+
+
+Meredith Informational [Page 4]
+
+RFC 3045 LDAP Root DSE to Display Vendor Information January 2001
+
+
+9. Author's Address
+
+ Mark Meredith
+ Novell Inc.
+ 1800 S. Novell Place
+ Provo, UT 84606
+
+ Phone: 801-861-2645
+ EMail: mark_meredith at novell.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Meredith Informational [Page 5]
+
+RFC 3045 LDAP Root DSE to Display Vendor Information January 2001
+
+
+10. Full Copyright Statement
+
+ Copyright (C) The Internet Society (2001). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Meredith Informational [Page 6]
+
Added: openldap/vendor/openldap-release/doc/rfc/rfc3062.txt
===================================================================
--- openldap/vendor/openldap-release/doc/rfc/rfc3062.txt (rev 0)
+++ openldap/vendor/openldap-release/doc/rfc/rfc3062.txt 2007-09-15 10:38:52 UTC (rev 844)
@@ -0,0 +1,339 @@
+
+
+
+
+
+
+Network Working Group K. Zeilenga
+Request for Comments: 3062 OpenLDAP Foundation
+Category: Standards Track February 2001
+
+
+ LDAP Password Modify Extended Operation
+
+Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2001). All Rights Reserved.
+
+Abstract
+
+ The integration of the Lightweight Directory Access Protocol (LDAP)
+ and external authentication services has introduced non-DN
+ authentication identities and allowed for non-directory storage of
+ passwords. As such, mechanisms which update the directory (e.g.,
+ Modify) cannot be used to change a user's password. This document
+ describes an LDAP extended operation to allow modification of user
+ passwords which is not dependent upon the form of the authentication
+ identity nor the password storage mechanism used.
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY" in this document are
+ to be interpreted as described in RFC 2119.
+
+1. Background and Intent of Use
+
+ Lightweight Directory Access Protocol (LDAP) [RFC2251] is designed to
+ support an number of authentication mechanisms including simple user
+ name/password pairs. Traditionally, LDAP users where identified by
+ the Distinguished Name [RFC2253] of a directory entry and this entry
+ contained a userPassword [RFC2256] attribute containing one or more
+ passwords.
+
+ The protocol does not mandate that passwords associated with a user
+ be stored in the directory server. The server may use any attribute
+ suitable for password storage (e.g., userPassword), or use non-
+ directory storage.
+
+
+
+
+Zeilenga Standards Track [Page 1]
+
+RFC 3062 LDAP Password Modify Extended Operation February 2001
+
+
+ The integration [RFC2829] of application neutral SASL [RFC2222]
+ services which support simple username/password mechanisms (such as
+ DIGEST-MD5) has introduced non-LDAP DN authentication identity forms
+ and made storage of passwords the responsibility of the SASL service
+ provider.
+
+ LDAP update operations are designed to act upon attributes of an
+ entry within the directory. LDAP update operations cannot be used to
+ modify a user's password when the user is not represented by a DN,
+ does not have a entry, or when that password used by the server is
+ not stored as an attribute of an entry. An alternative mechanism is
+ needed.
+
+ This document describes an LDAP Extended Operation intended to allow
+ directory clients to update user passwords. The user may or may not
+ be associated with a directory entry. The user may or may not be
+ represented as an LDAP DN. The user's password may or may not be
+ stored in the directory.
+
+ The operation SHOULD NOT be used without adequate security protection
+ as the operation affords no privacy or integrity protect itself.
+ This operation SHALL NOT be used anonymously.
+
+2. Password Modify Request and Response
+
+ The Password Modify operation is an LDAPv3 Extended Operation
+ [RFC2251, Section 4.12] and is identified by the OBJECT IDENTIFIER
+ passwdModifyOID. This section details the syntax of the protocol
+ request and response.
+
+ passwdModifyOID OBJECT IDENTIFIER ::= 1.3.6.1.4.1.4203.1.11.1
+
+ PasswdModifyRequestValue ::= SEQUENCE {
+ userIdentity [0] OCTET STRING OPTIONAL
+ oldPasswd [1] OCTET STRING OPTIONAL
+ newPasswd [2] OCTET STRING OPTIONAL }
+
+ PasswdModifyResponseValue ::= SEQUENCE {
+ genPasswd [0] OCTET STRING OPTIONAL }
+
+2.1. Password Modify Request
+
+ A Password Modify request is an ExtendedRequest with the requestName
+ field containing passwdModifyOID OID and optionally provides a
+ requestValue field. If the requestValue field is provided, it SHALL
+ contain a PasswdModifyRequestValue with one or more fields present.
+
+
+
+
+
+Zeilenga Standards Track [Page 2]
+
+RFC 3062 LDAP Password Modify Extended Operation February 2001
+
+
+ The userIdentity field, if present, SHALL contain an octet string
+ representation of the user associated with the request. This string
+ may or may not be an LDAPDN [RFC2253]. If no userIdentity field is
+ present, the request acts up upon the password of the user currently
+ associated with the LDAP session.
+
+ The oldPasswd field, if present, SHALL contain the user's current
+ password.
+
+ The newPasswd field, if present, SHALL contain the desired password
+ for this user.
+
+2.2. Password Modify Response
+
+ A Password Modify response is an ExtendedResponse where the
+ responseName field is absent and the response field is optional. The
+ response field, if present, SHALL contain a PasswdModifyResponseValue
+ with genPasswd field present.
+
+ The genPasswd field, if present, SHALL contain a generated password
+ for the user.
+
+ If an resultCode other than success (0) is indicated in the response,
+ the response field MUST be absent.
+
+3. Operation Requirements
+
+ Clients SHOULD NOT submit a Password Modification request without
+ ensuring adequate security safeguards are in place. Servers SHOULD
+ return a non-success resultCode if sufficient security protection are
+ not in place.
+
+ Servers SHOULD indicate their support for this extended operation by
+ providing PasswdModifyOID 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 and/or has
+ established the necessary security protections to use this operation.
+ Clients SHOULD verify the server implements this extended operation
+ prior to attempting the operation by asserting the supportedExtension
+ attribute contains a value of PasswdModifyOID.
+
+ The server SHALL only return success upon successfully changing the
+ user's password. The server SHALL leave the password unmodified and
+ return a non-success resultCode otherwise.
+
+ If the server does not recognize provided fields or does not support
+ the combination of fields provided, it SHALL NOT change the user
+ password.
+
+
+
+Zeilenga Standards Track [Page 3]
+
+RFC 3062 LDAP Password Modify Extended Operation February 2001
+
+
+ If oldPasswd is present and the provided value cannot be verified or
+ is incorrect, the server SHALL NOT change the user password. If
+ oldPasswd is not present, the server MAY use other policy to
+ determine whether or not to change the password.
+
+ The server SHALL NOT generate a password on behalf of the client if
+ the client has provided a newPasswd. In absence of a client provided
+ newPasswd, the server SHALL either generate a password on behalf of
+ the client or return a non-success result code. The server MUST
+ provide the generated password upon success as the value of the
+ genPasswd field.
+
+ The server MAY return adminLimitExceeded, busy,
+ confidentialityRequired, operationsError, unavailable,
+ unwillingToPerform, or other non-success resultCode as appropriate to
+ indicate that it was unable to successfully complete the operation.
+
+ Servers MAY implement administrative policies which restrict this
+ operation.
+
+4. Security Considerations
+
+ This operation is used to modify user passwords. The operation
+ itself does not provide any security protection to ensure integrity
+ and/or confidentiality of the information. Use of this operation is
+ strongly discouraged when privacy protections are not in place to
+ guarantee confidentiality and may result in the disclosure of the
+ password to unauthorized parties. This extension MUST be used with
+ confidentiality protection, such as Start TLS [RFC 2830]. The NULL
+ cipher suite MUST NOT be used.
+
+5. Bibliography
+
+ [RFC2219] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2222] Myers, J., "Simple Authentication and Security Layer
+ (SASL)", RFC 2222, October 1997.
+
+ [RFC2251] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory
+ Access Protocol (v3)", RFC 2251, December 1997.
+
+ [RFC2252] Wahl, M., Coulbeck, A., Howes, T. and S. Kille,
+ "Lightweight Directory Access Protocol (v3): Attribute
+ Syntax Definitions", RFC 2252, December 1997.
+
+
+
+
+
+
+Zeilenga Standards Track [Page 4]
+
+RFC 3062 LDAP Password Modify Extended Operation February 2001
+
+
+ [RFC2253] Wahl, M., Kille,S. and T. Howes, "Lightweight Directory
+ Access Protocol (v3): UTF-8 String Representation of
+ Distinguished Names", RFC 2253, December 1997.
+
+ [RFC2256] Wahl, M., "A Summary of the X.500(96) User Schema for use
+ with LDAPv3", RFC 2256, December 1997.
+
+ [RFC2829] Wahl, M., Alvestrand, H., Hodges, J. and R. Morgan,
+ "Authentication Methods for LDAP", RFC 2829, May 2000.
+
+ [RFC2830] Hodges, J., Morgan, R. and M. Wahl, "Lightweight Directory
+ Access Protocol (v3): Extension for Transport Layer
+ Security", RFC 2830, May 2000.
+
+6. Acknowledgment
+
+ This document borrows from a number of IETF documents and is based
+ upon input from the IETF LDAPext working group.
+
+7. Author's Address
+
+ Kurt D. Zeilenga
+ OpenLDAP Foundation
+
+ EMail: Kurt at OpenLDAP.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 5]
+
+RFC 3062 LDAP Password Modify Extended Operation February 2001
+
+
+8. Full Copyright Statement
+
+ Copyright (C) The Internet Society (2001). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 6]
+
Added: openldap/vendor/openldap-release/doc/rfc/rfc3088.txt
===================================================================
--- openldap/vendor/openldap-release/doc/rfc/rfc3088.txt (rev 0)
+++ openldap/vendor/openldap-release/doc/rfc/rfc3088.txt 2007-09-15 10:38:52 UTC (rev 844)
@@ -0,0 +1,619 @@
+
+
+
+
+
+
+Network Working Group K. Zeilenga
+Request for Comments: 3088 OpenLDAP Foundation
+Category: Experimental April 2001
+
+
+ OpenLDAP Root Service
+ An experimental LDAP referral service
+
+Status of this Memo
+
+ This memo defines an Experimental Protocol for the Internet
+ community. It does not specify an Internet standard of any kind.
+ Discussion and suggestions for improvement are requested.
+ Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2001). All Rights Reserved.
+
+Abstract
+
+ The OpenLDAP Project is operating an experimental LDAP (Lightweight
+ Directory Access Protocol) referral service known as the "OpenLDAP
+ Root Service". The automated system generates referrals based upon
+ service location information published in DNS SRV RRs (Domain Name
+ System location of services resource records). This document
+ describes this service.
+
+1. Background
+
+ LDAP [RFC2251] directories use a hierarchical naming scheme inherited
+ from X.500 [X500]. Traditionally, X.500 deployments have used a
+ geo-political naming scheme (e.g., CN=Jane
+ Doe,OU=Engineering,O=Example,ST=CA,C=US). However, registration
+ infrastructure and location services in many portions of the naming
+ hierarchical are inadequate or nonexistent.
+
+ The construction of a global directory requires a robust registration
+ infrastructure and location service. Use of Internet domain-based
+ naming [RFC2247] (e.g., UID=jdoe,DC=eng,DC=example,DC=net) allows
+ LDAP directory services to leverage the existing DNS [RFC1034]
+ registration infrastructure and DNS SRV [RFC2782] resource records
+ can be used to locate services [LOCATE].
+
+
+
+
+
+
+
+
+Zeilenga Experimental [Page 1]
+
+RFC 3088 OpenLDAP Root Service April 2001
+
+
+1.1. The Glue
+
+ Most existing LDAP implementations do not support location of
+ directory services using DNS SRV resource records. However, most
+ servers support generation of referrals to "superior" server(s).
+ This service provides a "root" LDAP service which servers may use as
+ their superior referral service.
+
+ Client may also use the service directly to locate services
+ associated with an arbitrary Distinguished Name [RFC2253] within the
+ domain based hierarchy.
+
+ Notice:
+ The mechanisms used by service are experimental. The descriptions
+ provided by this document are not definitive. Definitive
+ mechanisms shall be published in a Standard Track document(s).
+
+2. Generating Referrals based upon DNS SRV RRs
+
+ This service returns referrals generated from DNS SRV resource
+ records [RFC2782].
+
+2.1. DN to Domain Name Mapping
+
+ The service maps a DN [RFC2253] to a fully qualified domain name
+ using the following algorithm:
+
+ domain = null;
+ foreach RDN left-to-right // [1]
+
+ {
+ if not multi-valued RDN and
+ RDN.type == domainComponent
+ {
+ if ( domain == null || domain == "." )
+ { // start
+ domain = "";
+ }
+ else
+ { // append separator
+ domain .= ".";
+ }
+
+ if ( RDN.value == "." )
+ { // root
+ domain = ".";
+ }
+ else
+
+
+
+Zeilenga Experimental [Page 2]
+
+RFC 3088 OpenLDAP Root Service April 2001
+
+
+ { // append domainComponent
+ domain .= RDN.value;
+ }
+ continue;
+ }
+ domain = null;
+ }
+
+ Examples:
+
+ Distinguished Name Domain
+ ----------------------------- ------------
+ DC=example,DC=net example.net
+ UID=jdoe,DC=example,DC=net example.net
+ DC=. . [2]
+ DC=example,DC=net,DC=. . [3]
+ DC=example,DC=.,DC=net net [4]
+ DC=example.net example.net [5]
+ CN=Jane Doe,O=example,C=US null
+ UID=jdoe,DC=example,C=US null
+ DC=example,O=example,DC=net net
+ DC=example+O=example,DC=net net
+ DC=example,C=US+DC=net null
+
+ Notes:
+
+ 0) A later incarnation will use a Standard Track mechanism.
+
+ 1) A later incarnation of this service may use a right-to-left
+ algorithm.
+
+ 2) RFC 2247 does not state how one can map the domain representing
+ the root of the domain tree to a DN. We suggest the root of the
+ domain tree be mapped to "DC=." and that this be reversable.
+
+ 3) RFC 2247 states that domain "example.net" should be mapped to the
+ DN "DC=example,DC=net", not to "DC=example,DC=net,DC=.". As it is
+ not our intent to introduce or support an alternative domain to DN
+ mapping, the algorithm ignores domainComponents to the left of
+ "DC=.".
+
+ 4) RFC 2247 states that domain "example.net" should be mapped to the
+ DN "DC=example,DC=net", not to "DC=example,DC=.,DC=net". As it is
+ not our intent to introduce or support an alternative domain to DN
+ mapping, the algorithm ignores domainComponents to the left of
+ "DC=." and "DC=." itself if further domainComponents are found to
+ the right.
+
+
+
+
+Zeilenga Experimental [Page 3]
+
+RFC 3088 OpenLDAP Root Service April 2001
+
+
+ 5) RFC 2247 states that value of an DC attribute type is a domain
+ component. It should not contain multiple domain components. A
+ later incarnation of this service may map this domain to null or
+ be coded to return invalid DN error.
+
+ If the domain is null or ".", the service aborts further processing
+ and returns noSuchObject. Later incarnation of this service may
+ abort processing if the resulting domain is a top-level domain.
+
+2.2. Locating LDAP services
+
+ The root service locates services associated with a given fully
+ qualified domain name by querying the Domain Name System for LDAP SRV
+ resource records. For the domain example.net, the service would do a
+ issue a SRV query for the domain "_ldap._tcp.example.net". A
+ successful query will return one or more resource records of the
+ form:
+
+ _ldap._tcp.example.net. IN SRV 0 0 389 ldap.example.net.
+
+ If no LDAP SRV resource records are returned or any DNS error occurs,
+ the service aborts further processing and returns noSuchObject.
+ Later incarnations of this service will better handle transient
+ errors.
+
+2.3. Constructing an LDAP Referrals
+
+ For each DNS SRV resource record returned for the domain, a LDAP URL
+ [RFC2255] is constructed. For the above resource record, the URL
+ would be:
+
+ ldap://ldap.example.net:389/
+
+ These URLs are then returned in the referral. The URLs are currently
+ returned in resolver order. That is, the server itself does not make
+ use of priority or weight information in the SRV resource records. A
+ later incarnation of this service may.
+
+3. Protocol Operations
+
+ This section describes how the service performs basic LDAP
+ operations. The service supports operations extended through certain
+ controls as described in a later section.
+
+
+
+
+
+
+
+
+Zeilenga Experimental [Page 4]
+
+RFC 3088 OpenLDAP Root Service April 2001
+
+
+3.1. Basic Operations
+
+ Basic (add, compare, delete, modify, rename, search) operations
+ return a referral result if the target (or base) DN can be mapped to
+ a set of LDAP URLs as described above. Otherwise a noSuchObject
+ response or other appropriate response is returned.
+
+3.2. Bind Operation
+
+ The service accepts "anonymous" bind specifying version 2 or version
+ 3 of the protocol. All other bind requests will return a non-
+ successful resultCode. In particular, clients which submit clear
+ text credentials will be sent an unwillingToPerform resultCode with a
+ cautionary text regarding providing passwords to strangers.
+
+ As this service is read-only, LDAPv3 authentication [RFC2829] is not
+ supported.
+
+3.3. Unbind Operations
+
+ Upon receipt of an unbind request, the server abandons all
+ outstanding requests made by client and disconnects.
+
+3.4. Extended Operations
+
+ The service currently does recognize any extended operation. Later
+ incarnations of the service may support Start TLS [RFC2830] and other
+ operations.
+
+3.5. Update Operations
+
+ A later incarnation of this service may return unwillingToPerform for
+ all update operations as this is an unauthenticated service.
+
+4. Controls
+
+ The service supports the ManageDSAit control. Unsupported controls
+ are serviced per RFC 2251.
+
+4.1. ManageDSAit Control
+
+ The server recognizes and honors the ManageDSAit control [NAMEDREF]
+ provided with operations.
+
+ If DNS location information is available for the base DN itself, the
+ service will return unwillingToPerform for non-search operations.
+ For search operations, an entry will be returned if within scope and
+ matches the provided filter. For example:
+
+
+
+Zeilenga Experimental [Page 5]
+
+RFC 3088 OpenLDAP Root Service April 2001
+
+
+ c: searchRequest {
+ base="DC=example,DC=net"
+ scope=base
+ filter=(objectClass=*)
+ ManageDSAit
+ }
+
+ s: searchEntry {
+ dn: DC=example,DC=net
+ objectClass: referral
+ objectClass: extensibleObject
+ dc: example
+ ref: ldap://ldap.example.net:389/
+ associatedDomain: example.net
+ }
+ s: searchResult {
+ success
+ }
+
+ If DNS location information is available for the DC portion of a
+ subordinate entry, the service will return noSuchObject with the
+ matchedDN set to the DC portion of the base for search and update
+ operations.
+
+ c: searchRequest {
+ base="CN=subordinate,DC=example,DC=net"
+ scope=base
+ filter=(objectClass=*)
+ ManageDSAit
+ }
+
+ s: searchResult {
+ noSuchObject
+ matchedDN="DC=example,DC=net"
+ }
+
+5. Using the Service
+
+ Servers may be configured to refer superior requests to
+ <ldap://root.openldap.org:389>.
+
+ Though clients may use the service directly, this is not encouraged.
+ Clients should use a local service and only use this service when
+ referred to it.
+
+ The service supports LDAPv3 and LDAPv2+ [LDAPv2+] clients over
+ TCP/IPv4. Future incarnations of this service may support TCP/IPv6
+ or other transport/internet protocols.
+
+
+
+Zeilenga Experimental [Page 6]
+
+RFC 3088 OpenLDAP Root Service April 2001
+
+
+6. Lessons Learned
+
+6.1. Scaling / Reliability
+
+ This service currently runs on a single host. This host and
+ associated network resources are not yet exhausted. If they do
+ become exhausted, we believe we can easily scale to meet the demand
+ through common distributed load balancing technics. The service can
+ also easily be duplicated locally.
+
+6.2. Protocol interoperability
+
+ This service has able avoided known interoperability issues in
+ supporting variants of LDAP.
+
+6.2.1. LDAPv3
+
+ The server implements all features of LDAPv3 [RFC2251] necessary to
+ provide the service.
+
+6.2.2. LDAPv2
+
+ LDAPv2 [RFC1777] does not support the return of referrals and hence
+ may not be referred to this service. Though a LDAPv2 client could
+ connect and issue requests to this service, the client would treat
+ any referral returned to it as an unknown error.
+
+6.2.3. LDAPv2+
+
+ LDAPv2+ [LDAPv2+] provides a number of extensions to LDAPv2,
+ including referrals. LDAPv2+, like LDAPv3, does not require a bind
+ operation before issuing of other operations. As the referral
+ representation differ between LDAPv2+ and LDAPv3, the service returns
+ LDAPv3 referrals in this case. However, as commonly deployed LDAPv2+
+ clients issue bind requests (for compatibility with LDAPv2 servers),
+ this has not generated any interoperability issues (yet).
+
+ A future incarnation of this service may drop support for LDAPv2+
+ (and LDAPv2).
+
+6.2.4. CLDAP
+
+ CLDAP [RFC1798] does not support the return of referrals and hence is
+ not supported.
+
+
+
+
+
+
+
+Zeilenga Experimental [Page 7]
+
+RFC 3088 OpenLDAP Root Service April 2001
+
+
+7. Security Considerations
+
+ This service provides information to "anonymous" clients. This
+ information is derived from the public directories, namely the Domain
+ Name System.
+
+ The use of authentication would require clients to disclose
+ information to the service. This would be an unnecessary invasion of
+ privacy.
+
+ The lack of encryption allows eavesdropping upon client requests and
+ responses. A later incarnation of this service may support
+ encryption (such as via Start TLS [RFC2830]).
+
+ Information integrity protection is not provided by the service. The
+ service is subject to varies forms of DNS spoofing and attacks. LDAP
+ session or operation integrity would provide false sense of security
+ concerning the integrity of DNS information. A later incarnation of
+ this service may support DNSSEC and provide integrity protection (via
+ SASL, TLS, or IPSEC).
+
+ The service is subject to a variety of denial of service attacks.
+ The service is capable of blocking access by a number of factors.
+ This capability have yet to be used and likely would be ineffective
+ in preventing sophisticated attacks. Later incarnations of this
+ service will likely need better protection from such attacks.
+
+8. Conclusions
+
+ DNS is good glue. By leveraging of the Domain Name System, global
+ LDAP directories may be built without requiring a protocol specific
+ registration infrastructures.
+
+ In addition, use of DNS service location allows global directories to
+ be built "ad hoc". That is, anyone with a domain name can
+ participate. There is no requirement that the superior domain
+ participate.
+
+9. Additional Information
+
+ Additional information about the OpenLDAP Project and the OpenLDAP
+ Root Service can be found at <http://www.openldap.org/>.
+
+
+
+
+
+
+
+
+
+Zeilenga Experimental [Page 8]
+
+RFC 3088 OpenLDAP Root Service April 2001
+
+
+10. Author's Address
+
+ Kurt Zeilenga
+ OpenLDAP Foundation
+
+ EMail: kurt at openldap.org
+
+11. Acknowledgments
+
+ Internet hosting for this experiment is provided by the Internet
+ Software Consortium <http://www.isc.org/>. Computing resources were
+ provided by Net Boolean Incorporated <http://www.boolean.net/>. This
+ experiment would not have been possible without the contributions of
+ numerous volunteers of the open source community. Mechanisms
+ described in this document are based upon those introduced in
+ [RFC2247] and [LOCATE].
+
+References
+
+ [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
+ STD 13, RFC 1034, November 1987.
+
+ [RFC1777] Yeong, W., Howes, T. and S. Kille, "Lightweight Directory
+ Access Protocol", RFC 1777, March 1995.
+
+ [RFC1798] Young, A., "Connection-less Lightweight Directory Access
+ Protocol", RFC 1798, June 1995.
+
+ [RFC2119] Bradner, S., "Key Words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2247] Kille, S., Wahl, M., Grimstad, A., Huber, R. and S.
+ Sataluri, "Using Domains in LDAP/X.500 Distinguished
+ Names", RFC 2247, January 1998.
+
+ [RFC2251] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory
+ Access Protocol (v3)", RFC 2251, December 1997.
+
+ [RFC2253] Wahl, M., Kille, S. and T. Howes, "Lightweight Directory
+ Access Protocol (v3): UTF-8 String Representation of
+ Distinguished Names", RFC 2253, December 1997.
+
+ [RFC2255] Howes, T. and M. Smith, "The LDAP URL Format", RFC 2255,
+ December 1997.
+
+ [RFC2782] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for
+ specifying the location of services (DNS SRV)", RFC 2782,
+ February 2000.
+
+
+
+Zeilenga Experimental [Page 9]
+
+RFC 3088 OpenLDAP Root Service April 2001
+
+
+ [RFC2829] Wahl, M., Alvestrand, H., Hodges, J. and R. Morgan,
+ "Authentication Methods for LDAP", RFC 2829, May 2000.
+
+ [RFC2830] Hodges, J., Morgan, R. and M. Wahl, "Lightweight Directory
+ Access Protocol (v3): Extension for Transport Layer
+ Security", RFC 2830, May 2000.
+
+ [LOCATE] IETF LDAPext WG, "Discovering LDAP Services with DNS",
+ Work in Progress.
+
+ [LDAPv2+] University of Michigan LDAP Team, "Referrals within the
+ LDAPv2 Protocol", August 1996.
+
+ [NAMEDREF] Zeilenga, K. (editor), "Named Subordinate References in
+ LDAP Directories", Work in Progress.
+
+ [X500] ITU-T Rec. X.500, "The Directory: Overview of Concepts,
+ Models and Service", 1993.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga Experimental [Page 10]
+
+RFC 3088 OpenLDAP Root Service April 2001
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2001). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga Experimental [Page 11]
+
Added: openldap/vendor/openldap-release/doc/rfc/rfc3112.txt
===================================================================
--- openldap/vendor/openldap-release/doc/rfc/rfc3112.txt (rev 0)
+++ openldap/vendor/openldap-release/doc/rfc/rfc3112.txt 2007-09-15 10:38:52 UTC (rev 844)
@@ -0,0 +1,507 @@
+
+
+
+
+
+
+Network Working Group K. Zeilenga
+Request for Comments: 3112 OpenLDAP Foundation
+Category: Informational May 2001
+
+
+ LDAP Authentication Password Schema
+
+Status of this Memo
+
+ This memo provides information for the Internet community. It does
+ not specify an Internet standard of any kind. Distribution of this
+ memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2001). All Rights Reserved.
+
+Abstract
+
+ This document describes schema in support of user/password
+ authentication in a LDAP (Lightweight Directory Access Protocol)
+ directory including the authPassword attribute type. This attribute
+ type holds values derived from the user's password(s) (commonly using
+ cryptographic strength one-way hash). authPassword is intended to
+ used instead of userPassword.
+
+1. Background and Intended Use
+
+ The userPassword attribute type [RFC2256] is intended to be used to
+ support the LDAP [RFC2251] "simple" bind operation. However, values
+ of userPassword must be clear text passwords. It is often desirable
+ to store values derived from the user's password(s) instead of actual
+ passwords.
+
+ The authPassword attribute type is intended to be used to store
+ information used to implement simple password based authentication.
+ The attribute type may be used by LDAP servers to implement the LDAP
+ Bind operation's "simple" authentication method.
+
+ The attribute type supports multiple storage schemes. A matching
+ rule is provided for use with extensible search filters to allow
+ clients to assert that a clear text password "matches" one of the
+ attribute's values.
+
+ Storage schemes often use cryptographic strength one-way hashing.
+ Though the use of one-way hashing reduces the potential that exposed
+ values will allow unauthorized access to the Directory (unless the
+
+
+
+
+Zeilenga Informational [Page 1]
+
+RFC 3112 LDAP Authentication Password Schema May 2001
+
+
+ hash algorithm/implementation is flawed), the hashing of passwords is
+ intended to be as an additional layer of protection. It is
+ RECOMMENDED that hashed values be protected as if they were clear
+ text passwords.
+
+ This attribute may be used in conjunction with server side password
+ generation mechanisms (such as the LDAP Password Modify [RFC3062]
+ extended operation).
+
+ Access to this attribute may governed by administrative controls such
+ as those which implement password change policies.
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY" in this document are
+ to be interpreted as described in RFC 2119 [RFC2119].
+
+2. Schema Definitions
+
+ The following schema definitions are described in terms of LDAPv3
+ Attribute Syntax Definitions [RFC2252] with specific syntax detailed
+ using Augmented BNF [RFC2234].
+
+2.1. authPasswordSyntax
+
+ ( 1.3.6.1.4.1.4203.1.1.2
+ DESC 'authentication password syntax' )
+
+ Values of this syntax are encoded according to:
+
+ authPasswordValue = w scheme s authInfo s authValue w
+ scheme = %x30-39 / %x41-5A / %x2D-2F / %x5F
+ ; 0-9, A-Z, "-", ".", "/", or "_"
+ authInfo = schemeSpecificValue
+ authValue = schemeSpecificValue
+ schemeSpecificValue = *( %x21-23 / %x25-7E )
+ ; printable ASCII less "$" and " "
+ s = w SEP w
+ w = *SP
+ SEP = %x24 ; "$"
+ SP = %x20 ; " " (space)
+
+ where scheme describes the mechanism and authInfo and authValue are a
+ scheme specific. The authInfo field is often a base64 encoded salt.
+ The authValue field is often a base64 encoded value derived from a
+ user's password(s). Values of this attribute are case sensitive.
+
+
+
+
+
+
+Zeilenga Informational [Page 2]
+
+RFC 3112 LDAP Authentication Password Schema May 2001
+
+
+ Transfer of values of this syntax is strongly discouraged where the
+ underlying transport service cannot guarantee confidentiality and may
+ result in disclosure of the values to unauthorized parties.
+
+ This document describes a number of schemes, as well as requirements
+ for the scheme naming, in section 3.
+
+2.2. authPasswordExactMatch
+
+ ( 1.3.6.1.4.1.4203.1.2.2
+ NAME 'authPasswordExactMatch'
+ DESC 'authentication password exact matching rule'
+ SYNTAX 1.3.6.1.4.1.4203.1.1.2 )
+
+ This matching rule allows a client to assert that an asserted
+ authPasswordSyntax value matches authPasswordSyntax values. It is
+ meant to be used as the EQUALITY matching rule of attributes whose
+ SYNTAX is authPasswordSyntax.
+
+ The assertion is "TRUE" if there is an attribute value which has the
+ same scheme, authInfo, and authValue components as the asserted
+ value; "FALSE" if no attribute value has the same components as the
+ asserted value; and "Undefined" otherwise.
+
+2.3. authPasswordMatch
+
+ ( 1.3.6.1.4.1.4203.1.2.3
+ NAME 'authPasswordMatch'
+ DESC 'authentication password matching rule'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.40{128} )
+
+ This matching rule allows a client to assert that a password matches
+ values of authPasswordSyntax using an extensibleMatch filter
+ component. Each value is matched per its scheme. The assertion is
+ "TRUE" if one or more attribute values matches the asserted value,
+ "FALSE" if all values do not matches, and "Undefined" otherwise.
+
+ Servers which support use of this matching rule SHOULD publish
+ appropriate matchingRuleUse values per [RFC2252], 4.4.
+
+ Transfer of authPasswordMatch assertion values is strongly
+ discouraged where the underlying transport service cannot guarantee
+ confidentiality and may result in disclosure of the values to
+ unauthorized parties.
+
+
+
+
+
+
+
+Zeilenga Informational [Page 3]
+
+RFC 3112 LDAP Authentication Password Schema May 2001
+
+
+2.4. supportedAuthPasswordSchemes
+
+ ( 1.3.6.1.4.1.4203.1.3.3
+ NAME 'supportedAuthPasswordSchemes'
+ DESC 'supported password storage schemes'
+ EQUALITY caseExactIA5Match
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{32}
+ USAGE dSAOperation )
+
+ The values of this attribute are names of supported authentication
+ password schemes which the server supports. The syntax of a scheme
+ name is described in section 2.1. This attribute may only be present
+ in the root DSE. If the server does not support any password
+ schemes, this attribute will not be present.
+
+2.5. authPassword
+
+ ( 1.3.6.1.4.1.4203.1.3.4 NAME 'authPassword'
+ DESC 'password authentication information'
+ EQUALITY 1.3.6.1.4.1.4203.1.2.2
+ SYNTAX 1.3.6.1.4.1.4203.1.1.2 )
+
+ The values of this attribute are representative of the user's
+ password(s) and conform to the authPasswordSyntax described in 2.1.
+ The values of this attribute may be used for authentication purposes.
+
+ Transfer of authPassword values is strongly discouraged where the
+ underlying transport service cannot guarantee confidentiality and may
+ result in disclosure of the values to unauthorized parties.
+
+2.6. authPasswordObject
+
+ ( 1.3.6.1.4.1.4203.1.4.7 NAME 'authPasswordObject'
+ DESC 'authentication password mix in class'
+ MAY 'authPassword'
+ AUXILIARY )
+
+ Entries of this object class may contain authPassword attribute
+ types.
+
+3. Schemes
+
+ This section describes the "MD5" and "SHA1" schemes. Other schemes
+ may be defined by other documents. Schemes which are not described
+ in an RFC SHOULD be named with a leading "X-" to indicate they are a
+ private or implementation specific scheme, or may be named using the
+ dotted-decimal representation [RFC2252] of an OID assigned to the
+ scheme.
+
+
+
+Zeilenga Informational [Page 4]
+
+RFC 3112 LDAP Authentication Password Schema May 2001
+
+
+3.1. MD5 scheme
+
+ The MD5 [RFC1321] scheme name is "MD5".
+
+ The authValue is the base64 encoding of an MD5 digest of the
+ concatenation the user password and salt. The base64 encoding of the
+ salt is provided in the authInfo field. The salt MUST be at least 64
+ bits long. Implementations of this scheme MUST support salts up to
+ 128 bits in length.
+
+ Example:
+ Given a user "joe" who's password is "mary" and a salt of "salt",
+ the authInfo field would be the base64 encoding of "salt" and the
+ authValue field would be the base64 encoding of the MD5 digest of
+ "marysalt".
+
+ A match against an asserted password and an attribute value of this
+ scheme SHALL be true if and only if the MD5 digest of concatenation
+ of the asserted value and the salt is equal to the MD5 digest
+ contained in AuthValue. The match SHALL be undefined if the server
+ is unable to complete the equality test for any reason. Otherwise
+ the match SHALL be false.
+
+ Values of this scheme SHOULD only be used to implement simple
+ user/password authentication.
+
+3.2. SHA1 scheme
+
+ The SHA1 [SHA1] scheme name is "SHA1".
+
+ The authValue is the base64 encoding of a SHA1 digest of the
+ concatenation the user password and the salt. The base64 encoding of
+ the salt is provided in the authInfo field. The salt MUST be at
+ least 64 bits long. Implementations of this scheme MUST support
+ salts up to 128 bits in length.
+
+ Example:
+ Given a user "joe" who's password is "mary" and a salt of "salt",
+ the authInfo field would be the base64 encoding of "salt" and the
+ authValue field would be the base64 encoding of the SHA1 digest of
+ "marysalt".
+
+ A match against an asserted password and an attribute value of this
+ scheme SHALL be true if and only if the SHA1 digest of concatenation
+ of the asserted value and the salt is equal to the SHA1 digest
+ contained in AuthValue. The match SHALL be undefined if the server
+ is unable to complete the equality test for any reason. Otherwise
+ the match SHALL be false.
+
+
+
+Zeilenga Informational [Page 5]
+
+RFC 3112 LDAP Authentication Password Schema May 2001
+
+
+ Values of this scheme SHOULD only be used to implement simple
+ user/password authentication.
+
+4. Implementation Issues
+
+ For all implementations of this specification:
+
+ Servers MAY restrict which schemes are used in conjunction with a
+ particular authentication process but SHOULD use all values of
+ selected schemes. If the asserted password matches any of the
+ stored values, the asserted password SHOULD be considered valid.
+ Servers MAY use other authentication storage mechanisms, such as
+ userPassword or an external password store, in conjunction with
+ authPassword to support the authentication process.
+
+ Servers that support simple bind MUST support the SHA1 scheme and
+ SHOULD support the MD5 scheme.
+
+ Servers SHOULD NOT publish values of authPassword nor allow
+ operations which expose authPassword values or AuthPasswordMatch
+ assertions to unless confidentiality protection is in place.
+
+ Clients SHOULD NOT initiate operations which provide or request
+ values of authPassword or make authPasswordMatch assertions unless
+ confidentiality protection is in place.
+
+ Clients SHOULD NOT assume that a successful AuthPasswordMatch,
+ whether by compare or search, is sufficient to gain directory
+ access. The bind operation MUST be used to authenticate to the
+ directory.
+
+5. Security Considerations
+
+ This document describes how authentication information may be stored
+ in a directory. Authentication information MUST be adequately
+ protected as unintended disclosure will allow attackers to gain
+ immediate access to the directory as described by [RFC2829].
+
+ As flaws may be discovered in the hashing algorithm or with a
+ particular implementation of the algorithm or values could be subject
+ to various attacks if exposed, values of AuthPassword SHOULD be
+ protected as if they were clear text passwords. When values are
+ transferred, privacy protections, such as IPSEC or TLS, SHOULD be in
+ place.
+
+ Clients SHOULD use strong authentication mechanisms [RFC2829].
+
+
+
+
+
+Zeilenga Informational [Page 6]
+
+RFC 3112 LDAP Authentication Password Schema May 2001
+
+
+ AuthPasswordMatch matching rule allows applications to test the
+ validity of a user password and, hence, may be used to mount an
+ attack. Servers SHOULD take appropriate measures to protect the
+ directory from such attacks.
+
+ Some password schemes may require CPU intensive operations. Servers
+ SHOULD take appropriate measures to protect against Denial of Service
+ attacks.
+
+ AuthPassword does not restrict an authentication identity to a single
+ password. An attacker who gains write access to this attribute may
+ store additional values without disabling the user's true
+ password(s). Use of policy aware clients and servers is RECOMMENDED.
+
+ The level of protection offered against various attacks differ from
+ scheme to scheme. It is RECOMMENDED that servers support scheme
+ selection as a configuration item. This allows for a scheme to be
+ easily disabled if a significant security flaw is discovered.
+
+6. Acknowledgment
+
+ This document borrows from a number of IETF documents and is based
+ upon input from the IETF LDAPext working group.
+
+7. Bibliography
+
+ [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
+ April 1992
+
+ [RFC2219] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2234] Crocker, D., Editor, P. Overell, "Augmented BNF for Syntax
+ Specifications: ABNF", RFC 2234, November 1997.
+
+ [RFC2251] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory
+ Access Protocol (v3)", RFC 2251, December 1997.
+
+ [RFC2252] Wahl, M., Coulbeck, A., Howes, T., and S. Kille,
+ "Lightweight Directory Access Protocol (v3): Attribute
+ Syntax Definitions", RFC 2252, December 1997.
+
+ [RFC2256] Wahl, A., "A Summary of the X.500(96) User Schema for use
+ with LDAPv3", RFC 2256, December 1997.
+
+ [RFC2307] Howard, L., "An Approach for Using LDAP as a Network
+ Information Service", RFC 2307, March 1998.
+
+
+
+
+Zeilenga Informational [Page 7]
+
+RFC 3112 LDAP Authentication Password Schema May 2001
+
+
+ [RFC2829] Wahl, M., Alvestrand, H., Hodges, J. and R. Morgan,
+ "Authentication Methods for LDAP", RFC 2829, June 2000.
+
+ [RFC3062] Zeilenga, K., "LDAP Password Modify Extended Operation",
+ RFC 3062, February 2001.
+
+ [SHA1] NIST, FIPS PUB 180-1: Secure Hash Standard, April 1995.
+
+8. Author's Address
+
+ Kurt D. Zeilenga
+ OpenLDAP Foundation
+
+ EMail: Kurt at OpenLDAP.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga Informational [Page 8]
+
+RFC 3112 LDAP Authentication Password Schema May 2001
+
+
+9. Full Copyright Statement
+
+ Copyright (C) The Internet Society (2001). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga Informational [Page 9]
+
Added: openldap/vendor/openldap-release/doc/rfc/rfc3296.txt
===================================================================
--- openldap/vendor/openldap-release/doc/rfc/rfc3296.txt (rev 0)
+++ openldap/vendor/openldap-release/doc/rfc/rfc3296.txt 2007-09-15 10:38:52 UTC (rev 844)
@@ -0,0 +1,787 @@
+
+
+
+
+
+
+Network Working Group K. Zeilenga
+Request for Comments: 3296 OpenLDAP Foundation
+Category: Standards Track July 2002
+
+
+ Named Subordinate References in
+ Lightweight Directory Access Protocol (LDAP) Directories
+
+Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2002). All Rights Reserved.
+
+Abstract
+
+ This document details schema and protocol elements for representing
+ and managing named subordinate references in Lightweight Directory
+ Access Protocol (LDAP) Directories.
+
+Conventions
+
+ Schema definitions are provided using LDAPv3 description formats
+ [RFC2252]. Definitions provided here are formatted (line wrapped)
+ for readability.
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" used in
+ this document are to be interpreted as described in BCP 14 [RFC2119].
+
+1. Background and Intended Usage
+
+ The broadening of interest in LDAP (Lightweight Directory Access
+ Protocol) [RFC2251] directories beyond their use as front ends to
+ X.500 [X.500] directories has created a need to represent knowledge
+ information in a more general way. Knowledge information is
+ information about one or more servers maintained in another server,
+ used to link servers and services together.
+
+ This document details schema and protocol elements for representing
+ and manipulating named subordinate references in LDAP directories. A
+ referral object is used to hold subordinate reference information in
+
+
+
+Zeilenga Standards Track [Page 1]
+
+RFC 3296 Named Subordinate References in LDAP Directories July 2002
+
+
+ the directory. These referral objects hold one or more URIs
+ [RFC2396] contained in values of the ref attribute type and are used
+ to generate protocol referrals and continuations.
+
+ A control, ManageDsaIT, is defined to allow manipulation of referral
+ and other special objects as normal objects. As the name of control
+ implies, it is intended to be analogous to the ManageDsaIT service
+ option described in X.511(97) [X.511].
+
+ Other forms of knowledge information are not detailed by this
+ document. These forms may be described in subsequent documents.
+
+ This document details subordinate referral processing requirements
+ for servers. This document does not describe protocol syntax and
+ semantics. This is detailed in RFC 2251 [RFC2251].
+
+ This document does not detail use of subordinate knowledge references
+ to support replicated environments nor distributed operations (e.g.,
+ chaining of operations from one server to other servers).
+
+2. Schema
+
+2.1. The referral Object Class
+
+ A referral object is a directory entry whose structural object class
+ is (or is derived from) the referral object class.
+
+ ( 2.16.840.1.113730.3.2.6
+ NAME 'referral'
+ DESC 'named subordinate reference object'
+ STRUCTURAL
+ MUST ref )
+
+ The referral object class is a structural object class used to
+ represent a subordinate reference in the directory. The referral
+ object class SHOULD be used in conjunction with the extensibleObject
+ object class to support the naming attributes used in the entry's
+ Distinguished Name (DN) [RFC2253].
+
+ Referral objects are normally instantiated at DSEs immediately
+ subordinate to object entries within a naming context held by the
+ DSA. Referral objects are analogous to X.500 subordinate knowledge
+ (subr) DSEs [X.501].
+
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 2]
+
+RFC 3296 Named Subordinate References in LDAP Directories July 2002
+
+
+ In the presence of a ManageDsaIT control, referral objects are
+ treated as normal entries as described in section 3. Note that the
+ ref attribute is operational and will only be returned in a search
+ entry response when requested.
+
+ In the absence of a ManageDsaIT control, the content of referral
+ objects are used to construct referrals and search references as
+ described in Section 4 and, as such, the referral entries are not
+ themselves visible to clients.
+
+2.2 The ref Attribute Type
+
+ ( 2.16.840.1.113730.3.1.34
+ NAME 'ref'
+ DESC 'named reference - a labeledURI'
+ EQUALITY caseExactMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ USAGE distributedOperation )
+
+ The ref attribute type has directoryString syntax and is case
+ sensitive. The ref attribute is multi-valued. Values placed in the
+ attribute MUST conform to the specification given for the labeledURI
+ attribute [RFC2079]. The labeledURI specification defines a format
+ that is a URI, optionally followed by whitespace and a label. This
+ document does not make use of the label portion of the syntax.
+ Future documents MAY enable new functionality by imposing additional
+ structure on the label portion of the syntax as it appears in the ref
+ attribute.
+
+ If the URI contained in a ref attribute value refers to a LDAP
+ [RFC2251] server, it MUST be in the form of a LDAP URL [RFC2255].
+ The LDAP URL SHOULD NOT contain an explicit scope specifier, filter,
+ attribute description list, or any extensions. The LDAP URL SHOULD
+ contain a non-empty DN. The handling of LDAP URLs with absent or
+ empty DN parts or with explicit scope specifier is not defined by
+ this specification.
+
+ Other URI schemes MAY be used so long as all operations returning
+ referrals based upon the value could be performed. This document
+ does not detail use of non-LDAP URIs. This is left to future
+ specifications.
+
+ The referential integrity of the URI SHOULD NOT be validated by the
+ server holding or returning the URI (whether as a value of the
+ attribute or as part of a referral result or search reference
+ response).
+
+
+
+
+
+Zeilenga Standards Track [Page 3]
+
+RFC 3296 Named Subordinate References in LDAP Directories July 2002
+
+
+ When returning a referral result or search continuation, the server
+ MUST NOT return the separator or label portions of the attribute
+ values as part of the reference. When the attribute contains
+ multiple values, the URI part of each value is used to construct the
+ referral result or search continuation.
+
+ The ref attribute values SHOULD NOT be used as a relative name-
+ component of an entry's DN [RFC2253].
+
+ This document uses the ref attribute in conjunction with the referral
+ object class to represent subordinate references. The ref attribute
+ may be used for other purposes as defined by other documents.
+
+3. The ManageDsaIT Control
+
+ The client may provide the ManageDsaIT control with an operation to
+ indicate that the operation is intended to manage objects within the
+ DSA (server) Information Tree. The control causes Directory-specific
+ entries (DSEs), regardless of type, to be treated as normal entries
+ allowing clients to interrogate and update these entries using LDAP
+ operations.
+
+ A client MAY specify the following control when issuing an add,
+ compare, delete, modify, modifyDN, search request or an extended
+ operation for which the control is defined.
+
+ The control type is 2.16.840.1.113730.3.4.2. The control criticality
+ may be TRUE or, if FALSE, absent. The control value is absent.
+
+ When the control is present in the request, the server SHALL NOT
+ generate a referral or continuation reference based upon information
+ held in referral objects and instead SHALL treat the referral object
+ as a normal entry. The server, however, is still free to return
+ referrals for other reasons. When not present, referral objects
+ SHALL be handled as described above.
+
+ The control MAY cause other objects to be treated as normal entries
+ as defined by subsequent documents.
+
+4. Named Subordinate References
+
+ A named subordinate reference is constructed by instantiating a
+ referral object in the referencing server with ref attribute values
+ which point to the corresponding subtree maintained in the referenced
+ server. In general, the name of the referral object is the same as
+ the referenced object and this referenced object is a context prefix
+ [X.501].
+
+
+
+
+Zeilenga Standards Track [Page 4]
+
+RFC 3296 Named Subordinate References in LDAP Directories July 2002
+
+
+ That is, if server A holds "DC=example,DC=net" and server B holds
+ "DC=sub,DC=example,DC=net", server A may contain a referral object
+ named "DC=sub,DC=example,DC=net" which contains a ref attribute with
+ value of "ldap://B/DC=sub,DC=example,DC=net".
+
+ dn: DC=sub,DC=example,DC=net
+ dc: sub
+ ref: ldap://B/DC=sub,DC=example,DC=net
+ objectClass: referral
+ objectClass: extensibleObject
+
+ Typically the DN of the referral object and the DN of the object in
+ the referenced server are the same.
+
+ If the ref attribute has multiple values, all the DNs contained
+ within the LDAP URLs SHOULD be equivalent. Administrators SHOULD
+ avoid configuring naming loops using referrals.
+
+ Named references MUST be treated as normal entries if the request
+ includes the ManageDsaIT control as described in section 3.
+
+5. Scenarios
+
+ The following sections contain specifications of how referral objects
+ should be used in different scenarios followed by examples that
+ illustrate that usage. The scenarios described here consist of
+ referral object handling when finding target of a non-search
+ operation, when finding the base of a search operation, and when
+ generating search references. Lastly, other operation processing
+ considerations are presented.
+
+ It is to be noted that, in this document, a search operation is
+ conceptually divided into two distinct, sequential phases: (1)
+ finding the base object where the search is to begin, and (2)
+ performing the search itself. The first phase is similar to, but not
+ the same as, finding the target of a non-search operation.
+
+ It should also be noted that the ref attribute may have multiple
+ values and, where these sections refer to a single ref attribute
+ value, multiple ref attribute values may be substituted and SHOULD be
+ processed and returned (in any order) as a group in a referral or
+ search reference in the same way as described for a single ref
+ attribute value.
+
+ Search references returned for a given request may be returned in any
+ order.
+
+
+
+
+
+Zeilenga Standards Track [Page 5]
+
+RFC 3296 Named Subordinate References in LDAP Directories July 2002
+
+
+5.1. Example Configuration
+
+ For example, suppose the contacted server (hosta) holds the entry
+ "O=MNN,C=WW" and the entry "CN=Manager,O=MNN,C=WW" and the following
+ referral objects:
+
+ dn: OU=People,O=MNN,C=WW
+ ou: People
+ ref: ldap://hostb/OU=People,O=MNN,C=US
+ ref: ldap://hostc/OU=People,O=MNN,C=US
+ objectClass: referral
+ objectClass: extensibleObject
+
+ dn: OU=Roles,O=MNN,C=WW
+ ou: Roles
+ ref: ldap://hostd/OU=Roles,O=MNN,C=WW
+ objectClass: referral
+ objectClass: extensibleObject
+
+ The first referral object provides the server with the knowledge that
+ subtree "OU=People,O=MNN,C=WW" is held by hostb and hostc (e.g., one
+ is the master and the other a shadow). The second referral object
+ provides the server with the knowledge that the subtree
+ "OU=Roles,O=MNN,C=WW" is held by hostd.
+
+ Also, in the context of this document, the "nearest naming context"
+ means the deepest context which the object is within. That is, if
+ the object is within multiple naming contexts, the nearest naming
+ context is the one which is subordinate to all other naming contexts
+ the object is within.
+
+5.2. Target Object Considerations
+
+ This section details referral handling for add, compare, delete,
+ modify, and modify DN operations. If the client requests any of
+ these operations, there are four cases that the server must handle
+ with respect to the target object.
+
+ The DN part MUST be modified such that it refers to the appropriate
+ target in the referenced server (as detailed below). Even where the
+ DN to be returned is the same as the target DN, the DN part SHOULD
+ NOT be trimmed.
+
+ In cases where the URI to be returned is a LDAP URL, the server
+ SHOULD trim any present scope, filter, or attribute list from the URI
+ before returning it. Critical extensions MUST NOT be trimmed or
+ modified.
+
+
+
+
+Zeilenga Standards Track [Page 6]
+
+RFC 3296 Named Subordinate References in LDAP Directories July 2002
+
+
+ Case 1: The target object is not held by the server and is not within
+ or subordinate to any naming context nor subordinate to any
+ referral object held by the server.
+
+ The server SHOULD process the request normally as appropriate for
+ a non-existent base which is not within any naming context of the
+ server (generally return noSuchObject or a referral based upon
+ superior knowledge reference information). This document does not
+ detail management or processing of superior knowledge reference
+ information.
+
+ Case 2: The target object is held by the server and is a referral
+ object.
+
+ The server SHOULD return the URI value contained in the ref
+ attribute of the referral object appropriately modified as
+ described above.
+
+ Example: If the client issues a modify request for the target object
+ of "OU=People,O=MNN,c=WW", the server will return:
+
+ ModifyResponse (referral) {
+ ldap://hostb/OU=People,O=MNN,C=WW
+ ldap://hostc/OU=People,O=MNN,C=WW
+ }
+
+ Case 3: The target object is not held by the server, but the nearest
+ naming context contains no referral object which the target object
+ is subordinate to.
+
+ If the nearest naming context contains no referral object which
+ the target is subordinate to, the server SHOULD process the
+ request as appropriate for a nonexistent target (generally return
+ noSuchObject).
+
+ Case 4: The target object is not held by the server, but the nearest
+ naming context contains a referral object which the target object
+ is subordinate to.
+
+ If a client requests an operation for which the target object is
+ not held by the server and the nearest naming context contains a
+ referral object which the target object is subordinate to, the
+ server SHOULD return a referral response constructed from the URI
+ portion of the ref value of the referral object.
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 7]
+
+RFC 3296 Named Subordinate References in LDAP Directories July 2002
+
+
+ Example: If the client issues an add request where the target object
+ has a DN of "CN=Manager,OU=Roles,O=MNN,C=WW", the server will
+ return:
+
+ AddResponse (referral) {
+ ldap://hostd/CN=Manager,OU=Roles,O=MNN,C=WW"
+ }
+
+ Note that the DN part of the LDAP URL is modified such that it
+ refers to the appropriate entry in the referenced server.
+
+5.3. Base Object Considerations
+
+ This section details referral handling for base object processing
+ within search operations. Like target object considerations for
+ non-search operations, there are the four cases.
+
+ In cases where the URI to be returned is a LDAP URL, the server MUST
+ provide an explicit scope specifier from the LDAP URL prior to
+ returning it. In addition, the DN part MUST be modified such that it
+ refers to the appropriate target in the referenced server (as
+ detailed below).
+
+ If aliasing dereferencing was necessary in finding the referral
+ object, the DN part of the URI MUST be replaced with the base DN as
+ modified by the alias dereferencing such that the return URL refers
+ to the new target object per [RFC2251, 4.1.11].
+
+ Critical extensions MUST NOT be trimmed nor modified.
+
+ Case 1: The base object is not held by the server and is not within
+ nor subordinate to any naming context held by the server.
+
+ The server SHOULD process the request normally as appropriate for
+ a non-existent base which not within any naming context of the
+ server (generally return a superior referral or noSuchObject).
+ This document does not detail management or processing of superior
+ knowledge references.
+
+ Case 2: The base object is held by the server and is a referral
+ object.
+
+ The server SHOULD return the URI value contained in the ref
+ attribute of the referral object appropriately modified as
+ described above.
+
+
+
+
+
+
+Zeilenga Standards Track [Page 8]
+
+RFC 3296 Named Subordinate References in LDAP Directories July 2002
+
+
+ Example: If the client issues a subtree search in which the base
+ object is "OU=Roles,O=MNN,C=WW", the server will return
+
+ SearchResultDone (referral) {
+ ldap://hostd/OU=Roles,O=MNN,C=WW??sub
+ }
+
+ If the client were to issue a base or oneLevel search instead of
+ subtree, the returned LDAP URL would explicitly specify "base" or
+ "one", respectively, instead of "sub".
+
+ Case 3: The base object is not held by the server, but the nearest
+ naming context contains no referral object which the base object
+ is subordinate to.
+
+ If the nearest naming context contains no referral object which
+ the base is subordinate to, the request SHOULD be processed
+ normally as appropriate for a nonexistent base (generally return
+ noSuchObject).
+
+ Case 4: The base object is not held by the server, but the nearest
+ naming context contains a referral object which the base object is
+ subordinate to.
+
+ If a client requests an operation for which the target object is
+ not held by the server and the nearest naming context contains a
+ referral object which the target object is subordinate to, the
+ server SHOULD return a referral response which is constructed from
+ the URI portion of the ref value of the referral object.
+
+ Example: If the client issues a base search request for
+ "CN=Manager,OU=Roles,O=MNN,C=WW", the server will return
+
+ SearchResultDone (referral) {
+ ldap://hostd/CN=Manager,OU=Roles,O=MNN,C=WW??base"
+ }
+
+ If the client were to issue a subtree or oneLevel search instead
+ of subtree, the returned LDAP URL would explicitly specify "sub"
+ or "one", respectively, instead of "base".
+
+ Note that the DN part of the LDAP URL is modified such that it
+ refers to the appropriate entry in the referenced server.
+
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 9]
+
+RFC 3296 Named Subordinate References in LDAP Directories July 2002
+
+
+5.4. Search Continuation Considerations
+
+ For search operations, once the base object has been found and
+ determined not to be a referral object, the search may progress. Any
+ entry matching the filter and scope of the search which is not a
+ referral object is returned to the client normally as described in
+ [RFC2251].
+
+ For each referral object within the requested scope, regardless of
+ the search filter, the server SHOULD return a SearchResultReference
+ which is constructed from the URI component of values of the ref
+ attribute. If the URI component is not a LDAP URL, it should be
+ returned as is. If the LDAP URL's DN part is absent or empty, the DN
+ part must be modified to contain the DN of the referral object. If
+ the URI component is a LDAP URL, the URI SHOULD be modified to add an
+ explicit scope specifier.
+
+ Subtree Example:
+
+ If a client requests a subtree search of "O=MNN,C=WW", then in
+ addition to any entries within scope which match the filter, hosta
+ will also return two search references as the two referral objects
+ are within scope. One possible response might be:
+
+ SearchEntry for O=MNN,C=WW
+ SearchResultReference {
+ ldap://hostb/OU=People,O=MNN,C=WW??sub
+ ldap://hostc/OU=People,O=MNN,C=WW??sub
+ }
+ SearchEntry for CN=Manager,O=MNN,C=WW
+ SearchResultReference {
+ ldap://hostd/OU=Roles,O=MNN,C=WW??sub
+ }
+ SearchResultDone (success)
+
+ One Level Example:
+
+ If a client requests a one level search of "O=MNN,C=WW" then, in
+ addition to any entries one level below the "O=MNN,C=WW" entry
+ matching the filter, the server will also return two search
+ references as the two referral objects are within scope. One
+ possible sequence is shown:
+
+
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 10]
+
+RFC 3296 Named Subordinate References in LDAP Directories July 2002
+
+
+ SearchResultReference {
+ ldap://hostb/OU=People,O=MNN,C=WW??base
+ ldap://hostc/OU=People,O=MNN,C=WW??base
+ }
+ SearchEntry for CN=Manager,O=MNN,C=WW
+ SearchResultReference {
+ ldap://hostd/OU=Roles,O=MNN,C=WW??base
+ }
+ SearchResultDone (success)
+
+ Note: Unlike the examples in Section 4.5.3.1 of RFC 2251, the LDAP
+ URLs returned with the SearchResultReference messages contain, as
+ required by this specification, an explicit scope specifier.
+
+5.6. Other Considerations
+
+ This section details processing considerations for other operations.
+
+5.6.1 Bind
+
+ Servers SHOULD NOT return referral result code if the bind name (or
+ authentication identity or authorization identity) is (or is
+ subordinate to) a referral object but MAY use the knowledge
+ information to process the bind request (such as in support a future
+ distributed operation specification). Where the server makes no use
+ of the knowledge information, the server processes the request
+ normally as appropriate for a non-existent authentication or
+ authorization identity (e.g., return invalidCredentials).
+
+5.6.2 Modify DN
+
+ If the newSuperior is a referral object or is subordinate to a
+ referral object, the server SHOULD return affectsMultipleDSAs. If
+ the newRDN already exists but is a referral object, the server SHOULD
+ return affectsMultipleDSAs instead of entryAlreadyExists.
+
+6. Security Considerations
+
+ This document defines mechanisms that can be used to tie LDAP (and
+ other) servers together. The information used to tie services
+ together should be protected from unauthorized modification. If the
+ server topology information is not public information, it should be
+ protected from unauthorized disclosure as well.
+
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 11]
+
+RFC 3296 Named Subordinate References in LDAP Directories July 2002
+
+
+7. Acknowledgments
+
+ This document borrows heavily from previous work by IETF LDAPext
+ Working Group. In particular, this document is based upon "Named
+ Referral in LDAP Directories" (an expired Internet Draft) by
+ Christopher Lukas, Tim Howes, Michael Roszkowski, Mark C. Smith, and
+ Mark Wahl.
+
+8. Normative References
+
+ [RFC2079] Smith, M., "Definition of an X.500 Attribute Type and an
+ Object Class to Hold Uniform Resource Identifiers (URIs)",
+ RFC 2079, January 1997.
+
+ [RFC2119] Bradner, S., "Key Words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2251] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory
+ Access Protocol (v3)", RFC 2251, December 1997.
+
+ [RFC2252] Wahl, M., Coulbeck, A., Howes, T. and S. Kille,
+ "Lightweight Directory Access Protocol (v3): Attribute
+ Syntax Definitions", RFC 2252, December 1997.
+
+ [RFC2253] Wahl, M., Kille, S. and T. Howes, "Lightweight Directory
+ Access Protocol (v3): UTF-8 String Representation of
+ Distinguished Names", RFC 2253, December 1997.
+
+ [RFC2255] Howes, T. and M. Smith, "The LDAP URL Format", RFC 2255,
+ December, 1997.
+
+ [RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
+ Resource Identifiers (URI): Generic Syntax", RFC 2396,
+ August 1998.
+
+ [X.501] ITU-T, "The Directory: Models", X.501, 1993.
+
+9. Informative References
+
+ [X.500] ITU-T, "The Directory: Overview of Concepts, Models, and
+ Services", X.500, 1993.
+
+ [X.511] ITU-T, "The Directory: Abstract Service Definition", X.500,
+ 1997.
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 12]
+
+RFC 3296 Named Subordinate References in LDAP Directories July 2002
+
+
+10. Author's Address
+
+ Kurt D. Zeilenga
+ OpenLDAP Foundation
+
+ EMail: Kurt at OpenLDAP.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 13]
+
+RFC 3296 Named Subordinate References in LDAP Directories July 2002
+
+
+11. Full Copyright Statement
+
+ Copyright (C) The Internet Society (2002). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 14]
+
Added: openldap/vendor/openldap-release/doc/rfc/rfc3377.txt
===================================================================
--- openldap/vendor/openldap-release/doc/rfc/rfc3377.txt (rev 0)
+++ openldap/vendor/openldap-release/doc/rfc/rfc3377.txt 2007-09-15 10:38:52 UTC (rev 844)
@@ -0,0 +1,339 @@
+
+
+
+
+
+
+Network Working Group J. Hodges
+Request for Comments: 3377 Sun Microsystems Inc.
+Category: Standards Track R. Morgan
+ University of Washington
+ September 2002
+
+
+ Lightweight Directory Access Protocol (v3):
+ Technical Specification
+
+Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2002). All Rights Reserved.
+
+Abstract
+
+ This document specifies the set of RFCs comprising the Lightweight
+ Directory Access Protocol Version 3 (LDAPv3), and addresses the "IESG
+ Note" attached to RFCs 2251 through 2256.
+
+1. Background and Motivation
+
+ The specification for the Lightweight Directory Access Protocol
+ version 3 (LDAPv3) nominally comprises eight RFCs which were issued
+ in two distinct subsets at separate times -- RFCs 2251 through 2256
+ first, then RFCs 2829 and 2830 following later.
+
+ RFC 2251 through 2256 do not mandate the implementation of any
+ satisfactory authentication mechanisms and hence were published with
+ an "IESG Note" discouraging implementation and deployment of LDAPv3
+ clients or servers implementing update functionality until a Proposed
+ Standard for mandatory authentication in LDAPv3 is published.
+
+ RFC 2829 was subsequently published in answer to the IESG Note.
+
+ The purpose of this document is to explicitly specify the set of RFCs
+ comprising LDAPv3, and formally address the IESG Note through
+ explicit inclusion of RFC 2829.
+
+
+
+
+
+Hodges & Morgan Standards Track [Page 1]
+
+RFC 3377 LDAPv3: Technical Specification September 2002
+
+
+2. Specification of LDAPv3
+
+ The Lightweight Directory Access Protocol version 3 (LDAPv3) is
+ specified by this set of nine RFCs:
+
+ [RFC2251] Lightweight Directory Access Protocol (v3) [the
+ specification of the LDAP on-the-wire protocol]
+
+ [RFC2252] Lightweight Directory Access Protocol (v3): Attribute
+ Syntax Definitions
+
+ [RFC2253] Lightweight Directory Access Protocol (v3): UTF-8
+ String Representation of Distinguished Names
+
+ [RFC2254] The String Representation of LDAP Search Filters
+
+ [RFC2255] The LDAP URL Format
+
+ [RFC2256] A Summary of the X.500(96) User Schema for use with
+ LDAPv3
+
+ [RFC2829] Authentication Methods for LDAP
+
+ [RFC2830] Lightweight Directory Access Protocol (v3): Extension
+ for Transport Layer Security
+
+ And, this document (RFC3377).
+
+ The term "LDAPv3" is often used informally to refer to the protocol
+ specified by the above set of RFCs, or subsets thereof. However, the
+ LDAPv3 protocol suite, as defined here, should be formally identified
+ in other documents by a normative reference to this document.
+
+3. Addressing the "IESG Note" in RFCs 2251 through 2256
+
+ The IESG approved publishing RFCs 2251 through 2256 with an attendant
+ IESG Note included in each document. The Note begins with:
+
+ This document describes a directory access protocol that provides
+ both read and update access. Update access requires secure
+ authentication, but this document does not mandate implementation
+ of any satisfactory authentication mechanisms.
+
+
+
+
+
+
+
+
+
+Hodges & Morgan Standards Track [Page 2]
+
+RFC 3377 LDAPv3: Technical Specification September 2002
+
+
+ The Note ends with this statement:
+
+ Implementors are hereby discouraged from deploying LDAPv3 clients
+ or servers which implement the update functionality, until a
+ Proposed Standard for mandatory authentication in LDAPv3 has been
+ approved and published as an RFC.
+
+ [RFC2829] is expressly the "Proposed Standard for mandatory
+ authentication in LDAPv3" called for in the Note. Thus, the IESG
+ Note in [RFC2251], [RFC2252], [RFC2253], [RFC2254], [RFC2255], and
+ [RFC2256] is addressed.
+
+4. Security Considerations
+
+ This document does not directly discuss security, although the
+ context of the aforementioned IESG Note is security related, as is
+ the manner in which it is addressed.
+
+ Please refer to the referenced documents, especially [RFC2829],
+ [RFC2251], and [RFC2830], for further information concerning LDAPv3
+ security.
+
+5. Acknowledgements
+
+ The authors thank Patrik Faltstrom, Leslie Daigle, Thomas Narten, and
+ Kurt Zeilenga for their contributions to this document.
+
+6. References
+
+ [RFC2251] Wahl, M., Kille, S. and T. Howes, "Lightweight Directory
+ Access Protocol (v3)", RFC 2251, December 1997.
+
+ [RFC2252] Wahl, M., Coulbeck, A., Howes, T. and S. Kille,
+ "Lightweight Directory Access Protocol (v3): Attribute
+ Syntax Definitions", RFC 2252, December 1997.
+
+ [RFC2253] Kille, S., Wahl, M. and T. Howes, "Lightweight Directory
+ Access Protocol (v3): UTF-8 String Representation of
+ Distinguished Names", RFC 2253, December 1997.
+
+ [RFC2254] Howes, T., "The String Representation of LDAP Search
+ Filters", RFC 2254, December 1997.
+
+ [RFC2255] Howes, T. and M. Smith, "The LDAP URL Format", RFC 2255,
+ December 1997.
+
+ [RFC2256] Wahl, M., "A Summary of the X.500(96) User Schema for use
+ with LDAPv3", RFC 2256, December 1997.
+
+
+
+Hodges & Morgan Standards Track [Page 3]
+
+RFC 3377 LDAPv3: Technical Specification September 2002
+
+
+ [RFC2829] Wahl, M., Alvestrand, H., Hodges, J. and R. Morgan,
+ "Authentication Methods for LDAP", RFC 2829, May 2000.
+
+ [RFC2830] Hodges, J., Morgan, R. and M. Wahl, "Lightweight Directory
+ Access Protocol (v3): Extension for Transport Layer
+ Security", RFC 2830, May 2000.
+
+7. Intellectual Property Rights Notices
+
+ The IETF takes no position regarding the validity or scope of any
+ intellectual property or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; neither does it represent that it
+ has made any effort to identify any such rights. Information on the
+ IETF's procedures with respect to rights in standards-track and
+ standards-related documentation can be found in BCP-11. Copies of
+ claims of rights made available for publication and any assurances of
+ licenses to be made available, or the result of an attempt made to
+ obtain a general license or permission for the use of such
+ proprietary rights by implementors or users of this specification can
+ be obtained from the IETF Secretariat.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights which may cover technology that may be required to practice
+ this standard. Please address the information to the IETF Executive
+ Director.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hodges & Morgan Standards Track [Page 4]
+
+RFC 3377 LDAPv3: Technical Specification September 2002
+
+
+8. Authors' Addresses
+
+ Jeff Hodges
+ Sun Microsystems, Inc.
+ 901 San Antonio Road, USCA22-212
+ Palo Alto, CA 94303
+ USA
+
+ Phone: +1-408-276-5467
+ EMail: Jeff.Hodges at sun.com
+
+
+ RL "Bob" Morgan
+ Computing and Communications
+ University of Washington
+ Seattle, WA
+ USA
+
+ Phone: +1-206-221-3307
+ EMail: rlmorgan at washington.edu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hodges & Morgan Standards Track [Page 5]
+
+RFC 3377 LDAPv3: Technical Specification September 2002
+
+
+9. Full Copyright Statement
+
+ Copyright (C) The Internet Society (2002). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hodges & Morgan Standards Track [Page 6]
+
Added: openldap/vendor/openldap-release/doc/rfc/rfc3383.txt
===================================================================
--- openldap/vendor/openldap-release/doc/rfc/rfc3383.txt (rev 0)
+++ openldap/vendor/openldap-release/doc/rfc/rfc3383.txt 2007-09-15 10:38:52 UTC (rev 844)
@@ -0,0 +1,1291 @@
+
+
+
+
+
+
+Network Working Group K. Zeilenga
+Request for Comments: 3383 OpenLDAP Foundation
+BCP: 64 September 2002
+Category: Best Current Practice
+
+
+ Internet Assigned Numbers Authority (IANA) Considerations
+ for the Lightweight Directory Access Protocol (LDAP)
+
+Status of this Memo
+
+ This document specifies an Internet Best Current Practices for the
+ Internet Community, and requests discussion and suggestions for
+ improvements. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2002). All Rights Reserved.
+
+Abstract
+
+ This document provides procedures for registering extensible elements
+ of the Lightweight Directory Access Protocol (LDAP). This document
+ also provides guidelines to the Internet Assigned Numbers Authority
+ (IANA) describing conditions under which new values can be assigned.
+
+1. Introduction
+
+ The Lightweight Directory Access Protocol (LDAP) [RFC3377] is an
+ extensible protocol. LDAP supports:
+
+ - addition of new operations,
+ - extension of existing operations, and
+ - extensible schema.
+
+ This document details procedures for registering values of used to
+ unambiguously identify extensible elements of the protocol including:
+
+ - LDAP message types;
+ - LDAP extended operations and controls;
+ - LDAP result codes;
+ - LDAP authentication methods;
+ - LDAP attribute description options; and
+ - Object Identifier descriptors.
+
+ These registries are maintained by the Internet Assigned Numbers
+ Authority (IANA).
+
+
+
+
+Zeilenga Best Current Practice [Page 1]
+
+RFC 3383 IANA Considerations for LDAP September 2002
+
+
+ In addition, this document provides guidelines to IANA describing the
+ conditions under which new values can be assigned.
+
+2. Terminology and Conventions
+
+ This section details terms and conventions used in this document.
+
+2.1. Policy Terminology
+
+ The terms "IESG Approval", "Standards Action", "IETF Consensus",
+ "Specification Required", "First Come First Served", "Expert Review",
+ and "Private Use" are used as defined in BCP 26 [RFC2434].
+
+2.2. Requirement Terminology
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in BCP 14 [RFC2119]. In
+ this case, "the specification" as used by BCP 14 refers to the
+ processing of protocols being submitted to the IETF standards
+ process.
+
+2.3. Common ABNF Productions
+
+ A number of syntaxes in this document are described using ABNF
+ [RFC2234]. These syntaxes rely on the following common productions:
+
+ ALPHA = %x41-5A / %x61-7A ; A-Z / a-z
+
+ LDIGIT = %x31-39 ; 1-9
+
+ DIGIT = %x30 / LDIGIT ; 0-9
+
+ HYPHEN = %x2D ; "-"
+
+ DOT = %x2E ; "."
+
+ number = DIGIT / ( LDIGIT 1*DIGIT )
+
+ keychar = ALPHA / DIGIT / HYPHEN
+
+ leadkeychar = ALPHA
+
+ keystring = leadkeychar *keychar
+
+ A keyword is a case-insensitive string of UTF-8 [RFC2279] encoded
+ characters from the Universal Character Set (UCS) [ISO10646]
+ restricted to the <keystring> production.
+
+
+
+Zeilenga Best Current Practice [Page 2]
+
+RFC 3383 IANA Considerations for LDAP September 2002
+
+
+3. IANA Considerations for LDAP
+
+ This section details each kind of protocol value which can be
+ registered and provides IANA guidelines on how to assign new values.
+
+ IANA may reject obviously bogus registration requests.
+
+3.1. Object Identifiers
+
+ Numerous LDAP schema and protocol elements are identified by Object
+ Identifiers. Specifications which assign OIDs to elements SHOULD
+ state who delegated the OIDs for its use.
+
+ For IETF developed elements, specifications SHOULD use OIDs under
+ "Internet Directory Numbers" (1.3.6.1.1.x). Numbers under this OID
+ arc will be assigned upon Expert Review with Specification Required.
+ Only one OID per specification will be assigned. The specification
+ MAY then assign any number of OIDs within this arc without further
+ coordination with IANA.
+
+ For elements developed by others, any properly delegated OID can
+ be used, including those under "Internet Private Enterprise
+ Numbers" (1.3.6.1.4.1.x) assigned by IANA
+ <http://www.iana.org/cgi-bin/enterprise.pl>.
+
+ To avoid interoperability problems between early implementations of
+ "works in progress" and implementations of the published
+ specification (e.g., the RFC), experimental OIDs SHOULD be used in
+ "works in progress" and early implementations. OIDs under the
+ Internet Experimental OID arc (1.3.6.1.3.x) may be used for this
+ purpose.
+
+ Experimental OIDs are not to used in published specifications (e.g.,
+ RFCs).
+
+ Practices for IANA assignment of Internet Enterprise and Experimental
+ OIDs are detailed in STD 16 [RFC1155].
+
+3.2 Protocol Mechanisms
+
+ LDAP provides a number of Root DSE attributes for discovery of
+ protocol mechanisms identified by OIDs, including:
+
+ - supportedControl [RFC2252] and
+ - supportedExtension [RFC2252].
+
+
+
+
+
+
+Zeilenga Best Current Practice [Page 3]
+
+RFC 3383 IANA Considerations for LDAP September 2002
+
+
+ A registry of OIDs used for discover of protocol mechanisms is
+ provided to allow implementors and others to locate the technical
+ specification for these protocol mechanisms. Future specifications
+ of additional Root DSE attributes holding values identifying protocol
+ mechanisms MAY extend this registry for their values.
+
+ OIDs associated with discoverable protocol mechanisms SHOULD be
+ registered. These are be considered on a First Come First Served
+ with Specification Required basis.
+
+ OIDs associated with Standard Track mechanisms MUST be registered and
+ require Standards Action.
+
+3.3. Object Identifier Descriptors
+
+ LDAP allows short descriptive names (or descriptors) to be used
+ instead of a numeric Object Identifier to identify protocol
+ extensions [RFC2251], schema elements [RFC2252], LDAP URL [RFC2255]
+ extensions, and other objects. Descriptors are restricted to strings
+ of UTF-8 encoded UCS characters restricted by the following ABNF:
+
+ name = keystring
+
+ Descriptors are case-insensitive.
+
+ Multiple names may be assigned to a given OID. For purposes of
+ registration, an OID is to be represented in numeric OID form
+ conforming to the ABNF:
+
+ numericoid = number *( DOT number ) ; e.g., 1.1.0.23.40
+
+ While the protocol places no maximum length restriction upon
+ descriptors, they should be short. Descriptors longer than 48
+ characters may be viewed as too long to register.
+
+ A values ending with a hyphen ("-") reserve all descriptors which
+ start with the value. For example, the registration of the option
+ "descrFamily-" reserves all options which start with "descrFamily-"
+ for some related purpose.
+
+ Descriptors beginning with "x-" are for Private Use and cannot be
+ registered.
+
+ Descriptors beginning with "e-" are reserved for experiments and will
+ be registered on a First Come First Served basis.
+
+ All other descriptors require Expert Review to be registered.
+
+
+
+
+Zeilenga Best Current Practice [Page 4]
+
+RFC 3383 IANA Considerations for LDAP September 2002
+
+
+ The registrant need not "own" the OID being named.
+
+ The OID namespace is managed by The ISO/IEC Joint Technical Committee
+ 1 - Subcommittee 6.
+
+3.4. AttributeDescription Options
+
+ An AttributeDescription [RFC2251, Section 4.1.5] can contain zero or
+ more options specifying additional semantics. An option SHALL be
+ restricted to a string UTF-8 encoded UCS characters limited by the
+ following ABNF:
+
+ option = keystring
+
+ Options are case-insensitive.
+
+ While the protocol places no maximum length restriction upon option
+ strings, they should be short. Options longer than 24 characters may
+ be viewed as too long to register.
+
+ Values ending with a hyphen ("-") reserve all option names which
+ start with the name. For example, the registration of the option
+ "optionFamily-" reserves all options which start with "optionFamily-"
+ for some related purpose.
+
+ Options beginning with "x-" are for Private Use and cannot be
+ registered.
+
+ Options beginning with "e-" are reserved for experiments and will be
+ registered on a First Come First Served basis.
+
+ All other options require Standards Action or Expert Review with
+ Specification Required to be registered.
+
+3.5. LDAP Message Types
+
+ Each protocol message is encapsulated in an LDAPMessage envelope
+ [RFC2251, Section 4.1.1]. The protocolOp CHOICE indicates the type
+ of message encapsulated. Each message type consists of a keyword and
+ a non-negative choice number is combined with the class (APPLICATION)
+ and data type (CONSTRUCTED or PRIMITIVE) to construct the BER tag in
+ the message's encoding. The choice numbers for existing protocol
+ messages are implicit in the protocol's ASN.1 defined in [RFC2251].
+
+ New values will be registered upon Standards Action.
+
+ Note: LDAP provides extensible messages which reduces, but does not
+ eliminate, the need to add new message types.
+
+
+
+Zeilenga Best Current Practice [Page 5]
+
+RFC 3383 IANA Considerations for LDAP September 2002
+
+
+3.6. LDAP Result Codes
+
+ LDAP result messages carry an resultCode enumerated value to indicate
+ the outcome of the operation [RFC2251, Section 4.1.10]. Each result
+ code consists of a keyword and a non-negative integer.
+
+ New resultCodes integers in the range 0-1023 require Standards Action
+ to be registered. New resultCode integers in the range 1024-4095
+ require Expert Review with Specification Required. New resultCode
+ integers in the range 4096-16383 will be registered on a First Come
+ First Served basis. Keywords associated with integers in the range
+ 0-4095 SHALL NOT start with "e-" or "x-". Keywords associated with
+ integers in the range 4096-16383 SHALL start with "e-". Values
+ greater than or equal to 16384 and keywords starting with "x-" are
+ for Private Use and cannot be registered.
+
+3.7. LDAP Authentication Method
+
+ The LDAP Bind operation supports multiple authentication methods
+ [RFC2251, Section 4.2]. Each authentication choice consists of a
+ keyword and a non-negative integer.
+
+ The registrant SHALL classify the authentication method usage using
+ one of the following terms:
+
+ COMMON - method is appropriate for common use on the
+ Internet,
+ LIMITED USE - method is appropriate for limited use,
+ OBSOLETE - method has been deprecated or otherwise found to be
+ inappropriate for any use.
+
+ Methods without publicly available specifications SHALL NOT be
+ classified as COMMON. New registrations of class OBSOLETE cannot be
+ registered.
+
+ New authentication method integers in the range 0-1023 require
+ Standards Action to be registered. New authentication method
+ integers in the range 1024-4095 require Expert Review with
+ Specification Required. New authentication method integers in the
+ range 4096-16383 will be registered on a First Come First Served
+ basis. Keywords associated with integers in the range 0-4095 SHALL
+ NOT start with "e-" or "x-". Keywords associated with integers in
+ the range 4096-16383 SHALL start with "e-". Values greater than or
+ equal to 16384 and keywords starting with "x-" are for Private Use
+ and cannot be registered.
+
+ Note: LDAP supports SASL [RFC2222] as an Authentication CHOICE.
+ SASL is an extensible LDAP authentication method.
+
+
+
+Zeilenga Best Current Practice [Page 6]
+
+RFC 3383 IANA Considerations for LDAP September 2002
+
+
+3.8. Directory Systems Names
+
+ The IANA-maintained "Directory Systems Names" registry [IANADSN] of
+ valid keywords for well known attributes used in the LDAPv2 string
+ representation of a distinguished name [RFC1779]. RFC 1779 was
+ obsoleted by RFC 2253.
+
+ Directory systems names are not known to be used in any other
+ context. LDAPv3 uses Object Identifier Descriptors [Section 3.2]
+ (which have a different syntax than directory system names).
+
+ New Directory System Names will no longer be accepted. For
+ historical purposes, the current list of registered names should
+ remain publicly available.
+
+4. Registration Procedure
+
+ The procedure given here MUST be used by anyone who wishes to use a
+ new value of a type described in Section 3 of this document.
+
+ The first step is for the requester to fill out the appropriate form.
+ Templates are provided in Appendix A.
+
+ If the policy is Standards Action, the completed form SHOULD be
+ provided to the IESG with the request for Standards Action. Upon
+ approval of the Standards Action, the IESG SHALL forward the request
+ (possibly revised) to IANA. The IESG SHALL be viewed as the owner of
+ all values requiring Standards Action.
+
+ If the policy is Expert Review, the requester SHALL post the
+ completed form to the <directory at apps.ietf.org> mailing list for
+ public review. The review period is two (2) weeks. If a revised
+ form is later submitted, the review period is restarted. Anyone
+ may subscribe to this list by sending a request to
+ <directory-request at apps.ietf.org>. During the review, objections
+ may be raised by anyone (including the Expert) on the list. After
+ completion of the review, the Expert, based upon public comments,
+ SHALL either approve the request and forward it to the IESG OR deny
+ the request. In either case, the Expert SHALL promptly notify the
+ requester of the action. Actions of the Expert may be appealed
+ [RFC2026]. The Expert is appointed by Applications Area Director(s).
+ The requester is viewed as the owner of values registered under
+ Expert Review.
+
+ If the policy is First Come First Served, the requester SHALL submit
+ the completed form directly to the IANA: <iana at iana.org>. The
+ requester is viewed as the owner of values registered under First
+ Come First Served.
+
+
+
+Zeilenga Best Current Practice [Page 7]
+
+RFC 3383 IANA Considerations for LDAP September 2002
+
+
+ Neither the Expert nor IANA will take position on the claims of
+ copyright or trademarks issues regarding completed forms.
+
+ Prior to submission of the Internet Draft (I-D) to the RFC Editor but
+ after IESG review and tentative approval, the document editor SHOULD
+ revise the I-D to use registered values.
+
+5. Registration Maintenance
+
+ This section discusses maintenance of registrations.
+
+5.1. Lists of Registered Values
+
+ IANA makes lists of registered values readily available to the
+ Internet community on their web site: <http://www.iana.org/>.
+
+5.2. Change Control
+
+ The registration owner MAY update the registration subject to the
+ same constraints and review as with new registrations. In cases
+ where the owner is not unable or unwilling to make necessary updates,
+ the IESG MAY assert ownership in order to update the registration.
+
+5.3. Comments
+
+ For cases where others (anyone other than the owner) have significant
+ objections to the claims in a registration and the owner does not
+ agree to change the registration, comments MAY be attached to a
+ registration upon Expert Review. For registrations owned by the
+ IESG, the objections SHOULD be addressed by initiating a request for
+ Expert Review.
+
+ The form of these requests is ad hoc, but MUST include the specific
+ objections to be reviewed and SHOULD contain (directly or by
+ reference) materials supporting the objections.
+
+6. Security Considerations
+
+ The security considerations detailed in [RFC2434] are generally
+ applicable to this document. Additional security considerations
+ specific to each namespace are discussed in Section 3 where
+ appropriate.
+
+ Security considerations for LDAP are discussed in documents
+ comprising the technical specification [RFC3377].
+
+
+
+
+
+
+Zeilenga Best Current Practice [Page 8]
+
+RFC 3383 IANA Considerations for LDAP September 2002
+
+
+7. Acknowledgment
+
+ This document is a product of the IETF LDAP Revision (LDAPbis)
+ Working Group. Some text was borrowed from "Guidelines for Writing
+ an IANA Considerations Section in RFCs" [RFC2434] by Thomas Narten
+ and Harald Alvestrand.
+
+8. Normative References
+
+ [RFC1155] Rose, M. and K. McCloghrie, "Structure and Identification
+ of Management Information for TCP/IP-based Internets", STD
+ 16, RFC 1155, May 1990.
+
+ [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
+ 3", BCP 9, RFC 2026, October 1996.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
+ Specifications: ABNF", RFC 2234, November 1997.
+
+ [RFC2251] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory
+ Access Protocol (v3)", RFC 2251, December 1997.
+
+ [RFC2252] Wahl, M., Coulbeck, A., Howes, T. and S. Kille,
+ "Lightweight Directory Access Protocol (v3): Attribute
+ Syntax Definitions", RFC 2252, December 1997.
+
+ [RFC2255] Howes, T. and M. Smith, "The LDAP URL Format", RFC 2255,
+ December, 1997.
+
+ [RFC2256] Wahl, M., "A Summary of the X.500(96) User Schema for use
+ with LDAPv3", RFC 2256, December 1997.
+
+ [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO
+ 10646", RFC 2279, January 1998.
+
+ [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
+ IANA Considerations Section in RFCs", BCP 26, RFC 2434,
+ October 1998.
+
+ [RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access
+ Protocol (v3): Technical Specification", RFC 3377,
+ September 2002.
+
+ [IANADSN] IANA, "Directory Systems Names",
+ http://www.iana.org/assignments/directory-system-names
+
+
+
+Zeilenga Best Current Practice [Page 9]
+
+RFC 3383 IANA Considerations for LDAP September 2002
+
+
+ [ISO10646] Universal Multiple-Octet Coded Character Set (UCS) -
+ Architecture and Basic Multilingual Plane, ISO/IEC
+ 10646-1: 1993.
+
+10. Informative References
+
+ [RFC1779] Kille, S., "A String Representation of Distinguished
+ Names", RFC 1779, March 1995.
+
+ [RFC2222] Myers, J., "Simple Authentication and Security Layer
+ (SASL)", RFC 2222, October 1997.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga Best Current Practice [Page 10]
+
+RFC 3383 IANA Considerations for LDAP September 2002
+
+
+Appendix A. Registration Templates
+
+ This appendix provides registration templates for registering new
+ LDAP values.
+
+A.1. LDAP Object Identifier Registration Template
+
+ Subject: Request for LDAP OID Registration
+
+ Person & email address to contact for further information:
+
+ Specification: (I-D)
+
+ Author/Change Controller:
+
+ Comments:
+
+ (Any comments that the requester deems relevant to the request)
+
+A.2. LDAP Protocol Mechanism Registration Template
+
+ Subject: Request for LDAP Protocol Mechanism Registration
+
+ Object Identifier:
+
+ Description:
+
+ Person & email address to contact for further information:
+
+ Usage: (One of Control or Extension)
+
+ Specification: (I-D)
+
+ Author/Change Controller:
+
+ Comments:
+
+ (Any comments that the requester deems relevant to the request)
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga Best Current Practice [Page 11]
+
+RFC 3383 IANA Considerations for LDAP September 2002
+
+
+A.3. LDAP Descriptor Registration Template
+
+ Subject: Request for LDAP Descriptor Registration
+
+ Descriptor (short name):
+
+ Object Identifier:
+
+ Person & email address to contact for further information:
+
+ Usage: (One of attribute type, URL extension,
+ object class, or other)
+
+ Specification: (RFC, I-D, URI)
+
+ Author/Change Controller:
+
+ Comments:
+
+ (Any comments that the requester deems relevant to the request)
+
+A.4. LDAP Attribute Description Option Registration Template
+
+ Subject: Request for LDAP Attribute Description Option Registration
+
+ Option Name:
+
+ Family of Options: (YES or NO)
+
+ Person & email address to contact for further information:
+
+ Specification: (RFC, I-D, URI)
+
+ Author/Change Controller:
+
+ Comments:
+
+ (Any comments that the requester deems relevant to the request)
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga Best Current Practice [Page 12]
+
+RFC 3383 IANA Considerations for LDAP September 2002
+
+
+A.5. LDAP Message Type Registration Template
+
+ Subject: Request for LDAP Message Type Registration
+
+ LDAP Message Name:
+
+ Person & email address to contact for further information:
+
+ Specification: (Approved I-D)
+
+ Comments:
+
+ (Any comments that the requester deems relevant to the request)
+
+A.6. LDAP Result Code Registration Template
+
+ Subject: Request for LDAP Result Code Registration
+
+ Result Code Name:
+
+ Person & email address to contact for further information:
+
+ Specification: (RFC, I-D, URI)
+
+ Author/Change Controller:
+
+ Comments:
+
+ (Any comments that the requester deems relevant to the request)
+
+A.7. LDAP Authentication Method Registration Template
+
+ Subject: Request for LDAP Authentication Method Registration
+
+ Authentication Method Name:
+
+ Person & email address to contact for further information:
+
+ Specification: (RFC, I-D, URI)
+
+ Intended Usage: (One of COMMON, LIMITED-USE, OBSOLETE)
+
+ Author/Change Controller:
+
+ Comments:
+
+ (Any comments that the requester deems relevant to the request)
+
+
+
+
+Zeilenga Best Current Practice [Page 13]
+
+RFC 3383 IANA Considerations for LDAP September 2002
+
+
+Appendix B. Assigned Values
+
+ The following values are currently assigned.
+
+B.1. Object Identifiers
+
+ Currently registered "Internet Private Enterprise Numbers" can be
+ found at <http://www.iana.org/assignments/enterprise-numbers>.
+
+ Currently registered "Internet Directory Numbers" can be found at
+ <http://www.iana.org/assignments/smi-numbers>.
+
+B.2. Protocol Mechanisms
+
+Object Identifier Type Description Reference
+-------------------------- ---- -------------- ---------
+1.2.840.113556.1.4.473 C Sort Request [RFC2891]
+1.2.840.113556.1.4.474 C Sort Response [RFC2891]
+1.3.6.1.4.1.1466.101.119.1 E Dynamic Refresh [RFC2589]
+1.3.6.1.4.1.1466.20037 E Start TLS [RFC2830]
+1.3.6.1.4.1.4203.1.11.1 E Modify Password [RFC3062]
+2.16.840.1.113730.3.4.2 C ManageDsaIT [RFC3296]
+
+Legend
+------------------------
+C => supportedControl
+E => supportedExtension
+
+B.3. Object Identifier Descriptors
+
+NAME Type OID [REF]
+------------------------ ---- -----------------
+account O 0.9.2342.19200300.100.4.5 [RFC1274]
+alias O 2.5.6.1 [RFC2256]
+aliasedEntryName A 2.5.4.1 [X.501]
+aliasedObjectName A 2.5.4.1 [RFC2256]
+altServer A 1.3.6.1.4.1.1466.101.120.6 [RFC2252]
+applicationEntity O 2.5.6.12 [RFC2256]
+applicationProcess O 2.5.6.11 [RFC2256]
+aRecord A 0.9.2342.19200300.100.1.26 [RFC1274]
+associatedDomain A 0.9.2342.19200300.100.1.37 [RFC1274]
+associatedInternetGateway A 1.3.6.1.4.1.453.7.2.8 [RFC2164]
+associatedName A 0.9.2342.19200300.100.1.38 [RFC1274]
+associatedORAddress A 1.3.6.1.4.1.453.7.2.6 [RFC2164]
+associatedX400Gateway A 1.3.6.1.4.1.453.7.2.3 [RFC2164]
+attributeTypes A 2.5.21.5 [RFC2252]
+audio A 0.9.2342.19200300.100.1.55 [RFC1274]
+authorityRevocationList A 2.5.4.38 [RFC2256]
+
+
+
+Zeilenga Best Current Practice [Page 14]
+
+RFC 3383 IANA Considerations for LDAP September 2002
+
+
+bitStringMatch M 2.5.13.16 [RFC2252]
+buildingName A 0.9.2342.19200300.100.1.48 [RFC1274]
+businessCategory A 2.5.4.15 [RFC2256]
+C A 2.5.4.6 [RFC2256]
+cACertificate A 2.5.4.37 [RFC2256]
+calCalAdrURI A 1.2.840.113556.1.4.481 [RFC2739]
+calCalURI A 1.2.840.113556.1.4.478 [RFC2739]
+calCAPURI A 1.2.840.113556.1.4.480 [RFC2739]
+calEntry O 1.2.840.113556.1.5.87 [RFC2739]
+calFBURL A 1.2.840.113556.1.4.479 [RFC2739]
+calOtherCalAdrURIs A 1.2.840.113556.1.4.485 [RFC2739]
+calOtherCalURIs A 1.2.840.113556.1.4.482 [RFC2739]
+calOtherCAPURIs A 1.2.840.113556.1.4.484 [RFC2739]
+calOtherFBURLs A 1.2.840.113556.1.4.483 [RFC2739]
+caseExactIA5Match M 1.3.6.1.4.1.1466.109.114.1 [RFC2252]
+caseIgnoreIA5Match M 1.3.6.1.4.1.1466.109.114.2 [RFC2252]
+caseIgnoreListMatch M 2.5.13.11 [RFC2252]
+caseIgnoreMatch M 2.5.13.2 [RFC2252]
+caseIgnoreOrderingMatch M 2.5.13.3 [RFC2252]
+caseIgnoreSubstringsMatch M 2.5.13.4 [RFC2252]
+certificateRevocationList A 2.5.4.39 [RFC2256]
+certificationAuthority O 2.5.6.16 [RFC2256]
+certificationAuthority-V2 O 2.5.6.16.2 [RFC2256]
+CN A 2.5.4.3 [RFC2256]
+cNAMERecord A 0.9.2342.19200300.100.1.31 [RFC1274]
+co A 0.9.2342.19200300.100.1.43 [RFC1274]
+commonName A 2.5.4.3 [RFC2256]
+country O 2.5.6.2 [RFC2256]
+countryName A 2.5.4.6 [RFC2256]
+createTimestamp A 2.5.18.1 [RFC2252]
+creatorsName A 2.5.18.3 [RFC2252]
+cRLDistributionPoint O 2.5.6.19 [RFC2256]
+crossCertificatePair A 2.5.4.40 [RFC2256]
+DC A 0.9.2342.19200300.100.1.25 [RFC2247]
+dcObject O 1.3.6.1.4.1.1466.344 [RFC2247]
+deltaCRL O 2.5.6.23 [RFC2587]
+deltaRevocationList A 2.5.4.53 [RFC2256]
+description A 2.5.4.13 [RFC2256]
+destinationIndicator A 2.5.4.27 [RFC2256]
+device O 2.5.6.14 [RFC2256]
+distinguishedName A 2.5.4.49 [RFC2256]
+distinguishedNameMatch M 2.5.13.1 [RFC2252]
+distinguishedNameTableEntry O 1.3.6.1.4.1.453.7.1.5 [RFC2293]
+distinguishedNameTableKey A 1.3.6.1.4.1.453.7.2.3 [RFC2293]
+dITContentRules A 2.5.21.2 [RFC2252]
+dITRedirect A 0.9.2342.19200300.100.1.54 [RFC1274]
+dITStructureRules A 2.5.21.1 [RFC2252]
+dmd O 2.5.6.20 [RFC2256]
+
+
+
+Zeilenga Best Current Practice [Page 15]
+
+RFC 3383 IANA Considerations for LDAP September 2002
+
+
+dmdName A 2.5.4.54 [RFC2256]
+dnQualifier A 2.5.4.46 [RFC2256]
+dNSDomain O 0.9.2342.19200300.100.4.15 [RFC1274]
+document O 0.9.2342.19200300.100.4.6 [RFC1274]
+documentAuthor A 0.9.2342.19200300.100.1.14 [RFC1274]
+documentIdentifier A 0.9.2342.19200300.100.1.11 [RFC1274]
+documentLocation A 0.9.2342.19200300.100.1.15 [RFC1274]
+documentPublisher A 0.9.2342.19200300.100.1.56 [RFC1274]
+documentSeries O 0.9.2342.19200300.100.4.8 [RFC1274]
+documentTitle A 0.9.2342.19200300.100.1.12 [RFC1274]
+documentVersion A 0.9.2342.19200300.100.1.13 [RFC1274]
+domain O 0.9.2342.19200300.100.4.13 [RFC2247]
+domainComponent A 0.9.2342.19200300.100.1.25 [RFC2247]
+domainNameForm N 1.3.6.1.4.1.1466.345 [RFC2247]
+domainRelatedObject O 0.9.2342.19200300.100.4.17 [RFC1274]
+drink A 0.9.2342.19200300.100.1.5 [RFC1274]
+dSA O 2.5.6.13 [RFC2256]
+dSAQuality A 0.9.2342.19200300.100.1.49 [RFC1274]
+dynamicObject O 1.3.6.1.4.1.1466.101.119.2 [RFC2589]
+dynamicSubtrees A 1.3.6.1.4.1.1466.101.119.4 [RFC2589]
+enhancedSearchGuide A 2.5.4.47 [RFC2256]
+entryTtl A 1.3.6.1.4.1.1466.101.119.3 [RFC2589]
+extensibleObject O 1.3.6.1.4.1.1466.101.120.111 [RFC2252]
+facsimileTelephoneNumber A 2.5.4.23 [RFC2256]
+favouriteDrink A 0.9.2342.19200300.100.1.5 [RFC1274]
+friendlyCountry O 0.9.2342.19200300.100.4.18 [RFC1274]
+friendlyCountryName A 0.9.2342.19200300.100.1.43 [RFC1274]
+generalizedTimeMatch M 2.5.13.27 [RFC2252]
+generalizedTimeOrderingMatch M 2.5.13.28 [RFC2252]
+generationQualifier A 2.5.4.44 [RFC2256]
+givenName A 2.5.4.42 [RFC2256]
+GN A 2.5.4.42 [RFC2256]
+groupOfNames O 2.5.6.9 [RFC2256]
+groupOfUniqueNames O 2.5.6.17 [RFC2256]
+homePhone A 0.9.2342.19200300.100.1.20 [RFC1274]
+homePostalAddress A 0.9.2342.19200300.100.1.39 [RFC1274]
+homeTelephone A 0.9.2342.19200300.100.1.20 [RFC1274]
+host A 0.9.2342.19200300.100.1.9 [RFC1274]
+houseIdentifier A 2.5.4.51 [RFC2256]
+info A 0.9.2342.19200300.100.1.4 [RFC1274]
+initials A 2.5.4.43 [RFC2256]
+integerFirstComponentMatch M 2.5.13.29 [RFC2252]
+integerMatch M 2.5.13.14 [RFC2252]
+internationaliSDNNumber A 2.5.4.25 [RFC2256]
+janetMailbox A 0.9.2342.19200300.100.1.46 [RFC1274]
+jpegPhoto A 0.9.2342.19200300.100.1.60 [RFC1488]
+knowledgeInformation A 2.5.4.2 [RFC2256]
+L A 2.5.4.7 [RFC2256]
+
+
+
+Zeilenga Best Current Practice [Page 16]
+
+RFC 3383 IANA Considerations for LDAP September 2002
+
+
+labeledURI A 1.3.6.1.4.1.250.1.57 [RFC2079]
+labeledURIObject A 1.3.6.1.4.1.250.3.15 [RFC2079]
+lastModifiedBy A 0.9.2342.19200300.100.1.24 [RFC1274]
+lastModifiedTime A 0.9.2342.19200300.100.1.23 [RFC1274]
+ldapSyntaxes A 1.3.6.1.4.1.1466.101.120.16 [RFC2252]
+locality O 2.5.6.3 [RFC2256]
+localityName A 2.5.4.7 [RFC2256]
+mail A 0.9.2342.19200300.100.1.3 [RFC2798]
+mailPreferenceOption A 0.9.2342.19200300.100.1.47 [RFC1274]
+manager A 0.9.2342.19200300.100.1.10 [RFC1274]
+matchingRules A 2.5.21.4 [RFC2252]
+matchingRuleUse A 2.5.21.8 [RFC2252]
+mcgamTables A 1.3.6.1.4.1.453.7.2.9 [RFC2164]
+mDRecord A 0.9.2342.19200300.100.1.27 [RFC1274]
+member A 2.5.4.31 [RFC2256]
+mixerGateway O 1.3.6.1.4.1.453.7.1.4 [RFC2164]
+mobile A 0.9.2342.19200300.100.1.41 [RFC1274]
+mobileTelephoneNumber A 0.9.2342.19200300.100.1.41 [RFC1274]
+modifiersName A 2.5.18.4 [RFC2252]
+modifyTimestamp A 2.5.18.2 [RFC2252]
+mXRecord A 0.9.2342.19200300.100.1.28 [RFC1274]
+name A 2.5.4.41 [RFC2256]
+nameForms A 2.5.21.7 [RFC2252]
+namingContexts A 1.3.6.1.4.1.1466.101.120.5 [RFC2252]
+nSRecord A 0.9.2342.19200300.100.1.29 [RFC1274]
+numericStringMatch M 2.5.13.8 [RFC2252]
+numericStringSubstringsMatch M 2.5.13.10 [RFC2252]
+O A 2.5.4.10 [RFC2256]
+objectClass A 2.5.4.0 [RFC2256]
+objectClasses A 2.5.21.6 [RFC2252]
+objectIdentifierFirstComponentMatch M 2.5.13.30 [RFC2252]
+objectIdentifiersMatch M 2.5.13.0 [RFC2252]
+octetStringMatch M 2.5.13.17 [RFC2252]
+omittedORAddressComponent O 1.3.6.1.4.1.453.7.1.3 [RFC2164]
+oRAddressComponentType A 1.3.6.1.4.1.453.7.2.7 [RFC2164]
+organization O 2.5.6.4 [RFC2256]
+organizationalPerson O 2.5.6.7 [RFC2256]
+organizationalRole O 2.5.6.8 [RFC2256]
+organizationalStatus A 0.9.2342.19200300.100.1.45 [RFC1274]
+organizationalUnit O 2.5.6.5 [RFC2256]
+organizationalUnitName A 2.5.4.11 [RFC2256]
+organizationName A 2.5.4.10 [RFC2256]
+otherMailbox A 0.9.2342.19200300.100.1.22 [RFC1274]
+OU A 2.5.4.11 [RFC2256]
+owner A 2.5.4.32 [RFC2256]
+pager A 0.9.2342.19200300.100.1.42 [RFC1274]
+pagerTelephoneNumber A 0.9.2342.19200300.100.1.42 [RFC1274]
+person O 2.5.6.6 [RFC2256]
+
+
+
+Zeilenga Best Current Practice [Page 17]
+
+RFC 3383 IANA Considerations for LDAP September 2002
+
+
+personalSignature A 0.9.2342.19200300.100.1.53 [RFC1274]
+personalTitle A 0.9.2342.19200300.100.1.40 [RFC1274]
+photo A 0.9.2342.19200300.100.1.7 [RFC1274]
+physicalDeliveryOfficeName A 2.5.4.19 [RFC2256]
+pilotDSA O 0.9.2342.19200300.100.4.21 [RFC1274]
+pilotObject O 0.9.2342.19200300.100.4.3 [RFC1274]
+pilotOrganization O 0.9.2342.19200300.100.4.20 [RFC1274]
+pilotPerson O 0.9.2342.19200300.100.4.4 [RFC1274]
+pkiCA O 2.5.6.22 [RFC2587]
+pkiUser O 2.5.6.21 [RFC2587]
+postalAddress A 2.5.4.16 [RFC2256]
+postalCode A 2.5.4.17 [RFC2256]
+postOfficeBox A 2.5.4.18 [RFC2256]
+preferredDeliveryMethod A 2.5.4.28 [RFC2256]
+presentationAddress A 2.5.4.29 [RFC2256]
+presentationAddressMatch M 2.5.13.22 [RFC2252]
+protocolInformation A 2.5.4.48 [RFC2256]
+protocolInformationMatch M 2.5.13.24 [RFC2252]
+qualityLabelledData O 0.9.2342.19200300.100.4.22 [RFC1274]
+ref A 2.16.840.1.113730.3.1.34 [RFC3296]
+referral 0 2.16.840.1.113730.3.2.6 [RFC3296]
+registeredAddress A 2.5.4.26 [RFC2256]
+residentialPerson O 2.5.6.10 [RFC2256]
+RFC822LocalPart O 0.9.2342.19200300.100.4.14 [RFC1274]
+RFC822Mailbox A 0.9.2342.19200300.100.1.3 [RFC1274]
+rFC822ToX400Mapping O 1.3.6.1.4.1.453.7.1.1 [RFC2164]
+roleOccupant A 2.5.4.33 [RFC2256]
+room O 0.9.2342.19200300.100.4.7 [RFC1274]
+roomNumber A 0.9.2342.19200300.100.1.6 [RFC1274]
+searchGuide A 2.5.4.14 [RFC2256]
+secretary A 0.9.2342.19200300.100.1.21 [RFC1274]
+seeAlso A 2.5.4.34 [RFC2256]
+serialNumber A 2.5.4.5 [RFC2256]
+simpleSecurityObject O 0.9.2342.19200300.100.4.19 [RFC1274]
+singleLevelQuality A 0.9.2342.19200300.100.1.50 [RFC1274]
+SN A 2.5.4.4 [RFC2256]
+sOARecord A 0.9.2342.19200300.100.1.30 [RFC1274]
+ST A 2.5.4.8 [RFC2256]
+stateOrProvinceName A 2.5.4.8 [RFC2256]
+street A 2.5.4.9 [RFC2256]
+streetAddress A 2.5.4.9 [RFC2256]
+strongAuthenticationUser O 2.5.6.15 [RFC2256]
+subschema O 2.5.20.1 [RFC2252]
+subschemaSubentry A 2.5.18.10 [RFC2252]
+subtree O 1.3.6.1.4.1.453.7.1.1 [RFC2293]
+subtreeMaximumQuality A 0.9.2342.19200300.100.1.52 [RFC1274]
+subtreeMinimumQuality A 0.9.2342.19200300.100.1.51 [RFC1274]
+supportedAlgorithms A 2.5.4.52 [RFC2256]
+
+
+
+Zeilenga Best Current Practice [Page 18]
+
+RFC 3383 IANA Considerations for LDAP September 2002
+
+
+supportedApplicationContext A 2.5.4.30 [RFC2256]
+supportedControl A 1.3.6.1.4.1.1466.101.120.13 [RFC2252]
+supportedExtension A 1.3.6.1.4.1.1466.101.120.7 [RFC2252]
+supportedLDAPVersion A 1.3.6.1.4.1.1466.101.120.15 [RFC2252]
+supportedSASLMechanisms A 1.3.6.1.4.1.1466.101.120.14 [RFC2252]
+surname A 2.5.4.4 [RFC2256]
+table O 1.3.6.1.4.1.453.7.1.2 [RFC2293]
+tableEntry O 1.3.6.1.4.1.453.7.1.3 [RFC2293]
+telephoneNumber A 2.5.4.20 [RFC2256]
+telephoneNumberMatch M 2.5.13.20 [RFC2252]
+telephoneNumberSubstringsMatch M 2.5.13.21 [RFC2252]
+teletexTerminalIdentifier A 2.5.4.22 [RFC2256]
+telexNumber A 2.5.4.21 [RFC2256]
+textEncodedORAddress A 0.9.2342.19200300.100.1.2 [RFC1274]
+textTableEntry O 1.3.6.1.4.1.453.7.1.4 [RFC2293]
+textTableKey A 1.3.6.1.4.1.453.7.2.1 [RFC2293]
+textTableValue A 1.3.6.1.4.1.453.7.2.2 [RFC2293]
+title A 2.5.4.12 [RFC2256]
+top O 2.5.6.0 [RFC2256]
+uid A 0.9.2342.19200300.100.1.1 [RFC2253]
+uniqueIdentifier A 0.9.2342.19200300.100.1.44 [RFC1274]
+uniqueMember A 2.5.4.50 [RFC2256]
+uniqueMemberMatch M 2.5.13.23 [RFC2252]
+userCertificate A 2.5.4.36 [RFC2256]
+userClass A 0.9.2342.19200300.100.1.8 [RFC1274]
+userId A 0.9.2342.19200300.100.1.1 [RFC1274]
+userPassword A 2.5.4.35 [RFC2256]
+userSecurityInformation O 2.5.6.18 [RFC2256]
+x121Address A 2.5.4.24 [RFC2256]
+x400ToRFC822Mapping O 1.3.6.1.4.1.453.7.1.2 [RFC2164]
+x500UniqueIdentifier A 2.5.4.45 [RFC2256]
+
+Legend
+------------------------
+A => Attribute Type
+C => DIT Content Rule
+E => LDAP URL Extension
+M => Matching Rule
+N => Name Form
+O => Object Class
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga Best Current Practice [Page 19]
+
+RFC 3383 IANA Considerations for LDAP September 2002
+
+
+B.4. Attribute Description Options
+
+Option Owner Reference
+---------------- ----- ---------
+binary IESG [RFC2251]
+lang-* IESG [RFC2596]
+
+* family of options
+
+B.5. LDAPMessage types
+
+Name Code Owner Reference
+--------------------------- ---- ----- ---------
+bindRequest 0 IESG [RFC2251]
+bindResponse 1 IESG [RFC2251]
+unbindRequest 2 IESG [RFC2251]
+searchRequest 3 IESG [RFC2251]
+searchResEntry 4 IESG [RFC2251]
+searchResDone 5 IESG [RFC2251]
+modifyRequest 6 IESG [RFC2251]
+modifyResponse 7 IESG [RFC2251]
+addRequest 8 IESG [RFC2251]
+addResponse 9 IESG [RFC2251]
+delRequest 10 IESG [RFC2251]
+delResponse 11 IESG [RFC2251]
+modDNRequest 12 IESG [RFC2251]
+modDNResponse 13 IESG [RFC2251]
+compareRequest 14 IESG [RFC2251]
+compareResponse 15 IESG [RFC2251]
+abandonRequest 16 IESG [RFC2251]
+reserved 17-18 IESG
+searchResRef 19 IESG [RFC2251]
+reserved 20-22 IESG
+extendedReq 23 IESG [RFC2251]
+extendedResp 24 IESG [RFC2251]
+
+B.6. resultCode values
+
+Name Code Owner Reference
+--------------------------- ---- ----- ---------
+success 0 IESG [RFC2251]
+operationsError 1 IESG [RFC2251]
+protocolError 2 IESG [RFC2251]
+timeLimitExceeded 3 IESG [RFC2251]
+sizeLimitExceeded 4 IESG [RFC2251]
+compareFalse 5 IESG [RFC2251]
+compareTrue 6 IESG [RFC2251]
+authMethodNotSupported 7 IESG [RFC2251]
+
+
+
+Zeilenga Best Current Practice [Page 20]
+
+RFC 3383 IANA Considerations for LDAP September 2002
+
+
+strongAuthRequired 8 IESG [RFC2251]
+reserved (partialResults) 9 IESG [RFC2251]
+referral 10 IESG [RFC2251]
+adminLimitExceeded 11 IESG [RFC2251]
+unavailableCriticalExtension 12 IESG [RFC2251]
+confidentialityRequired 13 IESG [RFC2251]
+saslBindInProgress 14 IESG [RFC2251]
+noSuchAttribute 16 IESG [RFC2251]
+undefinedAttributeType 17 IESG [RFC2251]
+inappropriateMatching 18 IESG [RFC2251]
+constraintViolation 19 IESG [RFC2251]
+attributeOrValueExists 20 IESG [RFC2251]
+invalidAttributeSyntax 21 IESG [RFC2251]
+noSuchObject 32 IESG [RFC2251]
+aliasProblem 33 IESG [RFC2251]
+invalidDNSyntax 34 IESG [RFC2251]
+reserved (isLeaf) 35 IESG [RFC2251]
+aliasDereferencingProblem 36 IESG [RFC2251]
+reserved 37-47 IESG
+inappropriateAuthentication 48 IESG [RFC2251]
+invalidCredentials 49 IESG [RFC2251]
+insufficientAccessRights 50 IESG [RFC2251]
+busy 51 IESG [RFC2251]
+unavailable 52 IESG [RFC2251]
+unwillingToPerform 53 IESG [RFC2251]
+loopDetect 54 IESG [RFC2251]
+reserved 55-63 IESG
+namingViolation 64 IESG [RFC2251]
+objectClassViolation 65 IESG [RFC2251]
+notAllowedOnNonLeaf 66 IESG [RFC2251]
+notAllowedOnRDN 67 IESG [RFC2251]
+entryAlreadyExists 68 IESG [RFC2251]
+objectClassModsProhibited 69 IESG [RFC2251]
+reserved (resultsTooLarge) 70 IESG [RFC2251]
+reserved 71-79 IESG
+other 80 IESG [RFC2251]
+reserved (APIs) 81-90 IESG [RFC2251]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga Best Current Practice [Page 21]
+
+RFC 3383 IANA Considerations for LDAP September 2002
+
+
+B.7. Bind Authentication Method
+
+Method Value Owner Usage Reference
+------ ----- ----- ----------- -----------------
+simple 0 IESG LIMITED USE [RFC2251,RFC2829]
+krbv42LDAP 1 IESG OBSOLETE* [RFC1777]
+krbv42DSA 2 IESG OBSOLETE* [RFC1777]
+sasl 3 IESG COMMON [RFC2251,RFC2829]
+
+* These LDAPv2-only mechanisms were deprecated in favor of the
+LDAPv3 SASL authentication method, specifically the GSSAPI mechanism.
+
+Author's Address
+
+ Kurt D. Zeilenga
+ OpenLDAP Foundation
+
+ EMail: Kurt at OpenLDAP.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga Best Current Practice [Page 22]
+
+RFC 3383 IANA Considerations for LDAP September 2002
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2002). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga Best Current Practice [Page 23]
+
Added: openldap/vendor/openldap-release/doc/rfc/rfc3663.txt
===================================================================
--- openldap/vendor/openldap-release/doc/rfc/rfc3663.txt (rev 0)
+++ openldap/vendor/openldap-release/doc/rfc/rfc3663.txt 2007-09-15 10:38:52 UTC (rev 844)
@@ -0,0 +1,1179 @@
+
+
+
+
+
+
+Network Working Group A. Newton
+Request for Comments: 3663 VeriSign, Inc.
+Category: Experimental December 2003
+
+
+ Domain Administrative Data
+ in Lightweight Directory Access Protocol (LDAP)
+
+Status of this Memo
+
+ This memo defines an Experimental Protocol for the Internet
+ community. It does not specify an Internet standard of any kind.
+ Discussion and suggestions for improvement are requested.
+ Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2003). All Rights Reserved.
+
+Abstract
+
+ Domain registration data has typically been exposed to the general
+ public via Nicname/Whois for administrative purposes. This document
+ describes the Referral Lightweight Directory Access Protocol (LDAP)
+ Service, an experimental service using LDAP and well-known LDAP types
+ to make domain administrative data available.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Newton Experimental [Page 1]
+
+RFC 3663 Domain Administrative Data in LDAP December 2003
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 1.1. Historical Directory Services for Domain Registration
+ Data . . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 1.2. Motivations. . . . . . . . . . . . . . . . . . . . . . . 3
+ 1.3. Abbreviations Used . . . . . . . . . . . . . . . . . . . 4
+ 2. Service Description. . . . . . . . . . . . . . . . . . . . . . 4
+ 3. Registry LDAP Service. . . . . . . . . . . . . . . . . . . . . 6
+ 3.1. TLD DIT. . . . . . . . . . . . . . . . . . . . . . . . . 6
+ 3.1.1. DIT Structure. . . . . . . . . . . . . . . . . . 6
+ 3.1.2. Allowed Searches . . . . . . . . . . . . . . . . 7
+ 3.1.3. Access Control . . . . . . . . . . . . . . . . . 7
+ 3.2. Name Server DIT. . . . . . . . . . . . . . . . . . . . . 8
+ 3.2.1. DIT Structure. . . . . . . . . . . . . . . . . . 8
+ 3.2.2. Allowed Searches . . . . . . . . . . . . . . . . 8
+ 3.3. Registrar Referral DIT . . . . . . . . . . . . . . . . . 9
+ 3.3.1. DIT Structure. . . . . . . . . . . . . . . . . . 9
+ 4. Registrar LDAP Service . . . . . . . . . . . . . . . . . . . . 10
+ 4.1. TLD DIT. . . . . . . . . . . . . . . . . . . . . . . . . 10
+ 4.1.1. DIT Structure. . . . . . . . . . . . . . . . . . 10
+ 4.1.2. Allowed Searches . . . . . . . . . . . . . . . . 11
+ 4.1.3. Access Control . . . . . . . . . . . . . . . . . 11
+ 4.2. Name Server and Contact DIT. . . . . . . . . . . . . . . 12
+ 4.2.1. DIT Structure. . . . . . . . . . . . . . . . . . 12
+ 4.2.2. Allowed Searches . . . . . . . . . . . . . . . . 13
+ 5. Clients. . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
+ 6. Lessons Learned. . . . . . . . . . . . . . . . . . . . . . . . 14
+ 6.1. Intra-Server Referrals . . . . . . . . . . . . . . . . . 14
+ 6.2. Inter-Server Referrals . . . . . . . . . . . . . . . . . 15
+ 6.3. Common DIT . . . . . . . . . . . . . . . . . . . . . . . 15
+ 6.4. Universal Client . . . . . . . . . . . . . . . . . . . . 16
+ 6.5. Targeting Searches by Tier . . . . . . . . . . . . . . . 16
+ 6.6. Data Mining. . . . . . . . . . . . . . . . . . . . . . . 16
+ 7. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 16
+ 8. Internationalization Considerations. . . . . . . . . . . . . . 16
+ 9. Security Considerations. . . . . . . . . . . . . . . . . . . . 17
+ 10. Intellectual Property Statement. . . . . . . . . . . . . . . . 17
+ 11. Normative References . . . . . . . . . . . . . . . . . . . . . 18
+ Appendix A. Other Work. . . . . . . . . . . . . . . . . . . . . . 19
+ Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . . 19
+ Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20
+ Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 21
+
+
+
+
+
+
+
+
+Newton Experimental [Page 2]
+
+RFC 3663 Domain Administrative Data in LDAP December 2003
+
+
+1. Introduction
+
+ This document describes the Referral Lightweight Directory Access
+ Protocol (LDAP) Service, an experimental project launched by
+ VeriSign, Inc., to explore the use of LDAP and LDAP-related
+ technologies for use as a directory service of administrative domain
+ registration information.
+
+1.1. Historical Directory Services for Domain Registration Data
+
+ The original National Science Foundation contract for the InterNIC
+ called for the creation of an X.500 directory service for the
+ administrative needs of the domain registration data and information.
+ Due to problems with implementations of X.500 server software, a
+ server based on the Nicname/Whois [1] protocol was temporarily
+ erected.
+
+ In 1994, the Rwhois [3] protocol was introduced to enhance the
+ Nicname/Whois protocol. This directory service never gained wide
+ acceptance for use with domain data.
+
+ Presently, ICANN requires the operation of Nicname/Whois servers by
+ registries and registrars of generic Top-Level Domains (TLD's).
+
+1.2. Motivations
+
+ With the recent split in functional responsibilities between
+ registries and registrars, the constant misuse and data-mining of
+ domain registration data, and the difficulties with machine-
+ readability of Nicname/Whois output, the creation of the Referral
+ LDAP Service had the following motivations:
+
+ o Use a mechanism native to the directory protocol to refer clients
+ from inquiries about specific domains made at a registry to the
+ appropriate domain within the appropriate directory service at a
+ registrar.
+
+ o Limit access to domain data based on authentication of the client.
+
+ o Provide structured queries and well-known and structured results.
+
+ o Use a directory service technology already in general use.
+
+ Given these general criteria, LDAP [5] was selected as the protocol
+ for this directory service. The decision was also made to restrict
+ the use of LDAP to features most readily available in common
+ implementations. Therefore, a goal was set to not define any new
+ object classes, syntaxes, or matching rules.
+
+
+
+Newton Experimental [Page 3]
+
+RFC 3663 Domain Administrative Data in LDAP December 2003
+
+
+ The experiment was successful in exploring how LDAP might be used in
+ this context and demonstrating the level of customization required
+ for an operational service. Conclusions and observations about this
+ experiment are outlined in Section 6.
+
+1.3. Abbreviations Used
+
+ The following abbreviations are used to describe the nature of this
+ experiment:
+
+ TLD: Top-Level Domain. Refers to the domain names just beneath
+ the root in the Domain Name System. This experiment used the
+ TLD's .com, .net, .org, and .edu.
+
+ SLD: Second-Level Domain. Refers to the domain names just beneath
+ a TLD in the Domain Name System. An example of such a domain name
+ would be "example.com".
+
+ DIT: Directory Information Tree. One of many hierarchies of data
+ entries in an LDAP server.
+
+ DN: Distinguished Name. The unique name of an entry in a DIT.
+
+ cn: common name. See RFC 2256 [7].
+
+ dc: domain component. See RFC 2247 [4].
+
+ uid: user id. See RFC 2798 [9].
+
+2. Service Description
+
+ The service is composed of three distinct server types: a registry
+ LDAP server, registrar LDAP servers, and registrant LDAP servers.
+
+ The registry LDAP server contains three Directory Information Trees
+ (DIT's).
+
+ o The Top-Level Domain DIT's follow the DNS hierarchy for domains
+ (e.g., dc=foo,dc=com).
+
+ o The name server DIT allows a view of the name servers, many of
+ which serve multiple domains.
+
+ o The registrar-referral DIT provides referrals from the registry
+ into the respective TLD DIT of the registrars (on a TLD basis).
+
+
+
+
+
+
+Newton Experimental [Page 4]
+
+RFC 3663 Domain Administrative Data in LDAP December 2003
+
+
+ The registrar LDAP server contains two types of DIT's.
+
+ o The TLD DIT follows the DNS hierarchy for domains (e.g.,
+ dc=foo,dc=com) and parallels the TLD DIT of the registry.
+
+ o The name server and contact DIT allow a view of the name servers
+ and contacts, many of which are associated and serve multiple
+ domains.
+
+ There is no specification on the DIT or schema for the registrant
+ LDAP server. Referrals from the registrar server to the registrant
+ server are provided solely for the purpose of allowing the registrant
+ direct control over extra administrative information as it relates to
+ a particular domain.
+
+ Access control for this service is merely a demonstration of using a
+ Distinguished Name (DN) and password. Should registries and
+ registrars uniformly adopt LDAP as a means to disseminate domain
+ registration data, standardization of these DN's would need to be
+ undertaken based on each type of user base.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Newton Experimental [Page 5]
+
+RFC 3663 Domain Administrative Data in LDAP December 2003
+
+
+3. Registry LDAP Service
+
+3.1. TLD DIT
+
+3.1.1. DIT Structure
+
+ The registry TLD DIT has the following structural hierarchy:
+
+ TLD (e.g., dc=net)
+ |
+ |
+ -------------------------------------
+ | |
+ SLD (e.g., dc=foo,dc=net) SLD (e.g., dc=bar,dc=net)
+ | |
+ --------------------- ---------------------
+ | | | | | |
+ name server | | name server | |
+ (e.g., | | (e.g., | |
+ cn=nameserver1, | | cn=nameserver1, | |
+ dc=foo,dc=net ) | | dc=bar,dc=net ) | |
+ | | | |
+ name server | name server |
+ (e.g., | (e.g., |
+ cn=nameserver2, | cn=nameserver2, |
+ dc=foo,dc=net ) | dc=bar,dc=net ) |
+ | |
+ registrar referral registrar referral
+ (e.g., (e.g.,
+ cn=registrar, cn=registrar,
+ dc=foo,dc=net ) dc=bar,dc=net )
+
+
+ Figure 1: Registry DIT Overview
+
+ The root of a TLD DIT is an entry of objectclass domain as specified
+ by RFC 2247 [4] and represents a top-level domain.
+
+ The second tier of the DIT represents second-level domains. Each of
+ these entries is of objectclass domain as specified by RFC 2247 [4].
+ The description attribute on these entries often contains descriptive
+ text giving the name of the registrar through which these domains
+ have been registered.
+
+ The third tier contains entries specific to each second-level domain.
+ Name server entries are of objectclass ipHost as specified by RFC
+ 2307 [8]. The distinguished names of these name server entries are
+ algorithmically calculated, where the first component is the word
+
+
+
+Newton Experimental [Page 6]
+
+RFC 3663 Domain Administrative Data in LDAP December 2003
+
+
+ "nameserver" concatenated with an index number of the name server
+ entry and the remaining components are the appropriate domain names.
+ There is no specification relating the value of the name server entry
+ to the index it may be assigned other than it is unique and
+ consistent with respect to the client session. This tier also
+ contains the referral from the registry to the registrar. This
+ referral is a direct referral to the entry in the appropriate
+ registrar LDAP server corresponding to the domain name that the
+ referral falls beneath in this DIT.
+
+3.1.2. Allowed Searches
+
+ Because of the vast number of entries contained within this DIT, only
+ certain types of searches are allowed. Allowing any search
+ expressible via LDAP would lead to expensive searches that would be
+ far too costly for a publicly available service. The searches
+ allowed are as follows:
+
+ o One-level scoped searches based at the root of the DIT. Substring
+ matching is allowed on dc attributes, but the substring must be at
+ least be 3 characters in length.
+
+ o Base search based at the root of the DIT.
+
+ o Base, one-level, and sub-tree searches based at any second level
+ domain name (the second tier) and below.
+
+3.1.3. Access Control
+
+ The registry TLD DIT only has one access control type. When a client
+ binds with a DN of "cn=trademark" and password of "attorney", the
+ second-level domain entries also take on an objectclass of
+ extensibleObject with the added attributes of "createddate" and
+ "registrationexpirationdate", which are of type Generalized Time, as
+ specified by RFC 2252 [6].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Newton Experimental [Page 7]
+
+RFC 3663 Domain Administrative Data in LDAP December 2003
+
+
+3.2. Name Server DIT
+
+3.2.1. DIT Structure
+
+ The registry name server DIT has the following structural hierarchy:
+
+ (o=nsiregistry.com)
+ |
+ |
+ -------------------------------------
+ | | |
+ name server name server name server
+ (cn=ns1.foo.net) (cn=ns.bar.com) (cn=named.acme.org)
+
+
+ Figure 2: Registry DIT Overview
+
+ The root of a name server DIT is an entry of objectclass organization
+ as specified by RFC 1617 [2]. It has no significance other than to
+ serve as the root of the DIT.
+
+ The second tier of this DIT represents name servers. Each of these
+ entries is of objectclass ipHost, as specified by RFC 2307 [8].
+
+3.2.2. Allowed Searches
+
+ Because of the vast number of entries contained within this DIT, only
+ certain types of searches are allowed. Allowing any search
+ expressible via LDAP would lead to searches far too costly for a
+ publicly available service. The searches allowed are as follows:
+
+ o One-level and sub-tree scoped searches based at the root of the
+ DIT if a filter on the cn attribute is provided.
+
+ o Base search based at the root of the DIT.
+
+ o Base, one-level, and sub-tree searches based at any name server
+ entry.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Newton Experimental [Page 8]
+
+RFC 3663 Domain Administrative Data in LDAP December 2003
+
+
+3.3. Registrar Referral DIT
+
+3.3.1. DIT Structure
+
+ The registry registrar-referral DIT has the following structural
+ hierarchy:
+
+ (o=tlds)
+ |
+ |
+ -------------------------------
+ | | | |
+ tld tld tld tld
+ (dc=net) (dc=com) (dc=org) (dc=edu)
+ | | | |
+ : : | :
+ : : | :
+ |
+ ---------------------------
+ | | |
+ referral to referral to referral to
+ registrar 1 registrar 2 registrar n
+ dc=org DIT dc=org DIT dc=org DIT
+
+
+ Figure 3: Registry Referral DIT Overview
+
+ The root of the registrar referral DIT is an entry of objectclass
+ organization, as specified by RFC 1617 [2]. It has no significance
+ other than to serve as the root of this DIT.
+
+ The second tier of this DIT represents top-level domains. Each of
+ these entries is of objectclass domain, as specified by RFC 2247 [4].
+
+ Underneath each TLD entry, the third tier contains referrals to the
+ appropriate TLD DIT of each registrar.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Newton Experimental [Page 9]
+
+RFC 3663 Domain Administrative Data in LDAP December 2003
+
+
+4. Registrar LDAP Service
+
+4.1. TLD DIT
+
+4.1.1. DIT Structure
+
+ The registrar TLD DIT, which is similar to the registry TLD DIT, has
+ the following structural hierarchy:
+
+ TLD (e.g., dc=net)
+ |
+ |
+ ------------------------------------------------
+ | | |
+ SLD (e.g., dc=foo,dc=net) : :
+ | : :
+ ---------------------------------------------
+ | | |
+ | | |
+ name server contact referral to
+ (e.g., cn=nameserver1, (e.g., cn=contact1, registrant
+ dc=foo,dc=net ) dc=foo,dc=net )
+ |
+ |
+ name server contact
+ (e.g., cn=contact,
+ cn=nameserver1,
+ dc=foo,dc=net )
+
+ Figure 4: Registrar DIT Overview
+
+ The root of a TLD DIT is an entry of objectclass domain, as specified
+ by RFC 2247 [4] and represents a top-level domain.
+
+ The second tier of the DIT represents second-level domains. Each of
+ these entries is of objectclass domain, as specified by RFC 2247 [4].
+
+ The third tier contains entries specific to each second-level domain.
+ The entries at this level are as follows:
+
+ o Name server entries are of objectclass ipHost, as specified by RFC
+ 2307 [8]. The distinguished names of these name server entries
+ are algorithmically calculated where the first component is the
+ word "nameserver" concatenated with an index number of the name
+ server entry and the remaining components are the appropriate
+ domain names. There is no specification relating the value of the
+ name server entry to the index it may be assigned other than it is
+ unique and consistent with respect to the client session.
+
+
+
+Newton Experimental [Page 10]
+
+RFC 3663 Domain Administrative Data in LDAP December 2003
+
+
+ o Contact entries are of objectclass inetOrgPerson, as specified by
+ RFC 2798 [9]. The distinguished names of these contact entries
+ are algorithmically calculated, where the first component is the
+ word "contact" concatenated with an index number of the contact
+ and the remaining components are the appropriate domain names.
+ There is no specification relating the value of the contact entry
+ to the index it may be assigned other than it is unique and
+ consistent with respect to the client session. The description
+ attribute of the entry contains the role for which a contact is
+ related to a domain. These roles are identified as "Admin
+ Contact", "Technical Contact", and "Billing Contact", and may
+ appear in any order.
+
+ o Finally, this third tier contains the referral from the registrar
+ to the registrant.
+
+ The fourth tier only contains name server contact entries. These
+ entries are of objectclass inetOrgPerson, as specified by RFC 2798
+ [9].
+
+4.1.2. Allowed Searches
+
+ Because of the vast number of entries contained within this DIT, only
+ certain types of searches are allowed. Allowing any search
+ expressible via LDAP would lead to searches far too costly for a
+ publicly available service. The searches allowed are as follows:
+
+ o One-level scoped searches based at the root of the DIT. Substring
+ matching is allowed on dc and o attributes, but the substring must
+ be at least 3 characters in length.
+
+ o Base search based at the root of the DIT.
+
+ o Base, one-level, and sub-tree searches based at any second level
+ domain name (the second tier) and below.
+
+4.1.3. Access Control
+
+ The registrar TLD DIT has two access control types. When binding
+ anonymously, a client only sees dc, o, and c attributes of the
+ second-level domain entries. When a client binds with a DN of
+ "cn=trademark" and password of "attorney", all of the other
+ attributes normally available on entries of objectclass domain are
+ visible if they have values. In addition, if a client binds with the
+ DN of a contact and password of "password", all attributes for
+ second-level domain entries for which the bind DN has a relation are
+ visible.
+
+
+
+
+Newton Experimental [Page 11]
+
+RFC 3663 Domain Administrative Data in LDAP December 2003
+
+
+4.2. Name Server and Contact DIT
+
+4.2.1. DIT Structure
+
+ The registrar name server and contact DIT has the following
+ structural hierarchy:
+
+ (o=nsi.com)
+ |
+ |
+ --------------------------------------
+ | |
+ Contacts Name Servers
+ (ou=contacts) (ou=name servers)
+ | |
+ ----------------- ------------------------
+ | | | | | |
+ Contact : : Name Server : :
+ (uid=handle) : : (cn=handle) : :
+ |
+ Name Server
+ Contact
+ (cn=contact1)
+
+ Figure 5: Registrar DIT Overview
+
+ The first tier of the name server and contact DIT is an entry of
+ objectclass organization, as specified by RFC 1617 [2].
+
+ The second tier of the DIT contains two entries, each of which is of
+ objectclass organizationalUnit, as specified by RFC 2256 [7]. One
+ entry represents the part of the DIT containing contacts and the
+ other entry represents the part of the DIT containing name servers.
+
+ Entries underneath the contacts organizationalUnit entry are of
+ objectclass inetOrgPerson and represent contacts registered with the
+ registrar. Their RDN is composed of the uid attribute. The uid
+ attribute's value is a unique identifier or handle that is registrar
+ assigned.
+
+ Entries underneath the name server organizationalUnit entry are of
+ objectclass ipHost and represent name servers registered with the
+ registrar. Their RDN is composed of the cn attribute. The cn
+ attribute's value is a unique identifier or handle that is registrar
+ assigned. Each name server entry may optionally have children
+ entries of objectclass inetOrgPerson. These entries represent the
+ contacts of the name server they fall beneath.
+
+
+
+
+Newton Experimental [Page 12]
+
+RFC 3663 Domain Administrative Data in LDAP December 2003
+
+
+4.2.2. Allowed Searches
+
+ Because of the vast number of entries contained within this DIT, only
+ certain types of searches are allowed. Allowing any search
+ expressible via LDAP would lead to searches far too costly for a
+ publicly available service. The searches allowed are as follows:
+
+ o One-level and base searches at the root of the DIT.
+
+ o Sub-tree searches at the root of the DIT using cn and uid
+ attributes as a filter.
+
+ o Base searches at either entry of the second tier.
+
+ o One-level and sub-tree searches at either entry of the second
+ tier, using cn or uid attributes as a filter.
+
+ o Base, one-level, and sub-tree searches based at any contact or
+ name server entry and below.
+
+5. Clients
+
+ Early scoping and analysis of this project were based on the use of
+ output from command line clients, specifically the "ldapsearch"
+ command present with many implementations of LDAP servers. Our
+ survey of this tool, available from many vendors, showed that
+ referral chasing was difficult to control or predict, and the
+ behavior between these implementations with respect to referral
+ chasing was inconsistent.
+
+ Based on the limited nature of the expressive capabilities present
+ with just command line tools, searches involving nested queries or
+ advanced referral chasing were deemed the domain of clients making
+ direct use of LDAP client libraries. Three of these types of clients
+ were produced: a web-based client, a cross-platform C-based client,
+ and a Java client. No significant deficiencies or problems were
+ found with the LDAP client libraries in the construction of these
+ clients, and the level of control provided by their programming
+ interfaces was adequate to create the necessary searches. Instead,
+ most of the problems encountered with these clients were based on
+ usability concerns.
+
+ It was found that the web-based client caused a great amount of
+ confusion for users not familiar with LDAP or Nicname/Whois with
+ respect to the underlying technology and the network model. Thus,
+ many users believed the web-based client to be the only interface to
+ the data and were unaware or confused by the intermediate LDAP
+ protocol. In addition, it was difficult to express to users the
+
+
+
+Newton Experimental [Page 13]
+
+RFC 3663 Domain Administrative Data in LDAP December 2003
+
+
+ registry-registrar-registrant service model in adequate terms from
+ search results where the results could be rendered properly among the
+ various common web browsers.
+
+ Both the C and Java based clients were built to be both graphical and
+ cross-platform (in the case of the C-based client, the Linux and
+ Windows platforms were chosen as targets). The LDAP client libraries
+ chosen for both clients proved to be quite capable and offered the
+ necessary levels of control for conducting nested queries and
+ advanced referral chasing. Expectations at the outset for
+ construction of both clients, based on past experience, were that the
+ C-based client would not only perform better than the Java client but
+ also have a better appearance. In reality, these assumptions were
+ incorrect as there was no perceivable difference in performance and
+ the look of the Java client was often considered to be far superior
+ to its counter-part. In addition, the Java client required much less
+ time to create. Both clients are available under the terms of an
+ open source license. Though it is impossible to have accurate
+ measurements of their popularity, through monitoring and feedback it
+ was perceived that the web-based client had far greater use.
+
+6. Lessons Learned
+
+ Based on the experience of piloting this experimental service,
+ feedback from users of the service, and general comments and
+ observations of current and common opinions, the following items have
+ been noted.
+
+6.1. Intra-Server Referrals
+
+ Original analysis of the data set to be used revealed a high degree
+ of relationships between name servers, contacts, and domains.
+ Storing the data in non-normalized form according to the DIT outlined
+ in this document would make an original relational dataset of roughly
+ 20 million objects explode to over 115 million objects.
+
+ To combat this problem, the first pass at defining the DIT's made
+ heavy use of referrals between the TLD DIT's and the name server and
+ contact DIT's. The use of the 'alias' objectclass was considered but
+ ruled out in hopes of using referrals for load balancing across
+ servers (i.e., placing each TLD DIT on a separate server, and
+ separate servers for the name server and contact DIT's). However,
+ initial testing with the 'ldapsearch' command found inconsistencies
+ with the interpretation of the referrals and how they were managed.
+ Not only were the results inconsistent between implementations, but
+ many of these clients would easily get caught in referral loops.
+
+
+
+
+
+Newton Experimental [Page 14]
+
+RFC 3663 Domain Administrative Data in LDAP December 2003
+
+
+ The final solution to the problem was to create a customized back-end
+ data store containing the data in a normalized form. This gave the
+ client the appearance of having a non-normalized data set which
+ required no intra-server referrals. Aliases may have been a better
+ solution, however our interpretation of their output with
+ implementations of the 'ldapsearch' tool was not satisfactory. It
+ was also later learned that some LDAP server implementations place
+ certain restrictions on aliases that would have conflicted with our
+ overall DIT structure. In the end, it was felt that a customized
+ back-end would be required by any server with a large data-set, but
+ smaller data-sets for less populated domains could easily use off-
+ the-shelf implementations.
+
+6.2. Inter-Server Referrals
+
+ The modeling of the overall service to provide the split in
+ operational responsibility between registry and registrar required
+ the use of referrals (i.e., the two servers would not be operated by
+ the same organization, therefore would most likely not co-exist on
+ the same physical machine or network). The chief problem with LDAP
+ referrals returned for this purpose grew out of the need to limit
+ data returned to the client and the priority given to referrals. It
+ was quite easy to cause a sub-tree query at certain levels, for
+ instance a TLD level, to return nothing but referrals. This was true
+ because referrals would be returned out of the scope of the supplied
+ search filter and therefore would fill the result set to its limit,
+ normally set to 50 entries.
+
+ In certain use cases, a result set with nothing but referrals was
+ desired (e.g., o=tlds). However, even in these cases it was possible
+ for some referrals to not be returned due to the size limit. In this
+ case, it was felt that a result set of 50 referrals, the default for
+ the size limit in most cases, was too large for any practical use by
+ a client and was a failing of query distribution in general rather
+ than a limitation of LDAP.
+
+6.3. Common DIT
+
+ Because of the nature of software development, the graphical and web
+ clients were developed after the development of the server software.
+ The 'ldapsearch' client was used for testing and development during
+ server software creation. It was not until the creation of more
+ advanced clients that it was discovered that the design decision of
+ uniform DIT naming should have been made. Technically, this would
+ have allowed for slightly better software modularization and re-use.
+ In addition, the use of a company name in the DIT structure did not
+ allow the easy integration of another domain registry, as in the
+ registry-registrar model. Not only would clients have to be
+
+
+
+Newton Experimental [Page 15]
+
+RFC 3663 Domain Administrative Data in LDAP December 2003
+
+
+ reconfigured for each new registry operator, but this would most
+ likely have social implications as well.
+
+6.4. Universal Client
+
+ The construction of the clients revealed yet another misconception.
+ Though this project used a generic directory service technology, the
+ clients required a high-degree of algorithmic knowledge about the DIT
+ structure and schemas being used. The graphical clients could not be
+ used against an LDAP service with another DIT or schema. Therefore,
+ a generic or universal client, one that could be used for all LDAP
+ applications, would either not be able to make full use of the data
+ provided by the service or would be far too complex for operation by
+ the average user.
+
+6.5. Targeting Searches by Tier
+
+ The network model for this service was divided into three tiers:
+ registry, registrar, and registrant. Despite this, all searches
+ needed to start at the registry level causing overhead for searches
+ that could be targeted at a select tier. This service did not
+ implement a solution to this problem, such as using SRV and/or NAPTR
+ records in DNS to allow a client to find a responsible LDAP server.
+
+6.6. Data Mining
+
+ Section 3.1.2 and Section 4.1.2 describe the searches allowed by this
+ service. However, the most common question asked by users of the
+ service revolved around getting around these restrictions. Because
+ browsing at the TLD level was not permitted, many users asked about
+ the feasibility of using recursive dictionary queries to circumvent
+ the search restrictions.
+
+ It should be noted that many operators of Nicname/Whois server
+ consider this practice to be data mining and often refer to it
+ specifically as a dictionary attack.
+
+7. IANA Considerations
+
+ There are no applicable IANA considerations presented in this
+ document.
+
+8. Internationalization Considerations
+
+ The domain administrative data in this service did not cover
+ Internationalized Domain Names (IDN's).
+
+
+
+
+
+Newton Experimental [Page 16]
+
+RFC 3663 Domain Administrative Data in LDAP December 2003
+
+
+9. Security Considerations
+
+ This experiment did not endeavor to use security mechanisms beyond
+ those readily available in LDAP [5]. Section 3.1.3 and Section 4.1.3
+ describe the various access controls used within the scope of the
+ defined security mechanisms. While these mechanisms were adequate
+ for this experimental deployment, they would not be adequate for a
+ production environment, and they should not be taken as a model for
+ those contemplating deployment on the Internet.
+
+10. Intellectual Property Statement
+
+ The IETF takes no position regarding the validity or scope of any
+ intellectual property or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; neither does it represent that it
+ has made any effort to identify any such rights. Information on the
+ IETF's procedures with respect to rights in standards-track and
+ standards-related documentation can be found in BCP-11. Copies of
+ claims of rights made available for publication and any assurances of
+ licenses to be made available, or the result of an attempt made to
+ obtain a general license or permission for the use of such
+ proprietary rights by implementors or users of this specification can
+ be obtained from the IETF Secretariat.
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Newton Experimental [Page 17]
+
+RFC 3663 Domain Administrative Data in LDAP December 2003
+
+
+11. Normative References
+
+ [1] Harrenstien, K., Stahl, M. and E. Feinler, "NICNAME/WHOIS", RFC
+ 954, October 1985.
+
+ [2] Barker, P., Kille, S. and T. Lenggenhager, "Naming and
+ Structuring Guidelines for X.500 Directory Pilots", RFC 1617,
+ May 1994.
+
+ [3] Williamson, S., Kosters, M., Blacka, D., Singh, J. and K.
+ Zeilstra, "Referral Whois (RWhois) Protocol V1.5", RFC 2167,
+ June 1997.
+
+ [4] Kille, S., Wahl, M., Grimstad, A., Huber, R. and S. Sataluri,
+ "Using Domains in LDAP/X.500 Distinguished Names", RFC 2247,
+ January 1998.
+
+ [5] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access
+ Protocol (v3)", RFC 2251, December 1997.
+
+ [6] Wahl, M., Coulbeck, A., Howes, T. and S. Kille, "Lightweight
+ Directory Access Protocol (v3): Attribute Syntax Definitions",
+ RFC 2252, December 1997.
+
+ [7] Wahl, M., "A Summary of the X.500(96) User Schema for use with
+ LDAPv3", RFC 2256, December 1997.
+
+ [8] Howard, L., "An Approach for Using LDAP as a Network Information
+ Service", RFC 2307, March 1998.
+
+ [9] Smith, M., "Definition of the inetOrgPerson LDAP Object Class",
+ RFC 2798, April 2000.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Newton Experimental [Page 18]
+
+RFC 3663 Domain Administrative Data in LDAP December 2003
+
+
+Appendix A. Other Work
+
+ In addition to the deployment of servers and development of clients,
+ VeriSign conducted two sub-projects related to this experiment.
+
+ The first project was a Nicname/Whois-to-LDAP gateway. The goal of
+ the project was to create an LDAP server for use by registrars to
+ deploy in front of their Nicname/Whois servers. This gateway would
+ take LDAP requests, translate them to Nicname/Whois requests, issue
+ the request to a specific Nicname/Whois server deployed on port 43,
+ interpret the response, and return LDAP result sets. Because of the
+ unspecified nature of Nicname/Whois result sets, the gateway was
+ programmed to specifically recognize only the output of three
+ distinct registrars. While this gateway proved valuable enough to
+ allow domain lookups and limited searches, it was unable to provide
+ consistent contact lookups, nameserver lookups, or registrant
+ referrals. This software was also made publicly available under the
+ terms of an open source license.
+
+ The second project was an informal survey of registrants with
+ deployed LDAP servers. This was conducted by using the com, net,
+ org, and edu zone files and testing for the existence of an LDAP
+ server on port 389 using the name of the domain, a host named "ldap"
+ in the domain, and a host named "dir" in the domain (e.g., "foo.com",
+ "ldap.foo.com", and "dir.foo.com"). This survey did not attempt to
+ resolve LDAP services using SRV records in DNS.
+
+ The result of this survey found that roughly 0.5% of active domains
+ had an LDAP server. By profiling a server's root DSA-specific Entry
+ (DSE), the survey found that about 90% of the servers were
+ implementations provided by vendor A, 9% of the servers were
+ implementations provided by vendor B, and 1% of the servers were
+ implementations provided by other vendors. Of the servers queried
+ that were determined to be implementations provided by vendor A, it
+ appeared that about only 10% contained public data (this also led to
+ the assumption that the other 90% were not intended to be publicly
+ queried). Of the servers queried that were determined to be
+ implementations provided by vendor B, it appears that nearly all
+ contained public data.
+
+Appendix B. Acknowledgments
+
+ Significant analysis, design, and implementation for this project
+ were conducted by Brad McMillen, David Blacka, Anna Zhang, and
+ Michael Schiraldi. Mark Kosters and Leslie Daigle provided guidance
+ by reviewing this project, the project's goals, and this document.
+
+
+
+
+
+Newton Experimental [Page 19]
+
+RFC 3663 Domain Administrative Data in LDAP December 2003
+
+
+Author's Address
+
+ Andrew Newton
+ VeriSign, Inc.
+ 21345 Ridgetop Circle
+ Sterling, VA 20166
+ USA
+
+ Phone: +1 703 948 3382
+ EMail: anewton at verisignlabs.com; anewton at ecotroph.net
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Newton Experimental [Page 20]
+
+RFC 3663 Domain Administrative Data in LDAP December 2003
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2003). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assignees.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Newton Experimental [Page 21]
+
Added: openldap/vendor/openldap-release/doc/rfc/rfc3671.txt
===================================================================
--- openldap/vendor/openldap-release/doc/rfc/rfc3671.txt (rev 0)
+++ openldap/vendor/openldap-release/doc/rfc/rfc3671.txt 2007-09-15 10:38:52 UTC (rev 844)
@@ -0,0 +1,563 @@
+
+
+
+
+
+
+Network Working Group K. Zeilenga
+Request for Comments: 3671 OpenLDAP Foundation
+Category: Standards Track December 2003
+
+
+ Collective Attributes in
+ the Lightweight Directory Access Protocol (LDAP)
+
+Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2003). All Rights Reserved.
+
+Abstract
+
+ X.500 collective attributes allow common characteristics to be shared
+ between collections of entries. This document summarizes the X.500
+ information model for collective attributes and describes use of
+ collective attributes in LDAP (Lightweight Directory Access
+ Protocol). This document provides schema definitions for collective
+ attributes for use in LDAP.
+
+1. Introduction
+
+ In X.500 [X.500], a collective attribute is "a user attribute whose
+ values are the same for each member of an entry collection" [X.501].
+ This document details their use in the Lightweight Directory Access
+ Protocol (LDAP) [RFC3377].
+
+1.1. Entry Collections
+
+ A collection of entries is a grouping of object and alias entries
+ based upon common properties or shared relationship between the
+ corresponding entries which share certain attributes. An entry
+ collection consists of all entries within scope of a collective
+ attributes subentry [RFC3672]. An entry can belong to several entry
+ collections.
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 1]
+
+RFC 3671 Collective Attributes in LDAP December 2003
+
+
+1.2. Collective Attributes
+
+ Attributes shared by the entries comprising an entry collection are
+ called collective attributes. Values of collective attributes are
+ visible but not updateable to clients accessing entries within the
+ collection. Collective attributes are updated (i.e., modified) via
+ their associated collective attributes subentry.
+
+ When an entry belongs to multiple entry collections, the entry's
+ values of each collective attribute are combined such that
+ independent sources of these values are not manifested to clients.
+
+ Entries can specifically exclude a particular collective attribute by
+ listing the attribute as a value of the collectiveExclusions
+ attribute. Like other user attributes, collective attributes are
+ subject to a variety of controls including access, administrative,
+ and content controls.
+
+1.3. Conventions
+
+ Schema definitions are provided using LDAPv3 [RFC2251] description
+ formats [RFC2252]. Definitions provided here are formatted (line
+ wrapped) for readability.
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in BCP 14 [RFC2119].
+
+2. System Schema for Collective Attributes
+
+ The following operational attributes are used to manage Collective
+ Attributes. LDAP servers [RFC3377] MUST act in accordance with the
+ X.500 Directory Models [X.501] when providing this service.
+
+2.1. collectiveAttributeSubentry
+
+ Subentries of this object class are used to administer collective
+ attributes and are referred to as collective attribute subentries.
+
+ ( 2.5.17.2 NAME 'collectiveAttributeSubentry' AUXILIARY )
+
+ A collective attribute subentry SHOULD contain at least one
+ collective attribute. The collective attributes contained within a
+ collective attribute subentry are available for finding, searching,
+ and comparison at every entry within the scope of the subentry. The
+ collective attributes, however, are administered (e.g., modified) via
+ the subentry.
+
+
+
+
+Zeilenga Standards Track [Page 2]
+
+RFC 3671 Collective Attributes in LDAP December 2003
+
+
+ Implementations of this specification SHOULD support collective
+ attribute subentries in both collectiveAttributeSpecificArea
+ (2.5.23.5) and collectiveAttributeInnerArea (2.5.23.6) administrative
+ areas [RFC3672][X.501].
+
+2.2. collectiveAttributeSubentries
+
+ The collectiveAttributeSubentries operational attribute identifies
+ all collective attribute subentries that affect the entry.
+
+ ( 2.5.18.12 NAME 'collectiveAttributeSubentries'
+ EQUALITY distinguishedNameMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
+ USAGE directoryOperation NO-USER-MODIFICATION )
+
+2.3. collectiveExclusions
+
+ The collectiveExclusions operational attribute allows particular
+ collective attributes to be excluded from an entry. It MAY appear in
+ any entry and MAY have multiple values.
+
+ ( 2.5.18.7 NAME 'collectiveExclusions'
+ EQUALITY objectIdentifierMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
+ USAGE directoryOperation )
+
+ The descriptor excludeAllCollectiveAttributes is associated with the
+ OID 2.5.18.0. When this descriptor or OID is present as a value of
+ the collectiveExclusions attribute, all collective attributes are
+ excluded from an entry.
+
+3. Collective Attribute Types
+
+ A userApplications attribute type can be defined to be COLLECTIVE
+ [RFC2252]. This indicates that the same attribute values will appear
+ in the entries of an entry collection subject to the use of the
+ collectiveExclusions attribute and other administrative controls.
+ These administrative controls MAY include DIT Content Rules, if
+ implemented.
+
+ Collective attribute types are commonly defined as subtypes of non-
+ collective attribute types. By convention, collective attributes are
+ named by prefixing the name of their non-collective supertype with
+ "c-". For example, the collective telephone attribute is named
+ c-TelephoneNumber after its non-collective supertype telephoneNumber.
+
+ Non-collective attributes types SHALL NOT subtype collective
+ attributes.
+
+
+
+Zeilenga Standards Track [Page 3]
+
+RFC 3671 Collective Attributes in LDAP December 2003
+
+
+ Collective attributes SHALL NOT be SINGLE-VALUED. Collective
+ attribute types SHALL NOT appear in the attribute types of an object
+ class definition.
+
+ Operational attributes SHALL NOT be defined to be collective.
+
+ The remainder of section provides a summary of collective attributes
+ derived from those defined in [X.520]. The SUPerior attribute types
+ are described in [RFC 2256] for use with LDAP.
+
+ Implementations of this specification SHOULD support the following
+ collective attributes and MAY support additional collective
+ attributes.
+
+3.1. Collective Locality Name
+
+ The c-l attribute type specifies a locality name for a collection of
+ entries.
+
+ ( 2.5.4.7.1 NAME 'c-l'
+ SUP l COLLECTIVE )
+
+3.2. Collective State or Province Name
+
+ The c-st attribute type specifies a state or province name for a
+ collection of entries.
+
+ ( 2.5.4.8.1 NAME 'c-st'
+ SUP st COLLECTIVE )
+
+3.3. Collective Street Address
+
+ The c-street attribute type specifies a street address for a
+ collection of entries.
+
+ ( 2.5.4.9.1 NAME 'c-street'
+ SUP street COLLECTIVE )
+
+3.4. Collective Organization Name
+
+ The c-o attribute type specifies an organization name for a
+ collection of entries.
+
+ ( 2.5.4.10.1 NAME 'c-o'
+ SUP o COLLECTIVE )
+
+
+
+
+
+
+Zeilenga Standards Track [Page 4]
+
+RFC 3671 Collective Attributes in LDAP December 2003
+
+
+3.5. Collective Organizational Unit Name
+
+ The c-ou attribute type specifies an organizational unit name for a
+ collection of entries.
+
+ ( 2.5.4.11.1 NAME 'c-ou'
+ SUP ou COLLECTIVE )
+
+3.6. Collective Postal Address
+
+ The c-PostalAddress attribute type specifies a postal address for a
+ collection of entries.
+
+ ( 2.5.4.16.1 NAME 'c-PostalAddress'
+ SUP postalAddress COLLECTIVE )
+
+3.7. Collective Postal Code
+
+ The c-PostalCode attribute type specifies a postal code for a
+ collection of entries.
+
+ ( 2.5.4.17.1 NAME 'c-PostalCode'
+ SUP postalCode COLLECTIVE )
+
+3.8. Collective Post Office Box
+
+ The c-PostOfficeBox attribute type specifies a post office box for a
+ collection of entries.
+
+ ( 2.5.4.18.1 NAME 'c-PostOfficeBox'
+ SUP postOfficeBox COLLECTIVE )
+
+3.9. Collective Physical Delivery Office Name
+
+ The c-PhysicalDeliveryOfficeName attribute type specifies a physical
+ delivery office name for a collection of entries.
+
+ ( 2.5.4.19.1 NAME 'c-PhysicalDeliveryOfficeName'
+ SUP physicalDeliveryOfficeName COLLECTIVE )
+
+3.10. Collective Telephone Number
+
+ The c-TelephoneNumber attribute type specifies a telephone number for
+ a collection of entries.
+
+ ( 2.5.4.20.1 NAME 'c-TelephoneNumber'
+ SUP telephoneNumber COLLECTIVE )
+
+
+
+
+Zeilenga Standards Track [Page 5]
+
+RFC 3671 Collective Attributes in LDAP December 2003
+
+
+3.11. Collective Telex Number
+
+ The c-TelexNumber attribute type specifies a telex number for a
+ collection of entries.
+
+ ( 2.5.4.21.1 NAME 'c-TelexNumber'
+ SUP telexNumber COLLECTIVE )
+
+3.13. Collective Facsimile Telephone Number
+
+ The c-FacsimileTelephoneNumber attribute type specifies a facsimile
+ telephone number for a collection of entries.
+
+ ( 2.5.4.23.1 NAME 'c-FacsimileTelephoneNumber'
+
+ SUP facsimileTelephoneNumber COLLECTIVE )
+
+3.14. Collective International ISDN Number
+
+ The c-InternationalISDNNumber attribute type specifies an
+ international ISDN number for a collection of entries.
+
+ ( 2.5.4.25.1 NAME 'c-InternationalISDNNumber'
+ SUP internationalISDNNumber COLLECTIVE )
+
+4. Security Considerations
+
+ Collective attributes, like other attributes, are subject to access
+ control restrictions and other administrative policy. Generally
+ speaking, collective attributes accessed via an entry in a collection
+ are governed by rules restricting access to attributes of that entry.
+ And collective attributes access via a subentry are governed by rules
+ restricting access to attributes of that subentry. However, as LDAP
+ does not have a standard access model, the particulars of each
+ server's access control system may differ.
+
+ General LDAP security considerations [RFC3377] also apply.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 6]
+
+RFC 3671 Collective Attributes in LDAP December 2003
+
+
+5. IANA Considerations
+
+ The IANA has registered the LDAP descriptors [RFC3383] defined in
+ this technical specification. The following registration template is
+ suggested:
+
+ Subject: Request for LDAP Descriptor Registration
+ Descriptor see comments
+ Object Identifier: see comment
+ Person & email address to contact for further information:
+ Kurt Zeilenga <kurt at OpenLDAP.org>
+ Usage: see comment
+ Specification: RFC3671
+ Author/Change Controller: IESG
+ Comments:
+
+ NAME Type OID
+ ------------------------ ---- -----------------
+ c-FacsimileTelephoneNumber A 2.5.4.23.1
+ c-InternationalISDNNumber A 2.5.4.25.1
+ c-PhysicalDeliveryOffice A 2.5.4.19.1
+ c-PostOfficeBox A 2.5.4.18.1
+ c-PostalAddress A 2.5.4.16.1
+ c-PostalCode A 2.5.4.17.1
+ c-TelephoneNumber A 2.5.4.20.1
+ c-TelexNumber A 2.5.4.21.1
+ c-l A 2.5.4.7.1
+ c-o A 2.5.4.10.1
+ c-ou A 2.5.4.11.1
+ c-st A 2.5.4.8.1
+ c-street A 2.5.4.9.1
+ collectiveAttributeSubentries A 2.5.18.12
+ collectiveAttributeSubentry O 2.5.17.2
+ collectiveExclusions A 2.5.18.7
+
+ where Type A is Attribute and Type O is ObjectClass.
+
+ The Object Identifiers used in this document were assigned by the
+ ISO/IEC Joint Technical Committee 1 - Subcommittee 6 to identify
+ elements of X.500 schema [X.520]. This document make no OID
+ assignments, it only provides LDAP schema descriptions with existing
+ elements of X.500 schema.
+
+
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 7]
+
+RFC 3671 Collective Attributes in LDAP December 2003
+
+
+6. Intellectual Property Statement
+
+ The IETF takes no position regarding the validity or scope of any
+ intellectual property or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; neither does it represent that it
+ has made any effort to identify any such rights. Information on the
+ IETF's procedures with respect to rights in standards-track and
+ standards-related documentation can be found in BCP-11. Copies of
+ claims of rights made available for publication and any assurances of
+ licenses to be made available, or the result of an attempt made to
+ obtain a general license or permission for the use of such
+ proprietary rights by implementors or users of this specification can
+ be obtained from the IETF Secretariat.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights which may cover technology that may be required to practice
+ this standard. Please address the information to the IETF Executive
+ Director.
+
+7. Acknowledgments
+
+ This document is based upon the ITU Recommendations for the Directory
+ [X.501][X.520].
+
+8. References
+
+8.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2251] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory
+ Access Protocol (v3)", RFC 2251, December 1997.
+
+ [RFC2252] Wahl, M., Coulbeck, A., Howes, T. and S. Kille,
+ "Lightweight Directory Access Protocol (v3): Attribute
+ Syntax Definitions", RFC 2252, December 1997.
+
+ [RFC2256] Wahl, M., "A Summary of the X.500(96) User Schema for use
+ with LDAPv3", RFC 2256, December 1997.
+
+ [RFC3377] Hodges, J. and R. L. Morgan, "Lightweight Directory Access
+ Protocol (v3): Technical Specification", RFC 3377,
+ September 2002.
+
+
+
+
+Zeilenga Standards Track [Page 8]
+
+RFC 3671 Collective Attributes in LDAP December 2003
+
+
+ [RFC3383] Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
+ Considerations for the Lightweight Directory Access
+ Protocol (LDAP)", BCP 64, RFC 3383, September 2002.
+
+ [RFC3672] Zeilenga, K. and S. Legg, "Subentries in Lightweight
+ Directory Access Protocol (LDAP)", RFC 3672, December
+ 2003.
+
+ [X.501] "The Directory: Models", ITU-T Recommendation X.501, 1993.
+
+8.2. Informative References
+
+ [X.500] "The Directory: Overview of Concepts, Models", ITU-T
+ Recommendation X.500, 1993.
+
+ [X.520] "The Directory: Selected Attribute Types", ITU-T
+ Recommendation X.520, 1993.
+
+9. Author's Address
+
+ Kurt D. Zeilenga
+ OpenLDAP Foundation
+
+ EMail: Kurt at OpenLDAP.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 9]
+
+RFC 3671 Collective Attributes in LDAP December 2003
+
+
+10. Full Copyright Statement
+
+ Copyright (C) The Internet Society (2003). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assignees.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 10]
+
Added: openldap/vendor/openldap-release/doc/rfc/rfc3672.txt
===================================================================
--- openldap/vendor/openldap-release/doc/rfc/rfc3672.txt (rev 0)
+++ openldap/vendor/openldap-release/doc/rfc/rfc3672.txt 2007-09-15 10:38:52 UTC (rev 844)
@@ -0,0 +1,675 @@
+
+
+
+
+
+
+Network Working Group K. Zeilenga
+Request for Comments: 3672 OpenLDAP Foundation
+Category: Standards Track S. Legg
+ Adacel Technologies
+ December 2003
+
+
+ Subentries in the Lightweight Directory Access Protocol (LDAP)
+
+Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2003). All Rights Reserved.
+
+Abstract
+
+ In X.500 directories, subentries are special entries used to hold
+ information associated with a subtree or subtree refinement. This
+ document adapts X.500 subentries mechanisms for use with the
+ Lightweight Directory Access Protocol (LDAP).
+
+1. Overview
+
+ From [X.501]:
+
+ A subentry is a special kind of entry immediately subordinate to
+ an administrative point. It contains attributes that pertain to
+ a subtree (or subtree refinement) associated with its
+ administrative point. The subentries and their administrative
+ point are part of the same naming context.
+
+ A single subentry may serve all or several aspects of
+ administrative authority. Alternatively, a specific aspect of
+ administrative authority may be handled through one or more of
+ its own subentries.
+
+ Subentries in the Lightweight Directory Access Protocol (LDAP)
+ [RFC3377] SHALL behave in accordance with X.501 unless noted
+ otherwise in this specification.
+
+
+
+
+
+Zeilenga & Legg Standards Track [Page 1]
+
+RFC 3672 Subentries in LDAP December 2003
+
+
+ In absence of the subentries control (detailed in Section 3),
+ subentries SHALL NOT be considered in one-level and subtree scope
+ search operations. For all other operations, including base scope
+ search operations, subentries SHALL be considered.
+
+1.1. Conventions
+
+ Schema definitions are provided using LDAP description formats
+ [RFC2252]. Definitions provided here are formatted (line wrapped)
+ for readability.
+
+ 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].
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in BCP 14 [RFC2119].
+
+2. Subentry Schema
+
+2.1. Subtree Specification Syntax
+
+ The Subtree Specification syntax provides a general purpose mechanism
+ for the specification of a subset of entries in a subtree of the
+ Directory Information Tree (DIT). A subtree begins at some base
+ entry and includes the subordinates of that entry down to some
+ identified lower boundary, possibly extending to the leaf entries. A
+ subtree specification is always used within a context or scope which
+ implicitly determines the bounds of the subtree. For example, the
+ scope of a subtree specification for a subschema administrative area
+ does not include the subtrees of any subordinate administrative point
+ entries for subschema administration. Where a subtree specification
+ does not identify a contiguous subset of the entries within a single
+ subtree the collection is termed a subtree refinement.
+
+ This syntax corresponds to the SubtreeSpecification ASN.1 type
+ described in [X.501], Section 11.3. This ASN.1 data type definition
+ is reproduced here for completeness.
+
+ SubtreeSpecification ::= SEQUENCE {
+ base [0] LocalName DEFAULT { },
+ COMPONENTS OF ChopSpecification,
+ specificationFilter [4] Refinement OPTIONAL }
+
+ LocalName ::= RDNSequence
+
+
+
+
+Zeilenga & Legg Standards Track [Page 2]
+
+RFC 3672 Subentries in LDAP December 2003
+
+
+ ChopSpecification ::= SEQUENCE {
+ specificExclusions [1] SET OF CHOICE {
+ chopBefore [0] LocalName,
+ chopAfter [1] LocalName } OPTIONAL,
+ minimum [2] BaseDistance DEFAULT 0,
+ maximum [3] BaseDistance OPTIONAL }
+
+ BaseDistance ::= INTEGER (0 .. MAX)
+
+ Refinement ::= CHOICE {
+ item [0] OBJECT-CLASS.&id,
+ and [1] SET OF Refinement,
+ or [2] SET OF Refinement,
+ not [3] Refinement }
+
+ The components of SubtreeSpecification are: base, which identifies
+ the base entry of the subtree or subtree refinement, and
+ specificExclusions, minimum, maximum and specificationFilter, which
+ then reduce the set of subordinate entries of the base entry. The
+ subtree or subtree refinement contains all the entries within scope
+ that are not excluded by any of the components of the subtree
+ specification. When all of the components of SubtreeSpecification
+ are absent (i.e., when a value of the Subtree Specification syntax is
+ the empty sequence, {}), the specified subtree implicitly includes
+ all the entries within scope.
+
+ Any particular use of this mechanism MAY impose limitations or
+ constraints on the components of SubtreeSpecification.
+
+ The LDAP syntax specification is:
+
+ ( 1.3.6.1.4.1.1466.115.121.1.45 DESC 'SubtreeSpecification' )
+
+ The LDAP-specific encoding of values of this syntax is defined by the
+ Generic String Encoding Rules [RFC3641]. Appendix A provides an
+ equivalent Augmented Backus-Naur Form (ABNF) [RFC2234] for this
+ syntax.
+
+2.1.1. Base
+
+ The base component of SubtreeSpecification nominates the base entry
+ of the subtree or subtree refinement. The base entry may be an entry
+ which is subordinate to the root entry of the scope in which the
+ subtree specification is used, in which case the base component
+ contains a sequence of Relative Distinguished Names (RDNs) relative
+ to the root entry of the scope, or may be the root entry of the scope
+ itself (the default), in which case the base component is absent or
+ contains an empty sequence of RDNs.
+
+
+
+Zeilenga & Legg Standards Track [Page 3]
+
+RFC 3672 Subentries in LDAP December 2003
+
+
+ Entries that are not subordinates of the base entry are excluded from
+ the subtree or subtree refinement.
+
+2.1.2. Specific Exclusions
+
+ The specificExclusions component of a ChopSpecification is a list of
+ exclusions that specify entries and their subordinates to be excluded
+ from the subtree or subtree refinement. The entry is specified by a
+ sequence of RDNs relative to the base entry (i.e., a LocalName).
+ Each exclusion is of either the chopBefore or chopAfter form. If the
+ chopBefore form is used then the specified entry and its subordinates
+ are excluded from the subtree or subtree refinement. If the
+ chopAfter form is used then only the subordinates of the specified
+ entry are excluded from the subtree or subtree refinement.
+
+2.1.3. Minimum and Maximum
+
+ The minimum and maximum components of a ChopSpecification allow the
+ exclusion of entries based on their depth in the DIT.
+
+ Entries that are less than the minimum number of RDN arcs below the
+ base entry are excluded from the subtree or subtree refinement. A
+ minimum value of zero (the default) corresponds to the base entry.
+
+ Entries that are more than the maximum number of RDN arcs below the
+ base entry are excluded from the subtree or subtree refinement. An
+ absent maximum component indicates that there is no upper limit on
+ the number of RDN arcs below the base entry for entries in the
+ subtree or subtree refinement.
+
+2.1.4. Specification Filter
+
+ The specificationFilter component is a boolean expression of
+ assertions about the values of the objectClass attribute of the base
+ entry and its subordinates. A Refinement assertion item evaluates to
+ true for an entry if that entry's objectClass attribute contains the
+ OID nominated in the assertion. Entries for which the overall filter
+ evaluates to false are excluded from the subtree refinement. If the
+ specificationFilter is absent then no entries are excluded from the
+ subtree or subtree refinement because of their objectClass attribute
+ values.
+
+
+
+
+
+
+
+
+
+
+Zeilenga & Legg Standards Track [Page 4]
+
+RFC 3672 Subentries in LDAP December 2003
+
+
+2.2. Administrative Role Attribute Type
+
+ The Administrative Model defined in [X.501], clause 10 requires that
+ administrative entries contain an administrativeRole attribute to
+ indicate that the associated administrative area is concerned with
+ one or more administrative roles.
+
+ The administrativeRole operational attribute is specified as follows:
+
+ ( 2.5.18.5 NAME 'administrativeRole'
+ EQUALITY objectIdentifierMatch
+ USAGE directoryOperation
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
+
+ The possible values of this attribute defined in X.501 are:
+
+ OID NAME
+ -------- -------------------------------
+ 2.5.23.1 autonomousArea
+ 2.5.23.2 accessControlSpecificArea
+ 2.5.23.3 accessControlInnerArea
+ 2.5.23.4 subschemaAdminSpecificArea
+ 2.5.23.5 collectiveAttributeSpecificArea
+ 2.5.23.6 collectiveAttributeInnerArea
+
+ Other values may be defined in other specifications. Names
+ associated with each administrative role are Object Identifier
+ Descriptors [RFC3383].
+
+ The administrativeRole operational attribute is also used to regulate
+ the subentries permitted to be subordinate to an administrative
+ entry. A subentry not of a class permitted by the administrativeRole
+ attribute cannot be subordinate to the administrative entry.
+
+2.3. Subtree Specification Attribute Type
+
+ The subtreeSpecification operational attribute is defined as follows:
+
+ ( 2.5.18.6 NAME 'subtreeSpecification'
+ SINGLE-VALUE
+ USAGE directoryOperation
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.45 )
+
+ This attribute is present in all subentries. See [X.501], clause 10.
+ Values of the subtreeSpecification attribute nominate collections of
+ entries within the DIT for one or more aspects of administrative
+ authority.
+
+
+
+
+Zeilenga & Legg Standards Track [Page 5]
+
+RFC 3672 Subentries in LDAP December 2003
+
+
+2.4. Subentry Object Class
+
+ The subentry object class is a structural object class.
+
+ ( 2.5.17.0 NAME 'subentry'
+ SUP top STRUCTURAL
+ MUST ( cn $ subtreeSpecification ) )
+
+3. Subentries Control
+
+ The subentries control MAY be sent with a searchRequest to control
+ the visibility of entries and subentries which are within scope.
+ Non-visible entries or subentries are not returned in response to the
+ request.
+
+ The subentries control is an LDAP Control whose controlType is
+ 1.3.6.1.4.1.4203.1.10.1, criticality is TRUE or FALSE (hence absent),
+ and controlValue contains a BER-encoded BOOLEAN indicating
+ visibility. A controlValue containing the value TRUE indicates that
+ subentries are visible and normal entries are not. A controlValue
+ containing the value FALSE indicates that normal entries are visible
+ and subentries are not.
+
+ Note that TRUE visibility has the three octet encoding { 01 01 FF }
+ and FALSE visibility has the three octet encoding { 01 01 00 }.
+
+ The controlValue SHALL NOT be absent.
+
+ In absence of this control, subentries are not visible to singleLevel
+ and wholeSubtree scope Search requests but are visible to baseObject
+ scope Search requests.
+
+ There is no corresponding response control.
+
+ This control is not appropriate for non-Search operations.
+
+4. Security Considerations
+
+ Subentries often hold administrative information or other sensitive
+ information and should be protected from unauthorized access and
+ disclosure as described in [RFC2829][RFC2830].
+
+ General LDAP [RFC3377] security considerations also apply.
+
+
+
+
+
+
+
+
+Zeilenga & Legg Standards Track [Page 6]
+
+RFC 3672 Subentries in LDAP December 2003
+
+
+5. IANA Considerations
+
+5.1. Descriptors
+
+ The IANA has registered the LDAP descriptors detailed in this
+ technical specification. The following registration template is
+ suggested:
+
+ Subject: Request for LDAP Descriptor Registration
+ Descriptor (short name): see comment
+ Object Identifier: see comment
+ Person & email address to contact for further information:
+ Kurt Zeilenga <kurt at OpenLDAP.org>
+ Usage: see comment
+ Specification: RFC3672
+ Author/Change Controller: IESG
+ Comments:
+
+ NAME Type OID
+ ------------------------ ---- --------
+ accessControlInnerArea R 2.5.23.3
+ accessControlSpecificArea R 2.5.23.2
+ administrativeRole A 2.5.18.5
+ autonomousArea R 2.5.23.1
+ collectiveAttributeInnerArea R 2.5.23.6
+ collectiveAttributeSpecificArea R 2.5.23.5
+ subentry O 2.5.17.0
+ subschemaAdminSpecificArea R 2.5.23.4
+ subtreeSpecification A 2.5.18.6
+
+ where Type A is Attribute, Type O is ObjectClass, and Type R is
+ Administrative Role.
+
+5.2. Object Identifiers
+
+ This document uses the OID 1.3.6.1.4.1.4203.1.10.1 to identify an
+ LDAP protocol element defined herein. This OID was assigned [ASSIGN]
+ by OpenLDAP Foundation, under its IANA-assigned private enterprise
+ allocation [PRIVATE], for use in this specification.
+
+ Other OIDs which appear in this document were either assigned by the
+ ISO/IEC Joint Technical Committee 1 - Subcommittee 6 to identify
+ elements of X.500 schema or assigned in RFC 2252 for the use
+ described here.
+
+
+
+
+
+
+
+Zeilenga & Legg Standards Track [Page 7]
+
+RFC 3672 Subentries in LDAP December 2003
+
+
+5.3. Protocol Mechanisms
+
+ The IANA has registered the LDAP protocol mechanisms [RFC3383]
+ detailed in this specification.
+
+ Subject: Request for LDAP Protocol Mechanism Registration
+
+ Description: Subentries
+
+ Person & email address to contact for further information:
+ Kurt Zeilenga <kurt at openldap.org>
+
+ Usage: Control
+
+ Specification: RFC3672
+
+ Author/Change Controller: IESG
+
+ Comments: none
+
+6. Acknowledgment
+
+ This document is based on engineering done by IETF LDUP and LDAPext
+ Working Groups including "LDAP Subentry Schema" by Ed Reed. This
+ document also borrows from a number of ITU documents including X.501.
+
+7. Intellectual Property Statement
+
+ The IETF takes no position regarding the validity or scope of any
+ intellectual property or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; neither does it represent that it
+ has made any effort to identify any such rights. Information on the
+ IETF's procedures with respect to rights in standards-track and
+ standards-related documentation can be found in BCP-11. Copies of
+ claims of rights made available for publication and any assurances of
+ licenses to be made available, or the result of an attempt made to
+ obtain a general license or permission for the use of such
+ proprietary rights by implementors or users of this specification can
+ be obtained from the IETF Secretariat.
+
+ 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 & Legg Standards Track [Page 8]
+
+RFC 3672 Subentries in LDAP December 2003
+
+
+A. Subtree Specification ABNF
+
+ This appendix is non-normative.
+
+ The LDAP-specific string encoding for the Subtree Specification
+ syntax is specified by the Generic String Encoding Rules [RFC3641].
+ The ABNF [RFC2234] in this appendix for this syntax is provided only
+ as a convenience and is equivalent to the encoding specified by the
+ application of [RFC3641]. Since the SubtreeSpecification ASN.1 type
+ may be extended in future editions of [X.501], the provided ABNF
+ should be regarded as a snapshot in time. The LDAP-specific encoding
+ for any extension to the SubtreeSpecification ASN.1 type can be
+ determined from [RFC3641].
+
+ In the event that there is a discrepancy between this ABNF and the
+ encoding determined by [RFC3641], [RFC3641] is to be taken as
+ definitive.
+
+ SubtreeSpecification = "{" [ sp ss-base ]
+ [ sep sp ss-specificExclusions ]
+ [ sep sp ss-minimum ]
+ [ sep sp ss-maximum ]
+ [ sep sp ss-specificationFilter ]
+ sp "}"
+
+ ss-base = id-base msp LocalName
+ ss-specificExclusions = id-specificExclusions msp
+ SpecificExclusions
+ ss-minimum = id-minimum msp BaseDistance
+ ss-maximum = id-maximum msp BaseDistance
+ ss-specificationFilter = id-specificationFilter msp Refinement
+
+ id-base = %x62.61.73.65 ; "base"
+ id-specificExclusions = %x73.70.65.63.69.66.69.63.45.78.63.6C.75.73
+ %x69.6F.6E.73 ; "specificExclusions"
+ id-minimum = %x6D.69.6E.69.6D.75.6D ; "minimum"
+ id-maximum = %x6D.61.78.69.6D.75.6D ; "maximum"
+ id-specificationFilter = %x73.70.65.63.69.66.69.63.61.74.69.6F.6E.46
+ %x69.6C.74.65.72 ; "specificationFilter"
+
+ SpecificExclusions = "{" [ sp SpecificExclusion
+ *( "," sp SpecificExclusion ) ] sp "}"
+ SpecificExclusion = chopBefore / chopAfter
+ chopBefore = id-chopBefore ":" LocalName
+ chopAfter = id-chopAfter ":" LocalName
+ id-chopBefore = %x63.68.6F.70.42.65.66.6F.72.65 ; "chopBefore"
+ id-chopAfter = %x63.68.6F.70.41.66.74.65.72 ; "chopAfter"
+
+
+
+
+Zeilenga & Legg Standards Track [Page 9]
+
+RFC 3672 Subentries in LDAP December 2003
+
+
+ Refinement = item / and / or / not
+ item = id-item ":" OBJECT-IDENTIFIER
+ and = id-and ":" Refinements
+ or = id-or ":" Refinements
+ not = id-not ":" Refinement
+ Refinements = "{" [ sp Refinement
+ *( "," sp Refinement ) ] sp "}"
+ id-item = %x69.74.65.6D ; "item"
+ id-and = %x61.6E.64 ; "and"
+ id-or = %x6F.72 ; "or"
+ id-not = %x6E.6F.74 ; "not"
+
+ BaseDistance = INTEGER-0-MAX
+
+ The <sp>, <msp>, <sep>, <INTEGER>, <INTEGER-0-MAX>, <OBJECT-
+ IDENTIFIER> and <LocalName> rules are defined in [RFC3642].
+
+Normative References
+
+ [X.501] ITU-T, "The Directory -- Models," X.501, 1993.
+
+ [X.680] ITU-T, "Abstract Syntax Notation One (ASN.1) -
+ Specification of Basic Notation", X.680, 1994.
+
+ [X.690] ITU-T, "Specification of ASN.1 encoding rules: Basic,
+ Canonical, and Distinguished Encoding Rules", X.690,
+ 1994.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2251] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory
+ Access Protocol (v3)", RFC 2251, December 1997.
+
+ [RFC2252] Wahl, M., Coulbeck, A., Howes, T. and S. Kille,
+ "Lightweight Directory Access Protocol (v3): Attribute
+ Syntax Definitions", RFC 2252, December 1997.
+
+ [RFC2829] Wahl, M., Alvestrand, H., Hodges, J. and R. Morgan,
+ "Authentication Methods for LDAP", RFC 2829, May 2000.
+
+ [RFC2830] Hodges, J., Morgan, R. and M. Wahl, "Lightweight
+ Directory Access Protocol (v3): Extension for Transport
+ Layer Security", RFC 2830, May 2000.
+
+ [RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access
+ Protocol (v3): Technical Specification", RFC 3377,
+ September 2002.
+
+
+
+Zeilenga & Legg Standards Track [Page 10]
+
+RFC 3672 Subentries in LDAP December 2003
+
+
+ [RFC3383] Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
+ Considerations for the Lightweight Directory Access
+ Protocol (LDAP)", RFC 3383, September 2002.
+
+ [RFC3641] Legg, S., "Generic String Encoding Rules (GSER) for ASN.1
+ Types", RFC 3641, October 2003.
+
+Informative References
+
+ [RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
+ Specifications: ABNF", RFC 2234, November 1997.
+
+ [RFC3642] Legg, S., "Common Elements of Generic String Encoding
+ Rules (GSER) Encodings", RFC 3642, October 2003.
+
+ [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
+
+Authors' Addresses
+
+ Kurt D. Zeilenga
+ OpenLDAP Foundation
+
+ EMail: Kurt at OpenLDAP.org
+
+
+ Steven Legg
+ Adacel Technologies Ltd.
+ 250 Bay Street
+ Brighton, Victoria 3186
+ AUSTRALIA
+
+ Phone: +61 3 8530 7710
+ Fax: +61 3 8530 7888
+ EMail: steven.legg at adacel.com.au
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga & Legg Standards Track [Page 11]
+
+RFC 3672 Subentries in LDAP December 2003
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2003). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assignees.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga & Legg Standards Track [Page 12]
+
Added: openldap/vendor/openldap-release/doc/rfc/rfc3673.txt
===================================================================
--- openldap/vendor/openldap-release/doc/rfc/rfc3673.txt (rev 0)
+++ openldap/vendor/openldap-release/doc/rfc/rfc3673.txt 2007-09-15 10:38:52 UTC (rev 844)
@@ -0,0 +1,283 @@
+
+
+
+
+
+
+Network Working Group K. Zeilenga
+Request for Comments: 3673 OpenLDAP Foundation
+Category: Standards Track December 2003
+
+
+ Lightweight Directory Access Protocol version 3 (LDAPv3):
+ All Operational Attributes
+
+Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2003). All Rights Reserved.
+
+Abstract
+
+ The Lightweight Directory Access Protocol (LDAP) supports a mechanism
+ for requesting the return of all user attributes but not all
+ operational attributes. This document describes an LDAP extension
+ which clients may use to request the return of all operational
+ attributes.
+
+1. Overview
+
+ X.500 [X.500] provides a mechanism for clients to request all
+ operational attributes be returned with entries provided in response
+ to a search operation. This mechanism is often used by clients to
+ discover which operational attributes are present in an entry.
+
+ This documents extends the Lightweight Directory Access Protocol
+ (LDAP) [RFC3377] to provide a simple mechanism which clients may use
+ to request the return of all operational attributes. The mechanism
+ is designed for use with existing general purpose LDAP clients
+ (including web browsers which support LDAP URLs) and existing LDAP
+ APIs.
+
+ 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].
+
+
+
+
+
+
+Zeilenga Standards Track [Page 1]
+
+RFC 3673 LDAPv3: All Operational Attributes December 2003
+
+
+2. All Operational Attributes
+
+ The presence of the attribute description "+" (ASCII 43) in the list
+ of attributes in a Search Request [RFC2251] SHALL signify a request
+ for the return of all operational attributes.
+
+ As with all search requests, client implementors should note that
+ results may not include all requested attributes due to access
+ controls or other restrictions. Client implementors should also note
+ that certain operational attributes may be returned only if requested
+ by name even when "+" is present. This is because some operational
+ attributes are very expensive to return.
+
+ Servers supporting this feature SHOULD publish the Object Identifier
+ 1.3.6.1.4.1.4203.1.5.1 as a value of the 'supportedFeatures'
+ [RFC3674] attribute in the root DSE.
+
+3. Interoperability Considerations
+
+ This mechanism is specifically designed to allow users to request all
+ operational attributes using existing LDAP clients. In particular,
+ the mechanism is designed to be compatible with existing general
+ purpose LDAP clients including those supporting LDAP URLs [RFC2255].
+
+ The addition of this mechanism to LDAP is not believed to cause any
+ significant interoperability issues (this has been confirmed through
+ testing). Servers which have yet to implement this specification
+ should ignore the "+" as an unrecognized attribute description per
+ [RFC2251, Section 4.5.1]. From the client's perspective, a server
+ which does not return all operational attributes when "+" is
+ requested should be viewed as having other restrictions.
+
+ It is also noted that this mechanism is believed to require no
+ modification of existing LDAP APIs.
+
+4. Security Considerations
+
+ This document provides a general mechanism which clients may use to
+ discover operational attributes. Prior to the introduction of this
+ mechanism, operational attributes were only returned when requested
+ by name. Some might have viewed this as obscurity feature. However,
+ this feature offers a false sense of security as the attributes were
+ still transferable.
+
+ Implementations SHOULD implement appropriate access controls
+ mechanisms to restricts access to operational attributes.
+
+
+
+
+
+Zeilenga Standards Track [Page 2]
+
+RFC 3673 LDAPv3: All Operational Attributes December 2003
+
+
+5. IANA Considerations
+
+ This document uses the OID 1.3.6.1.4.1.4203.1.5.1 to identify the
+ feature described above. This OID was assigned [ASSIGN] by OpenLDAP
+ Foundation, under its IANA-assigned private enterprise allocation
+ [PRIVATE], for use in this specification.
+
+ Registration of this feature has been completed by IANA [RFC3674],
+ [RFC3383].
+
+ Subject: Request for LDAP Protocol Mechanism Registration
+
+ Object Identifier: 1.3.6.1.4.1.4203.1.5.1
+
+ Description: All Op Attrs
+
+ Person & email address to contact for further information:
+ Kurt Zeilenga <kurt at openldap.org>
+
+ Usage: Feature
+
+ Specification: RFC3673
+
+ Author/Change Controller: IESG
+
+ Comments: none
+
+6. Acknowledgment
+
+ The "+" mechanism is believed to have been first suggested by Bruce
+ Greenblatt in a November 1998 post to the IETF LDAPext Working Group
+ mailing list.
+
+7. Intellectual Property Statement
+
+ The IETF takes no position regarding the validity or scope of any
+ intellectual property or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; neither does it represent that it
+ has made any effort to identify any such rights. Information on the
+ IETF's procedures with respect to rights in standards-track and
+ standards-related documentation can be found in BCP-11. Copies of
+ claims of rights made available for publication and any assurances of
+ licenses to be made available, or the result of an attempt made to
+ obtain a general license or permission for the use of such
+ proprietary rights by implementors or users of this specification can
+ be obtained from the IETF Secretariat.
+
+
+
+Zeilenga Standards Track [Page 3]
+
+RFC 3673 LDAPv3: All Operational Attributes December 2003
+
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights which may cover technology that may be required to practice
+ this standard. Please address the information to the IETF Executive
+ Director.
+
+8. References
+
+8.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2251] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory
+ Access Protocol (v3)", RFC 2251, December 1997.
+
+ [RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access
+ Protocol (v3): Technical Specification", RFC 3377,
+ September 2002.
+
+ [RFC3674] Zeilenga, K., "Feature Discovery in Lightweight Directory
+ Access Protocol (LDAP)", RFC 3674, December 2003.
+
+8.2. Informative References
+
+ [RFC2255] Howes, T. and M. Smith, "The LDAP URL Format", RFC 2255,
+ December 1997.
+
+ [RFC3383] Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
+ Considerations for the Lightweight Directory Access
+ Protocol (LDAP)", BCP 64, RFC 3383, September 2002.
+
+ [X.500] ITU-T Rec. X.500, "The Directory: Overview of Concepts,
+ Models and Service", 1993.
+
+ [ASSIGN] OpenLDAP Foundation, "OpenLDAP OID Delegations",
+ http://www.openldap.org/foundation/oid-delegate.txt.
+
+ [PRIVATE] IANA, "Private Enterprise Numbers",
+ http://www.iana.org/assignments/enterprise-numbers.
+
+9. Author's Address
+
+ Kurt D. Zeilenga
+ OpenLDAP Foundation
+
+ EMail: Kurt at OpenLDAP.org
+
+
+
+
+Zeilenga Standards Track [Page 4]
+
+RFC 3673 LDAPv3: All Operational Attributes December 2003
+
+
+10. Full Copyright Statement
+
+ Copyright (C) The Internet Society (2003). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assignees.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 5]
+
Added: openldap/vendor/openldap-release/doc/rfc/rfc3674.txt
===================================================================
--- openldap/vendor/openldap-release/doc/rfc/rfc3674.txt (rev 0)
+++ openldap/vendor/openldap-release/doc/rfc/rfc3674.txt 2007-09-15 10:38:52 UTC (rev 844)
@@ -0,0 +1,283 @@
+
+
+
+
+
+
+Network Working Group K. Zeilenga
+Request for Comments: 3674 OpenLDAP Foundation
+Category: Standards Track December 2003
+
+
+ Feature Discovery in Lightweight Directory Access Protocol (LDAP)
+
+Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2003). All Rights Reserved.
+
+Abstract
+
+ The Lightweight Directory Access Protocol (LDAP) is an extensible
+ protocol with numerous elective features. This document introduces a
+ general mechanism for discovery of elective features and extensions
+ which cannot be discovered using existing mechanisms.
+
+1. Background and Intended Use
+
+ The Lightweight Directory Access Protocol (LDAP) [RFC3377] is an
+ extensible protocol with numerous elective features. LDAP provides
+ mechanisms for a client to discover supported protocol versions,
+ controls, extended operations, Simple Authentication and Security
+ Layer (SASL) mechanisms, and subschema information. However, these
+ mechanisms are not designed to support general feature discovery.
+
+ This document describes a simple, general-purpose mechanism which
+ clients may use to discover the set of elective features supported by
+ a server. For example, this mechanism could be used by a client to
+ discover whether or not the server supports requests for all
+ operational attributes, e.g., "+" [RFC3673]. As another example,
+ this mechanism could be used to discover absolute true, e.g., "(&)"
+ and false, e.g., "(|)", search filters [T-F] support.
+
+ This document extends the LDAP Protocol Mechanism registry [RFC3383]
+ to support registration of values of the supportedFeatures attribute.
+ This registry is managed by the Internet Assigned Numbers Authority
+ (IANA).
+
+
+
+
+Zeilenga Standards Track [Page 1]
+
+RFC 3674 Feature Discovery in LDAP December 2003
+
+
+ Schema definitions are provided using LDAP description formats
+ [RFC2252]. Definitions provided here are formatted (line wrapped)
+ for readability.
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in BCP 14 [RFC2119].
+
+2. Discovery of supported features
+
+ Each elective feature whose support may be discovered SHALL be
+ identified by an Object Identifier (OID). A server advertises its
+ support for a given feature by providing the OID associated with the
+ feature as a value of the 'supportedFeatures' attribute held in the
+ root DSE. A client may examine the values of this attribute to
+ determine if a particular feature is supported by the server. A
+ client MUST ignore values it doesn't recognize as they refer to
+ elective features it doesn't implement.
+
+ Features associated with Standard Track protocol mechanisms MUST be
+ registered. Features associated with other protocol mechanisms
+ SHOULD be registered. Procedures for registering protocol mechanisms
+ are described in BCP 64 [RFC3383]. The word "Feature" should be
+ placed in the usage field of the submitted LDAP Protocol Mechanism
+ template.
+
+ The 'supportedFeatures' attribute type is described as follows:
+
+ ( 1.3.6.1.4.1.4203.1.3.5
+ NAME 'supportedFeatures'
+ DESC 'features supported by the server'
+ EQUALITY objectIdentifierMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
+ USAGE dSAOperation )
+
+ Servers MUST be capable of recognizing this attribute type by the
+ name 'supportedFeatures'. Servers MAY recognize the attribute type
+ by other names.
+
+3. Security Considerations
+
+ As rogue clients can discover features of a server by other means
+ (such as by trial and error), this feature discovery mechanism is not
+ believed to introduce any new security risk to LDAP.
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 2]
+
+RFC 3674 Feature Discovery in LDAP December 2003
+
+
+4. IANA Considerations
+
+4.1. Registration of Features as Protocol Mechanisms
+
+ Future specifications detailing LDAP features are to register each
+ feature as a LDAP Protocol Mechanism per guidance given in BCP 64
+ [RFC3383]. A usage of "Feature" in a Protocol Mechanism registration
+ template indicates that the value to be registered is associated with
+ an LDAP feature.
+
+4.2. Registration of the supportedFeatures descriptor
+
+ The IANA has registered the LDAP 'supportedFeatures' descriptor. The
+ following registration template is suggested:
+
+ Subject: Request for LDAP Descriptor Registration
+ Descriptor (short name): supportedFeatures
+ Object Identifier: 1.3.6.1.4.1.4203.1.3.5
+ Person & email address to contact for further information:
+ Kurt Zeilenga <kurt at OpenLDAP.org>
+ Usage: Attribute Type
+ Specification: RFC 3674
+ Author/Change Controller: IESG
+
+ This OID was assigned [ASSIGN] by OpenLDAP Foundation under its IANA
+ assigned private enterprise allocation [PRIVATE] for use in this
+ specification.
+
+5. Acknowledgment
+
+ This document is based upon input from the IETF LDAPEXT working
+ group.
+
+6. Intellectual Property Statement
+
+ The IETF takes no position regarding the validity or scope of any
+ intellectual property or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; neither does it represent that it
+ has made any effort to identify any such rights. Information on the
+ IETF's procedures with respect to rights in standards-track and
+ standards-related documentation can be found in BCP-11. Copies of
+ claims of rights made available for publication and any assurances of
+ licenses to be made available, or the result of an attempt made to
+ obtain a general license or permission for the use of such
+ proprietary rights by implementors or users of this specification can
+ be obtained from the IETF Secretariat.
+
+
+
+Zeilenga Standards Track [Page 3]
+
+RFC 3674 Feature Discovery in LDAP December 2003
+
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights which may cover technology that may be required to practice
+ this standard. Please address the information to the IETF Executive
+ Director.
+
+7. References
+
+7.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2252] Wahl, M., Coulbeck, A., Howes, T. and S. Kille,
+ "Lightweight Directory Access Protocol (v3): Attribute
+ Syntax Definitions", RFC 2252, December 1997.
+
+ [RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access
+ Protocol (v3): Technical Specification", RFC 3377,
+ September 2002.
+
+ [RFC3383] Zeilenga, K., "Internet Assigned Numbers Authority
+ (IANA) Considerations for Lightweight Directory Access
+ Protocol (LDAP)", BCP 64, RFC 3383, September 2002.
+
+7.2. Informative References
+
+ [RFC3673] Zeilenga, K., "Lightweight Directory Access Protocol
+ version 3 (LDAPv3): All Operational Attributes", RFC
+ 3673, December 2003.
+
+ [T-F] Zeilenga, K., "LDAP True/False Filters", Work in
+ Progress.
+
+ [ASSIGN] OpenLDAP Foundation, "OpenLDAP OID Delegations",
+ http://www.openldap.org/foundation/oid-delegate.txt.
+
+ [PRIVATE] IANA, "Private Enterprise Numbers",
+ http://www.iana.org/assignments/enterprise-numbers.
+
+8. Author's Address
+
+ Kurt D. Zeilenga
+ OpenLDAP Foundation
+
+ EMail: Kurt at OpenLDAP.org
+
+
+
+
+
+Zeilenga Standards Track [Page 4]
+
+RFC 3674 Feature Discovery in LDAP December 2003
+
+
+9. Full Copyright Statement
+
+ Copyright (C) The Internet Society (2003). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assignees.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 5]
+
Added: openldap/vendor/openldap-release/doc/rfc/rfc3687.txt
===================================================================
--- openldap/vendor/openldap-release/doc/rfc/rfc3687.txt (rev 0)
+++ openldap/vendor/openldap-release/doc/rfc/rfc3687.txt 2007-09-15 10:38:52 UTC (rev 844)
@@ -0,0 +1,2355 @@
+
+
+
+
+
+
+Network Working Group S. Legg
+Request for Comments: 3687 Adacel Technologies
+Category: Standards Track February 2004
+
+
+ Lightweight Directory Access Protocol (LDAP)
+ and X.500 Component Matching Rules
+
+Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2004). All Rights Reserved.
+
+Abstract
+
+ The syntaxes of attributes in a Lightweight Directory Access Protocol
+ (LDAP) or X.500 directory range from simple data types, such as text
+ string, integer, or boolean, to complex structured data types, such
+ as the syntaxes of the directory schema operational attributes.
+ Matching rules defined for the complex syntaxes usually only provide
+ the most immediately useful matching capability. This document
+ defines generic matching rules that can match any user selected
+ component parts in an attribute value of any arbitrarily complex
+ attribute syntax.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Legg Standards Track [Page 1]
+
+RFC 3687 LDAP and X.500 Component Matching Rules February 2004
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 2. Conventions. . . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 3. ComponentAssertion . . . . . . . . . . . . . . . . . . . . . . 5
+ 3.1. Component Reference. . . . . . . . . . . . . . . . . . . 6
+ 3.1.1. Component Type Substitutions . . . . . . . . . . 7
+ 3.1.2. Referencing SET, SEQUENCE and CHOICE Components. 8
+ 3.1.3. Referencing SET OF and SEQUENCE OF Components. . 9
+ 3.1.4. Referencing Components of Parameterized Types. . 10
+ 3.1.5. Component Referencing Example. . . . . . . . . . 10
+ 3.1.6. Referencing Components of Open Types . . . . . . 12
+ 3.1.6.1. Open Type Referencing Example . . . . . 12
+ 3.1.7. Referencing Contained Types. . . . . . . . . . . 14
+ 3.1.7.1. Contained Type Referencing Example. . . 14
+ 3.2. Matching of Components . . . . . . . . . . . . . . . . . 15
+ 3.2.1. Applicability of Existing Matching Rules . . . . 17
+ 3.2.1.1. String Matching . . . . . . . . . . . . 17
+ 3.2.1.2. Telephone Number Matching . . . . . . . 17
+ 3.2.1.3. Distinguished Name Matching . . . . . . 18
+ 3.2.2. Additional Useful Matching Rules . . . . . . . . 18
+ 3.2.2.1. The rdnMatch Matching Rule. . . . . . . 18
+ 3.2.2.2. The presentMatch Matching Rule. . . . . 19
+ 3.2.3. Summary of Useful Matching Rules . . . . . . . . 20
+ 4. ComponentFilter. . . . . . . . . . . . . . . . . . . . . . . . 21
+ 5. The componentFilterMatch Matching Rule . . . . . . . . . . . . 22
+ 6. Equality Matching of Complex Components. . . . . . . . . . . . 24
+ 6.1. The OpenAssertionType Syntax . . . . . . . . . . . . . . 24
+ 6.2. The allComponentsMatch Matching Rule . . . . . . . . . . 25
+ 6.3. Deriving Component Equality Matching Rules . . . . . . . 27
+ 6.4. The directoryComponentsMatch Matching Rule . . . . . . . 28
+ 7. Component Matching Examples. . . . . . . . . . . . . . . . . . 30
+ 8. Security Considerations. . . . . . . . . . . . . . . . . . . . 37
+ 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 37
+ 10. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 37
+ 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38
+ 11.1. Normative References. . . . . . . . . . . . . . . . . . 38
+ 11.2. Informative References. . . . . . . . . . . . . . . . . 40
+ 12. Intellectual Property Statement. . . . . . . . . . . . . . . . 40
+ 13. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 41
+ 14. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 42
+
+
+
+
+
+
+
+
+
+
+Legg Standards Track [Page 2]
+
+RFC 3687 LDAP and X.500 Component Matching Rules February 2004
+
+
+1. Introduction
+
+ The structure or data type of data held in an attribute of a
+ Lightweight Directory Access Protocol (LDAP) [7] or X.500 [19]
+ directory is described by the attribute's syntax. Attribute syntaxes
+ range from simple data types, such as text string, integer, or
+ boolean, to complex data types, for example, the syntaxes of the
+ directory schema operational attributes.
+
+ In X.500, the attribute syntaxes are explicitly described by Abstract
+ Syntax Notation One (ASN.1) [13] type definitions. ASN.1 type
+ notation has a number of simple data types (e.g., PrintableString,
+ INTEGER, BOOLEAN), and combining types (i.e., SET, SEQUENCE, SET OF,
+ SEQUENCE OF, and CHOICE) for constructing arbitrarily complex data
+ types from simpler component types. In LDAP, the attribute syntaxes
+ are usually described in Augmented Backus-Naur Form (ABNF) [2],
+ though there is an implied association between the LDAP attribute
+ syntaxes and the X.500 ASN.1 types. To a large extent, the data
+ types of attribute values in either an LDAP or X.500 directory are
+ described by ASN.1 types. This formal description can be exploited
+ to identify component parts of an attribute value for a variety of
+ purposes. This document addresses attribute value matching.
+
+ With any complex attribute syntax there is normally a requirement to
+ partially match an attribute value of that syntax by matching only
+ selected components of the value. Typically, matching rules specific
+ to the attribute syntax are defined to fill this need. These highly
+ specific matching rules usually only provide the most immediately
+ useful matching capability. Some complex attribute syntaxes don't
+ even have an equality matching rule let alone any additional matching
+ rules for partial matching. This document defines a generic way of
+ matching user selected components in an attribute value of any
+ arbitrarily complex attribute syntax, where that syntax is described
+ using ASN.1 type notation. All of the type notations defined in
+ X.680 [13] are supported.
+
+ Section 3 describes the ComponentAssertion, a testable assertion
+ about the value of a component of an attribute value of any complex
+ syntax.
+
+ Section 4 introduces the ComponentFilter assertion, which is an
+ expression of ComponentAssertions. The ComponentFilter enables more
+ powerful filter matching of components in an attribute value.
+
+ Section 5 defines the componentFilterMatch matching rule, which
+ enables a ComponentFilter to be evaluated against attribute values.
+
+
+
+
+
+Legg Standards Track [Page 3]
+
+RFC 3687 LDAP and X.500 Component Matching Rules February 2004
+
+
+ Section 6 defines matching rules for component-wise equality matching
+ of attribute values of any syntax described by an ASN.1 type
+ definition.
+
+ Examples showing the usage of componentFilterMatch are in Section 7.
+
+ For a new attribute syntax, the Generic String Encoding Rules [9] and
+ the specifications in sections 3 to 6 of this document make it
+ possible to fully and precisely define the LDAP-specific encoding,
+ the LDAP and X.500 binary encoding (and possibly other ASN.1
+ encodings in the future), a suitable equality matching rule, and a
+ comprehensive collection of component matching capabilities, by
+ simply writing down an ASN.1 type definition for the syntax. These
+ implicit definitions are also automatically extended if the ASN.1
+ type is later extended. The algorithmic relationship between the
+ ASN.1 type definition, the various encodings and the component
+ matching behaviour makes directory server implementation support for
+ the component matching rules amenable to automatic code generation
+ from ASN.1 type definitions.
+
+ Schema designers have the choice of storing related items of data as
+ a single attribute value of a complex syntax in some entry, or as a
+ subordinate entry where the related data items are stored as separate
+ attribute values of simpler syntaxes. The inability to search
+ component parts of a complex syntax has been used as an argument for
+ favouring the subordinate entries approach. The component matching
+ rules provide the analogous matching capability on an attribute value
+ of a complex syntax that a search filter has on a subordinate entry.
+
+ Most LDAP syntaxes have corresponding ASN.1 type definitions, though
+ they are usually not reproduced or referenced alongside the formal
+ definition of the LDAP syntax. Syntaxes defined with only a
+ character string encoding, i.e., without an explicit or implied
+ corresponding ASN.1 type definition, cannot use the component
+ matching capabilities described in this document unless and until a
+ semantically equivalent ASN.1 type definition is defined for them.
+
+2. Conventions
+
+ Throughout this document "type" shall be taken to mean an ASN.1 type
+ unless explicitly qualified as an attribute type, and "value" shall
+ be taken to mean an ASN.1 value unless explicitly qualified as an
+ attribute value.
+
+
+
+
+
+
+
+
+Legg Standards Track [Page 4]
+
+RFC 3687 LDAP and X.500 Component Matching Rules February 2004
+
+
+ Note that "ASN.1 value" does not mean a Basic Encoding Rules (BER)
+ [17] encoded value. The ASN.1 value is an abstract concept that is
+ independent of any particular encoding. BER is just one possible
+ encoding of an ASN.1 value. The component matching rules operate at
+ the abstract level without regard for the possible encodings of a
+ value.
+
+ Attribute type and matching rule definitions in this document are
+ provided in both the X.500 [10] and LDAP [4] description formats.
+ Note that the LDAP descriptions have been rendered with additional
+ white-space and line breaks for the sake of readability.
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED" and "MAY" in this document are
+ to be interpreted as described in BCP 14, RFC 2119 [1]. The key word
+ "OPTIONAL" is exclusively used with its ASN.1 meaning.
+
+3. ComponentAssertion
+
+ A ComponentAssertion is an assertion about the presence, or values
+ of, components within an ASN.1 value, i.e., an instance of an ASN.1
+ type. The ASN.1 value is typically an attribute value, where the
+ ASN.1 type is the syntax of the attribute. However, a
+ ComponentAssertion may also be applied to a component part of an
+ attribute value. The assertion evaluates to either TRUE, FALSE or
+ Undefined for each tested ASN.1 value.
+
+ A ComponentAssertion is described by the following ASN.1 type
+ (assumed to be defined with "EXPLICIT TAGS" in force):
+
+ ComponentAssertion ::= SEQUENCE {
+ component ComponentReference (SIZE(1..MAX)) OPTIONAL,
+ useDefaultValues BOOLEAN DEFAULT TRUE,
+ rule MATCHING-RULE.&id,
+ value MATCHING-RULE.&AssertionType }
+
+ ComponentReference ::= UTF8String
+
+ MATCHING-RULE.&id equates to the OBJECT IDENTIFIER of a matching
+ rule. MATCHING-RULE.&AssertionType is an open type (formerly known
+ as the ANY type).
+
+ The "component" field of a ComponentAssertion identifies which
+ component part of a value of some ASN.1 type is to be tested, the
+ "useDefaultValues" field indicates whether DEFAULT values are to be
+ substituted for absent component values, the "rule" field indicates
+
+
+
+
+
+Legg Standards Track [Page 5]
+
+RFC 3687 LDAP and X.500 Component Matching Rules February 2004
+
+
+ how the component is to be tested, and the "value" field is an
+ asserted ASN.1 value against which the component is tested. The
+ ASN.1 type of the asserted value is determined by the chosen rule.
+
+ The fields of a ComponentAssertion are described in detail in the
+ following sections.
+
+3.1. Component Reference
+
+ The component field in a ComponentAssertion is a UTF-8 character
+ string [6] whose textual content is a component reference,
+ identifying a component part of some ASN.1 type or value. A
+ component reference conforms to the following ABNF [2], which extends
+ the notation defined in Clause 14 of X.680 [13]:
+
+ component-reference = ComponentId *( "." ComponentId )
+ ComponentId = identifier /
+ from-beginning /
+ count /
+ from-end / ; extends Clause 14
+ content / ; extends Clause 14
+ select / ; extends Clause 14
+ all
+
+ identifier = lowercase *alphanumeric
+ *(hyphen 1*alphanumeric)
+ alphanumeric = uppercase / lowercase / decimal-digit
+ uppercase = %x41-5A ; "A" to "Z"
+ lowercase = %x61-7A ; "a" to "z"
+ hyphen = "-"
+
+ from-beginning = positive-number
+ count = "0"
+ from-end = "-" positive-number
+ content = %x63.6F.6E.74.65.6E.74 ; "content"
+ select = "(" Value *( "," Value ) ")"
+ all = "*"
+
+
+ positive-number = non-zero-digit *decimal-digit
+
+ decimal-digit = %x30-39 ; "0" to "9"
+ non-zero-digit = %x31-39 ; "1" to "9"
+
+
+
+
+
+
+
+
+Legg Standards Track [Page 6]
+
+RFC 3687 LDAP and X.500 Component Matching Rules February 2004
+
+
+ An <identifier> conforms to the definition of an identifier in ASN.1
+ notation (Clause 11.3 of X.680 [13]). It begins with a lowercase
+ letter and is followed by zero or more letters, digits, and hyphens.
+ A hyphen is not permitted to be the last character and a hyphen is
+ not permitted to be followed by another hyphen.
+
+ The <Value> rule is described by the Generic String Encoding Rules
+ (GSER) [9].
+
+ A component reference is a sequence of one or more ComponentIds where
+ each successive ComponentId identifies either an inner component at
+ the next level of nesting of an ASN.1 combining type, i.e., SET,
+ SEQUENCE, SET OF, SEQUENCE OF, or CHOICE, or a specific type within
+ an ASN.1 open type.
+
+ A component reference is always considered in the context of a
+ particular complex ASN.1 type. When applied to the ASN.1 type the
+ component reference identifies a specific component type. When
+ applied to a value of the ASN.1 type a component reference identifies
+ zero, one or more component values of that component type. The
+ component values are potentially in a DEFAULT value if
+ useDefaultValues is TRUE. The specific component type identified by
+ the component reference determines what matching rules are capable of
+ being used to match the component values.
+
+ The component field in a ComponentAssertion may also be absent, in
+ which case the identified component type is the ASN.1 type to which
+ the ComponentAssertion is applied, and the identified component value
+ is the whole ASN.1 value.
+
+ A valid component reference for a particular complex ASN.1 type is
+ constructed by starting with the outermost combining type and
+ repeatedly selecting one of the permissible forms of ComponentId to
+ identify successively deeper nested components. A component
+ reference MAY identify a component with a complex ASN.1 type, i.e.,
+ it is not required that the component type identified by a component
+ reference be a simple ASN.1 type.
+
+3.1.1. Component Type Substitutions
+
+ ASN.1 type notation has a number of constructs for referencing other
+ defined types, and constructs that are irrelevant for matching
+ purposes. These constructs are not represented in a component
+ reference in any way and substitutions of the component type are
+ performed to eliminate them from further consideration. These
+ substitutions automatically occur prior to each ComponentId, whether
+ constructing or interpreting a component reference, but do not occur
+ after the last ComponentId, except as allowed by Section 3.2.
+
+
+
+Legg Standards Track [Page 7]
+
+RFC 3687 LDAP and X.500 Component Matching Rules February 2004
+
+
+ If the ASN.1 type is an ASN.1 type reference then the component type
+ is taken to be the actual definition on the right hand side of the
+ type assignment for the referenced type.
+
+ If the ASN.1 type is a tagged type then the component type is taken
+ to be the type without the tag.
+
+ If the ASN.1 type is a constrained type (see X.680 [13] and X.682
+ [15] for the details of ASN.1 constraint notation) then the component
+ type is taken to be the type without the constraint.
+
+ If the ASN.1 type is an ObjectClassFieldType (Clause 14 of X.681
+ [14]) that denotes a specific ASN.1 type (e.g., MATCHING-RULE.&id
+ denotes the OBJECT IDENTIFIER type) then the component type is taken
+ to be the denoted type. Section 3.1.6 describes the case where the
+ ObjectClassFieldType denotes an open type.
+
+ If the ASN.1 type is a selection type other than one used in the list
+ of components for a SET or SEQUENCE type then the component type is
+ taken to be the selected alternative type from the named CHOICE.
+
+ If the ASN.1 type is a TypeFromObject (Clause 15 of X.681 [14]) then
+ the component type is taken to be the denoted type.
+
+ If the ASN.1 type is a ValueSetFromObjects (Clause 15 of X.681 [14])
+ then the component type is taken to be the governing type of the
+ denoted values.
+
+3.1.2. Referencing SET, SEQUENCE and CHOICE Components
+
+ If the ASN.1 type is a SET or SEQUENCE type then the <identifier>
+ form of ComponentId may be used to identify the component type within
+ that SET or SEQUENCE having that identifier. If <identifier>
+ references an OPTIONAL component type and that component is not
+ present in a particular value then there are no corresponding
+ component values. If <identifier> references a DEFAULT component
+ type and useDefaultValues is TRUE (the default setting for
+ useDefaultValues) and that component is not present in a particular
+ value then the component value is taken to be the default value. If
+ <identifier> references a DEFAULT component type and useDefaultValues
+ is FALSE and that component is not present in a particular value then
+ there are no corresponding component values.
+
+ If the ASN.1 type is a CHOICE type then the <identifier> form of
+ ComponentId may be used to identify the alternative type within that
+ CHOICE having that identifier. If <identifier> references an
+ alternative other than the one used in a particular value then there
+ are no corresponding component values.
+
+
+
+Legg Standards Track [Page 8]
+
+RFC 3687 LDAP and X.500 Component Matching Rules February 2004
+
+
+ The COMPONENTS OF notation in Clause 24 of X.680 [13] augments the
+ defined list of components in a SET or SEQUENCE type by including all
+ the components of another defined SET or SEQUENCE type respectively.
+ These included components are referenced directly by identifier as
+ though they were defined in-line in the SET or SEQUENCE type
+ containing the COMPONENTS OF notation.
+
+ The SelectionType (Clause 29 of X.680 [13]), when used in the list of
+ components for a SET or SEQUENCE type, includes a single component
+ from a defined CHOICE type. This included component is referenced
+ directly by identifier as though it was defined in-line in the SET or
+ SEQUENCE type.
+
+ The REAL type is treated as though it is the SEQUENCE type defined in
+ Clause 20.5 of X.680 [13].
+
+ The EMBEDDED PDV type is treated as though it is the SEQUENCE type
+ defined in Clause 33.5 of X.680 [13].
+
+ The EXTERNAL type is treated as though it is the SEQUENCE type
+ defined in Clause 8.18.1 of X.690 [17].
+
+ The unrestricted CHARACTER STRING type is treated as though it is the
+ SEQUENCE type defined in Clause 40.5 of X.680 [13].
+
+ The INSTANCE OF type is treated as though it is the SEQUENCE type
+ defined in Annex C of X.681 [14].
+
+ The <identifier> form MUST NOT be used on any other ASN.1 type.
+
+3.1.3. Referencing SET OF and SEQUENCE OF Components
+
+ If the ASN.1 type is a SET OF or SEQUENCE OF type then the
+ <from-beginning>, <from-end>, <count> and <all> forms of ComponentId
+ may be used.
+
+ The <from-beginning> form of ComponentId may be used to identify one
+ instance (i.e., value) of the component type of the SET OF or
+ SEQUENCE OF type (e.g., if Foo ::= SET OF Bar, then Bar is the
+ component type), where the instances are numbered from one upwards.
+ If <from-beginning> references a higher numbered instance than the
+ last instance in a particular value of the SET OF or SEQUENCE OF type
+ then there is no corresponding component value.
+
+ The <from-end> form of ComponentId may be used to identify one
+ instance of the component type of the SET OF or SEQUENCE OF type,
+ where "-1" is the last instance, "-2" is the second last instance,
+
+
+
+
+Legg Standards Track [Page 9]
+
+RFC 3687 LDAP and X.500 Component Matching Rules February 2004
+
+
+ and so on. If <from-end> references a lower numbered instance than
+ the first instance in a particular value of the SET OF or SEQUENCE OF
+ type then there is no corresponding component value.
+
+ The <count> form of ComponentId identifies a notional count of the
+ number of instances of the component type in a value of the SET OF or
+ SEQUENCE OF type. This count is not explicitly represented but for
+ matching purposes it has an assumed ASN.1 type of INTEGER (0..MAX).
+ A ComponentId of the <count> form, if used, MUST be the last
+ ComponentId in a component reference.
+
+ The <all> form of ComponentId may be used to simultaneously identify
+ all instances of the component type of the SET OF or SEQUENCE OF
+ type. It is through the <all> form that a component reference can
+ identify more than one component value. However, if a particular
+ value of the SET OF or SEQUENCE OF type is an empty list, then there
+ are no corresponding component values.
+
+ Where multiple component values are identified, the remaining
+ ComponentIds in the component reference, if any, can identify zero,
+ one or more subcomponent values for each of the higher level
+ component values.
+
+ The corresponding ASN.1 type for the <from-beginning>, <from-end>,
+ and <all> forms of ComponentId is the component type of the SET OF or
+ SEQUENCE OF type.
+
+ The <from-beginning>, <count>, <from-end> and <all> forms MUST NOT be
+ used on ASN.1 types other than SET OF or SEQUENCE OF.
+
+3.1.4. Referencing Components of Parameterized Types
+
+ A component reference cannot be formed for a parameterized type
+ unless the type has been used with actual parameters, in which case
+ the type is treated as though the DummyReferences [16] have been
+ substituted with the actual parameters.
+
+3.1.5. Component Referencing Example
+
+ Consider the following ASN.1 type definitions.
+
+ ExampleType ::= SEQUENCE {
+ part1 [0] INTEGER,
+ part2 [1] ExampleSet,
+ part3 [2] SET OF OBJECT IDENTIFIER,
+ part4 [3] ExampleChoice }
+
+
+
+
+
+Legg Standards Track [Page 10]
+
+RFC 3687 LDAP and X.500 Component Matching Rules February 2004
+
+
+ ExampleSet ::= SET {
+ option PrintableString,
+ setting BOOLEAN }
+
+ ExampleChoice ::= CHOICE {
+ eeny-meeny BIT STRING,
+ miney-mo OCTET STRING }
+
+ Following are component references constructed with respect to the
+ type ExampleType.
+
+ The component reference "part1" identifies a component of a value of
+ ExampleType having the ASN.1 tagged type [0] INTEGER.
+
+ The component reference "part2" identifies a component of a value of
+ ExampleType having the ASN.1 type of [1] ExampleSet
+
+ The component reference "part2.option" identifies a component of a
+ value of ExampleType having the ASN.1 type of PrintableString. A
+ ComponentAssertion could also be applied to a value of ASN.1 type
+ ExampleSet, in which case the component reference "option" would
+ identify the same kind of information.
+
+ The component reference "part3" identifies a component of a value of
+ ExampleType having the ASN.1 type of [2] SET OF OBJECT IDENTIFIER.
+
+ The component reference "part3.2" identifies the second instance of
+ the part3 SET OF. The instance has the ASN.1 type of OBJECT
+ IDENTIFIER.
+
+ The component reference "part3.0" identifies the count of the number
+ of instances in the part3 SET OF. The count has the corresponding
+ ASN.1 type of INTEGER (0..MAX).
+
+ The component reference "part3.*" identifies all the instances in the
+ part3 SET OF. Each instance has the ASN.1 type of OBJECT IDENTIFIER.
+
+ The component reference "part4" identifies a component of a value of
+ ExampleType having the ASN.1 type of [3] ExampleChoice.
+
+ The component reference "part4.miney-mo" identifies a component of a
+ value of ExampleType having the ASN.1 type of OCTET STRING.
+
+
+
+
+
+
+
+
+
+Legg Standards Track [Page 11]
+
+RFC 3687 LDAP and X.500 Component Matching Rules February 2004
+
+
+3.1.6. Referencing Components of Open Types
+
+ If a sequence of ComponentIds identifies an ObjectClassFieldType
+ denoting an open type (e.g., ATTRIBUTE.&Type denotes an open type)
+ then the ASN.1 type of the component varies. An open type is
+ typically constrained by some other component(s) in an outer
+ enclosing type, either formally through the use of a component
+ relation constraint [15], or informally in the accompanying text, so
+ the actual ASN.1 type of a value of the open type will generally be
+ known. The constraint will also limit the range of permissible
+ types. The <select> form of ComponentId may be used to identify one
+ of these permissible types in an open type. Subcomponents of that
+ type can then be identified with further ComponentIds.
+
+ The other components constraining the open type are termed the
+ referenced components [15]. The <select> form contains a list of one
+ or more values which take the place of the value(s) of the referenced
+ component(s) to uniquely identify one of the permissible types of the
+ open type.
+
+ Where the open type is constrained by a component relation
+ constraint, there is a <Value> in the <select> form for each of the
+ referenced components in the component relation constraint, appearing
+ in the same order. The ASN.1 type of each of these values is the
+ same as the ASN.1 type of the corresponding referenced component.
+ The type of a referenced component is potentially any ASN.1 type
+ however it is typically an OBJECT IDENTIFIER or INTEGER, which means
+ that the <Value> in the <select> form of ComponentId will nearly
+ always be an <ObjectIdentifierValue> or <IntegerValue> [9].
+ Furthermore, component relation constraints typically have only one
+ referenced component.
+
+ Where the open type is not constrained by a component relation
+ constraint, the specification introducing the syntax containing the
+ open type should explicitly nominate the referenced components and
+ their order, so that the <select> form can be used.
+
+ If an instance of <select> contains a value other than the value of
+ the referenced component used in a particular value of the outer
+ enclosing type then there are no corresponding component values for
+ the open type.
+
+3.1.6.1. Open Type Referencing Example
+
+ The ASN.1 type AttributeTypeAndValue [10] describes a single
+ attribute value of a nominated attribute type.
+
+
+
+
+
+Legg Standards Track [Page 12]
+
+RFC 3687 LDAP and X.500 Component Matching Rules February 2004
+
+
+ AttributeTypeAndValue ::= SEQUENCE {
+ type ATTRIBUTE.&id ({SupportedAttributes}),
+ value ATTRIBUTE.&Type ({SupportedAttributes}{@type}) }
+
+ ATTRIBUTE.&id denotes an OBJECT IDENTIFIER and
+ ({SupportedAttributes}) constrains the OBJECT IDENTIFIER to be a
+ supported attribute type.
+
+ ATTRIBUTE.&Type denotes an open type, in this case an attribute
+ value, and ({SupportedAttributes}{@type}) is a component relation
+ constraint that constrains the open type to be of the attribute
+ syntax for the attribute type. The component relation constraint
+ references only the "type" component, which has the ASN.1 type of
+ OBJECT IDENTIFIER, thus if the <select> form of ComponentId is used
+ to identify attribute values of specific attribute types it will
+ contain a single OBJECT IDENTIFIER value.
+
+ The component reference "value" on AttributeTypeAndValue refers to
+ the open type.
+
+ One of the X.500 standard attributes is facsimileTelephoneNumber
+ [12], which is identified with the OBJECT IDENTIFIER 2.5.4.23, and is
+ defined to have the following syntax.
+
+ FacsimileTelephoneNumber ::= SEQUENCE {
+ telephoneNumber PrintableString(SIZE(1..ub-telephone-number)),
+ parameters G3FacsimileNonBasicParameters OPTIONAL }
+
+ The component reference "value.(2.5.4.23)" on AttributeTypeAndValue
+ specifies an attribute value with the FacsimileTelephoneNumber
+ syntax.
+
+ The component reference "value.(2.5.4.23).telephoneNumber" on
+ AttributeTypeAndValue identifies the telephoneNumber component of a
+ facsimileTelephoneNumber attribute value. The component reference
+ "value.(facsimileTelephoneNumber)" is equivalent to
+ "value.(2.5.4.23)".
+
+ If the AttributeTypeAndValue ASN.1 value contains an attribute type
+ other than facsimileTelephoneNumber then there are no corresponding
+ component values for the component references "value.(2.5.4.23)" and
+ "value.(2.5.4.23).telephoneNumber".
+
+
+
+
+
+
+
+
+
+Legg Standards Track [Page 13]
+
+RFC 3687 LDAP and X.500 Component Matching Rules February 2004
+
+
+3.1.7. Referencing Contained Types
+
+ Sometimes the contents of a BIT STRING or OCTET STRING value are
+ required to be the encodings of other ASN.1 values of specific ASN.1
+ types. For example, the extnValue component of the Extension type
+ component in the Certificate type [11] is an OCTET STRING that is
+ required to contain a Distinguished Encoding Rules (DER) [17]
+ encoding of a certificate extension value. It is useful to be able
+ to refer to the embedded encoded value and its components. An
+ embedded encoded value is here referred to as a contained value and
+ its associated type as the contained type.
+
+ If the ASN.1 type is a BIT STRING or OCTET STRING type containing
+ encodings of other ASN.1 values then the <content> form of
+ ComponentId may be used to identify the contained type.
+ Subcomponents of that type can then be identified with further
+ ComponentIds.
+
+ The contained type may be (effectively) an open type, constrained by
+ some other component in an outer enclosing type (e.g., in a
+ certificate Extension, extnValue is constrained by the chosen
+ extnId). In these cases the next ComponentId, if any, MUST be of the
+ <select> form.
+
+ For the purpose of building component references, the content of the
+ extnValue OCTET STRING in the Extension type is assumed to be an open
+ type having a notional component relation constraint with the extnId
+ component as the single referenced component, i.e.,
+
+ EXTENSION.&ExtnType ({ExtensionSet}{@extnId})
+
+ The data-value component of the associated types for the EMBEDDED PDV
+ and CHARACTER STRING types is an OCTET STRING containing the encoding
+ of a data value described by the identification component. For the
+ purpose of building component references, the content of the
+ data-value OCTET STRING in these types is assumed to be an open type
+ having a notional component relation constraint with the
+ identification component as the single referenced component.
+
+3.1.7.1. Contained Type Referencing Example
+
+ The Extension ASN.1 type [11] describes a single certificate
+ extension value of a nominated extension type.
+
+
+
+
+
+
+
+
+Legg Standards Track [Page 14]
+
+RFC 3687 LDAP and X.500 Component Matching Rules February 2004
+
+
+ Extension ::= SEQUENCE {
+ extnId EXTENSION.&id ({ExtensionSet}),
+ critical BOOLEAN DEFAULT FALSE,
+ extnValue OCTET STRING
+ -- contains a DER encoding of a value of type &ExtnType
+ -- for the extension object identified by extnId -- }
+
+ EXTENSION.&id denotes an OBJECT IDENTIFIER and ({ExtensionSet})
+ constrains the OBJECT IDENTIFIER to be the identifier of a supported
+ certificate extension.
+
+ The component reference "extnValue" on Extension refers to a
+ component type of OCTET STRING. The corresponding component values
+ will be OCTET STRING values. The component reference
+ "extnValue.content" on Extension refers to the type of the contained
+ type, which in this case is an open type.
+
+ One of the X.509 [11] standard extensions is basicConstraints, which
+ is identified with the OBJECT IDENTIFIER 2.5.29.19 and is defined to
+ have the following syntax.
+
+ BasicConstraintsSyntax ::= SEQUENCE {
+ cA BOOLEAN DEFAULT FALSE,
+ pathLenConstraint INTEGER (0..MAX) OPTIONAL }
+
+ The component reference "extnValue.content.(2.5.29.19)" on Extension
+ specifies a BasicConstraintsSyntax extension value and the component
+ reference "extnValue.content.(2.5.29.19).cA" identifies the cA
+ component of a BasicConstraintsSyntax extension value.
+
+3.2. Matching of Components
+
+ The rule in a ComponentAssertion specifies how the zero, one or more
+ component values identified by the component reference are tested by
+ the assertion. Attribute matching rules are used to specify the
+ semantics of the test.
+
+ Each matching rule has a notional set of attribute syntaxes
+ (typically one), defined as ASN.1 types, to which it may be applied.
+ When used in a ComponentAssertion these matching rules apply to the
+ same ASN.1 types, only in this context the corresponding ASN.1 values
+ are not necessarily complete attribute values.
+
+ Note that the referenced component type may be a tagged and/or
+ constrained version of the expected attribute syntax (e.g.,
+ [0] INTEGER, whereas integerMatch would expect simply INTEGER), or an
+ open type. Additional type substitutions of the kind described in
+
+
+
+
+Legg Standards Track [Page 15]
+
+RFC 3687 LDAP and X.500 Component Matching Rules February 2004
+
+
+ Section 3.1.1 are performed as required to reduce the component type
+ to the same type as the attribute syntax expected by the matching
+ rule.
+
+ If a matching rule applies to more than one attribute syntax (e.g.,
+ objectIdentifierFirstComponentMatch [12]) then the minimum number of
+ substitutions required to conform to any one of those syntaxes is
+ performed. If a matching rule can apply to any attribute syntax
+ (e.g., the allComponentsMatch rule defined in Section 6.2) then the
+ referenced component type is used as is, with no additional
+ substitutions.
+
+ The value in a ComponentAssertion will be of the assertion syntax
+ (i.e., ASN.1 type) required by the chosen matching rule. Note that
+ the assertion syntax of a matching rule is not necessarily the same
+ as the attribute syntax(es) to which the rule may be applied.
+
+ Some matching rules do not have a fixed assertion syntax (e.g.,
+ allComponentsMatch). The required assertion syntax is determined in
+ each instance of use by the syntax of the attribute type to which the
+ matching rule is applied. For these rules the ASN.1 type of the
+ referenced component is used in place of an attribute syntax to
+ decide the required assertion syntax.
+
+ The ComponentAssertion is Undefined if:
+
+ a) the matching rule in the ComponentAssertion is not known to the
+ evaluating procedure,
+
+ b) the matching rule is not applicable to the referenced component
+ type, even with the additional type substitutions,
+
+ c) the value in the ComponentAssertion does not conform to the
+ assertion syntax defined for the matching rule,
+
+ d) some part of the component reference identifies an open type in
+ the tested value that cannot be decoded, or
+
+ e) the implementation does not support the particular combination of
+ component reference and matching rule.
+
+ If the ComponentAssertion is not Undefined then the
+ ComponentAssertion evaluates to TRUE if there is at least one
+ component value for which the matching rule applied to that component
+ value returns TRUE, and evaluates to FALSE otherwise (which includes
+ the case where there are no component values).
+
+
+
+
+
+Legg Standards Track [Page 16]
+
+RFC 3687 LDAP and X.500 Component Matching Rules February 2004
+
+
+3.2.1. Applicability of Existing Matching Rules
+
+3.2.1.1. String Matching
+
+ ASN.1 has a number of built in restricted character string types with
+ different character sets and/or different character encodings. A
+ directory user generally has little interest in the particular
+ character set or encoding used to represent a character string
+ component value, and some directory server implementations make no
+ distinction between the different string types in their internal
+ representation of values. So rather than define string matching
+ rules for each of the restricted character string types, the existing
+ case ignore and case exact string matching rules are extended to
+ apply to component values of any of the restricted character string
+ types and any ChoiceOfStrings type [9], in addition to component
+ values of the DirectoryString type. This extension is only for the
+ purposes of component matching described in this document.
+
+ The relevant string matching rules are: caseIgnoreMatch,
+ caseIgnoreOrderingMatch, caseIgnoreSubstringsMatch, caseExactMatch,
+ caseExactOrderingMatch and caseExactSubstringsMatch. The relevant
+ restricted character string types are: NumericString,
+ PrintableString, VisibleString, IA5String, UTF8String, BMPString,
+ UniversalString, TeletexString, VideotexString, GraphicString and
+ GeneralString. A ChoiceOfStrings type is a purely syntactic CHOICE
+ of these ASN.1 string types. Note that GSER [9] declares each and
+ every use of the DirectoryString{} parameterized type to be a
+ ChoiceOfStrings type.
+
+ The assertion syntax of the string matching rules is still
+ DirectoryString regardless of the string syntax of the component
+ being matched. Thus an implementation will be called upon to compare
+ a DirectoryString value to a value of one of the restricted character
+ string types, or a ChoiceOfStrings type. As is the case when
+ comparing two DirectoryStrings where the chosen alternatives are of
+ different string types, the comparison proceeds so long as the
+ corresponding characters are representable in both character sets.
+ Otherwise matching returns FALSE.
+
+3.2.1.2. Telephone Number Matching
+
+ Early editions of X.520 [12] gave the syntax of the telephoneNumber
+ attribute as a constrained PrintableString. The fourth edition of
+ X.520 equates the ASN.1 type name TelephoneNumber to the constrained
+ PrintableString and uses TelephoneNumber as the attribute and
+ assertion syntax. For the purposes of component matching,
+
+
+
+
+
+Legg Standards Track [Page 17]
+
+RFC 3687 LDAP and X.500 Component Matching Rules February 2004
+
+
+ telephoneNumberMatch and telephoneNumberSubstringsMatch are permitted
+ to be applied to any PrintableString value, as well as to
+ TelephoneNumber values.
+
+3.2.1.3. Distinguished Name Matching
+
+ The DistinguishedName type is defined by assignment to be the same as
+ the RDNSequence type, however RDNSequence is sometimes directly used
+ in other type definitions. For the purposes of component matching,
+ distinguishedNameMatch is also permitted to be applied to values of
+ the RDNSequence type.
+
+3.2.2. Additional Useful Matching Rules
+
+ This section defines additional matching rules that may prove useful
+ in ComponentAssertions. These rules may also be used in
+ extensibleMatch search filters [3].
+
+3.2.2.1. The rdnMatch Matching Rule
+
+ The distinguishedNameMatch matching rule can match whole
+ distinguished names but it is sometimes useful to be able to match
+ specific Relative Distinguished Names (RDNs) in a Distinguished Name
+ (DN) without regard for the other RDNs in the DN. The rdnMatch
+ matching rule allows component RDNs of a DN to be tested.
+
+ The LDAP-style definitions for rdnMatch and its assertion syntax are:
+
+ ( 1.2.36.79672281.1.13.3 NAME 'rdnMatch'
+ SYNTAX 1.2.36.79672281.1.5.0 )
+
+ ( 1.2.36.79672281.1.5.0 DESC 'RDN' )
+
+ The LDAP-specific encoding for a value of the RDN syntax is given by
+ the <RelativeDistinguishedNameValue> rule [9].
+
+ The X.500-style definition for rdnMatch is:
+
+ rdnMatch MATCHING-RULE ::= {
+ SYNTAX RelativeDistinguishedName
+ ID { 1 2 36 79672281 1 13 3 } }
+
+ The rdnMatch rule evaluates to true if the component value and
+ assertion value are the same RDN, using the same RDN comparison
+ method as distinguishedNameMatch.
+
+
+
+
+
+
+Legg Standards Track [Page 18]
+
+RFC 3687 LDAP and X.500 Component Matching Rules February 2004
+
+
+ When using rdnMatch to match components of DNs it is important to
+ note that the LDAP-specific encoding of a DN [5] reverses the order
+ of the RDNs. So for the DN represented in LDAP as
+ "cn=Steven Legg,o=Adacel,c=AU", the RDN "cn=Steven Legg" corresponds
+ to the component reference "3", or alternatively, "-1".
+
+3.2.2.2. The presentMatch Matching Rule
+
+ At times it would be useful to test not if a specific value of a
+ particular component is present, but whether any value of a
+ particular component is present. The presentMatch matching rule
+ allows the presence of a particular component value to be tested.
+
+ The LDAP-style definitions for presentMatch and its assertion syntax
+ are:
+
+ ( 1.2.36.79672281.1.13.5 NAME 'presentMatch'
+ SYNTAX 1.2.36.79672281.1.5.1 )
+
+ ( 1.2.36.79672281.1.5.1 DESC 'NULL' )
+
+ The LDAP-specific encoding for a value of the NULL syntax is given by
+ the <NullValue> rule [9].
+
+ The X.500-style definition for presentMatch is:
+
+ presentMatch MATCHING-RULE ::= {
+ SYNTAX NULL
+ ID { 1 2 36 79672281 1 13 5 } }
+
+ When used in a extensible match filter item, presentMatch behaves
+ like the "present" case of a regular search filter. In a
+ ComponentAssertion, presentMatch evaluates to TRUE if and only if the
+ component reference identifies one or more component values,
+ regardless of the actual component value contents. Note that if
+ useDefaultValues is TRUE then the identified component values may be
+ (part of) a DEFAULT value.
+
+ The notional count referenced by the <count> form of ComponentId is
+ taken to be present if the SET OF value is present, and absent
+ otherwise. Note that in ASN.1 notation an absent SET OF value is
+ distinctly different from a SET OF value that is present but empty.
+ It is up to the specification using the ASN.1 notation to decide
+ whether the distinction matters. Often an empty SET OF component and
+ an absent SET OF component are treated as semantically equivalent.
+ If a SET OF value is present, but empty, a presentMatch on the SET OF
+ component SHALL return TRUE and the notional count SHALL be regarded
+ as present and equal to zero.
+
+
+
+Legg Standards Track [Page 19]
+
+RFC 3687 LDAP and X.500 Component Matching Rules February 2004
+
+
+3.2.3. Summary of Useful Matching Rules
+
+ The following is a non-exhaustive list of useful matching rules and
+ the ASN.1 types to which they can be applied, taking account of all
+ the extensions described in Section 3.2.1, and the new matching rules
+ defined in Section 3.2.2.
+
+ +================================+==============================+
+ | Matching Rule | ASN.1 Type |
+ +================================+==============================+
+ | bitStringMatch | BIT STRING |
+ +--------------------------------+------------------------------+
+ | booleanMatch | BOOLEAN |
+ +--------------------------------+------------------------------+
+ | caseIgnoreMatch | NumericString |
+ | caseIgnoreOrderingMatch | PrintableString |
+ | caseIgnoreSubstringsMatch | VisibleString (ISO646String) |
+ | caseExactMatch | IA5String |
+ | caseExactOrderingMatch | UTF8String |
+ | caseExactSubstringsMatch | BMPString (UCS-2, UNICODE) |
+ | | UniversalString (UCS-4) |
+ | | TeletexString (T61String) |
+ | | VideotexString |
+ | | GraphicString |
+ | | GeneralString |
+ | | any ChoiceOfStrings type |
+ +--------------------------------+------------------------------+
+ | caseIgnoreIA5Match | IA5String |
+ | caseExactIA5Match | |
+ +--------------------------------+------------------------------+
+ | distinguishedNameMatch | DistinguishedName |
+ | | RDNSequence |
+ +--------------------------------+------------------------------+
+ | generalizedTimeMatch | GeneralizedTime |
+ | generalizedTimeOrderingMatch | |
+ +--------------------------------+------------------------------+
+ | integerMatch | INTEGER |
+ | integerOrderingMatch | |
+ +--------------------------------+------------------------------+
+ | numericStringMatch | NumericString |
+ | numericStringOrderingMatch | |
+ | numericStringSubstringsMatch | |
+ +--------------------------------+------------------------------+
+ | objectIdentifierMatch | OBJECT IDENTIFIER |
+ +--------------------------------+------------------------------+
+ | octetStringMatch | OCTET STRING |
+ | octetStringOrderingMatch | |
+ | octetStringSubstringsMatch | |
+
+
+
+Legg Standards Track [Page 20]
+
+RFC 3687 LDAP and X.500 Component Matching Rules February 2004
+
+
+ +--------------------------------+------------------------------+
+ | presentMatch | any ASN.1 type |
+ +--------------------------------+------------------------------+
+ | rdnMatch | RelativeDistinguishedName |
+ +--------------------------------+------------------------------+
+ | telephoneNumberMatch | PrintableString |
+ | telephoneNumberSubstringsMatch | TelephoneNumber |
+ +--------------------------------+------------------------------+
+ | uTCTimeMatch | UTCTime |
+ | uTCTimeOrderingMatch | |
+ +--------------------------------+------------------------------+
+
+ Note that the allComponentsMatch matching rule defined in Section 6.2
+ can be used for equality matching of values of the ENUMERATED, NULL,
+ REAL and RELATIVE-OID ASN.1 types, among other things.
+
+4. ComponentFilter
+
+ The ComponentAssertion allows the value(s) of any one component type
+ in a complex ASN.1 type to be matched, but there is often a desire to
+ match the values of more than one component type. A ComponentFilter
+ is an assertion about the presence, or values of, multiple components
+ within an ASN.1 value.
+
+ The ComponentFilter assertion, an expression of ComponentAssertions,
+ evaluates to either TRUE, FALSE or Undefined for each tested ASN.1
+ value.
+
+ A ComponentFilter is described by the following ASN.1 type (assumed
+ to be defined with "EXPLICIT TAGS" in force):
+
+ ComponentFilter ::= CHOICE {
+ item [0] ComponentAssertion,
+ and [1] SEQUENCE OF ComponentFilter,
+ or [2] SEQUENCE OF ComponentFilter,
+ not [3] ComponentFilter }
+
+ Note: despite the use of SEQUENCE OF instead of SET OF for the "and"
+ and "or" alternatives in ComponentFilter, the order of the component
+ filters is not significant.
+
+ A ComponentFilter that is a ComponentAssertion evaluates to TRUE if
+ the ComponentAssertion is TRUE, evaluates to FALSE if the
+ ComponentAssertion is FALSE, and evaluates to Undefined otherwise.
+
+
+
+
+
+
+
+Legg Standards Track [Page 21]
+
+RFC 3687 LDAP and X.500 Component Matching Rules February 2004
+
+
+ The "and" of a sequence of component filters evaluates to TRUE if the
+ sequence is empty or if each component filter evaluates to TRUE,
+ evaluates to FALSE if at least one component filter is FALSE, and
+ evaluates to Undefined otherwise.
+
+ The "or" of a sequence of component filters evaluates to FALSE if the
+ sequence is empty or if each component filter evaluates to FALSE,
+ evaluates to TRUE if at least one component filter is TRUE, and
+ evaluates to Undefined otherwise.
+
+ The "not" of a component filter evaluates to TRUE if the component
+ filter is FALSE, evaluates to FALSE if the component filter is TRUE,
+ and evaluates to Undefined otherwise.
+
+5. The componentFilterMatch Matching Rule
+
+ The componentFilterMatch matching rule allows a ComponentFilter to be
+ applied to an attribute value. The result of the matching rule is
+ the result of applying the ComponentFilter to the attribute value.
+
+ The LDAP-style definitions for componentFilterMatch and its assertion
+ syntax are:
+
+ ( 1.2.36.79672281.1.13.2 NAME 'componentFilterMatch'
+ SYNTAX 1.2.36.79672281.1.5.2 )
+
+ ( 1.2.36.79672281.1.5.2 DESC 'ComponentFilter' )
+
+ The LDAP-specific encoding for the ComponentFilter assertion syntax
+ is specified by GSER [9].
+
+ As a convenience to implementors, an equivalent ABNF description of
+ the GSER encoding for ComponentFilter is provided here. In the event
+ that there is a discrepancy between this ABNF and the encoding
+ determined by GSER, GSER is to be taken as definitive. The GSER
+ encoding of a ComponentFilter is described by the following
+ equivalent ABNF:
+
+ ComponentFilter = filter-item /
+ and-filter /
+ or-filter /
+ not-filter
+
+ filter-item = item-chosen ComponentAssertion
+ and-filter = and-chosen SequenceOfComponentFilter
+ or-filter = or-chosen SequenceOfComponentFilter
+ not-filter = not-chosen ComponentFilter
+
+
+
+
+Legg Standards Track [Page 22]
+
+RFC 3687 LDAP and X.500 Component Matching Rules February 2004
+
+
+ item-chosen = %x69.74.65.6D.3A ; "item:"
+ and-chosen = %x61.6E.64.3A ; "and:"
+ or-chosen = %x6F.72.3A ; "or:"
+ not-chosen = %x6E.6F.74.3A ; "not:"
+
+ SequenceOfComponentFilter = "{" [ sp ComponentFilter
+ *( "," sp ComponentFilter) ] sp "}"
+
+ ComponentAssertion = "{" [ sp component "," ]
+ [ sp useDefaultValues "," ]
+ sp rule ","
+ sp assertion-value sp "}"
+ component = component-label msp StringValue
+ useDefaultValues = use-defaults-label msp BooleanValue
+ rule = rule-label msp ObjectIdentifierValue
+ assertion-value = value-label msp Value
+
+ component-label = %x63.6F.6D.70.6F.6E.65.6E.74 ; "component"
+ use-defaults-label = %x75.73.65.44.65.66.61.75.6C.74.56.61.6C.75
+ %x65.73 ; "useDefaultValues"
+ rule-label = %x72.75.6C.65 ; "rule"
+ value-label = %x76.61.6C.75.65 ; "value"
+
+ sp = *%x20 ; zero, one or more space characters
+ msp = 1*%x20 ; one or more space characters
+
+ The ABNF for <Value>, <StringValue>, <ObjectIdentifierValue> and
+ <BooleanValue> is defined by GSER [9].
+
+ The ABNF descriptions of LDAP-specific encodings for attribute
+ syntaxes typically do not clearly or consistently delineate the
+ component parts of an attribute value. A regular and uniform
+ character string encoding for arbitrary component data types is
+ needed to encode the assertion value in a ComponentAssertion. The
+ <Value> rule from GSER provides a human readable text encoding for a
+ component value of any arbitrary ASN.1 type.
+
+ The X.500-style definition [10] for componentFilterMatch is:
+
+ componentFilterMatch MATCHING-RULE ::= {
+ SYNTAX ComponentFilter
+ ID { 1 2 36 79672281 1 13 2 } }
+
+ A ComponentAssertion can potentially use any matching rule, including
+ componentFilterMatch, so componentFilterMatch may be nested. The
+ component references in a nested componentFilterMatch are relative to
+
+
+
+
+
+Legg Standards Track [Page 23]
+
+RFC 3687 LDAP and X.500 Component Matching Rules February 2004
+
+
+ the component corresponding to the containing ComponentAssertion. In
+ Section 7, an example search on the seeAlso attribute shows this
+ usage.
+
+6. Equality Matching of Complex Components
+
+ It is possible to test if an attribute value of a complex ASN.1
+ syntax is the same as some purported (i.e., assertion) value by using
+ a complicated ComponentFilter that tests if corresponding components
+ are the same. However, it would be more convenient to be able to
+ present a whole assertion value to a matching rule that could do the
+ component-wise comparison of an attribute value with the assertion
+ value for any arbitrary attribute syntax. Similarly, the ability to
+ do a straightforward equality comparison of a component value that is
+ itself of a complex ASN.1 type would also be convenient.
+
+ It would be difficult to define a single matching rule that
+ simultaneously satisfies all notions of what the equality matching
+ semantics should be. For example, in some instances a case sensitive
+ comparison of string components may be preferable to a case
+ insensitive comparison. Therefore a basic equality matching rule,
+ allComponentsMatch, is defined in Section 6.2, and the means to
+ derive new matching rules from it with slightly different equality
+ matching semantics are described in Section 6.3.
+
+ The directoryComponentsMatch defined in Section 6.4 is a derivation
+ of allComponentsMatch that suits typical uses of the directory.
+ Other specifications are free to derive new rules from
+ allComponentsMatch or directoryComponentsMatch, that suit their usage
+ of the directory.
+
+ The allComponentsMatch rule, the directoryComponentsMatch rule and
+ any matching rules derived from them are collectively called
+ component equality matching rules.
+
+6.1. The OpenAssertionType Syntax
+
+ The component equality matching rules have a variable assertion
+ syntax. In X.500 this is indicated by omitting the optional SYNTAX
+ field in the MATCHING-RULE information object. The assertion syntax
+ then defaults to the target attribute's syntax in actual usage,
+ unless the description of the matching rule says otherwise. The
+ SYNTAX field in the LDAP-specific encoding of a
+ MatchingRuleDescription is mandatory, so the OpenAssertionType syntax
+ is defined to fill the same role. That is, the OpenAssertionType
+ syntax is semantically equivalent to an omitted SYNTAX field in an
+ X.500 MATCHING-RULE information object. OpenAssertionType MUST NOT
+ be used as the attribute syntax in an attribute type definition.
+
+
+
+Legg Standards Track [Page 24]
+
+RFC 3687 LDAP and X.500 Component Matching Rules February 2004
+
+
+ Unless explicitly varied by the description of a particular matching
+ rule, if an OpenAssertionType assertion value appears in a
+ ComponentAssertion its LDAP-specific encoding is described by the
+ <Value> rule in GSER [9], otherwise its LDAP-specific encoding is the
+ encoding defined for the syntax of the attribute type to which the
+ matching rule with the OpenAssertionType assertion syntax is applied.
+
+ The LDAP definition for the OpenAssertionType syntax is:
+
+ ( 1.2.36.79672281.1.5.3 DESC 'OpenAssertionType' )
+
+6.2. The allComponentsMatch Matching Rule
+
+ The LDAP-style definition for allComponentsMatch is:
+
+ ( 1.2.36.79672281.1.13.6 NAME 'allComponentsMatch'
+ SYNTAX 1.2.36.79672281.1.5.3 )
+
+ The X.500-style definition for allComponentsMatch is:
+
+ allComponentsMatch MATCHING-RULE ::= {
+ ID { 1 2 36 79672281 1 13 6 } }
+
+ When allComponentsMatch is used in a ComponentAssertion the assertion
+ syntax is the same as the ASN.1 type of the identified component.
+ Otherwise, the assertion syntax of allComponentsMatch is the same as
+ the attribute syntax of the attribute to which the matching rule is
+ applied.
+
+ Broadly speaking, this matching rule evaluates to true if and only if
+ corresponding components of the assertion value and the attribute or
+ component value are the same.
+
+ In detail, equality is determined by the following cases applied
+ recursively.
+
+ a) Two values of a SET or SEQUENCE type are the same if and only if,
+ for each component type, the corresponding component values are
+ either,
+
+ 1) both absent,
+
+ 2) both present and the same, or
+
+ 3) absent or the same as the DEFAULT value for the component, if a
+ DEFAULT value is defined.
+
+
+
+
+
+Legg Standards Track [Page 25]
+
+RFC 3687 LDAP and X.500 Component Matching Rules February 2004
+
+
+ Values of an EMBEDDED PDV, EXTERNAL, unrestricted CHARACTER
+ STRING, or INSTANCE OF type are compared according to their
+ respective associated SEQUENCE type (see Section 3.1.2).
+
+ b) Two values of a SEQUENCE OF type are the same if and only if, the
+ values have the same number of (possibly duplicated) instances and
+ corresponding instances are the same.
+
+ c) Two values of a SET OF type are the same if and only if, the
+ values have the same number of instances and each distinct
+ instance occurs in both values the same number of times, i.e.,
+ both values have the same instances, including duplicates, but in
+ any order.
+
+ d) Two values of a CHOICE type are the same if and only if, both
+ values are of the same chosen alternative and the component values
+ are the same.
+
+ e) Two BIT STRING values are the same if and only if the values have
+ the same number of bits and corresponding bits are the same. If
+ the BIT STRING type is defined with a named bit list then trailing
+ zero bits in the values are treated as absent for the purposes of
+ this comparison.
+
+ f) Two BOOLEAN values are the same if and only if both are TRUE or
+ both are FALSE.
+
+ g) Two values of a string type are the same if and only if the values
+ have the same number of characters and corresponding characters
+ are the same. Letter case is significant. For the purposes of
+ allComponentsMatch, the string types are NumericString,
+ PrintableString, TeletexString (T61String), VideotexString,
+ IA5String, GraphicString, VisibleString (ISO646String),
+ GeneralString, UniversalString, BMPString, UTF8String,
+ GeneralizedTime, UTCTime and ObjectDescriptor.
+
+ h) Two INTEGER values are the same if and only if the integers are
+ equal.
+
+ i) Two ENUMERATED values are the same if and only if the enumeration
+ item identifiers are the same (equivalently, if the integer values
+ associated with the identifiers are equal).
+
+ j) Two NULL values are always the same, unconditionally.
+
+ k) Two OBJECT IDENTIFIER values are the same if and only if the
+ values have the same number of arcs and corresponding arcs are the
+ same.
+
+
+
+Legg Standards Track [Page 26]
+
+RFC 3687 LDAP and X.500 Component Matching Rules February 2004
+
+
+ l) Two OCTET STRING values are the same if and only if the values
+ have the same number of octets and corresponding octets are the
+ same.
+
+ m) Two REAL values are the same if and only if they are both the same
+ special value, or neither is a special value and they have the
+ same base and represent the same real number. The special values
+ for REAL are zero, PLUS-INFINITY and MINUS-INFINITY.
+
+ n) Two RELATIVE-OID values are the same if and only if the values
+ have the same number of arcs and corresponding arcs are the same.
+ The respective starting nodes for the RELATIVE-OID values are
+ disregarded in the comparison, i.e., they are assumed to be the
+ same.
+
+ o) Two values of an open type are the same if and only if both are of
+ the same ASN.1 type and are the same according to that type. If
+ the actual ASN.1 type of the values is unknown then the
+ allComponentsMatch rule evaluates to Undefined.
+
+ Tags and constraints, being part of the type definition and not part
+ of the abstract values, are ignored for matching purposes.
+
+ The allComponentsMatch rule may be used as the defined equality
+ matching rule for an attribute.
+
+6.3. Deriving Component Equality Matching Rules
+
+ A new component equality matching rule with more refined matching
+ semantics may be derived from allComponentsMatch, or any other
+ component equality matching rule, using the convention described in
+ this section.
+
+ The matching behaviour of a derived component equality matching rule
+ is specified by nominating, for each of one or more identified
+ components, a commutative equality matching rule that will be used to
+ match values of that component. This overrides the matching that
+ would otherwise occur for values of that component using the base
+ rule for the derivation. These overrides can be conveniently
+ represented as rows in a table of the following form.
+
+ Component | Matching Rule
+ ============+===============
+ |
+ |
+
+
+
+
+
+
+Legg Standards Track [Page 27]
+
+RFC 3687 LDAP and X.500 Component Matching Rules February 2004
+
+
+ Usually, all component values of a particular ASN.1 type are to be
+ matched the same way. An ASN.1 type reference (e.g.,
+ DistinguishedName) or an ASN.1 built-in type name (e.g., INTEGER) in
+ the Component column of the table specifies that the nominated
+ equality matching rule is to be applied to all values of the named
+ type, regardless of context.
+
+ An ASN.1 type reference with a component reference appended
+ (separated by a ".") specifies that the nominated matching rule
+ applies only to the identified components of values of the named
+ type. Other component values that happen to be of the same ASN.1
+ type are not selected.
+
+ Additional type substitutions as described in Section 3.2 are assumed
+ to be performed to align the component type with the matching rule
+ assertion syntax.
+
+ Conceptually, the rows in a table for the base rule are appended to
+ the rows in the table for a derived rule for the purpose of deciding
+ the matching semantics of the derived rule. Notionally,
+ allComponentsMatch has an empty table.
+
+ A row specifying values of an outer containing type (e.g.,
+ DistinguishedName) takes precedence over a row specifying values of
+ an inner component type (e.g., RelativeDistinguishedName), regardless
+ of their order in the table. Specifying a row for component values
+ of an inner type is only useful if a value of the type can also
+ appear on its own, or as a component of values of a different outer
+ type. For example, if there is a row for DistinguishedName then a
+ row for RelativeDistinguishedName can only ever apply to
+ RelativeDistinguishedName component values that are not part of a
+ DistinguishedName. A row for values of an outer type in the table
+ for the base rule takes precedence over a row for values of an inner
+ type in the table for the derived rule.
+
+ Where more than one row applies to a particular component value the
+ earlier row takes precedence over the later row. Thus rows in the
+ table for the derived rule take precedence over any rows for the same
+ component in the table for the base rule.
+
+6.4. The directoryComponentsMatch Matching Rule
+
+ The directoryComponentsMatch matching rule is derived from the
+ allComponentsMatch matching rule.
+
+
+
+
+
+
+
+Legg Standards Track [Page 28]
+
+RFC 3687 LDAP and X.500 Component Matching Rules February 2004
+
+
+ The LDAP-style definition for directoryComponentsMatch is:
+
+ ( 1.2.36.79672281.1.13.7 NAME 'directoryComponentsMatch'
+ SYNTAX 1.2.36.79672281.1.5.3 )
+
+ The X.500-style definition for directoryComponentsMatch is:
+
+ directoryComponentsMatch MATCHING-RULE ::= {
+ ID { 1 2 36 79672281 1 13 7 } }
+
+ The matching semantics of directoryComponentsMatch are described by
+ the following table, using the convention described in Section 6.3.
+
+ ASN.1 Type | Matching Rule
+ =========================================+========================
+ RDNSequence | distinguishedNameMatch
+ RelativeDistinguishedName | rdnMatch
+ TelephoneNumber | telephoneNumberMatch
+ FacsimileTelephoneNumber.telephoneNumber | telephoneNumberMatch
+ NumericString | numericStringMatch
+ GeneralizedTime | generalizedTimeMatch
+ UTCTime | uTCTimeMatch
+ DirectoryString{} | caseIgnoreMatch
+ BMPString | caseIgnoreMatch
+ GeneralString | caseIgnoreMatch
+ GraphicString | caseIgnoreMatch
+ IA5String | caseIgnoreMatch
+ PrintableString | caseIgnoreMatch
+ TeletexString | caseIgnoreMatch
+ UniversalString | caseIgnoreMatch
+ UTF8String | caseIgnoreMatch
+ VideotexString | caseIgnoreMatch
+ VisibleString | caseIgnoreMatch
+
+ Notes:
+
+ 1) The DistinguishedName type is defined by assignment to be the same
+ as the RDNSequence type. Some types (e.g., Name and LocalName)
+ directly reference RDNSequence rather than DistinguishedName.
+ Specifying RDNSequence captures all these DN-like types.
+
+ 2) A RelativeDistinguishedName value is only matched by rdnMatch if
+ it is not part of an RDNSequence value.
+
+ 3) The telephone number component of the FacsimileTelephoneNumber
+ ASN.1 type [12] is defined as a constrained PrintableString.
+ PrintableString component values that are part of a
+ FacsimileTelephoneNumber value can be identified separately from
+
+
+
+Legg Standards Track [Page 29]
+
+RFC 3687 LDAP and X.500 Component Matching Rules February 2004
+
+
+ other components of PrintableString type by the specifier
+ FacsimileTelephoneNumber.telephoneNumber, so that
+ telephoneNumberMatch can be selectively applied. The fourth
+ edition of X.520 defines the telephoneNumber component of
+ FacsimileTelephoneNumber to be of the type TelephoneNumber, making
+ the row for FacsimileTelephoneNumber.telephoneNumber components
+ redundant.
+
+ The directoryComponentsMatch rule may be used as the defined equality
+ matching rule for an attribute.
+
+7. Component Matching Examples
+
+ This section contains examples of search filters using the
+ componentFilterMatch matching rule. The filters are described using
+ the string representation of LDAP search filters [18]. Note that
+ this representation requires asterisks to be escaped in assertion
+ values (in these examples the assertion values are all
+ <ComponentAssertion> encodings). The asterisks have not been escaped
+ in these examples for the sake of clarity, and to avoid confusing the
+ protocol representation of LDAP search filter assertion values, where
+ such escaping does not apply. Line breaks and indenting have been
+ added only as an aid to readability.
+
+ The example search filters using componentFilterMatch are all single
+ extensible match filter items, though there is no reason why
+ componentFilterMatch can't be used in more complicated search
+ filters.
+
+ The first examples describe searches over the objectClasses schema
+ operational attribute, which has an attribute syntax described by the
+ ASN.1 type ObjectClassDescription [10], and holds the definitions of
+ the object classes known to a directory server. The definition of
+ ObjectClassDescription is as follows:
+
+ ObjectClassDescription ::= SEQUENCE {
+ identifier OBJECT-CLASS.&id,
+ name SET OF DirectoryString {ub-schema} OPTIONAL,
+ description DirectoryString {ub-schema} OPTIONAL,
+ obsolete BOOLEAN DEFAULT FALSE,
+ information [0] ObjectClassInformation }
+
+ ObjectClassInformation ::= SEQUENCE {
+ subclassOf SET OF OBJECT-CLASS.&id OPTIONAL,
+ kind ObjectClassKind DEFAULT structural,
+ mandatories [3] SET OF ATTRIBUTE.&id OPTIONAL,
+ optionals [4] SET OF ATTRIBUTE.&id OPTIONAL }
+
+
+
+
+Legg Standards Track [Page 30]
+
+RFC 3687 LDAP and X.500 Component Matching Rules February 2004
+
+
+ ObjectClassKind ::= ENUMERATED {
+ abstract (0),
+ structural (1),
+ auxiliary (2) }
+
+ OBJECT-CLASS.&id and ATTRIBUTE.&id are equivalent to the OBJECT
+ IDENTIFIER ASN.1 type. A value of OBJECT-CLASS.&id is an OBJECT
+ IDENTIFIER for an object class. A value of ATTRIBUTE.&id is an
+ OBJECT IDENTIFIER for an attribute type.
+
+ The following search filter finds the object class definition for the
+ object class identified by the OBJECT IDENTIFIER 2.5.6.18:
+
+ (objectClasses:componentFilterMatch:=
+ item:{ component "identifier",
+ rule objectIdentifierMatch, value 2.5.6.18 })
+
+ A match on the "identifier" component of objectClasses values is
+ equivalent to the objectIdentifierFirstComponentMatch matching rule
+ applied to attribute values of the objectClasses attribute type. The
+ componentFilterMatch matching rule subsumes the functionality of the
+ objectIdentifierFirstComponentMatch, integerFirstComponentMatch and
+ directoryStringFirstComponentMatch matching rules.
+
+ The following search filter finds the object class definition for the
+ object class called foobar:
+
+ (objectClasses:componentFilterMatch:=
+ item:{ component "name.*",
+ rule caseIgnoreMatch, value "foobar" })
+
+ An object class definition can have multiple names and the above
+ filter will match an objectClasses value if any one of the names is
+ "foobar".
+
+ The component reference "name.0" identifies the notional count of the
+ number of names in an object class definition. The following search
+ filter finds object class definitions with exactly one name:
+
+ (objectClasses:componentFilterMatch:=
+ item:{ component "name.0", rule integerMatch, value 1 })
+
+ The "description" component of an ObjectClassDescription is defined
+ to be an OPTIONAL DirectoryString. The following search filter finds
+ object class definitions that have descriptions, regardless of the
+ contents of the description string:
+
+
+
+
+
+Legg Standards Track [Page 31]
+
+RFC 3687 LDAP and X.500 Component Matching Rules February 2004
+
+
+ (objectClasses:componentFilterMatch:=
+ item:{ component "description",
+ rule presentMatch, value NULL })
+
+ The presentMatch returns TRUE if the description component is present
+ and FALSE otherwise.
+
+ The following search filter finds object class definitions that don't
+ have descriptions:
+
+ (objectClasses:componentFilterMatch:=
+ not:item:{ component "description",
+ rule presentMatch, value NULL })
+
+ The following search filter finds object class definitions with the
+ word "bogus" in the description:
+
+ (objectClasses:componentFilterMatch:=
+ item:{ component "description",
+ rule caseIgnoreSubstringsMatch,
+ value { any:"bogus" } })
+
+ The assertion value is of the SubstringAssertion syntax, i.e.,
+
+ SubstringAssertion ::= SEQUENCE OF CHOICE {
+ initial [0] DirectoryString {ub-match},
+ any [1] DirectoryString {ub-match},
+ final [2] DirectoryString {ub-match} }
+
+ The "obsolete" component of an ObjectClassDescription is defined to
+ be DEFAULT FALSE. An object class is obsolete if the "obsolete"
+ component is present and set to TRUE. The following search filter
+ finds all obsolete object classes:
+
+ (objectClasses:componentFilterMatch:=
+ item:{ component "obsolete", rule booleanMatch, value TRUE })
+
+ An object class is not obsolete if the "obsolete" component is not
+ present, in which case it defaults to FALSE, or is present but is
+ explicitly set to FALSE. The following search filter finds all non-
+ obsolete object classes:
+
+ (objectClasses:componentFilterMatch:=
+ item:{ component "obsolete", rule booleanMatch, value FALSE })
+
+ The useDefaultValues flag in the ComponentAssertion defaults to TRUE
+ so the componentFilterMatch rule treats an absent "obsolete"
+ component as being present and set to FALSE. The following search
+
+
+
+Legg Standards Track [Page 32]
+
+RFC 3687 LDAP and X.500 Component Matching Rules February 2004
+
+
+ filter finds only object class definitions where the "obsolete"
+ component has been explicitly set to FALSE, rather than implicitly
+ defaulting to FALSE:
+
+ (objectClasses:componentFilterMatch:=
+ item:{ component "obsolete", useDefaultValues FALSE,
+ rule booleanMatch, value FALSE })
+
+ With the useDefaultValues flag set to FALSE, if the "obsolete"
+ component is absent the component reference identifies no component
+ value and the matching rule will return FALSE. The matching rule can
+ only return TRUE if the component is present and set to FALSE.
+
+ The "information.kind" component of the ObjectClassDescription is an
+ ENUMERATED type. The allComponentsMatch matching rule can be used to
+ match values of an ENUMERATED type. The following search filter
+ finds object class definitions for auxiliary object classes:
+
+ (objectClasses:componentFilterMatch:=
+ item:{ component "information.kind",
+ rule allComponentsMatch, value auxiliary })
+
+ The following search filter finds auxiliary object classes with
+ commonName (cn or 2.5.4.3) as a mandatory attribute:
+
+ (objectClasses:componentFilterMatch:=and:{
+ item:{ component "information.kind",
+ rule allComponentsMatch, value auxiliary },
+ item:{ component "information.mandatories.*",
+ rule objectIdentifierMatch, value cn } })
+
+ The following search filter finds auxiliary object classes with
+ commonName as a mandatory or optional attribute:
+
+ (objectClasses:componentFilterMatch:=and:{
+ item:{ component "information.kind",
+ rule allComponentsMatch, value auxiliary },
+ or:{
+ item:{ component "information.mandatories.*",
+ rule objectIdentifierMatch, value cn },
+ item:{ component "information.optionals.*",
+ rule objectIdentifierMatch, value cn } } })
+
+ Extra care is required when matching optional SEQUENCE OF or SET OF
+ components because of the distinction between an absent list of
+ instances and a present, but empty, list of instances. The following
+ search filter finds object class definitions with less than three
+
+
+
+
+Legg Standards Track [Page 33]
+
+RFC 3687 LDAP and X.500 Component Matching Rules February 2004
+
+
+ names, including object class definitions with a present but empty
+ list of names, but does not find object class definitions with an
+ absent list of names:
+
+ (objectClasses:componentFilterMatch:=
+ item:{ component "name.0",
+ rule integerOrderingMatch, value 3 })
+
+ If the "name" component is absent the "name.0" component is also
+ considered to be absent and the ComponentAssertion evaluates to
+ FALSE. If the "name" component is present, but empty, the "name.0"
+ component is also present and equal to zero, so the
+ ComponentAssertion evaluates to TRUE. To also find the object class
+ definitions with an absent list of names the following search filter
+ would be used:
+
+ (objectClasses:componentFilterMatch:=or:{
+ not:item:{ component "name", rule presentMatch, value NULL },
+ item:{ component "name.0",
+ rule integerOrderingMatch, value 3 } })
+
+ Distinguished names embedded in other syntaxes can be matched with a
+ componentFilterMatch. The uniqueMember attribute type has an
+ attribute syntax described by the ASN.1 type NameAndOptionalUID.
+
+ NameAndOptionalUID ::= SEQUENCE {
+ dn DistinguishedName,
+ uid UniqueIdentifier OPTIONAL }
+
+ The following search filter finds values of the uniqueMember
+ attribute containing the author's DN:
+
+ (uniqueMember:componentFilterMatch:=
+ item:{ component "dn",
+ rule distinguishedNameMatch,
+ value "cn=Steven Legg,o=Adacel,c=AU" })
+
+ The DistinguishedName and RelativeDistinguishedName ASN.1 types are
+ also complex ASN.1 types so the component matching rules can be
+ applied to their inner components.
+
+ DistinguishedName ::= RDNSequence
+
+ RDNSequence ::= SEQUENCE OF RelativeDistinguishedName
+
+ RelativeDistinguishedName ::= SET SIZE (1..MAX) OF
+ AttributeTypeAndValue
+
+
+
+
+Legg Standards Track [Page 34]
+
+RFC 3687 LDAP and X.500 Component Matching Rules February 2004
+
+
+ AttributeTypeAndValue ::= SEQUENCE {
+ type AttributeType ({SupportedAttributes}),
+ value AttributeValue ({SupportedAttributes}{@type}) }
+
+ AttributeType ::= ATTRIBUTE.&id
+
+ AttributeValue ::= ATTRIBUTE.&Type
+
+ ATTRIBUTE.&Type is an open type. A value of ATTRIBUTE.&Type is
+ constrained by the type component of AttributeTypeAndValue to be of
+ the attribute syntax of the nominated attribute type. Note: the
+ fourth edition of X.500 extends and renames the AttributeTypeAndValue
+ SEQUENCE type.
+
+ The seeAlso attribute has the DistinguishedName syntax. The
+ following search filter finds seeAlso attribute values containing the
+ RDN, "o=Adacel", anywhere in the DN:
+
+ (seeAlso:componentFilterMatch:=
+ item:{ component "*", rule rdnMatch, value "o=Adacel" })
+
+ The following search filter finds all seeAlso attribute values with
+ "cn=Steven Legg" as the RDN of the named entry (i.e., the "first" RDN
+ in an LDAPDN or the "last" RDN in an X.500 DN):
+
+ (seeAlso:componentFilterMatch:=
+ item:{ component "-1",
+ rule rdnMatch, value "cn=Steven Legg" })
+
+ The following search filter finds all seeAlso attribute values naming
+ entries in the DIT subtree of "o=Adacel,c=AU":
+
+ (seeAlso:componentFilterMatch:=and:{
+ item:{ component "1", rule rdnMatch, value "c=AU" },
+ item:{ component "2", rule rdnMatch, value "o=Adacel" } })
+
+ The following search filter finds all seeAlso attribute values
+ containing the naming attribute types commonName (cn) and
+ telephoneNumber in the same RDN:
+
+ (seeAlso:componentFilterMatch:=
+ item:{ component "*", rule componentFilterMatch,
+ value and:{
+ item:{ component "*.type",
+ rule objectIdentifierMatch, value cn },
+ item:{ component "*.type",
+ rule objectIdentifierMatch,
+ value telephoneNumber } } })
+
+
+
+Legg Standards Track [Page 35]
+
+RFC 3687 LDAP and X.500 Component Matching Rules February 2004
+
+
+ The following search filter would find all seeAlso attribute values
+ containing the attribute types commonName and telephoneNumber, but
+ not necessarily in the same RDN:
+
+ (seeAlso:componentFilterMatch:=and:{
+ item:{ component "*.*.type",
+ rule objectIdentifierMatch, value cn },
+ item:{ component "*.*.type",
+ rule objectIdentifierMatch, value telephoneNumber } })
+
+ The following search filter finds all seeAlso attribute values
+ containing the word "Adacel" in any organizationalUnitName (ou)
+ attribute value in any AttributeTypeAndValue of any RDN:
+
+ (seeAlso:componentFilterMatch:=
+ item:{ component "*.*.value.(2.5.4.11)",
+ rule caseIgnoreSubstringsMatch,
+ value { any:"Adacel" } })
+
+ The component reference "*.*.value" identifies an open type, in this
+ case an attribute value. In a particular AttributeTypeAndValue, if
+ the attribute type is not organizationalUnitName then the
+ ComponentAssertion evaluates to FALSE. Otherwise the substring
+ assertion is evaluated against the attribute value.
+
+ Absent component references in ComponentAssertions can be exploited
+ to avoid false positive matches on multi-valued attributes. For
+ example, suppose there is a multi-valued attribute named
+ productCodes, defined to have the Integer syntax
+ (1.3.6.1.4.1.1466.115.121.1.27). Consider the following search
+ filter:
+
+ (&(!(productCodes:integerOrderingMatch:=3))
+ (productCodes:integerOrderingMatch:=8))
+
+ An entry whose productCodes attribute contains only the values 1 and
+ 10 will match the above filter. The first subfilter is satisfied by
+ the value 10 (10 is not less than 3), and the second subfilter is
+ satisfied by the value 1 (1 is less than 8). The following search
+ filter can be used instead to only match entries that have a
+ productCodes value in the range 3 to 7, because the ComponentFilter
+ is evaluated against each productCodes value in isolation:
+
+ (productCodes:componentFilterMatch:= and:{
+ not:item:{ rule integerOrderingMatch, value 3 },
+ item:{ rule integerOrderingMatch, value 8 } })
+
+
+
+
+
+Legg Standards Track [Page 36]
+
+RFC 3687 LDAP and X.500 Component Matching Rules February 2004
+
+
+ An entry whose productCodes attribute contains only the values 1 and
+ 10 will not match the above filter.
+
+8. Security Considerations
+
+ The component matching rules described in this document allow for a
+ compact specification of matching capabilities that could otherwise
+ have been defined by a plethora of specific matching rules, i.e.,
+ despite their expressiveness and flexibility the component matching
+ rules do not behave in a way uncharacteristic of other matching
+ rules, so the security issues for component matching rules are no
+ different than for any other matching rule. However, because the
+ component matching rules are applicable to any attribute syntax,
+ support for them in a directory server may allow searching of
+ attributes that were previously unsearchable by virtue of there not
+ being a suitable matching rule. Such attribute types ought to be
+ properly protected with appropriate access controls. A generic,
+ interoperable access control mechanism has not yet been developed,
+ however, and implementors should be aware of the interaction of that
+ lack with the increased risk of exposure described above.
+
+9. Acknowledgements
+
+ The author would like to thank Tom Gindin for private email
+ discussions that clarified and refined the ideas presented in this
+ document.
+
+10. IANA Considerations
+
+ The Internet Assigned Numbers Authority (IANA) has updated the LDAP
+ descriptors registry [8] as indicated by the following templates:
+
+ Subject: Request for LDAP Descriptor Registration
+ Descriptor (short name): componentFilterMatch
+ Object Identifier: 1.2.36.79672281.1.13.2
+ Person & email address to contact for further information:
+ Steven Legg <steven.legg at adacel.com.au>
+ Usage: other (matching rule)
+ Specification: RFC 3687
+ Author/Change Controller: IESG
+
+
+
+
+
+
+
+
+
+
+
+Legg Standards Track [Page 37]
+
+RFC 3687 LDAP and X.500 Component Matching Rules February 2004
+
+
+ Subject: Request for LDAP Descriptor Registration
+ Descriptor (short name): rdnMatch
+ Object Identifier: 1.2.36.79672281.1.13.3
+ Person & email address to contact for further information:
+ Steven Legg <steven.legg at adacel.com.au>
+ Usage: other (matching rule)
+ Specification: RFC 3687
+ Author/Change Controller: IESG
+
+ Subject: Request for LDAP Descriptor Registration
+ Descriptor (short name): presentMatch
+ Object Identifier: 1.2.36.79672281.1.13.5
+ Person & email address to contact for further information:
+ Steven Legg <steven.legg at adacel.com.au>
+ Usage: other (matching rule)
+ Specification: RFC 3687
+ Author/Change Controller: IESG
+
+ Subject: Request for LDAP Descriptor Registration
+ Descriptor (short name): allComponentsMatch
+ Object Identifier: 1.2.36.79672281.1.13.6
+ Person & email address to contact for further information:
+ Steven Legg <steven.legg at adacel.com.au>
+ Usage: other (matching rule)
+ Specification: RFC 3687
+ Author/Change Controller: IESG
+
+ Subject: Request for LDAP Descriptor Registration
+ Descriptor (short name): directoryComponentsMatch
+ Object Identifier: 1.2.36.79672281.1.13.7
+ Person & email address to contact for further information:
+ Steven Legg <steven.legg at adacel.com.au>
+ Usage: other (matching rule)
+ Specification: RFC 3687
+ Author/Change Controller: IESG
+
+ The object identifiers have been assigned for use in this
+ specification by Adacel Technologies, under an arc assigned to Adacel
+ by Standards Australia.
+
+11. References
+
+11.1. Normative References
+
+ [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+ Levels", BCP 14, RFC 2119, March 1997.
+
+
+
+
+
+Legg Standards Track [Page 38]
+
+RFC 3687 LDAP and X.500 Component Matching Rules February 2004
+
+
+ [2] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
+ Specifications: ABNF", RFC 2234, November 1997.
+
+ [3] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access
+ Protocol (v3)", RFC 2251, December 1997.
+
+ [4] Wahl, M., Coulbeck, A., Howes, T. and S. Kille, "Lightweight
+ Directory Access Protocol (v3): Attribute Syntax Definitions",
+ RFC 2252, December 1997.
+
+ [5] Wahl, M., Kille S. and T. Howes. "Lightweight Directory Access
+ Protocol (v3): UTF-8 String Representation of Distinguished
+ Names", RFC 2253, December 1997.
+
+ [6] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD
+ 63, RFC 3629, November 2003.
+
+ [7] Hodges, J. and R. Morgan, "Lightweight Directory Access
+ Protocol (v3): Technical Specification", RFC 3377, September
+ 2002.
+
+ [8] Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
+ Considerations for the Lightweight Directory Access Protocol
+ (LDAP)", BCP 64, RFC 3383, September 2002.
+
+ [9] Legg, S., "Generic String Encoding Rules (GSER) for ASN.1
+ Types", RFC 3641, October 2003.
+
+ [10] ITU-T Recommendation X.501 (1993) | ISO/IEC 9594-2:1994,
+ Information Technology - Open Systems Interconnection - The
+ Directory: Models
+
+ [11] ITU-T Recommendation X.509 (1997) | ISO/IEC 9594-8:1998,
+ Information Technology - Open Systems Interconnection - The
+ Directory: Authentication Framework
+
+ [12] ITU-T Recommendation X.520 (1993) | ISO/IEC 9594-6:1994,
+ Information technology - Open Systems Interconnection - The
+ Directory: Selected attribute types
+
+ [13] ITU-T Recommendation X.680 (07/02) | ISO/IEC 8824-1:2002,
+ Information technology - Abstract Syntax Notation One (ASN.1):
+ Specification of basic notation
+
+ [14] ITU-T Recommendation X.681 (07/02) | ISO/IEC 8824-2:2002,
+ Information technology - Abstract Syntax Notation One (ASN.1):
+ Information object specification
+
+
+
+
+Legg Standards Track [Page 39]
+
+RFC 3687 LDAP and X.500 Component Matching Rules February 2004
+
+
+ [15] ITU-T Recommendation X.682 (07/02) | ISO/IEC 8824-3:2002,
+ Information technology - Abstract Syntax Notation One (ASN.1):
+ Constraint specification
+
+ [16] ITU-T Recommendation X.683 (07/02) | ISO/IEC 8824-4:2002,
+ Information technology - Abstract Syntax Notation One (ASN.1):
+ Parameterization of ASN.1 specifications
+
+ [17] ITU-T Recommendation X.690 (07/02) | ISO/IEC 8825-1,
+ Information technology - ASN.1 encoding rules: Specification of
+ Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and
+ Distinguished Encoding Rules (DER)
+
+12.2. Informative References
+
+ [18] Howes, T., "The String Representation of LDAP Search Filters",
+ RFC 2254, December 1997.
+
+ [19] ITU-T Recommendation X.500 (1993) | ISO/IEC 9594-1:1994,
+ Information Technology - Open Systems Interconnection - The
+ Directory: Overview of concepts, models and services
+
+12. Intellectual Property Statement
+
+ The IETF takes no position regarding the validity or scope of any
+ intellectual property or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; neither does it represent that it
+ has made any effort to identify any such rights. Information on the
+ IETF's procedures with respect to rights in standards-track and
+ standards-related documentation can be found in BCP-11. Copies of
+ claims of rights made available for publication and any assurances of
+ licenses to be made available, or the result of an attempt made to
+ obtain a general license or permission for the use of such
+ proprietary rights by implementors or users of this specification can
+ be obtained from the IETF Secretariat.
+
+ 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.
+
+
+
+
+
+
+
+
+Legg Standards Track [Page 40]
+
+RFC 3687 LDAP and X.500 Component Matching Rules February 2004
+
+
+13. Author's Address
+
+ Steven Legg
+ Adacel Technologies Ltd.
+ 250 Bay Street
+ Brighton, Victoria 3186
+ AUSTRALIA
+
+ Phone: +61 3 8530 7710
+ Fax: +61 3 8530 7888
+ EMail: steven.legg at adacel.com.au
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Legg Standards Track [Page 41]
+
+RFC 3687 LDAP and X.500 Component Matching Rules February 2004
+
+
+14. Full Copyright Statement
+
+ Copyright (C) The Internet Society (2004). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assignees.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Legg Standards Track [Page 42]
+
Added: openldap/vendor/openldap-release/doc/rfc/rfc3698.txt
===================================================================
--- openldap/vendor/openldap-release/doc/rfc/rfc3698.txt (rev 0)
+++ openldap/vendor/openldap-release/doc/rfc/rfc3698.txt 2007-09-15 10:38:52 UTC (rev 844)
@@ -0,0 +1,507 @@
+
+
+
+
+
+
+Network Working Group K. Zeilenga, Ed.
+Request for Comments: 3698 OpenLDAP Foundation
+Updates: 2798 February 2004
+Category: Standards Track
+
+
+ Lightweight Directory Access Protocol (LDAP):
+ Additional Matching Rules
+
+Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2004). All Rights Reserved.
+
+Abstract
+
+ This document provides a collection of matching rules for use with
+ the Lightweight Directory Access Protocol (LDAP). As these matching
+ rules are simple adaptations of matching rules specified for use with
+ the X.500 Directory, most are already in wide use.
+
+Table of Contents
+
+ 1. Background and Intended Use. . . . . . . . . . . . . . . . . . 2
+ 2. Matching Rules . . . . . . . . . . . . . . . . . . . . . . . . 2
+ 2.1. booleanMatch . . . . . . . . . . . . . . . . . . . . . . 2
+ 2.2. caseExactMatch . . . . . . . . . . . . . . . . . . . . . 2
+ 2.3. caseExactOrderingMatch . . . . . . . . . . . . . . . . . 3
+ 2.4. caseExactSubstringsMatch . . . . . . . . . . . . . . . . 3
+ 2.5. caseIgnoreListSubstringsMatch. . . . . . . . . . . . . . 3
+ 2.6. directoryStringFirstComponentMatch . . . . . . . . . . . 4
+ 2.7. integerOrderingMatch . . . . . . . . . . . . . . . . . . 4
+ 2.8. keywordMatch . . . . . . . . . . . . . . . . . . . . . . 4
+ 2.9. numericStringOrderingMatch . . . . . . . . . . . . . . . 5
+ 2.10. octetStringOrderingMatch . . . . . . . . . . . . . . . . 5
+ 2.11. storedPrefixMatch. . . . . . . . . . . . . . . . . . . . 5
+ 2.12. wordMatch. . . . . . . . . . . . . . . . . . . . . . . . 6
+ 3. Security Considerations. . . . . . . . . . . . . . . . . . . . 6
+ 4. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 6
+ 5. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 7
+ 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
+
+
+
+Zeilenga Standards Track [Page 1]
+
+RFC 3698 LDAP: Additional Matching Rules February 2004
+
+
+ 6.1. Normative References . . . . . . . . . . . . . . . . . . 7
+ 6.2. Informative References . . . . . . . . . . . . . . . . . 7
+ 7. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 8
+ 8. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 9
+
+1. Background and Intended Use
+
+ This document adapts additional X.500 Directory [X.500] matching
+ rules [X.520] for use with the Lightweight Directory Access Protocol
+ (LDAP) [RFC3377]. Most of these rules are widely used today on the
+ Internet, such as in support of the inetOrgPerson [RFC2798] and
+ Policy Core Information Model [RFC3703] LDAP schemas. The rules are
+ applicable to many other applications.
+
+ This document supersedes the informational matching rules
+ descriptions provided in RFC 2798 that are now provided in this
+ document. Specifically, section 2 of this document replaces section
+ 9.3.3 of RFC 2798.
+
+ Schema definitions are provided using LDAP description formats
+ [RFC2252]. Definitions provided here are formatted (line wrapped)
+ for readability.
+
+2. Matching Rules
+
+2.1. booleanMatch
+
+ The booleanMatch rule compares for equality a asserted Boolean value
+ with an attribute value of BOOLEAN syntax. The rule returns TRUE if
+ and only if the values are the same, i.e., both are TRUE or both are
+ FALSE. (Source: X.520)
+
+ ( 2.5.13.13 NAME 'booleanMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 )
+
+ The BOOLEAN (1.3.6.1.4.1.1466.115.121.1.7) syntax is described in
+ [RFC2252].
+
+2.2. caseExactMatch
+
+ The caseExactMatch rule compares for equality the asserted value with
+ an attribute value of DirectoryString syntax. The rule is identical
+ to the caseIgnoreMatch [RFC2252] rule except that case is not
+ ignored. (Source: X.520)
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 2]
+
+RFC 3698 LDAP: Additional Matching Rules February 2004
+
+
+ ( 2.5.13.5 NAME 'caseExactMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+ The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax is
+ described in [RFC2252].
+
+2.3. caseExactOrderingMatch
+
+ The caseExactOrderingMatch rule compares the collation order of the
+ asserted string with an attribute value of DirectoryString syntax.
+ The rule is identical to the caseIgnoreOrderingMatch [RFC2252] rule
+ except that letters are not folded. (Source: X.520)
+
+ ( 2.5.13.6 NAME 'caseExactOrderingMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+ The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax is
+ described in [RFC2252].
+
+2.4. caseExactSubstringsMatch
+
+ The caseExactSubstringsMatch rule determines whether the asserted
+ value(s) are substrings of an attribute value of DirectoryString
+ syntax. The rule is identical to the caseIgnoreSubstringsMatch
+ [RFC2252] rule except that case is not ignored. (Source: X.520)
+
+ ( 2.5.13.7 NAME 'caseExactSubstringsMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
+
+ The SubstringsAssertion (1.3.6.1.4.1.1466.115.121.1.58) syntax is
+ described in [RFC2252].
+
+2.5. caseIgnoreListSubstringsMatch
+
+ The caseIgnoreListSubstringMatch rule compares the asserted substring
+ with an attribute value which is a sequence of DirectoryStrings, but
+ where the case (upper or lower) is not significant for comparison
+ purposes. The asserted value matches a stored value if and only if
+ the asserted value matches the string formed by concatenating the
+ strings of the stored value. This matching is done according to the
+ caseIgnoreSubstringsMatch [RFC2252] rule; however, none of the
+ initial, any, or final values of the asserted value are considered to
+ match a substring of the concatenated string which spans more than
+ one of the strings of the stored value. (Source: X.520)
+
+ ( 2.5.13.12 NAME 'caseIgnoreListSubstringsMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
+
+
+
+
+Zeilenga Standards Track [Page 3]
+
+RFC 3698 LDAP: Additional Matching Rules February 2004
+
+
+ The SubstringsAssertion (1.3.6.1.4.1.1466.115.121.1.58) syntax is
+ described in [RFC2252].
+
+2.6. directoryStringFirstComponentMatch
+
+ The directoryStringFirstComponentMatch rule compares for equality the
+ asserted DirectoryString value with an attribute value of type
+ SEQUENCE whose first component is mandatory and of type
+ DirectoryString. The rule returns TRUE if and only if the attribute
+ value has a first component whose value matches the asserted
+ DirectoryString using the rules of caseIgnoreMatch [RFC2252]. A
+ value of the assertion syntax is derived from a value of the
+ attribute syntax by using the value of the first component of the
+ SEQUENCE. (Source: X.520)
+
+ ( 2.5.13.31 NAME 'directoryStringFirstComponentMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+ The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax is
+ described in [RFC2252].
+
+2.7. integerOrderingMatch
+
+ The integerOrderingMatch rule compares the ordering of the asserted
+ integer with an attribute value of INTEGER syntax. The rule returns
+ True if the attribute value is less than the asserted value. (Source:
+ X.520)
+
+ ( 2.5.13.15 NAME 'integerOrderingMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )
+
+ The INTEGER (1.3.6.1.4.1.1466.115.121.1.27) syntax is described in
+ [RFC2252].
+
+2.8. keywordMatch
+
+ The keywordMatch rule compares the asserted string with keywords in
+ an attribute value of DirectoryString syntax. The rule returns TRUE
+ if and only if the asserted value matches any keyword in the
+ attribute value. The identification of keywords in an attribute
+ value and of the exactness of match are both implementation specific.
+ (Source: X.520)
+
+ ( 2.5.13.33 NAME 'keywordMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+ The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax is
+ described in [RFC2252].
+
+
+
+Zeilenga Standards Track [Page 4]
+
+RFC 3698 LDAP: Additional Matching Rules February 2004
+
+
+2.9. numericStringOrderingMatch
+
+ The numericStringOrderingMatch rule compares the collation order of
+ the asserted string with an attribute value of NumericString syntax.
+ The rule is identical to the caseIgnoreOrderingMatch [RFC2252] rule
+ except that all space characters are skipped during comparison (case
+ is irrelevant as characters are numeric). (Source: X.520)
+
+ ( 2.5.13.9 NAME 'numericStringOrderingMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 )
+
+ The NumericString (1.3.6.1.4.1.1466.115.121.1.36) syntax is described
+ in [RFC2252].
+
+2.10. octetStringOrderingMatch
+
+ The octetStringOrderingMatch rule compares the collation order of the
+ asserted octet string with an attribute value of OCTET STRING syntax.
+ The rule compares octet strings from first octet to last octet, and
+ from the most significant bit to the least significant bit within the
+ octet. The first occurrence of a different bit determines the
+ ordering of the strings. A zero bit precedes a one bit. If the
+ strings are identical but contain different numbers of octets, the
+ shorter string precedes the longer string. (Source: X.520)
+
+ ( 2.5.13.18 NAME 'octetStringOrderingMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )
+
+ The OCTET STRING (1.3.6.1.4.1.1466.115.121.1.40) syntax is described
+ in [RFC2252].
+
+2.11. storedPrefixMatch
+
+ The storedPrefixMatch rule determines whether an attribute value,
+ whose syntax is DirectoryString is a prefix (i.e., initial substring)
+ of the asserted value, without regard to the case (upper or lower) of
+ the strings. The rule returns TRUE if and only if the attribute
+ value is an initial substring of the asserted value with
+ corresponding characters identical except possibly with regard to
+ case. (Source: X.520)
+
+ ( 2.5.13.41 NAME 'storedPrefixMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 5]
+
+RFC 3698 LDAP: Additional Matching Rules February 2004
+
+
+ Note: This rule can be used, for example, to compare values in the
+ Directory which are telephone area codes with a purported value
+ which is a telephone number.
+
+ The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax is
+ described in [RFC2252].
+
+2.12. wordMatch
+
+ The wordMatch rule compares the asserted string with words in an
+ attribute value of DirectoryString syntax. The rule returns TRUE if
+ and only if the asserted word matches any word in the attribute
+ value. Individual word matching is as for the caseIgnoreMatch
+ [RFC2252] matching rule. The precise definition of a "word" is
+ implementation specific. (Source: X.520)
+
+ ( 2.5.13.32 NAME 'wordMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+ The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax is
+ described in [RFC2252].
+
+3. Security Considerations
+
+ General LDAP security considerations [RFC3377] is applicable to the
+ use of this schema. Additional considerations are noted above where
+ appropriate.
+
+4. IANA Considerations
+
+ The Internet Assigned Numbers Authority (IANA) has updated the LDAP
+ descriptors registry [RFC3383] as indicated in the following
+ template:
+
+ Subject: Request for LDAP Descriptor Registration Update
+ Descriptor (short name): see comment
+ Object Identifier: see comments
+ Person & email address to contact for further information:
+ Kurt Zeilenga <kurt at OpenLDAP.org>
+ Usage: see comments
+ Specification: RFC 3698
+ Author/Change Controller: IESG
+ Comments:
+
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 6]
+
+RFC 3698 LDAP: Additional Matching Rules February 2004
+
+
+ The following descriptors have been added:
+
+ NAME Type OID
+ ------------------------ ---- ---------
+ booleanMatch M 2.5.13.13
+ caseExactMatch M 2.5.13.5
+ caseExactOrderingMatch M 2.5.13.6
+ caseExactSubstringsMatch M 2.5.13.7
+ caseIgnoreListSubstringsMatch M 2.5.13.12
+ directoryStringFirstComponentMatch M 2.5.13.31
+ integerOrderingMatch M 2.5.13.15
+ keywordMatch M 2.5.13.33
+ numericStringOrderingMatch M 2.5.13.9
+ octetStringOrderingMatch M 2.5.13.18
+ storedPrefixMatch M 2.5.13.41
+ wordMatch M 2.5.13.32
+
+ where Type M is Matching Rule.
+
+ This document makes no new OID assignments. It only associates LDAP
+ matching rule descriptions with existing X.500 matching rules.
+
+5. Acknowledgments
+
+ This document borrows from [X.520], an ITU-T Recommendation.
+
+6. References
+
+6.1. Normative References
+
+ [RFC2252] Wahl, M., Coulbeck, A., Howes, T. and S. Kille,
+ "Lightweight Directory Access Protocol (v3): Attribute
+ Syntax Definitions", RFC 2252, December 1997.
+
+ [RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access
+ Protocol (v3): Technical Specification", RFC 3377,
+ September 2002.
+
+6.2. Informative References
+
+ [RFC2798] Smith, M., "The LDAP inetOrgPerson Object Class", RFC
+ 2798, April 2000.
+
+ [RFC3383] Zeilenga, K., "IANA Considerations for LDAP", BCP 64
+ RFC 3383, September 2002.
+
+ [RFC3703] Strassner, J., Moore, B., Moats, R. and E. Ellesson,
+ "Policy Core LDAP Schema", RFC 3703, February 2004.
+
+
+
+Zeilenga Standards Track [Page 7]
+
+RFC 3698 LDAP: Additional Matching Rules February 2004
+
+
+ [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.520] International Telecommunication Union -
+ Telecommunication Standardization Sector, "The
+ Directory: Selected Attribute Types", X.520(1997).
+
+7. Author's Address
+
+ Kurt D. Zeilenga
+ OpenLDAP Foundation
+
+ EMail: Kurt at OpenLDAP.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 8]
+
+RFC 3698 LDAP: Additional Matching Rules February 2004
+
+
+8. Full Copyright Statement
+
+ Copyright (C) The Internet Society (2004). This document is subject
+ to the rights, licenses and restrictions contained in BCP 78 and
+ except as set forth therein, the authors retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
+ REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
+ INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
+ IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
+ THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed
+ to pertain to the implementation or use of the technology
+ described in this document or the extent to which any license
+ under such rights might or might not be available; nor does it
+ represent that it has made any independent effort to identify any
+ such rights. Information on the procedures with respect to
+ rights in RFC documents can be found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use
+ of such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository
+ at http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention
+ any copyrights, patents or patent applications, or other
+ proprietary rights that may cover technology that may be required
+ to implement this standard. Please address the information to the
+ IETF at ietf-ipr at ietf.org.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 9]
+
Added: openldap/vendor/openldap-release/doc/rfc/rfc3703.txt
===================================================================
--- openldap/vendor/openldap-release/doc/rfc/rfc3703.txt (rev 0)
+++ openldap/vendor/openldap-release/doc/rfc/rfc3703.txt 2007-09-15 10:38:52 UTC (rev 844)
@@ -0,0 +1,3419 @@
+
+
+
+
+
+
+Network Working Group J. Strassner
+Request for Comments: 3703 Intelliden Corporation
+Category: Standards Track B. Moore
+ IBM Corporation
+ R. Moats
+ Lemur Networks, Inc.
+ E. Ellesson
+ February 2004
+
+
+ Policy Core Lightweight Directory Access Protocol (LDAP) Schema
+
+Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2004). All Rights Reserved.
+
+Abstract
+
+ This document defines a mapping of the Policy Core Information Model
+ to a form that can be implemented in a directory that uses
+ Lightweight Directory Access Protocol (LDAP) as its access protocol.
+ This model defines two hierarchies of object classes: structural
+ classes representing information for representing and controlling
+ policy data as specified in RFC 3060, and relationship classes that
+ indicate how instances of the structural classes are related to each
+ other. Classes are also added to the LDAP schema to improve the
+ performance of a client's interactions with an LDAP server when the
+ client is retrieving large amounts of policy-related information.
+ These classes exist only to optimize LDAP retrievals: there are no
+ classes in the information model that correspond to them.
+
+Table of Contents
+
+ 1. Introduction ................................................. 2
+ 2. The Policy Core Information Model ............................ 4
+ 3. Inheritance Hierarchy for the PCLS ........................... 5
+ 4. General Discussion of Mapping the Information Model to LDAP .. 6
+ 4.1. Summary of Class and Association Mappings .............. 7
+ 4.2. Usage of DIT Content and Structure Rules and Name Forms. 9
+ 4.3. Naming Attributes in the PCLS .......................... 10
+
+
+
+Strassner, et al. Standards Track [Page 1]
+
+RFC 3703 Policy Core LDAP Schema February 2004
+
+
+ 4.4. Rule-Specific and Reusable Conditions and Actions ...... 11
+ 4.5. Location and Retrieval of Policy Objects in the
+ Directory .............................................. 16
+ 4.5.1. Aliases and Other DIT-Optimization Techniques .. 19
+ 5. Class Definitions ............................................ 19
+ 5.1. The Abstract Class "pcimPolicy" ........................ 21
+ 5.2. The Three Policy Group Classes ......................... 22
+ 5.3. The Three Policy Rule Classes .......................... 23
+ 5.4. The Class pcimRuleConditionAssociation ................. 30
+ 5.5. The Class pcimRuleValidityAssociation .................. 32
+ 5.6. The Class pcimRuleActionAssociation .................... 34
+ 5.7. The Auxiliary Class pcimConditionAuxClass .............. 36
+ 5.8. The Auxiliary Class pcimTPCAuxClass .................... 36
+ 5.9. The Auxiliary Class pcimConditionVendorAuxClass ........ 40
+ 5.10. The Auxiliary Class pcimActionAuxClass ................. 41
+ 5.11. The Auxiliary Class pcimActionVendorAuxClass ........... 42
+ 5.12. The Class pcimPolicyInstance ........................... 43
+ 5.13. The Auxiliary Class pcimElementAuxClass ................ 44
+ 5.14. The Three Policy Repository Classes .................... 45
+ 5.15. The Auxiliary Class pcimSubtreesPtrAuxClass ............ 46
+ 5.16. The Auxiliary Class pcimGroupContainmentAuxClass ....... 48
+ 5.17. The Auxiliary Class pcimRuleContainmentAuxClass ........ 49
+ 6. Extending the Classes Defined in This Document ............... 50
+ 6.1. Subclassing pcimConditionAuxClass and pcimActionAuxClass 50
+ 6.2. Using the Vendor Policy Attributes ..................... 50
+ 6.3. Using Time Validity Periods ............................ 51
+ 7. Security Considerations ...................................... 51
+ 8. IANA Considerations .......................................... 53
+ 8.1. Object Identifiers ..................................... 53
+ 8.2. Object Identifier Descriptors .......................... 53
+ 9. Acknowledgments .............................................. 56
+ 10. Appendix: Constructing the Value of orderedCIMKeys .......... 57
+ 11. References ................................................... 58
+ 11.1. Normative References ................................... 58
+ 11.2. Informative References ................................. 59
+ 12. Authors' Addresses ........................................... 60
+ 13. Full Copyright Statement ..................................... 61
+
+1. Introduction
+
+ This document takes as its starting point the object-oriented
+ information model for representing information for representing and
+ controlling policy data as specified in [1]. Lightweight Directory
+ Access Protocol (LDAP) [2] implementers, please note that the use of
+ the term "policy" in this document does not refer to the use of the
+ term "policy" as defined in X.501 [4]. Rather, the use of the term
+ "policy" throughout this document is defined as follows:
+
+
+
+
+Strassner, et al. Standards Track [Page 2]
+
+RFC 3703 Policy Core LDAP Schema February 2004
+
+
+ Policy is defined as a set of rules to administer, manage, and
+ control access to network resources.
+
+ This work is currently under joint development in the IETF's Policy
+ Framework working group and in the Policy working group of the
+ Distributed Management Task Force (DMTF). This model defines two
+ hierarchies of object classes: structural classes representing policy
+ information and control of policies, and relationship classes that
+ indicate how instances of the structural classes are related to each
+ other. In general, both of these class hierarchies will need to be
+ mapped to a particular data store.
+
+ This document defines the mapping of these information model classes
+ to a directory that uses LDAP as its access protocol. Two types of
+ mappings are involved:
+
+ - For the structural classes in the information model, the
+ mapping is basically one-for-one: information model classes map
+ to LDAP classes, information model properties map to LDAP
+ attributes.
+
+ - For the relationship classes in the information model,
+ different mappings are possible. In this document, the Policy
+ Core Information Model's (PCIM's) relationship classes and
+ their properties are mapped in three ways: to LDAP auxiliary
+ classes, to attributes representing distinguished name (DN)
+ references, and to superior-subordinate relationships in the
+ Directory Information Tree (DIT).
+
+ Implementations that use an LDAP directory as their policy repository
+ and want to implement policy information according to RFC 3060 [1]
+ SHALL use the LDAP schema defined in this document, or a schema that
+ subclasses from the schema defined in this document. The use of the
+ information model defined in reference [1] as the starting point
+ enables the inheritance and the relationship class hierarchies to be
+ extensible, such that other types of policy repositories, such as
+ relational databases, can also use this information.
+
+ This document fits into the overall framework for representing,
+ deploying, and managing policies being developed by the Policy
+ Framework Working Group.
+
+ The LDAP schema described in this document uses the prefix "pcim" to
+ identify its classes and attributes. It consists of ten very general
+ classes: pcimPolicy (an abstract class), three policy group classes
+ (pcimGroup, pcimGroupAuxClass, and pcimGroupInstance), three policy
+ rule classes (pcimRule, pcimRuleAuxClass, and pcimRuleInstance), and
+ three special auxiliary classes (pcimConditionAuxClass,
+
+
+
+Strassner, et al. Standards Track [Page 3]
+
+RFC 3703 Policy Core LDAP Schema February 2004
+
+
+ pcimTPCAuxClass, and pcimActionAuxClass). (Note that the
+ PolicyTimePeriodCondition auxiliary class defined in [1] would
+ normally have been named pcimTimePeriodConditionAuxClass, but this
+ name is too long for some directories. Therefore, we have
+ abbreviated this name to be pcimTPCAuxClass).
+
+ The mapping for the PCIM classes pcimGroup and pcimRule is designed
+ to be as flexible as possible. Three classes are defined for these
+ two PCIM classes. First, an abstract superclass is defined that
+ contains all required properties of each PCIM class. Then, both an
+ auxiliary class as well as a structural class are derived from the
+ abstract superclass. This provides maximum flexibility for the
+ developer.
+
+ The schema also contains two less general classes:
+ pcimConditionVendorAuxClass and pcimActionVendorAuxClass. To achieve
+ the mapping of the information model's relationships, the schema also
+ contains two auxiliary classes: pcimGroupContainmentAuxClass and
+ pcimRuleContainmentAuxClass. Capturing the distinction between
+ rule-specific and reusable policy conditions and policy actions
+ introduces seven other classes: pcimRuleConditionAssociation,
+ pcimRuleValidityAssociation, pcimRuleActionAssociation,
+ pcimPolicyInstance, and three policy repository classes
+ (pcimRepository, pcimRepositoryAuxClass, and pcimRepositoryInstance).
+ Finally, the schema includes two classes (pcimSubtreesPtrAuxClass and
+ pcimElementAuxClass) for optimizing LDAP retrievals. In all, the
+ schema contains 23 classes.
+
+ Within the context of this document, the term "PCLS" (Policy Core
+ LDAP Schema) is used to refer to the LDAP class definitions that this
+ document contains. The term "PCIM" refers to classes defined in [1].
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in RFC 2119 [10].
+
+2. The Policy Core Information Model
+
+ This document contains an LDAP schema representing the classes
+ defined in the companion document "Policy Core Information
+ Model -- Version 1 Specification" [1]. Other documents may
+ subsequently be produced, with mappings of this same PCIM to other
+ storage technologies. Since the detailed semantics of the PCIM
+ classes appear only in [1], that document is a prerequisite for
+ reading and understanding this document.
+
+
+
+
+
+
+Strassner, et al. Standards Track [Page 4]
+
+RFC 3703 Policy Core LDAP Schema February 2004
+
+
+3. Inheritance Hierarchy for the PCLS
+
+ The following diagram illustrates the class hierarchy for the LDAP
+ Classes defined in this document:
+
+ top
+ |
+ +--dlm1ManagedElement (abstract)
+ | |
+ | +--pcimPolicy (abstract)
+ | | |
+ | | +--pcimGroup (abstract)
+ | | | |
+ | | | +--pcimGroupAuxClass (auxiliary)
+ | | | |
+ | | | +--pcimGroupInstance (structural)
+ | | |
+ | | +--pcimRule (abstract)
+ | | | |
+ | | | +--pcimRuleAuxClass (auxiliary)
+ | | | |
+ | | | +--pcimRuleInstance (structural)
+ | | |
+ | | +--pcimRuleConditionAssociation (structural)
+ | | |
+ | | +--pcimRuleValidityAssociation (structural)
+ | | |
+ | | +--pcimRuleActionAssociation (structural)
+ | | |
+ | | +--pcimPolicyInstance (structural)
+ | | |
+ | | +--pcimElementAuxClass (auxiliary)
+ | |
+ | +--dlm1ManagedSystemElement (abstract)
+ | |
+ | +--dlm1LogicalElement (abstract)
+ | |
+ | +--dlm1System (abstract)
+ | |
+ | +--dlm1AdminDomain (abstract)
+ | |
+ | +--pcimRepository (abstract)
+ | |
+ | +--pcimRepositoryAuxClass (auxiliary)
+
+
+
+
+
+
+
+Strassner, et al. Standards Track [Page 5]
+
+RFC 3703 Policy Core LDAP Schema February 2004
+
+
+ top
+ | |
+ | +--pcimRepositoryInstance
+ | (structural)
+ |
+ +--pcimConditionAuxClass (auxiliary)
+ | |
+ | +---pcimTPCAuxClass (auxiliary)
+ | |
+ | +---pcimConditionVendorAuxClass (auxiliary)
+ |
+ +--pcimActionAuxClass (auxiliary)
+ | |
+ | +---pcimActionVendorAuxClass (auxiliary)
+ |
+ +--pcimSubtreesPtrAuxClass (auxiliary)
+ |
+ +--pcimGroupContainmentAuxClass (auxiliary)
+ |
+ +--pcimRuleContainmentAuxClass (auxiliary)
+
+ Figure 1. LDAP Class Inheritance Hierarchy for the PCLS
+
+4. General Discussion of Mapping the Information Model to LDAP
+
+ The classes described in Section 5 below contain certain
+ optimizations for a directory that uses LDAP as its access protocol.
+ One example of this is the use of auxiliary classes to represent some
+ of the associations defined in the information model. Other data
+ stores might need to implement these associations differently. A
+ second example is the introduction of classes specifically designed
+ to optimize retrieval of large amounts of policy-related data from a
+ directory. This section discusses some general topics related to the
+ mapping from the information model to LDAP.
+
+ The remainder of this section will discuss the following topics.
+ Section 4.1 will discuss the strategy used in mapping the classes and
+ associations defined in [1] to a form that can be represented in a
+ directory that uses LDAP as its access protocol. Section 4.2
+ discusses DIT content and structure rules, as well as name forms.
+ Section 4.3 describes the strategy used in defining naming attributes
+ for the schema described in Section 5 of this document. Section 4.4
+ defines the strategy recommended for locating and retrieving
+ PCIM-derived objects in the directory.
+
+
+
+
+
+
+
+Strassner, et al. Standards Track [Page 6]
+
+RFC 3703 Policy Core LDAP Schema February 2004
+
+
+4.1. Summary of Class and Association Mappings
+
+ Fifteen of the classes in the PCLS come directly from the nine
+ corresponding classes in the information model. Note that names of
+ classes begin with an upper case character in the information model
+ (although for CIM in particular, case is not significant in class and
+ property names), but with a lower case character in LDAP. This is
+ because although LDAP doesn't care, X.500 doesn't allow class names
+ to begin with an uppercase character. Note also that the prefix
+ "pcim" is used to identify these LDAP classes.
+
+ +---------------------------+-------------------------------+
+ | Information Model | LDAP Class(es) |
+ +---------------------------+-------------------------------+
+ +---------------------------+-------------------------------+
+ | Policy | pcimPolicy |
+ +---------------------------+-------------------------------+
+ | PolicyGroup | pcimGroup |
+ | | pcimGroupAuxClass |
+ | | pcimGroupInstance |
+ +---------------------------+-------------------------------+
+ | PolicyRule | pcimRule |
+ | | pcimRuleAuxClass |
+ | | pcimRuleInstance |
+ +---------------------------+-------------------------------+
+ | PolicyCondition | pcimConditionAuxClass |
+ +---------------------------+-------------------------------+
+ | PolicyAction | pcimActionAuxClass |
+ +---------------------------+-------------------------------+
+ | VendorPolicyCondition | pcimConditionVendorAuxClass |
+ +---------------------------+-------------------------------+
+ | VendorPolicyAction | pcimActionVendorAuxClass |
+ +---------------------------+-------------------------------+
+ | PolicyTimePeriodCondition | pcimTPCAuxClass |
+ +---------------------------+-------------------------------+
+ | PolicyRepository | pcimRepository |
+ | | pcimRepositoryAuxClass |
+ | | pcimRepositoryInstance |
+ +---------------------------+-------------------------------+
+
+ Figure 2. Mapping of Information Model Classes to LDAP
+
+ The associations in the information model map to attributes that
+ reference DNs (Distinguished Names) or to Directory Information Tree
+ (DIT) containment (i.e., superior-subordinate relationships) in LDAP.
+ Two of the attributes that reference DNs appear in auxiliary classes,
+ which allow each of them to represent several relationships from the
+ information model.
+
+
+
+Strassner, et al. Standards Track [Page 7]
+
+RFC 3703 Policy Core LDAP Schema February 2004
+
+
++----------------------------------+----------------------------------+
+| Information Model Association | LDAP Attribute / Class |
++-----------------------------------+---------------------------------+
++-----------------------------------+---------------------------------+
+| PolicyGroupInPolicyGroup | pcimGroupsAuxContainedSet in |
+| | pcimGroupContainmentAuxClass |
++-----------------------------------+---------------------------------+
+| PolicyRuleInPolicyGroup | pcimRulesAuxContainedSet in |
+| | pcimRuleContainmentAuxClass |
++-----------------------------------+---------------------------------+
+| PolicyConditionInPolicyRule | DIT containment or |
+| | pcimRuleConditionList in |
+| | pcimRule or |
+| | pcimConditionDN in |
+| | pcimRuleConditionAssociation |
++-----------------------------------+---------------------------------+
+| PolicyActionInPolicyRule | DIT containment or |
+| | pcimRuleActionList in |
+| | pcimRule or |
+| | pcimActionDN in |
+| | pcimRuleActionAssociation |
++-----------------------------------+---------------------------------+
+| PolicyRuleValidityPeriod | pcimRuleValidityPeriodList |
+| | in pcimRule or (if reusable) |
+| | referenced through the |
+| | pcimTimePeriodConditionDN in |
+| | pcimRuleValidityAssociation |
++-----------------------------------+---------------------------------+
+| PolicyConditionInPolicyRepository | DIT containment |
++-----------------------------------+---------------------------------+
+| PolicyActionInPolicyRepository | DIT containment |
++-----------------------------------+---------------------------------+
+| PolicyRepositoryInPolicyRepository| DIT containment |
++-----------------------------------+---------------------------------+
+
+ Figure 3. Mapping of Information Model Associations to LDAP
+
+ Of the remaining classes in the PCLS, two (pcimElementAuxClass and
+ pcimSubtreesPtrAuxClass) are included to make navigation through the
+ DIT and retrieval of the entries found there more efficient. This
+ topic is discussed below in Section 4.5.
+
+ The remaining four classes in the PCLS, pcimRuleConditionAssociation,
+ pcimRuleValidityAssociation, pcimRuleActionAssociation, and
+ pcimPolicyInstance, are all involved with the representation of
+ policy conditions and policy actions in an LDAP directory. This
+ topic is discussed below in Section 4.4.
+
+
+
+
+Strassner, et al. Standards Track [Page 8]
+
+RFC 3703 Policy Core LDAP Schema February 2004
+
+
+4.2. Usage of DIT Content and Structure Rules and Name Forms
+
+ There are three powerful tools that can be used to help define
+ schemata. The first, DIT content rules, is a way of defining the
+ content of an entry for a structural object class. It can be used to
+ specify the following characteristics of the entry:
+
+ - additional mandatory attributes that the entries are required
+ to contain
+ - additional optional attributes the entries are allowed to
+ contain
+ - the set of additional auxiliary object classes that these
+ entries are allowed to be members of
+ - any optional attributes from the structural and auxiliary
+ object class definitions that the entries are required to
+ preclude
+
+ DIT content rules are NOT mandatory for any structural object class.
+
+ A DIT structure rule, together with a name form, controls the
+ placement and naming of an entry within the scope of a subschema.
+ Name forms define which attribute type(s) are required and are
+ allowed to be used in forming the Relative Distinguished Names (RDNs)
+ of entries. DIT structure rules specify which entries are allowed to
+ be superior to other entries, and hence control the way that RDNs are
+ added together to make DNs.
+
+ A name form specifies the following:
+
+ - the structural object class of the entries named by this name
+ form
+ - attributes that are required to be used in forming the RDNs of
+ these entries
+ - attributes that are allowed to be used in forming the RDNs of
+ these entries
+ - an object identifier to uniquely identify this name form
+
+ Note that name forms can only be specified for structural object
+ classes. However, every entry in the DIT must have a name form
+ controlling it.
+
+ Unfortunately, current LDAP servers vary quite a lot in their support
+ of these features. There are also three crucial implementation
+ points that must be followed. First, X.500 use of structure rules
+ requires that a structural object class with no superior structure
+ rule be a subschema administrative point. This is exactly NOT what
+ we want for policy information. Second, when an auxiliary class is
+ subclassed, if a content rule exists for the structural class that
+
+
+
+Strassner, et al. Standards Track [Page 9]
+
+RFC 3703 Policy Core LDAP Schema February 2004
+
+
+ the auxiliary class refers to, then that content rule needs to be
+ augmented. Finally, most LDAP servers unfortunately do not support
+ inheritance of structure and content rules.
+
+ Given these concerns, DIT structure and content rules have been
+ removed from the PCLS. This is because, if included, they would be
+ normative references and would require OIDs. However, we don't want
+ to lose the insight gained in building the structure and content
+ rules of the previous version of the schema. Therefore, we describe
+ where such rules could be used in this schema, what they would
+ control, and what their effect would be.
+
+4.3. Naming Attributes in the PCLS
+
+ Instances in a directory are identified by distinguished names (DNs),
+ which provide the same type of hierarchical organization that a file
+ system provides in a computer system. A distinguished name is a
+ sequence of RDNs. An RDN provides a unique identifier for an
+ instance within the context of its immediate superior, in the same
+ way that a filename provides a unique identifier for a file within
+ the context of the folder in which it resides.
+
+ To preserve maximum naming flexibility for policy administrators,
+ three optional (i.e., "MAY") naming attributes have been defined.
+ They are:
+
+ - Each of the structural classes defined in this schema has its
+ own unique ("MAY") naming attribute. Since the naming
+ attributes are different, a policy administrator can, by using
+ these attributes, guarantee that there will be no name
+ collisions between instances of different classes, even if the
+ same value is assigned to the instances' respective naming
+ attributes.
+
+ - The LDAP attribute cn (corresponding to X.500's commonName) is
+ included as a MAY attribute in the abstract class pcimPolicy,
+ and thus by inheritance in all of its subclasses. In X.500,
+ commonName typically functions as an RDN attribute, for naming
+ instances of many classes (e.g., X.500's person class).
+
+ - A special attribute is provided for implementations that expect
+ to map between native CIM and LDAP representations of policy
+ information. This attribute, called orderedCimKeys, is defined
+ in the class dlm1ManagedElement [6]. The value of this
+ attribute is derived algorithmically from values that are
+ already present in a CIM policy instance. The normative
+ reference for this algorithm is contained in [6]. See the
+ appendix of this document for a description of the algorithm.
+
+
+
+Strassner, et al. Standards Track [Page 10]
+
+RFC 3703 Policy Core LDAP Schema February 2004
+
+
+ Since any of these naming attributes MAY be used for naming an
+ instance of a PCLS class, implementations MUST be able to accommodate
+ instances named in any of these ways.
+
+ Note that it is recommended that two or more of these attributes
+ SHOULD NOT be used together to form a multi-part RDN, since support
+ for multi-part RDNs is limited among existing directory
+ implementations.
+
+4.4. Rule-Specific and Reusable Conditions and Actions
+
+ The PCIM [1] distinguishes between two types of policy conditions and
+ policy actions: those associated with a single policy rule, and
+ those that are reusable, in the sense that they may be associated
+ with more than one policy rule. While there is no inherent
+ functional difference between a rule-specific condition or action and
+ a reusable one, there is both a usage, as well as, an implementation
+ difference between them.
+
+ Defining a condition or action as reusable vs. rule-specific reflects
+ a conscious decision on the part of the administrator in defining how
+ they are used. In addition, there are variations that reflect
+ implementing rule-specific vs. reusable policy conditions and actions
+ and how they are treated in a policy repository. The major
+ implementation differences between a rule-specific and a reusable
+ condition or action are delineated below:
+
+ 1. It is natural for a rule-specific condition or action to be
+ removed from the policy repository at the same time the rule is.
+ It is just the opposite for reusable conditions and actions.
+ This is because the condition or action is conceptually attached
+ to the rule in the rule-specific case, whereas it is referenced
+ (e.g., pointed at) in the reusable case. The persistence of a
+ pcimRepository instance is independent of the persistence of a
+ pcimRule instance.
+ 2. Access permissions for a rule-specific condition or action are
+ usually identical to those for the rule itself. On the other
+ hand, access permissions of reusable conditions and actions must
+ be expressible without reference to a policy rule.
+ 3. Rule-specific conditions and actions require fewer accesses,
+ because the conditions and actions are "attached" to the rule.
+ In contrast, reusable conditions and actions require more
+ accesses, because each condition or action that is reusable
+ requires a separate access.
+ 4. Rule-specific conditions and actions are designed for use by a
+ single rule. As the number of rules that use the same
+ rule-specific condition increase, subtle problems are created
+ (the most obvious being how to keep the rule-specific conditions
+
+
+
+Strassner, et al. Standards Track [Page 11]
+
+RFC 3703 Policy Core LDAP Schema February 2004
+
+
+ and actions updated to reflect the same value). Reusable
+ conditions and actions lend themselves for use by multiple
+ independent rules.
+ 5. Reusable conditions and actions offer an optimization when
+ multiple rules are using the same condition or action. This is
+ because the reusable condition or action only needs be updated
+ once, and by virtue of DN reference, the policy rules will be
+ automatically updated.
+
+ The preceding paragraph does not contain an exhaustive list of the
+ ways in which reusable and rule-specific conditions should be treated
+ differently. Its purpose is merely to justify making a semantic
+ distinction between rule-specific and reusable, and then reflecting
+ this distinction in the policy repository itself.
+
+ When the policy repository is realized in an LDAP-accessible
+ directory, the distinction between rule-specific and reusable
+ conditions and actions is realized via placement of auxiliary classes
+ and via DIT containment. Figure 4 illustrates a policy rule Rule1
+ with one rule-specific condition CA and one rule-specific action AB.
+
+ +-----+
+ |Rule1|
+ | |
+ +-----|- -|-----+
+ | +-----+ |
+ | * * |
+ | * * |
+ | **** **** |
+ | * * |
+ v * * v
+ +--------+ +--------+
+ | CA+ca | | AB+ab |
+ +--------+ +--------+
+
+
+ +------------------------------+
+ |LEGEND: |
+ | ***** DIT containment |
+ | + auxiliary attachment |
+ | ----> DN reference |
+ +------------------------------+
+
+ Figure 4 Rule-Specific Policy Conditions and Actions
+
+
+
+
+
+
+
+Strassner, et al. Standards Track [Page 12]
+
+RFC 3703 Policy Core LDAP Schema February 2004
+
+
+ Because the condition and action are specific to Rule1, the auxiliary
+ classes ca and ab that represent them are attached, respectively, to
+ the structural classes CA and AB. These structural classes represent
+ not the condition ca and action ab themselves, but rather the
+ associations between Rule1 and ca, and between Rule1 and ab.
+
+ As Figure 4 illustrates, Rule1 contains DN references to the
+ structural classes CA and AB that appear below it in the DIT. At
+ first glance it might appear that these DN references are
+ unnecessary, since a subtree search below Rule1 would find all of the
+ structural classes representing the associations between Rule1 and
+ its conditions and actions. Relying only on a subtree search,
+ though, runs the risk of missing conditions or actions that should
+ have appeared in the subtree, but for some reason did not, or of
+ finding conditions or actions that were inadvertently placed in the
+ subtree, or that should have been removed from the subtree, but for
+ some reason were not. Implementation experience has suggested that
+ many (but not all) of these risks are eliminated.
+
+ However, it must be noted that this comes at a price. The use of DN
+ references, as shown in Figure 4 above, thwarts inheritance of access
+ control information as well as existence dependency information. It
+ also is subject to referential integrity considerations. Therefore,
+ it is being included as an option for the designer.
+
+ Figure 5 illustrates a second way of representing rule-specific
+ conditions and actions in an LDAP-accessible directory: attachment of
+ the auxiliary classes directly to the instance representing the
+ policy rule. When all of the conditions and actions are attached to
+ a policy rule in this way, the rule is termed a "simple" policy rule.
+ When conditions and actions are not attached directly to a policy
+ rule, the rule is termed a "complex" policy rule.
+
+ +-----------+
+ |Rule1+ca+ab|
+ | |
+ +-----------+
+
+ +------------------------------+
+ |LEGEND: |
+ | + auxiliary attachment |
+ +------------------------------+
+
+ Figure 5. A Simple Policy Rule
+
+
+
+
+
+
+
+Strassner, et al. Standards Track [Page 13]
+
+RFC 3703 Policy Core LDAP Schema February 2004
+
+
+ The simple/complex distinction for a policy rule is not all or
+ nothing. A policy rule may have its conditions attached to itself
+ and its actions attached to other entries, or it may have its actions
+ attached to itself and its conditions attached to other entries.
+ However, it SHALL NOT have either its conditions or its actions
+ attached both to itself and to other entries, with one exception: a
+ policy rule may reference its validity periods with the
+ pcimRuleValidityPeriodList attribute, but have its other conditions
+ attached to itself.
+
+ The tradeoffs between simple and complex policy rules are between the
+ efficiency of simple rules and the flexibility and greater potential
+ for reuse of complex rules. With a simple policy rule, the semantic
+ options are limited:
+
+ - All conditions are ANDed together. This combination can be
+ represented in two ways in the Disjunctive Normal Form (DNF)/
+ Conjunctive Normal Form (CNF) (please see [1] for definitions of
+ these terms) expressions characteristic of policy conditions: as
+ a DNF expression with a single AND group, or as a CNF expression
+ with multiple single-condition OR groups. The first of these is
+ arbitrarily chosen as the representation for the ANDed conditions
+ in a simple policy rule.
+
+ - If multiple actions are included, no order can be specified for
+ them.
+
+ If a policy administrator needs to combine conditions in some other
+ way, or if there is a set of actions that must be ordered, then the
+ only option is to use a complex policy rule.
+
+ Finally, Figure 6 illustrates the same policy rule Rule1, but this
+ time its condition and action are reusable. The association classes
+ CA and AB are still present, and they are still DIT contained under
+ Rule1. But rather than having the auxiliary classes ca and ab
+ attached directly to the association classes CA and AB, each now
+ contains DN references to other entries to which these auxiliary
+ classes are attached. These other entries, CIA and AIB, are DIT
+ contained under RepositoryX, which is an instance of the class
+ pcimRepository. Because they are named under an instance of
+ pcimRepository, ca and ab are clearly identified as reusable.
+
+
+
+
+
+
+
+
+
+
+Strassner, et al. Standards Track [Page 14]
+
+RFC 3703 Policy Core LDAP Schema February 2004
+
+
+ +-----+ +-------------+
+ |Rule1| | RepositoryX |
+ +-|- -|--+ | |
+ | +-----+ | +-------------+
+ | * * | * *
+ | * * | * *
+ | *** **** | * *
+ | * * v * *
+ | * +---+ * *
+ | * |AB | +------+ *
+ v * | -|-------->|AIB+ab| *
+ +---+ +---+ +------+ *
+ |CA | +------+
+ | -|------------------------>|CIA+ca|
+ +---+ +------+
+
+ +------------------------------+
+ |LEGEND: |
+ | ***** DIT containment |
+ | + auxiliary attachment |
+ | ----> DN reference |
+ +------------------------------+
+
+ Figure 6. Reusable Policy Conditions and Actions
+
+ The classes pcimConditionAuxClass and pcimActionAuxClass do not
+ themselves represent actual conditions and actions: these are
+ introduced in their subclasses. What pcimConditionAuxClass and
+ pcimActionAuxClass do introduce are the semantics of being a policy
+ condition or a policy action. These are the semantics that all the
+ subclasses of pcimConditionAuxClass and pcimActionAuxClass inherit.
+ Among these semantics are those of representing either a
+ rule-specific or a reusable policy condition or policy action.
+
+ In order to preserve the ability to represent a rule-specific or a
+ reusable condition or action, as well as a simple policy rule, all
+ the subclasses of pcimConditionAuxClass and pcimActionAuxClass MUST
+ also be auxiliary classes.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Strassner, et al. Standards Track [Page 15]
+
+RFC 3703 Policy Core LDAP Schema February 2004
+
+
+4.5. Location and Retrieval of Policy Objects in the Directory
+
+ When a Policy Decision Point (PDP) goes to an LDAP directory to
+ retrieve the policy object instances relevant to the Policy
+ Enforcement Points (PEPs) it serves, it is faced with two related
+ problems:
+
+ - How does it locate and retrieve the directory entries that apply
+ to its PEPs? These entries may include instances of the PCLS
+ classes, instances of domain-specific subclasses of these
+ classes, and instances of other classes modeling such resources
+ as user groups, interfaces, and address ranges.
+
+ - How does it retrieve the directory entries it needs in an
+ efficient manner, so that retrieval of policy information from
+ the directory does not become a roadblock to scalability? There
+ are two facets to this efficiency: retrieving only the relevant
+ directory entries, and retrieving these entries using as few LDAP
+ calls as possible.
+
+ The placement of objects in the Directory Information Tree (DIT)
+ involves considerations other than how the policy-related objects
+ will be retrieved by a PDP. Consequently, all that the PCLS can do
+ is to provide a "toolkit" of classes to assist the policy
+ administrator as the DIT is being designed and built. A PDP SHOULD
+ be able to take advantage of any tools that the policy administrator
+ is able to build into the DIT, but it MUST be able to use a less
+ efficient means of retrieval if that is all it has available to it.
+
+ The basic idea behind the LDAP optimization classes is a simple one:
+ make it possible for a PDP to retrieve all the policy-related objects
+ it needs, and only those objects, using as few LDAP calls as
+ possible. An important assumption underlying this approach is that
+ the policy administrator has sufficient control over the underlying
+ DIT structure to define subtrees for storing policy information. If
+ the policy administrator does not have this level of control over DIT
+ structure, a PDP can still retrieve the policy-related objects it
+ needs individually. But it will require more LDAP access operations
+ to do the retrieval in this way. Figure 7 illustrates how LDAP
+ optimization is accomplished.
+
+
+
+
+
+
+
+
+
+
+
+Strassner, et al. Standards Track [Page 16]
+
+RFC 3703 Policy Core LDAP Schema February 2004
+
+
+ +-----+
+ ---------------->| A |
+ DN reference to | | DN references to subtrees +---+
+ starting object +-----+ +-------------------------->| C |
+ | o--+----+ +---+ +---+
+ | o--+------------->| B | / \
+ +-----+ +---+ / \
+ / \ / \ / ... \
+ / \ / \
+ / \ / ... \
+
+ Figure 7. Using the pcimSubtreesPtrAuxClass to Locate Policies
+
+ The PDP is configured initially with a DN reference to some entry in
+ the DIT. The structural class of this entry is not important; the
+ PDP is interested only in the pcimSubtreesPtrAuxClass attached to it.
+ This auxiliary class contains a multi-valued attribute with DN
+ references to objects that anchor subtrees containing policy-related
+ objects of interest to the PDP. Since pcimSubtreesPtrAuxClass is an
+ auxiliary class, it can be attached to an entry that the PDP would
+ need to access anyway - perhaps an entry containing initial
+ configuration settings for the PDP, or for a PEP that uses the PDP.
+
+ Once it has retrieved the DN references, the PDP will direct to each
+ of the objects identified by them an LDAP request that all entries in
+ its subtree be evaluated against the selection criteria specified in
+ the request. The LDAP-enabled directory then returns all entries in
+ that subtree that satisfy the specified criteria.
+
+ The selection criteria always specify that object class="pcimPolicy".
+ Since all classes representing policy rules, policy conditions, and
+ policy actions, both in the PCLS and in any domain-specific schema
+ derived from it, are subclasses of the abstract class policy, this
+ criterion evaluates to TRUE for all instances of these classes. To
+ accommodate special cases where a PDP needs to retrieve objects that
+ are not inherently policy-related (for example, an IP address range
+ object referenced by a subclass of pcimActionAuxClass representing
+ the DHCP action "assign from this address range"), the auxiliary
+ class pcimElementAuxClass can be used to "tag" an entry, so that it
+ will be found by the selection criterion "object class=pcimPolicy".
+
+ The approach described in the preceding paragraph will not work for
+ certain directory implementations, because these implementations do
+ not support matching of auxiliary classes in the objectClass
+ attribute. For environments where these implementations are expected
+ to be present, the "tagging" of entries as relevant to policy can be
+
+
+
+
+
+Strassner, et al. Standards Track [Page 17]
+
+RFC 3703 Policy Core LDAP Schema February 2004
+
+
+ accomplished by inserting the special value "POLICY" into the list of
+ values contained in the pcimKeywords attribute (provided by the
+ pcimPolicy class).
+
+ If a PDP needs only a subset of the policy-related objects in the
+ indicated subtrees, then it can be configured with additional
+ selection criteria based on the pcimKeywords attribute defined in the
+ pcimPolicy class. This attribute supports both standardized and
+ administrator- defined values. For example, a PDP could be
+ configured to request only those policy-related objects containing
+ the keywords "DHCP" and "Eastern US".
+
+ To optimize what is expected to be a typical case, the initial
+ request from the client includes not only the object to which its
+ "seed" DN references, but also the subtree contained under this
+ object. The filter for searching this subtree is whatever the client
+ is going to use later to search the other subtrees: object
+ class="pcimPolicy" or the presence of the keyword "POLICY", and/or
+ presence of a more specific value of pcimKeywords (e.g., "QoS Edge
+ Policy").
+
+ Returning to the example in Figure 7, we see that in the best case, a
+ PDP can get all the policy-related objects it needs, and only those
+ objects, with exactly three LDAP requests: one to its starting
+ object A to get the references to B and C, as well as the
+ policy-related objects it needs from the subtree under A, and then
+ one each to B and C to get all the policy-related objects that pass
+ the selection criteria with which it was configured. Once it has
+ retrieved all of these objects, the PDP can then traverse their
+ various DN references locally to understand the semantic
+ relationships among them. The PDP should also be prepared to find a
+ reference to another subtree attached to any of the objects it
+ retrieves, and to follow this reference first, before it follows any
+ of the semantically significant references it has received. This
+ recursion permits a structured approach to identifying related
+ policies. In Figure 7, for example, if the subtree under B includes
+ departmental policies and the one under C includes divisional
+ policies, then there might be a reference from the subtree under C to
+ an object D that roots the subtree of corporate-level policies.
+
+ A PDP SHOULD understand the pcimSubtreesPtrAuxClass class, SHOULD be
+ capable of retrieving and processing the entries in the subtrees it
+ references, and SHOULD be capable of doing all of this recursively.
+ The same requirements apply to any other entity needing to retrieve
+ policy information from the directory. Thus, a Policy Management
+ Tool that retrieves policy entries from the directory in order to
+ perform validation and conflict detection SHOULD also understand and
+ be capable of using the pcimSubtreesPtrAuxClass. All of these
+
+
+
+Strassner, et al. Standards Track [Page 18]
+
+RFC 3703 Policy Core LDAP Schema February 2004
+
+
+ requirements are "SHOULD"s rather than "MUST"s because an LDAP client
+ that doesn't implement them can still access and retrieve the
+ directory entries it needs. The process of doing so will just be
+ less efficient than it would have been if the client had implemented
+ these optimizations.
+
+ When it is serving as a tool for creating policy entries in the
+ directory, a Policy Management Tool SHOULD support creation of
+ pcimSubtreesPtrAuxClass entries and their references to object
+ instances.
+
+4.5.1. Aliases and Other DIT-Optimization Techniques
+
+ Additional flexibility in DIT structure is available to the policy
+ administrator via LDAP aliasing and other techniques. Previous
+ versions of this document have used aliases. However, because
+ aliases are experimental, the use of aliases has been removed from
+ this version of this document. This is because the IETF has yet to
+ produce a specification on how aliases are represented in the
+ directory or how server implementations are to process aliases.
+
+5. Class Definitions
+
+ The semantics for the policy information classes that are to be
+ mapped directly from the information model to an LDAP representation
+ are detailed in [1]. Consequently, all that this document presents
+ for these classes is the specification for how to do the mapping from
+ the information model (which is independent of repository type and
+ access protocol) to a form that can be accessed using LDAP. Remember
+ that some new classes needed to be created (that were not part of
+ [1]) to implement the LDAP mapping. These new LDAP-only classes are
+ fully documented in this document.
+
+ The formal language for specifying the classes, attributes, and DIT
+ structure and content rules is that defined in reference [3]. If
+ your implementation does not support auxiliary class inheritance, you
+ will have to list auxiliary classes in content rules explicitly or
+ define them in another (implementation-specific) way.
+
+ The following notes apply to this section in its entirety.
+
+ Note 1: in the following definitions, the class and attribute
+ definitions follow RFC 2252 [3] but they are line-wrapped to enhance
+ human readability.
+
+ Note 2: where applicable, the possibilities for specifying DIT
+ structure and content rules are noted. However, care must be taken
+ in specifying DIT structure rules. This is because X.501 [4] states
+
+
+
+Strassner, et al. Standards Track [Page 19]
+
+RFC 3703 Policy Core LDAP Schema February 2004
+
+
+ that an entry may only exist in the DIT as a subordinate to another
+ superior entry (the superior) if a DIT structure rule exists in the
+ governing subschema which:
+
+ 1) indicates a name form for the structural object class of the
+ subordinate entry, and
+ 2) either includes the entry's superior structure rule as a possible
+ superior structure rule, or
+ 3) does not specify a superior structure rule.
+
+ If this last case (3) applies, then the entry is defined to be a
+ subschema administrative point. This is not what is desired.
+ Therefore, care must be taken in defining structure rules, and in
+ particular, they must be locally augmented.
+
+ Note 3: Wherever possible, both an equality and a substring matching
+ rule are defined for a particular attribute (as well as an ordering
+ match rule to enable sorting of matching results). This provides two
+ different choices for the developer for maximum flexibility.
+
+ For example, consider the pcimRoles attribute (section 5.3). Suppose
+ that a PEP has reported that it is interested in pcimRules for three
+ roles R1, R2, and R3. If the goal is to minimize queries, then the
+ PDP can supply three substring filters containing the three role
+ names.
+
+ These queries will return all of the pcimRules that apply to the PEP,
+ but they may also get some that do not apply (e.g., ones that contain
+ one of the roles R1, R2, or R3 and one or more other roles present in
+ a role-combination [1]).
+
+ Another strategy would be for the PDP to use only equality filters.
+ This approach eliminates the extraneous replies, but it requires the
+ PDP to explicitly build the desired role-combinations itself. It
+ also requires extra queries. Note that this approach is practical
+ only because the role names in a role combination are required to
+ appear in alphabetical order.
+
+ Note 4: in the following definitions, note that all LDAP matching
+ rules are defined in [3] and in [9]. The corresponding X.500
+ matching rules are defined in [8].
+
+ Note 5: some of the following attribute definitions specify
+ additional constraints on various data types (e.g., this integer has
+ values that are valid from 1..10). Text has been added to instruct
+ servers and applications what to do if a value outside of this range
+
+
+
+
+
+Strassner, et al. Standards Track [Page 20]
+
+RFC 3703 Policy Core LDAP Schema February 2004
+
+
+ is encountered. In all cases, if a constraint is violated, then the
+ policy rule SHOULD be treated as being disabled, meaning that
+ execution of the policy rule SHOULD be stopped.
+
+5.1. The Abstract Class pcimPolicy
+
+ The abstract class pcimPolicy is a direct mapping of the abstract
+ class Policy from the PCIM. The class value "pcimPolicy" is also
+ used as the mechanism for identifying policy-related instances in the
+ Directory Information Tree. An instance of any class may be "tagged"
+ with this class value by attaching to it the auxiliary class
+ pcimElementAuxClass. Since pcimPolicy is derived from the class
+ dlm1ManagedElement defined in reference [6], this specification has a
+ normative dependency on that element of reference [6].
+
+ The class definition is as follows:
+
+ ( 1.3.6.1.1.6.1.1 NAME 'pcimPolicy'
+ DESC 'An abstract class that is the base class for all classes
+ that describe policy-related instances.'
+ SUP dlm1ManagedElement
+ ABSTRACT
+ MAY ( cn $ dlmCaption $ dlmDescription $ orderedCimKeys $
+ pcimKeywords )
+ )
+
+ The attribute cn is defined in RFC 2256 [7]. The dlmCaption,
+ dlmDescription, and orderedCimKeys attributes are defined in [6].
+
+ The pcimKeywords attribute is a multi-valued attribute that contains
+ a set of keywords to assist directory clients in locating the policy
+ objects identified by these keywords. It is defined as follows:
+
+ ( 1.3.6.1.1.6.2.3 NAME 'pcimKeywords'
+ DESC 'A set of keywords to assist directory clients in
+ locating the policy objects applicable to them.'
+ EQUALITY caseIgnoreMatch
+ ORDERING caseIgnoreOrderingMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ )
+
+
+
+
+
+
+
+
+
+
+Strassner, et al. Standards Track [Page 21]
+
+RFC 3703 Policy Core LDAP Schema February 2004
+
+
+5.2. The Three Policy Group Classes
+
+ PCIM [1] defines the PolicyGroup class to serve as a generalized
+ aggregation mechanism, enabling PolicyRules and/or PolicyGroups to be
+ aggregated together. PCLS maps this class into three LDAP classes,
+ called pcimGroup, pcimGroupAuxClass, and pcimGroupInstance. This is
+ done in order to provide maximum flexibility for the DIT designer.
+
+ The class definitions for the three policy group classes are listed
+ below. These class definitions do not include attributes to realize
+ the PolicyRuleInPolicyGroup and PolicyGroupInPolicyGroup associations
+ from the PCIM. This is because a pcimGroup object refers to
+ instances of pcimGroup and pcimRule via, respectively, the attribute
+ pcimGroupsAuxContainedSet in the pcimGroupContainmentAuxClass object
+ class and the attribute pcimRulesAuxContainedSet in the
+ pcimRuleContainmentAuxClass object class.
+
+ To maximize flexibility, the pcimGroup class is defined as abstract.
+ The subclass pcimGroupAuxClass provides for auxiliary attachment to
+ another entry, while the structural subclass pcimGroupInstance is
+ available to represent a policy group as a standalone entry.
+
+ The class definitions are as follows. First, the definition of the
+ abstract class pcimGroup:
+
+ ( 1.3.6.1.1.6.1.2 NAME 'pcimGroup'
+ DESC 'A container for a set of related pcimRules and/or
+ a set of related pcimGroups.'
+ SUP pcimPolicy
+ ABSTRACT
+ MAY ( pcimGroupName )
+ )
+
+ The one attribute of pcimGroup is pcimGroupName. This attribute is
+ used to define a user-friendly name of this policy group, and may be
+ used as a naming attribute if desired. It is defined as follows:
+
+ ( 1.3.6.1.1.6.2.4 NAME 'pcimGroupName'
+ DESC 'The user-friendly name of this policy group.'
+ EQUALITY caseIgnoreMatch
+ ORDERING caseIgnoreOrderingMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ SINGLE-VALUE
+ )
+
+
+
+
+
+
+Strassner, et al. Standards Track [Page 22]
+
+RFC 3703 Policy Core LDAP Schema February 2004
+
+
+ The two subclasses of pcimGroup are defined as follows. The class
+ pcimGroupAuxClass is an auxiliary class that can be used to collect a
+ set of related pcimRule and/or pcimGroup classes. It is defined as
+ follows:
+
+ ( 1.3.6.1.1.6.1.3 NAME 'pcimGroupAuxClass'
+ DESC 'An auxiliary class that collects a set of related
+ pcimRule and/or pcimGroup entries.'
+ SUP pcimGroup
+ AUXILIARY
+ )
+
+ The class pcimGroupInstance is a structural class that can be used to
+ collect a set of related pcimRule and/or pcimGroup classes. It is
+ defined as follows:
+
+ ( 1.3.6.1.1.6.1.4 NAME 'pcimGroupInstance'
+ DESC 'A structural class that collects a set of related
+ pcimRule and/or pcimGroup entries.'
+ SUP pcimGroup
+ STRUCTURAL
+ )
+
+ A DIT content rule could be written to enable an instance of
+ pcimGroupInstance to have attached to it either references to one or
+ more policy groups (using pcimGroupContainmentAuxClass) or references
+ to one or more policy rules (using pcimRuleContainmentAuxClass).
+ This would be used to formalize the semantics of the PolicyGroup
+ class [1]. Since these semantics do not include specifying any
+ properties of the PolicyGroup class, the content rule would not need
+ to specify any attributes.
+
+ Similarly, three separate DIT structure rules could be written, each
+ of which would refer to a specific name form that identified one of
+ the three possible naming attributes (i.e., pcimGroupName, cn, and
+ orderedCIMKeys) for the pcimGroup object class. This structure rule
+ SHOULD include a superiorStructureRule (see Note 2 at the beginning
+ of section 5). The three name forms referenced by the three
+ structure rules would each define one of the three naming attributes.
+
+5.3. The Three Policy Rule Classes
+
+ The information model defines a PolicyRule class to represent the "If
+ Condition then Action" semantics associated with processing policy
+ information. For maximum flexibility, the PCLS maps this class into
+ three LDAP classes.
+
+
+
+
+
+Strassner, et al. Standards Track [Page 23]
+
+RFC 3703 Policy Core LDAP Schema February 2004
+
+
+ To maximize flexibility, the pcimRule class is defined as abstract.
+ The subclass pcimRuleAuxClass provides for auxiliary attachment to
+ another entry, while the structural subclass pcimRuleInstance is
+ available to represent a policy rule as a standalone entry.
+
+ The conditions and actions associated with a policy rule are modeled,
+ respectively, with auxiliary subclasses of the auxiliary classes
+ pcimConditionAuxClass and pcimActionAuxClass. Each of these
+ auxiliary subclasses is attached to an instance of one of three
+ structural classes. A subclass of pcimConditionAuxClass is attached
+ to an instance of pcimRuleInstance, to an instance of
+ pcimRuleConditionAssociation, or to an instance of
+ pcimPolicyInstance. Similarly, a subclass of pcimActionAuxClass is
+ attached to an instance of pcimRuleInstance, to an instance of
+ pcimRuleActionAssociation, or to an instance of pcimPolicyInstance.
+
+ The pcimRuleValidityPeriodList attribute (defined below) realizes the
+ PolicyRuleValidityPeriod association defined in the PCIM. Since this
+ association has no additional properties besides those that tie the
+ association to its associated objects, this association can be
+ realized by simply using an attribute. Thus, the
+ pcimRuleValidityPeriodList attribute is simply a multi-valued
+ attribute that provides an unordered set of DN references to one or
+ more instances of the pcimTPCAuxClass, indicating when the policy
+ rule is scheduled to be active and when it is scheduled to be
+ inactive. A policy rule is scheduled to be active if it is active
+ according to AT LEAST ONE of the pcimTPCAuxClass instances referenced
+ by this attribute.
+
+ The PolicyConditionInPolicyRule and PolicyActionInPolicyRule
+ associations, however, do have additional attributes. The
+ association PolicyActionInPolicyRule defines an integer attribute to
+ sequence the actions, and the association PolicyConditionInPolicyRule
+ has both an integer attribute to group the condition terms as well as
+ a Boolean property to specify whether a condition is to be negated.
+
+ In the PCLS, these additional association attributes are represented
+ as attributes of two classes introduced specifically to model these
+ associations. These classes are the pcimRuleConditionAssociation
+ class and the pcimRuleActionAssociation class, which are defined in
+ Sections 5.4 and 5.5, respectively. Thus, they do not appear as
+ attributes of the class pcimRule. Instead, the pcimRuleConditionList
+ and pcimRuleActionList attributes can be used to reference these
+ classes.
+
+
+
+
+
+
+
+Strassner, et al. Standards Track [Page 24]
+
+RFC 3703 Policy Core LDAP Schema February 2004
+
+
+ The class definitions for the three pcimRule classes are as follows.
+
+ The abstract class pcimRule is a base class for representing the "If
+ Condition then Action" semantics associated with a policy rule. It
+ is defined as follows:
+
+ ( 1.3.6.1.1.6.1.5 NAME 'pcimRule'
+ DESC 'The base class for representing the "If Condition
+ then Action" semantics associated with a policy rule.'
+ SUP pcimPolicy
+ ABSTRACT
+ MAY ( pcimRuleName $ pcimRuleEnabled $
+ pcimRuleConditionListType $ pcimRuleConditionList $
+ pcimRuleActionList $ pcimRuleValidityPeriodList $
+ pcimRuleUsage $ pcimRulePriority $
+ pcimRuleMandatory $ pcimRuleSequencedActions $
+ pcimRoles )
+ )
+
+ The PCIM [1] defines seven properties for the PolicyRule class. The
+ PCLS defines eleven attributes for the pcimRule class, which is the
+ LDAP equivalent of the PolicyRule class. Of these eleven attributes,
+ seven are mapped directly from corresponding properties in PCIM's
+ PolicyRule class. The remaining four attributes are a class-specific
+ optional naming attribute, and three attributes used to realize the
+ three associations that the pcimRule class participates in.
+
+ The pcimRuleName attribute is used as a user-friendly name of this
+ policy rule, and can also serve as the class-specific optional naming
+ attribute. It is defined as follows:
+
+ ( 1.3.6.1.1.6.2.5 NAME 'pcimRuleName'
+ DESC 'The user-friendly name of this policy rule.'
+ EQUALITY caseIgnoreMatch
+ ORDERING caseIgnoreOrderingMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ SINGLE-VALUE
+ )
+
+ The pcimRuleEnabled attribute is an integer enumeration indicating
+ whether a policy rule is administratively enabled (value=1),
+ administratively disabled (value=2), or enabled for debug (value=3).
+ It is defined as follows:
+
+ ( 1.3.6.1.1.6.2.6 NAME 'pcimRuleEnabled'
+ DESC 'An integer indicating whether a policy rule is
+ administratively enabled (value=1), disabled
+
+
+
+Strassner, et al. Standards Track [Page 25]
+
+RFC 3703 Policy Core LDAP Schema February 2004
+
+
+ (value=2), or enabled for debug (value=3).'
+ EQUALITY integerMatch
+ ORDERING integerOrderingMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
+ SINGLE-VALUE
+ )
+
+ Note: All other values for the pcimRuleEnabled attribute are
+ considered errors, and the administrator SHOULD treat this rule as
+ being disabled if an invalid value is found.
+
+ The pcimRuleConditionListType attribute is used to indicate whether
+ the list of policy conditions associated with this policy rule is in
+ disjunctive normal form (DNF, value=1) or conjunctive normal form
+ (CNF, value=2). It is defined as follows:
+
+ ( 1.3.6.1.1.6.2.7 NAME 'pcimRuleConditionListType'
+ DESC 'A value of 1 means that this policy rule is in
+ disjunctive normal form; a value of 2 means that this
+ policy rule is in conjunctive normal form.'
+ EQUALITY integerMatch
+ ORDERING integerOrderingMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
+ SINGLE-VALUE
+ )
+
+ Note: any value other than 1 or 2 for the pcimRuleConditionListType
+ attribute is considered an error. Administrators SHOULD treat this
+ rule as being disabled if an invalid value is found, since it is
+ unclear how to structure the condition list.
+
+ The pcimRuleConditionList attribute is a multi-valued attribute that
+ is used to realize the policyRuleInPolicyCondition association
+ defined in [1]. It contains a set of DNs of
+ pcimRuleConditionAssociation entries representing associations
+ between this policy rule and its conditions. No order is implied.
+ It is defined as follows:
+
+ ( 1.3.6.1.1.6.2.8 NAME 'pcimRuleConditionList'
+ DESC 'Unordered set of DNs of pcimRuleConditionAssociation
+ entries representing associations between this policy
+ rule and its conditions.'
+ EQUALITY distinguishedNameMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
+ )
+
+
+
+
+
+
+Strassner, et al. Standards Track [Page 26]
+
+RFC 3703 Policy Core LDAP Schema February 2004
+
+
+ The pcimRuleActionList attribute is a multi-valued attribute that is
+ used to realize the policyRuleInPolicyAction association defined in
+ [1]. It contains a set of DNs of pcimRuleActionAssociation entries
+ representing associations between this policy rule and its actions.
+ No order is implied. It is defined as follows:
+
+ ( 1.3.6.1.1.6.2.9 NAME 'pcimRuleActionList'
+ DESC 'Unordered set of DNs of pcimRuleActionAssociation
+ entries representing associations between this policy
+ rule and its actions.'
+ EQUALITY distinguishedNameMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
+ )
+
+ The pcimRuleValidityPeriodList attribute is a multi-valued attribute
+ that is used to realize the pcimRuleValidityPeriod association that
+ is defined in [1]. It contains a set of DNs of
+ pcimRuleValidityAssociation entries that determine when the pcimRule
+ is scheduled to be active or inactive. No order is implied. It is
+ defined as follows:
+
+ ( 1.3.6.1.1.6.2.10 NAME 'pcimRuleValidityPeriodList'
+ DESC 'Unordered set of DNs of pcimRuleValidityAssociation
+ entries that determine when the pcimRule is scheduled
+ to be active or inactive.'
+ EQUALITY distinguishedNameMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
+ )
+
+ The pcimRuleUsage attribute is a free-form string providing
+ guidelines on how this policy should be used. It is defined as
+ follows:
+
+ ( 1.3.6.1.1.6.2.11 NAME 'pcimRuleUsage'
+ DESC 'This attribute is a free-form sting providing
+ guidelines on how this policy should be used.'
+ EQUALITY caseIgnoreMatch
+ ORDERING caseIgnoreOrderingMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ SINGLE-VALUE
+ )
+
+
+
+
+
+
+
+
+
+Strassner, et al. Standards Track [Page 27]
+
+RFC 3703 Policy Core LDAP Schema February 2004
+
+
+ The pcimRulePriority attribute is a non-negative integer that is used
+ to prioritize this pcimRule relative to other pcimRules. A larger
+ value indicates a higher priority. It is defined as follows:
+
+ ( 1.3.6.1.1.6.2.12 NAME 'pcimRulePriority'
+ DESC 'A non-negative integer for prioritizing this
+ pcimRule relative to other pcimRules. A larger
+ value indicates a higher priority.'
+ EQUALITY integerMatch
+ ORDERING integerOrderingMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
+ SINGLE-VALUE
+ )
+
+ Note: if the value of the pcimRulePriority field is 0, then it SHOULD
+ be treated as "don't care". On the other hand, if the value is
+ negative, then it SHOULD be treated as an error and Administrators
+ SHOULD treat this rule as being disabled.
+
+ The pcimRuleMandatory attribute is a Boolean attribute that, if TRUE,
+ indicates that for this policy rule, the evaluation of its conditions
+ and execution of its actions (if the condition is satisfied) is
+ required. If it is FALSE, then the evaluation of its conditions and
+ execution of its actions (if the condition is satisfied) is not
+ required. This attribute is defined as follows:
+
+ ( 1.3.6.1.1.6.2.13 NAME 'pcimRuleMandatory'
+ DESC 'If TRUE, indicates that for this policy rule, the
+ evaluation of its conditions and execution of its
+ actions (if the condition is satisfied) is required.'
+ EQUALITY booleanMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
+ SINGLE-VALUE
+ )
+
+ The pcimRuleSequencedActions attribute is an integer enumeration that
+ is used to indicate that the ordering of actions defined by the
+ pcimActionOrder attribute is either mandatory(value=1),
+ recommended(value=2), or dontCare(value=3). It is defined as
+ follows:
+
+ ( 1.3.6.1.1.6.2.14 NAME 'pcimRuleSequencedActions'
+ DESC 'An integer enumeration indicating that the ordering of
+ actions defined by the pcimActionOrder attribute is
+ mandatory(1), recommended(2), or dontCare(3).'
+ EQUALITY integerMatch
+ ORDERING integerOrderingMatch
+
+
+
+
+Strassner, et al. Standards Track [Page 28]
+
+RFC 3703 Policy Core LDAP Schema February 2004
+
+
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
+ SINGLE-VALUE
+ )
+
+ Note: if the value of pcimRulesSequencedActions field is not one of
+ these three values, then Administrators SHOULD treat this rule as
+ being disabled.
+
+ The pcimRoles attribute represents the policyRoles property of [1].
+ Each value of this attribute represents a role-combination, which is
+ a string of the form:
+ <RoleName>[&&<RoleName>]* where the individual role names appear
+ in alphabetical order according to the collating sequence for UCS-2.
+ This attribute is defined as follows:
+
+ ( 1.3.6.1.1.6.2.15 NAME 'pcimRoles'
+ DESC 'Each value of this attribute represents a role-
+ combination.'
+ EQUALITY caseIgnoreMatch
+ ORDERING caseIgnoreOrderingMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ )
+
+ Note: if the value of the pcimRoles attribute does not conform to the
+ format "<RoleName>[&&<RoleName>]*" (see Section 6.3.7 of [1]), then
+ this attribute is malformed and its policy rule SHOULD be treated as
+ being disabled.
+
+ The two subclasses of the pcimRule class are defined as follows.
+ First, the pcimRuleAuxClass is an auxiliary class for representing
+ the "If Condition then Action" semantics associated with a policy
+ rule. Its class definition is as follows:
+
+ ( 1.3.6.1.1.6.1.6 NAME 'pcimRuleAuxClass'
+ DESC 'An auxiliary class for representing the "If Condition
+ then Action" semantics associated with a policy rule.'
+ SUP pcimRule
+ AUXILIARY
+ )
+
+ The pcimRuleInstance is a structural class for representing the "If
+ Condition then Action" semantics associated with a policy rule. Its
+ class definition is as follows:
+
+ ( 1.3.6.1.1.6.1.7 NAME 'pcimRuleInstance'
+ DESC 'A structural class for representing the "If Condition
+ then Action" semantics associated with a policy rule.'
+
+
+
+Strassner, et al. Standards Track [Page 29]
+
+RFC 3703 Policy Core LDAP Schema February 2004
+
+
+ SUP pcimRule
+ STRUCTURAL
+ )
+
+ A DIT content rule could be written to enable an instance of
+ pcimRuleInstance to have attached to it either references to one or
+ more policy conditions (using pcimConditionAuxClass) or references to
+ one or more policy actions (using pcimActionAuxClass). This would be
+ used to formalize the semantics of the PolicyRule class [1]. Since
+ these semantics do not include specifying any properties of the
+ PolicyRule class, the content rule would not need to specify any
+ attributes.
+
+ Similarly, three separate DIT structure rules could be written, each
+ of which would refer to a specific name form that identified one of
+ its three possible naming attributes (i.e., pcimRuleName, cn, and
+ orderedCIMKeys). This structure rule SHOULD include a
+ superiorStructureRule (see Note 2 at the beginning of section 5).
+ The three name forms referenced by the three structure rules would
+ each define one of the three naming attributes.
+
+5.4. The Class pcimRuleConditionAssociation
+
+ This class contains attributes to represent the properties of the
+ PCIM's PolicyConditionInPolicyRule association. Instances of this
+ class are related to an instance of pcimRule via DIT containment.
+ The policy conditions themselves are represented by auxiliary
+ subclasses of the auxiliary class pcimConditionAuxClass. These
+ auxiliary classes are attached directly to instances of
+ pcimRuleConditionAssociation for rule-specific policy conditions.
+ For a reusable policy condition, the policyCondition auxiliary
+ subclass is attached to an instance of the class pcimPolicyInstance
+ (which is presumably associated with a pcimRepository by DIT
+ containment), and the policyConditionDN attribute (of this class) is
+ used to reference the reusable policyCondition instance.
+
+ The class definition is as follows:
+
+ ( 1.3.6.1.1.6.1.8 NAME 'pcimRuleConditionAssociation'
+ DESC 'This class contains attributes characterizing the
+ relationship between a policy rule and one of its
+ policy conditions.'
+ SUP pcimPolicy
+ MUST ( pcimConditionGroupNumber $ pcimConditionNegated )
+ MAY ( pcimConditionName $ pcimConditionDN )
+ )
+
+
+
+
+
+Strassner, et al. Standards Track [Page 30]
+
+RFC 3703 Policy Core LDAP Schema February 2004
+
+
+ The attributes of this class are defined as follows.
+
+ The pcimConditionGroupNumber attribute is a non-negative integer. It
+ is used to identify the group to which the condition referenced by
+ this association is assigned. This attribute is defined as follows:
+
+ ( 1.3.6.1.1.6.2.16
+ NAME 'pcimConditionGroupNumber'
+ DESC 'The number of the group to which a policy condition
+ belongs. This is used to form the DNF or CNF
+ expression associated with a policy rule.'
+ EQUALITY integerMatch
+ ORDERING integerOrderingMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
+ SINGLE-VALUE
+ )
+
+ Note that this number is non-negative. A negative value for this
+ attribute is invalid, and any policy rule that refers to an invalid
+ entry SHOULD be treated as being disabled.
+
+ The pcimConditionNegated attribute is a Boolean attribute that
+ indicates whether this policy condition is to be negated or not. If
+ it is TRUE (FALSE), it indicates that a policy condition IS (IS NOT)
+ negated in the DNF or CNF expression associated with a policy rule.
+ This attribute is defined as follows:
+
+ ( 1.3.6.1.1.6.2.17
+ NAME 'pcimConditionNegated'
+ DESC 'If TRUE (FALSE), it indicates that a policy condition
+ IS (IS NOT) negated in the DNF or CNF expression
+ associated with a policy rule.'
+ EQUALITY booleanMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
+ SINGLE-VALUE
+ )
+
+ The pcimConditionName is a user-friendly name for identifying this
+ policy condition, and may be used as a naming attribute if desired.
+ This attribute is defined as follows:
+
+ ( 1.3.6.1.1.6.2.18
+ NAME 'pcimConditionName'
+ DESC 'A user-friendly name for a policy condition.'
+ EQUALITY caseIgnoreMatch
+ ORDERING caseIgnoreOrderingMatch
+ SUBSTR caseIgnoreSubstringsMatch
+
+
+
+
+Strassner, et al. Standards Track [Page 31]
+
+RFC 3703 Policy Core LDAP Schema February 2004
+
+
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ SINGLE-VALUE
+ )
+
+ The pcimConditionDN attribute is a DN that references an instance of
+ a reusable policy condition. This attribute is defined as follows:
+
+ ( 1.3.6.1.1.6.2.19
+ NAME 'pcimConditionDN'
+ DESC 'A DN that references an instance of a reusable policy
+ condition.'
+ EQUALITY distinguishedNameMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
+ SINGLE-VALUE
+ )
+
+ A DIT content rule could be written to enable an instance of
+ pcimRuleConditionAssociation to have attached to it an instance of
+ the auxiliary class pcimConditionAuxClass, or one of its subclasses.
+ This would be used to formalize the semantics of the
+ PolicyConditionInPolicyRule association. Specifically, this would be
+ used to represent a rule-specific policy condition [1].
+ Similarly, three separate DIT structure rules could be written. Each
+ of these DIT structure rules would refer to a specific name form that
+ defined two important semantics. First, each name form would
+ identify one of the three possible naming attributes (i.e.,
+ pcimConditionName, cn, and orderedCIMKeys) for the
+ pcimRuleConditionAssociation object class. Second, each name form
+ would require that an instance of the pcimRuleConditionAssociation
+ class have as its superior an instance of the pcimRule class. This
+ structure rule SHOULD also include a superiorStructureRule (see Note
+ 2 at the beginning of section 5).
+
+5.5. The Class pcimRuleValidityAssociation
+
+ The policyRuleValidityPeriod aggregation is mapped to the PCLS
+ pcimRuleValidityAssociation class. This class represents the
+ scheduled activation and deactivation of a policy rule by binding the
+ definition of times that the policy is active to the policy rule
+ itself. The "scheduled" times are either identified through an
+ attached auxiliary class pcimTPCAuxClass, or are referenced through
+ its pcimTimePeriodConditionDN attribute.
+
+ This class is defined as follows:
+
+ ( 1.3.6.1.1.6.1.9 NAME 'pcimRuleValidityAssociation'
+ DESC 'This defines the scheduled activation or deactivation
+ of a policy rule.'
+
+
+
+Strassner, et al. Standards Track [Page 32]
+
+RFC 3703 Policy Core LDAP Schema February 2004
+
+
+ SUP pcimPolicy
+ STRUCTURAL
+ MAY ( pcimValidityConditionName $ pcimTimePeriodConditionDN )
+ )
+
+ The attributes of this class are defined as follows:
+
+ The pcimValidityConditionName attribute is used to define a
+ user-friendly name of this condition, and may be used as a naming
+ attribute if desired. This attribute is defined as follows:
+
+ ( 1.3.6.1.1.6.2.20
+ NAME 'pcimValidityConditionName'
+ DESC 'A user-friendly name for identifying an instance of
+ a pcimRuleValidityAssociation entry.'
+ EQUALITY caseIgnoreMatch
+ ORDERING caseIgnoreOrderingMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ SINGLE-VALUE
+ )
+
+ The pcimTimePeriodConditionDN attribute is a DN that references a
+ reusable time period condition. It is defined as follows:
+
+ ( 1.3.6.1.1.6.2.21
+ NAME 'pcimTimePeriodConditionDN'
+ DESC 'A reference to a reusable policy time period
+ condition.'
+ EQUALITY distinguishedNameMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
+ SINGLE-VALUE
+ )
+
+ A DIT content rule could be written to enable an instance of
+ pcimRuleValidityAssociation to have attached to it an instance of the
+ auxiliary class pcimTPCAuxClass, or one of its subclasses. This
+ would be used to formalize the semantics of the
+ PolicyRuleValidityPeriod aggregation [1].
+
+ Similarly, three separate DIT structure rules could be written. Each
+ of these DIT structure rules would refer to a specific name form that
+ defined two important semantics. First, each name form would
+ identify one of the three possible naming attributes (i.e.,
+ pcimValidityConditionName, cn, and orderedCIMKeys) for the
+ pcimRuleValidityAssociation object class. Second, each name form
+ would require that an instance of the pcimRuleValidityAssociation
+ class have as its superior an instance of the pcimRule class. This
+
+
+
+Strassner, et al. Standards Track [Page 33]
+
+RFC 3703 Policy Core LDAP Schema February 2004
+
+
+ structure rule SHOULD also include a superiorStructureRule (see Note
+ 2 at the beginning of section 5).
+
+5.6. The Class pcimRuleActionAssociation
+
+ This class contains an attribute to represent the one property of the
+ PCIM PolicyActionInPolicyRule association, ActionOrder. This
+ property is used to specify an order for executing the actions
+ associated with a policy rule. Instances of this class are related
+ to an instance of pcimRule via DIT containment. The actions
+ themselves are represented by auxiliary subclasses of the auxiliary
+ class pcimActionAuxClass.
+
+ These auxiliary classes are attached directly to instances of
+ pcimRuleActionAssociation for rule-specific policy actions. For a
+ reusable policy action, the pcimAction auxiliary subclass is attached
+ to an instance of the class pcimPolicyInstance (which is presumably
+ associated with a pcimRepository by DIT containment), and the
+ pcimActionDN attribute (of this class) is used to reference the
+ reusable pcimCondition instance.
+
+ The class definition is as follows:
+
+ ( 1.3.6.1.1.6.1.10 NAME 'pcimRuleActionAssociation'
+ DESC 'This class contains attributes characterizing the
+ relationship between a policy rule and one of its
+ policy actions.'
+ SUP pcimPolicy
+ MUST ( pcimActionOrder )
+ MAY ( pcimActionName $ pcimActionDN )
+ )
+
+ The pcimActionName attribute is used to define a user-friendly name
+ of this action, and may be used as a naming attribute if desired.
+ This attribute is defined as follows:
+
+ ( 1.3.6.1.1.6.2.22
+ NAME 'pcimActionName'
+ DESC 'A user-friendly name for a policy action.'
+ EQUALITY caseIgnoreMatch
+ ORDERING caseIgnoreOrderingMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ SINGLE-VALUE
+ )
+
+
+
+
+
+
+Strassner, et al. Standards Track [Page 34]
+
+RFC 3703 Policy Core LDAP Schema February 2004
+
+
+ The pcimActionOrder attribute is an unsigned integer that is used to
+ indicate the relative position of an action in a sequence of actions
+ that are associated with a given policy rule. When this number is
+ positive, it indicates a place in the sequence of actions to be
+ performed, with smaller values indicating earlier positions in the
+ sequence. If the value is zero, then this indicates that the order
+ is irrelevant. Note that if two or more actions have the same
+ non-zero value, they may be performed in any order as long as they
+ are each performed in the correct place in the overall sequence of
+ actions. This attribute is defined as follows:
+
+ ( 1.3.6.1.1.6.2.23
+ NAME 'pcimActionOrder'
+ DESC 'An integer indicating the relative order of an action
+ in the context of a policy rule.'
+ EQUALITY integerMatch
+ ORDERING integerOrderingMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
+ SINGLE-VALUE
+ )
+
+ Note: if the value of the pcimActionOrder field is negative, then it
+ SHOULD be treated as an error and any policy rule that refers to such
+ an entry SHOULD be treated as being disabled.
+
+ The pcimActionDN attribute is a DN that references a reusable policy
+ action. It is defined as follows:
+
+ ( 1.3.6.1.1.6.2.24
+ NAME 'pcimActionDN'
+ DESC 'A DN that references a reusable policy action.'
+ EQUALITY distinguishedNameMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
+ SINGLE-VALUE
+ )
+
+ A DIT content rule could be written to enable an instance of
+ pcimRuleActionAssociation to have attached to it an instance of the
+ auxiliary class pcimActionAuxClass, or one of its subclasses. This
+ would be used to formalize the semantics of the
+ PolicyActionInPolicyRule association. Specifically, this would be
+ used to represent a rule-specific policy action [1].
+
+ Similarly, three separate DIT structure rules could be written. Each
+ of these DIT structure rules would refer to a specific name form that
+ defined two important semantics. First, each name form would
+ identify one of the three possible naming attributes (i.e.,
+ pcimActionName, cn, and orderedCIMKeys) for the
+
+
+
+Strassner, et al. Standards Track [Page 35]
+
+RFC 3703 Policy Core LDAP Schema February 2004
+
+
+ pcimRuleActionAssociation object class. Second, each name form would
+ require that an instance of the pcimRuleActionAssociation class have
+ as its superior an instance of the pcimRule class. This structure
+ rule should also include a superiorStructureRule (see Note 2 at the
+ beginning of section 5).
+
+5.7. The Auxiliary Class pcimConditionAuxClass
+
+ The purpose of a policy condition is to determine whether or not the
+ set of actions (contained in the pcimRule that the condition applies
+ to) should be executed or not. This class defines the basic
+ organizational semantics of a policy condition, as specified in [1].
+ Subclasses of this auxiliary class can be attached to instances of
+ three other classes in the PCLS. When a subclass of this class is
+ attached to an instance of pcimRuleConditionAssociation, or to an
+ instance of pcimRule, it represents a rule-specific policy condition.
+ When a subclass of this class is attached to an instance of
+ pcimPolicyInstance, it represents a reusable policy condition.
+
+ Since all of the classes to which subclasses of this auxiliary class
+ may be attached are derived from the pcimPolicy class, the attributes
+ of pcimPolicy will already be defined for the entries to which these
+ subclasses attach. Thus, this class is derived directly from "top".
+
+ The class definition is as follows:
+
+ ( 1.3.6.1.1.6.1.11 NAME 'pcimConditionAuxClass'
+ DESC 'A class representing a condition to be evaluated in
+ conjunction with a policy rule.'
+ SUP top
+ AUXILIARY
+ )
+
+5.8. The Auxiliary Class pcimTPCAuxClass
+
+ The PCIM defines a time period class, PolicyTimePeriodCondition, to
+ provide a means of representing the time periods during which a
+ policy rule is valid, i.e., active. It also defines an aggregation,
+ PolicyRuleValidityPeriod, so that time periods can be associated with
+ a PolicyRule. The LDAP mapping also provides two classes, one for
+ the time condition itself, and one for the aggregation.
+
+ In the PCIM, the time period class is named
+ PolicyTimePeriodCondition. However, the resulting name of the
+ auxiliary class in this mapping (pcimTimePeriodConditionAuxClass)
+ exceeds the length of a name that some directories can store.
+ Therefore, the name has been shortened to pcimTPCAuxClass.
+
+
+
+
+Strassner, et al. Standards Track [Page 36]
+
+RFC 3703 Policy Core LDAP Schema February 2004
+
+
+ The class definition is as follows:
+
+ ( 1.3.6.1.1.6.1.12 NAME 'pcimTPCAuxClass'
+ DESC 'This provides the capability of enabling or disabling
+ a policy rule according to a predetermined schedule.'
+ SUP pcimConditionAuxClass
+ AUXILIARY
+ MAY ( pcimTPCTime $ pcimTPCMonthOfYearMask $
+ pcimTPCDayOfMonthMask $ pcimTPCDayOfWeekMask $
+ pcimTPCTimeOfDayMask $ pcimTPCLocalOrUtcTime )
+ )
+
+ The attributes of the pcimTPCAuxClass are defined as follows.
+
+ The pcimTPCTime attribute represents the time period that a policy
+ rule is enabled for. This attribute is defined as a string in [1]
+ with a special format which defines a time period with a starting
+ date and an ending date separated by a forward slash ("/"), as
+ follows:
+
+ yyyymmddThhmmss/yyyymmddThhmmss
+
+ where the first date and time may be replaced with the string
+ "THISANDPRIOR" or the second date and time may be replaced with the
+ string "THISANDFUTURE". This attribute is defined as follows:
+
+ ( 1.3.6.1.1.6.2.25
+ NAME 'pcimTPCTime'
+ DESC 'The start and end times on which a policy rule is
+ valid.'
+ EQUALITY caseIgnoreMatch
+ ORDERING caseIgnoreOrderingMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.44
+ SINGLE-VALUE
+ )
+
+ The value of this attribute SHOULD be checked against its defined
+ format ("yyyymmddThhmmss/yyyymmddThhmmss", where the first and second
+ date strings may be replaced with the strings "THISANDPRIOR" and
+ "THISANDFUTURE"). If the value of this attribute does not conform to
+ this syntax, then this SHOULD be considered an error and the policy
+ rule SHOULD be treated as being disabled.
+
+ The next four attributes (pcimTPCMonthOfYearMask,
+ pcimTPCDayOfMonthMask, pcimTPCDayOfWeekMask, and
+ pcimTPCTimeOfDayMask) are all defined as octet strings in [1].
+ However, the semantics of each of these attributes are contained in
+
+
+
+Strassner, et al. Standards Track [Page 37]
+
+RFC 3703 Policy Core LDAP Schema February 2004
+
+
+ bit strings of various fixed lengths. Therefore, the PCLS uses a
+ syntax of Bit String to represent each of them. The definition of
+ these four attributes are as follows.
+
+ The pcimTPCMonthOfYearMask attribute defines a 12-bit mask
+ identifying the months of the year in which a policy rule is valid.
+ The format is a bit string of length 12, representing the months of
+ the year from January through December. The definition of this
+ attribute is as follows:
+
+ ( 1.3.6.1.1.6.2.26
+ NAME 'pcimTPCMonthOfYearMask'
+ DESC 'This identifies the valid months of the year for a
+ policy rule using a 12-bit string that represents the
+ months of the year from January through December.'
+ EQUALITY bitStringMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.6
+ SINGLE-VALUE
+ )
+
+ The value of this attribute SHOULD be checked against its defined
+ format. If the value of this attribute does not conform to this
+ syntax, then this SHOULD be considered an error and the policy rule
+ SHOULD be treated as being disabled.
+
+ The pcimTPCMonthOfDayMask attribute defines a mask identifying the
+ days of the month on which a policy rule is valid. The format is a
+ bit string of length 62. The first 31 positions represent the days
+ of the month in ascending order, from day 1 to day 31. The next 31
+ positions represent the days of the month in descending order, from
+ the last day to the day 31 days from the end. The definition of this
+ attribute is as follows:
+
+ ( 1.3.6.1.1.6.2.27
+ NAME 'pcimTPCDayOfMonthMask'
+ DESC 'This identifies the valid days of the month for a
+ policy rule using a 62-bit string. The first 31
+ positions represent the days of the month in ascending
+ order, and the next 31 positions represent the days of
+ the month in descending order.'
+ EQUALITY bitStringMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.6
+ SINGLE-VALUE
+ )
+
+
+
+
+
+
+
+Strassner, et al. Standards Track [Page 38]
+
+RFC 3703 Policy Core LDAP Schema February 2004
+
+
+ The value of this attribute SHOULD be checked against its defined
+ format. If the value of this attribute does not conform to this
+ syntax, then this SHOULD be considered an error and the policy rule
+ SHOULD be treated as being disabled.
+
+ The pcimTPCDayOfWeekMask attribute defines a mask identifying the
+ days of the week on which a policy rule is valid. The format is a
+ bit string of length 7, representing the days of the week from Sunday
+ through Saturday. The definition of this attribute is as follows:
+
+ ( 1.3.6.1.1.6.2.28
+ NAME 'pcimTPCDayOfWeekMask'
+ DESC 'This identifies the valid days of the week for a
+ policy rule using a 7-bit string. This represents
+ the days of the week from Sunday through Saturday.'
+ EQUALITY bitStringMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.6
+ SINGLE-VALUE
+ )
+
+ The value of this attribute SHOULD be checked against its defined
+ format. If the value of this attribute does not conform to this
+ syntax, then this SHOULD be considered an error and the policy rule
+ SHOULD be treated as being disabled.
+
+ The pcimTPCTimeOfDayMask attribute defines the range of times at
+ which a policy rule is valid. If the second time is earlier than the
+ first, then the interval spans midnight. The format of the string is
+ Thhmmss/Thhmmss. The definition of this attribute is as follows:
+
+ ( 1.3.6.1.1.6.2.29
+ NAME 'pcimTPCTimeOfDayMask'
+ DESC 'This identifies the valid range of times for a policy
+ using the format Thhmmss/Thhmmss.'
+ EQUALITY caseIgnoreMatch
+ ORDERING caseIgnoreOrderingMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.44
+ SINGLE-VALUE
+ )
+
+ The value of this attribute SHOULD be checked against its defined
+ format. If the value of this attribute does not conform to this
+ syntax, then this SHOULD be considered an error and the policy rule
+ SHOULD be treated as being disabled.
+
+
+
+
+
+
+Strassner, et al. Standards Track [Page 39]
+
+RFC 3703 Policy Core LDAP Schema February 2004
+
+
+ Finally, the pcimTPCLocalOrUtcTime attribute is used to choose
+ between local or UTC time representation. This is mapped as a simple
+ integer syntax, with the value of 1 representing local time and the
+ value of 2 representing UTC time. The definition of this attribute
+ is as follows:
+
+ ( 1.3.6.1.1.6.2.30
+ NAME 'pcimTPCLocalOrUtcTime'
+ DESC 'This defines whether the times in this instance
+ represent local (value=1) times or UTC (value=2)
+ times.'
+ EQUALITY integerMatch
+ ORDERING integerOrderingMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
+ SINGLE-VALUE
+ )
+
+ Note: if the value of the pcimTPCLocalOrUtcTime is not 1 or 2, then
+ this SHOULD be considered an error and the policy rule SHOULD be
+ disabled. If the attribute is not present at all, then all times are
+ interpreted as if it were present with the value 2, that is, UTC
+ time.
+
+5.9. The Auxiliary Class pcimConditionVendorAuxClass
+
+ This class provides a general extension mechanism for representing
+ policy conditions that have not been modeled with specific
+ properties. Instead, its two properties are used to define the
+ content and format of the condition, as explained below. This class
+ is intended for vendor-specific extensions that are not amenable to
+ using pcimCondition; standardized extensions SHOULD NOT use this
+ class.
+
+ The class definition is as follows:
+
+ ( 1.3.6.1.1.6.1.13 NAME 'pcimConditionVendorAuxClass'
+ DESC 'A class that defines a registered means to describe a
+ policy condition.'
+ SUP pcimConditionAuxClass
+ AUXILIARY
+ MAY ( pcimVendorConstraintData $
+ pcimVendorConstraintEncoding )
+ )
+
+ The pcimVendorConstraintData attribute is a multi-valued attribute.
+ It provides a general mechanism for representing policy conditions
+ that have not been modeled as specific attributes. This information
+ is encoded in a set of octet strings. The format of the octet
+
+
+
+Strassner, et al. Standards Track [Page 40]
+
+RFC 3703 Policy Core LDAP Schema February 2004
+
+
+ strings is identified by the OID stored in the
+ pcimVendorConstraintEncoding attribute. This attribute is defined as
+ follows:
+
+ ( 1.3.6.1.1.6.2.31
+ NAME 'pcimVendorConstraintData'
+ DESC 'Mechanism for representing constraints that have not
+ been modeled as specific attributes. Their format is
+ identified by the OID stored in the attribute
+ pcimVendorConstraintEncoding.'
+ EQUALITY octetStringMatch
+ ORDERING octetStringOrderingMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.40
+ )
+
+ The pcimVendorConstraintEncoding attribute is used to identify the
+ format and semantics for the pcimVendorConstraintData attribute.
+ This attribute is defined as follows:
+
+ ( 1.3.6.1.1.6.2.32
+ NAME 'pcimVendorConstraintEncoding'
+ DESC 'An OID identifying the format and semantics for the
+ pcimVendorConstraintData for this instance.'
+ EQUALITY objectIdentifierMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
+ SINGLE-VALUE
+ )
+
+5.10. The Auxiliary Class pcimActionAuxClass
+
+ The purpose of a policy action is to execute one or more operations
+ that will affect network traffic and/or systems, devices, etc. in
+ order to achieve a desired policy state. This class is used to
+ represent an action to be performed as a result of a policy rule
+ whose condition clause was satisfied.
+
+ Subclasses of this auxiliary class can be attached to instances of
+ three other classes in the PCLS. When a subclass of this class is
+ attached to an instance of pcimRuleActionAssociation, or to an
+ instance of pcimRule, it represents a rule-specific policy action.
+ When a subclass of this class is attached to an instance of
+ pcimPolicyInstance, it represents a reusable policy action.
+
+ Since all of the classes to which subclasses of this auxiliary class
+ may be attached are derived from the pcimPolicy class, the attributes
+ of the pcimPolicy class will already be defined for the entries to
+ which these subclasses attach. Thus, this class is derived directly
+ from "top".
+
+
+
+Strassner, et al. Standards Track [Page 41]
+
+RFC 3703 Policy Core LDAP Schema February 2004
+
+
+ The class definition is as follows:
+
+ ( 1.3.6.1.1.6.1.14 NAME 'pcimActionAuxClass'
+ DESC 'A class representing an action to be performed as a
+ result of a policy rule.'
+ SUP top
+ AUXILIARY
+ )
+
+5.11. The Auxiliary Class pcimActionVendorAuxClass
+
+ The purpose of this class is to provide a general extension mechanism
+ for representing policy actions that have not been modeled with
+ specific properties. Instead, its two properties are used to define
+ the content and format of the action, as explained below.
+
+ As its name suggests, this class is intended for vendor-specific
+ extensions that are not amenable to using the standard pcimAction
+ class. Standardized extensions SHOULD NOT use this class.
+
+ The class definition is as follows:
+
+ ( 1.3.6.1.1.6.1.15 NAME 'pcimActionVendorAuxClass'
+ DESC 'A class that defines a registered means to describe a
+ policy action.'
+ SUP pcimActionAuxClass
+ AUXILIARY
+ MAY ( pcimVendorActionData $ pcimVendorActionEncoding )
+ )
+
+ The pcimVendorActionData attribute is a multi-valued attribute. It
+ provides a general mechanism for representing policy actions that
+ have not been modeled as specific attributes. This information is
+ encoded in a set of octet strings. The format of the octet strings
+ is identified by the OID stored in the pcimVendorActionEncoding
+ attribute. This attribute is defined as follows:
+
+ ( 1.3.6.1.1.6.2.33
+ NAME 'pcimVendorActionData'
+ DESC ' Mechanism for representing policy actions that have
+ not been modeled as specific attributes. Their
+ format is identified by the OID stored in the
+ attribute pcimVendorActionEncoding.'
+ EQUALITY octetStringMatch
+ ORDERING octetStringOrderingMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.40
+ )
+
+
+
+
+Strassner, et al. Standards Track [Page 42]
+
+RFC 3703 Policy Core LDAP Schema February 2004
+
+
+ The pcimVendorActionEncoding attribute is used to identify the format
+ and semantics for the pcimVendorActionData attribute. This attribute
+ is defined as follows:
+
+ ( 1.3.6.1.1.6.2.34
+ NAME 'pcimVendorActionEncoding'
+ DESC 'An OID identifying the format and semantics for the
+ pcimVendorActionData attribute of this instance.'
+ EQUALITY objectIdentifierMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
+ SINGLE-VALUE
+ )
+
+5.12. The Class pcimPolicyInstance
+
+ This class is not defined in the PCIM. Its role is to serve as a
+ structural class to which auxiliary classes representing policy
+ information are attached when the information is reusable. For
+ auxiliary classes representing policy conditions and policy actions,
+ there are alternative structural classes that may be used. See
+ Section 4.4 for a complete discussion of reusable policy conditions
+ and actions, and of the role that this class plays in how they are
+ represented.
+
+ The class definition is as follows:
+
+ ( 1.3.6.1.1.6.1.16 NAME 'pcimPolicyInstance'
+ DESC 'A structural class to which aux classes containing
+ reusable policy information can be attached.'
+ SUP pcimPolicy
+ MAY ( pcimPolicyInstanceName )
+ )
+
+ The pcimPolicyInstanceName attribute is used to define a
+ user-friendly name of this class, and may be used as a naming
+ attribute if desired. It is defined as follows:
+
+ ( 1.3.6.1.1.6.2.35 NAME 'pcimPolicyInstanceName'
+ DESC 'The user-friendly name of this policy instance.'
+ EQUALITY caseIgnoreMatch
+ ORDERING caseIgnoreOrderingMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ SINGLE-VALUE
+ )
+
+
+
+
+
+
+Strassner, et al. Standards Track [Page 43]
+
+RFC 3703 Policy Core LDAP Schema February 2004
+
+
+ A DIT content rule could be written to enable an instance of
+ pcimPolicyInstance to have attached to it either instances of one or
+ more of the auxiliary object classes pcimConditionAuxClass and
+ pcimActionAuxClass. Since these semantics do not include specifying
+ any properties, the content rule would not need to specify any
+ attributes. Note that other content rules could be defined to enable
+ other policy-related auxiliary classes to be attached to
+ pcimPolicyInstance.
+
+ Similarly, three separate DIT structure rules could be written. Each
+ of these DIT structure rules would refer to a specific name form that
+ defined two important semantics. First, each name form would
+ identify one of the three possible naming attributes (i.e.,
+ pcimPolicyInstanceName, cn, and orderedCIMKeys) for this object
+ class. Second, each name form would require that an instance of the
+ pcimPolicyInstance class have as its superior an instance of the
+ pcimRepository class. This structure rule SHOULD also include a
+ superiorStructureRule (see Note 2 at the beginning of section 5).
+
+5.13. The Auxiliary Class pcimElementAuxClass
+
+ This class introduces no additional attributes, beyond those defined
+ in the class pcimPolicy from which it is derived. Its role is to
+ "tag" an instance of a class defined outside the realm of policy
+ information as represented by PCIM as being nevertheless relevant to
+ a policy specification. This tagging can potentially take place at
+ two levels:
+
+ - Every instance to which pcimElementAuxClass is attached becomes
+ an instance of the class pcimPolicy, since pcimElementAuxClass is
+ a subclass of pcimPolicy. Searching for object
+ class="pcimPolicy" will return the instance. (As noted earlier,
+ this approach does NOT work for some directory implementations.
+ To accommodate these implementations, policy-related entries
+ SHOULD be tagged with the pcimKeyword "POLICY".)
+
+ - With the pcimKeywords attribute that it inherits from pcimPolicy,
+ an instance to which pcimElementAuxClass is attached can be
+ tagged as being relevant to a particular type or category of
+ policy information, using standard keywords,
+ administrator-defined keywords, or both.
+
+ The class definition is as follows:
+
+ ( 1.3.6.1.1.6.1.17 NAME 'pcimElementAuxClass'
+ DESC 'An auxiliary class used to tag instances of classes
+ defined outside the realm of policy as relevant to a
+ particular policy specification.'
+
+
+
+Strassner, et al. Standards Track [Page 44]
+
+RFC 3703 Policy Core LDAP Schema February 2004
+
+
+ SUP pcimPolicy
+ AUXILIARY
+ )
+
+5.14. The Three Policy Repository Classes
+
+ These classes provide a container for reusable policy information,
+ such as reusable policy conditions and/or reusable policy actions.
+ This document is concerned with mapping just the properties that
+ appear in these classes. Conceptually, this may be thought of as a
+ special location in the DIT where policy information may reside.
+ Since pcimRepository is derived from the class dlm1AdminDomain
+ defined in reference [6], this specification has a normative
+ dependency on that element of reference [6] (as well as on its entire
+ derivation hierarchy, which also appears in reference [6]). To
+ maximize flexibility, the pcimRepository class is defined as
+ abstract. A subclass pcimRepositoryAuxClass provides for auxiliary
+ attachment to another entry, while a structural subclass
+ pcimRepositoryInstance is available to represent a policy repository
+ as a standalone entry.
+
+ The definition for the pcimRepository class is as follows:
+
+ ( 1.3.6.1.1.6.1.18 NAME 'pcimRepository'
+ DESC 'A container for reusable policy information.'
+ SUP dlm1AdminDomain
+ ABSTRACT
+ MAY ( pcimRepositoryName )
+ )
+
+ The pcimRepositoryName attribute is used to define a user-friendly
+ name of this class, and may be used as a naming attribute if desired.
+ It is defined as follows:
+
+ ( 1.3.6.1.1.6.2.36 NAME 'pcimRepositoryName'
+ DESC 'The user-friendly name of this policy repository.'
+ EQUALITY caseIgnoreMatch
+ ORDERING caseIgnoreOrderingMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ SINGLE-VALUE
+ )
+
+
+
+
+
+
+
+
+
+Strassner, et al. Standards Track [Page 45]
+
+RFC 3703 Policy Core LDAP Schema February 2004
+
+
+ The two subclasses of pcimRepository are defined as follows. First,
+ the pcimRepositoryAuxClass is an auxiliary class that can be used to
+ aggregate reusable policy information. It is defined as follows:
+
+ ( 1.3.6.1.1.6.1.19 NAME 'pcimRepositoryAuxClass'
+ DESC 'An auxiliary class that can be used to aggregate
+ reusable policy information.'
+ SUP pcimRepository
+ AUXILIARY
+ )
+
+ In cases where structural classes are needed instead of an auxiliary
+ class, the pcimRepositoryInstance class is a structural class that
+ can be used to aggregate reusable policy information. It is defined
+ as follows:
+
+ ( 1.3.6.1.1.6.1.20 NAME 'pcimRepositoryInstance'
+ DESC 'A structural class that can be used to aggregate
+ reusable policy information.'
+ SUP pcimRepository
+ STRUCTURAL
+ )
+
+ Three separate DIT structure rules could be written for this class.
+ Each of these DIT structure rules would refer to a specific name form
+ that enabled an instance of the pcimRepository class to be named
+ under any superior using one of the three possible naming attributes
+ (i.e., pcimRepositoryName, cn, and orderedCIMKeys). This structure
+ rule SHOULD also include a superiorStructureRule (see Note 2 at the
+ beginning of section 5).
+
+5.15. The Auxiliary Class pcimSubtreesPtrAuxClass
+
+ This auxiliary class provides a single, multi-valued attribute that
+ references a set of objects that are at the root of DIT subtrees
+ containing policy-related information. By attaching this attribute
+ to instances of various other classes, a policy administrator has a
+ flexible way of providing an entry point into the directory that
+ allows a client to locate and retrieve the policy information
+ relevant to it.
+
+ It is intended that these entries are placed in the DIT such that
+ well-known DNs can be used to reference a well-known structural entry
+ that has the pcimSubtreesPtrAuxClass attached to it. In effect, this
+ defines a set of entry points. Each of these entry points can
+ contain and/or reference all related policy entries for
+
+
+
+
+
+Strassner, et al. Standards Track [Page 46]
+
+RFC 3703 Policy Core LDAP Schema February 2004
+
+
+ any well-known policy domains. The pcimSubtreesPtrAuxClass functions
+ as a tag to identify portions of the DIT that contain policy
+ information.
+
+ This object does not provide the semantic linkages between individual
+ policy objects, such as those between a policy group and the policy
+ rules that belong to it. Its only role is to enable efficient bulk
+ retrieval of policy-related objects, as described in Section 4.5.
+
+ Once the objects have been retrieved, a directory client can
+ determine the semantic linkages by following references contained in
+ multi-valued attributes, such as pcimRulesAuxContainedSet.
+
+ Since policy-related objects will often be included in the DIT
+ subtree beneath an object to which this auxiliary class is attached,
+ a client SHOULD request the policy-related objects from the subtree
+ under the object with these references at the same time that it
+ requests the references themselves.
+
+ Since clients are expected to behave in this way, the policy
+ administrator SHOULD make sure that this subtree does not contain so
+ many objects unrelated to policy that an initial search done in this
+ way results in a performance problem. The pcimSubtreesPtrAuxClass
+ SHOULD NOT be attached to the partition root for a large directory
+ partition containing a relatively few number of policy-related
+ objects along with a large number of objects unrelated to policy
+ (again, "policy" here refers to the PCIM, not the X.501, definition
+ and use of "policy"). A better approach would be to introduce a
+ container object immediately below the partition root, attach
+ pcimSubtreesPtrAuxClass to this container object, and then place all
+ of the policy-related objects in that subtree.
+
+ The class definition is as follows:
+
+ ( 1.3.6.1.1.6.1.21 NAME 'pcimSubtreesPtrAuxClass'
+ DESC 'An auxiliary class providing DN references to roots of
+ DIT subtrees containing policy-related objects.'
+ SUP top
+ AUXILIARY
+ MAY ( pcimSubtreesAuxContainedSet )
+ )
+
+
+
+
+
+
+
+
+
+
+Strassner, et al. Standards Track [Page 47]
+
+RFC 3703 Policy Core LDAP Schema February 2004
+
+
+ The attribute pcimSubtreesAuxContainedSet provides an unordered set
+ of DN references to instances of one or more objects under which
+ policy-related information is present. The objects referenced may or
+ may not themselves contain policy-related information. The attribute
+ definition is as follows:
+
+ ( 1.3.6.1.1.6.2.37
+ NAME 'pcimSubtreesAuxContainedSet'
+ DESC 'DNs of objects that serve as roots for DIT subtrees
+ containing policy-related objects.'
+ EQUALITY distinguishedNameMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
+ )
+
+ Note that the cn attribute does NOT need to be defined for this
+ class. This is because an auxiliary class is used as a means to
+ collect common attributes and treat them as properties of an object.
+ A good analogy is a #include file, except that since an auxiliary
+ class is a class, all the benefits of a class (e.g., inheritance) can
+ be applied to an auxiliary class.
+
+5.16. The Auxiliary Class pcimGroupContainmentAuxClass
+
+ This auxiliary class provides a single, multi-valued attribute that
+ references a set of pcimGroups. By attaching this attribute to
+ instances of various other classes, a policy administrator has a
+ flexible way of providing an entry point into the directory that
+ allows a client to locate and retrieve the pcimGroups relevant to it.
+
+ As is the case with pcimRules, a policy administrator might have
+ several different references to a pcimGroup in the overall directory
+ structure. The pcimGroupContainmentAuxClass is the mechanism that
+ makes it possible for the policy administrator to define all these
+ different references.
+
+ The class definition is as follows:
+
+ ( 1.3.6.1.1.6.1.22 NAME 'pcimGroupContainmentAuxClass'
+ DESC 'An auxiliary class used to bind pcimGroups to an
+ appropriate container object.'
+ SUP top
+ AUXILIARY
+ MAY ( pcimGroupsAuxContainedSet )
+ )
+
+
+
+
+
+
+
+Strassner, et al. Standards Track [Page 48]
+
+RFC 3703 Policy Core LDAP Schema February 2004
+
+
+ The attribute pcimGroupsAuxContainedSet provides an unordered set of
+ references to instances of one or more pcimGroups associated with the
+ instance of a structural class to which this attribute has been
+ appended.
+
+ The attribute definition is as follows:
+
+ ( 1.3.6.1.1.6.2.38
+ NAME 'pcimGroupsAuxContainedSet'
+ DESC 'DNs of pcimGroups associated in some way with the
+ instance to which this attribute has been appended.'
+ EQUALITY distinguishedNameMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
+ )
+
+ Note that the cn attribute does NOT have to be defined for this class
+ for the same reasons as those given for the pcimSubtreesPtrAuxClass
+ in section 5.15.
+
+5.17. The Auxiliary Class pcimRuleContainmentAuxClass
+
+ This auxiliary class provides a single, multi-valued attribute that
+ references a set of pcimRules. By attaching this attribute to
+ instances of various other classes, a policy administrator has a
+ flexible way of providing an entry point into the directory that
+ allows a client to locate and retrieve the pcimRules relevant to it.
+
+ A policy administrator might have several different references to a
+ pcimRule in the overall directory structure. For example, there
+ might be references to all pcimRules for traffic originating in a
+ particular subnet from a directory entry that represents that subnet.
+ At the same time, there might be references to all pcimRules related
+ to a particular DiffServ setting from an instance of a pcimGroup
+ explicitly introduced as a container for DiffServ-related pcimRules.
+ The pcimRuleContainmentAuxClass is the mechanism that makes it
+ possible for the policy administrator to define all these separate
+ references.
+
+ The class definition is as follows:
+
+ ( 1.3.6.1.1.6.1.23 NAME 'pcimRuleContainmentAuxClass'
+ DESC 'An auxiliary class used to bind pcimRules to an
+ appropriate container object.'
+ SUP top
+ AUXILIARY
+ MAY ( pcimRulesAuxContainedSet )
+ )
+
+
+
+
+Strassner, et al. Standards Track [Page 49]
+
+RFC 3703 Policy Core LDAP Schema February 2004
+
+
+ The attribute pcimRulesAuxContainedSet provides an unordered set of
+ references to one or more instances of pcimRules associated with the
+ instance of a structural class to which this attribute has been
+ appended. The attribute definition is as follows:
+
+ ( 1.3.6.1.1.6.2.39
+ NAME 'pcimRulesAuxContainedSet'
+ DESC 'DNs of pcimRules associated in some way with the
+ instance to which this attribute has been appended.'
+ EQUALITY distinguishedNameMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
+ )
+
+ The cn attribute does NOT have to be defined for this class for the
+ same reasons as those given for the pcimSubtreesPtrAuxClass in
+ section 5.15.
+
+6. Extending the Classes Defined in This Document
+
+ The following subsections provide general guidance on how to create a
+ domain-specific schema derived from this document, discuss how the
+ vendor classes in the PCLS should be used, and explain how
+ policyTimePeriodConditions are related to other policy conditions.
+
+6.1. Subclassing pcimConditionAuxClass and pcimActionAuxClass
+
+ In Section 4.4, there is a discussion of how, by representing policy
+ conditions and policy actions as auxiliary classes in a schema, the
+ flexibility is retained to instantiate a particular condition or
+ action as either rule-specific or reusable. This flexibility is lost
+ if a condition or action class is defined as structural rather than
+ auxiliary. For standardized schemata, this document specifies that
+ domain-specific information MUST be expressed in auxiliary subclasses
+ of pcimConditionAuxClass and pcimActionAuxClass. It is RECOMMENDED
+ that non-standardized schemata follow this practice as well.
+
+6.2. Using the Vendor Policy Attributes
+
+ As discussed Section 5.9, the attributes pcimVendorConstraintData and
+ pcimVendorConstraintEncoding are included in the
+ pcimConditionVendorAuxClass to provide a mechanism for representing
+ vendor-specific policy conditions that are not amenable to being
+ represented with the pcimCondition class (or its subclasses). The
+ attributes pcimVendorActionData and pcimVendorActionEncoding in the
+ pcimActionVendorAuxClass class play the same role with respect to
+ actions. This enables interoperability between different vendors who
+ could not otherwise interoperate.
+
+
+
+
+Strassner, et al. Standards Track [Page 50]
+
+RFC 3703 Policy Core LDAP Schema February 2004
+
+
+ For example, imagine a network composed of access devices from vendor
+ A, edge and core devices from vendor B, and a policy server from
+ vendor C. It is desirable for this policy server to be able to
+ configure and manage all of the devices from vendors A and B.
+ Unfortunately, these devices will in general have little in common
+ (e.g., different mechanisms, different ways for controlling those
+ mechanisms, different operating systems, different commands, and so
+ forth). The extension conditions provide a way for vendor-specific
+ commands to be encoded as octet strings, so that a single policy
+ server can commonly manage devices from different vendors.
+
+6.3. Using Time Validity Periods
+
+ Time validity periods are defined as an auxiliary subclass of
+ pcimConditionAuxClass, called pcimTPCAuxClass. This is to allow
+ their inclusion in the AND/OR condition definitions for a pcimRule.
+ Care should be taken not to subclass pcimTPCAuxClass to add
+ domain-specific condition properties.
+
+ For example, it would be incorrect to add IPsec- or QoS-specific
+ condition properties to the pcimTPCAuxClass class, just because IPsec
+ or QoS includes time in its condition definition. The correct
+ subclassing would be to create IPsec or QoS-specific subclasses of
+ pcimConditionAuxClass and then combine instances of these
+ domain-specific condition classes with the appropriate validity
+ period criteria. This is accomplished using the AND/OR association
+ capabilities for policy conditions in pcimRules.
+
+7. Security Considerations
+
+ The PCLS, presented in this document, provides a mapping of the
+ object-oriented model for describing policy information (PCIM) into a
+ data model that forms the basic framework for describing the
+ structure of policy data, in the case where the policy repository
+ takes the form of an LDAP-accessible directory.
+
+ PCLS is not intended to represent any particular system design or
+ implementation. PCLS is not directly useable in a real world system,
+ without the discipline-specific mappings that are works in progress
+ in the Policy Framework Working Group of the IETF.
+
+ These other derivative documents, which use PCIM and its
+ discipline-specific extensions as a base, will need to convey more
+ specific security considerations (refer to RFC 3060 for more
+ information.)
+
+
+
+
+
+
+Strassner, et al. Standards Track [Page 51]
+
+RFC 3703 Policy Core LDAP Schema February 2004
+
+
+ The reason that PCLS, as defined here, is not representative of any
+ real-world system, is that its object classes were designed to be
+ independent of any specific discipline, or policy domain. For
+ example, DiffServ and IPsec represent two different policy domains.
+ Each document that extends PCIM to one of these domains will derive
+ subclasses from the classes and relationships defined in PCIM, in
+ order to represent extensions of a generic model to cover specific
+ technical domains.
+
+ PCIM-derived documents will thus subclass the PCIM classes into
+ classes specific to each technical policy domain (QOS, IPsec, etc.),
+ which will, in turn, be mapped, to directory-specific schemata
+ consistent with the PCLS documented here.
+
+ Even though discipline-specific security requirements are not
+ appropriate for PCLS, specific security requirements MUST be defined
+ for each operational real-world application of PCIM. Just as there
+ will be a wide range of operational, real-world systems using PCIM,
+ there will also be a wide range of security requirements for these
+ systems. Some operational, real-world systems that are deployed
+ using PCLS may have extensive security requirements that impact
+ nearly all object classes utilized by such a system, while other
+ systems' security requirements might have very little impact.
+
+ The derivative documents, discussed above, will create the context
+ for applying operational, real-world, system-level security
+ requirements against the various models that derive from PCIM,
+ consistent with PCLS.
+
+ In some real-world scenarios, the values associated with certain
+ properties, within certain instantiated object classes, may represent
+ information associated with scarce, and/or costly (and therefore
+ valuable) resources. It may be the case that these values must not
+ be disclosed to, or manipulated by, unauthorized parties.
+
+ Since this document forms the basis for the representation of a
+ policy data model in a specific format (an LDAP-accessible
+ directory), it is herein appropriate to reference the data
+ model-specific tools and mechanisms that are available for achieving
+ the authentication and authorization implicit in a requirement that
+ restricts read and/or read- write access to these values stored in a
+ directory.
+
+
+
+
+
+
+
+
+
+Strassner, et al. Standards Track [Page 52]
+
+RFC 3703 Policy Core LDAP Schema February 2004
+
+
+ General LDAP security considerations apply, as documented in RFC 3377
+ [2]. LDAP-specific authentication and authorization tools and
+ mechanisms are found in the following standards track documents,
+ which are appropriate for application to the management of security
+ applied to policy data models stored in an LDAP-accessible directory:
+
+ - RFC 2829 (Authentication Methods for LDAP)
+ - RFC 2830 (Lightweight Directory Access Protocol (v3): Extension
+ for Transport Layer Security)
+
+ Any identified security requirements that are not dealt with in the
+ appropriate discipline-specific information model documents, or in
+ this document, MUST be dealt with in the derivative data model
+ documents which are specific to each discipline.
+
+8. IANA Considerations
+
+ Refer to RFC 3383, "Internet Assigned Numbers Authority (IANA)
+ Considerations for the Lightweight Directory Access Protocol (LDAP)"
+ [16].
+
+8.1. Object Identifiers
+
+ The IANA has registered an LDAP Object Identifier for use in this
+ technical specification according to the following template:
+
+ Subject: Request for LDAP OID Registration
+ Person & email address to contact for further information:
+ Bob Moore (remoore at us.ibm.com)
+ Specification: RFC 3703
+ Author/Change Controller: IESG
+ Comments:
+ The assigned OID will be used as a base for identifying
+ a number of schema elements defined in this document.
+
+ IANA has assigned an OID of 1.3.6.1.1.6 with the name of pcimSchema
+ to this registration as recorded in the following registry:
+
+ http://www.iana.org/assignments/smi-numbers
+
+8.2. Object Identifier Descriptors
+
+ The IANA has registered the LDAP Descriptors used in this technical
+ specification as detailed in the following template:
+
+ Subject: Request for LDAP Descriptor Registration Update
+ Descriptor (short name): see comment
+ Object Identifier: see comment
+
+
+
+Strassner, et al. Standards Track [Page 53]
+
+RFC 3703 Policy Core LDAP Schema February 2004
+
+
+ Person & email address to contact for further information:
+ Bob Moore (remoore at us.ibm.com)
+ Usage: see comment
+ Specification: RFC 3703
+ Author/Change Controller: IESG
+ Comments:
+
+ The following descriptors have been added:
+
+ NAME Type OID
+ -------------- ---- ------------
+ pcimPolicy O 1.3.6.1.1.6.1.1
+ pcimGroup O 1.3.6.1.1.6.1.2
+ pcimGroupAuxClass O 1.3.6.1.1.6.1.3
+ pcimGroupInstance O 1.3.6.1.1.6.1.4
+ pcimRule O 1.3.6.1.1.6.1.5
+ pcimRuleAuxClass O 1.3.6.1.1.6.1.6
+ pcimRuleInstance O 1.3.6.1.1.6.1.7
+ pcimRuleConditionAssociation O 1.3.6.1.1.6.1.8
+ pcimRuleValidityAssociation O 1.3.6.1.1.6.1.9
+ pcimRuleActionAssociation O 1.3.6.1.1.6.1.10
+ pcimConditionAuxClass O 1.3.6.1.1.6.1.11
+ pcimTPCAuxClass O 1.3.6.1.1.6.1.12
+ pcimConditionVendorAuxClass O 1.3.6.1.1.6.1.13
+ pcimActionAuxClass O 1.3.6.1.1.6.1.14
+ pcimActionVendorAuxClass O 1.3.6.1.1.6.1.15
+ pcimPolicyInstance O 1.3.6.1.1.6.1.16
+ pcimElementAuxClass O 1.3.6.1.1.6.1.17
+ pcimRepository O 1.3.6.1.1.6.1.18
+ pcimRepositoryAuxClass O 1.3.6.1.1.6.1.19
+ pcimRepositoryInstance O 1.3.6.1.1.6.1.20
+ pcimSubtreesPtrAuxClass O 1.3.6.1.1.6.1.21
+ pcimGroupContainmentAuxClass O 1.3.6.1.1.6.1.22
+ pcimRuleContainmentAuxClass O 1.3.6.1.1.6.1.23
+ pcimKeywords A 1.3.6.1.1.6.2.3
+ pcimGroupName A 1.3.6.1.1.6.2.4
+ pcimRuleName A 1.3.6.1.1.6.2.5
+ pcimRuleEnabled A 1.3.6.1.1.6.2.6
+ pcimRuleConditionListType A 1.3.6.1.1.6.2.7
+ pcimRuleConditionList A 1.3.6.1.1.6.2.8
+ pcimRuleActionList A 1.3.6.1.1.6.2.9
+ pcimRuleValidityPeriodList A 1.3.6.1.1.6.2.10
+ pcimRuleUsage A 1.3.6.1.1.6.2.11
+ pcimRulePriority A 1.3.6.1.1.6.2.12
+ pcimRuleMandatory A 1.3.6.1.1.6.2.13
+ pcimRuleSequencedActions A 1.3.6.1.1.6.2.14
+ pcimRoles A 1.3.6.1.1.6.2.15
+ pcimConditionGroupNumber A 1.3.6.1.1.6.2.16
+
+
+
+Strassner, et al. Standards Track [Page 54]
+
+RFC 3703 Policy Core LDAP Schema February 2004
+
+
+ NAME Type OID
+ -------------- ---- ------------
+ pcimConditionNegated A 1.3.6.1.1.6.2.17
+ pcimConditionName A 1.3.6.1.1.6.2.18
+ pcimConditionDN A 1.3.6.1.1.6.2.19
+ pcimValidityConditionName A 1.3.6.1.1.6.2.20
+ pcimTimePeriodConditionDN A 1.3.6.1.1.6.2.21
+ pcimActionName A 1.3.6.1.1.6.2.22
+ pcimActionOrder A 1.3.6.1.1.6.2.23
+ pcimActionDN A 1.3.6.1.1.6.2.24
+ pcimTPCTime A 1.3.6.1.1.6.2.25
+ pcimTPCMonthOfYearMask A 1.3.6.1.1.6.2.26
+ pcimTPCDayOfMonthMask A 1.3.6.1.1.6.2.27
+ pcimTPCDayOfWeekMask A 1.3.6.1.1.6.2.28
+ pcimTPCTimeOfDayMask A 1.3.6.1.1.6.2.29
+ pcimTPCLocalOrUtcTime A 1.3.6.1.1.6.2.30
+ pcimVendorConstraintData A 1.3.6.1.1.6.2.31
+ pcimVendorConstraintEncoding A 1.3.6.1.1.6.2.32
+ pcimVendorActionData A 1.3.6.1.1.6.2.33
+ pcimVendorActionEncoding A 1.3.6.1.1.6.2.34
+ pcimPolicyInstanceName A 1.3.6.1.1.6.2.35
+ pcimRepositoryName A 1.3.6.1.1.6.2.36
+ pcimSubtreesAuxContainedSet A 1.3.6.1.1.6.2.37
+ pcimGroupsAuxContainedSet A 1.3.6.1.1.6.2.38
+ pcimRulesAuxContainedSet A 1.3.6.1.1.6.2.39
+
+ where Type A is Attribute, Type O is ObjectClass
+
+ These assignments are recorded in the following registry:
+
+ http://www.iana.org/assignments/ldap-parameters
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Strassner, et al. Standards Track [Page 55]
+
+RFC 3703 Policy Core LDAP Schema February 2004
+
+
+9. Acknowledgments
+
+ We would like to thank Kurt Zeilenga, Roland Hedburg, and Steven Legg
+ for doing a review of this document and making many helpful
+ suggestions and corrections.
+
+ Several of the policy classes in this model first appeared in early
+ IETF drafts on IPsec policy and QoS policy. The authors of these
+ drafts were Partha Bhattacharya, Rob Adams, William Dixon, Roy
+ Pereira, Raju Rajan, Jean-Christophe Martin, Sanjay Kamat, Michael
+ See, Rajiv Chaudhury, Dinesh Verma, George Powers, and Raj Yavatkar.
+
+ This document is closely aligned with the work being done in the
+ Distributed Management Task Force (DMTF) Policy and Networks working
+ groups. We would especially like to thank Lee Rafalow, Glenn Waters,
+ David Black, Michael Richardson, Mark Stevens, David Jones, Hugh
+ Mahon, Yoram Snir, and Yoram Ramberg for their helpful comments.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Strassner, et al. Standards Track [Page 56]
+
+RFC 3703 Policy Core LDAP Schema February 2004
+
+
+10. Appendix: Constructing the Value of orderedCIMKeys
+
+ This appendix is non-normative, and is included in this document as a
+ guide to implementers that wish to exchange information between CIM
+ schemata and LDAP schemata.
+
+ Within a CIM name space, the naming is basically flat; all instances
+ are identified by the values of their key properties, and each
+ combination of key values must be unique. A limited form of
+ hierarchical naming is available in CIM, however, by using weak
+ associations: since a weak association involves propagation of key
+ properties and their values from the superior object to the
+ subordinate one, the subordinate object can be thought of as being
+ named "under" the superior object. Once they have been propagated,
+ however, propagated key properties and their values function in
+ exactly the same way that native key properties and their values do
+ in identifying a CIM instance.
+
+ The CIM mapping document [6] introduces a special attribute,
+ orderedCIMKeys, to help map from the CIM_ManagedElement class to the
+ LDAP class dlm1ManagedElement. This attribute SHOULD only be used in
+ an environment where it is necessary to map between an
+ LDAP-accessible directory and a CIM repository. For an LDAP
+ environment, other LDAP naming attributes are defined (i.e., cn and a
+ class-specific naming attribute) that SHOULD be used instead.
+
+ The role of orderedCIMKeys is to represent the information necessary
+ to correlate an entry in an LDAP-accessible directory with an
+ instance in a CIM name space. Depending on how naming of CIM-related
+ entries is handled in an LDAP directory, the value of orderedCIMKeys
+ represents one of two things:
+
+ - If the DIT hierarchy does not mirror the "weakness hierarchy" of
+ the CIM name space, then orderedCIMKeys represents all the
+ keys of the CIM instance, both native and propagated.
+ - If the DIT hierarchy does mirror the "weakness hierarchy" of the
+ CIM name space, then orderedCIMKeys may represent either all the
+ keys of the instance, or only the native keys.
+
+ Regardless of which of these alternatives is taken, the syntax of
+ orderedCIMKeys is the same - a DirectoryString of the form
+
+ <className>.<key>=<value>[,<key>=<value>]*
+
+ where the <key>=<value> elements are ordered by the names of the key
+ properties, according to the collating sequence for US ASCII. The
+ only spaces allowed in the DirectoryString are those that fall within
+ a <value> element. As with alphabetizing the key properties, the
+
+
+
+Strassner, et al. Standards Track [Page 57]
+
+RFC 3703 Policy Core LDAP Schema February 2004
+
+
+ goal of suppressing the spaces is once again to make the results of
+ string operations predictable.
+
+ The values of the <value> elements are derived from the various CIM
+ syntaxes according to a grammar specified in [5].
+
+11. References
+
+11.1. Normative References
+
+ [1] Moore, B., Ellesson,E., Strassner, J. and A. Westerinen "Policy
+ Core Information Model -- Version 1 Specification", RFC 3060,
+ February 2001.
+
+ [2] Hodges, J. and R. Morgan, "Lightweight Directory Access
+ Protocol (v3): Technical Specification", RFC 3377, September
+ 2002.
+
+ [3] Wahl, M., Coulbeck, A., Howes,T. and S. Kille, "Lightweight
+ Directory Access Protocol (v3): Attribute Syntax Definitions",
+ RFC 2252, December 1997.
+
+ [4] The Directory: Models. ITU-T Recommendation X.501, 2001.
+
+ [5] Distributed Management Task Force, Inc., "Common Information
+ Model (CIM) Specification", Version 2.2, June 14, 1999. This
+ document is available on the following DMTF web page:
+ http://www.dmtf.org/standards/documents/CIM/DSP0004.pdf
+
+ [6] Distributed Management Task Force, Inc., "DMTF LDAP Schema for
+ the CIM v2.5 Core Information Model", April 15, 2002. This
+ document is available on the following DMTF web page:
+ http://www.dmtf.org/standards/documents/DEN/DSP0123.pdf
+
+ [7] Wahl, M., "A Summary of the X.500(96) User Schema for use with
+ LDAPv3", RFC 2256, December 1997.
+
+ [8] The Directory: Selected Attribute Types. ITU-T Recommendation
+ X.520, 2001.
+
+ [9] Zeilenga, K., Ed., "Lightweight Directory Access Protocol
+ (LDAP): Additional Matching Rules", RFC 3698, February 2004.
+
+ [10] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+ Levels", BCP 14, RFC 2119, March 1997.
+
+
+
+
+
+
+Strassner, et al. Standards Track [Page 58]
+
+RFC 3703 Policy Core LDAP Schema February 2004
+
+
+11.2. Informative References
+
+ [11] Hovey, R. and S. Bradner, "The Organizations Involved in the
+ IETF Standards Process", BCP 11, RFC 2028, October 1996.
+
+ [12] Strassner, J., policy architecture BOF presentation, 42nd IETF
+ Meeting, Chicago, Illinois, October 1998. Minutes of this BOF
+ are available at the following location:
+ http://www.ietf.org/proceedings/98aug/index.html.
+
+ [13] Yavatkar, R., Guerin, R. and D. Pendarakis, "A Framework for
+ Policy-based Admission Control", RFC 2753, January 2000.
+
+ [14] Wahl, M., Alvestrand, H., Hodges, J. and R. Morgan,
+ "Authentication Methods for LDAP", RFC 2829, May 2000
+
+ [15] Hodges, J., Morgan, R. and M. Wahl, "Lightweight Directory
+ Access Protocol (v3): Extension for Transport Layer Security",
+ RFC 2830, May 2000.
+
+ [16] Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
+ Considerations for the Lightweight Directory Access Protocol
+ (LDAP)", BCP 64, RFC 3383, September 2002.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Strassner, et al. Standards Track [Page 59]
+
+RFC 3703 Policy Core LDAP Schema February 2004
+
+
+12. Authors' Addresses
+
+ John Strassner
+ Intelliden Corporation
+ 90 South Cascade Avenue
+ Colorado Springs, CO 80903
+
+ Phone: +1.719.785.0648
+ Fax: +1.719.785.0644
+ EMail: john.strassner at intelliden.com
+
+
+ Bob Moore
+ IBM Corporation
+ P. O. Box 12195, BRQA/B501/G206
+ 3039 Cornwallis Rd.
+ Research Triangle Park, NC 27709-2195
+
+ Phone: +1 919-254-4436
+ Fax: +1 919-254-6243
+ EMail: remoore at us.ibm.com
+
+
+ Ryan Moats
+ Lemur Networks, Inc.
+ 15621 Drexel Circle
+ Omaha, NE 68135
+
+ Phone: +1-402-894-9456
+ EMail: rmoats at lemurnetworks.net
+
+
+ Ed Ellesson
+ 3026 Carriage Trail
+ Hillsborough, NC 27278
+
+ Phone: +1 919-644-3977
+ EMail: ellesson at mindspring.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+Strassner, et al. Standards Track [Page 60]
+
+RFC 3703 Policy Core LDAP Schema February 2004
+
+
+13. Full Copyright Statement
+
+ Copyright (C) The Internet Society (2004). This document is subject
+ to the rights, licenses and restrictions contained in BCP 78 and
+ except as set forth therein, the authors retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
+ REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
+ INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
+ IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
+ THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed
+ to pertain to the implementation or use of the technology
+ described in this document or the extent to which any license
+ under such rights might or might not be available; nor does it
+ represent that it has made any independent effort to identify any
+ such rights. Information on the procedures with respect to
+ rights in RFC documents can be found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use
+ of such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository
+ at http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention
+ any copyrights, patents or patent applications, or other
+ proprietary rights that may cover technology that may be required
+ to implement this standard. Please address the information to the
+ IETF at ietf-ipr at ietf.org.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+Strassner, et al. Standards Track [Page 61]
+
Added: openldap/vendor/openldap-release/doc/rfc/rfc3712.txt
===================================================================
--- openldap/vendor/openldap-release/doc/rfc/rfc3712.txt (rev 0)
+++ openldap/vendor/openldap-release/doc/rfc/rfc3712.txt 2007-09-15 10:38:52 UTC (rev 844)
@@ -0,0 +1,1851 @@
+
+
+
+
+
+
+Network Working Group P. Fleming
+Request for Comments: 3712 IBM
+Category: Informational I. McDonald
+ High North
+ February 2004
+
+
+ Lightweight Directory Access Protocol (LDAP):
+ Schema for Printer Services
+
+Status of this Memo
+
+ This memo provides information for the Internet community. It does
+ not specify an Internet standard of any kind. Distribution of this
+ memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2004). All Rights Reserved.
+
+Abstract
+
+ This document defines a schema, object classes and attributes, for
+ printers and printer services, for use with directories that support
+ Lightweight Directory Access Protocol v3 (LDAP-TS). This document is
+ based on the printer attributes listed in Appendix E of Internet
+ Printing Protocol/1.1 (IPP) (RFC 2911). A few additional printer
+ attributes are based on definitions in the Printer MIB (RFC 1759).
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 1.1. Rationale for using DirectoryString Syntax . . . . . . . 3
+ 1.2. Rationale for using caseIgnoreMatch. . . . . . . . . . . 4
+ 1.3. Rationale for using caseIgnoreSubstringsMatch. . . . . . 5
+ 2. Terminology and Conventions. . . . . . . . . . . . . . . . . . 5
+ 3. Definition of Object Classes . . . . . . . . . . . . . . . . . 6
+ 3.1. slpServicePrinter. . . . . . . . . . . . . . . . . . . . 6
+ 3.2. printerAbstract. . . . . . . . . . . . . . . . . . . . . 7
+ 3.3. printerService . . . . . . . . . . . . . . . . . . . . . 8
+ 3.4. printerServiceAuxClass . . . . . . . . . . . . . . . . . 8
+ 3.5. printerIPP . . . . . . . . . . . . . . . . . . . . . . . 8
+ 3.6. printerLPR . . . . . . . . . . . . . . . . . . . . . . . 9
+ 4. Definition of Attribute Types. . . . . . . . . . . . . . . . . 9
+ 4.1. printer-uri. . . . . . . . . . . . . . . . . . . . . . . 11
+ 4.2. printer-xri-supported. . . . . . . . . . . . . . . . . . 11
+ 4.3. printer-name . . . . . . . . . . . . . . . . . . . . . . 13
+ 4.4. printer-natural-language-configured. . . . . . . . . . . 13
+
+
+
+Fleming & McDonald Informational [Page 1]
+
+RFC 3712 LDAP Schema for Printer Services February 2004
+
+
+ 4.5. printer-location . . . . . . . . . . . . . . . . . . . . 14
+ 4.6. printer-info . . . . . . . . . . . . . . . . . . . . . . 14
+ 4.7. printer-more-info. . . . . . . . . . . . . . . . . . . . 14
+ 4.8. printer-make-and-model . . . . . . . . . . . . . . . . . 15
+ 4.9. printer-ipp-versions-supported . . . . . . . . . . . . . 15
+ 4.10. printer-multiple-document-jobs-supported . . . . . . . . 16
+ 4.11. printer-charset-configured . . . . . . . . . . . . . . . 16
+ 4.12. printer-charset-supported. . . . . . . . . . . . . . . . 16
+ 4.13. printer-generated-natural-language-supported . . . . . . 17
+ 4.14. printer-document-format-supported. . . . . . . . . . . . 17
+ 4.15. printer-color-supported. . . . . . . . . . . . . . . . . 18
+ 4.16. printer-compression-supported. . . . . . . . . . . . . . 18
+ 4.17. printer-pages-per-minute . . . . . . . . . . . . . . . . 18
+ 4.18. printer-pages-per-minute-color . . . . . . . . . . . . . 19
+ 4.19. printer-finishings-supported . . . . . . . . . . . . . . 19
+ 4.20. printer-number-up-supported. . . . . . . . . . . . . . . 19
+ 4.21. printer-sides-supported. . . . . . . . . . . . . . . . . 20
+ 4.22. printer-media-supported. . . . . . . . . . . . . . . . . 20
+ 4.23. printer-media-local-supported. . . . . . . . . . . . . . 20
+ 4.24. printer-resolution-supported . . . . . . . . . . . . . . 21
+ 4.25. printer-print-quality-supported. . . . . . . . . . . . . 22
+ 4.26. printer-job-priority-supported . . . . . . . . . . . . . 22
+ 4.27. printer-copies-supported . . . . . . . . . . . . . . . . 22
+ 4.28. printer-job-k-octets-supported . . . . . . . . . . . . . 23
+ 4.29. printer-current-operator . . . . . . . . . . . . . . . . 23
+ 4.30. printer-service-person . . . . . . . . . . . . . . . . . 24
+ 4.31. printer-delivery-orientation-supported . . . . . . . . . 24
+ 4.32. printer-stacking-order-supported . . . . . . . . . . . . 24
+ 4.33. printer-output-features-supported. . . . . . . . . . . . 25
+ 4.34. printer-aliases. . . . . . . . . . . . . . . . . . . . . 25
+ 5. Definition of Syntaxes . . . . . . . . . . . . . . . . . . . . 26
+ 6. Definition of Matching Rules . . . . . . . . . . . . . . . . . 26
+ 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
+ 7.1. Registration of Object Classes . . . . . . . . . . . . . 26
+ 7.2. Registration of Attribute Types. . . . . . . . . . . . . 27
+ 8. Internationalization Considerations. . . . . . . . . . . . . . 28
+ 9. Security Considerations. . . . . . . . . . . . . . . . . . . . 29
+ 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
+ 10.1. Normative References . . . . . . . . . . . . . . . . . . 29
+ 10.2. Informative References . . . . . . . . . . . . . . . . . 30
+ 11. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 32
+ 12. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 32
+ 13. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 33
+
+
+
+
+
+
+
+
+Fleming & McDonald Informational [Page 2]
+
+RFC 3712 LDAP Schema for Printer Services February 2004
+
+
+1. Introduction
+
+ This document defines several object classes to provide Lightweight
+ Directory Access Protocol v3 [LDAP-TS] applications with flexible
+ options in defining printer information using LDAP schema. Classes
+ are provided for defining directory entries with common printer
+ information as well as for extending existing directory entries with
+ SLPv2 [RFC2608], IPP/1.1 [RFC2911], and LPR [RFC1179] specific
+ information.
+
+ The schema defined in this document is based on the printer
+ attributes listed in Appendix E 'Generic Directory Schema' of
+ Internet Printing Protocol/1.1 (IPP) [RFC2911]. A few additional
+ printer attributes are based on definitions in the Printer MIB
+ [RFC1759].
+
+ The schema defined in this document is technically aligned with the
+ stable IANA-registered 'service:printer:' v2.0 template [SLP-PRT],
+ for compatibility with already deployed Service Location Protocol
+ (SLPv2) [RFC2608] service advertising and discovery infrastructure.
+ The attribute syntaxes are technically aligned with the
+ 'service:printer:' v2.0 template - therefore simpler types are
+ sometimes used (for example, 'DirectoryString' [RFC2252] rather than
+ 'labeledURI' [RFC2079] for the 'printer-uri' attribute).
+
+ Please send comments directly to the authors at the addresses listed
+ in Section 13 "Authors' Addresses".
+
+1.1. Rationale for using DirectoryString Syntax
+
+ The attribute syntax 'DirectoryString' (UTF-8 [RFC2279]) defined in
+ [RFC2252] is specified for several groups of string attributes that
+ are defined in this document:
+
+ 1) URI
+ - printer-uri, printer-xri-supported, printer-more-info
+
+ The UTF-8 encoding is forward compatible with any future
+ deployment of (UTF-8 based) IRI (Internationalized Resource
+ Identifiers) [W3C-IRI] currently being developed by the W3C
+ Internationalization Working Group.
+
+ 2) Description
+ - printer-name, printer-location, printer-info,
+ printer-make-and-model
+
+
+
+
+
+
+Fleming & McDonald Informational [Page 3]
+
+RFC 3712 LDAP Schema for Printer Services February 2004
+
+
+ The UTF-8 encoding supports descriptions in any language,
+ conformant with the "IETF Policy on Character Sets and Languages"
+ [RFC2277].
+
+ Note: The printer-natural-language-configured attribute contains
+ a language tag [RFC3066] for these description attributes (for
+ example, to support text-to-speech conversions).
+
+ 3) Keyword
+ - printer-compression-supported, printer-finishings-supported,
+ printer-media-supported, printer-media-local-supported,
+ printer-print-quality-supported
+
+ The UTF-8 encoding is compatible with the current IPP/1.1
+ [RFC2911] definition of the equivalent attributes, most of which
+ have the IPP/1.1 union syntax 'keyword or name'. The keyword
+ attributes defined in this document are extensible by
+ site-specific or vendor-specific 'names' which behave like new
+ 'keywords'
+
+ Note: In IPP/1.1, each value is strongly typed over-the-wire as
+ either 'keyword' or 'name'. This union selector is not preserved
+ in the definitions of these equivalent LDAP attributes.
+
+1.2. Rationale for using caseIgnoreMatch
+
+ The EQUALITY matching rule 'caseIgnoreMatch' defined in [RFC2252] is
+ specified for several groups of string attributes that are defined in
+ this document:
+
+ 1) URI
+
+ These URI attributes specify EQUALITY matching with
+ 'caseIgnoreMatch' (rather than with 'caseExactMatch') in order to
+ conform to the spirit of [RFC2396], which requires case
+ insensitive matching on the host part of a URI versus case
+ sensitive matching on the remainder of a URI.
+
+ These URI attributes follow existing practice of supporting case
+ insensitive equality matching for host names in the
+ associatedDomain attribute defined in [RFC1274].
+
+ Either equality matching rule choice would be a compromise:
+ a) case sensitive whole URI matching may lead to false negative
+ matches and has been shown to be fragile (given deployed client
+ applications that 'pretty up' host names displayed and
+ transferred in URI);
+
+
+
+
+Fleming & McDonald Informational [Page 4]
+
+RFC 3712 LDAP Schema for Printer Services February 2004
+
+
+ b) case insensitive whole URI matching may lead to false positive
+ matches, although it is a dangerous practice to publish URI that
+ differ only by case (for example, in the path elements).
+
+ 2) Description
+
+ Case insensitive equality matching is more user-friendly for
+ description attributes.
+
+ 3) Keyword
+
+ Case insensitive equality matching is more user-friendly for
+ keyword attributes.
+
+1.3. Rationale for using caseIgnoreSubstringsMatch
+
+ The SUBSTR matching rule 'caseIgnoreSubstringsMatch' defined in
+ [RFC2252] is specified for several groups of string attributes that
+ are defined in this document:
+
+ 1) URI
+
+ These URI attributes follow existing practice of supporting case
+ insensitive equality matching for host names in the
+ associatedDomain attribute defined in [RFC1274].
+
+ 2) Description
+
+ Support for case insensitive substring matching is more
+ user-friendly for description attributes.
+
+ 3) Keyword
+
+ Support for case insensitive substring matching is more
+ user-friendly for keyword attributes.
+
+2. Terminology and Conventions
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in BCP 14 [RFC2119].
+
+ Schema definitions are provided using LDAPv3 [LDAP-TS] description
+ formats. Definitions provided here are formatted (line wrapped) for
+ readability.
+
+
+
+
+
+
+Fleming & McDonald Informational [Page 5]
+
+RFC 3712 LDAP Schema for Printer Services February 2004
+
+
+3. Definition of Object Classes
+
+ We define the following LDAP object classes for use with both generic
+ printer related information and services specific to SLPv2 [RFC2608],
+ IPP/1.1 [RFC2911], and LPR [RFC1179].
+
+ slpServicePrinter - auxiliary class for SLP registered printers
+ printerAbstract - abstract class for all printer classes
+ printerService - structural class for printers
+ printerServiceAuxClass - auxiliary class for printers
+ printerIPP - auxiliary class for IPP printers
+ printerLPR - auxiliary class for LPR printers
+
+ The following are some examples of how applications may choose to use
+ these classes when creating directory entries:
+
+ 1) Use printerService for directory entries containing common
+ printer information.
+
+ 2) Use both printerService and slpServicePrinter for directory
+ entries containing common printer information for SLP registered
+ printers.
+
+ 3) Use printerService, printerLPR and printerIPP for directory
+ entries containing common printer information for printers that
+ support both LPR and IPP.
+
+ 4) Use printerServiceAuxClass and object classes not defined by this
+ document for directory entries containing common printer
+ information. In this example, printerServiceAuxClass is used for
+ extending other structural classes defining printer information
+ with common printer information defined in this document.
+
+ Refer to Section 4 for definition of attribute types referenced by
+ these object classes. We use attribute names instead of OIDs in
+ object class definitions for clarity. Some attribute names described
+ in [RFC2911] have been prefixed with 'printer-' as recommended in
+ [RFC2926] and [SLP-PRT].
+
+3.1. slpServicePrinter
+
+ ( 1.3.18.0.2.6.254
+ NAME 'slpServicePrinter'
+ DESC 'Service Location Protocol (SLP) information.'
+ AUXILIARY
+ SUP slpService
+ )
+
+
+
+
+Fleming & McDonald Informational [Page 6]
+
+RFC 3712 LDAP Schema for Printer Services February 2004
+
+
+ This auxiliary class defines Service Location Protocol (SLPv2)
+ [RFC2608] specific information. It should be used with a structural
+ class such as printerService. It may be used to create new or extend
+ existing directory entries with SLP 'service:printer' abstract
+ service type information as defined in [SLP-PRT]. This object class
+ is derived from 'slpService', the parent class for all SLP services,
+ defined in [RFC2926].
+
+3.2. printerAbstract
+
+ ( 1.3.18.0.2.6.258
+ NAME 'printerAbstract'
+ DESC 'Printer related information.'
+ ABSTRACT
+ SUP top
+ MAY ( printer-name $
+ printer-natural-language-configured $
+ printer-location $ printer-info $ printer-more-info $
+ printer-make-and-model $
+ printer-multiple-document-jobs-supported $
+ printer-charset-configured $ printer-charset-supported $
+ printer-generated-natural-language-supported $
+ printer-document-format-supported $ printer-color-supported $
+ printer-compression-supported $ printer-pages-per-minute $
+ printer-pages-per-minute-color $
+ printer-finishings-supported $ printer-number-up-supported $
+ printer-sides-supported $ printer-media-supported $
+ printer-media-local-supported $
+ printer-resolution-supported $
+ printer-print-quality-supported $
+ printer-job-priority-supported $ printer-copies-supported $
+ printer-job-k-octets-supported $ printer-current-operator $
+ printer-service-person $
+ printer-delivery-orientation-supported $
+ printer-stacking-order-supported $
+ printer-output-features-supported )
+ )
+
+ This abstract class defines printer information. It is a base class
+ for deriving other printer related classes, such as, but not limited
+ to, classes defined in this document. It defines a common set of
+ printer attributes that are not specific to any one type of service,
+ protocol or operating system.
+
+
+
+
+
+
+
+
+Fleming & McDonald Informational [Page 7]
+
+RFC 3712 LDAP Schema for Printer Services February 2004
+
+
+3.3. printerService
+
+ ( 1.3.18.0.2.6.255
+ NAME 'printerService'
+ DESC 'Printer information.'
+ STRUCTURAL
+ SUP printerAbstract
+ MAY ( printer-uri $ printer-xri-supported )
+ )
+
+ This structural class defines printer information. It is derived
+ from class printerAbstract and thus inherits common printer
+ attributes. This class can be used with or without auxiliary classes
+ to define printer information. Auxiliary classes can be used to
+ extend the common printer information with protocol, service or
+ operating system specific information.
+
+ Note: When extending other structural classes with auxiliary
+ classes, printerService should not be used.
+
+3.4. printerServiceAuxClass
+
+ ( 1.3.18.0.2.6.257
+ NAME 'printerServiceAuxClass'
+ DESC 'Printer information.'
+ AUXILIARY
+ SUP printerAbstract
+ MAY ( printer-uri $ printer-xri-supported )
+ )
+
+ This auxiliary class defines printer information. It is derived from
+ class printerAbstract and thus inherits common printer attributes.
+ This class should be used with a structural class.
+
+3.5. printerIPP
+
+ ( 1.3.18.0.2.6.256
+ NAME 'printerIPP'
+ DESC 'Internet Printing Protocol (IPP) information.'
+ AUXILIARY
+ SUP top
+ MAY ( printer-ipp-versions-supported $
+ printer-multiple-document-jobs-supported )
+ )
+
+
+
+
+
+
+
+Fleming & McDonald Informational [Page 8]
+
+RFC 3712 LDAP Schema for Printer Services February 2004
+
+
+ This auxiliary class defines Internet Printing Protocol (IPP/1.1)
+ [RFC2911] information. It should be used with a structural class
+ such as printerService. It is used to extend structural classes with
+ IPP specific printer information.
+
+3.6. printerLPR
+
+ ( 1.3.18.0.2.6.253
+ NAME 'printerLPR'
+ DESC 'LPR information.'
+ AUXILIARY
+ SUP top
+ MUST ( printer-name )
+ MAY ( printer-aliases)
+ )
+
+ This auxiliary class defines LPR [RFC1179] information. It should be
+ used with a structural class such as printerService. It is used to
+ identify directory entries that support LPR.
+
+4. Definition of Attribute Types
+
+ The following attribute types are referenced by the object classes
+ defined in Section 3.
+
+ The following attribute types reference syntax OIDs defined in
+ Section 6 of [RFC2252] (see Section 5 'Definition of Syntaxes'
+ below).
+
+ The following attribute types reference matching rule names (instead
+ of OIDs) for clarity (see Section 6 below). For optional attributes,
+ if the printer information is not known, the attribute value should
+ not be set. In the following definitions, referenced matching rules
+ are defined in Section 8 of [RFC2252] and/or Section 2 of [RFC3698]
+ (see Section 6 'Definition of Matching Rules' below).
+
+ The following table is a summary of the attribute names defined by
+ this document and their corresponding names from [RFC2911]. Some
+ attribute names described in [RFC2911] have been prefixed with
+ 'printer-' as recommended in [RFC2926], to address the flat namespace
+ for LDAP identifiers.
+
+
+
+
+
+
+
+
+
+
+Fleming & McDonald Informational [Page 9]
+
+RFC 3712 LDAP Schema for Printer Services February 2004
+
+
+ LDAP & SLP Printer Schema IPP Model [RFC2911]
+ ------------------------------ -------------------------------------
+ printer-uri
+ printer-xri-supported
+ [IPP printer-uri-supported]
+ [IPP uri-authentication-supported]
+ [IPP uri-security-supported]
+ printer-name printer-name
+ printer-natural-language-configured
+ natural-language-configured
+ printer-location printer-location
+ printer-info printer-info
+ printer-more-info printer-more-info
+ printer-make-and-model printer-make-and-model
+ printer-ipp-versions-supported ipp-versions-supported
+ printer-multiple-document-jobs-supported
+ multiple-document-jobs-supported
+ printer-charset-configured charset-configured
+ printer-charset-supported charset-supported
+ printer-generated-natural-language-supported
+ generated-natural-language-supported
+ printer-document-format-supported
+ document-format-supported
+ printer-color-supported color-supported
+ printer-compression-supported compression-supported
+ printer-pages-per-minute pages-per-minute
+ printer-pages-per-minute-color pages-per-minute-color
+ printer-finishings-supported finishings-supported
+ printer-number-up-supported number-up-supported
+ printer-sides-supported sides-supported
+ printer-media-supported media-supported
+ printer-media-local-supported [site names from IPP media-supported]
+ printer-resolution-supported printer-resolution-supported
+ printer-print-quality-supported print-quality-supported
+ printer-job-priority-supported job-priority-supported
+ printer-copies-supported copies-supported
+ printer-job-k-octets-supported job-k-octets-supported
+ printer-current-operator
+ printer-service-person
+ printer-delivery-orientation-supported
+ printer-stacking-order-supported
+ printer-output-features-supported
+ printer-aliases
+
+
+
+
+
+
+
+
+Fleming & McDonald Informational [Page 10]
+
+RFC 3712 LDAP Schema for Printer Services February 2004
+
+
+4.1. printer-uri
+
+ ( 1.3.18.0.2.4.1140
+ NAME 'printer-uri'
+ DESC 'A URI supported by this printer.'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ SINGLE-VALUE
+ )
+
+ If the printer-xri-supported LDAP attribute is implemented, then this
+ printer-uri value should be listed in printer-xri-supported.
+
+ Values of URI should conform to [RFC2396], although URI schemes may
+ be defined which do not conform to [RFC2396] (see [RFC2717] and
+ [RFC2718]).
+
+ Note: LDAP application clients should not attempt to use malformed
+ URI values read from this attribute. LDAP administrative clients
+ should not write malformed URI values into this attribute.
+
+ Note: For SLP registered printers, the LDAP printer-uri attribute
+ should be set to the value of the SLP-registered URL of the printer,
+ for interworking with SLPv2 [RFC2608] service discovery.
+
+ Note: See Sections 1.1, 1.2, and 1.3 for rationale for design
+ choices.
+
+4.2. printer-xri-supported
+
+ ( 1.3.18.0.2.4.1107
+ NAME 'printer-xri-supported'
+ DESC 'The unordered list of XRI (extended resource identifiers)
+ supported by this printer.'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ )
+
+ A list of XRI (extended resource identifiers) supported by this
+ printer. Each value of this list should consist of a URI (uniform
+ resource identifier) followed by (optional) authentication and
+ security fields.
+
+ Values of URI should conform to [RFC2396], although URI schemes may
+ be defined which do not conform to [RFC2396] (see [RFC2717] and
+ [RFC2718]).
+
+
+
+Fleming & McDonald Informational [Page 11]
+
+RFC 3712 LDAP Schema for Printer Services February 2004
+
+
+ Note: LDAP application clients should not attempt to use malformed
+ URI values read from this attribute. LDAP administrative clients
+ should not write malformed URI values into this attribute.
+
+ Note: This attribute is based on 'printer-uri-supported', 'uri-
+ authentication-supported', and `'uri-security-supported' (called the
+ 'Three Musketeers' because they are parallel ordered attributes)
+ defined in IPP/1.1 [RFC2911]. This attribute unfolds those IPP/1.1
+ attributes and thus avoids the ordering (and same number of values)
+ constraints of the IPP/1.1 separate attributes.
+
+ Defined keywords for fields include:
+
+ 'uri' (IPP 'printer-uri-supported')
+ 'auth' (IPP 'uri-authentication-supported')
+ 'sec' (IPP 'uri-security-supported')
+
+ A missing 'auth' field should be interpreted to mean 'none'. Per
+ IPP/1.1 [RFC2911], defined values of the 'auth' field include:
+
+ 'none' (no authentication for this URI)
+ 'requesting-user-name' (from operation request)
+ 'basic' (HTTP/1.1 Basic [RFC2617])
+ 'digest' (HTTP/1.1 Basic, [RFC2617])
+ 'certificate' (from certificate)
+
+ A missing 'sec' field should be interpreted to mean 'none'. Per
+ IPP/1.1 [RFC2911], defined values of the 'sec' field include:
+
+ 'none' (no security for this URI)
+ 'ssl3' (Netscape SSL3)
+ 'tls' (IETF TLS/1.0, [RFC2246])
+
+ Each XRI field should be delimited by '<'. For example:
+
+ 'uri=ipp://foo.com< auth=digest< sec=tls<'
+ 'uri=lpr://bar.com< auth=none< sec=none<'
+ 'uri=mailto:printer at foobar.com< auth=none< sec=none<'
+
+ Note: The syntax and delimiter for this attribute are aligned with
+ the equivalent attribute in the 'service:printer:' v2.0 template
+ [SLP-PRT]. Whitespace is permitted after (but not before) the
+ delimiter '<'. Note that this delimiter differs from printer-
+ resolution-supported.
+
+ Note: See Sections 1.1, 1.2, and 1.3 for rationale for design
+ choices.
+
+
+
+
+Fleming & McDonald Informational [Page 12]
+
+RFC 3712 LDAP Schema for Printer Services February 2004
+
+
+4.3. printer-name
+
+ ( 1.3.18.0.2.4.1135
+ NAME 'printer-name'
+ DESC 'The site-specific administrative name of this printer.'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{127}
+ SINGLE-VALUE
+ )
+
+ Values of this attribute should be specified in the language
+ specified in printer-natural-language-configured (for example, to
+ support text-to-speech conversions), although the printer's name may
+ be specified in any language. This name may be the last part of the
+ printer's URI or it may be completely unrelated. This name may
+ contain characters that are not allowed in a conventional URI (see
+ [RFC2396]).
+
+4.4. printer-natural-language-configured
+
+ ( 1.3.18.0.2.4.1119
+ NAME 'printer-natural-language-configured'
+ DESC 'The configured natural language in which error and status
+ messages will be generated (by default) by this printer.'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{127}
+ SINGLE-VALUE
+ )
+
+ Also, a possible natural language for printer string attributes set
+ by operator, system administrator, or manufacturer. Also, the
+ (declared) natural language of the printer-name, printer-location,
+ printer-info, and printer-make-and-model attributes of this printer.
+
+ Values of language tags should conform to "Tags for the
+ Identification of Languages" [RFC3066]. For example:
+
+ 'en-us' (English as spoken in the US)
+ 'fr-fr' (French as spoken in France)
+
+ For consistency with IPP/1.1 [RFC2911], language tags in this
+ attribute should be lowercase normalized.
+
+
+
+
+
+
+
+Fleming & McDonald Informational [Page 13]
+
+RFC 3712 LDAP Schema for Printer Services February 2004
+
+
+4.5. printer-location
+
+ ( 1.3.18.0.2.4.1136
+ NAME 'printer-location'
+ DESC 'The physical location of this printer.'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{127}
+ SINGLE-VALUE
+ )
+
+ For example:
+
+ 'Room 123A'
+ 'Second floor of building XYZ'
+
+4.6. printer-info
+
+ ( 1.3.18.0.2.4.1139
+ NAME 'printer-info'
+ DESC 'Descriptive information about this printer.'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{127}
+ SINGLE-VALUE
+ )
+
+ For example:
+
+ 'This printer can be used for printing color transparencies for
+ HR presentations'
+ 'Out of courtesy for others, please print only small (1-5 page)
+ jobs at this printer'
+ 'This printer is going away on July 1, 1997, please find a new
+ printer'
+
+4.7. printer-more-info
+
+ ( 1.3.18.0.2.4.1134
+ NAME 'printer-more-info'
+ DESC 'A URI for more information about this specific printer.'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ SINGLE-VALUE
+ )
+
+
+
+
+
+Fleming & McDonald Informational [Page 14]
+
+RFC 3712 LDAP Schema for Printer Services February 2004
+
+
+ For example, this could be an HTTP type URI referencing an HTML page
+ accessible to a Web Browser. The information obtained from this URI
+ is intended for end user consumption.
+
+ Values of URI should conform to [RFC2396], although URI schemes may
+ be defined which do not conform to [RFC2396] (see [RFC2717] and
+ [RFC2718]).
+
+ Note: LDAP application clients should not attempt to use malformed
+ URI values read from this attribute. LDAP administrative clients
+ should not write malformed URI values into this attribute.
+
+ Note: See Sections 1.1, 1.2, and 1.3 for rationale for design
+ choices.
+
+4.8. printer-make-and-model
+
+ ( 1.3.18.0.2.4.1138
+ NAME 'printer-make-and-model'
+ DESC 'Make and model of this printer.'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{127}
+ SINGLE-VALUE
+ )
+
+ Note: The printer manufacturer may initially populate this
+ attribute.
+
+4.9. printer-ipp-versions-supported
+
+ ( 1.3.18.0.2.4.1133
+ NAME 'printer-ipp-versions-supported'
+ DESC 'IPP protocol version(s) that this printer supports.'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{127}
+ )
+
+ The IPP protocol version(s) should include major and minor versions,
+ i.e., the exact version numbers for which this Printer implementation
+ meets the IPP version-specific conformance requirements.
+
+
+
+
+
+
+
+
+
+Fleming & McDonald Informational [Page 15]
+
+RFC 3712 LDAP Schema for Printer Services February 2004
+
+
+4.10. printer-multiple-document-jobs-supported
+
+ ( 1.3.18.0.2.4.1132
+ NAME 'printer-multiple-document-jobs-supported'
+ DESC 'Indicates whether or not this printer supports more than one
+ document per job.'
+ EQUALITY booleanMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
+ SINGLE-VALUE
+ )
+
+4.11. printer-charset-configured
+
+ ( 1.3.18.0.2.4.1109
+ NAME 'printer-charset-configured'
+ DESC 'The configured charset in which error and status messages will
+ be generated (by default) by this printer.'
+ EQUALITY caseIgnoreMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{63}
+ SINGLE-VALUE
+ )
+
+ Also, a possible charset for printer string attributes set by
+ operator, system administrator, or manufacturer. For example:
+
+ 'utf-8' (ISO 10646/Unicode in UTF-8 transform [RFC2279])
+ 'iso-8859-1' (Latin1)
+
+ Values of charset tags should be defined in the IANA Registry of
+ Coded Character Sets [IANA-CHAR] (see also [RFC2978]) and the
+ '(preferred MIME name)' should be used as the charset tag in this
+ attribute.
+
+ For consistency with IPP/1.1 [RFC2911], charset tags in this
+ attribute should be lowercase normalized.
+
+4.12. printer-charset-supported
+
+ ( 1.3.18.0.2.4.1131
+ NAME 'printer-charset-supported'
+ DESC 'Set of charsets supported for the attribute values of syntax
+ DirectoryString for this directory entry.'
+ EQUALITY caseIgnoreMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{63}
+ )
+
+
+
+
+
+
+Fleming & McDonald Informational [Page 16]
+
+RFC 3712 LDAP Schema for Printer Services February 2004
+
+
+ For example:
+
+ 'utf-8' (ISO 10646/Unicode in UTF-8 transform [RFC2279])
+ 'iso-8859-1' (Latin1)
+
+ Values of charset tags should be defined in the IANA Registry of
+ Coded Character Sets [IANA-CHAR] (see also [RFC2978]) and the
+ '(preferred MIME name)' should be used as the charset tag in this
+ attribute.
+
+ For consistency with IPP/1.1 [RFC2911], charset tags in this
+ attribute should be lowercase normalized.
+
+4.13. printer-generated-natural-language-supported
+
+ ( 1.3.18.0.2.4.1137
+ NAME 'printer-generated-natural-language-supported'
+ DESC 'Natural language(s) supported for this directory entry.'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{63}
+ )
+
+ Values of language tags should conform to "Tags for the
+ Identification of Languages" [RFC3066]. For example:
+
+ 'en-us' (English as spoken in the US)
+ 'fr-fr' (French as spoken in France)
+
+ For consistency with IPP/1.1 [RFC2911], language tags in this
+ attribute should be lowercase normalized.
+
+4.14. printer-document-format-supported
+
+ ( 1.3.18.0.2.4.1130
+ NAME 'printer-document-format-supported'
+ DESC 'The possible source document formats which may be interpreted
+ and printed by this printer.'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{127}
+ )
+
+ Values of document formats should be MIME media types defined in the
+ IANA Registry of MIME Media Types [IANA-MIME] (see also [RFC2048]).
+
+
+
+
+
+
+Fleming & McDonald Informational [Page 17]
+
+RFC 3712 LDAP Schema for Printer Services February 2004
+
+
+4.15. printer-color-supported
+
+ ( 1.3.18.0.2.4.1129
+ NAME 'printer-color-supported'
+ DESC 'Indicates whether this printer is capable of any type of color
+ printing at all, including highlight color.'
+ EQUALITY booleanMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
+ SINGLE-VALUE
+ )
+
+4.16. printer-compression-supported
+
+ ( 1.3.18.0.2.4.1128
+ NAME 'printer-compression-supported'
+ DESC 'Compression algorithms supported by this printer.'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{255}
+ )
+
+ Values defined in IPP/1.1 [RFC2911] include:
+
+ 'none' (no compression is used)
+ 'deflate' (public domain ZIP described in [RFC1951])
+ 'gzip' (GNU ZIP described in [RFC1952])
+ 'compress' (UNIX compression described in [RFC1977])
+
+4.17. printer-pages-per-minute
+
+ ( 1.3.18.0.2.4.1127
+ NAME 'printer-pages-per-minute'
+ DESC 'The nominal number of pages per minute which may be output by
+ this printer.'
+ EQUALITY integerMatch
+ ORDERING integerOrderingMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
+ SINGLE-VALUE
+ )
+
+ This attribute is informative, not a service guarantee. Typically,
+ it is the value used in marketing literature to describe this
+ printer. For example, the value for a simplex or black-and-white
+ print mode.
+
+
+
+
+
+
+
+Fleming & McDonald Informational [Page 18]
+
+RFC 3712 LDAP Schema for Printer Services February 2004
+
+
+4.18. printer-pages-per-minute-color
+
+ ( 1.3.18.0.2.4.1126
+ NAME 'printer-pages-per-minute-color'
+ DESC 'The nominal number of color pages per minute which may be
+ output by this printer.'
+ EQUALITY integerMatch
+ ORDERING integerOrderingMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
+ SINGLE-VALUE
+ )
+
+ This attribute is informative, not a service guarantee. Typically,
+ it is the value used in marketing literature to describe this
+ printer.
+
+
+4.19. printer-finishings-supported
+
+ ( 1.3.18.0.2.4.1125
+ NAME 'printer-finishings-supported'
+ DESC 'The possible finishing operations supported by this printer.'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{255}
+ )
+
+ Values defined in IPP/1.1 [RFC2911] include: 'none', 'staple',
+ 'punch', 'cover', 'bind', 'saddle-stitch', 'edge-stitch',
+ 'staple-top-left', 'staple-bottom-left', 'staple-top-right',
+ 'staple-bottom-right', 'edge-stitch-left', 'edge-stitch-top',
+ 'edge-stitch-right', 'edge-stitch-bottom', 'staple-dual-left',
+ 'staple-dual-top', 'staple-dual-right', 'staple-dual-bottom'.
+
+ Note: Implementations may support other values.
+
+4.20. printer-number-up-supported
+
+ ( 1.3.18.0.2.4.1124
+ NAME 'printer-number-up-supported'
+ DESC 'The possible numbers of print-stream pages to impose upon a
+ single side of an instance of a selected medium.'
+ EQUALITY integerMatch
+ ORDERING integerOrderingMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
+ )
+
+
+
+
+
+Fleming & McDonald Informational [Page 19]
+
+RFC 3712 LDAP Schema for Printer Services February 2004
+
+
+ Values defined in IPP/1.1 [RFC2911] include: '1', '2', and '4'.
+
+ Note: Implementations may support other values.
+
+4.21. printer-sides-supported
+
+ ( 1.3.18.0.2.4.1123
+ NAME 'printer-sides-supported'
+ DESC 'The number of impression sides (one or two) and the two-sided
+ impression rotations supported by this printer.'
+ EQUALITY caseIgnoreMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{127}
+ )
+
+ Values defined in IPP/1.1 [RFC2911] include: 'one-sided', 'two-
+ sided-long-edge', 'two-sided-short-edge'.'
+
+4.22. printer-media-supported
+
+ ( 1.3.18.0.2.4.1122
+ NAME 'printer-media-supported'
+ DESC 'The standard names/types/sizes (and optional color suffixes) of
+ the media supported by this printer.'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{255}
+ )
+
+ Values are defined in IPP/1.1 [RFC2911] or any IANA registered
+ extensions. For example:
+
+ 'iso-a4'
+ 'envelope'
+ 'na-letter-white'
+
+4.23. printer-media-local-supported
+
+ ( 1.3.18.0.2.4.1117
+ NAME 'printer-media-local-supported'
+ DESC 'Site-specific names of media supported by this printer.'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{255}
+ )
+
+ Values should be in the natural language specified by printer-
+ natural-language-configured.
+
+
+
+
+Fleming & McDonald Informational [Page 20]
+
+RFC 3712 LDAP Schema for Printer Services February 2004
+
+
+ For example:
+
+ 'purchasing-form' (site-specific name)
+
+ as opposed to 'na-letter' (standard keyword from IPP/1.1 [RFC2911])
+ in the printer-media-supported attribute.
+
+4.24. printer-resolution-supported
+
+ ( 1.3.18.0.2.4.1121
+ NAME 'printer-resolution-supported'
+ DESC 'List of resolutions supported for printing documents by this
+ printer.'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{255}
+ )
+
+ Each resolution value should be a string containing 3 fields:
+ 1) Cross feed direction resolution (positive integer);
+ 2) Feed direction resolution (positive integer);
+ 3) Unit - 'dpi' (dots per inch) or 'dpcm' (dots per centimeter).
+
+ Each resolution field should be delimited by '>'. For example:
+
+ '300> 300> dpi>'
+ '600> 600> dpi>'
+
+ Note: This attribute is based on 'printer-resolution-supported'
+ defined in IPP/1.1 [RFC2911] (which has a binary complex encoding)
+ derived from 'prtMarkerAddressabilityFeedDir',
+ 'prtMarkerAddressabilityXFeedDir', and 'prtMarkerAddressabilityUnit'
+ defined in the Printer MIB [RFC1759] (which have integer encodings).
+
+ Note: The syntax and delimiter for this attribute are aligned with
+ the equivalent attribute in the 'service:printer:' v2.0 template
+ [SLP-PRT]. Whitespace is permitted after (but not before) the
+ delimiter '>'. Note that this delimiter differs from printer-xri-
+ supported.
+
+
+
+
+
+
+
+
+
+
+
+
+Fleming & McDonald Informational [Page 21]
+
+RFC 3712 LDAP Schema for Printer Services February 2004
+
+
+4.25. printer-print-quality-supported
+
+ ( 1.3.18.0.2.4.1120
+ NAME 'printer-print-quality-supported'
+ DESC 'List of print qualities supported for printing documents on
+ this printer.'
+ EQUALITY caseIgnoreMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{127}
+ )
+
+ Values defined in IPP/1.1 [RFC2911] include:
+
+ 'unknown'
+ 'draft'
+ 'normal'
+ 'high'
+
+4.26. printer-job-priority-supported
+
+ ( 1.3.18.0.2.4.1110
+ NAME 'printer-job-priority-supported'
+ DESC 'Indicates the number of job priority levels supported by this
+ printer.'
+ EQUALITY integerMatch
+ ORDERING integerOrderingMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
+ SINGLE-VALUE
+ )
+
+ An IPP/1.1 [RFC2911] conformant Printer, which supports job priority,
+ always supports a full range of priorities from '1' to '100' (to
+ ensure consistent behavior), therefore this attribute describes the
+ 'granularity' of priority supported. Values of this attribute are
+ from '1' to '100'.
+
+4.27. printer-copies-supported
+
+ ( 1.3.18.0.2.4.1118
+ NAME 'printer-copies-supported'
+ DESC 'The maximum number of copies of a document that may be printed
+ as a single job on this printer.'
+ EQUALITY integerMatch
+ ORDERING integerOrderingMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
+ SINGLE-VALUE
+ )
+
+
+
+
+
+Fleming & McDonald Informational [Page 22]
+
+RFC 3712 LDAP Schema for Printer Services February 2004
+
+
+ A positive value indicates the maximum supported copies. A value of
+ '0' indicates no maximum limit. A value of '-1' indicates 'unknown'.
+
+ Note: The syntax and values for this attribute are aligned with the
+ equivalent attribute in the 'service:printer:' v2.0 template [SLP-
+ PRT].
+
+4.28. printer-job-k-octets-supported
+
+ ( 1.3.18.0.2.4.1111
+ NAME 'printer-job-k-octets-supported'
+ DESC 'The maximum size in kilobytes (1,024 octets actually) incoming
+ print job that this printer will accept.'
+ EQUALITY integerMatch
+ ORDERING integerOrderingMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
+ SINGLE-VALUE
+ )
+
+ A positive value indicates the maximum supported job size. A value
+ of '0' indicates no maximum limit. A value of '-1' indicates
+ 'unknown'.
+
+ Note: The syntax and values for this attribute are aligned with the
+ equivalent attribute in the 'service:printer:' v2.0 template [SLP-
+ PRT].
+
+4.29. printer-current-operator
+
+ ( 1.3.18.0.2.4.1112
+ NAME 'printer-current-operator'
+ DESC 'The identity of the current human operator responsible for
+ operating this printer.'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{127}
+ SINGLE-VALUE
+ )
+
+ The value of this attribute should include information that would
+ enable other humans to reach the operator, such as a telephone
+ number.
+
+
+
+
+
+
+
+
+
+Fleming & McDonald Informational [Page 23]
+
+RFC 3712 LDAP Schema for Printer Services February 2004
+
+
+4.30. printer-service-person
+
+ ( 1.3.18.0.2.4.1113
+ NAME 'printer-service-person'
+ DESC 'The identity of the current human service person responsible
+ for servicing this printer.'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{127}
+ SINGLE-VALUE
+ )
+
+ The value of this attribute should include information that would
+ enable other humans to reach the service person, such as a telephone
+ number.
+
+4.31. printer-delivery-orientation-supported
+
+ ( 1.3.18.0.2.4.1114
+ NAME 'printer-delivery-orientation-supported'
+ DESC 'The possible delivery orientations of pages as they are printed
+ and ejected from this printer.'
+ EQUALITY caseIgnoreMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{127}
+ )
+
+ Values defined include:
+
+ 'unknown'
+ 'face-up'
+ 'face-down'
+
+ Note: The syntax and values for this attribute are aligned with the
+ equivalent attribute in the 'service:printer:' v2.0 template [SLP-
+ PRT].
+
+4.32. printer-stacking-order-supported
+
+ ( 1.3.18.0.2.4.1115
+ NAME 'printer-stacking-order-supported'
+ DESC 'The possible stacking order of pages as they are printed and
+ ejected from this printer.'
+ EQUALITY caseIgnoreMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{127}
+ )
+
+
+
+
+
+
+Fleming & McDonald Informational [Page 24]
+
+RFC 3712 LDAP Schema for Printer Services February 2004
+
+
+ Values defined include:
+
+ 'unknown'
+ 'first-to-last'
+ 'last-to-first'
+
+ Note: The syntax and values for this attribute are aligned with the
+ equivalent attribute in the 'service:printer:' v2.0 template [SLP-
+ PRT].
+
+4.33. printer-output-features-supported
+
+ ( 1.3.18.0.2.4.1116
+ NAME 'printer-output-features-supported'
+ DESC 'The possible output features supported by this printer.'
+ EQUALITY caseIgnoreMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{127}
+ )
+
+ Values defined include:
+
+ 'unknown'
+ 'bursting'
+ 'decollating'
+ 'page-collating'
+ 'offset-stacking'
+
+ Note: The syntax and values for this attribute are aligned with the
+ equivalent attribute in the 'service:printer:' v2.0 template [SLP-
+ PRT].
+
+ Note: Implementations may support other values.
+
+4.34. printer-aliases
+
+ ( 1.3.18.0.2.4.1108
+ NAME 'printer-aliases'
+ DESC 'List of site-specific administrative names of this printer in
+ addition to the value specified for printer-name.'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{127}
+ )
+
+ Values of this attribute should be specified in the language
+ specified in printer-natural-language-configured (for example, to
+ support text-to-speech conversions), although the printer's alias may
+ be specified in any language.
+
+
+
+Fleming & McDonald Informational [Page 25]
+
+RFC 3712 LDAP Schema for Printer Services February 2004
+
+
+5. Definition of Syntaxes
+
+ No new attribute syntaxes are defined by this document.
+
+ The attribute types defined in Section 4 of this document reference
+ syntax OIDs defined in Section 6 of [RFC2252], which are summarized
+ below:
+
+ Syntax OID Syntax Description
+ ------------------------------ ------------------
+ 1.3.6.1.4.1.1466.115.121.1.7 Boolean
+ 1.3.6.1.4.1.1466.115.121.1.15 DirectoryString (UTF-8 [RFC2279])
+ 1.3.6.1.4.1.1466.115.121.1.27 Integer
+
+6. Definition of Matching Rules
+
+ No new matching rules are defined by this document.
+
+ The attribute types defined in Section 4 of this document reference
+ matching rules defined in Section 8 of [RFC2252] and/or Section 2 of
+ [RFC3698], which are summarized below:
+
+ Matching Rule OID Matching Rule Name Usage
+ ------------------------------ ------------------ -----
+ 2.5.13.13 booleanMatch EQUALITY
+ 2.5.13.2 caseIgnoreMatch EQUALITY
+ 2.5.13.14 integerMatch EQUALITY
+ 2.5.13.15 integerOrderingMatch ORDERING
+ 2.5.13.4 caseIgnoreSubstringsMatch SUBSTR
+
+7. IANA Considerations
+
+ This document does not define any new syntaxes or matching rules.
+
+ This document does define the following Object Identifier
+ Descriptors. They have been registered by the IANA:
+
+7.1. Registration of Object Classes
+
+ Subject: Request for LDAP Descriptor Registration
+
+ Descriptor (short name): see table below
+
+ Object Identifier: see table below
+
+ Person & email address to contact for further information: see below
+
+ Usage: object class
+
+
+
+Fleming & McDonald Informational [Page 26]
+
+RFC 3712 LDAP Schema for Printer Services February 2004
+
+
+ Specification: RFC3712
+
+ Author/Change Controller:
+
+ Pat Fleming
+ IBM
+ Highway 52 N
+ Rochester, MN 55901
+ USA
+ Phone: +1 507-253-7583
+ EMail: flemingp at us.ibm.com
+
+ Comments:
+
+ Object Class OID
+ ------------------------------------ ---------------------
+ slpServicePrinter 1.3.18.0.2.6.254
+ printerAbstract 1.3.18.0.2.6.258
+ printerService 1.3.18.0.2.6.255
+ printerServiceAuxClass 1.3.18.0.2.6.257
+ printerIPP 1.3.18.0.2.6.256
+ printerLPR 1.3.18.0.2.6.253
+
+7.2. Registration of Attribute Types
+
+ Subject: Request for LDAP Descriptor Registration
+
+ Descriptor (short name): see table below
+
+ Object Identifier: see table below
+
+ Person & email address to contact for further information: see below
+
+ Usage: attribute type
+
+ Specification: RFC3712
+
+ Author/Change Controller:
+
+ Pat Fleming
+ IBM
+ Highway 52 N
+ Rochester, MN 55901
+ USA
+ Phone: +1 507-253-7583
+ EMail: flemingp at us.ibm.com
+
+
+
+
+
+Fleming & McDonald Informational [Page 27]
+
+RFC 3712 LDAP Schema for Printer Services February 2004
+
+
+ Comments:
+
+ Attribute Type OID
+ ------------------------------------ ---------------------
+ printer-uri 1.3.18.0.2.4.1140
+ printer-xri-supported 1.3.18.0.2.4.1107
+ printer-name 1.3.18.0.2.4.1135
+ printer-natural-language-configured 1.3.18.0.2.4.1119
+ printer-location 1.3.18.0.2.4.1136
+ printer-info 1.3.18.0.2.4.1139
+ printer-more-info 1.3.18.0.2.4.1134
+ printer-make-and-model 1.3.18.0.2.4.1138
+ printer-ipp-versions-supported 1.3.18.0.2.4.1133
+ printer-multiple-document-jobs-supported 1.3.18.0.2.4.1132
+ printer-charset-configured 1.3.18.0.2.4.1109
+ printer-charset-supported 1.3.18.0.2.4.1131
+ printer-generated-natural-language-supported 1.3.18.0.2.4.1137
+ printer-document-format-supported 1.3.18.0.2.4.1130
+ printer-color-supported 1.3.18.0.2.4.1129
+ printer-compression-supported 1.3.18.0.2.4.1128
+ printer-pages-per-minute 1.3.18.0.2.4.1127
+ printer-pages-per-minute-color 1.3.18.0.2.4.1126
+ printer-finishings-supported 1.3.18.0.2.4.1125
+ printer-number-up-supported 1.3.18.0.2.4.1124
+ printer-sides-supported 1.3.18.0.2.4.1123
+ printer-media-supported 1.3.18.0.2.4.1122
+ printer-media-local-supported 1.3.18.0.2.4.1117
+ printer-resolution-supported 1.3.18.0.2.4.1121
+ printer-print-quality-supported 1.3.18.0.2.4.1120
+ printer-job-priority-supported 1.3.18.0.2.4.1110
+ printer-copies-supported 1.3.18.0.2.4.1118
+ printer-job-k-octets-supported 1.3.18.0.2.4.1111
+ printer-current-operator 1.3.18.0.2.4.1112
+ printer-service-person 1.3.18.0.2.4.1113
+ printer-delivery-orientation-supported 1.3.18.0.2.4.1114
+ printer-stacking-order-supported 1.3.18.0.2.4.1115
+ printer-output-features-supported 1.3.18.0.2.4.1116
+ printer-aliases 1.3.18.0.2.4.1108
+
+8. Internationalization Considerations
+
+ All text string attributes defined in this document of syntax
+ [RFC2279], as required by [RFC2252].
+
+ A language tag [RFC3066] for all of the text string attributes
+ defined in this document is contained in the printer-natural-
+ language-configured attribute.
+
+
+
+
+Fleming & McDonald Informational [Page 28]
+
+RFC 3712 LDAP Schema for Printer Services February 2004
+
+
+ Therefore, all object classes defined in this document conform to the
+ "IETF Policy on Character Sets and Languages" [RFC2277].
+
+9. Security Considerations
+
+ See [RFC2829] for detailed guidance on authentication methods for
+ LDAP. See [RFC2830] for detailed guidance of using TLS/1.0 [RFC2246]
+ to supply connection confidentiality and data integrity for LDAP
+ sessions.
+
+ As with any LDAP schema, it is important to protect specific entries
+ and attributes with the appropriate access control. It is
+ particularly important that only administrators can modify entries
+ defined in this LDAP printer schema. Otherwise, an LDAP client might
+ be fooled into diverting print service requests from the original
+ printer (or spooler) to a malicious intruder's host system, thus
+ exposing the information in printed documents.
+
+ For additional security considerations of deploying printers in an
+ IPP environment, see Section 8 of [RFC2911].
+
+10. References
+
+10.1. Normative References
+
+ [IANA-CHAR] IANA Registry of Character Sets
+ http://www.iana.org/assignments/charset-reg/...
+
+ [IANA-MIME] IANA Registry of MIME Media Types
+ http://www.iana.org/assignments/media-types/...
+
+ [LDAP-TS] Hodges, J. and R. Morgan, "Lightweight Directory Access
+ Protocol (v3): Technical Specification", RFC 3377,
+ September 2002.
+
+ [RFC1274] Barker, P. and S. Kille, "The COSINE and Internet X.500
+ Schema", RFC 1274, November 1991.
+
+ [RFC1759] Smith, R., Wright, F., Hastings, T., Zilles, S. and J.
+ Gyllenskog, "Printer MIB", RFC 1759, March 1995.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2252] Wahl, M., Coulbeck, T., Howes, T. and S. Kille,
+ "Lightweight Directory Access Protocol (v3): Attribute
+ Syntax Definitions", RFC 2252, December 1997.
+
+
+
+
+Fleming & McDonald Informational [Page 29]
+
+RFC 3712 LDAP Schema for Printer Services February 2004
+
+
+ [RFC2396] Berners-Lee. T., Fielding, R. and L. Masinter, "URI
+ Generic Syntax", RFC 2396, August 1998.
+
+ [RFC2829] Wahl, M., Alvestrand, H., Hodges, J. and R. Morgan,
+ "Authentication Methods for LDAP", RFC 2829, May 2000.
+
+ [RFC2830] Hodges, J., Morgan, R. and M. Wahl, "Lightweight
+ Directory Access Protocol (v3): Extension for Transport
+ Layer Security", RFC 2830, May 2000.
+
+ [RFC2911] Hastings, T., Ed.., Herrito, R., deBry, R., Isaacson, S.
+ and P. Powell, "Internet Printing Protocol/1.1: Model and
+ Semantics", RFC 2911, September 2000.
+
+ [RFC2926] Kempf, J., Moats, R. and P. St. Pierre, "Conversion of
+ LDAP Schemas to and from SLP Templates", RFC 2926,
+ September 2000.
+
+ [RFC3066] Alvestrand, H., "Tags for the Identification of
+ Languages", BCP 47, RFC 3066, January 2001.
+
+ [RFC3698] Zeilenga, K., Ed., "Lightweight Directory Access Protocol
+ (LDAP): Additional Matching Rules", RFC 3698, February
+ 2004.
+
+10.2. Informative References
+
+ [IANA-SLPT] IANA Registry of SLP Templates
+ http://www.iana.org/assignments/svrloc-templates/...
+
+ [RFC1179] McLaughlin, L., "Line Printer Daemon Protocol", RFC 1179,
+ August 1990.
+
+ [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format
+ Specification Version 1.3", RFC 1951, May 1996.
+
+ [RFC1952] Deutsch, P., "GZIP File Format Specification Version
+ 4.3", RFC 1952, May 1996.
+
+ [RFC1977] Schryver, V., "PPP BSD Compression Protocol", RFC 1977,
+ August 1996.
+
+ [RFC2048] Freed, N., Klensin, J. and J. Postel, "Multipurpose
+ Internet Mail Extensions (MIME) Part Four: Registration
+ Procedures", BCP 13, RFC 2048, November 1996.
+
+
+
+
+
+
+Fleming & McDonald Informational [Page 30]
+
+RFC 3712 LDAP Schema for Printer Services February 2004
+
+
+ [RFC2079] Smith, M., "Definition of an X.500 Attribute Type and an
+ Object Class to Hold Uniform Resource Identifiers
+ (URIs)", RFC 2079, January 1997.
+
+ [RFC2246] Dierks, T. and C. Allen, "TLS Protocol Version 1.0", RFC
+ 2246, January 1999.
+
+ [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and
+ Languages", RFC 2277, January 1998.
+
+ [RFC2279] Yergeau, F., "UTF-8, a Transformation Format of ISO
+ 10646", RFC 2279, January 1998.
+
+ [RFC2608] Guttman, E., Perkins, C., Veizades, J. and M. Day,
+ "Service Location Protocol v2", RFC 2608, June 1999.
+
+ [RFC2609] Guttman, E., Perkins, C. and J. Kempf, "Service Templates
+ and Service: Schemes", RFC 2609, June 1999.
+
+ [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence,
+ S., Leach, P., Luotonen, A. and L. Stewart, "HTTP
+ Authentication: Basic and Digest Access Authentication",
+ RFC 2617, June 1999.
+
+ [RFC2717] Petke, R. and I. King, "Registration Procedures for URL
+ Scheme Names", RFC 2717, November 1999.
+
+ [RFC2718] Masinter, L., Alvestrand, H., Zigmond, D. and R. Petke,
+ "Guidelines for new URL Schemes", BCP 19, RFC 2718,
+ November 1999.
+
+ [RFC2978] Freed, N. and J.Postel, "IANA Charset Registration
+ Procedures", RFC2978, October 2000.
+
+ [SLP-PRT] St. Pierre, Isaacson, McDonald. Definition of the
+ Printer Abstract Service Type v2.0, <durable URL below>,
+ May 2000. Reviewed and approved by IETF SLP Designated
+ Expert, according to Section 5 'IANA Considerations' in
+ [RFC2609].
+
+ Archived in the IANA Registry of SLP Templates [IANA-
+ SLPT] at: http://www.iana.org/assignments/svrloc-
+ templates/printer.2.0.en
+
+ [W3C-IRI] Duerst, Suignard, "Internationalized Resource Identifiers
+ (IRI), Work in Progress.
+
+
+
+
+
+Fleming & McDonald Informational [Page 31]
+
+RFC 3712 LDAP Schema for Printer Services February 2004
+
+
+11. Acknowledgments
+
+ The editors wish to acknowledge the very significant contributions of
+ Ken Jones (Bytemobile) and Harry Lewis (IBM) during the development
+ of this document.
+
+ Thanks to Patrik Faltstrom (Cisco), Ryan Moats (Lemur Networks),
+ Robert Moore (IBM), Lee Rafalow (IBM), Kimberly Reger (IBM), Kurt
+ Zeilenga (OpenLDAP), and the members of the IETF IPP Working Group,
+ for review comments and help in preparing this document.
+
+12. Authors' Addresses
+
+ Please send comments to the authors at the addresses listed below.
+
+ Pat Fleming
+ IBM
+ Highway 52 N
+ Rochester, MN 55901
+ USA
+
+ Phone: +1 507-253-7583
+ EMail: flemingp at us.ibm.com
+
+
+ Ira McDonald
+ High North Inc
+ 221 Ridge Ave
+ Grand Marais, MI 49839
+ USA
+
+ Phone: +1 906-494-2434
+ Email: imcdonald at sharplabs.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fleming & McDonald Informational [Page 32]
+
+RFC 3712 LDAP Schema for Printer Services February 2004
+
+
+13. Full Copyright Statement
+
+ Copyright (C) The Internet Society (2004). This document is subject
+ to the rights, licenses and restrictions contained in BCP 78 and
+ except as set forth therein, the authors retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
+ REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
+ INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
+ IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
+ THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed
+ to pertain to the implementation or use of the technology
+ described in this document or the extent to which any license
+ under such rights might or might not be available; nor does it
+ represent that it has made any independent effort to identify any
+ such rights. Information on the procedures with respect to
+ rights in RFC documents can be found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use
+ of such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository
+ at http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention
+ any copyrights, patents or patent applications, or other
+ proprietary rights that may cover technology that may be required
+ to implement this standard. Please address the information to the
+ IETF at ietf-ipr at ietf.org.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+Fleming & McDonald Informational [Page 33]
+
Added: openldap/vendor/openldap-release/doc/rfc/rfc3727.txt
===================================================================
--- openldap/vendor/openldap-release/doc/rfc/rfc3727.txt (rev 0)
+++ openldap/vendor/openldap-release/doc/rfc/rfc3727.txt 2007-09-15 10:38:52 UTC (rev 844)
@@ -0,0 +1,283 @@
+
+
+
+
+
+
+Network Working Group S. Legg
+Request for Comments: 3727 Adacel Technologies
+Category: Standards Track February 2004
+
+
+ ASN.1 Module Definition for the
+ LDAP and X.500 Component Matching Rules
+
+Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2004). All Rights Reserved.
+
+Abstract
+
+ This document updates the specification of the component matching
+ rules for Lightweight Directory Access Protocol (LDAP) and X.500
+ directories (RFC3687) by collecting the Abstract Syntax Notation One
+ (ASN.1) definitions of the component matching rules into an
+ appropriately identified ASN.1 module so that other specifications
+ may reference the component matching rule definitions from within
+ their own ASN.1 modules.
+
+1. Introduction
+
+ The structure or data type of data held in an attribute of a
+ Lightweight Directory Access Protocol (LDAP) [LDAP] or X.500 [X500]
+ directory is described by the attribute's syntax. Attribute syntaxes
+ range from simple data types, such as text string, integer, or
+ boolean, to complex data types, for example, the syntaxes of the
+ directory schema operational attributes. RFC 3687 [CMR] defines a
+ generic way of matching user selected components in a directory
+ attribute value of any arbitrarily complex attribute syntax.
+
+ This document updates RFC 3687 by collecting the Abstract Syntax
+ Notation One (ASN.1) [ASN1] definitions of RFC 3687 into an
+ appropriately identified ASN.1 module so that other specifications
+ may reference these definitions from within their own ASN.1 modules.
+
+
+
+
+
+
+Legg Standards Track [Page 1]
+
+RFC 3727 Module for Component Matching February 2004
+
+
+2. Module Definition for Component Matching
+
+ ComponentMatching
+ {iso(1) 2 36 79672281 xed(3) module(0) component-matching(4)}
+
+ -- Copyright (C) The Internet Society (2004). This version of
+ -- this ASN.1 module is part of RFC 3727; see the RFC itself
+ -- for full legal notices.
+
+ DEFINITIONS
+ EXPLICIT TAGS
+ EXTENSIBILITY IMPLIED ::= BEGIN
+
+ IMPORTS
+ MATCHING-RULE,
+ RelativeDistinguishedName
+ FROM InformationFramework
+ {joint-iso-itu-t ds(5) module(1)
+ informationFramework(1) 4} ;
+
+ ComponentAssertion ::= SEQUENCE {
+ component ComponentReference (SIZE(1..MAX)) OPTIONAL,
+ useDefaultValues BOOLEAN DEFAULT TRUE,
+ rule MATCHING-RULE.&id,
+ value MATCHING-RULE.&AssertionType }
+
+ ComponentReference ::= UTF8String
+
+ ComponentFilter ::= CHOICE {
+ item [0] ComponentAssertion,
+ and [1] SEQUENCE OF ComponentFilter,
+ or [2] SEQUENCE OF ComponentFilter,
+ not [3] ComponentFilter }
+
+ componentFilterMatch MATCHING-RULE ::= {
+ SYNTAX ComponentFilter
+ ID { 1 2 36 79672281 1 13 2 } }
+
+ allComponentsMatch MATCHING-RULE ::= {
+ ID { 1 2 36 79672281 1 13 6 } }
+
+ directoryComponentsMatch MATCHING-RULE ::= {
+ ID { 1 2 36 79672281 1 13 7 } }
+
+
+ -- Additional Useful Matching Rules --
+
+ rdnMatch MATCHING-RULE ::= {
+
+
+
+Legg Standards Track [Page 2]
+
+RFC 3727 Module for Component Matching February 2004
+
+
+ SYNTAX RelativeDistinguishedName
+ ID { 1 2 36 79672281 1 13 3 } }
+
+ presentMatch MATCHING-RULE ::= {
+ SYNTAX NULL
+ ID { 1 2 36 79672281 1 13 5 } }
+
+ END
+
+ The InformationFramework ASN.1 module from which the MATCHING-RULE
+ and RelativeDistinguishedName definitions are imported is defined in
+ X.501 [X501].
+
+ The object identifiers used in this document have been assigned for
+ use in specifying the component matching rules by Adacel
+ Technologies, under an arc assigned to Adacel by Standards Australia.
+
+3. Security Considerations
+
+ This document collects together the ASN.1 definitions of the
+ component matching rules into an ASN.1 module, but does not modify
+ those definitions in any way. See RFC 3687 [CMR] for the security
+ considerations of using the component matching rules.
+
+4. References
+
+4.1. Normative References
+
+ [CMR] Legg, S., "Lightweight Directory Access Protocol (LDAP) and
+ X.500 Component Matching Rules", RFC 3687, February 2004.
+
+ [X501] ITU-T Recommendation X.501 (1993) | ISO/IEC 9594-2:1994,
+ Information Technology - Open Systems Interconnection - The
+ Directory: Models
+
+ [ASN1] ITU-T Recommendation X.680 (07/02) | ISO/IEC 8824-1:2002,
+ Information technology - Abstract Syntax Notation One
+ (ASN.1): Specification of basic notation
+
+4.2. Informative References
+
+ [LDAP] Hodges, J. and R. Morgan, "Lightweight Directory Access
+ Protocol (v3): Technical Specification", RFC 3377, September
+ 2002.
+
+ [X500] ITU-T Recommendation X.500 (1993) | ISO/IEC 9594-1:1994,
+ Information Technology - Open Systems Interconnection - The
+ Directory: Overview of concepts, models and services
+
+
+
+Legg Standards Track [Page 3]
+
+RFC 3727 Module for Component Matching February 2004
+
+
+5. Author's Address
+
+ Steven Legg
+ Adacel Technologies Ltd.
+ 250 Bay Street
+ Brighton, Victoria 3186
+ AUSTRALIA
+
+ Phone: +61 3 8530 7710
+ Fax: +61 3 8530 7888
+ EMail: steven.legg at adacel.com.au
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Legg Standards Track [Page 4]
+
+RFC 3727 Module for Component Matching February 2004
+
+
+6. Full Copyright Statement
+
+ Copyright (C) The Internet Society (2004). This document is subject
+ to the rights, licenses and restrictions contained in BCP 78 and
+ except as set forth therein, the authors retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
+ REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
+ INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
+ IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
+ THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed
+ to pertain to the implementation or use of the technology
+ described in this document or the extent to which any license
+ under such rights might or might not be available; nor does it
+ represent that it has made any independent effort to identify any
+ such rights. Information on the procedures with respect to
+ rights in RFC documents can be found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use
+ of such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository
+ at http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention
+ any copyrights, patents or patent applications, or other
+ proprietary rights that may cover technology that may be required
+ to implement this standard. Please address the information to the
+ IETF at ietf-ipr at ietf.org.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+Legg Standards Track [Page 5]
+
Added: openldap/vendor/openldap-release/doc/rfc/rfc3771.txt
===================================================================
--- openldap/vendor/openldap-release/doc/rfc/rfc3771.txt (rev 0)
+++ openldap/vendor/openldap-release/doc/rfc/rfc3771.txt 2007-09-15 10:38:52 UTC (rev 844)
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+Network Working Group R. Harrison
+Request for Comments: 3771 Novell, Inc.
+Updates: 2251 K. Zeilenga
+Category: Standards Track OpenLDAP Foundation
+ April 2004
+
+
+ The Lightweight Directory Access Protocol (LDAP)
+ Intermediate Response Message
+
+Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2004). All Rights Reserved.
+
+Abstract
+
+ This document defines and describes the IntermediateResponse message,
+ a general mechanism for defining single-request/multiple-response
+ operations in Lightweight Directory Access Protocol (LDAP). The
+ IntermediateResponse message is defined in such a way that the
+ protocol behavior of existing LDAP operations is maintained. This
+ message is intended to be used in conjunction with the LDAP
+ ExtendedRequest and ExtendedResponse to define new single-
+ request/multiple-response operations or in conjunction with a control
+ when extending existing LDAP operations in a way that requires them
+ to return intermediate response information.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Harrison & Zeilenga Standards Track [Page 1]
+
+RFC 3771 LDAP Intermediate Response April 2004
+
+
+1. Introduction
+
+ The Lightweight Directory Access Protocol (LDAP), version 3 [RFC3377]
+ is an extensible protocol. Extended operations ([RFC2251] Section
+ 4.12) are defined to allow for the addition of operations to LDAP,
+ without requiring revisions of the protocol. Similarly, controls
+ ([RFC2251] Section 4.1.12) are defined to extend or modify the
+ behavior of existing LDAP operations.
+
+ LDAP is a client-request/server-response based protocol. With the
+ exception of the search operation, the entire response to an
+ operation request is returned in a single protocol data unit (i.e.,
+ LDAP message). While this single-request/single-response paradigm is
+ sufficient for many operations (including all but one of those
+ currently defined by [RFC3377]), both intuition and practical
+ experience validate the notion that it is insufficient for others.
+
+ For example, the LDAP delete operation could be extended via a
+ subtree control to mean that an entire subtree is to be deleted. A
+ subtree delete operation needs to return continuation references
+ based upon subordinate knowledge information contained in the server
+ so that the client can complete the operation. Returning references
+ as they are found, instead of with the final result, allows the
+ client to perform the operation more efficiently because it does not
+ have to wait for the final result to get this continuation reference
+ information.
+
+ Similarly, an engineer might choose to design the subtree delete
+ operation as an extended operation of its own rather than using a
+ subtree control in conjunction with the delete operation. Once
+ again, the same continuation reference information is needed by the
+ client to complete the operation, and sending the continuation
+ references as they are found would allow the client to perform the
+ operation more efficiently.
+
+ Operations that are completed in stages or that progress through
+ various states as they are completed might want to send intermediate
+ responses to the client, thereby informing it of the status of the
+ operation. For example, an LDAP implementation might define an
+ extended operation to create a new replica of an administrative area
+ on a server, and the operation is completed in three stages: (1)
+ begin creation of replica, (2) send replica data to server, (3)
+ replica creation complete. Intermediate messages might be sent from
+ the server to the client at the beginning of each stage with the
+ final response for the extended operation being sent after stage (3)
+ is complete.
+
+
+
+
+
+Harrison & Zeilenga Standards Track [Page 2]
+
+RFC 3771 LDAP Intermediate Response April 2004
+
+
+ As LDAP [RFC3377] is currently defined, there is no general LDAP
+ message type that can be used to return intermediate results. A
+ single, reusable LDAP message for carrying intermediate response
+ information is desired to avoid repeated modification of the
+ protocol. Although the ExtendedResponse message is defined in LDAP,
+ it is defined to be the one and only response message to an
+ ExtendedRequest message ([RFC2251] Section 4.12), for unsolicited
+ notifications ([RFC2251] Section 4.4), and to return intermediate
+ responses for the search operation ([RFC3377] Section 4.5.2, also see
+ Section 5 below). The adaptation of ExtendedResponse as a general
+ intermediate response mechanism would be problematic. In particular,
+ existing APIs would likely have to be redesigned. It is believed
+ (based upon operational experience) that the addition of a new
+ message to carry intermediate result information is easier to
+ implement and is less likely to cause interoperability problems with
+ existing deployed implementations.
+
+ This document defines and describes the LDAP IntermediateResponse
+ message. This message is intended to be used in conjunction with
+ ExtendedRequest and ExtendedResponse to define new single-
+ request/multiple-response operations or in conjunction with a control
+ when extending existing LDAP operations in a way that requires them
+ to return intermediate response information.
+
+ It is intended that the definitions and descriptions of extended
+ operations and controls using the IntermediateResponse message will
+ define the circumstances in which an IntermediateResponse message can
+ be sent by a server and the associated meaning of the
+ IntermediateResponse message sent in a particular circumstance.
+ Similarly, it is intended that clients will explicitly solicit
+ IntermediateResponse messages by issuing operations that specifically
+ call for their return.
+
+ The LDAP Content Sync Operation [ZEILENGA] demonstrates one use of
+ LDAP Intermediate Response messages.
+
+2. Conventions used in this document
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in [RFC2119].
+
+ The term "request control" is used to describe a control that is
+ included in an LDAP request message sent from an LDAP client to an
+ LDAP server.
+
+
+
+
+
+
+Harrison & Zeilenga Standards Track [Page 3]
+
+RFC 3771 LDAP Intermediate Response April 2004
+
+
+3. The IntermediateResponse Message
+
+ This document extends the protocolOp CHOICE of LDAPMessage ([RFC2251]
+ Section 4.1.1) to include the field:
+
+ intermediateResponse IntermediateResponse
+
+ where IntermediateResponse is defined as:
+
+ IntermediateResponse ::= [APPLICATION 25] SEQUENCE {
+ responseName [0] LDAPOID OPTIONAL,
+ responseValue [1] OCTET STRING OPTIONAL }
+
+ IntermediateResponse messages SHALL NOT be returned to the client
+ unless the client issues a request that specifically solicits their
+ return. This document defines two forms of solicitation: extended
+ operation and request control.
+
+ Although the responseName and responseValue are optional in some
+ circumstances, IntermediateResponse messages usually have a
+ predefined responseName and a responseValue. The value of the
+ responseName (if present), the syntax of the responseValue (if
+ present) and the semantics associated with a particular
+ IntermediateResponse message MUST be specified in documents
+ describing the extended operation or request control that uses them.
+ Sections 3.1 and 3.2 describe additional requirements for the
+ inclusion of responseName and responseValue in IntermediateResponse
+ messages.
+
+3.1. Usage with LDAP ExtendedRequest and ExtendedResponse
+
+ A single-request/multiple-response operation may be defined using a
+ single ExtendedRequest message to solicit zero or more
+ IntermediateResponse messages, of one or more kinds, followed by an
+ ExtendedResponse message.
+
+ An extended operation that defines the return of multiple kinds of
+ IntermediateResponse messages MUST provide and document a mechanism
+ for the client to distinguish the kind of IntermediateResponse
+ message being sent. This SHALL be accomplished by using different
+ responseName values for each type of IntermediateResponse message
+ associated with the extended operation or by including identifying
+ information in the responseValue of each type of IntermediateResponse
+ message associated with the extended operation.
+
+
+
+
+
+
+
+Harrison & Zeilenga Standards Track [Page 4]
+
+RFC 3771 LDAP Intermediate Response April 2004
+
+
+3.2. Usage with LDAP Request Controls
+
+ Any LDAP operation may be extended by the addition of one or more
+ controls ([RFC2251] Section 4.1.12). A control's semantics may
+ include the return of zero or more IntermediateResponse messages
+ prior to returning the final result code for the operation. One or
+ more kinds of IntermediateResponse messages may be sent in response
+ to a request control.
+
+ All IntermediateResponse messages associated with request controls
+ SHALL include a responseName. This requirement ensures that the
+ client can correctly identify the source of IntermediateResponse
+ messages when:
+
+ a) two or more controls using IntermediateResponse messages are
+ included in a request for any LDAP operation or
+
+ b) one or more controls using IntermediateResponse messages are
+ included in a request with an LDAP extended operation that uses
+ IntermediateResponse messages.
+
+ A request control that defines the return of multiple kinds of
+ IntermediateResponse messages MUST provide and document a mechanism
+ for the client to distinguish the kind of IntermediateResponse
+ message being sent. This SHALL be accomplished by using different
+ responseName values for each type of IntermediateResponse message
+ associated with the request control or by including identifying
+ information in the responseValue of each type of IntermediateResponse
+ message associated with the request control.
+
+4. Advertising Support for IntermediateResponse Messages
+
+ Because IntermediateResponse messages are associated with extended
+ operations or controls and LDAP provides a means for advertising the
+ extended operations and controls supported by a server (using the
+ supportedExtension ([RFC2252] Section 5.2.3) and supportedControl
+ ([RFC2252] Section 5.2.4) attributes of the root DSE), there is no
+ need for a separate means of advertising support for intermediate
+ response messages.
+
+5. Use of IntermediateResponse and ExtendedResponse with Search
+
+ It is noted that ExtendedResponse messages may be sent in response to
+ LDAP search operations with controls ([RFC2251] Section 4.5.2). This
+ use of ExtendedResponse messages SHOULD be viewed as deprecated, in
+ favor of use of the IntermediateResponse messages.
+
+
+
+
+
+Harrison & Zeilenga Standards Track [Page 5]
+
+RFC 3771 LDAP Intermediate Response April 2004
+
+
+6. Security Considerations
+
+ This document describes an enhancement to LDAP. All security
+ considerations of [RFC3377] apply to this document; however, it does
+ not introduce any new security considerations to LDAP.
+
+ Security considerations specific to each extension using this
+ protocol mechanism shall be discussed in the technical specification
+ detailing the extension.
+
+7. IANA Considerations
+
+ Registration of the following value has been completed [RFC3383].
+
+7.1. LDAP Message Type
+
+ The IANA has registered an LDAP Message Type (25) to identify the
+ LDAP IntermediateResponse message as defined in section 3 of this
+ document.
+
+ The following registration template is suggested:
+
+ Subject: Request for LDAP Message Type Registration
+ Person & email address to contact for further information:
+ Roger Harrison <roger_harrison at novell.com>
+ Specification: RFC3771
+ Author/Change Controller: IESG
+ Comments: Identifies the LDAP IntermediateResponse Message
+
+8. Acknowledgments
+
+ The authors would like to acknowledge the members of the IETF LDAP
+ Extensions (ldapext) working group mail list who responded to the
+ suggestion that a multiple-response paradigm might be useful for LDAP
+ extended requests. Special thanks to two individuals: David Wilbur
+ who first introduced the idea on the working group list, and Thomas
+ Salter, who succinctly summarized the group's discussion.
+
+9. References
+
+9.1. Normative References
+
+ [RFC2119] Bradner, S., "Key Words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2251] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory
+ Access Protocol (v3)", RFC 2251, December 1997.
+
+
+
+
+Harrison & Zeilenga Standards Track [Page 6]
+
+RFC 3771 LDAP Intermediate Response April 2004
+
+
+ [RFC2252] Wahl, M., Coulbeck, A., Howes, T. and S. Kille,
+ "Lightweight Directory Access Protocol (v3): Attribute
+ Syntax Definitions", RFC 2252, December 1997.
+
+ [RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access
+ Protocol (v3): Technical Specification", RFC 3377,
+ September 2002.
+
+ [RFC3383] Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
+ Considerations for the Lightweight Directory Access
+ Protocol (LDAP)", BCP 64, RFC 3383, September 2002.
+
+9.2. Informative References
+
+ [ZEILENGA] Zeilenga, K., "LDAP Content Synchronization Operation",
+ Work in Progress, February 2004.
+
+10. Authors' Addresses
+
+ Roger Harrison
+ Novell, Inc.
+ 1800 S. Novell Place
+ Provo, UT 84606
+
+ Phone: +1 801 861 2642
+ EMail: roger_harrison at novell.com
+
+
+ Kurt D. Zeilenga
+ OpenLDAP Foundation
+
+ EMail: Kurt at OpenLDAP.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Harrison & Zeilenga Standards Track [Page 7]
+
+RFC 3771 LDAP Intermediate Response April 2004
+
+
+11. Full Copyright Statement
+
+ Copyright (C) The Internet Society (2004). This document is subject
+ to the rights, licenses and restrictions contained in BCP 78, and
+ except as set forth therein, the authors retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at ietf-
+ ipr at ietf.org.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+Harrison & Zeilenga Standards Track [Page 8]
+
Added: openldap/vendor/openldap-release/doc/rfc/rfc3829.txt
===================================================================
--- openldap/vendor/openldap-release/doc/rfc/rfc3829.txt (rev 0)
+++ openldap/vendor/openldap-release/doc/rfc/rfc3829.txt 2007-09-15 10:38:52 UTC (rev 844)
@@ -0,0 +1,339 @@
+
+
+
+
+
+
+Network Working Group R. Weltman
+Request for Comments: 3829 America Online
+Category: Informational M. Smith
+ Pearl Crescent, LLC
+ M. Wahl
+ July 2004
+
+ Lightweight Directory Access Protocol (LDAP)
+ Authorization Identity Request and Response Controls
+
+Status of this Memo
+
+ This memo provides information for the Internet community. It does
+ not specify an Internet standard of any kind. Distribution of this
+ memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2004).
+
+Abstract
+
+ This document extends the Lightweight Directory Access Protocol
+ (LDAP) bind operation with a mechanism for requesting and returning
+ the authorization identity it establishes. Specifically, this
+ document defines the Authorization Identity Request and Response
+ controls for use with the Bind operation.
+
+1. Introduction
+
+ This document defines support for the Authorization Identity Request
+ Control and the Authorization Identity Response Control for
+ requesting and returning the authorization established in a bind
+ operation. The Authorization Identity Request Control may be
+ submitted by a client in a bind request if authenticating with
+ version 3 of the Lightweight Directory Access Protocol (LDAP)
+ protocol [LDAPv3]. In the LDAP server's bind response, it may then
+ include an Authorization Identity Response Control. The response
+ control contains the identity assumed by the client. This is useful
+ when there is a mapping step or other indirection during the bind, so
+ that the client can be told what LDAP identity was granted. Client
+ authentication with certificates is the primary situation where this
+ applies. Also, some Simple Authentication and Security Layer [SASL]
+ authentication mechanisms may not involve the client explicitly
+ providing a DN, or may result in an authorization identity which is
+ different from the authentication identity provided by the client
+ [AUTH].
+
+
+
+
+Weltman, et al. Informational [Page 1]
+
+RFC 3829 Authorization Identity Bind Control July 2004
+
+
+ The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
+ used in this document are to be interpreted as described in
+ [RFCKeyWords].
+
+2. Publishing support for the Authorization Identity Request Control
+ and the Authorization Identity Response Control
+
+ Support for the Authorization Identity Request Control and the
+ Authorization Identity Response Control is indicated by the presence
+ of the Object Identifiers (OIDs) 2.16.840.1.113730.3.4.16 and
+ 2.16.840.1.113730.3.4.15, respectively, in the supportedControl
+ attribute [LDAPATTRS] of a server's root DSA-specific Entry (DSE).
+
+3. Authorization Identity Request Control
+
+ This control MAY be included in any bind request which specifies
+ protocol version 3, as part of the controls field of the LDAPMessage
+ as defined in [LDAPPROT]. In a multi-step bind operation, the client
+ MUST provide the control with each bind request.
+
+ The controlType is "2.16.840.1.113730.3.4.16" and the controlValue is
+ absent.
+
+4. Authorization Identity Response Control
+
+ This control MAY be included in any final bind response where the
+ first bind request of the bind operation included an Authorization
+ Identity Request Control as part of the controls field of the
+ LDAPMessage as defined in [LDAPPROT].
+
+ The controlType is "2.16.840.1.113730.3.4.15". If the bind request
+ succeeded and resulted in an identity (not anonymous), the
+ controlValue contains the authorization identity (authzId), as
+ defined in [AUTH] section 9, granted to the requestor. If the bind
+ request resulted in an anonymous association, the controlValue field
+ is a string of zero length. If the bind request resulted in more
+ than one authzId, the primary authzId is returned in the controlValue
+ field.
+
+ The control is only included in a bind response if the resultCode for
+ the bind operation is success.
+
+ If the server requires confidentiality protections to be in place
+ prior to use of this control (see Security Considerations), the
+ server reports failure to have adequate confidentiality protections
+ in place by returning the confidentialityRequired result code.
+
+
+
+
+
+Weltman, et al. Informational [Page 2]
+
+RFC 3829 Authorization Identity Bind Control July 2004
+
+
+ If the client has insufficient access rights to the requested
+ authorization information, the server reports this by returning the
+ insufficientAccessRights result code.
+
+ Identities presented by a client as part of the authentication
+ process may be mapped by the server to one or more authorization
+ identities. The bind response control can be used to retrieve the
+ primary authzId.
+
+ For example, during client authentication with certificates [AUTH], a
+ client may possess more than one certificate and may not be able to
+ determine which one was ultimately selected for authentication to the
+ server. The subject DN field in the selected certificate may not
+ correspond exactly to a DN in the directory, but rather have gone
+ through a mapping process controlled by the server. Upon completing
+ the certificate-based authentication, the client may issue a SASL
+ [SASL] bind request, specifying the EXTERNAL mechanism and including
+ an Authorization Identity Request Control. The bind response MAY
+ include an Authorization Identity Response Control indicating the DN
+ in the server's Directory Information Tree (DIT) which the
+ certificate was mapped to.
+
+5. Alternative Approach with Extended Operation
+
+ The LDAP "Who am I?" [AUTHZID] extended operation provides a
+ mechanism to query the authorization identity associated with a bound
+ connection. Using an extended operation, as opposed to a bind
+ response control, allows a client to learn the authorization identity
+ after the bind has established integrity and data confidentiality
+ protections. The disadvantages of the extended operation approach
+ are coordination issues between "Who am I?" requests, bind requests,
+ and other requests, and that an extra operation is required to learn
+ the authorization identity. For multithreaded or high bandwidth
+ server application environments, the bind response approach may be
+ preferable.
+
+6. Security Considerations
+
+ The Authorization Identity Request and Response Controls are subject
+ to standard LDAP security considerations. The controls may be passed
+ over a secure as well as over an insecure channel. They are not
+ protected by security layers negotiated by the bind operation.
+
+ The response control allows for an additional authorization identity
+ to be passed. In some deployments, these identities may contain
+ confidential information which require privacy protection. In such
+ deployments, a security layer should be established prior to issuing
+ a bind request with an Authorization Identity Request Control.
+
+
+
+Weltman, et al. Informational [Page 3]
+
+RFC 3829 Authorization Identity Bind Control July 2004
+
+
+7. IANA Considerations
+
+ The OIDs 2.16.840.1.113730.3.4.16 and 2.16.840.1.113730.3.4.15 are
+ reserved for the Authorization Identity Request and Response
+ Controls, respectively. The Authorization Identity Request Control
+ has been registered as an LDAP Protocol Mechanism [IANALDAP].
+
+8. References
+
+8.1. Normative References
+
+ [LDAPv3] Hodges, J. and R. Morgan, "Lightweight Directory Access
+ Protocol (v3): Technical Specification", RFC 3377,
+ September 2002.
+
+ [LDAPPROT] Wahl, M., Howes, T. and S. Kille, "Lightweight
+ Directory Access Protocol (v3)", RFC 2251, December
+ 1997.
+
+ [RFCKeyWords] Bradner, S., "Key Words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [AUTH] Wahl, M., Alvestrand, H., Hodges, J. and R. Morgan,
+ "Authentication Methods for LDAP", RFC 2829, May 2000.
+
+ [SASL] Myers, J., "Simple Authentication and Security Layer
+ (SASL)", RFC 2222, October 1997.
+
+ [LDAPATTRS] Wahl, M., Coulbeck, A., Howes, T. and S. Kille,
+ "Lightweight Directory Access Protocol (v3): Attribute
+ Syntax Definitions", RFC 2252, December 1997.
+
+ [IANALDAP] Hodges, J. and R. Morgan, "Lightweight Directory Access
+ Protocol (v3): Technical Specification", RFC 3377,
+ September 2002.
+
+8.2. Informative References
+
+ [AUTHZID] Zeilenga, K., "LDAP 'Who am I?' Operation", Work in
+ Progress, April 2002.
+
+
+
+
+
+
+
+
+
+
+
+Weltman, et al. Informational [Page 4]
+
+RFC 3829 Authorization Identity Bind Control July 2004
+
+
+9. Author's Addresses
+
+ Rob Weltman
+ America Online
+ 360 W. Caribbean Drive
+ Sunnyvale, CA 94089
+ USA
+
+ Phone: +1 650 937-3194
+ EMail: robw at worldspot.com
+
+
+ Mark Smith
+ Pearl Crescent, LLC
+ 447 Marlpool Drive
+ Saline, MI 48176
+ USA
+
+ Phone: +1 734 944-2856
+ EMail: mcs at pearlcrescent.com
+
+
+ Mark Wahl
+ PO Box 90626
+ Austin, TX 78709-0626
+ USA
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Weltman, et al. Informational [Page 5]
+
+RFC 3829 Authorization Identity Bind Control July 2004
+
+
+10. Full Copyright Statement
+
+ Copyright (C) The Internet Society (2004). This document is subject
+ to the rights, licenses and restrictions contained in BCP 78, and
+ except as set forth therein, the authors retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at ietf-
+ ipr at ietf.org.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+Weltman, et al. Informational [Page 6]
+
Added: openldap/vendor/openldap-release/doc/rfc/rfc3866.txt
===================================================================
--- openldap/vendor/openldap-release/doc/rfc/rfc3866.txt (rev 0)
+++ openldap/vendor/openldap-release/doc/rfc/rfc3866.txt 2007-09-15 10:38:52 UTC (rev 844)
@@ -0,0 +1,843 @@
+
+
+
+
+
+
+Network Working Group K. Zeilenga, Ed.
+Request for Comments: 3866 OpenLDAP Foundation
+Obsoletes: 2596 July 2004
+Category: Standards Track
+
+
+ Language Tags and Ranges in the
+ Lightweight Directory Access Protocol (LDAP)
+
+Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2004).
+
+Abstract
+
+ It is often desirable to be able to indicate the natural language
+ associated with values held in a directory and to be able to query
+ the directory for values which fulfill the user's language needs.
+ This document details the use of Language Tags and Ranges in the
+ Lightweight Directory Access Protocol (LDAP).
+
+1. Background and Intended Use
+
+ 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
+ syntaxes which are human-readable strings, and it is desirable to be
+ able to indicate the natural language associated with attribute
+ values.
+
+ This document describes how language tags and ranges [RFC3066] are
+ carried in LDAP and are to be interpreted by LDAP implementations.
+ All LDAP implementations MUST be prepared to accept language tags and
+ ranges.
+
+ 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].
+
+
+
+
+Zeilenga Standards Track [Page 1]
+
+RFC 3866 Language Tags and Ranges in LDAP July 2004
+
+
+ This document replaces RFC 2596. Appendix A summaries changes made
+ since RFC 2596.
+
+ Appendix B discusses differences from X.500(1997) "contexts"
+ mechanism.
+
+ 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.
+
+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] 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.
+ Language ranges are used to specify sets of language 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 attribute description option naming restrictions in LDAP, this
+ document defines a different language range syntax. However, the
+ semantics of language ranges in LDAP are 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 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.
+
+
+
+
+
+Zeilenga Standards Track [Page 2]
+
+RFC 3866 Language Tags and Ranges in LDAP July 2004
+
+
+ AttributeDescriptions can also contain options which are not part of
+ the attribute, but indicate some other function (such as range
+ assertion or transfer encoding).
+
+ 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
+ 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 syntaxes to have language tag options associated with
+ it. Servers MAY allow language options to be associated with other
+ attributes types.
+
+ Clients SHOULD NOT assume servers are capable of storing attributes
+ with language tags in the directory.
+
+ Implementations MUST NOT otherwise interpret the structure of the tag
+ when comparing two tags, and MUST treat them simply as strings of
+ characters. Implementations MUST allow any arbitrary string which
+ conforms to the syntax defined in BCP 47 [RFC3066] to be used as a
+ language tag.
+
+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 type but different combinations of language tag (and other)
+ options.
+
+ A language tag option conforms to the following ABNF [RFC2234]:
+
+ language-tag-option = "lang-" Language-Tag
+
+
+
+
+
+
+Zeilenga Standards Track [Page 3]
+
+RFC 3866 Language Tags and Ranges in LDAP July 2004
+
+
+ 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:
+
+ 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 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:
+
+ givenName;lang-en-US
+ CN;lang-ja
+ SN;lang-de;lang-gem-PFL
+ O;lang-i-klingon;x-foobar
+ description;x-foobar
+ CN
+
+ Notes: The last two have no language tag options. The x-foobar
+ option is fictious and used for example purposes.
+
+2.2. Search Filter
+
+ If language tag options are present in an AttributeDescription in an
+ 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 each of the presented (and possibly
+ other) options is to be matched.
+
+ 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:
+
+ 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: Billy Ray MATCHES
+
+
+
+Zeilenga Standards Track [Page 4]
+
+RFC 3866 Language Tags and Ranges in LDAP July 2004
+
+
+ CN;lang-en-US;x-foobar: Billy Ray MATCHES
+ CN;lang-en;x-foobar: Billy Ray DOES NOT MATCH (differing lang-)
+ CN;x-foobar: Billy Ray DOES NOT MATCH (no lang-)
+ name: Billy Ray DOES NOT MATCH (no lang-)
+ SN;lang-en-GB;lang-en-US: Billy Ray MATCHES
+ SN: Ray DOES NOT MATCH (no lang-,
+ wrong value)
+
+ 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
+ does not match exactly. For example, the filter (name;lang-en=Billy
+ Ray) does NOT match the attribute "name;lang-en-US: Billy Ray".
+
+ If the server does not support storing attributes with language tag
+ options in the DIT, then any assertion which includes a language tag
+ 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.
+
+ If no options are specified in the assertion, then only the base
+ 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:
+
+ 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
+ CN;lang-en;x-foobar: Billy Ray MATCHES
+ CN;x-foobar: Billy Ray MATCHES
+ name: Billy Ray MATCHES
+ SN;lang-en-GB;lang-en-US: Billy Ray MATCHES
+ SN: Ray DOES NOT MATCH (wrong value)
+
+2.3. Requested Attributes in Search
+
+ 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 contains
+
+
+
+Zeilenga Standards Track [Page 5]
+
+RFC 3866 Language Tags and Ranges in LDAP July 2004
+
+
+ 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
+ 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
+ of name would match "name".
+
+ If a server does not support storing attributes with language tag
+ options in the DIT, then any attribute descriptions in the list which
+ include language tag options are to be ignored, just as if they were
+ unknown attribute types.
+
+ 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.
+
+ For example, if the client requests a "description" attribute, and a
+ matching entry contains the following attributes:
+
+ objectClass: top
+ objectClass: organization
+ O: Software GmbH
+ description: software products
+ description;lang-en: software products
+ description;lang-de: Softwareprodukte
+
+ The server would return:
+
+ description: software products
+ description;lang-en: software products
+ description;lang-de: Softwareprodukte
+
+2.4. Compare
+
+ Language tag options can be present in an AttributeDescription used
+ in 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 attribute type or its
+ subtype and contains each of the presented (or possibly other)
+ language tag options, the noSuchAttributeType error will be returned.
+
+
+
+
+Zeilenga Standards Track [Page 6]
+
+RFC 3866 Language Tags and Ranges in LDAP July 2004
+
+
+ Thus, for example, a compare request of type "name" and assertion
+ value "Johann", against an entry containing the following attributes:
+
+ objectClass: top
+ objectClass: person
+ givenName;lang-de-DE: Johann
+ CN: Johann Sibelius
+ SN: Sibelius
+
+ would cause the server to return compareTrue.
+
+ However, if the client issued a compare request of type
+ "name;lang-de" and assertion value "Johann" against the above entry,
+ the request would fail with the noSuchAttributeType error.
+
+ If the server does not support storing attributes with language tag
+ 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.
+
+2.5. Add Operation
+
+ Clients can provide language options in AttributeDescription in
+ 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 valid request:
+
+ dn: CN=John Smith,DC=example,DC=com
+ objectClass: residentialPerson
+ CN: John Smith
+ CN;lang-en: John Smith
+ SN: Smith
+ SN;lang-en: Smith
+ streetAddress: 1 University Street
+ streetAddress;lang-en-US: 1 University Street
+ streetAddress;lang-fr: 1 rue Universite
+ houseIdentifier;lang-fr: 9e etage
+
+ If a server does not support storing language tag options with
+ attribute values in the DIT, then it MUST treat an
+ AttributeDescription with a language tag option as an unrecognized
+ attribute. If the server forbids the addition of unrecognized
+ attributes then it MUST fail the add request with an appropriate
+ result code.
+
+
+
+Zeilenga Standards Track [Page 7]
+
+RFC 3866 Language Tags and Ranges in LDAP July 2004
+
+
+2.6. Modify Operation
+
+ A client can provide language tag options in an AttributeDescription
+ as part of a modification element in the modify operation.
+
+ Attribute types and language tag options MUST match exactly against
+ values stored in the directory. For example, if the modification is
+ a "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
+ any language tag option, then no language tag option is to be
+ provided.
+
+ If the server does not support storing language tag options with
+ attribute values in the DIT, then it MUST treat an
+ AttributeDescription with a language tag option as an unrecognized
+ attribute, and MUST fail the request with an appropriate result code.
+
+3. Use of Language Ranges in LDAP
+
+ 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
+ same sequence of language sub-tags.
+
+ AttributeDescriptions containing language range options are intended
+ to be used in attribute value assertions, search attribute lists, and
+ other places where the client desires to provide an attribute
+ description matching of a range of language tags associated with
+ attributes.
+
+ A language range option conforms to the following ABNF [RFC2234]:
+
+ 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 in
+ Section 2.1 for convenience.
+
+ 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
+ option "lang-" matches all language tag options.
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 8]
+
+RFC 3866 Language Tags and Ranges in LDAP July 2004
+
+
+ Examples of valid AttributeDescription containing language range
+ options:
+
+ 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 stored with language range options. Any attempt to add or update
+ an attribute description with a language range option SHALL be
+ treated as an undefined attribute type and result in an error.
+
+ A language range option has no effect on the transfer encoding nor on
+ the syntax of the attribute values.
+
+ Servers SHOULD support assertion of language ranges for any attribute
+ 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 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:
+
+ 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: Billy Ray MATCHES
+ CN;lang-en-US;x-foobar: Billy Ray MATCHES
+ CN;lang-en;x-foobar: Billy Ray MATCHES
+ CN;x-foobar: Billy Ray DOES NOT MATCH (no lang-)
+ name: Billy Ray DOES NOT MATCH (no lang-)
+ SN;lang-en-GB;lang-en-US: Billy Ray MATCHES
+ SN: Ray DOES NOT MATCH (no lang-,
+ wrong value)
+
+ Note that "CN" and "SN" are subtypes of "name".
+
+
+
+
+
+Zeilenga Standards Track [Page 9]
+
+RFC 3866 Language Tags and Ranges in LDAP July 2004
+
+
+ If the server does not support storing attributes with language tag
+ options in the DIT, then any assertion which includes a language
+ range option will not match as it is an unrecognized attribute type.
+ No error would be returned because of this; a presence filter would
+ evaluate to FALSE and all other assertions to Undefined.
+
+3.2. Requested Attributes in Search
+
+ 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 have the same attribute type or its subtype and a
+ language tag option matching the provided language range option are
+ to be returned. Thus if a client requests just the attribute
+ "name;lang-en-", the server would return "name;lang-en-US" and
+ "CN;lang-en;lang-ja" but not "SN" nor "name;lang-fr".
+
+ Clients can provide in the attribute list multiple
+ 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 whose type was name or subtype of name and with a language
+ tag option matching either language range option to be returned.
+
+ If a server does not support storing attributes with language tag
+ options in the DIT, then any attribute descriptions in the list which
+ include language range options are to be ignored, just as if they
+ were unknown attribute types.
+
+3.3. Compare
+
+ Language range options can be present in an AttributeDescription used
+ in a compare request AttributeValueAssertion. This is to be treated
+ by servers the same as the use of language range options in a search
+ filter with an equality match, as described in Section 3.1. If there
+ 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:
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 10]
+
+RFC 3866 Language Tags and Ranges in LDAP July 2004
+
+
+ objectClass: top
+ objectClass: person
+ givenName;lang-de-DE: Johann
+ CN: Johann Sibelius
+ SN: Sibelius
+
+ will cause the server to return compareTrue. (Note that the language
+ range option "lang-" matches any language tag option.)
+
+ However, if the client issued a compare request of type
+ "name;lang-de" and assertion value "Sibelius" against the above
+ entry, the request would fail with the noSuchAttributeType error.
+
+ If the server does not support storing attributes with language tag
+ options in the DIT, then any comparison which includes a language
+ range option will always fail to locate an attribute, and
+ noSuchAttributeType will be returned.
+
+4. Discovering Language Option Support
+
+ A server SHOULD indicate that it supports storing attributes with
+ language tag options in the DIT by publishing 1.3.6.1.4.1.4203.1.5.4
+ as a value of the root DSE.
+
+ A server SHOULD indicate that it supports language range matching of
+ attributes with language tag options stored in the DIT by publishing
+ 1.3.6.1.4.1.4203.1.5.5 as a value of the "supportedFeatures"
+ [RFC3674] 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
+ mechanism for determining which subset of attribute types can be used
+ with language tag options.
+
+5. Interoperability with Non-supporting Implementations
+
+ Implementators of this specification should take care that their use
+ of language tag options does not impede proper function of
+ implementations which do not support language tags.
+
+ Per RFC 2251, "an AttributeDescription with one or more options is
+ treated as a subtype of the attribute type without any options." A
+ non-supporting server will treat an AttributeDescription with any
+ language tag options as an unrecognized attribute type. A non-
+ supporting client will either do the same, or will treat the
+ AttributeDescription as it would any other unknown subtype.
+ Typically, non-supporting clients simply ignore unrecognized subtypes
+ (and unrecognized attribute types) of attributes they request.
+
+
+
+Zeilenga Standards Track [Page 11]
+
+RFC 3866 Language Tags and Ranges in LDAP July 2004
+
+
+ To ensure proper function of non-supporting clients, supporting
+ clients SHOULD ensure that entries they populate with tagged values
+ are also populated with non-tagged values.
+
+ Additionally, supporting clients SHOULD be prepared to handle entries
+ which are not populated with tagged values.
+
+6. Security Considerations
+
+ Language tags and range options are used solely to indicate the
+ native language of values and in querying the directory for values
+ which 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 [RFC3377].
+
+7. IANA Considerations
+
+ Registration of these protocol mechanisms [RFC3383] has been
+ completed by the IANA.
+
+ Subject: Request for LDAP Protocol Mechanism Registration
+ Object Identifier: 1.3.6.1.4.1.4203.1.5.4
+ Description: Language Tag Options
+ 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 at openldap.org>
+ Usage: Feature
+ Specification: RFC 3866
+ Author/Change Controller: IESG
+ Comments: none
+
+ These OIDs were assigned [ASSIGN] by OpenLDAP Foundation, under its
+ IANA-assigned private enterprise allocation [PRIVATE], for use in
+ this specification.
+
+8. 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.
+
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 12]
+
+RFC 3866 Language Tags and Ranges in LDAP July 2004
+
+
+9. References
+
+9.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for
+ Syntax Specifications: ABNF", RFC 2234, November 1997.
+
+ [RFC2251] Wahl, M., Howes, T. and S. Kille, "Lightweight
+ Directory Access Protocol (v3)", RFC 2251, December
+ 1997.
+
+ [RFC3066] Alvestrand, H., "Tags for the Identification of
+ Languages", BCP 47, RFC 3066, January 2001.
+
+ [RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access
+ Protocol (v3): Technical Specification", RFC 3377,
+ September 2002.
+
+ [RFC3674] Zeilenga, K., "Feature Discovery in Lightweight
+ Directory Access Protocol (LDAP)", RFC 3674, December
+ 2003.
+
+ [ASCII] Coded Character Set--7-bit American Standard Code for
+ Information Interchange, ANSI X3.4-1986.
+
+9.2. Informative References
+
+ [X.501] International Telecommunication Union -
+ Telecommunication Standardization Sector, "The
+ Directory -- Models," X.501(1997).
+
+ [RFC3383] Zeilenga, K., "Internet Assigned Numbers Authority
+ (IANA) Considerations for Lightweight Directory Access
+ Protocol (LDAP)", BCP 64, 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 Standards Track [Page 13]
+
+RFC 3866 Language Tags and Ranges in LDAP July 2004
+
+
+Appendix A. Differences from RFC 2596
+
+ This document adds support for language ranges, provides a mechanism
+ that a client can use to discover whether a server supports language
+ tags and ranges, and clarifies how attributes with multiple language
+ tags are to be treated. This document is a significant rewrite of
+ RFC 2596.
+
+Appendix B. Differences from X.500(1997)
+
+ X.500(1997) [X.501] defines a different mechanism, contexts, as the
+ means of representing language tags (codes). This section summarizes
+ the major differences in approach.
+
+ a) An X.500 operation which has specified a language code on a value
+ 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 (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.
+
+Editor's Address
+
+ Kurt D. Zeilenga
+ OpenLDAP Foundation
+
+ EMail: Kurt at OpenLDAP.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 14]
+
+RFC 3866 Language Tags and Ranges in LDAP July 2004
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2004). This document is subject
+ to the rights, licenses and restrictions contained in BCP 78, and
+ except as set forth therein, the authors retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at ietf-
+ ipr at ietf.org.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 15]
+
Added: openldap/vendor/openldap-release/doc/rfc/rfc3876.txt
===================================================================
--- openldap/vendor/openldap-release/doc/rfc/rfc3876.txt (rev 0)
+++ openldap/vendor/openldap-release/doc/rfc/rfc3876.txt 2007-09-15 10:38:52 UTC (rev 844)
@@ -0,0 +1,675 @@
+
+
+
+
+
+
+Network Working Group D. Chadwick
+Request for Comments: 3876 University of Salford
+Category: Standards Track S. Mullan
+ Sun Microsystems
+ September 2004
+
+
+ Returning Matched Values with the
+ Lightweight Directory Access Protocol version 3 (LDAPv3)
+
+Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2004).
+
+Abstract
+
+ This document describes a control for the Lightweight Directory
+ Access Protocol version 3 that is used to return a subset of
+ attribute values from an entry. Specifically, only those values that
+ match a "values return" filter. Without support for this control, a
+ client must retrieve all of an attribute's values and search for
+ specific values locally.
+
+1. Introduction
+
+ When reading an attribute from an entry using the Lightweight
+ Directory Access Protocol version 3 (LDAPv3) [2], it is normally only
+ possible to read either the attribute type, or the attribute type and
+ all its values. It is not possible to selectively read just a few of
+ the attribute values. If an attribute holds many values, for
+ example, the userCertificate attribute, or the subschema publishing
+ operational attributes objectClasses and attributeTypes [3], then it
+ may be desirable for the user to be able to selectively retrieve a
+ subset of the values, specifically, those attribute values that match
+ some user defined selection criteria. Without the control specified
+ in this document, a client must read all of the attribute's values
+ and filter out the unwanted values, necessitating the client to
+ implement the matching rules. It also requires the client to
+
+
+
+
+
+Chadwick & Mullan Standards Track [Page 1]
+
+RFC 3876 Returning Matched Values with LDAPv3 September 2004
+
+
+ potentially read and process many irrelevant values, which can be
+ inefficient if the values are large or complex, or there are many
+ values stored per attribute.
+
+ This document specifies an LDAPv3 control to enable a user to return
+ only those values that matched (i.e., returned TRUE to) one or more
+ elements of a newly defined "values return" filter. This control can
+ be especially useful when used in conjunction with extensible
+ matching rules that match on one or more components of complex binary
+ attribute values.
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in BCP 14, RFC 2119 [4].
+
+2. The valuesReturnFilter Control
+
+ The valuesReturnFilter control is either critical or non-critical as
+ determined by the user. It only has meaning for the Search
+ operation, and SHOULD only be added to the Search operation by the
+ client. If the server supports the control and it is present on a
+ Search operation, the server MUST obey the control, regardless of the
+ value of the criticality flag.
+
+ If the control is marked as critical, and either the server does not
+ support the control or the control is applied to an operation other
+ than Search, the server MUST return an unavailableCriticalExtension
+ error. If the control is not marked as critical, and either the
+ server does not support the control or the control is applied to an
+ operation other than Search, then the server MUST ignore the control.
+
+ The object identifier for this control is 1.2.826.0.1.3344810.2.3.
+
+ The controlValue is an OCTET STRING, whose value is the BER encoding
+ [6], as per Section 5.1 of RFC 2251 [2], of a value of the ASN.1 [5]
+ type ValuesReturnFilter.
+
+ ValuesReturnFilter ::= SEQUENCE OF SimpleFilterItem
+
+ SimpleFilterItem ::= CHOICE {
+ equalityMatch [3] AttributeValueAssertion,
+ substrings [4] SubstringFilter,
+ greaterOrEqual [5] AttributeValueAssertion,
+ lessOrEqual [6] AttributeValueAssertion,
+ present [7] AttributeDescription,
+ approxMatch [8] AttributeValueAssertion,
+ extensibleMatch [9] SimpleMatchingAssertion }
+
+
+
+
+Chadwick & Mullan Standards Track [Page 2]
+
+RFC 3876 Returning Matched Values with LDAPv3 September 2004
+
+
+ SimpleMatchingAssertion ::= SEQUENCE {
+ matchingRule [1] MatchingRuleId OPTIONAL,
+ type [2] AttributeDescription OPTIONAL,
+ --- at least one of the above must be present
+ matchValue [3] AssertionValue}
+
+ All the above data types have their standard meanings as defined in
+ [2].
+
+ If the server supports this control, the server MUST make use of the
+ control as follows:
+
+ 1) The Search Filter is first executed in order to determine which
+ entries satisfy the Search criteria (these are the filtered
+ entries). The control has no impact on this step.
+
+ 2) If the typesOnly parameter of the Search Request is TRUE, the
+ control has no effect and the Search Request is processed as if
+ the control had not been specified.
+
+ 3) If the attributes parameter of the Search Request consists of a
+ list containing only the attribute with OID "1.1" (specifying that
+ no attributes are to be returned), the control has no effect and
+ the Search Request is processed as if the control had not been
+ specified.
+
+ 4) For each attribute listed in the attributes parameter of the
+ Search Request, the server MUST apply the control as follows to
+ each entry in the set of filtered entries:
+
+ i) Every attribute value that evaluates TRUE against one or more
+ elements of the ValuesReturnFilter is placed in the
+ corresponding SearchResultEntry.
+
+ ii) Every attribute value that evaluates FALSE or undefined
+ against all elements of the ValuesReturnFilter is not placed
+ in the corresponding SearchResultEntry. An attribute that has
+ no values selected is returned with an empty set of values.
+
+ Note. If the AttributeDescriptionList (see [2]) is empty or
+ comprises "*", then the control MUST be applied against every user
+ attribute. If the AttributeDescriptionList contains a "+", then the
+ control MUST be applied against every operational attribute.
+
+
+
+
+
+
+
+
+Chadwick & Mullan Standards Track [Page 3]
+
+RFC 3876 Returning Matched Values with LDAPv3 September 2004
+
+
+3. Relationship to X.500
+
+ The control is a superset of the matchedValuesOnly (MVO) boolean of
+ the X.500 Directory Access Protocol (DAP) [8] Search argument, as
+ amended in the latest version [9]. Close examination of the
+ matchedValuesOnly boolean by the LDAP Extensions (LDAPEXT) Working
+ Group revealed ambiguities and complexities in the MVO boolean that
+ could not easily be resolved. For example, it was not clear if the
+ MVO boolean governed only those attribute values that contributed to
+ the overall truth of the filter, or all of the attribute values, even
+ if the filter item containing the attribute was evaluated as false.
+ For this reason the LDAPEXT group decided to replace the MVO boolean
+ with a simple filter that removes any uncertainty as to whether an
+ attribute value has been selected or not.
+
+4. Relationship to other LDAP Controls
+
+ The purpose of this control is to select zero, one, or more attribute
+ values from each requested attribute in a filtered entry, and to
+ discard the remainder. Once the attribute values have been discarded
+ by this control, they MUST NOT be re-instated into the Search results
+ by other controls.
+
+ This control acts independently of other LDAP controls such as server
+ side sorting [13] and duplicate entries [10]. However, there might
+ be interactions between this control and other controls so that a
+ different set of Search Result Entries are returned, or the entries
+ are returned in a different order, depending upon the sequencing of
+ this control and other controls in the LDAP request. For example,
+ with server side sorting, if sorting is done first, and value return
+ filtering second, the set of Search Results may appear to be in the
+ wrong order since the value filtering may remove the attribute values
+ upon which the ordering was done. (The sorting document specifies
+ that entries without any sort key attribute values should be treated
+ as coming after all other attribute values.) Similarly with
+ duplicate entries, if duplication is performed before value
+ filtering, the set of Search Result Entries may contain identical
+ duplicate entries, each with an empty set of attribute values,
+ because the value filtering removed the attribute values that were
+ used to duplicate the results.
+
+ For these reasons, the ValuesReturnFilter control in a SearchRequest
+ SHOULD precede other controls that affect the number and ordering of
+ SearchResultEntrys.
+
+
+
+
+
+
+
+Chadwick & Mullan Standards Track [Page 4]
+
+RFC 3876 Returning Matched Values with LDAPv3 September 2004
+
+
+5. Examples
+
+ All entries are provided in an LDAP Data Interchange Format
+ (LDIF)[11].
+
+ The string representation of the valuesReturnFilter in the examples
+ below uses the following ABNF [15] notation:
+
+ valuesReturnFilter = "(" 1*simpleFilterItem ")"
+ simpleFilterItem = "(" item ")"
+
+ where item is as defined below (adapted from RFC2254 [14]).
+
+ item = simple / present / substring / extensible
+ simple = attr filtertype value
+ filtertype = equal / approx / greater / less
+ equal = "="
+ approx = "~="
+ greater = ">="
+ less = "<="
+ extensible = attr [":" matchingrule] ":=" value
+ / ":" matchingrule ":=" value
+ present = attr "=*"
+ substring = attr "=" [initial] any [final]
+ initial = value
+ any = "*" *(value "*")
+ final = value
+ attr = AttributeDescription from Section 4.1.5 of [1]
+ matchingrule = MatchingRuleId from Section 4.1.9 of [1]
+ value = AttributeValue from Section 4.1.6 of [1]
+
+ 1) The first example shows how the control can be set to return all
+ attribute values from one attribute type (e.g., telephoneNumber)
+ and a subset of values from another attribute type (e.g., mail).
+
+ The entries below represent organizationalPerson object classes
+ located somewhere beneath the distinguished name dc=ac,dc=uk.
+
+ dn: cn=Sean Mullan,ou=people,dc=sun,dc=ac,dc=uk
+ cn: Sean Mullan
+ sn: Mullan
+ objectClass: organizationalPerson
+ objectClass: person
+ objectClass: inetOrgPerson
+ mail: sean.mullan at hotmail.com
+ mail: mullan at east.sun.com
+ telephoneNumber: + 781 442 0926
+ telephoneNumber: 555-9999
+
+
+
+Chadwick & Mullan Standards Track [Page 5]
+
+RFC 3876 Returning Matched Values with LDAPv3 September 2004
+
+
+ dn: cn=David Chadwick,ou=isi,o=salford,dc=ac,dc=uk
+ cn: David Chadwick
+ sn: Chadwick
+ objectClass: organizationalPerson
+ objectClass: person
+ objectClass: inetOrgPerson
+ mail: d.w.chadwick at salford.ac.uk
+
+ An LDAP search operation is specified with a baseObject set to the DN
+ of the search base (i.e., dc=ac,dc=uk), a subtree scope, a filter set
+ to (sn=mullan), and the list of attributes to be returned set to
+ "mail,telephoneNumber" or "*". In addition, a ValuesReturnFilter
+ control is set to ((mail=*hotmail.com)(telephoneNumber=*)).
+
+ The search results returned by the server would consist of the
+ following entry:
+
+ dn: cn=Sean Mullan,ou=people,dc=sun,dc=ac,dc=uk
+ mail: sean.mullan at hotmail.com
+ telephoneNumber: + 781 442 0926
+ telephoneNumber: 555-9999
+
+ Note that the control has no effect on the values returned for the
+ "telephoneNumber" attribute (all of the values are returned), since
+ the control specified that all values should be returned.
+
+ 2) The second example shows how one might retrieve a single attribute
+ type subschema definition for the "gunk" attribute with OID
+ 1.2.3.4.5 from the subschema subentry.
+
+ Assume the subschema subentry is held below the root entry with DN
+ cn=subschema subentry,o=myorg and this holds an attributeTypes
+ operational attribute holding the descriptions of the 35 attributes
+ known to this server (each description is held as a single attribute
+ value of the attributeTypes attribute).
+
+ dn: cn=subschema subentry,o=myorg
+ cn: subschema subentry
+ objectClass: subschema
+ attributeTypes: ( 2.5.4.3 NAME 'cn' SUP name )
+ attributeTypes: ( 2.5.4.6 NAME 'c' SUP name SINGLE-VALUE )
+ attributeTypes: ( 2.5.4.0 NAME 'objectClass' EQUALITY obj
+ ectIdentifierMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
+ attributeTypes: ( 2.5.18.2 NAME 'modifyTimestamp' EQUALITY gen
+ eralizedTimeMatch ORDERING generalizedTimeOrderingMatch SYN
+ TAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE NO-USER-
+ MODIFICATION USAGE directoryOperation )
+ attributeTypes: ( 2.5.21.6 NAME 'objectClasses' EQUALITY obj
+
+
+
+Chadwick & Mullan Standards Track [Page 6]
+
+RFC 3876 Returning Matched Values with LDAPv3 September 2004
+
+
+ ectIdentifierFirstComponentMatch SYNTAX 1.3.
+ 6.1.4.1.1466.115.121.1.37 USAGE directoryOperation )
+ attributeTypes: ( 1.2.3.4.5 NAME 'gunk' EQUALITY caseIgnoreMat
+ ch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.
+ 6.1.4.1.1466.115.121.1.44{64} )
+ attributeTypes: ( 2.5.21.5 NAME 'attributeTypes' EQUALITY obj
+ ectIdentifierFirstComponentMatch SYNTAX 1.3.
+ 6.1.4.1.1466.115.121.1.3 USAGE directoryOperation )
+
+ plus another 28 - you get the idea.
+
+ The user creates an LDAP search operation with a baseObject set to
+ cn=subschema subentry,o=myorg, a scope of base, a filter set to
+ (objectClass=subschema), the list of attributes to be returned set to
+ "attributeTypes", and the ValuesReturnFilter set to
+ ((attributeTypes=1.2.3.4.5))
+
+ The search result returned by the server would consist of the
+ following entry:
+
+ dn: cn=subschema subentry,o=myorg
+ attributeTypes: ( 1.2.3.4.5 NAME 'gunk' EQUALITY caseIgnoreMat
+ ch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.
+ 6.1.4.1.1466.115.121.1.44{64} )
+
+ 3) The final example shows how the control can be used to match on a
+ userCertificate attribute value. Note that this example requires
+ the LDAP server to support the certificateExactMatch matching rule
+ defined in [12] as the EQUALITY matching rule for userCertificate.
+
+ The entry below represents a pkiUser object class stored in the
+ directory.
+
+ dn: cn=David Chadwick,ou=people,o=University of Salford,c=gb
+ cn: David Chadwick
+ objectClass: person
+ objectClass: organizationalPerson
+ objectClass: pkiUser
+ objectClass: inetOrgPerson
+ sn: Chadwick
+ mail: d.w.chadwick at salford.ac.uk
+ userCertificate;binary: {binary representation of a certificate with
+ a serial number of 2468 issued by o=truetrust ltd,c=gb}
+ userCertificate;binary: {binary representation of certificate with a
+ serial number of 1357 issued by o=truetrust ltd,c=gb}
+ userCertificate;binary: {binary representation of certificate with a
+ serial number of 1234 issued by dc=certsRus,dc=com}
+
+
+
+
+Chadwick & Mullan Standards Track [Page 7]
+
+RFC 3876 Returning Matched Values with LDAPv3 September 2004
+
+
+ An LDAP search operation is specified with a baseObject set to
+ o=University of Salford,c=gb, a subtree scope, a filter set to
+ (sn=chadwick), and the list of attributes to be returned set to
+ "userCertificate;binary". In addition, a ValuesReturnFilter control
+ is set to ((userCertificate=1357$o=truetrust ltd,c=gb)).
+
+ The search result returned by the server would consist of the
+ following entry:
+
+ dn: cn=David Chadwick,ou=people,o=University of Salford,c=gb
+ userCertificate;binary: {binary representation of certificate with a
+ serial number of 1357 issued by o=truetrust ltd,c=gb}
+
+6. Security Considerations
+
+ This document does not primarily discuss security issues.
+
+ Note however that attribute values MUST only be returned if the
+ access controls applied by the LDAP server allow them to be returned,
+ and in this respect the effect of the ValuesReturnFilter control is
+ of no consequence.
+
+ Note that the ValuesReturnFilter control may have a positive effect
+ on the deployment of public key infrastructures. Certain PKI
+ operations, like searching for specific certificates, become more
+ scalable, and more practical when combined with X.509 certificate
+ matching rules at the server, since the control avoids the
+ downloading of potentially large numbers of irrelevant certificates
+ which would have to be processed and filtered locally (which in some
+ cases is very difficult to perform).
+
+7. IANA Considerations
+
+ The Matched Values control as an LDAP Protocol Mechanism [7] has been
+ registered as follows:
+
+ Subject: Request for LDAP Protocol Mechanism Registration
+
+ Object Identifier: 1.2.826.0.1.3344810.2.3
+ Description: Matched Values Control
+ Person & email address to contact for further information:
+ David Chadwick <d.w.chadwick at salford.ac.uk>
+ Usage: Control
+ Specification: RFC3876
+ Author/Change Controller: IESG
+ Comments: none
+
+
+
+
+
+Chadwick & Mullan Standards Track [Page 8]
+
+RFC 3876 Returning Matched Values with LDAPv3 September 2004
+
+
+ This document uses the OID 1.2.826.0.1.3344810.2.3 to identify the
+ matchedValues control described here. This OID was assigned by
+ TrueTrust Ltd, under its BSI assigned English/Welsh Registered
+ Company number [16].
+
+8. Acknowledgements
+
+ The authors would like to thank members of the LDAPExt list for their
+ constructive comments on earlier versions of this document, and in
+ particular to Harald Alvestrand who first suggested having an
+ attribute return filter and Bruce Greenblatt who first proposed a
+ syntax for this control.
+
+9. References
+
+9.1. Normative References
+
+ [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
+ 9, RFC 2026, October 1996.
+
+ [2] Wahl, M., Howes, T., and S. Kille, "Lightweight Directory Access
+ Protocol (w3)", RFC 2251, December 1997.
+
+ [3] Wahl, M., Coulbeck, A., Howes, T., and S. Kille, "Lightweight
+ Directory Access Protocol (v3): Attribute Syntax Definitions",
+ RFC 2252, December 1997.
+
+ [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+ Levels", BCP 14, RFC 2119, March 1997.
+
+ [5] ITU-T Recommendation X.680 (1997) | ISO/IEC 8824-1:1998,
+ Information Technology - Abstract Syntax Notation One (ASN.1):
+ Specification of Basic Notation
+
+ [6] ITU-T Recommendation X.690 (1997) | ISO/IEC 8825-1,2,3:1998
+ Information technology - ASN.1 encoding rules: Specification of
+ Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and
+ Distinguished Encoding Rules (DER)
+
+ [7] Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
+ Considerations for the Lightweight Directory Access Protocol
+ (LDAP)", BCP 64, RFC 3383, September 2002.
+
+
+
+
+
+
+
+
+
+Chadwick & Mullan Standards Track [Page 9]
+
+RFC 3876 Returning Matched Values with LDAPv3 September 2004
+
+
+9.2. Informative References
+
+ [8] ITU-T Rec. X.511, "The Directory: Abstract Service Definition",
+ 1993.
+
+ [9] ISO/IEC 9594 / ITU-T Rec X.511 (2001) The Directory: Abstract
+ Service Definition.
+
+ [10] Sermersheim, J., "LDAP Control for a Duplicate Entry
+ Representation of Search Results", Work in Progress, October
+ 2000.
+
+ [11] Good, G., "The LDAP Data Interchange Format (LDIF) - Technical
+ Specification", RFC 2849, June 2000.
+
+ [12] Chadwick, D. and S.Legg, "Internet X.509 Public Key
+ Infrastructure - Additional LDAP Schema for PKIs", Work in
+ Progress, June 2002
+
+ [13] Howes, T., Wahl, M., and A. Anantha, "LDAP Control Extension for
+ Server Side Sorting of Search Results", RFC 2891, August 2000.
+
+ [14] Howes, T., "The String Representation of LDAP Search Filters",
+ RFC 2254, December 1997.
+
+ [15] Crocker, D. and P. Overell, "Augmented BNF for Syntax
+ Specifications: ABNF", RFC 2234, November 1997.
+
+ [16] BRITISH STANDARD BS 7453 Part 1. Procedures for UK Registration
+ for Open System Standards Part 1: Procedures for the UK Name
+ Registration Authority.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Chadwick & Mullan Standards Track [Page 10]
+
+RFC 3876 Returning Matched Values with LDAPv3 September 2004
+
+
+10. Authors' Addresses
+
+ David Chadwick
+ IS Institute
+ University of Salford
+ Salford M5 4WT
+ England
+
+ Phone: +44 161 295 5351
+ EMail: d.w.chadwick at salford.ac.uk
+
+
+ Sean Mullan
+ Sun Microsystems
+ One Network Drive
+ Burlington, MA 01803
+ USA
+
+ EMail: sean.mullan at sun.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Chadwick & Mullan Standards Track [Page 11]
+
+RFC 3876 Returning Matched Values with LDAPv3 September 2004
+
+
+11. Full Copyright Statement
+
+ Copyright (C) The Internet Society (2004).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/S HE
+ REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
+ INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
+ IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
+ THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the IETF's procedures with respect to rights in IETF Documents can
+ be found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at ietf-
+ ipr at ietf.org.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+Chadwick & Mullan Standards Track [Page 12]
+
Added: openldap/vendor/openldap-release/doc/rfc/rfc3909.txt
===================================================================
--- openldap/vendor/openldap-release/doc/rfc/rfc3909.txt (rev 0)
+++ openldap/vendor/openldap-release/doc/rfc/rfc3909.txt 2007-09-15 10:38:52 UTC (rev 844)
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+Network Working Group K. Zeilenga
+Request for Comments: 3909 OpenLDAP Foundation
+Category: Standards Track October 2004
+
+
+ Lightweight Directory Access Protocol (LDAP)
+ Cancel Operation
+
+Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2004).
+
+Abstract
+
+ This specification describes a Lightweight Directory Access Protocol
+ (LDAP) extended operation to cancel (or abandon) an outstanding
+ operation. Unlike the LDAP Abandon operation, but like the X.511
+ Directory Access Protocol (DAP) Abandon operation, this operation has
+ a response which provides an indication of its outcome.
+
+1. Background and Intent of Use
+
+ The Lightweight Directory Access Protocol (LDAP) [RFC3377] provides
+ an Abandon operation [RFC2251] which clients may use to cancel other
+ operations. The Abandon operation does not have a response and
+ requires no response from the abandoned operation. These semantics
+ provide the client with no clear indication of the outcome of the
+ Abandon operation.
+
+ The X.511 Directory Access Protocol (DAP) [X.511] provides an Abandon
+ operation which has a response and also requires the abandoned
+ operation to return a response indicating it was canceled. The LDAP
+ Cancel operation is modeled after the DAP Abandon operation.
+
+ 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.
+
+
+
+
+
+Zeilenga Standards Track [Page 1]
+
+RFC 3909 LDAP Cancel Operation October 2004
+
+
+ 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].
+
+2. Cancel Operation
+
+ The Cancel operation is defined as an LDAP Extended Operation
+ [RFC2251, Section 4.12] identified by the object identifier
+ 1.3.6.1.1.8. This section details the syntax of the Cancel request
+ and response messages and defines additional LDAP resultCodes.
+
+2.1. Cancel Request
+
+ The Cancel request is an ExtendedRequest with the requestName field
+ containing 1.3.6.1.1.8 and a requestValue field which contains a
+ BER-encoded cancelRequestValue value.
+
+ cancelRequestValue ::= SEQUENCE {
+ cancelID MessageID
+ -- MessageID is as defined in [RFC2251]
+ }
+
+ The cancelID field contains the message ID associated with the
+ operation to be canceled.
+
+2.2. Cancel Response
+
+ A Cancel response is an ExtendedResponse where the responseName and
+ response fields are absent.
+
+2.3. Additional Result Codes
+
+ Implementations of this specification SHALL recognize the following
+ additional resultCode values:
+
+ canceled (118)
+ noSuchOperation (119)
+ tooLate (120)
+ cannotCancel (121)
+
+
+
+
+Zeilenga Standards Track [Page 2]
+
+RFC 3909 LDAP Cancel Operation October 2004
+
+
+3. Operational Semantics
+
+ The function of the Cancel Operation is to request that the server
+ 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 set to the message ID of
+ the outstanding operation. The Cancel Request itself has a distinct
+ message ID. Clients SHOULD NOT request the 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
+ with a success resultCode, and the canceled operation SHALL fail with
+ canceled resultCode. Otherwise the Cancel Response SHALL have a
+ non-success resultCode and SHALL NOT have an impact upon the
+ outstanding operation (if it exists).
+
+ The protocolError resultCode is returned if the server is unable to
+ parse the requestValue or the requestValue is absent,
+
+ The noSuchOperation resultCode is returned if the server has no
+ knowledge of the operation requested for cancelation.
+
+ 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:
+
+ - operations which have no response,
+
+ - operations which create, alter, or destroy authentication and/or
+ authorization associations,
+
+ - operations which establish, alter, or tear-down security services,
+ and
+
+ - operations which abandon or cancel other operations.
+
+ Specifically, the Abandon, Bind, Start TLS [RFC2830], Unbind, and
+ Cancel operations are not cancelable.
+
+ The Cancel operation cannot be abandoned.
+
+ 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
+ has already committed updates to the underlying data store.
+
+
+
+
+Zeilenga Standards Track [Page 3]
+
+RFC 3909 LDAP Cancel Operation October 2004
+
+
+ Servers SHOULD indicate their support for this extended operation by
+ providing 1.3.6.1.1.8 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 it.
+
+4. Security Considerations
+
+ This operation is intended to allow a 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 the cancelation of the Bind operation and
+ Start TLS extended operation so as to avoid adding complexity to
+ authentication, authorization, and security layer semantics.
+ Designers of future extended operations and/or controls should
+ disallow abandonment and cancelation when appropriate.
+
+5. IANA Considerations
+
+ The following values [RFC3383] have been registered by the IANA.
+
+5.1. Object Identifier
+
+ The IANA has registered upon Standards Action the LDAP Object
+ Identifier 1.3.6.1.1.8 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 at OpenLDAP.org>
+ Specification: RFC 3909
+ Author/Change Controller: IESG
+ Comments:
+ Identifies the LDAP Cancel Operation
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 4]
+
+RFC 3909 LDAP Cancel Operation October 2004
+
+
+5.2. LDAP Protocol Mechanism
+
+ The IANA has registered upon Standards Action the LDAP Protocol
+ Mechanism described in this document.
+
+ Subject: LDAP Protocol Mechanism Registration
+ Object Identifier: 1.3.6.1.1.8
+ Description: LDAP Cancel Operation
+ Person & email address to contact for further information:
+ Kurt Zeilenga <kurt at openldap.org>
+ Usage: Extended Operation
+ Specification: RFC 3909
+ Author/Change Controller: IESG
+ Comments: none
+
+5.3. LDAP Result Codes
+
+ The IANA has registered upon Standards Action the LDAP Result Codes
+ described in this document.
+
+ Subject: LDAP Result Code Registration
+ Person & email address to contact for further information:
+ Kurt Zeilenga <kurt at OpenLDAP.org>
+ Result Code Name: canceled (118)
+ Result Code Name: noSuchOperation (119)
+ Result Code Name: tooLate (120)
+ Result Code Name: cannotCancel (121)
+ Specification: RFC 3909
+ Author/Change Controller: IESG
+
+6. Acknowledgment
+
+ The LDAP Cancel operation is modeled after the X.511 DAP Abandon
+ operation.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 5]
+
+RFC 3909 LDAP Cancel Operation October 2004
+
+
+7. References
+
+7.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2251] Wahl, M., Howes, T., and S. Kille, "Lightweight Directory
+ Access Protocol (v3)", RFC 2251, December 1997.
+
+ [RFC2830] Hodges, J., Morgan, R., and M. Wahl, "Lightweight
+ Directory Access Protocol (v3): Extension for Transport
+ Layer Security", RFC 2830, May 2000.
+
+ [RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access
+ Protocol (v3): Technical Specification", RFC 3377,
+ September 2002.
+
+ [X.680] International Telecommunication Union - Telecommunication
+ Standardization Sector, "Abstract Syntax Notation One
+ (ASN.1) - Specification of Basic Notation", X.680(1997)
+ (also ISO/IEC 8824-1:1998).
+
+ [X.690] International Telecommunication Union - Telecommunication
+ Standardization Sector, "Specification of ASN.1 encoding
+ rules: Basic Encoding Rules (BER), Canonical Encoding
+ Rules (CER), and Distinguished Encoding Rules (DER)",
+ X.690(1997) (also ISO/IEC 8825-1:1998).
+
+7.2. Informative References
+
+ [RFC3383] Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
+ Considerations for the Lightweight Directory Access
+ Protocol (LDAP)", BCP 64, RFC 3383, September 2002.
+
+ [X.511] International Telecommunication Union - Telecommunication
+ Standardization Sector, "The Directory: Abstract Service
+ Definition", X.511(1993).
+
+8. Author's Address
+
+ Kurt D. Zeilenga
+ OpenLDAP Foundation
+
+ EMail: Kurt at OpenLDAP.org
+
+
+
+
+
+
+Zeilenga Standards Track [Page 6]
+
+RFC 3909 LDAP Cancel Operation October 2004
+
+
+9. Full Copyright Statement
+
+ Copyright (C) The Internet Society (2004).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and at www.rfc-editor.org, and except as set
+ forth therein, the authors retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the ISOC's procedures with respect to rights in ISOC Documents can
+ be found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at ietf-
+ ipr at ietf.org.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 7]
+
Added: openldap/vendor/openldap-release/doc/rfc/rfc3928.txt
===================================================================
--- openldap/vendor/openldap-release/doc/rfc/rfc3928.txt (rev 0)
+++ openldap/vendor/openldap-release/doc/rfc/rfc3928.txt 2007-09-15 10:38:52 UTC (rev 844)
@@ -0,0 +1,1683 @@
+
+
+
+
+
+
+Network Working Group R. Megginson, Ed.
+Request for Comments: 3928 Netscape Communications Corp.
+Category: Standards Track M. Smith
+ Pearl Crescent, LLC
+ O. Natkovich
+ Yahoo
+ J. Parham
+ Microsoft Corporation
+ October 2004
+
+
+ Lightweight Directory Access Protocol (LDAP)
+ Client Update Protocol (LCUP)
+
+Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2004).
+
+Abstract
+
+ This document defines the Lightweight Directory Access Protocol
+ (LDAP) Client Update Protocol (LCUP). The protocol is intended to
+ allow an LDAP client to synchronize with the content of a directory
+ information tree (DIT) stored by an LDAP server and to be notified
+ about the changes to that content.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Megginson, et al. Standards Track [Page 1]
+
+RFC 3928 LDAP Client Update Protocol October 2004
+
+
+Table of Contents
+
+ 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 2. Applicability. . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 3. Specification of Protocol Elements . . . . . . . . . . . . . . 5
+ 3.1. ASN.1 Considerations . . . . . . . . . . . . . . . . . . 5
+ 3.2. Universally Unique Identifiers . . . . . . . . . . . . . 5
+ 3.3. LCUP Scheme and LCUP Cookie. . . . . . . . . . . . . . . 5
+ 3.4. LCUP Context . . . . . . . . . . . . . . . . . . . . . . 6
+ 3.5. Additional LDAP Result Codes defined by LCUP . . . . . . 6
+ 3.6. Sync Request Control . . . . . . . . . . . . . . . . . . 7
+ 3.7. Sync Update Control. . . . . . . . . . . . . . . . . . . 7
+ 3.8. Sync Done Control. . . . . . . . . . . . . . . . . . . . 8
+ 4. Protocol Usage and Flow. . . . . . . . . . . . . . . . . . . . 8
+ 4.1. LCUP Search Requests . . . . . . . . . . . . . . . . . . 8
+ 4.1.1. Initial Synchronization and Full Resync . . . . . 9
+ 4.1.2. Incremental or Update Synchronization . . . . . . 10
+ 4.1.3. Persistent Only . . . . . . . . . . . . . . . . . 10
+ 4.2. LCUP Search Responses. . . . . . . . . . . . . . . . . . 10
+ 4.2.1. Sync Update Informational Responses . . . . . . . 11
+ 4.2.2. Cookie Return Frequency . . . . . . . . . . . . . 11
+ 4.2.3. Definition of an Entry That Has Entered the
+ Result Set. . . . . . . . . . . . . . . . . . . . 12
+ 4.2.4. Definition of an Entry That Has Changed . . . . . 13
+ 4.2.5. Definition of an Entry That Has Left the
+ Result Set. . . . . . . . . . . . . . . . . . . . 13
+ 4.2.6. Results For Entries Present in the Result Set . . 14
+ 4.2.7. Results For Entries That Have Left the Result
+ Set . . . . . . . . . . . . . . . . . . . . . . . 14
+ 4.3. Responses Requiring Special Consideration . . . . . . . . 15
+ 4.3.1. Returning Results During the Persistent Phase . . 15
+ 4.3.2. No Mixing of Sync Phase with Persist Phase. . . . 16
+ 4.3.3. Returning Updated Results During the Sync Phase . 16
+ 4.3.4. Operational Attributes and Administrative
+ Entries . . . . . . . . . . . . . . . . . . . . . 16
+ 4.3.5. Virtual Attributes. . . . . . . . . . . . . . . . 17
+ 4.3.6. Modify DN and Delete Operations Applied to
+ Subtrees. . . . . . . . . . . . . . . . . . . . . 17
+ 4.3.7. Convergence Guarantees. . . . . . . . . . . . . . 18
+ 4.4. LCUP Search Termination. . . . . . . . . . . . . . . . . 18
+ 4.4.1. Server Initiated Termination. . . . . . . . . . . 18
+ 4.4.2. Client Initiated Termination. . . . . . . . . . . 19
+ 4.5. Size and Time Limits . . . . . . . . . . . . . . . . . . 19
+ 4.6. Operations on the Same Connection. . . . . . . . . . . . 19
+ 4.7. Interactions with Other Controls . . . . . . . . . . . . 19
+ 4.8. Replication Considerations . . . . . . . . . . . . . . . 20
+ 5. Client Side Considerations . . . . . . . . . . . . . . . . . . 20
+ 5.1. Using Cookies with Different Search Criteria . . . . . . 20
+
+
+
+Megginson, et al. Standards Track [Page 2]
+
+RFC 3928 LDAP Client Update Protocol October 2004
+
+
+ 5.2. Renaming the Base Object . . . . . . . . . . . . . . . . 20
+ 5.3. Use of Persistent Searches With Respect to Resources . . 21
+ 5.4. Continuation References to Other LCUP Contexts . . . . . 21
+ 5.5. Referral Handling. . . . . . . . . . . . . . . . . . . . 21
+ 5.6. Multiple Copies of Same Entry During Sync Phase. . . . . 21
+ 5.7. Handling Server Out of Resources Condition . . . . . . . 21
+ 6. Server Implementation Considerations . . . . . . . . . . . . . 22
+ 6.1. Server Support for UUIDs . . . . . . . . . . . . . . . . 22
+ 6.2. Example of Using an RUV as the Cookie Value. . . . . . . 22
+ 6.3. Cookie Support Issues. . . . . . . . . . . . . . . . . . 22
+ 6.3.1. Support for Multiple Cookie Schemes . . . . . . . 22
+ 6.3.2. Information Contained in the Cookie . . . . . . . 23
+ 6.4. Persist Phase Response Time. . . . . . . . . . . . . . . 23
+ 6.5. Scaling Considerations . . . . . . . . . . . . . . . . . 23
+ 6.6. Alias Dereferencing. . . . . . . . . . . . . . . . . . . 24
+ 7. Synchronizing Heterogeneous Data Stores. . . . . . . . . . . . 24
+ 8. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 24
+ 9. Security Considerations. . . . . . . . . . . . . . . . . . . . 24
+ 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
+ 10.1. Normative References . . . . . . . . . . . . . . . . . . 25
+ 10.2. Informative References . . . . . . . . . . . . . . . . . 26
+ 11. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 26
+ Appendix - Features Left Out of LCUP . . . . . . . . . . . . . . . 27
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29
+ Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 30
+
+1. Overview
+
+ The LCUP protocol is intended to allow LDAP clients to synchronize
+ with the content stored by LDAP servers.
+
+ The problem areas addressed by the protocol include:
+
+ - Mobile clients that maintain a local read-only copy of the
+ directory data. While off-line, the client uses the local copy of
+ the data. When the client connects to the network, it
+ synchronizes with the current directory content and can optionally
+ receive notification about the changes that occur while it is on-
+ line. For example, a mail client can maintain a local copy of the
+ corporate address book that it synchronizes with the master copy
+ whenever the client is connected to the corporate network.
+
+ - Applications intending to synchronize heterogeneous data stores.
+ A meta directory application, for instance, would periodically
+ retrieve a list of modified entries from the directory, construct
+ the changes and apply them to a foreign data store.
+
+
+
+
+
+Megginson, et al. Standards Track [Page 3]
+
+RFC 3928 LDAP Client Update Protocol October 2004
+
+
+ - Clients that need to take certain actions when a directory entry
+ is modified. For instance, an electronic mail repository may want
+ to perform a "create mailbox" task when a new person entry is
+ added to an LDAP directory and a "delete mailbox" task when a
+ person entry is removed.
+
+ The problem areas not being considered:
+
+ - Directory server to directory server synchronization. The IETF is
+ developing a LDAP replication protocol, called LDUP [RFC3384],
+ which is specifically designed to address this problem area.
+
+ There are currently several protocols in use for LDAP client server
+ synchronization. While each protocol addresses the needs of a
+ particular group of clients (e.g., on-line clients or off-line
+ clients), none satisfies the requirements of all clients in the
+ target group. For instance, a mobile client that was off-line and
+ wants to become up to date with the server and stay up to date while
+ connected can't be easily supported by any of the existing protocols.
+
+ LCUP is designed such that the server does not need to maintain state
+ information specific to individual clients. The server may need to
+ maintain additional state information about attribute modifications,
+ deleted entries, and moved/renamed entries. The clients are
+ responsible for storing the information about how up to date they are
+ with respect to the server's content. LCUP design avoids the need
+ for LCUP-specific update agreements to be made between client and
+ server prior to LCUP use. The client decides when and from where to
+ retrieve the changes. LCUP design requires clients to initiate the
+ update session and "pull" the changes from server.
+
+ LCUP operations are subject to administrative and access control
+ policies enforced by the server.
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in BCP 14, RFC 2119
+ [RFC2119].
+
+2. Applicability
+
+ LCUP will work best if the following conditions are met:
+
+ 1) The server stores some degree of historical state or change
+ information to reduce the amount of wire traffic required for
+ incremental synchronizations. The optimal balance between server
+ state and wire traffic varies amongst implementations and usage
+ scenarios, and is therefore left in the hands of implementers.
+
+
+
+Megginson, et al. Standards Track [Page 4]
+
+RFC 3928 LDAP Client Update Protocol October 2004
+
+
+ 2) The client cannot be assumed to understand the physical
+ information model (virtual attributes, operational attributes,
+ subentries, etc.) implemented by the server. Optimizations would
+ be possible if such assumptions could be made.
+
+ 3) Meta data changes and renames and deletions of large subtrees are
+ very infrequent. LCUP makes these assumptions in order to reduce
+ client complexity required to deal with these special operations,
+ though when they do occur they may result in a large number of
+ incremental update messages or a full resync.
+
+3. Specification of Protocol Elements
+
+ The following sections define the new elements required to use this
+ protocol.
+
+3.1. ASN.1 Considerations
+
+ 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]. All ASN.1 in this document uses implicit tags.
+
+3.2. Universally Unique Identifiers
+
+ Distinguished names can change, so are therefore unreliable as
+ identifiers. A Universally Unique Identifier (or UUID for short)
+ MUST be used to uniquely identify entries used with LCUP. The UUID
+ is part of the Sync Update control value (see below) returned with
+ each search result. The server SHOULD provide the UUID as a single
+ valued operational attribute of the entry (e.g., "entryUUID"). We
+ RECOMMEND that the server provides a way to do efficient (i.e.,
+ indexed) searches for values of UUID, e.g., by using a search filter
+ like (entryUUID=<some UUID value>) to quickly search for and retrieve
+ an entry based on its UUID. Servers SHOULD use a UUID format as
+ specified in [UUID]. The UUID used by LCUP is a value of the
+ following ASN.1 type:
+
+ LCUPUUID ::= OCTET STRING
+
+3.3. LCUP Scheme and LCUP Cookie
+
+ The LCUP protocol uses a cookie to hold the state of the client's
+ data with respect to the server's data. Each cookie format is
+ uniquely identified by its scheme. The LCUP Scheme is a value of the
+ following ASN.1 type:
+
+ LCUPScheme ::= LDAPOID
+
+
+
+Megginson, et al. Standards Track [Page 5]
+
+RFC 3928 LDAP Client Update Protocol October 2004
+
+
+ This is the OID which identifies the format of the LCUP Cookie value.
+ The scheme OID, as all object identifiers, MUST be unique for a given
+ cookie scheme. The cookie value may be opaque or it may be exposed
+ to LCUP clients. For cookie schemes that expose their value, the
+ preferred form of documentation is an RFC. It is expected that there
+ will be one or more standards track cookie schemes where the value
+ format is exposed and described in detail.
+
+ The LCUP Cookie is a value of the following ASN.1 type:
+
+ LCUPCookie ::= OCTET STRING
+
+ This is the actual data describing the state of the client's data.
+ This value may be opaque, or its value may have some well-known
+ format, depending on the scheme.
+
+ Further uses of the LCUP Cookie value are described below.
+
+3.4. LCUP Context
+
+ A part of the DIT which is enabled for LCUP is referred to as an LCUP
+ Context. A server may support one or more LCUP Contexts. For
+ example, a server with two naming contexts may support LCUP in one
+ naming context but not the other, or support different LCUP cookie
+ schemes in each naming context. Each LCUP Context MAY use a
+ different cookie scheme. An LCUP search will not cross an LCUP
+ Context boundary, but will instead return a SearchResultReference
+ message, with the LDAP URL specifying the same host and port as
+ currently being searched, and with the baseDN set to the baseDN of
+ the new LCUP Context. The client is then responsible for issuing
+ another search using the new baseDN, and possibly a different cookie
+ if that LCUP Context uses a different cookie. The client is
+ responsible for maintaining a mapping of the LDAP URL to its
+ corresponding cookie.
+
+3.5. Additional LDAP Result Codes defined by LCUP
+
+ Implementations of this specification SHALL recognize the following
+ additional resultCode values. The LDAP result code names and numbers
+ defined in the following table have been assigned by IANA per RFC
+ 3383 [RFC3383].
+
+ lcupResourcesExhausted (113) the server is running out of resources
+ lcupSecurityViolation (114) the client is suspected of malicious
+ actions
+ lcupInvalidData (115) invalid scheme or cookie was supplied
+ by the client
+
+
+
+
+Megginson, et al. Standards Track [Page 6]
+
+RFC 3928 LDAP Client Update Protocol October 2004
+
+
+ lcupUnsupportedScheme (116) The cookie scheme is a valid OID but
+ is not supported by this server
+ lcupReloadRequired (117) indicates that client data needs to be
+ reinitialized. This reason is
+ returned if the server does not
+ contain sufficient information to
+ synchronize the client or if the
+ server's data was reloaded since the
+ last synchronization session
+
+ The uses of these codes are described below.
+
+3.6. Sync Request Control
+
+ The Sync Request Control is an LDAP Control [RFC2251, Section 4.1.2]
+ where the controlType is the object identifier 1.3.6.1.1.7.1 and the
+ controlValue, an OCTET STRING, contains a BER-encoded
+ syncRequestControlValue.
+
+ syncRequestControlValue ::= SEQUENCE {
+ updateType ENUMERATED {
+ syncOnly (0),
+ syncAndPersist (1),
+ persistOnly (2) },
+ sendCookieInterval [0] INTEGER OPTIONAL,
+ scheme [1] LCUPScheme OPTIONAL,
+ cookie [2] LCUPCookie OPTIONAL
+ }
+
+ sendCookieInterval - the server SHOULD send the cookie back in the
+ Sync Update control value (defined below) for every
+ sendCookieInterval number of SearchResultEntry and
+ SearchResultReference PDUs returned to the client. For example, if
+ the value is 5, the server SHOULD send the cookie back in the Sync
+ Update control value for every 5 search results returned to the
+ client. If this value is absent, zero or less than zero, the server
+ chooses the interval.
+
+ The Sync Request Control is only applicable to the searchRequest
+ message. Use of this control is described below.
+
+3.7. Sync Update Control
+
+ The Sync Update Control is an LDAP Control [RFC2251, Section 4.1.2]
+ where the controlType is the object identifier 1.3.6.1.1.7.2 and the
+ controlValue, an OCTET STRING, contains a BER-encoded
+ syncUpdateControlValue.
+
+
+
+
+Megginson, et al. Standards Track [Page 7]
+
+RFC 3928 LDAP Client Update Protocol October 2004
+
+
+ syncUpdateControlValue ::= SEQUENCE {
+ stateUpdate BOOLEAN,
+ entryUUID [0] LCUPUUID OPTIONAL, -- REQUIRED for entries --
+ UUIDAttribute [1] AttributeType OPTIONAL,
+ entryLeftSet [2] BOOLEAN,
+ persistPhase [3] BOOLEAN,
+ scheme [4] LCUPScheme OPTIONAL,
+ cookie [5] LCUPCookie OPTIONAL
+ }
+
+ The field UUIDAttribute contains the name or OID of the attribute
+ that the client should use to perform searches for entries based on
+ the UUID. The client should be able to use it in an equality search
+ filter, e.g., "(<uuid attribute>=<entry UUID value>)" and should be
+ able to use it in the attribute list of the search request to return
+ its value. The UUIDAttribute field may be omitted if the server does
+ not support searching on the UUID values.
+
+ The Sync Update Control is only applicable to SearchResultEntry and
+ SearchResultReference messages. Although entryUUID is OPTIONAL, it
+ MUST be used with SearchResultEntry messages. Use of this control is
+ described below.
+
+3.8. Sync Done Control
+
+ The Sync Done Control is an LDAP Control [RFC2251, Section 4.1.2]
+ where the controlType is the object identifier 1.3.6.1.1.7.3 and the
+ controlValue contains a BER-encoded syncDoneValue.
+
+ syncDoneValue ::= SEQUENCE {
+ scheme [0] LCUPScheme OPTIONAL,
+ cookie [1] LCUPCookie OPTIONAL
+ }
+
+ The Sync Done Control is only applicable to SearchResultDone message.
+ Use of this control is described below.
+
+4. Protocol Usage and Flow
+
+4.1. LCUP Search Requests
+
+ A client initiates a synchronization or persistent search session
+ with a server by attaching a Sync Request control to an LDAP
+ searchRequest message. The search specification determines the part
+ of the directory information tree (DIT) the client wishes to
+ synchronize with, the set of attributes it is interested in and the
+ amount of data the client is willing to receive. The Sync Request
+ control contains the client's request specification.
+
+
+
+Megginson, et al. Standards Track [Page 8]
+
+RFC 3928 LDAP Client Update Protocol October 2004
+
+
+ If there is an error condition, the server MUST immediately return a
+ SearchResultDone message with the resultCode set to an error code.
+ This table maps a condition to its corresponding behavior and
+ resultCode.
+
+ Condition Behavior or resultCode
+
+ Sync Request Control is not Server behaves as [RFC2251, Section
+ supported 4.1.2] - specifically, if the
+ criticality of the control is FALSE,
+ the server will process the request
+ as a normal search request
+
+ Scheme is not supported lcupUnsupportedScheme
+
+ A control value field is lcupInvalidData
+ invalid (e.g., illegal
+ updateType, or the scheme is
+ not a valid OID, or the cookie
+ is invalid)
+
+ Server is running out of lcupResourcesExhausted
+ resources
+
+ Server suspects client of lcupSecurityViolation
+ malicious behavior (frequent
+ connects/disconnects, etc.)
+
+ The server cannot bring the lcupReloadRequired
+ client up to date (server data
+ has been reloaded, or other
+ changes prevent
+ convergence)
+
+4.1.1. Initial Synchronization and Full Resync
+
+ For an initial synchronization or full resync, the fields of the Sync
+ Request control MUST be specified as follows:
+
+ updateType - MUST be set to syncOnly or syncAndPersist
+ sendCookieInterval - MAY be set
+ scheme - MAY be set - if set, the server MUST use this
+ specified scheme or return lcupUnsupportedScheme
+ (see above) - if not set, the server MAY use any
+ scheme it supports.
+ cookie - MUST NOT be set
+
+
+
+
+
+Megginson, et al. Standards Track [Page 9]
+
+RFC 3928 LDAP Client Update Protocol October 2004
+
+
+ If the request was successful, the client will receive results as
+ described in the section "LCUP Search Responses" below.
+
+4.1.2. Incremental or Update Synchronization
+
+ For an incremental or update synchronization, the fields of the Sync
+ Request control MUST be specified as follows:
+
+ updateType - MUST be set to syncOnly or syncAndPersist
+ sendCookieInterval - MAY be set
+ scheme - MUST be set
+ cookie - MUST be set
+
+ The client SHOULD always use the latest cookie it received from the
+ server.
+
+ If the request was successful, the client will receive results as
+ described in the section "LCUP Search Responses" below.
+
+4.1.3. Persistent Only
+
+ For persistent only search request, the fields of the Sync Request
+ MUST be specified as follows:
+
+ updateType - MUST be set to persistOnly
+ sendCookieInterval - MAY be set
+ scheme - MAY be set - if set, the server MUST use this
+ specified scheme or return
+ lcupUnsupportedScheme (see above) - if not set,
+ the server MAY use any scheme it supports.
+ cookie - MAY be set, but the server MUST ignore it
+
+ If the request was successful, the client will receive results as
+ described in the section "LCUP Search Responses" below.
+
+4.2. LCUP Search Responses
+
+ In response to the client's LCUP request, the server returns zero or
+ more SearchResultEntry or SearchResultReference PDUs that fit the
+ client's specification, followed by a SearchResultDone PDU. The
+ behavior is as specified in [RFC2251 Section 4.5]. Each
+ SearchResultEntry or SearchResultReference PDU also contains a Sync
+ Update control that describes the LCUP state of the returned entry.
+ The SearchResultDone PDU contains a Sync Done control. The following
+ sections specify behaviors in addition to [RFC2251 Section 4.5].
+
+
+
+
+
+
+Megginson, et al. Standards Track [Page 10]
+
+RFC 3928 LDAP Client Update Protocol October 2004
+
+
+4.2.1 Sync Update Informational Responses
+
+ The server may use the Sync Update control to return information not
+ related to a particular entry. It MAY do this at any time to return
+ a cookie to the client, or to inform the client that the sync phase
+ of a syncAndPersist search is complete and the persist phase has
+ begun. It MAY do this during the persist phase even though no entry
+ has changed that would have normally triggered a response. In order
+ to do this, it is REQUIRED to return the following:
+
+ - A SearchResultEntry PDU with the objectName field set to the DN of
+ the baseObject of the search request and with an empty attribute
+ list.
+
+ - A Sync Update control value with the fields set to the following:
+
+ stateUpdate - MUST be set to TRUE
+ entryUUID - SHOULD be set to the UUID of the baseObject of the
+ search request
+ entryLeftSet - MUST be set to FALSE
+ persistPhase - MUST be FALSE if the search is in the sync phase of a
+ request, and MUST be TRUE if the search is in the
+ persist phase
+ UUIDAttribute - SHOULD only be set if this is either the first result
+ returned or if the attribute has changed
+ scheme - MUST be set if the cookie is set and the cookie
+ format has changed; otherwise, it MAY be omitted
+ cookie - SHOULD be set
+
+ If the server merely wants to return a cookie to the client, it
+ should return as above with the cookie field set.
+
+ During a syncAndPersist request, the server MUST return (as above)
+ immediately after the last entry of the sync phase has been sent and
+ before the first entry of the persist phase has been sent. In this
+ case, the persistPhase field MUST be set to TRUE. This allows the
+ client to know that the sync phase is complete and the persist phase
+ is starting.
+
+4.2.2 Cookie Return Frequency
+
+ The cookie field of the Sync Update control value MAY be set in any
+ returned result, during both the sync phase and the persist phase.
+ The server should return the cookie to the client often enough for
+ the client to resync in a reasonable period of time in case the
+ search is disconnected or otherwise terminated. The
+ sendCookieInterval field in the Sync Request control is a suggestion
+
+
+
+
+Megginson, et al. Standards Track [Page 11]
+
+RFC 3928 LDAP Client Update Protocol October 2004
+
+
+ to the server of how often to return the cookie in the Sync Update
+ control. The server SHOULD respect this value.
+
+ The scheme field of the Sync Update control value MUST be set if the
+ cookie is set and the cookie format has changed; otherwise, it MAY be
+ omitted.
+
+ Some clients may have unreliable connections, for example, a wireless
+ device or a WAN connection. These clients may want to insure that
+ the cookie is returned often in the Sync Update control value, so
+ that if they have to reconnect, they do not have to process many
+ redundant entries. These clients should set the sendCookieInterval
+ in the Sync Request control value to a low number, perhaps even 1.
+ Some clients may have a limited bandwidth connection, and may not
+ want to receive the cookie very often, or even at all (however, the
+ cookie is always sent back in the Sync Done control value upon
+ successful completion). These clients should set the
+ sendCookieInterval in the Sync Request control value to a high
+ number.
+
+ A reasonable behavior of the server is to return the cookie only when
+ data in the LCUP context has changed, even if the client has
+ specified a frequent sendCookieInterval. If nothing has changed, the
+ server can probably save some bandwidth by not returning the cookie.
+
+4.2.3. Definition of an Entry That Has Entered the Result Set
+
+ An entry SHALL BE considered to have entered the client's search
+ result set if one of the following conditions is met:
+
+ - During the sync phase for an incremental sync operation, the entry
+ is present in the search result set but was not present before;
+ this can be due to the entry being added via an LDAP Add
+ operation, or by the entry being moved into the result set by an
+ LDAP Modify DN operation, or by some modification to the entry
+ that causes it to enter the result set (e.g., adding an attribute
+ value that matches the clients search filter), or by some meta-
+ data change that causes the entry to enter the result set (e.g.,
+ relaxing of some access control that permits the entry to be
+ visible to the client).
+
+ - During the persist phase for a persistent search operation, the
+ entry enters the search result set; this can be due to the entry
+ being added via an LDAP Add operation, or by the entry being moved
+ into the result set by an LDAP Modify DN operation, or by some
+ modification to the entry that causes it to enter the result set
+ (e.g., adding an attribute value that matches the clients search
+ filter), or by some meta-data change that causes the entry to
+
+
+
+Megginson, et al. Standards Track [Page 12]
+
+RFC 3928 LDAP Client Update Protocol October 2004
+
+
+ enter the result set (e.g., relaxing of some access control that
+ permits the entry to be visible to the client).
+
+4.2.4. Definition of an Entry That Has Changed
+
+ An entry SHALL BE considered to be changed if one or more of the
+ attributes in the attribute list in the search request have been
+ modified. For example, if the search request listed the attributes
+ "cn sn uid", and there is an entry in the client's search result set
+ with the "cn" attribute that has been modified, the entry is
+ considered to be modified. The modification may be due to an LDAP
+ Modify operation or by some change to the meta-data for the entry
+ (e.g., virtual attributes) that causes some change to the value of
+ the specified attributes.
+
+ The converse of this is that an entry SHALL NOT BE considered to be
+ changed if none of the attributes in the attribute list of the search
+ request are modified attributes of the entry. For example, if the
+ search request listed the attributes "cn sn uid", and there is an
+ entry in the client's search result set with the "foo" attribute that
+ has been modified, and none of the "cn" or "sn" or "uid" attributes
+ have been modified, the entry is NOT considered to be changed.
+
+4.2.5. Definition of an Entry That Has Left the Result Set
+
+ An entry SHALL BE considered to have left the client's search result
+ set if one of the following conditions is met:
+
+ - During the sync phase for an incremental sync operation, the entry
+ is not present in the search result set but was present before;
+ this can be due to the entry being deleted via an LDAP Delete
+ operation, or by the entry leaving the result set via an LDAP
+ Modify DN operation, or by some modification to the entry that
+ causes it to leave the result set (e.g., changing/removing an
+ attribute value so that it no longer matches the client's search
+ filter), or by some meta-data change that causes the entry to
+ leave the result set (e.g., adding of some access control that
+ denies the entry to be visible to the client).
+
+ - During the persist phase for a persistent search operation, the
+ entry leaves the search result set; this can be due to the entry
+ being deleted via an LDAP Delete operation, or by the entry
+ leaving the result set via an LDAP Modify DN operation, or by some
+ modification to the entry that causes it to leave the result set
+ (e.g., changing/removing an attribute value so that it no longer
+ matches the client's search filter), or by some meta-data change
+
+
+
+
+
+Megginson, et al. Standards Track [Page 13]
+
+RFC 3928 LDAP Client Update Protocol October 2004
+
+
+ that causes the entry to leave the result set (e.g., adding of
+ some access control that denies the entry to be visible to the
+ client).
+
+4.2.6. Results For Entries Present in the Result Set
+
+ An entry SHOULD be returned as present under the following
+ conditions:
+
+ - The request is an initial synchronization or full resync request
+ and the entry is present in the client's search result set
+
+ - The request is an incremental synchronization and the entry has
+ changed or entered the result set since the last sync
+
+ - The search is in the persist phase and the entry enters the result
+ set or changes
+
+ For a SearchResultEntry return, the fields of the Sync Update control
+ value MUST be set as follows:
+
+ stateUpdate - MUST be set to FALSE
+ entryUUID - MUST be set to the UUID of the entry
+ entryLeftSet - MUST be set to FALSE
+ persistPhase - MUST be set to FALSE if during the sync phase or TRUE
+ if during the persist phase
+ UUIDAttribute - SHOULD only be set if this is either the first result
+ returned or if the attribute has changed
+ scheme - as above
+ cookie - as above
+
+ The searchResultReference return will look the same, except that the
+ entryUUID is not required. If it is specified, it MUST contain the
+ UUID of the DSE holding the reference knowledge.
+
+4.2.7. Results For Entries That Have Left the Result Set
+
+ An entry SHOULD be returned as having left the result set under the
+ following conditions:
+
+ - The request is an incremental synchronization during the sync
+ phase and the entry has left the result set
+
+ - The search is in the persist phase and the entry has left the
+ result set
+
+
+
+
+
+
+Megginson, et al. Standards Track [Page 14]
+
+RFC 3928 LDAP Client Update Protocol October 2004
+
+
+ - The entry has left the result set as a result of an LDAP Delete or
+ LDAP Modify DN operation against the entry itself (i.e., not as a
+ result of an operation against its parent or ancestor)
+
+ For a SearchResultEntry return where the entry has left the result
+ set, the fields of the Sync Update control value MUST be set as
+ follows:
+
+ stateUpdate - MUST be set to FALSE
+ entryUUID - MUST be set to the UUID of the entry that left the
+ result set
+ entryLeftSet - MUST be set to TRUE
+ persistPhase - MUST be set to FALSE if during the sync phase or TRUE
+ if during the persist phase
+ UUIDAttribute - SHOULD only be set if this is either the first result
+ returned or if the attribute has changed
+ scheme - as above
+ cookie - as above
+
+ The searchResultReference return will look the same, except that the
+ entryUUID is not required. If it is specified, it MUST contain the
+ UUID of the DSE holding the reference knowledge.
+
+ Some server implementations keep track of deleted entries using a
+ tombstone - a hidden entry that keeps track of the state, but not all
+ of the data, of an entry that has been deleted. In this case, the
+ tombstone may not contain all of the original attributes of the
+ entry, and therefore it may be impossible for the server to determine
+ if an entry should be removed from the result set based on the
+ attributes in the client's search request. Servers SHOULD keep
+ enough information about the attributes in the deleted entries to
+ determine if an entry should be removed from the result set. Since
+ this may not be possible, the server MAY return an entry as having
+ left the result set even if it is not or never was in the client's
+ result set. Clients MUST ignore these notifications.
+
+4.3. Responses Requiring Special Consideration
+
+ The following sections describe special handling that may be required
+ when returning results.
+
+4.3.1. Returning Results During the Persistent Phase
+
+ During the persistent phase, the server SHOULD return the changed
+ entries to the client as quickly as possible.
+
+
+
+
+
+
+Megginson, et al. Standards Track [Page 15]
+
+RFC 3928 LDAP Client Update Protocol October 2004
+
+
+4.3.2. No Mixing of Sync Phase with Persist Phase
+
+ During a sync phase, the server MUST NOT return any entries with the
+ persistPhase flag set to TRUE, and during the persist phase, all
+ entries returned MUST have the persistPhase flag set to TRUE. The
+ server MUST NOT mix and match sync phase entries with persist phase
+ entries. If there are any sync phase entries to return, they MUST be
+ returned before any persist phase entries are returned.
+
+4.3.3. Returning Updated Results During the Sync Phase
+
+ There may be updates to the entries in the result set of a sync phase
+ search during the actual search operation. If the DSA is under a
+ heavy update load, and it attempts to send all of those updated
+ entries to the client in addition to the other updates it was already
+ planning to send for the sync phase, the server may never get to the
+ end of the sync phase. Therefore, it is left up to the discretion of
+ the server implementation to decide when the client is "in sync" -
+ that is, when to end a syncOnly request, or when to send the Sync
+ Update Informational Response between the sync phase and the persist
+ phase of a syncAndPersist request. The server MAY send the same
+ entry multiple times during the sync phase if the entry changes
+ during the sync phase.
+
+ A reasonable behavior is for the server to generate a cookie based on
+ the server state at the time the client initiated the LCUP request,
+ and only send entries up to that point during the sync phase. Entries
+ updated after that point will be returned only during the persist
+ phase of a syncAndPersist request, or only upon an incremental
+ synchronization.
+
+4.3.4. Operational Attributes and Administrative Entries
+
+ An operational attribute SHOULD be returned if it is specified in the
+ attributes list and would normally be returned as subject to the
+ constraints of [RFC2251 Section 4.5]. If the server does not support
+ syncing of operational attributes, the server MUST return a
+ SearchResultDone message with a resultCode of unwillingToPerform.
+
+ LDAP Subentries [RFC3672] SHOULD be returned if they would normally
+ be returned by the search request. If the server does not support
+ syncing of LDAP Subentries, and the server can determine from the
+ search request that the client has requested LDAP Subentries to be
+ returned (e.g., search control or search filter), the server MUST
+ return a SearchResultDone message with a resultCode of
+ unwillingToPerform. Otherwise, the server MAY simply omit returning
+ LDAP Subentries.
+
+
+
+
+Megginson, et al. Standards Track [Page 16]
+
+RFC 3928 LDAP Client Update Protocol October 2004
+
+
+4.3.5. Virtual Attributes
+
+ An entry may have attributes whose presence in the entry, or presence
+ of values of the attribute, is generated on the fly, possibly by some
+ mechanism outside of the entry, elsewhere in the DIT. An example of
+ this is collective attributes [RFC3671]. These attributes shall be
+ referred to in this document as virtual attributes.
+
+ LCUP treats these attributes the same way as normal, non-virtual
+ attributes. A virtual attribute SHOULD be returned if it is
+ specified in the attributes list and would normally be returned as
+ subject to the constraints of [RFC2251 Section 4.5]. If the server
+ does not support syncing of virtual attributes, the server MUST
+ return a SearchResultDone message with a resultCode of
+ unwillingToPerform.
+
+ One consequence of this is that if you change the definition of a
+ virtual attribute such that it makes the value of that attribute
+ change in many entries in the client's search scope, this means that
+ a server may have to return many entries to the client as a result of
+ that one change. It is not anticipated that this will be a frequent
+ occurrence, and the server has the option to simply force the client
+ to resync if necessary.
+
+ It is also possible that a future LDAP control will allow the client
+ to request only virtual or only non-virtual attributes.
+
+4.3.6. Modify DN and Delete Operations Applied to Subtrees
+
+ There is a special case where a Modify DN or a Delete operation is
+ applied to the base entry of a subtree, and either that base entry or
+ entries in the subtree are within the scope of an LCUP search
+ request. In this case, all of the entries in the subtree are
+ implicitly renamed or removed.
+
+ In either of these cases, the server MUST do one of the following:
+
+ - treat all of these entries as having been renamed or removed and
+ return each entry to the client as such
+
+ - decide that this would be prohibitively expensive, and force the
+ client to resync
+
+ If the search base object has been renamed, and the client has
+ received a noSuchObject as the result of a search request, the client
+ MAY use the entryUUID and UUIDAttribute to locate the new DN that is
+ the result of the modify DN operation.
+
+
+
+
+Megginson, et al. Standards Track [Page 17]
+
+RFC 3928 LDAP Client Update Protocol October 2004
+
+
+4.3.7. Convergence Guarantees
+
+ If at any time during an LCUP search, either during the sync phase or
+ the persist phase, the server determines that it cannot guarantee
+ that it can bring the client's copy of the data to eventual
+ convergence, it SHOULD immediately terminate the LCUP search request
+ and return a SearchResultDone message with a resultCode of
+ lcupReloadRequired. This can also happen at the beginning of an
+ incremental synchronization request, if the client presents a cookie
+ that is out of date or otherwise unable to be processed. The client
+ should then issue an initial synchronization request.
+
+ This can happen, for example, if the data on the server is reloaded,
+ or if there has been some change to the meta-data that makes it
+ impossible for the server to determine if a particular entry should
+ or should not be part of the search result set, or if the meta-data
+ change makes it too resource intensive for the server to calculate
+ the proper result set.
+
+ The server can also return lcupReloadRequired if it determines that
+ it would be more efficient for the client to perform a reload, for
+ example, if too many entries have changed and a simple reload would
+ be much faster.
+
+4.4. LCUP Search Termination
+
+4.4.1. Server Initiated Termination
+
+ When the server has successfully finished processing the client's
+ request, it attaches a Sync Done control to the SearchResultDone
+ message and sends it to the client. However, if the SearchResultDone
+ message contains a resultCode that is not success or canceled, the
+ Sync Done control MAY be omitted. Although the LCUP cookie is
+ OPTIONAL in the Sync Done control value, it MUST be set if the
+ SearchResultDone resultCode is success or canceled. The server
+ SHOULD also set the cookie if the resultCode is
+ lcupResourcesExhausted, timeLimitExceeded, sizeLimitExceeded, or
+ adminLimitExceeded. This allows the client to more easily resync
+ later. If some error occurred, either an LDAP search error (e.g.,
+ insufficientAccessRights) or an LCUP error (e.g.,
+ lcupUnsupportedScheme), the cookie MAY be omitted. If the cookie is
+ set, the scheme MUST be set also if the cookie format has changed,
+ otherwise, it MAY be omitted.
+
+ If server resources become tight, the server can terminate one or
+ more search operations by sending a SearchResultDone message to the
+ client(s) with a resultCode of lcupResourcesExhausted. The server
+ SHOULD attach a Sync Done control with the cookie set. A server side
+
+
+
+Megginson, et al. Standards Track [Page 18]
+
+RFC 3928 LDAP Client Update Protocol October 2004
+
+
+ policy is used to decide which searches to terminate. This can also
+ be used as a security mechanism to disconnect clients that are
+ suspected of malicious actions, but if the server can infer that the
+ client is malicious, the server SHOULD return lcupSecurityViolation
+ instead.
+
+4.4.2. Client Initiated Termination
+
+ If the client needs to terminate the synchronization process and it
+ wishes to obtain the cookie that represents the current state of its
+ data, it issues an LDAP Cancel operation [RFC3909]. The server
+ responds immediately with a LDAP Cancel response [RFC3909]. The
+ server MAY send any pending SearchResultEntry or
+ SearchResultReference PDUs if the server cannot easily abort or
+ remove those search results from its outgoing queue. The server
+ SHOULD send as few of these remaining messages as possible. Finally,
+ the server sends the message SearchResultDone with the Sync Done
+ control attached. If the search was successful up to that point, the
+ resultCode field of the SearchResultDone message MUST be canceled
+ [RFC3909], and the cookie MUST be set in the Sync Done control. If
+ there is an error condition, the server MAY return as described in
+ section 4.4.1 above, or MAY return as described in [RFC3909].
+
+ If the client is not interested in the state information, it can
+ simply abandon the search operation or disconnect from the server.
+
+4.5. Size and Time Limits
+
+ The server SHALL support size and time limits as specified in
+ [RFC2251, Section 5]. The server SHOULD ensure that if the operation
+ is terminated due to these conditions, the cookie is sent back to the
+ client.
+
+4.6. Operations on the Same Connection
+
+ It is permissible for the client to issue other LDAP operations on
+ the connection used by the protocol. Since each LDAP
+ request/response carries a message id there will be no ambiguity
+ about which PDU belongs to which operation. By sharing the
+ connection among multiple operations, the server will be able to
+ conserve its resources.
+
+4.7. Interactions with Other Controls
+
+ LCUP defines neither restrictions nor guarantees about the ability to
+ use the controls defined in this document in conjunction with other
+ LDAP controls, except for the following: A server MAY ignore non-
+ critical controls supplied with the LCUP control. A server MAY
+
+
+
+Megginson, et al. Standards Track [Page 19]
+
+RFC 3928 LDAP Client Update Protocol October 2004
+
+
+ ignore an LCUP defined control if it is non-critical and it is
+ supplied with other critical controls. If a server receives a
+ critical LCUP control with another critical control, and the server
+ does not support both controls at the same time, the server SHOULD
+ return unavailableCriticalExtension.
+
+ It is up to the server implementation to determine if the server
+ supports controls such as the Sort or VLV or similar controls that
+ change the order of the entries sent to the client. But note that it
+ may be difficult or impossible for a server to perform an incremental
+ synchronization in the presence of such controls, since the cookie
+ will typically be based off a change number, or Change Sequence
+ Number (CSN), or timestamp, or some criteria other than an
+ alphabetical order.
+
+4.8. Replication Considerations
+
+ Use of an LCUP cookie with multiple DSAs in a replicated environment
+ is not defined by LCUP. An implementation of LCUP may support
+ continuation of an LCUP session with another DSA holding a replica of
+ the LCUP context. Clients MAY submit cookies returned by one DSA to
+ a different DSA; it is up to the server to determine if a cookie is
+ one they recognize or not and to return an appropriate result code if
+ not.
+
+5. Client Side Considerations
+
+5.1. Using Cookies with Different Search Criteria
+
+ The cookie received from the server after a synchronization session
+ SHOULD only be used with the same search specification as the search
+ that generated the cookie. Some servers MAY allow the cookie to be
+ used with a more restrictive search specification than the search
+ that generated the cookie. If the server does not support the
+ cookie, it MUST return lcupInvalidCookie. This is because the client
+ can end up with an incomplete data store otherwise. A more
+ restrictive search specification is one that would generate a subset
+ of the data produced by the original search specification.
+
+5.2. Renaming the Base Object
+
+ Because an LCUP client specifies the area of the tree with which it
+ wishes to synchronize through the standard LDAP search specification,
+ the client can be returned noSuchObject error if the root of the
+ synchronization area was renamed between the synchronization sessions
+ or during a synchronization session. If this condition occurs, the
+ client can attempt to locate the root by using the root's UUID saved
+ in client's local data store. It then can repeat the synchronization
+
+
+
+Megginson, et al. Standards Track [Page 20]
+
+RFC 3928 LDAP Client Update Protocol October 2004
+
+
+ request using the new search base. In general, a client can detect
+ that an entry was renamed and apply the changes received to the right
+ entry by using the UUID rather than DN based addressing.
+
+5.3. Use of Persistent Searches With Respect to Resources
+
+ Each active persistent operation requires that an open TCP connection
+ be maintained between an LDAP client and an LDAP server that might
+ not otherwise be kept open. Therefore, client implementors are
+ encouraged to avoid using persistent operations for non-essential
+ tasks and to close idle LDAP connections as soon as practical. The
+ server may close connections if server resources become tight.
+
+5.4. Continuation References to Other LCUP Contexts
+
+ The client MAY receive a continuation reference
+ (SearchResultReference [RFC2251 SECTION 4.5.3]) if the search request
+ spans multiple parts of the DIT, some of which may require a
+ different LCUP cookie, some of which may not even be managed by LCUP.
+ The client SHOULD maintain a cache of the LDAP URLs returned in the
+ continuation references and the cookies associated with them. The
+ client is responsible for performing another LCUP search to follow
+ the references, and SHOULD use the cookie corresponding to the LDAP
+ URL for that reference (if it has a cookie).
+
+5.5. Referral Handling
+
+ The client may receive a referral (Referral [RFC2251 SECTION 4.1.11])
+ when the search base is a subordinate reference, and this will end
+ the operation.
+
+5.6. Multiple Copies of Same Entry During Sync Phase
+
+ The server MAY send the same entry multiple times during a sync phase
+ if the entry changes during the sync phase. The client SHOULD use
+ the last sent copy of the entry as the current one.
+
+5.7. Handling Server Out of Resources Condition
+
+ If the client receives an lcupResourcesExhausted or
+ lcupSecurityViolation resultCode, the client SHOULD wait at least 5
+ seconds before attempting another operation. It is RECOMMENDED that
+ the client use an exponential backoff strategy, but different clients
+ may want to use different backoff strategies.
+
+
+
+
+
+
+
+Megginson, et al. Standards Track [Page 21]
+
+RFC 3928 LDAP Client Update Protocol October 2004
+
+
+6. Server Implementation Considerations
+
+6.1. Server Support for UUIDs
+
+ Servers MUST support UUIDs. UUIDs are required in the Sync Update
+ control. Additionally, server implementers SHOULD make the UUID
+ values for the entries available as an attribute of the entry, and
+ provide indexing or other mechanisms to allow clients to search for
+ an entry using the UUID attribute in the search filter. The
+ syncUpdate control provides a field UUIDAttribute to allow the server
+ to let the client know the name or OID of the attribute to use to
+ search for an entry by UUID.
+
+6.2. Example of Using an RUV as the Cookie Value
+
+ By design, the protocol supports multiple cookie schemes. This is to
+ allow different implementations the flexibility of storing any
+ information applicable to their environment. A reasonable
+ implementation for an LDUP compliant server would be to use the
+ Replica Update Vector (RUV). For each master, RUV contains the
+ largest CSN seen from this master. In addition, RUV implemented by
+ some directory servers (not yet in LDUP) contains replica generation
+ - an opaque string that identifies the replica's data store. The
+ replica generation value changes whenever the replica's data is
+ reloaded. Replica generation is intended to signal the
+ replication/synchronization peers that the replica's data was
+ reloaded and that all other replicas need to be reinitialized. RUV
+ satisfies the three most important properties of the cookie: (1) it
+ uniquely identifies the state of client's data, (2) it can be used to
+ synchronize with multiple servers, and (3) it can be used to detect
+ that the server's data was reloaded. If RUV is used as the cookie,
+ entries last modified by a particular master must be sent to the
+ client in the order of their last modified CSN. This ordering
+ guarantees that the RUV can be updated after each entry is sent.
+
+6.3. Cookie Support Issues
+
+6.3.1. Support for Multiple Cookie Schemes
+
+ A server may support one or more LCUP cookie schemes. It is expected
+ that schemes will be published along with their OIDs as RFCs. The
+ server's DIT may be partitioned into different sections which may
+ have different cookies associated with them. For example, some
+ servers may use some sort of replication mechanism to support LCUP.
+ If so, the DIT may be partitioned into multiple replicas. A client
+ may send an LCUP search request that spans multiple replicas. Some
+ parts of the DIT spanned by the search request scope may support LCUP
+ and some may not. The server MUST send a SearchResultReference
+
+
+
+Megginson, et al. Standards Track [Page 22]
+
+RFC 3928 LDAP Client Update Protocol October 2004
+
+
+ [RFC2251, SECTION 4.5.3] when the LCUP Context for a returned entry
+ changes. The server SHOULD send all references to other LCUP
+ Contexts in the search scope first, in order to allow the clients to
+ process these searches in parallel. The LDAP URL(s) returned MUST
+ contain the DN(s) of the base of another section of the DIT (however
+ the server implementation has partitioned the DIT). The client will
+ then issue another LCUP search using the LDAP URL returned. Each
+ section of the DIT MAY require a different cookie value, so the
+ client SHOULD maintain a cache, mapping the different LDAP URL values
+ to different cookies. If the cookie changes, the scheme may change
+ as well, but the cookie scheme MUST be the same within a given LCUP
+ Context.
+
+6.3.2. Information Contained in the Cookie
+
+ The cookie must contain enough information to allow the server to
+ determine whether the cookie can be safely used with the search
+ specification it is attached to. As discussed earlier in the
+ document, the cookie SHOULD only be used with the search
+ specification that is equal to the one for which the cookie was
+ generated, but some servers MAY support using a cookie with a search
+ specification that is more restrictive than the one used to generate
+ the cookie.
+
+6.4. Persist Phase Response Time
+
+ The specification makes no guarantees about how soon a server should
+ send notification of a changed entry to the client during the persist
+ phase. This is intentional as any specific maximum delay would be
+ impossible to meet in a distributed directory service implementation.
+ Server implementers are encouraged to minimize the delay before
+ sending notifications to ensure that clients' needs for timeliness of
+ change notification are met.
+
+6.5. Scaling Considerations
+
+ Implementers of servers that support the mechanism described in this
+ document should ensure that their implementation scales well as the
+ number of active persistent operations and the number of changes made
+ in the directory increases. Server implementers are also encouraged
+ to support a large number of client connections if they need to
+ support large numbers of persistent operations.
+
+
+
+
+
+
+
+
+
+Megginson, et al. Standards Track [Page 23]
+
+RFC 3928 LDAP Client Update Protocol October 2004
+
+
+6.6. Alias Dereferencing
+
+ LCUP design does not consider issues associated with alias
+ dereferencing in search. Clients MUST specify derefAliases as either
+ neverDerefAliases or derefFindingBaseObj. Servers are to return
+ protocolError if the client specifies either derefInSearching or
+ derefAlways.
+
+7. Synchronizing Heterogeneous Data Stores
+
+ Clients, like a meta directory join engine, synchronizing multiple
+ writable data stores, will only work correctly if each piece of
+ information comes from a single authoritative data source. In a
+ replicated environment, an LCUP Context should employ the same
+ conflict resolution scheme across all its replicas. This is because
+ different systems have different notions of time and different update
+ resolution procedures. As a result, a change applied on one system
+ can be discarded by the other, thus preventing the data stores from
+ converging.
+
+8. IANA Considerations
+
+ This document lists several values that have been registered by the
+ IANA. The following LDAP result codes have been assigned by IANA as
+ described in section 3.6 of [RFC3383]:
+
+ lcupResourcesExhausted 113
+ lcupSecurityViolation 114
+ lcupInvalidData 115
+ lcupUnsupportedScheme 116
+ lcupReloadRequired 117
+
+ The three controls defined in this document have been registered as
+ LDAP Protocol Mechanisms as described in section 3.2 of [RFC3383].
+ One OID, 1.3.6.1.1.7, has been assigned by IANA as described in
+ section 3.1 of [RFC3383]. The OIDs for the controls defined in this
+ document are derived as follows from the one assigned by IANA:
+
+ LCUP Sync Request Control 1.3.6.1.1.7.1
+ LCUP Sync Update Control 1.3.6.1.1.7.2
+ LCUP Sync Done Control 1.3.6.1.1.7.3
+
+9. Security Considerations
+
+ In some situations, it may be important to prevent general exposure
+ of information about changes that occur in an LDAP server. Therefore,
+ servers that implement the mechanism described in this document
+ SHOULD provide a means to enforce access control on the entries
+
+
+
+Megginson, et al. Standards Track [Page 24]
+
+RFC 3928 LDAP Client Update Protocol October 2004
+
+
+ returned and MAY also provide specific access control mechanisms to
+ control the use of the controls and extended operations defined in
+ this document.
+
+ As with normal LDAP search requests, a malicious client can initiate
+ a large number of persistent search requests in an attempt to consume
+ all available server resources and deny service to legitimate
+ clients. The protocol provides the means to stop malicious clients
+ by disconnecting them from the server. The servers that implement
+ the mechanism SHOULD provide the means to detect the malicious
+ clients. In addition, the servers SHOULD provide the means to limit
+ the number of resources that can be consumed by a single client.
+
+10. References
+
+10.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2251] Wahl, M., Howes, T., and S. Kille, "Lightweight
+ Directory Access Protocol (v3)", RFC 2251, December
+ 1997.
+
+ [RFC3383] Zeilenga, K., "Internet Assigned Numbers Authority
+ (IANA) Considerations for Lightweight Directory Access
+ Protocol (LDAP)", BCP 64, RFC 3383, September 2002.
+
+ [RFC3909] Zeilenga, K., "Lightweight Directory Access Protocol
+ (LDAP) Cancel Operation", RFC 3909, October 2004.
+
+ [X.680] ITU-T, "Abstract Syntax Notation One (ASN.1) -
+ Specification of Basic Notation", X.680, 1994.
+
+ [X.690] ITU-T, "Specification of ASN.1 encoding rules: Basic,
+ Canonical, and Distinguished Encoding Rules", X.690,
+ 1994.
+
+ [UUID] International Organization for Standardization (ISO),
+ "Information technology - Open Systems Interconnection -
+ Remote Procedure Call", ISO/IEC 11578:1996.
+
+
+
+
+
+
+
+
+
+
+Megginson, et al. Standards Track [Page 25]
+
+RFC 3928 LDAP Client Update Protocol October 2004
+
+
+10.2. Informative References
+
+ [RFC3384] Stokes, E., Weiser, R., Moats, R., and R. Huber,
+ "Lightweight Directory Access Protocol (version 3)
+ Replication Requirements", RFC 3384, October 2002.
+
+ [RFC3671] Zeilenga, K., "Collective Attributes in the Lightweight
+ Directory Access Protocol (LDAP)", RFC 3671, December
+ 2003.
+
+ [RFC3672] Zeilenga, K. and S. Legg, "Subentries in the Lightweight
+ Directory Access Protocol (LDAP)", RFC 3672, December
+ 2003.
+
+11. Acknowledgments
+
+ The LCUP protocol is based in part on the Persistent Search Change
+ Notification Mechanism defined by Mark Smith, Gordon Good, Tim Howes,
+ and Rob Weltman, the LDAPv3 Triggered Search Control defined by Mark
+ Wahl, and the LDAP Control for Directory Synchronization defined by
+ Michael Armijo. The members of the IETF LDUP working group made
+ significant contributions to this document.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Megginson, et al. Standards Track [Page 26]
+
+RFC 3928 LDAP Client Update Protocol October 2004
+
+
+Appendix - Features Left Out of LCUP
+
+ There are several features present in other protocols or considered
+ useful by clients that are currently not included in the protocol
+ primarily because they are difficult to implement on the server.
+ These features are briefly discussed in this section.
+
+Triggered Search Change Type
+
+ This feature is present in the Triggered Search specification. A
+ flag is attached to each entry returned to the client indicating the
+ reason why this entry is returned. The possible reasons from the
+ document are:
+
+ - notChange: the entry existed in the directory and matched the
+ search at the time the operation is being performed,
+
+ - enteredSet: the entry entered the result,
+
+ - leftSet: the entry left the result,
+
+ - modified: the entry was part of the result set, was modified or
+ renamed, and still is in the result set.
+
+ The leftSet feature is particularly useful because it indicates to
+ the client that an entry is no longer within the client's search
+ specification and the client can remove the associated data from its
+ data store. Ironically, this feature is the hardest to implement on
+ the server because the server does not keep track of the client's
+ state and has no easy way of telling which entries moved out of scope
+ between synchronization sessions with the client. A compromise could
+ be reached by only providing this feature for the operations that
+ occur while the client is connected to the server. This is easier to
+ accomplish because the decision about the change type can be made
+ based only on the change without need for any historical information.
+ This, however, would add complexity to the protocol.
+
+Persistent Search Change Type
+
+ This feature is present in the Persistent Search specification.
+ Persistent search has the notion of changeTypes. The client
+ specifies which type of updates will cause entries to be returned,
+ and optionally whether the server tags each returned entry with the
+ type of change that caused that entry to be returned.
+
+ For LCUP, the intention is full synchronization, not partial. Each
+ entry returned by an LCUP search will have some change associated
+ with it that may concern the client. The client may have to have a
+
+
+
+Megginson, et al. Standards Track [Page 27]
+
+RFC 3928 LDAP Client Update Protocol October 2004
+
+
+ local index of entries by DN or UUID to determine if the entry has
+ been added or just modified. It is easy for clients to determine if
+ the entry has been deleted because the entryLeftSet value of the Sync
+ Update control will be TRUE.
+
+Sending Changes
+
+ Some earlier synchronization protocols sent the client(s) only the
+ modified attributes of the entry rather than the entire entry. While
+ this approach can significantly reduce the amount of data returned to
+ the client, it has several disadvantages. First, unless a separate
+ mechanism (like the change type described above) is used to notify
+ the client about entries moving into the search scope, sending only
+ the changes can result in the client having an incomplete version of
+ the data. Let's consider an example. An attribute of an entry is
+ modified. As a result of the change, the entry enters the scope of
+ the client's search. If only the changes are sent, the client would
+ never see the initial data of the entry. Second, this feature is
+ hard to implement since the server might not contain sufficient
+ information to construct the changes based solely on the server's
+ state and the client's cookie. On the other hand, this feature can
+ be easily implemented by the client assuming that the client has the
+ previous version of the data and can perform value by value
+ comparisons.
+
+Data Size Limits
+
+ Some earlier synchronization protocols allowed clients to control the
+ amount of data sent to them in the search response. This feature was
+ intended to allow clients with limited resources to process
+ synchronization data in batches. However, an LDAP search operation
+ already provides the means for the client to specify the size limit
+ by setting the sizeLimit field in the SearchRequest to the maximum
+ number of entries the client is willing to receive. While the
+ granularity is not the same, the assumption is that regular LDAP
+ clients that can deal with the limitations of the LDAP protocol will
+ implement LCUP.
+
+Data Ordering
+
+ Some earlier synchronization protocols allowed a client to specify
+ that parent entries should be sent before the children for add
+ operations and children entries sent before their parents during
+ delete operations. This ordering helps clients to maintain a
+ hierarchical view of the data in their data store. While possibly
+ useful, this feature is relatively hard to implement and is expensive
+ to perform.
+
+
+
+
+Megginson, et al. Standards Track [Page 28]
+
+RFC 3928 LDAP Client Update Protocol October 2004
+
+
+Authors' Addresses
+
+ Rich Megginson
+ Netscape Communications Corp., an America Online company.
+ 360 W. Caribbean Drive
+ Sunnyvale, CA 94089
+ USA
+
+ Phone: +1 505 797-7762
+ EMail: rmegginson0224 at aol.com
+
+
+ Olga Natkovich
+ Yahoo, Inc.
+ 701 First Ave.
+ Sunnyvale, CA 94089
+ USA
+
+ Phone: +1 408 349-6153
+ EMail: olgan at yahoo-inc.com
+
+
+ Mark Smith
+ Pearl Crescent, LLC
+ 447 Marlpool Drive
+ Saline, MI 48176
+ USA
+
+ Phone: +1 734 944-2856
+ EMail: mcs at pearlcrescent.com
+
+
+ Jeff Parham
+ Microsoft Corporation
+ One Microsoft Way
+ Redmond, WA 98052-6399
+ USA
+
+ Phone: +1 425 882-8080
+ EMail: jeffparh at microsoft.com
+
+
+
+
+
+
+
+
+
+
+
+Megginson, et al. Standards Track [Page 29]
+
+RFC 3928 LDAP Client Update Protocol October 2004
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2004).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and at www.rfc-editor.org, and except as set
+ forth therein, the authors retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the ISOC's procedures with respect to rights in ISOC Documents can
+ be found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at ietf-
+ ipr at ietf.org.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+Megginson, et al. Standards Track [Page 30]
+
Added: openldap/vendor/openldap-release/doc/rfc/rfc4013.txt
===================================================================
--- openldap/vendor/openldap-release/doc/rfc/rfc4013.txt (rev 0)
+++ openldap/vendor/openldap-release/doc/rfc/rfc4013.txt 2007-09-15 10:38:52 UTC (rev 844)
@@ -0,0 +1,339 @@
+
+
+
+
+
+
+Network Working Group K. Zeilenga
+Request for Comments: 4013 OpenLDAP Foundation
+Category: Standards Track February 2005
+
+
+ SASLprep: Stringprep Profile for User Names and Passwords
+
+Status of This Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2005).
+
+Abstract
+
+ This document describes how to prepare Unicode strings representing
+ user names and passwords for comparison. The document defines the
+ "SASLprep" profile of the "stringprep" algorithm to be used for both
+ user names and passwords. This profile is intended to be used by
+ Simple Authentication and Security Layer (SASL) mechanisms (such as
+ PLAIN, CRAM-MD5, and DIGEST-MD5), as well as other protocols
+ exchanging simple user names and/or passwords.
+
+1. Introduction
+
+ The use of simple user names and passwords in authentication and
+ authorization is pervasive on the Internet. To increase the
+ likelihood that user name and password input and comparison work in
+ ways that make sense for typical users throughout the world, this
+ document defines rules for preparing internationalized user names and
+ passwords for comparison. For simplicity and implementation ease, a
+ single algorithm is defined for both user names and passwords.
+
+ The algorithm assumes all strings are comprised of characters from
+ the Unicode [Unicode] character set.
+
+ This document defines the "SASLprep" profile of the "stringprep"
+ algorithm [StringPrep].
+
+ The profile is designed for use in Simple Authentication and Security
+ Layer ([SASL]) mechanisms, such as [PLAIN], [CRAM-MD5], and
+ [DIGEST-MD5]. It may be applicable where simple user names and
+
+
+
+Zeilenga Standards Track [Page 1]
+
+RFC 4013 SASLprep February 2005
+
+
+ passwords are used. This profile is not intended for use in
+ preparing identity strings that are not simple user names (e.g.,
+ email addresses, domain names, distinguished names), or where
+ identity or password strings that are not character data, or require
+ different handling (e.g., case folding).
+
+ This document does not alter the technical specification of any
+ existing protocols. Any specification that wishes to use the
+ algorithm described in this document needs to explicitly incorporate
+ this document and provide precise details as to where and how this
+ algorithm is used by implementations of that specification.
+
+2. The SASLprep Profile
+
+ This section defines the "SASLprep" profile of the "stringprep"
+ algorithm [StringPrep]. This profile is intended for use in
+ preparing strings representing simple user names and passwords.
+
+ This profile uses Unicode 3.2 [Unicode].
+
+ Character names in this document use the notation for code points and
+ names from the Unicode Standard [Unicode]. For example, the letter
+ "a" may be represented as either <U+0061> or <LATIN SMALL LETTER A>.
+ In the lists of mappings and the prohibited characters, the "U+" is
+ left off to make the lists easier to read. The comments for
+ character ranges are shown in square brackets (such as "[CONTROL
+ CHARACTERS]") and do not come from the standard.
+
+ Note: A glossary of terms used in Unicode can be found in [Glossary].
+ Information on the Unicode character encoding model can be found in
+ [CharModel].
+
+2.1. Mapping
+
+ This profile specifies:
+
+ - non-ASCII space characters [StringPrep, C.1.2] that can be
+ mapped to SPACE (U+0020), and
+
+ - the "commonly mapped to nothing" characters [StringPrep, B.1]
+ that can be mapped to nothing.
+
+2.2. Normalization
+
+ This profile specifies using Unicode normalization form KC, as
+ described in Section 4 of [StringPrep].
+
+
+
+
+
+Zeilenga Standards Track [Page 2]
+
+RFC 4013 SASLprep February 2005
+
+
+2.3. Prohibited Output
+
+ This profile specifies the following characters as prohibited input:
+
+ - Non-ASCII space characters [StringPrep, C.1.2]
+ - ASCII control characters [StringPrep, C.2.1]
+ - Non-ASCII control characters [StringPrep, C.2.2]
+ - Private Use characters [StringPrep, C.3]
+ - Non-character code points [StringPrep, C.4]
+ - Surrogate code points [StringPrep, C.5]
+ - Inappropriate for plain text characters [StringPrep, C.6]
+ - Inappropriate for canonical representation characters
+ [StringPrep, C.7]
+ - Change display properties or deprecated characters
+ [StringPrep, C.8]
+ - Tagging characters [StringPrep, C.9]
+
+2.4. Bidirectional Characters
+
+ This profile specifies checking bidirectional strings as described in
+ [StringPrep, Section 6].
+
+2.5. Unassigned Code Points
+
+ This profile specifies the [StringPrep, A.1] table as its list of
+ unassigned code points.
+
+3. Examples
+
+ The following table provides examples of how various character data
+ is transformed by the SASLprep string preparation algorithm
+
+ # Input Output Comments
+ - ----- ------ --------
+ 1 I<U+00AD>X IX SOFT HYPHEN mapped to nothing
+ 2 user user no transformation
+ 3 USER USER case preserved, will not match #2
+ 4 <U+00AA> a output is NFKC, input in ISO 8859-1
+ 5 <U+2168> IX output is NFKC, will match #1
+ 6 <U+0007> Error - prohibited character
+ 7 <U+0627><U+0031> Error - bidirectional check
+
+4. Security Considerations
+
+ This profile is intended to prepare simple user name and password
+ strings for comparison or use in cryptographic functions (e.g.,
+ message digests). The preparation algorithm was specifically
+ designed such that its output is canonical, and it is well-formed.
+
+
+
+Zeilenga Standards Track [Page 3]
+
+RFC 4013 SASLprep February 2005
+
+
+ However, due to an anomaly [PR29] in the specification of Unicode
+ normalization, canonical equivalence is not guaranteed for a select
+ few character sequences. These sequences, however, do not appear in
+ well-formed text. This specification was published despite this
+ known technical problem. It is expected that this specification will
+ be revised before further progression on the Standards Track (after
+ [Unicode] and/or [StringPrep] specifications have been updated to
+ address this problem).
+
+ It is not intended for preparing identity strings that are not simple
+ user names (e.g., distinguished names, domain names), nor is the
+ profile intended for use of simple user names that require different
+ handling (such as case folding). Protocols (or applications of those
+ protocols) that have application-specific identity forms and/or
+ comparison algorithms should use mechanisms specifically designed for
+ these forms and algorithms.
+
+ Application of string preparation may have an impact upon the
+ feasibility of brute force and dictionary attacks. While the number
+ of possible prepared strings is less than the number of possible
+ Unicode strings, the number of usable names and passwords is greater
+ than as if only ASCII was used. Though SASLprep eliminates some
+ Unicode code point sequences as possible prepared strings, that
+ elimination generally makes the (canonical) output forms practicable
+ and prohibits nonsensical inputs.
+
+ User names and passwords should be protected from eavesdropping.
+
+ General "stringprep" and Unicode security considerations apply. Both
+ are discussed in [StringPrep].
+
+5. IANA Considerations
+
+ This document details the "SASLprep" profile of the [StringPrep]
+ protocol. This profile has been registered in the stringprep profile
+ registry.
+
+ Name of this profile: SASLprep
+ RFC in which the profile is defined: RFC 4013
+ Indicator whether or not this is the newest version of the
+ profile: This is the first version of the SASPprep profile.
+
+6. Acknowledgement
+
+ This document borrows text from "Preparation of Internationalized
+ Strings ('stringprep')" and "Nameprep: A Stringprep Profile for
+ Internationalized Domain Names", both by Paul Hoffman and Marc
+ Blanchet. This document is a product of the IETF SASL WG.
+
+
+
+Zeilenga Standards Track [Page 4]
+
+RFC 4013 SASLprep February 2005
+
+
+7. Normative References
+
+ [StringPrep] Hoffman, P. and M. Blanchet, "Preparation of
+ Internationalized Strings ("stringprep")", RFC 3454,
+ December 2002.
+
+ [Unicode] The Unicode Consortium, "The Unicode Standard, Version
+ 3.2.0" is defined by "The Unicode Standard, Version
+ 3.0" (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-
+ 61633-5), as amended by the "Unicode Standard Annex
+ #27: Unicode 3.1"
+ (http://www.unicode.org/reports/tr27/) and by the
+ "Unicode Standard Annex #28: Unicode 3.2"
+ (http://www.unicode.org/reports/tr28/).
+
+8. Informative References
+
+ [Glossary] The Unicode Consortium, "Unicode Glossary",
+ <http://www.unicode.org/glossary/>.
+
+ [CharModel] Whistler, K. and M. Davis, "Unicode Technical Report
+ #17, Character Encoding Model", UTR17,
+ <http://www.unicode.org/unicode/reports/tr17/>, August
+ 2000.
+
+ [SASL] Melnikov, A., Ed., "Simple Authentication and Security
+ Layer (SASL)", Work in Progress.
+
+ [CRAM-MD5] Nerenberg, L., "The CRAM-MD5 SASL Mechanism", Work in
+ Progress.
+
+ [DIGEST-MD5] Leach, P., Newman, C., and A. Melnikov, "Using Digest
+ Authentication as a SASL Mechanism", Work in Progress.
+
+ [PLAIN] Zeilenga, K., Ed., "The Plain SASL Mechanism", Work in
+ Progress.
+
+ [PR29] "Public Review Issue #29: Normalization Issue",
+ <http://www.unicode.org/review/pr-29.html>, February
+ 2004.
+
+Author's Address
+
+ Kurt D. Zeilenga
+ OpenLDAP Foundation
+
+ EMail: Kurt at OpenLDAP.org
+
+
+
+
+Zeilenga Standards Track [Page 5]
+
+RFC 4013 SASLprep February 2005
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2005).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the IETF's procedures with respect to rights in IETF Documents can
+ be found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at ietf-
+ ipr at ietf.org.
+
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+Zeilenga Standards Track [Page 6]
+
Added: openldap/vendor/openldap-release/doc/rfc/rfc4370.txt
===================================================================
--- openldap/vendor/openldap-release/doc/rfc/rfc4370.txt (rev 0)
+++ openldap/vendor/openldap-release/doc/rfc/rfc4370.txt 2007-09-15 10:38:52 UTC (rev 844)
@@ -0,0 +1,283 @@
+
+
+
+
+
+
+Network Working Group R. Weltman
+Request for Comments: 4370 Yahoo!, Inc.
+Category: Standards Track February 2006
+
+
+ Lightweight Directory Access Protocol (LDAP)
+ Proxied Authorization Control
+
+Status of This Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2006).
+
+Abstract
+
+ This document defines the Lightweight Directory Access Protocol
+ (LDAP) Proxy Authorization Control. The Proxy Authorization Control
+ allows a client to request that an operation be processed under a
+ provided authorization identity instead of under the current
+ authorization identity associated with the connection.
+
+1. Introduction
+
+ Proxy authorization allows a client to request that an operation be
+ processed under a provided authorization identity instead of under
+ the current authorization identity associated with the connection.
+ This document defines support for proxy authorization using the
+ Control mechanism [RFC2251]. The Lightweight Directory Access
+ Protocol [LDAPV3] supports the use of the Simple Authentication and
+ Security Layer [SASL] for authentication and for supplying an
+ authorization identity distinct from the authentication identity,
+ where the authorization identity applies to the whole LDAP session.
+ The Proxy Authorization Control provides a mechanism for specifying
+ an authorization identity on a per-operation basis, benefiting
+ clients that need to perform operations efficiently on behalf of
+ multiple users.
+
+ The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
+ used in this document are to be interpreted as described in
+ [KEYWORDS].
+
+
+
+
+Weltman Standards Track [Page 1]
+
+RFC 4370 LDAP Proxied Authorization Control February 2006
+
+
+2. Publishing Support for the Proxy Authorization Control
+
+ Support for the Proxy Authorization Control is indicated by the
+ presence of the Object Identifier (OID) "2.16.840.1.113730.3.4.18" in
+ the supportedControl attribute [RFC2252] of a server's root
+ DSA-specific Entry (DSE).
+
+3. Proxy Authorization Control
+
+ A single Proxy Authorization Control may be included in any search,
+ compare, modify, add, delete, or modify Distinguished Name (DN) or
+ extended operation request message. The exception is any extension
+ that causes a change in authentication, authorization, or data
+ confidentiality [RFC2829], such as Start TLS [LDAPTLS] as part of the
+ controls field of the LDAPMessage, as defined in [RFC2251].
+
+ The controlType of the proxy authorization control is
+ "2.16.840.1.113730.3.4.18".
+
+ The criticality MUST be present and MUST be TRUE. This requirement
+ protects clients from submitting a request that is executed with an
+ unintended authorization identity.
+
+ Clients MUST include the criticality flag and MUST set it to TRUE.
+ Servers MUST reject any request containing a Proxy Authorization
+ Control without a criticality flag or with the flag set to FALSE with
+ a protocolError error. These requirements protect clients from
+ submitting a request that is executed with an unintended
+ authorization identity.
+
+ The controlValue SHALL be present and SHALL either contain an authzId
+ [AUTH] representing the authorization identity for the request or be
+ empty if an anonymous association is to be used.
+
+ The mechanism for determining proxy access rights is specific to the
+ server's proxy authorization policy.
+
+ If the requested authorization identity is recognized by the server,
+ and the client is authorized to adopt the requested authorization
+ identity, the request will be executed as if submitted by the proxy
+ authorization identity; otherwise, the result code 123 is returned.
+
+4. Implementation Considerations
+
+ One possible interaction of proxy authorization and normal access
+ control is illustrated here. During evaluation of a search request,
+ an entry that would have been returned for the search (if submitted
+ by the proxy authorization identity directly) may not be returned if
+
+
+
+Weltman Standards Track [Page 2]
+
+RFC 4370 LDAP Proxied Authorization Control February 2006
+
+
+ the server finds that the requester does not have the right to assume
+ the requested identity for searching the entry, even if the entry is
+ within the scope of a search request under a base DN that does imply
+ such rights. This means that fewer results, or no results, may be
+ returned than would be if the proxy authorization identity issued the
+ request directly. An example of such a case may be a system with
+ fine-grained access control, where the proxy right requester has
+ proxy rights at the top of a search tree, but not at or below a point
+ or points within the tree.
+
+5. Security Considerations
+
+ The Proxy Authorization Control method is subject to general LDAP
+ security considerations [RFC2251] [AUTH] [LDAPTLS]. The control may
+ be passed over a secure channel as well as over an insecure channel.
+
+ The control allows for an additional authorization identity to be
+ passed. In some deployments, these identities may contain
+ confidential information that requires privacy protection.
+
+ Note that the server is responsible for determining if a proxy
+ authorization request is to be honored. "Anonymous" users SHOULD NOT
+ be allowed to assume the identity of others.
+
+6. IANA Considerations
+
+ The OID "2.16.840.1.113730.3.4.18" is reserved for the Proxy
+ Authorization Control. It has been registered as an LDAP Protocol
+ Mechanism [RFC3383].
+
+ A result code (123) has been assigned by the IANA for the case where
+ the server does not execute a request using the proxy authorization
+ identity.
+
+7. Acknowledgements
+
+ Mark Smith, formerly of Netscape Communications Corp., Mark Wahl,
+ formerly of Sun Microsystems, Inc., Kurt Zeilenga of OpenLDAP
+ Foundation, Jim Sermersheim of Novell, and Steven Legg of Adacel have
+ contributed with reviews of this document.
+
+
+
+
+
+
+
+
+
+
+
+Weltman Standards Track [Page 3]
+
+RFC 4370 LDAP Proxied Authorization Control February 2006
+
+
+8. Normative References
+
+ [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [LDAPV3] Hodges, J. and R. Morgan, "Lightweight Directory Access
+ Protocol (v3): Technical Specification", RFC 3377,
+ September 2002.
+
+ [SASL] Myers, J., "Simple Authentication and Security Layer
+ (SASL)", RFC 2222, October 1997.
+
+ [AUTH] Wahl, M., Alvestrand, H., Hodges, J., and R. Morgan,
+ "Authentication Methods for LDAP", RFC 2829, May 2000.
+
+ [LDAPTLS] Hodges, J., Morgan, R., and M. Wahl, "Lightweight
+ Directory Access Protocol (v3): Extension for Transport
+ Layer Security", RFC 2830, May 2000.
+
+ [RFC2251] Wahl, M., Howes, T., and S. Kille, "Lightweight Directory
+ Access Protocol (v3)", RFC 2251, December 1997.
+
+ [RFC2252] Wahl, M., Coulbeck, A., Howes, T., and S. Kille,
+ "Lightweight Directory Access Protocol (v3): Attribute
+ Syntax Definitions", RFC 2252, December 1997.
+
+ [RFC2829] Wahl, M., Alvestrand, H., Hodges, J., and R. Morgan,
+ "Authentication Methods for LDAP", RFC 2829, May 2000.
+
+ [RFC3383] Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
+ Considerations for the Lightweight Directory Access
+ Protocol (LDAP)", BCP 64, RFC 3383, September 2002.
+
+Author's Address
+
+ Rob Weltman
+ Yahoo!, Inc.
+ 701 First Avenue
+ Sunnyvale, CA 94089
+ USA
+
+ Phone: +1 408 349-5504
+ EMail: robw at worldspot.com
+
+
+
+
+
+
+
+
+Weltman Standards Track [Page 4]
+
+RFC 4370 LDAP Proxied Authorization Control February 2006
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2006).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr at ietf.org.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is provided by the IETF
+ Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Weltman Standards Track [Page 5]
+
Added: openldap/vendor/openldap-release/doc/rfc/rfc4373.txt
===================================================================
--- openldap/vendor/openldap-release/doc/rfc/rfc4373.txt (rev 0)
+++ openldap/vendor/openldap-release/doc/rfc/rfc4373.txt 2007-09-15 10:38:52 UTC (rev 844)
@@ -0,0 +1,899 @@
+
+
+
+
+
+
+Network Working Group R. Harrison
+Request for Comments: 4373 J. Sermersheim
+Category: Informational Novell, Inc.
+ Y. Dong
+ January 2006
+
+
+ Lightweight Directory Access Protocol (LDAP)
+ Bulk Update/Replication Protocol (LBURP)
+
+Status of This Memo
+
+ This memo provides information for the Internet community. It does
+ not specify an Internet standard of any kind. Distribution of this
+ memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2006).
+
+Abstract
+
+ The Lightweight Directory Access Protocol (LDAP) Bulk
+ Update/Replication Protocol (LBURP) allows an LDAP client to perform
+ a bulk update to an LDAP server. The protocol frames a sequenced set
+ of update operations within a pair of LDAP extended operations to
+ notify the server that the update operations in the framed set are
+ related in such a way that the ordering of all operations can be
+ preserved during processing even when they are sent asynchronously by
+ the client. Update operations can be grouped within a single
+ protocol message to maximize the efficiency of client-server
+ communication.
+
+ The protocol is suitable for efficiently making a substantial set of
+ updates to the entries in an LDAP server.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Harrison, et al. Informational [Page 1]
+
+RFC 4373 LDAP Bulk Update/Replication Protocol January 2006
+
+
+Table of Contents
+
+ 1. Introduction ....................................................3
+ 2. Conventions Used in This Document ...............................3
+ 3. Overview of Protocol ............................................3
+ 3.1. Update Initiation ..........................................4
+ 3.2. Update Stream ..............................................4
+ 3.2.1. LBURPUpdateRequest ..................................4
+ 3.2.2. LBURPUpdateResponse .................................4
+ 3.3. Update Termination .........................................4
+ 3.4. Applicability of Protocol ..................................5
+ 4. Description of Protocol Flow ....................................5
+ 5. Elements of Protocol ............................................6
+ 5.1. StartLBURPRequest ..........................................7
+ 5.1.1. updateStyleOID ......................................7
+ 5.2. StartLBURPResponse .........................................7
+ 5.2.1. maxOperations .......................................8
+ 5.3. LBURPUpdateRequest .........................................8
+ 5.3.1. sequenceNumber ......................................8
+ 5.3.2. UpdateOperationList .................................9
+ 5.4. LBURPUpdateResponse ........................................9
+ 5.4.1. OperationResults ...................................10
+ 5.4.1.1. operationNumber ...........................10
+ 5.4.1.2. ldapResult ................................10
+ 5.5. EndLBURPRequest ...........................................10
+ 5.5.1. sequenceNumber .....................................10
+ 5.6. EndLBURPResponse ..........................................11
+ 6. Semantics of the Incremental Update Style ......................11
+ 7. General LBURP Semantics ........................................11
+ 8. Security Considerations ........................................12
+ 9. IANA Considerations ............................................13
+ 9.1. LDAP Object Identifier Registrations ......................13
+ 10. Normative References ..........................................14
+ 11. Informative References ........................................14
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Harrison, et al. Informational [Page 2]
+
+RFC 4373 LDAP Bulk Update/Replication Protocol January 2006
+
+
+1. Introduction
+
+ The Lightweight Directory Access Protocol (LDAP) Bulk
+ Update/Replication Protocol (LBURP) arose from the need to allow an
+ LDAP client to efficiently present large quantities of updates to an
+ LDAP server and have the LDAP server efficiently process them. LBURP
+ introduces a minimum of new operational functionality to the LDAP
+ protocol because the update requests sent by the client encapsulate
+ standard LDAP [RFC2251] update operations. However, this protocol
+ greatly facilitates bulk updates by allowing the client to send the
+ update operations asynchronously and still allow the server to
+ maintain proper ordering of the operations. It also allows the
+ server to recognize the client's intent to perform a potentially
+ large set of update operations and then to change its processing
+ strategy to more efficiently process the operations.
+
+2. Conventions Used in This Document
+
+ Imperative keywords defined in RFC 2119 [RFC2119] are used in this
+ document, and carry the meanings described there.
+
+ All Basic Encoding Rules (BER) [X.690] encodings follow the
+ conventions found in section 5.1 of [RFC2251].
+
+ The term "supplier" applies to an LDAP client or an LDAP server
+ (acting as a client) that supplies a set of update operations to a
+ consumer.
+
+ The term "consumer" applies to an LDAP server that consumes (i.e.,
+ processes) the sequenced set of update operations sent to it by a
+ supplier.
+
+3. Overview of Protocol
+
+ LBURP frames a set of update operations within a pair of LDAP
+ extended operations that mark the beginning and end of the update
+ set. These updates are sent via LDAP extended operations, each
+ containing a sequence number and a list of one or more update
+ operations to be performed by the consumer. Except for the fact that
+ they are grouped together as part of a larger LDAP message, the
+ update operations in each subset are encoded as LDAP update
+ operations and use the LDAP Abstract Syntax Notation One (ASN.1)
+ [X.680] message types specified in [RFC2251].
+
+
+
+
+
+
+
+
+Harrison, et al. Informational [Page 3]
+
+RFC 4373 LDAP Bulk Update/Replication Protocol January 2006
+
+
+3.1. Update Initiation
+
+ The protocol is initiated when a supplier sends a StartLBURPRequest
+ extended operation to a consumer as a notification that a stream of
+ associated LBURPUpdateRequests will follow. The supplier associates
+ semantics with this stream of requests by including the Object
+ Identifier (OID) of the bulk update/replication style in the
+ StartLBURPRequest. The consumer responds to the StartLBURPRequest
+ with a StartLBURPResponse message.
+
+3.2. Update Stream
+
+ After the consumer responds with a StartLBURPResponse, the supplier
+ sends a stream of LBURPUpdateRequest messages to the consumer.
+ Messages within this stream may be sent asynchronously to maximize
+ the efficiency of the transfer. The consumer responds to each
+ LBURPUpdateRequest with an LBURPUpdateResponse message.
+
+3.2.1. LBURPUpdateRequest
+
+ Each LBURPUpdateRequest contains a sequence number identifying its
+ relative position within the update stream and an UpdateOperationList
+ containing an ordered list of LDAP update operations to be applied to
+ the Directory Information Tree (DIT). The sequence number enables
+ the consumer to process LBURPUpdateRequest messages in the order they
+ were sent by the supplier even when they are sent asynchronously.
+ The consumer processes each LBURPUpdateRequest according to the
+ sequence number by applying the LDAP update operations in its
+ UpdateOperationList to the DIT in the order they are listed.
+
+3.2.2. LBURPUpdateResponse
+
+ When the consumer has processed the update operations from an
+ UpdateOperationList, it sends an LBURPUpdateResponse to the supplier
+ indicating the success or failure of the update operations contained
+ within the corresponding LBURPUpdateRequest.
+
+3.3. Update Termination
+
+ After the supplier has sent all of its LBURPUpdateRequest messages,
+ it sends an EndLBURPRequest message to the consumer to terminate the
+ update stream. Upon servicing all LBURPOperation requests and
+ receiving the EndLBURPRequest, the consumer responds with an
+ EndLBURPResponse, and the update is complete.
+
+
+
+
+
+
+
+Harrison, et al. Informational [Page 4]
+
+RFC 4373 LDAP Bulk Update/Replication Protocol January 2006
+
+
+3.4. Applicability of Protocol
+
+ LBURP is designed to facilitate the bulk update of LDAP servers. It
+ can also be used to synchronize directory information between a
+ single master and multiple slaves.
+
+ No attempt is made to deal with the issues associated with multiple-
+ master replication environments (such as keeping modification times
+ of attribute values) so that updates to the same entry on different
+ replicas can be correctly ordered. For this reason, when LBURP alone
+ is used for replication, proper convergence of the data between all
+ replicas can only be assured in a single-master replication
+ environment.
+
+4. Description of Protocol Flow
+
+ This section describes the LBURP protocol flow and the information
+ contained in each protocol message. Throughout this section, the
+ client or server acting as a supplier is indicated by the letter "S",
+ and the server acting as a consumer is indicated by the letter "C".
+ The construct "S -> C" indicates that the supplier is sending an LDAP
+ message to the consumer, and "C -> S" indicates that the consumer is
+ sending an LDAP message to the supplier. Note that the protocol flow
+ below assumes that a properly authenticated LDAP session has already
+ been established between the supplier and consumer.
+
+ S -> C: StartLBURPRequest message. The parameter is:
+
+ 1) OID for the LBURP update style (see section 5.1.1).
+
+ C -> S: StartLBURPResponse message. The parameter is:
+
+ 1) An optional maxOperations instruction
+ (see section 5.2.1).
+
+ S -> C: An update stream consisting of zero or more
+ LBURPUpdateRequest messages. The requests MAY be sent
+ asynchronously. The parameters are:
+
+ 1) A sequence number specifying the order of
+ this LBURPUpdateRequest with respect to the
+ other LBURPUpdateRequest messages in the update
+ stream (see section 5.3.1).
+
+ 2) LBURPUpdateRequest.updateOperationList, a list
+ of one or more LDAP update operations (see section
+ 5.3.2).
+
+
+
+
+Harrison, et al. Informational [Page 5]
+
+RFC 4373 LDAP Bulk Update/Replication Protocol January 2006
+
+
+ The consumer processes the LBURPUpdateRequest messages
+ in the order of their sequence numbers and applies the
+ LDAP update operations contained within each
+ LBURPUpdateRequest to the DIT in the order they are
+ listed.
+
+ C -> S: LBURPUpdateResponse message. This is sent when the
+ consumer completes processing the update operations
+ from each LBURPUpdateRequest.updateOperationList.
+
+ S -> C: EndLBURPRequest message. This is sent after the
+ supplier sends all of its LBURPUpdateRequest messages
+ to the consumer. The parameter is:
+
+ 1) A sequence number that is one greater than the
+ sequence number of the last LBURPUpdateRequest
+ message in the update stream. This allows the
+ EndLBURPRequest to also be sent asynchronously.
+
+ C -> S: EndLBURPResponse message. This is sent in response to
+ the EndLBURPRequest after the consumer has serviced
+ all LBURPOperation requests.
+
+5. Elements of Protocol
+
+ LBURP uses two LDAP ExtendedRequest messages--StartLBURPRequest and
+ EndLBURPRequest--to initiate and terminate the protocol. A third
+ LDAP ExtendedRequest message--LBURPUpdateRequest--is used to send
+ update operations from the supplier to the consumer. These three
+ requests along with their corresponding responses comprise the entire
+ protocol.
+
+ LBURP request messages are defined in terms of the LDAP
+ ExtendedRequest [RFC2251] as follows:
+
+ ExtendedRequest ::= [APPLICATION 23] SEQUENCE {
+ requestName [0] LDAPOID,
+ requestValue [1] OCTET STRING OPTIONAL
+ }
+
+ LBURP response messages are defined in terms of the LDAP
+ ExtendedResponse [RFC2251] as follows:
+
+ ExtendedResponse ::= [APPLICATION 24] SEQUENCE {
+ COMPONENTS of LDAPResult,
+ responseName [10] LDAPOID OPTIONAL,
+ response [11] OCTET STRING OPTIONAL
+ }
+
+
+
+Harrison, et al. Informational [Page 6]
+
+RFC 4373 LDAP Bulk Update/Replication Protocol January 2006
+
+
+5.1. StartLBURPRequest
+
+ The requestName value of the StartLBURPRequest is OID 1.3.6.1.1.17.1.
+
+ The requestValue of the StartLBURPRequest contains the BER-encoding
+ of the following ASN.1:
+
+ StartLBURPRequestValue ::= SEQUENCE {
+ updateStyleOID LDAPOID
+ }
+
+ LDAPOID is defined in [RFC2251], section 4.1.2.
+
+5.1.1. updateStyleOID
+
+ The updateStyleOID is an OID that uniquely identifies the LBURP
+ update style being used. This document defines one LBURP update
+ semantic style that can be transmitted between the StartLBURPRequest
+ and EndLBURPRequest. The updateStyleOID is included in the protocol
+ for future expansion of additional update styles. For example, a
+ future specification might define an update style with semantics to
+ replace all existing entries with a new set of entries and thus only
+ allows the Add operation.
+
+ The updateStyleOID for the LBURP Incremental Update style is
+ 1.3.6.1.1.17.7. The semantics of this update style are described in
+ section 6.
+
+5.2. StartLBURPResponse
+
+ The responseName of the StartLBURPResponse is the OID 1.3.6.1.1.17.2.
+
+ The optional response element contains the BER-encoding of the
+ following ASN.1:
+
+ StartLBURPResponseValue ::= maxOperations
+
+ maxOperations ::= INTEGER (0 .. maxInt)
+
+ maxInt INTEGER ::= 2147483647 -- (2^^31 - 1) --
+
+
+
+
+
+
+
+
+
+
+
+Harrison, et al. Informational [Page 7]
+
+RFC 4373 LDAP Bulk Update/Replication Protocol January 2006
+
+
+5.2.1. maxOperations
+
+ When present, the value of maxOperations instructs the supplier to
+ send no more than that number of update operations per
+ LBURPUpdateRequest.updateOperationList (see section 5.3.2). If the
+ consumer does not send a maxOperations value, it MUST be prepared to
+ accept any number of update operations per
+ LBURPUpdateRequest.updateOperationList. The supplier MAY send fewer
+ but MUST NOT send more than maxOperations update operations in a
+ single LBURPUpdateRequest.updateOperationList.
+
+5.3. LBURPUpdateRequest
+
+ The LBURPUpdateRequest message is used to send a set of zero or more
+ LDAP update operations from the supplier to the consumer along with
+ sequencing information that enables the consumer to maintain the
+ proper sequencing of multiple asynchronous LBURPUpdateRequest
+ messages.
+
+ The requestName of the LBURPUpdateRequest is the OID 1.3.6.1.1.17.5.
+
+ The requestValue of an LBURPOperation contains the BER-encoding of
+ the following ASN.1:
+
+ LBURPUpdateRequestValue ::= SEQUENCE {
+ sequenceNumber INTEGER (1 .. maxInt),
+ updateOperationList UpdateOperationList
+ }
+
+5.3.1. sequenceNumber
+
+ The sequenceNumber orders associated LBURPOperation requests. This
+ enables the consumer to process LBURPOperation requests in the order
+ specified by the supplier. The supplier MUST set the value of
+ sequenceNumber of the first LBURPUpdateRequest to 1, and MUST
+ increment the value of sequenceNumber by 1 for each succeeding
+ LBURPUpdateRequest. In the unlikely event that the number of
+ LBURPUpdateRequest messages exceeds maxInt, a sequenceNumber value of
+ 1 is deemed to be the succeeding sequence number following a sequence
+ number of maxInt.
+
+
+
+
+
+
+
+
+
+
+
+Harrison, et al. Informational [Page 8]
+
+RFC 4373 LDAP Bulk Update/Replication Protocol January 2006
+
+
+5.3.2. UpdateOperationList
+
+ The UpdateOperationList is a list of one or more standard LDAP update
+ requests and is defined as follows:
+
+ UpdateOperationList ::= SEQUENCE OF SEQUENCE{
+ updateOperation CHOICE {
+ addRequest AddRequest,
+ modifyRequest ModifyRequest,
+ delRequest DelRequest,
+ modDNRequest ModifyDNRequest
+ },
+ controls [0] Controls OPTIONAL
+ }
+
+ AddRequest, ModifyRequest, DelRequest, and ModifyDNRequest are
+ defined in [RFC2251], sections 4.6, 4.7, 4.8, and 4.9.
+
+ The LDAP update requests in the UpdateOperationList MUST be applied
+ to the DIT in the order in which they are listed.
+
+5.4. LBURPUpdateResponse
+
+ An LBURPUpdateResponse message is sent from the consumer to the
+ supplier to signal that all of the update operations from the
+ UpdateOperationList of an LBURPUpdateRequest have been completed and
+ to give the results for the update operations from that list.
+
+ The responseName of the LBURPUpdateResponse is the OID
+ 1.3.6.1.1.17.6.
+
+ If the consumer server cannot successfully decode an
+ LBURPUpdateRequest in its entirety, the resultCode for the
+ corresponding LBURPUpdateResponse is set to protocolError and the
+ response element is omitted. Updates from the LBURPUpdateRequest
+ SHALL NOT be committed to the DIT in this circumstance.
+
+ If the status of all of the update operations being reported by an
+ LBURPUpdateResponse message is success, the resultCode of the
+ LBURPUpdateResponse message is set to success and the response
+ element is omitted.
+
+ If the status of any of the update operations being reported by an
+ LBURPUpdateResponse message is something other than success, the
+ resultCode for the entire LBURPUpdateResponse is set to other to
+ signal that the response element is present.
+
+
+
+
+
+Harrison, et al. Informational [Page 9]
+
+RFC 4373 LDAP Bulk Update/Replication Protocol January 2006
+
+
+5.4.1. OperationResults
+
+ When a response element is included in an LBURPUpdateResponse
+ message, it contains the BER-encoding of the following ASN.1:
+
+ OperationResults ::= SEQUENCE OF OperationResult
+
+ OperationResult ::= SEQUENCE {
+ operationNumber INTEGER,
+ ldapResult LDAPResult
+ }
+
+ An OperationResult is included for each operation from the
+ UpdateOperationList that failed during processing.
+
+5.4.1.1. operationNumber
+
+ The operationNumber identifies the LDAP update operation from the
+ UpdateOperationList of the LBURPUpdateRequest that failed.
+ Operations are numbered beginning at 1.
+
+5.4.1.2. ldapResult
+
+ The ldapResult included in the OperationResult is the same ldapResult
+ that would be sent for the update operation that failed if it had
+ failed while being processed as a normal LDAP update operation.
+ LDAPResult is defined in [RFC2251], section 4.1.10.
+
+5.5. EndLBURPRequest
+
+ The requestName of the EndLBURPRequest is the OID 1.3.6.1.1.17.3.
+
+ The requestValue contains the BER-encoding of the following ASN.1:
+
+ EndLBURPRequestValue::= SEQUENCE {
+ sequenceNumber INTEGER (1 .. maxInt)
+ }
+
+5.5.1. sequenceNumber
+
+ The value in sequenceNumber is one greater than the last
+ LBURPUpdateRequest.sequenceNumber in the update stream. It allows
+ the server to know when it has received all outstanding asynchronous
+ LBURPUpdateRequests.
+
+
+
+
+
+
+
+Harrison, et al. Informational [Page 10]
+
+RFC 4373 LDAP Bulk Update/Replication Protocol January 2006
+
+
+5.6. EndLBURPResponse
+
+ The responseName of the EndLBURPResponse is the OID 1.3.6.1.1.17.4.
+
+ There is no response element in the EndLBURPResponse message.
+
+6. Semantics of the Incremental Update Style
+
+ The initial state of entries in the consumer's DIT plus the
+ LBURPUpdateRequest messages in the update stream collectively
+ represent the desired final state of the consumer's DIT. All LDAP
+ update operations defined in [RFC2251]--Add, Modify, Delete, and
+ Modify DN--are allowed in the incremental update stream. All of the
+ semantics of those operations are in effect, so for instance, an
+ attempt to add an entry that already exists will fail just as it
+ would during a normal LDAP Add operation.
+
+7. General LBURP Semantics
+
+ The consumer server may take any action required to efficiently
+ process the updates sent via LBURP, as long as the final state is
+ equivalent to that which would have been achieved if the updates in
+ the update stream had been applied to the DIT using normal LDAP
+ update operations.
+
+ The LBURPUpdateRequest messages that form the update stream MAY be
+ sent asynchronously by the supplier to the consumer. This means that
+ the supplier need not wait for an LBURPUpdateResponse message for one
+ LBURPUpdateRequest message before sending the next LBURPUpdateRequest
+ message.
+
+ When the LBURP update stream contains a request that affects multiple
+ Directory System Agents (DSAs), the consumer MAY choose to perform
+ the request or return a resultCode value of affectsMultipleDSAs. As
+ with any LDAP operation, a consumer MAY send a resultCode value of
+ referral as part of the OperationResult element for any operation on
+ an entry that it does not contain. If the consumer is configured to
+ do so, it MAY chain on behalf of the supplier to complete the update
+ operation instead.
+
+ While a consumer server is processing an LBURP update stream, it may
+ choose not to service LDAP requests on other connections. This
+ provision is designed to allow implementers the freedom to implement
+ highly-efficient methods of handling the update stream without being
+ constrained by the need to maintain a live, working DIT database
+ while doing so.
+
+
+
+
+
+Harrison, et al. Informational [Page 11]
+
+RFC 4373 LDAP Bulk Update/Replication Protocol January 2006
+
+
+ If a consumer chooses to refuse LDAP operation requests from other
+ suppliers during LBURP update, it is RECOMMENDED that the consumer
+ refer those requests to another server that has the appropriate data
+ to complete the operation.
+
+ Unless attribute values specifying timestamps are included as part of
+ the update stream, updates made using LBURP are treated the same as
+ other LDAP operations wherein they are deemed to occur at the
+ present. Consumers MAY store timestamp values sent by suppliers but
+ are not required to do so.
+
+ Implementations may choose to perform the operations in the update
+ stream with special permissions to improve performance.
+
+ Consumer implementations should include functionality to detect and
+ terminate connections on which an LBURP session has been initiated
+ but information (such as the EndLBURPRequest) needed to complete the
+ LBURP session is never received. A timeout is one mechanism that can
+ be used to accomplish this.
+
+8. Security Considerations
+
+ Implementations should ensure that a supplier making an LBURP request
+ is properly authenticated and authorized to make the updates
+ requested. There is a potential for loss of data if updates are made
+ to the DIT without proper authorization. If LBURP is used for
+ replication, implementers should note that unlike other replication
+ protocols, no existing replication agreement between supplier and
+ consumer is required. These risks increase if the consumer server
+ also processes the update stream with special permissions to improve
+ performance. For these reasons, implementers should carefully
+ consider which permissions should be required to perform LBURP
+ operations and take steps to ensure that only connections with
+ appropriate authorization are allowed to perform them.
+
+ The data contained in the update stream may contain passwords and
+ other sensitive data. Care should be taken to properly safeguard
+ this information while in transit between supplier and consumer. The
+ StartTLS [RFC2830] operation is one mechanism that can be used to
+ provide data confidentiality and integrity services for this purpose.
+
+ As with any asynchronous LDAP operation, it may be possible for an
+ LBURP supplier to send asynchronous LBURPUpdateRequest messages to
+ the consumer faster than the consumer can process them. Consumer
+ implementers should take steps to prevent LBURP suppliers from
+ interfering with the normal operation of a consumer server by issuing
+ a rapid stream of asynchronous LBURPUpdateRequest messages.
+
+
+
+
+Harrison, et al. Informational [Page 12]
+
+RFC 4373 LDAP Bulk Update/Replication Protocol January 2006
+
+
+9. IANA Considerations
+
+ Registration of the following values has been made by the IANA
+ [RFC3383].
+
+9.1. LDAP Object Identifier Registrations
+
+ The IANA has registered LDAP Object Identifiers identifying the
+ protocol elements defined in this technical specification. The
+ following registration template was provided:
+
+ Subject: Request for LDAP OID Registration
+ Person & email address to contact for further information:
+ Roger Harrison
+ rharrison at novell.com
+ Specification: RFC 4373
+ Author/Change Controller: IESG
+ Comments:
+ Seven delegations will be made under the assigned OID. The
+ following 6 OIDs are Protocol Mechanism OIDs of type "E"
+ (supportedExtension):
+
+ 1.3.6.1.1.17.1 StartLBURPRequest LDAP ExtendedRequest message
+ 1.3.6.1.1.17.2 StartLBURPResponse LDAP ExtendedResponse message
+ 1.3.6.1.1.17.3 EndLBURPRequest LDAP ExtendedRequest message
+ 1.3.6.1.1.17.4 EndLBURPResponse LDAP ExtendedResponse message
+ 1.3.6.1.1.17.5 LBURPUpdateRequest LDAP ExtendedRequest message
+ 1.3.6.1.1.17.6 LBURPUpdateResponse LDAP ExtendedResponse message
+
+ The following 1 OID is a Protocol Mechanism OID of type "F"
+ (supportedFeature):
+
+ 1.3.6.1.1.17.7 LBURP Incremental Update style OID
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Harrison, et al. Informational [Page 13]
+
+RFC 4373 LDAP Bulk Update/Replication Protocol January 2006
+
+
+10. Normative References
+
+ [RFC2119] Bradner, S., "Key Words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2251] Wahl, M., Howes, T., and S. Kille, "Lightweight Directory
+ Access Protocol (v3)", RFC 2251, December 1997.
+
+ [RFC3383] Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
+ Considerations for the Lightweight Directory Access
+ Protocol (LDAP)", BCP 64, RFC 3383, September 2002.
+
+ [X.680] ITU-T Recommendation X.680 (07/2002) | ISO/IEC 8824-1:2002
+ "Information Technology - Abstract Syntax Notation One
+ (ASN.1): Specification of basic notation"
+
+ [X.690] ITU-T Rec. X.690 (07/2002) | ISO/IEC 8825-1:2002,
+ "Information technology - ASN.1 encoding rules:
+ Specification of Basic Encoding Rules (BER), Canonical
+ Encoding Rules (CER) and Distinguished Encoding Rules
+ (DER)", 2002.
+
+11. Informative References
+
+ [RFC2830] Hodges, J., Morgan, R., and M. Wahl, "Lightweight
+ Directory Access Protocol (v3): Extension for Transport
+ Layer Security", RFC 2830, May 2000.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Harrison, et al. Informational [Page 14]
+
+RFC 4373 LDAP Bulk Update/Replication Protocol January 2006
+
+
+Authors' Addresses
+
+ Roger Harrison
+ Novell, Inc.
+ 1800 S. Novell Place
+ Provo, UT 84606
+
+ Phone: +1 801 861 2642
+ EMail: rharrison at novell.com
+
+
+ Jim Sermersheim
+ Novell, Inc.
+ 1800 S. Novell Place
+ Provo, UT 84606
+
+ Phone: +1 801 861 3088
+ EMail: jimse at novell.com
+
+
+ Yulin Dong
+
+ EMail: yulindong at gmail.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Harrison, et al. Informational [Page 15]
+
+RFC 4373 LDAP Bulk Update/Replication Protocol January 2006
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2006).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr at ietf.org.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is provided by the IETF
+ Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Harrison, et al. Informational [Page 16]
+
Added: openldap/vendor/openldap-release/doc/rfc/rfc4403.txt
===================================================================
--- openldap/vendor/openldap-release/doc/rfc/rfc4403.txt (rev 0)
+++ openldap/vendor/openldap-release/doc/rfc/rfc4403.txt 2007-09-15 10:38:52 UTC (rev 844)
@@ -0,0 +1,2355 @@
+
+
+
+
+
+
+Network Working Group B. Bergeson
+Request for Comments: 4403 K. Boogert
+Category: Informational Novell, Inc.
+ V. Nanjundaswamy
+ Oracle India Pvt. Ltd.
+ February 2006
+
+
+ Lightweight Directory Access Protocol (LDAP) Schema for
+ Universal Description, Discovery, and Integration version 3 (UDDIv3)
+
+Status of This Memo
+
+ This memo provides information for the Internet community. It does
+ not specify an Internet standard of any kind. Distribution of this
+ memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2006).
+
+Abstract
+
+ This document defines the Lightweight Directory Access Protocol
+ (LDAPv3) schema for representing Universal Description, Discovery,
+ and Integration (UDDI) data types in an LDAP directory. It defines
+ the LDAP object class and attribute definitions and containment rules
+ to model UDDI entities, defined in the UDDI version 3 information
+ model, in an LDAPv3-compliant directory.
+
+Table of Contents
+
+ 1. Introduction ....................................................2
+ 2. Conventions Used in This Document ...............................2
+ 3. Representation of UDDI Data Structures ..........................2
+ 4. Attribute Type Definitions ......................................6
+ 5. Object Class Definitions .......................................28
+ 6. Name Forms .....................................................32
+ 7. DIT Structure Rules ............................................35
+ 8. Security Considerations ........................................37
+ 9. IANA Considerations ............................................37
+ 10. Normative References ..........................................40
+
+
+
+
+
+
+
+
+
+Bergeson, et al. Informational [Page 1]
+
+RFC 4403 LDAP Schema for UDDIv3 February 2006
+
+
+1. Introduction
+
+ This document defines the Lightweight Directory Access Protocol
+ [LDAPv3] schema elements to represent the core data structures
+ identified in the Universal Description, Discovery, and Integration
+ version 3 [UDDIv3] information model. This includes a
+ businessEntity, a businessService, a bindingTemplate, a tModel, a
+ publisherAssertion, and a Subscription. Portions of [UDDIv3] are
+ repeated here for clarity.
+
+2. Conventions Used in This Document
+
+ The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in RFC 2119 [RFC2119].
+
+ All schema definitions are provided using [RFC2252] descriptions, and
+ are line-wrapped for readability only.
+
+3. Representation of UDDI Data Structures
+
+ The information that makes up a registration in a UDDI registry
+ consists of these data structure types. This division by information
+ type provides simple partitions to assist in the rapid location and
+ understanding of the different information that makes up a
+ registration.
+
+ The individual instance data managed by a UDDI registry is sensitive
+ to the parent/child relationships found in the schema. A
+ businessEntity object contains one or more unique businessService
+ objects. Similarly, individual businessService objects contain
+ specific instances of bindingTemplate, which in turn contains
+ information that includes pointers to specific instances of tModel
+ objects.
+
+ It is important to note that no single instance of a core schema type
+ is ever "contained" by more than one parent instance. This means
+ that only one specific businessEntity object (identified by its
+ unique key value) will ever contain or be used to express information
+ about a specific instance of a businessService object (also
+ identified by its own unique key value).
+
+3.1. businessEntity
+
+ The businessEntity object represents all known information about a
+ business or entity that publishes descriptive information about the
+ entity as well as the services that it offers. The businessEntity is
+ the top-level container that accommodates holding descriptive
+
+
+
+Bergeson, et al. Informational [Page 2]
+
+RFC 4403 LDAP Schema for UDDIv3 February 2006
+
+
+ information about a business or entity. Service descriptions and
+ technical information are expressed within a businessEntity by a
+ containment relationship.
+
+3.1.1. Representation in the Directory
+
+ A businessEntity is represented in the directory by the attributes
+ uddiBusinessKey, uddiAuthorizedName, uddiOperator, uddiDiscoveryURLs,
+ uddiName, uddiDescription, uddiIdentifierBag, uddiCategoryBag, and
+ uddiv3DigitalSignature, along with corresponding v3 keys viz.
+ uddiv3BusinessKey, as defined in Section 4. A businessEntity may
+ contain zero or more instances of uddiContact and
+ uddiBusinessService.
+
+ A mandatory attribute, uddiBusinessKey, contains the unique
+ identifier for a given instance of a businessEntity.
+
+ businessEntity's definition is given in Section 5.
+
+3.2. businessService
+
+ The businessService instances represent a logical business service.
+ Each businessService object is the logical child of a single
+ businessEntity object. Each businessService element contains
+ descriptive information in business terms outlining the type of
+ technical services found within each businessService instance.
+
+ In some cases, businesses would like to share or reuse services,
+ e.g., when a large enterprise publishes separate businessEntity
+ structures. This can be established by using the businessService
+ instance as a projection to an already published businessService.
+
+3.2.1. Representation in the Directory
+
+ A businessService is represented in the directory by the attributes
+ uddiBusinessKey, uddiServiceKey, uddiName, uddiDescription,
+ uddiCategoryBag, uddiIsProjection, and uddiv3DigitalSignature, along
+ with corresponding v3 keys viz. uddiv3BusinessKey, and
+ uddiv3ServiceKey, as defined in Section 4. A businessService may
+ contain zero or more instances of uddiBindingTemplate.
+
+ The mandatory attribute, uddiServiceKey, contains the unique
+ identifier for a given instance of a businessService.
+
+ businessService's definition is given in Section 5.
+
+
+
+
+
+
+Bergeson, et al. Informational [Page 3]
+
+RFC 4403 LDAP Schema for UDDIv3 February 2006
+
+
+3.3. bindingTemplate
+
+ Technical descriptions of Web services are accommodated via
+ individual contained instances of bindingTemplate objects. These
+ instances provide support for determining a technical entry point or
+ optionally support remotely hosted services, as well as a lightweight
+ facility for describing unique technical characteristics of a given
+ implementation. Support for technology and application specific
+ parameters and settings files are also supported.
+
+ Since UDDI's main purpose is to enable description and discovery of
+ Web service information, it is the bindingTemplate that provides the
+ most interesting technical data. With UDDIv3, bindingTemplates also
+ can have categorization information.
+
+ Each bindingTemplate instance has a single logical businessService
+ parent, which in turn has a single logical businessEntity parent.
+
+3.3.1. Representation in the Directory
+
+ A bindingTemplate is represented in the directory by the attributes
+ uddiBindingKey, uddiServiceKey, uddiDescription, uddiAccessPoint,
+ uddiHostingRedirector, uddiCategoryBag, and uddiv3DigitalSignature,
+ along with corresponding v3 keys viz. uddiv3ServiceKey and
+ uddiv3BindingKey, as defined in Section 4. A bindingTemplate may
+ contain zero or more instances of uddiTModelInstanceDetails.
+
+ The mandatory attribute, uddiBindingKey, contains the unique
+ identifier for a given instance of a bindingTemplate.
+
+ BindingTemplate's definition is given in Section 5.
+
+3.4. tModel
+
+ The tModel object takes the form of keyed metadata (data about data).
+ In a general sense, the purpose of a tModel within the UDDI registry
+ is to provide a reference system based on abstraction. Thus, the
+ kind of data that a tModel represents is pretty nebulous. In other
+ words, a tModel registration can define just about anything, but in
+ the current revision, two conventions have been applied for using
+ tModels: as sources for determining compatibility and as keyed
+ namespace references.
+
+ The information that makes up a tModel is quite simple. There are a
+ key, a name, an optional description, and a Uniform Resource Locator
+ [URL] that points somewhere--presumably somewhere where the curious
+ can go to find out more about the actual concept represented by the
+ metadata in the tModel itself.
+
+
+
+Bergeson, et al. Informational [Page 4]
+
+RFC 4403 LDAP Schema for UDDIv3 February 2006
+
+
+3.4.1. Representation in the Directory
+
+ A tModel is represented in the directory by the attributes
+ uddiTModelKey, uddiAuthorizedName, uddiOperator, uddiName,
+ uddiDescription, uddiOverviewDescription, uddiOverviewURL,
+ uddiIdentifierBag, uddiCategoryBag, uddiIsHidden, and
+ uddiv3DigitalSignature, along with the corresponding v3 key viz.
+ uddiv3tModelKey, as defined in Section 4. A tModel may also contain
+ a uddiHidden to logically delete a tModel.
+
+ A mandatory attribute, uddiTModelKey, contains the unique identifier
+ for a given instance of a tModel.
+
+ tModel's definition is given in Section 5.
+
+3.5. publisherAssertion
+
+ Many businesses, such as large enterprises or marketplaces, are not
+ effectively represented by a single businessEntity, since their
+ description and discovery are likely to be diverse. As a
+ consequence, several businessEntity instances can be published,
+ representing individual subsidiaries of a large enterprise or
+ individual participants of a marketplace. Nevertheless, they still
+ represent a more or less coupled community and would like to make
+ some of their relationships visible in their UDDI registrations.
+
+3.5.1. Representation in the Directory
+
+ A publisherAssertion is represented in the directory by the
+ attributes uddiFromKey, uddiToKey, uddiKeyedReference, and uddiUUID,
+ and uddiv3DigitalSignature, as defined in Section 5.
+
+ A mandatory attribute, uddiUUID, contains the unique identifier for a
+ given instance of a publisherAssertion.
+
+ publisherAssertion's definition is given in Section 5.
+
+3.6. Operational Information:
+
+ With UDDIv3, the operational information associated with the core
+ UDDI data structures is maintained in a separate OperationalInfo
+ structure, so that the digital signature specified by the publisher
+ remains valid.
+
+ The operationalInfo structure is used to convey the operational
+ information for the UDDIv3 core data structures, that is, the
+ businessEntity, businessService, bindingTemplate, and tModel
+
+
+
+
+Bergeson, et al. Informational [Page 5]
+
+RFC 4403 LDAP Schema for UDDIv3 February 2006
+
+
+ structures. UDDIv3 OperationalInfo consists of 5 elements: created,
+ Modified, modifiedIncludingChildren, nodeId, and authorizedName.
+
+ Depending on the specific UDDIv3 core data structure, the
+ operationalInformation is represented in the directory as a
+ combination of implicit LDAP Standard Operational attributes:
+ createTimestamp and modifyTimestamp, and the following explicit
+ attributes: uddiAuthorizedName, uddiv3EntityCreationTime,
+ uddiv3EntityModificationTime, and uddiv3NodeId.
+
+4. Attribute Type Definitions
+
+ The OIDs for the attribute types in this document have been
+ registered by the IANA.
+
+4.1. uddiBusinessKey
+
+ This is used in uddiBusinessEntity and uddiBusinessService.
+
+ The uddiBusinessKey is the unique identifier for a given instance of
+ a uddiBusinessEntity. The attribute is optional for businessService
+ instances contained within a fully expressed parent that already
+ contains a businessKey value.
+
+ If the businessService instance is rendered into the Extensible
+ Markup Language [XML] and has no containing parent that has within
+ its data a businessKey, the value of the businessKey that is the
+ parent of the businessService is required to be provided. This
+ behavior supports the ability to browse through the parent-child
+ relationships given any of the core elements as a starting point.
+ The businessKey may differ from the publishing businessEntity's
+ businessKey to allow service projections.
+
+ ( 1.3.6.1.1.10.4.1 NAME 'uddiBusinessKey'
+ DESC 'businessEntity unique identifier'
+ EQUALITY caseIgnoreMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ SINGLE-VALUE
+ )
+
+4.2. uddiAuthorizedName
+
+ The uddiAuthorizedName is the recorded name of the individual who
+ published the uddiBusinessEntity or uddiTModel data. This data is
+ generated by the controlling operator and should not be supplied
+ within save_business operations.
+
+ With UDDIv3, this attribute is part of the "operationalInformation"
+
+
+
+Bergeson, et al. Informational [Page 6]
+
+RFC 4403 LDAP Schema for UDDIv3 February 2006
+
+
+ metadata associated with core data structures.
+
+ ( 1.3.6.1.1.10.4.2 NAME 'uddiAuthorizedName'
+ DESC 'businessEntity publisher name'
+ EQUALITY distinguishedNameMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
+ SINGLE-VALUE
+ )
+
+4.3. uddiOperator
+
+ The uddiOperator is the certified name of the UDDI registry site
+ operator that manages the master copy of the uddiBusinessEntity or
+ uddiTModel. The controlling operator records this data at the time
+ data is saved. This data is generated and should not be supplied
+ within save_business or save_tModel operations.
+
+ With UDDIv3, this field is no longer used -- it is replaced by the
+ nodeId (uddiv3NodeId) attribute that is part of the
+ "operationalInformation" metadata.
+
+ ( 1.3.6.1.1.10.4.3 NAME 'uddiOperator'
+ DESC 'registry site operator of businessEntitys master copy'
+ EQUALITY caseIgnoreMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ SINGLE-VALUE
+ )
+
+4.4. uddiName
+
+ This is used in uddiBusinessEntity, uddiBusinessService, and
+ uddiTModel.
+
+ These are the human-readable names recorded for the
+ uddiBusinessEntity, uddiBusinessService, or uddiTModel, adorned with
+ a unique xml:lang value to signify the language that they are
+ expressed in. Name search is provided via find_business,
+ find_service, or find_tModel calls.
+
+ The publishing of several names, e.g., for romanization purposes, is
+ supported. In order to signify the language that the names are
+ expressed in, they carry unique xml:lang values. Not more than one
+ name element may omit specifying its language. Names passed in this
+ way will be assigned the default language code of the registering
+ party. This default language code is established at the time that
+ publishing credentials are established with an individual Operator
+
+
+
+
+
+Bergeson, et al. Informational [Page 7]
+
+RFC 4403 LDAP Schema for UDDIv3 February 2006
+
+
+ Site. If no default language is provisioned at the time a publisher
+ signs up, the operator can adopt an appropriate default language
+ code.
+
+ With UDDIv3, multiple values with the same language code are
+ permitted.
+
+ ( 1.3.6.1.1.10.4.4 NAME 'uddiName'
+ DESC 'human readable name'
+ EQUALITY caseIgnoreMatch
+ ORDERING caseIgnoreOrderingMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ )
+
+ The xml:lang value precedes the name value, with the "#" character
+ used as the separator.
+
+4.5. uddiDescription
+
+ The uddiDescription is an optional repeating element of one or more
+ descriptions. One description is allowed per national language code
+ supplied. With UDDIv3, there is no restriction on the number of
+ descriptions or on what xml:lang value that they may have.
+
+ ( 1.3.6.1.1.10.4.5 NAME 'uddiDescription'
+ DESC 'short description'
+ EQUALITY caseIgnoreMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ )
+
+ The xml:lang value precedes the name value, with the "#" character
+ used as the separator.
+
+4.6. uddiDiscoveryURLs
+
+ This is a list of Uniform Resource Locators (URLs) that point to
+ alternate, file-based service discovery mechanisms. Each recorded
+ uddiBusinessEntity structure is automatically assigned a URL that
+ returns the individual uddiBusinessEntity structure. A URL search is
+ provided via find_business call.
+
+ The uddiDiscoveryURLs attribute is used to hold pointers to URL-
+ addressable discovery documents. The expected retrieval mechanism
+ for URLs referenced in the data within this structure is via the
+ Hypertext Transfer Protocol [HTTP] HTTP-GET operation. The expected
+ return document is not defined. Rather, a framework for establishing
+ conventions is provided, and two such conventions are defined within
+
+
+
+Bergeson, et al. Informational [Page 8]
+
+RFC 4403 LDAP Schema for UDDIv3 February 2006
+
+
+ UDDI behaviors. It is hoped that other conventions come about and
+ use this structure to accommodate alternate means of discovery. With
+ UDDIv3, a new convention is defined with useType as "homepage".
+ Further, a UDDIv3 server need not generate/add a discoveryURL itself,
+ since this can invalidate the digital signature of signed the
+ Business Entity saved by publishers.
+
+ ( 1.3.6.1.1.10.4.6 NAME 'uddiDiscoveryURLs'
+ DESC 'URL to retrieve a businessEntity instance'
+ EQUALITY caseIgnoreMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ )
+
+ The useType value precedes the URL value, with the "#" character used
+ as the separator.
+
+4.7. uddiUseType
+
+ The uddiUseType is used to describe the type of contact or address in
+ freeform text. Suggested examples for contact include "technical
+ questions", "technical contact", "establish account", "sales
+ contact", etc. Suggested examples for address include
+ "headquarters", "sales office", "billing department", etc.
+
+ ( 1.3.6.1.1.10.4.7 NAME 'uddiUseType'
+ DESC 'name of convention the referenced document follows'
+ EQUALITY caseIgnoreMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ SINGLE-VALUE
+ )
+
+4.8. uddiPersonName
+
+ The uddiPersonName should list the name of the person or name of the
+ job role that will be available behind the contact. Examples of
+ roles include "administrator" or "webmaster".
+
+ ( 1.3.6.1.1.10.4.8 NAME 'uddiPersonName'
+ DESC 'name of person or job role available for contact'
+ EQUALITY caseIgnoreMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ SINGLE-VALUE
+ )
+
+ With UDDIv3, uddiPersonName becomes multi-valued and each name can
+ have an xml:lang attribute. The xml:lang value precedes the name
+ value with the "#" character used as the separator.
+
+
+
+
+Bergeson, et al. Informational [Page 9]
+
+RFC 4403 LDAP Schema for UDDIv3 February 2006
+
+
+4.9. uddiPhone
+
+ This is used to hold telephone numbers for the contact. This element
+ can be adorned with an optional uddiUseType attribute for descriptive
+ purposes. If more than one phone element is saved, uddiUseType
+ attributes are required on each.
+
+ ( 1.3.6.1.1.10.4.9 NAME 'uddiPhone'
+ DESC 'telephone number for contact'
+ EQUALITY caseIgnoreMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ )
+
+ The useType precedes the telephone number by a separating '#' (e.g.,
+ "Work Number#123 456-7890") .
+
+4.10. uddiEMail
+
+ This is used to hold email addresses for the contact. This element
+ can be adorned with an optional uddiUseType attribute for descriptive
+ purposes. If more than one email element is saved, uddiUseType
+ attributes are required on each.
+
+ ( 1.3.6.1.1.10.4.10 NAME 'uddiEMail'
+ DESC 'e-mail address for contact'
+ EQUALITY caseIgnoreMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ )
+
+ The useType precedes the email address by a separating '#' (e.g.,
+ "President of the United States #president at whitehouse.gov").
+
+4.11. uddiSortCode
+
+ The uddiSortCode is used to drive the behavior of external display
+ mechanisms that sort addresses. The suggested values for
+ uddiSortCode include numeric ordering values (e.g., 1, 2, 3),
+ alphabetic character ordering values (e.g., a, b, c), or the first n
+ positions of relevant data within the address.
+
+ ( 1.3.6.1.1.10.4.11 NAME 'uddiSortCode'
+ DESC 'specifies an external display mechanism'
+ EQUALITY caseIgnoreMatch
+ ORDERING caseIgnoreOrderingMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ SINGLE-VALUE
+ )
+
+
+
+
+Bergeson, et al. Informational [Page 10]
+
+RFC 4403 LDAP Schema for UDDIv3 February 2006
+
+
+ With UDDIv3, the sortCode attribute is deprecated because of the
+ guarantee of preserving the document Order.
+
+4.12. uddiTModelKey
+
+ The uddiTModelKey is the unique identifier for a given instance of an
+ uddiTModel.
+
+ It is also used in a KeyedReference and in Address structures. When
+ used with a keyed reference, this is the unique key to identify a
+ value set and implies that the keyName keyValue pair in a
+ uddiIdentifier or uddiCategory Bag are to be interpreted by the value
+ set referenced by the tModelKey.
+
+ When used with Addressline elements, it implies that the keyName
+ keyValue pair given by subsequent uddiAddressLine elements are to be
+ interpreted by the address structure associated with the tModel that
+ is referenced.
+
+ ( 1.3.6.1.1.10.4.12 NAME 'uddiTModelKey'
+ DESC 'tModel unique identifier'
+ EQUALITY caseIgnoreMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ SINGLE-VALUE
+ )
+
+4.13. uddiAddressLine
+
+ The uddiAddressLine contains the actual address in freeform text. If
+ the address element contains a uddiTModelKey, these uddiAddressLine
+ elements are to be adorned, each with an optional keyName keyValue
+ attribute pair. Together with the uddiTModelKey, keyName and
+ keyValue qualify the uddiAddressLine in order to describe its
+ meaning.
+
+ The uddiAddressLine elements contain string data with a line length
+ limit of 80 character positions. Each uddiAddressLine element can be
+ adorned with two optional descriptive attributes, keyName and
+ keyValue. Both attributes must be present in each address line if a
+ uddiTModelKey is assigned to the address structure. By doing this,
+ the otherwise arbitrary use of address lines becomes structured.
+ Together with the address' uddiTModelKey, keyName and keyValue
+ virtually build a uddiKeyedReference that represents an address line
+ qualifier, given by the referenced uddiTModel.
+
+ When no uddiTModelKey is provided for the address structure, the
+ keyName and keyValue attributes can be used without restrictions, for
+ example, to provide descriptive information for each uddiAddressLine
+
+
+
+Bergeson, et al. Informational [Page 11]
+
+RFC 4403 LDAP Schema for UDDIv3 February 2006
+
+
+ by using the keyName attribute. Since both the keyName and the
+ keyValue attributes are optional, address line order is significant
+ and will always be returned by the UDDI-compliant registry in the
+ order originally provided during a call to save_business.
+
+ ( 1.3.6.1.1.10.4.13 NAME 'uddiAddressLine'
+ DESC 'address'
+ EQUALITY caseIgnoreMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ )
+
+ The keyName, keyValue, and addressData of this attribute are
+ separated by "#" (e.g., "#"<keyName>"#"<keyValue>"#"<addressData>).
+ The addressData is the only required portion of the attribute.
+
+4.14. uddiIdentifierBag
+
+ The uddiIdentifierBag element allows uddiBusinessEntity or uddiTModel
+ structures to include information about common forms of
+ identification such as D-U-N-S_ numbers, tax identifiers, etc. This
+ data can be used to signify the identity of the uddiBusinessEntity or
+ can be used to signify the identity of the publishing party.
+ Including data of this sort is optional, but when used greatly
+ enhances the search behaviors exposed via the find_xx messages
+ defined in the UDDI Version 2.0 API Specification [UDDIapi]. For a
+ full description of the structures involved in establishing an
+ identity, see UDDI Version 2.0 Data Structure Specification -
+ Appendix A: Using Identifiers [UDDIdsr].
+
+ ( 1.3.6.1.1.10.4.14 NAME 'uddiIdentifierBag'
+ DESC 'identification information'
+ EQUALITY caseIgnoreMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ )
+
+ The tModel, keyName, and keyValue of this attribute are separated by
+ "#" (e.g., <tModel>"#"<keyName>"#"<keyValue>). The keyValue is the
+ only required portion of the attribute.
+
+4.15. uddiCategoryBag
+
+ The uddiCategoryBag element allows uddiBusinessEntity,
+ uddiBusinessService, and uddiTModel structures to be categorized
+ according to any of several available taxonomy-based classification
+ schemes. Operator Sites automatically provide validated
+ categorization support for three taxonomies that cover industry codes
+ (via NAICS), product and service classifications (via UNSPC), and
+ geography (via ISO 3166). Including data of this sort is optional,
+
+
+
+Bergeson, et al. Informational [Page 12]
+
+RFC 4403 LDAP Schema for UDDIv3 February 2006
+
+
+ but when used, it greatly enhances the search behaviors exposed by
+ the find_xx messages defined in the UDDI Version 2.0 API
+ Specification [UDDIapi]. For a full description of structures
+ involved in establishing categorization information, see UDDI Version
+ 2.03 Data Structure Specification--Appendix B: Using Categorization
+ [UDDIdsr].
+
+ ( 1.3.6.1.1.10.4.15 NAME 'uddiCategoryBag'
+ DESC 'categorization information'
+ EQUALITY caseIgnoreMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ )
+
+ The tModel, keyName, and keyValue of this attribute are separated by
+ "#" (e.g., <tModel>"#"<keyName>"#"<keyValue>). The keyValue is the
+ only required portion of the attribute.
+
+ With UDDIv3, uddiBindingTemplates also supports the uddiCategoryBag
+ element and they can also be categorized according to any of several
+ available taxonomy-based classification schemes.
+
+4.16. uddiKeyedReference
+
+ The uddiKeyedReference is a general-purpose attribute for a name-
+ value pair, with an additional reference to a tModel.
+
+ ( 1.3.6.1.1.10.4.16 NAME 'uddiKeyedReference'
+ DESC 'categorization information'
+ EQUALITY caseIgnoreMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ )
+
+ The tModel, keyName, and keyValue of this attribute are separated by
+ "#" (e.g., <tModel>"#"<keyName>"#"<keyValue>). The keyValue is the
+ only required portion of the attribute. With UDDIv3, the tModelKey
+ also becomes a mandatory part of the attribute.
+
+ Also, UDDIv3 defines KeyedReferenceGroups for CategoryBags. A
+ keyedReferenceGroup contains a tModelKey and a simple list of
+ KeyedReference structures. The uddiKeyedReference attribute will
+ support KeyedReferenceGroups by suffixing the tModelKey for
+ KeyedReferenceGroup to each of the keyedReference values associated
+ with the group.
+
+ For example, to represent a keyedReference group containing a list of
+ 2 keyed references, the attribute will hold the following 2 strings
+ as its values:
+
+
+
+
+Bergeson, et al. Informational [Page 13]
+
+RFC 4403 LDAP Schema for UDDIv3 February 2006
+
+
+ tModelKey1#KeyName1#KeyValue1#KeyedReferenceGroup1_tModelKey
+ tModelKey2#KeyName2#KeyValue2#KeyedReferenceGroup1_tModelKey
+
+4.17. uddiServiceKey
+
+ This is the unique key for a given uddiBusinessService. When saving
+ a new uddiBusinessService structure, pass an empty uddiServiceKey
+ value. This signifies that a UUID value is to be generated. To
+ update an existing uddiBusinessService structure, pass the UUID value
+ that corresponds to the existing service. If a uddiServiceKey is
+ received via an inquiry operation, the key values may not be blank.
+ When saving a new or updated service projection, pass the
+ uddiServiceKey of the referenced uddiBusinessService structure.
+
+ This attribute is optional when the uddiBindingTemplate data is
+ contained within a fully expressed parent that already contains a
+ uddiServiceKey value. If the uddiBindingTemplate data is rendered
+ into XML and has no containing parent that has within its data a
+ uddiServiceKey, the value of the uddiServiceKey that is the ultimate
+ containing parent of the uddiBindingTemplate is required to be
+ provided. This behavior supports the ability to browse through the
+ parent-child relationships given any of the core elements as a
+ starting point.
+
+ ( 1.3.6.1.1.10.4.17 NAME 'uddiServiceKey'
+ DESC 'businessService unique identifier'
+ EQUALITY caseIgnoreMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ SINGLE-VALUE
+ )
+
+4.18. uddiBindingKey
+
+ This is the unique key for a given uddiBindingTemplate. When saving
+ a new uddiBindingTemplate structure, pass an empty uddiBindingKey
+ value. This signifies that a UUID value is to be generated. To
+ update an existing uddiBindingTemplate, pass the UUID value that
+ corresponds to the existing uddiBindingTemplate instance. If a
+ uddiBindingKey is received via an inquiry operation, the key values
+ may not be blank.
+
+ ( 1.3.6.1.1.10.4.18 NAME 'uddiBindingKey'
+ DESC 'bindingTemplate unique identifier'
+ EQUALITY caseIgnoreMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ SINGLE-VALUE
+ )
+
+
+
+
+Bergeson, et al. Informational [Page 14]
+
+RFC 4403 LDAP Schema for UDDIv3 February 2006
+
+
+4.19. uddiAccessPoint
+
+ The uddiAccessPoint element is an attribute-qualified pointer to a
+ service entry point. The notion of service at the metadata level
+ seen here is fairly abstract and many types of entry points are
+ accommodated. A single attribute is provided named URLType.
+
+ Required attribute-qualified element8: This element is a text field
+ that is used to convey the entry point address suitable for calling a
+ particular Web service. This may be a URL, an electronic mail
+ address, or even a telephone number. No assumptions about the type
+ of data in this field can be made without first understanding the
+ technical requirements associated with the Web service.
+
+ ( 1.3.6.1.1.10.4.19 NAME 'uddiAccessPoint'
+ DESC 'entry point address to call a web service'
+ EQUALITY caseIgnoreMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ SINGLE-VALUE
+ )
+
+ The URLType value precedes the accessPoint value by a separating '#'.
+
+ With UDDIv3, the "URLType" attribute is replaced by a "UseType"
+ attribute. Using this UseType attribute, the accessPoint attribute
+ can model a hostingRedirector or support indirection to indicate that
+ the accesspoint is specified within a remotely hosted WSDL document.
+
+ For a UDDIv3 registry that needs to support UDDIv2 clients, the
+ attribute must allow the representation of URLType and UseType values
+ independently.
+
+ The UDDIv3 spec specifies the following logic for mapping values
+ between URLType and UseType: If an entity is saved with the v3
+ namespace and a v2 inquiry is made, the URLType will be returned as
+ "other". In the case when a v3 inquiry is made on an entity
+ published with the v2 namespace, the v3 useType attribute will be
+ returned as "endPoint".
+
+ For implementations that need to explicitly model both forms, the
+ recommended format is as follows: v2URLType#v3UseType#Address
+
+4.20. uddiHostingRedirector
+
+ The uddiHostingRedirector element is used to designate that a
+ uddiBindingTemplate entry is a pointer to a different
+ uddiBindingTemplate entry. The value in providing this facility is
+ seen when a business or entity wants to expose a service description
+
+
+
+Bergeson, et al. Informational [Page 15]
+
+RFC 4403 LDAP Schema for UDDIv3 February 2006
+
+
+ (e.g., advertise that it has a service available that suits a
+ specific purpose) that is actually a service described in a separate
+ uddiBindingTemplate record. This might occur when a service is
+ remotely hosted (hence the name of this element), or when many
+ service descriptions could benefit from a single service description.
+
+ The uddiHostingRedirector element has a single attribute and no
+ element content. The attribute is a uddiBindingKey value that is
+ suitable within the same UDDI registry instance for querying and
+ obtaining the uddiBindingDetail data that is to be used.
+
+ More on the uddiHostingRedirector can be found in the appendices for
+ the UDDI Version 2.0 API Specification [UDDIapi].
+
+ Required element if uddiAccessPoint is not provided: This element is
+ adorned with a uddiBindingKey attribute, giving the redirected
+ reference to a different uddiBindingTemplate. If you query a
+ uddiBindingTemplate and find a uddiHostingRedirector value, you
+ should retrieve that uddiBindingTemplate and use it in place of the
+ one containing the uddiHostingRedirector data.
+
+ ( 1.3.6.1.1.10.4.20 NAME 'uddiHostingRedirector'
+ DESC 'designates a pointer to another bindingTemplate'
+ EQUALITY caseIgnoreMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ SINGLE-VALUE
+ )
+
+ With UDDIv3, the hostingRedirector is a deprecated element, since its
+ functionality is now covered by the accessPoint. For backward-
+ compatibility, it can still be used, but it is not recommended.
+
+4.21. uddiInstanceDescription
+
+ This is an optional repeating element. This is one or more
+ language-qualified text descriptions that designate what role a
+ uddiTModel reference plays in the overall service description.
+
+ ( 1.3.6.1.1.10.4.21 NAME 'uddiInstanceDescription'
+ DESC 'instance details description'
+ EQUALITY caseIgnoreMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ )
+
+ The xml:lang value precedes the name value, with the "#" character
+ used as the separator.
+
+
+
+
+
+Bergeson, et al. Informational [Page 16]
+
+RFC 4403 LDAP Schema for UDDIv3 February 2006
+
+
+4.22. uddiInstanceParms
+
+ The uddiInstanceParms is an optional element of the uddiInstance. It
+ is used to contain settings parameters or a URL reference to a file
+ that contains settings or parameters required to use a specific facet
+ of a uddiBindingTemplate description. If used to house the
+ parameters themselves, the suggested content is a namespace-qualified
+ XML string using a namespace outside of the UDDI schema. If used to
+ house a URL pointer to a file, the suggested format is a URL that is
+ suitable for retrieving the settings or parameters via HTTP-GET.
+
+ ( 1.3.6.1.1.10.4.22 NAME 'uddiInstanceParms'
+ DESC 'URL reference to required settings'
+ EQUALITY caseIgnoreMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ SINGLE-VALUE
+ )
+
+4.23. uddiOverviewDescription
+
+ This is an optional repeating element. This language-qualified
+ string is intended to hold a short descriptive overview of how a
+ particular uddiTModel is to be used.
+
+ ( 1.3.6.1.1.10.4.23 NAME 'uddiOverviewDescription'
+ DESC 'outlines tModel usage'
+ EQUALITY caseIgnoreMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ )
+
+ The xml:lang value precedes the name value, with the "#" character
+ used as the separator.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bergeson, et al. Informational [Page 17]
+
+RFC 4403 LDAP Schema for UDDIv3 February 2006
+
+
+4.24. uddiOverviewURL
+
+ This is an optional element. This string data element is to be used
+ to hold a URL reference to a long form of an overview document that
+ covers the way a particular uddiTModel specific reference is used as
+ a component of an overall Web service description. The recommended
+ format for the overviewURL is a URI that is suitable for retrieving
+ the actual overview document with an HTTP-GET operation, for example,
+ via a Web browser.
+
+ ( 1.3.6.1.1.10.4.24 NAME 'uddiOverviewURL'
+ DESC 'URL reference to overview document'
+ EQUALITY caseIgnoreMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ SINGLE-VALUE
+ )
+
+ With UDDIv3, uddiOverviewURL becomes multi-valued to allow the
+ representation of multiple OverviewDocs within a single
+ InstanceDetail element.
+
+ Modeling multiple OverviewDocs within an InstanceDetail element:
+
+ In UDDIv3, the InstanceDetails element in TmodelInstanceInfo can have
+ multiple OverviewDoc's. In UDDIv2, we could have only 1 OverviewDoc.
+ To retain the grouping between a set of overviewDescriptions and
+ overviewURL, we can make both OverviewDoc and OverviewURL multi-
+ valued, and have a "group ID" Prefix to each value (to group
+ OverviewDescriptions and OverviewURL).
+
+ An example is shown below:
+
+ Overview Description OverviewURL
+ 1#xml:lang#overviewDescription1 1#UseType#overviewURL
+ 1#xml:lang#overviewDescription2 2#UseType#overviewURL
+ 1#xml:lang#overviewDescription3 4#UseType#overviewURL
+ 3#xml:lang#overviewDescription1
+ 3#xml:lang#overviewDescription2
+ 4#xml:lang#overviewDescription1
+
+ This implies that OverviewDoc1 has 3 overview descriptions and an
+ overviewURL. OverviewDoc2 has only an overviewURL. OverviewDoc3 has
+ only 2 overviewDescriptions. OverviewDoc4 also has 1 overview
+ description and an overviewURL.
+
+
+
+
+
+
+
+Bergeson, et al. Informational [Page 18]
+
+RFC 4403 LDAP Schema for UDDIv3 February 2006
+
+
+4.25. uddiFromKey
+
+ The uddiFromKey is a required element. This is the unique key
+ reference to the first uddiBusinessEntity for which the assertion is
+ made.
+
+ ( 1.3.6.1.1.10.4.25 NAME 'uddiFromKey'
+ DESC 'unique businessEntity key reference'
+ EQUALITY caseIgnoreMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ SINGLE-VALUE
+ )
+
+4.26. uddiToKey
+
+ The uddiToKey is a required element. This is the unique key
+ reference to the second uddiBusinessEntity for which the assertion is
+ made.
+
+ ( 1.3.6.1.1.10.4.26 NAME 'uddiToKey'
+ DESC 'unique businessEntity key reference'
+ EQUALITY caseIgnoreMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ SINGLE-VALUE
+ )
+
+4.27. uddiUUID
+
+ The uddiUUID is a required element. This is to ensure unique
+ identification of uddiContact, uddiAddress, and
+ uddiPublisherAssertion objects.
+
+ ( 1.3.6.1.1.10.4.27 NAME 'uddiUUID'
+ DESC 'unique attribute'
+ EQUALITY caseIgnoreMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ SINGLE-VALUE
+ )
+
+ With UDDIv3, this attribute will also be used for unique
+ identification of Subscription-feature-related entities.
+
+
+
+
+
+
+
+
+
+
+Bergeson, et al. Informational [Page 19]
+
+RFC 4403 LDAP Schema for UDDIv3 February 2006
+
+
+4.28. uddiIsHidden
+
+ This is used to provide functionality for the delete_tModel
+ operation. Logical deletion hides the deleted tModels from
+ find_tModel result sets but does not physically delete it.
+
+ ( 1.3.6.1.1.10.4.28 NAME 'uddiIsHidden'
+ DESC 'isHidden attribute'
+ EQUALITY booleanMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
+ SINGLE-VALUE
+ )
+
+ In case of UDDIv3, this attribute will represent the "deleted"
+ attribute value.
+
+4.29. uddiIsProjection
+
+ This is used to identify a Business Service that has a Service
+ Projection.
+
+ ( 1.3.6.1.1.10.4.29 NAME 'uddiIsProjection'
+ DESC 'isServiceProjection attribute'
+ EQUALITY booleanMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
+ SINGLE-VALUE
+ )
+
+4.30. uddiLang
+
+ This is used to model the xml:lang value for the Address structure in
+ UDDIv3.
+
+ ( 1.3.6.1.1.10.4.30 NAME 'uddiLang'
+ DESC 'xml:lang value in v3 Address structure'
+ EQUALITY caseIgnoreMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ SINGLE-VALUE
+ )
+
+ The following are attribute definitions to model new elements/fields
+ in UDDIv3 information model. These attribute definitions have the
+ "uddiv3" prefix to indicate that these attributes represent UDDI
+ information model elements unique to UDDIv3.
+
+
+
+
+
+
+
+Bergeson, et al. Informational [Page 20]
+
+RFC 4403 LDAP Schema for UDDIv3 February 2006
+
+
+4.31. uddiv3BusinessKey
+
+ This is the unique UDDIv3 identifier for a given instance of
+ uddiBusinessEntity. It is used in uddiBusinessEntity and
+ uddiBusinessService.
+
+ A uddiBusinessEntity will include the uddiBusinessKey (the v2 form)
+ for unique identification by UDDIv2 clients. The uddiBusinessKey
+ (36-char) will also be the LDAP naming attribute for the
+ uddiBusinessEntity. The uddiBusinessEntity entry MAY also include
+ the uddiv3BusinessKey, the explicit v3 form key, which can be 255
+ characters long.
+
+ ( 1.3.6.1.1.10.4.31 NAME 'uddiv3BusinessKey'
+ DESC 'UDDIv3 businessEntity unique identifier'
+ EQUALITY caseIgnoreMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ SINGLE-VALUE
+ )
+
+4.32. uddiv3ServiceKey
+
+ This is the unique UDDIv3 identifier for a given instance of
+ uddiBusinessService. It is used in uddiBusinessService and
+ uddiBindingTemplate.
+
+ A uddiBusinessService will include the uddiServiceKey (the v2 form)
+ for unique identification by UDDIv2 clients. The uddiServiceKey
+ (36-char) will also be the LDAP naming attribute for the
+ uddiBusinessService entry. The uddiBusinessService entry MAY also
+ include the uddiv3ServiceKey, the explicit v3 form key, which can be
+ 255 characters long.
+
+ ( 1.3.6.1.1.10.4.32 NAME 'uddiv3ServiceKey'
+ DESC 'UDDIv3 businessService unique identifier'
+ EQUALITY caseIgnoreMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ SINGLE-VALUE
+ )
+
+4.33. uddiv3BindingKey
+
+ This is the unique UDDIv3 identifier for a given instance of
+ uddiBindingTemplate.
+
+ A uddiBindingTemplate will include the uddiBindingKey (the v2 form)
+ for unique identification by UDDIv2 clients. The uddiBindingKey
+ (36-char) will also be the LDAP naming attribute for the
+
+
+
+Bergeson, et al. Informational [Page 21]
+
+RFC 4403 LDAP Schema for UDDIv3 February 2006
+
+
+ uddiBindingTemplate entry. The uddiBindingTemplate entry MAY also
+ include the uddiv3BindingKey, the explicit v3 form key, which can be
+ 255 characters long.
+
+ ( 1.3.6.1.1.10.4.33 NAME 'uddiv3BindingKey'
+ DESC 'UDDIv3 BindingTemplate unique identifier'
+ EQUALITY caseIgnoreMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ SINGLE-VALUE
+ )
+
+4.34. uddiv3TModelKey
+
+ This is the unique UDDIv3 identifier for a given instance of a
+ uddiTModel.
+
+ A uddiTModel will include the uddiTModelKey (the v2 form) for unique
+ identification by UDDIv2 clients. The uddiTModelKey (41-char) will
+ also be the LDAP naming attribute for the uddiTModel entry. The
+ uddiTModel entry MAY also include the uddiv3TModelKey, the explicit
+ v3 form key, which can be 255 characters long.
+
+ ( 1.3.6.1.1.10.4.34 NAME 'uddiv3TModelKey'
+ DESC 'UDDIv3 TModel unique identifier'
+ EQUALITY caseIgnoreMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ SINGLE-VALUE
+ )
+
+ The tModelKey is also used in a KeyedReference and in Address
+ structures. In all instances where a tModelKey is used as a
+ reference to tModel, the v3 form of the tModel key (viz.
+ uddiv3TModelKey) will be the form used, since using the v2 form key
+ will require translating it to the v3 key by the UDDI Server, which
+ may invalidate the digital signature of the entity.
+
+4.35. uddiv3DigitalSignature
+
+ The UDDIv3 v3 schema supports the signing of the following UDDI
+ elements using "XML-Signature Syntax and Processing" (see
+ http://www.w3.org/TR/xmldsig-core/).
+
+ ..businessEntity
+ ..businessService
+ ..bindingTemplate
+ ..tModel
+ ..publisherAssertion
+
+
+
+
+Bergeson, et al. Informational [Page 22]
+
+RFC 4403 LDAP Schema for UDDIv3 February 2006
+
+
+ This uddiv3DigitalSignature attribute holds the digital signature for
+ the corresponding UDDI entity.
+
+ ( 1.3.6.1.1.10.4.35 NAME 'uddiv3DigitalSignature'
+ DESC 'UDDIv3 entity digital signature'
+ EQUALITY caseExactMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ )
+
+ A Signature element SHOULD be generated according to the required
+ steps of "Core Generation" in XML-Signature Syntax and Processing.
+ The signature should be calculated on the top-level element that will
+ be stored by the registry as a result of the Publication API call.
+ This element, referred to as the data object in the XML-Signature and
+ Syntax specification, is the businessEntity element for save_business
+ API calls, the businessService element for save_service API calls,
+ the bindingTemplate for save_binding API calls, the tModel for
+ save_tModel API calls, and the publisherAssertion for
+ set_publisherAssertions and add_publisherAssertion API calls.
+
+ The signature should be generated on the elements before they are
+ added to the body of an API call. Also, according to the signature
+ generation, all children of the element being signed are included in
+ the generation of the signature unless first excluded by application
+ of a transform. Due to the containment of service projections as
+ businessService elements within a businessEntity element, this also
+ means that changes to the projected service will render a signature
+ of the businessEntity containing the projection invalid, unless a
+ businessService element representing a service projection is excluded
+ using a transform.
+
+ Due to the location of the sequence of Signature elements within an
+ element that is to be signed, the signature is "enveloped". As a
+ result of the enveloping of the signature, it is necessary to apply
+ at least one transformation on the signed entity to exclude the
+ signature or signature(s). The transformation selected by a
+ publisher or the XML-Signature tool is specified in a Transform
+ element inside the Signature element.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bergeson, et al. Informational [Page 23]
+
+RFC 4403 LDAP Schema for UDDIv3 February 2006
+
+
+4.36. uddiv3NodeId
+
+ This attribute contains the Node Identity for a UDDIv3 node.
+
+ ( 1.3.6.1.1.10.4.36 NAME 'uddiv3NodeId'
+ DESC 'UDDIv3 Node Identifier'
+ EQUALITY caseIgnoreMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ SINGLE-VALUE
+ )
+
+4.37. uddiv3EntityModificationTime
+
+ This attribute is used to maintain the last modification time for a
+ UDDI entity. It is needed in the context of maintaining the
+ modifiedIncludingChildren element. When a child entity (e.g.,
+ uddiBindingTemplate) is updated, the parent entity (e.g.,
+ uddiBusinessService) LDAP timestamp also gets updated. The
+ uddiv3EntityModificationTime attribute saves the last modification
+ time of the parent entity (uddiBusinessService in this case).
+
+ ( 1.3.6.1.1.10.4.37 NAME 'uddiv3EntityModificationTime'
+ DESC 'UDDIv3 Last Modified Time for Entity'
+ EQUALITY generalizedTimeMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
+ SINGLE-VALUE
+ )
+
+ The following attribute definitions define attributes related to the
+ modeling of UDDIv3 subscription-related entities in the LDAP
+ directory.
+
+ Subscription provides clients, known as subscribers, with the ability
+ to register their interest in receiving information concerning
+ changes made in a UDDI registry. These changes can be scoped based
+ on preferences provided with the request. The uddiv3Subscription
+ object class is used to model registered UDDIv3 subscriptions.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bergeson, et al. Informational [Page 24]
+
+RFC 4403 LDAP Schema for UDDIv3 February 2006
+
+
+4.38. uddiv3SubscriptionKey
+
+ This is the unique UDDIv3 identifier for a given instance of a
+ uddiv3Subscription entity.
+
+ ( 1.3.6.1.1.10.4.38 NAME 'uddiv3SubscriptionKey'
+ DESC 'UDDIv3 Subscription unique identifier'
+ EQUALITY caseIgnoreMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ SINGLE-VALUE
+ )
+
+4.39. uddiv3SubscriptionFilter
+
+ This attribute contains the UDDIv3 Subscription Filter, specified as
+ part of the save_subscription API, i.e., the Inquiry API specified as
+ filtering criteria with a registered subscription. The filtering
+ criteria limits the scope of a subscription to a subset of registry
+ records. The get_xx and find_xx APIs are all valid choices for use
+ as a subscriptionFilter. Only one of these can be chosen for each
+ subscription.
+
+ ( 1.3.6.1.1.10.4.39 NAME 'uddiv3SubscriptionFilter'
+ DESC 'UDDIv3 Subscription Filter'
+ EQUALITY caseIgnoreMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ SINGLE-VALUE
+ )
+
+4.40. uddiv3NotificationInterval
+
+ This attribute contains the Notification Interval string. It is of
+ the type xsd:duration and specifies how often Asynchronous change
+ notifications are to be provided to a subscriber.
+
+ ( 1.3.6.1.1.10.4.40 NAME 'uddiv3NotificationInterval'
+ DESC 'UDDIv3 Notification Interval'
+ EQUALITY caseIgnoreMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ SINGLE-VALUE
+ )
+
+
+
+
+
+
+
+
+
+
+Bergeson, et al. Informational [Page 25]
+
+RFC 4403 LDAP Schema for UDDIv3 February 2006
+
+
+4.41. uddiv3MaxEntities
+
+ This attribute contains the maximum number of entities to be returned
+ as part of a subscription notification. It is an integer and
+ specifies the maximum number of entities in a notification returned
+ to a subscription listener.
+
+ ( 1.3.6.1.1.10.4.41 NAME 'uddiv3MaxEntities'
+ DESC 'UDDIv3 Subscription maxEntities field'
+ EQUALITY integerMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
+ SINGLE-VALUE
+ )
+
+4.42. uddiv3ExpiresAfter
+
+ This attribute specifies the Expiry Time associated with a
+ subscription. It is of the XML Schema type xsd:dateTime.
+
+ ( 1.3.6.1.1.10.4.42 NAME 'uddiv3ExpiresAfter'
+ DESC 'UDDIv3 Subscription ExpiresAfter field'
+ EQUALITY generalizedTimeMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
+ SINGLE-VALUE
+ )
+
+4.43. uddiv3BriefResponse
+
+ This attribute is a Boolean flag for Brief Response associated with a
+ subscription entity. It controls the level of detail returned to a
+ subscription listener. The default is "false" when omitted. When
+ set to "true", it indicates that the subscription results are to be
+ returned to the subscriber in the form of a keyBag, listing all of
+ the entities that matched the subscriptionFilter.
+
+ ( 1.3.6.1.1.10.4.43 NAME 'uddiv3BriefResponse'
+ DESC 'UDDIv3 Subscription ExpiresAfter field'
+ EQUALITY booleanMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
+ SINGLE-VALUE
+ )
+
+
+
+
+
+
+
+
+
+
+Bergeson, et al. Informational [Page 26]
+
+RFC 4403 LDAP Schema for UDDIv3 February 2006
+
+
+4.44. uddiv3EntityKey
+
+ This is the unique UDDIv3 identifier for a given instance of a core
+ UDDI data structure that is to be logged as an Obituary entry
+ uddiv3EntityObituary. When a core UDDIv3 Entity is deleted and there
+ is an active subscription registered against this UDDI Entity, an
+ Obituary entry is created, in which the v3 key of the deleted entry
+ is logged as part of the uddiv3EntityKey attribute.
+
+ ( 1.3.6.1.1.10.4.44 NAME 'uddiv3EntityKey'
+ DESC 'UDDIv3 Entity unique identifier'
+ EQUALITY caseIgnoreMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ SINGLE-VALUE
+ )
+
+4.45. uddiv3EntityCreationTime
+
+ This attribute is used to log the original Creation Time for a UDDI
+ Entity that is deleted in the uddiv3EntityObituary entry.
+
+ It is also used in uddiBusinessService and uddiBindingTemplate. A
+ Move BS operation needs to delete and recreate BT sub-tree due to
+ lack of support for moving a sub-tree in many LDAPv3 servers. This
+ attribute is used to save the original creation time of the BT during
+ a Move BS.
+
+ ( 1.3.6.1.1.10.4.45 NAME 'uddiv3EntityCreationTime'
+ DESC 'UDDIv3 Entity Creation Time'
+ EQUALITY generalizedTimeMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
+ SINGLE-VALUE
+ )
+
+4.46. uddiv3EntityDeletionTime
+
+ This attribute is used to log the entity deletion time for a UDDI
+ Entity that is deleted in the uddiv3EntityObituary entry.
+
+ ( 1.3.6.1.1.10.4.46 NAME 'uddiv3EntityDeletionTime'
+ DESC 'UDDIv3 Entity Deletion Time'
+ EQUALITY generalizedTimeMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
+ SINGLE-VALUE
+ )
+
+
+
+
+
+
+Bergeson, et al. Informational [Page 27]
+
+RFC 4403 LDAP Schema for UDDIv3 February 2006
+
+
+5. Object Class Definitions
+
+ The OIDs for the object classes in this document have been registered
+ by the IANA.
+
+5.1. uddiBusinessEntity
+
+ This structural object class represents a businessEntity.
+
+ ( 1.3.6.1.1.10.6.1 NAME 'uddiBusinessEntity'
+ SUP top
+ STRUCTURAL
+ MUST ( uddiBusinessKey $
+ uddiName)
+ MAY ( uddiAuthorizedName $
+ uddiOperator $
+ uddiDiscoveryURLs $
+ uddiDescription $
+ uddiIdentifierBag $
+ uddiCategoryBag $
+ uddiv3BusinessKey $
+ uddiv3DigitalSignature $
+ uddiv3EntityModificationTime $
+ uddiv3NodeId)
+ )
+
+5.2. uddiContact
+
+ This structural object class represents a contact. It is contained
+ by a uddiBusinessEntity.
+
+ ( 1.3.6.1.1.10.6.2 NAME 'uddiContact'
+ SUP top
+ STRUCTURAL
+ MUST ( uddiPersonName $
+ uddiUUID )
+ MAY ( uddiUseType $
+ uddiDescription $
+ uddiPhone $
+ uddiEMail )
+ )
+
+
+
+
+
+
+
+
+
+
+Bergeson, et al. Informational [Page 28]
+
+RFC 4403 LDAP Schema for UDDIv3 February 2006
+
+
+5.3. uddiAddress
+
+ This structural object class represents an address. It is contained
+ by a uddiContact.
+
+ ( 1.3.6.1.1.10.6.3 NAME 'uddiAddress'
+ SUP top
+ STRUCTURAL
+ MUST ( uddiUUID )
+ MAY ( uddiUseType $
+ uddiSortCode $
+ uddiTModelKey $
+ uddiv3TmodelKey $
+ uddiAddressLine $
+ uddiLang)
+ )
+
+5.4. uddiBusinessService
+
+ This structural object class represents a businessService.
+
+ ( 1.3.6.1.1.10.6.4 NAME 'uddiBusinessService'
+ SUP top
+ STRUCTURAL
+ MUST ( uddiServiceKey )
+ MAY ( uddiName $
+ uddiBusinessKey $
+ uddiDescription $
+ uddiCategoryBag $
+ uddiIsProjection $
+ uddiv3ServiceKey $
+ uddiv3BusinessKey $
+ uddiv3DigitalSignature $
+ uddiv3EntityCreationTime $
+ uddiv3EntityModificationTime $
+ uddiv3NodeId)
+ )
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bergeson, et al. Informational [Page 29]
+
+RFC 4403 LDAP Schema for UDDIv3 February 2006
+
+
+5.5. uddiBindingTemplate
+
+ This structural object class represents a bindingTemplate.
+
+ ( 1.3.6.1.1.10.6.5 NAME 'uddiBindingTemplate'
+ SUP top
+ STRUCTURAL
+ MUST ( uddiBindingKey )
+ MAY ( uddiServiceKey $
+ uddiDescription $
+ uddiAccessPoint $
+ uddiHostingRedirector
+ uddiCategoryBag $
+ uddiv3BindingKey $
+ uddiv3ServiceKey $
+ uddiv3DigitalSignature $
+ uddiv3EntityCreationTime $
+ uddiv3NodeId)
+ )
+
+5.6. uddiTModelInstanceInfo
+
+ This structural object class represents a tModelInstanceInfo. It is
+ contained by a uddiBindingTemplate.
+
+ ( 1.3.6.1.1.10.6.6 NAME 'uddiTModelInstanceInfo'
+ SUP top
+ STRUCTURAL
+ MUST ( uddiTModelKey )
+ MAY ( uddiDescription $
+ uddiInstanceDescription $
+ uddiInstanceParms $
+ uddiOverviewDescription $
+ uddiOverviewURL $
+ uddiv3TmodelKey)
+ )
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bergeson, et al. Informational [Page 30]
+
+RFC 4403 LDAP Schema for UDDIv3 February 2006
+
+
+5.7. uddiTModel
+
+ This structural object class represents a tModel.
+
+ ( 1.3.6.1.1.10.6.7 NAME 'uddiTModel'
+ SUP top
+ STRUCTURAL
+ MUST ( uddiTModelKey $
+ uddiName )
+ MAY ( uddiAuthorizedName $
+ uddiOperator $
+ uddiDescription $
+ uddiOverviewDescription $
+ uddiOverviewURL $
+ uddiIdentifierBag $
+ uddiCategoryBag $
+ uddiIsHidden
+ uddiv3TModelKey $
+ uddiv3DigitalSignature $
+ uddiv3NodeId)
+ )
+
+5.8. uddiPublisherAssertion
+
+ This structural object class represents a publisherAssertion.
+
+ ( 1.3.6.1.1.10.6.8 NAME 'uddiPublisherAssertion'
+ SUP top
+ STRUCTURAL
+ MUST ( uddiFromKey $
+ uddiToKey $
+ uddiKeyedReference $
+ uddiUUID )
+ MAY ( uddiv3DigitalSignature $
+ uddiv3NodeId)
+ )
+
+ The following are object class definitions to model new data
+ structures needed to implement the UDDIv3 information model. These
+ object class definitions have the "uddiv3" prefix to indicate that
+ these attributes represent UDDI information model elements unique to
+ UDDIv3.
+
+
+
+
+
+
+
+
+
+Bergeson, et al. Informational [Page 31]
+
+RFC 4403 LDAP Schema for UDDIv3 February 2006
+
+
+5.9. uddiv3Subscription
+
+ This structural object class represents a Subscription entity.
+
+ ( 1.3.6.1.1.10.6.9 NAME 'uddiv3Subscription'
+ SUP top
+ STRUCTURAL
+ MUST ( uddiv3SubscriptionFilter $
+ uddiUUID)
+ MAY ( uddiAuthorizedName $
+ uddiv3SubscriptionKey $
+ uddiv3BindingKey $
+ uddiv3NotificationInterval $
+ uddiv3MaxEntities $
+ uddiv3ExpiresAfter $
+ uddiv3BriefResponse $
+ uddiv3NodeId)
+ )
+
+5.10. uddiv3EntityObituary
+
+ This structural object class represents an Obituary entry for and
+ stores obituary information for deleted UDDIv3 entities needed for
+ handling subscriptions.
+
+ ( 1.3.6.1.1.10.6.10 NAME 'uddiv3EntityObituary'
+ SUP top
+ STRUCTURAL
+ MUST ( uddiv3EntityKey $
+ uddiUUID)
+ MAY ( uddiAuthorizedName $
+ uddiv3EntityCreationTime $
+ uddiv3EntityDeletionTime $
+ uddiv3NodeId)
+ )
+
+6. Name Forms
+
+ This section defines the required hierarchical structure rules and
+ naming attributes for the object classes defined in Section 6.
+
+ The OIDs for the structure rules in this document have been
+ registered by the IANA.
+
+
+
+
+
+
+
+
+Bergeson, et al. Informational [Page 32]
+
+RFC 4403 LDAP Schema for UDDIv3 February 2006
+
+
+6.1. uddiBusinessEntityNameForm
+
+ This name form defines the naming attribute for a businessEntity.
+
+ ( 1.3.6.1.1.10.15.1 NAME 'uddiBusinessEntityNameForm'
+ OC uddiBusinessEntity
+ MUST ( uddiBusinessKey )
+ )
+
+6.2. uddiContactNameForm
+
+ This name form defines the naming attribute for a contact.
+
+ ( 1.3.6.1.1.10.15.2 NAME 'uddiContactNameForm'
+ OC uddiContact
+ MUST ( uddiUUID )
+ )
+
+6.3. uddiAddressNameForm
+
+ This name form defines the naming attribute for an address.
+
+ ( 1.3.6.1.1.10.15.3 NAME 'uddiAddressNameForm'
+ OC uddiAddress
+ MUST ( uddiUUID )
+ )
+
+6.4. uddiBusinessServiceNameForm
+
+ This name form defines the naming attribute for a businessService.
+
+ ( 1.3.6.1.1.10.15.4 NAME 'uddiBusinessServiceNameForm'
+ OC uddiBusinessService
+ MUST ( uddiServiceKey )
+ )
+
+6.5. uddiBindingTemplateNameForm
+
+ This name form defines the naming attribute for a bindingTemplate.
+
+ ( 1.3.6.1.1.10.15.5 NAME 'uddiBindingTemplateNameForm'
+ OC uddiBindingTemplate
+ MUST ( uddiBindingKey )
+ )
+
+
+
+
+
+
+
+Bergeson, et al. Informational [Page 33]
+
+RFC 4403 LDAP Schema for UDDIv3 February 2006
+
+
+6.6. uddiTModelInstanceInfoNameForm
+
+ This name form defines the naming attribute for a tModelInstanceInfo.
+
+ ( 1.3.6.1.1.10.15.6 NAME 'uddiTModelInstanceInfoNameForm'
+ OC uddiTModelInstanceInfo
+ MUST ( uddiTModelKey )
+ )
+
+6.7. uddiTModelNameForm
+
+ This name form defines the naming attribute for a tModel.
+
+ ( 1.3.6.1.1.10.15.7 NAME 'uddiTModelNameForm'
+ OC uddiTModel
+ MUST ( uddiTModelKey )
+ )
+
+6.8. uddiPublisherAssertionNameForm
+
+ This name form defines the naming attribute for a publisherAssertion.
+
+ ( 1.3.6.1.1.10.15.8 NAME 'uddiPublisherAssertionNameForm'
+ OC uddiPublisherAssertion
+ MUST ( uddiUUID )
+ )
+
+6.9. uddiv3SubscriptionNameForm
+
+ This name form defines the naming attribute for a Subscription.
+
+ ( 1.3.6.1.1.10.15.9 NAME 'uddiv3SubscriptionNameForm'
+ OC uddiv3Subscription
+ MUST ( uddiUUID )
+ )
+
+6.10. uddiv3EntityObituaryNameForm
+
+ This name form defines the naming attribute for an Entity Obituary.
+
+ ( 1.3.6.1.1.10.15.10 NAME 'uddiv3EntityObituaryNameForm'
+ OC uddiv3EntityObituary
+ MUST ( uddiUUID )
+ )
+
+
+
+
+
+
+
+Bergeson, et al. Informational [Page 34]
+
+RFC 4403 LDAP Schema for UDDIv3 February 2006
+
+
+7. DIT Structure Rules
+
+ This section defines the required hierarchical structure rules for
+ the object classes defined in Section 6.
+
+ Note that rule identifiers defined here show the relationship between
+ structure rules. Implementations may use different identifiers but
+ must follow the same hierarchical model.
+
+7.1. uddiBusinessEntityStructureRule
+
+ ( 1
+ NAME 'uddiBusinessEntityStructureRule'
+ FORM uddiBusinessEntityNameForm
+ )
+
+7.2. uddiContactStructureRule
+
+ This structure rule defines the object class containment for a
+ contact.
+
+ ( 2
+ NAME 'uddiContactStructureRule'
+ FORM uddiContactNameForm
+ SUP ( 1 )
+ )
+
+7.3. uddiAddressStructureRule
+
+ This structure rule defines the object class containment for an
+ address.
+
+ ( 3
+ NAME 'uddiAddressStructureRule'
+ FORM uddiAddressNameForm
+ SUP ( 2 )
+ )
+
+7.4. uddiBusinessServiceStructureRule
+
+ This structure rule defines the object class containment for a
+ businessService.
+
+ ( 4
+ NAME 'uddiBusinessServiceStructureRule'
+ FORM uddiBusinessServiceNameForm
+ SUP ( 1 )
+ )
+
+
+
+Bergeson, et al. Informational [Page 35]
+
+RFC 4403 LDAP Schema for UDDIv3 February 2006
+
+
+
+7.5. uddiBindingTemplateStructureRule
+
+ This structure rule defines the object class containment for a
+ bindingTemplate.
+
+ ( 5
+ NAME 'uddiBindingTemplateStructureRule'
+ FORM uddiBindingTemplateNameForm
+ SUP ( 4 )
+ )
+
+7.6. uddiTModelInstanceInfoStructureRule
+
+ This structure rule defines the object class containment for a
+ tModelInstanceInfo.
+
+ ( 6
+ NAME 'uddiTModelInstanceInfoStructureRule'
+ FORM uddiTModelInstanceInfoNameForm
+ SUP ( 5 )
+ )
+
+7.7. uddiTModelStructureRule
+
+ ( 7
+ NAME 'uddiTModelStructureRule'
+ FORM uddiTModelNameForm
+ )
+
+7.8. uddiPublisherAssertion
+
+ ( 8
+ NAME 'uddiPublisherAssertionStructureRule'
+ FORM uddiPublisherAssertionNameForm
+ )
+
+7.9. uddiv3SubscriptionStructureRule
+
+ ( 9
+ NAME 'uddiv3SubscriptionStructureRule'
+ FORM uddiv3SubscriptionNameForm
+ )
+
+
+
+
+
+
+
+
+Bergeson, et al. Informational [Page 36]
+
+RFC 4403 LDAP Schema for UDDIv3 February 2006
+
+
+7.10. uddiv3EntityObituaryStructureRule
+
+ ( 10
+ NAME 'uddiv3EntityObituaryStructureRule'
+ FORM uddiv3EntityObituaryNameForm
+ )
+
+8. Security Considerations
+
+ Storing UDDI data into the directory enables the data to be examined
+ and used outside the environment in which it was originally created.
+ The directory entry containing the UDDI data could be read and
+ modified within the constraints imposed by the access control
+ mechanisms of the directory. With UDDIv3 [UDDIv3], publishers can
+ digitally sign UDDI Entities enabling registry clients to validate
+ the integrity of entries read from the UDDIv3 registry by verifying
+ the digital signature.
+
+ Each UDDI Entity has a uddiAuthorizedName attribute that contains an
+ LDAP DN identifying the publisher/owner. The referenced LDAP object
+ can provide the public key of the signer to a registry client for
+ integrity validation of the UDDI Entity.
+
+ Other general LDAP [LDAPv3] security considerations apply. Some of
+ the UDDI attributes such as AccessPoints for services may contain
+ sensitive information. Use of strong authentication mechanisms and
+ data integrity/confidentiality services [RFC2829][RFC2830] is
+ advised.
+
+9. IANA Considerations
+
+ Refer to RFC 3383, "Internet Assigned Numbers Authority (IANA)
+ Considerations for the Lightweight Directory Access Protocol (LDAP)"
+ [RFC3383].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bergeson, et al. Informational [Page 37]
+
+RFC 4403 LDAP Schema for UDDIv3 February 2006
+
+
+9.1. Object Identifier Registration
+
+ The IANA has registered an LDAP Object Identifier for use in this
+ technical specification, according to the following template:
+
+ Subject: Request for LDAP OID Registration
+ Person & email address to contact for further information:
+ Bruce Bergeson (bruce.bergeson at novell.com)
+ Specification: RFC 4403
+ Author/Change Controller: IESG
+ Comments:
+ The assigned OID (10) will be used as a base for identifying
+ a number of UDDI schema elements defined in this document.
+
+9.2. Object Identifier Descriptors
+
+ The IANA has registered the LDAP Descriptors used in this technical
+ specification as detailed in the following template:
+
+ Subject: Request for LDAP Descriptor Registration Update
+ Descriptor (short name): see table
+ Object Identifier: see table
+ Person & email address to contact for further information:
+ Bruce Bergeson (bruce.bergeson at novell.com)
+ Usage: see table
+ Specification: RFC 4403
+ Author/Change Controller: IESG
+ Table:
+
+ The following descriptors have been added:
+
+ NAME Type OID
+ -------------- ---- ------------
+ uddiBusinessKey A 1.3.6.1.1.10.4.1
+ uddiAuthorizedName A 1.3.6.1.1.10.4.2
+ uddiOperator A 1.3.6.1.1.10.4.3
+ uddiName A 1.3.6.1.1.10.4.4
+ uddiDescription A 1.3.6.1.1.10.4.5
+ uddiDiscoveryURLs A 1.3.6.1.1.10.4.6
+ uddiUseType A 1.3.6.1.1.10.4.7
+ uddiPersonName A 1.3.6.1.1.10.4.8
+ uddiPhone A 1.3.6.1.1.10.4.9
+ uddiEMail A 1.3.6.1.1.10.4.10
+ uddiSortCode A 1.3.6.1.1.10.4.11
+ uddiTModelKey A 1.3.6.1.1.10.4.12
+ uddiAddressLine A 1.3.6.1.1.10.4.13
+
+
+
+
+
+Bergeson, et al. Informational [Page 38]
+
+RFC 4403 LDAP Schema for UDDIv3 February 2006
+
+
+ NAME Type OID
+ -------------- ---- ------------
+ uddiIdentifierBag A 1.3.6.1.1.10.4.14
+ uddiCategoryBag A 1.3.6.1.1.10.4.15
+ uddiKeyedReference A 1.3.6.1.1.10.4.16
+ uddiServiceKey A 1.3.6.1.1.10.4.17
+ uddiBindingKey A 1.3.6.1.1.10.4.18
+ uddiAccessPoint A 1.3.6.1.1.10.4.19
+ uddiHostingRedirector A 1.3.6.1.1.10.4.20
+ uddiInstanceDescription A 1.3.6.1.1.10.4.21
+ uddiInstanceParms A 1.3.6.1.1.10.4.22
+ uddiOverviewDescription A 1.3.6.1.1.10.4.23
+ uddiOverviewURL A 1.3.6.1.1.10.4.24
+ uddiFromKey A 1.3.6.1.1.10.4.25
+ uddiToKey A 1.3.6.1.1.10.4.26
+ uddiUUID A 1.3.6.1.1.10.4.27
+ uddiIsHidden A 1.3.6.1.1.10.4.28
+ uddiIsProjection A 1.3.6.1.1.10.4.29
+ uddiLang A 1.3.6.1.1.10.4.30
+ uddiv3BusinessKey A 1.3.6.1.1.10.4.31
+ uddiv3ServiceKey A 1.3.6.1.1.10.4.32
+ uddiv3BindingKey A 1.3.6.1.1.10.4.33
+ uddiv3TmodelKey A 1.3.6.1.1.10.4.34
+ uddiv3DigitalSignature A 1.3.6.1.1.10.4.35
+ uddiv3NodeId A 1.3.6.1.1.10.4.36
+ uddiv3EntityModificationTime A 1.3.6.1.1.10.4.37
+ uddiv3SubscriptionKey A 1.3.6.1.1.10.4.38
+ uddiv3SubscriptionFilter A 1.3.6.1.1.10.4.39
+ uddiv3NotificationInterval A 1.3.6.1.1.10.4.40
+ uddiv3MaxEntities A 1.3.6.1.1.10.4.41
+ uddiv3ExpiresAfter A 1.3.6.1.1.10.4.42
+ uddiv3BriefResponse A 1.3.6.1.1.10.4.43
+ uddiv3EntityKey A 1.3.6.1.1.10.4.44
+ uddiv3EntityCreationTime A 1.3.6.1.1.10.4.45
+ uddiv3EntityDeletionTime A 1.3.6.1.1.10.4.46
+ uddiBusinessEntity O 1.3.6.1.1.10.6.1
+ uddiContact O 1.3.6.1.1.10.6.2
+ uddiAddress O 1.3.6.1.1.10.6.3
+ uddiBusinessService O 1.3.6.1.1.10.6.4
+ uddiBindingTemplate O 1.3.6.1.1.10.6.5
+ uddiTModelInstanceInfo O 1.3.6.1.1.10.6.6
+ uddiTModel O 1.3.6.1.1.10.6.7
+ uddiPublisherAssertion O 1.3.6.1.1.10.6.8
+ uddiv3Subscription O 1.3.6.1.1.10.6.9
+ uddiv3EntityObituary O 1.3.6.1.1.10.6.10
+ uddiBusinessEntityNameForm N 1.3.6.1.1.10.15.1
+ uddiContactNameForm N 1.3.6.1.1.10.15.2
+ uddiAddressNameForm N 1.3.6.1.1.10.15.3
+
+
+
+Bergeson, et al. Informational [Page 39]
+
+RFC 4403 LDAP Schema for UDDIv3 February 2006
+
+
+ NAME Type OID
+ -------------- ---- ------------
+ uddiBusinessServiceNameForm N 1.3.6.1.1.10.15.4
+ uddiBindingTemplateNameForm N 1.3.6.1.1.10.15.5
+ uddiTModelInstanceInfoNameForm N 1.3.6.1.1.10.15.6
+ uddiTModelNameForm N 1.3.6.1.1.10.15.7
+ uddiPublisherAssertionNameForm N 1.3.6.1.1.10.15.8
+ uddiv3SubscriptionNameForm N 1.3.6.1.1.10.15.9
+ uddiv3EntityObituaryNameForm N 1.3.6.1.1.10.15.10
+
+ where Type A is Attribute, Type O is ObjectClass, Type N is NameForm
+
+ These assignments have been recorded in the following registry:
+
+ http://www.iana.org/assignments/ldap-parameters
+
+10. Normative References
+
+ [LDAPv3] Hodges, J. and R. Morgan, "Lightweight Directory Access
+ Protocol (v3): Technical Specification", RFC 3377,
+ September 2002.
+
+ [RFC2252] Wahl, M., Coulbeck, A., Howes, T., and S. Kille,
+ "Lightweight Directory Access Protocol (v3): Attribute
+ Syntax Definitions", RFC 2252, December 1997.
+
+ [UDDIdsr] UDDI.ORG, "UDDI version 2.03 Data Structure Reference,"
+ http://uddi.org/pubs/DataStructure-V2.03-Published-
+ 20020719.htm
+
+ [UDDIapi] "UDDI Version 2.04 API Specification",
+ http://uddi.org/pubs/ProgrammersAPI-V2.04-Published-
+ 20020719.htm
+
+ [UDDIv3] UDDI Version 3.0, Published Specification, 19 July 2002
+ http://uddi.org/pubs/uddi-v3.00-published-20020719.htm
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2829] Wahl, M., Alvestrand, H., Hodges, J., and R. Morgan,
+ "Authentication Methods for LDAP", RFC 2829, May 2000.
+
+ [RFC2830] Hodges, J., Morgan, R., and M. Wahl, "Lightweight Directory
+ Access Protocol (v3): Extension for Transport Layer
+ Security", RFC 2830, May 2000.
+
+
+
+
+
+Bergeson, et al. Informational [Page 40]
+
+RFC 4403 LDAP Schema for UDDIv3 February 2006
+
+
+ [RFC3383] Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
+ Considerations for the Lightweight Directory Access
+ Protocol (LDAP)", BCP 64, RFC 3383, September 2002.
+
+ [XML] Extensible Markup Language (XML) 1.0 (Second Edition) W3C
+ Recommendation 6 October 2000 http://www.w3.org/TR/REC-xml
+
+ [URL] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
+ Resource Identifier (URI): Generic Syntax", STD 66, RFC
+ 3986, January 2005.
+
+ [HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
+ Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
+ Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
+
+Authors' Addresses
+
+ Bruce Bergeson
+ Novell, Inc.
+ 1800 S Novell Place
+ Provo, UT 84606
+
+ Phone: +1 801 861 3854
+ EMail: bruce.bergeson at novell.com
+
+
+ Kent Boogert
+ Novell, Inc.
+ 1800 S Novell Place
+ Provo, UT 84606
+
+ Phone: +1 801 861 3212
+ EMail: kent.boogert at novell.com
+
+
+ Vijay Nanjundaswamy
+ Oracle India Pvt. Ltd.
+ Lexington Towers, Prestige St. John's Woods
+ #18, 2nd Cross Road,
+ Chikka Audugodi,
+ Bangalore 560029
+ India
+
+ Phone: +11 9180 4108 5000
+ EMail: vijay.nanjundaswamy at oracle.com
+
+
+
+
+
+
+Bergeson, et al. Informational [Page 41]
+
+RFC 4403 LDAP Schema for UDDIv3 February 2006
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2006).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr at ietf.org.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is provided by the IETF
+ Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Bergeson, et al. Informational [Page 42]
+
Modified: openldap/vendor/openldap-release/include/portable.hin
===================================================================
--- openldap/vendor/openldap-release/include/portable.hin 2007-09-15 10:30:38 UTC (rev 843)
+++ openldap/vendor/openldap-release/include/portable.hin 2007-09-15 10:38:52 UTC (rev 844)
@@ -1063,6 +1063,9 @@
first (like Motorola and SPARC, unlike Intel and VAX). */
#undef WORDS_BIGENDIAN
+/* Define to the type of arg 3 for `accept'. */
+#undef ber_socklen_t
+
/* Define to `char *' if <sys/types.h> does not define. */
#undef caddr_t
@@ -1090,7 +1093,7 @@
/* define to snprintf routine */
#undef snprintf
-/* Define to `int' if <sys/socket.h> does not define. */
+/* Define like ber_socklen_t if <sys/socket.h> does not define. */
#undef socklen_t
/* Define to `signed int' if <sys/types.h> does not define. */
Modified: openldap/vendor/openldap-release/libraries/liblber/sockbuf.c
===================================================================
--- openldap/vendor/openldap-release/libraries/liblber/sockbuf.c 2007-09-15 10:30:38 UTC (rev 843)
+++ openldap/vendor/openldap-release/libraries/liblber/sockbuf.c 2007-09-15 10:38:52 UTC (rev 844)
@@ -1,5 +1,5 @@
/* sockbuf.c - i/o routines with support for adding i/o layers. */
-/* $OpenLDAP: pkg/ldap/libraries/liblber/sockbuf.c,v 1.60.2.7 2007/01/02 21:43:48 kurt Exp $ */
+/* $OpenLDAP: pkg/ldap/libraries/liblber/sockbuf.c,v 1.60.2.8 2007/06/10 18:43:56 hallvard Exp $ */
/* This work is part of OpenLDAP Software <http://www.openldap.org/>.
*
* Copyright 1998-2007 The OpenLDAP Foundation.
@@ -873,7 +873,7 @@
sb_dgram_read( Sockbuf_IO_Desc *sbiod, void *buf, ber_len_t len )
{
ber_slen_t rc;
- socklen_t addrlen;
+ ber_socklen_t addrlen;
struct sockaddr *src;
assert( sbiod != NULL );
@@ -882,7 +882,7 @@
addrlen = sizeof( struct sockaddr );
src = buf;
- buf += addrlen;
+ buf = (char *) buf + addrlen;
len -= addrlen;
rc = recvfrom( sbiod->sbiod_sb->sb_fd, buf, len, 0, src, &addrlen );
@@ -900,7 +900,7 @@
assert( buf != NULL );
dst = buf;
- buf += sizeof( struct sockaddr );
+ buf = (char *) buf + sizeof( struct sockaddr );
len -= sizeof( struct sockaddr );
rc = sendto( sbiod->sbiod_sb->sb_fd, buf, len, 0, dst,
Modified: openldap/vendor/openldap-release/libraries/libldap/abandon.c
===================================================================
--- openldap/vendor/openldap-release/libraries/libldap/abandon.c 2007-09-15 10:30:38 UTC (rev 843)
+++ openldap/vendor/openldap-release/libraries/libldap/abandon.c 2007-09-15 10:38:52 UTC (rev 844)
@@ -1,5 +1,5 @@
/* abandon.c */
-/* $OpenLDAP: pkg/ldap/libraries/libldap/abandon.c,v 1.36.2.5 2007/01/02 21:43:48 kurt Exp $ */
+/* $OpenLDAP: pkg/ldap/libraries/libldap/abandon.c,v 1.36.2.6 2007/06/08 07:43:26 hyc Exp $ */
/* This work is part of OpenLDAP Software <http://www.openldap.org/>.
*
* Copyright 1998-2007 The OpenLDAP Foundation.
@@ -191,8 +191,9 @@
i = ++(ld)->ld_msgid;
#ifdef LDAP_CONNECTIONLESS
if ( LDAP_IS_UDP(ld) ) {
- err = ber_write( ber, ld->ld_options.ldo_peer,
- sizeof(struct sockaddr), 0);
+ struct sockaddr sa = {0};
+ /* dummy, filled with ldo_peer in request.c */
+ err = ber_write( ber, &sa, sizeof( sa ), 0 );
}
if ( LDAP_IS_UDP(ld) && ld->ld_options.ldo_version ==
LDAP_VERSION2) {
Modified: openldap/vendor/openldap-release/libraries/libldap/addentry.c
===================================================================
--- openldap/vendor/openldap-release/libraries/libldap/addentry.c 2007-09-15 10:30:38 UTC (rev 843)
+++ openldap/vendor/openldap-release/libraries/libldap/addentry.c 2007-09-15 10:38:52 UTC (rev 844)
@@ -1,5 +1,5 @@
/* addentry.c */
-/* $OpenLDAP: pkg/ldap/libraries/libldap/addentry.c,v 1.14.2.3 2007/01/02 21:43:48 kurt Exp $ */
+/* $OpenLDAP: pkg/ldap/libraries/libldap/addentry.c,v 1.14.2.4 2007/07/22 15:55:36 hyc Exp $ */
/* This work is part of OpenLDAP Software <http://www.openldap.org/>.
*
* Copyright 1998-2007 The OpenLDAP Foundation.
@@ -64,6 +64,9 @@
assert( e != NULL );
e->lm_chain = *list;
- e->lm_chain_tail = (*list)->lm_chain_tail;
+ if ( *list )
+ e->lm_chain_tail = (*list)->lm_chain_tail;
+ else
+ e->lm_chain_tail = e;
*list = e;
}
Modified: openldap/vendor/openldap-release/libraries/libldap/ldap-int.h
===================================================================
--- openldap/vendor/openldap-release/libraries/libldap/ldap-int.h 2007-09-15 10:30:38 UTC (rev 843)
+++ openldap/vendor/openldap-release/libraries/libldap/ldap-int.h 2007-09-15 10:38:52 UTC (rev 844)
@@ -1,5 +1,5 @@
/* ldap-int.h - defines & prototypes internal to the LDAP library */
-/* $OpenLDAP: pkg/ldap/libraries/libldap/ldap-int.h,v 1.160.2.9 2007/01/02 21:43:49 kurt Exp $ */
+/* $OpenLDAP: pkg/ldap/libraries/libldap/ldap-int.h,v 1.160.2.10 2007/04/23 12:28:20 hyc Exp $ */
/* This work is part of OpenLDAP Software <http://www.openldap.org/>.
*
* Copyright 1998-2007 The OpenLDAP Foundation.
@@ -38,7 +38,7 @@
#include <sasl.h>
#endif
-#define SASL_MAX_BUFF_SIZE 65536
+#define SASL_MAX_BUFF_SIZE (0xffffff)
#define SASL_MIN_BUFF_SIZE 4096
#endif
Modified: openldap/vendor/openldap-release/libraries/libldap/os-ip.c
===================================================================
--- openldap/vendor/openldap-release/libraries/libldap/os-ip.c 2007-09-15 10:30:38 UTC (rev 843)
+++ openldap/vendor/openldap-release/libraries/libldap/os-ip.c 2007-09-15 10:38:52 UTC (rev 844)
@@ -1,5 +1,5 @@
/* os-ip.c -- platform-specific TCP & UDP related code */
-/* $OpenLDAP: pkg/ldap/libraries/libldap/os-ip.c,v 1.108.2.13 2007/01/02 21:43:49 kurt Exp $ */
+/* $OpenLDAP: pkg/ldap/libraries/libldap/os-ip.c,v 1.108.2.14 2007/06/10 18:39:53 hallvard Exp $ */
/* This work is part of OpenLDAP Software <http://www.openldap.org/>.
*
* Copyright 1998-2007 The OpenLDAP Foundation.
@@ -174,7 +174,7 @@
#if defined( notyet ) /* && defined( SO_ERROR ) */
{
int so_errno;
- socklen_t dummy = sizeof(so_errno);
+ ber_socklen_t dummy = sizeof(so_errno);
if ( getsockopt( s, SOL_SOCKET, SO_ERROR, &so_errno, &dummy )
== AC_SOCKET_ERROR )
{
@@ -196,7 +196,7 @@
struct sockaddr_in sin;
#endif
char ch;
- socklen_t dummy = sizeof(sin);
+ ber_socklen_t dummy = sizeof(sin);
if ( getpeername( s, (struct sockaddr *) &sin, &dummy )
== AC_SOCKET_ERROR )
{
@@ -216,7 +216,7 @@
static int
ldap_pvt_connect(LDAP *ld, ber_socket_t s,
- struct sockaddr *sin, socklen_t addrlen,
+ struct sockaddr *sin, ber_socklen_t addrlen,
int async)
{
int rc, err;
@@ -326,7 +326,7 @@
/* This means the connection failed */
if ( FD_ISSET(s, &efds) ) {
int so_errno;
- int dummy = sizeof(so_errno);
+ ber_socklen_t dummy = sizeof(so_errno);
if ( getsockopt( s, SOL_SOCKET, SO_ERROR,
(char *) &so_errno, &dummy ) == AC_SOCKET_ERROR || !so_errno )
{
@@ -574,7 +574,7 @@
char *
ldap_host_connected_to( Sockbuf *sb, const char *host )
{
- socklen_t len;
+ ber_socklen_t len;
#ifdef LDAP_PF_INET6
struct sockaddr_storage sabuf;
#else
Modified: openldap/vendor/openldap-release/libraries/libldap/os-local.c
===================================================================
--- openldap/vendor/openldap-release/libraries/libldap/os-local.c 2007-09-15 10:30:38 UTC (rev 843)
+++ openldap/vendor/openldap-release/libraries/libldap/os-local.c 2007-09-15 10:38:52 UTC (rev 844)
@@ -1,5 +1,5 @@
/* os-local.c -- platform-specific domain socket code */
-/* $OpenLDAP: pkg/ldap/libraries/libldap/os-local.c,v 1.37.2.8 2007/04/04 21:56:13 hyc Exp $ */
+/* $OpenLDAP: pkg/ldap/libraries/libldap/os-local.c,v 1.37.2.9 2007/06/10 18:39:53 hallvard Exp $ */
/* This work is part of OpenLDAP Software <http://www.openldap.org/>.
*
* Copyright 1998-2007 The OpenLDAP Foundation.
@@ -120,7 +120,7 @@
#if defined( notyet ) /* && defined( SO_ERROR ) */
{
int so_errno;
- socklen_t dummy = sizeof(so_errno);
+ ber_socklen_t dummy = sizeof(so_errno);
if ( getsockopt( s, SOL_SOCKET, SO_ERROR, &so_errno, &dummy )
== AC_SOCKET_ERROR )
{
@@ -138,7 +138,7 @@
/* error slippery */
struct sockaddr_un sa;
char ch;
- socklen_t dummy = sizeof(sa);
+ ber_socklen_t dummy = sizeof(sa);
if ( getpeername( s, (struct sockaddr *) &sa, &dummy )
== AC_SOCKET_ERROR )
{
Modified: openldap/vendor/openldap-release/libraries/libldap/request.c
===================================================================
--- openldap/vendor/openldap-release/libraries/libldap/request.c 2007-09-15 10:30:38 UTC (rev 843)
+++ openldap/vendor/openldap-release/libraries/libldap/request.c 2007-09-15 10:38:52 UTC (rev 844)
@@ -1,4 +1,4 @@
-/* $OpenLDAP: pkg/ldap/libraries/libldap/request.c,v 1.103.2.15 2007/01/02 21:43:49 kurt Exp $ */
+/* $OpenLDAP: pkg/ldap/libraries/libldap/request.c,v 1.103.2.19 2007/07/01 12:17:28 hallvard Exp $ */
/* This work is part of OpenLDAP Software <http://www.openldap.org/>.
*
* Copyright 1998-2007 The OpenLDAP Foundation.
@@ -222,6 +222,19 @@
use_connection( ld, lc );
+#ifdef LDAP_CONNECTIONLESS
+ if ( LDAP_IS_UDP( ld )) {
+ BerElement tmpber = *ber;
+ ber_rewind( &tmpber );
+ rc = ber_write( &tmpber, ld->ld_options.ldo_peer,
+ sizeof( struct sockaddr ), 0 );
+ if ( rc == -1 ) {
+ ld->ld_errno = LDAP_ENCODING_ERROR;
+ return rc;
+ }
+ }
+#endif
+
/* If we still have an incomplete write, try to finish it before
* dealing with the new request. If we don't finish here, return
* LDAP_BUSY and let the caller retry later. We only allow a single
@@ -424,7 +437,10 @@
++lc->lconn_refcnt; /* avoid premature free */
ld->ld_defconn = lc;
- Debug( LDAP_DEBUG_TRACE, "anonymous rebind via ldap_bind_s\n", 0, 0, 0);
+ Debug( LDAP_DEBUG_TRACE,
+ "anonymous rebind via ldap_sasl_bind(\"\")\n",
+ 0, 0, 0);
+
#ifdef LDAP_R_COMPILE
ldap_pvt_thread_mutex_unlock( &ld->ld_req_mutex );
ldap_pvt_thread_mutex_unlock( &ld->ld_res_mutex );
@@ -462,7 +478,13 @@
break;
default:
- assert( 0 );
+ Debug( LDAP_DEBUG_TRACE,
+ "ldap_new_connection %p: "
+ "unexpected response %d "
+ "from BIND request id=%d\n",
+ (void *)ld, ldap_msgtype( res ), msgid );
+ err = -1;
+ break;
}
}
}
@@ -916,7 +938,7 @@
if ( lp == origreq ) {
lp = lp->lr_child;
} else {
- lp = lr->lr_refnext;
+ lp = lp->lr_refnext;
}
}
if ( looped ) {
Modified: openldap/vendor/openldap-release/libraries/libldap/search.c
===================================================================
--- openldap/vendor/openldap-release/libraries/libldap/search.c 2007-09-15 10:30:38 UTC (rev 843)
+++ openldap/vendor/openldap-release/libraries/libldap/search.c 2007-09-15 10:38:52 UTC (rev 844)
@@ -1,4 +1,4 @@
-/* $OpenLDAP: pkg/ldap/libraries/libldap/search.c,v 1.64.2.8 2007/01/02 21:43:50 kurt Exp $ */
+/* $OpenLDAP: pkg/ldap/libraries/libldap/search.c,v 1.64.2.9 2007/06/08 07:43:26 hyc Exp $ */
/* This work is part of OpenLDAP Software <http://www.openldap.org/>.
*
* Copyright 1998-2007 The OpenLDAP Foundation.
@@ -259,8 +259,9 @@
LDAP_NEXT_MSGID( ld, *idp );
#ifdef LDAP_CONNECTIONLESS
if ( LDAP_IS_UDP(ld) ) {
- err = ber_write( ber, ld->ld_options.ldo_peer,
- sizeof(struct sockaddr), 0);
+ struct sockaddr sa = {0};
+ /* dummy, filled with ldo_peer in request.c */
+ err = ber_write( ber, &sa, sizeof( sa ), 0 );
}
if ( LDAP_IS_UDP(ld) && ld->ld_options.ldo_version == LDAP_VERSION2) {
char *dn = ld->ld_options.ldo_cldapdn;
Modified: openldap/vendor/openldap-release/libraries/libldap_r/thr_debug.c
===================================================================
--- openldap/vendor/openldap-release/libraries/libldap_r/thr_debug.c 2007-09-15 10:30:38 UTC (rev 843)
+++ openldap/vendor/openldap-release/libraries/libldap_r/thr_debug.c 2007-09-15 10:38:52 UTC (rev 844)
@@ -1,5 +1,5 @@
/* thr_debug.c - wrapper around the chosen thread wrapper, for debugging. */
-/* $OpenLDAP: pkg/ldap/libraries/libldap_r/thr_debug.c,v 1.1.2.4 2007/01/02 21:43:50 kurt Exp $ */
+/* $OpenLDAP: pkg/ldap/libraries/libldap_r/thr_debug.c,v 1.1.2.5 2007/05/31 21:32:43 hallvard Exp $ */
/* This work is part of OpenLDAP Software <http://www.openldap.org/>.
*
* Copyright 2005-2007 The OpenLDAP Foundation.
@@ -205,18 +205,15 @@
if( s != NULL ) {
while( *(s += strspn( s, ", \t\r\n" )) != '\0' ) {
size_t optlen = strcspn( s, ", \t\r\n" );
- const struct option_info_s *oi;
- for( oi = option_info; oi->name; oi++ ) {
- if( strncasecmp( oi->name, s, optlen ) == 0 ) {
- if( oi->name && oi->name[optlen] == '\0' ) {
- *oi->var = oi->val;
- } else {
- fprintf( stderr, "Unknown $%s option '%.*s'\n",
- "LDAP_THREAD_DEBUG", (int) optlen, s );
- }
- break;
- }
- }
+ const struct option_info_s *oi = option_info;
+ while( oi->name &&
+ (strncasecmp( oi->name, s, optlen ) || oi->name[optlen]) )
+ oi++;
+ if( oi->name )
+ *oi->var = oi->val;
+ else
+ fprintf( stderr, "Unknown $%s option '%.*s'\n",
+ "LDAP_THREAD_DEBUG", (int) optlen, s );
s += optlen;
}
}
@@ -258,7 +255,7 @@
}
static void
-exit_thread_message( const ldap_pvt_thread_t thread )
+exit_thread_message( ldap_pvt_thread_t thread )
{
if( tracethreads ) {
char buf[40];
@@ -289,11 +286,18 @@
#define INITED_VALUE 0x12345678UL
#define INITED_BYTE_VALUE 0xd5
+/* Valid programs will access uninitialized memory here if dupinit. */
static int
debug_already_initialized( const LDAP_UINTPTR_T *num )
{
- /* Valid programs will access uninitialized memory if dupinit */
- return dupinit && *num == INITED_VALUE;
+ /*
+ * 'ret' keeps the Valgrind warning "Conditional jump or move
+ * depends on uninitialised value(s)" _inside_ this function.
+ */
+ volatile int ret = 0;
+ if( dupinit && *num == INITED_VALUE )
+ ret = 1;
+ return ret;
}
static void
@@ -310,6 +314,7 @@
*dummy = INITED_BYTE_VALUE;
if( wraptype == Wrap_scramble ) {
usage->num = ~(LDAP_UINTPTR_T) dummy;
+ /* Check that ptr<->integer casts work on this host */
assert( (unsigned char *)~usage->num == dummy );
} else {
usage->ptr = dummy + wrap_offset;
@@ -407,15 +412,15 @@
}
}
-ldap_debug_thread_t *
-get_thread_info( ldap_pvt_thread_t *thread, const char *msg )
+static ldap_debug_thread_t *
+get_thread_info( ldap_pvt_thread_t thread, const char *msg )
{
unsigned int i;
ldap_debug_thread_t *t;
if( nodebug )
return NULL;
for( i = 0; i < thread_info_used; i++ ) {
- if( ldap_pvt_thread_equal( *thread, thread_info[i]->wrapped ) )
+ if( ldap_pvt_thread_equal( thread, thread_info[i]->wrapped ) )
break;
}
ERROR_IF( i == thread_info_used, msg );
@@ -432,7 +437,7 @@
thread = ldap_pvt_thread_self();
exit_thread_message( thread );
with_threads_lock({
- ldap_debug_thread_t *t = get_thread_info( &thread, msg );
+ ldap_debug_thread_t *t = get_thread_info( thread, msg );
if( t->detached )
remove_thread_info( t, msg );
});
@@ -583,7 +588,9 @@
void
ldap_pvt_thread_exit( void *retval )
{
+#if 0 /* Detached threads may exit after ldap_debug_thread_destroy(). */
ERROR_IF( !threading_enabled, "ldap_pvt_thread_exit" );
+#endif
adjust_count( Idx_unexited_thread, -1 );
exiting_thread( "ldap_pvt_thread_exit" );
ldap_int_thread_exit( retval );
@@ -601,7 +608,7 @@
thread_name( buf, sizeof(buf), thread ) );
}
with_threads_lock(
- t = get_thread_info( &thread, "ldap_pvt_thread_join" ) );
+ t = get_thread_info( thread, "ldap_pvt_thread_join" ) );
rc = ldap_int_thread_join( thread, thread_return );
if( rc ) {
ERROR( rc, "ldap_pvt_thread_join" );
@@ -921,7 +928,7 @@
{
int rc, has_pool;
ERROR_IF( !threading_enabled, "ldap_pvt_thread_pool_submit" );
- has_pool = (tpool != NULL && *tpool != NULL);
+ has_pool = (tpool && *tpool);
rc = ldap_int_thread_pool_submit( tpool, start_routine, arg );
if( has_pool )
ERROR_IF( rc, "ldap_pvt_thread_pool_submit" );
@@ -949,7 +956,7 @@
{
int rc, has_pool;
ERROR_IF( !threading_enabled, "ldap_pvt_thread_pool_destroy" );
- has_pool = (tpool != NULL && *tpool != NULL);
+ has_pool = (tpool && *tpool);
rc = ldap_int_thread_pool_destroy( tpool, run_pending );
if( has_pool ) {
if( rc ) {
Modified: openldap/vendor/openldap-release/libraries/liblutil/getpeereid.c
===================================================================
--- openldap/vendor/openldap-release/libraries/liblutil/getpeereid.c 2007-09-15 10:30:38 UTC (rev 843)
+++ openldap/vendor/openldap-release/libraries/liblutil/getpeereid.c 2007-09-15 10:38:52 UTC (rev 844)
@@ -1,5 +1,5 @@
/* getpeereid.c */
-/* $OpenLDAP: pkg/ldap/libraries/liblutil/getpeereid.c,v 1.13.2.9 2007/04/02 23:21:36 hyc Exp $ */
+/* $OpenLDAP: pkg/ldap/libraries/liblutil/getpeereid.c,v 1.13.2.10 2007/06/10 18:39:53 hallvard Exp $ */
/* This work is part of OpenLDAP Software <http://www.openldap.org/>.
*
* Copyright 2000-2007 The OpenLDAP Foundation.
@@ -50,7 +50,7 @@
#ifdef LDAP_PF_LOCAL
#if defined( SO_PEERCRED )
struct ucred peercred;
- socklen_t peercredlen = sizeof peercred;
+ ber_socklen_t peercredlen = sizeof peercred;
if(( getsockopt( s, SOL_SOCKET, SO_PEERCRED,
(void *)&peercred, &peercredlen ) == 0 )
@@ -63,7 +63,7 @@
#elif defined( LOCAL_PEERCRED )
struct xucred peercred;
- socklen_t peercredlen = sizeof peercred;
+ ber_socklen_t peercredlen = sizeof peercred;
if(( getsockopt( s, LOCAL_PEERCRED, 1,
(void *)&peercred, &peercredlen ) == 0 )
@@ -139,7 +139,7 @@
}
#elif defined(SOCKCREDSIZE)
struct msghdr msg;
- socklen_t crmsgsize;
+ ber_socklen_t crmsgsize;
void *crmsg;
struct cmsghdr *cmp;
struct sockcred *sc;
Modified: openldap/vendor/openldap-release/libraries/liblutil/passfile.c
===================================================================
--- openldap/vendor/openldap-release/libraries/liblutil/passfile.c 2007-09-15 10:30:38 UTC (rev 843)
+++ openldap/vendor/openldap-release/libraries/liblutil/passfile.c 2007-09-15 10:38:52 UTC (rev 844)
@@ -1,4 +1,4 @@
-/* $OpenLDAP: pkg/ldap/libraries/liblutil/passfile.c,v 1.6.2.3 2007/01/02 21:43:52 kurt Exp $ */
+/* $OpenLDAP: pkg/ldap/libraries/liblutil/passfile.c,v 1.6.2.4 2007/06/08 07:59:05 hyc Exp $ */
/* This work is part of OpenLDAP Software <http://www.openldap.org/>.
*
* Copyright 1998-2007 The OpenLDAP Foundation.
@@ -44,7 +44,7 @@
}
passwd->bv_val = NULL;
- passwd->bv_len = 4196;
+ passwd->bv_len = 4096;
#ifdef HAVE_FSTAT
{
@@ -56,7 +56,8 @@
filename );
}
- passwd->bv_len = sb.st_size;
+ if ( sb.st_size )
+ passwd->bv_len = sb.st_size;
}
}
#endif /* HAVE_FSTAT */
Modified: openldap/vendor/openldap-release/libraries/liblutil/sockpair.c
===================================================================
--- openldap/vendor/openldap-release/libraries/liblutil/sockpair.c 2007-09-15 10:30:38 UTC (rev 843)
+++ openldap/vendor/openldap-release/libraries/liblutil/sockpair.c 2007-09-15 10:38:52 UTC (rev 844)
@@ -1,4 +1,4 @@
-/* $OpenLDAP: pkg/ldap/libraries/liblutil/sockpair.c,v 1.15.2.3 2007/01/02 21:43:52 kurt Exp $ */
+/* $OpenLDAP: pkg/ldap/libraries/liblutil/sockpair.c,v 1.15.2.4 2007/06/10 18:39:53 hallvard Exp $ */
/* This work is part of OpenLDAP Software <http://www.openldap.org/>.
*
* Copyright 1998-2007 The OpenLDAP Foundation.
@@ -35,7 +35,8 @@
return pipe( sds );
#else
struct sockaddr_in si;
- int rc, len = sizeof(si);
+ int rc;
+ ber_socklen_t len = sizeof(si);
ber_socket_t sd;
sd = socket( AF_INET, SOCK_DGRAM, 0 );
Modified: openldap/vendor/openldap-release/servers/slapd/back-bdb/add.c
===================================================================
--- openldap/vendor/openldap-release/servers/slapd/back-bdb/add.c 2007-09-15 10:30:38 UTC (rev 843)
+++ openldap/vendor/openldap-release/servers/slapd/back-bdb/add.c 2007-09-15 10:38:52 UTC (rev 844)
@@ -1,5 +1,5 @@
/* add.c - ldap BerkeleyDB back-end add routine */
-/* $OpenLDAP: pkg/ldap/servers/slapd/back-bdb/add.c,v 1.126.2.16 2007/01/02 21:43:59 kurt Exp $ */
+/* $OpenLDAP: pkg/ldap/servers/slapd/back-bdb/add.c,v 1.126.2.17 2007/08/08 16:21:17 ando Exp $ */
/* This work is part of OpenLDAP Software <http://www.openldap.org/>.
*
* Copyright 2000-2007 The OpenLDAP Foundation.
@@ -201,41 +201,43 @@
goto return_results;;
}
- if ( is_entry_subentry( p ) ) {
- /* parent is a subentry, don't allow add */
- Debug( LDAP_DEBUG_TRACE,
- LDAP_XSTRING(bdb_add) ": parent is subentry\n",
- 0, 0, 0 );
- rs->sr_err = LDAP_OBJECT_CLASS_VIOLATION;
- rs->sr_text = "parent is a subentry";
- goto return_results;;
+ if ( p != (Entry *)&slap_entry_root ) {
+ if ( is_entry_subentry( p ) ) {
+ /* parent is a subentry, don't allow add */
+ Debug( LDAP_DEBUG_TRACE,
+ LDAP_XSTRING(bdb_add) ": parent is subentry\n",
+ 0, 0, 0 );
+ rs->sr_err = LDAP_OBJECT_CLASS_VIOLATION;
+ rs->sr_text = "parent is a subentry";
+ goto return_results;;
+ }
+ if ( is_entry_alias( p ) ) {
+ /* parent is an alias, don't allow add */
+ Debug( LDAP_DEBUG_TRACE,
+ LDAP_XSTRING(bdb_add) ": parent is alias\n",
+ 0, 0, 0 );
+ rs->sr_err = LDAP_ALIAS_PROBLEM;
+ rs->sr_text = "parent is an alias";
+ goto return_results;;
+ }
+
+ if ( is_entry_referral( p ) ) {
+ /* parent is a referral, don't allow add */
+ rs->sr_matched = ber_strdup_x( p->e_name.bv_val,
+ op->o_tmpmemctx );
+ rs->sr_ref = get_entry_referrals( op, p );
+ bdb_unlocked_cache_return_entry_r( &bdb->bi_cache, p );
+ p = NULL;
+ Debug( LDAP_DEBUG_TRACE,
+ LDAP_XSTRING(bdb_add) ": parent is referral\n",
+ 0, 0, 0 );
+
+ rs->sr_err = LDAP_REFERRAL;
+ rs->sr_flags = REP_MATCHED_MUSTBEFREED | REP_REF_MUSTBEFREED;
+ goto return_results;
+ }
}
- if ( is_entry_alias( p ) ) {
- /* parent is an alias, don't allow add */
- Debug( LDAP_DEBUG_TRACE,
- LDAP_XSTRING(bdb_add) ": parent is alias\n",
- 0, 0, 0 );
- rs->sr_err = LDAP_ALIAS_PROBLEM;
- rs->sr_text = "parent is an alias";
- goto return_results;;
- }
- if ( is_entry_referral( p ) ) {
- /* parent is a referral, don't allow add */
- rs->sr_matched = ber_strdup_x( p->e_name.bv_val,
- op->o_tmpmemctx );
- rs->sr_ref = get_entry_referrals( op, p );
- bdb_unlocked_cache_return_entry_r( &bdb->bi_cache, p );
- p = NULL;
- Debug( LDAP_DEBUG_TRACE,
- LDAP_XSTRING(bdb_add) ": parent is referral\n",
- 0, 0, 0 );
-
- rs->sr_err = LDAP_REFERRAL;
- rs->sr_flags = REP_MATCHED_MUSTBEFREED | REP_REF_MUSTBEFREED;
- goto return_results;
- }
-
if ( subentry ) {
/* FIXME: */
/* parent must be an administrative point of the required kind */
Modified: openldap/vendor/openldap-release/servers/slapd/back-bdb/back-bdb.h
===================================================================
--- openldap/vendor/openldap-release/servers/slapd/back-bdb/back-bdb.h 2007-09-15 10:30:38 UTC (rev 843)
+++ openldap/vendor/openldap-release/servers/slapd/back-bdb/back-bdb.h 2007-09-15 10:38:52 UTC (rev 844)
@@ -1,5 +1,5 @@
/* back-bdb.h - bdb back-end header file */
-/* $OpenLDAP: pkg/ldap/servers/slapd/back-bdb/back-bdb.h,v 1.117.2.13 2007/01/03 04:36:04 hyc Exp $ */
+/* $OpenLDAP: pkg/ldap/servers/slapd/back-bdb/back-bdb.h,v 1.117.2.14 2007/08/06 12:32:51 ando Exp $ */
/* This work is part of OpenLDAP Software <http://www.openldap.org/>.
*
* Copyright 2000-2007 The OpenLDAP Foundation.
@@ -226,7 +226,7 @@
};
#define DB_OPEN(db, file, name, type, flags, mode) \
- (db)->open(db, file, name, type, flags, mode)
+ ((db)->open)(db, file, name, type, flags, mode)
#if DB_VERSION_MAJOR < 4
#define LOCK_DETECT(env,f,t,a) lock_detect(env, f, t, a)
@@ -257,7 +257,7 @@
#if DB_VERSION_FULL >= 0x04010011
#undef DB_OPEN
#define DB_OPEN(db, file, name, type, flags, mode) \
- (db)->open(db, NULL, file, name, type, flags, mode)
+ ((db)->open)(db, NULL, file, name, type, flags, mode)
#endif
#endif
Modified: openldap/vendor/openldap-release/servers/slapd/back-bdb/config.c
===================================================================
--- openldap/vendor/openldap-release/servers/slapd/back-bdb/config.c 2007-09-15 10:30:38 UTC (rev 843)
+++ openldap/vendor/openldap-release/servers/slapd/back-bdb/config.c 2007-09-15 10:38:52 UTC (rev 844)
@@ -1,5 +1,5 @@
/* config.c - bdb backend configuration file routine */
-/* $OpenLDAP: pkg/ldap/servers/slapd/back-bdb/config.c,v 1.43.2.17 2007/01/02 21:43:59 kurt Exp $ */
+/* $OpenLDAP: pkg/ldap/servers/slapd/back-bdb/config.c,v 1.43.2.18 2007/08/11 00:31:46 hyc Exp $ */
/* This work is part of OpenLDAP Software <http://www.openldap.org/>.
*
* Copyright 2000-2007 The OpenLDAP Foundation.
@@ -470,7 +470,6 @@
bdb->bi_db_config_path = NULL;
c->cleanup = bdb_cf_cleanup;
ldap_pvt_thread_pool_purgekey( bdb->bi_dbenv );
- ldap_pvt_thread_pool_purgekey( ((char *)bdb->bi_dbenv) + 1 );
break;
case BDB_NOSYNC:
bdb->bi_dbenv->set_flags( bdb->bi_dbenv, DB_TXN_NOSYNC, 0 );
Modified: openldap/vendor/openldap-release/servers/slapd/back-bdb/filterindex.c
===================================================================
--- openldap/vendor/openldap-release/servers/slapd/back-bdb/filterindex.c 2007-09-15 10:30:38 UTC (rev 843)
+++ openldap/vendor/openldap-release/servers/slapd/back-bdb/filterindex.c 2007-09-15 10:38:52 UTC (rev 844)
@@ -1,5 +1,5 @@
/* filterindex.c - generate the list of candidate entries from a filter */
-/* $OpenLDAP: pkg/ldap/servers/slapd/back-bdb/filterindex.c,v 1.51.2.10 2007/01/02 21:44:00 kurt Exp $ */
+/* $OpenLDAP: pkg/ldap/servers/slapd/back-bdb/filterindex.c,v 1.51.2.11 2007/07/22 15:20:16 hyc Exp $ */
/* This work is part of OpenLDAP Software <http://www.openldap.org/>.
*
* Copyright 2000-2007 The OpenLDAP Foundation.
@@ -328,9 +328,6 @@
if( rc != LDAP_SUCCESS ) {
return 0;
}
- if ( db == NULL ) {
- return 0;
- }
if( !mr ) {
return 0;
@@ -572,6 +569,14 @@
rc = bdb_index_param( op->o_bd, desc, LDAP_FILTER_PRESENT,
&db, &mask, &prefix );
+ if( rc == LDAP_INAPPROPRIATE_MATCHING ) {
+ /* not indexed */
+ Debug( LDAP_DEBUG_TRACE,
+ "<= bdb_presence_candidates: (%s) not indexed\n",
+ desc->ad_cname.bv_val, 0, 0 );
+ return 0;
+ }
+
if( rc != LDAP_SUCCESS ) {
Debug( LDAP_DEBUG_TRACE,
"<= bdb_presence_candidates: (%s) index_param "
@@ -580,14 +585,6 @@
return 0;
}
- if( db == NULL ) {
- /* not indexed */
- Debug( LDAP_DEBUG_TRACE,
- "<= bdb_presence_candidates: (%s) not indexed\n",
- desc->ad_cname.bv_val, 0, 0 );
- return 0;
- }
-
if( prefix.bv_val == NULL ) {
Debug( LDAP_DEBUG_TRACE,
"<= bdb_presence_candidates: (%s) no prefix\n",
@@ -642,6 +639,13 @@
rc = bdb_index_param( op->o_bd, ava->aa_desc, LDAP_FILTER_EQUALITY,
&db, &mask, &prefix );
+ if ( rc == LDAP_INAPPROPRIATE_MATCHING ) {
+ Debug( LDAP_DEBUG_ANY,
+ "<= bdb_equality_candidates: (%s) not indexed\n",
+ ava->aa_desc->ad_cname.bv_val, 0, 0 );
+ return 0;
+ }
+
if( rc != LDAP_SUCCESS ) {
Debug( LDAP_DEBUG_ANY,
"<= bdb_equality_candidates: (%s) "
@@ -650,13 +654,6 @@
return 0;
}
- if ( db == NULL ) {
- Debug( LDAP_DEBUG_ANY,
- "<= bdb_equality_candidates: (%s) not indexed\n",
- ava->aa_desc->ad_cname.bv_val, 0, 0 );
- return 0;
- }
-
mr = ava->aa_desc->ad_type->sat_equality;
if( !mr ) {
return 0;
@@ -758,6 +755,13 @@
rc = bdb_index_param( op->o_bd, ava->aa_desc, LDAP_FILTER_APPROX,
&db, &mask, &prefix );
+ if ( rc == LDAP_INAPPROPRIATE_MATCHING ) {
+ Debug( LDAP_DEBUG_ANY,
+ "<= bdb_approx_candidates: (%s) not indexed\n",
+ ava->aa_desc->ad_cname.bv_val, 0, 0 );
+ return 0;
+ }
+
if( rc != LDAP_SUCCESS ) {
Debug( LDAP_DEBUG_ANY,
"<= bdb_approx_candidates: (%s) "
@@ -766,13 +770,6 @@
return 0;
}
- if ( db == NULL ) {
- Debug( LDAP_DEBUG_ANY,
- "<= bdb_approx_candidates: (%s) not indexed\n",
- ava->aa_desc->ad_cname.bv_val, 0, 0 );
- return 0;
- }
-
mr = ava->aa_desc->ad_type->sat_approx;
if( !mr ) {
/* no approx matching rule, try equality matching rule */
@@ -877,6 +874,13 @@
rc = bdb_index_param( op->o_bd, sub->sa_desc, LDAP_FILTER_SUBSTRINGS,
&db, &mask, &prefix );
+ if ( rc == LDAP_INAPPROPRIATE_MATCHING ) {
+ Debug( LDAP_DEBUG_ANY,
+ "<= bdb_substring_candidates: (%s) not indexed\n",
+ sub->sa_desc->ad_cname.bv_val, 0, 0 );
+ return 0;
+ }
+
if( rc != LDAP_SUCCESS ) {
Debug( LDAP_DEBUG_ANY,
"<= bdb_substring_candidates: (%s) "
@@ -885,13 +889,6 @@
return 0;
}
- if ( db == NULL ) {
- Debug( LDAP_DEBUG_ANY,
- "<= bdb_substring_candidates: (%s) not indexed\n",
- sub->sa_desc->ad_cname.bv_val, 0, 0 );
- return 0;
- }
-
mr = sub->sa_desc->ad_type->sat_substr;
if( !mr ) {
@@ -993,6 +990,13 @@
rc = bdb_index_param( op->o_bd, ava->aa_desc, LDAP_FILTER_EQUALITY,
&db, &mask, &prefix );
+ if ( rc == LDAP_INAPPROPRIATE_MATCHING ) {
+ Debug( LDAP_DEBUG_ANY,
+ "<= bdb_inequality_candidates: (%s) not indexed\n",
+ ava->aa_desc->ad_cname.bv_val, 0, 0 );
+ return 0;
+ }
+
if( rc != LDAP_SUCCESS ) {
Debug( LDAP_DEBUG_ANY,
"<= bdb_inequality_candidates: (%s) "
@@ -1001,13 +1005,6 @@
return 0;
}
- if ( db == NULL ) {
- Debug( LDAP_DEBUG_ANY,
- "<= bdb_inequality_candidates: (%s) not indexed\n",
- ava->aa_desc->ad_cname.bv_val, 0, 0 );
- return 0;
- }
-
mr = ava->aa_desc->ad_type->sat_equality;
if( !mr ) {
return 0;
Modified: openldap/vendor/openldap-release/servers/slapd/back-bdb/index.c
===================================================================
--- openldap/vendor/openldap-release/servers/slapd/back-bdb/index.c 2007-09-15 10:30:38 UTC (rev 843)
+++ openldap/vendor/openldap-release/servers/slapd/back-bdb/index.c 2007-09-15 10:38:52 UTC (rev 844)
@@ -1,5 +1,5 @@
/* index.c - routines for dealing with attribute indexes */
-/* $OpenLDAP: pkg/ldap/servers/slapd/back-bdb/index.c,v 1.46.2.10 2007/01/02 21:44:00 kurt Exp $ */
+/* $OpenLDAP: pkg/ldap/servers/slapd/back-bdb/index.c,v 1.46.2.11 2007/07/22 15:54:14 hyc Exp $ */
/* This work is part of OpenLDAP Software <http://www.openldap.org/>.
*
* Copyright 2000-2007 The OpenLDAP Foundation.
@@ -435,6 +435,10 @@
AttrList *al;
int i, rc = 0;
+ /* Never index ID 0 */
+ if ( id == 0 )
+ return 0;
+
for (i=base; i<bdb->bi_nattrs; i+=slap_tool_thread_max) {
ir = ir0 + i;
if ( !ir->ai ) continue;
@@ -472,6 +476,10 @@
struct berval value = {0};
#endif
+ /* Never index ID 0 */
+ if ( e->e_id == 0 )
+ return 0;
+
Debug( LDAP_DEBUG_TRACE, "=> index_entry_%s( %ld, \"%s\" )\n",
opid == SLAP_INDEX_DELETE_OP ? "del" : "add",
(long) e->e_id, e->e_dn );
Modified: openldap/vendor/openldap-release/servers/slapd/back-bdb/init.c
===================================================================
--- openldap/vendor/openldap-release/servers/slapd/back-bdb/init.c 2007-09-15 10:30:38 UTC (rev 843)
+++ openldap/vendor/openldap-release/servers/slapd/back-bdb/init.c 2007-09-15 10:38:52 UTC (rev 844)
@@ -1,5 +1,5 @@
/* init.c - initialize bdb backend */
-/* $OpenLDAP: pkg/ldap/servers/slapd/back-bdb/init.c,v 1.177.2.28 2007/02/24 19:28:11 hyc Exp $ */
+/* $OpenLDAP: pkg/ldap/servers/slapd/back-bdb/init.c,v 1.177.2.29 2007/08/06 12:32:51 ando Exp $ */
/* This work is part of OpenLDAP Software <http://www.openldap.org/>.
*
* Copyright 2000-2007 The OpenLDAP Foundation.
@@ -288,7 +288,7 @@
bdb->bi_dbenv->set_shm_key( bdb->bi_dbenv, bdb->bi_shm_key );
flags |= DB_SYSTEM_MEM;
}
- rc = bdb->bi_dbenv->open( bdb->bi_dbenv, dbhome,
+ rc = (bdb->bi_dbenv->open)( bdb->bi_dbenv, dbhome,
flags | do_recover, bdb->bi_dbenv_mode );
if ( rc ) {
Modified: openldap/vendor/openldap-release/servers/slapd/back-bdb/modify.c
===================================================================
--- openldap/vendor/openldap-release/servers/slapd/back-bdb/modify.c 2007-09-15 10:30:38 UTC (rev 843)
+++ openldap/vendor/openldap-release/servers/slapd/back-bdb/modify.c 2007-09-15 10:38:52 UTC (rev 844)
@@ -1,5 +1,5 @@
/* modify.c - bdb backend modify routine */
-/* $OpenLDAP: pkg/ldap/servers/slapd/back-bdb/modify.c,v 1.124.2.16 2007/01/02 21:44:00 kurt Exp $ */
+/* $OpenLDAP: pkg/ldap/servers/slapd/back-bdb/modify.c,v 1.124.2.17 2007/04/11 18:32:24 ando Exp $ */
/* This work is part of OpenLDAP Software <http://www.openldap.org/>.
*
* Copyright 2000-2007 The OpenLDAP Foundation.
@@ -538,6 +538,8 @@
} else {
rs->sr_err = LDAP_X_NO_OPERATION;
ltid = NULL;
+ /* Only free attrs if they were dup'd. */
+ if ( dummy.e_attrs == e->e_attrs ) dummy.e_attrs = NULL;
goto return_results;
}
} else {
Modified: openldap/vendor/openldap-release/servers/slapd/back-bdb/search.c
===================================================================
--- openldap/vendor/openldap-release/servers/slapd/back-bdb/search.c 2007-09-15 10:30:38 UTC (rev 843)
+++ openldap/vendor/openldap-release/servers/slapd/back-bdb/search.c 2007-09-15 10:38:52 UTC (rev 844)
@@ -1,5 +1,5 @@
/* search.c - search operation */
-/* $OpenLDAP: pkg/ldap/servers/slapd/back-bdb/search.c,v 1.221.2.15 2007/01/02 21:44:00 kurt Exp $ */
+/* $OpenLDAP: pkg/ldap/servers/slapd/back-bdb/search.c,v 1.221.2.16 2007/07/20 22:42:26 hyc Exp $ */
/* This work is part of OpenLDAP Software <http://www.openldap.org/>.
*
* Copyright 2000-2007 The OpenLDAP Foundation.
@@ -360,6 +360,7 @@
ei_root.bei_parent = &ei_root;
e_root.e_private = &ei_root;
e_root.e_id = 0;
+ e_root.e_ocflags = SLAP_OC_GLUE | SLAP_OC__END;
BER_BVSTR( &e_root.e_nname, "" );
BER_BVSTR( &e_root.e_name, "" );
ei = &ei_root;
Modified: openldap/vendor/openldap-release/servers/slapd/back-bdb/tools.c
===================================================================
--- openldap/vendor/openldap-release/servers/slapd/back-bdb/tools.c 2007-09-15 10:30:38 UTC (rev 843)
+++ openldap/vendor/openldap-release/servers/slapd/back-bdb/tools.c 2007-09-15 10:38:52 UTC (rev 844)
@@ -1,5 +1,5 @@
/* tools.c - tools for slap tools */
-/* $OpenLDAP: pkg/ldap/servers/slapd/back-bdb/tools.c,v 1.72.2.16 2007/01/02 21:44:00 kurt Exp $ */
+/* $OpenLDAP: pkg/ldap/servers/slapd/back-bdb/tools.c,v 1.72.2.17 2007/08/11 00:32:20 hyc Exp $ */
/* This work is part of OpenLDAP Software <http://www.openldap.org/>.
*
* Copyright 2000-2007 The OpenLDAP Foundation.
@@ -228,19 +228,22 @@
Entry **e
)
{
- int rc = bdb_id2entry( be, NULL, 0, id, e );
+ int rc;
+ ID nid;
- if ( rc == DB_NOTFOUND && id == 0 ) {
- Entry *dummy = ch_calloc( 1, sizeof(Entry) );
- struct berval gluebv = BER_BVC("glue");
- dummy->e_name.bv_val = ch_strdup( "" );
- dummy->e_nname.bv_val = ch_strdup( "" );
- attr_merge_one( dummy, slap_schema.si_ad_objectClass, &gluebv, NULL );
- attr_merge_one( dummy, slap_schema.si_ad_structuralObjectClass,
- &gluebv, NULL );
- *e = dummy;
- rc = LDAP_SUCCESS;
+ BDB_ID2DISK( id, &nid );
+ key.ulen = key.size = sizeof(ID);
+ key.flags = DB_DBT_USERMEM;
+ key.data = &nid;
+
+ rc = cursor->c_get( cursor, &key, &data, DB_SET );
+ if ( rc == 0 ) {
+ *e = bdb_tool_entry_get( be, id );
+ if ( *e == NULL )
+ rc = LDAP_OTHER;
}
+ key.data = NULL;
+
return rc;
}
Modified: openldap/vendor/openldap-release/servers/slapd/back-ldap/chain.c
===================================================================
--- openldap/vendor/openldap-release/servers/slapd/back-ldap/chain.c 2007-09-15 10:30:38 UTC (rev 843)
+++ openldap/vendor/openldap-release/servers/slapd/back-ldap/chain.c 2007-09-15 10:38:52 UTC (rev 844)
@@ -1,5 +1,5 @@
/* chain.c - chain LDAP operations */
-/* $OpenLDAP: pkg/ldap/servers/slapd/back-ldap/chain.c,v 1.12.2.22 2007/02/01 21:20:21 ando Exp $ */
+/* $OpenLDAP: pkg/ldap/servers/slapd/back-ldap/chain.c,v 1.12.2.23 2007/05/19 12:27:53 ando Exp $ */
/* This work is part of OpenLDAP Software <http://www.openldap.org/>.
*
* Copyright 2003-2007 The OpenLDAP Foundation.
@@ -418,7 +418,7 @@
LDAPURLDesc *srv = NULL;
struct berval save_req_dn = op->o_req_dn,
save_req_ndn = op->o_req_ndn,
- dn,
+ dn = BER_BVNULL,
pdn = BER_BVNULL,
ndn = BER_BVNULL;
int temporary = 0;
@@ -449,17 +449,24 @@
}
/* normalize DN */
- ber_str2bv( srv->lud_dn, 0, 0, &dn );
- rc = dnPrettyNormal( NULL, &dn, &pdn, &ndn, op->o_tmpmemctx );
- if ( rc == LDAP_SUCCESS ) {
- /* remove DN essentially because later on
- * ldap_initialize() will parse the URL
- * as a comma-separated URL list */
+ rc = LDAP_SUCCESS;
+ srv->lud_scope = LDAP_SCOPE_DEFAULT;
+ if ( srv->lud_dn != NULL ) {
+ ber_str2bv( srv->lud_dn, 0, 0, &dn );
+ rc = dnPrettyNormal( NULL, &dn, &pdn, &ndn, op->o_tmpmemctx );
+ if ( rc == LDAP_SUCCESS ) {
+ /* remove DN essentially because later on
+ * ldap_initialize() will parse the URL
+ * as a comma-separated URL list */
+ srv->lud_dn = "";
+ }
+
+ } else {
srv->lud_dn = "";
- srv->lud_scope = LDAP_SCOPE_DEFAULT;
- li.li_uri = ldap_url_desc2str( srv );
- srv->lud_dn = dn.bv_val;
}
+
+ li.li_uri = ldap_url_desc2str( srv );
+ srv->lud_dn = dn.bv_val;
ldap_free_urldesc( srv );
if ( rc != LDAP_SUCCESS ) {
@@ -629,16 +636,19 @@
}
/* normalize DN */
- ber_str2bv( srv->lud_dn, 0, 0, &dn );
- rc = dnPrettyNormal( NULL, &dn, &pdn, &ndn, op->o_tmpmemctx );
- if ( rc == LDAP_SUCCESS ) {
- /* remove DN essentially because later on
- * ldap_initialize() will parse the URL
- * as a comma-separated URL list */
- srv->lud_dn = "";
- srv->lud_scope = LDAP_SCOPE_DEFAULT;
- li.li_uri = ldap_url_desc2str( srv );
- srv->lud_dn = dn.bv_val;
+ rc = LDAP_INVALID_SYNTAX;
+ if ( srv->lud_dn != NULL ) {
+ ber_str2bv( srv->lud_dn, 0, 0, &dn );
+ rc = dnPrettyNormal( NULL, &dn, &pdn, &ndn, op->o_tmpmemctx );
+ if ( rc == LDAP_SUCCESS ) {
+ /* remove DN essentially because later on
+ * ldap_initialize() will parse the URL
+ * as a comma-separated URL list */
+ srv->lud_dn = "";
+ srv->lud_scope = LDAP_SCOPE_DEFAULT;
+ li.li_uri = ldap_url_desc2str( srv );
+ srv->lud_dn = dn.bv_val;
+ }
}
ldap_free_urldesc( srv );
@@ -778,7 +788,7 @@
slap_callback *sc = op->o_callback,
sc2 = { 0 };
int rc = 0;
- char *text = NULL;
+ const char *text = NULL;
const char *matched;
BerVarray ref;
struct berval ndn = op->o_ndn;
@@ -917,6 +927,7 @@
* to send it... */
/* FIXME: what about chaining? */
if ( rc != SLAPD_ABANDON ) {
+ rs->sr_err = rc;
send_ldap_extended( op, rs );
rc = LDAP_SUCCESS;
}
Modified: openldap/vendor/openldap-release/servers/slapd/back-ldap/extended.c
===================================================================
--- openldap/vendor/openldap-release/servers/slapd/back-ldap/extended.c 2007-09-15 10:30:38 UTC (rev 843)
+++ openldap/vendor/openldap-release/servers/slapd/back-ldap/extended.c 2007-09-15 10:38:52 UTC (rev 844)
@@ -1,5 +1,5 @@
/* extended.c - ldap backend extended routines */
-/* $OpenLDAP: pkg/ldap/servers/slapd/back-ldap/extended.c,v 1.22.2.17 2007/01/13 11:19:07 ando Exp $ */
+/* $OpenLDAP: pkg/ldap/servers/slapd/back-ldap/extended.c,v 1.22.2.18 2007/05/19 12:27:53 ando Exp $ */
/* This work is part of OpenLDAP Software <http://www.openldap.org/>.
*
* Copyright 2003-2007 The OpenLDAP Foundation.
@@ -28,19 +28,21 @@
#include "back-ldap.h"
#include "lber_pvt.h"
-static BI_op_extended ldap_back_exop_passwd;
-static BI_op_extended ldap_back_exop_generic;
+typedef int (ldap_back_exop_f)( Operation *op, SlapReply *rs, ldapconn_t **lc );
+static ldap_back_exop_f ldap_back_exop_passwd;
+static ldap_back_exop_f ldap_back_exop_generic;
+
static struct exop {
- struct berval oid;
- BI_op_extended *extended;
+ struct berval oid;
+ ldap_back_exop_f *extended;
} exop_table[] = {
{ BER_BVC(LDAP_EXOP_MODIFY_PASSWD), ldap_back_exop_passwd },
{ BER_BVNULL, NULL }
};
static int
-ldap_back_extended_one( Operation *op, SlapReply *rs, BI_op_extended exop )
+ldap_back_extended_one( Operation *op, SlapReply *rs, ldap_back_exop_f exop )
{
ldapinfo_t *li = (ldapinfo_t *) op->o_bd->be_private;
@@ -68,7 +70,7 @@
goto done;
}
- rc = exop( op, rs );
+ rc = exop( op, rs, &lc );
if ( op->o_ctrls && op->o_ctrls != oldctrls ) {
free( op->o_ctrls[ 0 ] );
@@ -106,30 +108,83 @@
static int
ldap_back_exop_passwd(
- Operation *op,
- SlapReply *rs )
+ Operation *op,
+ SlapReply *rs,
+ ldapconn_t **lcp )
{
ldapinfo_t *li = (ldapinfo_t *) op->o_bd->be_private;
- ldapconn_t *lc = NULL;
+ ldapconn_t *lc = *lcp;
req_pwdexop_s *qpw = &op->oq_pwdexop;
LDAPMessage *res;
ber_int_t msgid;
- int rc, isproxy;
+ int rc, isproxy, freedn = 0;
int do_retry = 1;
- char *text = NULL;
+ char *text = NULL;
+ struct berval dn = op->o_req_dn,
+ ndn = op->o_req_ndn;
- if ( !ldap_back_dobind( &lc, op, rs, LDAP_BACK_SENDERR ) ) {
- return -1;
+ assert( lc != NULL );
+
+ if ( BER_BVISNULL( &ndn ) && op->ore_reqdata != NULL ) {
+ /* NOTE: most of this code is mutuated
+ * from slap_passwd_parse(); we can't call
+ * that function since now the request data
+ * has been destroyed by NULL-terminating
+ * the bervals. Luckily enough, we only need
+ * the first berval... */
+
+ ber_tag_t tag;
+ ber_len_t len = -1;
+ BerElementBuffer berbuf;
+ BerElement *ber = (BerElement *)&berbuf;
+
+ struct berval tmpid = BER_BVNULL;
+
+ if ( op->ore_reqdata->bv_len == 0 ) {
+ return LDAP_PROTOCOL_ERROR;
+ }
+
+ /* ber_init2 uses reqdata directly, doesn't allocate new buffers */
+ ber_init2( ber, op->ore_reqdata, 0 );
+
+ tag = ber_scanf( ber, "{" /*}*/ );
+
+ if ( tag == LBER_ERROR ) {
+ return LDAP_PROTOCOL_ERROR;
+ }
+
+ tag = ber_peek_tag( ber, &len );
+ if ( tag == LDAP_TAG_EXOP_MODIFY_PASSWD_ID ) {
+ tag = ber_scanf( ber, "m", &tmpid );
+
+ if ( tag == LBER_ERROR ) {
+ return LDAP_PROTOCOL_ERROR;
+ }
+ }
+
+ if ( !BER_BVISEMPTY( &tmpid ) ) {
+ rs->sr_err = dnPrettyNormal( NULL, &tmpid, &dn,
+ &ndn, op->o_tmpmemctx );
+ if ( rs->sr_err != LDAP_SUCCESS ) {
+ /* should have been successfully parsed earlier! */
+ return rs->sr_err;
+ }
+ freedn = 1;
+
+ } else {
+ dn = op->o_dn;
+ ndn = op->o_ndn;
+ }
}
- isproxy = ber_bvcmp( &op->o_req_ndn, &op->o_ndn );
+ isproxy = ber_bvcmp( &ndn, &op->o_ndn );
Debug( LDAP_DEBUG_ARGS, "==> ldap_back_exop_passwd(\"%s\")%s\n",
- op->o_req_dn.bv_val, isproxy ? " (proxy)" : "", 0 );
+ dn.bv_val, isproxy ? " (proxy)" : "", 0 );
retry:
- rc = ldap_passwd( lc->lc_ld, isproxy ? &op->o_req_dn : NULL,
+ rc = ldap_passwd( lc->lc_ld, isproxy ? &dn : NULL,
qpw->rs_old.bv_val ? &qpw->rs_old : NULL,
qpw->rs_new.bv_val ? &qpw->rs_new : NULL,
op->o_ctrls, NULL, &msgid );
@@ -214,6 +269,11 @@
ldap_back_quarantine( op, rs );
}
+ if ( freedn ) {
+ op->o_tmpfree( dn.bv_val, op->o_tmpmemctx );
+ op->o_tmpfree( ndn.bv_val, op->o_tmpmemctx );
+ }
+
/* these have to be freed anyway... */
if ( rs->sr_matched ) {
free( (char *)rs->sr_matched );
@@ -225,8 +285,9 @@
rs->sr_text = NULL;
}
- if ( lc != NULL ) {
- ldap_back_release_conn( li, lc );
+ /* in case, cleanup handler */
+ if ( lc == NULL ) {
+ *lcp = NULL;
}
return rc;
@@ -235,20 +296,19 @@
static int
ldap_back_exop_generic(
Operation *op,
- SlapReply *rs )
+ SlapReply *rs,
+ ldapconn_t **lcp )
{
ldapinfo_t *li = (ldapinfo_t *) op->o_bd->be_private;
- ldapconn_t *lc = NULL;
+ ldapconn_t *lc = *lcp;
LDAPMessage *res;
ber_int_t msgid;
int rc;
int do_retry = 1;
- char *text = NULL;
+ char *text = NULL;
- if ( !ldap_back_dobind( &lc, op, rs, LDAP_BACK_SENDERR ) ) {
- return -1;
- }
+ assert( lc != NULL );
Debug( LDAP_DEBUG_ARGS, "==> ldap_back_exop_generic(%s, \"%s\")\n",
op->ore_reqoid.bv_val, op->o_req_dn.bv_val, 0 );
@@ -335,8 +395,9 @@
rs->sr_text = NULL;
}
- if ( lc != NULL ) {
- ldap_back_release_conn( li, lc );
+ /* in case, cleanup handler */
+ if ( lc == NULL ) {
+ *lcp = NULL;
}
return rc;
Modified: openldap/vendor/openldap-release/servers/slapd/back-ldap/search.c
===================================================================
--- openldap/vendor/openldap-release/servers/slapd/back-ldap/search.c 2007-09-15 10:30:38 UTC (rev 843)
+++ openldap/vendor/openldap-release/servers/slapd/back-ldap/search.c 2007-09-15 10:38:52 UTC (rev 844)
@@ -1,5 +1,5 @@
/* search.c - ldap backend search function */
-/* $OpenLDAP: pkg/ldap/servers/slapd/back-ldap/search.c,v 1.148.2.38 2007/03/09 16:23:16 ando Exp $ */
+/* $OpenLDAP: pkg/ldap/servers/slapd/back-ldap/search.c,v 1.148.2.39 2007/07/11 23:41:11 hyc Exp $ */
/* This work is part of OpenLDAP Software <http://www.openldap.org/>.
*
* Copyright 1999-2007 The OpenLDAP Foundation.
@@ -330,12 +330,18 @@
e = ldap_first_entry( lc->lc_ld, res );
rc = ldap_build_entry( op, e, &ent, &bdn );
if ( rc == LDAP_SUCCESS ) {
+ ldap_get_entry_controls( lc->lc_ld, res, &rs->sr_ctrls );
rs->sr_entry = &ent;
rs->sr_attrs = op->ors_attrs;
rs->sr_operational_attrs = NULL;
rs->sr_flags = 0;
rs->sr_err = LDAP_SUCCESS;
rc = rs->sr_err = send_search_entry( op, rs );
+ if ( rs->sr_ctrls ) {
+ ldap_controls_free( rs->sr_ctrls );
+ rs->sr_ctrls = NULL;
+ }
+ rs->sr_entry = NULL;
if ( !BER_BVISNULL( &ent.e_name ) ) {
assert( ent.e_name.bv_val != bdn.bv_val );
op->o_tmpfree( ent.e_name.bv_val, op->o_tmpmemctx );
@@ -383,6 +389,7 @@
BER_BVZERO( &rs->sr_ref[ cnt ] );
/* ignore return value by now */
+ rs->sr_entry = NULL;
( void )send_search_reference( op, rs );
} else {
Modified: openldap/vendor/openldap-release/servers/slapd/back-ldbm/compare.c
===================================================================
--- openldap/vendor/openldap-release/servers/slapd/back-ldbm/compare.c 2007-09-15 10:30:38 UTC (rev 843)
+++ openldap/vendor/openldap-release/servers/slapd/back-ldbm/compare.c 2007-09-15 10:38:52 UTC (rev 844)
@@ -1,5 +1,5 @@
/* compare.c - ldbm backend compare routine */
-/* $OpenLDAP: pkg/ldap/servers/slapd/back-ldbm/compare.c,v 1.49.2.7 2007/01/02 21:44:02 kurt Exp $ */
+/* $OpenLDAP: pkg/ldap/servers/slapd/back-ldbm/compare.c,v 1.49.2.9 2007/07/13 17:28:55 hallvard Exp $ */
/* This work is part of OpenLDAP Software <http://www.openldap.org/>.
*
* Copyright 1998-2007 The OpenLDAP Foundation.
@@ -56,8 +56,6 @@
NULL, &op->o_req_dn, LDAP_SCOPE_DEFAULT );
}
- ldap_pvt_thread_rdwr_runlock(&li->li_giant_rwlock);
-
rs->sr_err = LDAP_REFERRAL;
goto return_results;
}
Modified: openldap/vendor/openldap-release/servers/slapd/back-ldbm/ldbm.c
===================================================================
--- openldap/vendor/openldap-release/servers/slapd/back-ldbm/ldbm.c 2007-09-15 10:30:38 UTC (rev 843)
+++ openldap/vendor/openldap-release/servers/slapd/back-ldbm/ldbm.c 2007-09-15 10:38:52 UTC (rev 844)
@@ -1,5 +1,5 @@
/* ldbm.c - ldap dbm compatibility routines */
-/* $OpenLDAP: pkg/ldap/servers/slapd/back-ldbm/ldbm.c,v 1.4.2.4 2007/01/02 21:44:03 kurt Exp $ */
+/* $OpenLDAP: pkg/ldap/servers/slapd/back-ldbm/ldbm.c,v 1.4.2.6 2007/08/06 12:32:51 ando Exp $ */
/* This work is part of OpenLDAP Software <http://www.openldap.org/>.
*
* Copyright 1998-2007 The OpenLDAP Foundation.
@@ -137,7 +137,7 @@
#if DB_VERSION_X < 0x040300
ldbm_db_errcall( const char *prefix, char *message )
#else
-ldbm_db_errcall( const DB_ENV *env, const char *prefix, char *message )
+ldbm_db_errcall( const DB_ENV *env, const char *prefix, const char *message )
#endif
{
#ifdef LDAP_SYSLOG
@@ -298,10 +298,10 @@
home = n2;
#endif
#if DB_VERSION_X >= 0x030100
- err = env->open( env, home, envFlags, 0 );
+ err = (env->open)( env, home, envFlags, 0 );
#else
/* 3.0.x requires an extra argument */
- err = env->open( env, home, NULL, envFlags, 0 );
+ err = (env->open)( env, home, NULL, envFlags, 0 );
#endif
if ( err != 0 ) {
@@ -380,9 +380,9 @@
name = n2;
#endif
#if DB_VERSION_X >= 0x040111
- err = ret->open( ret, NULL, name, NULL, DB_TYPE, rw, mode);
+ err = (ret->open)( ret, NULL, name, NULL, DB_TYPE, rw, mode);
#else
- err = ret->open( ret, name, NULL, DB_TYPE, rw, mode);
+ err = (ret->open)( ret, name, NULL, DB_TYPE, rw, mode);
#endif
if ( err != 0 ) {
Modified: openldap/vendor/openldap-release/servers/slapd/back-meta/search.c
===================================================================
--- openldap/vendor/openldap-release/servers/slapd/back-meta/search.c 2007-09-15 10:30:38 UTC (rev 843)
+++ openldap/vendor/openldap-release/servers/slapd/back-meta/search.c 2007-09-15 10:38:52 UTC (rev 844)
@@ -1,4 +1,4 @@
-/* $OpenLDAP: pkg/ldap/servers/slapd/back-meta/search.c,v 1.84.2.32 2007/03/14 00:07:56 ando Exp $ */
+/* $OpenLDAP: pkg/ldap/servers/slapd/back-meta/search.c,v 1.84.2.33 2007/08/14 09:59:44 ando Exp $ */
/* This work is part of OpenLDAP Software <http://www.openldap.org/>.
*
* Copyright 1999-2007 The OpenLDAP Foundation.
@@ -1720,6 +1720,7 @@
{
metainfo_t *mi = ( metainfo_t * )op->o_bd->be_private;
struct berval a, mapped;
+ int check_duplicate_attrs = 0;
Entry ent = { 0 };
BerElement ber = *e->lm_ber;
Attribute *attr, **attrp;
@@ -1786,6 +1787,10 @@
( void )ber_scanf( &ber, "x" /* [W] */ );
continue;
}
+ if ( mapped.bv_val != a.bv_val ) {
+ /* will need to check for duplicate attrs */
+ check_duplicate_attrs++;
+ }
attr = ( Attribute * )ch_calloc( 1, sizeof( Attribute ) );
if ( attr == NULL ) {
continue;
@@ -1858,6 +1863,7 @@
ldap_back_map( &mi->mi_targets[ target ]->mt_rwmap.rwm_oc,
bv, &mapped, BACKLDAP_REMAP );
if ( BER_BVISNULL( &mapped ) || mapped.bv_val[0] == '\0') {
+remove_oc:;
free( bv->bv_val );
BER_BVZERO( bv );
if ( --last < 0 ) {
@@ -1868,8 +1874,23 @@
bv--;
} else if ( mapped.bv_val != bv->bv_val ) {
- free( bv->bv_val );
- ber_dupbv( bv, &mapped );
+ int i;
+
+ for ( i = 0; !BER_BVISNULL( &attr->a_vals[ i ] ); i++ ) {
+ if ( &attr->a_vals[ i ] == bv ) {
+ continue;
+ }
+
+ if ( ber_bvstrcasecmp( &mapped, &attr->a_vals[ i ] ) == 0 ) {
+ break;
+ }
+ }
+
+ if ( !BER_BVISNULL( &attr->a_vals[ i ] ) ) {
+ goto remove_oc;
+ }
+
+ ber_bvreplace( bv, &mapped );
}
}
/*
@@ -1957,6 +1978,48 @@
attrp = &attr->a_next;
next_attr:;
}
+
+ /* only check if some mapping occurred */
+ if ( check_duplicate_attrs ) {
+ Attribute **ap;
+
+ for ( ap = &ent.e_attrs; *ap != NULL; ap = &(*ap)->a_next ) {
+ Attribute **tap;
+
+ for ( tap = &(*ap)->a_next; *tap != NULL; ) {
+ if ( (*tap)->a_desc == (*ap)->a_desc ) {
+ Entry e = { 0 };
+ Modification mod = { 0 };
+ const char *text = NULL;
+ char textbuf[ SLAP_TEXT_BUFLEN ];
+ Attribute *next = (*tap)->a_next;
+
+ BER_BVSTR( &e.e_name, "" );
+ BER_BVSTR( &e.e_nname, "" );
+ e.e_attrs = *ap;
+ mod.sm_op = LDAP_MOD_ADD;
+ mod.sm_desc = (*ap)->a_desc;
+ mod.sm_type = mod.sm_desc->ad_cname;
+ mod.sm_values = (*tap)->a_vals;
+ mod.sm_nvalues = (*tap)->a_nvals;
+
+ (void)modify_add_values( &e, &mod,
+ /* permissive */ 1,
+ &text, textbuf, sizeof( textbuf ) );
+
+ /* should not insert new attrs! */
+ assert( e.e_attrs == *ap );
+
+ attr_free( *tap );
+ *tap = next;
+
+ } else {
+ tap = &(*tap)->a_next;
+ }
+ }
+ }
+ }
+
rs->sr_entry = &ent;
rs->sr_attrs = op->ors_attrs;
rs->sr_flags = 0;
Modified: openldap/vendor/openldap-release/servers/slapd/back-perl/SampleLDAP.pm
===================================================================
--- openldap/vendor/openldap-release/servers/slapd/back-perl/SampleLDAP.pm 2007-09-15 10:30:38 UTC (rev 843)
+++ openldap/vendor/openldap-release/servers/slapd/back-perl/SampleLDAP.pm 2007-09-15 10:38:52 UTC (rev 844)
@@ -1,5 +1,5 @@
# This is a sample Perl module for the OpenLDAP server slapd.
-# $OpenLDAP: pkg/ldap/servers/slapd/back-perl/SampleLDAP.pm,v 1.8.2.3 2007/01/02 21:44:06 kurt Exp $
+# $OpenLDAP: pkg/ldap/servers/slapd/back-perl/SampleLDAP.pm,v 1.8.2.4 2007/06/18 13:31:06 hallvard Exp $
## This work is part of OpenLDAP Software <http://www.openldap.org/>.
##
## Copyright 1998-2007 The OpenLDAP Foundation.
@@ -18,8 +18,10 @@
#
# database perl
# suffix "o=AnyOrg,c=US"
-# perlModulePath /path/to/this/file
+# perlModulePath /directory/containing/this/module
# perlModule SampleLDAP
+#
+# See the slapd-perl(5) manual page for details.
package SampleLDAP;
Modified: openldap/vendor/openldap-release/servers/slapd/back-relay/config.c
===================================================================
--- openldap/vendor/openldap-release/servers/slapd/back-relay/config.c 2007-09-15 10:30:38 UTC (rev 843)
+++ openldap/vendor/openldap-release/servers/slapd/back-relay/config.c 2007-09-15 10:38:52 UTC (rev 844)
@@ -48,85 +48,134 @@
int rc;
BackendDB *bd;
- if ( argc < 2 ) {
- fprintf( stderr,
- "%s: line %d: missing relay suffix in \"relay <dn> [massage]\" line\n",
- fname, lineno );
+ if ( !BER_BVISNULL( &ri->ri_realsuffix ) ) {
+ Debug( LDAP_DEBUG_ANY,
+ "%s: line %d: "
+ "relay dn already specified.\n",
+ fname, lineno, 0 );
return 1;
+ }
- } else if ( argc > 3 ) {
- fprintf( stderr,
- "%s: line %d: too many args in \"relay <dn> [massage]\" line\n",
- fname, lineno );
+ switch ( argc ) {
+ case 3:
+ if ( strcmp( argv[ 2 ], "massage" ) != 0 ) {
+ Debug( LDAP_DEBUG_ANY,
+ "%s: line %d: "
+ "unknown arg[#2]=\"%s\" "
+ "in \"relay <dn> [massage]\" line\n",
+ fname, lineno, argv[ 2 ] );
+ return 1;
+ }
+
+ if ( be->be_nsuffix == NULL ) {
+ Debug( LDAP_DEBUG_ANY,
+ "%s: line %d: "
+ "\"relay\" directive "
+ "must appear after \"suffix\".\n",
+ fname, lineno, 0 );
+ return 1;
+ }
+
+ if ( !BER_BVISNULL( &be->be_nsuffix[ 1 ] ) ) {
+ Debug( LDAP_DEBUG_ANY,
+ "%s: line %d: "
+ "relaying of multiple suffix "
+ "database not supported.\n",
+ fname, lineno, 0 );
+ return 1;
+ }
+ /* fallthru */
+
+ case 2:
+ break;
+
+ case 1:
+ Debug( LDAP_DEBUG_ANY,
+ "%s: line %d: missing relay suffix "
+ "in \"relay <dn> [massage]\" line.\n",
+ fname, lineno, 0 );
return 1;
+
+ default:
+ Debug( LDAP_DEBUG_ANY,
+ "%s: line %d: extra cruft "
+ "in \"relay <dn> [massage]\" line.\n",
+ fname, lineno, 0 );
+ return 1;
}
+ /* The man page says that the "relay" directive
+ * automatically instantiates slapo-rwm; I don't
+ * like this very much any more, I'd prefer to
+ * have automatic instantiation only when "massage"
+ * is specified, so one has better control on
+ * where the overlay gets instantiated, but this
+ * would break compatibility. One can still control
+ * where the overlay is instantiated by moving
+ * around the "relay" directive, although this could
+ * make slapd.conf a bit confusing. */
+ if ( overlay_config( be, "rwm" ) ) {
+ Debug( LDAP_DEBUG_ANY,
+ "%s: line %d: unable to install "
+ "rwm overlay "
+ "in \"relay <dn> [massage]\" line\n",
+ fname, lineno, 0 );
+ return 1;
+ }
+
dn.bv_val = argv[ 1 ];
dn.bv_len = strlen( argv[ 1 ] );
rc = dnPrettyNormal( NULL, &dn, &pdn, &ndn, NULL );
if ( rc != LDAP_SUCCESS ) {
- fprintf( stderr, "%s: line %d: "
- "relay dn \"%s\" is invalid "
- "in \"relay <dn> [massage]\" line\n",
- fname, lineno, argv[ 1 ] );
+ Debug( LDAP_DEBUG_ANY,
+ "%s: line %d: "
+ "relay dn \"%s\" is invalid "
+ "in \"relay <dn> [massage]\" line\n",
+ fname, lineno, argv[ 1 ] );
return 1;
}
bd = select_backend( &ndn, 0, 1 );
if ( bd == NULL ) {
- fprintf( stderr, "%s: line %d: "
- "cannot find database "
- "of relay dn \"%s\" "
- "in \"relay <dn> [massage]\" line\n",
- fname, lineno, argv[ 1 ] );
- return 1;
+ Debug( LDAP_DEBUG_ANY,
+ "%s: line %d: "
+ "cannot find database "
+ "of relay dn \"%s\" "
+ "in \"relay <dn> [massage]\" line\n",
+ fname, lineno, argv[ 1 ] );
+ rc = 1;
+ goto relay_done;
- } else if ( bd == be ) {
- fprintf( stderr, "%s: line %d: "
- "relay dn \"%s\" would call self "
- "in \"relay <dn> [massage]\" line\n",
- fname, lineno, pdn.bv_val );
- return 1;
+ } else if ( bd->be_private == be->be_private ) {
+ Debug( LDAP_DEBUG_ANY,
+ "%s: line %d: "
+ "relay dn \"%s\" would call self "
+ "in \"relay <dn> [massage]\" line\n",
+ fname, lineno, pdn.bv_val );
+ rc = 1;
+ goto relay_done;
}
ri->ri_realsuffix = ndn;
- if ( overlay_config( be, "rwm" ) ) {
- fprintf( stderr, "%s: line %d: unable to install "
- "rwm overlay "
- "in \"relay <dn> [massage]\" line\n",
- fname, lineno );
- return 1;
- }
-
if ( argc == 3 ) {
char *cargv[ 4 ];
- if ( strcmp( argv[2], "massage" ) != 0 ) {
- fprintf( stderr, "%s: line %d: "
- "unknown directive \"%s\" "
- "in \"relay <dn> [massage]\" line\n",
- fname, lineno, argv[2] );
- return 1;
- }
-
cargv[ 0 ] = "rwm-suffixmassage";
cargv[ 1 ] = be->be_suffix[0].bv_val;
cargv[ 2 ] = pdn.bv_val;
cargv[ 3 ] = NULL;
- if ( be->be_config( be, fname, lineno, 3, cargv ) ) {
- return 1;
- }
+ rc = be->be_config( be, fname, lineno, 3, cargv );
}
+relay_done:;
ch_free( pdn.bv_val );
- /* anything else */
- } else {
- return SLAP_CONF_UNKNOWN;
+ return rc;
}
- return 0;
+ /* anything else */
+ return SLAP_CONF_UNKNOWN;
}
Modified: openldap/vendor/openldap-release/servers/slapd/back-relay/op.c
===================================================================
--- openldap/vendor/openldap-release/servers/slapd/back-relay/op.c 2007-09-15 10:30:38 UTC (rev 843)
+++ openldap/vendor/openldap-release/servers/slapd/back-relay/op.c 2007-09-15 10:38:52 UTC (rev 844)
@@ -60,7 +60,7 @@
relay_back_info *ri = (relay_back_info *)op->o_bd->be_private;
BackendDB *bd = ri->ri_bd;
- if ( bd == NULL ) {
+ if ( bd == NULL && !BER_BVISNULL( &op->o_req_ndn ) ) {
bd = select_backend( &op->o_req_ndn, 0, 1 );
if ( bd == op->o_bd ) {
if ( err > LDAP_SUCCESS ) {
@@ -140,9 +140,9 @@
BackendDB *bd;
int rc = 1;
- bd = ri->ri_bd;
+ bd = relay_back_select_backend( op, rs, -1 );
if ( bd == NULL ) {
- bd = select_backend( &op->o_req_ndn, 0, 1 );
+ return rc;
}
if ( bd && bd->be_unbind ) {
@@ -405,7 +405,7 @@
BackendDB *bd;
int rc = 1;
- bd = relay_back_select_backend( op, rs, LDAP_NO_SUCH_OBJECT );
+ bd = relay_back_select_backend( op, rs, LDAP_CANNOT_CANCEL );
if ( bd == NULL ) {
return 1;
}
Modified: openldap/vendor/openldap-release/servers/slapd/back-sql/entry-id.c
===================================================================
--- openldap/vendor/openldap-release/servers/slapd/back-sql/entry-id.c 2007-09-15 10:30:38 UTC (rev 843)
+++ openldap/vendor/openldap-release/servers/slapd/back-sql/entry-id.c 2007-09-15 10:38:52 UTC (rev 844)
@@ -1,4 +1,4 @@
-/* $OpenLDAP: pkg/ldap/servers/slapd/back-sql/entry-id.c,v 1.46.2.12 2007/01/02 21:44:07 kurt Exp $ */
+/* $OpenLDAP: pkg/ldap/servers/slapd/back-sql/entry-id.c,v 1.46.2.13 2007/08/11 07:39:30 ando Exp $ */
/* This work is part of OpenLDAP Software <http://www.openldap.org/>.
*
* Copyright 1999-2007 The OpenLDAP Foundation.
@@ -1002,12 +1002,14 @@
|| an_find( bsi->bsi_attrs, &AllOper )
|| an_find( bsi->bsi_attrs, &slap_schema.si_ad_structuralObjectClass->ad_cname ) )
{
+ ObjectClass *soc = NULL;
+
if ( BACKSQL_CHECK_SCHEMA( bi ) ) {
Attribute *a;
const char *text = NULL;
char textbuf[ 1024 ];
size_t textlen = sizeof( textbuf );
- struct berval soc,
+ struct berval soc_name,
bv[ 2 ],
*nvals;
int rc = LDAP_SUCCESS;
@@ -1023,7 +1025,7 @@
nvals = bv;
}
- rc = structural_class( nvals, &soc, NULL,
+ rc = structural_class( nvals, &soc_name, &soc,
&text, textbuf, textlen );
if ( rc != LDAP_SUCCESS ) {
Debug( LDAP_DEBUG_TRACE, "backsql_id2entry(%s): "
@@ -1034,21 +1036,33 @@
return rc;
}
- if ( !bvmatch( &soc, &bsi->bsi_oc->bom_oc->soc_cname ) ) {
+ if ( !bvmatch( &soc->soc_cname, &bsi->bsi_oc->bom_oc->soc_cname ) ) {
+ if ( !is_object_subclass( bsi->bsi_oc->bom_oc, soc ) ) {
+ Debug( LDAP_DEBUG_TRACE, "backsql_id2entry(%s): "
+ "computed structuralObjectClass %s "
+ "does not match objectClass %s associated "
+ "to entry\n",
+ bsi->bsi_e->e_name.bv_val, soc->soc_cname.bv_val,
+ bsi->bsi_oc->bom_oc->soc_cname.bv_val );
+ backsql_entry_clean( op, bsi->bsi_e );
+ return rc;
+ }
+
Debug( LDAP_DEBUG_TRACE, "backsql_id2entry(%s): "
"computed structuralObjectClass %s "
- "does not match objectClass %s associated "
+ "is subclass of objectClass %s associated "
"to entry\n",
- bsi->bsi_e->e_name.bv_val, soc.bv_val,
+ bsi->bsi_e->e_name.bv_val, soc->soc_cname.bv_val,
bsi->bsi_oc->bom_oc->soc_cname.bv_val );
- backsql_entry_clean( op, bsi->bsi_e );
- return rc;
}
+
+ } else {
+ soc = bsi->bsi_oc->bom_oc;
}
rc = attr_merge_normalize_one( bsi->bsi_e,
slap_schema.si_ad_structuralObjectClass,
- &bsi->bsi_oc->bom_oc->soc_cname,
+ &soc->soc_cname,
bsi->bsi_op->o_tmpmemctx );
if ( rc != LDAP_SUCCESS ) {
backsql_entry_clean( op, bsi->bsi_e );
Modified: openldap/vendor/openldap-release/servers/slapd/backend.c
===================================================================
--- openldap/vendor/openldap-release/servers/slapd/backend.c 2007-09-15 10:30:38 UTC (rev 843)
+++ openldap/vendor/openldap-release/servers/slapd/backend.c 2007-09-15 10:38:52 UTC (rev 844)
@@ -1,5 +1,5 @@
/* backend.c - routines for dealing with back-end databases */
-/* $OpenLDAP: pkg/ldap/servers/slapd/backend.c,v 1.288.2.25 2007/01/02 21:43:54 kurt Exp $ */
+/* $OpenLDAP: pkg/ldap/servers/slapd/backend.c,v 1.288.2.26 2007/07/22 15:04:25 hyc Exp $ */
/* This work is part of OpenLDAP Software <http://www.openldap.org/>.
*
* Copyright 1998-2007 The OpenLDAP Foundation.
@@ -573,12 +573,12 @@
Backend *
select_backend(
struct berval * dn,
- int manageDSAit,
+ int manageDSAit, /* unused since ITS#4986 */
int noSubs )
{
int j;
ber_len_t len, dnlen = dn->bv_len;
- Backend *be, *b2 = NULL;
+ Backend *be;
LDAP_STAILQ_FOREACH( be, &backendDB, be_next ) {
if ( be->be_nsuffix == NULL ) {
@@ -612,28 +612,12 @@
if ( strcmp( be->be_nsuffix[j].bv_val,
&dn->bv_val[dnlen-len] ) == 0 )
{
- if( b2 == NULL ) {
- b2 = be;
-
- if( manageDSAit && len == dnlen &&
- !SLAP_GLUE_SUBORDINATE( be ) ) {
- continue;
- }
- } else {
- /* If any parts of the tree are glued, use the first
- * match regardless of manageDSAit. Otherwise use the
- * last match.
- */
- if( !( SLAP_DBFLAGS( be ) & ( SLAP_DBFLAG_GLUE_INSTANCE |
- SLAP_DBFLAG_GLUE_SUBORDINATE )))
- b2 = be;
- }
- return b2;
+ return be;
}
}
}
- return b2;
+ return be;
}
int
Modified: openldap/vendor/openldap-release/servers/slapd/backglue.c
===================================================================
--- openldap/vendor/openldap-release/servers/slapd/backglue.c 2007-09-15 10:30:38 UTC (rev 843)
+++ openldap/vendor/openldap-release/servers/slapd/backglue.c 2007-09-15 10:38:52 UTC (rev 844)
@@ -1,5 +1,5 @@
/* backglue.c - backend glue */
-/* $OpenLDAP: pkg/ldap/servers/slapd/backglue.c,v 1.91.2.17 2007/01/03 08:55:03 hyc Exp $ */
+/* $OpenLDAP: pkg/ldap/servers/slapd/backglue.c,v 1.91.2.18 2007/07/12 00:36:36 hyc Exp $ */
/* This work is part of OpenLDAP Software <http://www.openldap.org/>.
*
* Copyright 2001-2007 The OpenLDAP Foundation.
@@ -611,19 +611,38 @@
}
static int
+glue_entry_get_rw (
+ Operation *op,
+ struct berval *dn,
+ ObjectClass *oc,
+ AttributeDescription *ad,
+ int rw,
+ Entry **e )
+{
+ BackendDB *b0 = op->o_bd;
+ op->o_bd = glue_back_select( b0, dn );
+ int rc;
+
+ if ( op->o_bd->be_fetch ) {
+ rc = op->o_bd->be_fetch( op, dn, oc, ad, rw, e );
+ } else {
+ rc = LDAP_UNWILLING_TO_PERFORM;
+ }
+ op->o_bd =b0;
+ return rc;
+}
+
+static int
glue_entry_release_rw (
Operation *op,
Entry *e,
int rw
)
{
- BackendDB *b0, b2;
+ BackendDB *b0 = op->o_bd;
int rc = -1;
- b0 = op->o_bd;
- b2 = *op->o_bd;
- b2.bd_info = (BackendInfo *)glue_tool_inst( op->o_bd->bd_info );
- op->o_bd = glue_back_select (&b2, &e->e_nname);
+ op->o_bd = glue_back_select (b0, &e->e_nname);
if ( op->o_bd->be_release ) {
rc = op->o_bd->be_release( op, e, rw );
@@ -819,8 +838,6 @@
oi->oi_bi.bi_open = glue_open;
oi->oi_bi.bi_close = glue_close;
- oi->oi_bi.bi_entry_release_rw = glue_entry_release_rw;
-
/* Only advertise these if the root DB supports them */
if ( bi->bi_tool_entry_open )
oi->oi_bi.bi_tool_entry_open = glue_tool_entry_open;
@@ -1033,6 +1050,9 @@
glue.on_bi.bi_chk_referrals = glue_chk_referrals;
glue.on_bi.bi_chk_controls = glue_chk_controls;
+ glue.on_bi.bi_entry_get_rw = glue_entry_get_rw;
+ glue.on_bi.bi_entry_release_rw = glue_entry_release_rw;
+
glue.on_response = glue_response;
return overlay_register( &glue );
Modified: openldap/vendor/openldap-release/servers/slapd/backover.c
===================================================================
--- openldap/vendor/openldap-release/servers/slapd/backover.c 2007-09-15 10:30:38 UTC (rev 843)
+++ openldap/vendor/openldap-release/servers/slapd/backover.c 2007-09-15 10:38:52 UTC (rev 844)
@@ -1,5 +1,5 @@
/* backover.c - backend overlay routines */
-/* $OpenLDAP: pkg/ldap/servers/slapd/backover.c,v 1.31.2.20 2007/01/02 21:43:54 kurt Exp $ */
+/* $OpenLDAP: pkg/ldap/servers/slapd/backover.c,v 1.31.2.22 2007/07/12 00:42:42 hyc Exp $ */
/* This work is part of OpenLDAP Software <http://www.openldap.org/>.
*
* Copyright 2003-2007 The OpenLDAP Foundation.
@@ -246,6 +246,147 @@
return rc;
}
+int
+overlay_entry_get_ov(
+ Operation *op,
+ struct berval *dn,
+ ObjectClass *oc,
+ AttributeDescription *ad,
+ int rw,
+ Entry **e,
+ slap_overinst *on )
+{
+ slap_overinfo *oi = on->on_info;
+ BackendDB *be = op->o_bd, db;
+ BackendInfo *bi = op->o_bd->bd_info;
+ int rc = SLAP_CB_CONTINUE;
+
+ for ( ; on; on = on->on_next ) {
+ if ( on->on_bi.bi_entry_get_rw ) {
+ /* NOTE: do not copy the structure until required */
+ if ( !SLAP_ISOVERLAY( op->o_bd ) ) {
+ db = *op->o_bd;
+ db.be_flags |= SLAP_DBFLAG_OVERLAY;
+ op->o_bd = &db;
+ }
+
+ op->o_bd->bd_info = (BackendInfo *)on;
+ rc = on->on_bi.bi_entry_get_rw( op, dn,
+ oc, ad, rw, e );
+ if ( rc != SLAP_CB_CONTINUE ) break;
+ }
+ }
+
+ if ( rc == SLAP_CB_CONTINUE ) {
+ /* if the database structure was changed, o_bd points to a
+ * copy of the structure; put the original bd_info in place */
+ if ( SLAP_ISOVERLAY( op->o_bd ) ) {
+ op->o_bd->bd_info = oi->oi_orig;
+ }
+
+ if ( oi->oi_orig->bi_entry_get_rw ) {
+ rc = oi->oi_orig->bi_entry_get_rw( op, dn,
+ oc, ad, rw, e );
+ }
+ }
+ /* should not fall thru this far without anything happening... */
+ if ( rc == SLAP_CB_CONTINUE ) {
+ rc = LDAP_UNWILLING_TO_PERFORM;
+ }
+
+ op->o_bd = be;
+ op->o_bd->bd_info = bi;
+
+ return rc;
+}
+
+static int
+over_entry_get_rw(
+ Operation *op,
+ struct berval *dn,
+ ObjectClass *oc,
+ AttributeDescription *ad,
+ int rw,
+ Entry **e )
+{
+ slap_overinfo *oi;
+ slap_overinst *on;
+
+ assert( op->o_bd != NULL );
+
+ oi = op->o_bd->bd_info->bi_private;
+ on = oi->oi_list;
+
+ return overlay_entry_get_ov( op, dn, oc, ad, rw, e, on );
+}
+
+int
+overlay_entry_release_ov(
+ Operation *op,
+ Entry *e,
+ int rw,
+ slap_overinst *on )
+{
+ slap_overinfo *oi = on->on_info;
+ BackendDB *be = op->o_bd, db;
+ BackendInfo *bi = op->o_bd->bd_info;
+ int rc = SLAP_CB_CONTINUE;
+
+ for ( ; on; on = on->on_next ) {
+ if ( on->on_bi.bi_entry_release_rw ) {
+ /* NOTE: do not copy the structure until required */
+ if ( !SLAP_ISOVERLAY( op->o_bd ) ) {
+ db = *op->o_bd;
+ db.be_flags |= SLAP_DBFLAG_OVERLAY;
+ op->o_bd = &db;
+ }
+
+ op->o_bd->bd_info = (BackendInfo *)on;
+ rc = on->on_bi.bi_entry_release_rw( op, e, rw );
+ if ( rc != SLAP_CB_CONTINUE ) break;
+ }
+ }
+
+ if ( rc == SLAP_CB_CONTINUE ) {
+ /* if the database structure was changed, o_bd points to a
+ * copy of the structure; put the original bd_info in place */
+ if ( SLAP_ISOVERLAY( op->o_bd ) ) {
+ op->o_bd->bd_info = oi->oi_orig;
+ }
+
+ if ( oi->oi_orig->bi_entry_release_rw ) {
+ rc = oi->oi_orig->bi_entry_release_rw( op, e, rw );
+ }
+ }
+ /* should not fall thru this far without anything happening... */
+ if ( rc == SLAP_CB_CONTINUE ) {
+ entry_free( e );
+ rc = 0;
+ }
+
+ op->o_bd = be;
+ op->o_bd->bd_info = bi;
+
+ return rc;
+}
+
+static int
+over_entry_release_rw(
+ Operation *op,
+ Entry *e,
+ int rw )
+{
+ slap_overinfo *oi;
+ slap_overinst *on;
+
+ assert( op->o_bd != NULL );
+
+ oi = op->o_bd->bd_info->bi_private;
+ on = oi->oi_list;
+
+ return overlay_entry_release_ov( op, e, rw, on );
+}
+
#ifdef SLAP_OVERLAY_ACCESS
static int
over_access_allowed(
@@ -930,8 +1071,10 @@
bi->bi_chk_referrals = over_aux_chk_referrals;
bi->bi_chk_controls = over_aux_chk_controls;
+ /* these have specific arglists */
+ bi->bi_entry_get_rw = over_entry_get_rw;
+ bi->bi_entry_release_rw = over_entry_release_rw;
#ifdef SLAP_OVERLAY_ACCESS
- /* these have specific arglists */
bi->bi_access_allowed = over_access_allowed;
bi->bi_acl_group = over_acl_group;
bi->bi_acl_attribute = over_acl_attribute;
Modified: openldap/vendor/openldap-release/servers/slapd/bconfig.c
===================================================================
--- openldap/vendor/openldap-release/servers/slapd/bconfig.c 2007-09-15 10:30:38 UTC (rev 843)
+++ openldap/vendor/openldap-release/servers/slapd/bconfig.c 2007-09-15 10:38:52 UTC (rev 844)
@@ -1,5 +1,5 @@
/* bconfig.c - the config backend */
-/* $OpenLDAP: pkg/ldap/servers/slapd/bconfig.c,v 1.17.2.49 2007/01/02 21:43:54 kurt Exp $ */
+/* $OpenLDAP: pkg/ldap/servers/slapd/bconfig.c,v 1.17.2.53 2007/07/23 19:41:30 hallvard Exp $ */
/* This work is part of OpenLDAP Software <http://www.openldap.org/>.
*
* Copyright 2005-2007 The OpenLDAP Foundation.
@@ -349,7 +349,7 @@
"SYNTAX OMsInteger SINGLE-VALUE )", NULL, NULL },
{ "moduleload", "file", 2, 0, 0,
#ifdef SLAPD_MODULES
- ARG_MAGIC|CFG_MODLOAD, &config_generic,
+ ARG_MAGIC|CFG_MODLOAD|ARG_NO_DELETE, &config_generic,
#else
ARG_IGNORED, NULL,
#endif
@@ -2102,8 +2102,7 @@
slap_loglevel_get( struct berval *s, int *l )
{
int rc;
- unsigned long i;
- slap_mask_t m;
+ slap_mask_t m, i;
if ( loglevel_ops == NULL ) {
loglevel_init();
@@ -2113,12 +2112,10 @@
m |= loglevel_ops[ i ].mask;
}
- m = ~m;
-
- for ( i = 1; i <= ( 1 << ( sizeof( int ) * 8 - 1 ) ) && !( m & i ); i <<= 1 )
+ for ( i = 1; m & i; i <<= 1 )
;
- if ( !( m & i ) ) {
+ if ( i == 0 ) {
return -1;
}
@@ -2216,8 +2213,6 @@
return 0;
}
- config_syslog = 0;
-
for( i=1; i < c->argc; i++ ) {
int level;
@@ -2236,7 +2231,11 @@
return( 1 );
}
}
- config_syslog |= level;
+ /* Explicitly setting a zero clears all the levels */
+ if ( level )
+ config_syslog |= level;
+ else
+ config_syslog = 0;
}
if ( slapMode & SLAP_SERVER_MODE ) {
ldap_syslog = config_syslog;
@@ -4284,7 +4283,10 @@
struct berval bv;
for (; cf; cf=cf->c_sibs, c->depth++) {
+ if ( !cf->c_at_head && !cf->c_cr_head && !cf->c_oc_head &&
+ !cf->c_om_head ) continue;
c->value_dn.bv_val = c->log;
+ LUTIL_SLASHPATH( cf->c_file.bv_val );
bv.bv_val = strrchr(cf->c_file.bv_val, LDAP_DIRSEP[0]);
if ( !bv.bv_val ) {
bv = cf->c_file;
Modified: openldap/vendor/openldap-release/servers/slapd/connection.c
===================================================================
--- openldap/vendor/openldap-release/servers/slapd/connection.c 2007-09-15 10:30:38 UTC (rev 843)
+++ openldap/vendor/openldap-release/servers/slapd/connection.c 2007-09-15 10:38:52 UTC (rev 844)
@@ -1,4 +1,4 @@
-/* $OpenLDAP: pkg/ldap/servers/slapd/connection.c,v 1.296.2.29 2007/01/25 12:52:48 hyc Exp $ */
+/* $OpenLDAP: pkg/ldap/servers/slapd/connection.c,v 1.296.2.30 2007/06/14 23:49:38 quanah Exp $ */
/* This work is part of OpenLDAP Software <http://www.openldap.org/>.
*
* Copyright 1998-2007 The OpenLDAP Foundation.
@@ -1805,13 +1805,14 @@
/* log authorization identity */
Statslog( LDAP_DEBUG_STATS,
- "%s BIND dn=\"%s\" mech=%s ssf=%d\n",
+ "%s BIND dn=\"%s\" mech=%s sasl_ssf=%d ssf=%d\n",
op->o_log_prefix,
BER_BVISNULL( &op->o_conn->c_dn ) ? "<empty>" : op->o_conn->c_dn.bv_val,
- op->o_conn->c_authmech.bv_val, op->orb_ssf, 0 );
+ op->o_conn->c_authmech.bv_val,
+ op->orb_ssf, op->o_conn->c_ssf );
Debug( LDAP_DEBUG_TRACE,
- "do_bind: SASL/%s bind: dn=\"%s\" ssf=%d\n",
+ "do_bind: SASL/%s bind: dn=\"%s\" sasl_ssf=%d\n",
op->o_conn->c_authmech.bv_val,
BER_BVISNULL( &op->o_conn->c_dn ) ? "<empty>" : op->o_conn->c_dn.bv_val,
op->orb_ssf );
Modified: openldap/vendor/openldap-release/servers/slapd/daemon.c
===================================================================
--- openldap/vendor/openldap-release/servers/slapd/daemon.c 2007-09-15 10:30:38 UTC (rev 843)
+++ openldap/vendor/openldap-release/servers/slapd/daemon.c 2007-09-15 10:38:52 UTC (rev 844)
@@ -1,4 +1,4 @@
-/* $OpenLDAP: pkg/ldap/servers/slapd/daemon.c,v 1.318.2.30 2007/04/01 21:30:02 quanah Exp $ */
+/* $OpenLDAP: pkg/ldap/servers/slapd/daemon.c,v 1.318.2.32 2007/07/23 20:34:28 hallvard Exp $ */
/* This work is part of OpenLDAP Software <http://www.openldap.org/>.
*
* Copyright 1998-2007 The OpenLDAP Foundation.
@@ -227,7 +227,8 @@
(int *)(ptr) <= &slap_daemon.sd_index[dtblsize]) ? 0 : 1 )
# define SLAP_EPOLL_EV_PTRFD(ptr) (SLAP_EPOLL_EV_LISTENER(ptr) ? \
- ((Listener *)ptr)->sl_sd : (int *)(ptr) - slap_daemon.sd_index)
+ ((Listener *)ptr)->sl_sd : \
+ (ber_socket_t) ((int *)(ptr) - slap_daemon.sd_index))
# define SLAP_SOCK_DEL(s) do { \
int fd, rc, index = SLAP_EPOLL_SOCK_IX((s)); \
@@ -1582,7 +1583,7 @@
Sockaddr from;
ber_socket_t s;
- socklen_t len = sizeof(from);
+ ber_socklen_t len = sizeof(from);
long id;
slap_ssf_t ssf = 0;
struct berval authid = BER_BVNULL;
Modified: openldap/vendor/openldap-release/servers/slapd/dn.c
===================================================================
--- openldap/vendor/openldap-release/servers/slapd/dn.c 2007-09-15 10:30:38 UTC (rev 843)
+++ openldap/vendor/openldap-release/servers/slapd/dn.c 2007-09-15 10:38:52 UTC (rev 844)
@@ -1,5 +1,5 @@
/* dn.c - routines for dealing with distinguished names */
-/* $OpenLDAP: pkg/ldap/servers/slapd/dn.c,v 1.170.2.10 2007/01/02 21:43:55 kurt Exp $ */
+/* $OpenLDAP: pkg/ldap/servers/slapd/dn.c,v 1.170.2.12 2007/08/04 20:35:38 hyc Exp $ */
/* This work is part of OpenLDAP Software <http://www.openldap.org/>.
*
* Copyright 1998-2007 The OpenLDAP Foundation.
@@ -262,81 +262,62 @@
* Note: the sorting can be slightly improved by sorting first
* by attribute type length, then by alphabetical order.
*
- * uses a linear search; should be fine since the number of AVAs in
+ * uses an insertion sort; should be fine since the number of AVAs in
* a RDN should be limited.
*/
-static void
-AVA_Sort( LDAPRDN rdn, int iAVA )
+static int
+AVA_Sort( LDAPRDN rdn, int nAVAs )
{
+ LDAPAVA *ava_i;
int i;
- LDAPAVA *ava_in = rdn[ iAVA ];
assert( rdn != NULL );
- assert( ava_in != NULL );
-
- for ( i = 0; i < iAVA; i++ ) {
- LDAPAVA *ava = rdn[ i ];
- int a, j;
- assert( ava != NULL );
+ for ( i = 1; i < nAVAs; i++ ) {
+ LDAPAVA *ava_j;
+ int j;
- a = strcmp( ava_in->la_attr.bv_val, ava->la_attr.bv_val );
+ ava_i = rdn[ i ];
+ for ( j = i-1; j >=0; j-- ) {
+ int a;
- if ( a > 0 ) {
- break;
- }
+ ava_j = rdn[ j ];
+ a = strcmp( ava_i->la_attr.bv_val, ava_j->la_attr.bv_val );
- while ( a == 0 ) {
- int v, d;
+ if ( a == 0 ) {
+ int d;
- d = ava_in->la_value.bv_len - ava->la_value.bv_len;
+ d = ava_i->la_value.bv_len - ava_j->la_value.bv_len;
- v = memcmp( ava_in->la_value.bv_val,
- ava->la_value.bv_val,
- d <= 0 ? ava_in->la_value.bv_len
- : ava->la_value.bv_len );
+ a = memcmp( ava_i->la_value.bv_val,
+ ava_j->la_value.bv_val,
+ d <= 0 ? ava_i->la_value.bv_len
+ : ava_j->la_value.bv_len );
- if ( v == 0 && d != 0 ) {
- v = d;
+ if ( a == 0 ) {
+ a = d;
+ }
}
+ /* Duplicates are not allowed */
+ if ( a == 0 )
+ return LDAP_INVALID_DN_SYNTAX;
- if ( v <= 0 ) {
- /*
- * got it!
- */
+ if ( a > 0 )
break;
- }
- if ( ++i == iAVA ) {
- /*
- * already sorted
- */
- return;
- }
-
- ava = rdn[ i ];
- a = strcmp( ava_in->la_attr.bv_val,
- ava->la_attr.bv_val );
+ rdn[ j+1 ] = rdn[ j ];
}
-
- /*
- * move ahead
- */
- for ( j = iAVA; j > i; j-- ) {
- rdn[ j ] = rdn[ j - 1 ];
- }
- rdn[ i ] = ava_in;
-
- return;
+ rdn[ j+1 ] = ava_i;
}
+ return LDAP_SUCCESS;
}
static int
LDAPRDN_rewrite( LDAPRDN rdn, unsigned flags, void *ctx )
{
- int rc;
- int iAVA;
+ int rc, iAVA, do_sort = 0;
+
for ( iAVA = 0; rdn[ iAVA ]; iAVA++ ) {
LDAPAVA *ava = rdn[ iAVA ];
AttributeDescription *ad;
@@ -345,7 +326,6 @@
slap_syntax_transform_func *transf = NULL;
MatchingRule *mr = NULL;
struct berval bv = BER_BVNULL;
- int do_sort = 0;
assert( ava != NULL );
@@ -445,10 +425,14 @@
ava->la_value = bv;
ava->la_flags |= LDAP_AVA_FREE_VALUE;
}
+ }
+ rc = LDAP_SUCCESS;
- if( do_sort ) AVA_Sort( rdn, iAVA );
+ if ( do_sort ) {
+ rc = AVA_Sort( rdn, iAVA );
}
- return LDAP_SUCCESS;
+
+ return rc;
}
/*
@@ -458,7 +442,7 @@
static int
LDAPDN_rewrite( LDAPDN dn, unsigned flags, void *ctx )
{
- int iRDN;
+ int iRDN, do_sort = 0;
int rc;
assert( dn != NULL );
@@ -477,7 +461,6 @@
slap_syntax_transform_func *transf = NULL;
MatchingRule *mr = NULL;
struct berval bv = BER_BVNULL;
- int do_sort = 0;
assert( ava != NULL );
@@ -578,10 +561,13 @@
ava->la_flags |= LDAP_AVA_FREE_VALUE;
}
- if( do_sort ) AVA_Sort( rdn, iAVA );
}
+ if( do_sort ) {
+ rc = AVA_Sort( rdn, iAVA );
+ if ( rc != LDAP_SUCCESS )
+ return rc;
+ }
}
-
return LDAP_SUCCESS;
}
Modified: openldap/vendor/openldap-release/servers/slapd/entry.c
===================================================================
--- openldap/vendor/openldap-release/servers/slapd/entry.c 2007-09-15 10:30:38 UTC (rev 843)
+++ openldap/vendor/openldap-release/servers/slapd/entry.c 2007-09-15 10:38:52 UTC (rev 844)
@@ -1,5 +1,5 @@
/* entry.c - routines for dealing with entries */
-/* $OpenLDAP: pkg/ldap/servers/slapd/entry.c,v 1.129.2.13 2007/02/26 08:53:54 ando Exp $ */
+/* $OpenLDAP: pkg/ldap/servers/slapd/entry.c,v 1.129.2.15 2007/08/13 17:35:03 ando Exp $ */
/* This work is part of OpenLDAP Software <http://www.openldap.org/>.
*
* Copyright 1998-2007 The OpenLDAP Foundation.
@@ -231,6 +231,16 @@
goto fail;
}
}
+
+ /* require ';binary' when appropriate (ITS#5071) */
+ if ( slap_syntax_is_binary( ad->ad_type->sat_syntax ) && !slap_ad_is_binary( ad ) ) {
+ Debug( LDAP_DEBUG_ANY,
+ "str2entry: attributeType %s #%d: "
+ "needs ';binary' transfer as per syntax %s\n",
+ ad->ad_cname.bv_val, 0,
+ ad->ad_type->sat_syntax->ssyn_oid );
+ goto fail;
+ }
}
if (( ad_prev && ad != ad_prev ) || ( i == lines )) {
@@ -268,6 +278,14 @@
if ( i == lines ) break;
}
+ if ( BER_BVISNULL( &vals[i] ) ) {
+ Debug( LDAP_DEBUG_ANY,
+ "str2entry: attributeType %s #%d: "
+ "no values\n",
+ ad->ad_cname.bv_val, attr_cnt, 0 );
+ goto fail;
+ }
+
if( slapMode & SLAP_TOOL_MODE ) {
struct berval pval;
slap_syntax_validate_func *validate =
Modified: openldap/vendor/openldap-release/servers/slapd/init.c
===================================================================
--- openldap/vendor/openldap-release/servers/slapd/init.c 2007-09-15 10:30:38 UTC (rev 843)
+++ openldap/vendor/openldap-release/servers/slapd/init.c 2007-09-15 10:38:52 UTC (rev 844)
@@ -1,5 +1,5 @@
/* init.c - initialize various things */
-/* $OpenLDAP: pkg/ldap/servers/slapd/init.c,v 1.81.2.16 2007/01/25 12:42:38 hyc Exp $ */
+/* $OpenLDAP: pkg/ldap/servers/slapd/init.c,v 1.81.2.17 2007/06/12 23:46:44 hyc Exp $ */
/* This work is part of OpenLDAP Software <http://www.openldap.org/>.
*
* Copyright 1998-2007 The OpenLDAP Foundation.
@@ -104,6 +104,8 @@
slapMode = mode;
+ slap_op_init();
+
#ifdef SLAPD_MODULES
if ( module_init() != 0 ) {
ldap_debug |= 1;
@@ -339,8 +341,10 @@
}
+ slap_op_destroy();
+
ldap_pvt_thread_destroy();
- /* should destory the above mutex */
+ /* should destroy the above mutex */
return rc;
}
Modified: openldap/vendor/openldap-release/servers/slapd/main.c
===================================================================
--- openldap/vendor/openldap-release/servers/slapd/main.c 2007-09-15 10:30:38 UTC (rev 843)
+++ openldap/vendor/openldap-release/servers/slapd/main.c 2007-09-15 10:38:52 UTC (rev 844)
@@ -1,4 +1,4 @@
-/* $OpenLDAP: pkg/ldap/servers/slapd/main.c,v 1.198.2.22 2007/01/25 12:42:38 hyc Exp $ */
+/* $OpenLDAP: pkg/ldap/servers/slapd/main.c,v 1.198.2.23 2007/06/12 23:46:44 hyc Exp $ */
/* This work is part of OpenLDAP Software <http://www.openldap.org/>.
*
* Copyright 1998-2007 The OpenLDAP Foundation.
@@ -656,7 +656,6 @@
extops_init();
lutil_passwd_init();
- slap_op_init();
rc = slap_init( serverMode, serverName );
if ( rc ) {
@@ -883,8 +882,6 @@
module_kill();
#endif
- slap_op_destroy();
-
extops_kill();
stop:
Modified: openldap/vendor/openldap-release/servers/slapd/overlays/Makefile.in
===================================================================
--- openldap/vendor/openldap-release/servers/slapd/overlays/Makefile.in 2007-09-15 10:30:38 UTC (rev 843)
+++ openldap/vendor/openldap-release/servers/slapd/overlays/Makefile.in 2007-09-15 10:38:52 UTC (rev 844)
@@ -1,5 +1,5 @@
# Makefile.in for overlays
-# $OpenLDAP: pkg/ldap/servers/slapd/overlays/Makefile.in,v 1.16.2.16 2007/01/02 21:44:08 kurt Exp $
+# $OpenLDAP: pkg/ldap/servers/slapd/overlays/Makefile.in,v 1.16.2.17 2007/05/29 21:57:47 hallvard Exp $
## This work is part of OpenLDAP Software <http://www.openldap.org/>.
##
## Copyright 2003-2007 The OpenLDAP Foundation.
@@ -29,9 +29,9 @@
translucent.c \
unique.c \
valsort.c
-OBJS = overlays.o \
- statover.o \
- @SLAPD_STATIC_OVERLAYS@
+OBJS = statover.o \
+ @SLAPD_STATIC_OVERLAYS@ \
+ overlays.o
# Add here the objs that are needed by overlays, but do not make it
# into SLAPD_STATIC_OVERLAYS...
Modified: openldap/vendor/openldap-release/servers/slapd/overlays/dynlist.c
===================================================================
--- openldap/vendor/openldap-release/servers/slapd/overlays/dynlist.c 2007-09-15 10:30:38 UTC (rev 843)
+++ openldap/vendor/openldap-release/servers/slapd/overlays/dynlist.c 2007-09-15 10:38:52 UTC (rev 844)
@@ -1,5 +1,5 @@
/* dynlist.c - dynamic list overlay */
-/* $OpenLDAP: pkg/ldap/servers/slapd/overlays/dynlist.c,v 1.5.2.11 2007/03/22 21:31:18 ando Exp $ */
+/* $OpenLDAP: pkg/ldap/servers/slapd/overlays/dynlist.c,v 1.5.2.12 2007/06/04 21:14:22 ando Exp $ */
/* This work is part of OpenLDAP Software <http://www.openldap.org/>.
*
* Copyright 2003-2007 The OpenLDAP Foundation.
@@ -67,13 +67,20 @@
} dynlist_info_t;
static dynlist_info_t *
-dynlist_is_dynlist( Operation *op, SlapReply *rs )
+dynlist_is_dynlist_next( Operation *op, SlapReply *rs, dynlist_info_t *old_dli )
{
slap_overinst *on = (slap_overinst *)op->o_bd->bd_info;
- dynlist_info_t *dli = (dynlist_info_t *)on->on_bi.bi_private;
+ dynlist_info_t *dli;
Attribute *a;
+ if ( old_dli == NULL ) {
+ dli = (dynlist_info_t *)on->on_bi.bi_private;
+
+ } else {
+ dli = old_dli->dli_next;
+ }
+
a = attrs_find( rs->sr_entry->e_attrs, slap_schema.si_ad_objectClass );
if ( a == NULL ) {
/* FIXME: objectClass must be present; for non-storage
@@ -198,7 +205,8 @@
for ( a = rs->sr_entry->e_attrs; a != NULL; a = a->a_next ) {
BerVarray vals, nvals = NULL;
- int i, j;
+ int i, j,
+ is_oc = a->a_desc == slap_schema.si_ad_objectClass;
/* if attribute is not requested, skip it */
if ( rs->sr_attrs == NULL ) {
@@ -247,6 +255,14 @@
}
for ( i = 0, j = 0; !BER_BVISNULL( &a->a_vals[i] ); i++ ) {
+ if ( is_oc ) {
+ ObjectClass *soc = oc_bvfind( &a->a_vals[i] );
+
+ if ( soc->soc_kind == LDAP_SCHEMA_STRUCTURAL ) {
+ continue;
+ }
+ }
+
if ( access_allowed( op, rs->sr_entry, a->a_desc,
&a->a_nvals[i], ACL_READ, &acl_state ) )
{
@@ -297,7 +313,7 @@
}
static int
-dynlist_send_entry( Operation *op, SlapReply *rs, dynlist_info_t *dli )
+dynlist_prepare_entry( Operation *op, SlapReply *rs, dynlist_info_t *dli )
{
Attribute *a;
slap_callback cb;
@@ -316,7 +332,11 @@
return SLAP_CB_CONTINUE;
}
- e = entry_dup( rs->sr_entry );
+ if ( !( rs->sr_flags & REP_ENTRY_MODIFIABLE ) ) {
+ e = entry_dup( rs->sr_entry );
+ } else {
+ e = rs->sr_entry;
+ }
e_flags = rs->sr_flags | ( REP_ENTRY_MODIFIABLE | REP_ENTRY_MUSTBEFREED );
dlc.dlc_e = e;
@@ -359,7 +379,7 @@
if ( lud->lud_host != NULL ) {
/* FIXME: host not allowed; reject as illegal? */
- Debug( LDAP_DEBUG_ANY, "dynlist_send_entry(\"%s\"): "
+ Debug( LDAP_DEBUG_ANY, "dynlist_prepare_entry(\"%s\"): "
"illegal URI \"%s\"\n",
e->e_name.bv_val, url->bv_val, 0 );
goto cleanup;
@@ -665,10 +685,18 @@
case LDAP_REQ_SEARCH:
if ( rs->sr_type == REP_SEARCH && !get_manageDSAit( op ) )
{
- dli = dynlist_is_dynlist( op, rs );
- if ( dli != NULL ) {
- return dynlist_send_entry( op, rs, dli );
+ int rc = LDAP_OTHER;
+
+ for ( dli = dynlist_is_dynlist_next( op, rs, NULL );
+ dli;
+ dli = dynlist_is_dynlist_next( op, rs, dli ) )
+ {
+ rc = dynlist_prepare_entry( op, rs, dli );
}
+
+ if ( rc != LDAP_OTHER ) {
+ return rc;
+ }
}
break;
@@ -787,32 +815,18 @@
for ( dlip = (dynlist_info_t **)&on->on_bi.bi_private;
*dlip; dlip = &(*dlip)->dli_next )
{
- /* The check on objectClass may be relaxed */
-#if 0
- if ( (*dlip)->dli_oc == oc ) {
+ /* The same URL attribute / member attribute pair
+ * cannot be repeated */
+ if ( (*dlip)->dli_ad == ad && (*dlip)->dli_member_ad == member_ad ) {
Debug( LDAP_DEBUG_ANY, "%s: line %d: "
"\"dynlist-attrset <oc> <URL-ad> [<member-ad>]\": "
- "objectClass \"%s\" already mapped.\n",
- fname, lineno, oc->soc_cname.bv_val );
- return 1;
- }
-#endif
-
- if ( (*dlip)->dli_ad == ad ) {
- Debug( LDAP_DEBUG_ANY, "%s: line %d: "
- "\"dynlist-attrset <oc> <URL-ad> [<member-ad>]\": "
"URL attributeDescription \"%s\" already mapped.\n",
fname, lineno, ad->ad_cname.bv_val );
+#if 0
+ /* make it a warning... */
return 1;
+#endif
}
-
- if ( member_ad != NULL && (*dlip)->dli_member_ad == member_ad ) {
- Debug( LDAP_DEBUG_ANY, "%s: line %d: "
- "\"dynlist-attrset <oc> <URL-ad> [<member-ad>]\": "
- "member attributeDescription \"%s\" already mapped.\n",
- fname, lineno, member_ad->ad_cname.bv_val );
- return 1;
- }
}
*dlip = (dynlist_info_t *)ch_calloc( 1, sizeof( dynlist_info_t ) );
@@ -878,36 +892,21 @@
return 1;
}
-
for ( dlip = (dynlist_info_t **)&on->on_bi.bi_private;
*dlip; dlip = &(*dlip)->dli_next )
{
-#if 0
- /* The check on objectClass may be relaxed */
- if ( (*dlip)->dli_oc == oc ) {
+ /* The same URL attribute / member attribute pair
+ * cannot be repeated */
+ if ( (*dlip)->dli_ad == ad && (*dlip)->dli_member_ad == member_ad ) {
Debug( LDAP_DEBUG_ANY, "%s: line %d: "
"\"dynlist-attrpair <member-ad> <URL-ad>\": "
- "objectClass \"%s\" already mapped.\n",
- fname, lineno, oc->soc_cname.bv_val );
- return 1;
- }
-#endif
-
- if ( (*dlip)->dli_ad == ad ) {
- Debug( LDAP_DEBUG_ANY, "%s: line %d: "
- "\"dynlist-attrpair <member-ad> <URL-ad>\": "
"URL attributeDescription \"%s\" already mapped.\n",
fname, lineno, ad->ad_cname.bv_val );
+#if 0
+ /* make it a warning... */
return 1;
+#endif
}
-
- if ( member_ad != NULL && (*dlip)->dli_member_ad == member_ad ) {
- Debug( LDAP_DEBUG_ANY, "%s: line %d: "
- "\"dynlist-attrpair <member-ad> <URL-ad>\": "
- "member attributeDescription \"%s\" already mapped.\n",
- fname, lineno, member_ad->ad_cname.bv_val );
- return 1;
- }
}
*dlip = (dynlist_info_t *)ch_calloc( 1, sizeof( dynlist_info_t ) );
@@ -1122,38 +1121,20 @@
for ( dlip = (dynlist_info_t **)&on->on_bi.bi_private;
*dlip; dlip = &(*dlip)->dli_next )
{
- /* The check on objectClass may be relaxed */
-#if 0
- if ( (*dlip)->dli_oc == oc ) {
+ /* The same URL attribute / member attribute pair
+ * cannot be repeated */
+ if ( (*dlip)->dli_ad == ad && (*dlip)->dli_member_ad == member_ad ) {
snprintf( c->msg, sizeof( c->msg ),
"\"dynlist-attrset <oc> <URL-ad> [<member-ad>]\": "
- "objectClass \"%s\" already mapped.\n",
- oc->soc_cname.bv_val );
- Debug( LDAP_DEBUG_ANY, "%s: %s.\n",
- c->log, c->msg, 0 );
- return 1;
- }
-#endif
-
- if ( (*dlip)->dli_ad == ad ) {
- snprintf( c->msg, sizeof( c->msg ),
- "\"dynlist-attrset <oc> <URL-ad> [<member-ad>]\": "
"URL attributeDescription \"%s\" already mapped.\n",
ad->ad_cname.bv_val );
Debug( LDAP_DEBUG_ANY, "%s: %s.\n",
c->log, c->msg, 0 );
+#if 0
+ /* make it a warning... */
return 1;
+#endif
}
-
- if ( member_ad != NULL && (*dlip)->dli_member_ad == member_ad ) {
- snprintf( c->msg, sizeof( c->msg ),
- "\"dynlist-attrset <oc> <URL-ad> [<member-ad>]\": "
- "member attributeDescription \"%s\" already mapped.\n",
- member_ad->ad_cname.bv_val );
- Debug( LDAP_DEBUG_ANY, "%s: %s.\n",
- c->log, c->msg, 0 );
- return 1;
- }
}
if ( c->valx > 0 ) {
@@ -1252,38 +1233,20 @@
for ( dlip = (dynlist_info_t **)&on->on_bi.bi_private;
*dlip; dlip = &(*dlip)->dli_next )
{
- /* The check on objectClass may be relaxed */
-#if 0
- if ( (*dlip)->dli_oc == oc ) {
+ /* The same URL attribute / member attribute pair
+ * cannot be repeated */
+ if ( (*dlip)->dli_ad == ad && (*dlip)->dli_member_ad == member_ad ) {
snprintf( c->msg, sizeof( c->msg ),
"\"dynlist-attrpair <member-ad> <URL-ad>\": "
- "objectClass \"%s\" already mapped.\n",
- oc->soc_cname.bv_val );
- Debug( LDAP_DEBUG_ANY, "%s: %s.\n",
- c->log, c->msg, 0 );
- return 1;
- }
-#endif
-
- if ( (*dlip)->dli_ad == ad ) {
- snprintf( c->msg, sizeof( c->msg ),
- "\"dynlist-attrpair <member-ad> <URL-ad>\": "
"URL attributeDescription \"%s\" already mapped.\n",
ad->ad_cname.bv_val );
Debug( LDAP_DEBUG_ANY, "%s: %s.\n",
c->log, c->msg, 0 );
+#if 0
+ /* make it a warning... */
return 1;
+#endif
}
-
- if ( member_ad != NULL && (*dlip)->dli_member_ad == member_ad ) {
- snprintf( c->msg, sizeof( c->msg ),
- "\"dynlist-attrpair <member-ad> <URL-ad>\": "
- "member attributeDescription \"%s\" already mapped.\n",
- member_ad->ad_cname.bv_val );
- Debug( LDAP_DEBUG_ANY, "%s: %s.\n",
- c->log, c->msg, 0 );
- return 1;
- }
}
*dlip = (dynlist_info_t *)ch_calloc( 1, sizeof( dynlist_info_t ) );
Modified: openldap/vendor/openldap-release/servers/slapd/overlays/pcache.c
===================================================================
--- openldap/vendor/openldap-release/servers/slapd/overlays/pcache.c 2007-09-15 10:30:38 UTC (rev 843)
+++ openldap/vendor/openldap-release/servers/slapd/overlays/pcache.c 2007-09-15 10:38:52 UTC (rev 844)
@@ -1,4 +1,4 @@
-/* $OpenLDAP: pkg/ldap/servers/slapd/overlays/pcache.c,v 1.41.2.17 2007/01/02 21:44:08 kurt Exp $ */
+/* $OpenLDAP: pkg/ldap/servers/slapd/overlays/pcache.c,v 1.41.2.19 2007/07/23 20:08:32 hallvard Exp $ */
/* This work is part of OpenLDAP Software <http://www.openldap.org/>.
*
* Copyright 2003-2007 The OpenLDAP Foundation.
@@ -417,7 +417,6 @@
static int
substr_containment_substr(Operation *op, Filter* stored, Filter* incoming)
{
- int i;
int rc = 0;
struct berval init_incoming;
@@ -608,7 +607,6 @@
free_query (CachedQuery* qc)
{
Query* q = (Query*)qc;
- int i;
free(qc->q_uuid.bv_val);
filter_free(q->filter);
@@ -1026,6 +1024,19 @@
}
static int
+pcache_op_cleanup( Operation *op, SlapReply *rs ) {
+ slap_callback *cb = op->o_callback;
+ struct search_info *si = cb->sc_private;
+ if ( si->query.save_attrs != NULL ) {
+ rs->sr_attrs = si->query.save_attrs;
+ op->ors_attrs = si->query.save_attrs;
+ }
+ op->o_callback = op->o_callback->sc_next;
+ op->o_tmpfree( cb, op->o_tmpmemctx );
+ return SLAP_CB_CONTINUE;
+}
+
+static int
pcache_response(
Operation *op,
SlapReply *rs )
@@ -1097,8 +1108,7 @@
filter_free( si->query.filter );
}
- /* free self */
- op->o_callback->sc_cleanup = slap_freeself_cb;
+ op->o_callback->sc_cleanup = pcache_op_cleanup;
}
return SLAP_CB_CONTINUE;
}
@@ -1205,8 +1215,6 @@
cache_manager *cm = on->on_bi.bi_private;
query_manager* qm = cm->qm;
- int count;
-
int i = -1;
AttributeName *filter_attrs = NULL;
@@ -1219,7 +1227,6 @@
int cacheable = 0;
int fattr_cnt=0;
int fattr_got_oc = 0;
- int oc_attr_absent = 1;
struct berval tempstr;
@@ -2014,7 +2021,7 @@
slap_overinst *on = (slap_overinst *)be->bd_info;
cache_manager *cm = on->on_bi.bi_private;
query_manager *qm = cm->qm;
- int i, j, rc = 0;
+ int i, rc = 0;
/* cleanup stuff inherited from the original database... */
cm->db.be_limits = NULL;
Modified: openldap/vendor/openldap-release/servers/slapd/overlays/ppolicy.c
===================================================================
--- openldap/vendor/openldap-release/servers/slapd/overlays/ppolicy.c 2007-09-15 10:30:38 UTC (rev 843)
+++ openldap/vendor/openldap-release/servers/slapd/overlays/ppolicy.c 2007-09-15 10:38:52 UTC (rev 844)
@@ -1,4 +1,4 @@
-/* $OpenLDAP: pkg/ldap/servers/slapd/overlays/ppolicy.c,v 1.31.2.29 2007/02/08 12:31:24 hyc Exp $ */
+/* $OpenLDAP: pkg/ldap/servers/slapd/overlays/ppolicy.c,v 1.31.2.35 2007/08/16 18:49:56 hyc Exp $ */
/* This work is part of OpenLDAP Software <http://www.openldap.org/>.
*
* Copyright 2004-2007 The OpenLDAP Foundation.
@@ -61,6 +61,7 @@
static pw_conn *pwcons;
static int ppolicy_cid;
+static int ov_count;
typedef struct pass_policy {
AttributeDescription *ad; /* attribute to which the policy applies */
@@ -356,6 +357,8 @@
#define PPOLICY_EXPIRE 0x80L /* primitive + 0 */
#define PPOLICY_GRACE 0x81L /* primitive + 1 */
+static const char ppolicy_ctrl_oid[] = LDAP_CONTROL_PASSWORDPOLICYRESPONSE;
+
static LDAPControl *
create_passcontrol( int exptime, int grace, LDAPPasswordPolicyError err )
{
@@ -368,7 +371,7 @@
if ( c == NULL ) {
return NULL;
}
- c->ldctl_oid = LDAP_CONTROL_PASSWORDPOLICYRESPONSE;
+ c->ldctl_oid = (char *)ppolicy_ctrl_oid;
c->ldctl_iscritical = 0;
BER_BVZERO( &c->ldctl_value );
@@ -848,7 +851,7 @@
assert( rs->sr_ctrls[0] != NULL );
for ( n = 0; rs->sr_ctrls[n]; n++ ) {
- if ( rs->sr_ctrls[n]->ldctl_oid == LDAP_CONTROL_PASSWORDPOLICYRESPONSE ) {
+ if ( rs->sr_ctrls[n]->ldctl_oid == ppolicy_ctrl_oid ) {
ch_free( rs->sr_ctrls[n]->ldctl_value.bv_val );
ch_free( rs->sr_ctrls[n] );
rs->sr_ctrls[n] = (LDAPControl *)(-1);
@@ -1692,7 +1695,10 @@
goto return_results;
}
- if (pp.pwdMinAge > 0) {
+ /* Check age, but only if pwdReset is not TRUE */
+ pa = attr_find( e->e_attrs, ad_pwdReset );
+ if ((!pa || !bvmatch( &pa->a_nvals[0], &slap_true_bv )) &&
+ pp.pwdMinAge > 0) {
time_t pwtime = (time_t)-1, now;
int age;
@@ -2113,6 +2119,7 @@
BackendDB *be
)
{
+ ov_count++;
return overlay_register_control( be, LDAP_CONTROL_PASSWORDPOLICYREQUEST );
}
@@ -2123,8 +2130,13 @@
{
slap_overinst *on = (slap_overinst *) be->bd_info;
pp_info *pi = on->on_bi.bi_private;
-
- free( pwcons );
+
+ /* Perhaps backover should provide bi_destroy hooks... */
+ ov_count--;
+ if ( ov_count <=0 && pwcons ) {
+ free( pwcons );
+ pwcons = NULL;
+ }
free( pi->def_policy.bv_val );
free( pi );
Modified: openldap/vendor/openldap-release/servers/slapd/overlays/rwm.c
===================================================================
--- openldap/vendor/openldap-release/servers/slapd/overlays/rwm.c 2007-09-15 10:30:38 UTC (rev 843)
+++ openldap/vendor/openldap-release/servers/slapd/overlays/rwm.c 2007-09-15 10:38:52 UTC (rev 844)
@@ -1,5 +1,5 @@
/* rwm.c - rewrite/remap operations */
-/* $OpenLDAP: pkg/ldap/servers/slapd/overlays/rwm.c,v 1.37.2.18 2007/01/05 09:47:11 ando Exp $ */
+/* $OpenLDAP: pkg/ldap/servers/slapd/overlays/rwm.c,v 1.37.2.20 2007/08/14 09:59:44 ando Exp $ */
/* This work is part of OpenLDAP Software <http://www.openldap.org/>.
*
* Copyright 2003-2007 The OpenLDAP Foundation.
@@ -32,6 +32,7 @@
struct berval ro_ndn;
struct berval r_dn;
struct berval r_ndn;
+ AttributeName *mapped_attrs;
OpRequest o_request;
} rwm_op_state;
@@ -79,7 +80,7 @@
}
break;
case LDAP_REQ_SEARCH:
- ch_free( op->ors_attrs );
+ ch_free( ros->mapped_attrs );
filter_free_x( op, op->ors_filter );
ch_free( op->ors_filterstr.bv_val );
op->ors_attrs = ros->ors_attrs;
@@ -770,6 +771,11 @@
rwm_op_state *ros = cb->sc_private;
rs->sr_attrs = ros->ors_attrs;
+
+ /* other overlays might have touched op->ors_attrs,
+ * so we restore the original version here, otherwise
+ * attribute-mapping might fail */
+ op->ors_attrs = ros->mapped_attrs;
return SLAP_CB_CONTINUE;
}
@@ -844,6 +850,9 @@
}
op->ors_attrs = an;
+ /* store the mapped Attributes for later usage, in
+ * the case that other overlays change op->ors_attrs */
+ roc->ros.mapped_attrs = an;
roc->cb.sc_response = rwm_swap_attrs;
op->o_callback = &roc->cb;
@@ -1066,6 +1075,7 @@
int rc;
Attribute **ap;
int isupdate;
+ int check_duplicate_attrs = 0;
/*
* Rewrite the dn attrs, if needed
@@ -1119,6 +1129,9 @@
if ( mapping != NULL ) {
(*ap)->a_desc = mapping->m_dst_ad;
+
+ /* will need to check for duplicate attrs */
+ check_duplicate_attrs++;
}
}
@@ -1155,6 +1168,7 @@
rwm_map( &rwmap->rwm_oc, &bv[0], &mapped, RWM_REMAP );
if ( BER_BVISNULL( &mapped ) || BER_BVISEMPTY( &mapped ) ) {
+remove_oc:;
ch_free( bv[0].bv_val );
BER_BVZERO( &bv[0] );
if ( &(*ap)->a_vals[last] > &bv[0] ) {
@@ -1165,12 +1179,32 @@
bv--;
} else if ( mapped.bv_val != bv[0].bv_val ) {
+ int i;
+
+ for ( i = 0; !BER_BVISNULL( &(*ap)->a_vals[ i ] ); i++ ) {
+ if ( &(*ap)->a_vals[ i ] == bv ) {
+ continue;
+ }
+
+ if ( ber_bvstrcasecmp( &mapped, &(*ap)->a_vals[ i ] ) == 0 ) {
+ break;
+ }
+ }
+
+ if ( !BER_BVISNULL( &(*ap)->a_vals[ i ] ) ) {
+ goto remove_oc;
+ }
+
/*
* FIXME: after LBER_FREEing
* the value is replaced by
* ch_alloc'ed memory
*/
ber_bvreplace( &bv[0], &mapped );
+
+ /* FIXME: will need to check
+ * if the structuralObjectClass
+ * changed */
}
}
@@ -1224,6 +1258,45 @@
attr_free( a );
}
+ /* only check if some mapping occurred */
+ if ( check_duplicate_attrs ) {
+ for ( ap = a_first; *ap != NULL; ap = &(*ap)->a_next ) {
+ Attribute **tap;
+
+ for ( tap = &(*ap)->a_next; *tap != NULL; ) {
+ if ( (*tap)->a_desc == (*ap)->a_desc ) {
+ Entry e = { 0 };
+ Modification mod = { 0 };
+ const char *text = NULL;
+ char textbuf[ SLAP_TEXT_BUFLEN ];
+ Attribute *next = (*tap)->a_next;
+
+ BER_BVSTR( &e.e_name, "" );
+ BER_BVSTR( &e.e_nname, "" );
+ e.e_attrs = *ap;
+ mod.sm_op = LDAP_MOD_ADD;
+ mod.sm_desc = (*ap)->a_desc;
+ mod.sm_type = mod.sm_desc->ad_cname;
+ mod.sm_values = (*tap)->a_vals;
+ mod.sm_nvalues = (*tap)->a_nvals;
+
+ (void)modify_add_values( &e, &mod,
+ /* permissive */ 1,
+ &text, textbuf, sizeof( textbuf ) );
+
+ /* should not insert new attrs! */
+ assert( e.e_attrs == *ap );
+
+ attr_free( *tap );
+ *tap = next;
+
+ } else {
+ tap = &(*tap)->a_next;
+ }
+ }
+ }
+ }
+
return 0;
}
Modified: openldap/vendor/openldap-release/servers/slapd/overlays/rwmmap.c
===================================================================
--- openldap/vendor/openldap-release/servers/slapd/overlays/rwmmap.c 2007-09-15 10:30:38 UTC (rev 843)
+++ openldap/vendor/openldap-release/servers/slapd/overlays/rwmmap.c 2007-09-15 10:38:52 UTC (rev 844)
@@ -1,5 +1,5 @@
/* rwmmap.c - rewrite/mapping routines */
-/* $OpenLDAP: pkg/ldap/servers/slapd/overlays/rwmmap.c,v 1.14.2.14 2007/02/26 22:59:55 ando Exp $ */
+/* $OpenLDAP: pkg/ldap/servers/slapd/overlays/rwmmap.c,v 1.14.2.15 2007/07/12 20:23:48 ando Exp $ */
/* This work is part of OpenLDAP Software <http://www.openldap.org/>.
*
* Copyright 1999-2007 The OpenLDAP Foundation.
@@ -768,7 +768,9 @@
case REWRITE_REGEXEC_OK:
if ( !BER_BVISNULL( fstr ) ) {
fstr->bv_len = strlen( fstr->bv_val );
- ch_free( ftmp.bv_val );
+ if ( fstr->bv_val != ftmp.bv_val ) {
+ ch_free( ftmp.bv_val );
+ }
} else {
*fstr = ftmp;
Modified: openldap/vendor/openldap-release/servers/slapd/overlays/syncprov.c
===================================================================
--- openldap/vendor/openldap-release/servers/slapd/overlays/syncprov.c 2007-09-15 10:30:38 UTC (rev 843)
+++ openldap/vendor/openldap-release/servers/slapd/overlays/syncprov.c 2007-09-15 10:38:52 UTC (rev 844)
@@ -1,4 +1,4 @@
-/* $OpenLDAP: pkg/ldap/servers/slapd/overlays/syncprov.c,v 1.56.2.42 2007/02/07 01:51:36 hyc Exp $ */
+/* $OpenLDAP: pkg/ldap/servers/slapd/overlays/syncprov.c,v 1.56.2.45 2007/07/22 15:24:26 hyc Exp $ */
/* syncprov.c - syncrepl provider */
/* This work is part of OpenLDAP Software <http://www.openldap.org/>.
*
@@ -401,6 +401,7 @@
slap_callback cb = {0};
Operation fop;
SlapReply frs = { REP_RESULT };
+ BackendInfo *bi;
int rc;
fc->fss->s_flags ^= PS_FIND_BASE;
@@ -412,6 +413,7 @@
fop.o_bd = op->o_bd;
fop.o_time = op->o_time;
fop.o_tincr = op->o_tincr;
+ bi = op->o_bd->bd_info;
cb.sc_response = findbase_cb;
cb.sc_private = fc;
@@ -429,9 +431,8 @@
fop.ors_filter = &generic_filter;
fop.ors_filterstr = generic_filterstr;
- fop.o_bd->bd_info = on->on_info->oi_orig;
- rc = fop.o_bd->be_search( &fop, &frs );
- fop.o_bd->bd_info = (BackendInfo *)on;
+ rc = overlay_op_walk( &fop, &frs, op_search, on->on_info, on );
+ op->o_bd->bd_info = bi;
} else {
ldap_pvt_thread_mutex_unlock( &fc->fss->s_mutex );
fc->fbase = 1;
@@ -641,6 +642,7 @@
} else {
cf.f_choice = LDAP_FILTER_LE;
fop.ors_limit = &fc_limits;
+ memset( &fc_limits, 0, sizeof( fc_limits ));
fc_limits.lms_s_unchecked = 1;
fop.ors_filterstr.bv_len = sprintf( buf, "(entryCSN<=%s)",
cf.f_av_value.bv_val );
@@ -818,7 +820,6 @@
int rc = 0;
opc.son = on;
- op->o_bd->bd_info = (BackendInfo *)on->on_info;
for (;;) {
ldap_pvt_thread_mutex_lock( &so->s_mutex );
@@ -840,7 +841,7 @@
e = NULL;
if ( sr->s_mode != LDAP_SYNC_DELETE ) {
- rc = be_entry_get_rw( op, &opc.sndn, NULL, NULL, 0, &e );
+ rc = overlay_entry_get_ov( op, &opc.sndn, NULL, NULL, 0, &e, on );
if ( rc ) {
Debug( LDAP_DEBUG_SYNC, "syncprov_qplay: failed to get %s, "
"error (%d), ignoring...\n", opc.sndn.bv_val, rc, 0 );
@@ -852,7 +853,7 @@
rc = syncprov_sendresp( op, &opc, so, &e, sr->s_mode );
if ( e ) {
- be_entry_release_rw( op, e, 0 );
+ overlay_entry_release_ov( op, e, 0, on );
}
ch_free( sr );
@@ -860,7 +861,6 @@
if ( rc )
break;
}
- op->o_bd->bd_info = (BackendInfo *)on;
return rc;
}
@@ -1060,7 +1060,7 @@
fbase_cookie fc;
syncops *ss, *sprev, *snext;
- Entry *e;
+ Entry *e = NULL;
Attribute *a;
int rc;
struct berval newdn;
@@ -1082,15 +1082,13 @@
db = *op->o_bd;
op->o_bd = &db;
}
- op->o_bd->bd_info = (BackendInfo *)on->on_info;
- rc = be_entry_get_rw( op, fc.fdn, NULL, NULL, 0, &e );
+ rc = overlay_entry_get_ov( op, fc.fdn, NULL, NULL, 0, &e, on );
/* If we're sending responses now, make a copy and unlock the DB */
if ( e && !saveit ) {
Entry *e2 = entry_dup( e );
- be_entry_release_rw( op, e, 0 );
+ overlay_entry_release_ov( op, e, 0, on );
e = e2;
}
- op->o_bd->bd_info = (BackendInfo *)on;
if ( rc ) {
op->o_bd = b0;
return;
@@ -2372,7 +2370,7 @@
OperationBuffer opbuf = { 0 };
char ctxcsnbuf[LDAP_LUTIL_CSNSTR_BUFSIZE];
Operation *op = (Operation *) &opbuf;
- Entry *e;
+ Entry *e = NULL;
Attribute *a;
int rc;
void *thrctx = NULL;
@@ -2400,9 +2398,8 @@
ctxcsnbuf[0] = '\0';
- op->o_bd->bd_info = on->on_info->oi_orig;
- rc = be_entry_get_rw( op, be->be_nsuffix, NULL,
- slap_schema.si_ad_contextCSN, 0, &e );
+ rc = overlay_entry_get_ov( op, be->be_nsuffix, NULL,
+ slap_schema.si_ad_contextCSN, 0, &e, on );
if ( e ) {
ldap_pvt_thread_t tid;
@@ -2417,9 +2414,8 @@
si->si_ctxcsnbuf[si->si_ctxcsn.bv_len] = '\0';
strcpy( ctxcsnbuf, si->si_ctxcsnbuf );
}
- be_entry_release_rw( op, e, 0 );
+ overlay_entry_release_ov( op, e, 0, on );
if ( !BER_BVISEMPTY( &si->si_ctxcsn ) ) {
- op->o_bd->bd_info = (BackendInfo *)on;
op->o_req_dn = be->be_suffix[0];
op->o_req_ndn = be->be_nsuffix[0];
op->ors_scope = LDAP_SCOPE_SUBTREE;
@@ -2466,7 +2462,7 @@
return 0;
}
if ( si->si_numops ) {
- Connection conn;
+ Connection conn = {0};
OperationBuffer opbuf;
Operation *op = (Operation *) &opbuf;
SlapReply rs = {REP_RESULT};
@@ -2628,8 +2624,8 @@
sr->sr_rhint = rhint;
if (!BER_BVISNULL(&cookie)) {
ber_dupbv_x( &sr->sr_state.octet_str, &cookie, op->o_tmpmemctx );
- slap_parse_sync_cookie( &sr->sr_state, op->o_tmpmemctx );
- if ( sr->sr_state.rid == -1 ) {
+ if ( slap_parse_sync_cookie( &sr->sr_state, op->o_tmpmemctx ) ||
+ sr->sr_state.rid == -1 ) {
rs->sr_text = "Sync control : cookie parsing error";
return LDAP_PROTOCOL_ERROR;
}
Modified: openldap/vendor/openldap-release/servers/slapd/overlays/translucent.c
===================================================================
--- openldap/vendor/openldap-release/servers/slapd/overlays/translucent.c 2007-09-15 10:30:38 UTC (rev 843)
+++ openldap/vendor/openldap-release/servers/slapd/overlays/translucent.c 2007-09-15 10:38:52 UTC (rev 844)
@@ -1,5 +1,5 @@
/* translucent.c - translucent proxy module */
-/* $OpenLDAP: pkg/ldap/servers/slapd/overlays/translucent.c,v 1.1.2.13 2007/01/02 21:44:09 kurt Exp $ */
+/* $OpenLDAP: pkg/ldap/servers/slapd/overlays/translucent.c,v 1.1.2.14 2007/08/10 15:02:15 ghenry Exp $ */
/* This work is part of OpenLDAP Software <http://www.openldap.org/>.
*
* Copyright 2004-2007 The OpenLDAP Foundation.
@@ -686,7 +686,7 @@
overlay_stack *ov;
int rc;
- Debug(LDAP_DEBUG_TRACE, "==> translucent_init\n", 0, 0, 0);
+ Debug(LDAP_DEBUG_TRACE, "==> translucent_db_init\n", 0, 0, 0);
ov = ch_calloc(1, sizeof(overlay_stack));
ov->config = ch_calloc(1, sizeof(translucent_configuration));
@@ -726,11 +726,11 @@
/* "should never happen" */
if(!ov->info) {
- Debug(LDAP_DEBUG_ANY, "translucent_open() called with bad ov->info\n", 0, 0, 0);
+ Debug(LDAP_DEBUG_ANY, "translucent_db_open() called with bad ov->info\n", 0, 0, 0);
return(LDAP_OTHER);
}
- Debug(LDAP_DEBUG_TRACE, "translucent_open\n", 0, 0, 0);
+ Debug(LDAP_DEBUG_TRACE, "translucent_db_open\n", 0, 0, 0);
be->be_private = ov->private;
rc = ov->info->bi_db_open ? ov->info->bi_db_open(be) : 0;
Modified: openldap/vendor/openldap-release/servers/slapd/overlays/valsort.c
===================================================================
--- openldap/vendor/openldap-release/servers/slapd/overlays/valsort.c 2007-09-15 10:30:38 UTC (rev 843)
+++ openldap/vendor/openldap-release/servers/slapd/overlays/valsort.c 2007-09-15 10:38:52 UTC (rev 844)
@@ -1,5 +1,5 @@
/* valsort.c - sort attribute values */
-/* $OpenLDAP: pkg/ldap/servers/slapd/overlays/valsort.c,v 1.9.2.6 2007/01/02 21:44:09 kurt Exp $ */
+/* $OpenLDAP: pkg/ldap/servers/slapd/overlays/valsort.c,v 1.9.2.7 2007/06/08 08:13:18 hyc Exp $ */
/* This work is part of OpenLDAP Software <http://www.openldap.org/>.
*
* Copyright 2005-2007 The OpenLDAP Foundation.
@@ -447,6 +447,9 @@
if ( !(vi->vi_sort & VALSORT_WEIGHTED ))
continue;
for (ml = op->orm_modlist; ml; ml=ml->sml_next ) {
+ /* Must be a Delete Attr op, so no values to consider */
+ if ( !ml->sml_values )
+ continue;
if ( ml->sml_desc == vi->vi_ad )
break;
}
Modified: openldap/vendor/openldap-release/servers/slapd/proto-slap.h
===================================================================
--- openldap/vendor/openldap-release/servers/slapd/proto-slap.h 2007-09-15 10:30:38 UTC (rev 843)
+++ openldap/vendor/openldap-release/servers/slapd/proto-slap.h 2007-09-15 10:38:52 UTC (rev 844)
@@ -1,4 +1,4 @@
-/* $OpenLDAP: pkg/ldap/servers/slapd/proto-slap.h,v 1.552.2.41 2007/01/02 21:43:57 kurt Exp $ */
+/* $OpenLDAP: pkg/ldap/servers/slapd/proto-slap.h,v 1.552.2.43 2007/07/23 20:10:22 hallvard Exp $ */
/* This work is part of OpenLDAP Software <http://www.openldap.org/>.
*
* Copyright 1998-2007 The OpenLDAP Foundation.
@@ -426,6 +426,19 @@
slap_operation_t which,
slap_overinfo *oi,
slap_overinst *on ));
+LDAP_SLAPD_F (int) overlay_entry_get_ov LDAP_P((
+ Operation *op,
+ struct berval *dn,
+ ObjectClass *oc,
+ AttributeDescription *ad,
+ int rw,
+ Entry **e,
+ slap_overinst *ov ));
+LDAP_SLAPD_F (int) overlay_entry_release_ov LDAP_P((
+ Operation *op,
+ Entry *e,
+ int rw,
+ slap_overinst *ov ));
/*
* bconfig.c
@@ -722,8 +735,8 @@
LDAP_SLAPD_F (Listener **) slapd_get_listeners LDAP_P((void));
LDAP_SLAPD_F (void) slapd_remove LDAP_P((ber_socket_t s, Sockbuf *sb,
int wasactive, int wake, int locked ));
-LDAP_SLAPD_F (void) slapd_sd_lock();
-LDAP_SLAPD_F (void) slapd_sd_unlock();
+LDAP_SLAPD_F (void) slapd_sd_lock LDAP_P((void));
+LDAP_SLAPD_F (void) slapd_sd_unlock LDAP_P((void));
LDAP_SLAPD_F (RETSIGTYPE) slap_sig_shutdown LDAP_P((int sig));
LDAP_SLAPD_F (RETSIGTYPE) slap_sig_wake LDAP_P((int sig));
Modified: openldap/vendor/openldap-release/servers/slapd/result.c
===================================================================
--- openldap/vendor/openldap-release/servers/slapd/result.c 2007-09-15 10:30:38 UTC (rev 843)
+++ openldap/vendor/openldap-release/servers/slapd/result.c 2007-09-15 10:38:52 UTC (rev 844)
@@ -1,5 +1,5 @@
/* result.c - routines to send ldap results, errors, and referrals */
-/* $OpenLDAP: pkg/ldap/servers/slapd/result.c,v 1.244.2.22 2007/01/02 21:43:57 kurt Exp $ */
+/* $OpenLDAP: pkg/ldap/servers/slapd/result.c,v 1.244.2.24 2007/06/13 14:31:47 ralf Exp $ */
/* This work is part of OpenLDAP Software <http://www.openldap.org/>.
*
* Copyright 1998-2007 The OpenLDAP Foundation.
@@ -170,7 +170,7 @@
break;
}
- err = errno;
+ err = sock_errno();
/*
* we got an error. if it's ewouldblock, we need to
@@ -287,7 +287,7 @@
int rc = LDAP_SUCCESS;
long bytes;
- if ( rs->sr_err == SLAPD_ABANDON ) {
+ if ( rs->sr_err == SLAPD_ABANDON || op->o_abandon ) {
rc = SLAPD_ABANDON;
goto clean2;
}
@@ -527,7 +527,7 @@
rs->sr_type = REP_RESULT;
/* Propagate Abandons so that cleanup callbacks can be processed */
- if ( rs->sr_err == SLAPD_ABANDON )
+ if ( rs->sr_err == SLAPD_ABANDON || op->o_abandon )
goto abandon;
assert( !LDAP_API_ERROR( rs->sr_err ) );
Modified: openldap/vendor/openldap-release/servers/slapd/sasl.c
===================================================================
--- openldap/vendor/openldap-release/servers/slapd/sasl.c 2007-09-15 10:30:38 UTC (rev 843)
+++ openldap/vendor/openldap-release/servers/slapd/sasl.c 2007-09-15 10:38:52 UTC (rev 844)
@@ -1,4 +1,4 @@
-/* $OpenLDAP: pkg/ldap/servers/slapd/sasl.c,v 1.212.2.17 2007/01/25 12:42:38 hyc Exp $ */
+/* $OpenLDAP: pkg/ldap/servers/slapd/sasl.c,v 1.212.2.18 2007/06/08 08:10:31 hyc Exp $ */
/* This work is part of OpenLDAP Software <http://www.openldap.org/>.
*
* Copyright 1998-2007 The OpenLDAP Foundation.
@@ -607,6 +607,7 @@
*/
if ( flags == SASL_CU_AUTHID && !auxvals[SLAP_SASL_PROP_AUTHZ].values ) {
conn->c_sasl_dn.bv_val = (char *) in;
+ conn->c_sasl_dn.bv_len = 0;
} else if ( flags == SASL_CU_AUTHZID && conn->c_sasl_dn.bv_val ) {
rc = strcmp( in, conn->c_sasl_dn.bv_val );
conn->c_sasl_dn.bv_val = NULL;
@@ -621,13 +622,13 @@
if ( rc != LDAP_SUCCESS ) {
sasl_seterror( sconn, 0, ldap_err2string( rc ) );
return SASL_NOAUTHZ;
- }
+ }
names[0] = slap_propnames[which];
names[1] = NULL;
prop_set( props, names[0], (char *)&dn, sizeof( dn ) );
-
+
Debug( LDAP_DEBUG_ARGS, "SASL Canonicalize [conn=%ld]: %s=\"%s\"\n",
conn ? conn->c_connid : -1, names[0]+1,
dn.bv_val ? dn.bv_val : "<EMPTY>" );
@@ -1451,6 +1452,9 @@
send_ldap_sasl( op, rs );
} else {
+ if ( op->o_conn->c_sasl_dn.bv_len )
+ ch_free( op->o_conn->c_sasl_dn.bv_val );
+ BER_BVZERO( &op->o_conn->c_sasl_dn );
#if SASL_VERSION_MAJOR >= 2
rs->sr_text = sasl_errdetail( ctx );
#endif
Added: openldap/vendor/openldap-release/servers/slapd/schema/corba.schema
===================================================================
--- openldap/vendor/openldap-release/servers/slapd/schema/corba.schema (rev 0)
+++ openldap/vendor/openldap-release/servers/slapd/schema/corba.schema 2007-09-15 10:38:52 UTC (rev 844)
@@ -0,0 +1,239 @@
+# corba.schema -- Corba Object Schema
+# depends upon core.schema
+# $OpenLDAP: pkg/ldap/servers/slapd/schema/corba.schema,v 1.4.2.3 2007/01/02 21:44:09 kurt Exp $
+# $OpenLDAP: pkg/ldap/servers/slapd/schema/corba.schema,v 1.4.2.3 2007/01/02 21:44:09 kurt Exp $
+## This work is part of OpenLDAP Software <http://www.openldap.org/>.
+##
+## Copyright 1998-2007 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>.
+#
+## Portions Copyright (C) The Internet Society (1999).
+## Please see full copyright statement below.
+
+
+# Network Working Group V. Ryan
+# Request for Comments: 2714 R. Lee
+# Category: Informational S. Seligman
+# Sun Microsystems, Inc.
+# October 1999
+#
+#
+# Schema for Representing CORBA Object References in an LDAP Directory
+#
+# Status of this Memo
+#
+# This memo provides information for the Internet community. It does
+# not specify an Internet standard of any kind. Distribution of this
+# memo is unlimited.
+#
+# Copyright Notice
+#
+# Copyright (C) The Internet Society (1999). All Rights Reserved.
+#
+# Abstract
+#
+# CORBA [CORBA] is the Common Object Request Broker Architecture
+# defined by the Object Management Group. This document defines the
+# schema for representing CORBA object references in an LDAP directory
+# [LDAPv3].
+#
+# [trimmed]
+
+# 3. Attribute Type Definitions
+#
+# The following attribute types are defined in this document:
+#
+# corbaIor
+# corbaRepositoryId
+#
+# 3.1 corbaIor
+#
+# This attribute stores the string representation of the interoperable
+# object reference (IOR) for a CORBA object. An IOR is an opaque handle
+# for the object which contains the information necessary to locate the
+# object, even if the object is in another ORB.
+#
+# This attribute's syntax is 'IA5 String' and its case is
+# insignificant.
+#
+# ( 1.3.6.1.4.1.42.2.27.4.1.14
+# NAME 'corbaIor'
+# DESC 'Stringified interoperable object reference of a CORBA object'
+# EQUALITY caseIgnoreIA5Match
+# SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
+# SINGLE-VALUE
+# )
+#
+attributetype ( 1.3.6.1.4.1.42.2.27.4.1.14
+ NAME 'corbaIor'
+ DESC 'Stringified interoperable object reference of a CORBA object'
+ EQUALITY caseIgnoreIA5Match
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
+ SINGLE-VALUE )
+
+# 3.2 corbaRepositoryId
+#
+# Each CORBA interface has a unique "repository id" (also called "type
+# id") that identifies the interface. A CORBA object has one or more
+# repository ids, one for each interface that it implements.
+#
+# The format of a repository id can be any string, but the OMG
+# specifies four standard formats:
+#
+# a. IDL-style
+#
+# IDL:Prefix/ModuleName/InterfaceName:VersionNumber
+#
+# For example, the repository id for the "NamingContext" in OMG's COS
+# Naming module is: "IDL:omg.org/CosNaming/NamingContext:1.0".
+#
+# b. RMI-style
+#
+# RMI:ClassName:HashCode[:SUID]
+#
+# This format is used by RMI-IIOP remote objects [RMI-IIOP].
+# "ClassName" is the fully qualified name of the class (for example,
+# "java.lang.String"). "HashCode" is the object's hash code (that is,
+# that obtained by invoking the "hashCode()" method). "SUID" is the
+# "stream unique identifier", which is a 64-bit number that uniquely
+# identifies the serialization version of the class; SUID is optional
+# in the repository id.
+#
+# c. DCE-style
+#
+# DCE:UUID
+#
+# This format is used for DCE/CORBA interoperability [CORBA-DCE].
+# "UUID" represents a DCE UUID.
+#
+# d. "local"
+#
+# This format is defined by the local Object Request Broker (ORB).
+#
+# The corbaRepositoryId attribute is a multivalued attribute; each
+# value records a single repository id of an interface implemented by
+# the CORBA object. This attribute need not contain a complete list of
+# the interfaces implemented by the CORBA object.
+#
+# This attribute's syntax is 'Directory String' and its case is
+# significant. The values of this attribute are encoded using UTF-8.
+# Some values may require translation from their native representation
+# in order to be correctly encoded using UTF-8.
+#
+# ( 1.3.6.1.4.1.42.2.27.4.1.15
+# NAME 'corbaRepositoryId'
+# DESC 'Repository ids of interfaces implemented by a CORBA object'
+# EQUALITY caseExactMatch
+# SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+# )
+#
+#
+attributetype ( 1.3.6.1.4.1.42.2.27.4.1.15
+ NAME 'corbaRepositoryId'
+ DESC 'Repository ids of interfaces implemented by a CORBA object'
+ EQUALITY caseExactMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+# 4. Object Class Definitions
+#
+# The following object classes are defined in this document:
+#
+# corbaContainer
+# corbaObject
+# corbaObjectReference
+#
+# 4.1 corbaContainer
+#
+# This structural object class represents a container for a CORBA
+# object.
+#
+# ( 1.3.6.1.4.1.42.2.27.4.2.10
+# NAME 'corbaContainer'
+# DESC 'Container for a CORBA object'
+# SUP top
+# STRUCTURAL
+# MUST ( cn )
+# )
+#
+objectclass ( 1.3.6.1.4.1.42.2.27.4.2.10
+ NAME 'corbaContainer'
+ DESC 'Container for a CORBA object'
+ SUP top
+ STRUCTURAL
+ MUST cn )
+
+# 4.2 corbaObject
+#
+# This abstract object class is the root class for representing a CORBA
+# object.
+#
+# ( 1.3.6.1.4.1.42.2.27.4.2.9
+# NAME 'corbaObject'
+# DESC 'CORBA object representation'
+# SUP top
+# ABSTRACT
+# MAY ( corbaRepositoryId $ description )
+# )
+#
+objectclass ( 1.3.6.1.4.1.42.2.27.4.2.9
+ NAME 'corbaObject'
+ DESC 'CORBA object representation'
+ SUP top
+ ABSTRACT
+ MAY ( corbaRepositoryId $ description ) )
+
+# 4.3 corbaObjectReference
+#
+# This auxiliary object class represents a CORBA object reference. It
+# must be mixed in with a structural object class.
+#
+# ( 1.3.6.1.4.1.42.2.27.4.2.11
+# NAME 'corbaObjectReference'
+# DESC 'CORBA interoperable object reference'
+# SUP corbaObject
+# AUXILIARY
+# MUST ( corbaIor )
+# )
+#
+objectclass ( 1.3.6.1.4.1.42.2.27.4.2.11
+ NAME 'corbaObjectReference'
+ DESC 'CORBA interoperable object reference'
+ SUP corbaObject
+ AUXILIARY
+ MUST corbaIor )
+
+# 10. Full Copyright Statement
+#
+# Copyright (C) The Internet Society (1999). All Rights Reserved.
+#
+# This document and translations of it may be copied and furnished to
+# others, and derivative works that comment on or otherwise explain it
+# or assist in its implementation may be prepared, copied, published
+# and distributed, in whole or in part, without restriction of any
+# kind, provided that the above copyright notice and this paragraph are
+# included on all such copies and derivative works. However, this
+# document itself may not be modified in any way, such as by removing
+# the copyright notice or references to the Internet Society or other
+# Internet organizations, except as needed for the purpose of
+# developing Internet standards in which case the procedures for
+# copyrights defined in the Internet Standards process must be
+# followed, or as required to translate it into languages other than
+# English.
+#
+# The limited permissions granted above are perpetual and will not be
+# revoked by the Internet Society or its successors or assigns.
+#
+# This document and the information contained herein is provided on an
+# "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+# TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+# BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+# HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+# MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Added: openldap/vendor/openldap-release/servers/slapd/schema/core.ldif
===================================================================
--- openldap/vendor/openldap-release/servers/slapd/schema/core.ldif (rev 0)
+++ openldap/vendor/openldap-release/servers/slapd/schema/core.ldif 2007-09-15 10:38:52 UTC (rev 844)
@@ -0,0 +1,588 @@
+# OpenLDAP Core schema
+# $OpenLDAP: pkg/ldap/servers/slapd/schema/core.ldif,v 1.1.2.5 2007/01/02 21:44:09 kurt Exp $
+## This work is part of OpenLDAP Software <http://www.openldap.org/>.
+##
+## Copyright 1998-2007 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>.
+#
+## Portions Copyright (C) The Internet Society (1997-2003).
+## All Rights Reserved.
+##
+## This document and translations of it may be copied and furnished to
+## others, and derivative works that comment on or otherwise explain it
+## or assist in its implementation may be prepared, copied, published
+## and distributed, in whole or in part, without restriction of any
+## kind, provided that the above copyright notice and this paragraph are
+## included on all such copies and derivative works. However, this
+## document itself may not be modified in any way, such as by removing
+## the copyright notice or references to the Internet Society or other
+## Internet organizations, except as needed for the purpose of
+## developing Internet standards in which case the procedures for
+## copyrights defined in the Internet Standards process must be
+## followed, or as required to translate it into languages other than
+## English.
+##
+## The limited permissions granted above are perpetual and will not be
+## revoked by the Internet Society or its successors or assigns.
+##
+## This document and the information contained herein is provided on an
+## "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+## TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+## BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+## HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+## MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+#
+#
+#
+# Includes LDAPv3 schema items from:
+# RFC 2252/2256 (LDAPv3)
+#
+# Select standard track schema items:
+# RFC 1274 (uid/dc)
+# RFC 2079 (URI)
+# RFC 2247 (dc/dcObject)
+# RFC 2587 (PKI)
+# RFC 2589 (Dynamic Directory Services)
+#
+# Select informational schema items:
+# RFC 2377 (uidObject)
+#
+#
+# Standard attribute types from RFC 2256
+#
+dn: cn=core,cn=schema,cn=config
+objectClass: olcSchemaConfig
+cn: core
+#
+# system schema
+#olcAttributeTypes: ( 2.5.4.0 NAME 'objectClass'
+# DESC 'RFC2256: object classes of the entity'
+# EQUALITY objectIdentifierMatch
+# SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
+#
+# system schema
+#olcAttributeTypes: ( 2.5.4.1 NAME ( 'aliasedObjectName' 'aliasedEntryName' )
+# DESC 'RFC2256: name of aliased object'
+# EQUALITY distinguishedNameMatch
+# SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE )
+#
+olcAttributeTypes: ( 2.5.4.2 NAME 'knowledgeInformation'
+ DESC 'RFC2256: knowledge information'
+ EQUALITY caseIgnoreMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} )
+#
+# system schema
+#olcAttributeTypes: ( 2.5.4.3 NAME ( 'cn' 'commonName' )
+# DESC 'RFC2256: common name(s) for which the entity is known by'
+# SUP name )
+#
+olcAttributeTypes: ( 2.5.4.4 NAME ( 'sn' 'surname' )
+ DESC 'RFC2256: last (family) name(s) for which the entity is known by'
+ SUP name )
+#
+olcAttributeTypes: ( 2.5.4.5 NAME 'serialNumber'
+ DESC 'RFC2256: serial number of the entity'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.44{64} )
+#
+olcAttributeTypes: ( 2.5.4.6 NAME ( 'c' 'countryName' )
+ DESC 'RFC2256: ISO-3166 country 2-letter code'
+ SUP name SINGLE-VALUE )
+#
+olcAttributeTypes: ( 2.5.4.7 NAME ( 'l' 'localityName' )
+ DESC 'RFC2256: locality which this object resides in'
+ SUP name )
+#
+olcAttributeTypes: ( 2.5.4.8 NAME ( 'st' 'stateOrProvinceName' )
+ DESC 'RFC2256: state or province which this object resides in'
+ SUP name )
+#
+olcAttributeTypes: ( 2.5.4.9 NAME ( 'street' 'streetAddress' )
+ DESC 'RFC2256: street address of this object'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{128} )
+#
+olcAttributeTypes: ( 2.5.4.10 NAME ( 'o' 'organizationName' )
+ DESC 'RFC2256: organization this object belongs to'
+ SUP name )
+#
+olcAttributeTypes: ( 2.5.4.11 NAME ( 'ou' 'organizationalUnitName' )
+ DESC 'RFC2256: organizational unit this object belongs to'
+ SUP name )
+#
+olcAttributeTypes: ( 2.5.4.12 NAME 'title'
+ DESC 'RFC2256: title associated with the entity'
+ SUP name )
+#
+# system schema
+#olcAttributeTypes: ( 2.5.4.13 NAME 'description'
+# DESC 'RFC2256: descriptive information'
+# EQUALITY caseIgnoreMatch
+# SUBSTR caseIgnoreSubstringsMatch
+# SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{1024} )
+#
+# Deprecated by enhancedSearchGuide
+olcAttributeTypes: ( 2.5.4.14 NAME 'searchGuide'
+ DESC 'RFC2256: search guide, deprecated by enhancedSearchGuide'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.25 )
+#
+olcAttributeTypes: ( 2.5.4.15 NAME 'businessCategory'
+ DESC 'RFC2256: business category'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{128} )
+#
+olcAttributeTypes: ( 2.5.4.16 NAME 'postalAddress'
+ DESC 'RFC2256: postal address'
+ EQUALITY caseIgnoreListMatch
+ SUBSTR caseIgnoreListSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 )
+#
+olcAttributeTypes: ( 2.5.4.17 NAME 'postalCode'
+ DESC 'RFC2256: postal code'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{40} )
+#
+olcAttributeTypes: ( 2.5.4.18 NAME 'postOfficeBox'
+ DESC 'RFC2256: Post Office Box'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{40} )
+#
+olcAttributeTypes: ( 2.5.4.19 NAME 'physicalDeliveryOfficeName'
+ DESC 'RFC2256: Physical Delivery Office Name'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{128} )
+#
+olcAttributeTypes: ( 2.5.4.20 NAME 'telephoneNumber'
+ DESC 'RFC2256: Telephone Number'
+ EQUALITY telephoneNumberMatch
+ SUBSTR telephoneNumberSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.50{32} )
+#
+olcAttributeTypes: ( 2.5.4.21 NAME 'telexNumber'
+ DESC 'RFC2256: Telex Number'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.52 )
+#
+olcAttributeTypes: ( 2.5.4.22 NAME 'teletexTerminalIdentifier'
+ DESC 'RFC2256: Teletex Terminal Identifier'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.51 )
+#
+olcAttributeTypes: ( 2.5.4.23 NAME ( 'facsimileTelephoneNumber' 'fax' )
+ DESC 'RFC2256: Facsimile (Fax) Telephone Number'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.22 )
+#
+olcAttributeTypes: ( 2.5.4.24 NAME 'x121Address'
+ DESC 'RFC2256: X.121 Address'
+ EQUALITY numericStringMatch
+ SUBSTR numericStringSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.36{15} )
+#
+olcAttributeTypes: ( 2.5.4.25 NAME 'internationaliSDNNumber'
+ DESC 'RFC2256: international ISDN number'
+ EQUALITY numericStringMatch
+ SUBSTR numericStringSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.36{16} )
+#
+olcAttributeTypes: ( 2.5.4.26 NAME 'registeredAddress'
+ DESC 'RFC2256: registered postal address'
+ SUP postalAddress
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 )
+#
+olcAttributeTypes: ( 2.5.4.27 NAME 'destinationIndicator'
+ DESC 'RFC2256: destination indicator'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.44{128} )
+#
+olcAttributeTypes: ( 2.5.4.28 NAME 'preferredDeliveryMethod'
+ DESC 'RFC2256: preferred delivery method'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.14
+ SINGLE-VALUE )
+#
+olcAttributeTypes: ( 2.5.4.29 NAME 'presentationAddress'
+ DESC 'RFC2256: presentation address'
+ EQUALITY presentationAddressMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.43
+ SINGLE-VALUE )
+#
+olcAttributeTypes: ( 2.5.4.30 NAME 'supportedApplicationContext'
+ DESC 'RFC2256: supported application context'
+ EQUALITY objectIdentifierMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
+#
+olcAttributeTypes: ( 2.5.4.31 NAME 'member'
+ DESC 'RFC2256: member of a group'
+ SUP distinguishedName )
+#
+olcAttributeTypes: ( 2.5.4.32 NAME 'owner'
+ DESC 'RFC2256: owner (of the object)'
+ SUP distinguishedName )
+#
+olcAttributeTypes: ( 2.5.4.33 NAME 'roleOccupant'
+ DESC 'RFC2256: occupant of role'
+ SUP distinguishedName )
+#
+# system schema
+#olcAttributeTypes: ( 2.5.4.34 NAME 'seeAlso'
+# DESC 'RFC2256: DN of related object'
+# SUP distinguishedName )
+#
+# system schema
+#olcAttributeTypes: ( 2.5.4.35 NAME 'userPassword'
+# DESC 'RFC2256/2307: password of user'
+# EQUALITY octetStringMatch
+# SYNTAX 1.3.6.1.4.1.1466.115.121.1.40{128} )
+#
+# Must be transferred using ;binary
+# with certificateExactMatch rule (per X.509)
+olcAttributeTypes: ( 2.5.4.36 NAME 'userCertificate'
+ DESC 'RFC2256: X.509 user certificate, use ;binary'
+ EQUALITY certificateExactMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.8 )
+#
+# Must be transferred using ;binary
+# with certificateExactMatch rule (per X.509)
+olcAttributeTypes: ( 2.5.4.37 NAME 'cACertificate'
+ DESC 'RFC2256: X.509 CA certificate, use ;binary'
+ EQUALITY certificateExactMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.8 )
+#
+# Must be transferred using ;binary
+olcAttributeTypes: ( 2.5.4.38 NAME 'authorityRevocationList'
+ DESC 'RFC2256: X.509 authority revocation list, use ;binary'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.9 )
+#
+# Must be transferred using ;binary
+olcAttributeTypes: ( 2.5.4.39 NAME 'certificateRevocationList'
+ DESC 'RFC2256: X.509 certificate revocation list, use ;binary'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.9 )
+#
+# Must be stored and requested in the binary form
+olcAttributeTypes: ( 2.5.4.40 NAME 'crossCertificatePair'
+ DESC 'RFC2256: X.509 cross certificate pair, use ;binary'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.10 )
+#
+# 2.5.4.41 is defined above as it's used for subtyping
+#olcAttributeTypes: ( 2.5.4.41 NAME 'name'
+# EQUALITY caseIgnoreMatch
+# SUBSTR caseIgnoreSubstringsMatch
+# SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} )
+#
+olcAttributeTypes: ( 2.5.4.42 NAME ( 'givenName' 'gn' )
+ DESC 'RFC2256: first name(s) for which the entity is known by'
+ SUP name )
+#
+olcAttributeTypes: ( 2.5.4.43 NAME 'initials'
+ DESC 'RFC2256: initials of some or all of names, but not the surname(s).'
+ SUP name )
+#
+olcAttributeTypes: ( 2.5.4.44 NAME 'generationQualifier'
+ DESC 'RFC2256: name qualifier indicating a generation'
+ SUP name )
+#
+olcAttributeTypes: ( 2.5.4.45 NAME 'x500UniqueIdentifier'
+ DESC 'RFC2256: X.500 unique identifier'
+ EQUALITY bitStringMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 )
+#
+olcAttributeTypes: ( 2.5.4.46 NAME 'dnQualifier'
+ DESC 'RFC2256: DN qualifier'
+ EQUALITY caseIgnoreMatch
+ ORDERING caseIgnoreOrderingMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 )
+#
+olcAttributeTypes: ( 2.5.4.47 NAME 'enhancedSearchGuide'
+ DESC 'RFC2256: enhanced search guide'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.21 )
+#
+olcAttributeTypes: ( 2.5.4.48 NAME 'protocolInformation'
+ DESC 'RFC2256: protocol information'
+ EQUALITY protocolInformationMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.42 )
+#
+# 2.5.4.49 is defined above as it's used for subtyping
+#olcAttributeTypes: ( 2.5.4.49 NAME 'distinguishedName'
+# EQUALITY distinguishedNameMatch
+# SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
+#
+olcAttributeTypes: ( 2.5.4.50 NAME 'uniqueMember'
+ DESC 'RFC2256: unique member of a group'
+ EQUALITY uniqueMemberMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.34 )
+#
+olcAttributeTypes: ( 2.5.4.51 NAME 'houseIdentifier'
+ DESC 'RFC2256: house identifier'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} )
+#
+# Must be transferred using ;binary
+olcAttributeTypes: ( 2.5.4.52 NAME 'supportedAlgorithms'
+ DESC 'RFC2256: supported algorithms'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.49 )
+#
+# Must be transferred using ;binary
+olcAttributeTypes: ( 2.5.4.53 NAME 'deltaRevocationList'
+ DESC 'RFC2256: delta revocation list; use ;binary'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.9 )
+#
+olcAttributeTypes: ( 2.5.4.54 NAME 'dmdName'
+ DESC 'RFC2256: name of DMD'
+ SUP name )
+#
+olcAttributeTypes: ( 2.5.4.65 NAME 'pseudonym'
+ DESC 'X.520(4th): pseudonym for the object'
+ SUP name )
+#
+# Standard object classes from RFC2256
+#
+# system schema
+#olcObjectClasses: ( 2.5.6.1 NAME 'alias'
+# DESC 'RFC2256: an alias'
+# SUP top STRUCTURAL
+# MUST aliasedObjectName )
+#
+olcObjectClasses: ( 2.5.6.2 NAME 'country'
+ DESC 'RFC2256: a country'
+ SUP top STRUCTURAL
+ MUST c
+ MAY ( searchGuide $ description ) )
+#
+olcObjectClasses: ( 2.5.6.3 NAME 'locality'
+ DESC 'RFC2256: a locality'
+ SUP top STRUCTURAL
+ MAY ( street $ seeAlso $ searchGuide $ st $ l $ description ) )
+#
+olcObjectClasses: ( 2.5.6.4 NAME 'organization'
+ DESC 'RFC2256: an organization'
+ SUP top STRUCTURAL
+ MUST o
+ MAY ( userPassword $ searchGuide $ seeAlso $ businessCategory $
+ x121Address $ registeredAddress $ destinationIndicator $
+ preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $
+ telephoneNumber $ internationaliSDNNumber $
+ facsimileTelephoneNumber $ street $ postOfficeBox $ postalCode $
+ postalAddress $ physicalDeliveryOfficeName $ st $ l $ description ) )
+#
+olcObjectClasses: ( 2.5.6.5 NAME 'organizationalUnit'
+ DESC 'RFC2256: an organizational unit'
+ SUP top STRUCTURAL
+ MUST ou
+ MAY ( userPassword $ searchGuide $ seeAlso $ businessCategory $
+ x121Address $ registeredAddress $ destinationIndicator $
+ preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $
+ telephoneNumber $ internationaliSDNNumber $
+ facsimileTelephoneNumber $ street $ postOfficeBox $ postalCode $
+ postalAddress $ physicalDeliveryOfficeName $ st $ l $ description ) )
+#
+olcObjectClasses: ( 2.5.6.6 NAME 'person'
+ DESC 'RFC2256: a person'
+ SUP top STRUCTURAL
+ MUST ( sn $ cn )
+ MAY ( userPassword $ telephoneNumber $ seeAlso $ description ) )
+#
+olcObjectClasses: ( 2.5.6.7 NAME 'organizationalPerson'
+ DESC 'RFC2256: an organizational person'
+ SUP person STRUCTURAL
+ MAY ( title $ x121Address $ registeredAddress $ destinationIndicator $
+ preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $
+ telephoneNumber $ internationaliSDNNumber $
+ facsimileTelephoneNumber $ street $ postOfficeBox $ postalCode $
+ postalAddress $ physicalDeliveryOfficeName $ ou $ st $ l ) )
+#
+olcObjectClasses: ( 2.5.6.8 NAME 'organizationalRole'
+ DESC 'RFC2256: an organizational role'
+ SUP top STRUCTURAL
+ MUST cn
+ MAY ( x121Address $ registeredAddress $ destinationIndicator $
+ preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $
+ telephoneNumber $ internationaliSDNNumber $ facsimileTelephoneNumber $
+ seeAlso $ roleOccupant $ preferredDeliveryMethod $ street $
+ postOfficeBox $ postalCode $ postalAddress $
+ physicalDeliveryOfficeName $ ou $ st $ l $ description ) )
+#
+olcObjectClasses: ( 2.5.6.9 NAME 'groupOfNames'
+ DESC 'RFC2256: a group of names (DNs)'
+ SUP top STRUCTURAL
+ MUST ( member $ cn )
+ MAY ( businessCategory $ seeAlso $ owner $ ou $ o $ description ) )
+#
+olcObjectClasses: ( 2.5.6.10 NAME 'residentialPerson'
+ DESC 'RFC2256: an residential person'
+ SUP person STRUCTURAL
+ MUST l
+ MAY ( businessCategory $ x121Address $ registeredAddress $
+ destinationIndicator $ preferredDeliveryMethod $ telexNumber $
+ teletexTerminalIdentifier $ telephoneNumber $ internationaliSDNNumber $
+ facsimileTelephoneNumber $ preferredDeliveryMethod $ street $
+ postOfficeBox $ postalCode $ postalAddress $
+ physicalDeliveryOfficeName $ st $ l ) )
+#
+olcObjectClasses: ( 2.5.6.11 NAME 'applicationProcess'
+ DESC 'RFC2256: an application process'
+ SUP top STRUCTURAL
+ MUST cn
+ MAY ( seeAlso $ ou $ l $ description ) )
+#
+olcObjectClasses: ( 2.5.6.12 NAME 'applicationEntity'
+ DESC 'RFC2256: an application entity'
+ SUP top STRUCTURAL
+ MUST ( presentationAddress $ cn )
+ MAY ( supportedApplicationContext $ seeAlso $ ou $ o $ l $
+ description ) )
+#
+olcObjectClasses: ( 2.5.6.13 NAME 'dSA'
+ DESC 'RFC2256: a directory system agent (a server)'
+ SUP applicationEntity STRUCTURAL
+ MAY knowledgeInformation )
+#
+olcObjectClasses: ( 2.5.6.14 NAME 'device'
+ DESC 'RFC2256: a device'
+ SUP top STRUCTURAL
+ MUST cn
+ MAY ( serialNumber $ seeAlso $ owner $ ou $ o $ l $ description ) )
+#
+olcObjectClasses: ( 2.5.6.15 NAME 'strongAuthenticationUser'
+ DESC 'RFC2256: a strong authentication user'
+ SUP top AUXILIARY
+ MUST userCertificate )
+#
+olcObjectClasses: ( 2.5.6.16 NAME 'certificationAuthority'
+ DESC 'RFC2256: a certificate authority'
+ SUP top AUXILIARY
+ MUST ( authorityRevocationList $ certificateRevocationList $
+ cACertificate ) MAY crossCertificatePair )
+#
+olcObjectClasses: ( 2.5.6.17 NAME 'groupOfUniqueNames'
+ DESC 'RFC2256: a group of unique names (DN and Unique Identifier)'
+ SUP top STRUCTURAL
+ MUST ( uniqueMember $ cn )
+ MAY ( businessCategory $ seeAlso $ owner $ ou $ o $ description ) )
+#
+olcObjectClasses: ( 2.5.6.18 NAME 'userSecurityInformation'
+ DESC 'RFC2256: a user security information'
+ SUP top AUXILIARY
+ MAY ( supportedAlgorithms ) )
+#
+olcObjectClasses: ( 2.5.6.16.2 NAME 'certificationAuthority-V2'
+ SUP certificationAuthority
+ AUXILIARY MAY ( deltaRevocationList ) )
+#
+olcObjectClasses: ( 2.5.6.19 NAME 'cRLDistributionPoint'
+ SUP top STRUCTURAL
+ MUST ( cn )
+ MAY ( certificateRevocationList $ authorityRevocationList $
+ deltaRevocationList ) )
+#
+olcObjectClasses: ( 2.5.6.20 NAME 'dmd'
+ SUP top STRUCTURAL
+ MUST ( dmdName )
+ MAY ( userPassword $ searchGuide $ seeAlso $ businessCategory $
+ x121Address $ registeredAddress $ destinationIndicator $
+ preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $
+ telephoneNumber $ internationaliSDNNumber $ facsimileTelephoneNumber $
+ street $ postOfficeBox $ postalCode $ postalAddress $
+ physicalDeliveryOfficeName $ st $ l $ description ) )
+#
+#
+# Object Classes from RFC 2587
+#
+olcObjectClasses: ( 2.5.6.21 NAME 'pkiUser'
+ DESC 'RFC2587: a PKI user'
+ SUP top AUXILIARY
+ MAY userCertificate )
+#
+olcObjectClasses: ( 2.5.6.22 NAME 'pkiCA'
+ DESC 'RFC2587: PKI certificate authority'
+ SUP top AUXILIARY
+ MAY ( authorityRevocationList $ certificateRevocationList $
+ cACertificate $ crossCertificatePair ) )
+#
+olcObjectClasses: ( 2.5.6.23 NAME 'deltaCRL'
+ DESC 'RFC2587: PKI user'
+ SUP top AUXILIARY
+ MAY deltaRevocationList )
+#
+#
+# Standard Track URI label schema from RFC 2079
+# system schema
+#olcAttributeTypes: ( 1.3.6.1.4.1.250.1.57 NAME 'labeledURI'
+# DESC 'RFC2079: Uniform Resource Identifier with optional label'
+# EQUALITY caseExactMatch
+# SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+#
+olcObjectClasses: ( 1.3.6.1.4.1.250.3.15 NAME 'labeledURIObject'
+ DESC 'RFC2079: object that contains the URI attribute type'
+ MAY ( labeledURI )
+ SUP top AUXILIARY )
+#
+#
+# Derived from RFC 1274, but with new "short names"
+#
+#olcAttributeTypes: ( 0.9.2342.19200300.100.1.1
+# NAME ( 'uid' 'userid' )
+# DESC 'RFC1274: user identifier'
+# EQUALITY caseIgnoreMatch
+# SUBSTR caseIgnoreSubstringsMatch
+# SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
+#
+olcAttributeTypes: ( 0.9.2342.19200300.100.1.3
+ NAME ( 'mail' 'rfc822Mailbox' )
+ DESC 'RFC1274: RFC822 Mailbox'
+ EQUALITY caseIgnoreIA5Match
+ SUBSTR caseIgnoreIA5SubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} )
+#
+olcObjectClasses: ( 0.9.2342.19200300.100.4.19 NAME 'simpleSecurityObject'
+ DESC 'RFC1274: simple security object'
+ SUP top AUXILIARY
+ MUST userPassword )
+#
+# RFC 1274 + RFC 2247
+olcAttributeTypes: ( 0.9.2342.19200300.100.1.25
+ NAME ( 'dc' 'domainComponent' )
+ DESC 'RFC1274/2247: domain component'
+ EQUALITY caseIgnoreIA5Match
+ SUBSTR caseIgnoreIA5SubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
+#
+# RFC 2247
+olcObjectClasses: ( 1.3.6.1.4.1.1466.344 NAME 'dcObject'
+ DESC 'RFC2247: domain component object'
+ SUP top AUXILIARY MUST dc )
+#
+# RFC 2377
+olcObjectClasses: ( 1.3.6.1.1.3.1 NAME 'uidObject'
+ DESC 'RFC2377: uid object'
+ SUP top AUXILIARY MUST uid )
+#
+# From COSINE Pilot
+olcAttributeTypes: ( 0.9.2342.19200300.100.1.37
+ NAME 'associatedDomain'
+ DESC 'RFC1274: domain associated with object'
+ EQUALITY caseIgnoreIA5Match
+ SUBSTR caseIgnoreIA5SubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
+#
+# RFC 2459 -- deprecated in favor of 'mail' (in cosine.schema)
+olcAttributeTypes: ( 1.2.840.113549.1.9.1
+ NAME ( 'email' 'emailAddress' 'pkcs9email' )
+ DESC 'RFC3280: legacy attribute for email addresses in DNs'
+ EQUALITY caseIgnoreIA5Match
+ SUBSTR caseIgnoreIA5SubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{128} )
+#
Added: openldap/vendor/openldap-release/servers/slapd/schema/core.schema
===================================================================
--- openldap/vendor/openldap-release/servers/slapd/schema/core.schema (rev 0)
+++ openldap/vendor/openldap-release/servers/slapd/schema/core.schema 2007-09-15 10:38:52 UTC (rev 844)
@@ -0,0 +1,591 @@
+# OpenLDAP Core schema
+# $OpenLDAP: pkg/ldap/servers/slapd/schema/core.schema,v 1.79.2.8 2007/01/02 21:44:09 kurt Exp $
+## This work is part of OpenLDAP Software <http://www.openldap.org/>.
+##
+## Copyright 1998-2007 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>.
+#
+## Portions Copyright (C) The Internet Society (1997-2003).
+## All Rights Reserved.
+##
+## This document and translations of it may be copied and furnished to
+## others, and derivative works that comment on or otherwise explain it
+## or assist in its implementation may be prepared, copied, published
+## and distributed, in whole or in part, without restriction of any
+## kind, provided that the above copyright notice and this paragraph are
+## included on all such copies and derivative works. However, this
+## document itself may not be modified in any way, such as by removing
+## the copyright notice or references to the Internet Society or other
+## Internet organizations, except as needed for the purpose of
+## developing Internet standards in which case the procedures for
+## copyrights defined in the Internet Standards process must be
+## followed, or as required to translate it into languages other than
+## English.
+##
+## The limited permissions granted above are perpetual and will not be
+## revoked by the Internet Society or its successors or assigns.
+##
+## This document and the information contained herein is provided on an
+## "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+## TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+## BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+## HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+## MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+#
+#
+# Includes LDAPv3 schema items from:
+# RFC 2252/2256 (LDAPv3)
+#
+# Select standard track schema items:
+# RFC 1274 (uid/dc)
+# RFC 2079 (URI)
+# RFC 2247 (dc/dcObject)
+# RFC 2587 (PKI)
+# RFC 2589 (Dynamic Directory Services)
+#
+# Select informational schema items:
+# RFC 2377 (uidObject)
+
+#
+# Standard attribute types from RFC 2256
+#
+
+# system schema
+#attributetype ( 2.5.4.0 NAME 'objectClass'
+# DESC 'RFC2256: object classes of the entity'
+# EQUALITY objectIdentifierMatch
+# SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
+
+# system schema
+#attributetype ( 2.5.4.1 NAME ( 'aliasedObjectName' 'aliasedEntryName' )
+# DESC 'RFC2256: name of aliased object'
+# EQUALITY distinguishedNameMatch
+# SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE )
+
+attributetype ( 2.5.4.2 NAME 'knowledgeInformation'
+ DESC 'RFC2256: knowledge information'
+ EQUALITY caseIgnoreMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} )
+
+# system schema
+#attributetype ( 2.5.4.3 NAME ( 'cn' 'commonName' )
+# DESC 'RFC2256: common name(s) for which the entity is known by'
+# SUP name )
+
+attributetype ( 2.5.4.4 NAME ( 'sn' 'surname' )
+ DESC 'RFC2256: last (family) name(s) for which the entity is known by'
+ SUP name )
+
+attributetype ( 2.5.4.5 NAME 'serialNumber'
+ DESC 'RFC2256: serial number of the entity'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.44{64} )
+
+attributetype ( 2.5.4.6 NAME ( 'c' 'countryName' )
+ DESC 'RFC2256: ISO-3166 country 2-letter code'
+ SUP name SINGLE-VALUE )
+
+attributetype ( 2.5.4.7 NAME ( 'l' 'localityName' )
+ DESC 'RFC2256: locality which this object resides in'
+ SUP name )
+
+attributetype ( 2.5.4.8 NAME ( 'st' 'stateOrProvinceName' )
+ DESC 'RFC2256: state or province which this object resides in'
+ SUP name )
+
+attributetype ( 2.5.4.9 NAME ( 'street' 'streetAddress' )
+ DESC 'RFC2256: street address of this object'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{128} )
+
+attributetype ( 2.5.4.10 NAME ( 'o' 'organizationName' )
+ DESC 'RFC2256: organization this object belongs to'
+ SUP name )
+
+attributetype ( 2.5.4.11 NAME ( 'ou' 'organizationalUnitName' )
+ DESC 'RFC2256: organizational unit this object belongs to'
+ SUP name )
+
+attributetype ( 2.5.4.12 NAME 'title'
+ DESC 'RFC2256: title associated with the entity'
+ SUP name )
+
+# system schema
+#attributetype ( 2.5.4.13 NAME 'description'
+# DESC 'RFC2256: descriptive information'
+# EQUALITY caseIgnoreMatch
+# SUBSTR caseIgnoreSubstringsMatch
+# SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{1024} )
+
+# Deprecated by enhancedSearchGuide
+attributetype ( 2.5.4.14 NAME 'searchGuide'
+ DESC 'RFC2256: search guide, deprecated by enhancedSearchGuide'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.25 )
+
+attributetype ( 2.5.4.15 NAME 'businessCategory'
+ DESC 'RFC2256: business category'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{128} )
+
+attributetype ( 2.5.4.16 NAME 'postalAddress'
+ DESC 'RFC2256: postal address'
+ EQUALITY caseIgnoreListMatch
+ SUBSTR caseIgnoreListSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 )
+
+attributetype ( 2.5.4.17 NAME 'postalCode'
+ DESC 'RFC2256: postal code'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{40} )
+
+attributetype ( 2.5.4.18 NAME 'postOfficeBox'
+ DESC 'RFC2256: Post Office Box'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{40} )
+
+attributetype ( 2.5.4.19 NAME 'physicalDeliveryOfficeName'
+ DESC 'RFC2256: Physical Delivery Office Name'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{128} )
+
+attributetype ( 2.5.4.20 NAME 'telephoneNumber'
+ DESC 'RFC2256: Telephone Number'
+ EQUALITY telephoneNumberMatch
+ SUBSTR telephoneNumberSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.50{32} )
+
+attributetype ( 2.5.4.21 NAME 'telexNumber'
+ DESC 'RFC2256: Telex Number'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.52 )
+
+attributetype ( 2.5.4.22 NAME 'teletexTerminalIdentifier'
+ DESC 'RFC2256: Teletex Terminal Identifier'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.51 )
+
+attributetype ( 2.5.4.23 NAME ( 'facsimileTelephoneNumber' 'fax' )
+ DESC 'RFC2256: Facsimile (Fax) Telephone Number'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.22 )
+
+attributetype ( 2.5.4.24 NAME 'x121Address'
+ DESC 'RFC2256: X.121 Address'
+ EQUALITY numericStringMatch
+ SUBSTR numericStringSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.36{15} )
+
+attributetype ( 2.5.4.25 NAME 'internationaliSDNNumber'
+ DESC 'RFC2256: international ISDN number'
+ EQUALITY numericStringMatch
+ SUBSTR numericStringSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.36{16} )
+
+attributetype ( 2.5.4.26 NAME 'registeredAddress'
+ DESC 'RFC2256: registered postal address'
+ SUP postalAddress
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 )
+
+attributetype ( 2.5.4.27 NAME 'destinationIndicator'
+ DESC 'RFC2256: destination indicator'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.44{128} )
+
+attributetype ( 2.5.4.28 NAME 'preferredDeliveryMethod'
+ DESC 'RFC2256: preferred delivery method'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.14
+ SINGLE-VALUE )
+
+attributetype ( 2.5.4.29 NAME 'presentationAddress'
+ DESC 'RFC2256: presentation address'
+ EQUALITY presentationAddressMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.43
+ SINGLE-VALUE )
+
+attributetype ( 2.5.4.30 NAME 'supportedApplicationContext'
+ DESC 'RFC2256: supported application context'
+ EQUALITY objectIdentifierMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
+
+attributetype ( 2.5.4.31 NAME 'member'
+ DESC 'RFC2256: member of a group'
+ SUP distinguishedName )
+
+attributetype ( 2.5.4.32 NAME 'owner'
+ DESC 'RFC2256: owner (of the object)'
+ SUP distinguishedName )
+
+attributetype ( 2.5.4.33 NAME 'roleOccupant'
+ DESC 'RFC2256: occupant of role'
+ SUP distinguishedName )
+
+# system schema
+#attributetype ( 2.5.4.34 NAME 'seeAlso'
+# DESC 'RFC2256: DN of related object'
+# SUP distinguishedName )
+
+# system schema
+#attributetype ( 2.5.4.35 NAME 'userPassword'
+# DESC 'RFC2256/2307: password of user'
+# EQUALITY octetStringMatch
+# SYNTAX 1.3.6.1.4.1.1466.115.121.1.40{128} )
+
+# Must be transferred using ;binary
+# with certificateExactMatch rule (per X.509)
+attributetype ( 2.5.4.36 NAME 'userCertificate'
+ DESC 'RFC2256: X.509 user certificate, use ;binary'
+ EQUALITY certificateExactMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.8 )
+
+# Must be transferred using ;binary
+# with certificateExactMatch rule (per X.509)
+attributetype ( 2.5.4.37 NAME 'cACertificate'
+ DESC 'RFC2256: X.509 CA certificate, use ;binary'
+ EQUALITY certificateExactMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.8 )
+
+# Must be transferred using ;binary
+attributetype ( 2.5.4.38 NAME 'authorityRevocationList'
+ DESC 'RFC2256: X.509 authority revocation list, use ;binary'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.9 )
+
+# Must be transferred using ;binary
+attributetype ( 2.5.4.39 NAME 'certificateRevocationList'
+ DESC 'RFC2256: X.509 certificate revocation list, use ;binary'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.9 )
+
+# Must be stored and requested in the binary form
+attributetype ( 2.5.4.40 NAME 'crossCertificatePair'
+ DESC 'RFC2256: X.509 cross certificate pair, use ;binary'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.10 )
+
+# system schema
+#attributetype ( 2.5.4.41 NAME 'name'
+# EQUALITY caseIgnoreMatch
+# SUBSTR caseIgnoreSubstringsMatch
+# SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} )
+
+attributetype ( 2.5.4.42 NAME ( 'givenName' 'gn' )
+ DESC 'RFC2256: first name(s) for which the entity is known by'
+ SUP name )
+
+attributetype ( 2.5.4.43 NAME 'initials'
+ DESC 'RFC2256: initials of some or all of names, but not the surname(s).'
+ SUP name )
+
+attributetype ( 2.5.4.44 NAME 'generationQualifier'
+ DESC 'RFC2256: name qualifier indicating a generation'
+ SUP name )
+
+attributetype ( 2.5.4.45 NAME 'x500UniqueIdentifier'
+ DESC 'RFC2256: X.500 unique identifier'
+ EQUALITY bitStringMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 )
+
+attributetype ( 2.5.4.46 NAME 'dnQualifier'
+ DESC 'RFC2256: DN qualifier'
+ EQUALITY caseIgnoreMatch
+ ORDERING caseIgnoreOrderingMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 )
+
+attributetype ( 2.5.4.47 NAME 'enhancedSearchGuide'
+ DESC 'RFC2256: enhanced search guide'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.21 )
+
+attributetype ( 2.5.4.48 NAME 'protocolInformation'
+ DESC 'RFC2256: protocol information'
+ EQUALITY protocolInformationMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.42 )
+
+# system schema
+#attributetype ( 2.5.4.49 NAME 'distinguishedName'
+# EQUALITY distinguishedNameMatch
+# SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
+
+attributetype ( 2.5.4.50 NAME 'uniqueMember'
+ DESC 'RFC2256: unique member of a group'
+ EQUALITY uniqueMemberMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.34 )
+
+attributetype ( 2.5.4.51 NAME 'houseIdentifier'
+ DESC 'RFC2256: house identifier'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} )
+
+# Must be transferred using ;binary
+attributetype ( 2.5.4.52 NAME 'supportedAlgorithms'
+ DESC 'RFC2256: supported algorithms'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.49 )
+
+# Must be transferred using ;binary
+attributetype ( 2.5.4.53 NAME 'deltaRevocationList'
+ DESC 'RFC2256: delta revocation list; use ;binary'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.9 )
+
+attributetype ( 2.5.4.54 NAME 'dmdName'
+ DESC 'RFC2256: name of DMD'
+ SUP name )
+
+attributetype ( 2.5.4.65 NAME 'pseudonym'
+ DESC 'X.520(4th): pseudonym for the object'
+ SUP name )
+
+# Standard object classes from RFC2256
+
+# system schema
+#objectclass ( 2.5.6.0 NAME 'top'
+# DESC 'RFC2256: top of the superclass chain'
+# ABSTRACT
+# MUST objectClass )
+
+# system schema
+#objectclass ( 2.5.6.1 NAME 'alias'
+# DESC 'RFC2256: an alias'
+# SUP top STRUCTURAL
+# MUST aliasedObjectName )
+
+objectclass ( 2.5.6.2 NAME 'country'
+ DESC 'RFC2256: a country'
+ SUP top STRUCTURAL
+ MUST c
+ MAY ( searchGuide $ description ) )
+
+objectclass ( 2.5.6.3 NAME 'locality'
+ DESC 'RFC2256: a locality'
+ SUP top STRUCTURAL
+ MAY ( street $ seeAlso $ searchGuide $ st $ l $ description ) )
+
+objectclass ( 2.5.6.4 NAME 'organization'
+ DESC 'RFC2256: an organization'
+ SUP top STRUCTURAL
+ MUST o
+ MAY ( userPassword $ searchGuide $ seeAlso $ businessCategory $
+ x121Address $ registeredAddress $ destinationIndicator $
+ preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $
+ telephoneNumber $ internationaliSDNNumber $
+ facsimileTelephoneNumber $ street $ postOfficeBox $ postalCode $
+ postalAddress $ physicalDeliveryOfficeName $ st $ l $ description ) )
+
+objectclass ( 2.5.6.5 NAME 'organizationalUnit'
+ DESC 'RFC2256: an organizational unit'
+ SUP top STRUCTURAL
+ MUST ou
+ MAY ( userPassword $ searchGuide $ seeAlso $ businessCategory $
+ x121Address $ registeredAddress $ destinationIndicator $
+ preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $
+ telephoneNumber $ internationaliSDNNumber $
+ facsimileTelephoneNumber $ street $ postOfficeBox $ postalCode $
+ postalAddress $ physicalDeliveryOfficeName $ st $ l $ description ) )
+
+objectclass ( 2.5.6.6 NAME 'person'
+ DESC 'RFC2256: a person'
+ SUP top STRUCTURAL
+ MUST ( sn $ cn )
+ MAY ( userPassword $ telephoneNumber $ seeAlso $ description ) )
+
+objectclass ( 2.5.6.7 NAME 'organizationalPerson'
+ DESC 'RFC2256: an organizational person'
+ SUP person STRUCTURAL
+ MAY ( title $ x121Address $ registeredAddress $ destinationIndicator $
+ preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $
+ telephoneNumber $ internationaliSDNNumber $
+ facsimileTelephoneNumber $ street $ postOfficeBox $ postalCode $
+ postalAddress $ physicalDeliveryOfficeName $ ou $ st $ l ) )
+
+objectclass ( 2.5.6.8 NAME 'organizationalRole'
+ DESC 'RFC2256: an organizational role'
+ SUP top STRUCTURAL
+ MUST cn
+ MAY ( x121Address $ registeredAddress $ destinationIndicator $
+ preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $
+ telephoneNumber $ internationaliSDNNumber $ facsimileTelephoneNumber $
+ seeAlso $ roleOccupant $ preferredDeliveryMethod $ street $
+ postOfficeBox $ postalCode $ postalAddress $
+ physicalDeliveryOfficeName $ ou $ st $ l $ description ) )
+
+objectclass ( 2.5.6.9 NAME 'groupOfNames'
+ DESC 'RFC2256: a group of names (DNs)'
+ SUP top STRUCTURAL
+ MUST ( member $ cn )
+ MAY ( businessCategory $ seeAlso $ owner $ ou $ o $ description ) )
+
+objectclass ( 2.5.6.10 NAME 'residentialPerson'
+ DESC 'RFC2256: an residential person'
+ SUP person STRUCTURAL
+ MUST l
+ MAY ( businessCategory $ x121Address $ registeredAddress $
+ destinationIndicator $ preferredDeliveryMethod $ telexNumber $
+ teletexTerminalIdentifier $ telephoneNumber $ internationaliSDNNumber $
+ facsimileTelephoneNumber $ preferredDeliveryMethod $ street $
+ postOfficeBox $ postalCode $ postalAddress $
+ physicalDeliveryOfficeName $ st $ l ) )
+
+objectclass ( 2.5.6.11 NAME 'applicationProcess'
+ DESC 'RFC2256: an application process'
+ SUP top STRUCTURAL
+ MUST cn
+ MAY ( seeAlso $ ou $ l $ description ) )
+
+objectclass ( 2.5.6.12 NAME 'applicationEntity'
+ DESC 'RFC2256: an application entity'
+ SUP top STRUCTURAL
+ MUST ( presentationAddress $ cn )
+ MAY ( supportedApplicationContext $ seeAlso $ ou $ o $ l $
+ description ) )
+
+objectclass ( 2.5.6.13 NAME 'dSA'
+ DESC 'RFC2256: a directory system agent (a server)'
+ SUP applicationEntity STRUCTURAL
+ MAY knowledgeInformation )
+
+objectclass ( 2.5.6.14 NAME 'device'
+ DESC 'RFC2256: a device'
+ SUP top STRUCTURAL
+ MUST cn
+ MAY ( serialNumber $ seeAlso $ owner $ ou $ o $ l $ description ) )
+
+objectclass ( 2.5.6.15 NAME 'strongAuthenticationUser'
+ DESC 'RFC2256: a strong authentication user'
+ SUP top AUXILIARY
+ MUST userCertificate )
+
+objectclass ( 2.5.6.16 NAME 'certificationAuthority'
+ DESC 'RFC2256: a certificate authority'
+ SUP top AUXILIARY
+ MUST ( authorityRevocationList $ certificateRevocationList $
+ cACertificate ) MAY crossCertificatePair )
+
+objectclass ( 2.5.6.17 NAME 'groupOfUniqueNames'
+ DESC 'RFC2256: a group of unique names (DN and Unique Identifier)'
+ SUP top STRUCTURAL
+ MUST ( uniqueMember $ cn )
+ MAY ( businessCategory $ seeAlso $ owner $ ou $ o $ description ) )
+
+objectclass ( 2.5.6.18 NAME 'userSecurityInformation'
+ DESC 'RFC2256: a user security information'
+ SUP top AUXILIARY
+ MAY ( supportedAlgorithms ) )
+
+objectclass ( 2.5.6.16.2 NAME 'certificationAuthority-V2'
+ SUP certificationAuthority
+ AUXILIARY MAY ( deltaRevocationList ) )
+
+objectclass ( 2.5.6.19 NAME 'cRLDistributionPoint'
+ SUP top STRUCTURAL
+ MUST ( cn )
+ MAY ( certificateRevocationList $ authorityRevocationList $
+ deltaRevocationList ) )
+
+objectclass ( 2.5.6.20 NAME 'dmd'
+ SUP top STRUCTURAL
+ MUST ( dmdName )
+ MAY ( userPassword $ searchGuide $ seeAlso $ businessCategory $
+ x121Address $ registeredAddress $ destinationIndicator $
+ preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $
+ telephoneNumber $ internationaliSDNNumber $ facsimileTelephoneNumber $
+ street $ postOfficeBox $ postalCode $ postalAddress $
+ physicalDeliveryOfficeName $ st $ l $ description ) )
+
+#
+# Object Classes from RFC 2587
+#
+objectclass ( 2.5.6.21 NAME 'pkiUser'
+ DESC 'RFC2587: a PKI user'
+ SUP top AUXILIARY
+ MAY userCertificate )
+
+objectclass ( 2.5.6.22 NAME 'pkiCA'
+ DESC 'RFC2587: PKI certificate authority'
+ SUP top AUXILIARY
+ MAY ( authorityRevocationList $ certificateRevocationList $
+ cACertificate $ crossCertificatePair ) )
+
+objectclass ( 2.5.6.23 NAME 'deltaCRL'
+ DESC 'RFC2587: PKI user'
+ SUP top AUXILIARY
+ MAY deltaRevocationList )
+
+#
+# Standard Track URI label schema from RFC 2079
+# system schema
+#attributetype ( 1.3.6.1.4.1.250.1.57 NAME 'labeledURI'
+# DESC 'RFC2079: Uniform Resource Identifier with optional label'
+# EQUALITY caseExactMatch
+# SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+objectclass ( 1.3.6.1.4.1.250.3.15 NAME 'labeledURIObject'
+ DESC 'RFC2079: object that contains the URI attribute type'
+ SUP top AUXILIARY
+ MAY ( labeledURI ) )
+
+#
+# Derived from RFC 1274, but with new "short names"
+#
+#attributetype ( 0.9.2342.19200300.100.1.1
+# NAME ( 'uid' 'userid' )
+# DESC 'RFC1274: user identifier'
+# EQUALITY caseIgnoreMatch
+# SUBSTR caseIgnoreSubstringsMatch
+# SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
+
+attributetype ( 0.9.2342.19200300.100.1.3
+ NAME ( 'mail' 'rfc822Mailbox' )
+ DESC 'RFC1274: RFC822 Mailbox'
+ EQUALITY caseIgnoreIA5Match
+ SUBSTR caseIgnoreIA5SubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} )
+
+objectclass ( 0.9.2342.19200300.100.4.19 NAME 'simpleSecurityObject'
+ DESC 'RFC1274: simple security object'
+ SUP top AUXILIARY
+ MUST userPassword )
+
+# RFC 1274 + RFC 2247
+attributetype ( 0.9.2342.19200300.100.1.25
+ NAME ( 'dc' 'domainComponent' )
+ DESC 'RFC1274/2247: domain component'
+ EQUALITY caseIgnoreIA5Match
+ SUBSTR caseIgnoreIA5SubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
+
+# RFC 2247
+objectclass ( 1.3.6.1.4.1.1466.344 NAME 'dcObject'
+ DESC 'RFC2247: domain component object'
+ SUP top AUXILIARY MUST dc )
+
+# RFC 2377
+objectclass ( 1.3.6.1.1.3.1 NAME 'uidObject'
+ DESC 'RFC2377: uid object'
+ SUP top AUXILIARY MUST uid )
+
+# From COSINE Pilot
+attributetype ( 0.9.2342.19200300.100.1.37
+ NAME 'associatedDomain'
+ DESC 'RFC1274: domain associated with object'
+ EQUALITY caseIgnoreIA5Match
+ SUBSTR caseIgnoreIA5SubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
+
+# RFC 2459 -- deprecated in favor of 'mail' (in cosine.schema)
+attributetype ( 1.2.840.113549.1.9.1
+ NAME ( 'email' 'emailAddress' 'pkcs9email' )
+ DESC 'RFC3280: legacy attribute for email addresses in DNs'
+ EQUALITY caseIgnoreIA5Match
+ SUBSTR caseIgnoreIA5SubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{128} )
+
Added: openldap/vendor/openldap-release/servers/slapd/schema/cosine.schema
===================================================================
--- openldap/vendor/openldap-release/servers/slapd/schema/cosine.schema (rev 0)
+++ openldap/vendor/openldap-release/servers/slapd/schema/cosine.schema 2007-09-15 10:38:52 UTC (rev 844)
@@ -0,0 +1,2571 @@
+# RFC1274: Cosine and Internet X.500 schema
+# $OpenLDAP: pkg/ldap/servers/slapd/schema/cosine.schema,v 1.19.2.5 2007/01/02 21:44:09 kurt Exp $
+## This work is part of OpenLDAP Software <http://www.openldap.org/>.
+##
+## Copyright 1998-2007 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>.
+#
+# RFC1274: Cosine and Internet X.500 schema
+#
+# This file contains LDAPv3 schema derived from X.500 COSINE "pilot"
+# schema. As this schema was defined for X.500(89), some
+# oddities were introduced in the mapping to LDAPv3. The
+# mappings were based upon: draft-ietf-asid-ldapv3-attributes-03.txt
+# (a work in progress)
+#
+# Note: It seems that the pilot schema evolved beyond what was
+# described in RFC1274. However, this document attempts to describes
+# RFC1274 as published.
+#
+# Depends on core.schema
+
+
+# Network Working Group P. Barker
+# Request for Comments: 1274 S. Kille
+# University College London
+# November 1991
+#
+# The COSINE and Internet X.500 Schema
+#
+# [trimmed]
+#
+# Abstract
+#
+# This document suggests an X.500 Directory Schema, or Naming
+# Architecture, for use in the COSINE and Internet X.500 pilots. The
+# schema is independent of any specific implementation. As well as
+# indicating support for the standard object classes and attributes, a
+# large number of generally useful object classes and attributes are
+# also defined. An appendix to this document includes a machine
+# processable version of the schema.
+#
+# [trimmed]
+
+# 7. Object Identifiers
+#
+# Some additional object identifiers are defined for this schema.
+# These are also reproduced in Appendix C.
+#
+# data OBJECT IDENTIFIER ::= {ccitt 9}
+# pss OBJECT IDENTIFIER ::= {data 2342}
+# ucl OBJECT IDENTIFIER ::= {pss 19200300}
+# pilot OBJECT IDENTIFIER ::= {ucl 100}
+#
+# pilotAttributeType OBJECT IDENTIFIER ::= {pilot 1}
+# pilotAttributeSyntax OBJECT IDENTIFIER ::= {pilot 3}
+# pilotObjectClass OBJECT IDENTIFIER ::= {pilot 4}
+# pilotGroups OBJECT IDENTIFIER ::= {pilot 10}
+#
+# iA5StringSyntax OBJECT IDENTIFIER ::= {pilotAttributeSyntax 4}
+# caseIgnoreIA5StringSyntax OBJECT IDENTIFIER ::=
+# {pilotAttributeSyntax 5}
+#
+# 8. Object Classes
+# [relocated after 9]
+
+#
+# 9. Attribute Types
+#
+# 9.1. X.500 standard attribute types
+#
+# A number of generally useful attribute types are defined in X.520,
+# and these are supported. Refer to that document for descriptions of
+# the suggested usage of these attribute types. The ASN.1 for these
+# attribute types is reproduced for completeness in Appendix C.
+#
+# 9.2. X.400 standard attribute types
+#
+# The standard X.400 attribute types are supported. See X.402 for full
+# details. The ASN.1 for these attribute types is reproduced in
+# Appendix C.
+#
+# 9.3. COSINE/Internet attribute types
+#
+# This section describes all the attribute types defined for use in the
+# COSINE and Internet pilots. Descriptions are given as to the
+# suggested usage of these attribute types. The ASN.1 for these
+# attribute types is reproduced in Appendix C.
+#
+# 9.3.1. Userid
+#
+# The Userid attribute type specifies a computer system login name.
+#
+# userid ATTRIBUTE
+# WITH ATTRIBUTE-SYNTAX
+# caseIgnoreStringSyntax
+# (SIZE (1 .. ub-user-identifier))
+# ::= {pilotAttributeType 1}
+#
+#(in core.schema)
+##attributetype ( 0.9.2342.19200300.100.1.1 NAME ( 'uid' 'userid' )
+## EQUALITY caseIgnoreMatch
+## SUBSTR caseIgnoreSubstringsMatch
+## SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
+
+# 9.3.2. Text Encoded O/R Address
+#
+# The Text Encoded O/R Address attribute type specifies a text encoding
+# of an X.400 O/R address, as specified in RFC 987. The use of this
+# attribute is deprecated as the attribute is intended for interim use
+# only. This attribute will be the first candidate for the attribute
+# expiry mechanisms!
+#
+# textEncodedORAddress ATTRIBUTE
+# WITH ATTRIBUTE-SYNTAX
+# caseIgnoreStringSyntax
+# (SIZE (1 .. ub-text-encoded-or-address))
+# ::= {pilotAttributeType 2}
+#
+attributetype ( 0.9.2342.19200300.100.1.2 NAME 'textEncodedORAddress'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
+
+# 9.3.3. RFC 822 Mailbox
+#
+# The RFC822 Mailbox attribute type specifies an electronic mailbox
+# attribute following the syntax specified in RFC 822. Note that this
+# attribute should not be used for greybook or other non-Internet order
+# mailboxes.
+#
+# rfc822Mailbox ATTRIBUTE
+# WITH ATTRIBUTE-SYNTAX
+# caseIgnoreIA5StringSyntax
+# (SIZE (1 .. ub-rfc822-mailbox))
+# ::= {pilotAttributeType 3}
+#
+#(in core.schema)
+##attributetype ( 0.9.2342.19200300.100.1.3 NAME ( 'mail' 'rfc822Mailbox' )
+## EQUALITY caseIgnoreIA5Match
+## SUBSTR caseIgnoreIA5SubstringsMatch
+## SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} )
+
+# 9.3.4. Information
+#
+# The Information attribute type specifies any general information
+# pertinent to an object. It is recommended that specific usage of
+# this attribute type is avoided, and that specific requirements are
+# met by other (possibly additional) attribute types.
+#
+# info ATTRIBUTE
+# WITH ATTRIBUTE-SYNTAX
+# caseIgnoreStringSyntax
+# (SIZE (1 .. ub-information))
+# ::= {pilotAttributeType 4}
+#
+attributetype ( 0.9.2342.19200300.100.1.4 NAME 'info'
+ DESC 'RFC1274: general information'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{2048} )
+
+
+# 9.3.5. Favourite Drink
+#
+# The Favourite Drink attribute type specifies the favourite drink of
+# an object (or person).
+#
+# favouriteDrink ATTRIBUTE
+# WITH ATTRIBUTE-SYNTAX
+# caseIgnoreStringSyntax
+# (SIZE (1 .. ub-favourite-drink))
+# ::= {pilotAttributeType 5}
+#
+attributetype ( 0.9.2342.19200300.100.1.5
+ NAME ( 'drink' 'favouriteDrink' )
+ DESC 'RFC1274: favorite drink'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
+
+# 9.3.6. Room Number
+#
+# The Room Number attribute type specifies the room number of an
+# object. Note that the commonName attribute should be used for naming
+# room objects.
+#
+# roomNumber ATTRIBUTE
+# WITH ATTRIBUTE-SYNTAX
+# caseIgnoreStringSyntax
+# (SIZE (1 .. ub-room-number))
+# ::= {pilotAttributeType 6}
+#
+attributetype ( 0.9.2342.19200300.100.1.6 NAME 'roomNumber'
+ DESC 'RFC1274: room number'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
+
+# 9.3.7. Photo
+#
+# The Photo attribute type specifies a "photograph" for an object.
+# This should be encoded in G3 fax as explained in recommendation T.4,
+# with an ASN.1 wrapper to make it compatible with an X.400 BodyPart as
+# defined in X.420.
+#
+# IMPORT G3FacsimileBodyPart FROM { mhs-motis ipms modules
+# information-objects }
+#
+# photo ATTRIBUTE
+# WITH ATTRIBUTE-SYNTAX
+# CHOICE {
+# g3-facsimile [3] G3FacsimileBodyPart
+# }
+# (SIZE (1 .. ub-photo))
+# ::= {pilotAttributeType 7}
+#
+attributetype ( 0.9.2342.19200300.100.1.7 NAME 'photo'
+ DESC 'RFC1274: photo (G3 fax)'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.23{25000} )
+
+# 9.3.8. User Class
+#
+# The User Class attribute type specifies a category of computer user.
+# The semantics placed on this attribute are for local interpretation.
+# Examples of current usage od this attribute in academia are
+# undergraduate student, researcher, lecturer, etc. Note that the
+# organizationalStatus attribute may now often be preferred as it makes
+# no distinction between computer users and others.
+#
+# userClass ATTRIBUTE
+# WITH ATTRIBUTE-SYNTAX
+# caseIgnoreStringSyntax
+# (SIZE (1 .. ub-user-class))
+# ::= {pilotAttributeType 8}
+#
+attributetype ( 0.9.2342.19200300.100.1.8 NAME 'userClass'
+ DESC 'RFC1274: category of user'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
+
+# 9.3.9. Host
+#
+# The Host attribute type specifies a host computer.
+#
+# host ATTRIBUTE
+# WITH ATTRIBUTE-SYNTAX
+# caseIgnoreStringSyntax
+# (SIZE (1 .. ub-host))
+# ::= {pilotAttributeType 9}
+#
+attributetype ( 0.9.2342.19200300.100.1.9 NAME 'host'
+ DESC 'RFC1274: host computer'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
+
+# 9.3.10. Manager
+#
+# The Manager attribute type specifies the manager of an object
+# represented by an entry.
+#
+# manager ATTRIBUTE
+# WITH ATTRIBUTE-SYNTAX
+# distinguishedNameSyntax
+# ::= {pilotAttributeType 10}
+#
+attributetype ( 0.9.2342.19200300.100.1.10 NAME 'manager'
+ DESC 'RFC1274: DN of manager'
+ EQUALITY distinguishedNameMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
+
+# 9.3.11. Document Identifier
+#
+# The Document Identifier attribute type specifies a unique identifier
+# for a document.
+#
+# documentIdentifier ATTRIBUTE
+# WITH ATTRIBUTE-SYNTAX
+# caseIgnoreStringSyntax
+# (SIZE (1 .. ub-document-identifier))
+# ::= {pilotAttributeType 11}
+#
+attributetype ( 0.9.2342.19200300.100.1.11 NAME 'documentIdentifier'
+ DESC 'RFC1274: unique identifier of document'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
+
+# 9.3.12. Document Title
+#
+# The Document Title attribute type specifies the title of a document.
+#
+# documentTitle ATTRIBUTE
+# WITH ATTRIBUTE-SYNTAX
+# caseIgnoreStringSyntax
+# (SIZE (1 .. ub-document-title))
+# ::= {pilotAttributeType 12}
+#
+attributetype ( 0.9.2342.19200300.100.1.12 NAME 'documentTitle'
+ DESC 'RFC1274: title of document'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
+
+# 9.3.13. Document Version
+#
+# The Document Version attribute type specifies the version number of a
+# document.
+#
+# documentVersion ATTRIBUTE
+# WITH ATTRIBUTE-SYNTAX
+# caseIgnoreStringSyntax
+# (SIZE (1 .. ub-document-version))
+# ::= {pilotAttributeType 13}
+#
+attributetype ( 0.9.2342.19200300.100.1.13 NAME 'documentVersion'
+ DESC 'RFC1274: version of document'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
+
+# 9.3.14. Document Author
+#
+# The Document Author attribute type specifies the distinguished name
+# of the author of a document.
+#
+# documentAuthor ATTRIBUTE
+# WITH ATTRIBUTE-SYNTAX
+# distinguishedNameSyntax
+# ::= {pilotAttributeType 14}
+#
+attributetype ( 0.9.2342.19200300.100.1.14 NAME 'documentAuthor'
+ DESC 'RFC1274: DN of author of document'
+ EQUALITY distinguishedNameMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
+
+# 9.3.15. Document Location
+#
+# The Document Location attribute type specifies the location of the
+# document original.
+#
+# documentLocation ATTRIBUTE
+# WITH ATTRIBUTE-SYNTAX
+# caseIgnoreStringSyntax
+# (SIZE (1 .. ub-document-location))
+# ::= {pilotAttributeType 15}
+#
+attributetype ( 0.9.2342.19200300.100.1.15 NAME 'documentLocation'
+ DESC 'RFC1274: location of document original'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
+
+# 9.3.16. Home Telephone Number
+#
+# The Home Telephone Number attribute type specifies a home telephone
+# number associated with a person. Attribute values should follow the
+# agreed format for international telephone numbers: i.e., "+44 71 123
+# 4567".
+#
+# homeTelephoneNumber ATTRIBUTE
+# WITH ATTRIBUTE-SYNTAX
+# telephoneNumberSyntax
+# ::= {pilotAttributeType 20}
+#
+attributetype ( 0.9.2342.19200300.100.1.20
+ NAME ( 'homePhone' 'homeTelephoneNumber' )
+ DESC 'RFC1274: home telephone number'
+ EQUALITY telephoneNumberMatch
+ SUBSTR telephoneNumberSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 )
+
+# 9.3.17. Secretary
+#
+# The Secretary attribute type specifies the secretary of a person.
+# The attribute value for Secretary is a distinguished name.
+#
+# secretary ATTRIBUTE
+# WITH ATTRIBUTE-SYNTAX
+# distinguishedNameSyntax
+# ::= {pilotAttributeType 21}
+#
+attributetype ( 0.9.2342.19200300.100.1.21 NAME 'secretary'
+ DESC 'RFC1274: DN of secretary'
+ EQUALITY distinguishedNameMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
+
+# 9.3.18. Other Mailbox
+#
+# The Other Mailbox attribute type specifies values for electronic
+# mailbox types other than X.400 and rfc822.
+#
+# otherMailbox ATTRIBUTE
+# WITH ATTRIBUTE-SYNTAX
+# SEQUENCE {
+# mailboxType PrintableString, -- e.g. Telemail
+# mailbox IA5String -- e.g. X378:Joe
+# }
+# ::= {pilotAttributeType 22}
+#
+attributetype ( 0.9.2342.19200300.100.1.22 NAME 'otherMailbox'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.39 )
+
+# 9.3.19. Last Modified Time
+#
+# The Last Modified Time attribute type specifies the last time, in UTC
+# time, that an entry was modified. Ideally, this attribute should be
+# maintained by the DSA.
+#
+# lastModifiedTime ATTRIBUTE
+# WITH ATTRIBUTE-SYNTAX
+# uTCTimeSyntax
+# ::= {pilotAttributeType 23}
+#
+## Deprecated in favor of modifyTimeStamp
+#attributetype ( 0.9.2342.19200300.100.1.23 NAME 'lastModifiedTime'
+# DESC 'RFC1274: time of last modify, replaced by modifyTimestamp'
+# OBSOLETE
+# SYNTAX 1.3.6.1.4.1.1466.115.121.1.53
+# USAGE directoryOperation )
+
+# 9.3.20. Last Modified By
+#
+# The Last Modified By attribute specifies the distinguished name of
+# the last user to modify the associated entry. Ideally, this
+# attribute should be maintained by the DSA.
+#
+# lastModifiedBy ATTRIBUTE
+# WITH ATTRIBUTE-SYNTAX
+# distinguishedNameSyntax
+# ::= {pilotAttributeType 24}
+#
+## Deprecated in favor of modifiersName
+#attributetype ( 0.9.2342.19200300.100.1.24 NAME 'lastModifiedBy'
+# DESC 'RFC1274: last modifier, replaced by modifiersName'
+# OBSOLETE
+# EQUALITY distinguishedNameMatch
+# SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
+# USAGE directoryOperation )
+
+# 9.3.21. Domain Component
+#
+# The Domain Component attribute type specifies a DNS/NRS domain. For
+# example, "uk" or "ac".
+#
+# domainComponent ATTRIBUTE
+# WITH ATTRIBUTE-SYNTAX
+# caseIgnoreIA5StringSyntax
+# SINGLE VALUE
+# ::= {pilotAttributeType 25}
+#
+##(in core.schema)
+##attributetype ( 0.9.2342.19200300.100.1.25 NAME ( 'dc' 'domainComponent' )
+## EQUALITY caseIgnoreIA5Match
+## SUBSTR caseIgnoreIA5SubstringsMatch
+## SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
+
+# 9.3.22. DNS ARecord
+#
+# The A Record attribute type specifies a type A (Address) DNS resource
+# record [6] [7].
+#
+# aRecord ATTRIBUTE
+# WITH ATTRIBUTE-SYNTAX
+# DNSRecordSyntax
+# ::= {pilotAttributeType 26}
+#
+## incorrect syntax?
+attributetype ( 0.9.2342.19200300.100.1.26 NAME 'aRecord'
+ EQUALITY caseIgnoreIA5Match
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
+
+## missing from RFC1274
+## incorrect syntax?
+attributetype ( 0.9.2342.19200300.100.1.27 NAME 'mDRecord'
+ EQUALITY caseIgnoreIA5Match
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
+
+# 9.3.23. MX Record
+#
+# The MX Record attribute type specifies a type MX (Mail Exchange) DNS
+# resource record [6] [7].
+#
+# mXRecord ATTRIBUTE
+# WITH ATTRIBUTE-SYNTAX
+# DNSRecordSyntax
+# ::= {pilotAttributeType 28}
+#
+## incorrect syntax!!
+attributetype ( 0.9.2342.19200300.100.1.28 NAME 'mXRecord'
+ EQUALITY caseIgnoreIA5Match
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
+
+# 9.3.24. NS Record
+#
+# The NS Record attribute type specifies an NS (Name Server) DNS
+# resource record [6] [7].
+#
+# nSRecord ATTRIBUTE
+# WITH ATTRIBUTE-SYNTAX
+# DNSRecordSyntax
+# ::= {pilotAttributeType 29}
+#
+## incorrect syntax!!
+attributetype ( 0.9.2342.19200300.100.1.29 NAME 'nSRecord'
+ EQUALITY caseIgnoreIA5Match
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
+
+# 9.3.25. SOA Record
+#
+# The SOA Record attribute type specifies a type SOA (Start of
+# Authority) DNS resorce record [6] [7].
+#
+# sOARecord ATTRIBUTE
+# WITH ATTRIBUTE-SYNTAX
+# DNSRecordSyntax
+# ::= {pilotAttributeType 30}
+#
+## incorrect syntax!!
+attributetype ( 0.9.2342.19200300.100.1.30 NAME 'sOARecord'
+ EQUALITY caseIgnoreIA5Match
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
+
+# 9.3.26. CNAME Record
+#
+# The CNAME Record attribute type specifies a type CNAME (Canonical
+# Name) DNS resource record [6] [7].
+#
+# cNAMERecord ATTRIBUTE
+# WITH ATTRIBUTE-SYNTAX
+# iA5StringSyntax
+# ::= {pilotAttributeType 31}
+#
+## incorrect syntax!!
+attributetype ( 0.9.2342.19200300.100.1.31 NAME 'cNAMERecord'
+ EQUALITY caseIgnoreIA5Match
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
+
+# 9.3.27. Associated Domain
+#
+# The Associated Domain attribute type specifies a DNS or NRS domain
+# which is associated with an object in the DIT. For example, the entry
+# in the DIT with a distinguished name "C=GB, O=University College
+# London" would have an associated domain of "UCL.AC.UK. Note that all
+# domains should be represented in rfc822 order. See [3] for more
+# details of usage of this attribute.
+#
+# associatedDomain ATTRIBUTE
+# WITH ATTRIBUTE-SYNTAX
+# caseIgnoreIA5StringSyntax
+# ::= {pilotAttributeType 37}
+#
+#attributetype ( 0.9.2342.19200300.100.1.37 NAME 'associatedDomain'
+# EQUALITY caseIgnoreIA5Match
+# SUBSTR caseIgnoreIA5SubstringsMatch
+# SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
+
+# 9.3.28. Associated Name
+#
+# The Associated Name attribute type specifies an entry in the
+# organisational DIT associated with a DNS/NRS domain. See [3] for
+# more details of usage of this attribute.
+#
+# associatedName ATTRIBUTE
+# WITH ATTRIBUTE-SYNTAX
+# distinguishedNameSyntax
+# ::= {pilotAttributeType 38}
+#
+attributetype ( 0.9.2342.19200300.100.1.38 NAME 'associatedName'
+ DESC 'RFC1274: DN of entry associated with domain'
+ EQUALITY distinguishedNameMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
+
+# 9.3.29. Home postal address
+#
+# The Home postal address attribute type specifies a home postal
+# address for an object. This should be limited to up to 6 lines of 30
+# characters each.
+#
+# homePostalAddress ATTRIBUTE
+# WITH ATTRIBUTE-SYNTAX
+# postalAddress
+# MATCHES FOR EQUALITY
+# ::= {pilotAttributeType 39}
+#
+attributetype ( 0.9.2342.19200300.100.1.39 NAME 'homePostalAddress'
+ DESC 'RFC1274: home postal address'
+ EQUALITY caseIgnoreListMatch
+ SUBSTR caseIgnoreListSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 )
+
+# 9.3.30. Personal Title
+#
+# The Personal Title attribute type specifies a personal title for a
+# person. Examples of personal titles are "Ms", "Dr", "Prof" and "Rev".
+#
+# personalTitle ATTRIBUTE
+# WITH ATTRIBUTE-SYNTAX
+# caseIgnoreStringSyntax
+# (SIZE (1 .. ub-personal-title))
+# ::= {pilotAttributeType 40}
+#
+attributetype ( 0.9.2342.19200300.100.1.40 NAME 'personalTitle'
+ DESC 'RFC1274: personal title'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
+
+# 9.3.31. Mobile Telephone Number
+#
+# The Mobile Telephone Number attribute type specifies a mobile
+# telephone number associated with a person. Attribute values should
+# follow the agreed format for international telephone numbers: i.e.,
+# "+44 71 123 4567".
+#
+# mobileTelephoneNumber ATTRIBUTE
+# WITH ATTRIBUTE-SYNTAX
+# telephoneNumberSyntax
+# ::= {pilotAttributeType 41}
+#
+attributetype ( 0.9.2342.19200300.100.1.41
+ NAME ( 'mobile' 'mobileTelephoneNumber' )
+ DESC 'RFC1274: mobile telephone number'
+ EQUALITY telephoneNumberMatch
+ SUBSTR telephoneNumberSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 )
+
+# 9.3.32. Pager Telephone Number
+#
+# The Pager Telephone Number attribute type specifies a pager telephone
+# number for an object. Attribute values should follow the agreed
+# format for international telephone numbers: i.e., "+44 71 123 4567".
+#
+# pagerTelephoneNumber ATTRIBUTE
+# WITH ATTRIBUTE-SYNTAX
+# telephoneNumberSyntax
+# ::= {pilotAttributeType 42}
+#
+attributetype ( 0.9.2342.19200300.100.1.42
+ NAME ( 'pager' 'pagerTelephoneNumber' )
+ DESC 'RFC1274: pager telephone number'
+ EQUALITY telephoneNumberMatch
+ SUBSTR telephoneNumberSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 )
+
+# 9.3.33. Friendly Country Name
+#
+# The Friendly Country Name attribute type specifies names of countries
+# in human readable format. The standard attribute country name must
+# be one of the two-letter codes defined in ISO 3166.
+#
+# friendlyCountryName ATTRIBUTE
+# WITH ATTRIBUTE-SYNTAX
+# caseIgnoreStringSyntax
+# ::= {pilotAttributeType 43}
+#
+attributetype ( 0.9.2342.19200300.100.1.43
+ NAME ( 'co' 'friendlyCountryName' )
+ DESC 'RFC1274: friendly country name'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+# 9.3.34. Unique Identifier
+#
+# The Unique Identifier attribute type specifies a "unique identifier"
+# for an object represented in the Directory. The domain within which
+# the identifier is unique, and the exact semantics of the identifier,
+# are for local definition. For a person, this might be an
+# institution-wide payroll number. For an organisational unit, it
+# might be a department code.
+#
+# uniqueIdentifier ATTRIBUTE
+# WITH ATTRIBUTE-SYNTAX
+# caseIgnoreStringSyntax
+# (SIZE (1 .. ub-unique-identifier))
+# ::= {pilotAttributeType 44}
+#
+attributetype ( 0.9.2342.19200300.100.1.44 NAME 'uniqueIdentifier'
+ DESC 'RFC1274: unique identifer'
+ EQUALITY caseIgnoreMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
+
+# 9.3.35. Organisational Status
+#
+# The Organisational Status attribute type specifies a category by
+# which a person is often referred to in an organisation. Examples of
+# usage in academia might include undergraduate student, researcher,
+# lecturer, etc.
+#
+# A Directory administrator should probably consider carefully the
+# distinctions between this and the title and userClass attributes.
+#
+# organizationalStatus ATTRIBUTE
+# WITH ATTRIBUTE-SYNTAX
+# caseIgnoreStringSyntax
+# (SIZE (1 .. ub-organizational-status))
+# ::= {pilotAttributeType 45}
+#
+attributetype ( 0.9.2342.19200300.100.1.45 NAME 'organizationalStatus'
+ DESC 'RFC1274: organizational status'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
+
+# 9.3.36. Janet Mailbox
+#
+# The Janet Mailbox attribute type specifies an electronic mailbox
+# attribute following the syntax specified in the Grey Book of the
+# Coloured Book series. This attribute is intended for the convenience
+# of U.K users unfamiliar with rfc822 and little-endian mail addresses.
+# Entries using this attribute MUST also include an rfc822Mailbox
+# attribute.
+#
+# janetMailbox ATTRIBUTE
+# WITH ATTRIBUTE-SYNTAX
+# caseIgnoreIA5StringSyntax
+# (SIZE (1 .. ub-janet-mailbox))
+# ::= {pilotAttributeType 46}
+#
+attributetype ( 0.9.2342.19200300.100.1.46 NAME 'janetMailbox'
+ DESC 'RFC1274: Janet mailbox'
+ EQUALITY caseIgnoreIA5Match
+ SUBSTR caseIgnoreIA5SubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} )
+
+# 9.3.37. Mail Preference Option
+#
+# An attribute to allow users to indicate a preference for inclusion of
+# their names on mailing lists (electronic or physical). The absence
+# of such an attribute should be interpreted as if the attribute was
+# present with value "no-list-inclusion". This attribute should be
+# interpreted by anyone using the directory to derive mailing lists,
+# and its value respected.
+#
+# mailPreferenceOption ATTRIBUTE
+# WITH ATTRIBUTE-SYNTAX ENUMERATED {
+# no-list-inclusion(0),
+# any-list-inclusion(1), -- may be added to any lists
+# professional-list-inclusion(2)
+# -- may be added to lists
+# -- which the list provider
+# -- views as related to the
+# -- users professional inter-
+# -- ests, perhaps evaluated
+# -- from the business of the
+# -- organisation or keywords
+# -- in the entry.
+# }
+# ::= {pilotAttributeType 47}
+#
+attributetype ( 0.9.2342.19200300.100.1.47
+ NAME 'mailPreferenceOption'
+ DESC 'RFC1274: mail preference option'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )
+
+# 9.3.38. Building Name
+#
+# The Building Name attribute type specifies the name of the building
+# where an organisation or organisational unit is based.
+#
+# buildingName ATTRIBUTE
+# WITH ATTRIBUTE-SYNTAX
+# caseIgnoreStringSyntax
+# (SIZE (1 .. ub-building-name))
+# ::= {pilotAttributeType 48}
+#
+attributetype ( 0.9.2342.19200300.100.1.48 NAME 'buildingName'
+ DESC 'RFC1274: name of building'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
+
+# 9.3.39. DSA Quality
+#
+# The DSA Quality attribute type specifies the purported quality of a
+# DSA. It allows a DSA manager to indicate the expected level of
+# availability of the DSA. See [8] for details of the syntax.
+#
+# dSAQuality ATTRIBUTE
+# WITH ATTRIBUTE-SYNTAX DSAQualitySyntax
+# SINGLE VALUE
+# ::= {pilotAttributeType 49}
+#
+attributetype ( 0.9.2342.19200300.100.1.49 NAME 'dSAQuality'
+ DESC 'RFC1274: DSA Quality'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.19 SINGLE-VALUE )
+
+# 9.3.40. Single Level Quality
+#
+# The Single Level Quality attribute type specifies the purported data
+# quality at the level immediately below in the DIT. See [8] for
+# details of the syntax.
+#
+# singleLevelQuality ATTRIBUTE
+# WITH ATTRIBUTE-SYNTAX DataQualitySyntax
+# SINGLE VALUE
+# ::= {pilotAttributeType 50}
+#
+attributetype ( 0.9.2342.19200300.100.1.50 NAME 'singleLevelQuality'
+ DESC 'RFC1274: Single Level Quality'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.13 SINGLE-VALUE )
+
+# 9.3.41. Subtree Minimum Quality
+#
+# The Subtree Minimum Quality attribute type specifies the purported
+# minimum data quality for a DIT subtree. See [8] for more discussion
+# and details of the syntax.
+#
+# subtreeMinimumQuality ATTRIBUTE
+# WITH ATTRIBUTE-SYNTAX DataQualitySyntax
+# SINGLE VALUE
+# -- Defaults to singleLevelQuality
+# ::= {pilotAttributeType 51}
+#
+attributetype ( 0.9.2342.19200300.100.1.51 NAME 'subtreeMinimumQuality'
+ DESC 'RFC1274: Subtree Mininum Quality'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.13 SINGLE-VALUE )
+
+# 9.3.42. Subtree Maximum Quality
+#
+# The Subtree Maximum Quality attribute type specifies the purported
+# maximum data quality for a DIT subtree. See [8] for more discussion
+# and details of the syntax.
+#
+# subtreeMaximumQuality ATTRIBUTE
+# WITH ATTRIBUTE-SYNTAX DataQualitySyntax
+# SINGLE VALUE
+# -- Defaults to singleLevelQuality
+# ::= {pilotAttributeType 52}
+#
+attributetype ( 0.9.2342.19200300.100.1.52 NAME 'subtreeMaximumQuality'
+ DESC 'RFC1274: Subtree Maximun Quality'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.13 SINGLE-VALUE )
+
+# 9.3.43. Personal Signature
+#
+# The Personal Signature attribute type allows for a representation of
+# a person's signature. This should be encoded in G3 fax as explained
+# in recommendation T.4, with an ASN.1 wrapper to make it compatible
+# with an X.400 BodyPart as defined in X.420.
+#
+# IMPORT G3FacsimileBodyPart FROM { mhs-motis ipms modules
+# information-objects }
+#
+# personalSignature ATTRIBUTE
+# WITH ATTRIBUTE-SYNTAX
+# CHOICE {
+# g3-facsimile [3] G3FacsimileBodyPart
+# }
+# (SIZE (1 .. ub-personal-signature))
+# ::= {pilotAttributeType 53}
+#
+attributetype ( 0.9.2342.19200300.100.1.53 NAME 'personalSignature'
+ DESC 'RFC1274: Personal Signature (G3 fax)'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.23 )
+
+# 9.3.44. DIT Redirect
+#
+# The DIT Redirect attribute type is used to indicate that the object
+# described by one entry now has a newer entry in the DIT. The entry
+# containing the redirection attribute should be expired after a
+# suitable grace period. This attribute may be used when an individual
+# changes his/her place of work, and thus acquires a new organisational
+# DN.
+#
+# dITRedirect ATTRIBUTE
+# WITH ATTRIBUTE-SYNTAX
+# distinguishedNameSyntax
+# ::= {pilotAttributeType 54}
+#
+attributetype ( 0.9.2342.19200300.100.1.54 NAME 'dITRedirect'
+ DESC 'RFC1274: DIT Redirect'
+ EQUALITY distinguishedNameMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
+
+# 9.3.45. Audio
+#
+# The Audio attribute type allows the storing of sounds in the
+# Directory. The attribute uses a u-law encoded sound file as used by
+# the "play" utility on a Sun 4. This is an interim format.
+#
+# audio ATTRIBUTE
+# WITH ATTRIBUTE-SYNTAX
+# Audio
+# (SIZE (1 .. ub-audio))
+# ::= {pilotAttributeType 55}
+#
+attributetype ( 0.9.2342.19200300.100.1.55 NAME 'audio'
+ DESC 'RFC1274: audio (u-law)'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.4{25000} )
+
+# 9.3.46. Publisher of Document
+#
+#
+# The Publisher of Document attribute is the person and/or organization
+# that published a document.
+#
+# documentPublisher ATTRIBUTE
+# WITH ATTRIBUTE SYNTAX caseIgnoreStringSyntax
+# ::= {pilotAttributeType 56}
+#
+attributetype ( 0.9.2342.19200300.100.1.56 NAME 'documentPublisher'
+ DESC 'RFC1274: publisher of document'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+# 9.4. Generally useful syntaxes
+#
+# caseIgnoreIA5StringSyntax ATTRIBUTE-SYNTAX
+# IA5String
+# MATCHES FOR EQUALITY SUBSTRINGS
+#
+# iA5StringSyntax ATTRIBUTE-SYNTAX
+# IA5String
+# MATCHES FOR EQUALITY SUBSTRINGS
+#
+#
+# -- Syntaxes to support the DNS attributes
+#
+# DNSRecordSyntax ATTRIBUTE-SYNTAX
+# IA5String
+# MATCHES FOR EQUALITY
+#
+#
+# NRSInformationSyntax ATTRIBUTE-SYNTAX
+# NRSInformation
+# MATCHES FOR EQUALITY
+#
+#
+# NRSInformation ::= SET {
+# [0] Context,
+# [1] Address-space-id,
+# routes [2] SEQUENCE OF SEQUENCE {
+# Route-cost,
+# Addressing-info }
+# }
+#
+#
+# 9.5. Upper bounds on length of attribute values
+#
+#
+# ub-document-identifier INTEGER ::= 256
+#
+# ub-document-location INTEGER ::= 256
+#
+# ub-document-title INTEGER ::= 256
+#
+# ub-document-version INTEGER ::= 256
+#
+# ub-favourite-drink INTEGER ::= 256
+#
+# ub-host INTEGER ::= 256
+#
+# ub-information INTEGER ::= 2048
+#
+# ub-unique-identifier INTEGER ::= 256
+#
+# ub-personal-title INTEGER ::= 256
+#
+# ub-photo INTEGER ::= 250000
+#
+# ub-rfc822-mailbox INTEGER ::= 256
+#
+# ub-room-number INTEGER ::= 256
+#
+# ub-text-or-address INTEGER ::= 256
+#
+# ub-user-class INTEGER ::= 256
+#
+# ub-user-identifier INTEGER ::= 256
+#
+# ub-organizational-status INTEGER ::= 256
+#
+# ub-janet-mailbox INTEGER ::= 256
+#
+# ub-building-name INTEGER ::= 256
+#
+# ub-personal-signature ::= 50000
+#
+# ub-audio INTEGER ::= 250000
+#
+
+# [back to 8]
+# 8. Object Classes
+#
+# 8.1. X.500 standard object classes
+#
+# A number of generally useful object classes are defined in X.521, and
+# these are supported. Refer to that document for descriptions of the
+# suggested usage of these object classes. The ASN.1 for these object
+# classes is reproduced for completeness in Appendix C.
+#
+# 8.2. X.400 standard object classes
+#
+# A number of object classes defined in X.400 are supported. Refer to
+# X.402 for descriptions of the usage of these object classes. The
+# ASN.1 for these object classes is reproduced for completeness in
+# Appendix C.
+#
+# 8.3. COSINE/Internet object classes
+#
+# This section attempts to fuse together the object classes designed
+# for use in the COSINE and Internet pilot activities. Descriptions
+# are given of the suggested usage of these object classes. The ASN.1
+# for these object classes is also reproduced in Appendix C.
+#
+# 8.3.1. Pilot Object
+#
+# The PilotObject object class is used as a sub-class to allow some
+# common, useful attributes to be assigned to entries of all other
+# object classes.
+#
+# pilotObject OBJECT-CLASS
+# SUBCLASS OF top
+# MAY CONTAIN {
+# info,
+# photo,
+# manager,
+# uniqueIdentifier,
+# lastModifiedTime,
+# lastModifiedBy,
+# dITRedirect,
+# audio}
+# ::= {pilotObjectClass 3}
+#
+#objectclass ( 0.9.2342.19200300.100.4.3 NAME 'pilotObject'
+# DESC 'RFC1274: pilot object'
+# SUP top AUXILIARY
+# MAY ( info $ photo $ manager $ uniqueIdentifier $
+# lastModifiedTime $ lastModifiedBy $ dITRedirect $ audio )
+# )
+
+# 8.3.2. Pilot Person
+#
+# The PilotPerson object class is used as a sub-class of person, to
+# allow the use of a number of additional attributes to be assigned to
+# entries of object class person.
+#
+# pilotPerson OBJECT-CLASS
+# SUBCLASS OF person
+# MAY CONTAIN {
+# userid,
+# textEncodedORAddress,
+# rfc822Mailbox,
+# favouriteDrink,
+# roomNumber,
+# userClass,
+# homeTelephoneNumber,
+# homePostalAddress,
+# secretary,
+# personalTitle,
+# preferredDeliveryMethod,
+# businessCategory,
+# janetMailbox,
+# otherMailbox,
+# mobileTelephoneNumber,
+# pagerTelephoneNumber,
+# organizationalStatus,
+# mailPreferenceOption,
+# personalSignature}
+# ::= {pilotObjectClass 4}
+#
+objectclass ( 0.9.2342.19200300.100.4.4
+ NAME ( 'pilotPerson' 'newPilotPerson' )
+ SUP person STRUCTURAL
+ MAY ( userid $ textEncodedORAddress $ rfc822Mailbox $
+ favouriteDrink $ roomNumber $ userClass $
+ homeTelephoneNumber $ homePostalAddress $ secretary $
+ personalTitle $ preferredDeliveryMethod $ businessCategory $
+ janetMailbox $ otherMailbox $ mobileTelephoneNumber $
+ pagerTelephoneNumber $ organizationalStatus $
+ mailPreferenceOption $ personalSignature )
+ )
+
+# 8.3.3. Account
+#
+# The Account object class is used to define entries representing
+# computer accounts. The userid attribute should be used for naming
+# entries of this object class.
+#
+# account OBJECT-CLASS
+# SUBCLASS OF top
+# MUST CONTAIN {
+# userid}
+# MAY CONTAIN {
+# description,
+# seeAlso,
+# localityName,
+# organizationName,
+# organizationalUnitName,
+# host}
+# ::= {pilotObjectClass 5}
+#
+objectclass ( 0.9.2342.19200300.100.4.5 NAME 'account'
+ SUP top STRUCTURAL
+ MUST userid
+ MAY ( description $ seeAlso $ localityName $
+ organizationName $ organizationalUnitName $ host )
+ )
+
+# 8.3.4. Document
+#
+# The Document object class is used to define entries which represent
+# documents.
+#
+# document OBJECT-CLASS
+# SUBCLASS OF top
+# MUST CONTAIN {
+# documentIdentifier}
+# MAY CONTAIN {
+# commonName,
+# description,
+# seeAlso,
+# localityName,
+# organizationName,
+# organizationalUnitName,
+# documentTitle,
+# documentVersion,
+# documentAuthor,
+# documentLocation,
+# documentPublisher}
+# ::= {pilotObjectClass 6}
+#
+objectclass ( 0.9.2342.19200300.100.4.6 NAME 'document'
+ SUP top STRUCTURAL
+ MUST documentIdentifier
+ MAY ( commonName $ description $ seeAlso $ localityName $
+ organizationName $ organizationalUnitName $
+ documentTitle $ documentVersion $ documentAuthor $
+ documentLocation $ documentPublisher )
+ )
+
+# 8.3.5. Room
+#
+# The Room object class is used to define entries representing rooms.
+# The commonName attribute should be used for naming pentries of this
+# object class.
+#
+# room OBJECT-CLASS
+# SUBCLASS OF top
+# MUST CONTAIN {
+# commonName}
+# MAY CONTAIN {
+# roomNumber,
+# description,
+# seeAlso,
+# telephoneNumber}
+# ::= {pilotObjectClass 7}
+#
+objectclass ( 0.9.2342.19200300.100.4.7 NAME 'room'
+ SUP top STRUCTURAL
+ MUST commonName
+ MAY ( roomNumber $ description $ seeAlso $ telephoneNumber )
+ )
+
+# 8.3.6. Document Series
+#
+# The Document Series object class is used to define an entry which
+# represents a series of documents (e.g., The Request For Comments
+# papers).
+#
+# documentSeries OBJECT-CLASS
+# SUBCLASS OF top
+# MUST CONTAIN {
+# commonName}
+# MAY CONTAIN {
+# description,
+# seeAlso,
+# telephoneNumber,
+# localityName,
+# organizationName,
+# organizationalUnitName}
+# ::= {pilotObjectClass 9}
+#
+objectclass ( 0.9.2342.19200300.100.4.9 NAME 'documentSeries'
+ SUP top STRUCTURAL
+ MUST commonName
+ MAY ( description $ seeAlso $ telephonenumber $
+ localityName $ organizationName $ organizationalUnitName )
+ )
+
+# 8.3.7. Domain
+#
+# The Domain object class is used to define entries which represent DNS
+# or NRS domains. The domainComponent attribute should be used for
+# naming entries of this object class. The usage of this object class
+# is described in more detail in [3].
+#
+# domain OBJECT-CLASS
+# SUBCLASS OF top
+# MUST CONTAIN {
+# domainComponent}
+# MAY CONTAIN {
+# associatedName,
+# organizationName,
+# organizationalAttributeSet}
+# ::= {pilotObjectClass 13}
+#
+objectclass ( 0.9.2342.19200300.100.4.13 NAME 'domain'
+ SUP top STRUCTURAL
+ MUST domainComponent
+ MAY ( associatedName $ organizationName $ description $
+ businessCategory $ seeAlso $ searchGuide $ userPassword $
+ localityName $ stateOrProvinceName $ streetAddress $
+ physicalDeliveryOfficeName $ postalAddress $ postalCode $
+ postOfficeBox $ streetAddress $
+ facsimileTelephoneNumber $ internationalISDNNumber $
+ telephoneNumber $ teletexTerminalIdentifier $ telexNumber $
+ preferredDeliveryMethod $ destinationIndicator $
+ registeredAddress $ x121Address )
+ )
+
+# 8.3.8. RFC822 Local Part
+#
+# The RFC822 Local Part object class is used to define entries which
+# represent the local part of RFC822 mail addresses. This treats this
+# part of an RFC822 address as a domain. The usage of this object
+# class is described in more detail in [3].
+#
+# rFC822localPart OBJECT-CLASS
+# SUBCLASS OF domain
+# MAY CONTAIN {
+# commonName,
+# surname,
+# description,
+# seeAlso,
+# telephoneNumber,
+# postalAttributeSet,
+# telecommunicationAttributeSet}
+# ::= {pilotObjectClass 14}
+#
+objectclass ( 0.9.2342.19200300.100.4.14 NAME 'RFC822localPart'
+ SUP domain STRUCTURAL
+ MAY ( commonName $ surname $ description $ seeAlso $ telephoneNumber $
+ physicalDeliveryOfficeName $ postalAddress $ postalCode $
+ postOfficeBox $ streetAddress $
+ facsimileTelephoneNumber $ internationalISDNNumber $
+ telephoneNumber $ teletexTerminalIdentifier $
+ telexNumber $ preferredDeliveryMethod $ destinationIndicator $
+ registeredAddress $ x121Address )
+ )
+
+# 8.3.9. DNS Domain
+#
+# The DNS Domain (Domain NameServer) object class is used to define
+# entries for DNS domains. The usage of this object class is described
+# in more detail in [3].
+#
+# dNSDomain OBJECT-CLASS
+# SUBCLASS OF domain
+# MAY CONTAIN {
+# ARecord,
+# MDRecord,
+# MXRecord,
+# NSRecord,
+# SOARecord,
+# CNAMERecord}
+# ::= {pilotObjectClass 15}
+#
+objectclass ( 0.9.2342.19200300.100.4.15 NAME 'dNSDomain'
+ SUP domain STRUCTURAL
+ MAY ( ARecord $ MDRecord $ MXRecord $ NSRecord $
+ SOARecord $ CNAMERecord )
+ )
+
+# 8.3.10. Domain Related Object
+#
+# The Domain Related Object object class is used to define entries
+# which represent DNS/NRS domains which are "equivalent" to an X.500
+# domain: e.g., an organisation or organisational unit. The usage of
+# this object class is described in more detail in [3].
+#
+# domainRelatedObject OBJECT-CLASS
+# SUBCLASS OF top
+# MUST CONTAIN {
+# associatedDomain}
+# ::= {pilotObjectClass 17}
+#
+objectclass ( 0.9.2342.19200300.100.4.17 NAME 'domainRelatedObject'
+ DESC 'RFC1274: an object related to an domain'
+ SUP top AUXILIARY
+ MUST associatedDomain )
+
+# 8.3.11. Friendly Country
+#
+# The Friendly Country object class is used to define country entries
+# in the DIT. The object class is used to allow friendlier naming of
+# countries than that allowed by the object class country. The naming
+# attribute of object class country, countryName, has to be a 2 letter
+# string defined in ISO 3166.
+#
+# friendlyCountry OBJECT-CLASS
+# SUBCLASS OF country
+# MUST CONTAIN {
+# friendlyCountryName}
+# ::= {pilotObjectClass 18}
+#
+objectclass ( 0.9.2342.19200300.100.4.18 NAME 'friendlyCountry'
+ SUP country STRUCTURAL
+ MUST friendlyCountryName )
+
+# 8.3.12. Simple Security Object
+#
+# The Simple Security Object object class is used to allow an entry to
+# have a userPassword attribute when an entry's principal object
+# classes do not allow userPassword as an attribute type.
+#
+# simpleSecurityObject OBJECT-CLASS
+# SUBCLASS OF top
+# MUST CONTAIN {
+# userPassword }
+# ::= {pilotObjectClass 19}
+#
+## (in core.schema)
+## objectclass ( 0.9.2342.19200300.100.4.19 NAME 'simpleSecurityObject'
+## SUP top AUXILIARY
+## MUST userPassword )
+
+# 8.3.13. Pilot Organization
+#
+# The PilotOrganization object class is used as a sub-class of
+# organization and organizationalUnit to allow a number of additional
+# attributes to be assigned to entries of object classes organization
+# and organizationalUnit.
+#
+# pilotOrganization OBJECT-CLASS
+# SUBCLASS OF organization, organizationalUnit
+# MAY CONTAIN {
+# buildingName}
+# ::= {pilotObjectClass 20}
+#
+objectclass ( 0.9.2342.19200300.100.4.20 NAME 'pilotOrganization'
+ SUP ( organization $ organizationalUnit ) STRUCTURAL
+ MAY buildingName )
+
+# 8.3.14. Pilot DSA
+#
+# The PilotDSA object class is used as a sub-class of the dsa object
+# class to allow additional attributes to be assigned to entries for
+# DSAs.
+#
+# pilotDSA OBJECT-CLASS
+# SUBCLASS OF dsa
+# MUST CONTAIN {
+# dSAQuality}
+# ::= {pilotObjectClass 21}
+#
+objectclass ( 0.9.2342.19200300.100.4.21 NAME 'pilotDSA'
+ SUP dsa STRUCTURAL
+ MAY dSAQuality )
+
+# 8.3.15. Quality Labelled Data
+#
+# The Quality Labelled Data object class is used to allow the
+# assignment of the data quality attributes to subtrees in the DIT.
+#
+# See [8] for more details.
+#
+# qualityLabelledData OBJECT-CLASS
+# SUBCLASS OF top
+# MUST CONTAIN {
+# dSAQuality}
+# MAY CONTAIN {
+# subtreeMinimumQuality,
+# subtreeMaximumQuality}
+# ::= {pilotObjectClass 22}
+objectclass ( 0.9.2342.19200300.100.4.22 NAME 'qualityLabelledData'
+ SUP top AUXILIARY
+ MUST dsaQuality
+ MAY ( subtreeMinimumQuality $ subtreeMaximumQuality )
+ )
+
+
+# References
+#
+# [1] CCITT/ISO, "X.500, The Directory - overview of concepts,
+# models and services, CCITT /ISO IS 9594.
+#
+# [2] Kille, S., "The THORN and RARE X.500 Naming Architecture, in
+# University College London, Department of Computer Science
+# Research Note 89/48, May 1989.
+#
+# [3] Kille, S., "X.500 and Domains", RFC 1279, University College
+# London, November 1991.
+#
+# [4] Rose, M., "PSI/NYSERNet White Pages Pilot Project: Status
+# Report", Technical Report 90-09-10-1, published by NYSERNet
+# Inc, 1990.
+#
+# [5] Craigie, J., "UK Academic Community Directory Service Pilot
+# Project, pp. 305-310 in Computer Networks and ISDN Systems
+# 17 (1989), published by North Holland.
+#
+# [6] Mockapetris, P., "Domain Names - Concepts and Facilities",
+# RFC 1034, USC/Information Sciences Institute, November 1987.
+#
+# [7] Mockapetris, P., "Domain Names - Implementation and
+# Specification, RFC 1035, USC/Information Sciences Institute,
+# November 1987.
+#
+# [8] Kille, S., "Handling QOS (Quality of service) in the
+# Directory," publication in process, March 1991.
+#
+#
+# APPENDIX C - Summary of all Object Classes and Attribute Types
+#
+# -- Some Important Object Identifiers
+#
+# data OBJECT IDENTIFIER ::= {ccitt 9}
+# pss OBJECT IDENTIFIER ::= {data 2342}
+# ucl OBJECT IDENTIFIER ::= {pss 19200300}
+# pilot OBJECT IDENTIFIER ::= {ucl 100}
+#
+# pilotAttributeType OBJECT IDENTIFIER ::= {pilot 1}
+# pilotAttributeSyntax OBJECT IDENTIFIER ::= {pilot 3}
+# pilotObjectClass OBJECT IDENTIFIER ::= {pilot 4}
+# pilotGroups OBJECT IDENTIFIER ::= {pilot 10}
+#
+# iA5StringSyntax OBJECT IDENTIFIER ::= {pilotAttributeSyntax 4}
+# caseIgnoreIA5StringSyntax OBJECT IDENTIFIER ::=
+# {pilotAttributeSyntax 5}
+#
+# -- Standard Object Classes
+#
+# top OBJECT-CLASS
+# MUST CONTAIN {
+# objectClass}
+# ::= {objectClass 0}
+#
+#
+# alias OBJECT-CLASS
+# SUBCLASS OF top
+# MUST CONTAIN {
+# aliasedObjectName}
+# ::= {objectClass 1}
+#
+#
+# country OBJECT-CLASS
+# SUBCLASS OF top
+# MUST CONTAIN {
+# countryName}
+# MAY CONTAIN {
+# description,
+# searchGuide}
+# ::= {objectClass 2}
+#
+#
+# locality OBJECT-CLASS
+# SUBCLASS OF top
+# MAY CONTAIN {
+# description,
+# localityName,
+# stateOrProvinceName,
+# searchGuide,
+# seeAlso,
+# streetAddress}
+# ::= {objectClass 3}
+#
+#
+# organization OBJECT-CLASS
+# SUBCLASS OF top
+# MUST CONTAIN {
+# organizationName}
+# MAY CONTAIN {
+# organizationalAttributeSet}
+# ::= {objectClass 4}
+#
+#
+# organizationalUnit OBJECT-CLASS
+# SUBCLASS OF top
+# MUST CONTAIN {
+# organizationalUnitName}
+# MAY CONTAIN {
+# organizationalAttributeSet}
+# ::= {objectClass 5}
+#
+#
+# person OBJECT-CLASS
+# SUBCLASS OF top
+# MUST CONTAIN {
+# commonName,
+# surname}
+# MAY CONTAIN {
+# description,
+# seeAlso,
+# telephoneNumber,
+# userPassword}
+# ::= {objectClass 6}
+#
+#
+# organizationalPerson OBJECT-CLASS
+# SUBCLASS OF person
+# MAY CONTAIN {
+# localeAttributeSet,
+# organizationalUnitName,
+# postalAttributeSet,
+# telecommunicationAttributeSet,
+# title}
+# ::= {objectClass 7}
+#
+#
+# organizationalRole OBJECT-CLASS
+# SUBCLASS OF top
+# MUST CONTAIN {
+# commonName}
+# MAY CONTAIN {
+# description,
+# localeAttributeSet,
+# organizationalUnitName,
+# postalAttributeSet,
+# preferredDeliveryMethod,
+# roleOccupant,
+# seeAlso,
+# telecommunicationAttributeSet}
+# ::= {objectClass 8}
+#
+#
+# groupOfNames OBJECT-CLASS
+# SUBCLASS OF top
+# MUST CONTAIN {
+# commonName,
+# member}
+# MAY CONTAIN {
+# description,
+# organizationName,
+# organizationalUnitName,
+# owner,
+# seeAlso,
+# businessCategory}
+# ::= {objectClass 9}
+#
+#
+# residentialPerson OBJECT-CLASS
+# SUBCLASS OF person
+# MUST CONTAIN {
+# localityName}
+# MAY CONTAIN {
+# localeAttributeSet,
+# postalAttributeSet,
+# preferredDeliveryMethod,
+# telecommunicationAttributeSet,
+# businessCategory}
+# ::= {objectClass 10}
+#
+#
+# applicationProcess OBJECT-CLASS
+# SUBCLASS OF top
+# MUST CONTAIN {
+# commonName}
+# MAY CONTAIN {
+# description,
+# localityName,
+# organizationalUnitName,
+# seeAlso}
+# ::= {objectClass 11}
+#
+#
+# applicationEntity OBJECT-CLASS
+# SUBCLASS OF top
+# MUST CONTAIN {
+# commonName,
+# presentationAddress}
+# MAY CONTAIN {
+# description,
+# localityName,
+# organizationName,
+# organizationalUnitName,
+# seeAlso,
+# supportedApplicationContext}
+# ::= {objectClass 12}
+#
+#
+# dSA OBJECT-CLASS
+# SUBCLASS OF applicationEntity
+# MAY CONTAIN {
+# knowledgeInformation}
+# ::= {objectClass 13}
+#
+#
+# device OBJECT-CLASS
+# SUBCLASS OF top
+# MUST CONTAIN {
+# commonName}
+# MAY CONTAIN {
+# description,
+# localityName,
+# organizationName,
+# organizationalUnitName,
+# owner,
+# seeAlso,
+# serialNumber}
+# ::= {objectClass 14}
+#
+#
+# strongAuthenticationUser OBJECT-CLASS
+# SUBCLASS OF top
+# MUST CONTAIN {
+# userCertificate}
+# ::= {objectClass 15}
+#
+#
+# certificationAuthority OBJECT-CLASS
+# SUBCLASS OF top
+# MUST CONTAIN {
+# cACertificate,
+# certificateRevocationList,
+# authorityRevocationList}
+# MAY CONTAIN {
+# crossCertificatePair}
+# ::= {objectClass 16}
+#
+# -- Standard MHS Object Classes
+#
+# mhsDistributionList OBJECT-CLASS
+# SUBCLASS OF top
+# MUST CONTAIN {
+# commonName,
+# mhsDLSubmitPermissions,
+# mhsORAddresses}
+# MAY CONTAIN {
+# description,
+# organizationName,
+# organizationalUnitName,
+# owner,
+# seeAlso,
+# mhsDeliverableContentTypes,
+# mhsdeliverableEits,
+# mhsDLMembers,
+# mhsPreferredDeliveryMethods}
+# ::= {mhsObjectClass 0}
+#
+#
+# mhsMessageStore OBJECT-CLASS
+# SUBCLASS OF applicationEntity
+# MAY CONTAIN {
+# description,
+# owner,
+# mhsSupportedOptionalAttributes,
+# mhsSupportedAutomaticActions,
+# mhsSupportedContentTypes}
+# ::= {mhsObjectClass 1}
+#
+#
+# mhsMessageTransferAgent OBJECT-CLASS
+# SUBCLASS OF applicationEntity
+# MAY CONTAIN {
+# description,
+# owner,
+# mhsDeliverableContentLength}
+# ::= {mhsObjectClass 2}
+#
+#
+# mhsOrganizationalUser OBJECT-CLASS
+# SUBCLASS OF organizationalPerson
+# MUST CONTAIN {
+# mhsORAddresses}
+# MAY CONTAIN {
+# mhsDeliverableContentLength,
+# mhsDeliverableContentTypes,
+# mhsDeliverableEits,
+# mhsMessageStoreName,
+# mhsPreferredDeliveryMethods }
+# ::= {mhsObjectClass 3}
+#
+#
+# mhsResidentialUser OBJECT-CLASS
+# SUBCLASS OF residentialPerson
+# MUST CONTAIN {
+# mhsORAddresses}
+# MAY CONTAIN {
+# mhsDeliverableContentLength,
+# mhsDeliverableContentTypes,
+# mhsDeliverableEits,
+# mhsMessageStoreName,
+# mhsPreferredDeliveryMethods }
+# ::= {mhsObjectClass 4}
+#
+#
+# mhsUserAgent OBJECT-CLASS
+# SUBCLASS OF applicationEntity
+# MAY CONTAIN {
+# mhsDeliverableContentLength,
+# mhsDeliverableContentTypes,
+# mhsDeliverableEits,
+# mhsORAddresses,
+# owner}
+# ::= {mhsObjectClass 5}
+#
+#
+#
+#
+# -- Pilot Object Classes
+#
+# pilotObject OBJECT-CLASS
+# SUBCLASS OF top
+# MAY CONTAIN {
+# info,
+# photo,
+# manager,
+# uniqueIdentifier,
+# lastModifiedTime,
+# lastModifiedBy,
+# dITRedirect,
+# audio}
+# ::= {pilotObjectClass 3}
+# pilotPerson OBJECT-CLASS
+# SUBCLASS OF person
+# MAY CONTAIN {
+# userid,
+# textEncodedORAddress,
+# rfc822Mailbox,
+# favouriteDrink,
+# roomNumber,
+# userClass,
+# homeTelephoneNumber,
+# homePostalAddress,
+# secretary,
+# personalTitle,
+# preferredDeliveryMethod,
+# businessCategory,
+# janetMailbox,
+# otherMailbox,
+# mobileTelephoneNumber,
+# pagerTelephoneNumber,
+# organizationalStatus,
+# mailPreferenceOption,
+# personalSignature}
+# ::= {pilotObjectClass 4}
+#
+#
+# account OBJECT-CLASS
+# SUBCLASS OF top
+# MUST CONTAIN {
+# userid}
+# MAY CONTAIN {
+# description,
+# seeAlso,
+# localityName,
+# organizationName,
+# organizationalUnitName,
+# host}
+# ::= {pilotObjectClass 5}
+#
+#
+# document OBJECT-CLASS
+# SUBCLASS OF top
+# MUST CONTAIN {
+# documentIdentifier}
+# MAY CONTAIN {
+# commonName,
+# description,
+# seeAlso,
+# localityName,
+# organizationName,
+# organizationalUnitName,
+# documentTitle,
+# documentVersion,
+# documentAuthor,
+# documentLocation,
+# documentPublisher}
+# ::= {pilotObjectClass 6}
+#
+#
+# room OBJECT-CLASS
+# SUBCLASS OF top
+# MUST CONTAIN {
+# commonName}
+# MAY CONTAIN {
+# roomNumber,
+# description,
+# seeAlso,
+# telephoneNumber}
+# ::= {pilotObjectClass 7}
+#
+#
+# documentSeries OBJECT-CLASS
+# SUBCLASS OF top
+# MUST CONTAIN {
+# commonName}
+# MAY CONTAIN {
+# description,
+# seeAlso,
+# telephoneNumber,
+# localityName,
+# organizationName,
+# organizationalUnitName}
+# ::= {pilotObjectClass 9}
+#
+#
+# domain OBJECT-CLASS
+# SUBCLASS OF top
+# MUST CONTAIN {
+# domainComponent}
+# MAY CONTAIN {
+# associatedName,
+# organizationName,
+# organizationalAttributeSet}
+# ::= {pilotObjectClass 13}
+#
+#
+# rFC822localPart OBJECT-CLASS
+# SUBCLASS OF domain
+# MAY CONTAIN {
+# commonName,
+# surname,
+# description,
+# seeAlso,
+# telephoneNumber,
+# postalAttributeSet,
+# telecommunicationAttributeSet}
+# ::= {pilotObjectClass 14}
+#
+#
+# dNSDomain OBJECT-CLASS
+# SUBCLASS OF domain
+# MAY CONTAIN {
+# ARecord,
+# MDRecord,
+# MXRecord,
+# NSRecord,
+# SOARecord,
+# CNAMERecord}
+# ::= {pilotObjectClass 15}
+#
+#
+# domainRelatedObject OBJECT-CLASS
+# SUBCLASS OF top
+# MUST CONTAIN {
+# associatedDomain}
+# ::= {pilotObjectClass 17}
+#
+#
+# friendlyCountry OBJECT-CLASS
+# SUBCLASS OF country
+# MUST CONTAIN {
+# friendlyCountryName}
+# ::= {pilotObjectClass 18}
+#
+#
+# simpleSecurityObject OBJECT-CLASS
+# SUBCLASS OF top
+# MUST CONTAIN {
+# userPassword }
+# ::= {pilotObjectClass 19}
+#
+#
+# pilotOrganization OBJECT-CLASS
+# SUBCLASS OF organization, organizationalUnit
+# MAY CONTAIN {
+# buildingName}
+# ::= {pilotObjectClass 20}
+#
+#
+# pilotDSA OBJECT-CLASS
+# SUBCLASS OF dsa
+# MUST CONTAIN {
+# dSAQuality}
+# ::= {pilotObjectClass 21}
+#
+#
+# qualityLabelledData OBJECT-CLASS
+# SUBCLASS OF top
+# MUST CONTAIN {
+# dSAQuality}
+# MAY CONTAIN {
+# subtreeMinimumQuality,
+# subtreeMaximumQuality}
+# ::= {pilotObjectClass 22}
+#
+#
+#
+#
+# -- Standard Attribute Types
+#
+# objectClass ObjectClass
+# ::= {attributeType 0}
+#
+#
+# aliasedObjectName AliasedObjectName
+# ::= {attributeType 1}
+#
+#
+# knowledgeInformation ATTRIBUTE
+# WITH ATTRIBUTE-SYNTAX caseIgnoreString
+# ::= {attributeType 2}
+#
+#
+# commonName ATTRIBUTE
+# WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax
+# (SIZE (1..ub-common-name))
+# ::= {attributeType 3}
+#
+#
+# surname ATTRIBUTE
+# WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax
+# (SIZE (1..ub-surname))
+# ::= {attributeType 4}
+#
+#
+# serialNumber ATTRIBUTE
+# WITH ATTRIBUTE-SYNTAX printableStringSyntax
+# (SIZE (1..ub-serial-number))
+# ::= {attributeType 5}
+#
+#
+# countryName ATTRIBUTE
+# WITH ATTRIBUTE-SYNTAX PrintableString
+# (SIZE (1..ub-country-code))
+# SINGLE VALUE
+# ::= {attributeType 6}
+#
+#
+# localityName ATTRIBUTE
+# WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax
+# (SIZE (1..ub-locality-name))
+# ::= {attributeType 7}
+#
+#
+# stateOrProvinceName ATTRIBUTE
+# WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax
+# (SIZE (1..ub-state-name))
+# ::= {attributeType 8}
+#
+#
+# streetAddress ATTRIBUTE
+# WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax
+# (SIZE (1..ub-street-address))
+# ::= {attributeType 9}
+#
+#
+# organizationName ATTRIBUTE
+# WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax
+# (SIZE (1..ub-organization-name))
+# ::= {attributeType 10}
+#
+#
+# organizationalUnitName ATTRIBUTE
+# WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax
+# (SIZE (1..ub-organizational-unit-name))
+# ::= {attributeType 11}
+#
+#
+# title ATTRIBUTE
+# WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax
+# (SIZE (1..ub-title))
+# ::= {attributeType 12}
+#
+#
+# description ATTRIBUTE
+# WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax
+# (SIZE (1..ub-description))
+# ::= {attributeType 13}
+#
+#
+# searchGuide ATTRIBUTE
+# WITH ATTRIBUTE-SYNTAX Guide
+# ::= {attributeType 14}
+#
+#
+# businessCategory ATTRIBUTE
+# WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax
+# (SIZE (1..ub-business-category))
+# ::= {attributeType 15}
+#
+#
+# postalAddress ATTRIBUTE
+# WITH ATTRIBUTE-SYNTAX PostalAddress
+# MATCHES FOR EQUALITY
+# ::= {attributeType 16}
+#
+#
+# postalCode ATTRIBUTE
+# WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax
+# (SIZE (1..ub-postal-code))
+# ::= {attributeType 17}
+#
+#
+# postOfficeBox ATTRIBUTE
+# WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax
+# (SIZE (1..ub-post-office-box))
+# ::= {attributeType 18}
+#
+#
+# physicalDeliveryOfficeName ATTRIBUTE
+# WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax
+# (SIZE (1..ub-physical-office-name))
+# ::= {attributeType 19}
+#
+#
+# telephoneNumber ATTRIBUTE
+# WITH ATTRIBUTE-SYNTAX telephoneNumberSyntax
+# (SIZE (1..ub-telephone-number))
+# ::= {attributeType 20}
+#
+#
+# telexNumber ATTRIBUTE
+# WITH ATTRIBUTE-SYNTAX TelexNumber
+# (SIZE (1..ub-telex))
+# ::= {attributeType 21}
+#
+#
+# teletexTerminalIdentifier ATTRIBUTE
+# WITH ATTRIBUTE-SYNTAX TeletexTerminalIdentifier
+# (SIZE (1..ub-teletex-terminal-id))
+# ::= {attributeType 22}
+#
+#
+# facsimileTelephoneNumber ATTRIBUTE
+# WITH ATTRIBUTE-SYNTAX FacsimileTelephoneNumber
+# ::= {attributeType 23}
+#
+#
+# x121Address ATTRIBUTE
+# WITH ATTRIBUTE-SYNTAX NumericString
+# (SIZE (1..ub-x121-address))
+# ::= {attributeType 24}
+#
+#
+# internationaliSDNNumber ATTRIBUTE
+# WITH ATTRIBUTE-SYNTAX NumericString
+# (SIZE (1..ub-isdn-address))
+# ::= {attributeType 25}
+#
+#
+# registeredAddress ATTRIBUTE
+# WITH ATTRIBUTE-SYNTAX PostalAddress
+# ::= {attributeType 26}
+#
+#
+# destinationIndicator ATTRIBUTE
+# WITH ATTRIBUTE-SYNTAX PrintableString
+# (SIZE (1..ub-destination-indicator))
+# MATCHES FOR EQUALITY SUBSTRINGS
+# ::= {attributeType 27}
+#
+#
+# preferredDeliveryMethod ATTRIBUTE
+# WITH ATTRIBUTE-SYNTAX deliveryMethod
+# ::= {attributeType 28}
+#
+#
+# presentationAddress ATTRIBUTE
+# WITH ATTRIBUTE-SYNTAX PresentationAddress
+# MATCHES FOR EQUALITY
+# ::= {attributeType 29}
+#
+#
+# supportedApplicationContext ATTRIBUTE
+# WITH ATTRIBUTE-SYNTAX objectIdentifierSyntax
+# ::= {attributeType 30}
+#
+#
+# member ATTRIBUTE
+# WITH ATTRIBUTE-SYNTAX distinguishedNameSyntax
+# ::= {attributeType 31}
+#
+#
+# owner ATTRIBUTE
+# WITH ATTRIBUTE-SYNTAX distinguishedNameSyntax
+# ::= {attributeType 32}
+#
+#
+# roleOccupant ATTRIBUTE
+# WITH ATTRIBUTE-SYNTAX distinguishedNameSyntax
+# ::= {attributeType 33}
+#
+#
+# seeAlso ATTRIBUTE
+# WITH ATTRIBUTE-SYNTAX distinguishedNameSyntax
+# ::= {attributeType 34}
+#
+#
+# userPassword ATTRIBUTE
+# WITH ATTRIBUTE-SYNTAX Userpassword
+# ::= {attributeType 35}
+#
+#
+# userCertificate ATTRIBUTE
+# WITH ATTRIBUTE-SYNTAX UserCertificate
+# ::= {attributeType 36}
+#
+#
+# cACertificate ATTRIBUTE
+# WITH ATTRIBUTE-SYNTAX cACertificate
+# ::= {attributeType 37}
+#
+#
+# authorityRevocationList ATTRIBUTE
+# WITH ATTRIBUTE-SYNTAX AuthorityRevocationList
+# ::= {attributeType 38}
+#
+#
+# certificateRevocationList ATTRIBUTE
+# WITH ATTRIBUTE-SYNTAX CertificateRevocationList
+# ::= {attributeType 39}
+#
+#
+# crossCertificatePair ATTRIBUTE
+# WITH ATTRIBUTE-SYNTAX CrossCertificatePair
+# ::= {attributeType 40}
+#
+#
+#
+#
+# -- Standard MHS Attribute Types
+#
+# mhsDeliverableContentLength ATTRIBUTE
+# WITH ATTRIBUTE-SYNTAX integer
+# ::= {mhsAttributeType 0}
+#
+#
+# mhsDeliverableContentTypes ATTRIBUTE
+# WITH ATTRIBUTE-SYNTAX oID
+# ::= {mhsAttributeType 1}
+#
+#
+# mhsDeliverableEits ATTRIBUTE
+# WITH ATTRIBUTE-SYNTAX oID
+# ::= {mhsAttributeType 2}
+#
+#
+# mhsDLMembers ATTRIBUTE
+# WITH ATTRIBUTE-SYNTAX oRName
+# ::= {mhsAttributeType 3}
+#
+#
+# mhsDLSubmitPermissions ATTRIBUTE
+# WITH ATTRIBUTE-SYNTAX dLSubmitPermission
+# ::= {mhsAttributeType 4}
+#
+#
+# mhsMessageStoreName ATTRIBUTE
+# WITH ATTRIBUTE-SYNTAX dN
+# ::= {mhsAttributeType 5}
+#
+#
+# mhsORAddresses ATTRIBUTE
+# WITH ATTRIBUTE-SYNTAX oRAddress
+# ::= {mhsAttributeType 6}
+#
+#
+# mhsPreferredDeliveryMethods ATTRIBUTE
+# WITH ATTRIBUTE-SYNTAX deliveryMethod
+# ::= {mhsAttributeType 7}
+#
+#
+# mhsSupportedAutomaticActions ATTRIBUTE
+# WITH ATTRIBUTE-SYNTAX oID
+# ::= {mhsAttributeType 8}
+#
+#
+# mhsSupportedContentTypes ATTRIBUTE
+#
+# WITH ATTRIBUTE-SYNTAX oID
+# ::= {mhsAttributeType 9}
+#
+#
+# mhsSupportedOptionalAttributes ATTRIBUTE
+# WITH ATTRIBUTE-SYNTAX oID
+# ::= {mhsAttributeType 10}
+#
+#
+#
+#
+# -- Pilot Attribute Types
+#
+# userid ATTRIBUTE
+# WITH ATTRIBUTE-SYNTAX
+# caseIgnoreStringSyntax
+# (SIZE (1 .. ub-user-identifier))
+# ::= {pilotAttributeType 1}
+#
+#
+# textEncodedORAddress ATTRIBUTE
+# WITH ATTRIBUTE-SYNTAX
+# caseIgnoreStringSyntax
+# (SIZE (1 .. ub-text-encoded-or-address))
+# ::= {pilotAttributeType 2}
+#
+#
+# rfc822Mailbox ATTRIBUTE
+# WITH ATTRIBUTE-SYNTAX
+# caseIgnoreIA5StringSyntax
+# (SIZE (1 .. ub-rfc822-mailbox))
+# ::= {pilotAttributeType 3}
+#
+#
+# info ATTRIBUTE
+# WITH ATTRIBUTE-SYNTAX
+# caseIgnoreStringSyntax
+# (SIZE (1 .. ub-information))
+# ::= {pilotAttributeType 4}
+#
+#
+# favouriteDrink ATTRIBUTE
+# WITH ATTRIBUTE-SYNTAX
+# caseIgnoreStringSyntax
+# (SIZE (1 .. ub-favourite-drink))
+# ::= {pilotAttributeType 5}
+#
+#
+# roomNumber ATTRIBUTE
+# WITH ATTRIBUTE-SYNTAX
+# caseIgnoreStringSyntax
+# (SIZE (1 .. ub-room-number))
+# ::= {pilotAttributeType 6}
+#
+#
+# photo ATTRIBUTE
+# WITH ATTRIBUTE-SYNTAX
+# CHOICE {
+# g3-facsimile [3] G3FacsimileBodyPart
+# }
+# (SIZE (1 .. ub-photo))
+# ::= {pilotAttributeType 7}
+#
+#
+# userClass ATTRIBUTE
+# WITH ATTRIBUTE-SYNTAX
+# caseIgnoreStringSyntax
+# (SIZE (1 .. ub-user-class))
+# ::= {pilotAttributeType 8}
+#
+#
+# host ATTRIBUTE
+# WITH ATTRIBUTE-SYNTAX
+# caseIgnoreStringSyntax
+# (SIZE (1 .. ub-host))
+# ::= {pilotAttributeType 9}
+#
+#
+# manager ATTRIBUTE
+# WITH ATTRIBUTE-SYNTAX
+# distinguishedNameSyntax
+# ::= {pilotAttributeType 10}
+#
+#
+# documentIdentifier ATTRIBUTE
+# WITH ATTRIBUTE-SYNTAX
+# caseIgnoreStringSyntax
+# (SIZE (1 .. ub-document-identifier))
+# ::= {pilotAttributeType 11}
+#
+#
+# documentTitle ATTRIBUTE
+# WITH ATTRIBUTE-SYNTAX
+# caseIgnoreStringSyntax
+# (SIZE (1 .. ub-document-title))
+# ::= {pilotAttributeType 12}
+#
+#
+# documentVersion ATTRIBUTE
+# WITH ATTRIBUTE-SYNTAX
+# caseIgnoreStringSyntax
+# (SIZE (1 .. ub-document-version))
+# ::= {pilotAttributeType 13}
+#
+#
+# documentAuthor ATTRIBUTE
+# WITH ATTRIBUTE-SYNTAX
+# distinguishedNameSyntax
+# ::= {pilotAttributeType 14}
+#
+#
+# documentLocation ATTRIBUTE
+# WITH ATTRIBUTE-SYNTAX
+# caseIgnoreStringSyntax
+# (SIZE (1 .. ub-document-location))
+# ::= {pilotAttributeType 15}
+#
+#
+# homeTelephoneNumber ATTRIBUTE
+# WITH ATTRIBUTE-SYNTAX
+# telephoneNumberSyntax
+# ::= {pilotAttributeType 20}
+#
+#
+# secretary ATTRIBUTE
+# WITH ATTRIBUTE-SYNTAX
+# distinguishedNameSyntax
+# ::= {pilotAttributeType 21}
+#
+#
+# otherMailbox ATTRIBUTE
+# WITH ATTRIBUTE-SYNTAX
+# SEQUENCE {
+# mailboxType PrintableString, -- e.g. Telemail
+# mailbox IA5String -- e.g. X378:Joe
+# }
+# ::= {pilotAttributeType 22}
+#
+#
+# lastModifiedTime ATTRIBUTE
+# WITH ATTRIBUTE-SYNTAX
+# uTCTimeSyntax
+# ::= {pilotAttributeType 23}
+#
+#
+# lastModifiedBy ATTRIBUTE
+# WITH ATTRIBUTE-SYNTAX
+# distinguishedNameSyntax
+# ::= {pilotAttributeType 24}
+#
+#
+# domainComponent ATTRIBUTE
+# WITH ATTRIBUTE-SYNTAX
+# caseIgnoreIA5StringSyntax
+# SINGLE VALUE
+# ::= {pilotAttributeType 25}
+#
+#
+# aRecord ATTRIBUTE
+# WITH ATTRIBUTE-SYNTAX
+# DNSRecordSyntax
+# ::= {pilotAttributeType 26}
+#
+#
+# mXRecord ATTRIBUTE
+# WITH ATTRIBUTE-SYNTAX
+# DNSRecordSyntax
+# ::= {pilotAttributeType 28}
+#
+#
+# nSRecord ATTRIBUTE
+# WITH ATTRIBUTE-SYNTAX
+# DNSRecordSyntax
+# ::= {pilotAttributeType 29}
+#
+# sOARecord ATTRIBUTE
+# WITH ATTRIBUTE-SYNTAX
+# DNSRecordSyntax
+# ::= {pilotAttributeType 30}
+#
+#
+# cNAMERecord ATTRIBUTE
+# WITH ATTRIBUTE-SYNTAX
+# iA5StringSyntax
+# ::= {pilotAttributeType 31}
+#
+#
+# associatedDomain ATTRIBUTE
+# WITH ATTRIBUTE-SYNTAX
+# caseIgnoreIA5StringSyntax
+# ::= {pilotAttributeType 37}
+#
+#
+# associatedName ATTRIBUTE
+# WITH ATTRIBUTE-SYNTAX
+# distinguishedNameSyntax
+# ::= {pilotAttributeType 38}
+#
+#
+# homePostalAddress ATTRIBUTE
+# WITH ATTRIBUTE-SYNTAX
+# postalAddress
+# MATCHES FOR EQUALITY
+# ::= {pilotAttributeType 39}
+#
+#
+# personalTitle ATTRIBUTE
+# WITH ATTRIBUTE-SYNTAX
+# caseIgnoreStringSyntax
+# (SIZE (1 .. ub-personal-title))
+# ::= {pilotAttributeType 40}
+#
+#
+# mobileTelephoneNumber ATTRIBUTE
+# WITH ATTRIBUTE-SYNTAX
+# telephoneNumberSyntax
+# ::= {pilotAttributeType 41}
+#
+#
+# pagerTelephoneNumber ATTRIBUTE
+# WITH ATTRIBUTE-SYNTAX
+# telephoneNumberSyntax
+# ::= {pilotAttributeType 42}
+#
+#
+# friendlyCountryName ATTRIBUTE
+# WITH ATTRIBUTE-SYNTAX
+# caseIgnoreStringSyntax
+# ::= {pilotAttributeType 43}
+#
+#
+# uniqueIdentifier ATTRIBUTE
+# WITH ATTRIBUTE-SYNTAX
+# caseIgnoreStringSyntax
+# (SIZE (1 .. ub-unique-identifier))
+# ::= {pilotAttributeType 44}
+#
+#
+# organizationalStatus ATTRIBUTE
+# WITH ATTRIBUTE-SYNTAX
+# caseIgnoreStringSyntax
+# (SIZE (1 .. ub-organizational-status))
+# ::= {pilotAttributeType 45}
+#
+#
+# janetMailbox ATTRIBUTE
+# WITH ATTRIBUTE-SYNTAX
+# caseIgnoreIA5StringSyntax
+# (SIZE (1 .. ub-janet-mailbox))
+# ::= {pilotAttributeType 46}
+#
+#
+# mailPreferenceOption ATTRIBUTE
+# WITH ATTRIBUTE-SYNTAX ENUMERATED {
+# no-list-inclusion(0),
+# any-list-inclusion(1), -- may be added to any lists
+# professional-list-inclusion(2)
+# -- may be added to lists
+# -- which the list provider
+# -- views as related to the
+# -- users professional inter-
+# -- ests, perhaps evaluated
+# -- from the business of the
+# -- organisation or keywords
+# -- in the entry.
+# }
+# ::= {pilotAttributeType 47}
+#
+#
+# buildingName ATTRIBUTE
+# WITH ATTRIBUTE-SYNTAX
+# caseIgnoreStringSyntax
+# (SIZE (1 .. ub-building-name))
+# ::= {pilotAttributeType 48}
+#
+#
+# dSAQuality ATTRIBUTE
+# WITH ATTRIBUTE-SYNTAX DSAQualitySyntax
+# SINGLE VALUE
+# ::= {pilotAttributeType 49}
+#
+#
+# singleLevelQuality ATTRIBUTE
+# WITH ATTRIBUTE-SYNTAX DataQualitySyntax
+# SINGLE VALUE
+#
+#
+# subtreeMinimumQuality ATTRIBUTE
+# WITH ATTRIBUTE-SYNTAX DataQualitySyntax
+# SINGLE VALUE
+# -- Defaults to singleLevelQuality
+# ::= {pilotAttributeType 51}
+#
+#
+# subtreeMaximumQuality ATTRIBUTE
+# WITH ATTRIBUTE-SYNTAX DataQualitySyntax
+# SINGLE VALUE
+# -- Defaults to singleLevelQuality
+# ::= {pilotAttributeType 52}
+#
+#
+# personalSignature ATTRIBUTE
+# WITH ATTRIBUTE-SYNTAX
+# CHOICE {
+# g3-facsimile [3] G3FacsimileBodyPart
+# }
+# (SIZE (1 .. ub-personal-signature))
+# ::= {pilotAttributeType 53}
+#
+#
+# dITRedirect ATTRIBUTE
+# WITH ATTRIBUTE-SYNTAX
+# distinguishedNameSyntax
+# ::= {pilotAttributeType 54}
+#
+#
+# audio ATTRIBUTE
+# WITH ATTRIBUTE-SYNTAX
+# Audio
+# (SIZE (1 .. ub-audio))
+# ::= {pilotAttributeType 55}
+#
+# documentPublisher ATTRIBUTE
+# WITH ATTRIBUTE SYNTAX caseIgnoreStringSyntax
+# ::= {pilotAttributeType 56}
+#
+#
+#
+# -- Generally useful syntaxes
+#
+#
+# caseIgnoreIA5StringSyntax ATTRIBUTE-SYNTAX
+# IA5String
+# MATCHES FOR EQUALITY SUBSTRINGS
+#
+#
+# iA5StringSyntax ATTRIBUTE-SYNTAX
+# IA5String
+# MATCHES FOR EQUALITY SUBSTRINGS
+#
+#
+# -- Syntaxes to support the DNS attributes
+#
+# DNSRecordSyntax ATTRIBUTE-SYNTAX
+# IA5String
+# MATCHES FOR EQUALITY
+#
+#
+# NRSInformationSyntax ATTRIBUTE-SYNTAX
+# NRSInformation
+# MATCHES FOR EQUALITY
+#
+#
+# NRSInformation ::= SET {
+# [0] Context,
+# [1] Address-space-id,
+# routes [2] SEQUENCE OF SEQUENCE {
+# Route-cost,
+# Addressing-info }
+# }
+#
+#
+# -- Upper bounds on length of attribute values
+#
+#
+# ub-document-identifier INTEGER ::= 256
+#
+# ub-document-location INTEGER ::= 256
+#
+# ub-document-title INTEGER ::= 256
+#
+# ub-document-version INTEGER ::= 256
+#
+# ub-favourite-drink INTEGER ::= 256
+#
+# ub-host INTEGER ::= 256
+#
+# ub-information INTEGER ::= 2048
+#
+# ub-unique-identifier INTEGER ::= 256
+#
+# ub-personal-title INTEGER ::= 256
+#
+# ub-photo INTEGER ::= 250000
+#
+# ub-rfc822-mailbox INTEGER ::= 256
+#
+# ub-room-number INTEGER ::= 256
+#
+# ub-text-or-address INTEGER ::= 256
+#
+# ub-user-class INTEGER ::= 256
+#
+# ub-user-identifier INTEGER ::= 256
+#
+# ub-organizational-status INTEGER ::= 256
+#
+# ub-janet-mailbox INTEGER ::= 256
+#
+# ub-building-name INTEGER ::= 256
+#
+# ub-personal-signature ::= 50000
+#
+# ub-audio INTEGER ::= 250000
+#
+# [remainder of memo trimmed]
+
Added: openldap/vendor/openldap-release/servers/slapd/schema/java.schema
===================================================================
--- openldap/vendor/openldap-release/servers/slapd/schema/java.schema (rev 0)
+++ openldap/vendor/openldap-release/servers/slapd/schema/java.schema 2007-09-15 10:38:52 UTC (rev 844)
@@ -0,0 +1,403 @@
+# java.schema -- Java Object Schema
+# $OpenLDAP: pkg/ldap/servers/slapd/schema/java.schema,v 1.5.2.3 2007/01/02 21:44:09 kurt Exp $
+## This work is part of OpenLDAP Software <http://www.openldap.org/>.
+##
+## Copyright 1998-2007 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>.
+#
+# Java Object Schema (defined in RFC 2713)
+# depends upon core.schema
+#
+
+# Network Working Group V. Ryan
+# Request for Comments: 2713 S. Seligman
+# Category: Informational R. Lee
+# Sun Microsystems, Inc.
+# October 1999
+#
+#
+# Schema for Representing Java(tm) Objects in an LDAP Directory
+#
+# Status of this Memo
+#
+# This memo provides information for the Internet community. It does
+# not specify an Internet standard of any kind. Distribution of this
+# memo is unlimited.
+#
+# Copyright Notice
+#
+# Copyright (C) The Internet Society (1999). All Rights Reserved.
+#
+# Abstract
+#
+# This document defines the schema for representing Java(tm) objects in
+# an LDAP directory [LDAPv3]. It defines schema elements to represent
+# a Java serialized object [Serial], a Java marshalled object [RMI], a
+# Java remote object [RMI], and a JNDI reference [JNDI].
+#
+
+# [trimmed]
+
+# 3 Attribute Type Definitions
+#
+# The following attribute types are defined in this document:
+#
+# javaClassName
+# javaClassNames
+# javaCodebase
+# javaSerializedData
+# javaFactory
+# javaReferenceAddress
+# javaDoc
+#
+# 3.1 javaClassName
+#
+# This attribute stores the fully qualified name of the Java object's
+# "distinguished" class or interface (for example, "java.lang.String").
+# It is a single-valued attribute. This attribute's syntax is '
+# Directory String' and its case is significant.
+#
+# ( 1.3.6.1.4.1.42.2.27.4.1.6
+# NAME 'javaClassName'
+# DESC 'Fully qualified name of distinguished Java class or
+# interface'
+# EQUALITY caseExactMatch
+# SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+# SINGLE-VALUE
+# )
+#
+attributetype ( 1.3.6.1.4.1.42.2.27.4.1.6
+ NAME 'javaClassName'
+ DESC 'Fully qualified name of distinguished Java class or interface'
+ EQUALITY caseExactMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ SINGLE-VALUE )
+
+# 3.2 javaCodebase
+#
+# This attribute stores the Java class definition's locations. It
+# specifies the locations from which to load the class definition for
+# the class specified by the javaClassName attribute. Each value of
+# the attribute contains an ordered list of URLs, separated by spaces.
+# For example, a value of "url1 url2 url3" means that the three
+# (possibly interdependent) URLs (url1, url2, and url3) form the
+# codebase for loading in the Java class definition.
+#
+# If the javaCodebase attribute contains more than one value, each
+# value is an independent codebase. That is, there is no relationship
+# between the URLs in one value and those in another; each value can be
+# viewed as an alternate source for loading the Java class definition.
+# See [Java] for information regarding class loading.
+#
+# This attribute's syntax is 'IA5 String' and its case is significant.
+#
+# ( 1.3.6.1.4.1.42.2.27.4.1.7
+# NAME 'javaCodebase'
+# DESC 'URL(s) specifying the location of class definition'
+# EQUALITY caseExactIA5Match
+# SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
+# )
+#
+attributetype ( 1.3.6.1.4.1.42.2.27.4.1.7
+ NAME 'javaCodebase'
+ DESC 'URL(s) specifying the location of class definition'
+ EQUALITY caseExactIA5Match
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
+
+# 3.3 javaClassNames
+#
+# This attribute stores the Java object's fully qualified class or
+# interface names (for example, "java.lang.String"). It is a
+# multivalued attribute. When more than one value is present, each is
+# the name of a class or interface, or ancestor class or interface, of
+# this object.
+#
+# This attribute's syntax is 'Directory String' and its case is
+# significant.
+#
+# ( 1.3.6.1.4.1.42.2.27.4.1.13
+# NAME 'javaClassNames'
+# DESC 'Fully qualified Java class or interface name'
+# EQUALITY caseExactMatch
+# SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+# )
+#
+#
+attributetype ( 1.3.6.1.4.1.42.2.27.4.1.13
+ NAME 'javaClassNames'
+ DESC 'Fully qualified Java class or interface name'
+ EQUALITY caseExactMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+# 3.4 javaSerializedData
+#
+# This attribute stores the serialized form of a Java object. The
+# serialized form is described in [Serial].
+#
+# This attribute's syntax is 'Octet String'.
+#
+# ( 1.3.6.1.4.1.42.2.27.4.1.8
+# NAME 'javaSerializedData
+# DESC 'Serialized form of a Java object'
+# SYNTAX 1.3.6.1.4.1.1466.115.121.1.40
+# SINGLE-VALUE
+# )
+#
+attributetype ( 1.3.6.1.4.1.42.2.27.4.1.8
+ NAME 'javaSerializedData'
+ DESC 'Serialized form of a Java object'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.40
+ SINGLE-VALUE )
+
+# 3.5 javaFactory
+#
+# This attribute stores the fully qualified class name of the object
+# factory (for example, "com.wiz.jndi.WizObjectFactory") that can be
+# used to create an instance of the object identified by the
+# javaClassName attribute.
+#
+# This attribute's syntax is 'Directory String' and its case is
+# significant.
+#
+# ( 1.3.6.1.4.1.42.2.27.4.1.10
+# NAME 'javaFactory'
+# DESC 'Fully qualified Java class name of a JNDI object factory'
+# EQUALITY caseExactMatch
+# SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+# SINGLE-VALUE
+# )
+#
+attributetype ( 1.3.6.1.4.1.42.2.27.4.1.10
+ NAME 'javaFactory'
+ DESC 'Fully qualified Java class name of a JNDI object factory'
+ EQUALITY caseExactMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ SINGLE-VALUE )
+
+# 3.6 javaReferenceAddress
+#
+# This attribute represents the sequence of addresses of a JNDI
+# reference. Each of its values represents one address, a Java object
+# of type javax.naming.RefAddr. Its value is a concatenation of the
+# address type and address contents, preceded by a sequence number (the
+# order of addresses in a JNDI reference is significant). For example:
+#
+# #0#TypeA#ValA
+# #1#TypeB#ValB
+# #2#TypeC##rO0ABXNyABpq...
+#
+# In more detail, the value is encoded as follows:
+#
+# The delimiter is the first character of the value. For readability
+# the character '#' is recommended when it is not otherwise used
+# anywhere in the value, but any character may be used subject to
+# restrictions given below.
+#
+# The first delimiter is followed by the sequence number. The sequence
+# number of an address is its position in the JNDI reference, with the
+# first address being numbered 0. It is represented by its shortest
+# string form, in decimal notation.
+#
+# The sequence number is followed by a delimiter, then by the address
+# type, and then by another delimiter. If the address is of Java class
+# javax.naming.StringRefAddr, then this delimiter is followed by the
+# value of the address contents (which is a string). Otherwise, this
+# delimiter is followed immediately by another delimiter, and then by
+# the Base64 encoding of the serialized form of the entire address.
+#
+# The delimiter may be any character other than a digit or a character
+# contained in the address type. In addition, if the address contents
+# is a string, the delimiter may not be the first character of that
+# string.
+#
+# This attribute's syntax is 'Directory String' and its case is
+# significant. It can contain multiple values.
+#
+# ( 1.3.6.1.4.1.42.2.27.4.1.11
+# NAME 'javaReferenceAddress'
+# DESC 'Addresses associated with a JNDI Reference'
+# EQUALITY caseExactMatch
+# SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+# )
+#
+attributetype ( 1.3.6.1.4.1.42.2.27.4.1.11
+ NAME 'javaReferenceAddress'
+ DESC 'Addresses associated with a JNDI Reference'
+ EQUALITY caseExactMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+# 3.7 javaDoc
+#
+# This attribute stores a pointer to the Java documentation for the
+# class. It's value is a URL. For example, the following URL points to
+# the specification of the java.lang.String class:
+# http://java.sun.com/products/jdk/1.2/docs/api/java/lang/String.html
+#
+# This attribute's syntax is 'IA5 String' and its case is significant.
+#
+# ( 1.3.6.1.4.1.42.2.27.4.1.12
+# NAME 'javaDoc'
+# DESC 'The Java documentation for the class'
+# EQUALITY caseExactIA5Match
+# SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
+# )
+#
+attributetype ( 1.3.6.1.4.1.42.2.27.4.1.12
+ NAME 'javaDoc'
+ DESC 'The Java documentation for the class'
+ EQUALITY caseExactIA5Match
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
+
+# 4 Object Class Definitions
+#
+# The following object classes are defined in this document:
+#
+# javaContainer
+# javaObject
+# javaSerializedObject
+# javaMarshalledObject
+# javaNamingReference
+#
+# 4.1 javaContainer
+#
+# This structural object class represents a container for a Java
+# object.
+#
+# ( 1.3.6.1.4.1.42.2.27.4.2.1
+# NAME 'javaContainer'
+# DESC 'Container for a Java object'
+# SUP top
+# STRUCTURAL
+# MUST ( cn )
+# )
+#
+objectclass ( 1.3.6.1.4.1.42.2.27.4.2.1
+ NAME 'javaContainer'
+ DESC 'Container for a Java object'
+ SUP top
+ STRUCTURAL
+ MUST cn )
+
+# 4.2 javaObject
+#
+# This abstract object class represents a Java object. A javaObject
+# cannot exist in the directory; only auxiliary or structural
+# subclasses of it can exist in the directory.
+#
+# ( 1.3.6.1.4.1.42.2.27.4.2.4
+# NAME 'javaObject'
+# DESC 'Java object representation'
+# SUP top
+# ABSTRACT
+# MUST ( javaClassName )
+# MAY ( javaClassNames $
+# javaCodebase $
+# javaDoc $
+# description )
+# )
+#
+objectclass ( 1.3.6.1.4.1.42.2.27.4.2.4
+ NAME 'javaObject'
+ DESC 'Java object representation'
+ SUP top
+ ABSTRACT
+ MUST javaClassName
+ MAY ( javaClassNames $ javaCodebase $
+ javaDoc $ description ) )
+
+# 4.3 javaSerializedObject
+#
+# This auxiliary object class represents a Java serialized object. It
+# must be mixed in with a structural object class.
+#
+# ( 1.3.6.1.4.1.42.2.27.4.2.5
+# NAME 'javaSerializedObject'
+# DESC 'Java serialized object'
+# SUP javaObject
+# AUXILIARY
+# MUST ( javaSerializedData )
+# )
+#
+objectclass ( 1.3.6.1.4.1.42.2.27.4.2.5
+ NAME 'javaSerializedObject'
+ DESC 'Java serialized object'
+ SUP javaObject
+ AUXILIARY
+ MUST javaSerializedData )
+
+# 4.4 javaMarshalledObject
+#
+# This auxiliary object class represents a Java marshalled object. It
+# must be mixed in with a structural object class.
+#
+# ( 1.3.6.1.4.1.42.2.27.4.2.8
+# NAME 'javaMarshalledObject'
+# DESC 'Java marshalled object'
+# SUP javaObject
+# AUXILIARY
+# MUST ( javaSerializedData )
+# )
+#
+objectclass ( 1.3.6.1.4.1.42.2.27.4.2.8
+ NAME 'javaMarshalledObject'
+ DESC 'Java marshalled object'
+ SUP javaObject
+ AUXILIARY
+ MUST javaSerializedData )
+
+# 4.5 javaNamingReference
+#
+# This auxiliary object class represents a JNDI reference. It must be
+# mixed in with a structural object class.
+#
+# ( 1.3.6.1.4.1.42.2.27.4.2.7
+# NAME 'javaNamingReference'
+# DESC 'JNDI reference'
+# SUP javaObject
+# AUXILIARY
+# MAY ( javaReferenceAddress $
+# javaFactory )
+# )
+#
+objectclass ( 1.3.6.1.4.1.42.2.27.4.2.7
+ NAME 'javaNamingReference'
+ DESC 'JNDI reference'
+ SUP javaObject
+ AUXILIARY
+ MAY ( javaReferenceAddress $ javaFactory ) )
+
+# Full Copyright Statement
+#
+# Copyright (C) The Internet Society (1999). All Rights Reserved.
+#
+# This document and translations of it may be copied and furnished to
+# others, and derivative works that comment on or otherwise explain it
+# or assist in its implementation may be prepared, copied, published
+# and distributed, in whole or in part, without restriction of any
+# kind, provided that the above copyright notice and this paragraph are
+# included on all such copies and derivative works. However, this
+# document itself may not be modified in any way, such as by removing
+# the copyright notice or references to the Internet Society or other
+# Internet organizations, except as needed for the purpose of
+# developing Internet standards in which case the procedures for
+# copyrights defined in the Internet Standards process must be
+# followed, or as required to translate it into languages other than
+# English.
+#
+# The limited permissions granted above are perpetual and will not be
+# revoked by the Internet Society or its successors or assigns.
+#
+# This document and the information contained herein is provided on an
+# "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+# TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+# BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+# HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+# MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Added: openldap/vendor/openldap-release/servers/slapd/schema/ppolicy.schema
===================================================================
--- openldap/vendor/openldap-release/servers/slapd/schema/ppolicy.schema (rev 0)
+++ openldap/vendor/openldap-release/servers/slapd/schema/ppolicy.schema 2007-09-15 10:38:52 UTC (rev 844)
@@ -0,0 +1,531 @@
+# $OpenLDAP: pkg/ldap/servers/slapd/schema/ppolicy.schema,v 1.2.2.4 2007/01/02 21:44:09 kurt Exp $
+## This work is part of OpenLDAP Software <http://www.openldap.org/>.
+##
+## Copyright 2004-2007 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>.
+#
+## Portions Copyright (C) The Internet Society (2004).
+## Please see full copyright statement below.
+
+# Definitions from Draft behera-ldap-password-policy-07 (a work in progress)
+# Password Policy for LDAP Directories
+# With extensions from Hewlett-Packard:
+# pwdCheckModule etc.
+
+# Contents of this file are subject to change (including deletion)
+# without notice.
+#
+# Not recommended for production use!
+# Use with extreme caution!
+
+#Network Working Group J. Sermersheim
+#Internet-Draft Novell, Inc
+#Expires: April 24, 2005 L. Poitou
+# Sun Microsystems
+# October 24, 2004
+#
+#
+# Password Policy for LDAP Directories
+# draft-behera-ldap-password-policy-08.txt
+#
+#Status of this Memo
+#
+# This document is an Internet-Draft and is subject to all provisions
+# of section 3 of RFC 3667. By submitting this Internet-Draft, each
+# author represents that any applicable patent or other IPR claims of
+# which he or she is aware have been or will be disclosed, and any of
+# which he or she become aware will be disclosed, in accordance with
+# RFC 3668.
+#
+# Internet-Drafts are working documents of the Internet Engineering
+# Task Force (IETF), its areas, and its working groups. Note that
+# other groups may also distribute working documents as
+# Internet-Drafts.
+#
+# Internet-Drafts are draft documents valid for a maximum of six months
+# and may be updated, replaced, or obsoleted by other documents at any
+# time. It is inappropriate to use Internet-Drafts as reference
+# material or to cite them other than as "work in progress."
+#
+# The list of current Internet-Drafts can be accessed at
+# http://www.ietf.org/ietf/1id-abstracts.txt.
+#
+# The list of Internet-Draft Shadow Directories can be accessed at
+# http://www.ietf.org/shadow.html.
+#
+# This Internet-Draft will expire on April 24, 2005.
+#
+#Copyright Notice
+#
+# Copyright (C) The Internet Society (2004).
+#
+#Abstract
+#
+# Password policy as described in this document is a set of rules that
+# controls how passwords are used and administered in Lightweight
+# Directory Access Protocol (LDAP) based directories. In order to
+# improve the security of LDAP directories and make it difficult for
+# password cracking programs to break into directories, it is desirable
+# to enforce a set of rules on password usage. These rules are made to
+#
+# [trimmed]
+#
+#5. Schema used for Password Policy
+#
+# The schema elements defined here fall into two general categories. A
+# password policy object class is defined which contains a set of
+# administrative password policy attributes, and a set of operational
+# attributes are defined that hold general password policy state
+# information for each user.
+#
+#5.2 Attribute Types used in the pwdPolicy ObjectClass
+#
+# Following are the attribute types used by the pwdPolicy object class.
+#
+#5.2.1 pwdAttribute
+#
+# This holds the name of the attribute to which the password policy is
+# applied. For example, the password policy may be applied to the
+# userPassword attribute.
+
+attributetype ( 1.3.6.1.4.1.42.2.27.8.1.1
+ NAME 'pwdAttribute'
+ EQUALITY objectIdentifierMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
+
+#5.2.2 pwdMinAge
+#
+# This attribute holds the number of seconds that must elapse between
+# modifications to the password. If this attribute is not present, 0
+# seconds is assumed.
+
+attributetype ( 1.3.6.1.4.1.42.2.27.8.1.2
+ NAME 'pwdMinAge'
+ EQUALITY integerMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
+ SINGLE-VALUE )
+
+#5.2.3 pwdMaxAge
+#
+# This attribute holds the number of seconds after which a modified
+# password will expire.
+#
+# If this attribute is not present, or if the value is 0 the password
+# does not expire. If not 0, the value must be greater than or equal
+# to the value of the pwdMinAge.
+
+attributetype ( 1.3.6.1.4.1.42.2.27.8.1.3
+ NAME 'pwdMaxAge'
+ EQUALITY integerMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
+ SINGLE-VALUE )
+
+#5.2.4 pwdInHistory
+#
+# This attribute specifies the maximum number of used passwords stored
+# in the pwdHistory attribute.
+#
+# If this attribute is not present, or if the value is 0, used
+# passwords are not stored in the pwdHistory attribute and thus may be
+# reused.
+
+attributetype ( 1.3.6.1.4.1.42.2.27.8.1.4
+ NAME 'pwdInHistory'
+ EQUALITY integerMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
+ SINGLE-VALUE )
+
+#5.2.5 pwdCheckQuality
+#
+# {TODO: Consider changing the syntax to OID. Each OID will list a
+# quality rule (like min len, # of special characters, etc). These
+# rules can be specified outsid ethis document.}
+#
+# {TODO: Note that even though this is meant to be a check that happens
+# during password modification, it may also be allowed to happen during
+# authN. This is useful for situations where the password is encrypted
+# when modified, but decrypted when used to authN.}
+#
+# This attribute indicates how the password quality will be verified
+# while being modified or added. If this attribute is not present, or
+# if the value is '0', quality checking will not be enforced. A value
+# of '1' indicates that the server will check the quality, and if the
+# server is unable to check it (due to a hashed password or other
+# reasons) it will be accepted. A value of '2' indicates that the
+# server will check the quality, and if the server is unable to verify
+# it, it will return an error refusing the password.
+
+attributetype ( 1.3.6.1.4.1.42.2.27.8.1.5
+ NAME 'pwdCheckQuality'
+ EQUALITY integerMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
+ SINGLE-VALUE )
+
+#5.2.6 pwdMinLength
+#
+# When quality checking is enabled, this attribute holds the minimum
+# number of characters that must be used in a password. If this
+# attribute is not present, no minimum password length will be
+# enforced. If the server is unable to check the length (due to a
+# hashed password or otherwise), the server will, depending on the
+# value of the pwdCheckQuality attribute, either accept the password
+# without checking it ('0' or '1') or refuse it ('2').
+
+attributetype ( 1.3.6.1.4.1.42.2.27.8.1.6
+ NAME 'pwdMinLength'
+ EQUALITY integerMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
+ SINGLE-VALUE )
+
+#5.2.7 pwdExpireWarning
+#
+# This attribute specifies the maximum number of seconds before a
+# password is due to expire that expiration warning messages will be
+# returned to an authenticating user.
+#
+# If this attribute is not present, or if the value is 0 no warnings
+# will be returned. If not 0, the value must be smaller than the value
+# of the pwdMaxAge attribute.
+
+attributetype ( 1.3.6.1.4.1.42.2.27.8.1.7
+ NAME 'pwdExpireWarning'
+ EQUALITY integerMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
+ SINGLE-VALUE )
+
+#5.2.8 pwdGraceAuthNLimit
+#
+# This attribute specifies the number of times an expired password can
+# be used to authenticate. If this attribute is not present or if the
+# value is 0, authentication will fail.
+
+attributetype ( 1.3.6.1.4.1.42.2.27.8.1.8
+ NAME 'pwdGraceAuthNLimit'
+ EQUALITY integerMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
+ SINGLE-VALUE )
+
+#5.2.9 pwdLockout
+#
+# This attribute indicates, when its value is "TRUE", that the password
+# may not be used to authenticate after a specified number of
+# consecutive failed bind attempts. The maximum number of consecutive
+# failed bind attempts is specified in pwdMaxFailure.
+#
+# If this attribute is not present, or if the value is "FALSE", the
+# password may be used to authenticate when the number of failed bind
+# attempts has been reached.
+
+attributetype ( 1.3.6.1.4.1.42.2.27.8.1.9
+ NAME 'pwdLockout'
+ EQUALITY booleanMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
+ SINGLE-VALUE )
+
+#5.2.10 pwdLockoutDuration
+#
+# This attribute holds the number of seconds that the password cannot
+# be used to authenticate due to too many failed bind attempts. If
+# this attribute is not present, or if the value is 0 the password
+# cannot be used to authenticate until reset by a password
+# administrator.
+
+attributetype ( 1.3.6.1.4.1.42.2.27.8.1.10
+ NAME 'pwdLockoutDuration'
+ EQUALITY integerMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
+ SINGLE-VALUE )
+
+#5.2.11 pwdMaxFailure
+#
+# This attribute specifies the number of consecutive failed bind
+# attempts after which the password may not be used to authenticate.
+# If this attribute is not present, or if the value is 0, this policy
+# is not checked, and the value of pwdLockout will be ignored.
+
+attributetype ( 1.3.6.1.4.1.42.2.27.8.1.11
+ NAME 'pwdMaxFailure'
+ EQUALITY integerMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
+ SINGLE-VALUE )
+
+#5.2.12 pwdFailureCountInterval
+#
+# This attribute holds the number of seconds after which the password
+# failures are purged from the failure counter, even though no
+# successful authentication occurred.
+#
+# If this attribute is not present, or if its value is 0, the failure
+# counter is only reset by a successful authentication.
+
+attributetype ( 1.3.6.1.4.1.42.2.27.8.1.12
+ NAME 'pwdFailureCountInterval'
+ EQUALITY integerMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
+ SINGLE-VALUE )
+
+#5.2.13 pwdMustChange
+#
+# This attribute specifies with a value of "TRUE" that users must
+# change their passwords when they first bind to the directory after a
+# password is set or reset by a password administrator. If this
+# attribute is not present, or if the value is "FALSE", users are not
+# required to change their password upon binding after the password
+# administrator sets or resets the password. This attribute is not set
+# due to any actions specified by this document, it is typically set by
+# a password administrator after resetting a user's password.
+
+attributetype ( 1.3.6.1.4.1.42.2.27.8.1.13
+ NAME 'pwdMustChange'
+ EQUALITY booleanMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
+ SINGLE-VALUE )
+
+#5.2.14 pwdAllowUserChange
+#
+# This attribute indicates whether users can change their own
+# passwords, although the change operation is still subject to access
+# control. If this attribute is not present, a value of "TRUE" is
+# assumed. This attribute is intended to be used in the absense of an
+# access control mechanism.
+
+attributetype ( 1.3.6.1.4.1.42.2.27.8.1.14
+ NAME 'pwdAllowUserChange'
+ EQUALITY booleanMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
+ SINGLE-VALUE )
+
+#5.2.15 pwdSafeModify
+#
+# This attribute specifies whether or not the existing password must be
+# sent along with the new password when being changed. If this
+# attribute is not present, a "FALSE" value is assumed.
+
+attributetype ( 1.3.6.1.4.1.42.2.27.8.1.15
+ NAME 'pwdSafeModify'
+ EQUALITY booleanMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
+ SINGLE-VALUE )
+
+# HP extensions
+#
+# pwdCheckModule
+#
+# This attribute names a user-defined loadable module that provides
+# a check_password() function. If pwdCheckQuality is set to '1' or '2'
+# this function will be called after all of the internal password
+# quality checks have been passed. The function has this prototype:
+#
+# int check_password( char *password, char **errormessage, void *arg )
+#
+# The function should return LDAP_SUCCESS for a valid password.
+
+attributetype ( 1.3.6.1.4.1.4754.1.99.1
+ NAME 'pwdCheckModule'
+ EQUALITY caseExactIA5Match
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
+ DESC 'Loadable module that instantiates "check_password() function'
+ SINGLE-VALUE )
+
+objectclass ( 1.3.6.1.4.1.4754.2.99.1
+ NAME 'pwdPolicyChecker'
+ SUP top
+ AUXILIARY
+ MAY ( pwdCheckModule ) )
+
+#5.1 The pwdPolicy Object Class
+#
+# This object class contains the attributes defining a password policy
+# in effect for a set of users. Section 10 describes the
+# administration of this object, and the relationship between it and
+# particular objects.
+#
+objectclass ( 1.3.6.1.4.1.42.2.27.8.2.1
+ NAME 'pwdPolicy'
+ SUP top
+ AUXILIARY
+ MUST ( pwdAttribute )
+ MAY ( pwdMinAge $ pwdMaxAge $ pwdInHistory $ pwdCheckQuality $
+ pwdMinLength $ pwdExpireWarning $ pwdGraceAuthNLimit $ pwdLockout
+ $ pwdLockoutDuration $ pwdMaxFailure $ pwdFailureCountInterval $
+ pwdMustChange $ pwdAllowUserChange $ pwdSafeModify ) )
+
+#5.3 Attribute Types for Password Policy State Information
+#
+# Password policy state information must be maintained for each user.
+# The information is located in each user entry as a set of operational
+# attributes. These operational attributes are: pwdChangedTime,
+# pwdAccountLockedTime, pwdFailureTime, pwdHistory, pwdGraceUseTime,
+# pwdReset, pwdPolicySubEntry.
+#
+#5.3.1 Password Policy State Attribute Option
+#
+# Since the password policy could apply to several attributes used to
+# store passwords, each of the above operational attributes must have
+# an option to specify which pwdAttribute it applies to. The password
+# policy option is defined as the following:
+#
+# pwd-<passwordAttribute>
+#
+# where passwordAttribute a string following the OID syntax
+# (1.3.6.1.4.1.1466.115.121.1.38). The attribute type descriptor
+# (short name) MUST be used.
+#
+# For example, if the pwdPolicy object has for pwdAttribute
+# "userPassword" then the pwdChangedTime operational attribute, in a
+# user entry, will be:
+#
+# pwdChangedTime;pwd-userPassword: 20000103121520Z
+#
+# This attribute option follows sub-typing semantics. If a client
+# requests a password policy state attribute to be returned in a search
+# operation, and does not specify an option, all subtypes of that
+# policy state attribute are returned.
+#
+#5.3.2 pwdChangedTime
+#
+# This attribute specifies the last time the entry's password was
+# changed. This is used by the password expiration policy. If this
+# attribute does not exist, the password will never expire.
+#
+# ( 1.3.6.1.4.1.42.2.27.8.1.16
+# NAME 'pwdChangedTime'
+# DESC 'The time the password was last changed'
+# EQUALITY generalizedTimeMatch
+# ORDERING generalizedTimeOrderingMatch
+# SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
+# SINGLE-VALUE
+# USAGE directoryOperation )
+#
+#5.3.3 pwdAccountLockedTime
+#
+# This attribute holds the time that the user's account was locked. A
+# locked account means that the password may no longer be used to
+# authenticate. A 000001010000Z value means that the account has been
+# locked permanently, and that only a password administrator can unlock
+# the account.
+#
+# ( 1.3.6.1.4.1.42.2.27.8.1.17
+# NAME 'pwdAccountLockedTime'
+# DESC 'The time an user account was locked'
+# EQUALITY generalizedTimeMatch
+# ORDERING generalizedTimeOrderingMatch
+# SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
+# SINGLE-VALUE
+# USAGE directoryOperation )
+#
+#5.3.4 pwdFailureTime
+#
+# This attribute holds the timestamps of the consecutive authentication
+# failures.
+#
+# ( 1.3.6.1.4.1.42.2.27.8.1.19
+# NAME 'pwdFailureTime'
+# DESC 'The timestamps of the last consecutive authentication
+# failures'
+# EQUALITY generalizedTimeMatch
+# ORDERING generalizedTimeOrderingMatch
+# SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
+# USAGE directoryOperation )
+#
+#5.3.5 pwdHistory
+#
+# This attribute holds a history of previously used passwords. Values
+# of this attribute are transmitted in string format as given by the
+# following ABNF:
+#
+# pwdHistory = time "#" syntaxOID "#" length "#" data
+#
+# time = <generalizedTimeString as specified in 6.14
+# of [RFC2252]>
+#
+# syntaxOID = numericoid ; the string representation of the
+# ; dotted-decimal OID that defines the
+# ; syntax used to store the password.
+# ; numericoid is described in 4.1
+# ; of [RFC2252].
+#
+# length = numericstring ; the number of octets in data.
+# ; numericstring is described in 4.1
+# ; of [RFC2252].
+#
+# data = <octets representing the password in the format
+# specified by syntaxOID>.
+#
+# This format allows the server to store, and transmit a history of
+# passwords that have been used. In order for equality matching to
+# function properly, the time field needs to adhere to a consistent
+# format. For this purpose, the time field MUST be in GMT format.
+#
+# ( 1.3.6.1.4.1.42.2.27.8.1.20
+# NAME 'pwdHistory'
+# DESC 'The history of user s passwords'
+# EQUALITY octetStringMatch
+# SYNTAX 1.3.6.1.4.1.1466.115.121.1.40
+# USAGE directoryOperation )
+#
+#5.3.6 pwdGraceUseTime
+#
+# This attribute holds the timestamps of grace authentications after a
+# password has expired.
+#
+# ( 1.3.6.1.4.1.42.2.27.8.1.21
+# NAME 'pwdGraceUseTime'
+# DESC 'The timestamps of the grace authentication after the
+# password has expired'
+# EQUALITY generalizedTimeMatch
+# SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
+#
+#5.3.7 pwdReset
+#
+# This attribute holds a flag to indicate (when TRUE) that the password
+# has been updated by the password administrator and must be changed by
+# the user on first authentication.
+#
+# ( 1.3.6.1.4.1.42.2.27.8.1.22
+# NAME 'pwdReset'
+# DESC 'The indication that the password has been reset'
+# EQUALITY booleanMatch
+# SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
+# SINGLE-VALUE
+# USAGE directoryOperation )
+#
+#5.3.8 pwdPolicySubentry
+#
+# This attribute points to the pwdPolicy subentry in effect for this
+# object.
+#
+# ( 1.3.6.1.4.1.42.2.27.8.1.23
+# NAME 'pwdPolicySubentry'
+# DESC 'The pwdPolicy subentry in effect for this object'
+# EQUALITY distinguishedNameMatch
+# SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
+# SINGLE-VALUE
+# USAGE directoryOperation )
+#
+#
+#Disclaimer of Validity
+#
+# This document and the information contained herein are provided on an
+# "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+# OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+# ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+# INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+# INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+# WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+#
+#
+#Copyright Statement
+#
+# Copyright (C) The Internet Society (2004). This document is subject
+# to the rights, licenses and restrictions contained in BCP 78, and
+# except as set forth therein, the authors retain all their rights.
+
Modified: openldap/vendor/openldap-release/servers/slapd/schema_init.c
===================================================================
--- openldap/vendor/openldap-release/servers/slapd/schema_init.c 2007-09-15 10:30:38 UTC (rev 843)
+++ openldap/vendor/openldap-release/servers/slapd/schema_init.c 2007-09-15 10:38:52 UTC (rev 844)
@@ -1,5 +1,5 @@
/* schema_init.c - init builtin schema */
-/* $OpenLDAP: pkg/ldap/servers/slapd/schema_init.c,v 1.360.2.17 2007/03/08 20:09:09 ando Exp $ */
+/* $OpenLDAP: pkg/ldap/servers/slapd/schema_init.c,v 1.360.2.18 2007/05/13 18:15:21 hallvard Exp $ */
/* This work is part of OpenLDAP Software <http://www.openldap.org/>.
*
* Copyright 1998-2007 The OpenLDAP Foundation.
@@ -4001,6 +4001,8 @@
mru_destroy();
syn_destroy();
- ldap_pvt_thread_mutex_destroy( &ad_undef_mutex );
- ldap_pvt_thread_mutex_destroy( &oc_undef_mutex );
+ if( schema_init_done ) {
+ ldap_pvt_thread_mutex_destroy( &ad_undef_mutex );
+ ldap_pvt_thread_mutex_destroy( &oc_undef_mutex );
+ }
}
Modified: openldap/vendor/openldap-release/servers/slapd/slap.h
===================================================================
--- openldap/vendor/openldap-release/servers/slapd/slap.h 2007-09-15 10:30:38 UTC (rev 843)
+++ openldap/vendor/openldap-release/servers/slapd/slap.h 2007-09-15 10:38:52 UTC (rev 844)
@@ -1,5 +1,5 @@
/* slap.h - stand alone ldap server include file */
-/* $OpenLDAP: pkg/ldap/servers/slapd/slap.h,v 1.612.2.45 2007/01/03 08:55:03 hyc Exp $ */
+/* $OpenLDAP: pkg/ldap/servers/slapd/slap.h,v 1.612.2.46 2007/07/23 19:44:46 hallvard Exp $ */
/* This work is part of OpenLDAP Software <http://www.openldap.org/>.
*
* Copyright 1998-2007 The OpenLDAP Foundation.
@@ -1655,7 +1655,7 @@
struct sync_cookie {
struct berval ctxcsn;
struct berval octet_str;
- long rid;
+ int rid;
LDAP_STAILQ_ENTRY(sync_cookie) sc_next;
};
Modified: openldap/vendor/openldap-release/servers/slapd/syncrepl.c
===================================================================
--- openldap/vendor/openldap-release/servers/slapd/syncrepl.c 2007-09-15 10:30:38 UTC (rev 843)
+++ openldap/vendor/openldap-release/servers/slapd/syncrepl.c 2007-09-15 10:38:52 UTC (rev 844)
@@ -1,5 +1,5 @@
/* syncrepl.c -- Replication Engine which uses the LDAP Sync protocol */
-/* $OpenLDAP: pkg/ldap/servers/slapd/syncrepl.c,v 1.168.2.47 2007/04/06 21:49:16 hyc Exp $ */
+/* $OpenLDAP: pkg/ldap/servers/slapd/syncrepl.c,v 1.168.2.49 2007/08/08 16:26:00 ando Exp $ */
/* This work is part of OpenLDAP Software <http://www.openldap.org/>.
*
* Copyright 2003-2007 The OpenLDAP Foundation.
@@ -52,7 +52,7 @@
typedef struct syncinfo_s {
struct slap_backend_db *si_be;
struct re_s *si_re;
- long si_rid;
+ int si_rid;
slap_bindconf si_bindconf;
struct berval si_base;
struct berval si_logbase;
@@ -2892,6 +2892,14 @@
Debug( LDAP_DEBUG_ANY, "%s: %s.\n", c->log, c->msg, 0 );
return -1;
}
+ if ( select_backend( &si->si_base, 0, 0 ) != c->be ) {
+ ber_memfree( si->si_base.bv_val );
+ snprintf( c->msg, sizeof( c->msg ),
+ "Base DN \"%s\" is not within the database naming context",
+ val );
+ Debug( LDAP_DEBUG_ANY, "%s: %s.\n", c->log, c->msg, 0 );
+ return -1;
+ }
gots |= GOT_BASE;
} else if ( !strncasecmp( c->argv[ i ], LOGBASESTR "=",
STRLENOF( LOGBASESTR "=" ) ) )
@@ -3316,7 +3324,7 @@
si->si_bindconf.sb_uri = uri;
ptr = buf;
- ptr += snprintf( ptr, sizeof( buf ), IDSTR "=%03ld " PROVIDERSTR "=%s",
+ ptr += snprintf( ptr, sizeof( buf ), IDSTR "=%03d " PROVIDERSTR "=%s",
si->si_rid, si->si_bindconf.sb_uri.bv_val );
if ( !BER_BVISNULL( &bc )) {
ptr = lutil_strcopy( ptr, bc.bv_val );
Modified: openldap/vendor/openldap-release/servers/slurpd/st.c
===================================================================
--- openldap/vendor/openldap-release/servers/slurpd/st.c 2007-09-15 10:30:38 UTC (rev 843)
+++ openldap/vendor/openldap-release/servers/slurpd/st.c 2007-09-15 10:38:52 UTC (rev 844)
@@ -1,4 +1,4 @@
-/* $OpenLDAP: pkg/ldap/servers/slurpd/st.c,v 1.18.2.5 2007/01/02 21:44:12 kurt Exp $ */
+/* $OpenLDAP: pkg/ldap/servers/slurpd/st.c,v 1.18.2.6 2007/07/01 12:15:17 hallvard Exp $ */
/* This work is part of OpenLDAP Software <http://www.openldap.org/>.
*
* Copyright 1998-2007 The OpenLDAP Foundation.
@@ -180,6 +180,7 @@
int rc;
char *hostname, *port, *timestamp, *seq, *p, *t;
int found;
+ long last;
if ( st == NULL ) {
return -1;
@@ -235,11 +236,11 @@
if ( !strcmp( hostname, sglob->st->st_data[ i ]->hostname ) &&
lutil_atoi( &p, port ) == 0 && p == sglob->st->st_data[ i ]->port )
{
- found = 1;
- if ( lutil_atol( &sglob->st->st_data[ i ]->last, timestamp ) != 0
- || lutil_atoi( &sglob->st->st_data[ i ]->seq, seq ) != 0 )
- {
- found = 0;
+ found = (lutil_atol( &last, timestamp ) == 0);
+ if ( found ) {
+ sglob->st->st_data[i]->last = last;
+ if ( lutil_atoi( &sglob->st->st_data[i]->seq, seq ) != 0 )
+ found = 0;
}
break;
}
More information about the Pkg-openldap-devel
mailing list