From 1fa65e992cae6edbfc0e3bb6eb3909039c0eccf3 Mon Sep 17 00:00:00 2001
From: Kurt Zeilenga <kurt@openldap.org>
Date: Sun, 12 Feb 2006 04:19:48 +0000
Subject: [PATCH] Sync with HEAD

---
 doc/devel/toolargs                            |  27 +
 .../draft-ietf-ldapbis-user-schema-xx.txt     | 198 ++--
 doc/drafts/draft-legg-ldap-binary-xx.txt      | 172 ++--
 doc/drafts/draft-weltman-ldapv3-proxy-xx.txt  | 295 ------
 .../draft-zeilenga-ldap-grouping-xx.txt       | 843 ++++++++++++++++
 doc/drafts/draft-zeilenga-ldap-txn-xx.txt     | 395 ++++++++
 doc/rfc/INDEX                                 |   2 +
 doc/rfc/rfc4370.txt                           | 283 ++++++
 doc/rfc/rfc4373.txt                           | 899 ++++++++++++++++++
 9 files changed, 2636 insertions(+), 478 deletions(-)
 create mode 100644 doc/devel/toolargs
 delete mode 100644 doc/drafts/draft-weltman-ldapv3-proxy-xx.txt
 create mode 100644 doc/drafts/draft-zeilenga-ldap-grouping-xx.txt
 create mode 100644 doc/drafts/draft-zeilenga-ldap-txn-xx.txt
 create mode 100644 doc/rfc/rfc4370.txt
 create mode 100644 doc/rfc/rfc4373.txt

diff --git a/doc/devel/toolargs b/doc/devel/toolargs
new file mode 100644
index 0000000000..24c1482c88
--- /dev/null
+++ b/doc/devel/toolargs
@@ -0,0 +1,27 @@
+Tools           ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz
+slapacl            D F              U  X   b d f        o     uv
+slapadd              F                     bcd f     l n  q  tuvw
+slapauth             F      M    R  U  X     d f               v
+slapcat              F                    abcd f     l n    s  v
+slapdn               F       N P             d f               v
+slapindex            F                     bcd f       n  q    v
+slappasswd                         T        c    h          s uv
+slaptest             F                       d f              uv
+
+* General flags:
+	-F config directory
+	-U authcID
+	-X authzID
+	-b suffix (slapacl: entryDN)
+	-c continue mode
+	-d debug level
+	-f config file
+	-l LDIF file
+	-n database number
+	-q "quick" mode
+	-s subtree
+	-u dryrun (slappasswd: RFC2307 userPassword)
+	-v verbose
+
+---
+$Header$
diff --git a/doc/drafts/draft-ietf-ldapbis-user-schema-xx.txt b/doc/drafts/draft-ietf-ldapbis-user-schema-xx.txt
index bf6bf8b93e..fb2e7a231b 100644
--- a/doc/drafts/draft-ietf-ldapbis-user-schema-xx.txt
+++ b/doc/drafts/draft-ietf-ldapbis-user-schema-xx.txt
@@ -1,14 +1,18 @@
 
 
+
+
+
+
 INTERNET-DRAFT                                      Editor: A. Sciberras
 Intended Category:  Standard Track                               eB2Bcom
-Updates:  RFC 2247, RFC 2798, RFC 2377                     July 11, 2005
+Updates:  RFC 2247, RFC 2798, RFC 2377                  January 30, 2006
 Obsoletes:  RFC 2256
 
                    LDAP: Schema for User Applications
-                 draft-ietf-ldapbis-user-schema-10.txt
+                 draft-ietf-ldapbis-user-schema-11.txt
 
-    Copyright (C) The Internet Society (2005). All Rights Reserved.
+    Copyright (C) The Internet Society (2006). All Rights Reserved.
 
    Status of this Memo
 
@@ -44,16 +48,16 @@ Obsoletes:  RFC 2256
    send editorial comments directly to the editor
    <andrew.sciberras@eb2bcom.com>.
 
-   This Internet-Draft expires on 11 January 2006.
+   This Internet-Draft expires on 30 July 2006.
 
 
 
 
 
 
-Sciberras                Expires 11 January 2006                [Page 1]
+Sciberras                 Expires 30 July 2006                  [Page 1]
 
-INTERNET-DRAFT     LDAP: Schema for User Applications      July 11, 2005
+INTERNET-DRAFT     LDAP: Schema for User Applications   January 30, 2006
 
 
 Abstract
@@ -107,9 +111,9 @@ Abstract
 
 
 
-Sciberras                Expires 11 January 2006                [Page 2]
+Sciberras                 Expires 30 July 2006                  [Page 2]
 
-INTERNET-DRAFT     LDAP: Schema for User Applications      July 11, 2005
+INTERNET-DRAFT     LDAP: Schema for User Applications   January 30, 2006
 
 
 Table of Contents
@@ -163,9 +167,9 @@ Table of Contents
 
 
 
-Sciberras                Expires 11 January 2006                [Page 3]
+Sciberras                 Expires 30 July 2006                  [Page 3]
 
-INTERNET-DRAFT     LDAP: Schema for User Applications      July 11, 2005
+INTERNET-DRAFT     LDAP: Schema for User Applications   January 30, 2006
 
 
        2.37 'telexNumber'. . . . . . . . . . . . . . . . . . . . . .  19
@@ -219,9 +223,9 @@ INTERNET-DRAFT     LDAP: Schema for User Applications      July 11, 2005
 
 
 
-Sciberras                Expires 11 January 2006                [Page 4]
+Sciberras                 Expires 30 July 2006                  [Page 4]
 
-INTERNET-DRAFT     LDAP: Schema for User Applications      July 11, 2005
+INTERNET-DRAFT     LDAP: Schema for User Applications   January 30, 2006
 
 
 1.  Introduction
@@ -275,12 +279,12 @@ INTERNET-DRAFT     LDAP: Schema for User Applications      July 11, 2005
 
 
 
-Sciberras                Expires 11 January 2006                [Page 5]
+Sciberras                 Expires 30 July 2006                  [Page 5]
 
-INTERNET-DRAFT     LDAP: Schema for User Applications      July 11, 2005
+INTERNET-DRAFT     LDAP: Schema for User Applications   January 30, 2006
 
 
-   using the Augmented Backus-Naur Form (ABNF) [RFC2234] of
+   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
@@ -331,9 +335,9 @@ INTERNET-DRAFT     LDAP: Schema for User Applications      July 11, 2005
 
 
 
-Sciberras                Expires 11 January 2006                [Page 6]
+Sciberras                 Expires 30 July 2006                  [Page 6]
 
-INTERNET-DRAFT     LDAP: Schema for User Applications      July 11, 2005
+INTERNET-DRAFT     LDAP: Schema for User Applications   January 30, 2006
 
 
    Examples: "DE", "AU" and "FR".
@@ -354,10 +358,10 @@ INTERNET-DRAFT     LDAP: Schema for User Applications      July 11, 2005
 2.4  'dc'
 
    The 'dc' ('domainComponent' in RFC 2247) attribute type is a string
-   holding one component, a <label> [RFC1034], of a DNS 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.
+   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'
@@ -370,26 +374,26 @@ INTERNET-DRAFT     LDAP: Schema for User Applications      July 11, 2005
    [Syntaxes].
 
    Examples: Valid values include "example" and "com".  The value
-             "example.com" is invalid, because it contains two <label>
+             "example.com" is invalid, because it contains two label
              components.
 
-   It is noted that the directory will not ensure that values of this
-   attribute conform to the label production [RFC1034].  It is the
-   application's responsibility to ensure domains it stores in this
-   attribute are appropriately represented.
+   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.
+
+
 
-   It is also noted that applications supporting Internationalized
-   Domain Names SHALL use the ToASCII method [RFC3490] to produce
-   <label> components of the <domain> [RFC1034] production.  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 11 January 2006                [Page 7]
+
+
+
+Sciberras                 Expires 30 July 2006                  [Page 7]
 
-INTERNET-DRAFT     LDAP: Schema for User Applications      July 11, 2005
+INTERNET-DRAFT     LDAP: Schema for User Applications   January 30, 2006
 
 
 2.5  'description'
@@ -443,9 +447,9 @@ INTERNET-DRAFT     LDAP: Schema for User Applications      July 11, 2005
 
 
 
-Sciberras                Expires 11 January 2006                [Page 8]
+Sciberras                 Expires 30 July 2006                  [Page 8]
 
-INTERNET-DRAFT     LDAP: Schema for User Applications      July 11, 2005
+INTERNET-DRAFT     LDAP: Schema for User Applications   January 30, 2006
 
 
    attribute types with a DN syntax can inherit.
@@ -499,9 +503,9 @@ INTERNET-DRAFT     LDAP: Schema for User Applications      July 11, 2005
 
 
 
-Sciberras                Expires 11 January 2006                [Page 9]
+Sciberras                 Expires 30 July 2006                  [Page 9]
 
-INTERNET-DRAFT     LDAP: Schema for User Applications      July 11, 2005
+INTERNET-DRAFT     LDAP: Schema for User Applications   January 30, 2006
 
 
       ( 2.5.4.47 NAME 'enhancedSearchGuide'
@@ -555,9 +559,9 @@ INTERNET-DRAFT     LDAP: Schema for User Applications      July 11, 2005
 
 
 
-Sciberras                Expires 11 January 2006               [Page 10]
+Sciberras                 Expires 30 July 2006                 [Page 10]
 
-INTERNET-DRAFT     LDAP: Schema for User Applications      July 11, 2005
+INTERNET-DRAFT     LDAP: Schema for User Applications   January 30, 2006
 
 
 2.13  'houseIdentifier'
@@ -611,9 +615,9 @@ INTERNET-DRAFT     LDAP: Schema for User Applications      July 11, 2005
 
 
 
-Sciberras                Expires 11 January 2006               [Page 11]
+Sciberras                 Expires 30 July 2006                 [Page 11]
 
-INTERNET-DRAFT     LDAP: Schema for User Applications      July 11, 2005
+INTERNET-DRAFT     LDAP: Schema for User Applications   January 30, 2006
 
 
 2.16  'l'
@@ -667,9 +671,9 @@ INTERNET-DRAFT     LDAP: Schema for User Applications      July 11, 2005
 
 
 
-Sciberras                Expires 11 January 2006               [Page 12]
+Sciberras                 Expires 30 July 2006                 [Page 12]
 
-INTERNET-DRAFT     LDAP: Schema for User Applications      July 11, 2005
+INTERNET-DRAFT     LDAP: Schema for User Applications   January 30, 2006
 
 
 2.19  'o'
@@ -723,9 +727,9 @@ INTERNET-DRAFT     LDAP: Schema for User Applications      July 11, 2005
 
 
 
-Sciberras                Expires 11 January 2006               [Page 13]
+Sciberras                 Expires 30 July 2006                 [Page 13]
 
-INTERNET-DRAFT     LDAP: Schema for User Applications      July 11, 2005
+INTERNET-DRAFT     LDAP: Schema for User Applications   January 30, 2006
 
 
       ( 2.5.4.19 NAME 'physicalDeliveryOfficeName'
@@ -779,9 +783,9 @@ INTERNET-DRAFT     LDAP: Schema for User Applications      July 11, 2005
 
 
 
-Sciberras                Expires 11 January 2006               [Page 14]
+Sciberras                 Expires 30 July 2006                 [Page 14]
 
-INTERNET-DRAFT     LDAP: Schema for User Applications      July 11, 2005
+INTERNET-DRAFT     LDAP: Schema for User Applications   January 30, 2006
 
 
    at a box on premises of the Postal Service.  Each postal box
@@ -835,9 +839,9 @@ INTERNET-DRAFT     LDAP: Schema for User Applications      July 11, 2005
 
 
 
-Sciberras                Expires 11 January 2006               [Page 15]
+Sciberras                 Expires 30 July 2006                 [Page 15]
 
-INTERNET-DRAFT     LDAP: Schema for User Applications      July 11, 2005
+INTERNET-DRAFT     LDAP: Schema for User Applications   January 30, 2006
 
 
 2.28  'roleOccupant'
@@ -891,9 +895,9 @@ INTERNET-DRAFT     LDAP: Schema for User Applications      July 11, 2005
 
 
 
-Sciberras                Expires 11 January 2006               [Page 16]
+Sciberras                 Expires 30 July 2006                 [Page 16]
 
-INTERNET-DRAFT     LDAP: Schema for User Applications      July 11, 2005
+INTERNET-DRAFT     LDAP: Schema for User Applications   January 30, 2006
 
 
             Since the role objects are related to the person object, the
@@ -947,9 +951,9 @@ INTERNET-DRAFT     LDAP: Schema for User Applications      July 11, 2005
 
 
 
-Sciberras                Expires 11 January 2006               [Page 17]
+Sciberras                 Expires 30 July 2006                 [Page 17]
 
-INTERNET-DRAFT     LDAP: Schema for User Applications      July 11, 2005
+INTERNET-DRAFT     LDAP: Schema for User Applications   January 30, 2006
 
 
 2.34  'street'
@@ -1003,9 +1007,9 @@ INTERNET-DRAFT     LDAP: Schema for User Applications      July 11, 2005
 
 
 
-Sciberras                Expires 11 January 2006               [Page 18]
+Sciberras                 Expires 30 July 2006                 [Page 18]
 
-INTERNET-DRAFT     LDAP: Schema for User Applications      July 11, 2005
+INTERNET-DRAFT     LDAP: Schema for User Applications   January 30, 2006
 
 
 2.37  'telexNumber'
@@ -1059,9 +1063,9 @@ INTERNET-DRAFT     LDAP: Schema for User Applications      July 11, 2005
 
 
 
-Sciberras                Expires 11 January 2006               [Page 19]
+Sciberras                 Expires 30 July 2006                 [Page 19]
 
-INTERNET-DRAFT     LDAP: Schema for User Applications      July 11, 2005
+INTERNET-DRAFT     LDAP: Schema for User Applications   January 30, 2006
 
 
    between objects when a distinguished name has been reused.  Each
@@ -1115,9 +1119,9 @@ INTERNET-DRAFT     LDAP: Schema for User Applications      July 11, 2005
 
 
 
-Sciberras                Expires 11 January 2006               [Page 20]
+Sciberras                 Expires 30 July 2006                 [Page 20]
 
-INTERNET-DRAFT     LDAP: Schema for User Applications      July 11, 2005
+INTERNET-DRAFT     LDAP: Schema for User Applications   January 30, 2006
 
 
 2.42  'x121Address'
@@ -1171,9 +1175,9 @@ INTERNET-DRAFT     LDAP: Schema for User Applications      July 11, 2005
 
 
 
-Sciberras                Expires 11 January 2006               [Page 21]
+Sciberras                 Expires 30 July 2006                 [Page 21]
 
-INTERNET-DRAFT     LDAP: Schema for User Applications      July 11, 2005
+INTERNET-DRAFT     LDAP: Schema for User Applications   January 30, 2006
 
 
 3.  Object Classes
@@ -1227,9 +1231,9 @@ INTERNET-DRAFT     LDAP: Schema for User Applications      July 11, 2005
 
 
 
-Sciberras                Expires 11 January 2006               [Page 22]
+Sciberras                 Expires 30 July 2006                 [Page 22]
 
-INTERNET-DRAFT     LDAP: Schema for User Applications      July 11, 2005
+INTERNET-DRAFT     LDAP: Schema for User Applications   January 30, 2006
 
 
 3.4  'device'
@@ -1283,9 +1287,9 @@ INTERNET-DRAFT     LDAP: Schema for User Applications      July 11, 2005
 
 
 
-Sciberras                Expires 11 January 2006               [Page 23]
+Sciberras                 Expires 30 July 2006                 [Page 23]
 
-INTERNET-DRAFT     LDAP: Schema for User Applications      July 11, 2005
+INTERNET-DRAFT     LDAP: Schema for User Applications   January 30, 2006
 
 
                cn )
@@ -1339,9 +1343,9 @@ INTERNET-DRAFT     LDAP: Schema for User Applications      July 11, 2005
 
 
 
-Sciberras                Expires 11 January 2006               [Page 24]
+Sciberras                 Expires 30 July 2006                 [Page 24]
 
-INTERNET-DRAFT     LDAP: Schema for User Applications      July 11, 2005
+INTERNET-DRAFT     LDAP: Schema for User Applications   January 30, 2006
 
 
       ( 2.5.6.7 NAME 'organizationalPerson'
@@ -1395,9 +1399,9 @@ INTERNET-DRAFT     LDAP: Schema for User Applications      July 11, 2005
 
 
 
-Sciberras                Expires 11 January 2006               [Page 25]
+Sciberras                 Expires 30 July 2006                 [Page 25]
 
-INTERNET-DRAFT     LDAP: Schema for User Applications      July 11, 2005
+INTERNET-DRAFT     LDAP: Schema for User Applications   January 30, 2006
 
 
 3.12  'person'
@@ -1451,9 +1455,9 @@ INTERNET-DRAFT     LDAP: Schema for User Applications      July 11, 2005
 
 
 
-Sciberras                Expires 11 January 2006               [Page 26]
+Sciberras                 Expires 30 July 2006                 [Page 26]
 
-INTERNET-DRAFT     LDAP: Schema for User Applications      July 11, 2005
+INTERNET-DRAFT     LDAP: Schema for User Applications   January 30, 2006
 
 
 4.  IANA Considerations
@@ -1507,9 +1511,9 @@ INTERNET-DRAFT     LDAP: Schema for User Applications      July 11, 2005
 
 
 
-Sciberras                Expires 11 January 2006               [Page 27]
+Sciberras                 Expires 30 July 2006                 [Page 27]
 
-INTERNET-DRAFT     LDAP: Schema for User Applications      July 11, 2005
+INTERNET-DRAFT     LDAP: Schema for User Applications   January 30, 2006
 
 
       internationalISDNNumber      A    2.5.4.25
@@ -1563,16 +1567,17 @@ INTERNET-DRAFT     LDAP: Schema for User Applications      July 11, 2005
 
 
 
-Sciberras                Expires 11 January 2006               [Page 28]
+Sciberras                 Expires 30 July 2006                 [Page 28]
 
-INTERNET-DRAFT     LDAP: Schema for User Applications      July 11, 2005
+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 may
-   result in disclosure of the password to unauthorized parties.
+   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
@@ -1618,10 +1623,9 @@ INTERNET-DRAFT     LDAP: Schema for User Applications      July 11, 2005
 
 
 
-
-Sciberras                Expires 11 January 2006               [Page 29]
+Sciberras                 Expires 30 July 2006                 [Page 29]
 
-INTERNET-DRAFT     LDAP: Schema for User Applications      July 11, 2005
+INTERNET-DRAFT     LDAP: Schema for User Applications   January 30, 2006
 
 
 7.  References
@@ -1653,9 +1657,6 @@ INTERNET-DRAFT     LDAP: Schema for User Applications      July 11, 2005
    [RFC2119]     Bradner, S., "Key words for use in RFCs to Indicate
                  Requirement Levels", RFC 2119, March 1997
 
-   [RFC2234]     Crocker, D., Overell P., "Augmented BNF for Syntax
-                 Specifications: ABNF", RFC 2234, November 1997
-
    [RFC3490]     Faltstrom P., Hoffman P., Costello A.,
                  "Internationalizing Domain Names in Applications
                  (IDNA)", RFC 3490, March 2003
@@ -1663,6 +1664,9 @@ INTERNET-DRAFT     LDAP: Schema for User Applications      July 11, 2005
    [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)
@@ -1675,9 +1679,9 @@ INTERNET-DRAFT     LDAP: Schema for User Applications      July 11, 2005
 
 
 
-Sciberras                Expires 11 January 2006               [Page 30]
+Sciberras                 Expires 30 July 2006                 [Page 30]
 
-INTERNET-DRAFT     LDAP: Schema for User Applications      July 11, 2005
+INTERNET-DRAFT     LDAP: Schema for User Applications   January 30, 2006
 
 
    [X.509]       The Directory:  Authentication Framework, ITU-T
@@ -1713,7 +1717,7 @@ INTERNET-DRAFT     LDAP: Schema for User Applications      July 11, 2005
    [RFC2798]     Smith, M., "Definition of the inetOrgPerson LDAP Object
                  Class", RFC 2798, April 2000
 
-   [X.500]       ITU-T Recommendations X.5000 (1993) | ISO/IEC
+   [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.
@@ -1731,9 +1735,9 @@ INTERNET-DRAFT     LDAP: Schema for User Applications      July 11, 2005
 
 
 
-Sciberras                Expires 11 January 2006               [Page 31]
+Sciberras                 Expires 30 July 2006                 [Page 31]
 
-INTERNET-DRAFT     LDAP: Schema for User Applications      July 11, 2005
+INTERNET-DRAFT     LDAP: Schema for User Applications   January 30, 2006
 
 
    Email:  andrew.sciberras@eb2bcom.com
@@ -1764,7 +1768,7 @@ INTERNET-DRAFT     LDAP: Schema for User Applications      July 11, 2005
 
 10.  Full Copyright Statement
 
-   Copyright (C) The Internet Society (2005).
+   Copyright (C) The Internet Society (2006).
 
    This document is subject to the rights, licenses and restrictions
    contained in BCP 78, and except as set forth therein, the authors
@@ -1787,9 +1791,9 @@ INTERNET-DRAFT     LDAP: Schema for User Applications      July 11, 2005
 
 
 
-Sciberras                Expires 11 January 2006               [Page 32]
+Sciberras                 Expires 30 July 2006                 [Page 32]
 
-INTERNET-DRAFT     LDAP: Schema for User Applications      July 11, 2005
+INTERNET-DRAFT     LDAP: Schema for User Applications   January 30, 2006
 
 
                   Appendix A  Changes Made Since RFC 2256
@@ -1843,9 +1847,9 @@ INTERNET-DRAFT     LDAP: Schema for User Applications      July 11, 2005
 
 
 
-Sciberras                Expires 11 January 2006               [Page 33]
+Sciberras                 Expires 30 July 2006                 [Page 33]
 
-INTERNET-DRAFT     LDAP: Schema for User Applications      July 11, 2005
+INTERNET-DRAFT     LDAP: Schema for User Applications   January 30, 2006
 
 
       12. Numerous edititorial changes.
@@ -1899,9 +1903,9 @@ INTERNET-DRAFT     LDAP: Schema for User Applications      July 11, 2005
 
 
 
-Sciberras                Expires 11 January 2006               [Page 34]
+Sciberras                 Expires 30 July 2006                 [Page 34]
 
-INTERNET-DRAFT     LDAP: Schema for User Applications      July 11, 2005
+INTERNET-DRAFT     LDAP: Schema for User Applications   January 30, 2006
 
 
       30. Spelt out and referenced ABNF on first usage.
@@ -1955,5 +1959,5 @@ INTERNET-DRAFT     LDAP: Schema for User Applications      July 11, 2005
 
 
 
-Sciberras                Expires 11 January 2006               [Page 35]
+Sciberras                 Expires 30 July 2006                 [Page 35]
 
diff --git a/doc/drafts/draft-legg-ldap-binary-xx.txt b/doc/drafts/draft-legg-ldap-binary-xx.txt
index efaf5d3692..1a6010758c 100644
--- a/doc/drafts/draft-legg-ldap-binary-xx.txt
+++ b/doc/drafts/draft-legg-ldap-binary-xx.txt
@@ -5,15 +5,14 @@
 
 
 INTERNET-DRAFT                                                   S. Legg
-draft-legg-ldap-binary-03.txt                                    eB2Bcom
-Intended Category: Standards Track                           7 June 2005
-Updates: [SYNTAX]
+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 (2005). All Rights Reserved.
+               Copyright (C) The Internet Society (2006).
 
    Status of this Memo
 
@@ -22,9 +21,6 @@ Updates: [SYNTAX]
    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
@@ -46,24 +42,24 @@ Updates: [SYNTAX]
    <ietf-ldapbis@openldap.org>.  Please send editorial comments directly
    to the editor <steven.legg@eb2bcom.com>.
 
-   This Internet-Draft expires on 7 December 2005.
+   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 7 December 2005                [Page 1]
+Legg                      Expires 30 July 2006                  [Page 1]
 
-INTERNET-DRAFT      LDAP: The Binary Encoding Option        June 7, 2005
+INTERNET-DRAFT      LDAP: The Binary Encoding Option    January 30, 2006
 
 
-   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 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
@@ -111,9 +107,13 @@ INTERNET-DRAFT      LDAP: The Binary Encoding Option        June 7, 2005
 
 
 
-Legg                     Expires 7 December 2005                [Page 2]
+
+
+
+
+Legg                      Expires 30 July 2006                  [Page 2]
 
-INTERNET-DRAFT      LDAP: The Binary Encoding Option        June 7, 2005
+INTERNET-DRAFT      LDAP: The Binary Encoding Option    January 30, 2006
 
 
 Table of Contents
@@ -123,11 +123,11 @@ Table of Contents
    3.  The binary Option. . . . . . . . . . . . . . . . . . . . . . .  4
    4.  Syntaxes Requiring Binary Transfer . . . . . . . . . . . . . .  4
    5.  Attributes Returned in a Search. . . . . . . . . . . . . . . .  5
-   6.  All User Attributes. . . . . . . . . . . . . . . . . . . . . .  5
+   6.  All User Attributes. . . . . . . . . . . . . . . . . . . . . .  6
    7.  Conflicting Requests . . . . . . . . . . . . . . . . . . . . .  6
    8.  Security Considerations. . . . . . . . . . . . . . . . . . . .  6
    9.  IANA Considerations. . . . . . . . . . . . . . . . . . . . . .  6
-   10. References . . . . . . . . . . . . . . . . . . . . . . . . . .  6
+   10. References . . . . . . . . . . . . . . . . . . . . . . . . . .  7
        10.1.  Normative References. . . . . . . . . . . . . . . . . .  7
        10.2.  Informative References. . . . . . . . . . . . . . . . .  7
    Author's Address . . . . . . . . . . . . . . . . . . . . . . . . .  8
@@ -155,21 +155,25 @@ Table of Contents
    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.  However the binary option was not included in the newer LDAP
-   technical specification due to a lack of consistency in its
-   implementation.  This document reintroduces the binary option.
-   However, except for the case of certain attribute syntaxes whose
-   values are required to BER encoded, no attempt is made here to
-   eliminate the known consistency problems.  Rather the focus is on
-   capturing current behaviours.  A more thorough solution is left for a
-   future specification.
+   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 7 December 2005                [Page 3]
+Legg                      Expires 30 July 2006                  [Page 3]
 
-INTERNET-DRAFT      LDAP: The Binary Encoding Option        June 7, 2005
+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
@@ -177,7 +181,7 @@ INTERNET-DRAFT      LDAP: The Binary Encoding Option        June 7, 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, RFC 2119
-   [KEYWORD].
+   [BCP14].
 
 3.  The binary Option
 
@@ -216,24 +220,26 @@ INTERNET-DRAFT      LDAP: The Binary Encoding Option        June 7, 2005
 
 4.  Syntaxes Requiring Binary Transfer
 
-   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
 
 
 
-Legg                     Expires 7 December 2005                [Page 4]
+Legg                      Expires 30 July 2006                  [Page 4]
 
-INTERNET-DRAFT      LDAP: The Binary Encoding Option        June 7, 2005
+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.
+   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
 
@@ -270,20 +276,20 @@ INTERNET-DRAFT      LDAP: The Binary Encoding Option        June 7, 2005
    requested encoding.
 
    Regardless of the encoding chosen, a particular attribute value is
-   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
 
+Legg                      Expires 30 July 2006                  [Page 5]
+
+INTERNET-DRAFT      LDAP: The Binary Encoding Option    January 30, 2006
 
 
-Legg                     Expires 7 December 2005                [Page 5]
-
-INTERNET-DRAFT      LDAP: The Binary Encoding Option        June 7, 2005
+   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
@@ -326,6 +332,14 @@ INTERNET-DRAFT      LDAP: The Binary Encoding Option        June 7, 2005
       Family of Options: NO
       Person & email address to contact for further information:
         Steven Legg <steven.legg@eb2bcom.com>
+
+
+
+Legg                      Expires 30 July 2006                  [Page 6]
+
+INTERNET-DRAFT      LDAP: The Binary Encoding Option    January 30, 2006
+
+
       Specification: RFC XXXX
       Author/Change Controller: IESG
       Comments: The existing registration for "binary"
@@ -333,21 +347,14 @@ INTERNET-DRAFT      LDAP: The Binary Encoding Option        June 7, 2005
 
 10.  References
 
-
-
-Legg                     Expires 7 December 2005                [Page 6]
-
-INTERNET-DRAFT      LDAP: The Binary Encoding Option        June 7, 2005
-
-
 10.1.  Normative References
 
-   [KEYWORD]  Bradner, S., "Key words for use in RFCs to Indicate
+   [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
-              Protcol (LDAP)", BCP 64, RFC 3383, September 2002.
+              Protocol (LDAP)", BCP 64, RFC 3383, September 2002.
 
    [ROADMAP]  Zeilenga, K., "Lightweight Directory Access Protocol
               (LDAP): Technical Specification Road Map",
@@ -360,17 +367,17 @@ INTERNET-DRAFT      LDAP: The Binary Encoding Option        June 7, 2005
 
    [PROT]     Sermersheim, J., "LDAP: The Protocol",
               draft-ietf-ldapbis-protocol-xx.txt, a work in progress,
-              February 2005.
+              October 2005.
 
-   [SYNTAX]   Legg, S. and K. Dally, "Lightweight Directory Access
-              Protocol (LDAP): Syntaxes and Matching Rules",
+   [SYNTAX]   Legg, S., "Lightweight Directory Access Protocol (LDAP):
+              Syntaxes and Matching Rules",
               draft-ietf-ldapbis-syntaxes-xx.txt, a work in progress,
-              February 2005.
+              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,
-              February 2005.
+              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:
@@ -381,27 +388,27 @@ INTERNET-DRAFT      LDAP: The Binary Encoding Option        June 7, 2005
 10.2.  Informative References
 
    [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.
 
-   [X.500]    ITU-T Recommendation X.500 (1993) | ISO/IEC 9594-1:1994,
 
+Legg                      Expires 30 July 2006                  [Page 7]
+
+INTERNET-DRAFT      LDAP: The Binary Encoding Option    January 30, 2006
 
 
-Legg                     Expires 7 December 2005                [Page 7]
-
-INTERNET-DRAFT      LDAP: The Binary Encoding Option        June 7, 2005
+              Access Protocol (v3)", RFC 2251, December 1997.
 
+   [RFC3377]  Hodges, J. and R. Morgan, "Lightweight Directory Access
+              Protocol (v3): Technical Specification", RFC 3377,
+              September 2002.
 
-              "Information Technology - Open Systems Interconnection -
-              The Directory: Overview of concepts, models and services".
+   [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
 
-   Steven Legg
+   Dr. Steven Legg
    eB2Bcom
    Suite 3, Woodhouse Corporate Centre
    935 Station Street
@@ -414,7 +421,7 @@ Author's Address
 
 Full Copyright Statement
 
-   Copyright (C) The Internet Society (2005).
+   Copyright (C) The Internet Society (2006).
 
    This document is subject to the rights, licenses and restrictions
    contained in BCP 78, and except as set forth therein, the authors
@@ -437,6 +444,14 @@ Intellectual Property
    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
@@ -444,14 +459,6 @@ Intellectual Property
    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
-
-
-
-Legg                     Expires 7 December 2005                [Page 8]
-
-INTERNET-DRAFT      LDAP: The Binary Encoding Option        June 7, 2005
-
-
    http://www.ietf.org/ipr.
 
    The IETF invites any interested party to bring to its attention any
@@ -496,12 +503,5 @@ INTERNET-DRAFT      LDAP: The Binary Encoding Option        June 7, 2005
 
 
 
-
-
-
-
-
-
-
-Legg                     Expires 7 December 2005                [Page 9]
+Legg                      Expires 30 July 2006                  [Page 9]
 
diff --git a/doc/drafts/draft-weltman-ldapv3-proxy-xx.txt b/doc/drafts/draft-weltman-ldapv3-proxy-xx.txt
deleted file mode 100644
index fe6b871f4f..0000000000
--- a/doc/drafts/draft-weltman-ldapv3-proxy-xx.txt
+++ /dev/null
@@ -1,295 +0,0 @@
-
-
-INTERNET-DRAFT                                               Rob Weltman 
-Intended Category: Standards Track                          Yahoo!, Inc. 
-                                                               June 2005 
-    
-                   LDAP Proxied Authorization Control 
-                   draft-weltman-ldapv3-proxy-13.txt 
- 
- 
-Status of this Memo 
- 
-   This document is an Internet-Draft and is in full conformance with 
-   all provisions of Section 10 of RFC2026. 
-    
-   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 
-    
-    
-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 as 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 as the 
-   current authorization identity associated with the connection. This 
-   document defines support for proxy authorization using the Control 
-   mechanism [RFC 2251]. 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 
-  
-Expires December 2005                                         [Page 1] 
-
-PROXIED AUTHORIZATION CONTROL                                June 2005 
- 
- 
-   authorization identity on a per operation basis, benefiting clients 
-   that need to efficiently perform operations 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]. 
-    
-    
-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 [RFC 2252] of a server's root DSE. 
-    
-    
-3. Proxy Authorization Control 
-    
-   A single Proxy Authorization Control may be included in any search, 
-   compare, modify, add, delete, modify DN or extended operation request 
-   message with the exception of any extension that causes a change in 
-   authentication, authorization, or data confidentiality [RFC 2829], 
-   such as Start TLS [LDAPTLS] as part of the controls field of the 
-   LDAPMessage, as defined in [RFC 2251]. 
-    
-   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 contain either an authzId 
-   [AUTH] representing the authorization identity for the request or 
-   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 TBD is returned. 
-   [Note to the IESG/IANA/RFC Editor: the value TBD is to be replaced 
-   with an IANA assigned LDAP Result Code (see RFC 3383 section 3.6] 
-    
-  
-Expires December 2005                                         [Page 2] 
-
-PROXIED AUTHORIZATION CONTROL                                June 2005 
- 
- 
-    
-4. Implementation Considerations 
-    
-   One possible interaction of proxy authorization and normal access 
-   control is illustrated here for the case of search requests. During 
-   evaluation of a search request, an entry which would have been 
-   returned for the search if submitted by the proxy authorization 
-   identity directly may not be returned if 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 which does imply such rights. This 
-   means that fewer results, or no results, may be returned compared to 
-   the case where 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 [RFC 2251] [AUTH] [LDAPTLS]. The control may 
-   be passed over a secure 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 which require 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 is to be registered as an LDAP Protocol 
-   Mechanism [RFC 3383]. 
-    
-   A result code for the case where the server does not execute a 
-   request using the proxy authorization identity is to be assigned by 
-   the IANA. 
-    
-    
-7. 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. 
-    
-  
-Expires December 2005                                         [Page 3] 
-
-PROXIED AUTHORIZATION CONTROL                                June 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. 
-    
-   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. 
-    
-    
-8. Normative References 
-    
-    
-   [KEYWORDS] Bradner, Scott, "Key Words for use in RFCs to Indicate 
-        Requirement Levels", draft-bradner-key-words-03.txt, January, 
-        1997. 
-    
-   [LDAPV3] Hodges, J. and R. Morgan, "Lightweight Directory Access 
-        Protocol (v3): Technical Specification", RFC 3377, September 
-        2002. 
-     
-   [SASL] J. Myers, "Simple Authentication and Security Layer (SASL)", 
-        RFC 2222, October 1997 
-    
-   [AUTH] M. Wahl, H. Alvestrand, J. Hodges, R. Morgan, "Authentication 
-        Methods for LDAP", RFC 2829, May 2000  
-    
-   [LDAPTLS] J. Hodges, R. Morgan, M. Wahl, "Lightweight Directory 
-        Access Protocol (v3): Extension for Transport Layer Security", 
-        RFC 2830, May 2000 
-    
-   [RFC 2251] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access 
-        Protocol (v3)", RFC 2251, December 1997. 
-    
-   [RFC 2252] M. Wahl, A. Coulbeck, T. Howes, S. Kille, "Lightweight 
-        Directory Access Protocol (v3): Attribute Syntax Definitions", 
-        RFC 2252, December 1997 
-  
-Expires December 2005                                         [Page 4] 
-
-PROXIED AUTHORIZATION CONTROL                                June 2005 
- 
- 
-    
-   [RFC 2829] M. Wahl, H. Alvestrand, J. Hodges, R. Morgan, 
-        "Authentication Methods for LDAP", RFC 2829, May 2000 
- 
-   [RFC 3383] K. Zeilenga, "Internet Assigned Numbers Authority (IANA) 
-        Considerations for the Lightweight Directory Access Protocol 
-        (LDAP)", RFC 3383, September 2002 
-    
-9. Author's Address 
-    
-   Rob Weltman 
-   Yahoo!, Inc 
-   701 First Avenue 
-   Sunnyvale, CA 94089 
-   USA 
-   +1 408 349-5504 
-   robw@worldspot.com 
-    
-    
-10. 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. 
-    
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-  
-Expires December 2005                                         [Page 5] 
-
\ No newline at end of file
diff --git a/doc/drafts/draft-zeilenga-ldap-grouping-xx.txt b/doc/drafts/draft-zeilenga-ldap-grouping-xx.txt
new file mode 100644
index 0000000000..76717f42c6
--- /dev/null
+++ b/doc/drafts/draft-zeilenga-ldap-grouping-xx.txt
@@ -0,0 +1,843 @@
+
+
+
+
+
+
+INTERNET-DRAFT                                         Kurt D. Zeilenga
+Intended Category: Standard Track                   OpenLDAP Foundation
+Expires in six months                                        3 May 2003
+
+
+
+                   LDAP: Grouping of Related Operations
+                  <draft-zeilenga-ldap-grouping-06.txt>
+
+
+Status of 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 a Standard Track document.
+  Distribution of this memo is unlimited.  Technical discussion of this
+  document will take place on the IETF LDAP Extension Working Group
+  mailing list <ldapext@ietf.org>.  Please send editorial comments
+  directly to the author <Kurt@OpenLDAP.org>.
+
+  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 2003, The Internet Society.  All Rights Reserved.
+
+  Please see the Copyright section near the end of this document for
+  more information.
+
+
+Abstract
+
+  This document provides a general mechanism for grouping related
+  Lightweight Directory Access Protocol (LDAP) operations.  Grouping of
+  operations can be used to support replication, proxies, and
+  transactions.
+
+
+
+
+Zeilenga                      LDAP Grouping                     [Page 1]
+
+INTERNET-DRAFT       draft-zeilenga-ldap-grouping-06          3 May 2003
+
+
+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].
+
+
+1. Introduction
+
+  This document provides a general mechanism for grouping related
+  Lightweight Directory Access Protocol (LDAP) [RFC3377] operations.
+  Grouping of operations can be used to support replication, proxies,
+  and high level operations such as transactions [TXNGRP].
+
+  This document describes a set of LDAP extended operations [RFC2251]
+  and other protocol and schema elements to support grouping of related
+  operations.  Uses of this grouping mechanism will be detailed in
+  separate documents.
+
+  A group of operations is defined as a set of operations within a
+  common session identified by a unique cookie.  All requests which are
+  initiated with the same cookie belong to the same grouping.  The
+  cookie is obtained using the create group operation and is normally
+  valid until the end group operation is completed.  A group can end
+  prematurely as described below.
+
+  Operations can be intermixed regardless of their grouping (or lack of
+  grouping).  Groups can be nested.
+
+  Each group is of a particular type specified when the group is
+  created.  This type defines the semantics of the group.
+
+
+2. Protocol Elements
+
+  This document describes three extended operations, two unsolicited
+  notification, and one control.  Extended operations and controls are
+  described by LDAP [RFC2251] and provide here for convenience:
+
+
+
+
+Zeilenga                      LDAP Grouping                     [Page 2]
+
+INTERNET-DRAFT       draft-zeilenga-ldap-grouping-06          3 May 2003
+
+
+    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
+    }
+
+    Control ::= SEQUENCE {
+      controlType    LDAPOID,
+      criticality    BOOLEAN DEFAULT FALSE,
+      controlValue   OCTET STRING OPTIONAL
+    }
+
+
+2.1 Common Protocol Elements
+
+    groupCookie ::= OCTET STRING
+
+  A groupCookie is an octet string used to uniquely identify a grouping
+  of related operations within the session.  A groupCookie is a
+  notational convenience.
+
+
+2.2 Create Grouping Operation
+
+  The Create Grouping extended operation is used to create or start a
+  grouping of related operations.  The operation consists of the
+  createGroupingRequest and the createGroupingResponse.  The object
+  identifier createGroupingOID identifies this operation and SHOULD be
+  listed as a value of supportedExtension in the root DSE of servers
+  which support this operation.
+
+    createGroupingOID ::= "IANA-ASSIGNED-OID.1"
+
+
+2.2.1 createGroupingRequest
+
+  The client initiates this operation by sending a
+  createGroupingRequest.  This request is an ExtendedRequest where the
+  requestName is the object identifier createGroupOID and requestValue
+  is BER-encoded createGroupingRequestValue:
+
+    createGroupingRequestValue ::= SEQUENCE {
+      createGroupType     [0] LDAPOID,
+
+
+
+Zeilenga                      LDAP Grouping                     [Page 3]
+
+INTERNET-DRAFT       draft-zeilenga-ldap-grouping-06          3 May 2003
+
+
+      createGroupValue    [1] OCTET STRING OPTIONAL
+    }
+
+  where createGroupType is an object identifier that describes the
+  specific type of grouping and createGroupValue contains a type
+  specific payload.
+
+
+2.2.2 createGroupingResponse
+
+  The createGroupingResponse is sent in response to a
+  createGroupingRequest.  This response is an ExtendedResponse where the
+  responseName MUST be the value of the requestName provided in the
+  request and the response is a BER-encoded createGroupingResponseValue:
+
+    createGroupingResponseValue ::= SEQUENCE {
+      createGroupCookie [0] groupCookie OPTIONAL,
+      createGroupValue  [1] OCTET STRING OPTIONAL
+    }
+
+  where createGroupCookie, if present, is a cookie uniquely identifying
+  the new grouping and createGroupValue is a type specific payload.  The
+  createGroupCookie only when the operation results in the creation of a
+  group.  Otherwise, it is absent.
+
+
+2.3 End Grouping Operation
+
+  The End Grouping extended operation is used to end or stop a grouping
+  of related operations.  The operation consists of the
+  endGroupingRequest and the endGroupingResponse.  The object identifier
+  endGroupingOID identifies this operation and SHOULD be listed as a
+  value of supportedExtension in the root DSE of servers which support
+  this operation.
+
+    endGroupingOID ::= "IANA-ASSIGNED-OID.2"
+
+
+2.3.1 endGroupingRequest
+
+  The client initiates this operation by sending an endGroupingRequest.
+  This request is an ExtendedRequest where the requestName is the object
+  identifier endGroupOID and requestValue is BER-encoded
+  endGroupingRequestValue:
+
+    endGroupingRequestValue ::= SEQUENCE {
+      endGroupCookie  [0] groupCookie,
+      endGroupValue   [1] OCTET STRING OPTIONAL
+
+
+
+Zeilenga                      LDAP Grouping                     [Page 4]
+
+INTERNET-DRAFT       draft-zeilenga-ldap-grouping-06          3 May 2003
+
+
+    }
+
+  where endGroupCookie is a cookie identifying the grouping and
+  endGroupValue contains a type specific payload.
+
+
+2.3.2 endGroupingResponse
+
+  The endGroupingResponse is sent in response to a endGroupingRequest.
+  This response is an ExtendedResponse where the responseName MUST be
+  the value of the requestName provided in request and the response is a
+  BER-encoded endGroupingResponseValue:
+
+    endGroupingResponseValue ::= SEQUENCE {
+      endGroupValue  [1] OCTET STRING OPTIONAL
+    }
+
+  where endGroupValue is a type specific payload.
+
+
+2.4 endGroupingNotice
+
+  The endGroupingNotice is an LDAP unsolicited notification.  The
+  notification may be sent to the client to end a grouping which the
+  server is unable or unwilling to continue to process.  The notice is
+  an extendedResponse where the responseName is the object identifier
+  endGroupingNoticeOID and the response is a BER-encoded
+  endGroupingNoticeValue:
+
+    endGroupingNoticeOID ::= "IANA-ASSIGNED-OID.3"
+
+    endGroupingNoticeValue ::= SEQUENCE {
+      endGroupingCookie [0] groupCookie,
+      endGroupValue     [1] OCTET STRING OPTIONAL
+    }
+
+  where endGroupingCookie is a cookie uniquely identifying the grouping
+  and endGroupValue contains a type specific payload.
+
+
+2.5 Action Grouping Operation
+
+  The Action Grouping extended operation is used to take an action
+  affecting a grouping of related operations.  The operation consists of
+  the actionGroupingRequest and the actionGroupingResponse.  The object
+  identifier actionGroupingOID identifies this operation and SHOULD be
+  listed as a value of supportedExtension in the root DSE of servers
+  which support this operation.
+
+
+
+Zeilenga                      LDAP Grouping                     [Page 5]
+
+INTERNET-DRAFT       draft-zeilenga-ldap-grouping-06          3 May 2003
+
+
+    actionGroupingOID ::= "IANA-ASSIGNED-OID.4"
+
+
+2.5.1 actionGroupingRequest
+
+  The client initiates this operation by sending an
+  actionGroupingRequest.  This request is an ExtendedRequest where the
+  requestName is the object identifier actionGroupOID and requestValue
+  is BER-encoded actionGroupingRequestValue:
+
+    actionGroupingRequestValue ::= SEQUENCE {
+      actionGroupCookie    [0] groupCookie,
+      actionGroupValue     [1] OCTET STRING OPTIONAL
+    }
+
+  where actionGroupCookie is a cookie identifying the grouping and
+  actionGroupValue contains a type specific payload.
+
+
+2.5.2 actionGroupingResponse
+
+  The actionGroupingResponse is sent in response to a
+  actionGroupingRequest.  This response is an ExtendedResponse where the
+  responseName MUST be the value of the requestName provided in request
+  and the response is a BER-encoded actionGroupingResponseValue:
+
+    actionGroupingResponseValue ::= SEQUENCE {
+      actionGroupValue  [1] OCTET STRING OPTIONAL
+    }
+
+  where actionGroupValue is a type specific payload.
+
+
+2.6 infoGroupingNotice
+
+  The infoGroupingNotice is an LDAP unsolicited notification.  The
+  notice may be sent to the client to provide additional grouping type
+  specific information.  The notice is an extendedResponse where the
+  responseName is the object identifier infoGroupingNoticeOID and the
+  response is a BER-encoded infoGroupingNoticeValue:
+
+    infoGroupingNoticeOID ::= "IANA-ASSIGNED-OID.5"
+
+    infoGroupingNoticeValue ::= SEQUENCE {
+      infoGroupingCookie [0] groupCookie,
+      infoGroupValue     [1] OCTET STRING OPTIONAL
+    }
+
+
+
+
+Zeilenga                      LDAP Grouping                     [Page 6]
+
+INTERNET-DRAFT       draft-zeilenga-ldap-grouping-06          3 May 2003
+
+
+  where infoGroupingCookie is a cookie uniquely identifying the grouping
+  and infoGroupValue contains a type specific payload.
+
+
+2.7 groupingControl
+
+  The groupingControl is used to identify requests and responses as
+  belonging to a grouping of operations.  The groupingControl is a
+  Control where the controlType is the object identifier
+  groupingControlOID, the criticality is TRUE, and the controlValue is a
+  BER-encoded groupingControlValue:
+
+    groupingControlOID ::= "IANA-ASSIGNED-OID.6"
+
+    groupingControlValue ::= SEQUENCE {
+      groupingCookie   [0] groupCookie,
+      groupValue       [1] OCTET STRING OPTIONAL
+    }
+
+  where groupingCookie is a cookie uniquely identifying the grouping and
+  groupingValue contains a type specific payload.
+
+  The value groupingControlOID SHOULD be listed as a value of
+  supportedControl in the root DSE by servers which support this
+  control.
+
+  The control SHALL NOT appear multiple times in the same LDAP PDU.  If
+  multiple occurrences of the control are detected, the PDU SHALL be
+  treated as a protocol error.
+
+
+3. Schema Elements
+
+  The document describes one attribute type.
+
+
+3.1. supportedGroupingTypes
+
+  Servers SHOULD publish grouping types they support listing group type
+  object identifiers as values of the supportedGroupingTypes attribute
+  type in the root DSE.  The supportedGroupingTypes attribute type is
+  defined as:
+
+    ( IANA-ASSIGNED-OID.7 NAME 'supportedGroupingTypes'
+      DESC 'supported types of groupings of operations'
+      EQUALITY objectIdentifierMatch
+      SYNTAX 1.3.6.1.4.1.1466.115.121.1.38      USAGE dSAOperation )
+
+
+
+
+Zeilenga                      LDAP Grouping                     [Page 7]
+
+INTERNET-DRAFT       draft-zeilenga-ldap-grouping-06          3 May 2003
+
+
+  The objectIdentifierMatch and OBJECT IDENTIFIER
+  (1.3.6.1.4.1.1466.115.121.1.38) are defined in [RFC2252].
+
+  Servers MUST be capable of recognizing this attribute type by the name
+  'supportedGroupingTypes'.  Servers MAY recognize the attribute type by
+  other names.
+
+
+4. Operational Semantics
+
+  This section details the common semantics of groups of related
+  operations.   Additional semantics may be associated with each
+  grouping type as described by other documents.
+
+
+4.1 Grouping Semantics
+
+  This subsection details semantics of the protocol elements introduced
+  in Section 2.
+
+
+4.1.1 Create Grouping
+
+  To group related operations, the client MUST request a groupCookie
+  from the server by sending a createGroupingRequest as described in
+  Section 2.2.1.  The client SHALL provide type specific payload in
+  createGroupValue if so required by the grouping type.
+
+  The server SHALL respond with a createGroupingResponse as described in
+  Section 2.2.2.  If the server is willing and able to create the
+  grouping as requested (and per type requirements), it SHALL respond
+  with success, provide a session-unique groupCookie and, if
+  appropriate, a type specific payload.  Otherwise the server SHALL
+  respond with a non-successful response containing no groupCookie, but
+  MAY, if appropriate, provide a type specific payload.
+
+
+4.1.2 End Grouping
+
+  When the client wishes to end the grouping, the client SHALL send a
+  endGroupingRequest as described in Section 2.3.1.  The client SHALL
+  provide the groupCookie of the grouping to end and MAY provided a type
+  specific payload.  If the grouping to end contains active nested
+  groupings, these are implicitly ended as well without notice.  The
+  server SHALL respond with an endGroupingResponse as described in
+  Section 2.3.2.
+
+
+
+
+
+Zeilenga                      LDAP Grouping                     [Page 8]
+
+INTERNET-DRAFT       draft-zeilenga-ldap-grouping-06          3 May 2003
+
+
+4.1.3 End Group Notice
+
+  The server MAY end a group without solicitation for any reason.  The
+  server SHALL notify the client of this action by sending a endGrouping
+  Notice, as described in Section 2.4.  The server SHALL provide the
+  groupCookie of the group it terminated and MAY provide a type specific
+  payload.  The notice SHALL have a non-success resultCode.
+
+  If the group contains nested groups, the nested groups are implicitly
+  ended as well without additional notice.
+
+
+4.1.4 Action Grouping
+
+  To perform an action within a group of related operations, the client
+  sends to the server actionGroupingRequest as described in Section
+  2.5.1.  The client SHALL provide the groupCookie of the group the
+  operation is requested upon and, if required by the grouping type, a
+  type specific payload.
+
+  The server SHALL respond with a actionGroupingResponse as described in
+  Section 2.5.2.  The server SHALL, if required by the grouping type,
+  provide type specific payload.
+
+
+4.1.5 Info Grouping Notice
+
+  As allowed by the grouping type, the server MAY provide to the client
+  a notice regarding the grouping of related operations in an
+  infoGroupingNotice as described in Section 2.6.   The server SHALL, if
+  required by the grouping type, provide type specific payload.
+
+
+4.2 Nested groupings
+
+  Groups of the same or different types MAY be nested.  A nested group
+  is instantiated by providing a groupingControl containing the parent
+  group's cookie with the createGroupingRequest.
+
+  Group type specifications MAY restrict the types of groupings which
+  may be nested.  Servers MAY also place additional restrictions upon
+  nesting.  Clients SHOULD NOT assume support for arbitrary nesting.
+
+
+4.3 Intermixing of unrelated operations
+
+  LDAP is designed to allow clients to perform unrelated tasks
+  concurrently.  In keeping with this design, operations which unrelated
+
+
+
+Zeilenga                      LDAP Grouping                     [Page 9]
+
+INTERNET-DRAFT       draft-zeilenga-ldap-grouping-06          3 May 2003
+
+
+  to the grouping are generally allowed be intermixed with grouped
+  operations.  (See Section 4.5 for specific exceptions to this general
+  rule.)  It is noted that undue restrictions often unrelated operation
+  cause unnecessary serialization of independent tasks, place
+  unnecessary burden upon implementors, and can limit extensibility.
+
+  Group type specifications SHOULD NOT disallow unrelated operations
+  from being intermixed with grouped operations.
+
+  Note: a grouping which disallows unrelated operatoins from being
+  intermixed with grouped operations can be viewed as providing
+  "framing" semantics.
+
+
+4.4 Grouped operations
+
+  Interrogation (compare, search) and update (add, delete, modify,
+  rename) MAY be grouped.  Certain extended operations MAY also be
+  grouped, but those which affect the session as a whole, such as Start
+  TLS, MUST NOT be grouped.
+
+  Requests and Responses associated with grouped operations contain a
+  groupingControl control as described in Section 2.7.
+
+  Group type specifications MAY restrict the kind and/or number of
+  operations which may be related.  Servers MAY place additional
+  restrictions upon groupings.  Clients SHOULD NOT assume support for
+  arbitrary grouping.
+
+
+4.5 Other Operations
+
+  Upon issuing any grouping operation, the semantics of following
+  operations listed is modified as described below.
+
+
+4.5.1 abandon
+
+  The abandon operation SHOULD NOT be used to cancel grouped operations.
+  The Cancel operation is to be used instead (as discussed in 4.5.3).
+
+
+4.5.2 bind
+
+  The client SHOULD end all outstanding groupings before issuing a bind
+  request.  The server SHALL, in addition to the behavior described in
+  [RFC2251] and [RFC2829], abandon all outstanding groups.  No
+  endGroupingNotice notification is sent upon such abandonment.
+
+
+
+Zeilenga                      LDAP Grouping                    [Page 10]
+
+INTERNET-DRAFT       draft-zeilenga-ldap-grouping-06          3 May 2003
+
+
+  A Bind operation cannot be related to other operations using this
+  grouping mechanism.  The bind messages SHOULD NOT contain
+  groupingControl controls and, if present, SHALL be treated as a a
+  protocol error.
+
+
+4.5.3 cancel
+
+  The cancel operation [CANCEL] MAY be used to cancel grouped operations
+  but SHOULD NOT contain a groupingControl control unless the group type
+  calls for a type specific payload to be provided.  The groupingCookie
+  in the provided groupingControl control MUST be the same associated
+  with the operation to be canceled, otherwise the cancel request SHALL
+  be treated as an error.
+
+
+4.5.4 Start TLS
+
+  The client SHOULD end all outstanding groupings before issuing a Start
+  TLS [RFC2930] request.  If there are any outstanding groupings, the
+  server MUST return operationsError in response to a StartTLS request.
+  Start TLS operation cannot be related to other operations using this
+  grouping mechanism and the Start TLS request and response PDUs SHALL
+  NOT contain a groupingControl control.
+
+
+4.5.5 unbind
+
+  The server SHALL, in addition to the behavior described in [RFC2251],
+  abandon all outstanding groups.  No endGroupingNotice is sent upon
+  such abandonment.  An unbind operation cannot be related to other
+  operations using this grouping mechanism.  The unbind request SHOULD
+  NOT contain a groupingControl control and, if present, SHALL be
+  ignored.
+
+
+5. Profiling Requirements
+
+  Documents detailing extensions using the grouping mechanism MUST
+  provide a profile of its use of the mechanism.
+
+  The profile SHALL specify the object identifier to be used to uniquely
+  identify each grouping type it defines.  Object identifiers used to
+  identity group types, like other protocol elements, SHALL be delegated
+  in accordance with BCP 64 [RFC3383] and registered as LDAP Protocol
+  Mechanisms [RFC3383] as detailed in Section 7.1 of this document.
+
+  The profile SHALL state which protocol elements of the mechanism it
+
+
+
+Zeilenga                      LDAP Grouping                    [Page 11]
+
+INTERNET-DRAFT       draft-zeilenga-ldap-grouping-06          3 May 2003
+
+
+  uses.
+
+  Each of the grouping protocol elements defined in this document allow
+  transfer of type specific payloads.  For each protocol element used,
+  the profile SHALL state whether the element is to carry a type
+  specific payload or not and SHALL fully describe the syntax and
+  semantics associated with each type specific payload.
+
+  The profile MAY define grouping type specific semantics which place
+  further restrictions upon the grouping related operations.
+
+
+6. Security Considerations
+
+  This mechanism can be used to support complex groupings of related
+  operations.  With such complexity comes inherit risk.  Specifications
+  of uses of this mechanism should take special care to address security
+  issues.  In particular, denial of service and authentication,
+  authorization, and access-control issues should be addressed in
+  documents detailing uses of this grouping mechanism.
+
+
+7. IANA Considerations
+
+7.1. Future Registration of Grouping Types
+
+  Future specifications which detail LDAP grouping types are to register
+  each grouping type as a LDAP Protocol Mechanism per guidance given in
+  BCP 64 [RFC3383].  A usage of "Grouping Type" in a Protocol Mechanism
+  registration template indicates that the value to be registered is
+  associated with an LDAP Grouping Type.
+
+
+7.2. Object Identifier Registration
+
+  It is requested that IANA register upon Standards Action an LDAP
+  Object Identifier to identify 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:
+          Kurt Zeilenga <kurt@OpenLDAP.org>
+      Specification: RFCXXXX
+      Author/Change Controller: IESG
+      Comments:
+          Identifies elements of the LDAP Grouping Operation
+
+
+
+
+Zeilenga                      LDAP Grouping                    [Page 12]
+
+INTERNET-DRAFT       draft-zeilenga-ldap-grouping-06          3 May 2003
+
+
+7.3.  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 Mechansism Registration
+      Object Identifier: IANA-ASSIGNED-OID
+      Description: See comments
+      Person & email address to contact for further information:
+          Kurt Zeilenga <kurt@openldap.org>
+      Usage: Extended Operation
+      Specification: RFCXXXX
+      Author/Change Controller: IESG
+      Comments: none
+
+        Object Identifier   Type Description
+        ------------------- ---- -------------------------
+        IANA-ASSIGNED-OID.1 E    Create Grouping Operation
+        IANA-ASSIGNED-OID.2 E    End Grouping Operation
+        IANA-ASSIGNED-OID.4 E    Action Grouping Operation
+
+      in 2
+
+
+7.4. supportedGroupingTypes Registration
+
+      It is requested that IANA register upon Standards Action the LDAP
+      'supportedGroupingTypes' descriptor.  The following registration
+      template is suggested:
+
+      Subject: Request for LDAP Descriptor Registration
+      Descriptor (short name): supportedGroupingTypes
+      Object Identifier: IANA-ASSIGNED-OID.7
+      Person & email address to contact for further information:
+          Kurt Zeilenga <kurt@OpenLDAP.org>
+      Usage: Attribute Type
+      Specification: RFCXXXX
+      Author/Change Controller: IESG
+
+
+8. Acknowledgments
+
+  The author gratefully acknowledges the contributions of the IETF
+  LDAPext and LDUP working groups.  In particular, Roger Harrison
+  provided many useful suggestions.  Also, the author notes that this
+  document builds upon the early works "Extended Operations for Framing
+  LDAP Operations" by Ellen Stokes, Roger Harrison, and Gordon Good and
+
+
+
+Zeilenga                      LDAP Grouping                    [Page 13]
+
+INTERNET-DRAFT       draft-zeilenga-ldap-grouping-06          3 May 2003
+
+
+  "Profile for Framing LDAPv3 Operations" by Roger Harrison.
+
+
+9. Author's Address
+
+  Kurt D. Zeilenga
+  OpenLDAP Foundation
+  <Kurt@OpenLDAP.org>
+
+
+10. References
+
+10.1 Normative References
+
+  [RFC2119]  S. Bradner, "Key Words for use in RFCs to Indicate
+             Requirement Levels", BCP 14 (also RFC 2119), March 1997.
+
+  [RFC2251]  M. Wahl, S. Kille, T. Howes, "Lightweight Directory Access
+             Protocol (v3)", RFC 2251, December 1997.
+
+  [RFC2252]  M. Wahl, A. Coulbeck, T. Howes, S. Kille, "Lightweight
+             Directory Access Protocol (v3):  Attribute Syntax
+             Definitions", RFC 2252, December 1997.
+
+  [RFC2829]  M. Wahl, H. Alvestrand, J. Hodges, R. Morgan,
+             "Authentication Methods for LDAP", RFC 2829, May 2000.
+
+  [RFC2830]  J. Hodges, R. Morgan, M. Wahl, "Lightweight Directory
+             Access Protocol (v3): Extension for Transport Layer
+             Security", RFC 2830, May 2000.
+
+  [RFC3377]  J. Hodges, R. Morgan, "Lightweight Directory Access
+             Protocol (v3): Technical Specification", RFC 3377,
+             September 2002.
+
+  [RFC3383]  K. Zeilenga, "IANA Considerations for LDAP", BCP 64 (also
+             RFC 3383), September 2002.
+
+  [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.
+
+
+10.2. Informative References
+
+  [TXNGRP]   K. Zeilenga, "LDAP Transactions" (a work in progress),
+
+
+
+Zeilenga                      LDAP Grouping                    [Page 14]
+
+INTERNET-DRAFT       draft-zeilenga-ldap-grouping-06          3 May 2003
+
+
+             draft-zeilenga-ldap-txn-xx.txt.
+
+
+Copyright 2003, The Internet Society.  All Rights Reserved.
+
+  This document and translations of it may be copied and furnished to
+  others, and derivative works that comment on or otherwise explain it
+  or assist in its implementation may be prepared, copied, published and
+  distributed, in whole or in part, without restriction of any kind,
+  provided that the above copyright notice and this paragraph are
+  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 AUTHORS, THE INTERNET SOCIETY, AND THE INTERNET
+  ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
+  INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+  INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+  WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga                      LDAP Grouping                    [Page 15]
+
diff --git a/doc/drafts/draft-zeilenga-ldap-txn-xx.txt b/doc/drafts/draft-zeilenga-ldap-txn-xx.txt
new file mode 100644
index 0000000000..a9683c5d29
--- /dev/null
+++ b/doc/drafts/draft-zeilenga-ldap-txn-xx.txt
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+INTERNET-DRAFT                                         Kurt D. Zeilenga
+Intended Category: Experimental                     OpenLDAP Foundation
+Expires in six months                                        3 May 2003
+
+
+                            LDAP Transactions
+                     <draft-zeilenga-ldap-txn-06.txt>
+
+
+Status of 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 Experimental document.
+  Distribution of this memo is unlimited.  Technical discussion of this
+  document will take place on the IETF LDAP Extension Working Group
+  mailing list <ldapext@ietf.org>.  Please send editorial comments
+  directly to the author <Kurt@OpenLDAP.org>.
+
+  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 2003, The Internet Society.  All Rights Reserved.
+
+  Please see the Copyright section near the end of this document for
+  more information.
+
+
+Abstract
+
+  Lightweight Directory Access Protocol (LDAP) update operations acting
+  upon entries have atomic, consistency, isolation, durability (ACID)
+  properties.  However, it is often desirable to update two or more
+  entries as one unit of interaction, a transaction.  Transactions are
+  necessary to support a number of applications including resource
+  provisioning and information replication.  This document defines an
+
+
+
+Zeilenga                    LDAP Transactions                   [Page 1]
+
+INTERNET-DRAFT         draft-zeilenga-ldap-txn-06             3 May 2003
+
+
+  LDAP extension to support transactions.
+
+
+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].  The term
+  "BER-encoded" means the element is to be encoded using the Basic
+  Encoding Rules [X.690] under the restrictions detailed in Section 5.1
+  of [RFC2251].
+
+
+1. Overview
+
+  This document extends the Lightweight Directory Access Protocol (LDAP)
+  [RFC3377] to allow clients to group a number of related update
+  operations [RFC2251] 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 uses the grouping mechanism provided by [GROUP] to
+  relate operations of the transaction.  The createGrouping operation is
+  used to obtain a group cookie which is used to identify operations
+  which are apart of the transaction.  The group cookie can be viewed as
+  a transaction identifier.  The endGrouping operation is used to settle
+  (commit or abort) the transaction.
+
+
+2. Specification of a Transaction
+
+  Servers implementing this specification SHOULD publish the
+  transactionGroupingType as a value of the 'supportedGroupingTypes'
+  attribute contained within the Root DSE.
+
+      transactionGroupingType ::= IANA-ASSIGNED-OID
+
+  A client wishing to preform a transaction issues a
+  createGroupingRequest with a createGroupType of
+  transactionGroupingType and no createGroupValue.  A server which is
+  willing and able to support transactions returns a
+  createGroupingResponse with a success result code, a
+  createGroupCookie, and no createGroupValue.  Otherwise the server
+  returns a non-success result code, no createGroupCookie, and no
+  createGroupValue.
+
+
+
+Zeilenga                    LDAP Transactions                   [Page 2]
+
+INTERNET-DRAFT         draft-zeilenga-ldap-txn-06             3 May 2003
+
+
+  The client then issues may issue one or more update (add, delete,
+  modify, rename) requests, each with a GroupingControl indicating they
+  are to processed as part of the transaction grouping.  If the server
+  is willing and able to attempt to process operation as part of the
+  transaction, the server returns success.  As further processing of the
+  operation is be deferred until settlement, the operation is considered
+  still outstanding and its messageID cannot to be reused until after
+  settlement.  If the server is unwilling or unable to attempt to
+  process the operation as part of the transaction, the server returns a
+  non-successful result code.
+
+  If the server becomes unwilling or unable to continue the
+  specification of a transaction, the server return the canceled
+  resultCode for each deferred operation and then issue a endGroupNotice
+  with a non-success resultCode.  Any future use of cookie by the client
+  will result in a response containing a non-success result code.  Upon
+  receipt of a endGroupingNotice, the client is to discontinue all use
+  of the grouping cookie as the transaction is null and void.
+
+  A client requests settling of transaction by issuing an
+  endGroupingRequest where the groupingCookie is the group cookie
+  identify the transaction.  The absence of any endGroupingValue
+  indicates a commit request.  The presence of an empty endGroupValue
+  indicates an abort request.  The endGroupValue MUST be empty if
+  provided.
+
+  If the commit response indicates failure, the server may return an
+  endGroupingValue with the endGroupingResponse.  If so, it contains the
+  BER-encoding of a MessageID [RFC2251] of the update operation
+  associated with the failure.
+
+
+3. Settling of the Transaction
+
+  Upon receipt of a request to abort the transaction, the server is to
+  abort the transaction and then return an endGroupingResponse
+  indicating success.
+
+  Upon receipt of a request to commit the transaction, the server
+  processes the group of update operations as one atomic, isolated
+  action with each update request being processed in turn.  Either all
+  of the requested updates SHALL be successfully applied or none of the
+  requested SHALL be applied.  If all are applied, the server returns an
+  endGroupingResponse indicating success.  Otherwise, the server returns
+  an endGroupingResponse indicating the nature of the failure.  If the
+  failure is associated with a particular update operation, the message
+  ID is returned an attached endGroupingValue.  If the failure was not
+  associated with any particular update operation, no endGroupingValue
+
+
+
+Zeilenga                    LDAP Transactions                   [Page 3]
+
+INTERNET-DRAFT         draft-zeilenga-ldap-txn-06             3 May 2003
+
+
+  is to be provided.
+
+  There is no requirement that a server serialize transactions.  That
+  is, a server MAY process multiple transactions 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 disallow servers from chaining operations which
+  are part of a transaction.  However, if a server does allow such
+  chaining, it MUST ensure that transaction semantics detailed above 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-slave
+  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
+  assume tight data consistency nor fast data convergence at slave
+  servers unless they have prior knowledge that such is provided.
+  Though this mechanism could be used to support replication, such use
+  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 and related grouping operations may be the
+  target of denial of service attacks.  Implementors should provide
+  safeguards to ensure these mechanisms are not abused.
+
+
+6. IANA Considerations
+
+  In accordance with [RFC3383], it is requested that Internet Assigned
+  Numbers Authority (IANA) make the following assignments.
+
+
+
+
+Zeilenga                    LDAP Transactions                   [Page 4]
+
+INTERNET-DRAFT         draft-zeilenga-ldap-txn-06             3 May 2003
+
+
+6.1.  Object Identifier
+
+  An LDAP Object Identifier to identify the grouping type defined in
+  this document is requested.
+
+  The following registration template is suggested:
+
+      Subject: Request for LDAP Object Identifier Registration
+      Person & email address to contact for further information:
+          Kurt Zeilenga <kurt@OpenLDAP.org>
+      Specification: RFCXXXX
+      Author/Change Controller: IESG
+      Comments:
+          Identifies the LDAP Transactions Grouping Type
+
+
+6.2.  LDAP Protocol Mechanism
+
+  Registration of the protocol mechanisms defined in this document is
+  requested.
+
+  Subject: Request for LDAP Protocol Mechansism Registration
+
+  Object Identifier: IANA-ASSIGNED-OID
+  Description: LDAP Transaction Grouping Type
+  Person & email address to contact for further information:
+       Kurt Zeilenga <kurt@openldap.org>
+  Usage: Grouping
+  Specification: RFCxxxx
+  Author/Change Controller: IESG
+  Comments: none
+
+
+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
+      <Kurt@OpenLDAP.org>
+
+
+9. Normative References
+
+
+
+
+Zeilenga                    LDAP Transactions                   [Page 5]
+
+INTERNET-DRAFT         draft-zeilenga-ldap-txn-06             3 May 2003
+
+
+  [RFC2119] S. Bradner, "Key Words for use in RFCs to Indicate
+            Requirement Levels", BCP 14 (also RFC 2119), March 1997.
+
+  [RFC2251] M. Wahl, S. Kille, T. Howes, "Lightweight Directory Access
+            Protocol (v3)", RFC 2251, December 1997.
+
+  [RFC3377] J. Hodges, R. Morgan, "Lightweight Directory Access
+            Protocol (v3): Technical Specification", RFC 3377, September 2002.
+
+  [GROUP]   K. Zeilenga, "LDAP: Grouping of Related Operations",
+            draft-zeilenga-ldap-grouping-xx.txt, a work in progress.
+
+  [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.
+
+
+10. Informative References
+
+  [ACID]    Section 4 of ISO/IEC 10026-1:1992.
+
+  [RFC3383] K. Zeilenga, "IANA Considerations for LDAP", BCP 64 (also
+            RFC 3383), September 2002.
+
+  [X.500]   ITU-T, "The Directory: Overview of Concepts, Models, and
+            Services", X.500, 1993.
+
+  [X.501]   ITU-T, "The Directory: Models", X.501, 1993.
+
+
+Copyright 2003, The Internet Society.  All Rights Reserved.
+
+  This document and translations of it may be copied and furnished
+  to others, and derivative works that comment on or otherwise explain
+  it or assist in its implementation may be prepared, copied, published
+  and distributed, in whole or in part, without restriction of any
+  kind, provided that the above copyright notice and this paragraph
+  are 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
+
+
+
+Zeilenga                    LDAP Transactions                   [Page 6]
+
+INTERNET-DRAFT         draft-zeilenga-ldap-txn-06             3 May 2003
+
+
+  be revoked by the Internet Society or its successors or assigns.
+
+  This document and the information contained herein is provided on
+  an "AS IS" basis and THE AUTHORS, THE INTERNET SOCIETY, AND THE
+  INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS
+  OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE
+  OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+  WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga                    LDAP Transactions                   [Page 7]
+
diff --git a/doc/rfc/INDEX b/doc/rfc/INDEX
index 8aeaf5248f..4929ee1903 100644
--- a/doc/rfc/INDEX
+++ b/doc/rfc/INDEX
@@ -49,6 +49,8 @@ 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)
 
 Legend:
 STD	Standard
diff --git a/doc/rfc/rfc4370.txt b/doc/rfc/rfc4370.txt
new file mode 100644
index 0000000000..8a8aa14f53
--- /dev/null
+++ b/doc/rfc/rfc4370.txt
@@ -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@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@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Weltman                     Standards Track                     [Page 5]
+
diff --git a/doc/rfc/rfc4373.txt b/doc/rfc/rfc4373.txt
new file mode 100644
index 0000000000..48d656e9d7
--- /dev/null
+++ b/doc/rfc/rfc4373.txt
@@ -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@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@novell.com
+
+
+   Jim Sermersheim
+   Novell, Inc.
+   1800 S. Novell Place
+   Provo, UT 84606
+
+   Phone: +1 801 861 3088
+   EMail: jimse@novell.com
+
+
+   Yulin Dong
+
+   EMail: yulindong@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@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Harrison, et al.             Informational                     [Page 16]
+
-- 
2.39.5