r17189: Add the new LDAP rfc series

(This used to be commit d3f8b813b33d1338e62f099017a1d4a32745e7a2)

24 files changed, 27176 insertions, 0 deletions

diff --git a/source4/ldap_server/devdocs/rfc4510.txt b/source4/ldap_server/devdocs/rfc4510.txt
new file mode 100644
index 0000000000..8ba41d1d93
--- /dev/null
+++ b/source4/ldap_server/devdocs/rfc4510.txt
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+Network Working Group                                   K. Zeilenga, Ed.
+Request for Comments: 4510                           OpenLDAP Foundation
+Obsoletes: 2251, 2252, 2253, 2254, 2255,                       June 2006
+           2256, 2829, 2830, 3377, 3771
+Category: Standards Track
+
+
+             Lightweight Directory Access Protocol (LDAP):
+                    Technical Specification Road Map
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   The Lightweight Directory Access Protocol (LDAP) is an Internet
+   protocol for accessing distributed directory services that act in
+   accordance with X.500 data and service models.  This document
+   provides a road map of the LDAP Technical Specification.
+
+1.  The LDAP Technical Specification
+
+   The technical specification detailing version 3 of the Lightweight
+   Directory Access Protocol (LDAP), an Internet Protocol, consists of
+   this document and the following documents:
+
+      LDAP: The Protocol [RFC4511]
+      LDAP: Directory Information Models [RFC4512]
+      LDAP: Authentication Methods and Security Mechanisms [RFC4513]
+      LDAP: String Representation of Distinguished Names [RFC4514]
+      LDAP: String Representation of Search Filters [RFC4515]
+      LDAP: Uniform Resource Locator [RFC4516]
+      LDAP: Syntaxes and Matching Rules [RFC4517]
+      LDAP: Internationalized String Preparation [RFC4518]
+      LDAP: Schema for User Applications [RFC4519]
+
+
+
+
+
+
+
+Zeilenga                    Standards Track                     [Page 1]
+
+RFC 4510                   LDAP: TS Road Map                   June 2006
+
+
+   The terms "LDAP" and "LDAPv3" are commonly used to refer informally
+   to the protocol specified by this technical specification.  The LDAP
+   suite, as defined here, should be formally identified in other
+   documents by a normative reference to this document.
+
+   LDAP is an extensible protocol.  Extensions to LDAP may be specified
+   in other documents.  Nomenclature denoting such combinations of
+   LDAP-plus-extensions is not defined by this document but may be
+   defined in some future document(s).  Extensions are expected to be
+   truly optional.  Considerations for the LDAP extensions described in
+   BCP 118, RFC 4521 [RFC4521] fully apply to this revision of the LDAP
+   Technical Specification.
+
+   IANA (Internet Assigned Numbers Authority) considerations for LDAP
+   described in BCP 64, RFC 4520 [RFC4520] apply fully to this revision
+   of the LDAP technical specification.
+
+1.1.  Conventions
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in BCP 14 [RFC2119].
+
+2.  Relationship to X.500
+
+   This technical specification defines LDAP in terms of [X.500] as an
+   X.500 access mechanism.  An LDAP server MUST act in accordance with
+   the X.500 (1993) series of International Telecommunication Union -
+   Telecommunication Standardization (ITU-T) Recommendations when
+   providing the service.  However, it is not required that an LDAP
+   server make use of any X.500 protocols in providing this service.
+   For example, LDAP can be mapped onto any other directory system so
+   long as the X.500 data and service models [X.501][X.511], as used in
+   LDAP, are not violated in the LDAP interface.
+
+   This technical specification explicitly incorporates portions of
+   X.500(93).  Later revisions of X.500 do not automatically apply to
+   this technical specification.
+
+3.  Relationship to Obsolete Specifications
+
+   This technical specification, as defined in Section 1, obsoletes
+   entirely the previously defined LDAP technical specification defined
+   in RFC 3377 (and consisting of RFCs 2251-2256, 2829, 2830, 3771, and
+   3377 itself).  The technical specification was significantly
+   reorganized.
+
+
+
+
+
+Zeilenga                    Standards Track                     [Page 2]
+
+RFC 4510                   LDAP: TS Road Map                   June 2006
+
+
+   This document replaces RFC 3377 as well as Section 3.3 of RFC 2251.
+   [RFC4512] replaces portions of RFC 2251, RFC 2252, and RFC 2256.
+   [RFC4511] replaces the majority RFC 2251, portions of RFC 2252, and
+   all of RFC 3771.  [RFC4513] replaces RFC 2829, RFC 2830, and portions
+   of RFC 2251.  [RFC4517] replaces the majority of RFC 2252 and
+   portions of RFC 2256.  [RFC4519] replaces the majority of RFC 2256.
+   [RFC4514] replaces RFC 2253.  [RFC4515] replaces RFC 2254.  [RFC4516]
+   replaces RFC 2255.
+
+   [RFC4518] is new to this revision of the LDAP technical
+   specification.
+
+   Each document of this specification contains appendices summarizing
+   changes to all sections of the specifications they replace.  Appendix
+   A.1 of this document details changes made to RFC 3377.  Appendix A.2
+   of this document details changes made to Section 3.3 of RFC 2251.
+
+   Additionally, portions of this technical specification update and/or
+   replace a number of other documents not listed above.  These
+   relationships are discussed in the documents detailing these portions
+   of this technical specification.
+
+4.  Security Considerations
+
+   LDAP security considerations are discussed in each document
+   comprising the technical specification.
+
+5.  Acknowledgements
+
+   This document is based largely on RFC 3377 by J. Hodges and R.
+   Morgan, a product of the LDAPBIS and LDAPEXT Working Groups.  The
+   document also borrows from RFC 2251 by M. Wahl, T. Howes, and S.
+   Kille, a product of the ASID Working Group.
+
+   This document is a product of the IETF LDAPBIS Working Group.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga                    Standards Track                     [Page 3]
+
+RFC 4510                   LDAP: TS Road Map                   June 2006
+
+
+6.  Normative References
+
+   [RFC2119]     Bradner, S., "Key words for use in RFCs to Indicate
+                 Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC4511]     Sermersheim, J., Ed., "Lightweight Directory Access
+                 Protocol (LDAP): The Protocol", RFC 4511, June 2006.
+
+   [RFC4512]     Zeilenga, K., "Lightweight Directory Access Protocol
+                 (LDAP): Directory Information Models", RFC 4512, June
+                 2006.
+
+   [RFC4513]     Harrison, R., Ed., "Lightweight Directory Access
+                 Protocol (LDAP): Authentication Methods and Security
+                 Mechanisms", RFC 4513, June 2006.
+
+   [RFC4514]     Zeilenga, K., Ed., "Lightweight Directory Access
+                 Protocol (LDAP): String Representation of Distinguished
+                 Names", RFC 4514, June 2006.
+
+   [RFC4515]     Smith, M., Ed. and T. Howes, "Lightweight Directory
+                 Access Protocol (LDAP): String Representation of Search
+                 Filters", RFC 4515, June 2006.
+
+   [RFC4516]     Smith, M., Ed. and T. Howes, "Lightweight Directory
+                 Access Protocol (LDAP): Uniform Resource Locator", RFC
+                 4516, June 2006.
+
+   [RFC4517]     Legg, S., Ed., "Lightweight Directory Access Protocol
+                 (LDAP): Syntaxes and Matching Rules", RFC 4517, June
+                 2006.
+
+   [RFC4518]     Zeilenga, K., "Lightweight Directory Access Protocol
+                 (LDAP): Internationalized String Preparation", RFC
+                 4518, June 2006.
+
+   [RFC4519]     Sciberras, A., Ed., "Lightweight Directory Access
+                 Protocol (LDAP): Schema for User Applications", RFC
+                 4519, June 2006.
+
+   [RFC4520]     Zeilenga, K., "Internet Assigned Numbers Authority
+                 (IANA) Considerations for the Lightweight Directory
+                 Access Protocol (LDAP)", BCP 64, RFC 4520, June 2006.
+
+   [RFC4521]     Zeilenga, K., "Considerations for LDAP Extensions", BCP
+                 118, RFC 4521, June 2006.
+
+
+
+
+
+Zeilenga                    Standards Track                     [Page 4]
+
+RFC 4510                   LDAP: TS Road Map                   June 2006
+
+
+   [X.500]       International Telecommunication Union -
+                 Telecommunication Standardization Sector, "The
+                 Directory -- Overview of concepts, models and
+                 services", X.500(1993) (also ISO/IEC 9594-1:1994).
+
+   [X.501]       International Telecommunication Union -
+                 Telecommunication Standardization Sector, "The
+                 Directory -- Models", X.501(1993) (also ISO/IEC 9594-
+                 2:1994).
+
+   [X.511]       International Telecommunication Union -
+                 Telecommunication Standardization Sector, "The
+                 Directory: Abstract Service Definition", X.511(1993)
+                 (also ISO/IEC 9594-3:1993).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga                    Standards Track                     [Page 5]
+
+RFC 4510                   LDAP: TS Road Map                   June 2006
+
+
+Appendix A.  Changes to Previous Documents
+
+   This appendix outlines changes this document makes relative to the
+   documents it replaces (in whole or in part).
+
+A.1. Changes to RFC 3377
+
+   This document is nearly a complete rewrite of RFC 3377 as much of the
+   material of RFC 3377 is no longer applicable.  The changes include
+   redefining the terms "LDAP" and "LDAPv3" to refer to this revision of
+   the technical specification.
+
+A.2. Changes to Section 3.3 of RFC 2251
+
+   The section was modified slightly (the word "document" was replaced
+   with "technical specification") to clarify that it applies to the
+   entire LDAP technical specification.
+
+Author's Address
+
+   Kurt D. Zeilenga
+   OpenLDAP Foundation
+
+   EMail: Kurt@OpenLDAP.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga                    Standards Track                     [Page 6]
+
+RFC 4510                   LDAP: TS Road Map                   June 2006
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2006).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Zeilenga                    Standards Track                     [Page 7]
+
diff --git a/source4/ldap_server/devdocs/rfc4511.txt b/source4/ldap_server/devdocs/rfc4511.txt
new file mode 100644
index 0000000000..8041f30544
--- /dev/null
+++ b/source4/ldap_server/devdocs/rfc4511.txt
@@ -0,0 +1,3811 @@
+
+
+
+
+
+
+Network Working Group                                J. Sermersheim, Ed.
+Request for Comments: 4511                                  Novell, Inc.
+Obsoletes: 2251, 2830, 3771                                    June 2006
+Category: Standards Track
+
+
+      Lightweight Directory Access Protocol (LDAP): The Protocol
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   This document describes the protocol elements, along with their
+   semantics and encodings, of the Lightweight Directory Access Protocol
+   (LDAP).  LDAP provides access to distributed directory services that
+   act in accordance with X.500 data and service models.  These protocol
+   elements are based on those described in the X.500 Directory Access
+   Protocol (DAP).
+
+Table of Contents
+
+   1. Introduction ....................................................3
+      1.1. Relationship to Other LDAP Specifications ..................3
+   2. Conventions .....................................................3
+   3. Protocol Model ..................................................4
+      3.1. Operation and LDAP Message Layer Relationship ..............5
+   4. Elements of Protocol ............................................5
+      4.1. Common Elements ............................................5
+           4.1.1. Message Envelope ....................................6
+           4.1.2. String Types ........................................7
+           4.1.3. Distinguished Name and Relative Distinguished Name ..8
+           4.1.4. Attribute Descriptions ..............................8
+           4.1.5. Attribute Value .....................................8
+           4.1.6. Attribute Value Assertion ...........................9
+           4.1.7. Attribute and PartialAttribute ......................9
+           4.1.8. Matching Rule Identifier ...........................10
+           4.1.9. Result Message .....................................10
+           4.1.10. Referral ..........................................12
+
+
+
+Sermersheim                 Standards Track                     [Page 1]
+
+RFC 4511                         LDAPv3                        June 2006
+
+
+           4.1.11. Controls ..........................................14
+      4.2. Bind Operation ............................................16
+           4.2.1. Processing of the Bind Request .....................17
+           4.2.2. Bind Response ......................................18
+      4.3. Unbind Operation ..........................................18
+      4.4. Unsolicited Notification ..................................19
+           4.4.1. Notice of Disconnection ............................19
+      4.5. Search Operation ..........................................20
+           4.5.1. Search Request .....................................20
+           4.5.2. Search Result ......................................27
+           4.5.3. Continuation References in the Search Result .......28
+      4.6. Modify Operation ..........................................31
+      4.7. Add Operation .............................................33
+      4.8. Delete Operation ..........................................34
+      4.9. Modify DN Operation .......................................34
+      4.10. Compare Operation ........................................36
+      4.11. Abandon Operation ........................................36
+      4.12. Extended Operation .......................................37
+      4.13. IntermediateResponse Message .............................39
+           4.13.1. Usage with LDAP ExtendedRequest and
+                   ExtendedResponse ..................................40
+           4.13.2. Usage with LDAP Request Controls ..................40
+      4.14. StartTLS Operation .......................................40
+           4.14.1. StartTLS Request ..................................40
+           4.14.2. StartTLS Response .................................41
+           4.14.3. Removal of the TLS Layer ..........................41
+   5. Protocol Encoding, Connection, and Transfer ....................42
+      5.1. Protocol Encoding .........................................42
+      5.2. Transmission Control Protocol (TCP) .......................43
+      5.3. Termination of the LDAP session ...........................43
+   6. Security Considerations ........................................43
+   7. Acknowledgements ...............................................45
+   8. Normative References ...........................................46
+   9. Informative References .........................................48
+   10. IANA Considerations ...........................................48
+   Appendix A. LDAP Result Codes .....................................49
+      A.1. Non-Error Result Codes ....................................49
+      A.2. Result Codes ..............................................49
+   Appendix B. Complete ASN.1 Definition .............................54
+   Appendix C. Changes ...............................................60
+      C.1. Changes Made to RFC 2251 ..................................60
+      C.2. Changes Made to RFC 2830 ..................................66
+      C.3. Changes Made to RFC 3771 ..................................66
+
+
+
+
+
+
+
+
+Sermersheim                 Standards Track                     [Page 2]
+
+RFC 4511                         LDAPv3                        June 2006
+
+
+1.  Introduction
+
+   The Directory is "a collection of open systems cooperating to provide
+   directory services" [X.500].  A directory user, which may be a human
+   or other entity, accesses the Directory through a client (or
+   Directory User Agent (DUA)).  The client, on behalf of the directory
+   user, interacts with one or more servers (or Directory System Agents
+   (DSA)).  Clients interact with servers using a directory access
+   protocol.
+
+   This document details the protocol elements of the Lightweight
+   Directory Access Protocol (LDAP), along with their semantics.
+   Following the description of protocol elements, it describes the way
+   in which the protocol elements are encoded and transferred.
+
+1.1.  Relationship to Other LDAP Specifications
+
+   This document is an integral part of the LDAP Technical Specification
+   [RFC4510], which obsoletes the previously defined LDAP technical
+   specification, RFC 3377, in its entirety.
+
+   This document, together with [RFC4510], [RFC4513], and [RFC4512],
+   obsoletes RFC 2251 in its entirety.  Section 3.3 is obsoleted by
+   [RFC4510].  Sections 4.2.1 (portions) and 4.2.2 are obsoleted by
+   [RFC4513].  Sections 3.2, 3.4, 4.1.3 (last paragraph), 4.1.4, 4.1.5,
+   4.1.5.1, 4.1.9 (last paragraph), 5.1, 6.1, and 6.2 (last paragraph)
+   are obsoleted by [RFC4512].  The remainder of RFC 2251 is obsoleted
+   by this document.  Appendix C.1 summarizes substantive changes in the
+   remainder.
+
+   This document obsoletes RFC 2830, Sections 2 and 4.  The remainder of
+   RFC 2830 is obsoleted by [RFC4513].  Appendix C.2 summarizes
+   substantive changes to the remaining sections.
+
+   This document also obsoletes RFC 3771 in entirety.
+
+2.  Conventions
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY" in this document are
+   to be interpreted as described in [RFC2119].
+
+   Character names in this document use the notation for code points and
+   names from the Unicode Standard [Unicode].  For example, the letter
+   "a" may be represented as either <U+0061> or <LATIN SMALL LETTER A>.
+
+
+
+
+
+
+Sermersheim                 Standards Track                     [Page 3]
+
+RFC 4511                         LDAPv3                        June 2006
+
+
+   Note: a glossary of terms used in Unicode can be found in [Glossary].
+   Information on the Unicode character encoding model can be found in
+   [CharModel].
+
+   The term "transport connection" refers to the underlying transport
+   services used to carry the protocol exchange, as well as associations
+   established by these services.
+
+   The term "TLS layer" refers to Transport Layer Security (TLS)
+   services used in providing security services, as well as associations
+   established by these services.
+
+   The term "SASL layer" refers to Simply Authentication and Security
+   Layer (SASL) services used in providing security services, as well as
+   associations established by these services.
+
+   The term "LDAP message layer" refers to the LDAP Message Protocol
+   Data Unit (PDU) services used in providing directory services, as
+   well as associations established by these services.
+
+   The term "LDAP session" refers to combined services (transport
+   connection, TLS layer, SASL layer, LDAP message layer) and their
+   associations.
+
+   See the table in Section 5 for an illustration of these four terms.
+
+3.  Protocol Model
+
+   The general model adopted by this protocol is one of clients
+   performing protocol operations against servers.  In this model, a
+   client transmits a protocol request describing the operation to be
+   performed to a server.  The server is then responsible for performing
+   the necessary operation(s) in the Directory.  Upon completion of an
+   operation, the server typically returns a response containing
+   appropriate data to the requesting client.
+
+   Protocol operations are generally independent of one another.  Each
+   operation is processed as an atomic action, leaving the directory in
+   a consistent state.
+
+   Although servers are required to return responses whenever such
+   responses are defined in the protocol, there is no requirement for
+   synchronous behavior on the part of either clients or servers.
+   Requests and responses for multiple operations generally may be
+   exchanged between a client and server in any order.  If required,
+   synchronous behavior may be controlled by client applications.
+
+
+
+
+
+Sermersheim                 Standards Track                     [Page 4]
+
+RFC 4511                         LDAPv3                        June 2006
+
+
+   The core protocol operations defined in this document can be mapped
+   to a subset of the X.500 (1993) Directory Abstract Service [X.511].
+   However, there is not a one-to-one mapping between LDAP operations
+   and X.500 Directory Access Protocol (DAP) operations.  Server
+   implementations acting as a gateway to X.500 directories may need to
+   make multiple DAP requests to service a single LDAP request.
+
+3.1.  Operation and LDAP Message Layer Relationship
+
+   Protocol operations are exchanged at the LDAP message layer.  When
+   the transport connection is closed, any uncompleted operations at the
+   LDAP message layer are abandoned (when possible) or are completed
+   without transmission of the response (when abandoning them is not
+   possible).  Also, when the transport connection is closed, the client
+   MUST NOT assume that any uncompleted update operations have succeeded
+   or failed.
+
+4.  Elements of Protocol
+
+   The protocol is described using Abstract Syntax Notation One
+   ([ASN.1]) and is transferred using a subset of ASN.1 Basic Encoding
+   Rules ([BER]).  Section 5 specifies how the protocol elements are
+   encoded and transferred.
+
+   In order to support future extensions to this protocol, extensibility
+   is implied where it is allowed per ASN.1 (i.e., sequence, set,
+   choice, and enumerated types are extensible).  In addition, ellipses
+   (...) have been supplied in ASN.1 types that are explicitly
+   extensible as discussed in [RFC4520].  Because of the implied
+   extensibility, clients and servers MUST (unless otherwise specified)
+   ignore trailing SEQUENCE components whose tags they do not recognize.
+
+   Changes to the protocol other than through the extension mechanisms
+   described here require a different version number.  A client
+   indicates the version it is using as part of the BindRequest,
+   described in Section 4.2.  If a client has not sent a Bind, the
+   server MUST assume the client is using version 3 or later.
+
+   Clients may attempt to determine the protocol versions a server
+   supports by reading the 'supportedLDAPVersion' attribute from the
+   root DSE (DSA-Specific Entry) [RFC4512].
+
+4.1.  Common Elements
+
+   This section describes the LDAPMessage envelope Protocol Data Unit
+   (PDU) format, as well as data type definitions, which are used in the
+   protocol operations.
+
+
+
+
+Sermersheim                 Standards Track                     [Page 5]
+
+RFC 4511                         LDAPv3                        June 2006
+
+
+4.1.1.  Message Envelope
+
+   For the purposes of protocol exchanges, all protocol operations are
+   encapsulated in a common envelope, the LDAPMessage, which is defined
+   as follows:
+
+        LDAPMessage ::= SEQUENCE {
+             messageID       MessageID,
+             protocolOp      CHOICE {
+                  bindRequest           BindRequest,
+                  bindResponse          BindResponse,
+                  unbindRequest         UnbindRequest,
+                  searchRequest         SearchRequest,
+                  searchResEntry        SearchResultEntry,
+                  searchResDone         SearchResultDone,
+                  searchResRef          SearchResultReference,
+                  modifyRequest         ModifyRequest,
+                  modifyResponse        ModifyResponse,
+                  addRequest            AddRequest,
+                  addResponse           AddResponse,
+                  delRequest            DelRequest,
+                  delResponse           DelResponse,
+                  modDNRequest          ModifyDNRequest,
+                  modDNResponse         ModifyDNResponse,
+                  compareRequest        CompareRequest,
+                  compareResponse       CompareResponse,
+                  abandonRequest        AbandonRequest,
+                  extendedReq           ExtendedRequest,
+                  extendedResp          ExtendedResponse,
+                  ...,
+                  intermediateResponse  IntermediateResponse },
+             controls       [0] Controls OPTIONAL }
+
+        MessageID ::= INTEGER (0 ..  maxInt)
+
+        maxInt INTEGER ::= 2147483647 -- (2^^31 - 1) --
+
+   The ASN.1 type Controls is defined in Section 4.1.11.
+
+   The function of the LDAPMessage is to provide an envelope containing
+   common fields required in all protocol exchanges.  At this time, the
+   only common fields are the messageID and the controls.
+
+   If the server receives an LDAPMessage from the client in which the
+   LDAPMessage SEQUENCE tag cannot be recognized, the messageID cannot
+   be parsed, the tag of the protocolOp is not recognized as a request,
+   or the encoding structures or lengths of data fields are found to be
+   incorrect, then the server SHOULD return the Notice of Disconnection
+
+
+
+Sermersheim                 Standards Track                     [Page 6]
+
+RFC 4511                         LDAPv3                        June 2006
+
+
+   described in Section 4.4.1, with the resultCode set to protocolError,
+   and MUST immediately terminate the LDAP session as described in
+   Section 5.3.
+
+   In other cases where the client or server cannot parse an LDAP PDU,
+   it SHOULD abruptly terminate the LDAP session (Section 5.3) where
+   further communication (including providing notice) would be
+   pernicious.  Otherwise, server implementations MUST return an
+   appropriate response to the request, with the resultCode set to
+   protocolError.
+
+4.1.1.1.  MessageID
+
+   All LDAPMessage envelopes encapsulating responses contain the
+   messageID value of the corresponding request LDAPMessage.
+
+   The messageID of a request MUST have a non-zero value different from
+   the messageID of any other request in progress in the same LDAP
+   session.  The zero value is reserved for the unsolicited notification
+   message.
+
+   Typical clients increment a counter for each request.
+
+   A client MUST NOT send a request with the same messageID as an
+   earlier request in the same LDAP session unless it can be determined
+   that the server is no longer servicing the earlier request (e.g.,
+   after the final response is received, or a subsequent Bind
+   completes).  Otherwise, the behavior is undefined.  For this purpose,
+   note that Abandon and successfully abandoned operations do not send
+   responses.
+
+4.1.2.  String Types
+
+   The LDAPString is a notational convenience to indicate that, although
+   strings of LDAPString type encode as ASN.1 OCTET STRING types, the
+   [ISO10646] character set (a superset of [Unicode]) is used, encoded
+   following the UTF-8 [RFC3629] algorithm.  Note that Unicode
+   characters U+0000 through U+007F are the same as ASCII 0 through 127,
+   respectively, and have the same single octet UTF-8 encoding.  Other
+   Unicode characters have a multiple octet UTF-8 encoding.
+
+        LDAPString ::= OCTET STRING -- UTF-8 encoded,
+                                    -- [ISO10646] characters
+
+   The LDAPOID is a notational convenience to indicate that the
+   permitted value of this string is a (UTF-8 encoded) dotted-decimal
+   representation of an OBJECT IDENTIFIER.  Although an LDAPOID is
+
+
+
+
+Sermersheim                 Standards Track                     [Page 7]
+
+RFC 4511                         LDAPv3                        June 2006
+
+
+   encoded as an OCTET STRING, values are limited to the definition of
+   <numericoid> given in Section 1.4 of [RFC4512].
+
+        LDAPOID ::= OCTET STRING -- Constrained to <numericoid>
+                                 -- [RFC4512]
+
+   For example,
+
+        1.3.6.1.4.1.1466.1.2.3
+
+4.1.3.  Distinguished Name and Relative Distinguished Name
+
+   An LDAPDN is defined to be the representation of a Distinguished Name
+   (DN) after encoding according to the specification in [RFC4514].
+
+        LDAPDN ::= LDAPString
+                   -- Constrained to <distinguishedName> [RFC4514]
+
+   A RelativeLDAPDN is defined to be the representation of a Relative
+   Distinguished Name (RDN) after encoding according to the
+   specification in [RFC4514].
+
+        RelativeLDAPDN ::= LDAPString
+                           -- Constrained to <name-component> [RFC4514]
+
+4.1.4.  Attribute Descriptions
+
+   The definition and encoding rules for attribute descriptions are
+   defined in Section 2.5 of [RFC4512].  Briefly, an attribute
+   description is an attribute type and zero or more options.
+
+        AttributeDescription ::= LDAPString
+                                -- Constrained to <attributedescription>
+                                -- [RFC4512]
+
+4.1.5.  Attribute Value
+
+   A field of type AttributeValue is an OCTET STRING containing an
+   encoded attribute value.  The attribute value is encoded according to
+   the LDAP-specific encoding definition of its corresponding syntax.
+   The LDAP-specific encoding definitions for different syntaxes and
+   attribute types may be found in other documents and in particular
+   [RFC4517].
+
+        AttributeValue ::= OCTET STRING
+
+
+
+
+
+
+Sermersheim                 Standards Track                     [Page 8]
+
+RFC 4511                         LDAPv3                        June 2006
+
+
+   Note that there is no defined limit on the size of this encoding;
+   thus, protocol values may include multi-megabyte attribute values
+   (e.g., photographs).
+
+   Attribute values may be defined that have arbitrary and non-printable
+   syntax.  Implementations MUST NOT display or attempt to decode an
+   attribute value if its syntax is not known.  The implementation may
+   attempt to discover the subschema of the source entry and to retrieve
+   the descriptions of 'attributeTypes' from it [RFC4512].
+
+   Clients MUST only send attribute values in a request that are valid
+   according to the syntax defined for the attributes.
+
+4.1.6.  Attribute Value Assertion
+
+   The AttributeValueAssertion (AVA) type definition is similar to the
+   one in the X.500 Directory standards.  It contains an attribute
+   description and a matching rule ([RFC4512], Section 4.1.3) assertion
+   value suitable for that type.  Elements of this type are typically
+   used to assert that the value in assertionValue matches a value of an
+   attribute.
+
+        AttributeValueAssertion ::= SEQUENCE {
+             attributeDesc   AttributeDescription,
+             assertionValue  AssertionValue }
+
+        AssertionValue ::= OCTET STRING
+
+   The syntax of the AssertionValue depends on the context of the LDAP
+   operation being performed.  For example, the syntax of the EQUALITY
+   matching rule for an attribute is used when performing a Compare
+   operation.  Often this is the same syntax used for values of the
+   attribute type, but in some cases the assertion syntax differs from
+   the value syntax.  See objectIdentiferFirstComponentMatch in
+   [RFC4517] for an example.
+
+4.1.7.  Attribute and PartialAttribute
+
+   Attributes and partial attributes consist of an attribute description
+   and attribute values.  A PartialAttribute allows zero values, while
+   Attribute requires at least one value.
+
+        PartialAttribute ::= SEQUENCE {
+             type       AttributeDescription,
+             vals       SET OF value AttributeValue }
+
+
+
+
+
+
+Sermersheim                 Standards Track                     [Page 9]
+
+RFC 4511                         LDAPv3                        June 2006
+
+
+        Attribute ::= PartialAttribute(WITH COMPONENTS {
+             ...,
+             vals (SIZE(1..MAX))})
+
+   No two of the attribute values may be equivalent as described by
+   Section 2.2 of [RFC4512].  The set of attribute values is unordered.
+   Implementations MUST NOT rely upon the ordering being repeatable.
+
+4.1.8.  Matching Rule Identifier
+
+   Matching rules are defined in Section 4.1.3 of [RFC4512].  A matching
+   rule is identified in the protocol by the printable representation of
+   either its <numericoid> or one of its short name descriptors
+   [RFC4512], e.g., 'caseIgnoreMatch' or '2.5.13.2'.
+
+        MatchingRuleId ::= LDAPString
+
+4.1.9.  Result Message
+
+   The LDAPResult is the construct used in this protocol to return
+   success or failure indications from servers to clients.  To various
+   requests, servers will return responses containing the elements found
+   in LDAPResult to indicate the final status of the protocol operation
+   request.
+
+        LDAPResult ::= SEQUENCE {
+             resultCode         ENUMERATED {
+                  success                      (0),
+                  operationsError              (1),
+                  protocolError                (2),
+                  timeLimitExceeded            (3),
+                  sizeLimitExceeded            (4),
+                  compareFalse                 (5),
+                  compareTrue                  (6),
+                  authMethodNotSupported       (7),
+                  strongerAuthRequired         (8),
+                       -- 9 reserved --
+                  referral                     (10),
+                  adminLimitExceeded           (11),
+                  unavailableCriticalExtension (12),
+                  confidentialityRequired      (13),
+                  saslBindInProgress           (14),
+                  noSuchAttribute              (16),
+                  undefinedAttributeType       (17),
+                  inappropriateMatching        (18),
+                  constraintViolation          (19),
+                  attributeOrValueExists       (20),
+                  invalidAttributeSyntax       (21),
+
+
+
+Sermersheim                 Standards Track                    [Page 10]
+
+RFC 4511                         LDAPv3                        June 2006
+
+
+                       -- 22-31 unused --
+                  noSuchObject                 (32),
+                  aliasProblem                 (33),
+                  invalidDNSyntax              (34),
+                       -- 35 reserved for undefined isLeaf --
+                  aliasDereferencingProblem    (36),
+                       -- 37-47 unused --
+                  inappropriateAuthentication  (48),
+                  invalidCredentials           (49),
+                  insufficientAccessRights     (50),
+                  busy                         (51),
+                  unavailable                  (52),
+                  unwillingToPerform           (53),
+                  loopDetect                   (54),
+                       -- 55-63 unused --
+                  namingViolation              (64),
+                  objectClassViolation         (65),
+                  notAllowedOnNonLeaf          (66),
+                  notAllowedOnRDN              (67),
+                  entryAlreadyExists           (68),
+                  objectClassModsProhibited    (69),
+                       -- 70 reserved for CLDAP --
+                  affectsMultipleDSAs          (71),
+                       -- 72-79 unused --
+                  other                        (80),
+                  ...  },
+             matchedDN          LDAPDN,
+             diagnosticMessage  LDAPString,
+             referral           [3] Referral OPTIONAL }
+
+   The resultCode enumeration is extensible as defined in Section 3.8 of
+   [RFC4520].  The meanings of the listed result codes are given in
+   Appendix A.  If a server detects multiple errors for an operation,
+   only one result code is returned.  The server should return the
+   result code that best indicates the nature of the error encountered.
+   Servers may return substituted result codes to prevent unauthorized
+   disclosures.
+
+   The diagnosticMessage field of this construct may, at the server's
+   option, be used to return a string containing a textual, human-
+   readable diagnostic message (terminal control and page formatting
+   characters should be avoided).  As this diagnostic message is not
+   standardized, implementations MUST NOT rely on the values returned.
+   Diagnostic messages typically supplement the resultCode with
+   additional information.  If the server chooses not to return a
+   textual diagnostic, the diagnosticMessage field MUST be empty.
+
+
+
+
+
+Sermersheim                 Standards Track                    [Page 11]
+
+RFC 4511                         LDAPv3                        June 2006
+
+
+   For certain result codes (typically, but not restricted to
+   noSuchObject, aliasProblem, invalidDNSyntax, and
+   aliasDereferencingProblem), the matchedDN field is set (subject to
+   access controls) to the name of the last entry (object or alias) used
+   in finding the target (or base) object.  This will be a truncated
+   form of the provided name or, if an alias was dereferenced while
+   attempting to locate the entry, of the resulting name.  Otherwise,
+   the matchedDN field is empty.
+
+4.1.10.  Referral
+
+   The referral result code indicates that the contacted server cannot
+   or will not perform the operation and that one or more other servers
+   may be able to.  Reasons for this include:
+
+   - The target entry of the request is not held locally, but the server
+     has knowledge of its possible existence elsewhere.
+
+   - The operation is restricted on this server -- perhaps due to a
+     read-only copy of an entry to be modified.
+
+   The referral field is present in an LDAPResult if the resultCode is
+   set to referral, and it is absent with all other result codes.  It
+   contains one or more references to one or more servers or services
+   that may be accessed via LDAP or other protocols.  Referrals can be
+   returned in response to any operation request (except Unbind and
+   Abandon, which do not have responses).  At least one URI MUST be
+   present in the Referral.
+
+   During a Search operation, after the baseObject is located, and
+   entries are being evaluated, the referral is not returned.  Instead,
+   continuation references, described in Section 4.5.3, are returned
+   when other servers would need to be contacted to complete the
+   operation.
+
+        Referral ::= SEQUENCE SIZE (1..MAX) OF uri URI
+
+        URI ::= LDAPString     -- limited to characters permitted in
+                               -- URIs
+
+   If the client wishes to progress the operation, it contacts one of
+   the supported services found in the referral.  If multiple URIs are
+   present, the client assumes that any supported URI may be used to
+   progress the operation.
+
+   Clients that follow referrals MUST ensure that they do not loop
+   between servers.  They MUST NOT repeatedly contact the same server
+   for the same request with the same parameters.  Some clients use a
+
+
+
+Sermersheim                 Standards Track                    [Page 12]
+
+RFC 4511                         LDAPv3                        June 2006
+
+
+   counter that is incremented each time referral handling occurs for an
+   operation, and these kinds of clients MUST be able to handle at least
+   ten nested referrals while progressing the operation.
+
+   A URI for a server implementing LDAP and accessible via TCP/IP (v4 or
+   v6) [RFC793][RFC791] is written as an LDAP URL according to
+   [RFC4516].
+
+   Referral values that are LDAP URLs follow these rules:
+
+   - If an alias was dereferenced, the <dn> part of the LDAP URL MUST be
+     present, with the new target object name.
+
+   - It is RECOMMENDED that the <dn> part be present to avoid ambiguity.
+
+   - If the <dn> part is present, the client uses this name in its next
+     request to progress the operation, and if it is not present the
+     client uses the same name as in the original request.
+
+   - Some servers (e.g., participating in distributed indexing) may
+     provide a different filter in a URL of a referral for a Search
+     operation.
+
+   - If the <filter> part of the LDAP URL is present, the client uses
+     this filter in its next request to progress this Search, and if it
+     is not present the client uses the same filter as it used for that
+     Search.
+
+   - For Search, it is RECOMMENDED that the <scope> part be present to
+     avoid ambiguity.
+
+   - If the <scope> part is missing, the scope of the original Search is
+     used by the client to progress the operation.
+
+   - Other aspects of the new request may be the same as or different
+     from the request that generated the referral.
+
+   Other kinds of URIs may be returned.  The syntax and semantics of
+   such URIs is left to future specifications.  Clients may ignore URIs
+   that they do not support.
+
+   UTF-8 encoded characters appearing in the string representation of a
+   DN, search filter, or other fields of the referral value may not be
+   legal for URIs (e.g., spaces) and MUST be escaped using the % method
+   in [RFC3986].
+
+
+
+
+
+
+Sermersheim                 Standards Track                    [Page 13]
+
+RFC 4511                         LDAPv3                        June 2006
+
+
+4.1.11.  Controls
+
+   Controls provide a mechanism whereby the semantics and arguments of
+   existing LDAP operations may be extended.  One or more controls may
+   be attached to a single LDAP message.  A control only affects the
+   semantics of the message it is attached to.
+
+   Controls sent by clients are termed 'request controls', and those
+   sent by servers are termed 'response controls'.
+
+        Controls ::= SEQUENCE OF control Control
+
+        Control ::= SEQUENCE {
+             controlType             LDAPOID,
+             criticality             BOOLEAN DEFAULT FALSE,
+             controlValue            OCTET STRING OPTIONAL }
+
+   The controlType field is the dotted-decimal representation of an
+   OBJECT IDENTIFIER that uniquely identifies the control.  This
+   provides unambiguous naming of controls.  Often, response control(s)
+   solicited by a request control share controlType values with the
+   request control.
+
+   The criticality field only has meaning in controls attached to
+   request messages (except UnbindRequest).  For controls attached to
+   response messages and the UnbindRequest, the criticality field SHOULD
+   be FALSE, and MUST be ignored by the receiving protocol peer.  A
+   value of TRUE indicates that it is unacceptable to perform the
+   operation without applying the semantics of the control.
+   Specifically, the criticality field is applied as follows:
+
+   - If the server does not recognize the control type, determines that
+     it is not appropriate for the operation, or is otherwise unwilling
+     to perform the operation with the control, and if the criticality
+     field is TRUE, the server MUST NOT perform the operation, and for
+     operations that have a response message, it MUST return with the
+     resultCode set to unavailableCriticalExtension.
+
+   - If the server does not recognize the control type, determines that
+     it is not appropriate for the operation, or is otherwise unwilling
+     to perform the operation with the control, and if the criticality
+     field is FALSE, the server MUST ignore the control.
+
+   - Regardless of criticality, if a control is applied to an
+     operation, it is applied consistently and impartially to the
+     entire operation.
+
+
+
+
+
+Sermersheim                 Standards Track                    [Page 14]
+
+RFC 4511                         LDAPv3                        June 2006
+
+
+   The controlValue may contain information associated with the
+   controlType.  Its format is defined by the specification of the
+   control.  Implementations MUST be prepared to handle arbitrary
+   contents of the controlValue octet string, including zero bytes.  It
+   is absent only if there is no value information that is associated
+   with a control of its type.  When a controlValue is defined in terms
+   of ASN.1, and BER-encoded according to Section 5.1, it also follows
+   the extensibility rules in Section 4.
+
+   Servers list the controlType of request controls they recognize in
+   the 'supportedControl' attribute in the root DSE (Section 5.1 of
+   [RFC4512]).
+
+   Controls SHOULD NOT be combined unless the semantics of the
+   combination has been specified.  The semantics of control
+   combinations, if specified, are generally found in the control
+   specification most recently published.  When a combination of
+   controls is encountered whose semantics are invalid, not specified
+   (or not known), the message is considered not well-formed; thus, the
+   operation fails with protocolError.  Controls with a criticality of
+   FALSE may be ignored in order to arrive at a valid combination.
+   Additionally, unless order-dependent semantics are given in a
+   specification, the order of a combination of controls in the SEQUENCE
+   is ignored.  Where the order is to be ignored but cannot be ignored
+   by the server, the message is considered not well-formed, and the
+   operation fails with protocolError.  Again, controls with a
+   criticality of FALSE may be ignored in order to arrive at a valid
+   combination.
+
+   This document does not specify any controls.  Controls may be
+   specified in other documents.  Documents detailing control extensions
+   are to provide for each control:
+
+   - the OBJECT IDENTIFIER assigned to the control,
+
+   - direction as to what value the sender should provide for the
+     criticality field (note: the semantics of the criticality field are
+     defined above should not be altered by the control's
+     specification),
+
+   - whether the controlValue field is present, and if so, the format of
+     its contents,
+
+   - the semantics of the control, and
+
+   - optionally, semantics regarding the combination of the control with
+     other controls.
+
+
+
+
+Sermersheim                 Standards Track                    [Page 15]
+
+RFC 4511                         LDAPv3                        June 2006
+
+
+4.2.  Bind Operation
+
+   The function of the Bind operation is to allow authentication
+   information to be exchanged between the client and server.  The Bind
+   operation should be thought of as the "authenticate" operation.
+   Operational, authentication, and security-related semantics of this
+   operation are given in [RFC4513].
+
+   The Bind request is defined as follows:
+
+        BindRequest ::= [APPLICATION 0] SEQUENCE {
+             version                 INTEGER (1 ..  127),
+             name                    LDAPDN,
+             authentication          AuthenticationChoice }
+
+        AuthenticationChoice ::= CHOICE {
+             simple                  [0] OCTET STRING,
+                                     -- 1 and 2 reserved
+             sasl                    [3] SaslCredentials,
+             ...  }
+
+        SaslCredentials ::= SEQUENCE {
+             mechanism               LDAPString,
+             credentials             OCTET STRING OPTIONAL }
+
+   Fields of the BindRequest are:
+
+   - version: A version number indicating the version of the protocol to
+     be used at the LDAP message layer.  This document describes version
+     3 of the protocol.  There is no version negotiation.  The client
+     sets this field to the version it desires.  If the server does not
+     support the specified version, it MUST respond with a BindResponse
+     where the resultCode is set to protocolError.
+
+   - name: If not empty, the name of the Directory object that the
+     client wishes to bind as.  This field may take on a null value (a
+     zero-length string) for the purposes of anonymous binds ([RFC4513],
+     Section 5.1) or when using SASL [RFC4422] authentication
+     ([RFC4513], Section 5.2).  Where the server attempts to locate the
+     named object, it SHALL NOT perform alias dereferencing.
+
+   - authentication: Information used in authentication.  This type is
+     extensible as defined in Section 3.7 of [RFC4520].  Servers that do
+     not support a choice supplied by a client return a BindResponse
+     with the resultCode set to authMethodNotSupported.
+
+
+
+
+
+
+Sermersheim                 Standards Track                    [Page 16]
+
+RFC 4511                         LDAPv3                        June 2006
+
+
+     Textual passwords (consisting of a character sequence with a known
+     character set and encoding) transferred to the server using the
+     simple AuthenticationChoice SHALL be transferred as UTF-8 [RFC3629]
+     encoded [Unicode].  Prior to transfer, clients SHOULD prepare text
+     passwords as "query" strings by applying the SASLprep [RFC4013]
+     profile of the stringprep [RFC3454] algorithm.  Passwords
+     consisting of other data (such as random octets) MUST NOT be
+     altered.  The determination of whether a password is textual is a
+     local client matter.
+
+4.2.1.  Processing of the Bind Request
+
+   Before processing a BindRequest, all uncompleted operations MUST
+   either complete or be abandoned.  The server may either wait for the
+   uncompleted operations to complete, or abandon them.  The server then
+   proceeds to authenticate the client in either a single-step or
+   multi-step Bind process.  Each step requires the server to return a
+   BindResponse to indicate the status of authentication.
+
+   After sending a BindRequest, clients MUST NOT send further LDAP PDUs
+   until receiving the BindResponse.  Similarly, servers SHOULD NOT
+   process or respond to requests received while processing a
+   BindRequest.
+
+   If the client did not bind before sending a request and receives an
+   operationsError to that request, it may then send a BindRequest.  If
+   this also fails or the client chooses not to bind on the existing
+   LDAP session, it may terminate the LDAP session, re-establish it, and
+   begin again by first sending a BindRequest.  This will aid in
+   interoperating with servers implementing other versions of LDAP.
+
+   Clients may send multiple Bind requests to change the authentication
+   and/or security associations or to complete a multi-stage Bind
+   process.  Authentication from earlier binds is subsequently ignored.
+
+   For some SASL authentication mechanisms, it may be necessary for the
+   client to invoke the BindRequest multiple times ([RFC4513], Section
+   5.2).  Clients MUST NOT invoke operations between two Bind requests
+   made as part of a multi-stage Bind.
+
+   A client may abort a SASL bind negotiation by sending a BindRequest
+   with a different value in the mechanism field of SaslCredentials, or
+   an AuthenticationChoice other than sasl.
+
+
+
+
+
+
+
+
+Sermersheim                 Standards Track                    [Page 17]
+
+RFC 4511                         LDAPv3                        June 2006
+
+
+   If the client sends a BindRequest with the sasl mechanism field as an
+   empty string, the server MUST return a BindResponse with the
+   resultCode set to authMethodNotSupported.  This will allow the client
+   to abort a negotiation if it wishes to try again with the same SASL
+   mechanism.
+
+4.2.2.  Bind Response
+
+   The Bind response is defined as follows.
+
+        BindResponse ::= [APPLICATION 1] SEQUENCE {
+             COMPONENTS OF LDAPResult,
+             serverSaslCreds    [7] OCTET STRING OPTIONAL }
+
+   BindResponse consists simply of an indication from the server of the
+   status of the client's request for authentication.
+
+   A successful Bind operation is indicated by a BindResponse with a
+   resultCode set to success.  Otherwise, an appropriate result code is
+   set in the BindResponse.  For BindResponse, the protocolError result
+   code may be used to indicate that the version number supplied by the
+   client is unsupported.
+
+   If the client receives a BindResponse where the resultCode is set to
+   protocolError, it is to assume that the server does not support this
+   version of LDAP.  While the client may be able proceed with another
+   version of this protocol (which may or may not require closing and
+   re-establishing the transport connection), how to proceed with
+   another version of this protocol is beyond the scope of this
+   document.  Clients that are unable or unwilling to proceed SHOULD
+   terminate the LDAP session.
+
+   The serverSaslCreds field is used as part of a SASL-defined bind
+   mechanism to allow the client to authenticate the server to which it
+   is communicating, or to perform "challenge-response" authentication.
+   If the client bound with the simple choice, or the SASL mechanism
+   does not require the server to return information to the client, then
+   this field SHALL NOT be included in the BindResponse.
+
+4.3.  Unbind Operation
+
+   The function of the Unbind operation is to terminate an LDAP session.
+   The Unbind operation is not the antithesis of the Bind operation as
+   the name implies.  The naming of these operations are historical.
+   The Unbind operation should be thought of as the "quit" operation.
+
+
+
+
+
+
+Sermersheim                 Standards Track                    [Page 18]
+
+RFC 4511                         LDAPv3                        June 2006
+
+
+   The Unbind operation is defined as follows:
+
+        UnbindRequest ::= [APPLICATION 2] NULL
+
+   The client, upon transmission of the UnbindRequest, and the server,
+   upon receipt of the UnbindRequest, are to gracefully terminate the
+   LDAP session as described in Section 5.3.  Uncompleted operations are
+   handled as specified in Section 3.1.
+
+4.4.  Unsolicited Notification
+
+   An unsolicited notification is an LDAPMessage sent from the server to
+   the client that is not in response to any LDAPMessage received by the
+   server.  It is used to signal an extraordinary condition in the
+   server or in the LDAP session between the client and the server.  The
+   notification is of an advisory nature, and the server will not expect
+   any response to be returned from the client.
+
+   The unsolicited notification is structured as an LDAPMessage in which
+   the messageID is zero and protocolOp is set to the extendedResp
+   choice using the ExtendedResponse type (See Section 4.12).  The
+   responseName field of the ExtendedResponse always contains an LDAPOID
+   that is unique for this notification.
+
+   One unsolicited notification (Notice of Disconnection) is defined in
+   this document.  The specification of an unsolicited notification
+   consists of:
+
+   - the OBJECT IDENTIFIER assigned to the notification (to be specified
+     in the responseName,
+
+   - the format of the contents of the responseValue (if any),
+
+   - the circumstances which will cause the notification to be sent, and
+
+   - the semantics of the message.
+
+4.4.1.  Notice of Disconnection
+
+   This notification may be used by the server to advise the client that
+   the server is about to terminate the LDAP session on its own
+   initiative.  This notification is intended to assist clients in
+   distinguishing between an exceptional server condition and a
+   transient network failure.  Note that this notification is not a
+   response to an Unbind requested by the client.  Uncompleted
+   operations are handled as specified in Section 3.1.
+
+
+
+
+
+Sermersheim                 Standards Track                    [Page 19]
+
+RFC 4511                         LDAPv3                        June 2006
+
+
+   The responseName is 1.3.6.1.4.1.1466.20036, the responseValue field
+   is absent, and the resultCode is used to indicate the reason for the
+   disconnection.  When the strongerAuthRequired resultCode is returned
+   with this message, it indicates that the server has detected that an
+   established security association between the client and server has
+   unexpectedly failed or been compromised.
+
+   Upon transmission of the Notice of Disconnection, the server
+   gracefully terminates the LDAP session as described in Section 5.3.
+
+4.5.  Search Operation
+
+   The Search operation is used to request a server to return, subject
+   to access controls and other restrictions, a set of entries matching
+   a complex search criterion.  This can be used to read attributes from
+   a single entry, from entries immediately subordinate to a particular
+   entry, or from a whole subtree of entries.
+
+4.5.1.  Search Request
+
+   The Search request is defined as follows:
+
+        SearchRequest ::= [APPLICATION 3] SEQUENCE {
+             baseObject      LDAPDN,
+             scope           ENUMERATED {
+                  baseObject              (0),
+                  singleLevel             (1),
+                  wholeSubtree            (2),
+                  ...  },
+             derefAliases    ENUMERATED {
+                  neverDerefAliases       (0),
+                  derefInSearching        (1),
+                  derefFindingBaseObj     (2),
+                  derefAlways             (3) },
+             sizeLimit       INTEGER (0 ..  maxInt),
+             timeLimit       INTEGER (0 ..  maxInt),
+             typesOnly       BOOLEAN,
+             filter          Filter,
+             attributes      AttributeSelection }
+
+        AttributeSelection ::= SEQUENCE OF selector LDAPString
+                        -- The LDAPString is constrained to
+                        -- <attributeSelector> in Section 4.5.1.8
+
+        Filter ::= CHOICE {
+             and             [0] SET SIZE (1..MAX) OF filter Filter,
+             or              [1] SET SIZE (1..MAX) OF filter Filter,
+             not             [2] Filter,
+
+
+
+Sermersheim                 Standards Track                    [Page 20]
+
+RFC 4511                         LDAPv3                        June 2006
+
+
+             equalityMatch   [3] AttributeValueAssertion,
+             substrings      [4] SubstringFilter,
+             greaterOrEqual  [5] AttributeValueAssertion,
+             lessOrEqual     [6] AttributeValueAssertion,
+             present         [7] AttributeDescription,
+             approxMatch     [8] AttributeValueAssertion,
+             extensibleMatch [9] MatchingRuleAssertion,
+             ...  }
+
+        SubstringFilter ::= SEQUENCE {
+             type           AttributeDescription,
+             substrings     SEQUENCE SIZE (1..MAX) OF substring CHOICE {
+                  initial [0] AssertionValue,  -- can occur at most once
+                  any     [1] AssertionValue,
+                  final   [2] AssertionValue } -- can occur at most once
+             }
+
+        MatchingRuleAssertion ::= SEQUENCE {
+             matchingRule    [1] MatchingRuleId OPTIONAL,
+             type            [2] AttributeDescription OPTIONAL,
+             matchValue      [3] AssertionValue,
+             dnAttributes    [4] BOOLEAN DEFAULT FALSE }
+
+   Note that an X.500 "list"-like operation can be emulated by the
+   client requesting a singleLevel Search operation with a filter
+   checking for the presence of the 'objectClass' attribute, and that an
+   X.500 "read"-like operation can be emulated by a baseObject Search
+   operation with the same filter.  A server that provides a gateway to
+   X.500 is not required to use the Read or List operations, although it
+   may choose to do so, and if it does, it must provide the same
+   semantics as the X.500 Search operation.
+
+4.5.1.1.  SearchRequest.baseObject
+
+   The name of the base object entry (or possibly the root) relative to
+   which the Search is to be performed.
+
+4.5.1.2.  SearchRequest.scope
+
+   Specifies the scope of the Search to be performed.  The semantics (as
+   described in [X.511]) of the defined values of this field are:
+
+      baseObject: The scope is constrained to the entry named by
+      baseObject.
+
+      singleLevel: The scope is constrained to the immediate
+      subordinates of the entry named by baseObject.
+
+
+
+
+Sermersheim                 Standards Track                    [Page 21]
+
+RFC 4511                         LDAPv3                        June 2006
+
+
+      wholeSubtree: The scope is constrained to the entry named by
+      baseObject and to all its subordinates.
+
+4.5.1.3.  SearchRequest.derefAliases
+
+   An indicator as to whether or not alias entries (as defined in
+   [RFC4512]) are to be dereferenced during stages of the Search
+   operation.
+
+   The act of dereferencing an alias includes recursively dereferencing
+   aliases that refer to aliases.
+
+   Servers MUST detect looping while dereferencing aliases in order to
+   prevent denial-of-service attacks of this nature.
+
+   The semantics of the defined values of this field are:
+
+      neverDerefAliases: Do not dereference aliases in searching or in
+      locating the base object of the Search.
+
+      derefInSearching: While searching subordinates of the base object,
+      dereference any alias within the search scope.  Dereferenced
+      objects become the vertices of further search scopes where the
+      Search operation is also applied.  If the search scope is
+      wholeSubtree, the Search continues in the subtree(s) of any
+      dereferenced object.  If the search scope is singleLevel, the
+      search is applied to any dereferenced objects and is not applied
+      to their subordinates.  Servers SHOULD eliminate duplicate entries
+      that arise due to alias dereferencing while searching.
+
+      derefFindingBaseObj: Dereference aliases in locating the base
+      object of the Search, but not when searching subordinates of the
+      base object.
+
+      derefAlways: Dereference aliases both in searching and in locating
+      the base object of the Search.
+
+4.5.1.4.  SearchRequest.sizeLimit
+
+   A size limit that restricts the maximum number of entries to be
+   returned as a result of the Search.  A value of zero in this field
+   indicates that no client-requested size limit restrictions are in
+   effect for the Search.  Servers may also enforce a maximum number of
+   entries to return.
+
+
+
+
+
+
+
+Sermersheim                 Standards Track                    [Page 22]
+
+RFC 4511                         LDAPv3                        June 2006
+
+
+4.5.1.5.  SearchRequest.timeLimit
+
+   A time limit that restricts the maximum time (in seconds) allowed for
+   a Search.  A value of zero in this field indicates that no client-
+   requested time limit restrictions are in effect for the Search.
+   Servers may also enforce a maximum time limit for the Search.
+
+4.5.1.6.  SearchRequest.typesOnly
+
+   An indicator as to whether Search results are to contain both
+   attribute descriptions and values, or just attribute descriptions.
+   Setting this field to TRUE causes only attribute descriptions (and
+   not values) to be returned.  Setting this field to FALSE causes both
+   attribute descriptions and values to be returned.
+
+4.5.1.7.  SearchRequest.filter
+
+   A filter that defines the conditions that must be fulfilled in order
+   for the Search to match a given entry.
+
+   The 'and', 'or', and 'not' choices can be used to form combinations
+   of filters.  At least one filter element MUST be present in an 'and'
+   or 'or' choice.  The others match against individual attribute values
+   of entries in the scope of the Search.  (Implementor's note: the
+   'not' filter is an example of a tagged choice in an implicitly-tagged
+   module.  In BER this is treated as if the tag were explicit.)
+
+   A server MUST evaluate filters according to the three-valued logic of
+   [X.511] (1993), Clause 7.8.1.  In summary, a filter is evaluated to
+   "TRUE", "FALSE", or "Undefined".  If the filter evaluates to TRUE for
+   a particular entry, then the attributes of that entry are returned as
+   part of the Search result (subject to any applicable access control
+   restrictions).  If the filter evaluates to FALSE or Undefined, then
+   the entry is ignored for the Search.
+
+   A filter of the "and" choice is TRUE if all the filters in the SET OF
+   evaluate to TRUE, FALSE if at least one filter is FALSE, and
+   Undefined otherwise.  A filter of the "or" choice is FALSE if all the
+   filters in the SET OF evaluate to FALSE, TRUE if at least one filter
+   is TRUE, and Undefined otherwise.  A filter of the 'not' choice is
+   TRUE if the filter being negated is FALSE, FALSE if it is TRUE, and
+   Undefined if it is Undefined.
+
+   A filter item evaluates to Undefined when the server would not be
+   able to determine whether the assertion value matches an entry.
+   Examples include:
+
+
+
+
+
+Sermersheim                 Standards Track                    [Page 23]
+
+RFC 4511                         LDAPv3                        June 2006
+
+
+   - An attribute description in an equalityMatch, substrings,
+     greaterOrEqual, lessOrEqual, approxMatch, or extensibleMatch filter
+     is not recognized by the server.
+
+   - The attribute type does not define the appropriate matching rule.
+
+   - A MatchingRuleId in the extensibleMatch is not recognized by the
+     server or is not valid for the attribute type.
+
+   - The type of filtering requested is not implemented.
+
+   - The assertion value is invalid.
+
+   For example, if a server did not recognize the attribute type
+   shoeSize, the filters (shoeSize=*), (shoeSize=12), (shoeSize>=12),
+   and (shoeSize<=12) would each evaluate to Undefined.
+
+   Servers MUST NOT return errors if attribute descriptions or matching
+   rule ids are not recognized, assertion values are invalid, or the
+   assertion syntax is not supported.  More details of filter processing
+   are given in Clause 7.8 of [X.511].
+
+4.5.1.7.1.  SearchRequest.filter.equalityMatch
+
+   The matching rule for an equalityMatch filter is defined by the
+   EQUALITY matching rule for the attribute type or subtype.  The filter
+   is TRUE when the EQUALITY rule returns TRUE as applied to the
+   attribute or subtype and the asserted value.
+
+4.5.1.7.2.  SearchRequest.filter.substrings
+
+   There SHALL be at most one 'initial' and at most one 'final' in the
+   'substrings' of a SubstringFilter.  If 'initial' is present, it SHALL
+   be the first element of 'substrings'.  If 'final' is present, it
+   SHALL be the last element of 'substrings'.
+
+   The matching rule for an AssertionValue in a substrings filter item
+   is defined by the SUBSTR matching rule for the attribute type or
+   subtype.  The filter is TRUE when the SUBSTR rule returns TRUE as
+   applied to the attribute or subtype and the asserted value.
+
+   Note that the AssertionValue in a substrings filter item conforms to
+   the assertion syntax of the EQUALITY matching rule for the attribute
+   type rather than to the assertion syntax of the SUBSTR matching rule
+   for the attribute type.  Conceptually, the entire SubstringFilter is
+   converted into an assertion value of the substrings matching rule
+   prior to applying the rule.
+
+
+
+
+Sermersheim                 Standards Track                    [Page 24]
+
+RFC 4511                         LDAPv3                        June 2006
+
+
+4.5.1.7.3.  SearchRequest.filter.greaterOrEqual
+
+   The matching rule for a greaterOrEqual filter is defined by the
+   ORDERING matching rule for the attribute type or subtype.  The filter
+   is TRUE when the ORDERING rule returns FALSE as applied to the
+   attribute or subtype and the asserted value.
+
+4.5.1.7.4.  SearchRequest.filter.lessOrEqual
+
+   The matching rules for a lessOrEqual filter are defined by the
+   ORDERING and EQUALITY matching rules for the attribute type or
+   subtype.  The filter is TRUE when either the ORDERING or EQUALITY
+   rule returns TRUE as applied to the attribute or subtype and the
+   asserted value.
+
+4.5.1.7.5.  SearchRequest.filter.present
+
+   A present filter is TRUE when there is an attribute or subtype of the
+   specified attribute description present in an entry, FALSE when no
+   attribute or subtype of the specified attribute description is
+   present in an entry, and Undefined otherwise.
+
+4.5.1.7.6.  SearchRequest.filter.approxMatch
+
+   An approxMatch filter is TRUE when there is a value of the attribute
+   type or subtype for which some locally-defined approximate matching
+   algorithm (e.g., spelling variations, phonetic match, etc.) returns
+   TRUE.  If a value matches for equality, it also satisfies an
+   approximate match.  If approximate matching is not supported for the
+   attribute, this filter item should be treated as an equalityMatch.
+
+4.5.1.7.7.  SearchRequest.filter.extensibleMatch
+
+   The fields of the extensibleMatch filter item are evaluated as
+   follows:
+
+   - If the matchingRule field is absent, the type field MUST be
+     present, and an equality match is performed for that type.
+
+   - If the type field is absent and the matchingRule is present, the
+     matchValue is compared against all attributes in an entry that
+     support that matchingRule.
+
+   - If the type field is present and the matchingRule is present, the
+     matchValue is compared against the specified attribute type and its
+     subtypes.
+
+
+
+
+
+Sermersheim                 Standards Track                    [Page 25]
+
+RFC 4511                         LDAPv3                        June 2006
+
+
+   - If the dnAttributes field is set to TRUE, the match is additionally
+     applied against all the AttributeValueAssertions in an entry's
+     distinguished name, and it evaluates to TRUE if there is at least
+     one attribute or subtype in the distinguished name for which the
+     filter item evaluates to TRUE.  The dnAttributes field is present
+     to alleviate the need for multiple versions of generic matching
+     rules (such as word matching), where one applies to entries and
+     another applies to entries and DN attributes as well.
+
+   The matchingRule used for evaluation determines the syntax for the
+   assertion value.  Once the matchingRule and attribute(s) have been
+   determined, the filter item evaluates to TRUE if it matches at least
+   one attribute type or subtype in the entry, FALSE if it does not
+   match any attribute type or subtype in the entry, and Undefined if
+   the matchingRule is not recognized, the matchingRule is unsuitable
+   for use with the specified type, or the assertionValue is invalid.
+
+4.5.1.8.  SearchRequest.attributes
+
+   A selection list of the attributes to be returned from each entry
+   that matches the search filter.  Attributes that are subtypes of
+   listed attributes are implicitly included.  LDAPString values of this
+   field are constrained to the following Augmented Backus-Naur Form
+   (ABNF) [RFC4234]:
+
+      attributeSelector = attributedescription / selectorspecial
+
+      selectorspecial = noattrs / alluserattrs
+
+      noattrs = %x31.2E.31 ; "1.1"
+
+      alluserattrs = %x2A ; asterisk ("*")
+
+      The <attributedescription> production is defined in Section 2.5 of
+      [RFC4512].
+
+      There are three special cases that may appear in the attributes
+      selection list:
+
+      1. An empty list with no attributes requests the return of all
+         user attributes.
+
+      2. A list containing "*" (with zero or more attribute
+         descriptions) requests the return of all user attributes in
+         addition to other listed (operational) attributes.
+
+
+
+
+
+
+Sermersheim                 Standards Track                    [Page 26]
+
+RFC 4511                         LDAPv3                        June 2006
+
+
+      3. A list containing only the OID "1.1" indicates that no
+         attributes are to be returned.  If "1.1" is provided with other
+         attributeSelector values, the "1.1" attributeSelector is
+         ignored.  This OID was chosen because it does not (and can not)
+         correspond to any attribute in use.
+
+   Client implementors should note that even if all user attributes are
+   requested, some attributes and/or attribute values of the entry may
+   not be included in Search results due to access controls or other
+   restrictions.  Furthermore, servers will not return operational
+   attributes, such as objectClasses or attributeTypes, unless they are
+   listed by name.  Operational attributes are described in [RFC4512].
+
+   Attributes are returned at most once in an entry.  If an attribute
+   description is named more than once in the list, the subsequent names
+   are ignored.  If an attribute description in the list is not
+   recognized, it is ignored by the server.
+
+4.5.2.  Search Result
+
+   The results of the Search operation are returned as zero or more
+   SearchResultEntry and/or SearchResultReference messages, followed by
+   a single SearchResultDone message.
+
+        SearchResultEntry ::= [APPLICATION 4] SEQUENCE {
+             objectName      LDAPDN,
+             attributes      PartialAttributeList }
+
+        PartialAttributeList ::= SEQUENCE OF
+                             partialAttribute PartialAttribute
+
+        SearchResultReference ::= [APPLICATION 19] SEQUENCE
+                                  SIZE (1..MAX) OF uri URI
+
+        SearchResultDone ::= [APPLICATION 5] LDAPResult
+
+   Each SearchResultEntry represents an entry found during the Search.
+   Each SearchResultReference represents an area not yet explored during
+   the Search.  The SearchResultEntry and SearchResultReference messages
+   may come in any order.  Following all the SearchResultReference and
+   SearchResultEntry responses, the server returns a SearchResultDone
+   response, which contains an indication of success or details any
+   errors that have occurred.
+
+   Each entry returned in a SearchResultEntry will contain all
+   appropriate attributes as specified in the attributes field of the
+   Search Request, subject to access control and other administrative
+   policy.  Note that the PartialAttributeList may hold zero elements.
+
+
+
+Sermersheim                 Standards Track                    [Page 27]
+
+RFC 4511                         LDAPv3                        June 2006
+
+
+   This may happen when none of the attributes of an entry were
+   requested or could be returned.  Note also that the partialAttribute
+   vals set may hold zero elements.  This may happen when typesOnly is
+   requested, access controls prevent the return of values, or other
+   reasons.
+
+   Some attributes may be constructed by the server and appear in a
+   SearchResultEntry attribute list, although they are not stored
+   attributes of an entry.  Clients SHOULD NOT assume that all
+   attributes can be modified, even if this is permitted by access
+   control.
+
+   If the server's schema defines short names [RFC4512] for an attribute
+   type, then the server SHOULD use one of those names in attribute
+   descriptions for that attribute type (in preference to using the
+   <numericoid> [RFC4512] format of the attribute type's object
+   identifier).  The server SHOULD NOT use the short name if that name
+   is known by the server to be ambiguous, or if it is otherwise likely
+   to cause interoperability problems.
+
+4.5.3.  Continuation References in the Search Result
+
+   If the server was able to locate the entry referred to by the
+   baseObject but was unable or unwilling to search one or more non-
+   local entries, the server may return one or more
+   SearchResultReference messages, each containing a reference to
+   another set of servers for continuing the operation.  A server MUST
+   NOT return any SearchResultReference messages if it has not located
+   the baseObject and thus has not searched any entries.  In this case,
+   it would return a SearchResultDone containing either a referral or
+   noSuchObject result code (depending on the server's knowledge of the
+   entry named in the baseObject).
+
+   If a server holds a copy or partial copy of the subordinate naming
+   context (Section 5 of [RFC4512]), it may use the search filter to
+   determine whether or not to return a SearchResultReference response.
+   Otherwise, SearchResultReference responses are always returned when
+   in scope.
+
+   The SearchResultReference is of the same data type as the Referral.
+
+   If the client wishes to progress the Search, it issues a new Search
+   operation for each SearchResultReference that is returned.  If
+   multiple URIs are present, the client assumes that any supported URI
+   may be used to progress the operation.
+
+
+
+
+
+
+Sermersheim                 Standards Track                    [Page 28]
+
+RFC 4511                         LDAPv3                        June 2006
+
+
+   Clients that follow search continuation references MUST ensure that
+   they do not loop between servers.  They MUST NOT repeatedly contact
+   the same server for the same request with the same parameters.  Some
+   clients use a counter that is incremented each time search result
+   reference handling occurs for an operation, and these kinds of
+   clients MUST be able to handle at least ten nested referrals while
+   progressing the operation.
+
+   Note that the Abandon operation described in Section 4.11 applies
+   only to a particular operation sent at the LDAP message layer between
+   a client and server.  The client must individually abandon subsequent
+   Search operations it wishes to.
+
+   A URI for a server implementing LDAP and accessible via TCP/IP (v4 or
+   v6) [RFC793][RFC791] is written as an LDAP URL according to
+   [RFC4516].
+
+   SearchResultReference values that are LDAP URLs follow these rules:
+
+   - The <dn> part of the LDAP URL MUST be present, with the new target
+     object name.  The client uses this name when following the
+     reference.
+
+   - Some servers (e.g., participating in distributed indexing) may
+     provide a different filter in the LDAP URL.
+
+   - If the <filter> part of the LDAP URL is present, the client uses
+     this filter in its next request to progress this Search, and if it
+     is not present the client uses the same filter as it used for that
+     Search.
+
+   - If the originating search scope was singleLevel, the <scope> part
+     of the LDAP URL will be "base".
+
+   - It is RECOMMENDED that the <scope> part be present to avoid
+     ambiguity.  In the absence of a <scope> part, the scope of the
+     original Search request is assumed.
+
+   - Other aspects of the new Search request may be the same as or
+     different from the Search request that generated the
+     SearchResultReference.
+
+   - The name of an unexplored subtree in a SearchResultReference need
+     not be subordinate to the base object.
+
+   Other kinds of URIs may be returned.  The syntax and semantics of
+   such URIs is left to future specifications.  Clients may ignore URIs
+   that they do not support.
+
+
+
+Sermersheim                 Standards Track                    [Page 29]
+
+RFC 4511                         LDAPv3                        June 2006
+
+
+   UTF-8-encoded characters appearing in the string representation of a
+   DN, search filter, or other fields of the referral value may not be
+   legal for URIs (e.g., spaces) and MUST be escaped using the % method
+   in [RFC3986].
+
+4.5.3.1.  Examples
+
+   For example, suppose the contacted server (hosta) holds the entry
+   <DC=Example,DC=NET> and the entry <CN=Manager,DC=Example,DC=NET>.  It
+   knows that both LDAP servers (hostb) and (hostc) hold
+   <OU=People,DC=Example,DC=NET> (one is the master and the other server
+   a shadow), and that LDAP-capable server (hostd) holds the subtree
+   <OU=Roles,DC=Example,DC=NET>.  If a wholeSubtree Search of
+   <DC=Example,DC=NET> is requested to the contacted server, it may
+   return the following:
+
+     SearchResultEntry for DC=Example,DC=NET
+     SearchResultEntry for CN=Manager,DC=Example,DC=NET
+     SearchResultReference {
+       ldap://hostb/OU=People,DC=Example,DC=NET??sub
+       ldap://hostc/OU=People,DC=Example,DC=NET??sub }
+     SearchResultReference {
+       ldap://hostd/OU=Roles,DC=Example,DC=NET??sub }
+     SearchResultDone (success)
+
+   Client implementors should note that when following a
+   SearchResultReference, additional SearchResultReference may be
+   generated.  Continuing the example, if the client contacted the
+   server (hostb) and issued the Search request for the subtree
+   <OU=People,DC=Example,DC=NET>, the server might respond as follows:
+
+     SearchResultEntry for OU=People,DC=Example,DC=NET
+     SearchResultReference {
+       ldap://hoste/OU=Managers,OU=People,DC=Example,DC=NET??sub }
+     SearchResultReference {
+       ldap://hostf/OU=Consultants,OU=People,DC=Example,DC=NET??sub }
+     SearchResultDone (success)
+
+   Similarly, if a singleLevel Search of <DC=Example,DC=NET> is
+   requested to the contacted server, it may return the following:
+
+     SearchResultEntry for CN=Manager,DC=Example,DC=NET
+     SearchResultReference {
+       ldap://hostb/OU=People,DC=Example,DC=NET??base
+       ldap://hostc/OU=People,DC=Example,DC=NET??base }
+     SearchResultReference {
+       ldap://hostd/OU=Roles,DC=Example,DC=NET??base }
+     SearchResultDone (success)
+
+
+
+Sermersheim                 Standards Track                    [Page 30]
+
+RFC 4511                         LDAPv3                        June 2006
+
+
+   If the contacted server does not hold the base object for the Search,
+   but has knowledge of its possible location, then it may return a
+   referral to the client.  In this case, if the client requests a
+   subtree Search of <DC=Example,DC=ORG> to hosta, the server returns a
+   SearchResultDone containing a referral.
+
+     SearchResultDone (referral) {
+       ldap://hostg/DC=Example,DC=ORG??sub }
+
+4.6.  Modify Operation
+
+   The Modify operation allows a client to request that a modification
+   of an entry be performed on its behalf by a server.  The Modify
+   Request is defined as follows:
+
+        ModifyRequest ::= [APPLICATION 6] SEQUENCE {
+             object          LDAPDN,
+             changes         SEQUENCE OF change SEQUENCE {
+                  operation       ENUMERATED {
+                       add     (0),
+                       delete  (1),
+                       replace (2),
+                       ...  },
+                  modification    PartialAttribute } }
+
+   Fields of the Modify Request are:
+
+   - object: The value of this field contains the name of the entry to
+     be modified.  The server SHALL NOT perform any alias dereferencing
+     in determining the object to be modified.
+
+   - changes: A list of modifications to be performed on the entry.  The
+     entire list of modifications MUST be performed in the order they
+     are listed as a single atomic operation.  While individual
+     modifications may violate certain aspects of the directory schema
+     (such as the object class definition and Directory Information Tree
+     (DIT) content rule), the resulting entry after the entire list of
+     modifications is performed MUST conform to the requirements of the
+     directory model and controlling schema [RFC4512].
+
+     -  operation: Used to specify the type of modification being
+        performed.  Each operation type acts on the following
+        modification.  The values of this field have the following
+        semantics, respectively:
+
+           add: add values listed to the modification attribute,
+           creating the attribute if necessary.
+
+
+
+
+Sermersheim                 Standards Track                    [Page 31]
+
+RFC 4511                         LDAPv3                        June 2006
+
+
+           delete: delete values listed from the modification attribute.
+           If no values are listed, or if all current values of the
+           attribute are listed, the entire attribute is removed.
+
+           replace: replace all existing values of the modification
+           attribute with the new values listed, creating the attribute
+           if it did not already exist.  A replace with no value will
+           delete the entire attribute if it exists, and it is ignored
+           if the attribute does not exist.
+
+     -  modification: A PartialAttribute (which may have an empty SET
+        of vals) used to hold the attribute type or attribute type and
+        values being modified.
+
+   Upon receipt of a Modify Request, the server attempts to perform the
+   necessary modifications to the DIT and returns the result in a Modify
+   Response, defined as follows:
+
+        ModifyResponse ::= [APPLICATION 7] LDAPResult
+
+   The server will return to the client a single Modify Response
+   indicating either the successful completion of the DIT modification,
+   or the reason that the modification failed.  Due to the requirement
+   for atomicity in applying the list of modifications in the Modify
+   Request, the client may expect that no modifications of the DIT have
+   been performed if the Modify Response received indicates any sort of
+   error, and that all requested modifications have been performed if
+   the Modify Response indicates successful completion of the Modify
+   operation.  Whether or not the modification was applied cannot be
+   determined by the client if the Modify Response was not received
+   (e.g., the LDAP session was terminated or the Modify operation was
+   abandoned).
+
+   Servers MUST ensure that entries conform to user and system schema
+   rules or other data model constraints.  The Modify operation cannot
+   be used to remove from an entry any of its distinguished values,
+   i.e., those values which form the entry's relative distinguished
+   name.  An attempt to do so will result in the server returning the
+   notAllowedOnRDN result code.  The Modify DN operation described in
+   Section 4.9 is used to rename an entry.
+
+   For attribute types that specify no equality matching, the rules in
+   Section 2.5.1 of [RFC4512] are followed.
+
+   Note that due to the simplifications made in LDAP, there is not a
+   direct mapping of the changes in an LDAP ModifyRequest onto the
+   changes of a DAP ModifyEntry operation, and different implementations
+
+
+
+
+Sermersheim                 Standards Track                    [Page 32]
+
+RFC 4511                         LDAPv3                        June 2006
+
+
+   of LDAP-DAP gateways may use different means of representing the
+   change.  If successful, the final effect of the operations on the
+   entry MUST be identical.
+
+4.7.  Add Operation
+
+   The Add operation allows a client to request the addition of an entry
+   into the Directory.  The Add Request is defined as follows:
+
+        AddRequest ::= [APPLICATION 8] SEQUENCE {
+             entry           LDAPDN,
+             attributes      AttributeList }
+
+        AttributeList ::= SEQUENCE OF attribute Attribute
+
+   Fields of the Add Request are:
+
+   - entry: the name of the entry to be added.  The server SHALL NOT
+     dereference any aliases in locating the entry to be added.
+
+   - attributes: the list of attributes that, along with those from the
+     RDN, make up the content of the entry being added.  Clients MAY or
+     MAY NOT include the RDN attribute(s) in this list.  Clients MUST
+     NOT supply NO-USER-MODIFICATION attributes such as the
+     createTimestamp or creatorsName attributes, since the server
+     maintains these automatically.
+
+   Servers MUST ensure that entries conform to user and system schema
+   rules or other data model constraints.  For attribute types that
+   specify no equality matching, the rules in Section 2.5.1 of [RFC4512]
+   are followed (this applies to the naming attribute in addition to any
+   multi-valued attributes being added).
+
+   The entry named in the entry field of the AddRequest MUST NOT exist
+   for the AddRequest to succeed.  The immediate superior (parent) of an
+   object or alias entry to be added MUST exist.  For example, if the
+   client attempted to add <CN=JS,DC=Example,DC=NET>, the
+   <DC=Example,DC=NET> entry did not exist, and the <DC=NET> entry did
+   exist, then the server would return the noSuchObject result code with
+   the matchedDN field containing <DC=NET>.
+
+   Upon receipt of an Add Request, a server will attempt to add the
+   requested entry.  The result of the Add attempt will be returned to
+   the client in the Add Response, defined as follows:
+
+        AddResponse ::= [APPLICATION 9] LDAPResult
+
+
+
+
+
+Sermersheim                 Standards Track                    [Page 33]
+
+RFC 4511                         LDAPv3                        June 2006
+
+
+   A response of success indicates that the new entry has been added to
+   the Directory.
+
+4.8.  Delete Operation
+
+   The Delete operation allows a client to request the removal of an
+   entry from the Directory.  The Delete Request is defined as follows:
+
+        DelRequest ::= [APPLICATION 10] LDAPDN
+
+   The Delete Request consists of the name of the entry to be deleted.
+   The server SHALL NOT dereference aliases while resolving the name of
+   the target entry to be removed.
+
+   Only leaf entries (those with no subordinate entries) can be deleted
+   with this operation.
+
+   Upon receipt of a Delete Request, a server will attempt to perform
+   the entry removal requested and return the result in the Delete
+   Response defined as follows:
+
+        DelResponse ::= [APPLICATION 11] LDAPResult
+
+4.9.  Modify DN Operation
+
+   The Modify DN operation allows a client to change the Relative
+   Distinguished Name (RDN) of an entry in the Directory and/or to move
+   a subtree of entries to a new location in the Directory.  The Modify
+   DN Request is defined as follows:
+
+        ModifyDNRequest ::= [APPLICATION 12] SEQUENCE {
+             entry           LDAPDN,
+             newrdn          RelativeLDAPDN,
+             deleteoldrdn    BOOLEAN,
+             newSuperior     [0] LDAPDN OPTIONAL }
+
+   Fields of the Modify DN Request are:
+
+   - entry: the name of the entry to be changed.  This entry may or may
+     not have subordinate entries.
+
+   - newrdn: the new RDN of the entry.  The value of the old RDN is
+     supplied when moving the entry to a new superior without changing
+     its RDN.  Attribute values of the new RDN not matching any
+     attribute value of the entry are added to the entry, and an
+     appropriate error is returned if this fails.
+
+
+
+
+
+Sermersheim                 Standards Track                    [Page 34]
+
+RFC 4511                         LDAPv3                        June 2006
+
+
+   - deleteoldrdn: a boolean field that controls whether the old RDN
+     attribute values are to be retained as attributes of the entry or
+     deleted from the entry.
+
+   - newSuperior: if present, this is the name of an existing object
+     entry that becomes the immediate superior (parent) of the
+     existing entry.
+
+   The server SHALL NOT dereference any aliases in locating the objects
+   named in entry or newSuperior.
+
+   Upon receipt of a ModifyDNRequest, a server will attempt to perform
+   the name change and return the result in the Modify DN Response,
+   defined as follows:
+
+        ModifyDNResponse ::= [APPLICATION 13] LDAPResult
+
+   For example, if the entry named in the entry field was <cn=John
+   Smith,c=US>, the newrdn field was <cn=John Cougar Smith>, and the
+   newSuperior field was absent, then this operation would attempt to
+   rename the entry as <cn=John Cougar Smith,c=US>.  If there was
+   already an entry with that name, the operation would fail with the
+   entryAlreadyExists result code.
+
+   Servers MUST ensure that entries conform to user and system schema
+   rules or other data model constraints.  For attribute types that
+   specify no equality matching, the rules in Section 2.5.1 of [RFC4512]
+   are followed (this pertains to newrdn and deleteoldrdn).
+
+   The object named in newSuperior MUST exist.  For example, if the
+   client attempted to add <CN=JS,DC=Example,DC=NET>, the
+   <DC=Example,DC=NET> entry did not exist, and the <DC=NET> entry did
+   exist, then the server would return the noSuchObject result code with
+   the matchedDN field containing <DC=NET>.
+
+   If the deleteoldrdn field is TRUE, the attribute values forming the
+   old RDN (but not the new RDN) are deleted from the entry.  If the
+   deleteoldrdn field is FALSE, the attribute values forming the old RDN
+   will be retained as non-distinguished attribute values of the entry.
+
+   Note that X.500 restricts the ModifyDN operation to affect only
+   entries that are contained within a single server.  If the LDAP
+   server is mapped onto DAP, then this restriction will apply, and the
+   affectsMultipleDSAs result code will be returned if this error
+   occurred.  In general, clients MUST NOT expect to be able to perform
+   arbitrary movements of entries and subtrees between servers or
+   between naming contexts.
+
+
+
+
+Sermersheim                 Standards Track                    [Page 35]
+
+RFC 4511                         LDAPv3                        June 2006
+
+
+4.10.  Compare Operation
+
+   The Compare operation allows a client to compare an assertion value
+   with the values of a particular attribute in a particular entry in
+   the Directory.  The Compare Request is defined as follows:
+
+        CompareRequest ::= [APPLICATION 14] SEQUENCE {
+             entry           LDAPDN,
+             ava             AttributeValueAssertion }
+
+   Fields of the Compare Request are:
+
+   - entry: the name of the entry to be compared.  The server SHALL NOT
+     dereference any aliases in locating the entry to be compared.
+
+   - ava: holds the attribute value assertion to be compared.
+
+   Upon receipt of a Compare Request, a server will attempt to perform
+   the requested comparison and return the result in the Compare
+   Response, defined as follows:
+
+        CompareResponse ::= [APPLICATION 15] LDAPResult
+
+   The resultCode is set to compareTrue, compareFalse, or an appropriate
+   error.  compareTrue indicates that the assertion value in the ava
+   field matches a value of the attribute or subtype according to the
+   attribute's EQUALITY matching rule.  compareFalse indicates that the
+   assertion value in the ava field and the values of the attribute or
+   subtype did not match.  Other result codes indicate either that the
+   result of the comparison was Undefined (Section 4.5.1.7), or that
+   some error occurred.
+
+   Note that some directory systems may establish access controls that
+   permit the values of certain attributes (such as userPassword) to be
+   compared but not interrogated by other means.
+
+4.11.  Abandon Operation
+
+   The function of the Abandon operation is to allow a client to request
+   that the server abandon an uncompleted operation.  The Abandon
+   Request is defined as follows:
+
+        AbandonRequest ::= [APPLICATION 16] MessageID
+
+   The MessageID is that of an operation that was requested earlier at
+   this LDAP message layer.  The Abandon request itself has its own
+   MessageID.  This is distinct from the MessageID of the earlier
+   operation being abandoned.
+
+
+
+Sermersheim                 Standards Track                    [Page 36]
+
+RFC 4511                         LDAPv3                        June 2006
+
+
+   There is no response defined in the Abandon operation.  Upon receipt
+   of an AbandonRequest, the server MAY abandon the operation identified
+   by the MessageID.  Since the client cannot tell the difference
+   between a successfully abandoned operation and an uncompleted
+   operation, the application of the Abandon operation is limited to
+   uses where the client does not require an indication of its outcome.
+
+   Abandon, Bind, Unbind, and StartTLS operations cannot be abandoned.
+
+   In the event that a server receives an Abandon Request on a Search
+   operation in the midst of transmitting responses to the Search, that
+   server MUST cease transmitting entry responses to the abandoned
+   request immediately, and it MUST NOT send the SearchResultDone.  Of
+   course, the server MUST ensure that only properly encoded LDAPMessage
+   PDUs are transmitted.
+
+   The ability to abandon other (particularly update) operations is at
+   the discretion of the server.
+
+   Clients should not send Abandon requests for the same operation
+   multiple times, and they MUST also be prepared to receive results
+   from operations they have abandoned (since these might have been in
+   transit when the Abandon was requested or might not be able to be
+   abandoned).
+
+   Servers MUST discard Abandon requests for messageIDs they do not
+   recognize, for operations that cannot be abandoned, and for
+   operations that have already been abandoned.
+
+4.12.  Extended Operation
+
+   The Extended operation allows additional operations to be defined for
+   services not already available in the protocol; for example, to Add
+   operations to install transport layer security (see Section 4.14).
+
+   The Extended operation allows clients to make requests and receive
+   responses with predefined syntaxes and semantics.  These may be
+   defined in RFCs or be private to particular implementations.
+
+   Each Extended operation consists of an Extended request and an
+   Extended response.
+
+        ExtendedRequest ::= [APPLICATION 23] SEQUENCE {
+             requestName      [0] LDAPOID,
+             requestValue     [1] OCTET STRING OPTIONAL }
+
+
+
+
+
+
+Sermersheim                 Standards Track                    [Page 37]
+
+RFC 4511                         LDAPv3                        June 2006
+
+
+   The requestName is a dotted-decimal representation of the unique
+   OBJECT IDENTIFIER corresponding to the request.  The requestValue is
+   information in a form defined by that request, encapsulated inside an
+   OCTET STRING.
+
+   The server will respond to this with an LDAPMessage containing an
+   ExtendedResponse.
+
+        ExtendedResponse ::= [APPLICATION 24] SEQUENCE {
+             COMPONENTS OF LDAPResult,
+             responseName     [10] LDAPOID OPTIONAL,
+             responseValue    [11] OCTET STRING OPTIONAL }
+
+   The responseName field, when present, contains an LDAPOID that is
+   unique for this extended operation or response.  This field is
+   optional (even when the extension specification defines an LDAPOID
+   for use in this field).  The field will be absent whenever the server
+   is unable or unwilling to determine the appropriate LDAPOID to
+   return, for instance, when the requestName cannot be parsed or its
+   value is not recognized.
+
+   Where the requestName is not recognized, the server returns
+   protocolError.  (The server may return protocolError in other cases.)
+
+   The requestValue and responseValue fields contain information
+   associated with the operation.  The format of these fields is defined
+   by the specification of the Extended operation.  Implementations MUST
+   be prepared to handle arbitrary contents of these fields, including
+   zero bytes.  Values that are defined in terms of ASN.1 and BER-
+   encoded according to Section 5.1 also follow the extensibility rules
+   in Section 4.
+
+   Servers list the requestName of Extended Requests they recognize in
+   the 'supportedExtension' attribute in the root DSE (Section 5.1 of
+   [RFC4512]).
+
+   Extended operations may be specified in other documents.  The
+   specification of an Extended operation consists of:
+
+   - the OBJECT IDENTIFIER assigned to the requestName,
+
+   - the OBJECT IDENTIFIER (if any) assigned to the responseName (note
+     that the same OBJECT IDENTIFIER may be used for both the
+     requestName and responseName),
+
+
+
+
+
+
+
+Sermersheim                 Standards Track                    [Page 38]
+
+RFC 4511                         LDAPv3                        June 2006
+
+
+   - the format of the contents of the requestValue and responseValue
+     (if any), and
+
+   - the semantics of the operation.
+
+4.13.  IntermediateResponse Message
+
+   While the Search operation provides a mechanism to return multiple
+   response messages for a single Search request, other operations, by
+   nature, do not provide for multiple response messages.
+
+   The IntermediateResponse message provides a general mechanism for
+   defining single-request/multiple-response operations in LDAP.  This
+   message is intended to be used in conjunction with the Extended
+   operation to define new single-request/multiple-response operations
+   or in conjunction with a control when extending existing LDAP
+   operations in a way that requires them to return Intermediate
+   response information.
+
+   It is intended that the definitions and descriptions of Extended
+   operations and controls that make use of the IntermediateResponse
+   message will define the circumstances when an IntermediateResponse
+   message can be sent by a server and the associated meaning of an
+   IntermediateResponse message sent in a particular circumstance.
+
+        IntermediateResponse ::= [APPLICATION 25] SEQUENCE {
+                responseName     [0] LDAPOID OPTIONAL,
+                responseValue    [1] OCTET STRING OPTIONAL }
+
+   IntermediateResponse messages SHALL NOT be returned to the client
+   unless the client issues a request that specifically solicits their
+   return.  This document defines two forms of solicitation: Extended
+   operation and request control.  IntermediateResponse messages are
+   specified in documents describing the manner in which they are
+   solicited (i.e., in the Extended operation or request control
+   specification that uses them).  These specifications include:
+
+   - the OBJECT IDENTIFIER (if any) assigned to the responseName,
+
+   - the format of the contents of the responseValue (if any), and
+
+   - the semantics associated with the IntermediateResponse message.
+
+   Extensions that allow the return of multiple types of
+   IntermediateResponse messages SHALL identify those types using unique
+   responseName values (note that one of these may specify no value).
+
+
+
+
+
+Sermersheim                 Standards Track                    [Page 39]
+
+RFC 4511                         LDAPv3                        June 2006
+
+
+   Sections 4.13.1 and 4.13.2 describe additional requirements on the
+   inclusion of responseName and responseValue in IntermediateResponse
+   messages.
+
+4.13.1.  Usage with LDAP ExtendedRequest and ExtendedResponse
+
+   A single-request/multiple-response operation may be defined using a
+   single ExtendedRequest message to solicit zero or more
+   IntermediateResponse messages of one or more kinds, followed by an
+   ExtendedResponse message.
+
+4.13.2.  Usage with LDAP Request Controls
+
+   A control's semantics may include the return of zero or more
+   IntermediateResponse messages prior to returning the final result
+   code for the operation.  One or more kinds of IntermediateResponse
+   messages may be sent in response to a request control.
+
+   All IntermediateResponse messages associated with request controls
+   SHALL include a responseName.  This requirement ensures that the
+   client can correctly identify the source of IntermediateResponse
+   messages when:
+
+   - two or more controls using IntermediateResponse messages are
+     included in a request for any LDAP operation or
+
+   - one or more controls using IntermediateResponse messages are
+     included in a request with an LDAP Extended operation that uses
+     IntermediateResponse messages.
+
+4.14.  StartTLS Operation
+
+   The Start Transport Layer Security (StartTLS) operation's purpose is
+   to initiate installation of a TLS layer.  The StartTLS operation is
+   defined using the Extended operation mechanism described in Section
+   4.12.
+
+4.14.1.  StartTLS Request
+
+   A client requests TLS establishment by transmitting a StartTLS
+   request message to the server.  The StartTLS request is defined in
+   terms of an ExtendedRequest.  The requestName is
+   "1.3.6.1.4.1.1466.20037", and the requestValue field is always
+   absent.
+
+
+
+
+
+
+
+Sermersheim                 Standards Track                    [Page 40]
+
+RFC 4511                         LDAPv3                        June 2006
+
+
+   The client MUST NOT send any LDAP PDUs at this LDAP message layer
+   following this request until it receives a StartTLS Extended response
+   and, in the case of a successful response, completes TLS
+   negotiations.
+
+   Detected sequencing problems (particularly those detailed in Section
+   3.1.1 of [RFC4513]) result in the resultCode being set to
+   operationsError.
+
+   If the server does not support TLS (whether by design or by current
+   configuration), it returns with the resultCode set to protocolError
+   as described in Section 4.12.
+
+4.14.2.  StartTLS Response
+
+   When a StartTLS request is received, servers supporting the operation
+   MUST return a StartTLS response message to the requestor.  The
+   responseName is "1.3.6.1.4.1.1466.20037" when provided (see Section
+   4.12).  The responseValue is always absent.
+
+   If the server is willing and able to negotiate TLS, it returns the
+   StartTLS response with the resultCode set to success.  Upon client
+   receipt of a successful StartTLS response, protocol peers may
+   commence with TLS negotiation as discussed in Section 3 of [RFC4513].
+
+   If the server is otherwise unwilling or unable to perform this
+   operation, the server is to return an appropriate result code
+   indicating the nature of the problem.  For example, if the TLS
+   subsystem is not presently available, the server may indicate this by
+   returning with the resultCode set to unavailable.  In cases where a
+   non-success result code is returned, the LDAP session is left without
+   a TLS layer.
+
+4.14.3.  Removal of the TLS Layer
+
+   Either the client or server MAY remove the TLS layer and leave the
+   LDAP message layer intact by sending and receiving a TLS closure
+   alert.
+
+   The initiating protocol peer sends the TLS closure alert and MUST
+   wait until it receives a TLS closure alert from the other peer before
+   sending further LDAP PDUs.
+
+   When a protocol peer receives the initial TLS closure alert, it may
+   choose to allow the LDAP message layer to remain intact.  In this
+   case, it MUST immediately transmit a TLS closure alert.  Following
+   this, it MAY send and receive LDAP PDUs.
+
+
+
+
+Sermersheim                 Standards Track                    [Page 41]
+
+RFC 4511                         LDAPv3                        June 2006
+
+
+   Protocol peers MAY terminate the LDAP session after sending or
+   receiving a TLS closure alert.
+
+5.  Protocol Encoding, Connection, and Transfer
+
+   This protocol is designed to run over connection-oriented, reliable
+   transports, where the data stream is divided into octets (8-bit
+   units), with each octet and each bit being significant.
+
+   One underlying service, LDAP over TCP, is defined in Section 5.2.
+   This service is generally applicable to applications providing or
+   consuming X.500-based directory services on the Internet.  This
+   specification was generally written with the TCP mapping in mind.
+   Specifications detailing other mappings may encounter various
+   obstacles.
+
+   Implementations of LDAP over TCP MUST implement the mapping as
+   described in Section 5.2.
+
+   This table illustrates the relationship among the different layers
+   involved in an exchange between two protocol peers:
+
+               +----------------------+
+               |  LDAP message layer  |
+               +----------------------+ > LDAP PDUs
+               +----------------------+ < data
+               |      SASL layer      |
+               +----------------------+ > SASL-protected data
+               +----------------------+ < data
+               |       TLS layer      |
+   Application +----------------------+ > TLS-protected data
+   ------------+----------------------+ < data
+     Transport | transport connection |
+               +----------------------+
+
+5.1.  Protocol Encoding
+
+   The protocol elements of LDAP SHALL be encoded for exchange using the
+   Basic Encoding Rules [BER] of [ASN.1] with the following
+   restrictions:
+
+   - Only the definite form of length encoding is used.
+
+   - OCTET STRING values are encoded in the primitive form only.
+
+   - If the value of a BOOLEAN type is true, the encoding of the value
+     octet is set to hex "FF".
+
+
+
+
+Sermersheim                 Standards Track                    [Page 42]
+
+RFC 4511                         LDAPv3                        June 2006
+
+
+   - If a value of a type is its default value, it is absent.  Only some
+     BOOLEAN and INTEGER types have default values in this protocol
+     definition.
+
+   These restrictions are meant to ease the overhead of encoding and
+   decoding certain elements in BER.
+
+   These restrictions do not apply to ASN.1 types encapsulated inside of
+   OCTET STRING values, such as attribute values, unless otherwise
+   stated.
+
+5.2.  Transmission Control Protocol (TCP)
+
+   The encoded LDAPMessage PDUs are mapped directly onto the TCP
+   [RFC793] bytestream using the BER-based encoding described in Section
+   5.1.  It is recommended that server implementations running over the
+   TCP provide a protocol listener on the Internet Assigned Numbers
+   Authority (IANA)-assigned LDAP port, 389 [PortReg].  Servers may
+   instead provide a listener on a different port number.  Clients MUST
+   support contacting servers on any valid TCP port.
+
+5.3.  Termination of the LDAP session
+
+   Termination of the LDAP session is typically initiated by the client
+   sending an UnbindRequest (Section 4.3), or by the server sending a
+   Notice of Disconnection (Section 4.4.1).  In these cases, each
+   protocol peer gracefully terminates the LDAP session by ceasing
+   exchanges at the LDAP message layer, tearing down any SASL layer,
+   tearing down any TLS layer, and closing the transport connection.
+
+   A protocol peer may determine that the continuation of any
+   communication would be pernicious, and in this case, it may abruptly
+   terminate the session by ceasing communication and closing the
+   transport connection.
+
+   In either case, when the LDAP session is terminated, uncompleted
+   operations are handled as specified in Section 3.1.
+
+6.  Security Considerations
+
+   This version of the protocol provides facilities for simple
+   authentication using a cleartext password, as well as any SASL
+   [RFC4422] mechanism.  Installing SASL and/or TLS layers can provide
+   integrity and other data security services.
+
+   It is also permitted that the server can return its credentials to
+   the client, if it chooses to do so.
+
+
+
+
+Sermersheim                 Standards Track                    [Page 43]
+
+RFC 4511                         LDAPv3                        June 2006
+
+
+   Use of cleartext password is strongly discouraged where the
+   underlying transport service cannot guarantee confidentiality and may
+   result in disclosure of the password to unauthorized parties.
+
+   Servers are encouraged to prevent directory modifications by clients
+   that have authenticated anonymously [RFC4513].
+
+   Security considerations for authentication methods, SASL mechanisms,
+   and TLS are described in [RFC4513].
+
+   Note that SASL authentication exchanges do not provide data
+   confidentiality or integrity protection for the version or name
+   fields of the BindRequest or the resultCode, diagnosticMessage, or
+   referral fields of the BindResponse, nor for any information
+   contained in controls attached to Bind requests or responses.  Thus,
+   information contained in these fields SHOULD NOT be relied on unless
+   it is otherwise protected (such as by establishing protections at the
+   transport layer).
+
+   Implementors should note that various security factors (including
+   authentication and authorization information and data security
+   services) may change during the course of the LDAP session or even
+   during the performance of a particular operation.  For instance,
+   credentials could expire, authorization identities or access controls
+   could change, or the underlying security layer(s) could be replaced
+   or terminated.  Implementations should be robust in the handling of
+   changing security factors.
+
+   In some cases, it may be appropriate to continue the operation even
+   in light of security factor changes.  For instance, it may be
+   appropriate to continue an Abandon operation regardless of the
+   change, or to continue an operation when the change upgraded (or
+   maintained) the security factor.  In other cases, it may be
+   appropriate to fail or alter the processing of the operation.  For
+   instance, if confidential protections were removed, it would be
+   appropriate either to fail a request to return sensitive data or,
+   minimally, to exclude the return of sensitive data.
+
+   Implementations that cache attributes and entries obtained via LDAP
+   MUST ensure that access controls are maintained if that information
+   is to be provided to multiple clients, since servers may have access
+   control policies that prevent the return of entries or attributes in
+   Search results except to particular authenticated clients.  For
+   example, caches could serve result information only to the client
+   whose request caused it to be in the cache.
+
+
+
+
+
+
+Sermersheim                 Standards Track                    [Page 44]
+
+RFC 4511                         LDAPv3                        June 2006
+
+
+   Servers may return referrals or Search result references that
+   redirect clients to peer servers.  It is possible for a rogue
+   application to inject such referrals into the data stream in an
+   attempt to redirect a client to a rogue server.  Clients are advised
+   to be aware of this and possibly reject referrals when
+   confidentiality measures are not in place.  Clients are advised to
+   reject referrals from the StartTLS operation.
+
+   The matchedDN and diagnosticMessage fields, as well as some
+   resultCode values (e.g., attributeOrValueExists and
+   entryAlreadyExists), could disclose the presence or absence of
+   specific data in the directory that is subject to access and other
+   administrative controls.  Server implementations should restrict
+   access to protected information equally under both normal and error
+   conditions.
+
+   Protocol peers MUST be prepared to handle invalid and arbitrary-
+   length protocol encodings.  Invalid protocol encodings include: BER
+   encoding exceptions, format string and UTF-8 encoding exceptions,
+   overflow exceptions, integer value exceptions, and binary mode on/off
+   flag exceptions.  The LDAPv3 PROTOS [PROTOS-LDAP] test suite provides
+   excellent examples of these exceptions and test cases used to
+   discover flaws.
+
+   In the event that a protocol peer senses an attack that in its nature
+   could cause damage due to further communication at any layer in the
+   LDAP session, the protocol peer should abruptly terminate the LDAP
+   session as described in Section 5.3.
+
+7.  Acknowledgements
+
+   This document is based on RFC 2251 by Mark Wahl, Tim Howes, and Steve
+   Kille.  RFC 2251 was a product of the IETF ASID Working Group.
+
+   It is also based on RFC 2830 by Jeff Hodges, RL "Bob" Morgan, and
+   Mark Wahl.  RFC 2830 was a product of the IETF LDAPEXT Working Group.
+
+   It is also based on RFC 3771 by Roger Harrison and Kurt Zeilenga.
+   RFC 3771 was an individual submission to the IETF.
+
+   This document is a product of the IETF LDAPBIS Working Group.
+   Significant contributors of technical review and content include Kurt
+   Zeilenga, Steven Legg, and Hallvard Furuseth.
+
+
+
+
+
+
+
+
+Sermersheim                 Standards Track                    [Page 45]
+
+RFC 4511                         LDAPv3                        June 2006
+
+
+8.  Normative References
+
+   [ASN.1]       ITU-T Recommendation X.680 (07/2002) | ISO/IEC 8824-
+                 1:2002 "Information Technology - Abstract Syntax
+                 Notation One (ASN.1): Specification of basic notation".
+
+   [BER]         ITU-T Rec. X.690 (07/2002) | ISO/IEC 8825-1:2002,
+                 "Information technology - ASN.1 encoding rules:
+                 Specification of Basic Encoding Rules (BER), Canonical
+                 Encoding Rules (CER) and Distinguished Encoding Rules
+                 (DER)", 2002.
+
+   [ISO10646]    Universal Multiple-Octet Coded Character Set (UCS) -
+                 Architecture and Basic Multilingual Plane, ISO/IEC
+                 10646-1 : 1993.
+
+   [RFC791]      Postel, J., "Internet Protocol", STD 5, RFC 791,
+                 September 1981.
+
+   [RFC793]      Postel, J., "Transmission Control Protocol", STD 7, RFC
+                 793, September 1981.
+
+   [RFC2119]     Bradner, S., "Key words for use in RFCs to Indicate
+                 Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC3454]     Hoffman P. and M. Blanchet, "Preparation of
+                 Internationalized Strings ('stringprep')", RFC 3454,
+                 December 2002.
+
+   [RFC3629]     Yergeau, F., "UTF-8, a transformation format of ISO
+                 10646", STD 63, RFC 3629, November 2003.
+
+   [RFC3986]     Berners-Lee, T., Fielding, R., and L. Masinter,
+                 "Uniform Resource Identifier (URI): Generic Syntax",
+                 STD 66, RFC 3986, January 2005.
+
+   [RFC4013]     Zeilenga, K., "SASLprep: Stringprep Profile for User
+                 Names and Passwords", RFC 4013, February 2005.
+
+   [RFC4234]     Crocker, D. and P. Overell, "Augmented BNF for Syntax
+                 Specifications: ABNF", RFC 4234, October 2005.
+
+   [RFC4346]     Dierks, T. and E. Rescorla, "The TLS Protocol Version
+                 1.1", RFC 4346, March 2006.
+
+   [RFC4422]     Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple
+                 Authentication and Security Layer (SASL)", RFC 4422,
+                 June 2006.
+
+
+
+Sermersheim                 Standards Track                    [Page 46]
+
+RFC 4511                         LDAPv3                        June 2006
+
+
+   [RFC4510]     Zeilenga, K., Ed., "Lightweight Directory Access
+                 Protocol (LDAP): Technical Specification Road Map", RFC
+                 4510, June 2006.
+
+   [RFC4512]     Zeilenga, K., Lightweight Directory Access Protocol
+                 (LDAP): Directory Information Models", RFC 4512, June
+                 2006.
+
+   [RFC4513]     Harrison, R., Ed., "Lightweight Directory Access
+                 Protocol (LDAP): Authentication Methods and Security
+                 Mechanisms", RFC 4513, June 2006.
+
+   [RFC4514]     Zeilenga, K., Ed., "Lightweight Directory Access
+                 Protocol (LDAP): String Representation of Distinguished
+                 Names", RFC 4514, June 2006.
+
+   [RFC4516]     Smith, M., Ed. and T. Howes, "Lightweight Directory
+                 Access Protocol (LDAP): Uniform Resource Locator", RFC
+                 4516, June 2006.
+
+   [RFC4517]     Legg, S., Ed., "Lightweight Directory Access Protocol
+                 (LDAP): Syntaxes and Matching Rules", RFC 4517, June
+                 2006.
+
+   [RFC4520]     Zeilenga, K., "Internet Assigned Numbers Authority
+                 (IANA) Considerations for the Lightweight Directory
+                 Access Protocol (LDAP)", BCP 64, RFC 4520, June 2006.
+
+   [Unicode]     The Unicode Consortium, "The Unicode Standard, Version
+                 3.2.0" is defined by "The Unicode Standard, Version
+                 3.0" (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-
+                 61633-5), as amended by the "Unicode Standard Annex
+                 #27: Unicode 3.1"
+                 (http://www.unicode.org/reports/tr27/) and by the
+                 "Unicode Standard Annex #28: Unicode 3.2"
+                 (http://www.unicode.org/reports/tr28/).
+
+   [X.500]       ITU-T Rec. X.500, "The Directory: Overview of Concepts,
+                 Models and Service", 1993.
+
+   [X.511]       ITU-T Rec. X.511, "The Directory: Abstract Service
+                 Definition", 1993.
+
+
+
+
+
+
+
+
+
+Sermersheim                 Standards Track                    [Page 47]
+
+RFC 4511                         LDAPv3                        June 2006
+
+
+9.  Informative References
+
+   [CharModel]   Whistler, K. and M. Davis, "Unicode Technical Report
+                 #17, Character Encoding Model", UTR17,
+                 <http://www.unicode.org/unicode/reports/tr17/>, August
+                 2000.
+
+   [Glossary]    The Unicode Consortium, "Unicode Glossary",
+                 <http://www.unicode.org/glossary/>.
+
+   [PortReg]     IANA, "Port Numbers",
+                 <http://www.iana.org/assignments/port-numbers>.
+
+   [PROTOS-LDAP] University of Oulu, "PROTOS Test-Suite: c06-ldapv3"
+                 <http://www.ee.oulu.fi/research/ouspg/protos/testing/
+                 c06/ldapv3/>.
+
+10.  IANA Considerations
+
+   The Internet Assigned Numbers Authority (IANA) has updated the LDAP
+   result code registry to indicate that this document provides the
+   definitive technical specification for result codes 0-36, 48-54, 64-
+   70, 80-90.  It is also noted that one resultCode value
+   (strongAuthRequired) has been renamed (to strongerAuthRequired).
+
+   The IANA has also updated the LDAP Protocol Mechanism registry to
+   indicate that this document and [RFC4513] provides the definitive
+   technical specification for the StartTLS (1.3.6.1.4.1.1466.20037)
+   Extended operation.
+
+   IANA has assigned LDAP Object Identifier 18 [RFC4520] to identify the
+   ASN.1 module defined in this document.
+
+        Subject: Request for LDAP Object Identifier Registration
+        Person & email address to contact for further information:
+             Jim Sermersheim <jimse@novell.com>
+        Specification: RFC 4511
+        Author/Change Controller: IESG
+        Comments:
+             Identifies the LDAP ASN.1 module
+
+
+
+
+
+
+
+
+
+
+
+Sermersheim                 Standards Track                    [Page 48]
+
+RFC 4511                         LDAPv3                        June 2006
+
+
+Appendix A.  LDAP Result Codes
+
+   This normative appendix details additional considerations regarding
+   LDAP result codes and provides a brief, general description of each
+   LDAP result code enumerated in Section 4.1.9.
+
+   Additional result codes MAY be defined for use with extensions
+   [RFC4520].  Client implementations SHALL treat any result code that
+   they do not recognize as an unknown error condition.
+
+   The descriptions provided here do not fully account for result code
+   substitutions used to prevent unauthorized disclosures (such as
+   substitution of noSuchObject for insufficientAccessRights, or
+   invalidCredentials for insufficientAccessRights).
+
+A.1.  Non-Error Result Codes
+
+   These result codes (called "non-error" result codes) do not indicate
+   an error condition:
+
+        success (0),
+        compareFalse (5),
+        compareTrue (6),
+        referral (10), and
+        saslBindInProgress (14).
+
+   The success, compareTrue, and compareFalse result codes indicate
+   successful completion (and, hence, are referred to as "successful"
+   result codes).
+
+   The referral and saslBindInProgress result codes indicate the client
+   needs to take additional action to complete the operation.
+
+A.2.  Result Codes
+
+   Existing LDAP result codes are described as follows:
+
+      success (0)
+         Indicates the successful completion of an operation.  Note:
+         this code is not used with the Compare operation.  See
+         compareFalse (5) and compareTrue (6).
+
+
+
+
+
+
+
+
+
+
+Sermersheim                 Standards Track                    [Page 49]
+
+RFC 4511                         LDAPv3                        June 2006
+
+
+      operationsError (1)
+         Indicates that the operation is not properly sequenced with
+         relation to other operations (of same or different type).
+
+         For example, this code is returned if the client attempts to
+         StartTLS [RFC4346] while there are other uncompleted operations
+         or if a TLS layer was already installed.
+
+      protocolError (2)
+         Indicates the server received data that is not well-formed.
+
+         For Bind operation only, this code is also used to indicate
+         that the server does not support the requested protocol
+         version.
+
+         For Extended operations only, this code is also used to
+         indicate that the server does not support (by design or
+         configuration) the Extended operation associated with the
+         requestName.
+
+         For request operations specifying multiple controls, this may
+         be used to indicate that the server cannot ignore the order
+         of the controls as specified, or that the combination of the
+         specified controls is invalid or unspecified.
+
+      timeLimitExceeded (3)
+         Indicates that the time limit specified by the client was
+         exceeded before the operation could be completed.
+
+      sizeLimitExceeded (4)
+         Indicates that the size limit specified by the client was
+         exceeded before the operation could be completed.
+
+      compareFalse (5)
+         Indicates that the Compare operation has successfully
+         completed and the assertion has evaluated to FALSE or
+         Undefined.
+
+      compareTrue (6)
+         Indicates that the Compare operation has successfully
+         completed and the assertion has evaluated to TRUE.
+
+      authMethodNotSupported (7)
+         Indicates that the authentication method or mechanism is not
+         supported.
+
+
+
+
+
+
+Sermersheim                 Standards Track                    [Page 50]
+
+RFC 4511                         LDAPv3                        June 2006
+
+
+      strongerAuthRequired (8)
+         Indicates the server requires strong(er) authentication in
+         order to complete the operation.
+
+         When used with the Notice of Disconnection operation, this
+         code indicates that the server has detected that an
+         established security association between the client and
+         server has unexpectedly failed or been compromised.
+
+      referral (10)
+         Indicates that a referral needs to be chased to complete the
+         operation (see Section 4.1.10).
+
+      adminLimitExceeded (11)
+         Indicates that an administrative limit has been exceeded.
+
+      unavailableCriticalExtension (12)
+         Indicates a critical control is unrecognized (see Section
+         4.1.11).
+
+      confidentialityRequired (13)
+         Indicates that data confidentiality protections are required.
+
+      saslBindInProgress (14)
+         Indicates the server requires the client to send a new bind
+         request, with the same SASL mechanism, to continue the
+         authentication process (see Section 4.2).
+
+      noSuchAttribute (16)
+         Indicates that the named entry does not contain the specified
+         attribute or attribute value.
+
+      undefinedAttributeType (17)
+         Indicates that a request field contains an unrecognized
+         attribute description.
+
+      inappropriateMatching (18)
+         Indicates that an attempt was made (e.g., in an assertion) to
+         use a matching rule not defined for the attribute type
+         concerned.
+
+      constraintViolation (19)
+         Indicates that the client supplied an attribute value that
+         does not conform to the constraints placed upon it by the
+         data model.
+
+         For example, this code is returned when multiple values are
+         supplied to an attribute that has a SINGLE-VALUE constraint.
+
+
+
+Sermersheim                 Standards Track                    [Page 51]
+
+RFC 4511                         LDAPv3                        June 2006
+
+
+      attributeOrValueExists (20)
+         Indicates that the client supplied an attribute or value to
+         be added to an entry, but the attribute or value already
+         exists.
+
+      invalidAttributeSyntax (21)
+         Indicates that a purported attribute value does not conform
+         to the syntax of the attribute.
+
+      noSuchObject (32)
+         Indicates that the object does not exist in the DIT.
+
+      aliasProblem (33)
+         Indicates that an alias problem has occurred.  For example,
+         the code may used to indicate an alias has been dereferenced
+         that names no object.
+
+      invalidDNSyntax (34)
+         Indicates that an LDAPDN or RelativeLDAPDN field (e.g., search
+         base, target entry, ModifyDN newrdn, etc.) of a request does
+         not conform to the required syntax or contains attribute
+         values that do not conform to the syntax of the attribute's
+         type.
+
+      aliasDereferencingProblem (36)
+         Indicates that a problem occurred while dereferencing an
+         alias.  Typically, an alias was encountered in a situation
+         where it was not allowed or where access was denied.
+
+      inappropriateAuthentication (48)
+         Indicates the server requires the client that had attempted
+         to bind anonymously or without supplying credentials to
+         provide some form of credentials.
+
+      invalidCredentials (49)
+         Indicates that the provided credentials (e.g., the user's name
+         and password) are invalid.
+
+      insufficientAccessRights (50)
+         Indicates that the client does not have sufficient access
+         rights to perform the operation.
+
+      busy (51)
+         Indicates that the server is too busy to service the
+         operation.
+
+
+
+
+
+
+Sermersheim                 Standards Track                    [Page 52]
+
+RFC 4511                         LDAPv3                        June 2006
+
+
+      unavailable (52)
+         Indicates that the server is shutting down or a subsystem
+         necessary to complete the operation is offline.
+
+      unwillingToPerform (53)
+         Indicates that the server is unwilling to perform the
+         operation.
+
+      loopDetect (54)
+         Indicates that the server has detected an internal loop (e.g.,
+         while dereferencing aliases or chaining an operation).
+
+      namingViolation (64)
+         Indicates that the entry's name violates naming restrictions.
+
+      objectClassViolation (65)
+         Indicates that the entry violates object class restrictions.
+
+      notAllowedOnNonLeaf (66)
+         Indicates that the operation is inappropriately acting upon a
+         non-leaf entry.
+
+      notAllowedOnRDN (67)
+         Indicates that the operation is inappropriately attempting to
+         remove a value that forms the entry's relative distinguished
+         name.
+
+      entryAlreadyExists (68)
+         Indicates that the request cannot be fulfilled (added, moved,
+         or renamed) as the target entry already exists.
+
+      objectClassModsProhibited (69)
+         Indicates that an attempt to modify the object class(es) of
+         an entry's 'objectClass' attribute is prohibited.
+
+         For example, this code is returned when a client attempts to
+         modify the structural object class of an entry.
+
+      affectsMultipleDSAs (71)
+         Indicates that the operation cannot be performed as it would
+         affect multiple servers (DSAs).
+
+      other (80)
+         Indicates the server has encountered an internal error.
+
+
+
+
+
+
+
+Sermersheim                 Standards Track                    [Page 53]
+
+RFC 4511                         LDAPv3                        June 2006
+
+
+Appendix B.  Complete ASN.1 Definition
+
+   This appendix is normative.
+
+        Lightweight-Directory-Access-Protocol-V3 {1 3 6 1 1 18}
+        -- Copyright (C) The Internet Society (2006).  This version of
+        -- this ASN.1 module is part of RFC 4511; see the RFC itself
+        -- for full legal notices.
+        DEFINITIONS
+        IMPLICIT TAGS
+        EXTENSIBILITY IMPLIED ::=
+
+        BEGIN
+
+        LDAPMessage ::= SEQUENCE {
+             messageID       MessageID,
+             protocolOp      CHOICE {
+                  bindRequest           BindRequest,
+                  bindResponse          BindResponse,
+                  unbindRequest         UnbindRequest,
+                  searchRequest         SearchRequest,
+                  searchResEntry        SearchResultEntry,
+                  searchResDone         SearchResultDone,
+                  searchResRef          SearchResultReference,
+                  modifyRequest         ModifyRequest,
+                  modifyResponse        ModifyResponse,
+                  addRequest            AddRequest,
+                  addResponse           AddResponse,
+                  delRequest            DelRequest,
+                  delResponse           DelResponse,
+                  modDNRequest          ModifyDNRequest,
+                  modDNResponse         ModifyDNResponse,
+                  compareRequest        CompareRequest,
+                  compareResponse       CompareResponse,
+                  abandonRequest        AbandonRequest,
+                  extendedReq           ExtendedRequest,
+                  extendedResp          ExtendedResponse,
+                  ...,
+                  intermediateResponse  IntermediateResponse },
+             controls       [0] Controls OPTIONAL }
+
+        MessageID ::= INTEGER (0 ..  maxInt)
+
+        maxInt INTEGER ::= 2147483647 -- (2^^31 - 1) --
+
+        LDAPString ::= OCTET STRING -- UTF-8 encoded,
+                                    -- [ISO10646] characters
+
+
+
+
+Sermersheim                 Standards Track                    [Page 54]
+
+RFC 4511                         LDAPv3                        June 2006
+
+
+        LDAPOID ::= OCTET STRING -- Constrained to <numericoid>
+                                 -- [RFC4512]
+
+        LDAPDN ::= LDAPString -- Constrained to <distinguishedName>
+                              -- [RFC4514]
+
+        RelativeLDAPDN ::= LDAPString -- Constrained to <name-component>
+                                      -- [RFC4514]
+
+        AttributeDescription ::= LDAPString
+                                -- Constrained to <attributedescription>
+                                -- [RFC4512]
+
+        AttributeValue ::= OCTET STRING
+
+        AttributeValueAssertion ::= SEQUENCE {
+             attributeDesc   AttributeDescription,
+             assertionValue  AssertionValue }
+
+        AssertionValue ::= OCTET STRING
+
+        PartialAttribute ::= SEQUENCE {
+             type       AttributeDescription,
+             vals       SET OF value AttributeValue }
+
+        Attribute ::= PartialAttribute(WITH COMPONENTS {
+             ...,
+             vals (SIZE(1..MAX))})
+
+        MatchingRuleId ::= LDAPString
+
+        LDAPResult ::= SEQUENCE {
+             resultCode         ENUMERATED {
+                  success                      (0),
+                  operationsError              (1),
+                  protocolError                (2),
+                  timeLimitExceeded            (3),
+                  sizeLimitExceeded            (4),
+                  compareFalse                 (5),
+                  compareTrue                  (6),
+                  authMethodNotSupported       (7),
+                  strongerAuthRequired         (8),
+                       -- 9 reserved --
+                  referral                     (10),
+                  adminLimitExceeded           (11),
+                  unavailableCriticalExtension (12),
+                  confidentialityRequired      (13),
+                  saslBindInProgress           (14),
+
+
+
+Sermersheim                 Standards Track                    [Page 55]
+
+RFC 4511                         LDAPv3                        June 2006
+
+
+                  noSuchAttribute              (16),
+                  undefinedAttributeType       (17),
+                  inappropriateMatching        (18),
+                  constraintViolation          (19),
+                  attributeOrValueExists       (20),
+                  invalidAttributeSyntax       (21),
+                       -- 22-31 unused --
+                  noSuchObject                 (32),
+                  aliasProblem                 (33),
+                  invalidDNSyntax              (34),
+                       -- 35 reserved for undefined isLeaf --
+                  aliasDereferencingProblem    (36),
+                       -- 37-47 unused --
+                  inappropriateAuthentication  (48),
+                  invalidCredentials           (49),
+                  insufficientAccessRights     (50),
+                  busy                         (51),
+                  unavailable                  (52),
+                  unwillingToPerform           (53),
+                  loopDetect                   (54),
+                       -- 55-63 unused --
+                  namingViolation              (64),
+                  objectClassViolation         (65),
+                  notAllowedOnNonLeaf          (66),
+                  notAllowedOnRDN              (67),
+                  entryAlreadyExists           (68),
+                  objectClassModsProhibited    (69),
+                       -- 70 reserved for CLDAP --
+                  affectsMultipleDSAs          (71),
+                       -- 72-79 unused --
+                  other                        (80),
+                  ...  },
+             matchedDN          LDAPDN,
+             diagnosticMessage  LDAPString,
+             referral           [3] Referral OPTIONAL }
+
+        Referral ::= SEQUENCE SIZE (1..MAX) OF uri URI
+
+        URI ::= LDAPString     -- limited to characters permitted in
+                               -- URIs
+
+        Controls ::= SEQUENCE OF control Control
+
+        Control ::= SEQUENCE {
+             controlType             LDAPOID,
+             criticality             BOOLEAN DEFAULT FALSE,
+             controlValue            OCTET STRING OPTIONAL }
+
+
+
+
+Sermersheim                 Standards Track                    [Page 56]
+
+RFC 4511                         LDAPv3                        June 2006
+
+
+        BindRequest ::= [APPLICATION 0] SEQUENCE {
+             version                 INTEGER (1 ..  127),
+             name                    LDAPDN,
+             authentication          AuthenticationChoice }
+
+        AuthenticationChoice ::= CHOICE {
+             simple                  [0] OCTET STRING,
+                                     -- 1 and 2 reserved
+             sasl                    [3] SaslCredentials,
+             ...  }
+
+        SaslCredentials ::= SEQUENCE {
+             mechanism               LDAPString,
+             credentials             OCTET STRING OPTIONAL }
+
+        BindResponse ::= [APPLICATION 1] SEQUENCE {
+             COMPONENTS OF LDAPResult,
+             serverSaslCreds    [7] OCTET STRING OPTIONAL }
+
+        UnbindRequest ::= [APPLICATION 2] NULL
+
+        SearchRequest ::= [APPLICATION 3] SEQUENCE {
+             baseObject      LDAPDN,
+             scope           ENUMERATED {
+                  baseObject              (0),
+                  singleLevel             (1),
+                  wholeSubtree            (2),
+                  ...  },
+             derefAliases    ENUMERATED {
+                  neverDerefAliases       (0),
+                  derefInSearching        (1),
+                  derefFindingBaseObj     (2),
+                  derefAlways             (3) },
+             sizeLimit       INTEGER (0 ..  maxInt),
+             timeLimit       INTEGER (0 ..  maxInt),
+             typesOnly       BOOLEAN,
+             filter          Filter,
+             attributes      AttributeSelection }
+
+        AttributeSelection ::= SEQUENCE OF selector LDAPString
+                       -- The LDAPString is constrained to
+                       -- <attributeSelector> in Section 4.5.1.8
+
+        Filter ::= CHOICE {
+             and             [0] SET SIZE (1..MAX) OF filter Filter,
+             or              [1] SET SIZE (1..MAX) OF filter Filter,
+             not             [2] Filter,
+             equalityMatch   [3] AttributeValueAssertion,
+
+
+
+Sermersheim                 Standards Track                    [Page 57]
+
+RFC 4511                         LDAPv3                        June 2006
+
+
+             substrings      [4] SubstringFilter,
+             greaterOrEqual  [5] AttributeValueAssertion,
+             lessOrEqual     [6] AttributeValueAssertion,
+             present         [7] AttributeDescription,
+             approxMatch     [8] AttributeValueAssertion,
+             extensibleMatch [9] MatchingRuleAssertion,
+             ...  }
+
+        SubstringFilter ::= SEQUENCE {
+             type           AttributeDescription,
+             substrings     SEQUENCE SIZE (1..MAX) OF substring CHOICE {
+                  initial [0] AssertionValue,  -- can occur at most once
+                  any     [1] AssertionValue,
+                  final   [2] AssertionValue } -- can occur at most once
+             }
+
+        MatchingRuleAssertion ::= SEQUENCE {
+             matchingRule    [1] MatchingRuleId OPTIONAL,
+             type            [2] AttributeDescription OPTIONAL,
+             matchValue      [3] AssertionValue,
+             dnAttributes    [4] BOOLEAN DEFAULT FALSE }
+
+        SearchResultEntry ::= [APPLICATION 4] SEQUENCE {
+             objectName      LDAPDN,
+             attributes      PartialAttributeList }
+
+        PartialAttributeList ::= SEQUENCE OF
+                             partialAttribute PartialAttribute
+
+        SearchResultReference ::= [APPLICATION 19] SEQUENCE
+                                  SIZE (1..MAX) OF uri URI
+
+        SearchResultDone ::= [APPLICATION 5] LDAPResult
+
+        ModifyRequest ::= [APPLICATION 6] SEQUENCE {
+             object          LDAPDN,
+             changes         SEQUENCE OF change SEQUENCE {
+                  operation       ENUMERATED {
+                       add     (0),
+                       delete  (1),
+                       replace (2),
+                       ...  },
+                  modification    PartialAttribute } }
+
+        ModifyResponse ::= [APPLICATION 7] LDAPResult
+
+
+
+
+
+
+Sermersheim                 Standards Track                    [Page 58]
+
+RFC 4511                         LDAPv3                        June 2006
+
+
+        AddRequest ::= [APPLICATION 8] SEQUENCE {
+             entry           LDAPDN,
+             attributes      AttributeList }
+
+        AttributeList ::= SEQUENCE OF attribute Attribute
+
+        AddResponse ::= [APPLICATION 9] LDAPResult
+
+        DelRequest ::= [APPLICATION 10] LDAPDN
+
+        DelResponse ::= [APPLICATION 11] LDAPResult
+
+        ModifyDNRequest ::= [APPLICATION 12] SEQUENCE {
+             entry           LDAPDN,
+             newrdn          RelativeLDAPDN,
+             deleteoldrdn    BOOLEAN,
+             newSuperior     [0] LDAPDN OPTIONAL }
+
+        ModifyDNResponse ::= [APPLICATION 13] LDAPResult
+
+        CompareRequest ::= [APPLICATION 14] SEQUENCE {
+             entry           LDAPDN,
+             ava             AttributeValueAssertion }
+
+        CompareResponse ::= [APPLICATION 15] LDAPResult
+
+        AbandonRequest ::= [APPLICATION 16] MessageID
+
+        ExtendedRequest ::= [APPLICATION 23] SEQUENCE {
+             requestName      [0] LDAPOID,
+             requestValue     [1] OCTET STRING OPTIONAL }
+
+        ExtendedResponse ::= [APPLICATION 24] SEQUENCE {
+             COMPONENTS OF LDAPResult,
+             responseName     [10] LDAPOID OPTIONAL,
+             responseValue    [11] OCTET STRING OPTIONAL }
+
+        IntermediateResponse ::= [APPLICATION 25] SEQUENCE {
+             responseName     [0] LDAPOID OPTIONAL,
+             responseValue    [1] OCTET STRING OPTIONAL }
+
+        END
+
+
+
+
+
+
+
+
+
+Sermersheim                 Standards Track                    [Page 59]
+
+RFC 4511                         LDAPv3                        June 2006
+
+
+Appendix C.  Changes
+
+   This appendix is non-normative.
+
+   This appendix summarizes substantive changes made to RFC 2251, RFC
+   2830, and RFC 3771.
+
+C.1.  Changes Made to RFC 2251
+
+   This section summarizes the substantive changes made to Sections 1,
+   2, 3.1, and 4, and the remainder of RFC 2251.  Readers should
+   consult [RFC4512] and [RFC4513] for summaries of changes to other
+   sections.
+
+C.1.1.  Section 1 (Status of this Memo)
+
+   - Removed IESG note.  Post publication of RFC 2251, mandatory LDAP
+     authentication mechanisms have been standardized which are
+     sufficient to remove this note.  See [RFC4513] for authentication
+     mechanisms.
+
+C.1.2.  Section 3.1 (Protocol Model) and others
+
+   - Removed notes giving history between LDAP v1, v2, and v3.  Instead,
+     added sufficient language so that this document can stand on its
+     own.
+
+C.1.3.  Section 4 (Elements of Protocol)
+
+   - Clarified where the extensibility features of ASN.1 apply to the
+     protocol.  This change affected various ASN.1 types by the
+     inclusion of ellipses (...) to certain elements.
+   - Removed the requirement that servers that implement version 3 or
+     later MUST provide the 'supportedLDAPVersion' attribute.  This
+     statement provided no interoperability advantages.
+
+C.1.4.  Section 4.1.1 (Message Envelope)
+
+   - There was a mandatory requirement for the server to return a
+     Notice of Disconnection and drop the transport connection when a
+     PDU is malformed in a certain way.  This has been updated such that
+     the server SHOULD return the Notice of Disconnection, and it MUST
+     terminate the LDAP Session.
+
+C.1.5.  Section 4.1.1.1 (Message ID)
+
+   - Required that the messageID of requests MUST be non-zero as the
+     zero is reserved for Notice of Disconnection.
+
+
+
+Sermersheim                 Standards Track                    [Page 60]
+
+RFC 4511                         LDAPv3                        June 2006
+
+
+   - Specified when it is and isn't appropriate to return an already
+     used messageID.  RFC 2251 accidentally imposed synchronous server
+     behavior in its wording of this.
+
+C.1.6.  Section 4.1.2 (String Types)
+
+   - Stated that LDAPOID is constrained to <numericoid> from [RFC4512].
+
+C.1.7.  Section 4.1.5.1 (Binary Option) and others
+
+   - Removed the Binary Option from the specification.  There are
+     numerous interoperability problems associated with this method of
+     alternate attribute type encoding.  Work to specify a suitable
+     replacement is ongoing.
+
+C.1.8.  Section 4.1.8 (Attribute)
+
+   - Combined the definitions of PartialAttribute and Attribute here,
+     and defined Attribute in terms of PartialAttribute.
+
+C.1.9.  Section 4.1.10 (Result Message)
+
+   - Renamed "errorMessage" to "diagnosticMessage" as it is allowed to
+     be sent for non-error results.
+   - Moved some language into Appendix A, and referred the reader there.
+   - Allowed matchedDN to be present for other result codes than those
+     listed in RFC 2251.
+   - Renamed the code "strongAuthRequired" to "strongerAuthRequired" to
+     clarify that this code may often be returned to indicate that a
+     stronger authentication is needed to perform a given operation.
+
+C.1.10.  Section 4.1.11 (Referral)
+
+   - Defined referrals in terms of URIs rather than URLs.
+   - Removed the requirement that all referral URIs MUST be equally
+     capable of progressing the operation.  The statement was ambiguous
+     and provided no instructions on how to carry it out.
+   - Added the requirement that clients MUST NOT loop between servers.
+   - Clarified the instructions for using LDAPURLs in referrals, and in
+     doing so added a recommendation that the scope part be present.
+   - Removed imperatives which required clients to use URLs in specific
+     ways to progress an operation.  These did nothing for
+     interoperability.
+
+
+
+
+
+
+
+
+Sermersheim                 Standards Track                    [Page 61]
+
+RFC 4511                         LDAPv3                        June 2006
+
+
+C.1.11.  Section 4.1.12 (Controls)
+
+   - Specified how control values defined in terms of ASN.1 are to be
+     encoded.
+   - Noted that the criticality field is only applied to request
+     messages (except UnbindRequest), and must be ignored when present
+     on response messages and UnbindRequest.
+   - Specified that non-critical controls may be ignored at the
+     server's discretion.  There was confusion in the original wording
+     which led some to believe that recognized controls may not be
+     ignored as long as they were associated with a proper request.
+   - Added language regarding combinations of controls and the ordering
+     of controls on a message.
+   - Specified that when the semantics of the combination of controls
+     is undefined or unknown, it results in a protocolError.
+   - Changed "The server MUST be prepared" to "Implementations MUST be
+     prepared" in paragraph 8 to reflect that both client and server
+     implementations must be able to handle this (as both parse
+     controls).
+
+C.1.12.  Section 4.2 (Bind Operation)
+
+   - Mandated that servers return protocolError when the version is not
+     supported.
+   - Disambiguated behavior when the simple authentication is used, the
+     name is empty, and the password is non-empty.
+   - Required servers to not dereference aliases for Bind.  This was
+     added for consistency with other operations and to help ensure
+     data consistency.
+   - Required that textual passwords be transferred as UTF-8 encoded
+     Unicode, and added recommendations on string preparation.  This was
+     to help ensure interoperability of passwords being sent from
+     different clients.
+
+C.1.13.  Section 4.2.1 (Sequencing of the Bind Request)
+
+   - This section was largely reorganized for readability, and language
+     was added to clarify the authentication state of failed and
+     abandoned Bind operations.
+   - Removed: "If a SASL transfer encryption or integrity mechanism has
+     been negotiated, that mechanism does not support the changing of
+     credentials from one identity to another, then the client MUST
+     instead establish a new connection."
+     If there are dependencies between multiple negotiations of a
+     particular SASL mechanism, the technical specification for that
+     SASL mechanism details how applications are to deal with them.
+     LDAP should not require any special handling.
+   - Dropped MUST imperative in paragraph 3 to align with [RFC2119].
+
+
+
+Sermersheim                 Standards Track                    [Page 62]
+
+RFC 4511                         LDAPv3                        June 2006
+
+
+   - Mandated that clients not send non-Bind operations while a Bind is
+     in progress, and suggested that servers not process them if they
+     are received.  This is needed to ensure proper sequencing of the
+     Bind in relationship to other operations.
+
+C.1.14.  Section 4.2.3 (Bind Response)
+
+   - Moved most error-related text to Appendix A, and added text
+     regarding certain errors used in conjunction with the Bind
+     operation.
+   - Prohibited the server from specifying serverSaslCreds when not
+     appropriate.
+
+C.1.15.  Section 4.3 (Unbind Operation)
+
+   - Specified that both peers are to cease transmission and terminate
+     the LDAP session for the Unbind operation.
+
+C.1.16.  Section 4.4 (Unsolicited Notification)
+
+   - Added instructions for future specifications of Unsolicited
+     Notifications.
+
+C.1.17.  Section 4.5.1 (Search Request)
+
+   - SearchRequest attributes is now defined as an AttributeSelection
+     type rather than AttributeDescriptionList, and an ABNF is
+     provided.
+   - SearchRequest attributes may contain duplicate attribute
+     descriptions.  This was previously prohibited.  Now servers are
+     instructed to ignore subsequent names when they are duplicated.
+     This was relaxed in order to allow different short names and also
+     OIDs to be requested for an attribute.
+   - The present search filter now evaluates to Undefined when the
+     specified attribute is not known to the server.  It used to
+     evaluate to FALSE, which caused behavior inconsistent with what
+     most would expect, especially when the 'not' operator was used.
+   - The Filter choice SubstringFilter substrings type is now defined
+     with a lower bound of 1.
+   - The SubstringFilter substrings 'initial, 'any', and 'final' types
+     are now AssertionValue rather than LDAPString.  Also, added
+     imperatives stating that 'initial' (if present) must be listed
+     first, and 'final' (if present) must be listed last.
+   - Disambiguated the semantics of the derefAliases choices.  There was
+     question as to whether derefInSearching applied to the base object
+     in a wholeSubtree Search.
+   - Added instructions for equalityMatch, substrings, greaterOrEqual,
+     lessOrEqual, and approxMatch.
+
+
+
+Sermersheim                 Standards Track                    [Page 63]
+
+RFC 4511                         LDAPv3                        June 2006
+
+
+
+C.1.18.  Section 4.5.2 (Search Result)
+
+   - Recommended that servers not use attribute short names when it
+     knows they are ambiguous or may cause interoperability problems.
+   - Removed all mention of ExtendedResponse due to lack of
+     implementation.
+
+C.1.19.  Section 4.5.3 (Continuation References in the Search Result)
+
+   - Made changes similar to those made to Section 4.1.11.
+
+C.1.20.  Section 4.5.3.1 (Example)
+
+   - Fixed examples to adhere to changes made to Section 4.5.3.
+
+C.1.21.  Section 4.6 (Modify Operation)
+
+   - Replaced AttributeTypeAndValues with Attribute as they are
+     equivalent.
+   - Specified the types of modification changes that might
+     temporarily violate schema.  Some readers were under the impression
+     that any temporary schema violation was allowed.
+
+C.1.22.  Section 4.7 (Add Operation)
+
+   - Aligned Add operation with X.511 in that the attributes of the RDN
+     are used in conjunction with the listed attributes to create the
+     entry.  Previously, Add required that the distinguished values be
+     present in the listed attributes.
+   - Removed requirement that the objectClass attribute MUST be
+     specified as some DSE types do not require this attribute.
+     Instead, generic wording was added, requiring the added entry to
+     adhere to the data model.
+   - Removed recommendation regarding placement of objects.  This is
+     covered in the data model document.
+
+C.1.23.  Section 4.9 (Modify DN Operation)
+
+   - Required servers to not dereference aliases for Modify DN.  This
+     was added for consistency with other operations and to help ensure
+     data consistency.
+   - Allow Modify DN to fail when moving between naming contexts.
+   - Specified what happens when the attributes of the newrdn are not
+     present on the entry.
+
+
+
+
+
+
+Sermersheim                 Standards Track                    [Page 64]
+
+RFC 4511                         LDAPv3                        June 2006
+
+
+C.1.24.  Section 4.10 (Compare Operation)
+
+   - Specified that compareFalse means that the Compare took place and
+     the result is false.  There was confusion that led people to
+     believe that an Undefined match resulted in compareFalse.
+   - Required servers to not dereference aliases for Compare.  This was
+     added for consistency with other operations and to help ensure
+     data consistency.
+
+C.1.25.  Section 4.11 (Abandon Operation)
+
+   - Explained that since Abandon returns no response, clients should
+     not use it if they need to know the outcome.
+   - Specified that Abandon and Unbind cannot be abandoned.
+
+C.1.26.  Section 4.12 (Extended Operation)
+
+   - Specified how values of Extended operations defined in terms of
+     ASN.1 are to be encoded.
+   - Added instructions on what Extended operation specifications
+     consist of.
+   - Added a recommendation that servers advertise supported Extended
+     operations.
+
+C.1.27.  Section 5.2 (Transfer Protocols)
+
+   - Moved referral-specific instructions into referral-related
+     sections.
+
+C.1.28.  Section 7 (Security Considerations)
+
+   - Reworded notes regarding SASL not protecting certain aspects of
+     the LDAP Bind messages.
+   - Noted that Servers are encouraged to prevent directory
+     modifications by clients that have authenticated anonymously
+     [RFC4513].
+   - Added a note regarding the possibility of changes to security
+     factors (authentication, authorization, and data confidentiality).
+   - Warned against following referrals that may have been injected in
+     the data stream.
+   - Noted that servers should protect information equally, whether in
+     an error condition or not, and mentioned matchedDN,
+     diagnosticMessage, and resultCodes specifically.
+   - Added a note regarding malformed and long encodings.
+
+
+
+
+
+
+
+Sermersheim                 Standards Track                    [Page 65]
+
+RFC 4511                         LDAPv3                        June 2006
+
+
+C.1.29.  Appendix A (Complete ASN.1 Definition)
+
+   - Added "EXTENSIBILITY IMPLIED" to ASN.1 definition.
+   - Removed AttributeType.  It is not used.
+
+C.2.  Changes Made to RFC 2830
+
+   This section summarizes the substantive changes made to Sections of
+   RFC 2830.  Readers should consult [RFC4513] for summaries of changes
+   to other sections.
+
+C.2.1.  Section 2.3 (Response other than "success")
+
+   - Removed wording indicating that referrals can be returned from
+     StartTLS.
+   - Removed requirement that only a narrow set of result codes can be
+     returned.  Some result codes are required in certain scenarios, but
+     any other may be returned if appropriate.
+   - Removed requirement that the ExtendedResponse.responseName MUST be
+     present.  There are circumstances where this is impossible, and
+     requiring this is at odds with language in Section 4.12.
+
+C.2.1.  Section 4 (Closing a TLS Connection)
+
+   - Reworded most of this section to align with definitions of the
+     LDAP protocol layers.
+   - Removed instructions on abrupt closure as this is covered in other
+     areas of the document (specifically, Section 5.3)
+
+C.3.  Changes Made to RFC 3771
+
+   - Rewrote to fit into this document.  In general, semantics were
+     preserved.  Supporting and background language seen as redundant
+     due to its presence in this document was omitted.
+
+   - Specified that Intermediate responses to a request may be of
+     different types, and one of the response types may be specified to
+     have no response value.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sermersheim                 Standards Track                    [Page 66]
+
+RFC 4511                         LDAPv3                        June 2006
+
+
+Editor's Address
+
+   Jim Sermersheim
+   Novell, Inc.
+   1800 South Novell Place
+   Provo, Utah 84606, USA
+
+   Phone: +1 801 861-3088
+   EMail: jimse@novell.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sermersheim                 Standards Track                    [Page 67]
+
+RFC 4511                         LDAPv3                        June 2006
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2006).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Sermersheim                 Standards Track                    [Page 68]
+
diff --git a/source4/ldap_server/devdocs/rfc4512.txt b/source4/ldap_server/devdocs/rfc4512.txt
new file mode 100644
index 0000000000..f45a3f3e73
--- /dev/null
+++ b/source4/ldap_server/devdocs/rfc4512.txt
@@ -0,0 +1,2915 @@
+
+
+
+
+
+
+Network Working Group                                        K. Zeilenga
+Request for Comments: 4512                           OpenLDAP Foundation
+Obsoletes: 2251, 2252, 2256, 3674                              June 2006
+Category: Standards Track
+
+
+             Lightweight Directory Access Protocol (LDAP):
+                      Directory Information Models
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   The Lightweight Directory Access Protocol (LDAP) is an Internet
+   protocol for accessing distributed directory services that act in
+   accordance with X.500 data and service models.  This document
+   describes the X.500 Directory Information Models, as used in LDAP.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga                    Standards Track                     [Page 1]
+
+RFC 4512                      LDAP Models                      June 2006
+
+
+Table of Contents
+
+   1. Introduction ....................................................3
+      1.1. Relationship to Other LDAP Specifications ..................3
+      1.2. Relationship to X.501 ......................................4
+      1.3. Conventions ................................................4
+      1.4. Common ABNF Productions ....................................4
+   2. Model of Directory User Information .............................6
+      2.1. The Directory Information Tree .............................7
+      2.2. Structure of an Entry ......................................7
+      2.3. Naming of Entries ..........................................8
+      2.4. Object Classes .............................................9
+      2.5. Attribute Descriptions ....................................12
+      2.6. Alias Entries .............................................16
+   3. Directory Administrative and Operational Information ...........17
+      3.1. Subtrees ..................................................17
+      3.2. Subentries ................................................18
+      3.3. The 'objectClass' attribute ...............................18
+      3.4. Operational Attributes ....................................19
+   4. Directory Schema ...............................................22
+      4.1. Schema Definitions ........................................23
+      4.2. Subschema Subentries ......................................32
+      4.3. 'extensibleObject' object class ...........................35
+      4.4. Subschema Discovery .......................................35
+   5. DSA (Server) Informational Model ...............................36
+      5.1. Server-Specific Data Requirements .........................36
+   6. Other Considerations ...........................................40
+      6.1. Preservation of User Information ..........................40
+      6.2. Short Names ...............................................41
+      6.3. Cache and Shadowing .......................................41
+   7. Implementation Guidelines ......................................42
+      7.1. Server Guidelines .........................................42
+      7.2. Client Guidelines .........................................42
+   8. Security Considerations ........................................43
+   9. IANA Considerations ............................................43
+   10. Acknowledgements ..............................................44
+   11. Normative References ..........................................45
+   Appendix A. Changes ...............................................47
+      A.1. Changes to RFC 2251 .......................................47
+      A.2. Changes to RFC 2252 .......................................49
+      A.3. Changes to RFC 2256 .......................................50
+      A.4. Changes to RFC 3674 .......................................51
+
+
+
+
+
+
+
+
+
+Zeilenga                    Standards Track                     [Page 2]
+
+RFC 4512                      LDAP Models                      June 2006
+
+
+1.  Introduction
+
+   This document discusses the X.500 Directory Information Models
+   [X.501], as used by the Lightweight Directory Access Protocol (LDAP)
+   [RFC4510].
+
+   The Directory is "a collection of open systems cooperating to provide
+   directory services" [X.500].  The information held in the Directory
+   is collectively known as the Directory Information Base (DIB).  A
+   Directory user, which may be a human or other entity, accesses the
+   Directory through a client (or Directory User Agent (DUA)).  The
+   client, on behalf of the directory user, interacts with one or more
+   servers (or Directory System Agents (DSA)).  A server holds a
+   fragment of the DIB.
+
+   The DIB contains two classes of information:
+
+      1) user information (e.g., information provided and administrated
+         by users).  Section 2 describes the Model of User Information.
+
+      2) administrative and operational information (e.g., information
+         used to administer and/or operate the directory).  Section 3
+         describes the model of Directory Administrative and Operational
+         Information.
+
+   These two models, referred to as the generic Directory Information
+   Models, describe how information is represented in the Directory.
+   These generic models provide a framework for other information
+   models.  Section 4 discusses the subschema information model and
+   subschema discovery.  Section 5 discusses the DSA (Server)
+   Informational Model.
+
+   Other X.500 information models (such as access control distribution
+   knowledge and replication knowledge information models) may be
+   adapted for use in LDAP.  Specification of how these models apply to
+   LDAP is left to future documents.
+
+1.1.  Relationship to Other LDAP Specifications
+
+   This document is a integral part of the LDAP technical specification
+   [RFC4510], which obsoletes the previously defined LDAP technical
+   specification, RFC 3377, in its entirety.
+
+   This document obsoletes RFC 2251, Sections 3.2 and 3.4, as well as
+   portions of Sections 4 and 6.  Appendix A.1 summarizes changes to
+   these sections.  The remainder of RFC 2251 is obsoleted by the
+   [RFC4511], [RFC4513], and [RFC4510] documents.
+
+
+
+
+Zeilenga                    Standards Track                     [Page 3]
+
+RFC 4512                      LDAP Models                      June 2006
+
+
+   This document obsoletes RFC 2252, Sections 4, 5, and 7.  Appendix A.2
+   summarizes changes to these sections.  The remainder of RFC 2252 is
+   obsoleted by [RFC4517].
+
+   This document obsoletes RFC 2256, Sections 5.1, 5.2, 7.1, and 7.2.
+   Appendix A.3 summarizes changes to these sections.  The remainder of
+   RFC 2256 is obsoleted by [RFC4519] and [RFC4517].
+
+   This document obsoletes RFC 3674 in its entirety.  Appendix A.4
+   summarizes changes since RFC 3674.
+
+1.2.  Relationship to X.501
+
+   This document includes material, with and without adaptation, from
+   [X.501] as necessary to describe this protocol.  These adaptations
+   (and any other differences herein) apply to this protocol, and only
+   this protocol.
+
+1.3.  Conventions
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in BCP 14 [RFC2119].
+
+   Schema definitions are provided using LDAP description formats (as
+   defined in Section 4.1).  Definitions provided here are formatted
+   (line wrapped) for readability.  Matching rules and LDAP syntaxes
+   referenced in these definitions are specified in [RFC4517].
+
+1.4.  Common ABNF Productions
+
+   A number of syntaxes in this document are described using Augmented
+   Backus-Naur Form (ABNF) [RFC4234].  These syntaxes (as well as a
+   number of syntaxes defined in other documents) rely on the following
+   common productions:
+
+      keystring = leadkeychar *keychar
+      leadkeychar = ALPHA
+      keychar = ALPHA / DIGIT / HYPHEN
+      number  = DIGIT / ( LDIGIT 1*DIGIT )
+
+      ALPHA   = %x41-5A / %x61-7A   ; "A"-"Z" / "a"-"z"
+      DIGIT   = %x30 / LDIGIT       ; "0"-"9"
+      LDIGIT  = %x31-39             ; "1"-"9"
+      HEX     = DIGIT / %x41-46 / %x61-66 ; "0"-"9" / "A"-"F" / "a"-"f"
+
+      SP      = 1*SPACE  ; one or more " "
+      WSP     = 0*SPACE  ; zero or more " "
+
+
+
+Zeilenga                    Standards Track                     [Page 4]
+
+RFC 4512                      LDAP Models                      June 2006
+
+
+      NULL    = %x00 ; null (0)
+      SPACE   = %x20 ; space (" ")
+      DQUOTE  = %x22 ; quote (""")
+      SHARP   = %x23 ; octothorpe (or sharp sign) ("#")
+      DOLLAR  = %x24 ; dollar sign ("$")
+      SQUOTE  = %x27 ; single quote ("'")
+      LPAREN  = %x28 ; left paren ("(")
+      RPAREN  = %x29 ; right paren (")")
+      PLUS    = %x2B ; plus sign ("+")
+      COMMA   = %x2C ; comma (",")
+      HYPHEN  = %x2D ; hyphen ("-")
+      DOT     = %x2E ; period (".")
+      SEMI    = %x3B ; semicolon (";")
+      LANGLE  = %x3C ; left angle bracket ("<")
+      EQUALS  = %x3D ; equals sign ("=")
+      RANGLE  = %x3E ; right angle bracket (">")
+      ESC     = %x5C ; backslash ("\")
+      USCORE  = %x5F ; underscore ("_")
+      LCURLY  = %x7B ; left curly brace "{"
+      RCURLY  = %x7D ; right curly brace "}"
+
+      ; Any UTF-8 [RFC3629] encoded Unicode [Unicode] character
+      UTF8    = UTF1 / UTFMB
+      UTFMB   = UTF2 / UTF3 / UTF4
+      UTF0    = %x80-BF
+      UTF1    = %x00-7F
+      UTF2    = %xC2-DF UTF0
+      UTF3    = %xE0 %xA0-BF UTF0 / %xE1-EC 2(UTF0) /
+                %xED %x80-9F UTF0 / %xEE-EF 2(UTF0)
+      UTF4    = %xF0 %x90-BF 2(UTF0) / %xF1-F3 3(UTF0) /
+                %xF4 %x80-8F 2(UTF0)
+
+      OCTET   = %x00-FF ; Any octet (8-bit data unit)
+
+   Object identifiers (OIDs) [X.680] are represented in LDAP using a
+   dot-decimal format conforming to the ABNF:
+
+      numericoid = number 1*( DOT number )
+
+   Short names, also known as descriptors, are used as more readable
+   aliases for object identifiers.  Short names are case insensitive and
+   conform to the ABNF:
+
+      descr = keystring
+
+
+
+
+
+
+
+Zeilenga                    Standards Track                     [Page 5]
+
+RFC 4512                      LDAP Models                      June 2006
+
+
+   Where either an object identifier or a short name may be specified,
+   the following production is used:
+
+      oid = descr / numericoid
+
+   While the <descr> form is generally preferred when the usage is
+   restricted to short names referring to object identifiers that
+   identify like kinds of objects (e.g., attribute type descriptions,
+   matching rule descriptions, object class descriptions), the
+   <numericoid> form should be used when the object identifiers may
+   identify multiple kinds of objects or when an unambiguous short name
+   (descriptor) is not available.
+
+   Implementations SHOULD treat short names (descriptors) used in an
+   ambiguous manner (as discussed above) as unrecognized.
+
+   Short Names (descriptors) are discussed further in Section 6.2.
+
+2.  Model of Directory User Information
+
+   As [X.501] states:
+
+      The purpose of the Directory is to hold, and provide access to,
+      information about objects of interest (objects) in some 'world'.
+      An object can be anything which is identifiable (can be named).
+
+      An object class is an identified family of objects, or conceivable
+      objects, which share certain characteristics.  Every object
+      belongs to at least one class.  An object class may be a subclass
+      of other object classes, in which case the members of the former
+      class, the subclass, are also considered to be members of the
+      latter classes, the superclasses.  There may be subclasses of
+      subclasses, etc., to an arbitrary depth.
+
+   A directory entry, a named collection of information, is the basic
+   unit of information held in the Directory.  There are multiple kinds
+   of directory entries.
+
+   An object entry represents a particular object.  An alias entry
+   provides alternative naming.  A subentry holds administrative and/or
+   operational information.
+
+   The set of entries representing the DIB are organized hierarchically
+   in a tree structure known as the Directory Information Tree (DIT).
+
+   Section 2.1 describes the Directory Information Tree.
+   Section 2.2 discusses the structure of entries.
+   Section 2.3 discusses naming of entries.
+
+
+
+Zeilenga                    Standards Track                     [Page 6]
+
+RFC 4512                      LDAP Models                      June 2006
+
+
+   Section 2.4 discusses object classes.
+   Section 2.5 discusses attribute descriptions.
+   Section 2.6 discusses alias entries.
+
+2.1.  The Directory Information Tree
+
+   As noted above, the DIB is composed of a set of entries organized
+   hierarchically in a tree structure known as the Directory Information
+   Tree (DIT); specifically, a tree where vertices are the entries.
+
+   The arcs between vertices define relations between entries.  If an
+   arc exists from X to Y, then the entry at X is the immediate superior
+   of Y, and Y is the immediate subordinate of X.  An entry's superiors
+   are the entry's immediate superior and its superiors.  An entry's
+   subordinates are all of its immediate subordinates and their
+   subordinates.
+
+   Similarly, the superior/subordinate relationship between object
+   entries can be used to derive a relation between the objects they
+   represent.  DIT structure rules can be used to govern relationships
+   between objects.
+
+   Note: An entry's immediate superior is also known as the entry's
+         parent, and an entry's immediate subordinate is also known as
+         the entry's child.  Entries that have the same parent are known
+         as siblings.
+
+2.2.  Structure of an Entry
+
+   An entry consists of a set of attributes that hold information about
+   the object that the entry represents.  Some attributes represent user
+   information and are called user attributes.  Other attributes
+   represent operational and/or administrative information and are
+   called operational attributes.
+
+   An attribute is an attribute description (a type and zero or more
+   options) with one or more associated values.  An attribute is often
+   referred to by its attribute description.  For example, the
+   'givenName' attribute is the attribute that consists of the attribute
+   description 'givenName' (the 'givenName' attribute type [RFC4519] and
+   zero options) and one or more associated values.
+
+   The attribute type governs whether the attribute can have multiple
+   values, the syntax and matching rules used to construct and compare
+   values of that attribute, and other functions.  Options indicate
+   subtypes and other functions.
+
+   Attribute values conform to the defined syntax of the attribute type.
+
+
+
+Zeilenga                    Standards Track                     [Page 7]
+
+RFC 4512                      LDAP Models                      June 2006
+
+
+   No two values of an attribute may be equivalent.  Two values are
+   considered equivalent if and only if they would match according to
+   the equality matching rule of the attribute type.  Or, if the
+   attribute type is defined with no equality matching rule, two values
+   are equivalent if and only if they are identical.  (See 2.5.1 for
+   other restrictions.)
+
+   For example, a 'givenName' attribute can have more than one value,
+   they must be Directory Strings, and they are case insensitive.  A
+   'givenName' attribute cannot hold both "John" and "JOHN", as these
+   are equivalent values per the equality matching rule of the attribute
+   type.
+
+   Additionally, no attribute is to have a value that is not equivalent
+   to itself.  For example, the 'givenName' attribute cannot have as a
+   value a directory string that includes the REPLACEMENT CHARACTER
+   (U+FFFD) code point, as matching involving that directory string is
+   Undefined per this attribute's equality matching rule.
+
+   When an attribute is used for naming of the entry, one and only one
+   value of the attribute is used in forming the Relative Distinguished
+   Name.  This value is known as a distinguished value.
+
+2.3.  Naming of Entries
+
+2.3.1.  Relative Distinguished Names
+
+   Each entry is named relative to its immediate superior.  This
+   relative name, known as its Relative Distinguished Name (RDN)
+   [X.501], is composed of an unordered set of one or more attribute
+   value assertions (AVA) consisting of an attribute description with
+   zero options and an attribute value.  These AVAs are chosen to match
+   attribute values (each a distinguished value) of the entry.
+
+   An entry's relative distinguished name must be unique among all
+   immediate subordinates of the entry's immediate superior (i.e., all
+   siblings).
+
+   The following are examples of string representations of RDNs
+   [RFC4514]:
+
+      UID=12345
+      OU=Engineering
+      CN=Kurt Zeilenga+L=Redwood Shores
+
+   The last is an example of a multi-valued RDN; that is, an RDN
+   composed of multiple AVAs.
+
+
+
+
+Zeilenga                    Standards Track                     [Page 8]
+
+RFC 4512                      LDAP Models                      June 2006
+
+
+2.3.2.  Distinguished Names
+
+   An entry's fully qualified name, known as its Distinguished Name (DN)
+   [X.501], is the concatenation of its RDN and its immediate superior's
+   DN.  A Distinguished Name unambiguously refers to an entry in the
+   tree.  The following are examples of string representations of DNs
+   [RFC4514]:
+
+      UID=nobody@example.com,DC=example,DC=com
+      CN=John Smith,OU=Sales,O=ACME Limited,L=Moab,ST=Utah,C=US
+
+2.3.3.  Alias Names
+
+   An alias, or alias name, is "an name for an object, provided by the
+   use of alias entries" [X.501].  Alias entries are described in
+   Section 2.6.
+
+2.4.  Object Classes
+
+   An object class is "an identified family of objects (or conceivable
+   objects) that share certain characteristics" [X.501].
+
+   As defined in [X.501]:
+
+      Object classes are used in the Directory for a number of purposes:
+
+        - describing and categorizing objects and the entries that
+          correspond to these objects;
+
+        - where appropriate, controlling the operation of the Directory;
+
+        - regulating, in conjunction with DIT structure rule
+          specifications, the position of entries in the DIT;
+
+        - regulating, in conjunction with DIT content rule
+          specifications, the attributes that are contained in entries;
+
+        - identifying classes of entry that are to be associated with a
+          particular policy by the appropriate administrative authority.
+
+      An object class (a subclass) may be derived from an object class
+      (its direct superclass) which is itself derived from an even more
+      generic object class.  For structural object classes, this process
+      stops at the most generic object class, 'top' (defined in Section
+      2.4.1).  An ordered set of superclasses up to the most superior
+      object class of an object class is its superclass chain.
+
+
+
+
+
+Zeilenga                    Standards Track                     [Page 9]
+
+RFC 4512                      LDAP Models                      June 2006
+
+
+      An object class may be derived from two or more direct
+      superclasses (superclasses not part of the same superclass chain).
+      This feature of subclassing is termed multiple inheritance.
+
+   Each object class identifies the set of attributes required to be
+   present in entries belonging to the class and the set of attributes
+   allowed to be present in entries belonging to the class.  As an entry
+   of a class must meet the requirements of each class it belongs to, it
+   can be said that an object class inherits the sets of allowed and
+   required attributes from its superclasses.  A subclass can identify
+   an attribute allowed by its superclass as being required.  If an
+   attribute is a member of both sets, it is required to be present.
+
+   Each object class is defined to be one of three kinds of object
+   classes: Abstract, Structural, or Auxiliary.
+
+   Each object class is identified by an object identifier (OID) and,
+   optionally, one or more short names (descriptors).
+
+2.4.1.  Abstract Object Classes
+
+   An abstract object class, as the name implies, provides a base of
+   characteristics from which other object classes can be defined to
+   inherit from.  An entry cannot belong to an abstract object class
+   unless it belongs to a structural or auxiliary class that inherits
+   from that abstract class.
+
+   Abstract object classes cannot derive from structural or auxiliary
+   object classes.
+
+   All structural object classes derive (directly or indirectly) from
+   the 'top' abstract object class.  Auxiliary object classes do not
+   necessarily derive from 'top'.
+
+   The following is the object class definition (see Section 4.1.1) for
+   the 'top' object class:
+
+      ( 2.5.6.0 NAME 'top' ABSTRACT MUST objectClass )
+
+   All entries belong to the 'top' abstract object class.
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga                    Standards Track                    [Page 10]
+
+RFC 4512                      LDAP Models                      June 2006
+
+
+2.4.2.  Structural Object Classes
+
+   As stated in [X.501]:
+
+      An object class defined for use in the structural specification of
+      the DIT is termed a structural object class.  Structural object
+      classes are used in the definition of the structure of the names
+      of the objects for compliant entries.
+
+      An object or alias entry is characterized by precisely one
+      structural object class superclass chain which has a single
+      structural object class as the most subordinate object class.
+      This structural object class is referred to as the structural
+      object class of the entry.
+
+      Structural object classes are related to associated entries:
+
+        - an entry conforming to a structural object class shall
+          represent the real-world object constrained by the object
+          class;
+
+        - DIT structure rules only refer to structural object classes;
+          the structural object class of an entry is used to specify the
+          position of the entry in the DIT;
+
+        - the structural object class of an entry is used, along with an
+          associated DIT content rule, to control the content of an
+          entry.
+
+      The structural object class of an entry shall not be changed.
+
+   Each structural object class is a (direct or indirect) subclass of
+   the 'top' abstract object class.
+
+   Structural object classes cannot subclass auxiliary object classes.
+
+   Each entry is said to belong to its structural object class as well
+   as all classes in its structural object class's superclass chain.
+
+2.4.3.  Auxiliary Object Classes
+
+   Auxiliary object classes are used to augment the characteristics of
+   entries.  They are commonly used to augment the sets of attributes
+   required and allowed to be present in an entry.  They can be used to
+   describe entries or classes of entries.
+
+   Auxiliary object classes cannot subclass structural object classes.
+
+
+
+
+Zeilenga                    Standards Track                    [Page 11]
+
+RFC 4512                      LDAP Models                      June 2006
+
+
+   An entry can belong to any subset of the set of auxiliary object
+   classes allowed by the DIT content rule associated with the
+   structural object class of the entry.  If no DIT content rule is
+   associated with the structural object class of the entry, the entry
+   cannot belong to any auxiliary object class.
+
+   The set of auxiliary object classes that an entry belongs to can
+   change over time.
+
+2.5.  Attribute Descriptions
+
+   An attribute description is composed of an attribute type (see
+   Section 2.5.1) and a set of zero or more attribute options (see
+   Section 2.5.2).
+
+   An attribute description is represented by the ABNF:
+
+      attributedescription = attributetype options
+      attributetype = oid
+      options = *( SEMI option )
+      option = 1*keychar
+
+   where <attributetype> identifies the attribute type and each <option>
+   identifies an attribute option.  Both <attributetype> and <option>
+   productions are case insensitive.  The order in which <option>s
+   appear is irrelevant.  That is, any two <attributedescription>s that
+   consist of the same <attributetype> and same set of <option>s are
+   equivalent.
+
+   Examples of valid attribute descriptions:
+
+      2.5.4.0
+      cn;lang-de;lang-en
+      owner
+
+   An attribute description with an unrecognized attribute type is to be
+   treated as unrecognized.  Servers SHALL treat an attribute
+   description with an unrecognized attribute option as unrecognized.
+   Clients MAY treat an unrecognized attribute option as a tagging
+   option (see Section 2.5.2.1).
+
+   All attributes of an entry must have distinct attribute descriptions.
+
+2.5.1.  Attribute Types
+
+   An attribute type governs whether the attribute can have multiple
+   values, the syntax and matching rules used to construct and compare
+   values of that attribute, and other functions.
+
+
+
+Zeilenga                    Standards Track                    [Page 12]
+
+RFC 4512                      LDAP Models                      June 2006
+
+
+   If no equality matching is specified for the attribute type:
+
+      - the attribute (of the type) cannot be used for naming;
+      - when adding the attribute (or replacing all values), no two
+        values may be equivalent (see 2.2);
+      - individual values of a multi-valued attribute are not to be
+        independently added or deleted;
+      - attribute value assertions (such as matching in search filters
+        and comparisons) using values of such a type cannot be
+        performed.
+
+   Otherwise, the specified equality matching rule is to be used to
+   evaluate attribute value assertions concerning the attribute type.
+   The specified equality rule is to be transitive and commutative.
+
+   The attribute type indicates whether the attribute is a user
+   attribute or an operational attribute.  If operational, the attribute
+   type indicates the operational usage and whether or not the attribute
+   is modifiable by users.  Operational attributes are discussed in
+   Section 3.4.
+
+   An attribute type (a subtype) may derive from a more generic
+   attribute type (a direct supertype).  The following restrictions
+   apply to subtyping:
+
+      - a subtype must have the same usage as its direct supertype,
+      - a subtype's syntax must be the same, or a refinement of, its
+        supertype's syntax, and
+      - a subtype must be collective [RFC3671] if its supertype is
+        collective.
+
+   An attribute description consisting of a subtype and no options is
+   said to be the direct description subtype of the attribute
+   description consisting of the subtype's direct supertype and no
+   options.
+
+   Each attribute type is identified by an object identifier (OID) and,
+   optionally, one or more short names (descriptors).
+
+2.5.2.  Attribute Options
+
+   There are multiple kinds of attribute description options.  The LDAP
+   technical specification details one kind: tagging options.
+
+   Not all options can be associated with attributes held in the
+   directory.  Tagging options can be.
+
+
+
+
+
+Zeilenga                    Standards Track                    [Page 13]
+
+RFC 4512                      LDAP Models                      June 2006
+
+
+   Not all options can be used in conjunction with all attribute types.
+   In such cases, the attribute description is to be treated as
+   unrecognized.
+
+   An attribute description that contains mutually exclusive options
+   shall be treated as unrecognized.  That is, "cn;x-bar;x-foo", where
+   "x-foo" and "x-bar" are mutually exclusive, is to be treated as
+   unrecognized.
+
+   Other kinds of options may be specified in future documents.  These
+   documents must detail how new kinds of options they define relate to
+   tagging options.  In particular, these documents must detail whether
+   or not new kinds of options can be associated with attributes held in
+   the directory, how new kinds of options affect transfer of attribute
+   values, and how new kinds of options are treated in attribute
+   description hierarchies.
+
+   Options are represented as short, case-insensitive textual strings
+   conforming to the <option> production defined in Section 2.5 of this
+   document.
+
+   Procedures for registering options are detailed in BCP 64, RFC 4520
+   [RFC4520].
+
+2.5.2.1.  Tagging Options
+
+   Attributes held in the directory can have attribute descriptions with
+   any number of tagging options.  Tagging options are never mutually
+   exclusive.
+
+   An attribute description with N tagging options is a direct
+   (description) subtype of all attribute descriptions of the same
+   attribute type and all but one of the N options.  If the attribute
+   type has a supertype, then the attribute description is also a direct
+   (description) subtype of the attribute description of the supertype
+   and the N tagging options.  That is, 'cn;lang-de;lang-en' is a direct
+   (description) subtype of 'cn;lang-de', 'cn;lang-en', and
+   'name;lang-de;lang-en' ('cn' is a subtype of 'name'; both are defined
+   in [RFC4519]).
+
+2.5.3.  Attribute Description Hierarchies
+
+   An attribute description can be the direct subtype of zero or more
+   other attribute descriptions as indicated by attribute type subtyping
+   (as described in Section 2.5.1) or attribute tagging option subtyping
+   (as described in Section 2.5.2.1).  These subtyping relationships are
+   used to form hierarchies of attribute descriptions and attributes.
+
+
+
+
+Zeilenga                    Standards Track                    [Page 14]
+
+RFC 4512                      LDAP Models                      June 2006
+
+
+   As adapted from [X.501]:
+
+      Attribute hierarchies allow access to the DIB with varying degrees
+      of granularity.  This is achieved by allowing the value components
+      of attributes to be accessed by using either their specific
+      attribute description (a direct reference to the attribute) or a
+      more generic attribute description (an indirect reference).
+
+      Semantically related attributes may be placed in a hierarchical
+      relationship, the more specialized being placed subordinate to the
+      more generalized.  Searching for or retrieving attributes and
+      their values is made easier by quoting the more generalized
+      attribute description; a filter item so specified is evaluated for
+      the more specialized descriptions as well as for the quoted
+      description.
+
+      Where subordinate specialized descriptions are selected to be
+      returned as part of a search result these descriptions shall be
+      returned if available.  Where the more general descriptions are
+      selected to be returned as part of a search result both the
+      general and the specialized descriptions shall be returned, if
+      available.  An attribute value shall always be returned as a value
+      of its own attribute description.
+
+      All of the attribute descriptions in an attribute hierarchy are
+      treated as distinct and unrelated descriptions for user
+      modification of entry content.
+
+      An attribute value stored in an object or alias entry is of
+      precisely one attribute description.  The description is indicated
+      when the value is originally added to the entry.
+
+   For the purpose of subschema administration of the entry, a
+   specification that an attribute is required is fulfilled if the entry
+   contains a value of an attribute description belonging to an
+   attribute hierarchy where the attribute type of that description is
+   the same as the required attribute's type.  That is, a "MUST name"
+   specification is fulfilled by 'name' or 'name;x-tag-option', but is
+   not fulfilled by 'CN' or 'CN;x-tag-option' (even though 'CN' is a
+   subtype of 'name').  Likewise, an entry may contain a value of an
+   attribute description belonging to an attribute hierarchy where the
+   attribute type of that description is either explicitly included in
+   the definition of an object class to which the entry belongs or
+   allowed by the DIT content rule applicable to that entry.  That is,
+   'name' and 'name;x-tag-option' are allowed by "MAY name" (or by "MUST
+   name"), but 'CN' and 'CN;x-tag-option' are not allowed by "MAY name"
+   (or by "MUST name").
+
+
+
+
+Zeilenga                    Standards Track                    [Page 15]
+
+RFC 4512                      LDAP Models                      June 2006
+
+
+   For the purposes of other policy administration, unless stated
+   otherwise in the specification of the particular administrative
+   model, all of the attribute descriptions in an attribute hierarchy
+   are treated as distinct and unrelated descriptions.
+
+2.6.  Alias Entries
+
+   As adapted from [X.501]:
+
+      An alias, or an alias name, for an object is an alternative name
+      for an object or object entry which is provided by the use of
+      alias entries.
+
+      Each alias entry contains, within the 'aliasedObjectName'
+      attribute (known as the 'aliasedEntryName' attribute in X.500), a
+      name of some object.  The distinguished name of the alias entry is
+      thus also a name for this object.
+
+          NOTE - The name within the 'aliasedObjectName' is said to be
+                 pointed to by the alias.  It does not have to be the
+                 distinguished name of any entry.
+
+      The conversion of an alias name to an object name is termed
+      (alias) dereferencing and comprises the systematic replacement of
+      alias names, where found within a purported name, by the value of
+      the corresponding 'aliasedObjectName' attribute.  The process may
+      require the examination of more than one alias entry.
+
+      Any particular entry in the DIT may have zero or more alias names.
+      It therefore follows that several alias entries may point to the
+      same entry.  An alias entry may point to an entry that is not a
+      leaf entry and may point to another alias entry.
+
+      An alias entry shall have no subordinates, so that an alias entry
+      is always a leaf entry.
+
+      Every alias entry shall belong to the 'alias' object class.
+
+   An entry with the 'alias' object class must also belong to an object
+   class (or classes), or be governed by a DIT content rule, which
+   allows suitable naming attributes to be present.
+
+   Example:
+
+      dn: cn=bar,dc=example,dc=com
+      objectClass: top
+      objectClass: alias
+      objectClass: extensibleObject
+
+
+
+Zeilenga                    Standards Track                    [Page 16]
+
+RFC 4512                      LDAP Models                      June 2006
+
+
+      cn: bar
+      aliasedObjectName: cn=foo,dc=example,dc=com
+
+2.6.1.  'alias' Object Class
+
+   Alias entries belong to the 'alias' object class.
+
+      ( 2.5.6.1 NAME 'alias'
+        SUP top STRUCTURAL
+        MUST aliasedObjectName )
+
+2.6.2.  'aliasedObjectName' Attribute Type
+
+   The 'aliasedObjectName' attribute holds the name of the entry an
+   alias points to.  The 'aliasedObjectName' attribute is known as the
+   'aliasedEntryName' attribute in X.500.
+
+      ( 2.5.4.1 NAME 'aliasedObjectName'
+        EQUALITY distinguishedNameMatch
+        SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
+        SINGLE-VALUE )
+
+   The 'distinguishedNameMatch' matching rule and the DistinguishedName
+   (1.3.6.1.4.1.1466.115.121.1.12) syntax are defined in [RFC4517].
+
+3.  Directory Administrative and Operational Information
+
+   This section discusses select aspects of the X.500 Directory
+   Administrative and Operational Information model [X.501].  LDAP
+   implementations MAY support other aspects of this model.
+
+3.1.  Subtrees
+
+   As defined in [X.501]:
+
+      A subtree is a collection of object and alias entries situated at
+      the vertices of a tree.  Subtrees do not contain subentries.  The
+      prefix sub, in subtree, emphasizes that the base (or root) vertex
+      of this tree is usually subordinate to the root of the DIT.
+
+      A subtree begins at some vertex and extends to some identifiable
+      lower boundary, possibly extending to leaves.  A subtree is always
+      defined within a context which implicitly bounds the subtree.  For
+      example, the vertex and lower boundaries of a subtree defining a
+      replicated area are bounded by a naming context.
+
+
+
+
+
+
+Zeilenga                    Standards Track                    [Page 17]
+
+RFC 4512                      LDAP Models                      June 2006
+
+
+3.2.  Subentries
+
+   A subentry is a "special sort of entry, known by the Directory, used
+   to hold information associated with a subtree or subtree refinement"
+   [X.501].  Subentries are used in Directory to hold for administrative
+   and operational purposes as defined in [X.501].  Their use in LDAP is
+   detailed in [RFC3672].
+
+   The term "(sub)entry" in this specification indicates that servers
+   implementing X.500(93) models are, in accordance with X.500(93) as
+   described in [RFC3672], to use a subentry and that other servers are
+   to use an object entry belonging to the appropriate auxiliary class
+   normally used with the subentry (e.g., 'subschema' for subschema
+   subentries) to mimic the subentry.  This object entry's RDN SHALL be
+   formed from a value of the 'cn' (commonName) attribute [RFC4519] (as
+   all subentries are named with 'cn').
+
+3.3.  The 'objectClass' attribute
+
+   Each entry in the DIT has an 'objectClass' attribute.
+
+      ( 2.5.4.0 NAME 'objectClass'
+        EQUALITY objectIdentifierMatch
+        SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
+
+   The 'objectIdentifierMatch' matching rule and the OBJECT IDENTIFIER
+   (1.3.6.1.4.1.1466.115.121.1.38) syntax are defined in [RFC4517].
+
+   The 'objectClass' attribute specifies the object classes of an entry,
+   which (among other things) are used in conjunction with the
+   controlling schema to determine the permitted attributes of an entry.
+   Values of this attribute can be modified by clients, but the
+   'objectClass' attribute cannot be removed.
+
+   Servers that follow X.500(93) models SHALL restrict modifications of
+   this attribute to prevent the basic structural class of the entry
+   from being changed.  That is, one cannot change a 'person' into a
+   'country'.
+
+   When creating an entry or adding an 'objectClass' value to an entry,
+   all superclasses of the named classes SHALL be implicitly added as
+   well if not already present.  That is, if the auxiliary class 'x-a'
+   is a subclass of the class 'x-b', adding 'x-a' to 'objectClass'
+   causes 'x-b' to be implicitly added (if is not already present).
+
+   Servers SHALL restrict modifications of this attribute to prevent
+   superclasses of remaining 'objectClass' values from being deleted.
+   That is, if the auxiliary class 'x-a' is a subclass of the auxiliary
+
+
+
+Zeilenga                    Standards Track                    [Page 18]
+
+RFC 4512                      LDAP Models                      June 2006
+
+
+   class 'x-b' and the 'objectClass' attribute contains 'x-a' and 'x-b',
+   an attempt to delete only 'x-b' from the 'objectClass' attribute is
+   an error.
+
+3.4.  Operational Attributes
+
+   Some attributes, termed operational attributes, are used or
+   maintained by servers for administrative and operational purposes.
+   As stated in [X.501]: "There are three varieties of operational
+   attributes:  Directory operational attributes, DSA-shared operational
+   attributes, and DSA-specific operational attributes".
+
+   A directory operational attribute is used to represent operational
+   and/or administrative information in the Directory Information Model.
+   This includes operational attributes maintained by the server (e.g.,
+   'createTimestamp') as well as operational attributes that hold values
+   administrated by the user (e.g., 'ditContentRules').
+
+   A DSA-shared operational attribute is used to represent information
+   of the DSA Information Model that is shared between DSAs.
+
+   A DSA-specific operational attribute is used to represent information
+   of the DSA Information Model that is specific to the DSA (though, in
+   some cases, may be derived from information shared between DSAs;
+   e.g., 'namingContexts').
+
+   The DSA Information Model operational attributes are detailed in
+   [X.501].
+
+   Operational attributes are not normally visible.  They are not
+   returned in search results unless explicitly requested by name.
+
+   Not all operational attributes are user modifiable.
+
+   Entries may contain, among others, the following operational
+   attributes:
+
+      - creatorsName: the Distinguished Name of the user who added this
+          entry to the directory,
+
+      - createTimestamp: the time this entry was added to the directory,
+
+      - modifiersName: the Distinguished Name of the user who last
+          modified this entry, and
+
+      - modifyTimestamp: the time this entry was last modified.
+
+
+
+
+
+Zeilenga                    Standards Track                    [Page 19]
+
+RFC 4512                      LDAP Models                      June 2006
+
+
+   Servers SHOULD maintain the 'creatorsName', 'createTimestamp',
+   'modifiersName', and 'modifyTimestamp' attributes for all entries of
+   the DIT.
+
+3.4.1.  'creatorsName'
+
+   This attribute appears in entries that were added using the protocol
+   (e.g., using the Add operation).  The value is the distinguished name
+   of the creator.
+
+      ( 2.5.18.3 NAME 'creatorsName'
+        EQUALITY distinguishedNameMatch
+        SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
+        SINGLE-VALUE NO-USER-MODIFICATION
+        USAGE directoryOperation )
+
+   The 'distinguishedNameMatch' matching rule and the DistinguishedName
+   (1.3.6.1.4.1.1466.115.121.1.12) syntax are defined in [RFC4517].
+
+3.4.2.  'createTimestamp'
+
+   This attribute appears in entries that were added using the protocol
+   (e.g., using the Add operation).  The value is the time the entry was
+   added.
+
+      ( 2.5.18.1 NAME 'createTimestamp'
+        EQUALITY generalizedTimeMatch
+        ORDERING generalizedTimeOrderingMatch
+        SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
+        SINGLE-VALUE NO-USER-MODIFICATION
+        USAGE directoryOperation )
+
+   The 'generalizedTimeMatch' and 'generalizedTimeOrderingMatch'
+   matching rules and the GeneralizedTime
+   (1.3.6.1.4.1.1466.115.121.1.24) syntax are defined in [RFC4517].
+
+3.4.3.  'modifiersName'
+
+   This attribute appears in entries that have been modified using the
+   protocol (e.g., using the Modify operation).  The value is the
+   distinguished name of the last modifier.
+
+      ( 2.5.18.4 NAME 'modifiersName'
+        EQUALITY distinguishedNameMatch
+        SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
+        SINGLE-VALUE NO-USER-MODIFICATION
+        USAGE directoryOperation )
+
+
+
+
+Zeilenga                    Standards Track                    [Page 20]
+
+RFC 4512                      LDAP Models                      June 2006
+
+
+   The 'distinguishedNameMatch' matching rule and the DistinguishedName
+   (1.3.6.1.4.1.1466.115.121.1.12) syntax are defined in [RFC4517].
+
+3.4.4.  'modifyTimestamp'
+
+   This attribute appears in entries that have been modified using the
+   protocol (e.g., using the Modify operation).  The value is the time
+   the entry was last modified.
+
+      ( 2.5.18.2 NAME 'modifyTimestamp'
+        EQUALITY generalizedTimeMatch
+        ORDERING generalizedTimeOrderingMatch
+        SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
+        SINGLE-VALUE NO-USER-MODIFICATION
+        USAGE directoryOperation )
+
+   The 'generalizedTimeMatch' and 'generalizedTimeOrderingMatch'
+   matching rules and the GeneralizedTime
+   (1.3.6.1.4.1.1466.115.121.1.24) syntax are defined in [RFC4517].
+
+3.4.5.  'structuralObjectClass'
+
+   This attribute indicates the structural object class of the entry.
+
+      ( 2.5.21.9 NAME 'structuralObjectClass'
+        EQUALITY objectIdentifierMatch
+        SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
+        SINGLE-VALUE NO-USER-MODIFICATION
+        USAGE directoryOperation )
+
+   The 'objectIdentifierMatch' matching rule and OBJECT IDENTIFIER
+   (1.3.6.1.4.1.1466.115.121.1.38) syntax is defined in [RFC4517].
+
+3.4.6.  'governingStructureRule'
+
+   This attribute indicates the structure rule governing the entry.
+
+      ( 2.5.21.10 NAME 'governingStructureRule'
+        EQUALITY integerMatch
+        SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
+        SINGLE-VALUE NO-USER-MODIFICATION
+        USAGE directoryOperation )
+
+   The 'integerMatch' matching rule and INTEGER
+   (1.3.6.1.4.1.1466.115.121.1.27) syntax is defined in [RFC4517].
+
+
+
+
+
+
+Zeilenga                    Standards Track                    [Page 21]
+
+RFC 4512                      LDAP Models                      June 2006
+
+
+4.  Directory Schema
+
+   As defined in [X.501]:
+
+      The Directory Schema is a set of definitions and constraints
+      concerning the structure of the DIT, the possible ways entries are
+      named, the information that can be held in an entry, the
+      attributes used to represent that information and their
+      organization into hierarchies to facilitate search and retrieval
+      of the information and the ways in which values of attributes may
+      be matched in attribute value and matching rule assertions.
+
+      NOTE 1 - The schema enables the Directory system to, for example:
+
+      - prevent the creation of subordinate entries of the wrong
+        object-class (e.g., a country as a subordinate of a person);
+
+      - prevent the addition of attribute-types to an entry
+        inappropriate to the object-class (e.g., a serial number to a
+        person's entry);
+
+      - prevent the addition of an attribute value of a syntax not
+        matching that defined for the attribute-type (e.g., a printable
+        string to a bit string).
+
+      Formally, the Directory Schema comprises a set of:
+
+      a) Name Form definitions that define primitive naming relations
+         for structural object classes;
+
+      b) DIT Structure Rule definitions that define the names that
+         entries may have and the ways in which the entries may be
+         related to one another in the DIT;
+
+      c) DIT Content Rule definitions that extend the specification of
+         allowable attributes for entries beyond those indicated by the
+         structural object classes of the entries;
+
+      d) Object Class definitions that define the basic set of mandatory
+         and optional attributes that shall be present, and may be
+         present, respectively, in an entry of a given class, and which
+         indicate the kind of object class that is being defined;
+
+
+
+
+
+
+
+
+
+Zeilenga                    Standards Track                    [Page 22]
+
+RFC 4512                      LDAP Models                      June 2006
+
+
+      e) Attribute Type definitions that identify the object identifier
+         by which an attribute is known, its syntax, associated matching
+         rules, whether it is an operational attribute and if so its
+         type, whether it is a collective attribute, whether it is
+         permitted to have multiple values and whether or not it is
+         derived from another attribute type;
+
+      f) Matching Rule definitions that define matching rules.
+
+      And in LDAP:
+
+      g) LDAP Syntax definitions that define encodings used in LDAP.
+
+4.1.  Schema Definitions
+
+   Schema definitions in this section are described using ABNF and rely
+   on the common productions specified in Section 1.2 as well as these:
+
+      noidlen = numericoid [ LCURLY len RCURLY ]
+      len = number
+
+      oids = oid / ( LPAREN WSP oidlist WSP RPAREN )
+      oidlist = oid *( WSP DOLLAR WSP oid )
+
+      extensions = *( SP xstring SP qdstrings )
+      xstring = "X" HYPHEN 1*( ALPHA / HYPHEN / USCORE )
+
+      qdescrs = qdescr / ( LPAREN WSP qdescrlist WSP RPAREN )
+      qdescrlist = [ qdescr *( SP qdescr ) ]
+      qdescr = SQUOTE descr SQUOTE
+
+      qdstrings = qdstring / ( LPAREN WSP qdstringlist WSP RPAREN )
+      qdstringlist = [ qdstring *( SP qdstring ) ]
+      qdstring = SQUOTE dstring SQUOTE
+      dstring = 1*( QS / QQ / QUTF8 )   ; escaped UTF-8 string
+
+      QQ =  ESC %x32 %x37 ; "\27"
+      QS =  ESC %x35 ( %x43 / %x63 ) ; "\5C" / "\5c"
+
+      ; Any UTF-8 encoded Unicode character
+      ; except %x27 ("\'") and %x5C ("\")
+      QUTF8    = QUTF1 / UTFMB
+
+      ; Any ASCII character except %x27 ("\'") and %x5C ("\")
+      QUTF1    = %x00-26 / %x28-5B / %x5D-7F
+
+   Schema definitions in this section also share a number of common
+   terms.
+
+
+
+Zeilenga                    Standards Track                    [Page 23]
+
+RFC 4512                      LDAP Models                      June 2006
+
+
+   The NAME field provides a set of short names (descriptors) that are
+   to be used as aliases for the OID.
+
+   The DESC field optionally allows a descriptive string to be provided
+   by the directory administrator and/or implementor.  While
+   specifications may suggest a descriptive string, there is no
+   requirement that the suggested (or any) descriptive string be used.
+
+   The OBSOLETE field, if present, indicates the element is not active.
+
+   Implementors should note that future versions of this document may
+   expand these definitions to include additional terms.  Terms whose
+   identifier begins with "X-" are reserved for private experiments and
+   are followed by <SP> and <qdstrings> tokens.
+
+4.1.1.  Object Class Definitions
+
+   Object Class definitions are written according to the ABNF:
+
+     ObjectClassDescription = LPAREN WSP
+         numericoid                 ; object identifier
+         [ SP "NAME" SP qdescrs ]   ; short names (descriptors)
+         [ SP "DESC" SP qdstring ]  ; description
+         [ SP "OBSOLETE" ]          ; not active
+         [ SP "SUP" SP oids ]       ; superior object classes
+         [ SP kind ]                ; kind of class
+         [ SP "MUST" SP oids ]      ; attribute types
+         [ SP "MAY" SP oids ]       ; attribute types
+         extensions WSP RPAREN
+
+     kind = "ABSTRACT" / "STRUCTURAL" / "AUXILIARY"
+
+   where:
+     <numericoid> is object identifier assigned to this object class;
+     NAME <qdescrs> are short names (descriptors) identifying this
+         object class;
+     DESC <qdstring> is a short descriptive string;
+     OBSOLETE indicates this object class is not active;
+     SUP <oids> specifies the direct superclasses of this object class;
+     the kind of object class is indicated by one of ABSTRACT,
+         STRUCTURAL, or AUXILIARY (the default is STRUCTURAL);
+     MUST and MAY specify the sets of required and allowed attribute
+         types, respectively; and
+     <extensions> describe extensions.
+
+
+
+
+
+
+
+Zeilenga                    Standards Track                    [Page 24]
+
+RFC 4512                      LDAP Models                      June 2006
+
+
+4.1.2.  Attribute Types
+
+   Attribute Type definitions are written according to the ABNF:
+
+     AttributeTypeDescription = LPAREN WSP
+         numericoid                    ; object identifier
+         [ SP "NAME" SP qdescrs ]      ; short names (descriptors)
+         [ SP "DESC" SP qdstring ]     ; description
+         [ SP "OBSOLETE" ]             ; not active
+         [ SP "SUP" SP oid ]           ; supertype
+         [ SP "EQUALITY" SP oid ]      ; equality matching rule
+         [ SP "ORDERING" SP oid ]      ; ordering matching rule
+         [ SP "SUBSTR" SP oid ]        ; substrings matching rule
+         [ SP "SYNTAX" SP noidlen ]    ; value syntax
+         [ SP "SINGLE-VALUE" ]         ; single-value
+         [ SP "COLLECTIVE" ]           ; collective
+         [ SP "NO-USER-MODIFICATION" ] ; not user modifiable
+         [ SP "USAGE" SP usage ]       ; usage
+         extensions WSP RPAREN         ; extensions
+
+     usage = "userApplications"     /  ; user
+             "directoryOperation"   /  ; directory operational
+             "distributedOperation" /  ; DSA-shared operational
+             "dSAOperation"            ; DSA-specific operational
+
+   where:
+     <numericoid> is object identifier assigned to this attribute type;
+     NAME <qdescrs> are short names (descriptors) identifying this
+         attribute type;
+     DESC <qdstring> is a short descriptive string;
+     OBSOLETE indicates this attribute type is not active;
+     SUP oid specifies the direct supertype of this type;
+     EQUALITY, ORDERING, and SUBSTR provide the oid of the equality,
+         ordering, and substrings matching rules, respectively;
+     SYNTAX identifies value syntax by object identifier and may suggest
+         a minimum upper bound;
+     SINGLE-VALUE indicates attributes of this type are restricted to a
+         single value;
+     COLLECTIVE indicates this attribute type is collective
+         [X.501][RFC3671];
+     NO-USER-MODIFICATION indicates this attribute type is not user
+         modifiable;
+     USAGE indicates the application of this attribute type; and
+     <extensions> describe extensions.
+
+   Each attribute type description must contain at least one of the SUP
+   or SYNTAX fields.  If no SYNTAX field is provided, the attribute type
+   description takes its value from the supertype.
+
+
+
+Zeilenga                    Standards Track                    [Page 25]
+
+RFC 4512                      LDAP Models                      June 2006
+
+
+   If SUP field is provided, the EQUALITY, ORDERING, and SUBSTRING
+   fields, if not specified, take their value from the supertype.
+
+   Usage of userApplications, the default, indicates that attributes of
+   this type represent user information.  That is, they are user
+   attributes.
+
+   A usage of directoryOperation, distributedOperation, or dSAOperation
+   indicates that attributes of this type represent operational and/or
+   administrative information.  That is, they are operational
+   attributes.
+
+   directoryOperation usage indicates that the attribute of this type is
+   a directory operational attribute.  distributedOperation usage
+   indicates that the attribute of this type is a DSA-shared usage
+   operational attribute.  dSAOperation usage indicates that the
+   attribute of this type is a DSA-specific operational attribute.
+
+   COLLECTIVE requires usage userApplications.  Use of collective
+   attribute types in LDAP is discussed in [RFC3671].
+
+   NO-USER-MODIFICATION requires an operational usage.
+
+   Note that the <AttributeTypeDescription> does not list the matching
+   rules that can be used with that attribute type in an extensibleMatch
+   search filter [RFC4511].  This is done using the 'matchingRuleUse'
+   attribute described in Section 4.1.4.
+
+   This document refines the schema description of X.501 by requiring
+   that the SYNTAX field in an <AttributeTypeDescription> be a string
+   representation of an object identifier for the LDAP string syntax
+   definition, with an optional indication of the suggested minimum
+   bound of a value of this attribute.
+
+   A suggested minimum upper bound on the number of characters in a
+   value with a string-based syntax, or the number of bytes in a value
+   for all other syntaxes, may be indicated by appending this bound
+   count inside of curly braces following the syntax's OBJECT IDENTIFIER
+   in an Attribute Type Description.  This bound is not part of the
+   syntax name itself.  For instance, "1.3.6.4.1.1466.0{64}" suggests
+   that server implementations should allow a string to be 64 characters
+   long, although they may allow longer strings.  Note that a single
+   character of the Directory String syntax may be encoded in more than
+   one octet since UTF-8 [RFC3629] is a variable-length encoding.
+
+
+
+
+
+
+
+Zeilenga                    Standards Track                    [Page 26]
+
+RFC 4512                      LDAP Models                      June 2006
+
+
+4.1.3.  Matching Rules
+
+   Matching rules are used in performance of attribute value assertions,
+   such as in performance of a Compare operation.  They are also used in
+   evaluating search filters, determining which individual values are to
+   be added or deleted during performance of a Modify operation, and in
+   comparing distinguished names.
+
+   Each matching rule is identified by an object identifier (OID) and,
+   optionally, one or more short names (descriptors).
+
+   Matching rule definitions are written according to the ABNF:
+
+     MatchingRuleDescription = LPAREN WSP
+         numericoid                 ; object identifier
+         [ SP "NAME" SP qdescrs ]   ; short names (descriptors)
+         [ SP "DESC" SP qdstring ]  ; description
+         [ SP "OBSOLETE" ]          ; not active
+         SP "SYNTAX" SP numericoid  ; assertion syntax
+         extensions WSP RPAREN      ; extensions
+
+   where:
+     <numericoid> is object identifier assigned to this matching rule;
+     NAME <qdescrs> are short names (descriptors) identifying this
+         matching rule;
+     DESC <qdstring> is a short descriptive string;
+     OBSOLETE indicates this matching rule is not active;
+     SYNTAX identifies the assertion syntax (the syntax of the assertion
+         value) by object identifier; and
+     <extensions> describe extensions.
+
+4.1.4.  Matching Rule Uses
+
+   A matching rule use lists the attribute types that are suitable for
+   use with an extensibleMatch search filter.
+
+   Matching rule use descriptions are written according to the following
+   ABNF:
+
+     MatchingRuleUseDescription = LPAREN WSP
+         numericoid                 ; object identifier
+         [ SP "NAME" SP qdescrs ]   ; short names (descriptors)
+         [ SP "DESC" SP qdstring ]  ; description
+         [ SP "OBSOLETE" ]          ; not active
+         SP "APPLIES" SP oids       ; attribute types
+         extensions WSP RPAREN      ; extensions
+
+
+
+
+
+Zeilenga                    Standards Track                    [Page 27]
+
+RFC 4512                      LDAP Models                      June 2006
+
+
+   where:
+     <numericoid> is the object identifier of the matching rule
+         associated with this matching rule use description;
+     NAME <qdescrs> are short names (descriptors) identifying this
+         matching rule use;
+     DESC <qdstring> is a short descriptive string;
+     OBSOLETE indicates this matching rule use is not active;
+     APPLIES provides a list of attribute types the matching rule
+         applies to; and
+     <extensions> describe extensions.
+
+4.1.5.  LDAP Syntaxes
+
+   LDAP Syntaxes of (attribute and assertion) values are described in
+   terms of ASN.1 [X.680] and, optionally, have an octet string encoding
+   known as the LDAP-specific encoding.  Commonly, the LDAP-specific
+   encoding is constrained to a string of Unicode [Unicode] characters
+   in UTF-8 [RFC3629] form.
+
+   Each LDAP syntax is identified by an object identifier (OID).
+
+   LDAP syntax definitions are written according to the ABNF:
+
+     SyntaxDescription = LPAREN WSP
+         numericoid                 ; object identifier
+         [ SP "DESC" SP qdstring ]  ; description
+         extensions WSP RPAREN      ; extensions
+
+   where:
+     <numericoid> is the object identifier assigned to this LDAP syntax;
+     DESC <qdstring> is a short descriptive string; and
+     <extensions> describe extensions.
+
+4.1.6.  DIT Content Rules
+
+   A DIT content rule is a "rule governing the content of entries of a
+   particular structural object class" [X.501].
+
+   For DIT entries of a particular structural object class, a DIT
+   content rule specifies which auxiliary object classes the entries are
+   allowed to belong to and which additional attributes (by type) are
+   required, allowed, or not allowed to appear in the entries.
+
+   The list of precluded attributes cannot include any attribute listed
+   as mandatory in the rule, the structural object class, or any of the
+   allowed auxiliary object classes.
+
+
+
+
+
+Zeilenga                    Standards Track                    [Page 28]
+
+RFC 4512                      LDAP Models                      June 2006
+
+
+   Each content rule is identified by the object identifier, as well as
+   any short names (descriptors), of the structural object class it
+   applies to.
+
+   An entry may only belong to auxiliary object classes listed in the
+   governing content rule.
+
+   An entry must contain all attributes required by the object classes
+   the entry belongs to as well as all attributes required by the
+   governing content rule.
+
+   An entry may contain any non-precluded attributes allowed by the
+   object classes the entry belongs to as well as all attributes allowed
+   by the governing content rule.
+
+   An entry cannot include any attribute precluded by the governing
+   content rule.
+
+   An entry is governed by (if present and active in the subschema) the
+   DIT content rule that applies to the structural object class of the
+   entry (see Section 2.4.2).  If no active rule is present for the
+   entry's structural object class, the entry's content is governed by
+   the structural object class (and possibly other aspects of user and
+   system schema).  DIT content rules for superclasses of the structural
+   object class of an entry are not applicable to that entry.
+
+   DIT content rule descriptions are written according to the ABNF:
+
+     DITContentRuleDescription = LPAREN WSP
+         numericoid                 ; object identifier
+         [ SP "NAME" SP qdescrs ]   ; short names (descriptors)
+         [ SP "DESC" SP qdstring ]  ; description
+         [ SP "OBSOLETE" ]          ; not active
+         [ SP "AUX" SP oids ]       ; auxiliary object classes
+         [ SP "MUST" SP oids ]      ; attribute types
+         [ SP "MAY" SP oids ]       ; attribute types
+         [ SP "NOT" SP oids ]       ; attribute types
+         extensions WSP RPAREN      ; extensions
+
+   where:
+     <numericoid> is the object identifier of the structural object
+         class associated with this DIT content rule;
+     NAME <qdescrs> are short names (descriptors) identifying this DIT
+         content rule;
+     DESC <qdstring> is a short descriptive string;
+     OBSOLETE indicates this DIT content rule use is not active;
+     AUX specifies a list of auxiliary object classes that entries
+         subject to this DIT content rule may belong to;
+
+
+
+Zeilenga                    Standards Track                    [Page 29]
+
+RFC 4512                      LDAP Models                      June 2006
+
+
+     MUST, MAY, and NOT specify lists of attribute types that are
+         required, allowed, or precluded, respectively, from appearing
+         in entries subject to this DIT content rule; and
+     <extensions> describe extensions.
+
+4.1.7.  DIT Structure Rules and Name Forms
+
+   It is sometimes desirable to regulate where object and alias entries
+   can be placed in the DIT and how they can be named based upon their
+   structural object class.
+
+4.1.7.1.  DIT Structure Rules
+
+   A DIT structure rule is a "rule governing the structure of the DIT by
+   specifying a permitted superior to subordinate entry relationship.  A
+   structure rule relates a name form, and therefore a structural object
+   class, to superior structure rules.  This permits entries of the
+   structural object class identified by the name form to exist in the
+   DIT as subordinates to entries governed by the indicated superior
+   structure rules" [X.501].
+
+   DIT structure rule descriptions are written according to the ABNF:
+
+     DITStructureRuleDescription = LPAREN WSP
+         ruleid                     ; rule identifier
+         [ SP "NAME" SP qdescrs ]   ; short names (descriptors)
+         [ SP "DESC" SP qdstring ]  ; description
+         [ SP "OBSOLETE" ]          ; not active
+         SP "FORM" SP oid           ; NameForm
+         [ SP "SUP" ruleids ]       ; superior rules
+         extensions WSP RPAREN      ; extensions
+
+     ruleids = ruleid / ( LPAREN WSP ruleidlist WSP RPAREN )
+     ruleidlist = ruleid *( SP ruleid )
+     ruleid = number
+
+   where:
+     <ruleid> is the rule identifier of this DIT structure rule;
+     NAME <qdescrs> are short names (descriptors) identifying this DIT
+         structure rule;
+     DESC <qdstring> is a short descriptive string;
+     OBSOLETE indicates this DIT structure rule use is not active;
+     FORM is specifies the name form associated with this DIT structure
+         rule;
+     SUP identifies superior rules (by rule id); and
+     <extensions> describe extensions.
+
+
+
+
+
+Zeilenga                    Standards Track                    [Page 30]
+
+RFC 4512                      LDAP Models                      June 2006
+
+
+   If no superior rules are identified, the DIT structure rule applies
+   to an autonomous administrative point (e.g., the root vertex of the
+   subtree controlled by the subschema) [X.501].
+
+4.1.7.2.  Name Forms
+
+   A name form "specifies a permissible RDN for entries of a particular
+   structural object class.  A name form identifies a named object class
+   and one or more attribute types to be used for naming (i.e., for the
+   RDN).  Name forms are primitive pieces of specification used in the
+   definition of DIT structure rules" [X.501].
+
+   Each name form indicates the structural object class to be named, a
+   set of required attribute types, and a set of allowed attribute
+   types.  A particular attribute type cannot be in both sets.
+
+   Entries governed by the form must be named using a value from each
+   required attribute type and zero or more values from the allowed
+   attribute types.
+
+   Each name form is identified by an object identifier (OID) and,
+   optionally, one or more short names (descriptors).
+
+   Name form descriptions are written according to the ABNF:
+
+     NameFormDescription = LPAREN WSP
+         numericoid                 ; object identifier
+         [ SP "NAME" SP qdescrs ]   ; short names (descriptors)
+         [ SP "DESC" SP qdstring ]  ; description
+         [ SP "OBSOLETE" ]          ; not active
+         SP "OC" SP oid             ; structural object class
+         SP "MUST" SP oids          ; attribute types
+         [ SP "MAY" SP oids ]       ; attribute types
+         extensions WSP RPAREN      ; extensions
+
+   where:
+     <numericoid> is object identifier that identifies this name form;
+     NAME <qdescrs> are short names (descriptors) identifying this name
+         form;
+     DESC <qdstring> is a short descriptive string;
+     OBSOLETE indicates this name form is not active;
+     OC identifies the structural object class this rule applies to,
+     MUST and MAY specify the sets of required and allowed,
+         respectively, naming attributes for this name form; and
+     <extensions> describe extensions.
+
+   All attribute types in the required ("MUST") and allowed ("MAY")
+   lists shall be different.
+
+
+
+Zeilenga                    Standards Track                    [Page 31]
+
+RFC 4512                      LDAP Models                      June 2006
+
+
+4.2.  Subschema Subentries
+
+   Subschema (sub)entries are used for administering information about
+   the directory schema.  A single subschema (sub)entry contains all
+   schema definitions (see Section 4.1) used by entries in a particular
+   part of the directory tree.
+
+   Servers that follow X.500(93) models SHOULD implement subschema using
+   the X.500 subschema mechanisms (as detailed in Section 12 of
+   [X.501]), so these are not ordinary object entries but subentries
+   (see Section 3.2).  LDAP clients SHOULD NOT assume that servers
+   implement any of the other aspects of X.500 subschema.
+
+   Servers MAY allow subschema modification.  Procedures for subschema
+   modification are discussed in Section 14.5 of [X.501].
+
+   A server that masters entries and permits clients to modify these
+   entries SHALL implement and provide access to these subschema
+   (sub)entries including providing a 'subschemaSubentry' attribute in
+   each modifiable entry.  This is so clients may discover the
+   attributes and object classes that are permitted to be present.  It
+   is strongly RECOMMENDED that all other servers implement this as
+   well.
+
+   The value of the 'subschemaSubentry' attribute is the name of the
+   subschema (sub)entry holding the subschema controlling the entry.
+
+      ( 2.5.18.10 NAME 'subschemaSubentry'
+        EQUALITY distinguishedNameMatch
+        SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
+        SINGLE-VALUE NO-USER-MODIFICATION
+        USAGE directoryOperation )
+
+   The 'distinguishedNameMatch' matching rule and the DistinguishedName
+   (1.3.6.1.4.1.1466.115.121.1.12) syntax are defined in [RFC4517].
+
+   Subschema is held in (sub)entries belonging to the subschema
+   auxiliary object class.
+
+      ( 2.5.20.1 NAME 'subschema' AUXILIARY
+        MAY ( dITStructureRules $ nameForms $ ditContentRules $
+          objectClasses $ attributeTypes $ matchingRules $
+          matchingRuleUse ) )
+
+   The 'ldapSyntaxes' operational attribute may also be present in
+   subschema entries.
+
+
+
+
+
+Zeilenga                    Standards Track                    [Page 32]
+
+RFC 4512                      LDAP Models                      June 2006
+
+
+   Servers MAY provide additional attributes (described in other
+   documents) in subschema (sub)entries.
+
+   Servers SHOULD provide the attributes 'createTimestamp' and
+   'modifyTimestamp' in subschema (sub)entries, in order to allow
+   clients to maintain their caches of schema information.
+
+   The following subsections provide attribute type definitions for each
+   of schema definition attribute types.
+
+4.2.1.  'objectClasses'
+
+   This attribute holds definitions of object classes.
+
+      ( 2.5.21.6 NAME 'objectClasses'
+        EQUALITY objectIdentifierFirstComponentMatch
+        SYNTAX 1.3.6.1.4.1.1466.115.121.1.37
+        USAGE directoryOperation )
+
+   The 'objectIdentifierFirstComponentMatch' matching rule and the
+   ObjectClassDescription (1.3.6.1.4.1.1466.115.121.1.37) syntax are
+   defined in [RFC4517].
+
+4.2.2.  'attributeTypes'
+
+   This attribute holds definitions of attribute types.
+
+      ( 2.5.21.5 NAME 'attributeTypes'
+        EQUALITY objectIdentifierFirstComponentMatch
+        SYNTAX 1.3.6.1.4.1.1466.115.121.1.3
+        USAGE directoryOperation )
+
+   The 'objectIdentifierFirstComponentMatch' matching rule and the
+   AttributeTypeDescription (1.3.6.1.4.1.1466.115.121.1.3) syntax are
+   defined in [RFC4517].
+
+4.2.3.  'matchingRules'
+
+   This attribute holds definitions of matching rules.
+
+      ( 2.5.21.4 NAME 'matchingRules'
+        EQUALITY objectIdentifierFirstComponentMatch
+        SYNTAX 1.3.6.1.4.1.1466.115.121.1.30
+        USAGE directoryOperation )
+
+   The 'objectIdentifierFirstComponentMatch' matching rule and the
+   MatchingRuleDescription (1.3.6.1.4.1.1466.115.121.1.30) syntax are
+   defined in [RFC4517].
+
+
+
+Zeilenga                    Standards Track                    [Page 33]
+
+RFC 4512                      LDAP Models                      June 2006
+
+
+4.2.4 'matchingRuleUse'
+
+   This attribute holds definitions of matching rule uses.
+
+      ( 2.5.21.8 NAME 'matchingRuleUse'
+        EQUALITY objectIdentifierFirstComponentMatch
+        SYNTAX 1.3.6.1.4.1.1466.115.121.1.31
+        USAGE directoryOperation )
+
+   The 'objectIdentifierFirstComponentMatch' matching rule and the
+   MatchingRuleUseDescription (1.3.6.1.4.1.1466.115.121.1.31) syntax are
+   defined in [RFC4517].
+
+4.2.5.  'ldapSyntaxes'
+
+   This attribute holds definitions of LDAP syntaxes.
+
+      ( 1.3.6.1.4.1.1466.101.120.16 NAME 'ldapSyntaxes'
+        EQUALITY objectIdentifierFirstComponentMatch
+        SYNTAX 1.3.6.1.4.1.1466.115.121.1.54
+        USAGE directoryOperation )
+
+   The 'objectIdentifierFirstComponentMatch' matching rule and the
+   SyntaxDescription (1.3.6.1.4.1.1466.115.121.1.54) syntax are defined
+   in [RFC4517].
+
+4.2.6.  'dITContentRules'
+
+   This attribute lists DIT Content Rules that are present in the
+   subschema.
+
+      ( 2.5.21.2 NAME 'dITContentRules'
+        EQUALITY objectIdentifierFirstComponentMatch
+        SYNTAX 1.3.6.1.4.1.1466.115.121.1.16
+        USAGE directoryOperation )
+
+   The 'objectIdentifierFirstComponentMatch' matching rule and the
+   DITContentRuleDescription (1.3.6.1.4.1.1466.115.121.1.16) syntax are
+   defined in [RFC4517].
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga                    Standards Track                    [Page 34]
+
+RFC 4512                      LDAP Models                      June 2006
+
+
+4.2.7.  'dITStructureRules'
+
+   This attribute lists DIT Structure Rules that are present in the
+   subschema.
+
+      ( 2.5.21.1 NAME 'dITStructureRules'
+        EQUALITY integerFirstComponentMatch
+        SYNTAX 1.3.6.1.4.1.1466.115.121.1.17
+        USAGE directoryOperation )
+
+   The 'integerFirstComponentMatch' matching rule and the
+   DITStructureRuleDescription (1.3.6.1.4.1.1466.115.121.1.17) syntax
+   are defined in [RFC4517].
+
+4.2.8 'nameForms'
+
+   This attribute lists Name Forms that are in force.
+
+      ( 2.5.21.7 NAME 'nameForms'
+        EQUALITY objectIdentifierFirstComponentMatch
+        SYNTAX 1.3.6.1.4.1.1466.115.121.1.35
+        USAGE directoryOperation )
+
+   The 'objectIdentifierFirstComponentMatch' matching rule and the
+   NameFormDescription (1.3.6.1.4.1.1466.115.121.1.35) syntax are
+   defined in [RFC4517].
+
+4.3.  'extensibleObject' object class
+
+   The 'extensibleObject' auxiliary object class allows entries that
+   belong to it to hold any user attribute.  The set of allowed
+   attribute types of this object class is implicitly the set of all
+   attribute types of userApplications usage.
+
+      ( 1.3.6.1.4.1.1466.101.120.111 NAME 'extensibleObject'
+        SUP top AUXILIARY )
+
+   The mandatory attributes of the other object classes of this entry
+   are still required to be present, and any precluded attributes are
+   still not allowed to be present.
+
+4.4.  Subschema Discovery
+
+   To discover the DN of the subschema (sub)entry holding the subschema
+   controlling a particular entry, a client reads that entry's
+   'subschemaSubentry' operational attribute.  To read schema attributes
+   from the subschema (sub)entry, clients MUST issue a Search operation
+   [RFC4511] where baseObject is the DN of the subschema (sub)entry,
+
+
+
+Zeilenga                    Standards Track                    [Page 35]
+
+RFC 4512                      LDAP Models                      June 2006
+
+
+   scope is baseObject, filter is "(objectClass=subschema)" [RFC4515],
+   and the attributes field lists the names of the desired schema
+   attributes (as they are operational).  Note: the
+   "(objectClass=subschema)" filter allows LDAP servers that gateway to
+   X.500 to detect that subentry information is being requested.
+
+   Clients SHOULD NOT assume that a published subschema is complete,
+   that the server supports all of the schema elements it publishes, or
+   that the server does not support an unpublished element.
+
+5.  DSA (Server) Informational Model
+
+   The LDAP protocol assumes there are one or more servers that jointly
+   provide access to a Directory Information Tree (DIT).  The server
+   holding the original information is called the "master" (for that
+   information).  Servers that hold copies of the original information
+   are referred to as "shadowing" or "caching" servers.
+
+
+   As defined in [X.501]:
+
+      context prefix: The sequence of RDNs leading from the Root of the
+          DIT to the initial vertex of a naming context; corresponds to
+          the distinguished name of that vertex.
+
+      naming context: A subtree of entries held in a single master DSA.
+
+   That is, a naming context is the largest collection of entries,
+   starting at an entry that is mastered by a particular server, and
+   including all its subordinates and their subordinates, down to the
+   entries that are mastered by different servers.  The context prefix
+   is the name of the initial entry.
+
+   The root of the DIT is a DSA-specific Entry (DSE) and not part of any
+   naming context (or any subtree); each server has different attribute
+   values in the root DSE.
+
+5.1.  Server-Specific Data Requirements
+
+   An LDAP server SHALL provide information about itself and other
+   information that is specific to each server.  This is represented as
+   a group of attributes located in the root DSE, which is named with
+   the DN with zero RDNs (whose [RFC4514] representation is as the
+   zero-length string).
+
+   These attributes are retrievable, subject to access control and other
+   restrictions, if a client performs a Search operation [RFC4511] with
+   an empty baseObject, scope of baseObject, the filter
+
+
+
+Zeilenga                    Standards Track                    [Page 36]
+
+RFC 4512                      LDAP Models                      June 2006
+
+
+   "(objectClass=*)" [RFC4515], and the attributes field listing the
+   names of the desired attributes.  It is noted that root DSE
+   attributes are operational and, like other operational attributes,
+   are not returned in search requests unless requested by name.
+
+   The root DSE SHALL NOT be included if the client performs a subtree
+   search starting from the root.
+
+   Servers may allow clients to modify attributes of the root DSE, where
+   appropriate.
+
+   The following attributes of the root DSE are defined below.
+   Additional attributes may be defined in other documents.
+
+      - altServer: alternative servers;
+
+      - namingContexts: naming contexts;
+
+      - supportedControl: recognized LDAP controls;
+
+      - supportedExtension: recognized LDAP extended operations;
+
+      - supportedFeatures: recognized LDAP features;
+
+      - supportedLDAPVersion: LDAP versions supported; and
+
+      - supportedSASLMechanisms: recognized Simple Authentication and
+        Security Layers (SASL) [RFC4422] mechanisms.
+
+   The values provided for these attributes may depend on session-
+   specific and other factors.  For example, a server supporting the
+   SASL EXTERNAL mechanism might only list "EXTERNAL" when the client's
+   identity has been established by a lower level.  See [RFC4513].
+
+   The root DSE may also include a 'subschemaSubentry' attribute.  If it
+   does, the attribute refers to the subschema (sub)entry holding the
+   schema controlling the root DSE.  Clients SHOULD NOT assume that this
+   subschema (sub)entry controls other entries held by the server.
+   General subschema discovery procedures are provided in Section 4.4.
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga                    Standards Track                    [Page 37]
+
+RFC 4512                      LDAP Models                      June 2006
+
+
+5.1.1.  'altServer'
+
+   The 'altServer' attribute lists URIs referring to alternative servers
+   that may be contacted when this server becomes unavailable.  URIs for
+   servers implementing the LDAP are written according to [RFC4516].
+   Other kinds of URIs may be provided.  If the server does not know of
+   any other servers that could be used, this attribute will be absent.
+   Clients may cache this information in case their preferred server
+   later becomes unavailable.
+
+      ( 1.3.6.1.4.1.1466.101.120.6 NAME 'altServer'
+        SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
+        USAGE dSAOperation )
+
+   The IA5String (1.3.6.1.4.1.1466.115.121.1.26) syntax is defined in
+   [RFC4517].
+
+5.1.2.  'namingContexts'
+
+   The 'namingContexts' attribute lists the context prefixes of the
+   naming contexts the server masters or shadows (in part or in whole).
+   If the server is a first-level DSA [X.501], it should list (in
+   addition) an empty string (indicating the root of the DIT).  If the
+   server does not master or shadow any information (e.g., it is an LDAP
+   gateway to a public X.500 directory) this attribute will be absent.
+   If the server believes it masters or shadows the entire directory,
+   the attribute will have a single value, and that value will be the
+   empty string (indicating the root of the DIT).
+
+   This attribute may be used, for example, to select a suitable entry
+   name for subsequent operations with this server.
+
+      ( 1.3.6.1.4.1.1466.101.120.5 NAME 'namingContexts'
+        SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
+        USAGE dSAOperation )
+
+   The DistinguishedName (1.3.6.1.4.1.1466.115.121.1.12) syntax is
+   defined in [RFC4517].
+
+5.1.3.  'supportedControl'
+
+   The 'supportedControl' attribute lists object identifiers identifying
+   the request controls [RFC4511] the server supports.  If the server
+   does not support any request controls, this attribute will be absent.
+   Object identifiers identifying response controls need not be listed.
+
+   Procedures for registering object identifiers used to discovery of
+   protocol mechanisms are detailed in BCP 64, RFC 4520 [RFC4520].
+
+
+
+Zeilenga                    Standards Track                    [Page 38]
+
+RFC 4512                      LDAP Models                      June 2006
+
+
+      ( 1.3.6.1.4.1.1466.101.120.13 NAME 'supportedControl'
+        SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
+        USAGE dSAOperation )
+
+   The OBJECT IDENTIFIER (1.3.6.1.4.1.1466.115.121.1.38) syntax is
+   defined in [RFC4517].
+
+5.1.4.  'supportedExtension'
+
+   The 'supportedExtension' attribute lists object identifiers
+   identifying the extended operations [RFC4511] that the server
+   supports.  If the server does not support any extended operations,
+   this attribute will be absent.
+
+   An extended operation generally consists of an extended request and
+   an extended response but may also include other protocol data units
+   (such as intermediate responses).  The object identifier assigned to
+   the extended request is used to identify the extended operation.
+   Other object identifiers used in the extended operation need not be
+   listed as values of this attribute.
+
+   Procedures for registering object identifiers used to discovery of
+   protocol mechanisms are detailed in BCP 64, RFC 4520 [RFC4520].
+
+      ( 1.3.6.1.4.1.1466.101.120.7 NAME 'supportedExtension'
+        SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
+        USAGE dSAOperation )
+
+   The OBJECT IDENTIFIER (1.3.6.1.4.1.1466.115.121.1.38) syntax is
+   defined in [RFC4517].
+
+5.1.5.  'supportedFeatures'
+
+   The 'supportedFeatures' attribute lists object identifiers
+   identifying elective features that the server supports.  If the
+   server does not support any discoverable elective features, this
+   attribute will be absent.
+
+      ( 1.3.6.1.4.1.4203.1.3.5 NAME 'supportedFeatures'
+          EQUALITY objectIdentifierMatch
+          SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
+          USAGE dSAOperation )
+
+   Procedures for registering object identifiers used to discovery of
+   protocol mechanisms are detailed in BCP 64, RFC 4520 [RFC4520].
+
+   The OBJECT IDENTIFIER (1.3.6.1.4.1.1466.115.121.1.38) syntax and
+   objectIdentifierMatch matching rule are defined in [RFC4517].
+
+
+
+Zeilenga                    Standards Track                    [Page 39]
+
+RFC 4512                      LDAP Models                      June 2006
+
+
+5.1.6.  'supportedLDAPVersion'
+
+   The 'supportedLDAPVersion' attribute lists the versions of LDAP that
+   the server supports.
+
+      ( 1.3.6.1.4.1.1466.101.120.15 NAME 'supportedLDAPVersion'
+        SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
+        USAGE dSAOperation )
+
+   The INTEGER (1.3.6.1.4.1.1466.115.121.1.27) syntax is defined in
+   [RFC4517].
+
+5.1.7.  'supportedSASLMechanisms'
+
+   The 'supportedSASLMechanisms' attribute lists the SASL mechanisms
+   [RFC4422] that the server recognizes and/or supports [RFC4513].  The
+   contents of this attribute may depend on the current session state.
+   If the server does not support any SASL mechanisms, this attribute
+   will not be present.
+
+      ( 1.3.6.1.4.1.1466.101.120.14 NAME 'supportedSASLMechanisms'
+        SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+        USAGE dSAOperation )
+
+   The Directory String (1.3.6.1.4.1.1466.115.121.1.15) syntax is
+   defined in [RFC4517].
+
+6.  Other Considerations
+
+6.1.  Preservation of User Information
+
+   Syntaxes may be defined that have specific value and/or value form
+   (representation) preservation requirements.  For example, a syntax
+   containing digitally signed data can mandate that the server preserve
+   both the value and form of value presented to ensure that the
+   signature is not invalidated.
+
+   Where such requirements have not been explicitly stated, servers
+   SHOULD preserve the value of user information but MAY return the
+   value in a different form.  And where a server is unable (or
+   unwilling) to preserve the value of user information, the server
+   SHALL ensure that an equivalent value (per Section 2.3) is returned.
+
+
+
+
+
+
+
+
+
+Zeilenga                    Standards Track                    [Page 40]
+
+RFC 4512                      LDAP Models                      June 2006
+
+
+6.2.  Short Names
+
+   Short names, also known as descriptors, are used as more readable
+   aliases for object identifiers and are used to identify various
+   schema elements.  However, it is not expected that LDAP
+   implementations with human user interface would display these short
+   names (or the object identifiers they refer to) to the user.
+   Instead, they would most likely be performing translations (such as
+   expressing the short name in one of the local national languages).
+   For example, the short name "st" (stateOrProvinceName) might be
+   displayed to a German-speaking user as "Land".
+
+   The same short name might have different meaning in different
+   subschemas, and, within a particular subschema, the same short name
+   might refer to different object identifiers each identifying a
+   different kind of schema element.
+
+   Implementations MUST be prepared that the same short name might be
+   used in a subschema to refer to the different kinds of schema
+   elements.  That is, there might be an object class 'x-fubar' and an
+   attribute type 'x-fubar' in a subschema.
+
+   Implementations MUST be prepared that the same short name might be
+   used in the different subschemas to refer to the different schema
+   elements.  That is, there might be two matching rules 'x-fubar', each
+   in different subschemas.
+
+   Procedures for registering short names (descriptors) are detailed in
+   BCP 64, RFC 4520 [RFC4520].
+
+6.3.  Cache and Shadowing
+
+   Some servers may hold cache or shadow copies of entries, which can be
+   used to answer search and comparison queries, but will return
+   referrals or contact other servers if modification operations are
+   requested.  Servers that perform shadowing or caching MUST ensure
+   that they do not violate any access control constraints placed on the
+   data by the originating server.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga                    Standards Track                    [Page 41]
+
+RFC 4512                      LDAP Models                      June 2006
+
+
+7.  Implementation Guidelines
+
+7.1.  Server Guidelines
+
+   Servers MUST recognize all names of attribute types and object
+   classes defined in this document but, unless stated otherwise, need
+   not support the associated functionality.  Servers SHOULD recognize
+   all the names of attribute types and object classes defined in
+   Section 3 and 4, respectively, of [RFC4519].
+
+   Servers MUST ensure that entries conform to user and system schema
+   rules or other data model constraints.
+
+   Servers MAY support DIT Content Rules.  Servers MAY support DIT
+   Structure Rules and Name Forms.
+
+   Servers MAY support alias entries.
+
+   Servers MAY support the 'extensibleObject' object class.
+
+   Servers MAY support subentries.  If so, they MUST do so in accordance
+   with [RFC3672].  Servers that do not support subentries SHOULD use
+   object entries to mimic subentries as detailed in Section 3.2.
+
+   Servers MAY implement additional schema elements.  Servers SHOULD
+   provide definitions of all schema elements they support in subschema
+   (sub)entries.
+
+7.2.  Client Guidelines
+
+   In the absence of prior agreements with servers, clients SHOULD NOT
+   assume that servers support any particular schema elements beyond
+   those referenced in Section 7.1.  The client can retrieve subschema
+   information as described in Section 4.4.
+
+   Clients MUST NOT display or attempt to decode a value as ASN.1 if the
+   value's syntax is not known.  Clients MUST NOT assume the LDAP-
+   specific string encoding is restricted to a UTF-8 encoded string of
+   Unicode characters or any particular subset of Unicode (such as a
+   printable subset) unless such restriction is explicitly stated.
+   Clients SHOULD NOT send attribute values in a request that are not
+   valid according to the syntax defined for the attributes.
+
+
+
+
+
+
+
+
+
+Zeilenga                    Standards Track                    [Page 42]
+
+RFC 4512                      LDAP Models                      June 2006
+
+
+8.  Security Considerations
+
+   Attributes of directory entries are used to provide descriptive
+   information about the real-world objects they represent, which can be
+   people, organizations, or devices.  Most countries have privacy laws
+   regarding the publication of information about people.
+
+   General security considerations for accessing directory information
+   with LDAP are discussed in [RFC4511] and [RFC4513].
+
+9.  IANA Considerations
+
+   The Internet Assigned Numbers Authority (IANA) has updated the LDAP
+   descriptors registry as indicated in the following template:
+
+      Subject: Request for LDAP Descriptor Registration Update
+      Descriptor (short name): see comment
+      Object Identifier: see comment
+      Person & email address to contact for further information:
+          Kurt Zeilenga <kurt@OpenLDAP.org>
+      Usage: see comment
+      Specification: RFC 4512
+      Author/Change Controller: IESG
+      Comments:
+
+      The following descriptors (short names) has been added to
+      the registry.
+
+        NAME                         Type OID
+        ------------------------     ---- -----------------
+        governingStructureRule          A 2.5.21.10
+        structuralObjectClass           A 2.5.21.9
+
+      The following descriptors (short names) have been updated to
+      refer to this RFC.
+
+        NAME                         Type OID
+        ------------------------     ---- -----------------
+        alias                           O 2.5.6.1
+        aliasedObjectName               A 2.5.4.1
+        altServer                       A 1.3.6.1.4.1.1466.101.120.6
+        attributeTypes                  A 2.5.21.5
+        createTimestamp                 A 2.5.18.1
+        creatorsName                    A 2.5.18.3
+        dITContentRules                 A 2.5.21.2
+        dITStructureRules               A 2.5.21.1
+        extensibleObject                O 1.3.6.1.4.1.1466.101.120.111
+        ldapSyntaxes                    A 1.3.6.1.4.1.1466.101.120.16
+
+
+
+Zeilenga                    Standards Track                    [Page 43]
+
+RFC 4512                      LDAP Models                      June 2006
+
+
+        matchingRuleUse                 A 2.5.21.8
+        matchingRules                   A 2.5.21.4
+        modifiersName                   A 2.5.18.4
+        modifyTimestamp                 A 2.5.18.2
+        nameForms                       A 2.5.21.7
+        namingContexts                  A 1.3.6.1.4.1.1466.101.120.5
+        objectClass                     A 2.5.4.0
+        objectClasses                   A 2.5.21.6
+        subschema                       O 2.5.20.1
+        subschemaSubentry               A 2.5.18.10
+        supportedControl                A 1.3.6.1.4.1.1466.101.120.13
+        supportedExtension              A 1.3.6.1.4.1.1466.101.120.7
+        supportedFeatures               A 1.3.6.1.4.1.4203.1.3.5
+        supportedLDAPVersion            A 1.3.6.1.4.1.1466.101.120.15
+        supportedSASLMechanisms         A 1.3.6.1.4.1.1466.101.120.14
+        top                             O 2.5.6.0
+
+10.  Acknowledgements
+
+   This document is based in part on RFC 2251 by M. Wahl, T. Howes, and
+   S. Kille; RFC 2252 by M. Wahl, A. Coulbeck, T. Howes, S. Kille; and
+   RFC 2556 by M. Wahl, all products of the IETF Access, Searching and
+   Indexing of Directories (ASID) Working Group.  This document is also
+   based in part on "The Directory: Models" [X.501], a product of the
+   International Telephone Union (ITU).  Additional text was borrowed
+   from RFC 2253 by M. Wahl, T. Howes, and S. Kille.
+
+   This document is a product of the IETF LDAP Revision (LDAPBIS)
+   Working Group.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga                    Standards Track                    [Page 44]
+
+RFC 4512                      LDAP Models                      June 2006
+
+
+11.  Normative References
+
+   [RFC2119]     Bradner, S., "Key words for use in RFCs to Indicate
+                 Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC3629]     Yergeau, F., "UTF-8, a transformation format of ISO
+                 10646", STD 63, RFC 3629, November 2003.
+
+   [RFC3671]     Zeilenga, K., "Collective Attributes in the Lightweight
+                 Directory Access Protocol (LDAP)", RFC 3671, December
+                 2003.
+
+   [RFC3672]     Zeilenga, K., "Subentries in the Lightweight Directory
+                 Access Protocol (LDAP)", RFC 3672, December 2003.
+
+   [RFC4234]     Crocker, D. and P. Overell, "Augmented BNF for Syntax
+                 Specifications: ABNF", RFC 4234, October 2005.
+
+   [RFC4422]     Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple
+                 Authentication and Security Layer (SASL)", RFC 4422,
+                 June 2006.
+
+   [RFC4510]     Zeilenga, K., Ed., "Lightweight Directory Access
+                 Protocol (LDAP): Technical Specification Road Map", RFC
+                 4510, June 2006.
+
+   [RFC4511]     Sermersheim, J., Ed., "Lightweight Directory Access
+                 Protocol (LDAP): The Protocol", RFC 4511, June 2006.
+
+   [RFC4513]     Harrison, R., Ed., "Lightweight Directory Access
+                 Protocol (LDAP): Authentication Methods and Security
+                 Mechanisms", RFC 4513, June 2006.
+
+   [RFC4514]     Zeilenga, K., Ed., "Lightweight Directory Access
+                 Protocol (LDAP): String Representation of Distinguished
+                 Names", RFC 4514, June 2006.
+
+   [RFC4515]     Smith, M., Ed. and T. Howes, "Lightweight Directory
+                 Access Protocol (LDAP): String Representation of Search
+                 Filters", RFC 4515, June 2006.
+
+   [RFC4516]     Smith, M., Ed. and T. Howes, "Lightweight Directory
+                 Access Protocol (LDAP): Uniform Resource Locator", RFC
+                 4516, June 2006.
+
+   [RFC4517]     Legg, S., Ed., "Lightweight Directory Access Protocol
+                 (LDAP): Syntaxes and Matching Rules", RFC 4517, June
+                 2006.
+
+
+
+Zeilenga                    Standards Track                    [Page 45]
+
+RFC 4512                      LDAP Models                      June 2006
+
+
+   [RFC4519]     Sciberras, A., Ed., "Lightweight Directory Access
+                 Protocol (LDAP): Schema for User Applications", RFC
+                 4519, June 2006.
+
+   [RFC4520]     Zeilenga, K., "Internet Assigned Numbers Authority
+                 (IANA) Considerations for the Lightweight Directory
+                 Access Protocol (LDAP)", BCP 64, RFC 4520, June 2006.
+
+   [Unicode]     The Unicode Consortium, "The Unicode Standard, Version
+                 3.2.0" is defined by "The Unicode Standard, Version
+                 3.0" (Reading, MA, Addison-Wesley, 2000.  ISBN 0-201-
+                 61633-5), as amended by the "Unicode Standard Annex
+                 #27: Unicode 3.1"
+                 (http://www.unicode.org/reports/tr27/) and by the
+                 "Unicode Standard Annex #28: Unicode 3.2"
+                 (http://www.unicode.org/reports/tr28/).
+
+   [X.500]       International Telecommunication Union -
+                 Telecommunication Standardization Sector, "The
+                 Directory -- Overview of concepts, models and
+                 services," X.500(1993) (also ISO/IEC 9594-1:1994).
+
+   [X.501]       International Telecommunication Union -
+                 Telecommunication Standardization Sector, "The
+                 Directory -- Models," X.501(1993) (also ISO/IEC 9594-
+                 2:1994).
+
+   [X.680]       International Telecommunication Union -
+                 Telecommunication Standardization Sector, "Abstract
+                 Syntax Notation One (ASN.1) - Specification of Basic
+                 Notation", X.680(2002) (also ISO/IEC 8824-1:2002).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga                    Standards Track                    [Page 46]
+
+RFC 4512                      LDAP Models                      June 2006
+
+
+Appendix A.  Changes
+
+   This appendix is non-normative.
+
+   This document amounts to nearly a complete rewrite of portions of RFC
+   2251, RFC 2252, and RFC 2256.  This rewrite was undertaken to improve
+   overall clarity of technical specification.  This appendix provides a
+   summary of substantive changes made to the portions of these
+   documents incorporated into this document.  Readers should consult
+   [RFC4510], [RFC4511], [RFC4517], and [RFC4519] for summaries of
+   remaining portions of these documents.
+
+A.1.  Changes to RFC 2251
+
+   This document incorporates from RFC 2251, Sections 3.2 and 3.4, and
+   portions of Sections 4 and 6 as summarized below.
+
+A.1.1.  Section 3.2 of RFC 2251
+
+   Section 3.2 of RFC 2251 provided a brief introduction to the X.500
+   data model, as used by LDAP.  The previous specification relied on
+   [X.501] but lacked clarity in how X.500 models are adapted for use by
+   LDAP.  This document describes the X.500 data models, as used by
+   LDAP, in greater detail, especially in areas where adaptation is
+   needed.
+
+   Section 3.2.1 of RFC 2251 described an attribute as "a type with one
+   or more associated values".  In LDAP, an attribute is better
+   described as an attribute description, a type with zero or more
+   options, and one or more associated values.
+
+   Section 3.2.2 of RFC 2251 mandated that subschema subentries contain
+   objectClasses and attributeTypes attributes, yet X.500(93) treats
+   these attributes as optional.  While generally all implementations
+   that support X.500(93) subschema mechanisms will provide both of
+   these attributes, it is not absolutely required for interoperability
+   that all servers do.  The mandate was removed for consistency with
+   X.500(93).   The subschema discovery mechanism was also clarified to
+   indicate that subschema controlling an entry is obtained by reading
+   the (sub)entry referred to by that entry's 'subschemaSubentry'
+   attribute.
+
+
+
+
+
+
+
+
+
+
+Zeilenga                    Standards Track                    [Page 47]
+
+RFC 4512                      LDAP Models                      June 2006
+
+
+A.1.2.  Section 3.4 of RFC 2251
+
+   Section 3.4 of RFC 2251 provided "Server-specific Data Requirements".
+   This material, with changes, was incorporated in Section 5.1 of this
+   document.
+
+   Changes:
+
+   - Clarify that attributes of the root DSE are subject to "other
+     restrictions" in addition to access controls.
+
+   - Clarify that only recognized extended requests need to be
+     enumerated 'supportedExtension'.
+
+   - Clarify that only recognized request controls need to be enumerated
+     'supportedControl'.
+
+   - Clarify that root DSE attributes are operational and, like other
+     operational attributes, will not be returned in search requests
+     unless requested by name.
+
+   - Clarify that not all root DSE attributes are user modifiable.
+
+   - Remove inconsistent text regarding handling of the
+     'subschemaSubentry' attribute within the root DSE.  The previous
+     specification stated that the 'subschemaSubentry' attribute held in
+     the root DSE referred to "subschema entries (or subentries) known
+     by this server".  This is inconsistent with the attribute's
+     intended use as well as its formal definition as a single valued
+     attribute [X.501].  It is also noted that a simple (possibly
+     incomplete) list of subschema (sub)entries is not terribly useful.
+     This document (in Section 5.1) specifies that the
+     'subschemaSubentry' attribute of the root DSE refers to the
+     subschema controlling the root DSE.  It is noted that the general
+     subschema discovery mechanism remains available (see Section 4.4 of
+     this document).
+
+A.1.3.  Section 4 of RFC 2251
+
+   Portions of Section 4 of RFC 2251 detailing aspects of the
+   information model used by LDAP were incorporated in this document,
+   including:
+
+   - Restriction of distinguished values to attributes whose
+     descriptions have no options (from Section 4.1.3);
+
+
+
+
+
+
+Zeilenga                    Standards Track                    [Page 48]
+
+RFC 4512                      LDAP Models                      June 2006
+
+
+   - Data model aspects of Attribute Types (from Section 4.1.4),
+     Attribute Descriptions (from 4.1.5), Attribute (from 4.1.8),
+     Matching Rule Identifier (from 4.1.9); and
+
+   - User schema requirements (from Sections 4.1.6, 4.5.1, and 4.7).
+
+   Clarifications to these portions include:
+
+   - Subtyping and AttributeDescriptions with options.
+
+A.1.4.  Section 6 of RFC 2251
+
+   The Section 6.1 and the second paragraph of Section 6.2 of RFC 2251
+   where incorporated into this document.
+
+A.2.  Changes to RFC 2252
+
+   This document incorporates Sections 4, 5, and 7 from RFC 2252.
+
+A.2.1.  Section 4 of RFC 2252
+
+   The specification was updated to use Augmented BNF [RFC4234].  The
+   string representation of an OBJECT IDENTIFIER was tightened to
+   disallow leading zeros as described in RFC 2252.
+
+   The <descr> syntax was changed to disallow semicolon (U+003B)
+   characters in order to appear to be consistent its natural language
+   specification "descr is the syntactic representation of an object
+   descriptor, which consists of letters and digits, starting with a
+   letter".  In a related change, the statement "an AttributeDescription
+   can be used as the value in a NAME part of an
+   AttributeTypeDescription" was deleted.  RFC 2252 provided no
+   specification of the semantics of attribute options appearing in NAME
+   fields.
+
+   RFC 2252 stated that the <descr> form of <oid> SHOULD be preferred
+   over the <numericoid> form.  However, <descr> form can be ambiguous.
+   To address this issue, the imperative was replaced with a statement
+   (in Section 1.4) that while the <descr> form is generally preferred,
+   <numericoid> should be used where an unambiguous <descr> is not
+   available.  Additionally, an expanded discussion of descriptor issues
+   is in Section 6.2 ("Short Names").
+
+   The ABNF for a quoted string (qdstring) was updated to reflect
+   support for the escaping mechanism described in Section 4.3 of RFC
+   2252.
+
+
+
+
+
+Zeilenga                    Standards Track                    [Page 49]
+
+RFC 4512                      LDAP Models                      June 2006
+
+
+A.2.2.  Section 5 of RFC 2252
+
+   Definitions of operational attributes provided in Section 5 of RFC
+   2252 where incorporated into this document.
+
+   The 'namingContexts' description was clarified.  A first-level DSA
+   should publish, in addition to other values, "" indicating the root
+   of the DIT.
+
+   The 'altServer' description was clarified.  It may hold any URI.
+
+   The 'supportedExtension' description was clarified.  A server need
+   only list the OBJECT IDENTIFIERs associated with the extended
+   requests of the extended operations it recognizes.
+
+   The 'supportedControl' description was clarified.  A server need only
+   list the OBJECT IDENTIFIERs associated with the request controls it
+   recognizes.
+
+   Descriptions for the 'structuralObjectClass' and
+   'governingStructureRule' operational attribute types were added.
+
+   The attribute definition of 'subschemaSubentry' was corrected to list
+   the terms SINGLE-VALUE and NO-USER-MODIFICATION in proper order.
+
+A.2.3.  Section 7 of RFC 2252
+
+   Section 7 of RFC 2252 provides definitions of the 'subschema' and
+   'extensibleObject' object classes.  These definitions where
+   integrated into Section 4.2 and Section 4.3 of this document,
+   respectively.  Section 7 of RFC 2252 also contained the object class
+   implementation requirement.  This was incorporated into Section 7 of
+   this document.
+
+   The specification of 'extensibleObject' was clarified regarding how
+   it interacts with precluded attributes.
+
+A.3.  Changes to RFC 2256
+
+   This document incorporates Sections 5.1, 5.2, 7.1, and 7.2 of RFC
+   2256.
+
+   Section 5.1 of RFC 2256 provided the definition of the 'objectClass'
+   attribute type.  This was integrated into Section 2.4.1 of this
+   document.  The statement "One of the values is either 'top' or
+   'alias'" was replaced with statement that one of the values is 'top'
+   as entries belonging to 'alias' also belong to 'top'.
+
+
+
+
+Zeilenga                    Standards Track                    [Page 50]
+
+RFC 4512                      LDAP Models                      June 2006
+
+
+   Section 5.2 of RFC 2256 provided the definition of the
+   'aliasedObjectName' attribute type.  This was integrated into Section
+   2.6.2 of this document.
+
+   Section 7.1 of RFC 2256 provided the definition of the 'top' object
+   class.  This was integrated into Section 2.4.1 of this document.
+
+   Section 7.2 of RFC 2256 provided the definition of the 'alias' object
+   class.  This was integrated into Section 2.6.1 of this document.
+
+A.4.  Changes to RFC 3674
+
+   This document made no substantive change to the 'supportedFeatures'
+   technical specification provided in RFC 3674.
+
+Editor's Address
+
+   Kurt D.  Zeilenga
+   OpenLDAP Foundation
+
+   EMail: Kurt@OpenLDAP.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga                    Standards Track                    [Page 51]
+
+RFC 4512                      LDAP Models                      June 2006
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2006).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Zeilenga                    Standards Track                    [Page 52]
+
diff --git a/source4/ldap_server/devdocs/rfc4513.txt b/source4/ldap_server/devdocs/rfc4513.txt
new file mode 100644
index 0000000000..7e6e7eb4bd
--- /dev/null
+++ b/source4/ldap_server/devdocs/rfc4513.txt
@@ -0,0 +1,1907 @@
+
+
+
+
+
+
+Network Working Group                                   R. Harrison, Ed.
+Request for Comments: 4513                                  Novell, Inc.
+Obsoletes: 2251, 2829, 2830                                    June 2006
+Category: Standards Track
+
+
+             Lightweight Directory Access Protocol (LDAP):
+             Authentication Methods and Security Mechanisms
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   This document describes authentication methods and security
+   mechanisms of the Lightweight Directory Access Protocol (LDAP).  This
+   document details establishment of Transport Layer Security (TLS)
+   using the StartTLS operation.
+
+   This document details the simple Bind authentication method including
+   anonymous, unauthenticated, and name/password mechanisms and the
+   Simple Authentication and Security Layer (SASL) Bind authentication
+   method including the EXTERNAL mechanism.
+
+   This document discusses various authentication and authorization
+   states through which a session to an LDAP server may pass and the
+   actions that trigger these state changes.
+
+   This document, together with other documents in the LDAP Technical
+   Specification (see Section 1 of the specification's road map),
+   obsoletes RFC 2251, RFC 2829, and RFC 2830.
+
+
+
+
+
+
+
+
+
+
+
+Harrison                    Standards Track                     [Page 1]
+
+RFC 4513              LDAP Authentication Methods              June 2006
+
+
+Table of Contents
+
+   1. Introduction ....................................................4
+      1.1. Relationship to Other Documents ............................6
+      1.2. Conventions ................................................6
+   2. Implementation Requirements .....................................7
+   3. StartTLS Operation ..............................................8
+      3.1.  TLS Establishment Procedures ..............................8
+           3.1.1. StartTLS Request Sequencing .........................8
+           3.1.2. Client Certificate ..................................9
+           3.1.3. Server Identity Check ...............................9
+                  3.1.3.1. Comparison of DNS Names ...................10
+                  3.1.3.2. Comparison of IP Addresses ................11
+                  3.1.3.3. Comparison of Other subjectName Types .....11
+           3.1.4. Discovery of Resultant Security Level ..............11
+           3.1.5. Refresh of Server Capabilities Information .........11
+      3.2.  Effect of TLS on Authorization State .....................12
+      3.3. TLS Ciphersuites ..........................................12
+   4. Authorization State ............................................13
+   5. Bind Operation .................................................14
+      5.1. Simple Authentication Method ..............................14
+           5.1.1. Anonymous Authentication Mechanism of Simple Bind ..14
+           5.1.2. Unauthenticated Authentication Mechanism of
+                  Simple Bind ........................................14
+           5.1.3. Name/Password Authentication Mechanism of
+                  Simple Bind ........................................15
+      5.2. SASL Authentication Method ................................16
+           5.2.1. SASL Protocol Profile ..............................16
+                  5.2.1.1. SASL Service Name for LDAP ................16
+                  5.2.1.2. SASL Authentication Initiation and
+                           Protocol Exchange .........................16
+                  5.2.1.3. Optional Fields ...........................17
+                  5.2.1.4. Octet Where Negotiated Security
+                           Layers Take Effect ........................18
+                  5.2.1.5. Determination of Supported SASL
+                           Mechanisms ................................18
+                  5.2.1.6. Rules for Using SASL Layers ...............19
+                  5.2.1.7. Support for Multiple Authentications ......19
+                  5.2.1.8. SASL Authorization Identities .............19
+           5.2.2. SASL Semantics within LDAP .........................20
+           5.2.3. SASL EXTERNAL Authentication Mechanism .............20
+                  5.2.3.1. Implicit Assertion ........................21
+                  5.2.3.2. Explicit Assertion ........................21
+   6. Security Considerations ........................................21
+      6.1. General LDAP Security Considerations ......................21
+      6.2. StartTLS Security Considerations ..........................22
+      6.3. Bind Operation Security Considerations ....................23
+           6.3.1. Unauthenticated Mechanism Security Considerations ..23
+
+
+
+Harrison                    Standards Track                     [Page 2]
+
+RFC 4513              LDAP Authentication Methods              June 2006
+
+
+           6.3.2. Name/Password Mechanism Security Considerations ....23
+           6.3.3. Password-Related Security Considerations ...........23
+           6.3.4. Hashed Password Security Considerations ............24
+      6.4. SASL Security Considerations ..............................24
+      6.5. Related Security Considerations ...........................25
+   7. IANA Considerations ............................................25
+   8. Acknowledgements ...............................................25
+   9. Normative References ...........................................26
+   10. Informative References ........................................27
+   Appendix A. Authentication and Authorization Concepts .............28
+      A.1. Access Control Policy .....................................28
+      A.2. Access Control Factors ....................................28
+      A.3. Authentication, Credentials, Identity .....................28
+      A.4. Authorization Identity ....................................29
+   Appendix B. Summary of Changes ....................................29
+      B.1. Changes Made to RFC 2251 ..................................30
+           B.1.1. Section 4.2.1 ("Sequencing of the Bind Request") ...30
+           B.1.2. Section 4.2.2 ("Authentication and Other Security
+                  Services") .........................................30
+      B.2. Changes Made to RFC 2829 ..................................30
+           B.2.1. Section 4 ("Required security mechanisms") .........30
+           B.2.2. Section 5.1 ("Anonymous authentication
+                  procedure") ........................................31
+           B.2.3. Section 6 ("Password-based authentication") ........31
+           B.2.4. Section 6.1 ("Digest authentication") ..............31
+           B.2.5. Section 6.2 ("'simple' authentication choice under
+                  TLS encryption") ...................................31
+           B.2.6. Section 6.3 ("Other authentication choices with
+                  TLS") ..............................................31
+           B.2.7. Section 7.1 ("Certificate-based authentication
+                  with TLS") .........................................31
+           B.2.8. Section 8 ("Other mechanisms") .....................32
+           B.2.9. Section 9 ("Authorization Identity") ...............32
+           B.2.10. Section 10 ("TLS Ciphersuites") ...................32
+      B.3. Changes Made to RFC 2830 ..................................32
+           B.3.1. Section 3.6 ("Server Identity Check") ..............32
+           B.3.2. Section 3.7 ("Refresh of Server Capabilities
+                  Information") ......................................33
+           B.3.3. Section 5 ("Effects of TLS on a Client's
+                  Authorization Identity") ...........................33
+           B.3.4. Section 5.2 ("TLS Connection Closure Effects") .....33
+
+
+
+
+
+
+
+
+
+
+Harrison                    Standards Track                     [Page 3]
+
+RFC 4513              LDAP Authentication Methods              June 2006
+
+
+1.  Introduction
+
+   The Lightweight Directory Access Protocol (LDAP) [RFC4510] is a
+   powerful protocol for accessing directories.  It offers means of
+   searching, retrieving, and manipulating directory content and ways to
+   access a rich set of security functions.
+
+   It is vital that these security functions be interoperable among all
+   LDAP clients and servers on the Internet; therefore there has to be a
+   minimum subset of security functions that is common to all
+   implementations that claim LDAP conformance.
+
+   Basic threats to an LDAP directory service include (but are not
+   limited to):
+
+   (1) Unauthorized access to directory data via data-retrieval
+       operations.
+
+   (2) Unauthorized access to directory data by monitoring access of
+       others.
+
+   (3) Unauthorized access to reusable client authentication information
+       by monitoring access of others.
+
+   (4) Unauthorized modification of directory data.
+
+   (5) Unauthorized modification of configuration information.
+
+   (6) Denial of Service: Use of resources (commonly in excess) in a
+       manner intended to deny service to others.
+
+   (7) Spoofing: Tricking a user or client into believing that
+       information came from the directory when in fact it did not,
+       either by modifying data in transit or misdirecting the client's
+       transport connection.  Tricking a user or client into sending
+       privileged information to a hostile entity that appears to be the
+       directory server but is not.  Tricking a directory server into
+       believing that information came from a particular client when in
+       fact it came from a hostile entity.
+
+   (8) Hijacking: An attacker seizes control of an established protocol
+       session.
+
+   Threats (1), (4), (5), (6), (7), and (8) are active attacks.  Threats
+   (2) and (3) are passive attacks.
+
+
+
+
+
+
+Harrison                    Standards Track                     [Page 4]
+
+RFC 4513              LDAP Authentication Methods              June 2006
+
+
+   Threats (1), (4), (5), and (6) are due to hostile clients.  Threats
+   (2), (3), (7), and (8) are due to hostile agents on the path between
+   client and server or hostile agents posing as a server, e.g., IP
+   spoofing.
+
+   LDAP offers the following security mechanisms:
+
+   (1) Authentication by means of the Bind operation.  The Bind
+       operation provides a simple method that supports anonymous,
+       unauthenticated, and name/password mechanisms, and the Simple
+       Authentication and Security Layer (SASL) method, which supports a
+       wide variety of authentication mechanisms.
+
+   (2) Mechanisms to support vendor-specific access control facilities
+       (LDAP does not offer a standard access control facility).
+
+   (3) Data integrity service by means of security layers in Transport
+       Layer Security (TLS) or SASL mechanisms.
+
+   (4) Data confidentiality service by means of security layers in TLS
+       or SASL mechanisms.
+
+   (5) Server resource usage limitation by means of administrative
+       limits configured on the server.
+
+   (6) Server authentication by means of the TLS protocol or SASL
+       mechanisms.
+
+   LDAP may also be protected by means outside the LDAP protocol, e.g.,
+   with IP layer security [RFC4301].
+
+   Experience has shown that simply allowing implementations to pick and
+   choose the security mechanisms that will be implemented is not a
+   strategy that leads to interoperability.  In the absence of mandates,
+   clients will continue to be written that do not support any security
+   function supported by the server, or worse, they will only support
+   mechanisms that provide inadequate security for most circumstances.
+
+   It is desirable to allow clients to authenticate using a variety of
+   mechanisms including mechanisms where identities are represented as
+   distinguished names [X.501][RFC4512], in string form [RFC4514], or as
+   used in different systems (e.g., simple user names [RFC4013]).
+   Because some authentication mechanisms transmit credentials in plain
+   text form, and/or do not provide data security services and/or are
+   subject to passive attacks, it is necessary to ensure secure
+   interoperability by identifying a mandatory-to-implement mechanism
+   for establishing transport-layer security services.
+
+
+
+
+Harrison                    Standards Track                     [Page 5]
+
+RFC 4513              LDAP Authentication Methods              June 2006
+
+
+   The set of security mechanisms provided in LDAP and described in this
+   document is intended to meet the security needs for a wide range of
+   deployment scenarios and still provide a high degree of
+   interoperability among various LDAP implementations and deployments.
+
+1.1.  Relationship to Other Documents
+
+   This document is an integral part of the LDAP Technical Specification
+   [RFC4510].
+
+   This document, together with [RFC4510], [RFC4511], and [RFC4512],
+   obsoletes RFC 2251 in its entirety.  Sections 4.2.1 (portions) and
+   4.2.2 of RFC 2251 are obsoleted by this document.  Appendix B.1
+   summarizes the substantive changes made to RFC 2251 by this document.
+
+   This document obsoletes RFC 2829 in its entirety.  Appendix B.2
+   summarizes the substantive changes made to RFC 2829 by this document.
+
+   Sections 2 and 4 of RFC 2830 are obsoleted by [RFC4511].  The
+   remainder of RFC 2830 is obsoleted by this document.  Appendix B.3
+   summarizes the substantive changes made to RFC 2830 by this document.
+
+1.2.  Conventions
+
+   The key words "MUST", "MUST NOT", "SHALL", "SHOULD", "SHOULD NOT",
+   "MAY", and "OPTIONAL" in this document are to be interpreted as
+   described in RFC 2119 [RFC2119].
+
+   The term "user" represents any human or application entity that is
+   accessing the directory using a directory client.  A directory client
+   (or client) is also known as a directory user agent (DUA).
+
+   The term "transport connection" refers to the underlying transport
+   services used to carry the protocol exchange, as well as associations
+   established by these services.
+
+   The term "TLS layer" refers to TLS services used in providing
+   security services, as well as associations established by these
+   services.
+
+   The term "SASL layer" refers to SASL services used in providing
+   security services, as well as associations established by these
+   services.
+
+   The term "LDAP message layer" refers to the LDAP Message (PDU)
+   services used in providing directory services, as well as
+   associations established by these services.
+
+
+
+
+Harrison                    Standards Track                     [Page 6]
+
+RFC 4513              LDAP Authentication Methods              June 2006
+
+
+   The term "LDAP session" refers to combined services (transport
+   connection, TLS layer, SASL layer, LDAP message layer) and their
+   associations.
+
+   In general, security terms in this document are used consistently
+   with the definitions provided in [RFC2828].  In addition, several
+   terms and concepts relating to security, authentication, and
+   authorization are presented in Appendix A of this document.  While
+   the formal definition of these terms and concepts is outside the
+   scope of this document, an understanding of them is prerequisite to
+   understanding much of the material in this document.  Readers who are
+   unfamiliar with security-related concepts are encouraged to review
+   Appendix A before reading the remainder of this document.
+
+2.  Implementation Requirements
+
+   LDAP server implementations MUST support the anonymous authentication
+   mechanism of the simple Bind method (Section 5.1.1).
+
+   LDAP implementations that support any authentication mechanism other
+   than the anonymous authentication mechanism of the simple Bind method
+   MUST support the name/password authentication mechanism of the simple
+   Bind method (Section 5.1.3) and MUST be capable of protecting this
+   name/password authentication using TLS as established by the StartTLS
+   operation (Section 3).
+
+   Implementations SHOULD disallow the use of the name/password
+   authentication mechanism by default when suitable data security
+   services are not in place, and they MAY provide other suitable data
+   security services for use with this authentication mechanism.
+
+   Implementations MAY support additional authentication mechanisms.
+   Some of these mechanisms are discussed below.
+
+   LDAP server implementations SHOULD support client assertion of
+   authorization identity via the SASL EXTERNAL mechanism (Section
+   5.2.3).
+
+   LDAP server implementations that support no authentication mechanism
+   other than the anonymous mechanism of the simple bind method SHOULD
+   support use of TLS as established by the StartTLS operation (Section
+   3).  (Other servers MUST support TLS per the second paragraph of this
+   section.)
+
+
+
+
+
+
+
+
+Harrison                    Standards Track                     [Page 7]
+
+RFC 4513              LDAP Authentication Methods              June 2006
+
+
+   Implementations supporting TLS MUST support the
+   TLS_RSA_WITH_3DES_EDE_CBC_SHA ciphersuite and SHOULD support the
+   TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA ciphersuite.  Support for the
+   latter ciphersuite is recommended to encourage interoperability with
+   implementations conforming to earlier LDAP StartTLS specifications.
+
+3.  StartTLS Operation
+
+   The Start Transport Layer Security (StartTLS) operation defined in
+   Section 4.14 of [RFC4511] provides the ability to establish TLS
+   [RFC4346] in an LDAP session.
+
+   The goals of using the TLS protocol with LDAP are to ensure data
+   confidentiality and integrity, and to optionally provide for
+   authentication.  TLS expressly provides these capabilities, although
+   the authentication services of TLS are available to LDAP only in
+   combination with the SASL EXTERNAL authentication method (see Section
+   5.2.3), and then only if the SASL EXTERNAL implementation chooses to
+   make use of the TLS credentials.
+
+3.1.  TLS Establishment Procedures
+
+   This section describes the overall procedures clients and servers
+   must follow for TLS establishment.  These procedures take into
+   consideration various aspects of the TLS layer including discovery of
+   resultant security level and assertion of the client's authorization
+   identity.
+
+3.1.1.  StartTLS Request Sequencing
+
+   A client may send the StartTLS extended request at any time after
+   establishing an LDAP session, except:
+
+      - when TLS is currently established on the session,
+      - when a multi-stage SASL negotiation is in progress on the
+        session, or
+      - when there are outstanding responses for operation requests
+        previously issued on the session.
+
+   As described in [RFC4511], Section 4.14.1, a (detected) violation of
+   any of these requirements results in a return of the operationsError
+   resultCode.
+
+   Client implementers should ensure that they strictly follow these
+   operation sequencing requirements to prevent interoperability issues.
+   Operational experience has shown that violating these requirements
+
+
+
+
+
+Harrison                    Standards Track                     [Page 8]
+
+RFC 4513              LDAP Authentication Methods              June 2006
+
+
+   causes interoperability issues because there are race conditions that
+   prevent servers from detecting some violations of these requirements
+   due to factors such as server hardware speed and network latencies.
+
+   There is no general requirement that the client have or have not
+   already performed a Bind operation (Section 5) before sending a
+   StartTLS operation request; however, where a client intends to
+   perform both a Bind operation and a StartTLS operation, it SHOULD
+   first perform the StartTLS operation so that the Bind request and
+   response messages are protected by the data security services
+   established by the StartTLS operation.
+
+3.1.2.  Client Certificate
+
+   If an LDAP server requests or demands that a client provide a user
+   certificate during TLS negotiation and the client does not present a
+   suitable user certificate (e.g., one that can be validated), the
+   server may use a local security policy to determine whether to
+   successfully complete TLS negotiation.
+
+   If a client that has provided a suitable certificate subsequently
+   performs a Bind operation using the SASL EXTERNAL authentication
+   mechanism (Section 5.2.3), information in the certificate may be used
+   by the server to identify and authenticate the client.
+
+3.1.3.  Server Identity Check
+
+   In order to prevent man-in-the-middle attacks, the client MUST verify
+   the server's identity (as presented in the server's Certificate
+   message).  In this section, the client's understanding of the
+   server's identity (typically the identity used to establish the
+   transport connection) is called the "reference identity".
+
+   The client determines the type (e.g., DNS name or IP address) of the
+   reference identity and performs a comparison between the reference
+   identity and each subjectAltName value of the corresponding type
+   until a match is produced.  Once a match is produced, the server's
+   identity has been verified, and the server identity check is
+   complete.  Different subjectAltName types are matched in different
+   ways.  Sections 3.1.3.1 - 3.1.3.3 explain how to compare values of
+   various subjectAltName types.
+
+   The client may map the reference identity to a different type prior
+   to performing a comparison.  Mappings may be performed for all
+   available subjectAltName types to which the reference identity can be
+   mapped; however, the reference identity should only be mapped to
+   types for which the mapping is either inherently secure (e.g.,
+   extracting the DNS name from a URI to compare with a subjectAltName
+
+
+
+Harrison                    Standards Track                     [Page 9]
+
+RFC 4513              LDAP Authentication Methods              June 2006
+
+
+   of type dNSName) or for which the mapping is performed in a secure
+   manner (e.g., using DNSSEC, or using user- or admin-configured host-
+   to-address/address-to-host lookup tables).
+
+   The server's identity may also be verified by comparing the reference
+   identity to the Common Name (CN) [RFC4519] value in the leaf Relative
+   Distinguished Name (RDN) of the subjectName field of the server's
+   certificate.  This comparison is performed using the rules for
+   comparison of DNS names in Section 3.1.3.1, below, with the exception
+   that no wildcard matching is allowed.  Although the use of the Common
+   Name value is existing practice, it is deprecated, and Certification
+   Authorities are encouraged to provide subjectAltName values instead.
+   Note that the TLS implementation may represent DNs in certificates
+   according to X.500 or other conventions.  For example, some X.500
+   implementations order the RDNs in a DN using a left-to-right (most
+   significant to least significant) convention instead of LDAP's
+   right-to-left convention.
+
+   If the server identity check fails, user-oriented clients SHOULD
+   either notify the user (clients may give the user the opportunity to
+   continue with the LDAP session in this case) or close the transport
+   connection and indicate that the server's identity is suspect.
+   Automated clients SHOULD close the transport connection and then
+   return or log an error indicating that the server's identity is
+   suspect or both.
+
+   Beyond the server identity check described in this section, clients
+   should be prepared to do further checking to ensure that the server
+   is authorized to provide the service it is requested to provide.  The
+   client may need to make use of local policy information in making
+   this determination.
+
+3.1.3.1.  Comparison of DNS Names
+
+   If the reference identity is an internationalized domain name,
+   conforming implementations MUST convert it to the ASCII Compatible
+   Encoding (ACE) format as specified in Section 4 of RFC 3490 [RFC3490]
+   before comparison with subjectAltName values of type dNSName.
+   Specifically, conforming implementations MUST perform the conversion
+   operation specified in Section 4 of RFC 3490 as follows:
+
+      * in step 1, the domain name SHALL be considered a "stored
+        string";
+      * in step 3, set the flag called "UseSTD3ASCIIRules";
+      * in step 4, process each label with the "ToASCII" operation; and
+      * in step 5, change all label separators to U+002E (full stop).
+
+
+
+
+
+Harrison                    Standards Track                    [Page 10]
+
+RFC 4513              LDAP Authentication Methods              June 2006
+
+
+   After performing the "to-ASCII" conversion, the DNS labels and names
+   MUST be compared for equality according to the rules specified in
+   Section 3 of RFC3490.
+
+   The '*' (ASCII 42) wildcard character is allowed in subjectAltName
+   values of type dNSName, and then only as the left-most (least
+   significant) DNS label in that value.  This wildcard matches any
+   left-most DNS label in the server name.  That is, the subject
+   *.example.com matches the server names a.example.com and
+   b.example.com, but does not match example.com or a.b.example.com.
+
+3.1.3.2.  Comparison of IP Addresses
+
+   When the reference identity is an IP address, the identity MUST be
+   converted to the "network byte order" octet string representation
+   [RFC791][RFC2460].  For IP Version 4, as specified in RFC 791, the
+   octet string will contain exactly four octets.  For IP Version 6, as
+   specified in RFC 2460, the octet string will contain exactly sixteen
+   octets.  This octet string is then compared against subjectAltName
+   values of type iPAddress.  A match occurs if the reference identity
+   octet string and value octet strings are identical.
+
+3.1.3.3.  Comparison of Other subjectName Types
+
+   Client implementations MAY support matching against subjectAltName
+   values of other types as described in other documents.
+
+3.1.4.  Discovery of Resultant Security Level
+
+   After a TLS layer is established in an LDAP session, both parties are
+   to each independently decide whether or not to continue based on
+   local policy and the security level achieved.  If either party
+   decides that the security level is inadequate for it to continue, it
+   SHOULD remove the TLS layer immediately after the TLS (re)negotiation
+   has completed (see [RFC4511], Section 4.14.3, and Section 3.2 below).
+   Implementations may reevaluate the security level at any time and,
+   upon finding it inadequate, should remove the TLS layer.
+
+3.1.5.  Refresh of Server Capabilities Information
+
+   After a TLS layer is established in an LDAP session, the client
+   SHOULD discard or refresh all information about the server that it
+   obtained prior to the initiation of the TLS negotiation and that it
+   did not obtain through secure mechanisms.  This protects against
+   man-in-the-middle attacks that may have altered any server
+   capabilities information retrieved prior to TLS layer installation.
+
+
+
+
+
+Harrison                    Standards Track                    [Page 11]
+
+RFC 4513              LDAP Authentication Methods              June 2006
+
+
+   The server may advertise different capabilities after installing a
+   TLS layer.  In particular, the value of 'supportedSASLMechanisms' may
+   be different after a TLS layer has been installed (specifically, the
+   EXTERNAL and PLAIN [PLAIN] mechanisms are likely to be listed only
+   after a TLS layer has been installed).
+
+3.2.  Effect of TLS on Authorization State
+
+   The establishment, change, and/or closure of TLS may cause the
+   authorization state to move to a new state.  This is discussed
+   further in Section 4.
+
+3.3.  TLS Ciphersuites
+
+   Several issues should be considered when selecting TLS ciphersuites
+   that are appropriate for use in a given circumstance.  These issues
+   include the following:
+
+      - The ciphersuite's ability to provide adequate confidentiality
+        protection for passwords and other data sent over the transport
+        connection.  Client and server implementers should recognize
+        that some TLS ciphersuites provide no confidentiality
+        protection, while other ciphersuites that do provide
+        confidentiality protection may be vulnerable to being cracked
+        using brute force methods, especially in light of ever-
+        increasing CPU speeds that reduce the time needed to
+        successfully mount such attacks.
+
+      - Client and server implementers should carefully consider the
+        value of the password or data being protected versus the level
+        of confidentiality protection provided by the ciphersuite to
+        ensure that the level of protection afforded by the ciphersuite
+        is appropriate.
+
+      - The ciphersuite's vulnerability (or lack thereof) to man-in-the-
+        middle attacks.  Ciphersuites vulnerable to man-in-the-middle
+        attacks SHOULD NOT be used to protect passwords or sensitive
+        data, unless the network configuration is such that the danger
+        of a man-in-the-middle attack is negligible.
+
+      - After a TLS negotiation (either initial or subsequent) is
+        completed, both protocol peers should independently verify that
+        the security services provided by the negotiated ciphersuite are
+        adequate for the intended use of the LDAP session.  If they are
+        not, the TLS layer should be closed.
+
+
+
+
+
+
+Harrison                    Standards Track                    [Page 12]
+
+RFC 4513              LDAP Authentication Methods              June 2006
+
+
+4.  Authorization State
+
+   Every LDAP session has an associated authorization state.  This state
+   is comprised of numerous factors such as what (if any) authentication
+   state has been established, how it was established, and what security
+   services are in place.  Some factors may be determined and/or
+   affected by protocol events (e.g., Bind, StartTLS, or TLS closure),
+   and some factors may be determined by external events (e.g., time of
+   day or server load).
+
+   While it is often convenient to view authorization state in
+   simplistic terms (as we often do in this technical specification)
+   such as "an anonymous state", it is noted that authorization systems
+   in LDAP implementations commonly involve many factors that
+   interrelate in complex manners.
+
+   Authorization in LDAP is a local matter.  One of the key factors in
+   making authorization decisions is authorization identity.  The Bind
+   operation (defined in Section 4.2 of [RFC4511] and discussed further
+   in Section 5 below) allows information to be exchanged between the
+   client and server to establish an authorization identity for the LDAP
+   session.  The Bind operation may also be used to move the LDAP
+   session to an anonymous authorization state (see Section 5.1.1).
+
+   Upon initial establishment of the LDAP session, the session has an
+   anonymous authorization identity.  Among other things this implies
+   that the client need not send a BindRequest in the first PDU of the
+   LDAP message layer.  The client may send any operation request prior
+   to performing a Bind operation, and the server MUST treat it as if it
+   had been performed after an anonymous Bind operation (Section 5.1.1).
+
+   Upon receipt of a Bind request, the server immediately moves the
+   session to an anonymous authorization state.  If the Bind request is
+   successful, the session is moved to the requested authentication
+   state with its associated authorization state.  Otherwise, the
+   session remains in an anonymous state.
+
+   It is noted that other events both internal and external to LDAP may
+   result in the authentication and authorization states being moved to
+   an anonymous one.  For instance, the establishment, change, or
+   closure of data security services may result in a move to an
+   anonymous state, or the user's credential information (e.g.,
+   certificate) may have expired.  The former is an example of an event
+   internal to LDAP, whereas the latter is an example of an event
+   external to LDAP.
+
+
+
+
+
+
+Harrison                    Standards Track                    [Page 13]
+
+RFC 4513              LDAP Authentication Methods              June 2006
+
+
+5.  Bind Operation
+
+   The Bind operation ([RFC4511], Section 4.2) allows authentication
+   information to be exchanged between the client and server to
+   establish a new authorization state.
+
+   The Bind request typically specifies the desired authentication
+   identity.  Some Bind mechanisms also allow the client to specify the
+   authorization identity.  If the authorization identity is not
+   specified, the server derives it from the authentication identity in
+   an implementation-specific manner.
+
+   If the authorization identity is specified, the server MUST verify
+   that the client's authentication identity is permitted to assume
+   (e.g., proxy for) the asserted authorization identity.  The server
+   MUST reject the Bind operation with an invalidCredentials resultCode
+   in the Bind response if the client is not so authorized.
+
+5.1.  Simple Authentication Method
+
+   The simple authentication method of the Bind Operation provides three
+   authentication mechanisms:
+
+      - An anonymous authentication mechanism (Section 5.1.1).
+
+      - An unauthenticated authentication mechanism (Section 5.1.2).
+
+      - A name/password authentication mechanism using credentials
+        consisting of a name (in the form of an LDAP distinguished name
+        [RFC4514]) and a password (Section 5.1.3).
+
+5.1.1.  Anonymous Authentication Mechanism of Simple Bind
+
+   An LDAP client may use the anonymous authentication mechanism of the
+   simple Bind method to explicitly establish an anonymous authorization
+   state by sending a Bind request with a name value of zero length and
+   specifying the simple authentication choice containing a password
+   value of zero length.
+
+5.1.2.  Unauthenticated Authentication Mechanism of Simple Bind
+
+   An LDAP client may use the unauthenticated authentication mechanism
+   of the simple Bind method to establish an anonymous authorization
+   state by sending a Bind request with a name value (a distinguished
+   name in LDAP string form [RFC4514] of non-zero length) and specifying
+   the simple authentication choice containing a password value of zero
+   length.
+
+
+
+
+Harrison                    Standards Track                    [Page 14]
+
+RFC 4513              LDAP Authentication Methods              June 2006
+
+
+   The distinguished name value provided by the client is intended to be
+   used for trace (e.g., logging) purposes only.  The value is not to be
+   authenticated or otherwise validated (including verification that the
+   DN refers to an existing directory object).  The value is not to be
+   used (directly or indirectly) for authorization purposes.
+
+   Unauthenticated Bind operations can have significant security issues
+   (see Section 6.3.1).  In particular, users intending to perform
+   Name/Password Authentication may inadvertently provide an empty
+   password and thus cause poorly implemented clients to request
+   Unauthenticated access.  Clients SHOULD be implemented to require
+   user selection of the Unauthenticated Authentication Mechanism by
+   means other than user input of an empty password.  Clients SHOULD
+   disallow an empty password input to a Name/Password Authentication
+   user interface.  Additionally, Servers SHOULD by default fail
+   Unauthenticated Bind requests with a resultCode of
+   unwillingToPerform.
+
+5.1.3.  Name/Password Authentication Mechanism of Simple Bind
+
+   An LDAP client may use the name/password authentication mechanism of
+   the simple Bind method to establish an authenticated authorization
+   state by sending a Bind request with a name value (a distinguished
+   name in LDAP string form [RFC4514] of non-zero length) and specifying
+   the simple authentication choice containing an OCTET STRING password
+   value of non-zero length.
+
+   Servers that map the DN sent in the Bind request to a directory entry
+   with an associated set of one or more passwords used with this
+   mechanism will compare the presented password to that set of
+   passwords.  The presented password is considered valid if it matches
+   any member of this set.
+
+   A resultCode of invalidDNSyntax indicates that the DN sent in the
+   name value is syntactically invalid.  A resultCode of
+   invalidCredentials indicates that the DN is syntactically correct but
+   not valid for purposes of authentication, that the password is not
+   valid for the DN, or that the server otherwise considers the
+   credentials invalid.  A resultCode of success indicates that the
+   credentials are valid and that the server is willing to provide
+   service to the entity these credentials identify.
+
+   Server behavior is undefined for Bind requests specifying the
+   name/password authentication mechanism with a zero-length name value
+   and a password value of non-zero length.
+
+
+
+
+
+
+Harrison                    Standards Track                    [Page 15]
+
+RFC 4513              LDAP Authentication Methods              June 2006
+
+
+   The name/password authentication mechanism of the simple Bind method
+   is not suitable for authentication in environments without
+   confidentiality protection.
+
+5.2.  SASL Authentication Method
+
+   The sasl authentication method of the Bind Operation provides
+   facilities for using any SASL mechanism including authentication
+   mechanisms and other services (e.g., data security services).
+
+5.2.1.  SASL Protocol Profile
+
+   LDAP allows authentication via any SASL mechanism [RFC4422].  As LDAP
+   includes native anonymous and name/password (plain text)
+   authentication methods, the ANONYMOUS [RFC4505] and PLAIN [PLAIN]
+   SASL mechanisms are typically not used with LDAP.
+
+   Each protocol that utilizes SASL services is required to supply
+   certain information profiling the way they are exposed through the
+   protocol ([RFC4422], Section 4).  This section explains how each of
+   these profiling requirements is met by LDAP.
+
+5.2.1.1.  SASL Service Name for LDAP
+
+   The SASL service name for LDAP is "ldap", which has been registered
+   with the IANA as a SASL service name.
+
+5.2.1.2.  SASL Authentication Initiation and Protocol Exchange
+
+   SASL authentication is initiated via a BindRequest message
+   ([RFC4511], Section 4.2) with the following parameters:
+
+      - The version is 3.
+      - The AuthenticationChoice is sasl.
+      - The mechanism element of the SaslCredentials sequence contains
+        the value of the desired SASL mechanism.
+      - The optional credentials field of the SaslCredentials sequence
+        MAY be used to provide an initial client response for mechanisms
+        that are defined to have the client send data first (see
+        [RFC4422], Sections 3 and 5).
+
+   In general, a SASL authentication protocol exchange consists of a
+   series of server challenges and client responses, the contents of
+   which are specific to and defined by the SASL mechanism.  Thus, for
+   some SASL authentication mechanisms, it may be necessary for the
+   client to respond to one or more server challenges by sending
+   BindRequest messages multiple times.  A challenge is indicated by the
+   server sending a BindResponse message with the resultCode set to
+
+
+
+Harrison                    Standards Track                    [Page 16]
+
+RFC 4513              LDAP Authentication Methods              June 2006
+
+
+   saslBindInProgress.  This indicates that the server requires the
+   client to send a new BindRequest message with the same SASL mechanism
+   to continue the authentication process.
+
+   To the LDAP message layer, these challenges and responses are opaque
+   binary tokens of arbitrary length.  LDAP servers use the
+   serverSaslCreds field (an OCTET STRING) in a BindResponse message to
+   transmit each challenge.  LDAP clients use the credentials field (an
+   OCTET STRING) in the SaslCredentials sequence of a BindRequest
+   message to transmit each response.  Note that unlike some Internet
+   protocols where SASL is used, LDAP is not text based and does not
+   Base64-transform these challenge and response values.
+
+   Clients sending a BindRequest message with the sasl choice selected
+   SHOULD send a zero-length value in the name field.  Servers receiving
+   a BindRequest message with the sasl choice selected SHALL ignore any
+   value in the name field.
+
+   A client may abort a SASL Bind negotiation by sending a BindRequest
+   message with a different value in the mechanism field of
+   SaslCredentials or with an AuthenticationChoice other than sasl.
+
+   If the client sends a BindRequest with the sasl mechanism field as an
+   empty string, the server MUST return a BindResponse with a resultCode
+   of authMethodNotSupported.  This will allow the client to abort a
+   negotiation if it wishes to try again with the same SASL mechanism.
+
+   The server indicates completion of the SASL challenge-response
+   exchange by responding with a BindResponse in which the resultCode
+   value is not saslBindInProgress.
+
+   The serverSaslCreds field in the BindResponse can be used to include
+   an optional challenge with a success notification for mechanisms that
+   are defined to have the server send additional data along with the
+   indication of successful completion.
+
+5.2.1.3.  Optional Fields
+
+   As discussed above, LDAP provides an optional field for carrying an
+   initial response in the message initiating the SASL exchange and
+   provides an optional field for carrying additional data in the
+   message indicating the outcome of the authentication exchange.  As
+   the mechanism-specific content in these fields may be zero length,
+   SASL requires protocol specifications to detail how an empty field is
+   distinguished from an absent field.
+
+
+
+
+
+
+Harrison                    Standards Track                    [Page 17]
+
+RFC 4513              LDAP Authentication Methods              June 2006
+
+
+   Zero-length initial response data is distinguished from no initial
+   response data in the initiating message, a BindRequest PDU, by the
+   presence of the SaslCredentials.credentials OCTET STRING (of length
+   zero) in that PDU.  If the client does not intend to send an initial
+   response with the BindRequest initiating the SASL exchange, it MUST
+   omit the SaslCredentials.credentials OCTET STRING (rather than
+   include an zero-length OCTET STRING).
+
+   Zero-length additional data is distinguished from no additional
+   response data in the outcome message, a BindResponse PDU, by the
+   presence of the serverSaslCreds OCTET STRING (of length zero) in that
+   PDU.  If a server does not intend to send additional data in the
+   BindResponse message indicating outcome of the exchange, the server
+   SHALL omit the serverSaslCreds OCTET STRING (rather than including a
+   zero-length OCTET STRING).
+
+5.2.1.4.  Octet Where Negotiated Security Layers Take Effect
+
+   SASL layers take effect following the transmission by the server and
+   reception by the client of the final BindResponse in the SASL
+   exchange with a resultCode of success.
+
+   Once a SASL layer providing data integrity or confidentiality
+   services takes effect, the layer remains in effect until a new layer
+   is installed (i.e., at the first octet following the final
+   BindResponse of the Bind operation that caused the new layer to take
+   effect).  Thus, an established SASL layer is not affected by a failed
+   or non-SASL Bind.
+
+5.2.1.5.  Determination of Supported SASL Mechanisms
+
+   Clients may determine the SASL mechanisms a server supports by
+   reading the 'supportedSASLMechanisms' attribute from the root DSE
+   (DSA-Specific Entry) ([RFC4512], Section 5.1).  The values of this
+   attribute, if any, list the mechanisms the server supports in the
+   current LDAP session state.  LDAP servers SHOULD allow all clients --
+   even those with an anonymous authorization -- to retrieve the
+   'supportedSASLMechanisms' attribute of the root DSE both before and
+   after the SASL authentication exchange.  The purpose of the latter is
+   to allow the client to detect possible downgrade attacks (see Section
+   6.4 and [RFC4422], Section 6.1.2).
+
+   Because SASL mechanisms provide critical security functions, clients
+   and servers should be configurable to specify what mechanisms are
+   acceptable and allow only those mechanisms to be used.  Both clients
+   and servers must confirm that the negotiated security level meets
+   their requirements before proceeding to use the session.
+
+
+
+
+Harrison                    Standards Track                    [Page 18]
+
+RFC 4513              LDAP Authentication Methods              June 2006
+
+
+5.2.1.6.  Rules for Using SASL Layers
+
+   Upon installing a SASL layer, the client SHOULD discard or refresh
+   all information about the server that it obtained prior to the
+   initiation of the SASL negotiation and that it did not obtain through
+   secure mechanisms.
+
+   If a lower-level security layer (such as TLS) is installed, any SASL
+   layer SHALL be layered on top of such security layers regardless of
+   the order of their negotiation.  In all other respects, the SASL
+   layer and other security layers act independently, e.g., if both a
+   TLS layer and a SASL layer are in effect, then removing the TLS layer
+   does not affect the continuing service of the SASL layer.
+
+5.2.1.7.  Support for Multiple Authentications
+
+   LDAP supports multiple SASL authentications as defined in [RFC4422],
+   Section 4.
+
+5.2.1.8.  SASL Authorization Identities
+
+   Some SASL mechanisms allow clients to request a desired authorization
+   identity for the LDAP session ([RFC4422], Section 3.4).  The decision
+   to allow or disallow the current authentication identity to have
+   access to the requested authorization identity is a matter of local
+   policy.  The authorization identity is a string of UTF-8 [RFC3629]
+   encoded [Unicode] characters corresponding to the following Augmented
+   Backus-Naur Form (ABNF) [RFC4234] grammar:
+
+      authzId = dnAuthzId / uAuthzId
+
+      ; distinguished-name-based authz id
+      dnAuthzId =  "dn:" distinguishedName
+
+      ; unspecified authorization id, UTF-8 encoded
+      uAuthzId = "u:" userid
+      userid = *UTF8 ; syntax unspecified
+
+   where the distinguishedName rule is defined in Section 3 of [RFC4514]
+   and the UTF8 rule is defined in Section 1.4 of [RFC4512].
+
+   The dnAuthzId choice is used to assert authorization identities in
+   the form of a distinguished name to be matched in accordance with the
+   distinguishedNameMatch matching rule ([RFC4517], Section 4.2.15).
+   There is no requirement that the asserted distinguishedName value be
+   that of an entry in the directory.
+
+
+
+
+
+Harrison                    Standards Track                    [Page 19]
+
+RFC 4513              LDAP Authentication Methods              June 2006
+
+
+   The uAuthzId choice allows clients to assert an authorization
+   identity that is not in distinguished name form.  The format of
+   userid is defined only as a sequence of UTF-8 [RFC3629] encoded
+   [Unicode] characters, and any further interpretation is a local
+   matter.  For example, the userid could identify a user of a specific
+   directory service, be a login name, or be an email address.  A
+   uAuthzId SHOULD NOT be assumed to be globally unique.  To compare
+   uAuthzId values, each uAuthzId value MUST be prepared as a "query"
+   string ([RFC3454], Section 7) using the SASLprep [RFC4013] algorithm,
+   and then the two values are compared octet-wise.
+
+   The above grammar is extensible.  The authzId production may be
+   extended to support additional forms of identities.  Each form is
+   distinguished by its unique prefix (see Section 3.12 of [RFC4520] for
+   registration requirements).
+
+5.2.2.  SASL Semantics within LDAP
+
+   Implementers must take care to maintain the semantics of SASL
+   specifications when handling data that has different semantics in the
+   LDAP protocol.
+
+   For example, the SASL DIGEST-MD5 authentication mechanism
+   [DIGEST-MD5] utilizes an authentication identity and a realm that are
+   syntactically simple strings and semantically simple username
+   [RFC4013] and realm values.  These values are not LDAP DNs, and there
+   is no requirement that they be represented or treated as such.
+
+5.2.3.  SASL EXTERNAL Authentication Mechanism
+
+   A client can use the SASL EXTERNAL ([RFC4422], Appendix A) mechanism
+   to request the LDAP server to authenticate and establish a resulting
+   authorization identity using security credentials exchanged by a
+   lower security layer (such as by TLS authentication).  If the
+   client's authentication credentials have not been established at a
+   lower security layer, the SASL EXTERNAL Bind MUST fail with a
+   resultCode of inappropriateAuthentication.  Although this situation
+   has the effect of leaving the LDAP session in an anonymous state
+   (Section 4), the state of any installed security layer is unaffected.
+
+   A client may either request that its authorization identity be
+   automatically derived from its authentication credentials exchanged
+   at a lower security layer, or it may explicitly provide a desired
+   authorization identity.  The former is known as an implicit
+   assertion, and the latter as an explicit assertion.
+
+
+
+
+
+
+Harrison                    Standards Track                    [Page 20]
+
+RFC 4513              LDAP Authentication Methods              June 2006
+
+
+5.2.3.1.  Implicit Assertion
+
+   An implicit authorization identity assertion is performed by invoking
+   a Bind request of the SASL form using the EXTERNAL mechanism name
+   that does not include the optional credentials field (found within
+   the SaslCredentials sequence in the BindRequest).  The server will
+   derive the client's authorization identity from the authentication
+   identity supplied by a security layer (e.g., a public key certificate
+   used during TLS layer installation) according to local policy.  The
+   underlying mechanics of how this is accomplished are implementation
+   specific.
+
+5.2.3.2.  Explicit Assertion
+
+   An explicit authorization identity assertion is performed by invoking
+   a Bind request of the SASL form using the EXTERNAL mechanism name
+   that includes the credentials field (found within the SaslCredentials
+   sequence in the BindRequest).  The value of the credentials field (an
+   OCTET STRING) is the asserted authorization identity and MUST be
+   constructed as documented in Section 5.2.1.8.
+
+6.  Security Considerations
+
+   Security issues are discussed throughout this document.  The
+   unsurprising conclusion is that security is an integral and necessary
+   part of LDAP.  This section discusses a number of LDAP-related
+   security considerations.
+
+6.1.  General LDAP Security Considerations
+
+   LDAP itself provides no security or protection from accessing or
+   updating the directory by means other than through the LDAP protocol,
+   e.g., from inspection of server database files by database
+   administrators.
+
+   Sensitive data may be carried in almost any LDAP message, and its
+   disclosure may be subject to privacy laws or other legal regulation
+   in many countries.  Implementers should take appropriate measures to
+   protect sensitive data from disclosure to unauthorized entities.
+
+   A session on which the client has not established data integrity and
+   privacy services (e.g., via StartTLS, IPsec, or a suitable SASL
+   mechanism) is subject to man-in-the-middle attacks to view and modify
+   information in transit.  Client and server implementers SHOULD take
+   measures to protect sensitive data in the LDAP session from these
+   attacks by using data protection services as discussed in this
+   document.  Clients and servers should provide the ability to be
+   configured to require these protections.  A resultCode of
+
+
+
+Harrison                    Standards Track                    [Page 21]
+
+RFC 4513              LDAP Authentication Methods              June 2006
+
+
+   confidentialityRequired indicates that the server requires
+   establishment of (stronger) data confidentiality protection in order
+   to perform the requested operation.
+
+   Access control should always be applied when reading sensitive
+   information or updating directory information.
+
+   Various security factors, including authentication and authorization
+   information and data security services may change during the course
+   of the LDAP session, or even during the performance of a particular
+   operation.  Implementations should be robust in the handling of
+   changing security factors.
+
+6.2.  StartTLS Security Considerations
+
+   All security gained via use of the StartTLS operation is gained by
+   the use of TLS itself.  The StartTLS operation, on its own, does not
+   provide any additional security.
+
+   The level of security provided through the use of TLS depends
+   directly on both the quality of the TLS implementation used and the
+   style of usage of that implementation.  Additionally, a man-in-the-
+   middle attacker can remove the StartTLS extended operation from the
+   'supportedExtension' attribute of the root DSE.  Both parties SHOULD
+   independently ascertain and consent to the security level achieved
+   once TLS is established and before beginning use of the TLS-
+   protected session.  For example, the security level of the TLS layer
+   might have been negotiated down to plaintext.
+
+   Clients MUST either warn the user when the security level achieved
+   does not provide an acceptable level of data confidentiality and/or
+   data integrity protection, or be configurable to refuse to proceed
+   without an acceptable level of security.
+
+   As stated in Section 3.1.2, a server may use a local security policy
+   to determine whether to successfully complete TLS negotiation.
+   Information in the user's certificate that is originated or verified
+   by the certification authority should be used by the policy
+   administrator when configuring the identification and authorization
+   policy.
+
+   Server implementers SHOULD allow server administrators to elect
+   whether and when data confidentiality and integrity are required, as
+   well as elect whether authentication of the client during the TLS
+   handshake is required.
+
+   Implementers should be aware of and understand TLS security
+   considerations as discussed in the TLS specification [RFC4346].
+
+
+
+Harrison                    Standards Track                    [Page 22]
+
+RFC 4513              LDAP Authentication Methods              June 2006
+
+
+6.3.  Bind Operation Security Considerations
+
+   This section discusses several security considerations relevant to
+   LDAP authentication via the Bind operation.
+
+6.3.1.  Unauthenticated Mechanism Security Considerations
+
+   Operational experience shows that clients can (and frequently do)
+   misuse the unauthenticated authentication mechanism of the simple
+   Bind method (see Section 5.1.2).  For example, a client program might
+   make a decision to grant access to non-directory information on the
+   basis of successfully completing a Bind operation.  LDAP server
+   implementations may return a success response to an unauthenticated
+   Bind request.  This may erroneously leave the client with the
+   impression that the server has successfully authenticated the
+   identity represented by the distinguished name when in reality, an
+   anonymous authorization state has been established.  Clients that use
+   the results from a simple Bind operation to make authorization
+   decisions should actively detect unauthenticated Bind requests (by
+   verifying that the supplied password is not empty) and react
+   appropriately.
+
+6.3.2.  Name/Password Mechanism Security Considerations
+
+   The name/password authentication mechanism of the simple Bind method
+   discloses the password to the server, which is an inherent security
+   risk.  There are other mechanisms, such as SASL DIGEST-MD5
+   [DIGEST-MD5], that do not disclose the password to the server.
+
+6.3.3.  Password-Related Security Considerations
+
+   LDAP allows multi-valued password attributes.  In systems where
+   entries are expected to have one and only one password,
+   administrative controls should be provided to enforce this behavior.
+
+   The use of clear text passwords and other unprotected authentication
+   credentials is strongly discouraged over open networks when the
+   underlying transport service cannot guarantee confidentiality.  LDAP
+   implementations SHOULD NOT by default support authentication methods
+   using clear text passwords and other unprotected authentication
+   credentials unless the data on the session is protected using TLS or
+   other data confidentiality and data integrity protection.
+
+   The transmission of passwords in the clear -- typically for
+   authentication or modification -- poses a significant security risk.
+   This risk can be avoided by using SASL authentication [RFC4422]
+
+
+
+
+
+Harrison                    Standards Track                    [Page 23]
+
+RFC 4513              LDAP Authentication Methods              June 2006
+
+
+   mechanisms that do not transmit passwords in the clear or by
+   negotiating transport or session layer data confidentiality services
+   before transmitting password values.
+
+   To mitigate the security risks associated with the transfer of
+   passwords, a server implementation that supports any password-based
+   authentication mechanism that transmits passwords in the clear MUST
+   support a policy mechanism that at the time of authentication or
+   password modification, requires that:
+
+         A TLS layer has been successfully installed.
+
+         OR
+
+         Some other data confidentiality mechanism that protects the
+         password value from eavesdropping has been provided.
+
+         OR
+
+         The server returns a resultCode of confidentialityRequired for
+         the operation (i.e., name/password Bind with password value,
+         SASL Bind transmitting a password value in the clear, add or
+         modify including a userPassword value, etc.), even if the
+         password value is correct.
+
+   Server implementations may also want to provide policy mechanisms to
+   invalidate or otherwise protect accounts in situations where a server
+   detects that a password for an account has been transmitted in the
+   clear.
+
+6.3.4.  Hashed Password Security Considerations
+
+   Some authentication mechanisms (e.g., DIGEST-MD5) transmit a hash of
+   the password value that may be vulnerable to offline dictionary
+   attacks.  Implementers should take care to protect such hashed
+   password values during transmission using TLS or other
+   confidentiality mechanisms.
+
+6.4.  SASL Security Considerations
+
+   Until data integrity service is installed on an LDAP session, an
+   attacker can modify the transmitted values of the
+   'supportedSASLMechanisms' attribute response and thus downgrade the
+   list of available SASL mechanisms to include only the least secure
+   mechanism.  To detect this type of attack, the client may retrieve
+   the SASL mechanisms the server makes available both before and after
+   data integrity service is installed on an LDAP session.  If the
+   client finds that the integrity-protected list (the list obtained
+
+
+
+Harrison                    Standards Track                    [Page 24]
+
+RFC 4513              LDAP Authentication Methods              June 2006
+
+
+   after data integrity service was installed) contains a stronger
+   mechanism than those in the previously obtained list, the client
+   should assume the previously obtained list was modified by an
+   attacker.  In this circumstance it is recommended that the client
+   close the underlying transport connection and then reconnect to
+   reestablish the session.
+
+6.5.  Related Security Considerations
+
+   Additional security considerations relating to the various
+   authentication methods and mechanisms discussed in this document
+   apply and can be found in [RFC4422], [RFC4013], [RFC3454], and
+   [RFC3629].
+
+7.  IANA Considerations
+
+   The IANA has updated the LDAP Protocol Mechanism registry to indicate
+   that this document and [RFC4511] provide the definitive technical
+   specification for the StartTLS (1.3.6.1.4.1.1466.20037) extended
+   operation.
+
+   The IANA has updated the LDAP LDAPMessage types registry to indicate
+   that this document and [RFC4511] provide the definitive technical
+   specification for the bindRequest (0) and bindResponse (1) message
+   types.
+
+   The IANA has updated the LDAP Bind Authentication Method registry to
+   indicate that this document and [RFC4511] provide the definitive
+   technical specification for the simple (0) and sasl (3) bind
+   authentication methods.
+
+   The IANA has updated the LDAP authzid prefixes registry to indicate
+   that this document provides the definitive technical specification
+   for the dnAuthzId (dn:) and uAuthzId (u:) authzid prefixes.
+
+8.  Acknowledgements
+
+   This document combines information originally contained in RFC 2251,
+   RFC 2829, and RFC 2830.  RFC 2251 was a product of the Access,
+   Searching, and Indexing of Directories (ASID) Working Group.  RFC
+   2829 and RFC 2830 were products of the LDAP Extensions (LDAPEXT)
+   Working Group.
+
+   This document is a product of the IETF LDAP Revision (LDAPBIS)
+   working group.
+
+
+
+
+
+
+Harrison                    Standards Track                    [Page 25]
+
+RFC 4513              LDAP Authentication Methods              June 2006
+
+
+9.  Normative References
+
+   [RFC791]     Postel, J., "Internet Protocol", STD 5, RFC 791,
+                September 1981.
+
+   [RFC2119]    Bradner, S., "Key words for use in RFCs to Indicate
+                Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2460]    Deering, S. and R. Hinden, "Internet Protocol, Version 6
+                (IPv6) Specification", RFC 2460, December 1998.
+
+   [RFC3454]    Hoffman, P. and M. Blanchet, "Preparation of
+                Internationalized Strings ("stringprep")", RFC 3454,
+                December 2002.
+
+   [RFC3490]    Faltstrom, P., Hoffman, P., and A. Costello,
+                "Internationalizing Domain Names in Applications
+                (IDNA)", RFC 3490, March 2003.
+
+   [RFC3629]    Yergeau, F., "UTF-8, a transformation format of ISO
+                10646", STD 63, RFC 3629, November 2003.
+
+   [RFC4013]    Zeilenga, K., "SASLprep: Stringprep Profile for User
+                Names and Passwords", RFC 4013, February 2005.
+
+   [RFC4234]    Crocker, D. and P. Overell, "Augmented BNF for Syntax
+                Specifications: ABNF", RFC 4234, October 2005.
+
+   [RFC4346]    Dierks, T. and E. Rescorla, "The TLS Protocol Version
+                1.1", RFC 4346, March 2006.
+
+   [RFC4422]    Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple
+                Authentication and Security Layer (SASL)", RFC 4422,
+                June 2006.
+
+   [RFC4510]    Zeilenga, K., Ed., "Lightweight Directory Access
+                Protocol (LDAP): Technical Specification Road Map", RFC
+                4510, June 2006.
+
+   [RFC4511]    Sermersheim, J., Ed., "Lightweight Directory Access
+                Protocol (LDAP): The Protocol", RFC 4511, June 2006.
+
+   [RFC4512]    Zeilenga, K., "Lightweight Directory Access Protocol
+                (LDAP): Directory Information Models", RFC 4512, June
+                2006.
+
+
+
+
+
+
+Harrison                    Standards Track                    [Page 26]
+
+RFC 4513              LDAP Authentication Methods              June 2006
+
+
+   [RFC4514]    Zeilenga, K., Ed., "Lightweight Directory Access
+                Protocol (LDAP): String Representation of Distinguished
+                Names", RFC 4514, June 2006.
+
+   [RFC4517]    Legg, S., Ed., "Lightweight Directory Access Protocol
+                (LDAP): Syntaxes and Matching Rules", RFC 4517, June
+                2006.
+
+   [RFC4519]    Sciberras, A., Ed., "Lightweight Directory Access
+                Protocol (LDAP): Schema for User Applications", RFC
+                4519, June 2006.
+
+   [RFC4520]    Zeilenga, K., "Internet Assigned Numbers Authority
+                (IANA) Considerations for the Lightweight Directory
+                Access Protocol (LDAP)", BCP 64, RFC 4520, June 2006.
+
+   [Unicode]    The Unicode Consortium, "The Unicode Standard, Version
+                3.2.0" is defined by "The Unicode Standard, Version 3.0"
+                (Reading, MA, Addison-Wesley, 2000.  ISBN 0-201-61633-
+                5), as amended by the "Unicode Standard Annex #27:
+                Unicode 3.1" (http://www.unicode.org/reports/tr27/) and
+                by the "Unicode Standard Annex #28: Unicode 3.2"
+                (http://www.unicode.org/reports/tr28/).
+
+   [X.501]      ITU-T Rec. X.501, "The Directory: Models", 1993.
+
+10.  Informative References
+
+   [DIGEST-MD5] Leach, P., Newman, C., and A. Melnikov, "Using Digest
+                Authentication as a SASL Mechanism", Work in Progress,
+                March 2006.
+
+   [PLAIN]      Zeilenga, K., "The Plain SASL Mechanism", Work in
+                Progress, March 2005.
+
+   [RFC2828]    Shirey, R., "Internet Security Glossary", FYI 36, RFC
+                2828, May 2000.
+
+   [RFC4301]    Kent, S. and K. Seo, "Security Architecture for the
+                Internet Protocol", RFC 4301, December 2005.
+
+   [RFC4505]    Zeilenga, K., "The Anonymous SASL Mechanism", RFC 4505,
+                June 2006.
+
+
+
+
+
+
+
+
+Harrison                    Standards Track                    [Page 27]
+
+RFC 4513              LDAP Authentication Methods              June 2006
+
+
+Appendix A.  Authentication and Authorization Concepts
+
+   This appendix is non-normative.
+
+   This appendix defines basic terms, concepts, and interrelationships
+   regarding authentication, authorization, credentials, and identity.
+   These concepts are used in describing how various security approaches
+   are utilized in client authentication and authorization.
+
+A.1.  Access Control Policy
+
+   An access control policy is a set of rules defining the protection of
+   resources, generally in terms of the capabilities of persons or other
+   entities accessing those resources.  Security objects and mechanisms,
+   such as those described here, enable the expression of access control
+   policies and their enforcement.
+
+A.2.  Access Control Factors
+
+   A request, when it is being processed by a server, may be associated
+   with a wide variety of security-related factors.  The server uses
+   these factors to determine whether and how to process the request.
+   These are called access control factors (ACFs).  They might include
+   source IP address, encryption strength, the type of operation being
+   requested, time of day, etc..  Some factors may be specific to the
+   request itself; others may be associated with the transport
+   connection via which the request is transmitted; and others (e.g.,
+   time of day) may be "environmental".
+
+   Access control policies are expressed in terms of access control
+   factors; for example, "a request having ACFs i,j,k can perform
+   operation Y on resource Z".  The set of ACFs that a server makes
+   available for such expressions is implementation specific.
+
+A.3.  Authentication, Credentials, Identity
+
+   Authentication credentials are the evidence supplied by one party to
+   another, asserting the identity of the supplying party (e.g., a user)
+   who is attempting to establish a new authorization state with the
+   other party (typically a server).  Authentication is the process of
+   generating, transmitting, and verifying these credentials and thus
+   the identity they assert.  An authentication identity is the name
+   presented in a credential.
+
+   There are many forms of authentication credentials.  The form used
+   depends upon the particular authentication mechanism negotiated by
+   the parties.  X.509 certificates, Kerberos tickets, and simple
+   identity and password pairs are all examples of authentication
+
+
+
+Harrison                    Standards Track                    [Page 28]
+
+RFC 4513              LDAP Authentication Methods              June 2006
+
+
+   credential forms.  Note that an authentication mechanism may
+   constrain the form of authentication identities used with it.
+
+A.4.  Authorization Identity
+
+   An authorization identity is one kind of access control factor.  It
+   is the name of the user or other entity that requests that operations
+   be performed.  Access control policies are often expressed in terms
+   of authorization identities; for example, "entity X can perform
+   operation Y on resource Z".
+
+   The authorization identity of an LDAP session is often semantically
+   the same as the authentication identity presented by the client, but
+   it may be different.  SASL allows clients to specify an authorization
+   identity distinct from the authentication identity asserted by the
+   client's credentials.  This permits agents such as proxy servers to
+   authenticate using their own credentials, yet request the access
+   privileges of the identity for which they are proxying [RFC4422].
+   Also, the form of authentication identity supplied by a service like
+   TLS may not correspond to the authorization identities used to
+   express a server's access control policy, thus requiring a server-
+   specific mapping to be done.  The method by which a server composes
+   and validates an authorization identity from the authentication
+   credentials supplied by a client is implementation specific.
+
+Appendix B.  Summary of Changes
+
+   This appendix is non-normative.
+
+   This appendix summarizes substantive changes made to RFC 2251, RFC
+   2829 and RFC 2830.  In addition to the specific changes detailed
+   below, the reader of this document should be aware that numerous
+   general editorial changes have been made to the original content from
+   the source documents.  These changes include the following:
+
+   - The material originally found in RFC 2251 Sections 4.2.1 and 4.2.2,
+     RFC 2829 (all sections except Sections 2 and 4), and RFC 2830 was
+     combined into a single document.
+
+   - The combined material was substantially reorganized and edited to
+     group related subjects, improve the document flow, and clarify
+     intent.
+
+   - Changes were made throughout the text to align with definitions of
+     LDAP protocol layers and IETF security terminology.
+
+
+
+
+
+
+Harrison                    Standards Track                    [Page 29]
+
+RFC 4513              LDAP Authentication Methods              June 2006
+
+
+   - Substantial updates and additions were made to security
+     considerations from both documents based on current operational
+     experience.
+
+B.1.  Changes Made to RFC 2251
+
+   This section summarizes the substantive changes made to Sections
+   4.2.1 and 4.2.2 of RFC 2251 by this document.  Additional substantive
+   changes to Section 4.2.1 of RFC 2251 are also documented in
+   [RFC4511].
+
+B.1.1.  Section 4.2.1 ("Sequencing of the Bind Request")
+
+   - Paragraph 1: Removed the sentence, "If at any stage the client
+     wishes to abort the bind process it MAY unbind and then drop the
+     underlying connection".  The Unbind operation still permits this
+     behavior, but it is not documented explicitly.
+
+   - Clarified that the session is moved to an anonymous state upon
+     receipt of the BindRequest PDU and that it is only moved to a non-
+     anonymous state if and when the Bind request is successful.
+
+B.1.2.  Section 4.2.2 ("Authentication and Other Security Services")
+
+   - RFC 2251 states that anonymous authentication MUST be performed
+     using the simple bind method.  This specification defines the
+     anonymous authentication mechanism of the simple bind method and
+     requires all conforming implementations to support it.  Other
+     authentication mechanisms producing anonymous authentication and
+     authorization state may also be implemented and used by conforming
+     implementations.
+
+B.2.  Changes Made to RFC 2829
+
+   This section summarizes the substantive changes made to RFC 2829.
+
+B.2.1.  Section 4 ("Required security mechanisms")
+
+   - The name/password authentication mechanism (see Section B.2.5
+     below) protected by TLS replaces the SASL DIGEST-MD5 mechanism as
+     LDAP's mandatory-to-implement password-based authentication
+     mechanism.  Implementations are encouraged to continue supporting
+     SASL DIGEST-MD5 [DIGEST-MD5].
+
+
+
+
+
+
+
+
+Harrison                    Standards Track                    [Page 30]
+
+RFC 4513              LDAP Authentication Methods              June 2006
+
+
+B.2.2.  Section 5.1 ("Anonymous authentication procedure")
+
+   - Clarified that anonymous authentication involves a name value of
+     zero length and a password value of zero length.  The
+     unauthenticated authentication mechanism was added to handle simple
+     Bind requests involving a name value with a non-zero length and a
+     password value of zero length.
+
+B.2.3.  Section 6 ("Password-based authentication")
+
+   - See Section B.2.1.
+
+B.2.4.  Section 6.1 ("Digest authentication")
+
+   - As the SASL-DIGEST-MD5 mechanism is no longer mandatory to
+     implement, this section is now historical and was not included in
+     this document.  RFC 2829, Section 6.1, continues to document the
+     SASL DIGEST-MD5 authentication mechanism.
+
+B.2.5.  Section 6.2 ("'simple' authentication choice under TLS
+        encryption")
+
+   - Renamed the "simple" authentication mechanism to the name/password
+     authentication mechanism to better describe it.
+
+   - The use of TLS was generalized to align with definitions of LDAP
+     protocol layers.  TLS establishment is now discussed as an
+     independent subject and is generalized for use with all
+     authentication mechanisms and other security layers.
+
+   - Removed the implication that the userPassword attribute is the sole
+     location for storage of password values to be used in
+     authentication.  There is no longer any implied requirement for how
+     or where passwords are stored at the server for use in
+     authentication.
+
+B.2.6.  Section 6.3 ("Other authentication choices with TLS")
+
+   - See Section B.2.5.
+
+B.2.7.  Section 7.1 ("Certificate-based authentication with TLS")
+
+   - See Section B.2.5.
+
+
+
+
+
+
+
+
+Harrison                    Standards Track                    [Page 31]
+
+RFC 4513              LDAP Authentication Methods              June 2006
+
+
+B.2.8.  Section 8 ("Other mechanisms")
+
+   - All SASL authentication mechanisms are explicitly allowed within
+     LDAP.  Specifically, this means the SASL ANONYMOUS and SASL PLAIN
+     mechanisms are no longer precluded from use within LDAP.
+
+B.2.9.  Section 9 ("Authorization Identity")
+
+   - Specified matching rules for dnAuthzId and uAuthzId values.  In
+     particular, the DN value in the dnAuthzId form must be matched
+     using DN matching rules, and the uAuthzId value MUST be prepared
+     using SASLprep rules before being compared octet-wise.
+
+   - Clarified that uAuthzId values should not be assumed to be globally
+     unique.
+
+B.2.10.  Section 10 ("TLS Ciphersuites")
+
+   - TLS ciphersuite recommendations are no longer included in this
+     specification.  Implementations must now support the
+     TLS_RSA_WITH_3DES_EDE_CBC_SHA ciphersuite and should continue to
+     support the TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA ciphersuite.
+
+   - Clarified that anonymous authentication involves a name value of
+     zero length and a password value of zero length.  The
+     unauthenticated authentication mechanism was added to handle simple
+     Bind requests involving a name value with a non-zero length and a
+     password value of zero length.
+
+B.3.  Changes Made to RFC 2830
+
+   This section summarizes the substantive changes made to Sections 3
+   and 5 of RFC 2830.  Readers should consult [RFC4511] for summaries of
+   changes to other sections.
+
+B.3.1.  Section 3.6 ("Server Identity Check")
+
+   - Substantially updated the server identity check algorithm to ensure
+     that it is complete and robust.  In particular, the use of all
+     relevant values in the subjectAltName and the subjectName fields
+     are covered by the algorithm and matching rules are specified for
+     each type of value.  Mapped (derived) forms of the server identity
+     may now be used when the mapping is performed in a secure fashion.
+
+
+
+
+
+
+
+
+Harrison                    Standards Track                    [Page 32]
+
+RFC 4513              LDAP Authentication Methods              June 2006
+
+
+B.3.2.  Section 3.7 ("Refresh of Server Capabilities Information")
+
+   - Clients are no longer required to always refresh information about
+     server capabilities following TLS establishment.  This is to allow
+     for situations where this information was obtained through a secure
+     mechanism.
+
+B.3.3.  Section 5 ("Effects of TLS on a Client's Authorization
+        Identity")
+
+   - Establishing a TLS layer on an LDAP session may now cause the
+     authorization state of the LDAP session to change.
+
+B.3.4.  Section 5.2 ("TLS Connection Closure Effects")
+
+   - Closing a TLS layer on an LDAP session changes the authentication
+     and authorization state of the LDAP session based on local policy.
+     Specifically, this means that implementations are not required to
+     change the authentication and authorization states to anonymous
+     upon TLS closure.
+
+   - Replaced references to RFC 2401 with RFC 4301.
+
+Author's Address
+
+   Roger Harrison
+   Novell, Inc.
+   1800 S.  Novell Place
+   Provo, UT 84606
+   USA
+
+   Phone: +1 801 861 2642
+   EMail: roger_harrison@novell.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Harrison                    Standards Track                    [Page 33]
+
+RFC 4513              LDAP Authentication Methods              June 2006
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2006).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Harrison                    Standards Track                    [Page 34]
+
diff --git a/source4/ldap_server/devdocs/rfc4514.txt b/source4/ldap_server/devdocs/rfc4514.txt
new file mode 100644
index 0000000000..036c077cbf
--- /dev/null
+++ b/source4/ldap_server/devdocs/rfc4514.txt
@@ -0,0 +1,843 @@
+
+
+
+
+
+
+Network Working Group                                   K. Zeilenga, Ed.
+Request for Comments: 4514                           OpenLDAP Foundation
+Obsoletes: 2253                                                June 2006
+Category: Standards Track
+
+
+             Lightweight Directory Access Protocol (LDAP):
+              String Representation of Distinguished Names
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   The X.500 Directory uses distinguished names (DNs) as primary keys to
+   entries in the directory.  This document defines the string
+   representation used in the Lightweight Directory Access Protocol
+   (LDAP) to transfer distinguished names.  The string representation is
+   designed to give a clean representation of commonly used
+   distinguished names, while being able to represent any distinguished
+   name.
+
+1.  Background and Intended Usage
+
+   In X.500-based directory systems [X.500], including those accessed
+   using the Lightweight Directory Access Protocol (LDAP) [RFC4510],
+   distinguished names (DNs) are used to unambiguously refer to
+   directory entries [X.501][RFC4512].
+
+   The structure of a DN [X.501] is described in terms of ASN.1 [X.680].
+   In the X.500 Directory Access Protocol [X.511] (and other ITU-defined
+   directory protocols), DNs are encoded using the Basic Encoding Rules
+   (BER) [X.690].  In LDAP, DNs are represented in the string form
+   described in this document.
+
+   It is important to have a common format to be able to unambiguously
+   represent a distinguished name.  The primary goal of this
+   specification is ease of encoding and decoding.  A secondary goal is
+   to have names that are human readable.  It is not expected that LDAP
+
+
+
+Zeilenga                    Standards Track                     [Page 1]
+
+RFC 4514               LDAP: Distinguished Names               June 2006
+
+
+   implementations with a human user interface would display these
+   strings directly to the user, but that they would most likely be
+   performing translations (such as expressing attribute type names in
+   the local national language).
+
+   This document defines the string representation of Distinguished
+   Names used in LDAP [RFC4511][RFC4517].  Section 2 details the
+   RECOMMENDED algorithm for converting a DN from its ASN.1 structured
+   representation to a string.  Section 3 details how to convert a DN
+   from a string to an ASN.1 structured representation.
+
+   While other documents may define other algorithms for converting a DN
+   from its ASN.1 structured representation to a string, all algorithms
+   MUST produce strings that adhere to the requirements of Section 3.
+
+   This document does not define a canonical string representation for
+   DNs.  Comparison of DNs for equality is to be performed in accordance
+   with the distinguishedNameMatch matching rule [RFC4517].
+
+   This document is a integral part of the LDAP technical specification
+   [RFC4510], which obsoletes the previously defined LDAP technical
+   specification, RFC 3377, in its entirety.  This document obsoletes
+   RFC 2253.  Changes since RFC 2253 are summarized in Appendix B.
+
+   This specification assumes familiarity with X.500 [X.500] and the
+   concept of Distinguished Name [X.501][RFC4512].
+
+1.1.  Conventions
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in BCP 14 [RFC2119].
+
+   Character names in this document use the notation for code points and
+   names from the Unicode Standard [Unicode].  For example, the letter
+   "a" may be represented as either <U+0061> or <LATIN SMALL LETTER A>.
+
+   Note: a glossary of terms used in Unicode can be found in [Glossary].
+   Information on the Unicode character encoding model can be found in
+   [CharModel].
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga                    Standards Track                     [Page 2]
+
+RFC 4514               LDAP: Distinguished Names               June 2006
+
+
+2.  Converting DistinguishedName from ASN.1 to a String
+
+   X.501 [X.501] defines the ASN.1 [X.680] structure of distinguished
+   name.  The following is a variant provided for discussion purposes.
+
+      DistinguishedName ::= RDNSequence
+
+      RDNSequence ::= SEQUENCE OF RelativeDistinguishedName
+
+      RelativeDistinguishedName ::= SET SIZE (1..MAX) OF
+          AttributeTypeAndValue
+
+      AttributeTypeAndValue ::= SEQUENCE {
+          type  AttributeType,
+          value AttributeValue }
+
+   This section defines the RECOMMENDED algorithm for converting a
+   distinguished name from an ASN.1-structured representation to a UTF-8
+   [RFC3629] encoded Unicode [Unicode] character string representation.
+   Other documents may describe other algorithms for converting a
+   distinguished name to a string, but only strings that conform to the
+   grammar defined in Section 3 SHALL be produced by LDAP
+   implementations.
+
+2.1.  Converting the RDNSequence
+
+   If the RDNSequence is an empty sequence, the result is the empty or
+   zero-length string.
+
+   Otherwise, the output consists of the string encodings of each
+   RelativeDistinguishedName in the RDNSequence (according to Section
+   2.2), starting with the last element of the sequence and moving
+   backwards toward the first.
+
+   The encodings of adjoining RelativeDistinguishedNames are separated
+   by a comma (',' U+002C) character.
+
+2.2.  Converting RelativeDistinguishedName
+
+   When converting from an ASN.1 RelativeDistinguishedName to a string,
+   the output consists of the string encodings of each
+   AttributeTypeAndValue (according to Section 2.3), in any order.
+
+   Where there is a multi-valued RDN, the outputs from adjoining
+   AttributeTypeAndValues are separated by a plus sign ('+' U+002B)
+   character.
+
+
+
+
+
+Zeilenga                    Standards Track                     [Page 3]
+
+RFC 4514               LDAP: Distinguished Names               June 2006
+
+
+2.3.  Converting AttributeTypeAndValue
+
+   The AttributeTypeAndValue is encoded as the string representation of
+   the AttributeType, followed by an equals sign ('=' U+003D) character,
+   followed by the string representation of the AttributeValue.  The
+   encoding of the AttributeValue is given in Section 2.4.
+
+   If the AttributeType is defined to have a short name (descriptor)
+   [RFC4512] and that short name is known to be registered [REGISTRY]
+   [RFC4520] as identifying the AttributeType, that short name, a
+   <descr>, is used.  Otherwise the AttributeType is encoded as the
+   dotted-decimal encoding, a <numericoid>, of its OBJECT IDENTIFIER.
+   The <descr> and <numericoid> are defined in [RFC4512].
+
+   Implementations are not expected to dynamically update their
+   knowledge of registered short names.  However, implementations SHOULD
+   provide a mechanism to allow their knowledge of registered short
+   names to be updated.
+
+2.4.  Converting an AttributeValue from ASN.1 to a String
+
+   If the AttributeType is of the dotted-decimal form, the
+   AttributeValue is represented by an number sign ('#' U+0023)
+   character followed by the hexadecimal encoding of each of the octets
+   of the BER encoding of the X.500 AttributeValue.  This form is also
+   used when the syntax of the AttributeValue does not have an LDAP-
+   specific ([RFC4517], Section 3.1) string encoding defined for it, or
+   the LDAP-specific string encoding is not restricted to UTF-8-encoded
+   Unicode characters.  This form may also be used in other cases, such
+   as when a reversible string representation is desired (see Section
+   5.2).
+
+   Otherwise, if the AttributeValue is of a syntax that has a LDAP-
+   specific string encoding, the value is converted first to a UTF-8-
+   encoded Unicode string according to its syntax specification (see
+   [RFC4517], Section 3.3, for examples).  If that UTF-8-encoded Unicode
+   string does not have any of the following characters that need
+   escaping, then that string can be used as the string representation
+   of the value.
+
+      - a space (' ' U+0020) or number sign ('#' U+0023) occurring at
+        the beginning of the string;
+
+      - a space (' ' U+0020) character occurring at the end of the
+        string;
+
+
+
+
+
+
+Zeilenga                    Standards Track                     [Page 4]
+
+RFC 4514               LDAP: Distinguished Names               June 2006
+
+
+      - one of the characters '"', '+', ',', ';', '<', '>',  or '\'
+        (U+0022, U+002B, U+002C, U+003B, U+003C, U+003E, or U+005C,
+        respectively);
+
+      - the null (U+0000) character.
+
+   Other characters may be escaped.
+
+   Each octet of the character to be escaped is replaced by a backslash
+   and two hex digits, which form a single octet in the code of the
+   character.  Alternatively, if and only if the character to be escaped
+   is one of
+
+      ' ', '"', '#', '+', ',', ';', '<', '=', '>', or '\'
+      (U+0020, U+0022, U+0023, U+002B, U+002C, U+003B,
+       U+003C, U+003D, U+003E, U+005C, respectively)
+
+   it can be prefixed by a backslash ('\' U+005C).
+
+   Examples of the escaping mechanism are shown in Section 4.
+
+3.  Parsing a String Back to a Distinguished Name
+
+   The string representation of Distinguished Names is restricted to
+   UTF-8 [RFC3629] encoded Unicode [Unicode] characters.  The structure
+   of this string representation is specified using the following
+   Augmented BNF [RFC4234] grammar:
+
+      distinguishedName = [ relativeDistinguishedName
+          *( COMMA relativeDistinguishedName ) ]
+      relativeDistinguishedName = attributeTypeAndValue
+          *( PLUS attributeTypeAndValue )
+      attributeTypeAndValue = attributeType EQUALS attributeValue
+      attributeType = descr / numericoid
+      attributeValue = string / hexstring
+
+      ; The following characters are to be escaped when they appear
+      ; in the value to be encoded: ESC, one of <escaped>, leading
+      ; SHARP or SPACE, trailing SPACE, and NULL.
+      string =   [ ( leadchar / pair ) [ *( stringchar / pair )
+         ( trailchar / pair ) ] ]
+
+      leadchar = LUTF1 / UTFMB
+      LUTF1 = %x01-1F / %x21 / %x24-2A / %x2D-3A /
+         %x3D / %x3F-5B / %x5D-7F
+
+      trailchar  = TUTF1 / UTFMB
+      TUTF1 = %x01-1F / %x21 / %x23-2A / %x2D-3A /
+
+
+
+Zeilenga                    Standards Track                     [Page 5]
+
+RFC 4514               LDAP: Distinguished Names               June 2006
+
+
+         %x3D / %x3F-5B / %x5D-7F
+
+      stringchar = SUTF1 / UTFMB
+      SUTF1 = %x01-21 / %x23-2A / %x2D-3A /
+         %x3D / %x3F-5B / %x5D-7F
+
+      pair = ESC ( ESC / special / hexpair )
+      special = escaped / SPACE / SHARP / EQUALS
+      escaped = DQUOTE / PLUS / COMMA / SEMI / LANGLE / RANGLE
+      hexstring = SHARP 1*hexpair
+      hexpair = HEX HEX
+
+   where the productions <descr>, <numericoid>, <COMMA>, <DQUOTE>,
+   <EQUALS>, <ESC>, <HEX>, <LANGLE>, <NULL>, <PLUS>, <RANGLE>, <SEMI>,
+   <SPACE>, <SHARP>, and <UTFMB> are defined in [RFC4512].
+
+   Each <attributeType>, either a <descr> or a <numericoid>, refers to
+   an attribute type of an attribute value assertion (AVA).  The
+   <attributeType> is followed by an <EQUALS> and an <attributeValue>.
+   The <attributeValue> is either in <string> or <hexstring> form.
+
+   If in <string> form, a LDAP string representation asserted value can
+   be obtained by replacing (left to right, non-recursively) each <pair>
+   appearing in the <string> as follows:
+
+      replace <ESC><ESC> with <ESC>;
+      replace <ESC><special> with <special>;
+      replace <ESC><hexpair> with the octet indicated by the <hexpair>.
+
+   If in <hexstring> form, a BER representation can be obtained from
+   converting each <hexpair> of the <hexstring> to the octet indicated
+   by the <hexpair>.
+
+   There is one or more attribute value assertions, separated by <PLUS>,
+   for a relative distinguished name.
+
+   There is zero or more relative distinguished names, separated by
+   <COMMA>, for a distinguished name.
+
+   Implementations MUST recognize AttributeType name strings
+   (descriptors) listed in the following table, but MAY recognize other
+   name strings.
+
+
+
+
+
+
+
+
+
+Zeilenga                    Standards Track                     [Page 6]
+
+RFC 4514               LDAP: Distinguished Names               June 2006
+
+
+      String  X.500 AttributeType
+      ------  --------------------------------------------
+      CN      commonName (2.5.4.3)
+      L       localityName (2.5.4.7)
+      ST      stateOrProvinceName (2.5.4.8)
+      O       organizationName (2.5.4.10)
+      OU      organizationalUnitName (2.5.4.11)
+      C       countryName (2.5.4.6)
+      STREET  streetAddress (2.5.4.9)
+      DC      domainComponent (0.9.2342.19200300.100.1.25)
+      UID     userId (0.9.2342.19200300.100.1.1)
+
+   These attribute types are described in [RFC4519].
+
+   Implementations MAY recognize other DN string representations.
+   However, as there is no requirement that alternative DN string
+   representations be recognized (and, if so, how), implementations
+   SHOULD only generate DN strings in accordance with Section 2 of this
+   document.
+
+4.  Examples
+
+   This notation is designed to be convenient for common forms of name.
+   This section gives a few examples of distinguished names written
+   using this notation.  First is a name containing three relative
+   distinguished names (RDNs):
+
+      UID=jsmith,DC=example,DC=net
+
+   Here is an example of a name containing three RDNs, in which the
+   first RDN is multi-valued:
+
+      OU=Sales+CN=J.  Smith,DC=example,DC=net
+
+   This example shows the method of escaping of a special characters
+   appearing in a common name:
+
+      CN=James \"Jim\" Smith\, III,DC=example,DC=net
+
+   The following shows the method for encoding a value that contains a
+   carriage return character:
+
+      CN=Before\0dAfter,DC=example,DC=net
+
+   In this RDN example, the type in the RDN is unrecognized, and the
+   value is the BER encoding of an OCTET STRING containing two octets,
+   0x48 and 0x69.
+
+
+
+
+Zeilenga                    Standards Track                     [Page 7]
+
+RFC 4514               LDAP: Distinguished Names               June 2006
+
+
+      1.3.6.1.4.1.1466.0=#04024869
+
+   Finally, this example shows an RDN whose commonName value consists of
+   5 letters:
+
+      Unicode Character                Code       UTF-8   Escaped
+      -------------------------------  ------     ------  --------
+      LATIN CAPITAL LETTER L           U+004C     0x4C    L
+      LATIN SMALL LETTER U             U+0075     0x75    u
+      LATIN SMALL LETTER C WITH CARON  U+010D     0xC48D  \C4\8D
+      LATIN SMALL LETTER I             U+0069     0x69    i
+      LATIN SMALL LETTER C WITH ACUTE  U+0107     0xC487  \C4\87
+
+   This could be encoded in printable ASCII [ASCII] (useful for
+   debugging purposes) as:
+
+      CN=Lu\C4\8Di\C4\87
+
+5.  Security Considerations
+
+   The following security considerations are specific to the handling of
+   distinguished names.  LDAP security considerations are discussed in
+   [RFC4511] and other documents comprising the LDAP Technical
+   Specification [RFC4510].
+
+5.1.  Disclosure
+
+   Distinguished Names typically consist of descriptive information
+   about the entries they name, which can be people, organizations,
+   devices, or other real-world objects.  This frequently includes some
+   of the following kinds of information:
+
+      - the common name of the object (i.e., a person's full name)
+      - an email or TCP/IP address
+      - its physical location (country, locality, city, street address)
+      - organizational attributes (such as department name or
+        affiliation)
+
+   In some cases, such information can be considered sensitive.  In many
+   countries, privacy laws exist that prohibit disclosure of certain
+   kinds of descriptive information (e.g., email addresses).  Hence,
+   server implementers are encouraged to support Directory Information
+   Tree (DIT) structural rules and name forms [RFC4512], as these
+   provide a mechanism for administrators to select appropriate naming
+   attributes for entries.  Administrators are encouraged to use
+   mechanisms, access controls, and other administrative controls that
+   may be available to restrict use of attributes containing sensitive
+   information in naming of entries.   Additionally, use of
+
+
+
+Zeilenga                    Standards Track                     [Page 8]
+
+RFC 4514               LDAP: Distinguished Names               June 2006
+
+
+   authentication and data security services in LDAP [RFC4513][RFC4511]
+   should be considered.
+
+5.2.  Use of Distinguished Names in Security Applications
+
+   The transformations of an AttributeValue value from its X.501 form to
+   an LDAP string representation are not always reversible back to the
+   same BER (Basic Encoding Rules) or DER (Distinguished Encoding Rules)
+   form.  An example of a situation that requires the DER form of a
+   distinguished name is the verification of an X.509 certificate.
+
+   For example, a distinguished name consisting of one RDN with one AVA,
+   in which the type is commonName and the value is of the TeletexString
+   choice with the letters 'Sam', would be represented in LDAP as the
+   string <CN=Sam>.  Another distinguished name in which the value is
+   still 'Sam', but is of the PrintableString choice, would have the
+   same representation <CN=Sam>.
+
+   Applications that require the reconstruction of the DER form of the
+   value SHOULD NOT use the string representation of attribute syntaxes
+   when converting a distinguished name to the LDAP format.  Instead,
+   they SHOULD use the hexadecimal form prefixed by the number sign ('#'
+   U+0023) as described in the first paragraph of Section 2.4.
+
+6.  Acknowledgements
+
+   This document is an update to RFC 2253, by Mark Wahl, Tim Howes, and
+   Steve Kille.  RFC 2253 was a product of the IETF ASID Working Group.
+
+   This document is a product of the IETF LDAPBIS Working Group.
+
+7.  References
+
+7.1.  Normative References
+
+   [REGISTRY]    IANA, Object Identifier Descriptors Registry,
+                 <http://www.iana.org/assignments/ldap-parameters>.
+
+   [Unicode]     The Unicode Consortium, "The Unicode Standard, Version
+                 3.2.0" is defined by "The Unicode Standard, Version
+                 3.0" (Reading, MA, Addison-Wesley, 2000.  ISBN 0-201-
+                 61633-5), as amended by the "Unicode Standard Annex
+                 #27: Unicode 3.1"
+                 (http://www.unicode.org/reports/tr27/) and by the
+                 "Unicode Standard Annex #28: Unicode 3.2"
+                 (http://www.unicode.org/reports/tr28/).
+
+
+
+
+
+Zeilenga                    Standards Track                     [Page 9]
+
+RFC 4514               LDAP: Distinguished Names               June 2006
+
+
+   [X.501]       International Telecommunication Union -
+                 Telecommunication Standardization Sector, "The
+                 Directory -- Models," X.501(1993) (also ISO/IEC 9594-
+                 2:1994).
+
+   [X.680]       International Telecommunication Union -
+                 Telecommunication Standardization Sector, "Abstract
+                 Syntax Notation One (ASN.1) - Specification of Basic
+                 Notation", X.680(1997) (also ISO/IEC 8824-1:1998).
+
+   [RFC2119]     Bradner, S., "Key words for use in RFCs to Indicate
+                 Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC3629]     Yergeau, F., "UTF-8, a transformation format of ISO
+                 10646", STD 63, RFC 3629, November 2003.
+
+   [RFC4234]     Crocker, D. and P. Overell, "Augmented BNF for Syntax
+                 Specifications: ABNF", RFC 4234, October 2005.
+
+   [RFC4510]     Zeilenga, K., Ed., "Lightweight Directory Access
+                 Protocol (LDAP): Technical Specification Road Map", RFC
+                 4510, June 2006.
+
+   [RFC4511]     Sermersheim, J., Ed., "Lightweight Directory Access
+                 Protocol (LDAP): The Protocol", RFC 4511, June 2006.
+
+   [RFC4512]     Zeilenga, K., "Lightweight Directory Access Protocol
+                 (LDAP): Directory Information Models", RFC 4512, June
+                 2006.
+
+   [RFC4513]     Harrison, R., Ed., "Lightweight Directory Access
+                 Protocol (LDAP): Authentication Methods and Security
+                 Mechanisms", RFC 4513, June 2006.
+
+   [RFC4517]     Legg, S., Ed., "Lightweight Directory Access Protocol
+                 (LDAP): Syntaxes and Matching Rules", RFC 4517, June
+                 2006.
+
+   [RFC4519]     Sciberras, A., Ed., "Lightweight Directory Access
+                 Protocol (LDAP): Schema for User Applications", RFC
+                 4519, June 2006.
+
+   [RFC4520]     Zeilenga, K., "Internet Assigned Numbers Authority
+                 (IANA) Considerations for the Lightweight Directory
+                 Access Protocol (LDAP)", BCP 64, RFC 4520, June 2006.
+
+
+
+
+
+
+Zeilenga                    Standards Track                    [Page 10]
+
+RFC 4514               LDAP: Distinguished Names               June 2006
+
+
+7.2.  Informative References
+
+   [ASCII]       Coded Character Set--7-bit American Standard Code for
+                 Information Interchange, ANSI X3.4-1986.
+
+   [CharModel]   Whistler, K. and M. Davis, "Unicode Technical Report
+                 #17, Character Encoding Model", UTR17,
+                 <http://www.unicode.org/unicode/reports/tr17/>, August
+                 2000.
+
+   [Glossary]    The Unicode Consortium, "Unicode Glossary",
+                 <http://www.unicode.org/glossary/>.
+
+   [X.500]       International Telecommunication Union -
+                 Telecommunication Standardization Sector, "The
+                 Directory -- Overview of concepts, models and
+                 services," X.500(1993) (also ISO/IEC 9594-1:1994).
+
+   [X.511]       International Telecommunication Union -
+                 Telecommunication Standardization Sector, "The
+                 Directory: Abstract Service Definition", X.511(1993)
+                 (also ISO/IEC 9594-3:1993).
+
+   [X.690]       International Telecommunication Union -
+                 Telecommunication Standardization Sector,
+                 "Specification of ASN.1 encoding rules: Basic Encoding
+                 Rules (BER), Canonical Encoding Rules (CER), and
+                 Distinguished Encoding Rules (DER)", X.690(1997) (also
+                 ISO/IEC 8825-1:1998).
+
+   [RFC2849]     Good, G., "The LDAP Data Interchange Format (LDIF) -
+                 Technical Specification", RFC 2849, June 2000.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga                    Standards Track                    [Page 11]
+
+RFC 4514               LDAP: Distinguished Names               June 2006
+
+
+Appendix A.  Presentation Issues
+
+   This appendix is provided for informational purposes only; it is not
+   a normative part of this specification.
+
+   The string representation described in this document is not intended
+   to be presented to humans without translation.  However, at times it
+   may be desirable to present non-translated DN strings to users.  This
+   section discusses presentation issues associated with non-translated
+   DN strings.  Issues with presentation of translated DN strings are
+   not discussed in this appendix.  Transcoding issues are also not
+   discussed in this appendix.
+
+   This appendix provides guidance for applications presenting DN
+   strings to users.  This section is not comprehensive; it does not
+   discuss all presentation issues that implementers may face.
+
+   Not all user interfaces are capable of displaying the full set of
+   Unicode characters.  Some Unicode characters are not displayable.
+
+   It is recommended that human interfaces use the optional hex pair
+   escaping mechanism (Section 2.3) to produce a string representation
+   suitable for display to the user.  For example, an application can
+   generate a DN string for display that escapes all non-printable
+   characters appearing in the AttributeValue's string representation
+   (as demonstrated in the final example of Section 4).
+
+   When a DN string is displayed in free-form text, it is often
+   necessary to distinguish the DN string from surrounding text.  While
+   this is often done with whitespace (as demonstrated in Section 4), it
+   is noted that DN strings may end with whitespace.  Careful readers of
+   Section 3 will note that the characters '<' (U+003C) and '>' (U+003E)
+   may only appear in the DN string if escaped.  These characters are
+   intended to be used in free-form text to distinguish a DN string from
+   surrounding text.  For example, <CN=Sam\ > distinguishes the string
+   representation of the DN composed of one RDN consisting of the AVA
+   (the commonName (CN) value 'Sam ') from the surrounding text.  It
+   should be noted to the user that the wrapping '<' and '>' characters
+   are not part of the DN string.
+
+   DN strings can be quite long.  It is often desirable to line-wrap
+   overly long DN strings in presentations.  Line wrapping should be
+   done by inserting whitespace after the RDN separator character or, if
+   necessary, after the AVA separator character.  It should be noted to
+   the user that the inserted whitespace is not part of the DN string
+   and is to be removed before use in LDAP.  For example, the following
+   DN string is long:
+
+
+
+
+Zeilenga                    Standards Track                    [Page 12]
+
+RFC 4514               LDAP: Distinguished Names               June 2006
+
+
+         CN=Kurt D.  Zeilenga,OU=Engineering,L=Redwood Shores,
+         O=OpenLDAP Foundation,ST=California,C=US
+
+   So it has been line-wrapped for readability.  The extra whitespace is
+   to be removed before the DN string is used in LDAP.
+
+   Inserting whitespace is not advised because it may not be obvious to
+   the user which whitespace is part of the DN string and which
+   whitespace was added for readability.
+
+   Another alternative is to use the LDAP Data Interchange Format (LDIF)
+   [RFC2849].  For example:
+
+         # This entry has a long DN...
+         dn: CN=Kurt D.  Zeilenga,OU=Engineering,L=Redwood Shores,
+          O=OpenLDAP Foundation,ST=California,C=US
+         CN: Kurt D.  Zeilenga
+         SN: Zeilenga
+         objectClass: person
+
+Appendix B.  Changes Made since RFC 2253
+
+   This appendix is provided for informational purposes only, it is not
+   a normative part of this specification.
+
+   The following substantive changes were made to RFC 2253:
+
+      - Removed IESG Note.  The IESG Note has been addressed.
+      - Replaced all references to ISO 10646-1 with [Unicode].
+      - Clarified (in Section 1) that this document does not define a
+        canonical string representation.
+      - Clarified that Section 2 describes the RECOMMENDED encoding
+        algorithm and that alternative algorithms are allowed.  Some
+        encoding options described in RFC 2253 are now treated as
+        alternative algorithms in this specification.
+      - Revised specification (in Section 2) to allow short names of any
+        registered attribute type to appear in string representations of
+        DNs instead of being restricted to a "published table".  Removed
+        "as an example" language.  Added statement (in Section 3)
+        allowing recognition of additional names but require recognition
+        of those names in the published table.  The table now appears in
+        Section 3.
+      - Removed specification of additional requirements for LDAPv2
+        implementations which also support LDAPv3 (RFC 2253, Section 4)
+        as LDAPv2 is now Historic.
+      - Allowed recognition of alternative string representations.
+      - Updated Section 2.4 to allow hex pair escaping of all characters
+        and clarified escaping for when multiple octet UTF-8 encodings
+
+
+
+Zeilenga                    Standards Track                    [Page 13]
+
+RFC 4514               LDAP: Distinguished Names               June 2006
+
+
+        are present.  Indicated that null (U+0000) character is to be
+        escaped.  Indicated that equals sign ('=' U+003D) character may
+        be escaped as '\='.
+      - Rewrote Section 3 to use ABNF as defined in RFC 4234.
+      - Updated the Section 3 ABNF.  Changes include:
+        + allowed AttributeType short names of length 1 (e.g., 'L'),
+        + used more restrictive <oid> production in AttributeTypes,
+        + did not require escaping of equals sign ('=' U+003D)
+          characters,
+        + did not require escaping of non-leading number sign ('#'
+          U+0023) characters,
+        + allowed space (' ' U+0020) to be escaped as '\ ',
+        + required hex escaping of null (U+0000) characters, and
+        + removed LDAPv2-only constructs.
+      - Updated Section 3 to describe how to parse elements of the
+        grammar.
+      - Rewrote examples.
+      - Added reference to documentations containing general LDAP
+        security considerations.
+      - Added discussion of presentation issues (Appendix A).
+      - Added this appendix.
+
+   In addition, numerous editorial changes were made.
+
+Editor's Address
+
+   Kurt D.  Zeilenga
+   OpenLDAP Foundation
+
+   EMail: Kurt@OpenLDAP.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga                    Standards Track                    [Page 14]
+
+RFC 4514               LDAP: Distinguished Names               June 2006
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2006).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Zeilenga                    Standards Track                    [Page 15]
+
diff --git a/source4/ldap_server/devdocs/rfc4515.txt b/source4/ldap_server/devdocs/rfc4515.txt
new file mode 100644
index 0000000000..86f03ebcd3
--- /dev/null
+++ b/source4/ldap_server/devdocs/rfc4515.txt
@@ -0,0 +1,675 @@
+
+
+
+
+
+
+Network Working Group                                      M. Smith, Ed.
+Request for Comments: 4515                           Pearl Crescent, LLC
+Obsoletes: 2254                                                 T. Howes
+Category: Standards Track                                  Opsware, Inc.
+                                                               June 2006
+
+
+             Lightweight Directory Access Protocol (LDAP):
+                String Representation of Search Filters
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   Lightweight Directory Access Protocol (LDAP) search filters are
+   transmitted in the LDAP protocol using a binary representation that
+   is appropriate for use on the network.  This document defines a
+   human-readable string representation of LDAP search filters that is
+   appropriate for use in LDAP URLs (RFC 4516) and in other
+   applications.
+
+Table of Contents
+
+   1. Introduction ....................................................2
+   2. LDAP Search Filter Definition ...................................2
+   3. String Search Filter Definition .................................3
+   4. Examples ........................................................5
+   5. Security Considerations .........................................7
+   6. Normative References ............................................7
+   7. Informative References ..........................................8
+   8. Acknowledgements ................................................8
+   Appendix A: Changes Since RFC 2254 .................................9
+      A.1. Technical Changes ..........................................9
+      A.2. Editorial Changes ..........................................9
+
+
+
+
+
+
+
+Smith and Howes             Standards Track                     [Page 1]
+
+RFC 4515     LDAP: String Representation of Search Filters     June 2006
+
+
+1.  Introduction
+
+   The Lightweight Directory Access Protocol (LDAP) [RFC4510] defines a
+   network representation of a search filter transmitted to an LDAP
+   server.  Some applications may find it useful to have a common way of
+   representing these search filters in a human-readable form; LDAP URLs
+   [RFC4516] are an example of one such application.  This document
+   defines a human-readable string format for representing the full
+   range of possible LDAP version 3 search filters, including extended
+   match filters.
+
+   This document is a integral part of the LDAP technical specification
+   [RFC4510], which obsoletes the previously defined LDAP technical
+   specification, RFC 3377, in its entirety.
+
+   This document replaces RFC 2254.  Changes to RFC 2254 are summarized
+   in Appendix A.
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in BCP 14 [RFC2119].
+
+2.  LDAP Search Filter Definition
+
+   An LDAP search filter is defined in Section 4.5.1 of [RFC4511] as
+   follows:
+
+        Filter ::= CHOICE {
+            and                [0] SET SIZE (1..MAX) OF filter Filter,
+            or                 [1] SET SIZE (1..MAX) OF filter Filter,
+            not                [2] Filter,
+            equalityMatch      [3] AttributeValueAssertion,
+            substrings         [4] SubstringFilter,
+            greaterOrEqual     [5] AttributeValueAssertion,
+            lessOrEqual        [6] AttributeValueAssertion,
+            present            [7] AttributeDescription,
+            approxMatch        [8] AttributeValueAssertion,
+            extensibleMatch    [9] MatchingRuleAssertion }
+
+        SubstringFilter ::= SEQUENCE {
+            type    AttributeDescription,
+            -- initial and final can occur at most once
+            substrings    SEQUENCE SIZE (1..MAX) OF substring CHOICE {
+             initial        [0] AssertionValue,
+             any            [1] AssertionValue,
+             final          [2] AssertionValue } }
+
+
+
+
+
+Smith and Howes             Standards Track                     [Page 2]
+
+RFC 4515     LDAP: String Representation of Search Filters     June 2006
+
+
+        AttributeValueAssertion ::= SEQUENCE {
+            attributeDesc   AttributeDescription,
+            assertionValue  AssertionValue }
+
+        MatchingRuleAssertion ::= SEQUENCE {
+            matchingRule    [1] MatchingRuleId OPTIONAL,
+            type            [2] AttributeDescription OPTIONAL,
+            matchValue      [3] AssertionValue,
+            dnAttributes    [4] BOOLEAN DEFAULT FALSE }
+
+        AttributeDescription ::= LDAPString
+                        -- Constrained to <attributedescription>
+                        -- [RFC4512]
+
+        AttributeValue ::= OCTET STRING
+
+        MatchingRuleId ::= LDAPString
+
+        AssertionValue ::= OCTET STRING
+
+        LDAPString ::= OCTET STRING -- UTF-8 encoded,
+                                    -- [Unicode] characters
+
+   The AttributeDescription, as defined in [RFC4511], is a string
+   representation of the attribute description that is discussed in
+   [RFC4512].  The AttributeValue and AssertionValue OCTET STRING have
+   the form defined in [RFC4517].  The Filter is encoded for
+   transmission over a network using the Basic Encoding Rules (BER)
+   defined in [X.690], with simplifications described in [RFC4511].
+
+3.  String Search Filter Definition
+
+   The string representation of an LDAP search filter is a string of
+   UTF-8 [RFC3629] encoded Unicode characters [Unicode] that is defined
+   by the following grammar, following the ABNF notation defined in
+   [RFC4234].  The productions used that are not defined here are
+   defined in Section 1.4 (Common ABNF Productions) of [RFC4512] unless
+   otherwise noted.  The filter format uses a prefix notation.
+
+      filter         = LPAREN filtercomp RPAREN
+      filtercomp     = and / or / not / item
+      and            = AMPERSAND filterlist
+      or             = VERTBAR filterlist
+      not            = EXCLAMATION filter
+      filterlist     = 1*filter
+      item           = simple / present / substring / extensible
+      simple         = attr filtertype assertionvalue
+      filtertype     = equal / approx / greaterorequal / lessorequal
+
+
+
+Smith and Howes             Standards Track                     [Page 3]
+
+RFC 4515     LDAP: String Representation of Search Filters     June 2006
+
+
+      equal          = EQUALS
+      approx         = TILDE EQUALS
+      greaterorequal = RANGLE EQUALS
+      lessorequal    = LANGLE EQUALS
+      extensible     = ( attr [dnattrs]
+                           [matchingrule] COLON EQUALS assertionvalue )
+                       / ( [dnattrs]
+                            matchingrule COLON EQUALS assertionvalue )
+      present        = attr EQUALS ASTERISK
+      substring      = attr EQUALS [initial] any [final]
+      initial        = assertionvalue
+      any            = ASTERISK *(assertionvalue ASTERISK)
+      final          = assertionvalue
+      attr           = attributedescription
+                         ; The attributedescription rule is defined in
+                         ; Section 2.5 of [RFC4512].
+      dnattrs        = COLON "dn"
+      matchingrule   = COLON oid
+      assertionvalue = valueencoding
+      ; The <valueencoding> rule is used to encode an <AssertionValue>
+      ; from Section 4.1.6 of [RFC4511].
+      valueencoding  = 0*(normal / escaped)
+      normal         = UTF1SUBSET / UTFMB
+      escaped        = ESC HEX HEX
+      UTF1SUBSET     = %x01-27 / %x2B-5B / %x5D-7F
+                          ; UTF1SUBSET excludes 0x00 (NUL), LPAREN,
+                          ; RPAREN, ASTERISK, and ESC.
+      EXCLAMATION    = %x21 ; exclamation mark ("!")
+      AMPERSAND      = %x26 ; ampersand (or AND symbol) ("&")
+      ASTERISK       = %x2A ; asterisk ("*")
+      COLON          = %x3A ; colon (":")
+      VERTBAR        = %x7C ; vertical bar (or pipe) ("|")
+      TILDE          = %x7E ; tilde ("~")
+
+   Note that although both the <substring> and <present> productions in
+   the grammar above can produce the "attr=*" construct, this construct
+   is used only to denote a presence filter.
+
+   The <valueencoding> rule ensures that the entire filter string is a
+   valid UTF-8 string and provides that the octets that represent the
+   ASCII characters "*" (ASCII 0x2a), "(" (ASCII 0x28), ")" (ASCII
+   0x29), "\" (ASCII 0x5c), and NUL (ASCII 0x00) are represented as a
+   backslash "\" (ASCII 0x5c) followed by the two hexadecimal digits
+   representing the value of the encoded octet.
+
+
+
+
+
+
+
+Smith and Howes             Standards Track                     [Page 4]
+
+RFC 4515     LDAP: String Representation of Search Filters     June 2006
+
+
+   This simple escaping mechanism eliminates filter-parsing ambiguities
+   and allows any filter that can be represented in LDAP to be
+   represented as a NUL-terminated string.  Other octets that are part
+   of the <normal> set may be escaped using this mechanism, for example,
+   non-printing ASCII characters.
+
+   For AssertionValues that contain UTF-8 character data, each octet of
+   the character to be escaped is replaced by a backslash and two hex
+   digits, which form a single octet in the code of the character.  For
+   example, the filter checking whether the "cn" attribute contained a
+   value with the character "*" anywhere in it would be represented as
+   "(cn=*\2a*)".
+
+   As indicated by the <valueencoding> rule, implementations MUST escape
+   all octets greater than 0x7F that are not part of a valid UTF-8
+   encoding sequence when they generate a string representation of a
+   search filter.  Implementations SHOULD accept as input strings that
+   are not valid UTF-8 strings.  This is necessary because RFC 2254 did
+   not clearly define the term "string representation" (and in
+   particular did not mention that the string representation of an LDAP
+   search filter is a string of UTF-8-encoded Unicode characters).
+
+4.  Examples
+
+   This section gives a few examples of search filters written using
+   this notation.
+
+        (cn=Babs Jensen)
+        (!(cn=Tim Howes))
+        (&(objectClass=Person)(|(sn=Jensen)(cn=Babs J*)))
+        (o=univ*of*mich*)
+        (seeAlso=)
+
+   The following examples illustrate the use of extensible matching.
+
+        (cn:caseExactMatch:=Fred Flintstone)
+        (cn:=Betty Rubble)
+        (sn:dn:2.4.6.8.10:=Barney Rubble)
+        (o:dn:=Ace Industry)
+        (:1.2.3:=Wilma Flintstone)
+        (:DN:2.4.6.8.10:=Dino)
+
+   The first example shows use of the matching rule "caseExactMatch."
+
+   The second example demonstrates use of a MatchingRuleAssertion form
+   without a matchingRule.
+
+
+
+
+
+Smith and Howes             Standards Track                     [Page 5]
+
+RFC 4515     LDAP: String Representation of Search Filters     June 2006
+
+
+   The third example illustrates the use of the ":oid" notation to
+   indicate that the matching rule identified by the OID "2.4.6.8.10"
+   should be used when making comparisons, and that the attributes of an
+   entry's distinguished name should be considered part of the entry
+   when evaluating the match (indicated by the use of ":dn").
+
+   The fourth example denotes an equality match, except that DN
+   components should be considered part of the entry when doing the
+   match.
+
+   The fifth example is a filter that should be applied to any attribute
+   supporting the matching rule given (since the <attr> has been
+   omitted).
+
+   The sixth and final example is also a filter that should be applied
+   to any attribute supporting the matching rule given.  Attributes
+   supporting the matching rule contained in the DN should also be
+   considered.
+
+   The following examples illustrate the use of the escaping mechanism.
+
+        (o=Parens R Us \28for all your parenthetical needs\29)
+        (cn=*\2A*)
+        (filename=C:\5cMyFile)
+        (bin=\00\00\00\04)
+        (sn=Lu\c4\8di\c4\87)
+        (1.3.6.1.4.1.1466.0=\04\02\48\69)
+
+   The first example shows the use of the escaping mechanism to
+   represent parenthesis characters.  The second shows how to represent
+   a "*" in an assertion value, preventing it from being interpreted as
+   a substring indicator.  The third illustrates the escaping of the
+   backslash character.
+
+   The fourth example shows a filter searching for the four-octet value
+   00 00 00 04 (hex), illustrating the use of the escaping mechanism to
+   represent arbitrary data, including NUL characters.
+
+   The fifth example illustrates the use of the escaping mechanism to
+   represent various non-ASCII UTF-8 characters.  Specifically, there
+   are 5 characters in the <assertionvalue> portion of this example:
+   LATIN CAPITAL LETTER L (U+004C), LATIN SMALL LETTER U (U+0075), LATIN
+   SMALL LETTER C WITH CARON (U+010D), LATIN SMALL LETTER I (U+0069),
+   and LATIN SMALL LETTER C WITH ACUTE (U+0107).
+
+   The sixth and final example demonstrates assertion of a BER-encoded
+   value.
+
+
+
+
+Smith and Howes             Standards Track                     [Page 6]
+
+RFC 4515     LDAP: String Representation of Search Filters     June 2006
+
+
+5.  Security Considerations
+
+   This memo describes a string representation of LDAP search filters.
+   While the representation itself has no known security implications,
+   LDAP search filters do.  They are interpreted by LDAP servers to
+   select entries from which data is retrieved.  LDAP servers should
+   take care to protect the data they maintain from unauthorized access.
+
+   Please refer to the Security Considerations sections of [RFC4511] and
+   [RFC4513] for more information.
+
+6.  Normative References
+
+   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
+               Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC3629]   Yergeau, F., "UTF-8, a transformation format of ISO
+               10646", STD 63, RFC 3629, November 2003.
+
+   [RFC4234]   Crocker, D. and P. Overell, "Augmented BNF for Syntax
+               Specifications: ABNF", RFC 4234, October 2005.
+
+   [RFC4510]   Zeilenga, K., Ed., "Lightweight Directory Access Protocol
+               (LDAP): Technical Specification Road Map", RFC 4510, June
+               2006.
+
+   [RFC4511]   Sermersheim, J., Ed., "Lightweight Directory Access
+               Protocol (LDAP): The Protocol", RFC 4511, June 2006.
+
+   [RFC4512]   Zeilenga, K., "Lightweight Directory Access Protocol
+               (LDAP): Directory Information Models", RFC 4512, June
+               2006.
+
+   [RFC4513]   Harrison, R., Ed., "Lightweight Directory Access Protocol
+               (LDAP): Authentication Methods and Security Mechanisms",
+               RFC 4513, June 2006.
+
+   [RFC4517]   Legg, S., Ed., "Lightweight Directory Access Protocol
+               (LDAP): Syntaxes and Matching Rules", RFC 4517, June
+               2006.
+
+   [Unicode]   The Unicode Consortium, "The Unicode Standard, Version
+               3.2.0" is defined by "The Unicode Standard, Version 3.0"
+               (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5),
+               as amended by the "Unicode Standard Annex #27: Unicode
+               3.1" (http://www.unicode.org/reports/tr27/) and by the
+               "Unicode Standard Annex #28: Unicode 3.2."
+
+
+
+
+Smith and Howes             Standards Track                     [Page 7]
+
+RFC 4515     LDAP: String Representation of Search Filters     June 2006
+
+
+7.  Informative References
+
+   [RFC4516]   Smith, M., Ed. and T. Howes, "Lightweight Directory
+               Access Protocol (LDAP): Uniform Resource Locator", RFC
+               4516, June 2006.
+
+   [X.690]     Specification of ASN.1 encoding rules: Basic, Canonical,
+               and Distinguished Encoding Rules, ITU-T Recommendation
+               X.690, 1994.
+
+8.  Acknowledgements
+
+   This document replaces RFC 2254 by Tim Howes.  RFC 2254 was a product
+   of the IETF ASID Working Group.
+
+   Changes included in this revised specification are based upon
+   discussions among the authors, discussions within the LDAP (v3)
+   Revision Working Group (ldapbis), and discussions within other IETF
+   Working Groups.  The contributions of individuals in these working
+   groups is gratefully acknowledged.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Smith and Howes             Standards Track                     [Page 8]
+
+RFC 4515     LDAP: String Representation of Search Filters     June 2006
+
+
+Appendix A: Changes Since RFC 2254
+
+A.1.  Technical Changes
+
+   Replaced [ISO 10646] reference with [Unicode].
+
+   The following technical changes were made to the contents of the
+   "String Search Filter Definition" section:
+
+   Added statement that the string representation is a string of UTF-8-
+   encoded Unicode characters.
+
+   Revised all of the ABNF to use common productions from [RFC4512].
+
+   Replaced the "value" rule with a new "assertionvalue" rule within the
+   "simple", "extensible", and "substring" ("initial", "any", and
+   "final") rules.  This matches a change made in [RFC4517].
+
+   Added "(" and ")" around the components of the <extensible>
+   subproductions for clarity.
+
+   Revised the "attr", "matchingrule", and "assertionvalue" ABNF to more
+   precisely reference productions from the [RFC4512] and [RFC4511]
+   documents.
+
+   "String Search Filter Definition" section: replaced "greater" and
+   "less" with "greaterorequal" and "lessorequal" to avoid confusion.
+
+   Introduced the "valueencoding" and associated "normal" and "escaped"
+   rules to reduce the dependence on descriptive text.  The "normal"
+   production restricts filter strings to valid UTF-8 sequences.
+
+   Added a statement about expected behavior in light of RFC 2254's lack
+   of a clear definition of "string representation."
+
+A.2.  Editorial Changes
+
+   Changed document title to include "LDAP:" prefix.
+
+   IESG Note: removed note about lack of satisfactory mandatory
+   authentication mechanisms.
+
+   Header and "Authors' Addresses" sections: added Mark Smith as the
+   document editor and updated affiliation and contact information.
+
+   "Table of Contents" and "Intellectual Property" sections: added.
+
+   Copyright: updated per latest IETF guidelines.
+
+
+
+Smith and Howes             Standards Track                     [Page 9]
+
+RFC 4515     LDAP: String Representation of Search Filters     June 2006
+
+
+   "Abstract" section: separated from introductory material.
+
+   "Introduction" section: new section; separated from the Abstract.
+   Updated second paragraph to indicate that RFC 2254 is replaced by
+   this document (instead of RFC 1960).  Added reference to the
+   [RFC4510] document.
+
+   "LDAP Search Filter Definition" section: made corrections to the LDAP
+   search filter ABNF so it matches that used in [RFC4511].
+
+   Clarified the definition of 'value' (now 'assertionvalue') to take
+   into account the fact that it is not precisely an AttributeAssertion
+   from [RFC4511] Section 4.1.6 (special handling is required for some
+   characters).  Added a note that each octet of a character to be
+   escaped is replaced by a backslash and two hex digits, which
+   represent a single octet.
+
+   "Examples" section: added four additional examples: (seeAlso=),
+   (cn:=Betty Rubble), (:1.2.3:=Wilma Flintstone), and
+   (1.3.6.1.4.1.1466.0=\04\02\48\69).  Replaced one occurrence of "a
+   value" with "an assertion value".  Corrected the description of this
+   example: (sn:dn:2.4.6.8.10:=Barney Rubble).  Replaced the numeric OID
+   in the first extensible match example with "caseExactMatch" to
+   demonstrate use of the descriptive form.  Used "DN" (uppercase) in
+   the last extensible match example to remind the reader to treat the
+   <dnattrs> production as case insensitive.  Reworded the description
+   of the fourth escaping mechanism example to avoid making assumptions
+   about byte order.  Added text to the fifth escaping mechanism example
+   to spell out what the non-ASCII characters are in Unicode terms.
+
+   "Security Considerations" section: added references to [RFC4511] and
+   [RFC4513].
+
+   "Normative References" section: renamed from "References" per new RFC
+   guidelines.  Changed from [1] style to [RFC4511] style throughout the
+   document.  Added entries for [Unicode], [RFC2119], [RFC4513],
+   [RFC4512], and [RFC4510] and updated the UTF-8 reference.  Replaced
+   RFC 822 reference with a reference to RFC 4234.
+
+   "Informative References" section: (new section) moved [X.690] to this
+   section.  Added a reference to [RFC4516].
+
+   "Acknowledgements" section: added.
+
+   "Appendix A: Changes Since RFC 2254" section: added.
+
+   Surrounded the names of all ABNF productions with "<" and ">" where
+   they are used in descriptive text.
+
+
+
+Smith and Howes             Standards Track                    [Page 10]
+
+RFC 4515     LDAP: String Representation of Search Filters     June 2006
+
+
+   Replaced all occurrences of "LDAPv3" with "LDAP."
+
+Authors' Addresses
+
+   Mark Smith, Editor
+   Pearl Crescent, LLC
+   447 Marlpool Dr.
+   Saline, MI 48176
+   USA
+
+   Phone: +1 734 944-2856
+   EMail: mcs@pearlcrescent.com
+
+
+   Tim Howes
+   Opsware, Inc.
+   599 N. Mathilda Ave.
+   Sunnyvale, CA 94085
+   USA
+
+   Phone: +1 408 744-7509
+   EMail: howes@opsware.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Smith and Howes             Standards Track                    [Page 11]
+
+RFC 4515     LDAP: String Representation of Search Filters     June 2006
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2006).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Smith and Howes             Standards Track                    [Page 12]
+
diff --git a/source4/ldap_server/devdocs/rfc4516.txt b/source4/ldap_server/devdocs/rfc4516.txt
new file mode 100644
index 0000000000..6de1e1d08a
--- /dev/null
+++ b/source4/ldap_server/devdocs/rfc4516.txt
@@ -0,0 +1,843 @@
+
+
+
+
+
+
+Network Working Group                                      M. Smith, Ed.
+Request for Comments: 4516                           Pearl Crescent, LLC
+Obsoletes: 2255                                                 T. Howes
+Category: Standards Track                                  Opsware, Inc.
+                                                               June 2006
+
+
+             Lightweight Directory Access Protocol (LDAP):
+                        Uniform Resource Locator
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   This document describes a format for a Lightweight Directory Access
+   Protocol (LDAP) Uniform Resource Locator (URL).  An LDAP URL
+   describes an LDAP search operation that is used to retrieve
+   information from an LDAP directory, or, in the context of an LDAP
+   referral or reference, an LDAP URL describes a service where an LDAP
+   operation may be progressed.
+
+Table of Contents
+
+   1. Introduction ....................................................2
+   2. URL Definition ..................................................2
+      2.1. Percent-Encoding ...........................................4
+   3. Defaults for Fields of the LDAP URL .............................5
+   4. Examples ........................................................6
+   5. Security Considerations .........................................8
+   6. Normative References ............................................9
+   7. Informative References .........................................10
+   8. Acknowledgements ...............................................10
+   Appendix A: Changes Since RFC 2255 ................................11
+      A.1. Technical Changes .........................................11
+      A.2. Editorial Changes .........................................11
+
+
+
+
+
+
+Smith & Howes               Standards Track                     [Page 1]
+
+RFC 4516             LDAP: Uniform Resource Locator            June 2006
+
+
+1.  Introduction
+
+   LDAP is the Lightweight Directory Access Protocol [RFC4510].  This
+   document specifies the LDAP URL format for version 3 of LDAP and
+   clarifies how LDAP URLs are resolved.  This document also defines an
+   extension mechanism for LDAP URLs.  This mechanism may be used to
+   provide access to new LDAP extensions.
+
+   Note that not all the parameters of the LDAP search operation
+   described in [RFC4511] can be expressed using the format defined in
+   this document.  Note also that URLs may be used to represent
+   reference knowledge, including that for non-search operations.
+
+   This document is an integral part of the LDAP technical specification
+   [RFC4510], which obsoletes the previously defined LDAP technical
+   specification, RFC 3377, in its entirety.
+
+   This document replaces RFC 2255.  See Appendix A for a list of
+   changes relative to RFC 2255.
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in BCP 14 [RFC2119].
+
+2.  URL Definition
+
+   An LDAP URL begins with the protocol prefix "ldap" and is defined by
+   the following grammar, following the ABNF notation defined in
+   [RFC4234].
+
+      ldapurl     = scheme COLON SLASH SLASH [host [COLON port]]
+                       [SLASH dn [QUESTION [attributes]
+                       [QUESTION [scope] [QUESTION [filter]
+                       [QUESTION extensions]]]]]
+                                      ; <host> and <port> are defined
+                                      ;   in Sections 3.2.2 and 3.2.3
+                                      ;   of [RFC3986].
+                                      ; <filter> is from Section 3 of
+                                      ;   [RFC4515], subject to the
+                                      ;   provisions of the
+                                      ;   "Percent-Encoding" section
+                                      ;   below.
+
+      scheme      = "ldap"
+
+
+
+
+
+
+
+Smith & Howes               Standards Track                     [Page 2]
+
+RFC 4516             LDAP: Uniform Resource Locator            June 2006
+
+
+      dn          = distinguishedName ; From Section 3 of [RFC4514],
+                                      ; subject to the provisions of
+                                      ; the "Percent-Encoding"
+                                      ; section below.
+
+      attributes  = attrdesc *(COMMA attrdesc)
+      attrdesc    = selector *(COMMA selector)
+      selector    = attributeSelector ; From Section 4.5.1 of
+                                      ; [RFC4511], subject to the
+                                      ; provisions of the
+                                      ; "Percent-Encoding" section
+                                      ; below.
+
+      scope       = "base" / "one" / "sub"
+      extensions  = extension *(COMMA extension)
+      extension   = [EXCLAMATION] extype [EQUALS exvalue]
+      extype      = oid               ; From section 1.4 of [RFC4512].
+
+      exvalue     = LDAPString        ; From section 4.1.2 of
+                                      ; [RFC4511], subject to the
+                                      ; provisions of the
+                                      ; "Percent-Encoding" section
+                                      ; below.
+
+      EXCLAMATION = %x21              ; exclamation mark ("!")
+      SLASH       = %x2F              ; forward slash ("/")
+      COLON       = %x3A              ; colon (":")
+      QUESTION    = %x3F              ; question mark ("?")
+
+   The "ldap" prefix indicates an entry or entries accessible from the
+   LDAP server running on the given hostname at the given portnumber.
+   Note that the <host> may contain literal IPv6 addresses as specified
+   in Section 3.2.2 of [RFC3986].
+
+   The <dn> is an LDAP Distinguished Name using the string format
+   described in [RFC4514].  It identifies the base object of the LDAP
+   search or the target of a non-search operation.
+
+   The <attributes> construct is used to indicate which attributes
+   should be returned from the entry or entries.
+
+   The <scope> construct is used to specify the scope of the search to
+   perform in the given LDAP server.  The allowable scopes are "base"
+   for a base object search, "one" for a one-level search, or "sub" for
+   a subtree search.
+
+
+
+
+
+
+Smith & Howes               Standards Track                     [Page 3]
+
+RFC 4516             LDAP: Uniform Resource Locator            June 2006
+
+
+   The <filter> is used to specify the search filter to apply to entries
+   within the specified scope during the search.  It has the format
+   specified in [RFC4515].
+
+   The <extensions> construct provides the LDAP URL with an
+   extensibility mechanism, allowing the capabilities of the URL to be
+   extended in the future.  Extensions are a simple comma-separated list
+   of type=value pairs, where the =value portion MAY be omitted for
+   options not requiring it.  Each type=value pair is a separate
+   extension.  These LDAP URL extensions are not necessarily related to
+   any of the LDAP extension mechanisms.  Extensions may be supported or
+   unsupported by the client resolving the URL.  An extension prefixed
+   with a '!' character (ASCII 0x21) is critical.  An extension not
+   prefixed with a '!' character is non-critical.
+
+   If an LDAP URL extension is implemented (that is, if the
+   implementation understands it and is able to use it), the
+   implementation MUST make use of it.  If an extension is not
+   implemented and is marked critical, the implementation MUST NOT
+   process the URL.  If an extension is not implemented and is not
+   marked critical, the implementation MUST ignore the extension.
+
+   The extension type (<extype>) MAY be specified using the numeric OID
+   <numericoid> form (e.g., 1.2.3.4) or the descriptor <descr> form
+   (e.g., myLDAPURLExtension).  Use of the <descr> form SHOULD be
+   restricted to registered object identifier descriptive names.  See
+   [RFC4520] for registration details and usage guidelines for
+   descriptive names.
+
+   No LDAP URL extensions are defined in this document.  Other documents
+   or a future version of this document MAY define one or more
+   extensions.
+
+2.1.  Percent-Encoding
+
+   A generated LDAP URL MUST consist only of the restricted set of
+   characters included in one of the following three productions defined
+   in [RFC3986]:
+
+         <reserved>
+         <unreserved>
+         <pct-encoded>
+
+   Implementations SHOULD accept other valid UTF-8 strings [RFC3629] as
+   input.  An octet MUST be encoded using the percent-encoding mechanism
+   described in section 2.1 of [RFC3986] in any of these situations:
+
+
+
+
+
+Smith & Howes               Standards Track                     [Page 4]
+
+RFC 4516             LDAP: Uniform Resource Locator            June 2006
+
+
+      The octet is not in the reserved set defined in section 2.2 of
+      [RFC3986] or in the unreserved set defined in section 2.3 of
+      [RFC3986].
+
+      It is the single Reserved character '?' and occurs inside a <dn>,
+      <filter>, or other element of an LDAP URL.
+
+      It is a comma character ',' that occurs inside an <exvalue>.
+
+   Note that before the percent-encoding mechanism is applied, the
+   extensions component of the LDAP URL may contain one or more null
+   (zero) bytes.  No other component may.
+
+3.  Defaults for Fields of the LDAP URL
+
+   Some fields of the LDAP URL are optional, as described above.  In the
+   absence of any other specification, the following general defaults
+   SHOULD be used when a field is absent.  Note that other documents MAY
+   specify different defaulting rules; for example, section 4.1.10 of
+   [RFC4511] specifies a different rule for determining the correct DN
+   to use when it is absent in an LDAP URL that is returned as a
+   referral.
+
+   <host>
+      If no <host> is given, the client must have some a priori
+      knowledge of an appropriate LDAP server to contact.
+
+   <port>
+      The default LDAP port is TCP port 389.
+
+   <dn>
+      If no <dn> is given, the default is the zero-length DN, "".
+
+   <attributes>
+      If the <attributes> part is omitted, all user attributes of the
+      entry or entries should be requested (e.g., by setting the
+      attributes field AttributeDescriptionList in the LDAP search
+      request to a NULL list, or by using the special <alluserattrs>
+      selector "*").
+
+   <scope>
+      If <scope> is omitted, a <scope> of "base" is assumed.
+
+   <filter>
+      If <filter> is omitted, a filter of "(objectClass=*)" is assumed.
+
+   <extensions>
+      If <extensions> is omitted, no extensions are assumed.
+
+
+
+Smith & Howes               Standards Track                     [Page 5]
+
+RFC 4516             LDAP: Uniform Resource Locator            June 2006
+
+
+4.  Examples
+
+   The following are some example LDAP URLs that use the format defined
+   above.  The first example is an LDAP URL referring to the University
+   of Michigan entry, available from an LDAP server of the client's
+   choosing:
+
+      ldap:///o=University%20of%20Michigan,c=US
+
+   The next example is an LDAP URL referring to the University of
+   Michigan entry in a particular ldap server:
+
+      ldap://ldap1.example.net/o=University%20of%20Michigan,c=US
+
+   Both of these URLs correspond to a base object search of the
+   "o=University of Michigan,c=US" entry using a filter of
+   "(objectclass=*)", requesting all attributes.
+
+   The next example is an LDAP URL referring to only the postalAddress
+   attribute of the University of Michigan entry:
+
+      ldap://ldap1.example.net/o=University%20of%20Michigan,
+             c=US?postalAddress
+
+   The corresponding LDAP search operation is the same as in the
+   previous example, except that only the postalAddress attribute is
+   requested.
+
+   The next example is an LDAP URL referring to the set of entries found
+   by querying the given LDAP server on port 6666 and doing a subtree
+   search of the University of Michigan for any entry with a common name
+   of "Babs Jensen", retrieving all attributes:
+
+      ldap://ldap1.example.net:6666/o=University%20of%20Michigan,
+             c=US??sub?(cn=Babs%20Jensen)
+
+   The next example is an LDAP URL referring to all children of the c=GB
+   entry:
+
+      LDAP://ldap1.example.com/c=GB?objectClass?ONE
+
+   The objectClass attribute is requested to be returned along with the
+   entries, and the default filter of "(objectclass=*)" is used.
+
+   The next example is an LDAP URL to retrieve the mail attribute for
+   the LDAP entry named "o=Question?,c=US", illustrating the use of the
+   percent-encoding mechanism on the reserved character '?'.
+
+
+
+
+Smith & Howes               Standards Track                     [Page 6]
+
+RFC 4516             LDAP: Uniform Resource Locator            June 2006
+
+
+      ldap://ldap2.example.com/o=Question%3f,c=US?mail
+
+   The next example (which is broken into two lines for readability)
+   illustrates the interaction between the LDAP string representation of
+   the filters-quoting mechanism and the URL-quoting mechanisms.
+
+      ldap://ldap3.example.com/o=Babsco,c=US
+              ???(four-octet=%5c00%5c00%5c00%5c04)
+
+   The filter in this example uses the LDAP escaping mechanism of \ to
+   encode three zero or null bytes in the value.  In LDAP, the filter
+   would be written as (four-octet=\00\00\00\04).  Because the \
+   character must be escaped in a URL, the \s are percent-encoded as %5c
+   (or %5C) in the URL encoding.
+
+   The next example illustrates the interaction between the LDAP string
+   representation of the DNs-quoting mechanism and URL-quoting
+   mechanisms.
+
+      ldap://ldap.example.com/o=An%20Example%5C2C%20Inc.,c=US
+
+   The DN encoded in the above URL is:
+
+      o=An Example\2C Inc.,c=US
+
+   That is, the left-most RDN value is:
+
+      An Example, Inc.
+
+   The following three URLs are equivalent, assuming that the defaulting
+   rules specified in Section 3 of this document are used:
+
+      ldap://ldap.example.net
+      ldap://ldap.example.net/
+      ldap://ldap.example.net/?
+
+   These three URLs point to the root DSE on the ldap.example.net
+   server.
+
+   The final two examples show use of a hypothetical, experimental bind
+   name extension (the value associated with the extension is an LDAP
+   DN).
+
+      ldap:///??sub??e-bindname=cn=Manager%2cdc=example%2cdc=com
+      ldap:///??sub??!e-bindname=cn=Manager%2cdc=example%2cdc=com
+
+
+
+
+
+
+Smith & Howes               Standards Track                     [Page 7]
+
+RFC 4516             LDAP: Uniform Resource Locator            June 2006
+
+
+   The two URLs are the same, except that the second one marks the
+   e-bindname extension as critical.  Notice the use of the percent-
+   encoding mechanism to encode the commas within the distinguished name
+   value in the e-bindname extension.
+
+5.  Security Considerations
+
+   The general URL security considerations discussed in [RFC3986] are
+   relevant for LDAP URLs.
+
+   The use of security mechanisms when processing LDAP URLs requires
+   particular care, since clients may encounter many different servers
+   via URLs, and since URLs are likely to be processed automatically,
+   without user intervention.  A client SHOULD have a user-configurable
+   policy that controls which servers the client will establish LDAP
+   sessions with and with which security mechanisms, and SHOULD NOT
+   establish LDAP sessions that are inconsistent with this policy.  If a
+   client chooses to reuse an existing LDAP session when resolving one
+   or more LDAP URLs, it MUST ensure that the session is compatible with
+   the URL and that no security policies are violated.
+
+   Sending authentication information, no matter the mechanism, may
+   violate a user's privacy requirements.  In the absence of specific
+   policy permitting authentication information to be sent to a server,
+   a client should use an anonymous LDAP session.  (Note that clients
+   conforming to previous LDAP URL specifications, where all LDAP
+   sessions are anonymous and unprotected, are consistent with this
+   specification; they simply have the default security policy.)  Simply
+   opening a transport connection to another server may violate some
+   users' privacy requirements, so clients should provide the user with
+   a way to control URL processing.
+
+   Some authentication methods, in particular, reusable passwords sent
+   to the server, may reveal easily-abused information to the remote
+   server or to eavesdroppers in transit and should not be used in URL
+   processing unless they are explicitly permitted by policy.
+   Confirmation by the human user of the use of authentication
+   information is appropriate in many circumstances.  Use of strong
+   authentication methods that do not reveal sensitive information is
+   much preferred.  If the URL represents a referral for an update
+   operation, strong authentication methods SHOULD be used.  Please
+   refer to the Security Considerations section of [RFC4513] for more
+   information.
+
+   The LDAP URL format allows the specification of an arbitrary LDAP
+   search operation to be performed when evaluating the LDAP URL.
+   Following an LDAP URL may cause unexpected results, for example, the
+   retrieval of large amounts of data or the initiation of a long-lived
+
+
+
+Smith & Howes               Standards Track                     [Page 8]
+
+RFC 4516             LDAP: Uniform Resource Locator            June 2006
+
+
+   search.  The security implications of resolving an LDAP URL are the
+   same as those of resolving an LDAP search query.
+
+6.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO
+              10646", STD 63, RFC 3629, November 2003.
+
+   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
+              Resource Identifier (URI): Generic Syntax", STD 66, RFC
+              3986, January 2005.
+
+   [RFC4234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
+              Specifications: ABNF", RFC 4234, October 2005.
+
+   [RFC4510]  Zeilenga, K., Ed., "Lightweight Directory Access Protocol
+              (LDAP): Technical Specification Road Map", RFC 4510, June
+              2006.
+
+   [RFC4511]  Sermersheim, J., Ed., "Lightweight Directory Access
+              Protocol (LDAP): The Protocol", RFC 4511, June 2006.
+
+   [RFC4512]  Zeilenga, K., "Lightweight Directory Access Protocol
+              (LDAP): Directory Information Models", RFC 4512, June
+              2006.
+
+   [RFC4513]  Harrison, R., Ed., "Lightweight Directory Access Protocol
+              (LDAP): Authentication Methods and Security Mechanisms",
+              RFC 4513, June 2006.
+
+   [RFC4514]  Zeilenga, K., Ed., "Lightweight Directory Access Protocol
+              (LDAP): String Representation of Distinguished Names", RFC
+              4514, June 2006.
+
+   [RFC4515]  Smith, M. Ed. and T. Howes, "Lightweight Directory Access
+              Protocol (LDAP): String Representation of Search Filters",
+              RFC 4515, June 2006.
+
+
+
+
+
+
+
+
+
+
+
+Smith & Howes               Standards Track                     [Page 9]
+
+RFC 4516             LDAP: Uniform Resource Locator            June 2006
+
+
+7.  Informative References
+
+   [RFC2396]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
+              Resource Identifiers (URI): Generic Syntax", RFC 2396,
+              August 1998.
+
+   [RFC4520]  Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
+              Considerations for the Lightweight Directory Access
+              Protocol (LDAP)", BCP 64, RFC 4520, June 2006.
+
+8.  Acknowledgements
+
+   The LDAP URL format was originally defined at the University of
+   Michigan.  This material is based upon work supported by the National
+   Science Foundation under Grant No. NCR-9416667.  The support of both
+   the University of Michigan and the National Science Foundation is
+   gratefully acknowledged.
+
+   This document obsoletes RFC 2255 by Tim Howes and Mark Smith.
+   Changes included in this revised specification are based upon
+   discussions among the authors, discussions within the LDAP (v3)
+   Revision Working Group (ldapbis), and discussions within other IETF
+   Working Groups.  The contributions of individuals in these working
+   groups is gratefully acknowledged.  Several people in particular have
+   made valuable comments on this document: RL "Bob" Morgan, Mark Wahl,
+   Kurt Zeilenga, Jim Sermersheim, and Hallvard Furuseth deserve special
+   thanks for their contributions.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Smith & Howes               Standards Track                    [Page 10]
+
+RFC 4516             LDAP: Uniform Resource Locator            June 2006
+
+
+Appendix A: Changes Since RFC 2255
+
+A.1.  Technical Changes
+
+   The following technical changes were made to the contents of the "URL
+   Definition" section:
+
+   Revised all of the ABNF to use common productions from [RFC4512].
+
+   Replaced references to [RFC2396] with a reference to [RFC3986] (this
+   allows literal IPv6 addresses to be used inside the <host> portion of
+   the URL, and a note was added to remind the reader of this
+   enhancement).  Referencing [RFC3986] required changes to the ABNF and
+   text so that productions that are no longer defined by [RFC3986] are
+   not used.  For example, <hostport> is not defined by [RFC3986] so it
+   has been replaced with host [COLON port].  Note that [RFC3986]
+   includes new definitions for the "Reserved" and "Unreserved" sets of
+   characters, and the net result is that the following two additional
+   characters should be percent-encoded when they appear anywhere in the
+   data used to construct an LDAP URL: "[" and "]" (these two characters
+   were first added to the Reserved set by RFC 2732).
+
+   Changed the definition of <attrdesc> to refer to <attributeSelector>
+   from [RFC4511].  This allows the use of "*" in the <attrdesc> part of
+   the URL.  It is believed that existing implementations of RFC 2255
+   already support this.
+
+   Avoided use of <prose-val> (bracketed-string) productions in the
+   <dn>, <host>, <attrdesc>, and <exvalue> rules.
+
+   Changed the ABNF for <ldapurl> to group the <dn> component with the
+   preceding <SLASH>.
+
+   Changed the <extype> rule to be an <oid> from [RFC4512].
+
+   Changed the text about extension types so it references [RFC4520].
+   Reordered rules to more closely follow the order in which the
+   elements appear in the URL.
+
+   "Bindname Extension": removed due to lack of known implementations.
+
+A.2.  Editorial Changes
+
+   Changed document title to include "LDAP:" prefix.
+
+   IESG Note: removed note about lack of satisfactory mandatory
+   authentication mechanisms.
+
+
+
+
+Smith & Howes               Standards Track                    [Page 11]
+
+RFC 4516             LDAP: Uniform Resource Locator            June 2006
+
+
+   "Status of this Memo" section: updated boilerplate to match current
+   I-D guidelines.
+
+   "Abstract" section: separated from introductory material.
+
+   "Table of Contents" and "Intellectual Property" sections: added.
+
+   "Introduction" section: new section; separated from the Abstract.
+   Changed the text indicate that RFC 2255 is replaced by this document
+   (instead of RFC 1959).  Added text to indicate that LDAP URLs are
+   used for references and referrals.  Fixed typo (replaced the nonsense
+   phrase "to perform to retrieve" with "used to retrieve").  Added a
+   note to let the reader know that not all of the parameters of the
+   LDAP search operation described in [RFC4511] can be expressed using
+   this format.
+
+   "URL Definition" section: removed second copy of <ldapurl> grammar
+   and following two paragraphs (editorial error in RFC 2255).  Fixed
+   line break within '!' sequence.  Reformatted the ABNF to improve
+   readability by aligning comments and adding some blank lines.
+   Replaced "residing in the LDAP server" with "accessible from the LDAP
+   server" in the sentence immediately following the ABNF.  Removed the
+   sentence "Individual attrdesc names are as defined for
+   AttributeDescription in [RFC4511]."  because [RFC4511]'s
+   <attributeSelector> is now used directly in the ABNF.  Reworded last
+   paragraph to clarify which characters must be percent-encoded.  Added
+   text to indicate that LDAP URLs are used for references and
+   referrals.  Added text that refers to the ABNF from RFC 4234.
+   Clarified and strengthened the requirements with respect to
+   processing of URLs that contain implemented and not implemented
+   extensions (the approach now closely matches that specified in
+   [RFC4511] for LDAP controls).
+
+   "Defaults for Fields of the LDAP URL" section: added; formed by
+   moving text about defaults out of the "URL Definition" section.
+   Replaced direct reference to the attribute name "*" with a reference
+   to the special <alluserattrs> selector "*" defined in [RFC4511].
+
+   "URL Processing" section: removed.
+
+   "Examples" section: Modified examples to use example.com and
+   example.net hostnames.  Added missing '?' to the LDAP URL example
+   whose filter contains three null bytes.  Removed space after one
+   comma within a DN.  Revised the bindname example to use e-bindname.
+   Changed the name of an attribute used in one example from "int" to
+   "four-octet" to avoid potential confusion.  Added an example that
+   demonstrates the interaction between DN escaping and URL percent-
+   encoding.  Added some examples to show URL equivalence with respect
+
+
+
+Smith & Howes               Standards Track                    [Page 12]
+
+RFC 4516             LDAP: Uniform Resource Locator            June 2006
+
+
+   to the <dn> portion of the URL.  Used uppercase in some examples to
+   remind the reader that some tokens are case-insensitive.
+
+   "Security Considerations" section: Added a note about connection
+   reuse.  Added a note about using strong authentication methods for
+   updates.  Added a reference to [RFC4513].  Added note that simply
+   opening a connection may violate some users' privacy requirements.
+   Adopted the working group's revised LDAP terminology specification by
+   replacing the word "connection" with "LDAP session" or "LDAP
+   connection" as appropriate.
+
+   "Acknowledgements" section: added statement that this document
+   obsoletes RFC 2255.  Added Kurt Zeilenga, Jim Sermersheim, and
+   Hallvard Furuseth.
+
+   "Normative References" section: renamed from "References" per new RFC
+   guidelines.  Changed from [1] style to [RFC4511] style throughout the
+   document.  Added references to RFC 4234 and RFC 3629.  Updated all
+   RFC 1738 references to point to the appropriate sections within
+   [RFC3986].  Updated the LDAP references to refer to LDAPBis WG
+   documents.  Removed the reference to the LDAP Attribute Syntaxes
+   document and added references to the [RFC4513], [RFC4520], and
+   [RFC4510] documents.
+
+   "Informative References" section: added.
+
+   Header and "Authors' Addresses" sections: added "editor" next to Mark
+   Smith's name.  Updated affiliation and contact information.
+
+   Copyright: updated the year.
+
+   Throughout the document: surrounded the names of all ABNF productions
+   with "<" and ">" where they are used in descriptive text.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Smith & Howes               Standards Track                    [Page 13]
+
+RFC 4516             LDAP: Uniform Resource Locator            June 2006
+
+
+Authors' Addresses
+
+   Mark Smith, Editor
+   Pearl Crescent, LLC
+   447 Marlpool Dr.
+   Saline, MI 48176
+   USA
+
+   Phone: +1 734 944-2856
+   EMail: mcs@pearlcrescent.com
+
+
+   Tim Howes
+   Opsware, Inc.
+   599 N. Mathilda Ave.
+   Sunnyvale, CA 94085
+   USA
+
+   Phone: +1 408 744-7509
+   EMail: howes@opsware.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Smith & Howes               Standards Track                    [Page 14]
+
+RFC 4516             LDAP: Uniform Resource Locator            June 2006
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2006).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Smith & Howes               Standards Track                    [Page 15]
+
diff --git a/source4/ldap_server/devdocs/rfc4517.txt b/source4/ldap_server/devdocs/rfc4517.txt
new file mode 100644
index 0000000000..177e08b2ac
--- /dev/null
+++ b/source4/ldap_server/devdocs/rfc4517.txt
@@ -0,0 +1,2971 @@
+
+
+
+
+
+
+Network Working Group                                       S. Legg, Ed.
+Request for Comments: 4517                                       eB2Bcom
+Obsoletes: 2252, 2256                                          June 2006
+Updates: 3698
+Category: Standards Track
+
+
+             Lightweight Directory Access Protocol (LDAP):
+                      Syntaxes and Matching Rules
+
+
+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
+
+   Each attribute stored in a Lightweight Directory Access Protocol
+   (LDAP) directory, whose values may be transferred in the LDAP
+   protocol, has a defined syntax that constrains the structure and
+   format of its values.  The comparison semantics for values of a
+   syntax are not part of the syntax definition but are instead provided
+   through separately defined matching rules.  Matching rules specify an
+   argument, an assertion value, which also has a defined syntax.  This
+   document defines a base set of syntaxes and matching rules for use in
+   defining attributes for LDAP directories.
+
+Table of Contents
+
+   1. Introduction ....................................................3
+   2. Conventions .....................................................4
+   3. Syntaxes ........................................................4
+      3.1. General Considerations .....................................5
+      3.2. Common Definitions .........................................5
+      3.3. Syntax Definitions .........................................6
+           3.3.1. Attribute Type Description ..........................6
+           3.3.2. Bit String ..........................................6
+           3.3.3. Boolean .............................................7
+           3.3.4. Country String ......................................7
+           3.3.5. Delivery Method .....................................8
+
+
+
+Legg                        Standards Track                     [Page 1]
+
+RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
+
+
+           3.3.6. Directory String ....................................8
+           3.3.7. DIT Content Rule Description ........................9
+           3.3.8. DIT Structure Rule Description .....................10
+           3.3.9. DN .................................................10
+           3.3.10. Enhanced Guide ....................................11
+           3.3.11. Facsimile Telephone Number ........................12
+           3.3.12. Fax ...............................................12
+           3.3.13. Generalized Time ..................................13
+           3.3.14. Guide .............................................14
+           3.3.15. IA5 String ........................................15
+           3.3.16. Integer ...........................................15
+           3.3.17. JPEG ..............................................15
+           3.3.18. LDAP Syntax Description ...........................16
+           3.3.19. Matching Rule Description .........................16
+           3.3.20. Matching Rule Use Description .....................17
+           3.3.21. Name and Optional UID .............................17
+           3.3.22. Name Form Description .............................18
+           3.3.23. Numeric String ....................................18
+           3.3.24. Object Class Description ..........................18
+           3.3.25. Octet String ......................................19
+           3.3.26. OID ...............................................19
+           3.3.27. Other Mailbox .....................................20
+           3.3.28. Postal Address ....................................20
+           3.3.29. Printable String ..................................21
+           3.3.30. Substring Assertion ...............................22
+           3.3.31. Telephone Number ..................................23
+           3.3.32. Teletex Terminal Identifier .......................23
+           3.3.33. Telex Number ......................................24
+           3.3.34. UTC Time ..........................................24
+   4. Matching Rules .................................................25
+      4.1. General Considerations ....................................25
+      4.2. Matching Rule Definitions .................................27
+           4.2.1. bitStringMatch .....................................27
+           4.2.2. booleanMatch .......................................28
+           4.2.3. caseExactIA5Match ..................................28
+           4.2.4. caseExactMatch .....................................29
+           4.2.5. caseExactOrderingMatch .............................29
+           4.2.6. caseExactSubstringsMatch ...........................30
+           4.2.7. caseIgnoreIA5Match .................................30
+           4.2.8. caseIgnoreIA5SubstringsMatch .......................31
+           4.2.9. caseIgnoreListMatch ................................31
+           4.2.10. caseIgnoreListSubstringsMatch .....................32
+           4.2.11. caseIgnoreMatch ...................................33
+           4.2.12. caseIgnoreOrderingMatch ...........................33
+           4.2.13. caseIgnoreSubstringsMatch .........................34
+           4.2.14. directoryStringFirstComponentMatch ................34
+           4.2.15. distinguishedNameMatch ............................35
+           4.2.16. generalizedTimeMatch ..............................36
+
+
+
+Legg                        Standards Track                     [Page 2]
+
+RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
+
+
+           4.2.17. generalizedTimeOrderingMatch ......................36
+           4.2.18. integerFirstComponentMatch ........................36
+           4.2.19. integerMatch ......................................37
+           4.2.20. integerOrderingMatch ..............................37
+           4.2.21. keywordMatch ......................................38
+           4.2.22. numericStringMatch ................................38
+           4.2.23. numericStringOrderingMatch ........................39
+           4.2.24. numericStringSubstringsMatch ......................39
+           4.2.25. objectIdentifierFirstComponentMatch ...............40
+           4.2.26. objectIdentifierMatch .............................40
+           4.2.27. octetStringMatch ..................................41
+           4.2.28. octetStringOrderingMatch ..........................41
+           4.2.29. telephoneNumberMatch ..............................42
+           4.2.30. telephoneNumberSubstringsMatch ....................42
+           4.2.31. uniqueMemberMatch .................................43
+           4.2.32. wordMatch .........................................44
+   5. Security Considerations ........................................44
+   6. Acknowledgements ...............................................44
+   7. IANA Considerations ............................................45
+   8. References .....................................................46
+      8.1. Normative References ......................................46
+      8.2. Informative References ....................................48
+   Appendix A. Summary of Syntax Object Identifiers ..................49
+   Appendix B. Changes from RFC 2252 .................................49
+
+1.  Introduction
+
+   Each attribute stored in a Lightweight Directory Access Protocol
+   (LDAP) directory [RFC4510], whose values may be transferred in the
+   LDAP protocol [RFC4511], has a defined syntax (i.e., data type) that
+   constrains the structure and format of its values.  The comparison
+   semantics for values of a syntax are not part of the syntax
+   definition but are instead provided through separately defined
+   matching rules.  Matching rules specify an argument, an assertion
+   value, which also has a defined syntax.  This document defines a base
+   set of syntaxes and matching rules for use in defining attributes for
+   LDAP directories.
+
+   Readers are advised to familiarize themselves with the Directory
+   Information Models [RFC4512] before reading the rest of this
+   document.  Section 3 provides definitions for the base set of LDAP
+   syntaxes.  Section 4 provides definitions for the base set of
+   matching rules for LDAP.
+
+   This document is an integral part of the LDAP technical specification
+   [RFC4510], which obsoletes the previously defined LDAP technical
+   specification, RFC 3377, in its entirety.
+
+
+
+
+Legg                        Standards Track                     [Page 3]
+
+RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
+
+
+   Sections 4, 5, and 7 of RFC 2252 are obsoleted by [RFC4512].  The
+   remainder of RFC 2252 is obsoleted by this document.  Sections 6 and
+   8 of RFC 2256 are obsoleted by this document.  The remainder of RFC
+   2256 is obsoleted by [RFC4519] and [RFC4512].  All but Section 2.11
+   of RFC 3698 is obsoleted by this document.
+
+   A number of schema elements that were included in the previous
+   revision of the LDAP technical specification are not included in this
+   revision of LDAP.  Public Key Infrastructure schema elements are now
+   specified in [RFC4523].  Unless reintroduced in future technical
+   specifications, the remainder are to be considered Historic.
+
+   The changes with respect to RFC 2252 are described in Appendix B of
+   this document.
+
+2.  Conventions
+
+   In this document, the key words "MUST", "MUST NOT", "REQUIRED",
+   "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
+   and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119
+   [RFC2119].
+
+   Syntax definitions are written according to the <SyntaxDescription>
+   ABNF [RFC4234] rule specified in [RFC4512], and matching rule
+   definitions are written according to the <MatchingRuleDescription>
+   ABNF rule specified in [RFC4512], except that the syntax and matching
+   rule definitions provided in this document are line-wrapped for
+   readability.  When such definitions are transferred as attribute
+   values in the LDAP protocol (e.g., as values of the ldapSyntaxes and
+   matchingRules attributes [RFC4512], respectively), then those values
+   would not contain line breaks.
+
+3.  Syntaxes
+
+   Syntax definitions constrain the structure of attribute values stored
+   in an LDAP directory, and determine the representation of attribute
+   and assertion values transferred in the LDAP protocol.
+
+   Syntaxes that are required for directory operation, or that are in
+   common use, are specified in this section.  Servers SHOULD recognize
+   all the syntaxes listed in this document, but are not required to
+   otherwise support them, and MAY recognise or support other syntaxes.
+   However, the definition of additional arbitrary syntaxes is
+   discouraged since it will hinder interoperability.  Client and server
+   implementations typically do not have the ability to dynamically
+   recognize new syntaxes.
+
+
+
+
+
+Legg                        Standards Track                     [Page 4]
+
+RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
+
+
+3.1.  General Considerations
+
+   The description of each syntax specifies how attribute or assertion
+   values conforming to the syntax are to be represented when
+   transferred in the LDAP protocol [RFC4511].  This representation is
+   referred to as the LDAP-specific encoding to distinguish it from
+   other methods of encoding attribute values (e.g., the Basic Encoding
+   Rules (BER) encoding [BER] used by X.500 [X.500] directories).
+
+   The LDAP-specific encoding of a given attribute syntax always
+   produces octet-aligned values.  To the greatest extent possible,
+   encoding rules for LDAP syntaxes should produce character strings
+   that can be displayed with little or no translation by clients
+   implementing LDAP.  However, clients MUST NOT assume that the LDAP-
+   specific encoding of a value of an unrecognized syntax is a human-
+   readable character string.  There are a few cases (e.g., the JPEG
+   syntax) when it is not reasonable to produce a human-readable
+   representation.
+
+   Each LDAP syntax is uniquely identified with an object identifier
+   [ASN.1] represented in the dotted-decimal format (short descriptive
+   names are not defined for syntaxes).  These object identifiers are
+   not intended to be displayed to users.  The object identifiers for
+   the syntaxes defined in this document are summarized in Appendix A.
+
+   A suggested minimum upper bound on the number of characters in an
+   attribute value with a string-based syntax, or the number of octets
+   in a value for all other syntaxes, MAY be indicated by appending the
+   bound inside of curly braces following the syntax's OBJECT IDENTIFIER
+   in an attribute type definition (see the <noidlen> rule in
+   [RFC4512]).  Such a bound is not considered part of the syntax
+   identifier.
+
+   For example, "1.3.6.1.4.1.1466.115.121.1.15{64}" in an attribute
+   definition suggests that the directory server will allow a value of
+   the attribute to be up to 64 characters long, although it may allow
+   longer character strings.  Note that a single character of the
+   Directory String syntax can be encoded in more than one octet, since
+   UTF-8 [RFC3629] is a variable-length encoding.  Therefore, a 64-
+   character string may be more than 64 octets in length.
+
+3.2.  Common Definitions
+
+   The following ABNF rules are used in a number of the syntax
+   definitions in Section 3.3.
+
+      PrintableCharacter = ALPHA / DIGIT / SQUOTE / LPAREN / RPAREN /
+                           PLUS / COMMA / HYPHEN / DOT / EQUALS /
+
+
+
+Legg                        Standards Track                     [Page 5]
+
+RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
+
+
+                           SLASH / COLON / QUESTION / SPACE
+      PrintableString    = 1*PrintableCharacter
+      IA5String          = *(%x00-7F)
+      SLASH              = %x2F  ; forward slash ("/")
+      COLON              = %x3A  ; colon (":")
+      QUESTION           = %x3F  ; question mark ("?")
+
+   The <ALPHA>, <DIGIT>, <SQUOTE>, <LPAREN>, <RPAREN>, <PLUS>, <COMMA>,
+   <HYPHEN>, <DOT>, <EQUALS>, and <SPACE> rules are defined in
+   [RFC4512].
+
+3.3.  Syntax Definitions
+
+3.3.1.  Attribute Type Description
+
+   A value of the Attribute Type Description syntax is the definition of
+   an attribute type.  The LDAP-specific encoding of a value of this
+   syntax is defined by the <AttributeTypeDescription> rule in
+   [RFC4512].
+
+      For example, the following definition of the createTimestamp
+      attribute type from [RFC4512] is also a value of the Attribute
+      Type Description syntax.  (Note: Line breaks have been added for
+      readability; they are not part of the value when transferred in
+      protocol.)
+
+         ( 2.5.18.1 NAME 'createTimestamp'
+            EQUALITY generalizedTimeMatch
+            ORDERING generalizedTimeOrderingMatch
+            SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
+            SINGLE-VALUE NO-USER-MODIFICATION
+            USAGE directoryOperation )
+
+   The LDAP definition for the Attribute Type Description syntax is:
+
+      ( 1.3.6.1.4.1.1466.115.121.1.3 DESC 'Attribute Type Description' )
+
+   This syntax corresponds to the AttributeTypeDescription ASN.1 type
+   from [X.501].
+
+3.3.2.  Bit String
+
+   A value of the Bit String syntax is a sequence of binary digits.  The
+   LDAP-specific encoding of a value of this syntax is defined by the
+   following ABNF:
+
+      BitString    = SQUOTE *binary-digit SQUOTE "B"
+      binary-digit = "0" / "1"
+
+
+
+Legg                        Standards Track                     [Page 6]
+
+RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
+
+
+   The <SQUOTE> rule is defined in [RFC4512].
+
+      Example:
+         '0101111101'B
+
+   The LDAP definition for the Bit String syntax is:
+
+      ( 1.3.6.1.4.1.1466.115.121.1.6 DESC 'Bit String' )
+
+   This syntax corresponds to the BIT STRING ASN.1 type from [ASN.1].
+
+3.3.3.  Boolean
+
+   A value of the Boolean syntax is one of the Boolean values, true or
+   false.  The LDAP-specific encoding of a value of this syntax is
+   defined by the following ABNF:
+
+      Boolean = "TRUE" / "FALSE"
+
+   The LDAP definition for the Boolean syntax is:
+
+      ( 1.3.6.1.4.1.1466.115.121.1.7 DESC 'Boolean' )
+
+   This syntax corresponds to the BOOLEAN ASN.1 type from [ASN.1].
+
+3.3.4.  Country String
+
+   A value of the Country String syntax is one of the two-character
+   codes from ISO 3166 [ISO3166] for representing a country.  The LDAP-
+   specific encoding of a value of this syntax is defined by the
+   following ABNF:
+
+      CountryString  = 2(PrintableCharacter)
+
+   The <PrintableCharacter> rule is defined in Section 3.2.
+
+      Examples:
+
+         US
+         AU
+
+   The LDAP definition for the Country String syntax is:
+
+      ( 1.3.6.1.4.1.1466.115.121.1.11 DESC 'Country String' )
+
+   This syntax corresponds to the following ASN.1 type from [X.520]:
+
+      PrintableString (SIZE (2)) -- ISO 3166 codes only
+
+
+
+Legg                        Standards Track                     [Page 7]
+
+RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
+
+
+3.3.5.  Delivery Method
+
+   A value of the Delivery Method syntax is a sequence of items that
+   indicate, in preference order, the service(s) by which an entity is
+   willing and/or capable of receiving messages.  The LDAP-specific
+   encoding of a value of this syntax is defined by the following ABNF:
+
+      DeliveryMethod = pdm *( WSP DOLLAR WSP pdm )
+
+      pdm = "any" / "mhs" / "physical" / "telex" / "teletex" /
+            "g3fax" / "g4fax" / "ia5" / "videotex" / "telephone"
+
+   The <WSP> and <DOLLAR> rules are defined in [RFC4512].
+
+      Example:
+         telephone $ videotex
+
+   The LDAP definition for the Delivery Method syntax is:
+
+      ( 1.3.6.1.4.1.1466.115.121.1.14 DESC 'Delivery Method' )
+
+   This syntax corresponds to the following ASN.1 type from [X.520]:
+
+      SEQUENCE OF INTEGER {
+          any-delivery-method     (0),
+          mhs-delivery            (1),
+          physical-delivery       (2),
+          telex-delivery          (3),
+          teletex-delivery        (4),
+          g3-facsimile-delivery   (5),
+          g4-facsimile-delivery   (6),
+          ia5-terminal-delivery   (7),
+          videotex-delivery       (8),
+          telephone-delivery      (9) }
+
+3.3.6.  Directory String
+
+   A value of the Directory String syntax is a string of one or more
+   arbitrary characters from the Universal Character Set (UCS) [UCS].  A
+   zero-length character string is not permitted.  The LDAP-specific
+   encoding of a value of this syntax is the UTF-8 encoding [RFC3629] of
+   the character string.  Such encodings conform to the following ABNF:
+
+      DirectoryString = 1*UTF8
+
+   The <UTF8> rule is defined in [RFC4512].
+
+
+
+
+
+Legg                        Standards Track                     [Page 8]
+
+RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
+
+
+      Example:
+         This is a value of Directory String containing #!%#@.
+
+   Servers and clients MUST be prepared to receive arbitrary UCS code
+   points, including code points outside the range of printable ASCII
+   and code points not presently assigned to any character.
+
+   Attribute type definitions using the Directory String syntax should
+   not restrict the format of Directory String values, e.g., by
+   requiring that the character string conforms to specific patterns
+   described by ABNF.  A new syntax should be defined in such cases.
+
+   The LDAP definition for the Directory String syntax is:
+
+      ( 1.3.6.1.4.1.1466.115.121.1.15 DESC 'Directory String' )
+
+   This syntax corresponds to the DirectoryString parameterized ASN.1
+   type from [X.520].
+
+   The DirectoryString ASN.1 type allows a choice between the
+   TeletexString, PrintableString, or UniversalString ASN.1 types from
+   [ASN.1].  However, note that the chosen alternative is not indicated
+   in the LDAP-specific encoding of a Directory String value.
+
+   Implementations that convert Directory String values from the LDAP-
+   specific encoding to the BER encoding used by X.500 must choose an
+   alternative that permits the particular characters in the string and
+   must convert the characters from the UTF-8 encoding into the
+   character encoding of the chosen alternative.  When converting
+   Directory String values from the BER encoding to the LDAP-specific
+   encoding, the characters must be converted from the character
+   encoding of the chosen alternative into the UTF-8 encoding.  These
+   conversions SHOULD be done in a manner consistent with the Transcode
+   step of the string preparation algorithms [RFC4518] for LDAP.
+
+3.3.7.  DIT Content Rule Description
+
+   A value of the DIT Content Rule Description syntax is the definition
+   of a DIT (Directory Information Tree) content rule.  The LDAP-
+   specific encoding of a value of this syntax is defined by the
+   <DITContentRuleDescription> rule in [RFC4512].
+
+      Example:
+         ( 2.5.6.4 DESC 'content rule for organization'
+            NOT ( x121Address $ telexNumber ) )
+
+      Note: A line break has been added for readability; it is not part
+      of the value.
+
+
+
+Legg                        Standards Track                     [Page 9]
+
+RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
+
+
+   The LDAP definition for the DIT Content Rule Description syntax is:
+
+      ( 1.3.6.1.4.1.1466.115.121.1.16
+         DESC 'DIT Content Rule Description' )
+
+   This syntax corresponds to the DITContentRuleDescription ASN.1 type
+   from [X.501].
+
+3.3.8.  DIT Structure Rule Description
+
+   A value of the DIT Structure Rule Description syntax is the
+   definition of a DIT structure rule.  The LDAP-specific encoding of a
+   value of this syntax is defined by the <DITStructureRuleDescription>
+   rule in [RFC4512].
+
+      Example:
+         ( 2 DESC 'organization structure rule' FORM 2.5.15.3 )
+
+   The LDAP definition for the DIT Structure Rule Description syntax is:
+
+      ( 1.3.6.1.4.1.1466.115.121.1.17
+         DESC 'DIT Structure Rule Description' )
+
+   This syntax corresponds to the DITStructureRuleDescription ASN.1 type
+   from [X.501].
+
+3.3.9.  DN
+
+   A value of the DN syntax is the (purported) distinguished name (DN)
+   of an entry [RFC4512].  The LDAP-specific encoding of a value of this
+   syntax is defined by the <distinguishedName> rule from the string
+   representation of distinguished names [RFC4514].
+
+      Examples (from [RFC4514]):
+         UID=jsmith,DC=example,DC=net
+         OU=Sales+CN=J. Smith,DC=example,DC=net
+         CN=John Smith\, III,DC=example,DC=net
+         CN=Before\0dAfter,DC=example,DC=net
+         1.3.6.1.4.1.1466.0=#04024869,DC=example,DC=com
+         CN=Lu\C4\8Di\C4\87
+
+   The LDAP definition for the DN syntax is:
+
+      ( 1.3.6.1.4.1.1466.115.121.1.12 DESC 'DN' )
+
+   The DN syntax corresponds to the DistinguishedName ASN.1 type from
+   [X.501].  Note that a BER encoded distinguished name (as used by
+   X.500) re-encoded into the LDAP-specific encoding is not necessarily
+
+
+
+Legg                        Standards Track                    [Page 10]
+
+RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
+
+
+   reversible to the original BER encoding since the chosen string type
+   in any DirectoryString components of the distinguished name is not
+   indicated in the LDAP-specific encoding of the distinguished name
+   (see Section 3.3.6).
+
+3.3.10.  Enhanced Guide
+
+   A value of the Enhanced Guide syntax suggests criteria, which consist
+   of combinations of attribute types and filter operators, to be used
+   in constructing filters to search for entries of particular object
+   classes.  The Enhanced Guide syntax improves upon the Guide syntax by
+   allowing the recommended depth of the search to be specified.
+
+   The LDAP-specific encoding of a value of this syntax is defined by
+   the following ABNF:
+
+      EnhancedGuide = object-class SHARP WSP criteria WSP
+                         SHARP WSP subset
+      object-class  = WSP oid WSP
+      subset        = "baseobject" / "oneLevel" / "wholeSubtree"
+
+      criteria   = and-term *( BAR and-term )
+      and-term   = term *( AMPERSAND term )
+      term       = EXCLAIM term /
+                   attributetype DOLLAR match-type /
+                   LPAREN criteria RPAREN /
+                   true /
+                   false
+      match-type = "EQ" / "SUBSTR" / "GE" / "LE" / "APPROX"
+      true       = "?true"
+      false      = "?false"
+      BAR        = %x7C  ; vertical bar ("|")
+      AMPERSAND  = %x26  ; ampersand ("&")
+      EXCLAIM    = %x21  ; exclamation mark ("!")
+
+   The <SHARP>, <WSP>, <oid>, <LPAREN>, <RPAREN>, <attributetype>, and
+   <DOLLAR> rules are defined in [RFC4512].
+
+   The LDAP definition for the Enhanced Guide syntax is:
+
+      ( 1.3.6.1.4.1.1466.115.121.1.21 DESC 'Enhanced Guide' )
+
+      Example:
+         person#(sn$EQ)#oneLevel
+
+   The Enhanced Guide syntax corresponds to the EnhancedGuide ASN.1 type
+   from [X.520].  The EnhancedGuide type references the Criteria ASN.1
+   type, also from [X.520].  The <true> rule, above, represents an empty
+
+
+
+Legg                        Standards Track                    [Page 11]
+
+RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
+
+
+   "and" expression in a value of the Criteria type.  The <false> rule,
+   above, represents an empty "or" expression in a value of the Criteria
+   type.
+
+3.3.11.  Facsimile Telephone Number
+
+   A value of the Facsimile Telephone Number syntax is a subscriber
+   number of a facsimile device on the public switched telephone
+   network.  The LDAP-specific encoding of a value of this syntax is
+   defined by the following ABNF:
+
+      fax-number       = telephone-number *( DOLLAR fax-parameter )
+      telephone-number = PrintableString
+      fax-parameter    = "twoDimensional" /
+                         "fineResolution" /
+                         "unlimitedLength" /
+                         "b4Length" /
+                         "a3Width" /
+                         "b4Width" /
+                         "uncompressed"
+
+   The <telephone-number> is a string of printable characters that
+   complies with the internationally agreed format for representing
+   international telephone numbers [E.123].  The <PrintableString> rule
+   is defined in Section 3.2.  The <DOLLAR> rule is defined in
+   [RFC4512].
+
+   The LDAP definition for the Facsimile Telephone Number syntax is:
+
+      ( 1.3.6.1.4.1.1466.115.121.1.22 DESC 'Facsimile Telephone Number')
+
+   The Facsimile Telephone Number syntax corresponds to the
+   FacsimileTelephoneNumber ASN.1 type from [X.520].
+
+3.3.12.  Fax
+
+   A value of the Fax syntax is an image that is produced using the
+   Group 3 facsimile process [FAX] to duplicate an object, such as a
+   memo.  The LDAP-specific encoding of a value of this syntax is the
+   string of octets for a Group 3 Fax image as defined in [FAX].
+
+   The LDAP definition for the Fax syntax is:
+
+      ( 1.3.6.1.4.1.1466.115.121.1.23 DESC 'Fax' )
+
+   The ASN.1 type corresponding to the Fax syntax is defined as follows,
+   assuming EXPLICIT TAGS:
+
+
+
+
+Legg                        Standards Track                    [Page 12]
+
+RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
+
+
+      Fax ::= CHOICE {
+        g3-facsimile  [3] G3FacsimileBodyPart
+      }
+
+   The G3FacsimileBodyPart ASN.1 type is defined in [X.420].
+
+3.3.13.  Generalized Time
+
+   A value of the Generalized Time syntax is a character string
+   representing a date and time.  The LDAP-specific encoding of a value
+   of this syntax is a restriction of the format defined in [ISO8601],
+   and is described by the following ABNF:
+
+      GeneralizedTime = century year month day hour
+                           [ minute [ second / leap-second ] ]
+                           [ fraction ]
+                           g-time-zone
+
+      century = 2(%x30-39) ; "00" to "99"
+      year    = 2(%x30-39) ; "00" to "99"
+      month   =   ( %x30 %x31-39 ) ; "01" (January) to "09"
+                / ( %x31 %x30-32 ) ; "10" to "12"
+      day     =   ( %x30 %x31-39 )    ; "01" to "09"
+                / ( %x31-32 %x30-39 ) ; "10" to "29"
+                / ( %x33 %x30-31 )    ; "30" to "31"
+      hour    = ( %x30-31 %x30-39 ) / ( %x32 %x30-33 ) ; "00" to "23"
+      minute  = %x30-35 %x30-39                        ; "00" to "59"
+
+      second      = ( %x30-35 %x30-39 ) ; "00" to "59"
+      leap-second = ( %x36 %x30 )       ; "60"
+
+      fraction        = ( DOT / COMMA ) 1*(%x30-39)
+      g-time-zone     = %x5A  ; "Z"
+                        / g-differential
+      g-differential  = ( MINUS / PLUS ) hour [ minute ]
+      MINUS           = %x2D  ; minus sign ("-")
+
+   The <DOT>, <COMMA>, and <PLUS> rules are defined in [RFC4512].
+
+   The above ABNF allows character strings that do not represent valid
+   dates (in the Gregorian calendar) and/or valid times (e.g., February
+   31, 1994).  Such character strings SHOULD be considered invalid for
+   this syntax.
+
+   The time value represents coordinated universal time (equivalent to
+   Greenwich Mean Time) if the "Z" form of <g-time-zone> is used;
+   otherwise, the value represents a local time in the time zone
+   indicated by <g-differential>.  In the latter case, coordinated
+
+
+
+Legg                        Standards Track                    [Page 13]
+
+RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
+
+
+   universal time can be calculated by subtracting the differential from
+   the local time.  The "Z" form of <g-time-zone> SHOULD be used in
+   preference to <g-differential>.
+
+   If <minute> is omitted, then <fraction> represents a fraction of an
+   hour; otherwise, if <second> and <leap-second> are omitted, then
+   <fraction> represents a fraction of a minute; otherwise, <fraction>
+   represents a fraction of a second.
+
+      Examples:
+         199412161032Z
+         199412160532-0500
+
+   Both example values represent the same coordinated universal time:
+   10:32 AM, December 16, 1994.
+
+   The LDAP definition for the Generalized Time syntax is:
+
+      ( 1.3.6.1.4.1.1466.115.121.1.24 DESC 'Generalized Time' )
+
+   This syntax corresponds to the GeneralizedTime ASN.1 type from
+   [ASN.1], with the constraint that local time without a differential
+   SHALL NOT be used.
+
+3.3.14.  Guide
+
+   A value of the Guide syntax suggests criteria, which consist of
+   combinations of attribute types and filter operators, to be used in
+   constructing filters to search for entries of particular object
+   classes.  The Guide syntax is obsolete and should not be used for
+   defining new attribute types.
+
+   The LDAP-specific encoding of a value of this syntax is defined by
+   the following ABNF:
+
+      Guide = [ object-class SHARP ] criteria
+
+   The <object-class> and <criteria> rules are defined in Section
+   3.3.10.  The <SHARP> rule is defined in [RFC4512].
+
+   The LDAP definition for the Guide syntax is:
+
+      ( 1.3.6.1.4.1.1466.115.121.1.25 DESC 'Guide' )
+
+   The Guide syntax corresponds to the Guide ASN.1 type from [X.520].
+
+
+
+
+
+
+Legg                        Standards Track                    [Page 14]
+
+RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
+
+
+3.3.15.  IA5 String
+
+   A value of the IA5 String syntax is a string of zero, one, or more
+   characters from International Alphabet 5 (IA5) [T.50], the
+   international version of the ASCII character set.  The LDAP-specific
+   encoding of a value of this syntax is the unconverted string of
+   characters, which conforms to the <IA5String> rule in Section 3.2.
+
+   The LDAP definition for the IA5 String syntax is:
+
+      ( 1.3.6.1.4.1.1466.115.121.1.26 DESC 'IA5 String' )
+
+   This syntax corresponds to the IA5String ASN.1 type from [ASN.1].
+
+3.3.16.  Integer
+
+   A value of the Integer syntax is a whole number of unlimited
+   magnitude.  The LDAP-specific encoding of a value of this syntax is
+   the optionally signed decimal digit character string representation
+   of the number (for example, the number 1321 is represented by the
+   character string "1321").  The encoding is defined by the following
+   ABNF:
+
+      Integer = ( HYPHEN LDIGIT *DIGIT ) / number
+
+   The <HYPHEN>, <LDIGIT>, <DIGIT>, and <number> rules are defined in
+   [RFC4512].
+
+   The LDAP definition for the Integer syntax is:
+
+      ( 1.3.6.1.4.1.1466.115.121.1.27 DESC 'INTEGER' )
+
+   This syntax corresponds to the INTEGER ASN.1 type from [ASN.1].
+
+3.3.17.  JPEG
+
+   A value of the JPEG syntax is an image in the JPEG File Interchange
+   Format (JFIF), as described in [JPEG].  The LDAP-specific encoding of
+   a value of this syntax is the sequence of octets of the JFIF encoding
+   of the image.
+
+   The LDAP definition for the JPEG syntax is:
+
+      ( 1.3.6.1.4.1.1466.115.121.1.28 DESC 'JPEG' )
+
+   The JPEG syntax corresponds to the following ASN.1 type:
+
+
+
+
+
+Legg                        Standards Track                    [Page 15]
+
+RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
+
+
+      JPEG ::= OCTET STRING (CONSTRAINED BY
+                   { -- contents octets are an image in the --
+                     -- JPEG File Interchange Format -- })
+
+3.3.18.  LDAP Syntax Description
+
+   A value of the LDAP Syntax Description syntax is the description of
+   an LDAP syntax.  The LDAP-specific encoding of a value of this syntax
+   is defined by the <SyntaxDescription> rule in [RFC4512].
+
+   The LDAP definition for the LDAP Syntax Description syntax is:
+
+      ( 1.3.6.1.4.1.1466.115.121.1.54 DESC 'LDAP Syntax Description' )
+
+   The above LDAP definition for the LDAP Syntax Description syntax is
+   itself a legal value of the LDAP Syntax Description syntax.
+
+   The ASN.1 type corresponding to the LDAP Syntax Description syntax is
+   defined as follows, assuming EXPLICIT TAGS:
+
+      LDAPSyntaxDescription ::= SEQUENCE {
+          identifier      OBJECT IDENTIFIER,
+          description     DirectoryString { ub-schema } OPTIONAL }
+
+   The DirectoryString parameterized ASN.1 type is defined in [X.520].
+
+   The value of ub-schema (an integer) is implementation defined.  A
+   non-normative definition appears in [X.520].
+
+3.3.19.  Matching Rule Description
+
+   A value of the Matching Rule Description syntax is the definition of
+   a matching rule.  The LDAP-specific encoding of a value of this
+   syntax is defined by the <MatchingRuleDescription> rule in [RFC4512].
+
+      Example:
+         ( 2.5.13.2 NAME 'caseIgnoreMatch'
+            SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+   Note: A line break has been added for readability; it is not part of
+   the syntax.
+
+   The LDAP definition for the Matching Rule Description syntax is:
+
+      ( 1.3.6.1.4.1.1466.115.121.1.30 DESC 'Matching Rule Description' )
+
+   This syntax corresponds to the MatchingRuleDescription ASN.1 type
+   from [X.501].
+
+
+
+Legg                        Standards Track                    [Page 16]
+
+RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
+
+
+3.3.20.  Matching Rule Use Description
+
+   A value of the Matching Rule Use Description syntax indicates the
+   attribute types to which a matching rule may be applied in an
+   extensibleMatch search filter [RFC4511].  The LDAP-specific encoding
+   of a value of this syntax is defined by the
+   <MatchingRuleUseDescription> rule in [RFC4512].
+
+      Example:
+         ( 2.5.13.16 APPLIES ( givenName $ surname ) )
+
+   The LDAP definition for the Matching Rule Use Description syntax is:
+
+      ( 1.3.6.1.4.1.1466.115.121.1.31
+         DESC 'Matching Rule Use Description' )
+
+   This syntax corresponds to the MatchingRuleUseDescription ASN.1 type
+   from [X.501].
+
+3.3.21.  Name and Optional UID
+
+   A value of the Name and Optional UID syntax is the distinguished name
+   [RFC4512] of an entity optionally accompanied by a unique identifier
+   that serves to differentiate the entity from others with an identical
+   distinguished name.
+
+   The LDAP-specific encoding of a value of this syntax is defined by
+   the following ABNF:
+
+      NameAndOptionalUID = distinguishedName [ SHARP BitString ]
+
+   The <BitString> rule is defined in Section 3.3.2.  The
+   <distinguishedName> rule is defined in [RFC4514].  The <SHARP> rule
+   is defined in [RFC4512].
+
+   Note that although the '#' character may occur in the string
+   representation of a distinguished name, no additional escaping of
+   this character is performed when a <distinguishedName> is encoded in
+   a <NameAndOptionalUID>.
+
+      Example:
+         1.3.6.1.4.1.1466.0=#04024869,O=Test,C=GB#'0101'B
+
+   The LDAP definition for the Name and Optional UID syntax is:
+
+      ( 1.3.6.1.4.1.1466.115.121.1.34 DESC 'Name And Optional UID' )
+
+
+
+
+
+Legg                        Standards Track                    [Page 17]
+
+RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
+
+
+   This syntax corresponds to the NameAndOptionalUID ASN.1 type from
+   [X.520].
+
+3.3.22.  Name Form Description
+
+   A value of the Name Form Description syntax is the definition of a
+   name form, which regulates how entries may be named.  The LDAP-
+   specific encoding of a value of this syntax is defined by the
+   <NameFormDescription> rule in [RFC4512].
+
+      Example:
+         ( 2.5.15.3 NAME 'orgNameForm' OC organization MUST o )
+
+   The LDAP definition for the Name Form Description syntax is:
+
+      ( 1.3.6.1.4.1.1466.115.121.1.35 DESC 'Name Form Description' )
+
+   This syntax corresponds to the NameFormDescription ASN.1 type from
+   [X.501].
+
+3.3.23.  Numeric String
+
+   A value of the Numeric String syntax is a sequence of one or more
+   numerals and spaces.  The LDAP-specific encoding of a value of this
+   syntax is the unconverted string of characters, which conforms to the
+   following ABNF:
+
+      NumericString = 1*(DIGIT / SPACE)
+
+   The <DIGIT> and <SPACE> rules are defined in [RFC4512].
+
+      Example:
+         15 079 672 281
+
+   The LDAP definition for the Numeric String syntax is:
+
+      ( 1.3.6.1.4.1.1466.115.121.1.36 DESC 'Numeric String' )
+
+   This syntax corresponds to the NumericString ASN.1 type from [ASN.1].
+
+3.3.24.  Object Class Description
+
+   A value of the Object Class Description syntax is the definition of
+   an object class.  The LDAP-specific encoding of a value of this
+   syntax is defined by the <ObjectClassDescription> rule in [RFC4512].
+
+
+
+
+
+
+Legg                        Standards Track                    [Page 18]
+
+RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
+
+
+      Example:
+         ( 2.5.6.2 NAME 'country' SUP top STRUCTURAL MUST c
+            MAY ( searchGuide $ description ) )
+
+   Note: A line break has been added for readability; it is not part of
+   the syntax.
+
+   The LDAP definition for the Object Class Description syntax is:
+
+      ( 1.3.6.1.4.1.1466.115.121.1.37 DESC 'Object Class Description' )
+
+   This syntax corresponds to the ObjectClassDescription ASN.1 type from
+   [X.501].
+
+3.3.25.  Octet String
+
+   A value of the Octet String syntax is a sequence of zero, one, or
+   more arbitrary octets.  The LDAP-specific encoding of a value of this
+   syntax is the unconverted sequence of octets, which conforms to the
+   following ABNF:
+
+      OctetString = *OCTET
+
+   The <OCTET> rule is defined in [RFC4512].  Values of this syntax are
+   not generally human-readable.
+
+   The LDAP definition for the Octet String syntax is:
+
+      ( 1.3.6.1.4.1.1466.115.121.1.40 DESC 'Octet String' )
+
+   This syntax corresponds to the OCTET STRING ASN.1 type from [ASN.1].
+
+3.3.26.  OID
+
+   A value of the OID syntax is an object identifier: a sequence of two
+   or more non-negative integers that uniquely identify some object or
+   item of specification.  Many of the object identifiers used in LDAP
+   also have IANA registered names [RFC4520].
+
+   The LDAP-specific encoding of a value of this syntax is defined by
+   the <oid> rule in [RFC4512].
+
+      Examples:
+         1.2.3.4
+         cn
+
+   The LDAP definition for the OID syntax is:
+
+
+
+
+Legg                        Standards Track                    [Page 19]
+
+RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
+
+
+      ( 1.3.6.1.4.1.1466.115.121.1.38 DESC 'OID' )
+
+   This syntax corresponds to the OBJECT IDENTIFIER ASN.1 type from
+   [ASN.1].
+
+3.3.27.  Other Mailbox
+
+   A value of the Other Mailbox syntax identifies an electronic mailbox,
+   in a particular named mail system.  The LDAP-specific encoding of a
+   value of this syntax is defined by the following ABNF:
+
+      OtherMailbox = mailbox-type DOLLAR mailbox
+      mailbox-type = PrintableString
+      mailbox      = IA5String
+
+   The <mailbox-type> rule represents the type of mail system in which
+   the mailbox resides (for example, "MCIMail"), and <mailbox> is the
+   actual mailbox in the mail system described by <mailbox-type>.  The
+   <PrintableString> and <IA5String> rules are defined in Section 3.2.
+   The <DOLLAR> rule is defined in [RFC4512].
+
+   The LDAP definition for the Other Mailbox syntax is:
+
+      ( 1.3.6.1.4.1.1466.115.121.1.39 DESC 'Other Mailbox' )
+
+   The ASN.1 type corresponding to the Other Mailbox syntax is defined
+   as follows, assuming EXPLICIT TAGS:
+
+      OtherMailbox ::= SEQUENCE {
+          mailboxType  PrintableString,
+          mailbox      IA5String
+      }
+
+3.3.28.  Postal Address
+
+   A value of the Postal Address syntax is a sequence of strings of one
+   or more arbitrary UCS characters, which form an address in a physical
+   mail system.
+
+   The LDAP-specific encoding of a value of this syntax is defined by
+   the following ABNF:
+
+
+
+
+
+
+
+
+
+
+Legg                        Standards Track                    [Page 20]
+
+RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
+
+
+      PostalAddress = line *( DOLLAR line )
+      line          = 1*line-char
+      line-char     = %x00-23
+                      / (%x5C "24")  ; escaped "$"
+                      / %x25-5B
+                      / (%x5C "5C")  ; escaped "\"
+                      / %x5D-7F
+                      / UTFMB
+
+   Each character string (i.e., <line>) of a postal address value is
+   encoded as a UTF-8 [RFC3629] string, except that "\" and "$"
+   characters, if they occur in the string, are escaped by a "\"
+   character followed by the two hexadecimal digit code for the
+   character.  The <DOLLAR> and <UTFMB> rules are defined in [RFC4512].
+
+   Many servers limit the postal address to no more than six lines of no
+   more than thirty characters each.
+
+      Example:
+         1234 Main St.$Anytown, CA 12345$USA
+         \241,000,000 Sweepstakes$PO Box 1000000$Anytown, CA 12345$USA
+
+   The LDAP definition for the Postal Address syntax is:
+
+      ( 1.3.6.1.4.1.1466.115.121.1.41 DESC 'Postal Address' )
+
+   This syntax corresponds to the PostalAddress ASN.1 type from [X.520];
+   that is
+
+      PostalAddress ::= SEQUENCE SIZE(1..ub-postal-line) OF
+          DirectoryString { ub-postal-string }
+
+   The values of ub-postal-line and ub-postal-string (both integers) are
+   implementation defined.  Non-normative definitions appear in [X.520].
+
+3.3.29.  Printable String
+
+   A value of the Printable String syntax is a string of one or more
+   latin alphabetic, numeric, and selected punctuation characters as
+   specified by the <PrintableCharacter> rule in Section 3.2.
+
+   The LDAP-specific encoding of a value of this syntax is the
+   unconverted string of characters, which conforms to the
+   <PrintableString> rule in Section 3.2.
+
+      Example:
+         This is a PrintableString.
+
+
+
+
+Legg                        Standards Track                    [Page 21]
+
+RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
+
+
+   The LDAP definition for the PrintableString syntax is:
+
+      ( 1.3.6.1.4.1.1466.115.121.1.44 DESC 'Printable String' )
+
+   This syntax corresponds to the PrintableString ASN.1 type from
+   [ASN.1].
+
+3.3.30.  Substring Assertion
+
+   A value of the Substring Assertion syntax is a sequence of zero, one,
+   or more character substrings used as an argument for substring
+   extensible matching of character string attribute values; i.e., as
+   the matchValue of a MatchingRuleAssertion [RFC4511].  Each substring
+   is a string of one or more arbitrary characters from the Universal
+   Character Set (UCS) [UCS].  A zero-length substring is not permitted.
+
+   The LDAP-specific encoding of a value of this syntax is defined by
+   the following ABNF:
+
+      SubstringAssertion = [ initial ] any [ final ]
+
+      initial  = substring
+      any      = ASTERISK *(substring ASTERISK)
+      final    = substring
+      ASTERISK = %x2A  ; asterisk ("*")
+
+      substring           = 1*substring-character
+      substring-character = %x00-29
+                            / (%x5C "2A")  ; escaped "*"
+                            / %x2B-5B
+                            / (%x5C "5C")  ; escaped "\"
+                            / %x5D-7F
+                            / UTFMB
+
+   Each <substring> of a Substring Assertion value is encoded as a UTF-8
+   [RFC3629] string, except that "\" and "*" characters, if they occur
+   in the substring, are escaped by a "\" character followed by the two
+   hexadecimal digit code for the character.
+
+   The Substring Assertion syntax is used only as the syntax of
+   assertion values in the extensible match.  It is not used as an
+   attribute syntax, or in the SubstringFilter [RFC4511].
+
+   The LDAP definition for the Substring Assertion syntax is:
+
+      ( 1.3.6.1.4.1.1466.115.121.1.58 DESC 'Substring Assertion' )
+
+
+
+
+
+Legg                        Standards Track                    [Page 22]
+
+RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
+
+
+   This syntax corresponds to the SubstringAssertion ASN.1 type from
+   [X.520].
+
+3.3.31.  Telephone Number
+
+   A value of the Telephone Number syntax is a string of printable
+   characters that complies with the internationally agreed format for
+   representing international telephone numbers [E.123].
+
+   The LDAP-specific encoding of a value of this syntax is the
+   unconverted string of characters, which conforms to the
+   <PrintableString> rule in Section 3.2.
+
+      Examples:
+         +1 512 315 0280
+         +1-512-315-0280
+         +61 3 9896 7830
+
+   The LDAP definition for the Telephone Number syntax is:
+
+      ( 1.3.6.1.4.1.1466.115.121.1.50 DESC 'Telephone Number' )
+
+   The Telephone Number syntax corresponds to the following ASN.1 type
+   from [X.520]:
+
+      PrintableString (SIZE(1..ub-telephone-number))
+
+   The value of ub-telephone-number (an integer) is implementation
+   defined.  A non-normative definition appears in [X.520].
+
+3.3.32.  Teletex Terminal Identifier
+
+   A value of this syntax specifies the identifier and (optionally)
+   parameters of a teletex terminal.
+
+   The LDAP-specific encoding of a value of this syntax is defined by
+   the following ABNF:
+
+      teletex-id = ttx-term *(DOLLAR ttx-param)
+      ttx-term   = PrintableString          ; terminal identifier
+      ttx-param  = ttx-key COLON ttx-value  ; parameter
+      ttx-key    = "graphic" / "control" / "misc" / "page" / "private"
+      ttx-value  = *ttx-value-octet
+
+      ttx-value-octet = %x00-23
+                        / (%x5C "24")  ; escaped "$"
+                        / %x25-5B
+                        / (%x5C "5C")  ; escaped "\"
+
+
+
+Legg                        Standards Track                    [Page 23]
+
+RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
+
+
+                        / %x5D-FF
+
+   The <PrintableString> and <COLON> rules are defined in Section 3.2.
+   The <DOLLAR> rule is defined in [RFC4512].
+
+   The LDAP definition for the Teletex Terminal Identifier syntax is:
+
+      ( 1.3.6.1.4.1.1466.115.121.1.51
+         DESC 'Teletex Terminal Identifier' )
+
+   This syntax corresponds to the TeletexTerminalIdentifier ASN.1 type
+   from [X.520].
+
+3.3.33.  Telex Number
+
+   A value of the Telex Number syntax specifies the telex number,
+   country code, and answerback code of a telex terminal.
+
+   The LDAP-specific encoding of a value of this syntax is defined by
+   the following ABNF:
+
+      telex-number  = actual-number DOLLAR country-code
+                         DOLLAR answerback
+      actual-number = PrintableString
+      country-code  = PrintableString
+      answerback    = PrintableString
+
+   The <PrintableString> rule is defined in Section 3.2.  The <DOLLAR>
+   rule is defined in [RFC4512].
+
+   The LDAP definition for the Telex Number syntax is:
+
+      ( 1.3.6.1.4.1.1466.115.121.1.52 DESC 'Telex Number' )
+
+   This syntax corresponds to the TelexNumber ASN.1 type from [X.520].
+
+3.3.34.  UTC Time
+
+   A value of the UTC Time syntax is a character string representing a
+   date and time to a precision of one minute or one second.  The year
+   is given as a two-digit number.  The LDAP-specific encoding of a
+   value of this syntax follows the format defined in [ASN.1] for the
+   UTCTime type and is described by the following ABNF:
+
+      UTCTime         = year month day hour minute [ second ]
+                           [ u-time-zone ]
+      u-time-zone     = %x5A  ; "Z"
+                        / u-differential
+
+
+
+Legg                        Standards Track                    [Page 24]
+
+RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
+
+
+      u-differential  = ( MINUS / PLUS ) hour minute
+
+   The <year>, <month>, <day>, <hour>, <minute>, <second>, and <MINUS>
+   rules are defined in Section 3.3.13.  The <PLUS> rule is defined in
+   [RFC4512].
+
+   The above ABNF allows character strings that do not represent valid
+   dates (in the Gregorian calendar) and/or valid times.  Such character
+   strings SHOULD be considered invalid for this syntax.
+
+   The time value represents coordinated universal time if the "Z" form
+   of <u-time-zone> is used; otherwise, the value represents a local
+   time.  In the latter case, if <u-differential> is provided, then
+   coordinated universal time can be calculated by subtracting the
+   differential from the local time.  The <u-time-zone> SHOULD be
+   present in time values, and the "Z" form of <u-time-zone> SHOULD be
+   used in preference to <u-differential>.
+
+   The LDAP definition for the UTC Time syntax is:
+
+      ( 1.3.6.1.4.1.1466.115.121.1.53 DESC 'UTC Time' )
+
+   Note: This syntax is deprecated in favor of the Generalized Time
+   syntax.
+
+   The UTC Time syntax corresponds to the UTCTime ASN.1 type from
+   [ASN.1].
+
+4.  Matching Rules
+
+   Matching rules are used by directory implementations to compare
+   attribute values against assertion values when performing Search and
+   Compare operations [RFC4511].  They are also used when comparing a
+   purported distinguished name [RFC4512] with the name of an entry.
+   When modifying entries, matching rules are used to identify values to
+   be deleted and to prevent an attribute from containing two equal
+   values.
+
+   Matching rules that are required for directory operation, or that are
+   in common use, are specified in this section.
+
+4.1.  General Considerations
+
+   A matching rule is applied to attribute values through an
+   AttributeValueAssertion or MatchingRuleAssertion [RFC4511].  The
+   conditions under which an AttributeValueAssertion or
+   MatchingRuleAssertion evaluates to Undefined are specified elsewhere
+   [RFC4511].  If an assertion is not Undefined, then the result of the
+
+
+
+Legg                        Standards Track                    [Page 25]
+
+RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
+
+
+   assertion is the result of applying the selected matching rule.  A
+   matching rule evaluates to TRUE, and in some cases Undefined, as
+   specified in the description of the matching rule; otherwise, it
+   evaluates to FALSE.
+
+   Each assertion contains an assertion value.  The definition of each
+   matching rule specifies the syntax for the assertion value.  The
+   syntax of the assertion value is typically, but not necessarily, the
+   same as the syntax of the attribute values to which the matching rule
+   may be applied.  Note that an AssertionValue in a SubstringFilter
+   [RFC4511] conforms to the assertion syntax of the equality matching
+   rule for the attribute type rather than to the assertion syntax of
+   the substrings matching rule for the attribute type.  Conceptually,
+   the entire SubstringFilter is converted into an assertion value of
+   the substrings matching rule prior to applying the rule.
+
+   The definition of each matching rule indicates the attribute syntaxes
+   to which the rule may be applied, by specifying conditions the
+   corresponding ASN.1 type of a candidate attribute syntax must
+   satisfy.  These conditions are also satisfied if the corresponding
+   ASN.1 type is a tagged or constrained derivative of the ASN.1 type
+   explicitly mentioned in the rule description (i.e., ASN.1 tags and
+   constraints are ignored in checking applicability), or is an
+   alternative reference notation for the explicitly mentioned type.
+   Each rule description lists, as examples of applicable attribute
+   syntaxes, the complete list of the syntaxes defined in this document
+   to which the matching rule applies.  A matching rule may be
+   applicable to additional syntaxes defined in other documents if those
+   syntaxes satisfy the conditions on the corresponding ASN.1 type.
+
+   The description of each matching rule indicates whether the rule is
+   suitable for use as the equality matching rule (EQUALITY), ordering
+   matching rule (ORDERING), or substrings matching rule (SUBSTR) in an
+   attribute type definition [RFC4512].
+
+   Each matching rule is uniquely identified with an object identifier.
+   The definition of a matching rule should not subsequently be changed.
+   If a change is desirable, then a new matching rule with a different
+   object identifier should be defined instead.
+
+   Servers MAY implement the wordMatch and keywordMatch matching rules,
+   but they SHOULD implement the other matching rules in Section 4.2.
+   Servers MAY implement additional matching rules.
+
+   Servers that implement the extensibleMatch filter SHOULD allow the
+   matching rules listed in Section 4.2 to be used in the
+   extensibleMatch filter and SHOULD allow matching rules to be used
+   with all attribute types known to the server, where the assertion
+
+
+
+Legg                        Standards Track                    [Page 26]
+
+RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
+
+
+   syntax of the matching rule is the same as the value syntax of the
+   attribute.
+
+   Servers MUST publish, in the matchingRules attribute, the definitions
+   of matching rules referenced by values of the attributeTypes and
+   matchingRuleUse attributes in the same subschema entry.  Other
+   unreferenced matching rules MAY be published in the matchingRules
+   attribute.
+
+   If the server supports the extensibleMatch filter, then the server
+   MAY use the matchingRuleUse attribute to indicate the applicability
+   (in an extensibleMatch filter) of selected matching rules to
+   nominated attribute types.
+
+4.2.  Matching Rule Definitions
+
+   Nominated character strings in assertion and attribute values are
+   prepared according to the string preparation algorithms [RFC4518] for
+   LDAP when evaluating the following matching rules:
+
+      numericStringMatch,
+      numericStringSubstringsMatch,
+      caseExactMatch,
+      caseExactOrderingMatch,
+      caseExactSubstringsMatch,
+      caseExactIA5Match,
+      caseIgnoreIA5Match,
+      caseIgnoreIA5SubstringsMatch,
+      caseIgnoreListMatch,
+      caseIgnoreListSubstringsMatch,
+      caseIgnoreMatch,
+      caseIgnoreOrderingMatch,
+      caseIgnoreSubstringsMatch,
+      directoryStringFirstComponentMatch,
+      telephoneNumberMatch,
+      telephoneNumberSubstringsMatch and
+      wordMatch.
+
+   The Transcode, Normalize, Prohibit, and Check bidi steps are the same
+   for each of the matching rules.  However, the Map and Insignificant
+   Character Handling steps depend on the specific rule, as detailed in
+   the description of these matching rules in the sections that follow.
+
+4.2.1.  bitStringMatch
+
+   The bitStringMatch rule compares an assertion value of the Bit String
+   syntax to an attribute value of a syntax (e.g., the Bit String
+   syntax) whose corresponding ASN.1 type is BIT STRING.
+
+
+
+Legg                        Standards Track                    [Page 27]
+
+RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
+
+
+   If the corresponding ASN.1 type of the attribute syntax does not have
+   a named bit list [ASN.1] (which is the case for the Bit String
+   syntax), then the rule evaluates to TRUE if and only if the attribute
+   value has the same number of bits as the assertion value and the bits
+   match on a bitwise basis.
+
+   If the corresponding ASN.1 type does have a named bit list, then
+   bitStringMatch operates as above, except that trailing zero bits in
+   the attribute and assertion values are treated as absent.
+
+   The LDAP definition for the bitStringMatch rule is:
+
+      ( 2.5.13.16 NAME 'bitStringMatch'
+         SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 )
+
+   The bitStringMatch rule is an equality matching rule.
+
+4.2.2.  booleanMatch
+
+   The booleanMatch rule compares an assertion value of the Boolean
+   syntax to an attribute value of a syntax (e.g., the Boolean syntax)
+   whose corresponding ASN.1 type is BOOLEAN.
+
+   The rule evaluates to TRUE if and only if the attribute value and the
+   assertion value are both TRUE or both FALSE.
+
+   The LDAP definition for the booleanMatch rule is:
+
+      ( 2.5.13.13 NAME 'booleanMatch'
+         SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 )
+
+   The booleanMatch rule is an equality matching rule.
+
+4.2.3.  caseExactIA5Match
+
+   The caseExactIA5Match rule compares an assertion value of the IA5
+   String syntax to an attribute value of a syntax (e.g., the IA5 String
+   syntax) whose corresponding ASN.1 type is IA5String.
+
+   The rule evaluates to TRUE if and only if the prepared attribute
+   value character string and the prepared assertion value character
+   string have the same number of characters and corresponding
+   characters have the same code point.
+
+   In preparing the attribute value and assertion value for comparison,
+   characters are not case folded in the Map preparation step, and only
+   Insignificant Space Handling is applied in the Insignificant
+   Character Handling step.
+
+
+
+Legg                        Standards Track                    [Page 28]
+
+RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
+
+
+   The LDAP definition for the caseExactIA5Match rule is:
+
+      ( 1.3.6.1.4.1.1466.109.114.1 NAME 'caseExactIA5Match'
+         SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
+
+   The caseExactIA5Match rule is an equality matching rule.
+
+4.2.4.  caseExactMatch
+
+   The caseExactMatch rule compares an assertion value of the Directory
+   String syntax to an attribute value of a syntax (e.g., the Directory
+   String, Printable String, Country String, or Telephone Number syntax)
+   whose corresponding ASN.1 type is DirectoryString or one of the
+   alternative string types of DirectoryString, such as PrintableString
+   (the other alternatives do not correspond to any syntax defined in
+   this document).
+
+   The rule evaluates to TRUE if and only if the prepared attribute
+   value character string and the prepared assertion value character
+   string have the same number of characters and corresponding
+   characters have the same code point.
+
+   In preparing the attribute value and assertion value for comparison,
+   characters are not case folded in the Map preparation step, and only
+   Insignificant Space Handling is applied in the Insignificant
+   Character Handling step.
+
+   The LDAP definition for the caseExactMatch rule is:
+
+      ( 2.5.13.5 NAME 'caseExactMatch'
+         SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+   The caseExactMatch rule is an equality matching rule.
+
+4.2.5.  caseExactOrderingMatch
+
+   The caseExactOrderingMatch rule compares an assertion value of the
+   Directory String syntax to an attribute value of a syntax (e.g., the
+   Directory String, Printable String, Country String, or Telephone
+   Number syntax) whose corresponding ASN.1 type is DirectoryString or
+   one of its alternative string types.
+
+   The rule evaluates to TRUE if and only if, in the code point
+   collation order, the prepared attribute value character string
+   appears earlier than the prepared assertion value character string;
+   i.e., the attribute value is "less than" the assertion value.
+
+
+
+
+
+Legg                        Standards Track                    [Page 29]
+
+RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
+
+
+   In preparing the attribute value and assertion value for comparison,
+   characters are not case folded in the Map preparation step, and only
+   Insignificant Space Handling is applied in the Insignificant
+   Character Handling step.
+
+   The LDAP definition for the caseExactOrderingMatch rule is:
+
+      ( 2.5.13.6 NAME 'caseExactOrderingMatch'
+         SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+   The caseExactOrderingMatch rule is an ordering matching rule.
+
+4.2.6.  caseExactSubstringsMatch
+
+   The caseExactSubstringsMatch rule compares an assertion value of the
+   Substring Assertion syntax to an attribute value of a syntax (e.g.,
+   the Directory String, Printable String, Country String, or Telephone
+   Number syntax) whose corresponding ASN.1 type is DirectoryString or
+   one of its alternative string types.
+
+   The rule evaluates to TRUE if and only if (1) the prepared substrings
+   of the assertion value match disjoint portions of the prepared
+   attribute value character string in the order of the substrings in
+   the assertion value, (2) an <initial> substring, if present, matches
+   the beginning of the prepared attribute value character string, and
+   (3) a <final> substring, if present, matches the end of the prepared
+   attribute value character string.  A prepared substring matches a
+   portion of the prepared attribute value character string if
+   corresponding characters have the same code point.
+
+   In preparing the attribute value and assertion value substrings for
+   comparison, characters are not case folded in the Map preparation
+   step, and only Insignificant Space Handling is applied in the
+   Insignificant Character Handling step.
+
+   The LDAP definition for the caseExactSubstringsMatch rule is:
+
+      ( 2.5.13.7 NAME 'caseExactSubstringsMatch'
+         SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
+
+   The caseExactSubstringsMatch rule is a substrings matching rule.
+
+4.2.7.  caseIgnoreIA5Match
+
+   The caseIgnoreIA5Match rule compares an assertion value of the IA5
+   String syntax to an attribute value of a syntax (e.g., the IA5 String
+   syntax) whose corresponding ASN.1 type is IA5String.
+
+
+
+
+Legg                        Standards Track                    [Page 30]
+
+RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
+
+
+   The rule evaluates to TRUE if and only if the prepared attribute
+   value character string and the prepared assertion value character
+   string have the same number of characters and corresponding
+   characters have the same code point.
+
+   In preparing the attribute value and assertion value for comparison,
+   characters are case folded in the Map preparation step, and only
+   Insignificant Space Handling is applied in the Insignificant
+   Character Handling step.
+
+   The LDAP definition for the caseIgnoreIA5Match rule is:
+
+      ( 1.3.6.1.4.1.1466.109.114.2 NAME 'caseIgnoreIA5Match'
+         SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
+
+   The caseIgnoreIA5Match rule is an equality matching rule.
+
+4.2.8.  caseIgnoreIA5SubstringsMatch
+
+   The caseIgnoreIA5SubstringsMatch rule compares an assertion value of
+   the Substring Assertion syntax to an attribute value of a syntax
+   (e.g., the IA5 String syntax) whose corresponding ASN.1 type is
+   IA5String.
+
+   The rule evaluates to TRUE if and only if (1) the prepared substrings
+   of the assertion value match disjoint portions of the prepared
+   attribute value character string in the order of the substrings in
+   the assertion value, (2) an <initial> substring, if present, matches
+   the beginning of the prepared attribute value character string, and
+   (3) a <final> substring, if present, matches the end of the prepared
+   attribute value character string.  A prepared substring matches a
+   portion of the prepared attribute value character string if
+   corresponding characters have the same code point.
+
+   In preparing the attribute value and assertion value substrings for
+   comparison, characters are case folded in the Map preparation step,
+   and only Insignificant Space Handling is applied in the Insignificant
+   Character Handling step.
+
+      ( 1.3.6.1.4.1.1466.109.114.3 NAME 'caseIgnoreIA5SubstringsMatch'
+         SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
+
+   The caseIgnoreIA5SubstringsMatch rule is a substrings matching rule.
+
+4.2.9.  caseIgnoreListMatch
+
+   The caseIgnoreListMatch rule compares an assertion value that is a
+   sequence of strings to an attribute value of a syntax (e.g., the
+
+
+
+Legg                        Standards Track                    [Page 31]
+
+RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
+
+
+   Postal Address syntax) whose corresponding ASN.1 type is a SEQUENCE
+   OF the DirectoryString ASN.1 type.
+
+   The rule evaluates to TRUE if and only if the attribute value and the
+   assertion value have the same number of strings and corresponding
+   strings (by position) match according to the caseIgnoreMatch matching
+   rule.
+
+   In [X.520], the assertion syntax for this matching rule is defined to
+   be:
+
+      SEQUENCE OF DirectoryString {ub-match}
+
+   That is, it is different from the corresponding type for the Postal
+   Address syntax.  The choice of the Postal Address syntax for the
+   assertion syntax of the caseIgnoreListMatch in LDAP should not be
+   seen as limiting the matching rule to apply only to attributes with
+   the Postal Address syntax.
+
+   The LDAP definition for the caseIgnoreListMatch rule is:
+
+      ( 2.5.13.11 NAME 'caseIgnoreListMatch'
+         SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 )
+
+   The caseIgnoreListMatch rule is an equality matching rule.
+
+4.2.10.  caseIgnoreListSubstringsMatch
+
+   The caseIgnoreListSubstringsMatch rule compares an assertion value of
+   the Substring Assertion syntax to an attribute value of a syntax
+   (e.g., the Postal Address syntax) whose corresponding ASN.1 type is a
+   SEQUENCE OF the DirectoryString ASN.1 type.
+
+   The rule evaluates to TRUE if and only if the assertion value
+   matches, per the caseIgnoreSubstringsMatch rule, the character string
+   formed by concatenating the strings of the attribute value, except
+   that none of the <initial>, <any>, or <final> substrings of the
+   assertion value are considered to match a substring of the
+   concatenated string which spans more than one of the original strings
+   of the attribute value.
+
+   Note that, in terms of the LDAP-specific encoding of the Postal
+   Address syntax, the concatenated string omits the <DOLLAR> line
+   separator and the escaping of "\" and "$" characters.
+
+   The LDAP definition for the caseIgnoreListSubstringsMatch rule is:
+
+      ( 2.5.13.12 NAME 'caseIgnoreListSubstringsMatch'
+
+
+
+Legg                        Standards Track                    [Page 32]
+
+RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
+
+
+         SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
+
+   The caseIgnoreListSubstringsMatch rule is a substrings matching rule.
+
+4.2.11.  caseIgnoreMatch
+
+   The caseIgnoreMatch rule compares an assertion value of the Directory
+   String syntax to an attribute value of a syntax (e.g., the Directory
+   String, Printable String, Country String, or Telephone Number syntax)
+   whose corresponding ASN.1 type is DirectoryString or one of its
+   alternative string types.
+
+   The rule evaluates to TRUE if and only if the prepared attribute
+   value character string and the prepared assertion value character
+   string have the same number of characters and corresponding
+   characters have the same code point.
+
+   In preparing the attribute value and assertion value for comparison,
+   characters are case folded in the Map preparation step, and only
+   Insignificant Space Handling is applied in the Insignificant
+   Character Handling step.
+
+   The LDAP definition for the caseIgnoreMatch rule is:
+
+      ( 2.5.13.2 NAME 'caseIgnoreMatch'
+         SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+   The caseIgnoreMatch rule is an equality matching rule.
+
+4.2.12.  caseIgnoreOrderingMatch
+
+   The caseIgnoreOrderingMatch rule compares an assertion value of the
+   Directory String syntax to an attribute value of a syntax (e.g., the
+   Directory String, Printable String, Country String, or Telephone
+   Number syntax) whose corresponding ASN.1 type is DirectoryString or
+   one of its alternative string types.
+
+   The rule evaluates to TRUE if and only if, in the code point
+   collation order, the prepared attribute value character string
+   appears earlier than the prepared assertion value character string;
+   i.e., the attribute value is "less than" the assertion value.
+
+   In preparing the attribute value and assertion value for comparison,
+   characters are case folded in the Map preparation step, and only
+   Insignificant Space Handling is applied in the Insignificant
+   Character Handling step.
+
+   The LDAP definition for the caseIgnoreOrderingMatch rule is:
+
+
+
+Legg                        Standards Track                    [Page 33]
+
+RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
+
+
+      ( 2.5.13.3 NAME 'caseIgnoreOrderingMatch'
+         SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+   The caseIgnoreOrderingMatch rule is an ordering matching rule.
+
+4.2.13.  caseIgnoreSubstringsMatch
+
+   The caseIgnoreSubstringsMatch rule compares an assertion value of the
+   Substring Assertion syntax to an attribute value of a syntax (e.g.,
+   the Directory String, Printable String, Country String, or Telephone
+   Number syntax) whose corresponding ASN.1 type is DirectoryString or
+   one of its alternative string types.
+
+   The rule evaluates to TRUE if and only if (1) the prepared substrings
+   of the assertion value match disjoint portions of the prepared
+   attribute value character string in the order of the substrings in
+   the assertion value, (2) an <initial> substring, if present, matches
+   the beginning of the prepared attribute value character string, and
+   (3) a <final> substring, if present, matches the end of the prepared
+   attribute value character string.  A prepared substring matches a
+   portion of the prepared attribute value character string if
+   corresponding characters have the same code point.
+
+   In preparing the attribute value and assertion value substrings for
+   comparison, characters are case folded in the Map preparation step,
+   and only Insignificant Space Handling is applied in the Insignificant
+   Character Handling step.
+
+   The LDAP definition for the caseIgnoreSubstringsMatch rule is:
+
+      ( 2.5.13.4 NAME 'caseIgnoreSubstringsMatch'
+         SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
+
+   The caseIgnoreSubstringsMatch rule is a substrings matching rule.
+
+4.2.14.  directoryStringFirstComponentMatch
+
+   The directoryStringFirstComponentMatch rule compares an assertion
+   value of the Directory String syntax to an attribute value of a
+   syntax whose corresponding ASN.1 type is a SEQUENCE with a mandatory
+   first component of the DirectoryString ASN.1 type.
+
+   Note that the assertion syntax of this matching rule differs from the
+   attribute syntax of attributes for which this is the equality
+   matching rule.
+
+
+
+
+
+
+Legg                        Standards Track                    [Page 34]
+
+RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
+
+
+   The rule evaluates to TRUE if and only if the assertion value matches
+   the first component of the attribute value using the rules of
+   caseIgnoreMatch.
+
+   The LDAP definition for the directoryStringFirstComponentMatch
+   matching rule is:
+
+      ( 2.5.13.31 NAME 'directoryStringFirstComponentMatch'
+         SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+   The directoryStringFirstComponentMatch rule is an equality matching
+   rule.  When using directoryStringFirstComponentMatch to compare two
+   attribute values (of an applicable syntax), an assertion value must
+   first be derived from one of the attribute values.  An assertion
+   value can be derived from an attribute value by taking the first
+   component of that attribute value.
+
+4.2.15.  distinguishedNameMatch
+
+   The distinguishedNameMatch rule compares an assertion value of the DN
+   syntax to an attribute value of a syntax (e.g., the DN syntax) whose
+   corresponding ASN.1 type is DistinguishedName.
+
+   The rule evaluates to TRUE if and only if the attribute value and the
+   assertion value have the same number of relative distinguished names
+   and corresponding relative distinguished names (by position) are the
+   same.  A relative distinguished name (RDN) of the assertion value is
+   the same as an RDN of the attribute value if and only if they have
+   the same number of attribute value assertions and each attribute
+   value assertion (AVA) of the first RDN is the same as the AVA of the
+   second RDN with the same attribute type.  The order of the AVAs is
+   not significant.  Also note that a particular attribute type may
+   appear in at most one AVA in an RDN.  Two AVAs with the same
+   attribute type are the same if their values are equal according to
+   the equality matching rule of the attribute type.  If one or more of
+   the AVA comparisons evaluate to Undefined and the remaining AVA
+   comparisons return TRUE then the distinguishedNameMatch rule
+   evaluates to Undefined.
+
+   The LDAP definition for the distinguishedNameMatch rule is:
+
+      ( 2.5.13.1 NAME 'distinguishedNameMatch'
+         SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
+
+   The distinguishedNameMatch rule is an equality matching rule.
+
+
+
+
+
+
+Legg                        Standards Track                    [Page 35]
+
+RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
+
+
+4.2.16.  generalizedTimeMatch
+
+   The generalizedTimeMatch rule compares an assertion value of the
+   Generalized Time syntax to an attribute value of a syntax (e.g., the
+   Generalized Time syntax) whose corresponding ASN.1 type is
+   GeneralizedTime.
+
+   The rule evaluates to TRUE if and only if the attribute value
+   represents the same universal coordinated time as the assertion
+   value.  If a time is specified with the minutes or seconds absent,
+   then the number of minutes or seconds (respectively) is assumed to be
+   zero.
+
+   The LDAP definition for the generalizedTimeMatch rule is:
+
+      ( 2.5.13.27 NAME 'generalizedTimeMatch'
+         SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 )
+
+   The generalizedTimeMatch rule is an equality matching rule.
+
+4.2.17.  generalizedTimeOrderingMatch
+
+   The generalizedTimeOrderingMatch rule compares the time ordering of
+   an assertion value of the Generalized Time syntax to an attribute
+   value of a syntax (e.g., the Generalized Time syntax) whose
+   corresponding ASN.1 type is GeneralizedTime.
+
+   The rule evaluates to TRUE if and only if the attribute value
+   represents a universal coordinated time that is earlier than the
+   universal coordinated time represented by the assertion value.
+
+   The LDAP definition for the generalizedTimeOrderingMatch rule is:
+
+      ( 2.5.13.28 NAME 'generalizedTimeOrderingMatch'
+         SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 )
+
+   The generalizedTimeOrderingMatch rule is an ordering matching rule.
+
+4.2.18.  integerFirstComponentMatch
+
+   The integerFirstComponentMatch rule compares an assertion value of
+   the Integer syntax to an attribute value of a syntax (e.g., the DIT
+   Structure Rule Description syntax) whose corresponding ASN.1 type is
+   a SEQUENCE with a mandatory first component of the INTEGER ASN.1
+   type.
+
+
+
+
+
+
+Legg                        Standards Track                    [Page 36]
+
+RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
+
+
+   Note that the assertion syntax of this matching rule differs from the
+   attribute syntax of attributes for which this is the equality
+   matching rule.
+
+   The rule evaluates to TRUE if and only if the assertion value and the
+   first component of the attribute value are the same integer value.
+
+   The LDAP definition for the integerFirstComponentMatch matching rule
+   is:
+
+      ( 2.5.13.29 NAME 'integerFirstComponentMatch'
+         SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )
+
+   The integerFirstComponentMatch rule is an equality matching rule.
+   When using integerFirstComponentMatch to compare two attribute values
+   (of an applicable syntax), an assertion value must first be derived
+   from one of the attribute values.  An assertion value can be derived
+   from an attribute value by taking the first component of that
+   attribute value.
+
+4.2.19.  integerMatch
+
+   The integerMatch rule compares an assertion value of the Integer
+   syntax to an attribute value of a syntax (e.g., the Integer syntax)
+   whose corresponding ASN.1 type is INTEGER.
+
+   The rule evaluates to TRUE if and only if the attribute value and the
+   assertion value are the same integer value.
+
+   The LDAP definition for the integerMatch matching rule is:
+
+      ( 2.5.13.14 NAME 'integerMatch'
+         SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )
+
+   The integerMatch rule is an equality matching rule.
+
+4.2.20.  integerOrderingMatch
+
+   The integerOrderingMatch rule compares an assertion value of the
+   Integer syntax to an attribute value of a syntax (e.g., the Integer
+   syntax) whose corresponding ASN.1 type is INTEGER.
+
+   The rule evaluates to TRUE if and only if the integer value of the
+   attribute value is less than the integer value of the assertion
+   value.
+
+   The LDAP definition for the integerOrderingMatch matching rule is:
+
+
+
+
+Legg                        Standards Track                    [Page 37]
+
+RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
+
+
+      ( 2.5.13.15 NAME 'integerOrderingMatch'
+         SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )
+
+   The integerOrderingMatch rule is an ordering matching rule.
+
+4.2.21.  keywordMatch
+
+   The keywordMatch rule compares an assertion value of the Directory
+   String syntax to an attribute value of a syntax (e.g., the Directory
+   String syntax) whose corresponding ASN.1 type is DirectoryString.
+
+   The rule evaluates to TRUE if and only if the assertion value
+   character string matches any keyword in the attribute value.  The
+   identification of keywords in the attribute value and the exactness
+   of the match are both implementation specific.
+
+   The LDAP definition for the keywordMatch rule is:
+
+      ( 2.5.13.33 NAME 'keywordMatch'
+         SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+4.2.22.  numericStringMatch
+
+   The numericStringMatch rule compares an assertion value of the
+   Numeric String syntax to an attribute value of a syntax (e.g., the
+   Numeric String syntax) whose corresponding ASN.1 type is
+   NumericString.
+
+   The rule evaluates to TRUE if and only if the prepared attribute
+   value character string and the prepared assertion value character
+   string have the same number of characters and corresponding
+   characters have the same code point.
+
+   In preparing the attribute value and assertion value for comparison,
+   characters are not case folded in the Map preparation step, and only
+   numericString Insignificant Character Handling is applied in the
+   Insignificant Character Handling step.
+
+   The LDAP definition for the numericStringMatch matching rule is:
+
+      ( 2.5.13.8 NAME 'numericStringMatch'
+         SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 )
+
+   The numericStringMatch rule is an equality matching rule.
+
+
+
+
+
+
+
+Legg                        Standards Track                    [Page 38]
+
+RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
+
+
+4.2.23.  numericStringOrderingMatch
+
+   The numericStringOrderingMatch rule compares an assertion value of
+   the Numeric String syntax to an attribute value of a syntax (e.g.,
+   the Numeric String syntax) whose corresponding ASN.1 type is
+   NumericString.
+
+   The rule evaluates to TRUE if and only if, in the code point
+   collation order, the prepared attribute value character string
+   appears earlier than the prepared assertion value character string;
+   i.e., the attribute value is "less than" the assertion value.
+
+   In preparing the attribute value and assertion value for comparison,
+   characters are not case folded in the Map preparation step, and only
+   numericString Insignificant Character Handling is applied in the
+   Insignificant Character Handling step.
+
+   The rule is identical to the caseIgnoreOrderingMatch rule except that
+   all space characters are skipped during comparison (case is
+   irrelevant as the characters are numeric).
+
+   The LDAP definition for the numericStringOrderingMatch matching rule
+   is:
+
+      ( 2.5.13.9 NAME 'numericStringOrderingMatch'
+         SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 )
+
+   The numericStringOrderingMatch rule is an ordering matching rule.
+
+4.2.24.  numericStringSubstringsMatch
+
+   The numericStringSubstringsMatch rule compares an assertion value of
+   the Substring Assertion syntax to an attribute value of a syntax
+   (e.g., the Numeric String syntax) whose corresponding ASN.1 type is
+   NumericString.
+
+   The rule evaluates to TRUE if and only if (1) the prepared substrings
+   of the assertion value match disjoint portions of the prepared
+   attribute value character string in the order of the substrings in
+   the assertion value, (2) an <initial> substring, if present, matches
+   the beginning of the prepared attribute value character string, and
+   (3) a <final> substring, if present, matches the end of the prepared
+   attribute value character string.  A prepared substring matches a
+   portion of the prepared attribute value character string if
+   corresponding characters have the same code point.
+
+   In preparing the attribute value and assertion value for comparison,
+   characters are not case folded in the Map preparation step, and only
+
+
+
+Legg                        Standards Track                    [Page 39]
+
+RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
+
+
+   numericString Insignificant Character Handling is applied in the
+   Insignificant Character Handling step.
+
+   The LDAP definition for the numericStringSubstringsMatch matching
+   rule is:
+
+      ( 2.5.13.10 NAME 'numericStringSubstringsMatch'
+         SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
+
+   The numericStringSubstringsMatch rule is a substrings matching rule.
+
+4.2.25.  objectIdentifierFirstComponentMatch
+
+   The objectIdentifierFirstComponentMatch rule compares an assertion
+   value of the OID syntax to an attribute value of a syntax (e.g., the
+   Attribute Type Description, DIT Content Rule Description, LDAP Syntax
+   Description, Matching Rule Description, Matching Rule Use
+   Description, Name Form Description, or Object Class Description
+   syntax) whose corresponding ASN.1 type is a SEQUENCE with a mandatory
+   first component of the OBJECT IDENTIFIER ASN.1 type.
+
+   Note that the assertion syntax of this matching rule differs from the
+   attribute syntax of attributes for which this is the equality
+   matching rule.
+
+   The rule evaluates to TRUE if and only if the assertion value matches
+   the first component of the attribute value using the rules of
+   objectIdentifierMatch.
+
+   The LDAP definition for the objectIdentifierFirstComponentMatch
+   matching rule is:
+
+      ( 2.5.13.30 NAME 'objectIdentifierFirstComponentMatch'
+         SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
+
+   The objectIdentifierFirstComponentMatch rule is an equality matching
+   rule.  When using objectIdentifierFirstComponentMatch to compare two
+   attribute values (of an applicable syntax), an assertion value must
+   first be derived from one of the attribute values.  An assertion
+   value can be derived from an attribute value by taking the first
+   component of that attribute value.
+
+4.2.26.  objectIdentifierMatch
+
+   The objectIdentifierMatch rule compares an assertion value of the OID
+   syntax to an attribute value of a syntax (e.g., the OID syntax) whose
+   corresponding ASN.1 type is OBJECT IDENTIFIER.
+
+
+
+
+Legg                        Standards Track                    [Page 40]
+
+RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
+
+
+   The rule evaluates to TRUE if and only if the assertion value and the
+   attribute value represent the same object identifier; that is, the
+   same sequence of integers, whether represented explicitly in the
+   <numericoid> form of <oid> or implicitly in the <descr> form (see
+   [RFC4512]).
+
+   If an LDAP client supplies an assertion value in the <descr> form and
+   the chosen descriptor is not recognized by the server, then the
+   objectIdentifierMatch rule evaluates to Undefined.
+
+   The LDAP definition for the objectIdentifierMatch matching rule is:
+
+      ( 2.5.13.0 NAME 'objectIdentifierMatch'
+         SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
+
+   The objectIdentifierMatch rule is an equality matching rule.
+
+4.2.27.  octetStringMatch
+
+   The octetStringMatch rule compares an assertion value of the Octet
+   String syntax to an attribute value of a syntax (e.g., the Octet
+   String or JPEG syntax) whose corresponding ASN.1 type is the OCTET
+   STRING ASN.1 type.
+
+   The rule evaluates to TRUE if and only if the attribute value and the
+   assertion value are the same length and corresponding octets (by
+   position) are the same.
+
+   The LDAP definition for the octetStringMatch matching rule is:
+
+      ( 2.5.13.17 NAME 'octetStringMatch'
+         SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )
+
+   The octetStringMatch rule is an equality matching rule.
+
+4.2.28.  octetStringOrderingMatch
+
+   The octetStringOrderingMatch rule compares an assertion value of the
+   Octet String syntax to an attribute value of a syntax (e.g., the
+   Octet String or JPEG syntax) whose corresponding ASN.1 type is the
+   OCTET STRING ASN.1 type.
+
+   The rule evaluates to TRUE if and only if the attribute value appears
+   earlier in the collation order than the assertion value.  The rule
+   compares octet strings from the first octet to the last octet, and
+   from the most significant bit to the least significant bit within the
+   octet.  The first occurrence of a different bit determines the
+   ordering of the strings.  A zero bit precedes a one bit.  If the
+
+
+
+Legg                        Standards Track                    [Page 41]
+
+RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
+
+
+   strings contain different numbers of octets but the longer string is
+   identical to the shorter string up to the length of the shorter
+   string, then the shorter string precedes the longer string.
+
+   The LDAP definition for the octetStringOrderingMatch matching rule
+   is:
+
+      ( 2.5.13.18 NAME 'octetStringOrderingMatch'
+         SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )
+
+   The octetStringOrderingMatch rule is an ordering matching rule.
+
+4.2.29.  telephoneNumberMatch
+
+   The telephoneNumberMatch rule compares an assertion value of the
+   Telephone Number syntax to an attribute value of a syntax (e.g., the
+   Telephone Number syntax) whose corresponding ASN.1 type is a
+   PrintableString representing a telephone number.
+
+   The rule evaluates to TRUE if and only if the prepared attribute
+   value character string and the prepared assertion value character
+   string have the same number of characters and corresponding
+   characters have the same code point.
+
+   In preparing the attribute value and assertion value for comparison,
+   characters are case folded in the Map preparation step, and only
+   telephoneNumber Insignificant Character Handling is applied in the
+   Insignificant Character Handling step.
+
+   The LDAP definition for the telephoneNumberMatch matching rule is:
+
+      ( 2.5.13.20 NAME 'telephoneNumberMatch'
+         SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 )
+
+   The telephoneNumberMatch rule is an equality matching rule.
+
+4.2.30.  telephoneNumberSubstringsMatch
+
+   The telephoneNumberSubstringsMatch rule compares an assertion value
+   of the Substring Assertion syntax to an attribute value of a syntax
+   (e.g., the Telephone Number syntax) whose corresponding ASN.1 type is
+   a PrintableString representing a telephone number.
+
+   The rule evaluates to TRUE if and only if (1) the prepared substrings
+   of the assertion value match disjoint portions of the prepared
+   attribute value character string in the order of the substrings in
+   the assertion value, (2) an <initial> substring, if present, matches
+   the beginning of the prepared attribute value character string, and
+
+
+
+Legg                        Standards Track                    [Page 42]
+
+RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
+
+
+   (3) a <final> substring, if present, matches the end of the prepared
+   attribute value character string.  A prepared substring matches a
+   portion of the prepared attribute value character string if
+   corresponding characters have the same code point.
+
+   In preparing the attribute value and assertion value substrings for
+   comparison, characters are case folded in the Map preparation step,
+   and only telephoneNumber Insignificant Character Handling is applied
+   in the Insignificant Character Handling step.
+
+   The LDAP definition for the telephoneNumberSubstringsMatch matching
+   rule is:
+
+      ( 2.5.13.21 NAME 'telephoneNumberSubstringsMatch'
+         SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
+
+   The telephoneNumberSubstringsMatch rule is a substrings matching
+   rule.
+
+4.2.31.  uniqueMemberMatch
+
+   The uniqueMemberMatch rule compares an assertion value of the Name
+   And Optional UID syntax to an attribute value of a syntax (e.g., the
+   Name And Optional UID syntax) whose corresponding ASN.1 type is
+   NameAndOptionalUID.
+
+   The rule evaluates to TRUE if and only if the <distinguishedName>
+   components of the assertion value and attribute value match according
+   to the distinguishedNameMatch rule and either, (1) the <BitString>
+   component is absent from both the attribute value and assertion
+   value, or (2) the <BitString> component is present in both the
+   attribute value and the assertion value and the <BitString> component
+   of the assertion value matches the <BitString> component of the
+   attribute value according to the bitStringMatch rule.
+
+   Note that this matching rule has been altered from its description in
+   X.520 [X.520] in order to make the matching rule commutative.  Server
+   implementors should consider using the original X.520 semantics
+   (where the matching was less exact) for approximate matching of
+   attributes with uniqueMemberMatch as the equality matching rule.
+
+   The LDAP definition for the uniqueMemberMatch matching rule is:
+
+      ( 2.5.13.23 NAME 'uniqueMemberMatch'
+         SYNTAX 1.3.6.1.4.1.1466.115.121.1.34 )
+
+   The uniqueMemberMatch rule is an equality matching rule.
+
+
+
+
+Legg                        Standards Track                    [Page 43]
+
+RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
+
+
+4.2.32.  wordMatch
+
+   The wordMatch rule compares an assertion value of the Directory
+   String syntax to an attribute value of a syntax (e.g., the Directory
+   String syntax) whose corresponding ASN.1 type is DirectoryString.
+
+   The rule evaluates to TRUE if and only if the assertion value word
+   matches, according to the semantics of caseIgnoreMatch, any word in
+   the attribute value.  The precise definition of a word is
+   implementation specific.
+
+   The LDAP definition for the wordMatch rule is:
+
+      ( 2.5.13.32 NAME 'wordMatch'
+         SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+5.  Security Considerations
+
+   In general, the LDAP-specific encodings for syntaxes defined in this
+   document do not define canonical encodings.  That is, a
+   transformation from an LDAP-specific encoding into some other
+   encoding (e.g., BER) and back into the LDAP-specific encoding will
+   not necessarily reproduce exactly the original octets of the LDAP-
+   specific encoding.  Therefore, an LDAP-specific encoding should not
+   be used where a canonical encoding is required.
+
+   Furthermore, the LDAP-specific encodings do not necessarily enable an
+   alternative encoding of values of the Directory String and DN
+   syntaxes to be reconstructed; e.g., a transformation from a
+   Distinguished Encoding Rules (DER) [BER] encoding to an LDAP-specific
+   encoding and back to a DER encoding may not reproduce the original
+   DER encoding.  Therefore, LDAP-specific encodings should not be used
+   where reversibility to DER is needed; e.g., for the verification of
+   digital signatures.  Instead, DER or a DER-reversible encoding should
+   be used.
+
+   When interpreting security-sensitive fields (in particular, fields
+   used to grant or deny access), implementations MUST ensure that any
+   matching rule comparisons are done on the underlying abstract value,
+   regardless of the particular encoding used.
+
+6.  Acknowledgements
+
+   This document is primarily a revision of RFC 2252 by M. Wahl, A.
+   Coulbeck, T. Howes, and S. Kille.  RFC 2252 was a product of the IETF
+   ASID Working Group.
+
+
+
+
+
+Legg                        Standards Track                    [Page 44]
+
+RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
+
+
+   This document is based on input from the IETF LDAPBIS working group.
+   The author would like to thank Kathy Dally for editing the early
+   drafts of this document, and Jim Sermersheim and Kurt Zeilenga for
+   their significant contributions to this revision.
+
+7.  IANA Considerations
+
+   The Internet Assigned Numbers Authority (IANA) has updated the LDAP
+   descriptors registry [BCP64] as indicated by the following templates:
+
+      Subject: Request for LDAP Descriptor Registration Update
+      Descriptor (short name): see comment
+      Object Identifier: see comment
+      Person & email address to contact for further information:
+        Steven Legg <steven.legg@eb2bcom.com>
+      Usage: see comment
+      Specification: RFC 4517
+      Author/Change Controller: IESG
+
+      NAME                              Type  OID
+      ------------------------------------------------------------------
+      bitStringMatch                       M  2.5.13.16
+      booleanMatch                         M  2.5.13.13
+      caseExactIA5Match                    M  1.3.6.1.4.1.1466.109.114.1
+      caseExactMatch                       M  2.5.13.5
+      caseExactOrderingMatch               M  2.5.13.6
+      caseExactSubstringsMatch             M  2.5.13.7
+      caseIgnoreIA5Match                   M  1.3.6.1.4.1.1466.109.114.2
+      caseIgnoreListMatch                  M  2.5.13.11
+      caseIgnoreListSubstringsMatch        M  2.5.13.12
+      caseIgnoreMatch                      M  2.5.13.2
+      caseIgnoreOrderingMatch              M  2.5.13.3
+      caseIgnoreSubstringsMatch            M  2.5.13.4
+      directoryStringFirstComponentMatch   M  2.5.13.31
+      distinguishedNameMatch               M  2.5.13.1
+      generalizedTimeMatch                 M  2.5.13.27
+      generalizedTimeOrderingMatch         M  2.5.13.28
+      integerFirstComponentMatch           M  2.5.13.29
+      integerMatch                         M  2.5.13.14
+      integerOrderingMatch                 M  2.5.13.15
+      keywordMatch                         M  2.5.13.33
+      numericStringMatch                   M  2.5.13.8
+      numericStringOrderingMatch           M  2.5.13.9
+      numericStringSubstringsMatch         M  2.5.13.10
+      objectIdentifierFirstComponentMatch  M  2.5.13.30
+      octetStringMatch                     M  2.5.13.17
+      octetStringOrderingMatch             M  2.5.13.18
+      telephoneNumberMatch                 M  2.5.13.20
+
+
+
+Legg                        Standards Track                    [Page 45]
+
+RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
+
+
+      telephoneNumberSubstringsMatch       M  2.5.13.21
+      uniqueMemberMatch                    M  2.5.13.23
+      wordMatch                            M  2.5.13.32
+
+      The descriptor for the object identifier 2.5.13.0 was incorrectly
+      registered as objectIdentifiersMatch (extraneous \`s') in BCP 64.
+      It has been changed to the following, with a reference to
+      RFC 4517.
+
+      NAME                              Type  OID
+      ------------------------------------------------------------------
+      objectIdentifierMatch                M  2.5.13.0
+
+      Subject: Request for LDAP Descriptor Registration
+      Descriptor (short name): caseIgnoreIA5SubstringsMatch
+      Object Identifier: 1.3.6.1.4.1.1466.109.114.3
+      Person & email address to contact for further information:
+        Steven Legg <steven.legg@eb2bcom.com>
+      Usage: other (M)
+      Specification: RFC 4517
+      Author/Change Controller: IESG
+
+8.  References
+
+8.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO
+              10646", STD 63, RFC 3629, November 2003.
+
+   [RFC4234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
+              Specifications: ABNF", RFC 4234, October 2005.
+
+   [RFC4510]  Zeilenga, K., Ed., "Lightweight Directory Access Protocol
+              (LDAP): Technical Specification Road Map", RFC 4510, June
+              2006.
+
+   [RFC4511]  Sermersheim, J., Ed., "Lightweight Directory Access
+              Protocol (LDAP): The Protocol", RFC 4511, June 2006.
+
+   [RFC4512]  Zeilenga, K., "Lightweight Directory Access Protocol
+              (LDAP): Directory Information Models", RFC 4512, June
+              2006.
+
+
+
+
+
+
+Legg                        Standards Track                    [Page 46]
+
+RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
+
+
+   [RFC4514]  Zeilenga, K., Ed., "Lightweight Directory Access Protocol
+              (LDAP): String Representation of Distinguished Names", RFC
+              4514, June 2006.
+
+   [RFC4518]  Zeilenga, K., "Lightweight Directory Access Protocol
+              (LDAP): Internationalized String Preparation", RFC 4518,
+              June 2006.
+
+   [RFC4520]  Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
+              Considerations for the Lightweight Directory Access
+              Protocol (LDAP)", BCP 64, RFC 4520, June 2006.
+
+   [E.123]    Notation for national and international telephone numbers,
+              ITU-T Recommendation E.123, 1988.
+
+   [FAX]      Standardization of Group 3 facsimile apparatus for
+              document transmission - Terminal Equipment and Protocols
+              for Telematic Services, ITU-T Recommendation T.4, 1993
+
+   [T.50]     International Reference Alphabet (IRA) (Formerly
+              International Alphabet No. 5 or IA5) Information
+              Technology - 7-Bit Coded Character Set for Information
+              Interchange, ITU-T Recommendation T.50, 1992
+
+   [X.420]    ITU-T Recommendation X.420 (1996) | ISO/IEC 10021-7:1997,
+              Information Technology - Message Handling Systems (MHS):
+              Interpersonal messaging system
+
+   [X.501]    ITU-T Recommendation X.501 (1993) | ISO/IEC 9594-2:1994,
+              Information Technology - Open Systems Interconnection -
+              The Directory: Models
+
+   [X.520]    ITU-T Recommendation X.520 (1993) | ISO/IEC 9594-6:1994,
+              Information Technology - Open Systems Interconnection -
+              The Directory: Selected attribute types
+
+   [ASN.1]    ITU-T Recommendation X.680 (07/02) | ISO/IEC 8824-1:2002,
+              Information technology - Abstract Syntax Notation One
+              (ASN.1): Specification of basic notation
+
+   [ISO3166]  ISO 3166, "Codes for the representation of names of
+              countries".
+
+   [ISO8601]  ISO 8601:2004, "Data elements and interchange formats --
+              Information interchange -- Representation of dates and
+              times".
+
+
+
+
+
+Legg                        Standards Track                    [Page 47]
+
+RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
+
+
+   [UCS]      Universal Multiple-Octet Coded Character Set (UCS) -
+              Architecture and Basic Multilingual Plane, ISO/IEC 10646-
+              1:  1993 (with amendments).
+
+   [JPEG]     JPEG File Interchange Format (Version 1.02).  Eric
+              Hamilton, C-Cube Microsystems, Milpitas, CA, September 1,
+              1992.
+
+8.2.  Informative References
+
+   [RFC4519]  Sciberras, A., Ed., "Lightweight Directory Access Protocol
+              (LDAP): Schema for User Applications", RFC 4519, June
+              2006.
+
+   [RFC4523]  Zeilenga, K., "Lightweight Directory Access Protocol
+              (LDAP) Schema Definitions for X.509 Certificates", RFC
+              4523, June 2006.
+
+   [X.500]    ITU-T Recommendation X.500 (1993) | ISO/IEC 9594-1:1994,
+              Information Technology - Open Systems Interconnection -
+              The Directory: Overview of concepts, models and services
+
+   [BER]      ITU-T Recommendation X.690 (07/02) | ISO/IEC 8825-1:2002,
+              Information technology - ASN.1 encoding rules:
+              Specification of Basic Encoding Rules (BER), Canonical
+              Encoding Rules (CER) and Distinguished Encoding Rules
+              (DER)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Legg                        Standards Track                    [Page 48]
+
+RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
+
+
+Appendix A. Summary of Syntax Object Identifiers
+
+   The following list summarizes the object identifiers assigned to the
+   syntaxes defined in this document.
+
+      Syntax                           OBJECT IDENTIFIER
+      ==============================================================
+      Attribute Type Description       1.3.6.1.4.1.1466.115.121.1.3
+      Bit String                       1.3.6.1.4.1.1466.115.121.1.6
+      Boolean                          1.3.6.1.4.1.1466.115.121.1.7
+      Country String                   1.3.6.1.4.1.1466.115.121.1.11
+      Delivery Method                  1.3.6.1.4.1.1466.115.121.1.14
+      Directory String                 1.3.6.1.4.1.1466.115.121.1.15
+      DIT Content Rule Description     1.3.6.1.4.1.1466.115.121.1.16
+      DIT Structure Rule Description   1.3.6.1.4.1.1466.115.121.1.17
+      DN                               1.3.6.1.4.1.1466.115.121.1.12
+      Enhanced Guide                   1.3.6.1.4.1.1466.115.121.1.21
+      Facsimile Telephone Number       1.3.6.1.4.1.1466.115.121.1.22
+      Fax                              1.3.6.1.4.1.1466.115.121.1.23
+      Generalized Time                 1.3.6.1.4.1.1466.115.121.1.24
+      Guide                            1.3.6.1.4.1.1466.115.121.1.25
+      IA5 String                       1.3.6.1.4.1.1466.115.121.1.26
+      Integer                          1.3.6.1.4.1.1466.115.121.1.27
+      JPEG                             1.3.6.1.4.1.1466.115.121.1.28
+      LDAP Syntax Description          1.3.6.1.4.1.1466.115.121.1.54
+      Matching Rule Description        1.3.6.1.4.1.1466.115.121.1.30
+      Matching Rule Use Description    1.3.6.1.4.1.1466.115.121.1.31
+      Name And Optional UID            1.3.6.1.4.1.1466.115.121.1.34
+      Name Form Description            1.3.6.1.4.1.1466.115.121.1.35
+      Numeric String                   1.3.6.1.4.1.1466.115.121.1.36
+      Object Class Description         1.3.6.1.4.1.1466.115.121.1.37
+      Octet String                     1.3.6.1.4.1.1466.115.121.1.40
+      OID                              1.3.6.1.4.1.1466.115.121.1.38
+      Other Mailbox                    1.3.6.1.4.1.1466.115.121.1.39
+      Postal Address                   1.3.6.1.4.1.1466.115.121.1.41
+      Printable String                 1.3.6.1.4.1.1466.115.121.1.44
+      Substring Assertion              1.3.6.1.4.1.1466.115.121.1.58
+      Telephone Number                 1.3.6.1.4.1.1466.115.121.1.50
+      Teletex Terminal Identifier      1.3.6.1.4.1.1466.115.121.1.51
+      Telex Number                     1.3.6.1.4.1.1466.115.121.1.52
+      UTC Time                         1.3.6.1.4.1.1466.115.121.1.53
+
+Appendix B. Changes from RFC 2252
+
+   This annex lists the significant differences between this
+   specification and RFC 2252.
+
+
+
+
+
+Legg                        Standards Track                    [Page 49]
+
+RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
+
+
+   This annex is provided for informational purposes only.  It is not a
+   normative part of this specification.
+
+   1.  The IESG Note has been removed.
+
+   2.  The major part of Sections 4, 5 and 7 has been moved to [RFC4512]
+       and revised.  Changes to the parts of these sections moved to
+       [RFC4512] are detailed in [RFC4512].
+
+   3.  BNF descriptions of syntax formats have been replaced by ABNF
+       [RFC4234] specifications.
+
+   4.  The ambiguous statement in RFC 2252, Section 4.3 regarding the
+       use of a backslash quoting mechanism to escape separator symbols
+       has been removed.  The escaping mechanism is now explicitly
+       represented in the ABNF for the syntaxes where this provision
+       applies.
+
+   5.  The description of each of the LDAP syntaxes has been expanded so
+       that they are less dependent on knowledge of X.500 for
+       interpretation.
+
+   6.  The relationship of LDAP syntaxes to corresponding ASN.1 type
+       definitions has been made explicit.
+
+   7.  The set of characters allowed in a <PrintableString> (formerly
+       <printablestring>) has been corrected to align with the
+       PrintableString ASN.1 type in [ASN.1].  Specifically, the double
+       quote character has been removed and the single quote character
+       and equals sign have been added.
+
+   8.  Values of the Directory String, Printable String and Telephone
+       Number syntaxes are now required to have at least one character.
+
+   9.  The <DITContentRuleDescription>, <NameFormDescription> and
+       <DITStructureRuleDescription> rules have been moved to [RFC4512].
+
+   10. The corresponding ASN.1 type for the Other Mailbox syntax has
+       been incorporated from RFC 1274.
+
+   11. A corresponding ASN.1 type for the LDAP Syntax Description syntax
+       has been invented.
+
+   12. The Binary syntax has been removed because it was not adequately
+       specified, implementations with different incompatible
+       interpretations exist, and it was confused with the ;binary
+       transfer encoding.
+
+
+
+
+Legg                        Standards Track                    [Page 50]
+
+RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
+
+
+   13. All discussion of transfer options, including the ";binary"
+       option, has been removed.  All imperatives regarding binary
+       transfer of values have been removed.
+
+   14. The Delivery Method, Enhanced Guide, Guide, Octet String, Teletex
+       Terminal Identifier and Telex Number syntaxes from RFC 2256 have
+       been incorporated.
+
+   15. The <criteria> rule for the Enhanced Guide and Guide syntaxes has
+       been extended to accommodate empty "and" and "or" expressions.
+
+   16. An encoding for the <ttx-value> rule in the Teletex Terminal
+       Identifier syntax has been defined.
+
+   17. The PKI-related syntaxes (Certificate, Certificate List and
+       Certificate Pair) have been removed.  They are reintroduced in
+       [RFC4523] (as is the Supported Algorithm syntax from RFC 2256).
+
+   18. The MHS OR Address syntax has been removed since its
+       specification (in RFC 2156) is not at draft standard maturity.
+
+   19. The DL Submit Permission syntax has been removed as it depends on
+       the MHS OR Address syntax.
+
+   20. The Presentation Address syntax has been removed since its
+       specification (in RFC 1278) is not at draft standard maturity.
+
+   21. The ACI Item, Access Point, Audio, Data Quality, DSA Quality, DSE
+       Type, LDAP Schema Description, Master And Shadow Access Points,
+       Modify Rights, Protocol Information, Subtree Specification,
+       Supplier Information, Supplier Or Consumer and Supplier And
+       Consumer syntaxes have been removed.  These syntaxes are
+       referenced in RFC 2252, but not defined.
+
+   22. The LDAP Schema Definition syntax (defined in RFC 2927) and the
+       Mail Preference syntax have been removed on the grounds that they
+       are out of scope for the core specification.
+
+   23. The description of each of the matching rules has been expanded
+       so that they are less dependent on knowledge of X.500 for
+       interpretation.
+
+   24. The caseIgnoreIA5SubstringsMatch matching rule from RFC 2798 has
+       been added.
+
+   25. The caseIgnoreListSubstringsMatch, caseIgnoreOrderingMatch and
+       caseIgnoreSubstringsMatch matching rules have been added to the
+       list of matching rules for which the provisions for handling
+
+
+
+Legg                        Standards Track                    [Page 51]
+
+RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
+
+
+       leading, trailing and multiple adjoining whitespace characters
+       apply (now through string preparation).  This is consistent with
+       the definitions of these matching rules in X.500.  The
+       caseIgnoreIA5SubstringsMatch rule has also been added to the
+       list.
+
+   26. The specification of the octetStringMatch matching rule from
+       RFC 2256 has been added to this document.
+
+   27. The presentationAddressMatch matching rule has been removed as it
+       depends on an assertion syntax (Presentation Address) that is not
+       at draft standard maturity.
+
+   28. The protocolInformationMatch matching rule has been removed as it
+       depends on an undefined assertion syntax (Protocol Information).
+
+   29. The definitive reference for ASN.1 has been changed from X.208 to
+       X.680 since X.680 is the version of ASN.1 referred to by X.500.
+
+   30. The specification of the caseIgnoreListSubstringsMatch matching
+       rule from RFC 2798 & X.520 has been added.
+
+   31. String preparation algorithms have been applied to the character
+       string matching rules.
+
+   32. The specifications of the booleanMatch, caseExactMatch,
+       caseExactOrderingMatch, caseExactSubstringsMatch,
+       directoryStringFirstComponentMatch, integerOrderingMatch,
+       keywordMatch, numericStringOrderingMatch,
+       octetStringOrderingMatch and wordMatch matching rules from
+       RFC 3698 & X.520 have been added.
+
+Author's Address
+
+   Steven Legg
+   eB2Bcom
+   Suite3, Woodhouse Corporate Centre
+   935 Station Street
+   Box Hill North, Victoria 3129
+   AUSTRALIA
+
+   Phone: +61 3 9896 7830
+   Fax: +61 3 9896 7801
+   EMail: steven.legg@eb2bcom.com
+
+
+
+
+
+
+
+Legg                        Standards Track                    [Page 52]
+
+RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2006).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Legg                        Standards Track                    [Page 53]
+
diff --git a/source4/ldap_server/devdocs/rfc4518.txt b/source4/ldap_server/devdocs/rfc4518.txt
new file mode 100644
index 0000000000..f886bdfb5d
--- /dev/null
+++ b/source4/ldap_server/devdocs/rfc4518.txt
@@ -0,0 +1,787 @@
+
+
+
+
+
+
+Network Working Group                                        K. Zeilenga
+Request for Comments: 4518                           OpenLDAP Foundation
+Category: Standards Track                                      June 2006
+
+
+             Lightweight Directory Access Protocol (LDAP):
+                  Internationalized String Preparation
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   The previous Lightweight Directory Access Protocol (LDAP) technical
+   specifications did not precisely define how character string matching
+   is to be performed.  This led to a number of usability and
+   interoperability problems.  This document defines string preparation
+   algorithms for character-based matching rules defined for use in
+   LDAP.
+
+1.  Introduction
+
+1.1.  Background
+
+   A Lightweight Directory Access Protocol (LDAP) [RFC4510] matching
+   rule [RFC4517] defines an algorithm for determining whether a
+   presented value matches an attribute value in accordance with the
+   criteria defined for the rule.  The proposition may be evaluated to
+   True, False, or Undefined.
+
+      True      - the attribute contains a matching value,
+
+      False     - the attribute contains no matching value,
+
+      Undefined - it cannot be determined whether the attribute contains
+                  a matching value.
+
+
+
+
+
+
+Zeilenga                    Standards Track                     [Page 1]
+
+RFC 4518       LDAP: Internationalized String Preparation      June 2006
+
+
+   For instance, the caseIgnoreMatch matching rule may be used to
+   compare whether the commonName attribute contains a particular value
+   without regard for case and insignificant spaces.
+
+1.2.  X.500 String Matching Rules
+
+   "X.520: Selected attribute types" [X.520] provides (among other
+   things) value syntaxes and matching rules for comparing values
+   commonly used in the directory [X.500].  These specifications are
+   inadequate for strings composed of Unicode [Unicode] characters.
+
+   The caseIgnoreMatch matching rule [X.520], for example, is simply
+   defined as being a case-insensitive comparison where insignificant
+   spaces are ignored.  For printableString, there is only one space
+   character and case mapping is bijective, hence this definition is
+   sufficient.  However, for Unicode string types such as
+   universalString, this is not sufficient.  For example, a case-
+   insensitive matching implementation that folded lowercase characters
+   to uppercase would yield different results than an implementation
+   that used uppercase to lowercase folding.  Or one implementation may
+   view space as referring to only SPACE (U+0020), a second
+   implementation may view any character with the space separator (Zs)
+   property as a space, and another implementation may view any
+   character with the whitespace (WS) category as a space.
+
+   The lack of precise specification for character string matching has
+   led to significant interoperability problems.  When used in
+   certificate chain validation, security vulnerabilities can arise.  To
+   address these problems, this document defines precise algorithms for
+   preparing character strings for matching.
+
+1.3.  Relationship to "stringprep"
+
+   The character string preparation algorithms described in this
+   document are based upon the "stringprep" approach [RFC3454].  In
+   "stringprep", presented and stored values are first prepared for
+   comparison so that a character-by-character comparison yields the
+   "correct" result.
+
+   The approach used here is a refinement of the "stringprep" [RFC3454]
+   approach.  Each algorithm involves two additional preparation steps.
+
+   a) Prior to applying the Unicode string preparation steps outlined in
+      "stringprep", the string is transcoded to Unicode.
+
+   b) After applying the Unicode string preparation steps outlined in
+      "stringprep", the string is modified to appropriately handle
+      characters insignificant to the matching rule.
+
+
+
+Zeilenga                    Standards Track                     [Page 2]
+
+RFC 4518       LDAP: Internationalized String Preparation      June 2006
+
+
+   Hence, preparation of character strings for X.500 [X.500] matching
+   [X.501] involves the following steps:
+
+      1) Transcode
+      2) Map
+      3) Normalize
+      4) Prohibit
+      5) Check Bidi (Bidirectional)
+      6) Insignificant Character Handling
+
+   These steps are described in Section 2.
+
+   It is noted that while various tables of Unicode characters included
+   or referenced by this specification are derived from Unicode
+   [Unicode] data, these tables are to be considered definitive for the
+   purpose of implementing this specification.
+
+1.4.  Relationship to the LDAP Technical Specification
+
+   This document is an integral part of the LDAP technical specification
+   [RFC4510], which obsoletes the previously defined LDAP technical
+   specification [RFC3377] in its entirety.
+
+   This document details new LDAP internationalized character string
+   preparation algorithms used by [RFC4517] and possible other technical
+   specifications defining LDAP syntaxes and/or matching rules.
+
+1.5.  Relationship to X.500
+
+   LDAP is defined [RFC4510] in X.500 terms as an X.500 access
+   mechanism.  As such, there is a strong desire for alignment between
+   LDAP and X.500 syntax and semantics.  The character string
+   preparation algorithms described in this document are based upon
+   "Internationalized String Matching Rules for X.500" [XMATCH] proposal
+   to ITU/ISO Joint Study Group 2.
+
+1.6.  Conventions and Terms
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in BCP 14 [RFC2119].
+
+   Character names in this document use the notation for code points and
+   names from the Unicode Standard [Unicode].  For example, the letter
+   "a" may be represented as either <U+0061> or <LATIN SMALL LETTER A>.
+   In the lists of mappings and the prohibited characters, the "U+" is
+
+
+
+
+
+Zeilenga                    Standards Track                     [Page 3]
+
+RFC 4518       LDAP: Internationalized String Preparation      June 2006
+
+
+   left off to make the lists easier to read.  The comments for
+   character ranges are shown in square brackets (such as "[CONTROL
+   CHARACTERS]") and do not come from the standard.
+
+   Note: a glossary of terms used in Unicode can be found in [Glossary].
+   Information on the Unicode character encoding model can be found in
+   [CharModel].
+
+   The term "combining mark", as used in this specification, refers to
+   any Unicode [Unicode] code point that has a mark property (Mn, Mc,
+   Me).  Appendix A provides a definitive list of combining marks.
+
+2.  String Preparation
+
+   The following six-step process SHALL be applied to each presented and
+   attribute value in preparation for character string matching rule
+   evaluation.
+
+      1) Transcode
+      2) Map
+      3) Normalize
+      4) Prohibit
+      5) Check bidi
+      6) Insignificant Character Handling
+
+   Failure in any step causes the assertion to evaluate to Undefined.
+
+   The character repertoire of this process is Unicode 3.2 [Unicode].
+
+   Note that this six-step process specification is intended to describe
+   expected matching behavior.  Implementations are free to use
+   alternative processes so long as the matching rule evaluation
+   behavior provided is consistent with the behavior described by this
+   specification.
+
+2.1.  Transcode
+
+   Each non-Unicode string value is transcoded to Unicode.
+
+   PrintableString [X.680] values are transcoded directly to Unicode.
+
+   UniversalString, UTF8String, and bmpString [X.680] values need not be
+   transcoded as they are Unicode-based strings (in the case of
+   bmpString, a subset of Unicode).
+
+   TeletexString [X.680] values are transcoded to Unicode.  As there is
+   no standard for mapping TeletexString values to Unicode, the mapping
+   is left a local matter.
+
+
+
+Zeilenga                    Standards Track                     [Page 4]
+
+RFC 4518       LDAP: Internationalized String Preparation      June 2006
+
+
+   For these and other reasons, use of TeletexString is NOT RECOMMENDED.
+
+   The output is the transcoded string.
+
+2.2.  Map
+
+   SOFT HYPHEN (U+00AD) and MONGOLIAN TODO SOFT HYPHEN (U+1806) code
+   points are mapped to nothing.  COMBINING GRAPHEME JOINER (U+034F) and
+   VARIATION SELECTORs (U+180B-180D, FF00-FE0F) code points are also
+   mapped to nothing.  The OBJECT REPLACEMENT CHARACTER (U+FFFC) is
+   mapped to nothing.
+
+   CHARACTER TABULATION (U+0009), LINE FEED (LF) (U+000A), LINE
+   TABULATION (U+000B), FORM FEED (FF) (U+000C), CARRIAGE RETURN (CR)
+   (U+000D), and NEXT LINE (NEL) (U+0085) are mapped to SPACE (U+0020).
+
+   All other control code (e.g., Cc) points or code points with a
+   control function (e.g., Cf) are mapped to nothing.  The following is
+   a complete list of these code points: U+0000-0008, 000E-001F, 007F-
+   0084, 0086-009F, 06DD, 070F, 180E, 200C-200F, 202A-202E, 2060-2063,
+   206A-206F, FEFF, FFF9-FFFB, 1D173-1D17A, E0001, E0020-E007F.
+
+   ZERO WIDTH SPACE (U+200B) is mapped to nothing.  All other code
+   points with Separator (space, line, or paragraph) property (e.g., Zs,
+   Zl, or Zp) are mapped to SPACE (U+0020).  The following is a complete
+   list of these code points: U+0020, 00A0, 1680, 2000-200A, 2028-2029,
+   202F, 205F, 3000.
+
+   For case ignore, numeric, and stored prefix string matching rules,
+   characters are case folded per B.2 of [RFC3454].
+
+   The output is the mapped string.
+
+2.3.  Normalize
+
+   The input string is to be normalized to Unicode Form KC
+   (compatibility composed) as described in [UAX15].  The output is the
+   normalized string.
+
+2.4.  Prohibit
+
+   All Unassigned code points are prohibited.  Unassigned code points
+   are listed in Table A.1 of [RFC3454].
+
+   Characters that, per Section 5.8 of [RFC3454], change display
+   properties or are deprecated are prohibited.  These characters are
+   listed in Table C.8 of [RFC3454].
+
+
+
+
+Zeilenga                    Standards Track                     [Page 5]
+
+RFC 4518       LDAP: Internationalized String Preparation      June 2006
+
+
+   Private Use code points are prohibited.  These characters are listed
+   in Table C.3 of [RFC3454].
+
+   All non-character code points are prohibited.  These code points are
+   listed in Table C.4 of [RFC3454].
+
+   Surrogate codes are prohibited.  These characters are listed in Table
+   C.5 of [RFC3454].
+
+   The REPLACEMENT CHARACTER (U+FFFD) code point is prohibited.
+
+   The step fails if the input string contains any prohibited code
+   point.  Otherwise, the output is the input string.
+
+2.5.  Check bidi
+
+   Bidirectional characters are ignored.
+
+2.6.  Insignificant Character Handling
+
+   In this step, the string is modified to ensure proper handling of
+   characters insignificant to the matching rule.  This modification
+   differs from matching rule to matching rule.
+
+   Section 2.6.1 applies to case ignore and exact string matching.
+   Section 2.6.2 applies to numericString matching.
+   Section 2.6.3 applies to telephoneNumber matching.
+
+2.6.1.  Insignificant Space Handling
+
+   For the purposes of this section, a space is defined to be the SPACE
+   (U+0020) code point followed by no combining marks.
+
+       NOTE - The previous steps ensure that the string cannot contain
+              any code points in the separator class, other than SPACE
+              (U+0020).
+
+   For input strings that are attribute values or non-substring
+   assertion values:  If the input string contains no non-space
+   character, then the output is exactly two SPACEs.  Otherwise (the
+   input string contains at least one non-space character), the string
+   is modified such that the string starts with exactly one space
+   character, ends with exactly one SPACE character, and any inner
+   (non-empty) sequence of space characters is replaced with exactly two
+   SPACE characters.  For instance, the input strings
+   "foo<SPACE>bar<SPACE><SPACE>", result in the output
+   "<SPACE>foo<SPACE><SPACE>bar<SPACE>".
+
+
+
+
+Zeilenga                    Standards Track                     [Page 6]
+
+RFC 4518       LDAP: Internationalized String Preparation      June 2006
+
+
+   For input strings that are substring assertion values: If the string
+   being prepared contains no non-space characters, then the output
+   string is exactly one SPACE.  Otherwise, the following steps are
+   taken:
+
+   -  If the input string is an initial substring, it is modified to
+      start with exactly one SPACE character;
+
+   -  If the input string is an initial or an any substring that ends in
+      one or more space characters, it is modified to end with exactly
+      one SPACE character;
+
+   -  If the input string is an any or a final substring that starts in
+      one or more space characters, it is modified to start with exactly
+      one SPACE character; and
+
+   -  If the input string is a final substring, it is modified to end
+      with exactly one SPACE character.
+
+   For instance, for the input string "foo<SPACE>bar<SPACE><SPACE>" as
+   an initial substring, the output would be
+   "<SPACE>foo<SPACE><SPACE>bar<SPACE>".  As an any or final substring,
+   the same input would result in "foo<SPACE>bar<SPACE>".
+
+   Appendix B discusses the rationale for the behavior.
+
+2.6.2.  numericString Insignificant Character Handling
+
+   For the purposes of this section, a space is defined to be the SPACE
+   (U+0020) code point followed by no combining marks.
+
+   All spaces are regarded as insignificant and are to be removed.
+
+   For example, removal of spaces from the Form KC string:
+       "<SPACE><SPACE>123<SPACE><SPACE>456<SPACE><SPACE>"
+   would result in the output string:
+       "123456"
+   and the Form KC string:
+       "<SPACE><SPACE><SPACE>"
+   would result in the output string:
+       "" (an empty string).
+
+2.6.3.  telephoneNumber Insignificant Character Handling
+
+   For the purposes of this section, a hyphen is defined to be a
+   HYPHEN-MINUS (U+002D), ARMENIAN HYPHEN (U+058A), HYPHEN (U+2010),
+   NON-BREAKING HYPHEN (U+2011), MINUS SIGN (U+2212), SMALL HYPHEN-MINUS
+   (U+FE63), or FULLWIDTH HYPHEN-MINUS (U+FF0D) code point followed by
+
+
+
+Zeilenga                    Standards Track                     [Page 7]
+
+RFC 4518       LDAP: Internationalized String Preparation      June 2006
+
+
+   no combining marks and a space is defined to be the SPACE (U+0020)
+   code point followed by no combining marks.
+
+   All hyphens and spaces are considered insignificant and are to be
+   removed.
+
+   For example, removal of hyphens and spaces from the Form KC string:
+       "<SPACE><HYPHEN>123<SPACE><SPACE>456<SPACE><HYPHEN>"
+   would result in the output string:
+       "123456"
+   and the Form KC string:
+       "<HYPHEN><HYPHEN><HYPHEN>"
+   would result in the (empty) output string:
+       "".
+
+3.  Security Considerations
+
+   "Preparation of Internationalized Strings ("stringprep")" [RFC3454]
+   security considerations generally apply to the algorithms described
+   here.
+
+4.  Acknowledgements
+
+   The approach used in this document is based upon design principles
+   and algorithms described in "Preparation of Internationalized Strings
+   ('stringprep')" [RFC3454] by Paul Hoffman and Marc Blanchet.  Some
+   additional guidance was drawn from Unicode Technical Standards,
+   Technical Reports, and Notes.
+
+   This document is a product of the IETF LDAP Revision (LDAPBIS)
+   Working Group.
+
+5.  References
+
+5.1.  Normative References
+
+   [RFC2119]     Bradner, S., "Key words for use in RFCs to Indicate
+                 Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC3454]     Hoffman, P. and M. Blanchet, "Preparation of
+                 Internationalized Strings ("stringprep")", RFC 3454,
+                 December 2002.
+
+   [RFC4510]     Zeilenga, K., "Lightweight Directory Access Protocol
+                 (LDAP): Technical Specification Road Map", RFC 4510,
+                 June 2006.
+
+
+
+
+
+Zeilenga                    Standards Track                     [Page 8]
+
+RFC 4518       LDAP: Internationalized String Preparation      June 2006
+
+
+   [RFC4517]     Legg, S., Ed., "Lightweight Directory Access Protocol
+                 (LDAP): Syntaxes and Matching Rules", RFC 4517, June
+                 2006.
+
+   [Unicode]     The Unicode Consortium, "The Unicode Standard, Version
+                 3.2.0" is defined by "The Unicode Standard, Version
+                 3.0" (Reading, MA, Addison-Wesley, 2000.  ISBN 0-201-
+                 61633-5), as amended by the "Unicode Standard Annex
+                 #27: Unicode 3.1"
+                 (http://www.unicode.org/reports/tr27/) and by the
+                 "Unicode Standard Annex #28: Unicode 3.2"
+                 (http://www.unicode.org/reports/tr28/).
+
+   [UAX15]       Davis, M. and M. Duerst, "Unicode Standard Annex #15:
+                 Unicode Normalization Forms, Version 3.2.0".
+                 <http://www.unicode.org/unicode/reports/tr15/tr15-
+                 22.html>, March 2002.
+
+   [X.680]       International Telecommunication Union -
+                 Telecommunication Standardization Sector, "Abstract
+                 Syntax Notation One (ASN.1) - Specification of Basic
+                 Notation", X.680(2002) (also ISO/IEC 8824-1:2002).
+
+5.2.  Informative References
+
+   [X.500]       International Telecommunication Union -
+                 Telecommunication Standardization Sector, "The
+                 Directory -- Overview of concepts, models and
+                 services," X.500(1993) (also ISO/IEC 9594-1:1994).
+
+   [X.501]       International Telecommunication Union -
+                 Telecommunication Standardization Sector, "The
+                 Directory -- Models," X.501(1993) (also ISO/IEC 9594-
+                 2:1994).
+
+   [X.520]       International Telecommunication Union -
+                 Telecommunication Standardization Sector, "The
+                 Directory: Selected Attribute Types", X.520(1993) (also
+                 ISO/IEC 9594-6:1994).
+
+   [Glossary]    The Unicode Consortium, "Unicode Glossary",
+                 <http://www.unicode.org/glossary/>.
+
+   [CharModel]   Whistler, K. and M. Davis, "Unicode Technical Report
+                 #17, Character Encoding Model", UTR17,
+                 <http://www.unicode.org/unicode/reports/tr17/>, August
+                 2000.
+
+
+
+
+Zeilenga                    Standards Track                     [Page 9]
+
+RFC 4518       LDAP: Internationalized String Preparation      June 2006
+
+
+   [RFC3377]     Hodges, J. and R. Morgan, "Lightweight Directory Access
+                 Protocol (v3): Technical Specification", RFC 3377,
+                 September 2002.
+
+   [RFC4515]     Smith, M., Ed. and T. Howes, "Lightweight Directory
+                 Access Protocol (LDAP): String Representation of Search
+                 Filters", RFC 4515, June 2006.
+
+   [XMATCH]      Zeilenga, K., "Internationalized String Matching Rules
+                 for X.500", Work in Progress.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga                    Standards Track                    [Page 10]
+
+RFC 4518       LDAP: Internationalized String Preparation      June 2006
+
+
+Appendix A.  Combining Marks
+
+   This appendix is normative.
+
+   This table was derived from Unicode [Unicode] data files; it lists
+   all code points with the Mn, Mc, or Me properties.  This table is to
+   be considered definitive for the purposes of implementation of this
+   specification.
+
+         0300-034F 0360-036F 0483-0486 0488-0489 0591-05A1
+         05A3-05B9 05BB-05BC 05BF 05C1-05C2 05C4 064B-0655 0670
+         06D6-06DC 06DE-06E4 06E7-06E8 06EA-06ED 0711 0730-074A
+         07A6-07B0 0901-0903 093C 093E-094F 0951-0954 0962-0963
+         0981-0983 09BC 09BE-09C4 09C7-09C8 09CB-09CD 09D7
+         09E2-09E3 0A02 0A3C 0A3E-0A42 0A47-0A48 0A4B-0A4D
+         0A70-0A71 0A81-0A83 0ABC 0ABE-0AC5 0AC7-0AC9 0ACB-0ACD
+         0B01-0B03 0B3C 0B3E-0B43 0B47-0B48 0B4B-0B4D 0B56-0B57
+         0B82 0BBE-0BC2 0BC6-0BC8 0BCA-0BCD 0BD7 0C01-0C03
+         0C3E-0C44 0C46-0C48 0C4A-0C4D 0C55-0C56 0C82-0C83
+         0CBE-0CC4 0CC6-0CC8 0CCA-0CCD 0CD5-0CD6 0D02-0D03
+         0D3E-0D43 0D46-0D48 0D4A-0D4D 0D57 0D82-0D83 0DCA
+         0DCF-0DD4 0DD6 0DD8-0DDF 0DF2-0DF3 0E31 0E34-0E3A
+         0E47-0E4E 0EB1 0EB4-0EB9 0EBB-0EBC 0EC8-0ECD 0F18-0F19
+         0F35 0F37 0F39 0F3E-0F3F 0F71-0F84 0F86-0F87 0F90-0F97
+         0F99-0FBC 0FC6 102C-1032 1036-1039 1056-1059 1712-1714
+         1732-1734 1752-1753 1772-1773 17B4-17D3 180B-180D 18A9
+         20D0-20EA 302A-302F 3099-309A FB1E FE00-FE0F FE20-FE23
+         1D165-1D169 1D16D-1D172 1D17B-1D182 1D185-1D18B
+         1D1AA-1D1AD
+
+Appendix B.  Substrings Matching
+
+   This appendix is non-normative.
+
+   In the absence of substrings matching, the insignificant space
+   handling for case ignore/exact matching could be simplified.
+   Specifically, the handling could be to require that all sequences of
+   one or more spaces be replaced with one space and, if the string
+   contains non-space characters, removal of all leading spaces and
+   trailing spaces.
+
+   In the presence of substrings matching, this simplified space
+   handling would lead to unexpected and undesirable matching behavior.
+   For instance:
+
+   1) (CN=foo\20*\20bar) would match the CN value "foobar";
+
+
+
+
+
+Zeilenga                    Standards Track                    [Page 11]
+
+RFC 4518       LDAP: Internationalized String Preparation      June 2006
+
+
+   2) (CN=*\20foobar\20*) would match "foobar", but
+      (CN=*\20*foobar*\20*) would not.
+
+   Note to readers not familiar with LDAP substrings matching: the LDAP
+   filter [RFC4515] assertion (CN=A*B*C) says to "match any value (of
+   the attribute CN) that begins with A, contains B after A, ends with C
+   where C is also after B."
+
+   The first case illustrates that this simplified space handling would
+   cause leading and trailing spaces in substrings of the string to be
+   regarded as insignificant.  However, only leading and trailing (as
+   well as multiple consecutive spaces) of the string (as a whole) are
+   insignificant.
+
+   The second case illustrates that this simplified space handling would
+   cause sub-partitioning failures.  That is, if a prepared any
+   substring matches a partition of the attribute value, then an
+   assertion constructed by subdividing that substring into multiple
+   substrings should also match.
+
+   In designing an appropriate approach for space handling for
+   substrings matching, one must study key aspects of X.500 case
+   exact/ignore matching.  X.520 [X.520] says:
+
+      The [substrings] rule returns TRUE if there is a partitioning of
+      the attribute value (into portions) such that:
+
+         -  the specified substrings (initial, any, final) match
+            different portions of the value in the order of the strings
+            sequence;
+
+         -  initial, if present, matches the first portion of the value;
+
+         -  final, if present, matches the last portion of the value;
+
+         -  any, if present, matches some arbitrary portion of the
+            value.
+
+   That is, the substrings assertion (CN=foo\20*\20bar) matches the
+   attribute value "foo<SPACE><SPACE>bar" as the value can be
+   partitioned into the portions "foo<SPACE>" and "<SPACE>bar" meeting
+   the above requirements.
+
+
+
+
+
+
+
+
+
+Zeilenga                    Standards Track                    [Page 12]
+
+RFC 4518       LDAP: Internationalized String Preparation      June 2006
+
+
+   X.520 also says:
+
+      [T]he following spaces are regarded as not significant:
+
+         -  leading spaces (i.e., those preceding the first character
+            that is not a space);
+
+         -  trailing spaces (i.e., those following the last character
+            that is not a space);
+
+         -  multiple consecutive spaces (these are taken as equivalent
+            to a single space character).
+
+   This statement applies to the assertion values and attribute values
+   as whole strings, and not individually to substrings of an assertion
+   value.  In particular, the statements should be taken to mean that if
+   an assertion value and attribute value match without any
+   consideration to insignificant characters, then that assertion value
+   should also match any attribute value that differs only by inclusion
+   nor removal of insignificant characters.
+
+   Hence the assertion (CN=foo\20*\20bar) matches
+   "foo<SPACE><SPACE><SPACE>bar" and "foo<SPACE>bar" as these values
+   only differ from "foo<SPACE><SPACE>bar" by the inclusion or removal
+   of insignificant spaces.
+
+   Astute readers of this text will also note that there are special
+   cases where the specified space handling does not ignore spaces that
+   could be considered insignificant.  For instance, the assertion
+   (CN=\20*\20*\20) does not match "<SPACE><SPACE><SPACE>"
+   (insignificant spaces present in value) or " " (insignificant spaces
+   not present in value).  However, as these cases have no practical
+   application that cannot be met by simple assertions, e.g., (cn=\20),
+   and this minor anomaly can only be fully addressed by a preparation
+   algorithm to be used in conjunction with character-by-character
+   partitioning and matching, the anomaly is considered acceptable.
+
+Author's Address
+
+   Kurt D. Zeilenga
+   OpenLDAP Foundation
+
+   EMail: Kurt@OpenLDAP.org
+
+
+
+
+
+
+
+
+Zeilenga                    Standards Track                    [Page 13]
+
+RFC 4518       LDAP: Internationalized String Preparation      June 2006
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2006).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Zeilenga                    Standards Track                    [Page 14]
+
diff --git a/source4/ldap_server/devdocs/rfc4519.txt b/source4/ldap_server/devdocs/rfc4519.txt
new file mode 100644
index 0000000000..f2e9b7c4b6
--- /dev/null
+++ b/source4/ldap_server/devdocs/rfc4519.txt
@@ -0,0 +1,1963 @@
+
+
+
+
+
+
+Network Working Group                                  A. Sciberras, Ed.
+Request for Comments: 4519                                       eB2Bcom
+Obsoletes: 2256                                                June 2006
+Updates: 2247, 2798, 2377
+Category: Standards Track
+
+
+             Lightweight Directory Access Protocol (LDAP):
+                      Schema for User Applications
+
+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 is an integral part of the Lightweight Directory Access
+   Protocol (LDAP) technical specification.  It provides a technical
+   specification of attribute types and object classes intended for use
+   by LDAP directory clients for many directory services, such as White
+   Pages.  These objects are widely used as a basis for the schema in
+   many LDAP directories.  This document does not cover attributes used
+   for the administration of directory servers, nor does it include
+   directory objects defined for specific uses in other documents.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sciberras                   Standards Track                     [Page 1]
+
+RFC 4519           LDAP: Schema for User Applications          June 2006
+
+
+Table of Contents
+
+   1. Introduction ....................................................3
+      1.1. Relationship with Other Specifications .....................3
+      1.2. Conventions ................................................4
+      1.3. General Issues .............................................4
+   2. Attribute Types .................................................4
+      2.1. 'businessCategory' .........................................5
+      2.2. 'c' ........................................................5
+      2.3. 'cn' .......................................................5
+      2.4. 'dc' .......................................................6
+      2.5. 'description' ..............................................6
+      2.6. 'destinationIndicator' .....................................7
+      2.7. 'distinguishedName' ........................................7
+      2.8. 'dnQualifier' ..............................................8
+      2.9. 'enhancedSearchGuide' ......................................8
+      2.10. 'facsimileTelephoneNumber' ................................9
+      2.11. 'generationQualifier' .....................................9
+      2.12. 'givenName' ...............................................9
+      2.13. 'houseIdentifier' .........................................9
+      2.14. 'initials' ...............................................10
+      2.15. 'internationalISDNNumber' ................................10
+      2.16. 'l' ......................................................10
+      2.17. 'member' .................................................11
+      2.18. 'name' ...................................................11
+      2.19. 'o' ......................................................11
+      2.20. 'ou' .....................................................12
+      2.21. 'owner' ..................................................12
+      2.22. 'physicalDeliveryOfficeName' .............................12
+      2.23. 'postalAddress' ..........................................13
+      2.24. 'postalCode' .............................................13
+      2.25. 'postOfficeBox' ..........................................14
+      2.26. 'preferredDeliveryMethod' ................................14
+      2.27. 'registeredAddress' ......................................14
+      2.28. 'roleOccupant' ...........................................15
+      2.29. 'searchGuide' ............................................15
+      2.30. 'seeAlso' ................................................15
+      2.31. 'serialNumber' ...........................................16
+      2.32. 'sn' .....................................................16
+      2.33. 'st' .....................................................16
+      2.34. 'street' .................................................17
+      2.35. 'telephoneNumber' ........................................17
+      2.36. 'teletexTerminalIdentifier' ..............................17
+      2.37. 'telexNumber' ............................................18
+      2.38. 'title' ..................................................18
+      2.39. 'uid' ....................................................18
+      2.40. 'uniqueMember' ...........................................19
+      2.41. 'userPassword' ...........................................19
+
+
+
+Sciberras                   Standards Track                     [Page 2]
+
+RFC 4519           LDAP: Schema for User Applications          June 2006
+
+
+      2.42. 'x121Address' ............................................20
+      2.43. 'x500UniqueIdentifier' ...................................20
+   3. Object Classes .................................................20
+      3.1. 'applicationProcess' ......................................21
+      3.2. 'country' .................................................21
+      3.3. 'dcObject' ................................................21
+      3.4. 'device' ..................................................21
+      3.5. 'groupOfNames' ............................................22
+      3.6. 'groupOfUniqueNames' ......................................22
+      3.7. 'locality' ................................................23
+      3.8. 'organization' ............................................23
+      3.9. 'organizationalPerson' ....................................24
+      3.10. 'organizationalRole' .....................................24
+      3.11. 'organizationalUnit' .....................................24
+      3.12. 'person' .................................................25
+      3.13. 'residentialPerson' ......................................25
+      3.14. 'uidObject' ..............................................26
+   4. IANA Considerations ............................................26
+   5. Security Considerations ........................................28
+   6. Acknowledgements ...............................................28
+   7. References .....................................................29
+      7.1. Normative References ......................................29
+      7.2. Informative References ....................................30
+   Appendix A  Changes Made Since RFC 2256 ...........................32
+
+1.  Introduction
+
+   This document provides an overview of attribute types and object
+   classes intended for use by Lightweight Directory Access Protocol
+   (LDAP) directory clients for many directory services, such as White
+   Pages.  Originally specified in the X.500 [X.500] documents, these
+   objects are widely used as a basis for the schema in many LDAP
+   directories.  This document does not cover attributes used for the
+   administration of directory servers, nor does it include directory
+   objects defined for specific uses in other documents.
+
+1.1.  Relationship with Other Specifications
+
+   This document is an integral part of the LDAP technical specification
+   [RFC4510], which obsoletes the previously defined LDAP technical
+   specification, RFC 3377, in its entirety.  In terms of RFC 2256,
+   Sections 6 and 8 of RFC 2256 are obsoleted by [RFC4517].  Sections
+   5.1, 5.2, 7.1, and 7.2 of RFC 2256 are obsoleted by [RFC4512].  The
+   remainder of RFC 2256 is obsoleted by this document.  The technical
+   specification for the 'dc' attribute type and 'dcObject' object class
+   found in RFC 2247 are superseded by sections 2.4 and 3.3 of this
+   document.  The remainder of RFC 2247 remains in force.
+
+
+
+
+Sciberras                   Standards Track                     [Page 3]
+
+RFC 4519           LDAP: Schema for User Applications          June 2006
+
+
+   This document updates RFC 2798 by replacing the informative
+   description of the 'uid' attribute type with the definitive
+   description provided in Section 2.39 of this document.
+
+   This document updates RFC 2377 by replacing the informative
+   description of the 'uidObject' object class with the definitive
+   description provided in Section 3.14 of this document.
+
+   A number of schema elements that were included in the previous
+   revision of the LDAP Technical Specification are not included in this
+   revision of LDAP.  PKI-related schema elements are now specified in
+   [RFC4523].  Unless reintroduced in future technical specifications,
+   the remainder are to be considered Historic.
+
+   The descriptions in this document SHALL be considered definitive for
+   use in LDAP.
+
+1.2.  Conventions
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [RFC2119].
+
+1.3.  General Issues
+
+   This document references Syntaxes defined in Section 3 of [RFC4517]
+   and Matching Rules defined in Section 4 of [RFC4517].
+
+   The definitions of Attribute Types and Object Classes are written
+   using the Augmented Backus-Naur Form (ABNF) [RFC4234] of
+   AttributeTypeDescription and ObjectClassDescription given in
+   [RFC4512].  Lines have been folded for readability.  When such values
+   are transferred as attribute values in the LDAP Protocol, the values
+   will not contain line breaks.
+
+2.  Attribute Types
+
+   The attribute types contained in this section hold user information.
+
+   There is no requirement that servers implement the 'searchGuide' and
+   'teletexTerminalIdentifier' attribute types.  In fact, their use is
+   greatly discouraged.
+
+   An LDAP server implementation SHOULD recognize the rest of the
+   attribute types described in this section.
+
+
+
+
+
+
+Sciberras                   Standards Track                     [Page 4]
+
+RFC 4519           LDAP: Schema for User Applications          June 2006
+
+
+2.1.  'businessCategory'
+
+   The 'businessCategory' attribute type describes the kinds of business
+   performed by an organization.  Each kind is one value of this
+   multi-valued attribute.
+   (Source: X.520 [X.520])
+
+      ( 2.5.4.15 NAME 'businessCategory'
+         EQUALITY caseIgnoreMatch
+         SUBSTR caseIgnoreSubstringsMatch
+         SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+   1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax
+   [RFC4517].
+
+   Examples: "banking", "transportation", and "real estate".
+
+2.2.  'c'
+
+   The 'c' ('countryName' in X.500) attribute type contains a two-letter
+   ISO 3166 [ISO3166] country code.
+   (Source: X.520 [X.520])
+
+      ( 2.5.4.6 NAME 'c'
+         SUP name
+         SYNTAX 1.3.6.1.4.1.1466.115.121.1.11
+         SINGLE-VALUE )
+
+   1.3.6.1.4.1.1466.115.121.1.11 refers to the Country String syntax
+   [RFC4517].
+
+   Examples: "DE", "AU" and "FR".
+
+2.3.  'cn'
+
+   The 'cn' ('commonName' in X.500) attribute type contains names of an
+   object.  Each name is one value of this multi-valued attribute.  If
+   the object corresponds to a person, it is typically the person's full
+   name.
+   (Source: X.520 [X.520])
+
+      ( 2.5.4.3 NAME 'cn'
+         SUP name )
+
+   Examples: "Martin K Smith", "Marty Smith" and "printer12".
+
+
+
+
+
+
+Sciberras                   Standards Track                     [Page 5]
+
+RFC 4519           LDAP: Schema for User Applications          June 2006
+
+
+2.4.  'dc'
+
+   The 'dc' ('domainComponent' in RFC 1274) attribute type is a string
+   holding one component, a label, of a DNS domain name
+   [RFC1034][RFC2181] naming a host [RFC1123].  That is, a value of this
+   attribute is a string of ASCII characters adhering to the following
+   ABNF [RFC4234]:
+
+   label = (ALPHA / DIGIT) [*61(ALPHA / DIGIT / HYPHEN) (ALPHA / DIGIT)]
+   ALPHA   = %x41-5A / %x61-7A     ; "A"-"Z" / "a"-"z"
+   DIGIT   = %x30-39               ; "0"-"9"
+   HYPHEN  = %x2D                  ; hyphen ("-")
+
+   The encoding of IA5String for use in LDAP is simply the characters of
+   the ASCII label.  The equality matching rule is case insensitive, as
+   is today's DNS.  (Source: RFC 2247 [RFC2247] and RFC 1274 [RFC 1274])
+
+      ( 0.9.2342.19200300.100.1.25 NAME 'dc'
+         EQUALITY caseIgnoreIA5Match
+         SUBSTR caseIgnoreIA5SubstringsMatch
+         SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
+         SINGLE-VALUE )
+
+   1.3.6.1.4.1.1466.115.121.1.26 refers to the IA5 String syntax
+   [RFC4517].
+
+   Examples: Valid values include "example" and "com" but not
+   "example.com".  The latter is invalid as it contains multiple domain
+   components.
+
+   It is noted that the directory service will not ensure that values of
+   this attribute conform to the host label restrictions [RFC1123]
+   illustrated by the <label> production provided above.  It is the
+   directory client's responsibility to ensure that the labels it stores
+   in this attribute are appropriately restricted.
+
+   Directory applications supporting International Domain Names SHALL
+   use the ToASCII method [RFC3490] to produce the domain component
+   label.  The special considerations discussed in Section 4 of RFC 3490
+   [RFC3490] should be taken, depending on whether the domain component
+   is used for "stored" or "query" purposes.
+
+2.5.  'description'
+
+   The 'description' attribute type contains human-readable descriptive
+   phrases about the object.  Each description is one value of this
+   multi-valued attribute.
+   (Source: X.520 [X.520])
+
+
+
+Sciberras                   Standards Track                     [Page 6]
+
+RFC 4519           LDAP: Schema for User Applications          June 2006
+
+
+      ( 2.5.4.13 NAME 'description'
+         EQUALITY caseIgnoreMatch
+         SUBSTR caseIgnoreSubstringsMatch
+         SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+   1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax
+   [RFC4517].
+
+   Examples: "a color printer", "Maintenance is done every Monday, at
+             1pm.", and "distribution list for all technical staff".
+
+2.6.  'destinationIndicator'
+
+   The 'destinationIndicator' attribute type contains country and city
+   strings associated with the object (the addressee) needed to provide
+   the Public Telegram Service.  The strings are composed in accordance
+   with CCITT Recommendations F.1 [F.1] and F.31 [F.31].  Each string is
+   one value of this multi-valued attribute.
+   (Source: X.520 [X.520])
+
+      ( 2.5.4.27 NAME 'destinationIndicator'
+         EQUALITY caseIgnoreMatch
+         SUBSTR caseIgnoreSubstringsMatch
+         SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 )
+
+   1.3.6.1.4.1.1466.115.121.1.44 refers to the Printable String syntax
+   [RFC4517].
+
+   Examples: "AASD" as a destination indicator for Sydney, Australia.
+             "GBLD" as a destination indicator for London, United
+             Kingdom.
+
+   It is noted that the directory will not ensure that values of this
+   attribute conform to the F.1 and F.31 CCITT Recommendations.  It is
+   the application's responsibility to ensure destination indicators
+   that it stores in this attribute are appropriately constructed.
+
+2.7.  'distinguishedName'
+
+   The 'distinguishedName' attribute type is not used as the name of the
+   object itself, but it is instead a base type from which some user
+   attribute types with a DN syntax can inherit.
+
+   It is unlikely that values of this type itself will occur in an
+   entry.  LDAP server implementations that do not support attribute
+   subtyping need not recognize this attribute in requests.  Client
+   implementations MUST NOT assume that LDAP servers are capable of
+   performing attribute subtyping.
+
+
+
+Sciberras                   Standards Track                     [Page 7]
+
+RFC 4519           LDAP: Schema for User Applications          June 2006
+
+
+   (Source: X.520 [X.520])
+
+      ( 2.5.4.49 NAME 'distinguishedName'
+         EQUALITY distinguishedNameMatch
+         SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
+
+   1.3.6.1.4.1.1466.115.121.1.12 refers to the DN syntax [RFC4517].
+
+2.8.  'dnQualifier'
+
+   The 'dnQualifier' attribute type contains disambiguating information
+   strings to add to the relative distinguished name of an entry.  The
+   information is intended for use when merging data from multiple
+   sources in order to prevent conflicts between entries that would
+   otherwise have the same name.  Each string is one value of this
+   multi-valued attribute.  It is recommended that a value of the
+   'dnQualifier' attribute be the same for all entries from a particular
+   source.
+   (Source: X.520 [X.520])
+
+      ( 2.5.4.46 NAME 'dnQualifier'
+         EQUALITY caseIgnoreMatch
+         ORDERING caseIgnoreOrderingMatch
+         SUBSTR caseIgnoreSubstringsMatch
+         SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 )
+
+   1.3.6.1.4.1.1466.115.121.1.44 refers to the Printable String syntax
+   [RFC4517].
+
+   Examples: "20050322123345Z" - timestamps can be used to disambiguate
+             information.
+             "123456A" - serial numbers can be used to disambiguate
+             information.
+
+2.9.  'enhancedSearchGuide'
+
+   The 'enhancedSearchGuide' attribute type contains sets of information
+   for use by directory clients in constructing search filters.  Each
+   set is one value of this multi-valued attribute.
+   (Source: X.520 [X.520])
+
+      ( 2.5.4.47 NAME 'enhancedSearchGuide'
+         SYNTAX 1.3.6.1.4.1.1466.115.121.1.21 )
+
+   1.3.6.1.4.1.1466.115.121.1.21 refers to the Enhanced Guide syntax
+   [RFC4517].
+
+
+
+
+
+Sciberras                   Standards Track                     [Page 8]
+
+RFC 4519           LDAP: Schema for User Applications          June 2006
+
+
+   Examples: "person#(sn$APPROX)#wholeSubtree" and
+             "organizationalUnit#(ou$SUBSTR)#oneLevel".
+
+2.10.  'facsimileTelephoneNumber'
+
+   The 'facsimileTelephoneNumber' attribute type contains telephone
+   numbers (and, optionally, the parameters) for facsimile terminals.
+   Each telephone number is one value of this multi-valued attribute.
+   (Source: X.520 [X.520])
+
+      ( 2.5.4.23 NAME 'facsimileTelephoneNumber'
+         SYNTAX 1.3.6.1.4.1.1466.115.121.1.22 )
+
+   1.3.6.1.4.1.1466.115.121.1.22 refers to the Facsimile Telephone
+   Number syntax [RFC4517].
+
+   Examples: "+61 3 9896 7801" and "+81 3 347 7418$fineResolution".
+
+2.11.  'generationQualifier'
+
+   The 'generationQualifier' attribute type contains name strings that
+   are typically the suffix part of a person's name.  Each string is one
+   value of this multi-valued attribute.
+   (Source: X.520 [X.520])
+
+      ( 2.5.4.44 NAME 'generationQualifier'
+         SUP name )
+
+   Examples: "III", "3rd", and "Jr.".
+
+2.12.  'givenName'
+
+   The 'givenName' attribute type contains name strings that are the
+   part of a person's name that is not their surname.  Each string is
+   one value of this multi-valued attribute.
+   (Source: X.520 [X.520])
+
+      ( 2.5.4.42 NAME 'givenName'
+         SUP name )
+
+   Examples: "Andrew", "Charles", and "Joanne".
+
+2.13.  'houseIdentifier'
+
+   The 'houseIdentifier' attribute type contains identifiers for a
+   building within a location.  Each identifier is one value of this
+   multi-valued attribute.
+   (Source: X.520 [X.520])
+
+
+
+Sciberras                   Standards Track                     [Page 9]
+
+RFC 4519           LDAP: Schema for User Applications          June 2006
+
+
+      ( 2.5.4.51 NAME 'houseIdentifier'
+         EQUALITY caseIgnoreMatch
+         SUBSTR caseIgnoreSubstringsMatch
+         SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+   1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax
+   [RFC4517].
+
+   Example: "20" to represent the house number 20.
+
+2.14.  'initials'
+
+   The 'initials' attribute type contains strings of initials of some or
+   all of an individual's names, except the surname(s).  Each string is
+   one value of this multi-valued attribute.
+   (Source: X.520 [X.520])
+
+      ( 2.5.4.43 NAME 'initials'
+         SUP name )
+
+   Examples: "K. A." and "K".
+
+2.15.  'internationalISDNNumber'
+
+   The 'internationalISDNNumber' attribute type contains Integrated
+   Services Digital Network (ISDN) addresses, as defined in the
+   International Telecommunication Union (ITU) Recommendation E.164
+   [E.164].  Each address is one value of this multi-valued attribute.
+   (Source: X.520 [X.520])
+
+      ( 2.5.4.25 NAME 'internationalISDNNumber'
+         EQUALITY numericStringMatch
+         SUBSTR numericStringSubstringsMatch
+         SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 )
+
+   1.3.6.1.4.1.1466.115.121.1.36 refers to the Numeric String syntax
+   [RFC4517].
+
+   Example: "0198 333 333".
+
+2.16.  'l'
+
+   The 'l' ('localityName' in X.500) attribute type contains names of a
+   locality or place, such as a city, county, or other geographic
+   region.  Each name is one value of this multi-valued attribute.
+   (Source: X.520 [X.520])
+
+
+
+
+
+Sciberras                   Standards Track                    [Page 10]
+
+RFC 4519           LDAP: Schema for User Applications          June 2006
+
+
+      ( 2.5.4.7 NAME 'l'
+         SUP name )
+
+   Examples: "Geneva", "Paris", and "Edinburgh".
+
+2.17.  'member'
+
+   The 'member' attribute type contains the distinguished names of
+   objects that are on a list or in a group.  Each name is one value of
+   this multi-valued attribute.
+   (Source: X.520 [X.520])
+
+      ( 2.5.4.31 NAME 'member'
+         SUP distinguishedName )
+
+   Examples: "cn=James Clarke,ou=Finance,o=Widget\, Inc." and
+             "cn=John Xerri,ou=Finance,o=Widget\, Inc." may
+             be two members of the financial team (group) at Widget,
+             Inc., in which case, both of these distinguished names
+             would be present as individual values of the member
+             attribute.
+
+2.18.  'name'
+
+   The 'name' attribute type is the attribute supertype from which user
+   attribute types with the name syntax inherit.  Such attribute types
+   are typically used for naming.  The attribute type is multi-valued.
+
+   It is unlikely that values of this type itself will occur in an
+   entry.  LDAP server implementations that do not support attribute
+   subtyping need not recognize this attribute in requests.  Client
+   implementations MUST NOT assume that LDAP servers are capable of
+   performing attribute subtyping.
+   (Source: X.520 [X.520])
+
+      ( 2.5.4.41 NAME 'name'
+         EQUALITY caseIgnoreMatch
+         SUBSTR caseIgnoreSubstringsMatch
+         SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+   1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax
+   [RFC4517].
+
+2.19.  'o'
+
+   The 'o' ('organizationName' in X.500) attribute type contains the
+   names of an organization.  Each name is one value of this
+   multi-valued attribute.
+
+
+
+Sciberras                   Standards Track                    [Page 11]
+
+RFC 4519           LDAP: Schema for User Applications          June 2006
+
+
+   (Source: X.520 [X.520])
+
+      ( 2.5.4.10 NAME 'o'
+         SUP name )
+
+   Examples: "Widget", "Widget, Inc.", and "Widget, Incorporated.".
+
+2.20.  'ou'
+
+   The 'ou' ('organizationalUnitName' in X.500) attribute type contains
+   the names of an organizational unit.  Each name is one value of this
+   multi-valued attribute.
+   (Source: X.520 [X.520])
+
+      ( 2.5.4.11 NAME 'ou'
+         SUP name )
+
+   Examples: "Finance", "Human Resources", and "Research and
+             Development".
+
+2.21.  'owner'
+
+   The 'owner' attribute type contains the distinguished names of
+   objects that have an ownership responsibility for the object that is
+   owned.  Each owner's name is one value of this multi-valued
+   attribute.
+   (Source: X.520 [X.520])
+
+      ( 2.5.4.32 NAME 'owner'
+         SUP distinguishedName )
+
+   Example: The mailing list object, whose DN is "cn=All Employees,
+            ou=Mailing List,o=Widget\, Inc.", is owned by the Human
+            Resources Director.
+
+            Therefore, the value of the 'owner' attribute within the
+            mailing list object, would be the DN of the director (role):
+            "cn=Human Resources Director,ou=employee,o=Widget\, Inc.".
+
+2.22.  'physicalDeliveryOfficeName'
+
+   The 'physicalDeliveryOfficeName' attribute type contains names that a
+   Postal Service uses to identify a post office.
+   (Source: X.520 [X.520])
+
+
+
+
+
+
+
+Sciberras                   Standards Track                    [Page 12]
+
+RFC 4519           LDAP: Schema for User Applications          June 2006
+
+
+      ( 2.5.4.19 NAME 'physicalDeliveryOfficeName'
+         EQUALITY caseIgnoreMatch
+         SUBSTR caseIgnoreSubstringsMatch
+         SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+   1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax
+   [RFC4517].
+
+   Examples: "Bremerhaven, Main" and "Bremerhaven, Bonnstrasse".
+
+2.23.  'postalAddress'
+
+   The 'postalAddress' attribute type contains addresses used by a
+   Postal Service to perform services for the object.  Each address is
+   one value of this multi-valued attribute.
+   (Source: X.520 [X.520])
+
+      ( 2.5.4.16 NAME 'postalAddress'
+         EQUALITY caseIgnoreListMatch
+         SUBSTR caseIgnoreListSubstringsMatch
+         SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 )
+
+   1.3.6.1.4.1.1466.115.121.1.41 refers to the Postal Address syntax
+   [RFC4517].
+
+   Example: "15 Main St.$Ottawa$Canada".
+
+2.24.  'postalCode'
+
+   The 'postalCode' attribute type contains codes used by a Postal
+   Service to identify postal service zones.  Each code is one value of
+   this multi-valued attribute.
+   (Source: X.520 [X.520])
+
+      ( 2.5.4.17 NAME 'postalCode'
+         EQUALITY caseIgnoreMatch
+         SUBSTR caseIgnoreSubstringsMatch
+         SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+   1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax
+   [RFC4517].
+
+   Example: "22180", to identify Vienna, VA, in the USA.
+
+
+
+
+
+
+
+
+Sciberras                   Standards Track                    [Page 13]
+
+RFC 4519           LDAP: Schema for User Applications          June 2006
+
+
+2.25.  'postOfficeBox'
+
+   The 'postOfficeBox' attribute type contains postal box identifiers
+   that a Postal Service uses when a customer arranges to receive mail
+   at a box on the premises of the Postal Service.  Each postal box
+   identifier is a single value of this multi-valued attribute.
+   (Source: X.520 [X.520])
+
+      ( 2.5.4.18 NAME 'postOfficeBox'
+         EQUALITY caseIgnoreMatch
+         SUBSTR caseIgnoreSubstringsMatch
+         SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+   1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax
+   [RFC4517].
+
+   Example: "Box 45".
+
+2.26.  'preferredDeliveryMethod'
+
+   The 'preferredDeliveryMethod' attribute type contains an indication
+   of the preferred method of getting a message to the object.
+   (Source: X.520 [X.520])
+
+      ( 2.5.4.28 NAME 'preferredDeliveryMethod'
+         SYNTAX 1.3.6.1.4.1.1466.115.121.1.14
+         SINGLE-VALUE )
+
+   1.3.6.1.4.1.1466.115.121.1.14 refers to the Delivery Method syntax
+   [RFC4517].
+
+   Example: If the mhs-delivery Delivery Method is preferred over
+            telephone-delivery, which is preferred over all other
+            methods, the value would be: "mhs $ telephone".
+
+2.27.  'registeredAddress'
+
+   The 'registeredAddress' attribute type contains postal addresses
+   suitable for reception of telegrams or expedited documents, where it
+   is necessary to have the recipient accept delivery.  Each address is
+   one value of this multi-valued attribute.
+   (Source: X.520 [X.520])
+
+      ( 2.5.4.26 NAME 'registeredAddress'
+         SUP postalAddress
+         SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 )
+
+
+
+
+
+Sciberras                   Standards Track                    [Page 14]
+
+RFC 4519           LDAP: Schema for User Applications          June 2006
+
+
+   1.3.6.1.4.1.1466.115.121.1.41 refers to the Postal Address syntax
+   [RFC4517].
+
+   Example: "Receptionist$Widget, Inc.$15 Main St.$Ottawa$Canada".
+
+2.28.  'roleOccupant'
+
+   The 'roleOccupant' attribute type contains the distinguished names of
+   objects (normally people) that fulfill the responsibilities of a role
+   object.  Each distinguished name is one value of this multi-valued
+   attribute.
+   (Source: X.520 [X.520])
+
+      ( 2.5.4.33 NAME 'roleOccupant'
+         SUP distinguishedName )
+
+   Example: The role object, "cn=Human Resources
+            Director,ou=Position,o=Widget\, Inc.", is fulfilled by two
+            people whose object names are "cn=Mary
+            Smith,ou=employee,o=Widget\, Inc." and "cn=James
+            Brown,ou=employee,o=Widget\, Inc.".  The 'roleOccupant'
+            attribute will contain both of these distinguished names,
+            since they are the occupants of this role.
+
+2.29.  'searchGuide'
+
+   The 'searchGuide' attribute type contains sets of information for use
+   by clients in constructing search filters.  It is superseded by
+   'enhancedSearchGuide', described above in Section 2.9.  Each set is
+   one value of this multi-valued attribute.
+   (Source: X.520 [X.520])
+
+      ( 2.5.4.14 NAME 'searchGuide'
+         SYNTAX 1.3.6.1.4.1.1466.115.121.1.25 )
+
+   1.3.6.1.4.1.1466.115.121.1.25 refers to the Guide syntax [RFC4517].
+
+   Example: "person#sn$EQ".
+
+2.30.  'seeAlso'
+
+   The 'seeAlso' attribute type contains the distinguished names of
+   objects that are related to the subject object.  Each related object
+   name is one value of this multi-valued attribute.
+   (Source: X.520 [X.520])
+
+      ( 2.5.4.34 NAME 'seeAlso'
+         SUP distinguishedName )
+
+
+
+Sciberras                   Standards Track                    [Page 15]
+
+RFC 4519           LDAP: Schema for User Applications          June 2006
+
+
+   Example: The person object "cn=James Brown,ou=employee,o=Widget\,
+            Inc." is related to the role objects "cn=Football Team
+            Captain,ou=sponsored activities,o=Widget\, Inc." and
+            "cn=Chess Team,ou=sponsored activities,o=Widget\, Inc.".
+            Since the role objects are related to the person object, the
+            'seeAlso' attribute will contain the distinguished name of
+            each role object as separate values.
+
+2.31.  'serialNumber'
+
+   The 'serialNumber' attribute type contains the serial numbers of
+   devices.  Each serial number is one value of this multi-valued
+   attribute.
+   (Source: X.520 [X.520])
+
+      ( 2.5.4.5 NAME 'serialNumber'
+         EQUALITY caseIgnoreMatch
+         SUBSTR caseIgnoreSubstringsMatch
+         SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 )
+
+   1.3.6.1.4.1.1466.115.121.1.44 refers to the Printable String syntax
+   [RFC4517].
+
+   Examples: "WI-3005" and "XF551426".
+
+2.32.  'sn'
+
+   The 'sn' ('surname' in X.500) attribute type contains name strings
+   for the family names of a person.  Each string is one value of this
+   multi-valued attribute.
+   (Source: X.520 [X.520])
+
+      ( 2.5.4.4 NAME 'sn'
+         SUP name )
+
+   Example: "Smith".
+
+2.33.  'st'
+
+   The 'st' ('stateOrProvinceName' in X.500) attribute type contains the
+   full names of states or provinces.  Each name is one value of this
+   multi-valued attribute.
+   (Source: X.520 [X.520])
+
+      ( 2.5.4.8 NAME 'st'
+         SUP name )
+
+   Example: "California".
+
+
+
+Sciberras                   Standards Track                    [Page 16]
+
+RFC 4519           LDAP: Schema for User Applications          June 2006
+
+
+2.34.  'street'
+
+   The 'street' ('streetAddress' in X.500) attribute type contains site
+   information from a postal address (i.e., the street name, place,
+   avenue, and the house number).  Each street is one value of this
+   multi-valued attribute.
+   (Source: X.520 [X.520])
+
+      ( 2.5.4.9 NAME 'street'
+         EQUALITY caseIgnoreMatch
+         SUBSTR caseIgnoreSubstringsMatch
+         SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+   1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax
+   [RFC4517].
+
+   Example: "15 Main St.".
+
+2.35.  'telephoneNumber'
+
+   The 'telephoneNumber' attribute type contains telephone numbers that
+   comply with the ITU Recommendation E.123 [E.123].  Each number is one
+   value of this multi-valued attribute.
+   (Source: X.520 [X.520])
+
+      ( 2.5.4.20 NAME 'telephoneNumber'
+         EQUALITY telephoneNumberMatch
+         SUBSTR telephoneNumberSubstringsMatch
+         SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 )
+
+   1.3.6.1.4.1.1466.115.121.1.50 refers to the Telephone Number syntax
+   [RFC4517].
+
+   Example: "+1 234 567 8901".
+
+2.36.  'teletexTerminalIdentifier'
+
+   The withdrawal of Recommendation F.200 has resulted in the withdrawal
+   of this attribute.
+   (Source: X.520 [X.520])
+
+      ( 2.5.4.22 NAME 'teletexTerminalIdentifier'
+         SYNTAX 1.3.6.1.4.1.1466.115.121.1.51 )
+
+   1.3.6.1.4.1.1466.115.121.1.51 refers to the Teletex Terminal
+   Identifier syntax [RFC4517].
+
+
+
+
+
+Sciberras                   Standards Track                    [Page 17]
+
+RFC 4519           LDAP: Schema for User Applications          June 2006
+
+
+2.37.  'telexNumber'
+
+   The 'telexNumber' attribute type contains sets of strings that are a
+   telex number, country code, and answerback code of a telex terminal.
+   Each set is one value of this multi-valued attribute.
+   (Source: X.520 [X.520])
+
+      ( 2.5.4.21 NAME 'telexNumber'
+         SYNTAX 1.3.6.1.4.1.1466.115.121.1.52 )
+
+   1.3.6.1.4.1.1466.115.121.1.52 refers to the Telex Number syntax
+   [RFC4517].
+
+   Example: "12345$023$ABCDE".
+
+2.38.  'title'
+
+   The 'title' attribute type contains the title of a person in their
+   organizational context.  Each title is one value of this multi-valued
+   attribute.
+   (Source: X.520 [X.520])
+
+      ( 2.5.4.12 NAME 'title'
+         SUP name )
+   Examples: "Vice President", "Software Engineer", and "CEO".
+
+2.39.  'uid'
+
+   The 'uid' ('userid' in RFC 1274) attribute type contains computer
+   system login names associated with the object.  Each name is one
+   value of this multi-valued attribute.
+   (Source: RFC 2798 [RFC2798] and RFC 1274 [RFC1274])
+
+      ( 0.9.2342.19200300.100.1.1 NAME 'uid'
+         EQUALITY caseIgnoreMatch
+         SUBSTR caseIgnoreSubstringsMatch
+         SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+   1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax
+   [RFC4517].
+
+   Examples: "s9709015", "admin", and "Administrator".
+
+
+
+
+
+
+
+
+
+Sciberras                   Standards Track                    [Page 18]
+
+RFC 4519           LDAP: Schema for User Applications          June 2006
+
+
+2.40.  'uniqueMember'
+
+   The 'uniqueMember' attribute type contains the distinguished names of
+   an object that is on a list or in a group, where the relative
+   distinguished names of the object include a value that distinguishes
+   between objects when a distinguished name has been reused.  Each
+   distinguished name is one value of this multi-valued attribute.
+   (Source: X.520 [X.520])
+
+      ( 2.5.4.50 NAME 'uniqueMember'
+         EQUALITY uniqueMemberMatch
+         SYNTAX 1.3.6.1.4.1.1466.115.121.1.34 )
+
+   1.3.6.1.4.1.1466.115.121.1.34 refers to the Name and Optional UID
+   syntax [RFC4517].
+
+   Example: If "ou=1st Battalion,o=Defense,c=US" is a battalion that was
+            disbanded, establishing a new battalion with the "same" name
+            would have a unique identifier value added, resulting in
+            "ou=1st Battalion, o=Defense,c=US#'010101'B".
+
+2.41.  'userPassword'
+
+   The 'userPassword' attribute contains octet strings that are known
+   only to the user and the system to which the user has access.  Each
+   string is one value of this multi-valued attribute.
+
+   The application SHOULD prepare textual strings used as passwords by
+   transcoding them to Unicode, applying SASLprep [RFC4013], and
+   encoding as UTF-8.  The determination of whether a password is
+   textual is a local client matter.
+   (Source: X.509 [X.509])
+
+      ( 2.5.4.35 NAME 'userPassword'
+         EQUALITY octetStringMatch
+         SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )
+
+   1.3.6.1.4.1.1466.115.121.1.40 refers to the Octet String syntax
+   [RFC4517].
+
+   Passwords are stored using an Octet String syntax and are not
+   encrypted.  Transfer of cleartext passwords is strongly discouraged
+   where the underlying transport service cannot guarantee
+   confidentiality and may result in disclosure of the password to
+   unauthorized parties.
+
+   An example of a need for multiple values in the 'userPassword'
+   attribute is an environment where every month the user is expected to
+
+
+
+Sciberras                   Standards Track                    [Page 19]
+
+RFC 4519           LDAP: Schema for User Applications          June 2006
+
+
+   use a different password generated by some automated system.  During
+   transitional periods, like the last and first day of the periods, it
+   may be necessary to allow two passwords for the two consecutive
+   periods to be valid in the system.
+
+2.42.  'x121Address'
+
+   The 'x121Address' attribute type contains data network addresses as
+   defined by ITU Recommendation X.121 [X.121].  Each address is one
+   value of this multi-valued attribute.
+   (Source: X.520 [X.520])
+
+      ( 2.5.4.24 NAME 'x121Address'
+         EQUALITY numericStringMatch
+         SUBSTR numericStringSubstringsMatch
+         SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 )
+
+   1.3.6.1.4.1.1466.115.121.1.36 refers to the Numeric String syntax
+   [RFC4517].
+
+   Example: "36111222333444555".
+
+2.43.  'x500UniqueIdentifier'
+
+   The 'x500UniqueIdentifier' attribute type contains binary strings
+   that are used to distinguish between objects when a distinguished
+   name has been reused.  Each string is one value of this multi-valued
+   attribute.
+
+   In X.520 [X.520], this attribute type is called 'uniqueIdentifier'.
+   This is a different attribute type from both the 'uid' and
+   'uniqueIdentifier' LDAP attribute types.  The 'uniqueIdentifier'
+   attribute type is defined in [RFC4524].
+   (Source: X.520 [X.520])
+
+      ( 2.5.4.45 NAME 'x500UniqueIdentifier'
+         EQUALITY bitStringMatch
+         SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 )
+
+   1.3.6.1.4.1.1466.115.121.1.6 refers to the Bit String syntax
+   [RFC4517].
+
+3.  Object Classes
+
+   LDAP servers SHOULD recognize all the Object Classes listed here as
+   values of the 'objectClass' attribute (see [RFC4512]).
+
+
+
+
+
+Sciberras                   Standards Track                    [Page 20]
+
+RFC 4519           LDAP: Schema for User Applications          June 2006
+
+
+3.1.  'applicationProcess'
+
+   The 'applicationProcess' object class definition is the basis of an
+   entry that represents an application executing in a computer system.
+   (Source: X.521 [X.521])
+
+      ( 2.5.6.11 NAME 'applicationProcess'
+         SUP top
+         STRUCTURAL
+         MUST cn
+         MAY ( seeAlso $
+               ou $
+               l $
+               description ) )
+
+3.2.  'country'
+
+   The 'country' object class definition is the basis of an entry that
+   represents a country.
+   (Source: X.521 [X.521])
+
+      ( 2.5.6.2 NAME 'country'
+         SUP top
+         STRUCTURAL
+         MUST c
+         MAY ( searchGuide $
+               description ) )
+
+3.3.  'dcObject'
+
+   The 'dcObject' object class permits an entry to contains domain
+   component information.  This object class is defined as auxiliary,
+   because it will be used in conjunction with an existing structural
+   object class.
+   (Source: RFC 2247 [RFC2247])
+
+      ( 1.3.6.1.4.1.1466.344 NAME 'dcObject'
+         SUP top
+         AUXILIARY
+         MUST dc )
+
+3.4.  'device'
+
+   The 'device' object class is the basis of an entry that represents an
+   appliance, computer, or network element.
+   (Source: X.521 [X.521])
+
+
+
+
+
+Sciberras                   Standards Track                    [Page 21]
+
+RFC 4519           LDAP: Schema for User Applications          June 2006
+
+
+      ( 2.5.6.14 NAME 'device'
+         SUP top
+         STRUCTURAL
+         MUST cn
+         MAY ( serialNumber $
+               seeAlso $
+               owner $
+               ou $
+               o $
+               l $
+               description ) )
+
+3.5.  'groupOfNames'
+
+   The 'groupOfNames' object class is the basis of an entry that
+   represents a set of named objects including information related to
+   the purpose or maintenance of the set.
+   (Source: X.521 [X.521])
+
+      ( 2.5.6.9 NAME 'groupOfNames'
+         SUP top
+         STRUCTURAL
+         MUST ( member $
+               cn )
+         MAY ( businessCategory $
+               seeAlso $
+               owner $
+               ou $
+               o $
+               description ) )
+
+3.6.  'groupOfUniqueNames'
+
+   The 'groupOfUniqueNames' object class is the same as the
+   'groupOfNames' object class except that the object names are not
+   repeated or reassigned within a set scope.
+   (Source: X.521 [X.521])
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sciberras                   Standards Track                    [Page 22]
+
+RFC 4519           LDAP: Schema for User Applications          June 2006
+
+
+      ( 2.5.6.17 NAME 'groupOfUniqueNames'
+         SUP top
+         STRUCTURAL
+         MUST ( uniqueMember $
+               cn )
+         MAY ( businessCategory $
+               seeAlso $
+               owner $
+               ou $
+               o $
+               description ) )
+
+3.7.  'locality'
+
+   The 'locality' object class is the basis of an entry that represents
+   a place in the physical world.
+   (Source: X.521 [X.521])
+
+      ( 2.5.6.3 NAME 'locality'
+         SUP top
+         STRUCTURAL
+         MAY ( street $
+               seeAlso $
+               searchGuide $
+               st $
+               l $
+               description ) )
+
+3.8.  'organization'
+
+   The 'organization' object class is the basis of an entry that
+   represents a structured group of people.
+   (Source: X.521 [X.521])
+
+      ( 2.5.6.4 NAME 'organization'
+         SUP top
+         STRUCTURAL
+         MUST o
+         MAY ( userPassword $ searchGuide $ seeAlso $
+               businessCategory $ x121Address $ registeredAddress $
+               destinationIndicator $ preferredDeliveryMethod $
+               telexNumber $ teletexTerminalIdentifier $
+               telephoneNumber $ internationalISDNNumber $
+               facsimileTelephoneNumber $ street $ postOfficeBox $
+               postalCode $ postalAddress $ physicalDeliveryOfficeName $
+               st $ l $ description ) )
+
+
+
+
+
+Sciberras                   Standards Track                    [Page 23]
+
+RFC 4519           LDAP: Schema for User Applications          June 2006
+
+
+3.9.  'organizationalPerson'
+
+   The 'organizationalPerson' object class is the basis of an entry that
+   represents a person in relation to an organization.
+   (Source: X.521 [X.521])
+
+      ( 2.5.6.7 NAME 'organizationalPerson'
+         SUP person
+         STRUCTURAL
+         MAY ( title $ x121Address $ registeredAddress $
+               destinationIndicator $ preferredDeliveryMethod $
+               telexNumber $ teletexTerminalIdentifier $
+               telephoneNumber $ internationalISDNNumber $
+               facsimileTelephoneNumber $ street $ postOfficeBox $
+               postalCode $ postalAddress $ physicalDeliveryOfficeName $
+               ou $ st $ l ) )
+
+3.10.  'organizationalRole'
+
+   The 'organizationalRole' object class is the basis of an entry that
+   represents a job, function, or position in an organization.
+   (Source: X.521 [X.521])
+
+      ( 2.5.6.8 NAME 'organizationalRole'
+         SUP top
+         STRUCTURAL
+         MUST cn
+         MAY ( x121Address $ registeredAddress $ destinationIndicator $
+               preferredDeliveryMethod $ telexNumber $
+               teletexTerminalIdentifier $ telephoneNumber $
+               internationalISDNNumber $ facsimileTelephoneNumber $
+               seeAlso $ roleOccupant $ preferredDeliveryMethod $
+               street $ postOfficeBox $ postalCode $ postalAddress $
+               physicalDeliveryOfficeName $ ou $ st $ l $
+               description ) )
+
+3.11.  'organizationalUnit'
+
+   The 'organizationalUnit' object class is the basis of an entry that
+   represents a piece of an organization.
+   (Source: X.521 [X.521])
+
+
+
+
+
+
+
+
+
+
+Sciberras                   Standards Track                    [Page 24]
+
+RFC 4519           LDAP: Schema for User Applications          June 2006
+
+
+      ( 2.5.6.5 NAME 'organizationalUnit'
+         SUP top
+         STRUCTURAL
+         MUST ou
+         MAY ( businessCategory $ description $ destinationIndicator $
+               facsimileTelephoneNumber $ internationalISDNNumber $ l $
+               physicalDeliveryOfficeName $ postalAddress $ postalCode $
+               postOfficeBox $ preferredDeliveryMethod $
+               registeredAddress $ searchGuide $ seeAlso $ st $ street $
+               telephoneNumber $ teletexTerminalIdentifier $
+               telexNumber $ userPassword $ x121Address ) )
+
+3.12  'person'
+
+   The 'person' object class is the basis of an entry that represents a
+   human being.
+   (Source: X.521 [X.521])
+
+      ( 2.5.6.6 NAME 'person'
+         SUP top
+         STRUCTURAL
+         MUST ( sn $
+               cn )
+         MAY ( userPassword $
+               telephoneNumber $
+               seeAlso $ description ) )
+
+3.13.  'residentialPerson'
+
+   The 'residentialPerson' object class is the basis of an entry that
+   includes a person's residence in the representation of the person.
+   (Source: X.521 [X.521])
+
+      ( 2.5.6.10 NAME 'residentialPerson'
+         SUP person
+         STRUCTURAL
+         MUST l
+         MAY ( businessCategory $ x121Address $ registeredAddress $
+               destinationIndicator $ preferredDeliveryMethod $
+               telexNumber $ teletexTerminalIdentifier $
+               telephoneNumber $ internationalISDNNumber $
+               facsimileTelephoneNumber $ preferredDeliveryMethod $
+               street $ postOfficeBox $ postalCode $ postalAddress $
+               physicalDeliveryOfficeName $ st $ l ) )
+
+
+
+
+
+
+
+Sciberras                   Standards Track                    [Page 25]
+
+RFC 4519           LDAP: Schema for User Applications          June 2006
+
+
+3.14.  'uidObject'
+
+   The 'uidObject' object class permits an entry to contains user
+   identification information.  This object class is defined as
+   auxiliary, because it will be used in conjunction with an existing
+   structural object class.
+   (Source: RFC 2377 [RFC2377])
+
+      ( 1.3.6.1.1.3.1 NAME 'uidObject'
+         SUP top
+         AUXILIARY
+         MUST uid )
+
+4.  IANA Considerations
+
+   The Internet Assigned Numbers Authority (IANA) has updated the LDAP
+   descriptors registry as indicated in the following template:
+
+      Subject: Request for LDAP Descriptor Registration Update
+      Descriptor (short name): see comments
+      Object Identifier: see comments
+      Person & email address to contact for further information:
+         Andrew Sciberras <andrew.sciberras@eb2bcom.com>
+      Usage: (A = attribute type, O = Object Class) see comment
+      Specification: RFC 4519
+      Author/Change Controller: IESG
+
+   Comments
+
+      In the LDAP descriptors registry, the following descriptors (short
+      names) have been updated to refer to RFC 4519.  Names that need to
+      be reserved, rather than assigned to an Object Identifier, will
+      contain an Object Identifier value of RESERVED.
+
+      NAME                         Type OID
+      ------------------------     ---- ----------------------------
+      applicationProcess           O    2.5.6.11
+      businessCategory             A    2.5.4.15
+      c                            A    2.5.4.6
+      cn                           A    2.5.4.3
+      commonName                   A    2.5.4.3
+      country                      O    2.5.6.2
+      countryName                  A    2.5.4.6
+      dc                           A    0.9.2342.19200300.100.1.25
+      dcObject                     O    1.3.6.1.4.1.1466.344
+      description                  A    2.5.4.13
+      destinationIndicator         A    2.5.4.27
+      device                       O    2.5.6.14
+
+
+
+Sciberras                   Standards Track                    [Page 26]
+
+RFC 4519           LDAP: Schema for User Applications          June 2006
+
+
+      NAME                         Type OID
+      ------------------------     ---- ----------------------------
+      distinguishedName            A    2.5.4.49
+      dnQualifier                  A    2.5.4.46
+      domainComponent              A    0.9.2342.19200300.100.1.25
+      enhancedSearchGuide          A    2.5.4.47
+      facsimileTelephoneNumber     A    2.5.4.23
+      generationQualifier          A    2.5.4.44
+      givenName                    A    2.5.4.42
+      gn                           A    RESERVED
+      groupOfNames                 O    2.5.6.9
+      groupOfUniqueNames           O    2.5.6.17
+      houseIdentifier              A    2.5.4.51
+      initials                     A    2.5.4.43
+      internationalISDNNumber      A    2.5.4.25
+      l                            A    2.5.4.7
+      locality                     O    2.5.6.3
+      localityName                 A    2.5.4.7
+      member                       A    2.5.4.31
+      name                         A    2.5.4.41
+      o                            A    2.5.4.10
+      organization                 O    2.5.6.4
+      organizationName             A    2.5.4.10
+      organizationalPerson         O    2.5.6.7
+      organizationalRole           O    2.5.6.8
+      organizationalUnit           O    2.5.6.5
+      organizationalUnitName       A    2.5.4.11
+      ou                           A    2.5.4.11
+      owner                        A    2.5.4.32
+      person                       O    2.5.6.6
+      physicalDeliveryOfficeName   A    2.5.4.19
+      postalAddress                A    2.5.4.16
+      postalCode                   A    2.5.4.17
+      postOfficeBox                A    2.5.4.18
+      preferredDeliveryMethod      A    2.5.4.28
+      registeredAddress            A    2.5.4.26
+      residentialPerson            O    2.5.6.10
+      roleOccupant                 A    2.5.4.33
+      searchGuide                  A    2.5.4.14
+      seeAlso                      A    2.5.4.34
+      serialNumber                 A    2.5.4.5
+      sn                           A    2.5.4.4
+      st                           A    2.5.4.8
+      street                       A    2.5.4.9
+      surname                      A    2.5.4.4
+      telephoneNumber              A    2.5.4.20
+      teletexTerminalIdentifier    A    2.5.4.22
+      telexNumber                  A    2.5.4.21
+
+
+
+Sciberras                   Standards Track                    [Page 27]
+
+RFC 4519           LDAP: Schema for User Applications          June 2006
+
+
+      NAME                         Type OID
+      ------------------------     ---- ----------------------------
+      title                        A    2.5.4.12
+      uid                          A    0.9.2342.19200300.100.1.1
+      uidObject                    O    1.3.6.1.1.3.1
+      uniqueMember                 A    2.5.4.50
+      userid                       A    0.9.2342.19200300.100.1.1
+      userPassword                 A    2.5.4.35
+      x121Address                  A    2.5.4.24
+      x500UniqueIdentifier         A    2.5.4.45
+
+5.  Security Considerations
+
+   Attributes of directory entries are used to provide descriptive
+   information about the real-world objects they represent, which can be
+   people, organizations, or devices.  Most countries have privacy laws
+   regarding the publication of information about people.
+
+   Transfer of cleartext passwords is strongly discouraged where the
+   underlying transport service cannot guarantee confidentiality and
+   integrity, since this may result in disclosure of the password to
+   unauthorized parties.
+
+   Multiple attribute values for the 'userPassword' attribute need to be
+   used with care.  Especially reset/deletion of a password by an
+   administrator without knowing the old user password gets tricky or
+   impossible if multiple values for different applications are present.
+
+   Certainly, applications that intend to replace the 'userPassword'
+   value(s) with new value(s) should use modify/replaceValues (or
+   modify/deleteAttribute+addAttribute).  In addition, server
+   implementations are encouraged to provide administrative controls
+   that, if enabled, restrict the 'userPassword' attribute to one value.
+
+   Note that when used for authentication purposes [RFC4513], the user
+   need only prove knowledge of one of the values, not all of the
+   values.
+
+6.  Acknowledgements
+
+   The definitions, on which this document is based, have been developed
+   by committees for telecommunications and international standards.
+
+   This document is an update of RFC 2256 by Mark Wahl.  RFC 2256 was a
+   product of the IETF ASID Working Group.
+
+
+
+
+
+
+Sciberras                   Standards Track                    [Page 28]
+
+RFC 4519           LDAP: Schema for User Applications          June 2006
+
+
+   The 'dc' attribute type definition and the 'dcObject' object class
+   definition in this document supersede the specification in RFC 2247
+   by S. Kille, M. Wahl, A. Grimstad, R. Huber, and S. Sataluri.
+
+   The 'uid' attribute type definition in this document supersedes the
+   specification of the 'userid' in RFC 1274 by P. Barker and S. Kille
+   and of the uid in RFC 2798 by M. Smith.
+
+   The 'uidObject' object class definition in this document supersedes
+   the specification of the 'uidObject' in RFC 2377 by A. Grimstad, R.
+   Huber, S. Sataluri, and M. Wahl.
+
+   This document is based upon input of the IETF LDAPBIS working group.
+   The author wishes to thank S. Legg and K. Zeilenga for their
+   significant contribution to this update.  The author would also like
+   to thank Kathy Dally, who edited early versions of this document.
+
+7.  References
+
+7.1.  Normative References
+
+   [E.123]    Notation for national and international telephone numbers,
+              ITU-T Recommendation E.123, 1988
+
+   [E.164]    The international public telecommunication numbering plan,
+              ITU-T Recommendation E.164, 1997
+
+   [F.1]      Operational Provisions For The International Public
+              Telegram Service Transmission System, CCITT Recommendation
+              F.1, 1992
+
+   [F.31]     Telegram Retransmission System, CCITT Recommendation F.31,
+              1988
+
+   [ISO3166]  ISO 3166, "Codes for the representation of names of
+              countries".
+
+   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
+              STD 13, RFC 1034, November 1987.
+
+   [RFC1123]  Braden, R., "Requirements for Internet Hosts - Application
+              and Support", STD 3, RFC 1123, October 1989.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2181]  Elz, R. and R. Bush, "Clarifications to the DNS
+              Specification", RFC 2181, July 1997.
+
+
+
+Sciberras                   Standards Track                    [Page 29]
+
+RFC 4519           LDAP: Schema for User Applications          June 2006
+
+
+   [RFC3490]  Faltstrom, P., Hoffman, P., and A. Costello,
+              "Internationalizing Domain Names in Applications (IDNA)",
+              RFC 3490, March 2003.
+
+   [RFC4013]  Zeilenga, K., "SASLprep: Stringprep Profile for User Names
+              and Passwords", RFC 4013, February 2005.
+
+   [RFC4234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
+              Specifications: ABNF", RFC 4234, October 2005.
+
+   [RFC4510]  Zeilenga, K., Ed., "Lightweight Directory Access Protocol
+              (LDAP): Technical Specification Road Map", RFC 4510, June
+              2006.
+
+   [RFC4512]  Zeilenga, K., "Lightweight Directory Access Protocol
+              (LDAP): Directory Information Models", RFC 4512, June
+              2006.
+
+   [RFC4517]  Legg, S., Ed., "Lightweight Directory Access Protocol
+              (LDAP): Syntaxes and Matching Rules", RFC 4517, June 2006.
+
+   [X.121]    International numbering plan for public data networks,
+              ITU-T Recommendation X.121, 1996
+
+   [X.509]    The Directory:  Authentication Framework, ITU-T
+              Recommendation X.509, 1993
+
+   [X.520]    The Directory: Selected Attribute Types, ITU-T
+              Recommendation X.520, 1993
+
+   [X.521]    The Directory: Selected Object Classes.  ITU-T
+              Recommendation X.521, 1993
+
+7.2.  Informative References
+
+   [RFC1274]  Barker, P. and S. Kille, "The COSINE and Internet X.500
+              Schema", RFC 1274, November 1991.
+
+   [RFC2247]  Kille, S., Wahl, M., Grimstad, A., Huber, R., and S.
+              Sataluri, "Using Domains in LDAP/X.500 Distinguished
+              Names", RFC 2247, January 1998.
+
+   [RFC2377]  Grimstad, A., Huber, R., Sataluri, S., and M. Wahl,
+              "Naming Plan for Internet Directory-Enabled Applications",
+              RFC 2377, September 1998.
+
+   [RFC2798]  Smith, M., "Definition of the inetOrgPerson LDAP Object
+              Class", RFC 2798, April 2000.
+
+
+
+Sciberras                   Standards Track                    [Page 30]
+
+RFC 4519           LDAP: Schema for User Applications          June 2006
+
+
+   [RFC4513]  Harrison R., Ed., "Lightweight Directory Access Protocol
+              (LDAP): Authentication Methods and Security Mechanisms",
+              RFC 4513, June 2006.
+
+   [RFC4523]  Zeilenga, K., "Lightweight Directory Access Protocol
+              (LDAP) Schema Definitions for X.509 Certificates", RFC
+              4523, June 2006.
+
+   [RFC4524]  Zeilenga, E., Ed., "COSINE LDAP/X.500 Schema", RFC 4524,
+              June 2006.
+
+   [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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sciberras                   Standards Track                    [Page 31]
+
+RFC 4519           LDAP: Schema for User Applications          June 2006
+
+
+Appendix A.  Changes Made Since RFC 2256
+
+   This appendix lists the changes that have been made from RFC 2256 to
+   RFC 4519.
+
+   This appendix is not a normative part of this specification, which
+   has been provided for informational purposes only.
+
+      1.  Replaced the document title.
+
+      2.  Removed the IESG Note.
+
+      3.  Dependencies on RFC 1274 have been eliminated.
+
+      4.  Added a Security Considerations section and an IANA
+          Considerations section.
+
+      5.  Deleted the conformance requirement for subschema object
+          classes in favor of a statement in [RFC4517].
+
+      6.  Added explanation to attribute types and to each object class.
+
+      7.  Removed Section 4, Syntaxes, and Section 6, Matching Rules,
+          (moved to [RFC4517]).
+
+      8.  Removed the certificate-related attribute types:
+          authorityRevocationList, cACertificate,
+          certificateRevocationList, crossCertificatePair,
+          deltaRevocationList, supportedAlgorithms, and userCertificate.
+
+          Removed the certificate-related Object Classes:
+          certificationAuthority, certificationAuthority-V2,
+          cRLDistributionPoint, strongAuthenticationUser, and
+          userSecurityInformation
+
+          LDAP PKI is now discussed in [RFC4523].
+
+      9.  Removed the dmdName, knowledgeInformation,
+          presentationAddress, protocolInformation, and
+          supportedApplicationContext attribute types and the dmd,
+          applicationEntity, and dSA object classes.
+
+      10. Deleted the aliasedObjectName and objectClass attribute type
+          definitions.  Deleted the alias and top object class
+          definitions.  They are included in [RFC4512].
+
+
+
+
+
+
+Sciberras                   Standards Track                    [Page 32]
+
+RFC 4519           LDAP: Schema for User Applications          June 2006
+
+
+      11. Added the 'dc' attribute type from RFC 2247, making the
+          distinction between 'stored' and 'query' values when preparing
+          IDN strings.
+
+      12. Numerous editorial changes.
+
+      13. Removed upper bound after the SYNTAX oid in all attribute
+          definitions where it appeared.
+
+      14. Added text about Unicode, SASLprep [RFC4013], and UTF-8 for
+          userPassword.
+
+      15. Included definitions, comments and references for 'dcObject'
+          and 'uidObject'.
+
+      16. Replaced PKI schema references to use RFC 4523.
+
+      17. Spelt out and referenced ABNF on first usage.
+
+      18. Removed Section 2.4 (Source).  Replaced the source table with
+          explicit references for each definition.
+
+      19. All references to an attribute type or object class are
+          enclosed in single quotes.
+
+      20. The layout of attribute type definitions has been changed to
+          provide consistency throughout the document:
+          > Section Heading
+          > Description of Attribute type
+          > Multivalued description
+          > Source Information
+          > Definition
+          > Example
+          > Additional Comments
+
+          Adding this consistent output included the addition of
+          examples to some definitions.
+
+      21. References to alternate names for attributes types are
+          provided with a reference to where they were originally
+          specified.
+
+      22. Clarification of the description of 'distinguishedName' and
+          'name', in regards to these attribute types being supertypes.
+
+      23. Spelt out ISDN on first usage.
+
+
+
+
+
+Sciberras                   Standards Track                    [Page 33]
+
+RFC 4519           LDAP: Schema for User Applications          June 2006
+
+
+      24. Inserted a reference to [RFC4517] for the
+          'teletexTerminalIdentifier' definition's SYNTAX OID.
+
+      25. Additional names were added to the IANA Considerations.  Names
+          include 'commonName', 'dcObject', 'domainComponent', 'GN',
+          'localityName', 'organizationName', 'organizationUnitName',
+          'surname', 'uidObject' and 'userid'.
+
+      26. Renamed all instances of supercede to supersede.
+
+      27. Moved [F.1], [F.31] and [RFC4013] from informative to
+          normative references.
+
+      28. Changed the 'c' definition to be consistent with X.500.
+
+Author's Address
+
+   Andrew Sciberras
+   eB2Bcom
+   Suite 3, Woodhouse Corporate Centre,
+   935 Station Street,
+   Box Hill North, Victoria 3129
+   AUSTRALIA
+
+   Phone: +61 3 9896 7833
+   EMail: andrew.sciberras@eb2bcom.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sciberras                   Standards Track                    [Page 34]
+
+RFC 4519           LDAP: Schema for User Applications          June 2006
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2006).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Sciberras                   Standards Track                    [Page 35]
+
diff --git a/source4/ldap_server/devdocs/rfc4520.txt b/source4/ldap_server/devdocs/rfc4520.txt
new file mode 100644
index 0000000000..9ef5daadea
--- /dev/null
+++ b/source4/ldap_server/devdocs/rfc4520.txt
@@ -0,0 +1,1067 @@
+
+
+
+
+
+
+Network Working Group                                        K. Zeilenga
+Request for Comments: 4520                           OpenLDAP Foundation
+BCP: 64                                                        June 2006
+Obsoletes: 3383
+Category: Best Current Practice
+
+
+     Internet Assigned Numbers Authority (IANA) Considerations for
+            the Lightweight Directory Access Protocol (LDAP)
+
+Status of This Memo
+
+   This document specifies an Internet Best Current Practices for the
+   Internet Community, and requests discussion and suggestions for
+   improvements.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   This document provides procedures for registering extensible elements
+   of the Lightweight Directory Access Protocol (LDAP).  The document
+   also provides guidelines to the Internet Assigned Numbers Authority
+   (IANA) describing conditions under which new values can be assigned.
+
+1.  Introduction
+
+   The Lightweight Directory Access Protocol [RFC4510] (LDAP) is an
+   extensible protocol.  LDAP supports:
+
+      -  the addition of new operations,
+      -  the extension of existing operations, and
+      -  the extensible schema.
+
+   This document details procedures for registering values used to
+   unambiguously identify extensible elements of the protocol, including
+   the following:
+
+      - LDAP message types
+      - LDAP extended operations and controls
+      - LDAP result codes
+      - LDAP authentication methods
+      - LDAP attribute description options
+      - Object Identifier descriptors
+
+
+
+
+
+Zeilenga                 Best Current Practice                  [Page 1]
+
+RFC 4520              IANA Considerations for LDAP             June 2006
+
+
+   These registries are maintained by the Internet Assigned Numbers
+   Authority (IANA).
+
+   In addition, this document provides guidelines to IANA describing the
+   conditions under which new values can be assigned.
+
+   This document replaces RFC 3383.
+
+2.  Terminology and Conventions
+
+   This section details terms and conventions used in this document.
+
+2.1.  Policy Terminology
+
+   The terms "IESG Approval", "Standards Action", "IETF Consensus",
+   "Specification Required", "First Come First Served", "Expert Review",
+   and "Private Use" are used as defined in BCP 26 [RFC2434].
+
+   The term "registration owner" (or "owner") refers to the party
+   authorized to change a value's registration.
+
+2.2.  Requirement Terminology
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in BCP 14 [RFC2119].  In
+   this case, "the specification", as used by BCP 14, refers to the
+   processing of protocols being submitted to the IETF standards
+   process.
+
+2.3.  Common ABNF Productions
+
+   A number of syntaxes in this document are described using ABNF
+   [RFC4234].  These syntaxes rely on the following common productions:
+
+         ALPHA = %x41-5A / %x61-7A    ; "A"-"Z" / "a"-"z"
+         LDIGIT = %x31-39             ; "1"-"9"
+         DIGIT = %x30 / LDIGIT        ; "0"-"9"
+         HYPHEN = %x2D                ; "-"
+         DOT = %x2E                   ; "."
+         number = DIGIT / ( LDIGIT 1*DIGIT )
+         keychar = ALPHA / DIGIT / HYPHEN
+         leadkeychar = ALPHA
+         keystring = leadkeychar *keychar
+         keyword = keystring
+
+   Keywords are case insensitive.
+
+
+
+
+Zeilenga                 Best Current Practice                  [Page 2]
+
+RFC 4520              IANA Considerations for LDAP             June 2006
+
+
+3.  IANA Considerations for LDAP
+
+   This section details each kind of protocol value that can be
+   registered and provides IANA guidelines on how to assign new values.
+
+   IANA may reject obviously bogus registrations.
+
+   LDAP values specified in RFCs MUST be registered.  Other LDAP values,
+   except those in private-use name spaces, SHOULD be registered.  RFCs
+   SHOULD NOT reference, use, or otherwise recognize unregistered LDAP
+   values.
+
+3.1.  Object Identifiers
+
+   Numerous LDAP schema and protocol elements are identified by Object
+   Identifiers (OIDs) [X.680].  Specifications that assign OIDs to
+   elements SHOULD state who delegated the OIDs for their use.
+
+   For IETF-developed elements, specifications SHOULD use OIDs under
+   "Internet Directory Numbers" (1.3.6.1.1.x).  For elements developed
+   by others, any properly delegated OID can be used, including those
+   under "Internet Directory Numbers" (1.3.6.1.1.x) or "Internet Private
+   Enterprise Numbers" (1.3.6.1.4.1.x).
+
+   Internet Directory Numbers (1.3.6.1.1.x) will be assigned upon Expert
+   Review with Specification Required.  Only one OID per specification
+   will be assigned.  The specification MAY then assign any number of
+   OIDs within this arc without further coordination with IANA.
+
+   Internet Private Enterprise Numbers (1.3.6.1.4.1.x) are assigned by
+   IANA <http://www.iana.org/cgi-bin/enterprise.pl>.  Practices for IANA
+   assignment of Internet Private Enterprise Numbers are detailed in RFC
+   2578 [RFC2578].
+
+   To avoid interoperability problems between early implementations of a
+   "work in progress" and implementations of the published specification
+   (e.g., the RFC), experimental OIDs SHOULD be used in "works in
+   progress" and early implementations.  OIDs under the Internet
+   Experimental OID arc (1.3.6.1.3.x) may be used for this purpose.
+   Practices for IANA assignment of these Internet Experimental numbers
+   are detailed in RFC 2578 [RFC2578].
+
+3.2.  Protocol Mechanisms
+
+   LDAP provides a number of Root DSA-Specific Entry (DSE) attributes
+   for discovery of protocol mechanisms identified by OIDs, including
+   the supportedControl, supportedExtension, and supportedFeatures
+   attributes [RFC4512].
+
+
+
+Zeilenga                 Best Current Practice                  [Page 3]
+
+RFC 4520              IANA Considerations for LDAP             June 2006
+
+
+   A registry of OIDs used for discovery of protocol mechanisms is
+   provided to allow implementors and others to locate the technical
+   specification for these protocol mechanisms.  Future specifications
+   of additional Root DSE attributes holding values identifying protocol
+   mechanisms MAY extend this registry for their values.
+
+   Protocol mechanisms are registered on a First Come First Served
+   basis.
+
+3.3.  LDAP Syntaxes
+
+   This registry provides a listing of LDAP syntaxes [RFC4512].  Each
+   LDAP syntax is identified by an OID.  This registry is provided to
+   allow implementors and others to locate the technical specification
+   describing a particular LDAP Syntax.
+
+   LDAP Syntaxes are registered on a First Come First Served with
+   Specification Required basis.
+
+   Note: Unlike object classes, attribute types, and various other kinds
+         of schema elements, descriptors are not used in LDAP to
+         identify LDAP Syntaxes.
+
+3.4.  Object Identifier Descriptors
+
+   LDAP allows short descriptive names (or descriptors) to be used
+   instead of a numeric Object Identifier to identify select protocol
+   extensions [RFC4511], schema elements [RFC4512], LDAP URL [RFC4516]
+   extensions, and other objects.
+
+   Although the protocol allows the same descriptor to refer to
+   different object identifiers in certain cases and the registry
+   supports multiple registrations of the same descriptor (each
+   indicating a different kind of schema element and different object
+   identifier), multiple registrations of the same descriptor are to be
+   avoided.  All such multiple registration requests require Expert
+   Review.
+
+   Descriptors are restricted to strings of UTF-8 [RFC3629] encoded
+   Unicode characters restricted by the following ABNF:
+
+      name = keystring
+
+   Descriptors are case insensitive.
+
+   Multiple names may be assigned to a given OID.  For purposes of
+   registration, an OID is to be represented in numeric OID form (e.g.,
+   1.1.0.23.40) conforming to the following ABNF:
+
+
+
+Zeilenga                 Best Current Practice                  [Page 4]
+
+RFC 4520              IANA Considerations for LDAP             June 2006
+
+
+      numericoid = number 1*( DOT number )
+
+   While the protocol places no maximum length restriction upon
+   descriptors, they should be short.  Descriptors longer than 48
+   characters may be viewed as too long to register.
+
+   A value ending with a hyphen ("-") reserves all descriptors that
+   start with that value.  For example, the registration of the option
+   "descrFamily-" reserves all options that start with "descrFamily-"
+   for some related purpose.
+
+   Descriptors beginning with "x-" are for Private Use and cannot be
+   registered.
+
+   Descriptors beginning with "e-" are reserved for experiments and will
+   be registered on a First Come First Served basis.
+
+   All other descriptors require Expert Review to be registered.
+
+   The registrant need not "own" the OID being named.
+
+   The OID name space is managed by the ISO/IEC Joint Technical
+   Committee 1 - Subcommittee 6.
+
+3.5.  AttributeDescription Options
+
+   An AttributeDescription [RFC4512] can contain zero or more options
+   specifying additional semantics.  An option SHALL be restricted to a
+   string of UTF-8 encoded Unicode characters limited by the following
+   ABNF:
+
+      option = keystring
+
+   Options are case insensitive.
+
+   While the protocol places no maximum length restriction upon option
+   strings, they should be short.  Options longer than 24 characters may
+   be viewed as too long to register.
+
+   Values ending with a hyphen ("-") reserve all option names that start
+   with the name.  For example, the registration of the option
+   "optionFamily-" reserves all options that start with "optionFamily-"
+   for some related purpose.
+
+   Options beginning with "x-" are for Private Use and cannot be
+   registered.
+
+
+
+
+
+Zeilenga                 Best Current Practice                  [Page 5]
+
+RFC 4520              IANA Considerations for LDAP             June 2006
+
+
+   Options beginning with "e-" are reserved for experiments and will be
+   registered on a First Come First Served basis.
+
+   All other options require Standards Action or Expert Review with
+   Specification Required to be registered.
+
+3.6.  LDAP Message Types
+
+   Each protocol message is encapsulated in an LDAPMessage envelope
+   [RFC4511.  The protocolOp CHOICE indicates the type of message
+   encapsulated.  Each message type consists of an ASN.1 identifier in
+   the form of a keyword and a non-negative choice number.  The choice
+   number is combined with the class (APPLICATION) and data type
+   (CONSTRUCTED or PRIMITIVE) to construct the BER tag in the message's
+   encoding.  The choice numbers for existing protocol messages are
+   implicit in the protocol's ASN.1 defined in [RFC4511].
+
+   New values will be registered upon Standards Action.
+
+   Note: LDAP provides extensible messages that reduce but do not
+         eliminate the need to add new message types.
+
+3.7.  LDAP Authentication Method
+
+   The LDAP Bind operation supports multiple authentication methods
+   [RFC4511].  Each authentication choice consists of an ASN.1
+   identifier in the form of a keyword and a non-negative integer.
+
+   The registrant SHALL classify the authentication method usage using
+   one of the following terms:
+
+         COMMON      - method is appropriate for common use on the
+                       Internet.
+         LIMITED USE - method is appropriate for limited use.
+         OBSOLETE    - method has been deprecated or otherwise found to
+                       be inappropriate for any use.
+
+   Methods without publicly available specifications SHALL NOT be
+   classified as COMMON.  New registrations of the class OBSOLETE cannot
+   be registered.
+
+   New authentication method integers in the range 0-1023 require
+   Standards Action to be registered.  New authentication method
+   integers in the range 1024-4095 require Expert Review with
+   Specification Required.  New authentication method integers in the
+   range 4096-16383 will be registered on a First Come First Served
+   basis.  Keywords associated with integers in the range 0-4095 SHALL
+   NOT start with "e-" or "x-".  Keywords associated with integers in
+
+
+
+Zeilenga                 Best Current Practice                  [Page 6]
+
+RFC 4520              IANA Considerations for LDAP             June 2006
+
+
+   the range 4096-16383 SHALL start with "e-".  Values greater than or
+   equal to 16384 and keywords starting with "x-" are for Private Use
+   and cannot be registered.
+
+   Note: LDAP supports Simple Authentication and Security Layers
+         [RFC4422] as an authentication choice.  SASL is an extensible
+         authentication framework.
+
+3.8.  LDAP Result Codes
+
+   LDAP result messages carry a resultCode enumerated value to indicate
+   the outcome of the operation [RFC4511].  Each result code consists of
+   an ASN.1 identifier in the form of a keyword and a non-negative
+   integer.
+
+   New resultCodes integers in the range 0-1023 require Standards Action
+   to be registered.  New resultCode integers in the range 1024-4095
+   require Expert Review with Specification Required.  New resultCode
+   integers in the range 4096-16383 will be registered on a First Come
+   First Served basis.  Keywords associated with integers in the range
+   0-4095 SHALL NOT start with "e-" or "x-".  Keywords associated with
+   integers in the range 4096-16383 SHALL start with "e-".  Values
+   greater than or equal to 16384 and keywords starting with "x-" are
+   for Private Use and cannot be registered.
+
+3.9.  LDAP Search Scope
+
+   LDAP SearchRequest messages carry a scope-enumerated value to
+   indicate the extent of search within the DIT [RFC4511].  Each search
+   value consists of an ASN.1 identifier in the form of a keyword and a
+   non-negative integer.
+
+   New scope integers in the range 0-1023 require Standards Action to be
+   registered.  New scope integers in the range 1024-4095 require Expert
+   Review with Specification Required.  New scope integers in the range
+   4096-16383 will be registered on a First Come First Served basis.
+   Keywords associated with integers in the range 0-4095 SHALL NOT start
+   with "e-" or "x-".  Keywords associated with integers in the range
+   4096-16383 SHALL start with "e-".  Values greater than or equal to
+   16384 and keywords starting with "x-" are for Private Use and cannot
+   be registered.
+
+3.10.  LDAP Filter Choice
+
+   LDAP filters are used in making assertions against an object
+   represented in the directory [RFC4511].  The Filter CHOICE indicates
+   a type of assertion.  Each Filter CHOICE consists of an ASN.1
+   identifier in the form of a keyword and a non-negative choice number.
+
+
+
+Zeilenga                 Best Current Practice                  [Page 7]
+
+RFC 4520              IANA Considerations for LDAP             June 2006
+
+
+   The choice number is combined with the class (APPLICATION) and data
+   type (CONSTRUCTED or PRIMITIVE) to construct the BER tag in the
+   message's encoding.
+
+   Note: LDAP provides the extensibleMatching choice, which reduces but
+         does not eliminate the need to add new filter choices.
+
+3.11.  LDAP ModifyRequest Operation Type
+
+   The LDAP ModifyRequest carries a sequence of modification operations
+   [RFC4511].  Each kind (e.g., add, delete, replace) of operation
+   consists of an ASN.1 identifier in the form of a keyword and a non-
+   negative integer.
+
+   New operation type integers in the range 0-1023 require Standards
+   Action to be registered.  New operation type integers in the range
+   1024-4095 require Expert Review with Specification Required.  New
+   operation type integers in the range 4096-16383 will be registered on
+   a First Come First Served basis.  Keywords associated with integers
+   in the range 0-4095 SHALL NOT start with "e-" or "x-".  Keywords
+   associated with integers in the range 4096-16383 SHALL start with
+   "e-".  Values greater than or equal to 16384 and keywords starting
+   with "x-" are for Private Use and cannot be registered.
+
+3.12.  LDAP authzId Prefixes
+
+   Authorization Identities in LDAP are strings conforming to the
+   <authzId> production [RFC4513].  This production is extensible.  Each
+   new specific authorization form is identified by a prefix string
+   conforming to the following ABNF:
+
+         prefix = keystring COLON
+         COLON = %x3A ; COLON (":" U+003A)
+
+   Prefixes are case insensitive.
+
+   While the protocol places no maximum length restriction upon prefix
+   strings, they should be short.  Prefixes longer than 12 characters
+   may be viewed as too long to register.
+
+   Prefixes beginning with "x-" are for Private Use and cannot be
+   registered.
+
+   Prefixes beginning with "e-" are reserved for experiments and will be
+   registered on a First Come First Served basis.
+
+   All other prefixes require Standards Action or Expert Review with
+   Specification Required to be registered.
+
+
+
+Zeilenga                 Best Current Practice                  [Page 8]
+
+RFC 4520              IANA Considerations for LDAP             June 2006
+
+
+3.13.  Directory Systems Names
+
+   The IANA-maintained "Directory Systems Names" registry [IANADSN] of
+   valid keywords for well-known attributes was used in the LDAPv2
+   string representation of a distinguished name [RFC1779].  LDAPv2 is
+   now Historic [RFC3494].
+
+   Directory systems names are not known to be used in any other
+   context.  LDAPv3 [RFC4514] uses Object Identifier Descriptors
+   [Section 3.2] (which have a different syntax than directory system
+   names).
+
+   New Directory System Names will no longer be accepted.  For
+   historical purposes, the current list of registered names should
+   remain publicly available.
+
+4.  Registration Procedure
+
+   The procedure given here MUST be used by anyone who wishes to use a
+   new value of a type described in Section 3 of this document.
+
+   The first step is for the requester to fill out the appropriate form.
+   Templates are provided in Appendix A.
+
+   If the policy is Standards Action, the completed form SHOULD be
+   provided to the IESG with the request for Standards Action.  Upon
+   approval of the Standards Action, the IESG SHALL forward the request
+   (possibly revised) to IANA.  The IESG SHALL be regarded as the
+   registration owner of all values requiring Standards Action.
+
+   If the policy is Expert Review, the requester SHALL post the
+   completed form to the <directory@apps.ietf.org> mailing list for
+   public review.  The review period is two (2) weeks.  If a revised
+   form is later submitted, the review period is restarted.  Anyone may
+   subscribe to this list by sending a request to <directory-
+   request@apps.ietf.org>.  During the review, objections may be raised
+   by anyone (including the Expert) on the list.  After completion of
+   the review, the Expert, based on public comments, SHALL either
+   approve the request and forward it to the IANA OR deny the request.
+   In either case, the Expert SHALL promptly notify the requester of the
+   action.  Actions of the Expert may be appealed [RFC2026].  The Expert
+   is appointed by Applications Area Directors.  The requester is viewed
+   as the registration owner of values registered under Expert Review.
+
+   If the policy is First Come First Served, the requester SHALL submit
+   the completed form directly to the IANA: <iana@iana.org>.  The
+   requester is viewed as the registration owner of values registered
+   under First Come First Served.
+
+
+
+Zeilenga                 Best Current Practice                  [Page 9]
+
+RFC 4520              IANA Considerations for LDAP             June 2006
+
+
+   Neither the Expert nor IANA will take position on the claims of
+   copyright or trademark issues regarding completed forms.
+
+   Prior to submission of the Internet Draft (I-D) to the RFC Editor but
+   after IESG review and tentative approval, the document editor SHOULD
+   revise the I-D to use registered values.
+
+5.  Registration Maintenance
+
+   This section discusses maintenance of registrations.
+
+5.1.  Lists of Registered Values
+
+   IANA makes lists of registered values readily available to the
+   Internet community on its web site: <http://www.iana.org/>.
+
+5.2.  Change Control
+
+   The registration owner MAY update the registration subject to the
+   same constraints and review as with new registrations.  In cases
+   where the registration owner is unable or is unwilling to make
+   necessary updates, the IESG MAY assume ownership of the registration
+   in order to update the registration.
+
+5.3.  Comments
+
+   For cases where others (anyone other than the registration owner)
+   have significant objections to the claims in a registration and the
+   registration owner does not agree to change the registration,
+   comments MAY be attached to a registration upon Expert Review.  For
+   registrations owned by the IESG, the objections SHOULD be addressed
+   by initiating a request for Expert Review.
+
+   The form of these requests is ad hoc, but MUST include the specific
+   objections to be reviewed and SHOULD contain (directly or by
+   reference) materials supporting the objections.
+
+6.  Security Considerations
+
+   The security considerations detailed in BCP 26 [RFC2434] are
+   generally applicable to this document.  Additional security
+   considerations specific to each name space are discussed in Section
+   3, where appropriate.
+
+   Security considerations for LDAP are discussed in documents
+   comprising the technical specification [RFC4510].
+
+
+
+
+
+Zeilenga                 Best Current Practice                 [Page 10]
+
+RFC 4520              IANA Considerations for LDAP             June 2006
+
+
+7.  Acknowledgement
+
+   This document is a product of the IETF LDAP Revision (LDAPBIS)
+   Working Group (WG).  This document is a revision of RFC 3383, also a
+   product of the LDAPBIS WG.
+
+   This document includes text borrowed from "Guidelines for Writing an
+   IANA Considerations Section in RFCs" [RFC2434] by Thomas Narten and
+   Harald Alvestrand.
+
+8.  References
+
+8.1.  Normative References
+
+   [RFC2026]  Bradner, S., "The Internet Standards Process -- Revision
+              3", BCP 9, RFC 2026, October 1996.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2434]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
+              IANA Considerations Section in RFCs", BCP 26, RFC 2434,
+              October 1998.
+
+   [RFC2578]  McCloghrie, K., Perkins, D., and J. Schoenwaelder,
+              "Structure of Management Information Version 2 (SMIv2)",
+              STD 58, RFC 2578, April 1999.
+
+   [RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO
+              10646", STD 63, RFC 3629, November 2003.
+
+   [RFC4234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
+              Specifications: ABNF", RFC 4234, October 2005.
+
+   [RFC4510]  Zeilenga, K., Ed., "Lightweight Directory Access Protocol
+              (LDAP): Technical Specification Road Map", RFC 4510, June
+              2006.
+
+   [RFC4511]  Sermersheim, J., Ed., "Lightweight Directory Access
+              Protocol (LDAP): The Protocol", RFC 4511, June 2006.
+
+   [RFC4512]  Zeilenga, K., "Lightweight Directory Access Protocol
+              (LDAP): Directory Information Models", RFC 4512, June
+              2006.
+
+   [RFC4513]  Harrison, R., Ed., "Lightweight Directory Access Protocol
+              (LDAP): Authentication Methods and Security Mechanisms",
+              RFC 4513, June 2006.
+
+
+
+Zeilenga                 Best Current Practice                 [Page 11]
+
+RFC 4520              IANA Considerations for LDAP             June 2006
+
+
+   [RFC4516]  Smith, M., Ed. and T. Howes, "Lightweight Directory Access
+              Protocol (LDAP): Uniform Resource Locator", RFC 4516, June
+              2006.
+
+   [Unicode]  The Unicode Consortium, "The Unicode Standard, Version
+              3.2.0" is defined by "The Unicode Standard, Version 3.0"
+              (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5),
+              as amended by the "Unicode Standard Annex #27: Unicode
+              3.1" (http://www.unicode.org/reports/tr27/) and by the
+              "Unicode Standard Annex #28: Unicode 3.2"
+              (http://www.unicode.org/reports/tr28/).
+
+   [X.680]    International Telecommunication Union - Telecommunication
+              Standardization Sector, "Abstract Syntax Notation One
+              (ASN.1) - Specification of Basic Notation", X.680(2002)
+              (also ISO/IEC 8824-1:2002).
+
+8.2.  Informative References
+
+   [RFC1779]  Kille, S., "A String Representation of Distinguished
+              Names", RFC 1779, March 1995.
+
+   [RFC3494]  Zeilenga, K.,"Lightweight Directory Access Protocol
+              version 2 (LDAPv2) to Historic Status", RFC 3494, March
+              2003.
+
+   [RFC4514]  Zeilenga, K., Ed., "Lightweight Directory Access Protocol
+              (LDAP): String Representation of Distinguished Names", RFC
+              4514, June 2006.
+
+   [RFC4422]  Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple
+              Authentication and Security Layer (SASL)", RFC 4422, June
+              2006.
+
+   [IANADSN]  IANA, "Directory Systems Names",
+              http://www.iana.org/assignments/directory-system-names.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga                 Best Current Practice                 [Page 12]
+
+RFC 4520              IANA Considerations for LDAP             June 2006
+
+
+Appendix A.  Registration Templates
+
+   This appendix provides registration templates for registering new
+   LDAP values.  Note that more than one value may be requested by
+   extending the template by listing multiple values, or through use of
+   tables.
+
+A.1.  LDAP Object Identifier Registration Template
+
+   Subject: Request for LDAP OID Registration
+
+   Person & email address to contact for further information:
+
+   Specification: (I-D)
+
+   Author/Change Controller:
+
+   Comments:
+
+   (Any comments that the requester deems relevant to the request.)
+
+A.2.  LDAP Protocol Mechanism Registration Template
+
+   Subject: Request for LDAP Protocol Mechanism Registration
+
+   Object Identifier:
+
+   Description:
+
+   Person & email address to contact for further information:
+
+   Usage: (One of Control or Extension or Feature or other)
+
+   Specification: (RFC, I-D, URI)
+
+   Author/Change Controller:
+
+   Comments:
+
+   (Any comments that the requester deems relevant to the request.)
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga                 Best Current Practice                 [Page 13]
+
+RFC 4520              IANA Considerations for LDAP             June 2006
+
+
+A.3.  LDAP Syntax Registration Template
+
+   Subject: Request for LDAP Syntax Registration
+
+   Object Identifier:
+
+   Description:
+
+   Person & email address to contact for further information:
+
+   Specification: (RFC, I-D, URI)
+
+   Author/Change Controller:
+
+   Comments:
+
+   (Any comments that the requester deems relevant to the request.)
+
+A.4.  LDAP Descriptor Registration Template
+
+   Subject: Request for LDAP Descriptor Registration
+
+   Descriptor (short name):
+
+   Object Identifier:
+
+   Person & email address to contact for further information:
+
+   Usage: (One of administrative role, attribute type, matching rule,
+     name form, object class, URL extension, or other)
+
+   Specification: (RFC, I-D, URI)
+
+   Author/Change Controller:
+
+   Comments:
+
+   (Any comments that the requester deems relevant to the request.)
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga                 Best Current Practice                 [Page 14]
+
+RFC 4520              IANA Considerations for LDAP             June 2006
+
+
+A.5.  LDAP Attribute Description Option Registration Template
+
+   Subject: Request for LDAP Attribute Description Option Registration
+   Option Name:
+
+   Family of Options: (YES or NO)
+
+   Person & email address to contact for further information:
+
+   Specification: (RFC, I-D, URI)
+
+   Author/Change Controller:
+
+   Comments:
+
+   (Any comments that the requester deems relevant to the request.)
+
+A.6.  LDAP Message Type Registration Template
+
+   Subject: Request for LDAP Message Type Registration
+
+   LDAP Message Name:
+
+   Person & email address to contact for further information:
+
+   Specification: (Approved I-D)
+
+   Comments:
+
+   (Any comments that the requester deems relevant to the request.)
+
+A.7.  LDAP Authentication Method Registration Template
+
+   Subject: Request for LDAP Authentication Method Registration
+
+   Authentication Method Name:
+
+   Person & email address to contact for further information:
+
+   Specification: (RFC, I-D, URI)
+
+   Intended Usage: (One of COMMON, LIMITED-USE, OBSOLETE)
+
+   Author/Change Controller:
+
+   Comments:
+
+   (Any comments that the requester deems relevant to the request.)
+
+
+
+Zeilenga                 Best Current Practice                 [Page 15]
+
+RFC 4520              IANA Considerations for LDAP             June 2006
+
+
+A.8.  LDAP Result Code Registration Template
+
+   Subject: Request for LDAP Result Code Registration
+
+   Result Code Name:
+
+   Person & email address to contact for further information:
+
+   Specification: (RFC, I-D, URI)
+
+   Author/Change Controller:
+
+   Comments:
+
+   (Any comments that the requester deems relevant to the request.)
+
+A.8.  LDAP Search Scope Registration Template
+
+   Subject: Request for LDAP Search Scope Registration
+
+   Search Scope Name:
+
+   Filter Scope String:
+
+   Person & email address to contact for further information:
+
+   Specification: (RFC, I-D, URI)
+
+   Author/Change Controller:
+
+   Comments:
+
+   (Any comments that the requester deems relevant to the request.)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga                 Best Current Practice                 [Page 16]
+
+RFC 4520              IANA Considerations for LDAP             June 2006
+
+
+A.9.  LDAP Filter Choice Registration Template
+
+   Subject: Request for LDAP Filter Choice Registration
+
+   Filter Choice Name:
+
+   Person & email address to contact for further information:
+
+   Specification: (RFC, I-D, URI)
+
+   Author/Change Controller:
+
+   Comments:
+
+   (Any comments that the requester deems relevant to the request.)
+
+A.10.  LDAP ModifyRequest Operation Registration Template
+
+   Subject: Request for LDAP ModifyRequest Operation Registration
+
+   ModifyRequest Operation Name:
+
+   Person & email address to contact for further information:
+
+   Specification: (RFC, I-D, URI)
+
+   Author/Change Controller:
+
+   Comments:
+
+   (Any comments that the requester deems relevant to the request.)
+
+Appendix B.  Changes since RFC 3383
+
+   This informative appendix provides a summary of changes made since
+   RFC 3383.
+
+      -  Object Identifier Descriptors practices were updated to require
+         all descriptors defined in RFCs to be registered and
+         recommending all other descriptors (excepting those in
+         private-use name space) be registered.  Additionally, all
+         requests for multiple registrations of the same descriptor are
+         now subject to Expert Review.
+
+      -  Protocol Mechanisms practices were updated to include values of
+         the 'supportedFeatures' attribute type.
+
+
+
+
+
+Zeilenga                 Best Current Practice                 [Page 17]
+
+RFC 4520              IANA Considerations for LDAP             June 2006
+
+
+      -  LDAP Syntax, Search Scope, Filter Choice, ModifyRequest
+         operation, and authzId prefixes registries were added.
+
+      -  References to RFCs comprising the LDAP technical specifications
+         have been updated to latest revisions.
+
+      -  References to ISO 10646 have been replaced with [Unicode].
+
+      -  The "Assigned Values" appendix providing initial registry
+         values was removed.
+
+      -  Numerous editorial changes were made.
+
+Author's Address
+
+   Kurt D. Zeilenga
+   OpenLDAP Foundation
+
+   EMail: Kurt@OpenLDAP.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga                 Best Current Practice                 [Page 18]
+
+RFC 4520              IANA Considerations for LDAP             June 2006
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2006).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Zeilenga                 Best Current Practice                 [Page 19]
+
diff --git a/source4/ldap_server/devdocs/rfc4521.txt b/source4/ldap_server/devdocs/rfc4521.txt
new file mode 100644
index 0000000000..813ff1e30f
--- /dev/null
+++ b/source4/ldap_server/devdocs/rfc4521.txt
@@ -0,0 +1,899 @@
+
+
+
+
+
+
+Network Working Group                                        K. Zeilenga
+Request for Comments: 4521                           OpenLDAP Foundation
+BCP: 118                                                       June 2006
+Category: Best Current Practice
+
+
+                          Considerations for
+        Lightweight Directory Access Protocol (LDAP) Extensions
+
+Status of This Memo
+
+   This document specifies an Internet Best Current Practices for the
+   Internet Community, and requests discussion and suggestions for
+   improvements.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   The Lightweight Directory Access Protocol (LDAP) is extensible.  It
+   provides mechanisms for adding new operations, extending existing
+   operations, and expanding user and system schemas.  This document
+   discusses considerations for designers of LDAP extensions.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga                 Best Current Practice                  [Page 1]
+
+RFC 4521                    LDAP Extensions                    June 2006
+
+
+Table of Contents
+
+   1. Introduction ....................................................3
+      1.1. Terminology ................................................3
+   2. General Considerations ..........................................4
+      2.1. Scope of Extension .........................................4
+      2.2. Interaction between extensions .............................4
+      2.3. Discovery Mechanism ........................................4
+      2.4. Internationalization Considerations ........................5
+      2.5. Use of the Basic Encoding Rules ............................5
+      2.6. Use of Formal Languages ....................................5
+      2.7. Examples ...................................................5
+      2.8. Registration of Protocol Values ............................5
+   3. LDAP Operation Extensions .......................................6
+      3.1. Controls ...................................................6
+           3.1.1. Extending Bind Operation with Controls ..............6
+           3.1.2. Extending the Start TLS Operation with Controls .....7
+           3.1.3. Extending the Search Operation with Controls ........7
+           3.1.4. Extending the Update Operations with Controls .......8
+           3.1.5. Extending the Responseless Operations with Controls..8
+      3.2. Extended Operations ........................................8
+      3.3. Intermediate Responses .....................................8
+      3.4. Unsolicited Notifications ..................................9
+   4. Extending the LDAP ASN.1 Definition .............................9
+      4.1. Result Codes ...............................................9
+      4.2. LDAP Message Types .........................................9
+      4.3. Authentication Methods ....................................10
+      4.4. General ASN.1 Extensibility ...............................10
+   5. Schema Extensions ..............................................10
+      5.1. LDAP Syntaxes .............................................11
+      5.2. Matching Rules ............................................11
+      5.3. Attribute Types ...........................................12
+      5.4. Object Classes ............................................12
+   6. Other Extension Mechanisms .....................................12
+      6.1. Attribute Description Options .............................12
+      6.2. Authorization Identities ..................................12
+      6.3. LDAP URL Extensions .......................................12
+   7. Security Considerations ........................................12
+   8. Acknowledgements ...............................................13
+   9. References .....................................................13
+      9.1. Normative References ......................................13
+      9.2. Informative References ....................................15
+
+
+
+
+
+
+
+
+
+Zeilenga                 Best Current Practice                  [Page 2]
+
+RFC 4521                    LDAP Extensions                    June 2006
+
+
+1.  Introduction
+
+   The Lightweight Directory Access Protocol (LDAP) [RFC4510] is an
+   extensible protocol.
+
+   LDAP allows for new operations to be added and for existing
+   operations to be enhanced [RFC4511].
+
+   LDAP allows additional schema to be defined [RFC4512][RFC4517].  This
+   can include additional object classes, attribute types, matching
+   rules, additional syntaxes, and other elements of schema.  LDAP
+   provides an ability to extend attribute types with options [RFC4512].
+
+   LDAP supports a Simple Authentication and Security Layer (SASL)
+   authentication method [RFC4511][RFC4513].  SASL [RFC4422] is
+   extensible.  LDAP may be extended to support additional
+   authentication methods [RFC4511].
+
+   LDAP supports establishment of Transport Layer Security (TLS)
+   [RFC4511][RFC4513].  TLS [RFC4346] is extensible.
+
+   LDAP has an extensible Uniform Resource Locator (URL) format
+   [RFC4516].
+
+   Lastly, LDAP allows for certain extensions to the protocol's Abstract
+   Syntax Notation - One (ASN.1) [X.680] definition to be made.  This
+   facilitates a wide range of protocol enhancements, for example, new
+   result codes needed to support extensions to be added through
+   extension of the protocol's ASN.1 definition.
+
+   This document describes practices that engineers should consider when
+   designing extensions to LDAP.
+
+1.1.  Terminology
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in BCP 14 [RFC2119].  In
+   this document, "the specification", as used by BCP 14, RFC 2119,
+   refers to the engineering of LDAP extensions.
+
+   The term "Request Control" refers to a control attached to a client-
+   generated message sent to a server.  The term "Response Control"
+   refers to a control attached to a server-generated message sent to a
+   client.
+
+
+
+
+
+
+Zeilenga                 Best Current Practice                  [Page 3]
+
+RFC 4521                    LDAP Extensions                    June 2006
+
+
+   DIT stands for Directory Information Tree.
+   DSA stands for Directory System Agent, a server.
+   DSE stands for DSA-Specific Entry.
+   DUA stands for Directory User Agent, a client.
+   DN stands for Distinguished Name.
+
+2.  General Considerations
+
+2.1.  Scope of Extension
+
+   Mutually agreeing peers may, within the confines of an extension,
+   agree to significant changes in protocol semantics.  However,
+   designers MUST consider the impact of an extension upon protocol
+   peers that have not agreed to implement or otherwise recognize and
+   support the extension.  Extensions MUST be "truly optional"
+   [RFC2119].
+
+2.2.  Interaction between extensions
+
+   Designers SHOULD consider how extensions they engineer interact with
+   other extensions.
+
+   Designers SHOULD consider the extensibility of extensions they
+   specify.  Extensions to LDAP SHOULD themselves be extensible.
+
+   Except where it is stated otherwise, extensibility is implied.
+
+2.3.  Discovery Mechanism
+
+   Extensions SHOULD provide adequate discovery mechanisms.
+
+   As LDAP design is based upon the client-request/server-response
+   paradigm, the general discovery approach is for the client to
+   discover the capabilities of the server before utilizing a particular
+   extension.  Commonly, this discovery involves querying the root DSE
+   and/or other DSEs for operational information associated with the
+   extension.  LDAP provides no mechanism for a server to discover the
+   capabilities of a client.
+
+   The 'supportedControl' attribute [RFC4512] is used to advertise
+   supported controls.  The 'supportedExtension' attribute [RFC4512] is
+   used to advertise supported extended operations.  The
+   'supportedFeatures' attribute [RFC4512] is used to advertise
+   features.  Other root DSE attributes MAY be defined to advertise
+   other capabilities.
+
+
+
+
+
+
+Zeilenga                 Best Current Practice                  [Page 4]
+
+RFC 4521                    LDAP Extensions                    June 2006
+
+
+2.4.  Internationalization Considerations
+
+   LDAP is designed to support the full Unicode [Unicode] repertory of
+   characters.  Extensions SHOULD avoid unnecessarily restricting
+   applications to subsets of Unicode (e.g., Basic Multilingual Plane,
+   ISO 8859-1, ASCII, Printable String).
+
+   LDAP Language Tag options [RFC3866] provide a mechanism for tagging
+   text (and other) values with language information.  Extensions that
+   define attribute types SHOULD allow use of language tags with these
+   attributes.
+
+2.5.  Use of the Basic Encoding Rules
+
+   Numerous elements of LDAP are described using ASN.1 [X.680] and are
+   encoded using a particular subset [Protocol, Section 5.2] of the
+   Basic Encoding Rules (BER) [X.690].  To allow reuse of
+   parsers/generators used in implementing the LDAP "core" technical
+   specification [RFC4510], it is RECOMMENDED that extension elements
+   (e.g., extension specific contents of controlValue, requestValue,
+   responseValue fields) described by ASN.1 and encoded using BER be
+   subjected to the restrictions of [Protocol, Section 5.2].
+
+2.6.  Use of Formal Languages
+
+   Formal languages SHOULD be used in specifications in accordance with
+   IESG guidelines [FORMAL].
+
+2.7.  Examples
+
+   Example DN strings SHOULD conform to the syntax defined in [RFC4518].
+   Example LDAP filter strings SHOULD conform to the syntax defined in
+   [RFC4515].  Example LDAP URLs SHOULD conform to the syntax defined in
+   [RFC4516].  Entries SHOULD be represented using LDIF [RFC2849].
+
+2.8.  Registration of Protocol Values
+
+   Designers SHALL register protocol values of their LDAP extensions in
+   accordance with BCP 64, RFC 4520 [RFC4520].  Specifications that
+   create new extensible protocol elements SHALL extend existing
+   registries or establish new registries for values of these elements
+   in accordance with BCP 64, RFC 4520 [RFC4520] and BCP 26, RFC 2434
+   [RFC2434].
+
+
+
+
+
+
+
+
+Zeilenga                 Best Current Practice                  [Page 5]
+
+RFC 4521                    LDAP Extensions                    June 2006
+
+
+3.  LDAP Operation Extensions
+
+   Extensions SHOULD use controls in defining extensions that complement
+   existing operations.  Where the extension to be defined does not
+   complement an existing operation, designers SHOULD consider defining
+   an extended operation instead.
+
+   For example, a subtree delete operation could be designed as either
+   an extension of the delete operation or as a new operation.  As the
+   feature complements the existing delete operation, use of the control
+   mechanism to extend the delete operation is likely more appropriate.
+
+   As a counter (and contrived) example, a locate services operation (an
+   operation that would return for a DN a set of LDAP URLs to services
+   that may hold the entry named by this DN) could be designed as either
+   a search operation or a new operation.  As the feature doesn't
+   complement the search operation (e.g., the operation is not contrived
+   to search for entries held in the Directory Information Tree), it is
+   likely more appropriate to define a new operation using the extended
+   operation mechanism.
+
+3.1.  Controls
+
+   Controls [Protocol, Section 4.1.11] are the RECOMMENDED mechanism for
+   extending existing operations.  The existing operation can be a base
+   operation defined in [RFC4511] (e.g., search, modify) , an extended
+   operation (e.g., Start TLS [RFC4511], Password Modify [RFC3062]), or
+   an operation defined as an extension to a base or extended operation.
+
+   Extensions SHOULD NOT return Response controls unless the server has
+   specific knowledge that the client can make use of the control.
+   Generally, the client requests the return of a particular response
+   control by providing a related request control.
+
+   An existing operation MAY be extended to return IntermediateResponse
+   messages [Protocol, Section 4.13].
+
+   Specifications of controls SHALL NOT attach additional semantics to
+   the criticality of controls beyond those defined in [Protocol,
+   Section 4.1.11].  A specification MAY mandate the criticality take on
+   a particular value (e.g., TRUE or FALSE), where appropriate.
+
+3.1.1.  Extending Bind Operation with Controls
+
+   Controls attached to the request and response messages of a Bind
+   Operation [RFC4511] are not protected by any security layers
+   established by that Bind operation.
+
+
+
+
+Zeilenga                 Best Current Practice                  [Page 6]
+
+RFC 4521                    LDAP Extensions                    June 2006
+
+
+   Specifications detailing controls extending the Bind operation SHALL
+   detail that the Bind negotiated security layers do not protect the
+   information contained in these controls and SHALL detail how the
+   information in these controls is protected or why the information
+   does not need protection.
+
+   It is RECOMMENDED that designers consider alternative mechanisms for
+   providing the function.  For example, an extended operation issued
+   subsequent to the Bind operation (hence, protected by the security
+   layers negotiated by the Bind operation) might be used to provide the
+   desired function.
+
+   Additionally, designers of Bind control extensions MUST also consider
+   how the controls' semantics interact with individual steps of a
+   multi-step Bind operation.  Note that some steps are optional and
+   thus may require special attention in the design.
+
+3.1.2.  Extending the Start TLS Operation with Controls
+
+   Controls attached to the request and response messages of a Start TLS
+   Operation [RFC4511] are not protected by the security layers
+   established by the Start TLS operation.
+
+   Specifications detailing controls extending the Start TLS operation
+   SHALL detail that the Start TLS negotiated security layers do not
+   protect the information contained in these controls and SHALL detail
+   how the information in these controls is protected or why the
+   information does not need protection.
+
+   It is RECOMMENDED that designers consider alternative mechanisms for
+   providing the function.  For example, an extended operation issued
+   subsequent to the Start TLS operation (hence, protected by the
+   security layers negotiated by the Start TLS operation) might be used
+   to provided the desired function.
+
+3.1.3.  Extending the Search Operation with Controls
+
+   The Search operation processing has two distinct phases:
+
+      -  finding the base object; and
+
+      -  searching for objects at or under that base object.
+
+   Specifications of controls extending the Search Operation should
+   clearly state in which phase(s) the control's semantics apply.
+   Semantics of controls that are not specific to the Search Operation
+   SHOULD apply in the finding phase.
+
+
+
+
+Zeilenga                 Best Current Practice                  [Page 7]
+
+RFC 4521                    LDAP Extensions                    June 2006
+
+
+3.1.4.  Extending the Update Operations with Controls
+
+   Update operations have properties of atomicity, consistency,
+   isolation, and durability ([ACID]).
+
+      -  atomicity: All or none of the DIT changes requested are made.
+
+      -  consistency: The resulting DIT state must be conform to schema
+         and other constraints.
+
+      -  isolation: Intermediate states are not exposed.
+
+      -  durability: The resulting DIT state is preserved until
+         subsequently updated.
+
+   When defining a control that requests additional (or other) DIT
+   changes be made to the DIT, these additional changes SHOULD NOT be
+   treated as part of a separate transaction.  The specification MUST be
+   clear as to whether the additional DIT changes are part of the same
+   or a separate transaction as the DIT changes expressed in the request
+   of the base operation.
+
+   When defining a control that requests additional (or other) DIT
+   changes be made to the DIT, the specification MUST be clear as to the
+   order in which these and the base changes are to be applied to the
+   DIT.
+
+3.1.5.  Extending the Responseless Operations with Controls
+
+   The Abandon and Unbind operations do not include a response message.
+   For this reason, specifications for controls designed to be attached
+   to Abandon and Unbind requests SHOULD mandate that the control's
+   criticality be FALSE.
+
+3.2.  Extended Operations
+
+   Extended Operations [Protocol, Section 4.12] are the RECOMMENDED
+   mechanism for defining new operations.  An extended operation
+   consists of an ExtendedRequest message, zero or more
+   IntermediateResponse messages, and an ExtendedResponse message.
+
+3.3.  Intermediate Responses
+
+   Extensions SHALL use IntermediateResponse messages instead of
+   ExtendedResponse messages to return intermediate results.
+
+
+
+
+
+
+Zeilenga                 Best Current Practice                  [Page 8]
+
+RFC 4521                    LDAP Extensions                    June 2006
+
+
+3.4.  Unsolicited Notifications
+
+   Unsolicited notifications [Protocol, Section 4.4] offer a capability
+   for the server to notify the client of events not associated with the
+   operation currently being processed.
+
+   Extensions SHOULD be designed such that unsolicited notifications are
+   not returned unless the server has specific knowledge that the client
+   can make use of the notification.  Generally, the client requests the
+   return of a particular unsolicited notification by performing a
+   related extended operation.
+
+   For example, a time hack extension could be designed to return
+   unsolicited notifications at regular intervals that were enabled by
+   an extended operation (which possibly specified the desired
+   interval).
+
+4.  Extending the LDAP ASN.1 Definition
+
+   LDAP allows limited extension [Protocol, Section 4] of the LDAP ASN.1
+   definition [Protocol, Appendix B] to be made.
+
+4.1.  Result Codes
+
+   Extensions that specify new operations or enhance existing operations
+   often need to define new result codes.  The extension SHOULD be
+   designed such that a client has a reasonably clear indication of the
+   nature of the successful or non-successful result.
+
+   Extensions SHOULD use existing result codes to indicate conditions
+   that are consistent with the intended meaning [RFC4511][X.511] of
+   these codes.  Extensions MAY introduce new result codes [RFC4520]
+   where no existing result code provides an adequate indication of the
+   nature of the result.
+
+   Extensions SHALL NOT disallow or otherwise restrict the return of
+   general service result codes, especially those reporting a protocol,
+   service, or security problem, or indicating that the server is unable
+   or unwilling to complete the operation.
+
+4.2.  LDAP Message Types
+
+   While extensions can specify new types of LDAP messages by extending
+   the protocolOp CHOICE of the LDAPMessage SEQUENCE, this is generally
+   unnecessary and inappropriate.  Existing operation extension
+   mechanisms (e.g., extended operations, unsolicited notifications, and
+   intermediate responses) SHOULD be used instead.  However, there may
+   be cases where an extension does not fit well into these mechanisms.
+
+
+
+Zeilenga                 Best Current Practice                  [Page 9]
+
+RFC 4521                    LDAP Extensions                    June 2006
+
+
+   In such cases, a new extension mechanism SHOULD be defined that can
+   be used by multiple extensions that have similar needs.
+
+4.3.  Authentication Methods
+
+   The Bind operation currently supports two authentication methods,
+   simple and SASL.  SASL [RFC4422] is an extensible authentication
+   framework used by multiple application-level protocols (e.g., BEEP,
+   IMAP, SMTP).  It is RECOMMENDED that new authentication processes be
+   defined as SASL mechanisms.  New LDAP authentication methods MAY be
+   added to support new authentication frameworks.
+
+   The Bind operation's primary function is to establish the LDAP
+   association [RFC4513].  No other operation SHALL be defined (or
+   extended) to establish the LDAP association.  However, other
+   operations MAY be defined to establish other security associations
+   (e.g., IPsec).
+
+4.4.  General ASN.1 Extensibility
+
+   Section 4 of [RFC4511] states the following:
+
+      In order to support future extensions to this protocol,
+      extensibility is implied where it is allowed per ASN.1 (i.e.,
+      sequence, set, choice, and enumerated types are extensible).  In
+      addition, ellipses (...)  have been supplied in ASN.1 types that
+      are explicitly extensible as discussed in [RFC4520].  Because of
+      the implied extensibility, clients and servers MUST (unless
+      otherwise specified) ignore trailing SEQUENCE components whose
+      tags they do not recognize.
+
+   Designers SHOULD avoid introducing extensions that rely on
+   unsuspecting implementations to ignore trailing components of
+   SEQUENCE whose tags they do not recognize.
+
+5.  Schema Extensions
+
+   Extensions defining LDAP schema elements SHALL provide schema
+   definitions conforming with syntaxes defined in [Models, Section
+   4.1].  While provided definitions MAY be reformatted (line wrapped)
+   for readability, this SHALL be noted in the specification.
+
+   For definitions that allow a NAME field, new schema elements SHOULD
+   provide one and only one name.  The name SHOULD be short.
+
+   Each schema definition allows a DESC field.  The DESC field, if
+   provided, SHOULD contain a short descriptive phrase.  The DESC field
+   MUST be regarded as informational.  That is, the specification MUST
+
+
+
+Zeilenga                 Best Current Practice                 [Page 10]
+
+RFC 4521                    LDAP Extensions                    June 2006
+
+
+   be written such that its interpretation is the same with and without
+   the provided DESC fields.
+
+   The extension SHALL NOT mandate that implementations provide the same
+   DESC field in the schema they publish.  Implementors MAY replace or
+   remove the DESC field.
+
+   Published schema elements SHALL NOT be redefined.  Replacement schema
+   elements (new OIDs, new NAMEs) SHOULD be defined as needed.
+
+   Schema designers SHOULD reuse existing schema elements, where
+   appropriate.  However, any reuse MUST not alter the semantics of the
+   element.
+
+5.1.  LDAP Syntaxes
+
+   Each LDAP syntax [RFC4517] is defined in terms of ASN.1 [X.680].
+   Each extension detailing an LDAP syntax MUST specify the ASN.1 data
+   definition associated with the syntax.  A distinct LDAP syntax SHOULD
+   be created for each distinct ASN.1 data definition (including
+   constraints).
+
+   Each LDAP syntax SHOULD have a string encoding defined for it.  It is
+   RECOMMENDED that this string encoding be restricted to UTF-8
+   [RFC3629] encoded Unicode [Unicode] characters.  Use of Generic
+   String Encoding Rules (GSER) [RFC3641][RFC3642] or other generic
+   string encoding rules to provide string encodings for complex ASN.1
+   data definitions is RECOMMENDED.  Otherwise, it is RECOMMENDED that
+   the string encoding be described using a formal language (e.g., ABNF
+   [RFC4234]).  Formal languages SHOULD be used in specifications in
+   accordance with IESG guidelines [FORMAL].
+
+   If no string encoding is defined, the extension SHALL specify how the
+   transfer encoding is to be indicated.  Generally, the extension
+   SHOULD mandate use of binary or other transfer encoding option.
+
+5.2.  Matching Rules
+
+   Three basic kinds of matching rules (e.g., EQUALITY, ORDERING, and
+   SUBSTRING) may be associated with an attribute type.  In addition,
+   LDAP provides an extensible matching rule mechanism.
+
+   The matching rule specification SHOULD detail which kind of matching
+   rule it is and SHOULD describe which kinds of values it can be used
+   with.
+
+   In addition to requirements stated in the LDAP technical
+   specification, equality matching rules SHOULD be commutative.
+
+
+
+Zeilenga                 Best Current Practice                 [Page 11]
+
+RFC 4521                    LDAP Extensions                    June 2006
+
+
+5.3.  Attribute Types
+
+   Designers SHOULD carefully consider how the structure of values is to
+   be restricted.  Designers SHOULD consider that servers will only
+   enforce constraints of the attribute's syntax.  That is, an attribute
+   intended to hold URIs, but that has directoryString syntax, is not
+   restricted to values that are URIs.
+
+   Designers SHOULD carefully consider which matching rules, if any, are
+   appropriate for the attribute type.  Matching rules specified for an
+   attribute type MUST be compatible with the attribute type's syntax.
+
+   Extensions specifying operational attributes MUST detail how servers
+   are to maintain and/or utilize values of each operational attribute.
+
+5.4.  Object Classes
+
+   Designers SHOULD carefully consider whether each attribute of an
+   object class is required ("MUST") or allowed ("MAY").
+
+   Extensions specifying object classes that allow (or require)
+   operational attributes MUST specify how servers are to maintain
+   and/or utilize entries belonging to these object classes.
+
+6.  Other Extension Mechanisms
+
+6.1.  Attribute Description Options
+
+   Each option is identified by a string of letters, numbers, and
+   hyphens.  This string SHOULD be short.
+
+6.2.  Authorization Identities
+
+   Extensions interacting with authorization identities SHALL support
+   the LDAP authzId format [RFC4513].  The authzId format is extensible.
+
+6.3.  LDAP URL Extensions
+
+   LDAP URL extensions are identified by a short string, a descriptor.
+   Like other descriptors, the string SHOULD be short.
+
+7.  Security Considerations
+
+   LDAP does not place undue restrictions on the kinds of extensions
+   that can be implemented.  While this document attempts to outline
+   some specific issues that designers need to consider, it is not (and
+
+
+
+
+
+Zeilenga                 Best Current Practice                 [Page 12]
+
+RFC 4521                    LDAP Extensions                    June 2006
+
+
+   cannot be) all encompassing.  Designers MUST do their own evaluations
+   of the security considerations applicable to their extensions.
+
+   Designers MUST NOT assume that the LDAP "core" technical
+   specification [RFC4510] adequately addresses the specific concerns
+   surrounding their extensions or assume that their extensions have no
+   specific concerns.
+
+   Extension specifications, however, SHOULD note whether security
+   considerations specific to the feature they are extending, as well as
+   general LDAP security considerations, apply to the extension.
+
+8.  Acknowledgements
+
+   The author thanks the IETF LDAP community for their thoughtful
+   comments.
+
+   This work builds upon "LDAP Extension Style Guide" [GUIDE] by Bruce
+   Greenblatt.
+
+9.  References
+
+9.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2434]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
+              IANA Considerations Section in RFCs", BCP 26, RFC 2434,
+              October 1998.
+
+   [RFC2849]  Good, G., "The LDAP Data Interchange Format (LDIF) -
+              Technical Specification", RFC 2849, June 2000.
+
+   [RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO
+              10646", STD 63, RFC 3629, November 2003.
+
+   [RFC3641]  Legg, S., "Generic String Encoding Rules (GSER) for ASN.1
+              Types", RFC 3641, October 2003.
+
+   [RFC3642]  Legg, S., "Common Elements of Generic String Encoding
+              Rules (GSER) Encodings", RFC 3642, October 2003.
+
+   [RFC4512]  Zeilenga, K., "Lightweight Directory Access Protocol
+              (LDAP): Directory Information Models", RFC 4512, June
+              2006.
+
+
+
+
+
+Zeilenga                 Best Current Practice                 [Page 13]
+
+RFC 4521                    LDAP Extensions                    June 2006
+
+
+   [RFC3866]  Zeilenga, K., Ed., "Language Tags and Ranges in the
+              Lightweight Directory Access Protocol (LDAP)", RFC 3866,
+              July 2004.
+
+   [RFC4234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
+              Specifications: ABNF", RFC 4234, October 2005.
+
+   [RFC4510]  Zeilenga, K., Ed., "Lightweight Directory Access Protocol
+              (LDAP): Technical Specification Road Map", RFC 4510, June
+              2006.
+
+   [RFC4511]  Sermersheim, J., Ed., "Lightweight Directory Access
+              Protocol (LDAP): The Protocol", RFC 4511, June 2006.
+
+   [RFC4512]  Zeilenga, K., "Lightweight Directory Access Protocol
+              (LDAP): Directory Information Models", RFC 4512, June
+              2006.
+
+   [RFC4513]  Harrison, R., Ed., "Lightweight Directory Access Protocol
+              (LDAP): Authentication Methods and Security Mechanisms",
+              RFC 4513, June 2006.
+
+   [RFC4515]  Smith, M., Ed. and T. Howes, "Lightweight Directory Access
+              Protocol (LDAP): String Representation of Search Filters",
+              RFC 4515, June 2006.
+
+   [RFC4516]  Smith, M., Ed. and T. Howes, "Lightweight Directory Access
+              Protocol (LDAP): Uniform Resource Locator", RFC 4516, June
+              2006.
+
+   [RFC4517]  Legg, S., Ed., "Lightweight Directory Access Protocol
+              (LDAP): Syntaxes and Matching Rules", RFC 4517, June 2006.
+
+   [RFC4518]  Zeilenga, K., "Lightweight Directory Access Protocol
+              (LDAP): String Representation of Distinguished Names", RFC
+              4518, June 2006.
+
+   [RFC4520]  Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
+              Considerations for the Lightweight Directory Access
+              Protocol (LDAP)", BCP 64, RFC 4520, June 2006.
+
+   [RFC4422]  Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple
+              Authentication and Security Layer (SASL)", RFC 4422, June
+              2006.
+
+
+
+
+
+
+
+Zeilenga                 Best Current Practice                 [Page 14]
+
+RFC 4521                    LDAP Extensions                    June 2006
+
+
+   [Unicode]  The Unicode Consortium, "The Unicode Standard, Version
+              3.2.0" is defined by "The Unicode Standard, Version 3.0"
+              (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5),
+              as amended by the "Unicode Standard Annex #27: Unicode
+              3.1" (http://www.unicode.org/reports/tr27/) and by the
+              "Unicode Standard Annex #28: Unicode 3.2"
+              (http://www.unicode.org/reports/tr28/).
+
+   [FORMAL]   IESG, "Guidelines for the use of formal languages in IETF
+              specifications",
+              <http://www.ietf.org/IESG/STATEMENTS/pseudo-code-in-
+              specs.txt>, 2001.
+
+   [X.511]    International Telecommunication Union - Telecommunication
+              Standardization Sector, "The Directory: Abstract Service
+              Definition", X.511(1993) (also ISO/IEC 9594-3:1993).
+
+   [X.680]    International Telecommunication Union - Telecommunication
+              Standardization Sector, "Abstract Syntax Notation One
+              (ASN.1) - Specification of Basic Notation", X.680(2002)
+              (also ISO/IEC 8824-1:2002).
+
+   [X.690]    International Telecommunication Union - Telecommunication
+              Standardization Sector, "Specification of ASN.1 encoding
+              rules: Basic Encoding Rules (BER), Canonical Encoding
+              Rules (CER), and Distinguished Encoding Rules (DER)",
+              X.690(2002) (also ISO/IEC 8825-1:2002).
+
+9.2.  Informative References
+
+   [ACID]     Section 4 of ISO/IEC 10026-1:1992.
+
+   [GUIDE]    Greenblatt, B., "LDAP Extension Style Guide", Work in
+              Progress.
+
+   [RFC3062]  Zeilenga, K., "LDAP Password Modify Extended Operation",
+              RFC 3062, February 2001.
+
+   [RFC4346]  Dierks, T. and E. Rescorla, "The Transport Layer Security
+              (TLS) Protocol Version 1.1", RFC 4346, April 2006.
+
+Author's Address
+
+   Kurt D. Zeilenga
+   OpenLDAP Foundation
+
+   EMail: Kurt@OpenLDAP.org
+
+
+
+
+Zeilenga                 Best Current Practice                 [Page 15]
+
+RFC 4521                    LDAP Extensions                    June 2006
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2006).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Zeilenga                 Best Current Practice                 [Page 16]
+
diff --git a/source4/ldap_server/devdocs/rfc4522.txt b/source4/ldap_server/devdocs/rfc4522.txt
new file mode 100644
index 0000000000..11156a07f1
--- /dev/null
+++ b/source4/ldap_server/devdocs/rfc4522.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+Network Working Group                                            S. Legg
+Request for Comments: 4522                                       eB2Bcom
+Category: Standards Track                                      June 2006
+
+
+             Lightweight Directory Access Protocol (LDAP):
+                       The Binary Encoding Option
+
+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
+
+   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
+   document defines an attribute option, the binary option, that can be
+   used to specify that the associated attribute values are instead
+   encoded according to the Basic Encoding Rules (BER) used by X.500
+   directories.
+
+Table of Contents
+
+   1. Introduction ....................................................2
+   2. Conventions .....................................................2
+   3. The Binary Option ...............................................2
+   4. Syntaxes Requiring Binary Transfer ..............................3
+   5. Attributes Returned in a Search .................................4
+   6. All User Attributes .............................................4
+   7. Conflicting Requests ............................................5
+   8. Security Considerations .........................................5
+   9. IANA Considerations .............................................5
+   10. References .....................................................5
+      10.1. Normative References ......................................5
+      10.2. Informative References ....................................6
+
+
+
+
+Legg                        Standards Track                     [Page 1]
+
+RFC 4522            LDAP: The Binary Encoding Option           June 2006
+
+
+1.  Introduction
+
+   Each attribute stored in a Lightweight Directory Access Protocol
+   (LDAP) directory [RFC4510] has a defined syntax (i.e., data type)
+   which constrains the structure and format of its values.
+
+   The description of each syntax [RFC4517] specifies how attribute or
+   assertion values [RFC4512] conforming to the syntax are normally
+   represented when transferred in LDAP operations [RFC4511].  This
+   representation is referred to as the LDAP-specific encoding to
+   distinguish it from other methods of encoding attribute values.
+
+   This document defines an attribute option, the binary option, which
+   can be used in an attribute description [RFC4512] in an LDAP
+   operation to specify that the associated attribute values or
+   assertion values are, or are requested to be, encoded according to
+   the Basic Encoding Rules (BER) [BER] as used by X.500 [X.500]
+   directories, instead of the usual LDAP-specific encoding.
+
+   The binary option was originally defined in RFC 2251 [RFC2251].  The
+   LDAP technical specification [RFC4510] has obsoleted the previously
+   defined LDAP technical specification [RFC3377], which included RFC
+   2251.  The binary option was not included in the revised LDAP
+   technical specification for a variety of reasons including
+   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 [RFC4523], that
+   specifically require it.  No attempt has been made to address use of
+   the binary option with attributes of syntaxes that do not require its
+   use.  Unless addressed in a future specification, this use is to be
+   avoided.
+
+2.  Conventions
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in BCP 14, RFC 2119
+   [BCP14].
+
+3.  The Binary Option
+
+   The binary option is indicated with the attribute option string
+   "binary" in an attribute description.  Note that, like all attribute
+   options, the string representing the binary option is case
+   insensitive.
+
+
+
+
+Legg                        Standards Track                     [Page 2]
+
+RFC 4522            LDAP: The Binary Encoding Option           June 2006
+
+
+   Where the binary option is present in an attribute description, the
+   associated attribute values or assertion values MUST be BER encoded
+   (otherwise the values are encoded according to the LDAP-specific
+   encoding [RFC4517] for the attribute's syntax).  Note that it is
+   possible for a syntax to be defined such that its LDAP-specific
+   encoding is exactly the same as its BER encoding.
+
+   In terms of the protocol [RFC4511], the binary option specifies that
+   the contents octets of the associated AttributeValue or
+   AssertionValue OCTET STRING are a complete BER encoding of the
+   relevant value.
+
+   The binary option is not a tagging option [RFC4512], so the presence
+   of the binary option does not specify an attribute subtype.  An
+   attribute description containing the binary option references exactly
+   the same attribute as the attribute description without the binary
+   option.  The supertype/subtype relationships of attributes with
+   tagging options are not altered in any way by the presence or absence
+   of the binary option.
+
+   An attribute description SHALL be treated as unrecognized if it
+   contains the binary option and the syntax of the attribute does not
+   have an associated ASN.1 type [RFC4517], or the BER encoding of
+   values of that type is not supported.
+
+   The presence or absence of the binary option only affects the
+   transfer of attribute and assertion values in the protocol; servers
+   store any particular attribute value in a format of their choosing.
+
+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
+   certificate, certificate list, certificate pair, and supported
+   algorithm syntaxes [RFC4523] are examples of syntaxes with a binary
+   transfer requirement.  These syntaxes also have an additional
+   requirement that the exact BER encoding must be preserved.  Note that
+   this is a property of the syntaxes themselves, and not a property of
+   the binary option.  In the absence of this requirement, LDAP clients
+   would need to re-encode values using the Distinguished Encoding Rules
+   (DER).
+
+
+
+
+
+
+
+
+Legg                        Standards Track                     [Page 3]
+
+RFC 4522            LDAP: The Binary Encoding Option           June 2006
+
+
+5.  Attributes Returned in a Search
+
+   An LDAP search request [RFC4511] contains a list of the attributes
+   (the requested attributes list) to be returned from each entry
+   matching the search filter.  An attribute description in the
+   requested attributes list also implicitly requests all subtypes of
+   the attribute type in the attribute description, whether through
+   attribute subtyping or attribute tagging option subtyping [RFC4512].
+
+   The requested attributes list MAY contain attribute descriptions with
+   the binary option, but MUST NOT contain two attribute descriptions
+   with the same attribute type and the same tagging options (even if
+   only one of them has the binary option).  The binary option in an
+   attribute description in the requested attributes list implicitly
+   applies to all the subtypes of the attribute type in the attribute
+   description (however, see Section 7).
+
+   Attributes of a syntax with the binary transfer requirement, if
+   returned, SHALL be returned in the binary form (i.e., with the binary
+   option in the attribute description and the associated attribute
+   values BER encoded) regardless of whether the binary option was
+   present in the request (for the attribute or for one of its
+   supertypes).
+
+   Attributes of a syntax without the binary transfer requirement, if
+   returned, SHOULD be returned in the form explicitly requested.  That
+   is, if the attribute description in the requested attributes list
+   contains the binary option, then the corresponding attribute in the
+   result SHOULD be in the binary form.  If the attribute description in
+   the request does not contain the binary option, then the
+   corresponding attribute in the result SHOULD NOT be in the binary
+   form.  A server MAY omit an attribute from the result if it does not
+   support the requested encoding.
+
+   Regardless of the encoding chosen, a particular attribute value is
+   returned at most once.
+
+6.  All User Attributes
+
+   If the list of attributes in a search request is empty or contains
+   the special attribute description string "*", then all user
+   attributes are requested to be returned.
+
+   Attributes of a syntax with the binary transfer requirement, if
+   returned, SHALL be returned in the binary form.
+
+
+
+
+
+
+Legg                        Standards Track                     [Page 4]
+
+RFC 4522            LDAP: The Binary Encoding Option           June 2006
+
+
+   Attributes of a syntax without the binary transfer requirement and
+   having a defined LDAP-specific encoding SHOULD NOT be returned in the
+   binary form.
+
+   Attributes of a syntax without the binary transfer requirement and
+   without a defined LDAP-specific encoding may be returned in the
+   binary form or omitted from the result.
+
+7.  Conflicting Requests
+
+   A particular attribute could be explicitly requested by an attribute
+   description and/or implicitly requested by the attribute descriptions
+   of one or more of its supertypes, or by the special attribute
+   description string "*".  If the binary option is present in at least
+   one, but not all, of these attribute descriptions then the effect of
+   the request with respect to binary transfer is implementation
+   defined.
+
+8.  Security Considerations
+
+   When interpreting security-sensitive fields, and in particular fields
+   used to grant or deny access, implementations MUST ensure that any
+   matching rule comparisons are done on the underlying abstract value,
+   regardless of the particular encoding used.
+
+9.  IANA Considerations
+
+   The Internet Assigned Numbers Authority (IANA) has updated the LDAP
+   attribute description option registry [BCP64] as indicated by the
+   following template:
+
+      Subject:
+        Request for LDAP Attribute Description Option Registration
+      Option Name: binary
+      Family of Options: NO
+      Person & email address to contact for further information:
+        Steven Legg <steven.legg@eb2bcom.com>
+      Specification: RFC 4522
+      Author/Change Controller: IESG
+
+10.  References
+
+10.1.  Normative References
+
+   [BCP14]    Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+
+
+
+
+Legg                        Standards Track                     [Page 5]
+
+RFC 4522            LDAP: The Binary Encoding Option           June 2006
+
+
+   [BCP64]    Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
+              Considerations for the Lightweight Directory Access
+              Protocol (LDAP)", BCP 64, RFC 4520, June 2006.
+
+   [RFC4510]  Zeilenga, K., Ed., "Lightweight Directory Access Protocol
+              (LDAP): Technical Specification Road Map", RFC RFC 4510,
+              June 2006.
+
+   [RFC4511]  Sermersheim, J., "Lightweight Directory Access Protocol
+              (LDAP): The Protocol", RFC 4511, June 2006.
+
+   [RFC4512]  Zeilenga, K., "Lightweight Directory Access Protocol
+              (LDAP): Directory Information Models", RFC 4512, June
+              2006.
+
+   [RFC4517]  Legg, S., Ed., "Lightweight Directory Access Protocol
+              (LDAP):  Syntaxes and Matching Rules", RFC 4517, June
+              2006.
+
+   [RFC4523]  Zeilenga, K., "Lightweight Directory Access Protocol
+              (LDAP) Schema Definitions for X.509 Certificates", RFC
+              4523, June 2006.
+
+   [BER]      ITU-T Recommendation X.690 (07/02) | ISO/IEC 8825-1,
+              Information Technology - ASN.1 encoding rules:
+              Specification of Basic Encoding Rules (BER), Canonical
+              Encoding Rules (CER) and Distinguished Encoding Rules
+              (DER).
+
+10.2.  Informative References
+
+   [RFC2251]  Wahl, M., Howes, T., and S. Kille, "Lightweight Directory
+              Access Protocol (v3)", RFC 2251, December 1997.
+
+   [RFC3377]  Hodges, J. and R. Morgan, "Lightweight Directory Access
+              Protocol (v3): Technical Specification", RFC 3377,
+              September 2002.
+
+   [X.500]    ITU-T Recommendation X.500 (02/01) | ISO/IEC 9594-1:2001,
+              Information technology - Open Systems Interconnection -
+              The Directory:  Overview of concepts, models and services
+
+
+
+
+
+
+
+
+
+
+Legg                        Standards Track                     [Page 6]
+
+RFC 4522            LDAP: The Binary Encoding Option           June 2006
+
+
+Author's Address
+
+   Dr. Steven Legg
+   eB2Bcom
+   Suite 3, Woodhouse Corporate Centre
+   935 Station Street
+   Box Hill North, Victoria 3129
+   AUSTRALIA
+
+   Phone: +61 3 9896 7830
+   Fax:   +61 3 9896 7801
+   EMail: steven.legg@eb2bcom.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Legg                        Standards Track                     [Page 7]
+
+RFC 4522            LDAP: The Binary Encoding Option           June 2006
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2006).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Legg                        Standards Track                     [Page 8]
+
diff --git a/source4/ldap_server/devdocs/rfc4523.txt b/source4/ldap_server/devdocs/rfc4523.txt
new file mode 100644
index 0000000000..d2589811c7
--- /dev/null
+++ b/source4/ldap_server/devdocs/rfc4523.txt
@@ -0,0 +1,1347 @@
+
+
+
+
+
+
+Network Working Group                                        K. Zeilenga
+Request for Comments: 4523                           OpenLDAP Foundation
+Obsoletes: 2252, 2256, 2587                                    June 2006
+Category: Standards Track
+
+
+             Lightweight Directory Access Protocol (LDAP)
+               Schema Definitions for X.509 Certificates
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+   Abstract
+
+   This document describes schema for representing X.509 certificates,
+   X.521 security information, and related elements in directories
+   accessible using the Lightweight Directory Access Protocol (LDAP).
+   The LDAP definitions for these X.509 and X.521 schema elements
+   replace those provided in RFCs 2252 and 2256.
+
+1.  Introduction
+
+   This document provides LDAP [RFC4510] schema definitions [RFC4512]
+   for a subset of elements specified in X.509 [X.509] and X.521
+   [X.521], including attribute types for certificates, cross
+   certificate pairs, and certificate revocation lists; matching rules
+   to be used with these attribute types; and related object classes.
+   LDAP syntax definitions are also provided for associated assertion
+   and attribute values.
+
+   As the semantics of these elements are as defined in X.509 and X.521,
+   knowledge of X.509 and X.521 is necessary to make use of the LDAP
+   schema definitions provided herein.
+
+   This document, together with [RFC4510], obsoletes RFCs 2252 and 2256
+   in their entirety.  The changes (in this document) made since RFC
+   2252 and RFC 2256 include:
+
+      -  addition of pkiUser, pkiCA, and deltaCRL classes;
+
+
+
+Zeilenga                    Standards Track                     [Page 1]
+
+RFC 4523                   LDAP X.509 Schema                   June 2006
+
+
+      -  update of attribute types to include equality matching rules in
+         accordance with their X.500 specifications;
+
+      -  addition of certificate, certificate pair, certificate list,
+         and algorithm identifier matching rules; and
+
+      -  addition of LDAP syntax for assertion syntaxes for these
+         matching rules.
+
+   This document obsoletes RFC 2587.  The X.509 schema descriptions for
+   LDAPv2 [RFC1777] are Historic, as is LDAPv2 [RFC3494].
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in BCP 14 [RFC2119].
+
+   Schema definitions are provided using LDAP description formats
+   [RFC4512].  Definitions provided here are formatted (line wrapped)
+   for readability.
+
+2.  Syntaxes
+
+   This section describes various syntaxes used in LDAP to transfer
+   certificates and related data types.
+
+2.1.  Certificate
+
+      ( 1.3.6.1.4.1.1466.115.121.1.8 DESC 'X.509 Certificate' )
+
+   A value of this syntax is an X.509 Certificate [X.509, clause 7].
+
+   Due to changes made to the definition of a Certificate through time,
+   no LDAP-specific encoding is defined for this syntax.  Values of this
+   syntax SHOULD be encoded using Distinguished Encoding Rules (DER)
+   [X.690] and MUST only be transferred using the ;binary transfer
+   option [RFC4522]; that is, by requesting and returning values using
+   attribute descriptions such as "userCertificate;binary".
+
+   As values of this syntax contain digitally signed data, values of
+   this syntax and the form of each value MUST be preserved as
+   presented.
+
+2.2.  CertificateList
+
+      ( 1.3.6.1.4.1.1466.115.121.1.9 DESC 'X.509 Certificate List' )
+
+   A value of this syntax is an X.509 CertificateList [X.509, clause
+   7.3].
+
+
+
+Zeilenga                    Standards Track                     [Page 2]
+
+RFC 4523                   LDAP X.509 Schema                   June 2006
+
+
+   Due to changes made to the definition of a CertificateList through
+   time, no LDAP-specific encoding is defined for this syntax.  Values
+   of this syntax SHOULD be encoded using DER [X.690] and MUST only be
+   transferred using the ;binary transfer option [RFC4522]; that is, by
+   requesting and returning values using attribute descriptions such as
+   "certificateRevocationList;binary".
+
+   As values of this syntax contain digitally signed data, values of
+   this syntax and the form of each value MUST be preserved as
+   presented.
+
+2.3.  CertificatePair
+
+      ( 1.3.6.1.4.1.1466.115.121.1.10 DESC 'X.509 Certificate Pair' )
+
+   A value of this syntax is an X.509 CertificatePair [X.509, clause
+   11.2.3].
+
+   Due to changes made to the definition of an X.509 CertificatePair
+   through time, no LDAP-specific encoding is defined for this syntax.
+   Values of this syntax SHOULD be encoded using DER [X.690] and MUST
+   only be transferred using the ;binary transfer option [RFC4522]; that
+   is, by requesting and returning values using attribute descriptions
+   such as "crossCertificatePair;binary".
+
+   As values of this syntax contain digitally signed data, values of
+   this syntax and the form of each value MUST be preserved as
+   presented.
+
+2.4.  SupportedAlgorithm
+
+      ( 1.3.6.1.4.1.1466.115.121.1.49
+           DESC 'X.509 Supported Algorithm' )
+
+   A value of this syntax is an X.509 SupportedAlgorithm [X.509, clause
+   11.2.7].
+
+   Due to changes made to the definition of an X.509 SupportedAlgorithm
+   through time, no LDAP-specific encoding is defined for this syntax.
+   Values of this syntax SHOULD be encoded using DER [X.690] and MUST
+   only be transferred using the ;binary transfer option [RFC4522]; that
+   is, by requesting and returning values using attribute descriptions
+   such as "supportedAlgorithms;binary".
+
+   As values of this syntax contain digitally signed data, values of
+   this syntax and the form of the value MUST be preserved as presented.
+
+
+
+
+
+Zeilenga                    Standards Track                     [Page 3]
+
+RFC 4523                   LDAP X.509 Schema                   June 2006
+
+
+2.5.  CertificateExactAssertion
+
+      ( 1.3.6.1.1.15.1 DESC 'X.509 Certificate Exact Assertion' )
+
+   A value of this syntax is an X.509 CertificateExactAssertion [X.509,
+   clause 11.3.1].  Values of this syntax MUST be encoded using the
+   Generic String Encoding Rules (GSER) [RFC3641].  Appendix A.1
+   provides an equivalent Augmented Backus-Naur Form (ABNF) [RFC4234]
+   grammar for this syntax.
+
+2.6.  CertificateAssertion
+
+      ( 1.3.6.1.1.15.2 DESC 'X.509 Certificate Assertion' )
+
+   A value of this syntax is an X.509 CertificateAssertion [X.509,
+   clause 11.3.2].  Values of this syntax MUST be encoded using GSER
+   [RFC3641].  Appendix A.2 provides an equivalent ABNF [RFC4234]
+   grammar for this syntax.
+
+2.7.  CertificatePairExactAssertion
+
+      ( 1.3.6.1.1.15.3
+           DESC 'X.509 Certificate Pair Exact Assertion' )
+
+   A value of this syntax is an X.509 CertificatePairExactAssertion
+   [X.509, clause 11.3.3].  Values of this syntax MUST be encoded using
+   GSER [RFC3641].  Appendix A.3 provides an equivalent ABNF [RFC4234]
+   grammar for this syntax.
+
+2.8.  CertificatePairAssertion
+
+      ( 1.3.6.1.1.15.4 DESC 'X.509 Certificate Pair Assertion' )
+
+   A value of this syntax is an X.509 CertificatePairAssertion [X.509,
+   clause 11.3.4].  Values of this syntax MUST be encoded using GSER
+   [RFC3641].  Appendix A.4 provides an equivalent ABNF [RFC4234]
+   grammar for this syntax.
+
+2.9.  CertificateListExactAssertion
+
+      ( 1.3.6.1.1.15.5
+           DESC 'X.509 Certificate List Exact Assertion' )
+
+   A value of this syntax is an X.509 CertificateListExactAssertion
+   [X.509, clause 11.3.5].  Values of this syntax MUST be encoded using
+   GSER [RFC3641].  Appendix A.5 provides an equivalent ABNF grammar for
+   this syntax.
+
+
+
+
+Zeilenga                    Standards Track                     [Page 4]
+
+RFC 4523                   LDAP X.509 Schema                   June 2006
+
+
+2.10.  CertificateListAssertion
+
+      ( 1.3.6.1.1.15.6 DESC 'X.509 Certificate List Assertion' )
+
+   A value of this syntax is an X.509 CertificateListAssertion [X.509,
+   clause 11.3.6].  Values of this syntax MUST be encoded using GSER
+   [RFC3641].  Appendix A.6 provides an equivalent ABNF [RFC4234]
+   grammar for this syntax.
+
+2.11.  AlgorithmIdentifier
+
+      ( 1.3.6.1.1.15.7 DESC 'X.509 Algorithm Identifier' )
+
+   A value of this syntax is an X.509 AlgorithmIdentifier [X.509, Clause
+   7].  Values of this syntax MUST be encoded using GSER [RFC3641].
+
+   Appendix A.7 provides an equivalent ABNF [RFC4234] grammar for this
+   syntax.
+
+3.  Matching Rules
+
+   This section introduces a set of certificate and related matching
+   rules for use in LDAP.  These rules are intended to act in accordance
+   with their X.500 counterparts.
+
+3.1.  certificateExactMatch
+
+   The certificateExactMatch matching rule compares the presented
+   certificate exact assertion value with an attribute value of the
+   certificate syntax as described in clause 11.3.1 of [X.509].
+
+      ( 2.5.13.34 NAME 'certificateExactMatch'
+           DESC 'X.509 Certificate Exact Match'
+           SYNTAX 1.3.6.1.1.15.1 )
+
+3.2.  certificateMatch
+
+   The certificateMatch matching rule compares the presented certificate
+   assertion value with an attribute value of the certificate syntax as
+   described in clause 11.3.2 of [X.509].
+
+      ( 2.5.13.35 NAME 'certificateMatch'
+           DESC 'X.509 Certificate Match'
+           SYNTAX 1.3.6.1.1.15.2 )
+
+
+
+
+
+
+
+Zeilenga                    Standards Track                     [Page 5]
+
+RFC 4523                   LDAP X.509 Schema                   June 2006
+
+
+3.3.  certificatePairExactMatch
+
+   The certificatePairExactMatch matching rule compares the presented
+   certificate pair exact assertion value with an attribute value of the
+   certificate pair syntax as described in clause 11.3.3 of [X.509].
+
+      ( 2.5.13.36 NAME 'certificatePairExactMatch'
+           DESC 'X.509 Certificate Pair Exact Match'
+           SYNTAX 1.3.6.1.1.15.3 )
+
+3.4.  certificatePairMatch
+
+   The certificatePairMatch matching rule compares the presented
+   certificate pair assertion value with an attribute value of the
+   certificate pair syntax as described in clause 11.3.4 of [X.509].
+
+      ( 2.5.13.37 NAME 'certificatePairMatch'
+           DESC 'X.509 Certificate Pair Match'
+           SYNTAX 1.3.6.1.1.15.4 )
+
+3.5.  certificateListExactMatch
+
+   The certificateListExactMatch matching rule compares the presented
+   certificate list exact assertion value with an attribute value of the
+   certificate pair syntax as described in clause 11.3.5 of [X.509].
+
+      ( 2.5.13.38 NAME 'certificateListExactMatch'
+           DESC 'X.509 Certificate List Exact Match'
+           SYNTAX 1.3.6.1.1.15.5 )
+
+3.6.  certificateListMatch
+
+   The certificateListMatch matching rule compares the presented
+   certificate list assertion value with an attribute value of the
+   certificate pair syntax as described in clause 11.3.6 of [X.509].
+
+      ( 2.5.13.39 NAME 'certificateListMatch'
+           DESC 'X.509 Certificate List Match'
+           SYNTAX 1.3.6.1.1.15.6 )
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga                    Standards Track                     [Page 6]
+
+RFC 4523                   LDAP X.509 Schema                   June 2006
+
+
+3.7.  algorithmIdentifierMatch
+
+   The algorithmIdentifierMatch mating rule compares a presented
+   algorithm identifier with an attribute value of the supported
+   algorithm as described in clause 11.3.7 of [X.509].
+
+      ( 2.5.13.40 NAME 'algorithmIdentifier'
+           DESC 'X.509 Algorithm Identifier Match'
+           SYNTAX 1.3.6.1.1.15.7 )
+
+4.  Attribute Types
+
+   This section details a set of certificate and related attribute types
+   for use in LDAP.
+
+4.1.  userCertificate
+
+   The userCertificate attribute holds the X.509 certificates issued to
+   the user by one or more certificate authorities, as discussed in
+   clause 11.2.1 of [X.509].
+
+      ( 2.5.4.36 NAME 'userCertificate'
+           DESC 'X.509 user certificate'
+           EQUALITY certificateExactMatch
+           SYNTAX 1.3.6.1.4.1.1466.115.121.1.8 )
+
+   As required by this attribute type's syntax, values of this attribute
+   are requested and transferred using the attribute description
+   "userCertificate;binary".
+
+4.2.  cACertificate
+
+   The cACertificate attribute holds the X.509 certificates issued to
+   the certificate authority (CA), as discussed in clause 11.2.2 of
+   [X.509].
+
+      ( 2.5.4.37 NAME 'cACertificate'
+           DESC 'X.509 CA certificate'
+           EQUALITY certificateExactMatch
+           SYNTAX 1.3.6.1.4.1.1466.115.121.1.8 )
+
+   As required by this attribute type's syntax, values of this attribute
+   are requested and transferred using the attribute description
+   "cACertificate;binary".
+
+
+
+
+
+
+
+Zeilenga                    Standards Track                     [Page 7]
+
+RFC 4523                   LDAP X.509 Schema                   June 2006
+
+
+4.3.  crossCertificatePair
+
+   The crossCertificatePair attribute holds an X.509 certificate pair,
+   as discussed in clause 11.2.3 of [X.509].
+
+      ( 2.5.4.40 NAME 'crossCertificatePair'
+           DESC 'X.509 cross certificate pair'
+           EQUALITY certificatePairExactMatch
+           SYNTAX 1.3.6.1.4.1.1466.115.121.1.10 )
+
+   As required by this attribute type's syntax, values of this attribute
+   are requested and transferred using the attribute description
+   "crossCertificatePair;binary".
+
+4.4.  certificateRevocationList
+
+   The certificateRevocationList attribute holds certificate lists, as
+   discussed in 11.2.4 of [X.509].
+
+      ( 2.5.4.39 NAME 'certificateRevocationList'
+           DESC 'X.509 certificate revocation list'
+           EQUALITY certificateListExactMatch
+           SYNTAX 1.3.6.1.4.1.1466.115.121.1.9 )
+
+   As required by this attribute type's syntax, values of this attribute
+   are requested and transferred using the attribute description
+   "certificateRevocationList;binary".
+
+4.5.  authorityRevocationList
+
+   The authorityRevocationList attribute holds certificate lists, as
+   discussed in 11.2.5 of [X.509].
+
+      ( 2.5.4.38 NAME 'authorityRevocationList'
+           DESC 'X.509 authority revocation list'
+           EQUALITY certificateListExactMatch
+           SYNTAX 1.3.6.1.4.1.1466.115.121.1.9 )
+
+   As required by this attribute type's syntax, values of this attribute
+   are requested and transferred using the attribute description
+   "authorityRevocationList;binary".
+
+
+
+
+
+
+
+
+
+
+Zeilenga                    Standards Track                     [Page 8]
+
+RFC 4523                   LDAP X.509 Schema                   June 2006
+
+
+4.6.  deltaRevocationList
+
+   The deltaRevocationList attribute holds certificate lists, as
+   discussed in 11.2.6 of [X.509].
+
+      ( 2.5.4.53 NAME 'deltaRevocationList'
+           DESC 'X.509 delta revocation list'
+           EQUALITY certificateListExactMatch
+           SYNTAX 1.3.6.1.4.1.1466.115.121.1.9 )
+
+   As required by this attribute type's syntax, values of this attribute
+   MUST be requested and transferred using the attribute description
+   "deltaRevocationList;binary".
+
+4.7.  supportedAlgorithms
+
+   The supportedAlgorithms attribute holds supported algorithms, as
+   discussed in 11.2.7 of [X.509].
+
+      ( 2.5.4.52 NAME 'supportedAlgorithms'
+           DESC 'X.509 supported algorithms'
+           EQUALITY algorithmIdentifierMatch
+           SYNTAX 1.3.6.1.4.1.1466.115.121.1.49 )
+
+   As required by this attribute type's syntax, values of this attribute
+   MUST be requested and transferred using the attribute description
+   "supportedAlgorithms;binary".
+
+5.  Object Classes
+
+   This section details a set of certificate-related object classes for
+   use in LDAP.
+
+5.1.  pkiUser
+
+   This object class is used in augment entries for objects that may be
+   subject to certificates, as defined in clause 11.1.1 of [X.509].
+
+      ( 2.5.6.21 NAME 'pkiUser'
+           DESC 'X.509 PKI User'
+           SUP top AUXILIARY
+           MAY userCertificate )
+
+
+
+
+
+
+
+
+
+Zeilenga                    Standards Track                     [Page 9]
+
+RFC 4523                   LDAP X.509 Schema                   June 2006
+
+
+5.2.  pkiCA
+
+   This object class is used to augment entries for objects that act as
+   certificate authorities, as defined in clause 11.1.2 of [X.509]
+
+      ( 2.5.6.22 NAME 'pkiCA'
+           DESC 'X.509 PKI Certificate Authority'
+           SUP top AUXILIARY
+           MAY ( cACertificate $ certificateRevocationList $
+                authorityRevocationList $ crossCertificatePair ) )
+
+5.3.  cRLDistributionPoint
+
+   This class is used to represent objects that act as CRL distribution
+   points, as discussed in clause 11.1.3 of [X.509].
+
+      ( 2.5.6.19 NAME 'cRLDistributionPoint'
+           DESC 'X.509 CRL distribution point'
+           SUP top STRUCTURAL
+           MUST cn
+           MAY ( certificateRevocationList $
+                authorityRevocationList $ deltaRevocationList ) )
+
+5.4.  deltaCRL
+
+   The deltaCRL object class is used to augment entries to hold delta
+   revocation lists, as discussed in clause 11.1.4 of [X.509].
+
+      ( 2.5.6.23 NAME 'deltaCRL'
+           DESC 'X.509 delta CRL'
+           SUP top AUXILIARY
+           MAY deltaRevocationList )
+
+5.5.  strongAuthenticationUser
+
+   This object class is used to augment entries for objects
+   participating in certificate-based authentication, as defined in
+   clause 6.15 of [X.521].  This object class is deprecated in favor of
+   pkiUser.
+
+      ( 2.5.6.15 NAME 'strongAuthenticationUser'
+           DESC 'X.521 strong authentication user'
+           SUP top AUXILIARY
+           MUST userCertificate )
+
+
+
+
+
+
+
+Zeilenga                    Standards Track                    [Page 10]
+
+RFC 4523                   LDAP X.509 Schema                   June 2006
+
+
+5.6.  userSecurityInformation
+
+   This object class is used to augment entries with needed additional
+   associated security information, as defined in clause 6.16 of
+   [X.521].
+
+      ( 2.5.6.18 NAME 'userSecurityInformation'
+           DESC 'X.521 user security information'
+           SUP top AUXILIARY
+           MAY ( supportedAlgorithms ) )
+
+5.7.  certificationAuthority
+
+   This object class is used to augment entries for objects that act as
+   certificate authorities, as defined in clause 6.17 of [X.521].  This
+   object class is deprecated in favor of pkiCA.
+
+      ( 2.5.6.16 NAME 'certificationAuthority'
+           DESC 'X.509 certificate authority'
+           SUP top AUXILIARY
+           MUST ( authorityRevocationList $
+                certificateRevocationList $ cACertificate )
+           MAY crossCertificatePair )
+
+5.8.  certificationAuthority-V2
+
+   This object class is used to augment entries for objects that act as
+   certificate authorities, as defined in clause 6.18 of [X.521].  This
+   object class is deprecated in favor of pkiCA.
+
+      ( 2.5.6.16.2 NAME 'certificationAuthority-V2'
+           DESC 'X.509 certificate authority, version 2'
+           SUP certificationAuthority AUXILIARY
+           MAY deltaRevocationList )
+
+6.  Security Considerations
+
+   General certificate considerations [RFC3280] apply to LDAP-aware
+   certificate applications.  General LDAP security considerations
+   [RFC4510] apply as well.
+
+   While elements of certificate information are commonly signed, these
+   signatures only protect the integrity of the signed information.  In
+   the absence of data integrity protections in LDAP (or lower layer,
+   e.g., IPsec), a server is not assured that client certificate request
+   (or other request) was unaltered in transit.  Likewise, a client
+   cannot be assured that the results of the query were unaltered in
+
+
+
+
+Zeilenga                    Standards Track                    [Page 11]
+
+RFC 4523                   LDAP X.509 Schema                   June 2006
+
+
+   transit.  Hence, it is generally recommended that implementations
+   make use of authentication and data integrity services in LDAP
+   [RFC4513][RFC4511].
+
+7.  IANA Considerations
+
+7.1.  Object Identifier Registration
+
+   The IANA has registered an LDAP Object Identifier [RFC4520] for use
+   in this technical specification.
+
+      Subject: Request for LDAP OID Registration
+      Person & email address to contact for further information:
+          Kurt Zeilenga <kurt@OpenLDAP.org>
+      Specification: RFC 4523
+      Author/Change Controller: IESG
+      Comments:
+          Identifies the LDAP X.509 Certificate schema elements
+           introduced in this document.
+
+7.2.  Descriptor Registration
+
+   The IANA has updated the LDAP
+   Descriptor registry [RFC44520] as indicated below.
+
+      Subject: Request for LDAP Descriptor Registration
+      Descriptor (short name): see table
+      Object Identifier: see table
+      Person & email address to contact for further information:
+          Kurt Zeilenga <kurt@OpenLDAP.org>
+      Usage: see table
+      Specification: RFC 4523
+      Author/Change Controller: IESG
+
+      algorithmIdentifierMatch     M 2.5.13.40
+      authorityRevocationList      A 2.5.4.38 *
+      cACertificate                A 2.5.4.37 *
+      cRLDistributionPoint         O 2.5.6.19 *
+      certificateExactMatch        M 2.5.13.34
+      certificateListExactMatch    M 2.5.13.38
+      certificateListMatch         M 2.5.13.39
+      certificateMatch             M 2.5.13.35
+      certificatePairExactMatch    M 2.5.13.36
+      certificatePairMatch         M 2.5.13.37
+      certificateRevocationList    A 2.5.4.39 *
+      certificationAuthority       O 2.5.6.16 *
+      certificationAuthority-V2    O 2.5.6.16.2 *
+      crossCertificatePair         A 2.5.4.40 *
+
+
+
+Zeilenga                    Standards Track                    [Page 12]
+
+RFC 4523                   LDAP X.509 Schema                   June 2006
+
+
+      deltaCRL                     O 2.5.6.23 *
+      deltaRevocationList          A 2.5.4.53 *
+      pkiCA                        O 2.5.6.22 *
+      pkiUser                      O 2.5.6.21 *
+      strongAuthenticationUser     O 2.5.6.15 *
+      supportedAlgorithms          A 2.5.4.52 *
+      userCertificate              A 2.5.4.36 *
+      userSecurityInformation      O 2.5.6.18 *
+
+      * Updates previous registration
+
+8.  Acknowledgements
+
+   This document is based on X.509, a product of the ITU-T.  A number of
+   LDAP schema definitions were based on those found in RFCs 2252 and
+   2256, both products of the IETF ASID WG.  The ABNF productions in
+   Appendix A were provided by Steven Legg.  Additional material was
+   borrowed from prior works by David Chadwick and Steven Legg to refine
+   the LDAP X.509 schema.
+
+9.  References
+
+9.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC3641]  Legg, S., "Generic String Encoding Rules (GSER) for ASN.1
+              Types", RFC 3641, October 2003.
+
+   [RFC4510]  Zeilenga, K., Ed., "Lightweight Directory Access Protocol
+              (LDAP): Technical Specification Road Map", RFC 4510, June
+              2006.
+
+   [RFC4512]  Zeilenga, K., "Lightweight Directory Access Protocol
+              (LDAP): Directory Information Models", RFC 4512, June
+              2006.
+
+   [RFC4522]  Legg, S., "Lightweight Directory Access Protocol (LDAP):
+              The Binary Encoding Option", RFC 4522, June 2006.
+
+   [X.509]    International Telecommunication Union - Telecommunication
+              Standardization Sector, "The Directory: Authentication
+              Framework", X.509(2000).
+
+
+
+
+
+
+
+Zeilenga                    Standards Track                    [Page 13]
+
+RFC 4523                   LDAP X.509 Schema                   June 2006
+
+
+   [X.521]    International Telecommunication Union - Telecommunication
+              Standardization Sector, "The Directory: Selected Object
+              Classes", X.521(2000).
+
+   [X.690]    International Telecommunication Union - Telecommunication
+              Standardization Sector, "Specification of ASN.1 encoding
+              rules: Basic Encoding Rules (BER), Canonical Encoding
+              Rules (CER), and Distinguished Encoding Rules (DER)",
+              X.690(2002) (also ISO/IEC 8825-1:2002).
+
+9.2.  Informative References
+
+   [RFC1777]  Yeong, W., Howes, T., and S. Kille, "Lightweight Directory
+              Access Protocol", RFC 1777, March 1995.
+
+   [RFC2156]  Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay):
+              Mapping between X.400 and RFC 822/MIME", RFC 2156, January
+              1998.
+
+   [RFC3280]  Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
+              X.509 Public Key Infrastructure Certificate and
+              Certificate Revocation List (CRL) Profile", RFC 3280,
+              April 2002.
+
+   [RFC3494]  Zeilenga, K., "Lightweight Directory Access Protocol
+              version 2 (LDAPv2) to Historic Status", RFC 3494, March
+              2003.
+
+   [RFC3642]  Legg, S., "Common Elements of Generic String Encoding
+              Rules (GSER) Encodings", RFC 3642, October 2003.
+
+   [RFC4234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
+              Specifications: ABNF", RFC 4234, October 2005.
+
+   [RFC4511]  Sermersheim, J., Ed., "Lightweight Directory Access
+              Protocol (LDAP): The Protocol", RFC 4511, June 2006.
+
+   [RFC4513]  Harrison, R. Ed., "Lightweight Directory Access Protocol
+              (LDAP): Authentication Methods and Security Mechanisms",
+              RFC 4513, June 2006.
+
+   [RFC4520]  Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
+              Considerations for the Lightweight Directory Access
+              Protocol (LDAP)", BCP 64, RFC 4520, June 2006.
+
+
+
+
+
+
+
+Zeilenga                    Standards Track                    [Page 14]
+
+RFC 4523                   LDAP X.509 Schema                   June 2006
+
+
+Appendix A.
+
+   This appendix is informative.
+
+   This appendix provides ABNF [RFC4234] grammars for GSER-based
+   [RFC3641] LDAP-specific encodings specified in this document.  These
+   grammars where produced using, and relying on, Common Elements for
+   GSER Encodings [RFC3642].
+
+A.1.  CertificateExactAssertion
+
+   CertificateExactAssertion = "{" sp cea-serialNumber ","
+        sp cea-issuer sp "}"
+
+   cea-serialNumber = id-serialNumber msp CertificateSerialNumber
+   cea-issuer = id-issuer msp Name
+
+   id-serialNumber =
+        %x73.65.72.69.61.6C.4E.75.6D.62.65.72 ; 'serialNumber'
+   id-issuer = %x69.73.73.75.65.72 ; 'issuer'
+
+   Name = id-rdnSequence ":" RDNSequence
+   id-rdnSequence = %x72.64.6E.53.65.71.75.65.6E.63.65 ; 'rdnSequence'
+
+   CertificateSerialNumber = INTEGER
+
+A.2.  CertificateAssertion
+
+CertificateAssertion = "{" [ sp ca-serialNumber ]
+     [ sep sp ca-issuer ]
+     [ sep sp ca-subjectKeyIdentifier ]
+     [ sep sp ca-authorityKeyIdentifier ]
+     [ sep sp ca-certificateValid ]
+     [ sep sp ca-privateKeyValid ]
+     [ sep sp ca-subjectPublicKeyAlgID ]
+     [ sep sp ca-keyUsage ]
+     [ sep sp ca-subjectAltName ]
+     [ sep sp ca-policy ]
+     [ sep sp ca-pathToName ]
+     [ sep sp ca-subject ]
+     [ sep sp ca-nameConstraints ] sp "}"
+
+ca-serialNumber = id-serialNumber msp CertificateSerialNumber
+ca-issuer = id-issuer msp Name
+ca-subjectKeyIdentifier = id-subjectKeyIdentifier msp
+     SubjectKeyIdentifier
+ca-authorityKeyIdentifier = id-authorityKeyIdentifier msp
+     AuthorityKeyIdentifier
+
+
+
+Zeilenga                    Standards Track                    [Page 15]
+
+RFC 4523                   LDAP X.509 Schema                   June 2006
+
+
+ca-certificateValid = id-certificateValid msp Time
+ca-privateKeyValid = id-privateKeyValid msp GeneralizedTime
+ca-subjectPublicKeyAlgID = id-subjectPublicKeyAlgID msp
+     OBJECT-IDENTIFIER
+ca-keyUsage = id-keyUsage msp KeyUsage
+ca-subjectAltName = id-subjectAltName msp AltNameType
+ca-policy = id-policy msp CertPolicySet
+ca-pathToName = id-pathToName msp Name
+ca-subject = id-subject msp Name
+ca-nameConstraints = id-nameConstraints msp NameConstraintsSyntax
+
+id-subjectKeyIdentifier =
+     %x73.75.62.6A.65.63.74.4B.65.79.49.64.65.6E.74.69.66.69.65.72
+     ; 'subjectKeyIdentifier'
+id-authorityKeyIdentifier =
+     %x61.75.74.68.6F.72.69.74.79.4B.65.79.49.64.65.6E.74.69.66.69.65.72
+     ; 'authorityKeyIdentifier'
+id-certificateValid = %x63.65.72.74.69.66.69.63.61.74.65.56.61.6C.69.64
+     ; 'certificateValid'
+id-privateKeyValid = %x70.72.69.76.61.74.65.4B.65.79.56.61.6C.69.64
+     ; 'privateKeyValid'
+id-subjectPublicKeyAlgID  =
+     %x73.75.62.6A.65.63.74.50.75.62.6C.69.63.4B.65.79.41.6C.67.49.44
+     ; 'subjectPublicKeyAlgID'
+id-keyUsage = %x6B.65.79.55.73.61.67.65 ; 'keyUsage'
+id-subjectAltName = %x73.75.62.6A.65.63.74.41.6C.74.4E.61.6D.65
+     ; 'subjectAltName'
+id-policy = %x70.6F.6C.69.63.79 ; 'policy'
+id-pathToName = %x70.61.74.68.54.6F.4E.61.6D.65 ; 'pathToName'
+id-subject = %x73.75.62.6A.65.63.74 ; 'subject'
+id-nameConstraints = %x6E.61.6D.65.43.6F.6E.73.74.72.61.69.6E.74.73
+     ; 'nameConstraints'
+
+SubjectKeyIdentifier = KeyIdentifier
+
+KeyIdentifier = OCTET-STRING
+
+AuthorityKeyIdentifier = "{" [ sp aki-keyIdentifier ]
+     [ sep sp aki-authorityCertIssuer ]
+     [ sep sp aki-authorityCertSerialNumber ] sp "}"
+
+aki-keyIdentifier = id-keyIdentifier msp KeyIdentifier
+aki-authorityCertIssuer = id-authorityCertIssuer msp GeneralNames
+
+GeneralNames = "{" sp GeneralName *( "," sp GeneralName ) sp "}"
+GeneralName  = gn-otherName
+     / gn-rfc822Name
+     / gn-dNSName
+
+
+
+Zeilenga                    Standards Track                    [Page 16]
+
+RFC 4523                   LDAP X.509 Schema                   June 2006
+
+
+     / gn-x400Address
+     / gn-directoryName
+     / gn-ediPartyName
+     / gn-uniformResourceIdentifier
+     / gn-iPAddress
+     / gn-registeredID
+
+gn-otherName = id-otherName ":" OtherName
+gn-rfc822Name = id-rfc822Name ":" IA5String
+gn-dNSName = id-dNSName ":" IA5String
+gn-x400Address = id-x400Address ":" ORAddress
+gn-directoryName = id-directoryName ":" Name
+gn-ediPartyName = id-ediPartyName ":" EDIPartyName
+gn-iPAddress = id-iPAddress ":" OCTET-STRING
+gn-registeredID = gn-id-registeredID ":" OBJECT-IDENTIFIER
+
+gn-uniformResourceIdentifier = id-uniformResourceIdentifier
+     ":" IA5String
+
+id-otherName = %x6F.74.68.65.72.4E.61.6D.65 ; 'otherName'
+gn-id-registeredID = %x72.65.67.69.73.74.65.72.65.64.49.44
+     ; 'registeredID'
+
+OtherName = "{" sp on-type-id "," sp on-value sp "}"
+on-type-id = id-type-id msp OBJECT-IDENTIFIER
+on-value = id-value msp Value
+     ;; <Value> as defined in Section 3 of [RFC3641]
+
+id-type-id = %x74.79.70.65.2D.69.64 ; 'type-id'
+id-value = %x76.61.6C.75.65 ; 'value'
+
+ORAddress = dquote *SafeIA5Character dquote
+SafeIA5Character = %x01-21 / %x23-7F / ; ASCII minus dquote
+     dquote dquote ; escaped double quote
+dquote = %x22 ; '"' (double quote)
+
+;; Note: The <ORAddress> rule encodes the x400Address component
+;; of a GeneralName as a character string between double quotes.
+;; The character string is first derived according to Section 4.1
+;; of [RFC2156], and then any embedded double quotes are escaped
+;; by being repeated. This resulting string is output between
+;; double quotes.
+
+EDIPartyName = "{" [ sp nameAssigner "," ] sp partyName sp "}"
+nameAssigner = id-nameAssigner msp DirectoryString
+partyName = id-partyName msp DirectoryString
+id-nameAssigner = %x6E.61.6D.65.41.73.73.69.67.6E.65.72
+     ; 'nameAssigner'
+
+
+
+Zeilenga                    Standards Track                    [Page 17]
+
+RFC 4523                   LDAP X.509 Schema                   June 2006
+
+
+id-partyName    = %x70.61.72.74.79.4E.61.6D.65 ; 'partyName'
+
+aki-authorityCertSerialNumber = id-authorityCertSerialNumber
+     msp CertificateSerialNumber
+
+id-keyIdentifier = %x6B.65.79.49.64.65.6E.74.69.66.69.65.72
+     ; 'keyIdentifier'
+id-authorityCertIssuer =
+     %x61.75.74.68.6F.72.69.74.79.43.65.72.74.49.73.73.75.65.72
+     ; 'authorityCertIssuer'
+
+id-authorityCertSerialNumber = %x61.75.74.68.6F.72.69.74.79.43
+     %x65.72.74.53.65.72.69.61.6C.4E.75.6D.62.65.72
+     ; 'authorityCertSerialNumber'
+
+Time = time-utcTime / time-generalizedTime
+time-utcTime = id-utcTime ":" UTCTime
+time-generalizedTime = id-generalizedTime ":" GeneralizedTime
+id-utcTime = %x75.74.63.54.69.6D.65 ; 'utcTime'
+id-generalizedTime = %x67.65.6E.65.72.61.6C.69.7A.65.64.54.69.6D.65
+     ; 'generalizedTime'
+
+KeyUsage = BIT-STRING / key-usage-bit-list
+key-usage-bit-list = "{" [ sp key-usage *( "," sp key-usage ) ] sp "}"
+
+;; Note: The <key-usage-bit-list> rule encodes the one bits in
+;; a KeyUsage value as a comma separated list of identifiers.
+
+key-usage = id-digitalSignature
+     / id-nonRepudiation
+     / id-keyEncipherment
+     / id-dataEncipherment
+     / id-keyAgreement
+     / id-keyCertSign
+     / id-cRLSign
+     / id-encipherOnly
+     / id-decipherOnly
+
+id-digitalSignature = %x64.69.67.69.74.61.6C.53.69.67.6E.61.74
+     %x75.72.65 ; 'digitalSignature'
+id-nonRepudiation   = %x6E.6F.6E.52.65.70.75.64.69.61.74.69.6F.6E
+     ; 'nonRepudiation'
+id-keyEncipherment  = %x6B.65.79.45.6E.63.69.70.68.65.72.6D.65.6E.74
+     ; 'keyEncipherment'
+id-dataEncipherment = %x64.61.74.61.45.6E.63.69.70.68.65.72.6D.65.6E
+     %x74 ; "dataEncipherment'
+id-keyAgreement     = %x6B.65.79.41.67.72.65.65.6D.65.6E.74
+     ; 'keyAgreement'
+
+
+
+Zeilenga                    Standards Track                    [Page 18]
+
+RFC 4523                   LDAP X.509 Schema                   June 2006
+
+
+id-keyCertSign      = %x6B.65.79.43.65.72.74.53.69.67.6E
+     ; 'keyCertSign'
+id-cRLSign          = %x63.52.4C.53.69.67.6E ; "cRLSign"
+id-encipherOnly     = %x65.6E.63.69.70.68.65.72.4F.6E.6C.79
+     ; 'encipherOnly'
+id-decipherOnly     = %x64.65.63.69.70.68.65.72.4F.6E.6C.79
+     ; 'decipherOnly'
+
+AltNameType = ant-builtinNameForm / ant-otherNameForm
+
+ant-builtinNameForm = id-builtinNameForm ":" BuiltinNameForm
+ant-otherNameForm = id-otherNameForm ":" OBJECT-IDENTIFIER
+
+id-builtinNameForm = %x62.75.69.6C.74.69.6E.4E.61.6D.65.46.6F.72.6D
+     ; 'builtinNameForm'
+id-otherNameForm   = %x6F.74.68.65.72.4E.61.6D.65.46.6F.72.6D
+     ; 'otherNameForm'
+
+BuiltinNameForm  = id-rfc822Name
+     / id-dNSName
+     / id-x400Address
+     / id-directoryName
+     / id-ediPartyName
+     / id-uniformResourceIdentifier
+     / id-iPAddress
+     / id-registeredId
+
+id-rfc822Name = %x72.66.63.38.32.32.4E.61.6D.65 ; 'rfc822Name'
+id-dNSName = %x64.4E.53.4E.61.6D.65 ; 'dNSName'
+id-x400Address  = %x78.34.30.30.41.64.64.72.65.73.73 ; 'x400Address'
+id-directoryName = %x64.69.72.65.63.74.6F.72.79.4E.61.6D.65
+     ; 'directoryName'
+id-ediPartyName  = %x65.64.69.50.61.72.74.79.4E.61.6D.65
+     ; 'ediPartyName'
+id-iPAddress = %x69.50.41.64.64.72.65.73.73 ; 'iPAddress'
+id-registeredId = %x72.65.67.69.73.74.65.72.65.64.49.64
+     ; 'registeredId'
+
+id-uniformResourceIdentifier = %x75.6E.69.66.6F.72.6D.52.65.73.6F.75
+     %x72.63.65.49.64.65.6E.74.69.66.69.65.72
+     ; 'uniformResourceIdentifier'
+
+CertPolicySet = "{" sp CertPolicyId *( "," sp CertPolicyId ) sp "}"
+CertPolicyId = OBJECT-IDENTIFIER
+
+NameConstraintsSyntax = "{" [ sp ncs-permittedSubtrees ]
+     [ sep sp ncs-excludedSubtrees ] sp "}"
+
+
+
+
+Zeilenga                    Standards Track                    [Page 19]
+
+RFC 4523                   LDAP X.509 Schema                   June 2006
+
+
+ncs-permittedSubtrees = id-permittedSubtrees msp GeneralSubtrees
+ncs-excludedSubtrees = id-excludedSubtrees  msp GeneralSubtrees
+
+id-permittedSubtrees =
+     %x70.65.72.6D.69.74.74.65.64.53.75.62.74.72.65.65.73
+     ; 'permittedSubtrees'
+id-excludedSubtrees =
+     %x65.78.63.6C.75.64.65.64.53.75.62.74.72.65.65.73
+     ; 'excludedSubtrees'
+
+GeneralSubtrees = "{" sp GeneralSubtree
+     *( "," sp GeneralSubtree ) sp "}"
+GeneralSubtree  = "{" sp gs-base
+     [ "," sp gs-minimum ]
+     [ "," sp gs-maximum ] sp "}"
+
+gs-base = id-base msp GeneralName
+gs-minimum = id-minimum msp BaseDistance
+gs-maximum = id-maximum msp BaseDistance
+
+id-base = %x62.61.73.65 ; 'base'
+id-minimum = %x6D.69.6E.69.6D.75.6D ; 'minimum'
+id-maximum = %x6D.61.78.69.6D.75.6D ; 'maximum'
+
+BaseDistance = INTEGER-0-MAX
+
+A.3.  CertificatePairExactAssertion
+
+  CertificatePairExactAssertion = "{" [ sp cpea-issuedTo ]
+       [sep sp cpea-issuedBy ] sp "}"
+  ;; At least one of <cpea-issuedTo> or <cpea-issuedBy> MUST be present.
+
+  cpea-issuedTo = id-issuedToThisCAAssertion msp
+       CertificateExactAssertion
+  cpea-issuedBy = id-issuedByThisCAAssertion msp
+       CertificateExactAssertion
+
+  id-issuedToThisCAAssertion = %x69.73.73.75.65.64.54.6F.54.68.69.73
+       %x43.41.41.73.73.65.72.74.69.6F.6E ; 'issuedToThisCAAssertion'
+  id-issuedByThisCAAssertion = %x69.73.73.75.65.64.42.79.54.68.69.73
+       %x43.41.41.73.73.65.72.74.69.6F.6E ; 'issuedByThisCAAssertion'
+
+
+
+
+
+
+
+
+
+
+Zeilenga                    Standards Track                    [Page 20]
+
+RFC 4523                   LDAP X.509 Schema                   June 2006
+
+
+A.4.  CertificatePairAssertion
+
+   CertificatePairAssertion = "{" [ sp cpa-issuedTo ]
+        [sep sp cpa-issuedBy ] sp "}"
+   ;; At least one of <cpa-issuedTo> and <cpa-issuedBy> MUST be present.
+
+   cpa-issuedTo = id-issuedToThisCAAssertion msp CertificateAssertion
+   cpa-issuedBy = id-issuedByThisCAAssertion msp CertificateAssertion
+
+A.5.  CertificateListExactAssertion
+
+   CertificateListExactAssertion = "{" sp clea-issuer ","
+        sp clea-thisUpdate
+        [ "," sp clea-distributionPoint ] sp "}"
+
+   clea-issuer = id-issuer msp Name
+   clea-thisUpdate = id-thisUpdate msp Time
+   clea-distributionPoint = id-distributionPoint msp
+        DistributionPointName
+
+   id-thisUpdate = %x74.68.69.73.55.70.64.61.74.65 ; 'thisUpdate'
+   id-distributionPoint =
+        %x64.69.73.74.72.69.62.75.74.69.6F.6E.50.6F.69.6E.74
+        ; 'distributionPoint'
+
+   DistributionPointName = dpn-fullName / dpn-nameRelativeToCRLIssuer
+
+   dpn-fullName = id-fullName ":" GeneralNames
+   dpn-nameRelativeToCRLIssuer = id-nameRelativeToCRLIssuer ":"
+        RelativeDistinguishedName
+
+   id-fullName = %x66.75.6C.6C.4E.61.6D.65 ; 'fullName'
+   id-nameRelativeToCRLIssuer = %x6E.61.6D.65.52.65.6C.61.74.69.76.65
+        %x54.6F.43.52.4C.49.73.73.75.65.72 ; 'nameRelativeToCRLIssuer'
+
+A.6.  CertificateListAssertion
+
+   CertificateListAssertion = "{" [ sp cla-issuer ]
+        [ sep sp cla-minCRLNumber ]
+        [ sep sp cla-maxCRLNumber ]
+        [ sep sp cla-reasonFlags ]
+        [ sep sp cla-dateAndTime ]
+        [ sep sp cla-distributionPoint ]
+        [ sep sp cla-authorityKeyIdentifier ] sp "}"
+
+   cla-issuer = id-issuer msp Name
+   cla-minCRLNumber = id-minCRLNumber msp CRLNumber
+   cla-maxCRLNumber = id-maxCRLNumber msp CRLNumber
+
+
+
+Zeilenga                    Standards Track                    [Page 21]
+
+RFC 4523                   LDAP X.509 Schema                   June 2006
+
+
+   cla-reasonFlags = id-reasonFlags msp ReasonFlags
+   cla-dateAndTime = id-dateAndTime msp Time
+
+   cla-distributionPoint = id-distributionPoint msp
+        DistributionPointName
+
+   cla-authorityKeyIdentifier = id-authorityKeyIdentifier msp
+        AuthorityKeyIdentifier
+
+   id-minCRLNumber = %x6D.69.6E.43.52.4C.4E.75.6D.62.65.72
+        ; 'minCRLNumber'
+   id-maxCRLNumber = %x6D.61.78.43.52.4C.4E.75.6D.62.65.72
+        ; 'maxCRLNumber'
+   id-reasonFlags = %x72.65.61.73.6F.6E.46.6C.61.67.73 ; 'reasonFlags'
+   id-dateAndTime = %x64.61.74.65.41.6E.64.54.69.6D.65 ; 'dateAndTime'
+
+   CRLNumber = INTEGER-0-MAX
+
+   ReasonFlags = BIT-STRING
+        / "{" [ sp reason-flag *( "," sp reason-flag ) ] sp "}"
+
+   reason-flag = id-unused
+        / id-keyCompromise
+        / id-cACompromise
+        / id-affiliationChanged
+        / id-superseded
+        / id-cessationOfOperation
+        / id-certificateHold
+        / id-privilegeWithdrawn
+        / id-aACompromise
+
+   id-unused = %x75.6E.75.73.65.64 ; 'unused'
+   id-keyCompromise = %x6B.65.79.43.6F.6D.70.72.6F.6D.69.73.65
+        ; 'keyCompromise'
+   id-cACompromise = %x63.41.43.6F.6D.70.72.6F.6D.69.73.65
+        ; 'cACompromise'
+   id-affiliationChanged =
+        %x61.66.66.69.6C.69.61.74.69.6F.6E.43.68.61.6E.67.65.64
+        ; 'affiliationChanged'
+   id-superseded = %x73.75.70.65.72.73.65.64.65.64 ; 'superseded'
+   id-cessationOfOperation =
+        %x63.65.73.73.61.74.69.6F.6E.4F.66.4F.70.65.72.61.74.69.6F.6E
+        ; 'cessationOfOperation'
+   id-certificateHold = %x63.65.72.74.69.66.69.63.61.74.65.48.6F.6C.64
+        ; 'certificateHold'
+   id-privilegeWithdrawn =
+        %x70.72.69.76.69.6C.65.67.65.57.69.74.68.64.72.61.77.6E
+        ; 'privilegeWithdrawn'
+
+
+
+Zeilenga                    Standards Track                    [Page 22]
+
+RFC 4523                   LDAP X.509 Schema                   June 2006
+
+
+   id-aACompromise = %x61.41.43.6F.6D.70.72.6F.6D.69.73.65
+        ; 'aACompromise'
+
+A.7.  AlgorithmIdentifier
+
+   AlgorithmIdentifier = "{" sp ai-algorithm
+        [ "," sp ai-parameters ] sp "}"
+
+   ai-algorithm = id-algorithm msp OBJECT-IDENTIFIER
+   ai-parameters = id-parameters msp Value
+   id-algorithm = %x61.6C.67.6F.72.69.74.68.6D ; 'algorithm'
+   id-parameters = %x70.61.72.61.6D.65.74.65.72.73 ; 'parameters'
+
+Author's Address
+
+   Kurt D. Zeilenga
+   OpenLDAP Foundation
+
+   EMail: Kurt@OpenLDAP.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga                    Standards Track                    [Page 23]
+
+RFC 4523                   LDAP X.509 Schema                   June 2006
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2006).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Zeilenga                    Standards Track                    [Page 24]
+
diff --git a/source4/ldap_server/devdocs/rfc4524.txt b/source4/ldap_server/devdocs/rfc4524.txt
new file mode 100644
index 0000000000..fa36be27a3
--- /dev/null
+++ b/source4/ldap_server/devdocs/rfc4524.txt
@@ -0,0 +1,1403 @@
+
+
+
+
+
+
+Network Working Group                                   K. Zeilenga, Ed.
+Request for Comments: 4524                           OpenLDAP Foundation
+Obsoletes: 1274                                                June 2006
+Updates: 2247, 2798
+Category: Standards Track
+
+
+                        COSINE LDAP/X.500 Schema
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   This document provides a collection of schema elements for use with
+   the Lightweight Directory Access Protocol (LDAP) from the COSINE and
+   Internet X.500 pilot projects.
+
+   This document obsoletes RFC 1274 and updates RFCs 2247 and 2798.
+
+Table of Contents
+
+   1. Introduction ....................................................3
+      1.1. Relationship to Other Documents ............................3
+      1.2. Terminology and Conventions ................................4
+   2. COSINE Attribute Types ..........................................4
+      2.1. associatedDomain ...........................................4
+      2.2. associatedName .............................................5
+      2.3. buildingName ...............................................5
+      2.4. co .........................................................5
+      2.5. documentAuthor .............................................6
+      2.6. documentIdentifier .........................................6
+      2.7. documentLocation ...........................................6
+      2.8. documentPublisher ..........................................7
+      2.9. documentTitle ..............................................7
+      2.10. documentVersion ...........................................7
+      2.11. drink .....................................................8
+      2.12. homePhone .................................................8
+      2.13. homePostalAddress .........................................8
+
+
+
+Zeilenga                    Standards Track                     [Page 1]
+
+RFC 4524                COSINE LDAP/X.500 Schema               June 2006
+
+
+      2.14. host ......................................................9
+      2.15. info ......................................................9
+      2.16. mail ......................................................9
+      2.17. manager ..................................................10
+      2.18. mobile ...................................................10
+      2.19. organizationalStatus .....................................11
+      2.20. pager ....................................................11
+      2.21. personalTitle ............................................11
+      2.22. roomNumber ...............................................12
+      2.23. secretary ................................................12
+      2.24. uniqueIdentifier .........................................12
+      2.25. userClass ................................................13
+   3. COSINE Object Classes ..........................................13
+      3.1. account ...................................................13
+      3.2. document ..................................................14
+      3.3. documentSeries ............................................14
+      3.4. domain ....................................................15
+      3.5. domainRelatedObject .......................................16
+      3.6. friendlyCountry ...........................................16
+      3.7. rFC822LocalPart ...........................................17
+      3.8. room ......................................................18
+      3.9. simpleSecurityObject ......................................18
+   4. Security Considerations ........................................18
+   5. IANA Considerations ............................................19
+   6. Acknowledgements ...............................................20
+   7. References .....................................................20
+      7.1. Normative References ......................................20
+      7.2. Informative References ....................................21
+   Appendix A.  Changes since RFC 1274 ...............................23
+      A.1.  LDAP Short Names .........................................23
+      A.2.  pilotObject ..............................................23
+      A.3.  pilotPerson ..............................................23
+      A.4.  dNSDomain ................................................24
+      A.5.  pilotDSA and qualityLabelledData .........................24
+      A.6.  Attribute Syntaxes .......................................24
+   Appendix B.  Changes since RFC 2247 ...............................24
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga                    Standards Track                     [Page 2]
+
+RFC 4524                COSINE LDAP/X.500 Schema               June 2006
+
+
+1.  Introduction
+
+   In the late 1980s, X.500 Directory Services were standardized by the
+   CCITT (Commite' Consultatif International de Telegraphique et
+   Telephonique), now a part of the ITU (International Telephone Union).
+   This lead to Directory Service piloting activities in the early
+   1990s, including the COSINE (Co-operation and Open Systems
+   Interconnection in Europe) PARADISE Project pilot [COSINEpilot] in
+   Europe.  Motivated by needs for large-scale directory pilots, RFC
+   1274 was published to standardize the directory schema and naming
+   architecture for use in the COSINE and other Internet X.500 pilots
+   [RFC1274].
+
+   In the years that followed, X.500 Directory Services have evolved to
+   incorporate new capabilities and even new protocols.  In particular,
+   the Lightweight Directory Access Protocol (LDAP) [RFC4510] was
+   introduced in the early 1990s [RFC1487], with Version 3 of LDAP
+   introduced in the late 1990s [RFC2251] and subsequently revised in
+   2005 [RFC4510].
+
+   While much of the material in RFC 1274 has been superceded by
+   subsequently published ITU-T Recommendations and IETF RFCs, many of
+   the schema elements lack standardized schema descriptions for use in
+   modern X.500 and LDAP directory services despite the fact that these
+   schema elements are in wide use today.  As the old schema
+   descriptions cannot be used without adaptation, interoperability
+   issues may arise due to lack of standardized modern schema
+   descriptions.
+
+   This document addresses these issues by offering standardized schema
+   descriptions, where needed, for widely used COSINE schema elements.
+
+1.1.  Relationship to Other Documents
+
+   This document, together with [RFC4519] and [RFC4517], obsoletes RFC
+   1274 in its entirety.  [RFC4519] replaces Sections 9.3.1 (Userid) and
+   9.3.21 (Domain Component) of RFC 1274.  [RFC4517] replaces Section
+   9.4 (Generally useful syntaxes) of RFC 1274.
+
+   This document replaces the remainder of RFC 1274.  Appendix A
+   discusses changes since RFC 1274, as well as why certain schema
+   elements were not brought forward in this revision of the COSINE
+   schema.  All elements not brought are to be regarded as Historic.
+
+   The description of the 'domain' object class provided in this
+   document supercedes that found in RFC 2247.  That is, Section 3.4 of
+   this document replaces Section 5.2 of [RFC2247].
+
+
+
+
+Zeilenga                    Standards Track                     [Page 3]
+
+RFC 4524                COSINE LDAP/X.500 Schema               June 2006
+
+
+   Some of the schema elements specified here were described in RFC 2798
+   (inetOrgPerson schema).  This document supersedes these descriptions.
+   This document, together with [RFC4519], replaces Section 9.1.3 of RFC
+   2798.
+
+1.2.  Terminology and Conventions
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in BCP 14 [RFC2119].
+
+   DIT stands for Directory Information Tree.
+   DN stands for Distinguished Name.
+   DSA stands for Directory System Agent, a server.
+   DSE stands for DSA-Specific Entry.
+   DUA stands for Directory User Agent, a client.
+
+   These terms are discussed in [RFC4512].
+
+   Schema definitions are provided using LDAP description formats
+   [RFC4512].  Definitions provided here are formatted (line wrapped)
+   for readability.
+
+2.  COSINE Attribute Types
+
+   This section details COSINE attribute types for use in LDAP.
+
+2.1.  associatedDomain
+
+   The 'associatedDomain' attribute specifies DNS [RFC1034][RFC2181]
+   host names [RFC1123] that are associated with an object.   That is,
+   values of this attribute should conform to the following ABNF:
+
+    domain = root / label *( DOT label )
+    root   = SPACE
+    label  = LETDIG [ *61( LETDIG / HYPHEN ) LETDIG ]
+    LETDIG = %x30-39 / %x41-5A / %x61-7A ; "0" - "9" / "A"-"Z" / "a"-"z"
+    SPACE  = %x20                        ; space (" ")
+    HYPHEN = %x2D                        ; hyphen ("-")
+    DOT    = %x2E                        ; period (".")
+
+   For example, the entry in the DIT with a DN <DC=example,DC=com> might
+   have an associated domain of "example.com".
+
+      ( 0.9.2342.19200300.100.1.37 NAME 'associatedDomain'
+        EQUALITY caseIgnoreIA5Match
+        SUBSTR caseIgnoreIA5SubstringsMatch
+        SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
+
+
+
+Zeilenga                    Standards Track                     [Page 4]
+
+RFC 4524                COSINE LDAP/X.500 Schema               June 2006
+
+
+   The IA5String (1.3.6.1.4.1.1466.115.121.1.26) syntax and the
+   'caseIgnoreIA5Match' and 'caseIgnoreIA5SubstringsMatch' rules are
+   described in [RFC4517].
+
+   Note that the directory will not ensure that values of this attribute
+   conform to the <domain> production provided above.  It is the
+   application's responsibility to ensure that domains it stores in this
+   attribute are appropriately represented.
+
+   Also note that applications supporting Internationalized Domain Names
+   SHALL use the ToASCII method [RFC3490] to produce <label> components
+   of the <domain> production.
+
+2.2.  associatedName
+
+   The 'associatedName' attribute specifies names of entries in the
+   organizational DIT associated with a DNS domain [RFC1034][RFC2181].
+
+      ( 0.9.2342.19200300.100.1.38 NAME 'associatedName'
+        EQUALITY distinguishedNameMatch
+        SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
+
+   The DistinguishedName (1.3.6.1.4.1.1466.115.121.1.12) syntax and the
+   'distinguishedNameMatch' rule are described in [RFC4517].
+
+2.3.  buildingName
+
+   The 'buildingName' attribute specifies names of the buildings where
+   an organization or organizational unit is based, for example, "The
+   White House".
+
+      ( 0.9.2342.19200300.100.1.48 NAME 'buildingName'
+        EQUALITY caseIgnoreMatch
+        SUBSTR caseIgnoreSubstringsMatch
+        SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
+
+   The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the
+   'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described
+   in [RFC4517].
+
+2.4.  co
+
+   The 'co' (Friendly Country Name) attribute specifies names of
+   countries in human-readable format, for example, "Germany" and
+   "Federal Republic of Germany".  It is commonly used in conjunction
+   with the 'c' (Country Name) [RFC4519] attribute (whose values are
+   restricted to the two-letter codes defined in [ISO3166]).
+
+
+
+
+Zeilenga                    Standards Track                     [Page 5]
+
+RFC 4524                COSINE LDAP/X.500 Schema               June 2006
+
+
+      ( 0.9.2342.19200300.100.1.43 NAME 'co'
+        EQUALITY caseIgnoreMatch
+        SUBSTR caseIgnoreSubstringsMatch
+        SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+   The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the
+   'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described
+   in [RFC4517].
+
+2.5.  documentAuthor
+
+   The 'documentAuthor' attribute specifies the distinguished names of
+   authors (or editors) of a document.  For example,
+
+      ( 0.9.2342.19200300.100.1.14 NAME 'documentAuthor'
+        EQUALITY distinguishedNameMatch
+        SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
+
+   The DistinguishedName (1.3.6.1.4.1.1466.115.121.1.12) syntax and the
+   'distinguishedNameMatch' rule are described in [RFC4517].
+
+2.6.  documentIdentifier
+
+   The 'documentIdentifier' attribute specifies unique identifiers for a
+   document.  A document may be identified by more than one unique
+   identifier.  For example, RFC 3383 and BCP 64 are unique identifiers
+   that (presently) refer to the same document.
+
+      ( 0.9.2342.19200300.100.1.11 NAME 'documentIdentifier'
+        EQUALITY caseIgnoreMatch
+        SUBSTR caseIgnoreSubstringsMatch
+        SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
+
+   The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the
+   'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described
+   in [RFC4517].
+
+2.7.  documentLocation
+
+   The 'documentLocation' attribute specifies locations of the document
+   original.
+
+      ( 0.9.2342.19200300.100.1.15 NAME 'documentLocation'
+        EQUALITY caseIgnoreMatch
+        SUBSTR caseIgnoreSubstringsMatch
+        SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
+
+
+
+
+
+Zeilenga                    Standards Track                     [Page 6]
+
+RFC 4524                COSINE LDAP/X.500 Schema               June 2006
+
+
+   The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the
+   'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described
+   in [RFC4517].
+
+2.8.  documentPublisher
+
+   The 'documentPublisher' attribute is the persons and/or organizations
+   that published the document.  Documents that are jointly published
+   have one value for each publisher.
+
+      ( 0.9.2342.19200300.100.1.56 NAME 'documentPublisher'
+        EQUALITY caseIgnoreMatch
+        SUBSTR caseIgnoreSubstringsMatch
+        SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+   The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the
+   'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described
+   in [RFC4517].
+
+2.9.  documentTitle
+
+   The 'documentTitle' attribute specifies the titles of a document.
+   Multiple values are allowed to accommodate both long and short
+   titles, or other situations where a document has multiple titles, for
+   example, "The Lightweight Directory Access Protocol Technical
+   Specification" and "The LDAP Technical Specification".
+
+      ( 0.9.2342.19200300.100.1.12 NAME 'documentTitle'
+        EQUALITY caseIgnoreMatch
+        SUBSTR caseIgnoreSubstringsMatch
+        SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
+
+   The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the
+   'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described
+   in [RFC4517].
+
+2.10.  documentVersion
+
+   The 'documentVersion' attribute specifies the version information of
+   a document.
+
+      ( 0.9.2342.19200300.100.1.13 NAME 'documentVersion'
+        EQUALITY caseIgnoreMatch
+        SUBSTR caseIgnoreSubstringsMatch
+        SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
+
+
+
+
+
+
+Zeilenga                    Standards Track                     [Page 7]
+
+RFC 4524                COSINE LDAP/X.500 Schema               June 2006
+
+
+   The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the
+   'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described
+   in [RFC4517].
+
+2.11.  drink
+
+   The 'drink' (favoriteDrink) attribute specifies the favorite drinks
+   of an object (or person), for instance, "cola" and "beer".
+
+      ( 0.9.2342.19200300.100.1.5 NAME 'drink'
+        EQUALITY caseIgnoreMatch
+        SUBSTR caseIgnoreSubstringsMatch
+        SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
+
+   The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the
+   'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described
+   in [RFC4517].
+
+2.12.  homePhone
+
+   The 'homePhone' (Home Telephone Number) attribute specifies home
+   telephone numbers (e.g., "+1 775 555 1234") associated with a person.
+
+      ( 0.9.2342.19200300.100.1.20 NAME 'homePhone'
+        EQUALITY telephoneNumberMatch
+        SUBSTR telephoneNumberSubstringsMatch
+        SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 )
+
+   The telephoneNumber (1.3.6.1.4.1.1466.115.121.1.50) syntax and the
+   'telephoneNumberMatch' and 'telephoneNumberSubstringsMatch' rules are
+   described in [RFC4517].
+
+2.13.  homePostalAddress
+
+   The 'homePostalAddress' attribute specifies home postal addresses for
+   an object.  Each value should be limited to up to 6 directory strings
+   of 30 characters each.  (Note: It is not intended that the directory
+   service enforce these limits.)
+
+      ( 0.9.2342.19200300.100.1.39 NAME 'homePostalAddress'
+        EQUALITY caseIgnoreListMatch
+        SUBSTR caseIgnoreListSubstringsMatch
+        SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 )
+
+   The PostalAddress (1.3.6.1.4.1.1466.115.121.1.41) syntax and the
+   'caseIgnoreListMatch' and 'caseIgnoreListSubstringsMatch' rules are
+   described in [RFC4517].
+
+
+
+
+Zeilenga                    Standards Track                     [Page 8]
+
+RFC 4524                COSINE LDAP/X.500 Schema               June 2006
+
+
+2.14.  host
+
+   The 'host' attribute specifies host computers, generally by their
+   primary fully qualified domain name (e.g., my-host.example.com).
+
+      ( 0.9.2342.19200300.100.1.9 NAME 'host'
+        EQUALITY caseIgnoreMatch
+        SUBSTR caseIgnoreSubstringsMatch
+        SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
+
+   The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the
+   'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described
+   in [RFC4517].
+
+2.15.  info
+
+   The 'info' attribute specifies any general information pertinent to
+   an object.  This information is not necessarily descriptive of the
+   object.
+
+   Applications should not attach specific semantics to values of this
+   attribute.  The 'description' attribute [RFC4519] is available for
+   specifying descriptive information pertinent to an object.
+
+      ( 0.9.2342.19200300.100.1.4 NAME 'info'
+        EQUALITY caseIgnoreMatch
+        SUBSTR caseIgnoreSubstringsMatch
+        SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{2048} )
+
+   The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the
+   'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described
+   in [RFC4517].
+
+2.16.  mail
+
+   The 'mail' (rfc822mailbox) attribute type holds Internet mail
+   addresses in Mailbox [RFC2821] form (e.g., user@example.com).
+
+      ( 0.9.2342.19200300.100.1.3 NAME 'mail'
+        EQUALITY caseIgnoreIA5Match
+        SUBSTR caseIgnoreIA5SubstringsMatch
+        SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} )
+
+   The IA5String (1.3.6.1.4.1.1466.115.121.1.26) syntax and the
+   'caseIgnoreIA5Match' and 'caseIgnoreIA5SubstringsMatch' rules are
+   described in [RFC4517].
+
+
+
+
+
+Zeilenga                    Standards Track                     [Page 9]
+
+RFC 4524                COSINE LDAP/X.500 Schema               June 2006
+
+
+   Note that the directory will not ensure that values of this attribute
+   conform to the <Mailbox> production [RFC2821].  It is the
+   application's responsibility to ensure that domains it stores in this
+   attribute are appropriately represented.
+
+   Additionally, the directory will compare values per the matching
+   rules named in the above attribute type description.  As these rules
+   differ from rules that normally apply to <Mailbox> comparisons,
+   operational issues may arise.  For example, the assertion
+   (mail=joe@example.com) will match "JOE@example.com" even though the
+   <local-parts> differ.  Also, where a user has two <Mailbox>es whose
+   addresses differ only by case of the <local-part>, both cannot be
+   listed as values of the user's mail attribute (as they are considered
+   equal by the 'caseIgnoreIA5Match' rule).
+
+   Also note that applications supporting internationalized domain names
+   SHALL use the ToASCII method [RFC3490] to produce <sub-domain>
+   components of the <Mailbox> production.
+
+2.17.  manager
+
+   The 'manager' attribute specifies managers, by distinguished name, of
+   the person (or entity).
+
+      ( 0.9.2342.19200300.100.1.10 NAME 'manager'
+        EQUALITY distinguishedNameMatch
+        SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
+
+   The DistinguishedName (1.3.6.1.4.1.1466.115.121.1.12) syntax and the
+   'distinguishedNameMatch' rule are described in [RFC4517].
+
+2.18.  mobile
+
+   The 'mobile' (mobileTelephoneNumber) attribute specifies mobile
+   telephone numbers (e.g., "+1 775 555 6789") associated with a person
+   (or entity).
+
+      ( 0.9.2342.19200300.100.1.41 NAME 'mobile'
+        EQUALITY telephoneNumberMatch
+        SUBSTR telephoneNumberSubstringsMatch
+        SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 )
+
+   The telephoneNumber (1.3.6.1.4.1.1466.115.121.1.50) syntax and the
+   'telephoneNumberMatch' and 'telephoneNumberSubstringsMatch' rules are
+   described in [RFC4517].
+
+
+
+
+
+
+Zeilenga                    Standards Track                    [Page 10]
+
+RFC 4524                COSINE LDAP/X.500 Schema               June 2006
+
+
+2.19.  organizationalStatus
+
+   The 'organizationalStatus' attribute specifies categories by which a
+   person is often referred to in an organization.  Examples of usage in
+   academia might include "undergraduate student", "researcher",
+   "professor", and "staff".  Multiple values are allowed where the
+   person is in multiple categories.
+
+   Directory administrators and application designers SHOULD consider
+   carefully the distinctions between this and the 'title' and
+   'userClass' attributes.
+
+      ( 0.9.2342.19200300.100.1.45 NAME 'organizationalStatus'
+        EQUALITY caseIgnoreMatch
+        SUBSTR caseIgnoreSubstringsMatch
+        SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
+
+   The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the
+   'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described
+   in [RFC4517].
+
+2.20.  pager
+
+   The 'pager' (pagerTelephoneNumber) attribute specifies pager
+   telephone numbers (e.g., "+1 775 555 5555") for an object.
+
+      ( 0.9.2342.19200300.100.1.42 NAME 'pager'
+        EQUALITY telephoneNumberMatch
+        SUBSTR telephoneNumberSubstringsMatch
+        SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 )
+
+   The telephoneNumber (1.3.6.1.4.1.1466.115.121.1.50) syntax and the
+   'telephoneNumberMatch' and 'telephoneNumberSubstringsMatch' rules are
+   described in [RFC4517].
+
+2.21.  personalTitle
+
+   The 'personalTitle' attribute specifies personal titles for a person.
+   Examples of personal titles are "Frau", "Dr.", "Herr", and
+   "Professor".
+
+      ( 0.9.2342.19200300.100.1.40 NAME 'personalTitle'
+        EQUALITY caseIgnoreMatch
+        SUBSTR caseIgnoreSubstringsMatch
+        SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
+
+
+
+
+
+
+Zeilenga                    Standards Track                    [Page 11]
+
+RFC 4524                COSINE LDAP/X.500 Schema               June 2006
+
+
+   The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the
+   'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described
+   in [RFC4517].
+
+2.22.  roomNumber
+
+   The 'roomNumber' attribute specifies the room number of an object.
+   During periods of renumbering, or in other circumstances where a room
+   has multiple valid room numbers associated with it, multiple values
+   may be provided.  Note that the 'cn' (commonName) attribute type
+   SHOULD be used for naming room objects.
+
+      ( 0.9.2342.19200300.100.1.6 NAME 'roomNumber'
+        EQUALITY caseIgnoreMatch
+        SUBSTR caseIgnoreSubstringsMatch
+        SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
+
+   The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the
+   'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described
+   in [RFC4517].
+
+2.23.  secretary
+
+   The 'secretary' attribute specifies secretaries and/or administrative
+   assistants, by distinguished name.
+
+      ( 0.9.2342.19200300.100.1.21 NAME 'secretary'
+        EQUALITY distinguishedNameMatch
+        SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
+
+   The DistinguishedName (1.3.6.1.4.1.1466.115.121.1.12) syntax and the
+   'distinguishedNameMatch' rule are described in [RFC4517].
+
+2.24.  uniqueIdentifier
+
+   The 'uniqueIdentifier' attribute specifies a unique identifier for an
+   object represented in the Directory.  The domain within which the
+   identifier is unique and the exact semantics of the identifier are
+   for local definition.  For a person, this might be an institution-
+   wide payroll number.  For an organizational unit, it might be a
+   department code.
+
+      ( 0.9.2342.19200300.100.1.44 NAME 'uniqueIdentifier'
+        EQUALITY caseIgnoreMatch
+        SUBSTR caseIgnoreSubstringsMatch
+        SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
+
+
+
+
+
+Zeilenga                    Standards Track                    [Page 12]
+
+RFC 4524                COSINE LDAP/X.500 Schema               June 2006
+
+
+   The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the
+   'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described
+   in [RFC4517].
+
+   Note: X.520 also describes an attribute called 'uniqueIdentifier'
+         (2.5.4.45), which is called 'x500UniqueIdentifier' in LDAP
+         [RFC4519].  The attribute detailed here ought not be confused
+         with 'x500UniqueIdentifier'.
+
+2.25.  userClass
+
+   The 'userClass' attribute specifies categories of computer or
+   application user.  The semantics placed on this attribute are for
+   local interpretation.  Examples of current usage of this attribute in
+   academia are "student", "staff", and "faculty".  Note that the
+   'organizationalStatus' attribute type is now often preferred, as it
+   makes no distinction between persons as opposed to users.
+
+      ( 0.9.2342.19200300.100.1.8 NAME 'userClass'
+        EQUALITY caseIgnoreMatch
+        SUBSTR caseIgnoreSubstringsMatch
+        SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
+
+   The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the
+   'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described
+   in [RFC4517].
+
+3.  COSINE Object Classes
+
+   This section details COSINE object classes for use in LDAP.
+
+3.1.  account
+
+   The 'account' object class is used to define entries representing
+   computer accounts.  The 'uid' attribute SHOULD be used for naming
+   entries of this object class.
+
+      ( 0.9.2342.19200300.100.4.5 NAME 'account'
+        SUP top STRUCTURAL
+        MUST uid
+        MAY ( description $ seeAlso $ l $ o $ ou $ host ) )
+
+   The 'top' object class is described in [RFC4512].  The 'description',
+   'seeAlso', 'l', 'o', 'ou', and 'uid' attribute types are described in
+   [RFC4519].  The 'host' attribute type is described in Section 2 of
+   this document.
+
+
+
+
+
+Zeilenga                    Standards Track                    [Page 13]
+
+RFC 4524                COSINE LDAP/X.500 Schema               June 2006
+
+
+   3.3.  documentSeriesExample:
+
+      dn: uid=kdz,cn=Accounts,dc=Example,dc=COM
+      objectClass: account
+      uid: kdz
+      seeAlso: cn=Kurt D. Zeilenga,cn=Persons,dc=Example,dc=COM
+
+3.2.  document
+
+   The 'document' object class is used to define entries that represent
+   documents.
+
+      ( 0.9.2342.19200300.100.4.6 NAME 'document'
+        SUP top STRUCTURAL
+        MUST documentIdentifier
+        MAY ( cn $ description $ seeAlso $ l $ o $ ou $
+          documentTitle $ documentVersion $ documentAuthor $
+          documentLocation $ documentPublisher ) )
+
+   The 'top' object class is described in [RFC4512].  The 'cn',
+   'description', 'seeAlso', 'l', 'o', and 'ou' attribute types are
+   described in [RFC4519].  The 'documentIdentifier', 'documentTitle',
+   'documentVersion', 'documentAuthor', 'documentLocation', and
+   'documentPublisher' attribute types are described in Section 2 of
+   this document.
+
+   Example:
+
+      dn: documentIdentifier=RFC 4524,cn=RFC,dc=Example,dc=COM
+      objectClass: document
+      documentIdentifier: RFC 4524
+      documentTitle: COSINE LDAP/X.500 Schema
+      documentAuthor: cn=Kurt D. Zeilenga,cn=Persons,dc=Example,dc=COM
+      documentLocation: http://www.rfc-editor.org/rfc/rfc4524.txt
+      documentPublisher: Internet Engineering Task Force
+      description: A collection of schema elements for use in LDAP
+      description: Obsoletes RFC 1274
+      seeAlso: documentIdentifier=RFC 4510,cn=RFC,dc=Example,dc=COM
+      seeAlso: documentIdentifier=RFC 1274,cn=RFC,dc=Example,dc=COM
+
+3.3.  documentSeries
+
+   The 'documentSeries' object class is used to define an entry that
+   represents a series of documents (e.g., The Request For Comments
+   memos).
+
+
+
+
+
+
+Zeilenga                    Standards Track                    [Page 14]
+
+RFC 4524                COSINE LDAP/X.500 Schema               June 2006
+
+
+      ( 0.9.2342.19200300.100.4.9 NAME 'documentSeries'
+        SUP top STRUCTURAL
+        MUST cn
+        MAY ( description $ l $ o $ ou $ seeAlso $
+          telephonenumber ) )
+
+   The 'top' object class is described in [RFC4512].  The 'description',
+   'l', 'o', 'ou', 'seeAlso', and 'telephoneNumber' attribute types are
+   described in [RFC4519].
+
+   Example:
+
+      dn: cn=RFC,dc=Example,dc=COM
+      objectClass: documentSeries
+      cn: Request for Comments
+      cn: RFC
+      description: a series of memos about the Internet
+
+3.4.  domain
+
+   The 'domain' object class is used to define entries that represent
+   DNS domains for objects that are not organizations, organizational
+   units, or other kinds of objects more appropriately defined using an
+   object class specific to the kind of object being defined (e.g.,
+   'organization', 'organizationUnit').
+
+   The 'dc' attribute should be used for naming entries of the 'domain'
+   object class.
+
+      ( 0.9.2342.19200300.100.4.13 NAME 'domain'
+        SUP top STRUCTURAL
+        MUST dc
+        MAY ( userPassword $ searchGuide $ seeAlso $ businessCategory $
+          x121Address $ registeredAddress $ destinationIndicator $
+          preferredDeliveryMethod $ telexNumber $
+          teletexTerminalIdentifier $ telephoneNumber $
+          internationaliSDNNumber $ facsimileTelephoneNumber $ street $
+          postOfficeBox $ postalCode $ postalAddress $
+          physicalDeliveryOfficeName $ st $ l $ description $ o $
+          associatedName ) )
+
+   The 'top' object class and the 'dc', 'userPassword', 'searchGuide',
+   'seeAlso', 'businessCategory', 'x121Address', 'registeredAddress',
+   'destinationIndicator', 'preferredDeliveryMethod', 'telexNumber',
+   'teletexTerminalIdentifier', 'telephoneNumber',
+   'internationaliSDNNumber', 'facsimileTelephoneNumber', 'street',
+   'postOfficeBox', 'postalCode', 'postalAddress',
+   'physicalDeliveryOfficeName', 'st', 'l', 'description', and 'o' types
+
+
+
+Zeilenga                    Standards Track                    [Page 15]
+
+RFC 4524                COSINE LDAP/X.500 Schema               June 2006
+
+
+   are described in [RFC4519].  The 'associatedName' attribute type is
+   described in Section 2 of this document.
+
+   Example:
+
+      dn: dc=com
+      objectClass: domain
+      dc: com
+      description: the .COM TLD
+
+3.5.  domainRelatedObject
+
+   The 'domainRelatedObject' object class is used to define entries that
+   represent DNS domains that are "equivalent" to an X.500 domain, e.g.,
+   an organization or organizational unit.
+
+      ( 0.9.2342.19200300.100.4.17 NAME 'domainRelatedObject'
+        SUP top AUXILIARY
+        MUST associatedDomain )
+
+   The 'top' object class is described in [RFC4512].  The
+   'associatedDomain' attribute type is described in Section 2 of this
+   document.
+
+   Example:
+
+      dn: dc=example,dc=com
+      objectClass: organization
+      objectClass: dcObject
+      objectClass: domainRelatedObject
+      dc: example
+      associatedDomain: example.com
+      o: Example Organization
+
+   The 'organization' and 'dcObject' object classes and the 'dc' and 'o'
+   attribute types are described in [RFC4519].
+
+3.6.  friendlyCountry
+
+   The 'friendlyCountry' object class is used to define entries
+   representing countries in the DIT.  The object class is used to allow
+   friendlier naming of countries than that allowed by the object class
+   'country' [RFC4519].
+
+      ( 0.9.2342.19200300.100.4.18 NAME 'friendlyCountry'
+        SUP country STRUCTURAL
+        MUST co )
+
+
+
+
+Zeilenga                    Standards Track                    [Page 16]
+
+RFC 4524                COSINE LDAP/X.500 Schema               June 2006
+
+
+   The 'country' object class is described in [RFC4519].  The 'co'
+   attribute type is described in Section 2 of this document.
+
+   Example:
+
+      dn: c=DE
+      objectClass: country
+      objectClass: friendlyCountry
+      c: DE
+      co: Deutschland
+      co: Germany
+      co: Federal Republic of Germany
+      co: FRG
+
+   The 'c' attribute type is described in [RFC4519].
+
+3.7.  rFC822LocalPart
+
+   The 'rFC822LocalPart' object class is used to define entries that
+   represent the local part of Internet mail addresses [RFC2822].  This
+   treats the local part of the address as a 'domain' object.
+
+      ( 0.9.2342.19200300.100.4.14 NAME 'rFC822localPart'
+        SUP domain STRUCTURAL
+        MAY ( cn $ description $ destinationIndicator $
+          facsimileTelephoneNumber $ internationaliSDNNumber $
+          physicalDeliveryOfficeName $ postalAddress $ postalCode $
+          postOfficeBox $ preferredDeliveryMethod $ registeredAddress $
+          seeAlso $ sn $ street $ telephoneNumber $
+          teletexTerminalIdentifier $ telexNumber $ x121Address ) )
+
+   The 'domain' object class is described in Section 3.4 of this
+   document.  The 'cn', 'description', 'destinationIndicator',
+   'facsimileTelephoneNumber', 'internationaliSDNNumber,
+   'physicalDeliveryOfficeName', 'postalAddress', 'postalCode',
+   'postOfficeBox', 'preferredDeliveryMethod', 'registeredAddress',
+   'seeAlso', 'sn, 'street', 'telephoneNumber',
+   'teletexTerminalIdentifier', 'telexNumber', and 'x121Address'
+   attribute types are described in [RFC4519].
+
+   Example:
+
+      dn: dc=kdz,dc=example,dc=com
+      objectClass: domain
+      objectClass: rFC822LocalPart
+      dc: kdz
+      associatedName: cn=Kurt D. Zeilenga,cn=Persons,dc=Example,dc=COM
+
+
+
+
+Zeilenga                    Standards Track                    [Page 17]
+
+RFC 4524                COSINE LDAP/X.500 Schema               June 2006
+
+
+   The 'dc' attribute type is described in [RFC4519].
+
+3.8.  room
+
+   The 'room' object class is used to define entries representing rooms.
+   The 'cn' (commonName) attribute SHOULD be used for naming entries of
+   this object class.
+
+      ( 0.9.2342.19200300.100.4.7 NAME 'room'
+        SUP top STRUCTURAL
+        MUST cn
+        MAY ( roomNumber $ description $ seeAlso $ telephoneNumber ) )
+
+   The 'top' object class is described in [RFC4512].  The 'cn',
+   'description', 'seeAlso', and 'telephoneNumber' attribute types are
+   described in [RFC4519].  The 'roomNumber' attribute type is described
+   in Section 2 of this document.
+
+      dn: cn=conference room,dc=example,dc=com
+      objectClass: room
+      cn: conference room
+      telephoneNumber: +1 755 555 1111
+
+3.9.  simpleSecurityObject
+
+   The 'simpleSecurityObject' object class is used to require an entry
+   to have a 'userPassword' attribute when the entry's structural object
+   class does not require (or allow) the 'userPassword attribute'.
+
+      ( 0.9.2342.19200300.100.4.19 NAME 'simpleSecurityObject'
+        SUP top AUXILIARY
+        MUST userPassword )
+
+   The 'top' object class is described in [RFC4512].  The 'userPassword'
+   attribute type is described in [RFC4519].
+
+      dn: dc=kdz,dc=Example,dc=COM
+      objectClass: account
+      objectClass: simpleSecurityObject
+      uid: kdz
+      userPassword: My Password
+      seeAlso: cn=Kurt D. Zeilenga,cn=Persons,dc=Example,dc=COM
+
+4.  Security Considerations
+
+   General LDAP security considerations [RFC4510] are applicable to the
+   use of this schema.  Additional considerations are noted above where
+   appropriate.
+
+
+
+Zeilenga                    Standards Track                    [Page 18]
+
+RFC 4524                COSINE LDAP/X.500 Schema               June 2006
+
+
+   Directories administrators should ensure that access to sensitive
+   information be restricted to authorized entities and that appropriate
+   data security services, including data integrity and data
+   confidentiality, are used to protect against eavesdropping.
+
+   Simple authentication (e.g., plain text passwords) mechanisms should
+   only be used when adequate data security services are in place.  LDAP
+   offers reasonably strong authentication and data security services
+   [RFC4513].
+
+5.  IANA Considerations
+
+   The Internet Assigned Numbers Authority (IANA) has updated the LDAP
+   descriptors registry [RFC4520] as indicated in the following
+   template:
+
+      Subject: Request for LDAP Descriptor Registration Update
+      Descriptor (short name): see comment
+      Object Identifier: see comments
+      Person & email address to contact for further information:
+          Kurt Zeilenga <kurt@OpenLDAP.org>
+      Usage: see comments
+      Specification: RFC 4524
+      Author/Change Controller: IESG
+      Comments:
+
+      The following descriptors have been updated to refer to RFC 4524.
+
+        NAME                           Type OID
+        ------------------------       ---- --------------------------
+        account                        O    0.9.2342.19200300.100.4.5
+        associatedDomain               A    0.9.2342.19200300.100.1.37
+        associatedName                 A    0.9.2342.19200300.100.1.38
+        buildingName                   A    0.9.2342.19200300.100.1.48
+        co                             A    0.9.2342.19200300.100.1.43
+        document                       O    0.9.2342.19200300.100.4.6
+        documentAuthor                 A    0.9.2342.19200300.100.1.14
+        documentIdentifier             A    0.9.2342.19200300.100.1.11
+        documentLocation               A    0.9.2342.19200300.100.1.15
+        documentPublisher              A    0.9.2342.19200300.100.1.56
+        documentSeries                 O    0.9.2342.19200300.100.4.8
+        documentTitle                  A    0.9.2342.19200300.100.1.12
+        documentVersion                A    0.9.2342.19200300.100.1.13
+        domain                         O    0.9.2342.19200300.100.4.13
+        domainRelatedObject            O    0.9.2342.19200300.100.4.17
+        drink                          A    0.9.2342.19200300.100.1.5
+        favouriteDrink                 A*   0.9.2342.19200300.100.1.5
+        friendlyCountry                O    0.9.2342.19200300.100.4.18
+
+
+
+Zeilenga                    Standards Track                    [Page 19]
+
+RFC 4524                COSINE LDAP/X.500 Schema               June 2006
+
+
+        friendlyCountryName            A*   0.9.2342.19200300.100.1.43
+        homePhone                      A    0.9.2342.19200300.100.1.20
+        homePostalAddress              A    0.9.2342.19200300.100.1.39
+        homeTelephone                  A*   0.9.2342.19200300.100.1.20
+        host                           A    0.9.2342.19200300.100.1.9
+        info                           A    0.9.2342.19200300.100.1.4
+        mail                           A    0.9.2342.19200300.100.1.3
+        manager                        A    0.9.2342.19200300.100.1.10
+        mobile                         A    0.9.2342.19200300.100.1.41
+        mobileTelephoneNumber          A*   0.9.2342.19200300.100.1.41
+        organizationalStatus           A    0.9.2342.19200300.100.1.45
+        pager                          A    0.9.2342.19200300.100.1.42
+        pagerTelephoneNumber           A*   0.9.2342.19200300.100.1.42
+        personalTitle                  A    0.9.2342.19200300.100.1.40
+        rFC822LocalPart                O    0.9.2342.19200300.100.4.14
+        rfc822Mailbox                  A*   0.9.2342.19200300.100.1.3
+        room                           O    0.9.2342.19200300.100.4.7
+        roomNumber                     A    0.9.2342.19200300.100.1.6
+        secretary                      A    0.9.2342.19200300.100.1.21
+        simpleSecurityObject           O    0.9.2342.19200300.100.4.19
+        singleLevelQuality             A    0.9.2342.19200300.100.1.50
+        uniqueIdentifier               A    0.9.2342.19200300.100.1.44
+        userClass                      A    0.9.2342.19200300.100.1.8
+
+      where Type A is Attribute, Type O is ObjectClass, and *
+      indicates that the registration is historic in nature.
+
+6.  Acknowledgements
+
+   This document is based on RFC 1274, by Paul Barker and Steve Kille,
+   as well as on RFC 2247, by Steve Kill, Mark Wahl, Al Grimstad, Rick
+   Huber, and Sri Satulari.
+
+7.  References
+
+7.1.  Normative References
+
+   [RFC1034]     Mockapetris, P., "Domain names - concepts and
+                 facilities", STD 13, RFC 1034, November 1987.
+
+   [RFC1123]     Braden, R., "Requirements for Internet Hosts -
+                 Application and Support", STD 3, RFC 1123, October
+                 1989.
+
+   [RFC2119]     Bradner, S., "Key words for use in RFCs to Indicate
+                 Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+
+
+
+
+Zeilenga                    Standards Track                    [Page 20]
+
+RFC 4524                COSINE LDAP/X.500 Schema               June 2006
+
+
+   [RFC2181]     Elz, R. and R. Bush, "Clarifications to the DNS
+                 Specification", RFC 2181, July 1997.
+
+   [RFC2247]     Kille, S., Wahl, M., Grimstad, A., Huber, R., and S.
+                 Sataluri, "Using Domains in LDAP/X.500 Distinguished
+                 Names", RFC 2247, January 1998.
+
+   [RFC2821]     Klensin, J., Ed., "Simple Mail Transfer Protocol", RFC
+                 2821, April 2001.
+
+   [RFC2822]     Resnick, P., "Internet Message Format", RFC 2822, April
+                 2001.
+
+   [RFC3490]     Faltstrom, P., Hoffman, P., and A. Costello,
+                 "Internationalizing Domain Names in Applications
+                 (IDNA)", RFC 3490, March 2003.
+
+   [RFC4510]     Zeilenga, K., Ed.,  "Lightweight Directory Access
+                 Protocol (LDAP): Technical Specification Road Map", RFC
+                 4510, June 2006.
+
+   [RFC4512]     Zeilenga, K., "Lightweight Directory Access Protocol
+                 (LDAP): Directory Information Models", RFC 4512, June
+                 2006.
+
+   [RFC4513]     Harrison, R., "Lightweight Directory Access Protocol
+                 (LDAP): Authentication Methods and Security
+                 Mechanisms", RFC 4513, June 2006.
+
+   [RFC4517]     Legg, S., Ed., "Lightweight Directory Access Protocol
+                 (LDAP): Syntaxes and Matching Rules", RC 4517, June
+                 2006.
+
+   [RFC4519]     Sciberras, A., Ed., "Lightweight Directory Access
+                 Protocol (LDAP): Schema for User Applications", RFC
+                 4519, June 2006.
+
+   [X.501]       International Telecommunication Union -
+                 Telecommunication Standardization Sector, "The
+                 Directory -- Models," X.501(1993) (also ISO/IEC 9594-
+                 2:1994).
+
+7.2.  Informative References
+
+   [COSINEpilot] Goodman, D., "PARADISE" section of the March 1991
+                 INTERNET MONTHLY REPORTS (p. 28-29),
+                 http://www.iana.org/periodic-reports/imr-mar91.txt
+
+
+
+
+Zeilenga                    Standards Track                    [Page 21]
+
+RFC 4524                COSINE LDAP/X.500 Schema               June 2006
+
+
+   [ISO3166]     International Organization for Standardization, "Codes
+                 for the representation of names of countries", ISO
+                 3166.
+
+   [RFC1274]     Barker, P. and S. Kille, "The COSINE and Internet X.500
+                 Schema", RFC 1274, November 1991.
+
+   [RFC1279]     Hardcastle-Kille, S., "X.500 and Domains", RFC 1279,
+                 November 1991.
+
+   [RFC1487]     Yeong, W., Howes, T., and S. Kille, "X.500 Lightweight
+                 Directory Access Protocol", RFC 1487, July 1993.
+
+   [RFC2251]     Wahl, M., Howes, T., and S. Kille, "Lightweight
+                 Directory Access Protocol (v3)", RFC 2251, December
+                 1997.
+
+   [RFC2798]     Smith, M., "Definition of the inetOrgPerson LDAP Object
+                 Class", RFC 2798, April 2000.
+
+   [RFC3494]     Zeilenga, K., "Lightweight Directory Access Protocol
+                 version 2 (LDAPv2) to Historic Status", RFC 3494, March
+                 2003.
+
+   [RFC4520]     Zeilenga, K., "Internet Assigned Numbers Authority
+                 (IANA) Considerations for the Lightweight Directory
+                 Access Protocol (LDAP)", BCP 64, RFC 4520.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga                    Standards Track                    [Page 22]
+
+RFC 4524                COSINE LDAP/X.500 Schema               June 2006
+
+
+Appendix A.  Changes since RFC 1274
+
+   This document represents a substantial rewrite of RFC 1274.  The
+   following sections summarize the substantive changes.
+
+A.1.  LDAP Short Names
+
+   A number of COSINE attribute types have short names in LDAP.
+
+      X.500 Name              LDAP Short Name
+      -------------           ---------------
+      domainComponent         dc
+      favoriteDrink           drink
+      friendCountryName       co
+      homeTelephoneNumber     homePhone
+      mobileTelephoneNumber   mobile
+      pagerTelephoneNumber    pager
+      rfc822Mailbox           mail
+      userid                  uid
+
+   While the LDAP short names are generally used in LDAP, some
+   implementations may (for legacy reasons [RFC3494]) recognize the
+   attribute type by its X.500 name.  Hence, the X.500 names have been
+   reserved solely for this purpose.
+
+   Note: 'uid' and 'dc' are described in [RFC4519].
+
+A.2.  pilotObject
+
+   The 'pilotObject' object class was not brought forward as its
+   function is largely replaced by operational attributes introduced in
+   X.500(93) [X.501] and version 3 of LDAP [RFC4512].  For instance, the
+   function of the 'lastModifiedBy' and 'lastModifiedTime' attribute
+   types is now served by the 'creatorsName', 'createTimestamp',
+   'modifiersName', and 'modifyTimestamp' operational attributes
+   [RFC4512].
+
+A.3.  pilotPerson
+
+   The 'pilotPerson' object class was not brought forward as its
+   function is largely replaced by the 'organizationalPerson' [RFC4512]
+   object class and its subclasses, such as 'inetOrgPerson' [RFC2798].
+
+   Most of the related attribute types (e.g., 'mail', 'manager') were
+   brought forward as they are used in other object classes.
+
+
+
+
+
+
+Zeilenga                    Standards Track                    [Page 23]
+
+RFC 4524                COSINE LDAP/X.500 Schema               June 2006
+
+
+A.4.  dNSDomain
+
+   The 'dNSDomain' object class and related attribute types were not
+   brought forward as its use is primarily experimental [RFC1279].
+
+A.5.  pilotDSA and qualityLabelledData
+
+   The 'pilotDSA' and 'qualityLabelledData' object classes, as well as
+   related attribute types, were not brought forward as its use is
+   primarily experimental [QoS].
+
+A.6.  Attribute Syntaxes
+
+   RFC 1274 defined and used caseIgnoreIA5StringSyntax attribute syntax.
+   This has been replaced with the IA5String syntax and appropriate
+   matching rules in 'mail' and 'associatedDomain'.
+
+   RFC 1274 restricted 'mail' to have non-zero length values.  This
+   restriction is not reflected in the IA5String syntax used in the
+   definitions provided in this specification.  However, as values are
+   to conform to the <Mailbox> production, the 'mail' should not contain
+   zero-length values.  Unfortunately, the directory service will not
+   enforce this restriction.
+
+Appendix B.  Changes since RFC 2247
+
+   The 'domainNameForm' name form was not brought forward as
+   specification of name forms used in LDAP is left to a future
+   specification.
+
+Editor's Address
+
+   Kurt D. Zeilenga
+   OpenLDAP Foundation
+
+   EMail: Kurt@OpenLDAP.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga                    Standards Track                    [Page 24]
+
+RFC 4524                COSINE LDAP/X.500 Schema               June 2006
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2006).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Zeilenga                    Standards Track                    [Page 25]
+
diff --git a/source4/ldap_server/devdocs/rfc4525.txt b/source4/ldap_server/devdocs/rfc4525.txt
new file mode 100644
index 0000000000..6e15e4f6e9
--- /dev/null
+++ b/source4/ldap_server/devdocs/rfc4525.txt
@@ -0,0 +1,339 @@
+
+
+
+
+
+
+Network Working Group                                        K. Zeilenga
+Request for Comments: 4525                           OpenLDAP Foundation
+Category: Informational                                        June 2006
+
+
+              Lightweight Directory Access Protocol (LDAP)
+                       Modify-Increment Extension
+
+
+Status of This Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   This document describes an extension to the Lightweight Directory
+   Access Protocol (LDAP) Modify operation to support an increment
+   capability.  This extension is useful in provisioning applications,
+   especially when combined with the assertion control and/or the pre-
+   read or post-read control extension.
+
+Table of Contents
+
+   1. Background and Intended Use .....................................1
+   2. The Modify-Increment Extension ..................................2
+   3. LDIF Support ....................................................2
+   4. Security Considerations .........................................3
+   5. IANA Considerations .............................................3
+      5.1. Object Identifier ..........................................3
+      5.2. LDAP Protocol Mechanism ....................................3
+      5.3. LDAP Protocol Mechanism ....................................4
+   6. References ......................................................4
+      6.1. Normative References .......................................4
+      6.2. Informative References .....................................5
+
+1.  Background and Intended Use
+
+   The Lightweight Directory Access Protocol (LDAP) [RFC4510] does not
+   currently provide an operation to increment values of an attribute.
+   A client must read the values of the attribute and then modify those
+   values to increment them by the desired amount.  As the values may be
+   updated by other clients between this add and modify, the client must
+
+
+
+Zeilenga                     Informational                      [Page 1]
+
+RFC 4525            LDAP Modify-Increment Extension            June 2006
+
+
+   be careful to construct the modify request so that it fails in this
+   case, and upon failure, to re-read the values and construct a new
+   modify request.
+
+   This document extends the LDAP Modify Operation [RFC4511] to support
+   an increment values capability.  This feature is intended to be used
+   with either the LDAP pre-read or post-read control extensions
+   [RFC4527].  This feature may also be used with the LDAP assertion
+   control extension [RFC4528] to provide test-and-increment
+   functionality.
+
+   In this document key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
+   "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
+   "OPTIONAL" are to be interpreted as described in BCP 14 [RFC2119].
+
+2.  The Modify-Increment Extension
+
+   This document extends the LDAP Modify request to support a increment
+   values capability.  Implementations of this extension SHALL support
+   an additional ModifyRequest operation enumeration value increment
+   (3), as described herein.  Implementations not supporting this
+   extension will treat this value as they would an unlisted value,
+   e.g., as a protocol error.
+
+   The increment (3) operation value specifies that an increment values
+   modification is requested.  All existing values of the modification
+   attribute are to be incremented by the listed value.  The
+   modification attribute must be appropriate for the request (e.g., it
+   must have INTEGER or other increment-able values), and the
+   modification must provide one and only one value.  If the attribute
+   is not appropriate for the request, a constraintViolation or other
+   appropriate error is to be returned.  If multiple values are
+   provided, a protocolError is to be returned.
+
+   Servers supporting this feature SHOULD publish the object identifier
+   (OID) 1.3.6.1.1.14  as a value of the 'supportedFeatures' [RFC4512]
+   attribute in the root DSE.  Clients supporting this feature SHOULD
+   NOT use the feature unless they know the server supports it.
+
+3. LDIF Support
+
+   To represent Modify-Increment requests in LDAP Data Interchange
+   Format [RFC2849], the ABNF [RFC4234] production <mod-spec> is
+   extended as follows:
+
+       mod-spec =/ "increment:" FILL AttributeDescription SEP
+            attrval-spec "-" SEP
+
+
+
+
+Zeilenga                     Informational                      [Page 2]
+
+RFC 4525            LDAP Modify-Increment Extension            June 2006
+
+
+   For example,
+
+       # Increment uidNumber
+       dn: cn=max-assigned uidNumber,dc=example,dc=com
+       changetype: modify
+       increment: uidNumber
+       uidNumber: 1
+       -
+
+   This LDIF fragment represents a Modify request to increment the
+   value(s) of uidNumber by 1.
+
+4.  Security Considerations
+
+   General LDAP security considerations [RFC4510], as well as those
+   specific to the LDAP Modify [RFC4511], apply to this Modify-Increment
+   extension.  Beyond these considerations, it is noted that
+   introduction of this extension should reduce application complexity
+   (by providing one operation for what presently requires multiple
+   operations) and, hence, it may aid in the production of correct and
+   secure implementations.
+
+5.  IANA Considerations
+
+   Registration of the following values [RFC4520] have been completed.
+
+5.1.  Object Identifier
+
+   The IANA has assigned an LDAP Object Identifier to identify the LDAP
+   Modify-Increment feature, as defined in this document.
+
+       Subject: Request for LDAP Object Identifier Registration
+       Person & email address to contact for further information:
+           Kurt Zeilenga <kurt@OpenLDAP.org>
+       Specification: RFC 4525
+       Author/Change Controller: Author
+       Comments:
+           Identifies the LDAP Modify-Increment feature
+
+5.2.  LDAP Protocol Mechanism
+
+   The following LDAP Protocol Mechanism has been registered.
+
+       Subject: Request for LDAP Protocol Mechanism Registration
+       Object Identifier: 1.3.6.1.1.14
+       Description: Modify-Increment
+       Person & email address to contact for further information:
+           Kurt Zeilenga <kurt@openldap.org>
+
+
+
+Zeilenga                     Informational                      [Page 3]
+
+RFC 4525            LDAP Modify-Increment Extension            June 2006
+
+
+       Usage: Feature
+       Specification: RFC 4525
+       Author/Change Controller: Kurt Zeilenga <kurt@openldap.org>
+       Comments: none
+
+5.3.  LDAP Protocol Mechanism
+
+   The IANA has assigned an LDAP ModifyRequest Operation Type (3)
+   [RFC4520] for use in this document.
+
+       Subject: Request for LDAP Protocol Mechanism Registration
+       ModifyRequest Operation Name: increment
+       Description: Modify-Increment
+       Person & email address to contact for further information:
+           Kurt Zeilenga <kurt@openldap.org>
+       Usage: Feature
+       Specification: RFC 4525
+       Author/Change Controller: Kurt Zeilenga <kurt@openldap.org>
+       Comments: none
+
+6.  References
+
+6.1.  Normative References
+
+   [RFC2119]     Bradner, S., "Key words for use in RFCs to Indicate
+                 Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC4234]     Crocker, D. and P. Overell, "Augmented BNF for Syntax
+                 Specifications: ABNF", RFC 4234, October 2005.
+
+   [RFC2849]     Good, G., "The LDAP Data Interchange Format (LDIF) -
+                 Technical Specification", RFC 2849, June 2000.
+
+   [RFC4510]     Zeilenga, K., Ed., "Lightweight Directory Access
+                 Protocol (LDAP): Technical Specification Road Map", RFC
+                 4510, June 2006.
+
+   [RFC4511]     Sermersheim, J., Ed., "Lightweight Directory Access
+                 Protocol (LDAP): The Protocol", RFC 4511, June 2006.
+
+   [RFC4512]     Zeilenga, K., "Lightweight Directory Access Protocol
+                 (LDAP): Directory Information Models", RFC 4512, June
+                 2006.
+
+
+
+
+
+
+
+
+Zeilenga                     Informational                      [Page 4]
+
+RFC 4525            LDAP Modify-Increment Extension            June 2006
+
+
+6.2.  Informative References
+
+   [RFC4520]     Zeilenga, K., "Internet Assigned Numbers Authority
+                 (IANA) Considerations for the Lightweight Directory
+                 Access Protocol (LDAP)", BCP 64, RFC 4520, June 2006.
+
+   [RFC4527]     Zeilenga, K., "Lightweight Directory Access Protocol
+                 (LDAP) Read Entry Controls", RFC 4527, June 2006.
+
+   [RFC4528]     Zeilenga, K., "Lightweight Directory Access Protocol
+                 (LDAP) Assertion Control", RFC 4528, June 2006.
+
+Author's Address
+
+   Kurt D. Zeilenga
+   OpenLDAP Foundation
+
+   EMail: Kurt@OpenLDAP.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga                     Informational                      [Page 5]
+
+RFC 4525            LDAP Modify-Increment Extension            June 2006
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2006).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Zeilenga                     Informational                      [Page 6]
+
diff --git a/source4/ldap_server/devdocs/rfc4526.txt b/source4/ldap_server/devdocs/rfc4526.txt
new file mode 100644
index 0000000000..9795632b99
--- /dev/null
+++ b/source4/ldap_server/devdocs/rfc4526.txt
@@ -0,0 +1,283 @@
+
+
+
+
+
+
+Network Working Group                                        K. Zeilenga
+Request for Comments: 4526                           OpenLDAP Foundation
+Category: Standards Track                                      June 2006
+
+
+              Lightweight Directory Access Protocol (LDAP)
+                    Absolute True and False Filters
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   This document extends the Lightweight Directory Access Protocol
+   (LDAP) to support absolute True and False filters based upon similar
+   capabilities found in X.500 directory systems.  The document also
+   extends the String Representation of LDAP Search Filters to support
+   these filters.
+
+Table of Contents
+
+   1. Background ......................................................1
+   2. Absolute True and False Filters .................................2
+   3. Security Considerations .........................................2
+   4. IANA Considerations .............................................3
+   5. References ......................................................3
+      5.1. Normative References .......................................3
+      5.2. Informative References .....................................3
+
+1.  Background
+
+   The X.500 Directory Access Protocol (DAP) [X.511] supports absolute
+   True and False assertions.  An 'and' filter with zero elements always
+   evaluates to True.  An 'or' filter with zero elements always
+   evaluates to False.  These filters are commonly used when requesting
+   DSA-specific Entries (DSEs) that do not necessarily have
+   'objectClass' attributes; that is, where "(objectClass=*)" may
+   evaluate to False.
+
+
+
+
+Zeilenga                    Standards Track                     [Page 1]
+
+RFC 4526          LDAP Absolute True and False Filters         June 2006
+
+
+   Although LDAPv2 [RFC1777][RFC3494] placed no restriction on the
+   number of elements in 'and' and 'or' filter sets, the LDAPv2 string
+   representation [RFC1960][RFC3494] could not represent empty 'and' and
+   'or' filter sets.  Due to this, absolute True or False filters were
+   (unfortunately) eliminated from LDAPv3 [RFC4510].
+
+   This documents extends LDAPv3 to support absolute True and False
+   assertions by allowing empty 'and' and 'or' in Search filters
+   [RFC4511] and extends the filter string representation [RFC4515] to
+   allow empty filter lists.
+
+   It is noted that certain search operations, such as those used to
+   retrieve subschema information [RFC4512], require use of particular
+   filters.  This document does not change these requirements.
+
+   This feature is intended to allow a more direct mapping between DAP
+   and LDAP (as needed to implement DAP-to-LDAP gateways).
+
+   In this document, the key words "MUST", "MUST NOT", "REQUIRED",
+   "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
+   and "OPTIONAL" are to be interpreted as described in BCP 14
+   [RFC2119].
+
+2.  Absolute True and False Filters
+
+   Implementations of this extension SHALL allow 'and' and 'or' choices
+   with zero filter elements.
+
+   An 'and' filter consisting of an empty set of filters SHALL evaluate
+   to True.  This filter is represented by the string "(&)".
+
+   An 'or' filter consisting of an empty set of filters SHALL evaluate
+   to False.  This filter is represented by the string "(|)".
+
+   Servers supporting this feature SHOULD publish the Object Identifier
+   1.3.6.1.4.1.4203.1.5.3 as a value of the 'supportedFeatures'
+   [RFC4512] attribute in the root DSE.
+
+   Clients supporting this feature SHOULD NOT use the feature unless
+   they know that the server supports it.
+
+3.  Security Considerations
+
+   The (re)introduction of absolute True and False filters is not
+   believed to raise any new security considerations.
+
+   Implementors of this (or any) LDAPv3 extension should be familiar
+   with general LDAPv3 security considerations [RFC4510].
+
+
+
+Zeilenga                    Standards Track                     [Page 2]
+
+RFC 4526          LDAP Absolute True and False Filters         June 2006
+
+
+4.  IANA Considerations
+
+   Registration of this feature has been completed by the IANA
+   [RFC4520].
+
+   Subject: Request for LDAP Protocol Mechanism Registration Object
+   Identifier: 1.3.6.1.4.1.4203.1.5.3 Description: True/False filters
+   Person & email address to contact for further information:
+        Kurt Zeilenga <kurt@openldap.org> Usage: Feature Specification:
+   RFC 4526 Author/Change Controller: IESG Comments: none
+
+   This OID was assigned [ASSIGN] by OpenLDAP Foundation, under its
+   IANA-assigned private enterprise allocation [PRIVATE], for use in
+   this specification.
+
+5.  References
+
+5.1.  Normative References
+
+   [RFC2119]     Bradner, S., "Key words for use in RFCs to Indicate
+                 Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC4510]     Zeilenga, K., Ed, "Lightweight Directory Access
+                 Protocol (LDAP): Technical Specification Road Map", RFC
+                 4510, June 2006.
+
+   [RFC4511]     Sermersheim, J., Ed., "Lightweight Directory Access
+                 Protocol (LDAP): The Protocol", RFC 4511, June 2006.
+
+   [RFC4512]     Zeilenga, K., "Lightweight Directory Access Protocol
+                 (LDAP): Directory Information Models", RFC 4512, June
+                 2006.
+
+   [RFC4515]     Smith, M., Ed. and T. Howes, "Lightweight Directory
+                 Access Protocol (LDAP): String Representation of Search
+                 Filters", RFC 4515, June 2006.
+
+5.2.  Informative References
+
+   [RFC1777]     Yeong, W., Howes, T., and S. Kille, "Lightweight
+                 Directory Access Protocol", RFC 1777, March 1995.
+
+   [RFC1960]     Howes, T., "A String Representation of LDAP Search
+                 Filters", RFC 1960, June 1996.
+
+   [RFC3494]     Zeilenga, K., "Lightweight Directory Access Protocol
+                 version 2 (LDAPv2) to Historic Status", RFC 3494, March
+                 2003.
+
+
+
+Zeilenga                    Standards Track                     [Page 3]
+
+RFC 4526          LDAP Absolute True and False Filters         June 2006
+
+
+   [RFC4520]     Zeilenga, K., "Internet Assigned Numbers Authority
+                 (IANA) Considerations for the Lightweight Directory
+                 Access Protocol (LDAP)", BCP 64, RFC 4520, June 2006.
+
+   [X.500]       International Telecommunication Union -
+                 Telecommunication Standardization Sector, "The
+                 Directory -- Overview of concepts, models and
+                 services," X.500(1993) (also ISO/IEC 9594-1:1994).
+
+   [X.501]       International Telecommunication Union -
+                 Telecommunication Standardization Sector, "The
+                 Directory -- Models," X.501(1993) (also ISO/IEC 9594-
+                 2:1994).
+
+   [X.511]       International Telecommunication Union -
+                 Telecommunication Standardization Sector, "The
+                 Directory: Abstract Service Definition", X.511(1993)
+                 (also ISO/IEC 9594-3:1993).
+
+   [ASSIGN]      OpenLDAP Foundation, "OpenLDAP OID Delegations",
+                 http://www.openldap.org/foundation/oid-delegate.txt.
+
+   [PRIVATE]     IANA, "Private Enterprise Numbers",
+                 http://www.iana.org/assignments/enterprise-numbers.
+
+Author's Address
+
+   Kurt D. Zeilenga
+   OpenLDAP Foundation
+
+   EMail: Kurt@OpenLDAP.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga                    Standards Track                     [Page 4]
+
+RFC 4526          LDAP Absolute True and False Filters         June 2006
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2006).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Zeilenga                    Standards Track                     [Page 5]
+
diff --git a/source4/ldap_server/devdocs/rfc4527.txt b/source4/ldap_server/devdocs/rfc4527.txt
new file mode 100644
index 0000000000..de6e5d0d54
--- /dev/null
+++ b/source4/ldap_server/devdocs/rfc4527.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+Network Working Group                                        K. Zeilenga
+Request for Comments: 4527                           OpenLDAP Foundation
+Category: Standards Track                                      June 2006
+
+
+              Lightweight Directory Access Protocol (LDAP)
+                          Read Entry Controls
+
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   This document specifies an extension to the Lightweight Directory
+   Access Protocol (LDAP) to allow the client to read the target entry
+   of an update operation.  The client may request to read the entry
+   before and/or after the modifications are applied.  These reads are
+   done as an atomic part of the update operation.
+
+Table of Contents
+
+   1. Background and Intent of Use ....................................2
+   2. Terminology .....................................................2
+   3. Read Entry Controls .............................................3
+      3.1. The Pre-Read Controls ......................................3
+      3.2. The Post-Read Controls .....................................3
+   4. Interaction with Other Controls .................................4
+   5. Security Considerations .........................................4
+   6. IANA Considerations .............................................5
+      6.1. Object Identifier ..........................................5
+      6.2. LDAP Protocol Mechanisms ...................................5
+   7. Acknowledgement .................................................5
+   8. References ......................................................6
+      8.1. Normative References .......................................6
+      8.2. Informative References .....................................7
+
+
+
+
+
+
+Zeilenga                    Standards Track                     [Page 1]
+
+RFC 4527                LDAP Read Entry Controls               June 2006
+
+
+1.  Background and Intent of Use
+
+   This document specifies an extension to the Lightweight Directory
+   Access Protocol (LDAP) [RFC4510] to allow the client to read the
+   target entry of an update operation (e.g., Add, Delete, Modify,
+   ModifyDN).  The extension utilizes controls [RFC4511] attached to
+   update requests to request and return copies of the target entry.
+   One request control, called the Pre-Read request control, indicates
+   that a copy of the entry before application of update is to be
+   returned.  Another control, called the Post-Read request control,
+   indicates that a copy of the entry after application of the update is
+   to be returned.  Each request control has a corresponding response
+   control used to return the entry.
+
+   To ensure proper isolation, the controls are processed as an atomic
+   part of the update operation.
+
+   The functionality offered by these controls is based upon similar
+   functionality in the X.500 Directory Access Protocol (DAP) [X.511].
+
+   The Pre-Read controls may be used to obtain replaced or deleted
+   values of modified attributes or a copy of the entry being deleted.
+
+   The Post-Read controls may be used to obtain values of operational
+   attributes, such as the 'entryUUID' [RFC4530] and 'modifyTimestamp'
+   [RFC4512] attributes, updated by the server as part of the update
+   operation.
+
+2. Terminology
+
+   Protocol elements are described using ASN.1 [X.680] with implicit
+   tags.  The term "BER-encoded" means the element is to be encoded
+   using the Basic Encoding Rules [X.690] under the restrictions
+   detailed in Section 5.1 of [RFC4511].
+
+   DN stands for Distinguished Name.
+   DSA stands for Directory System Agent (i.e., a directory server).
+   DSE stands for DSA-specific Entry.
+
+   In this document, the key words "MUST", "MUST NOT", "REQUIRED",
+   "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
+   and "OPTIONAL" are to be interpreted as described in BCP 14
+   [RFC2119].
+
+
+
+
+
+
+
+
+Zeilenga                    Standards Track                     [Page 2]
+
+RFC 4527                LDAP Read Entry Controls               June 2006
+
+
+3.  Read Entry Controls
+
+3.1.  The Pre-Read Controls
+
+   The Pre-Read request and response controls are identified by the
+   1.3.6.1.1.13.1 object identifier.  Servers implementing these
+   controls SHOULD publish 1.3.6.1.1.13.1 as a value of the
+   'supportedControl' [RFC4512] in their root DSE.
+
+   The Pre-Read request control is a LDAP Control [RFC4511] whose
+   controlType is 1.3.6.1.1.13.1 and whose controlValue is a BER-encoded
+   AttributeSelection [RFC4511], as extended by [RFC3673].  The
+   criticality may be TRUE or FALSE.  This control is appropriate for
+   the modifyRequest, delRequest, and modDNRequest LDAP messages.
+
+   The corresponding response control is a LDAP Control whose
+   controlType is 1.3.6.1.1.13.1 and whose the controlValue, an OCTET
+   STRING, contains a BER-encoded SearchResultEntry.  The criticality
+   may be TRUE or FALSE.  This control is appropriate for the
+   modifyResponse, delResponse, and modDNResponse LDAP messages with a
+   resultCode of success (0).
+
+   When the request control is attached to an appropriate update LDAP
+   request, the control requests the return of a copy of the target
+   entry prior to the application of the update.  The AttributeSelection
+   indicates, as discussed in [RFC4511][RFC3673], which attributes are
+   requested to appear in the copy.  The server is to return a
+   SearchResultEntry containing, subject to access controls and other
+   constraints, values of the requested attributes.
+
+   The normal processing of the update operation and the processing of
+   this control MUST be performed as one atomic action isolated from
+   other update operations.
+
+   If the update operation fails (in either normal or control
+   processing), no Pre-Read response control is provided.
+
+3.2.  The Post-Read Controls
+
+   The Post-Read request and response controls are identified by the
+   1.3.6.1.1.13.2 object identifier.  Servers implementing these
+   controls SHOULD publish 1.3.6.1.1.13.2 as a value of the
+   'supportedControl' [RFC4512] in their root DSE.
+
+   The Post-Read request control is a LDAP Control [RFC4511] whose
+   controlType is 1.3.6.1.1.13.2 and whose controlValue, an OCTET
+   STRING, contains a BER-encoded AttributeSelection [RFC4511], as
+   extended by [RFC3673].  The criticality may be TRUE or FALSE.  This
+
+
+
+Zeilenga                    Standards Track                     [Page 3]
+
+RFC 4527                LDAP Read Entry Controls               June 2006
+
+
+   control is appropriate for the addRequest, modifyRequest, and
+   modDNRequest LDAP messages.
+
+   The corresponding response control is a LDAP Control whose
+   controlType is 1.3.6.1.1.13.2 and whose controlValue is a BER-encoded
+   SearchResultEntry.  The criticality may be TRUE or FALSE.  This
+   control is appropriate for the addResponse, modifyResponse, and
+   modDNResponse LDAP messages with a resultCode of success (0).
+
+   When the request control is attached to an appropriate update LDAP
+   request, the control requests the return of a copy of the target
+   entry after the application of the update.  The AttributeSelection
+   indicates, as discussed in [RFC4511][RFC3673], which attributes are
+   requested to appear in the copy.  The server is to return a
+   SearchResultEntry containing, subject to access controls and other
+   constraints, values of the requested attributes.
+
+   The normal processing of the update operation and the processing of
+   this control MUST be performed as one atomic action isolated from
+   other update operations.
+
+   If the update operation fails (in either normal or control
+   processing), no Post-Read response control is provided.
+
+4.  Interaction with Other Controls
+
+   The Pre-Read and Post-Read controls may be combined with each other
+   and/or with a variety of other controls.  When combined with the
+   assertion control [RFC4528] and/or the manageDsaIT control [RFC3296],
+   the semantics of each control included in the combination applies.
+   The Pre-Read and Post-Read controls may be combined with other
+   controls as detailed in other technical specifications.
+
+5.  Security Considerations
+
+   The controls defined in this document extend update operations to
+   support read capabilities.  Servers MUST ensure that the client is
+   authorized for reading of the information provided in this control
+   and that the client is authorized to perform the requested directory
+   update.
+
+   Security considerations for the update operations [RFC4511] extended
+   by this control, as well as general LDAP security considerations
+   [RFC4510], generally apply to implementation and use of this
+   extension
+
+
+
+
+
+
+Zeilenga                    Standards Track                     [Page 4]
+
+RFC 4527                LDAP Read Entry Controls               June 2006
+
+
+6.  IANA Considerations
+
+   Registration of the following protocol values [RFC4520] have been
+   completed by the IANA.
+
+6.1.  Object Identifier
+
+   The IANA has registered an LDAP Object Identifier to identify LDAP
+   protocol elements defined in this document.
+
+       Subject: Request for LDAP Object Identifier Registration
+       Person & email address to contact for further information:
+            Kurt Zeilenga <kurt@OpenLDAP.org>
+       Specification: RFC 4527
+       Author/Change Controller: IESG
+       Comments: Identifies the LDAP Read Entry Controls
+
+6.2.  LDAP Protocol Mechanisms
+
+   The IANA has registered the LDAP Protocol Mechanism described in this
+   document.
+
+       Subject: Request for LDAP Protocol Mechanism Registration
+       Object Identifier: 1.3.6.1.1.13.1
+       Description: LDAP Pre-read Control
+       Person & email address to contact for further information:
+            Kurt Zeilenga <kurt@openldap.org>
+       Usage: Control
+       Specification: RFC 4527
+       Author/Change Controller: IESG
+       Comments: none
+
+       Subject: Request for LDAP Protocol Mechanism Registration
+       Object Identifier: 1.3.6.1.1.13.2
+       Description: LDAP Post-read Control
+       Person & email address to contact for further information:
+            Kurt Zeilenga <kurt@openldap.org>
+       Usage: Control
+       Specification: RFC 4527
+       Author/Change Controller: IESG
+       Comments: none
+
+7.  Acknowledgement
+
+   The LDAP Pre-Read and Post-Read controls are modeled after similar
+   capabilities offered in the DAP [X.511].
+
+
+
+
+
+Zeilenga                    Standards Track                     [Page 5]
+
+RFC 4527                LDAP Read Entry Controls               June 2006
+
+
+8.  References
+
+8.1.  Normative References
+
+   [RFC2119]     Bradner, S., "Key words for use in RFCs to Indicate
+                 Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC3296]     Zeilenga, K., "Named Subordinate References in
+                 Lightweight Directory Access Protocol (LDAP)
+                 Directories", RFC 3296, July 2002.
+
+   [RFC3673]     Zeilenga, K., "Lightweight Directory Access Protocol
+                 version 3 (LDAPv3): All Operational Attributes", RFC
+                 3673, December 2003.
+
+   [RFC4510]     Zeilenga, K., Ed, "Lightweight Directory Access
+                 Protocol (LDAP): Technical Specification Road Map", RFC
+                 4510, June 2006.
+
+   [RFC4511]     Sermersheim, J., Ed., "Lightweight Directory Access
+                 Protocol (LDAP): The Protocol", RFC 4511, June 2006.
+
+   [RFC4512]     Zeilenga, K., "Lightweight Directory Access Protocol
+                 (LDAP): Directory Information Models", RFC 4512, June
+                 2006.
+
+   [RFC4528]     Zeilenga, K., "Lightweight Directory Access Protocol
+                 (LDAP) Assertion Control", RFC 4528, June 2006.
+
+   [X.680]       International Telecommunication Union -
+                 Telecommunication Standardization Sector, "Abstract
+                 Syntax Notation One (ASN.1) - Specification of Basic
+                 Notation", X.680(1997) (also ISO/IEC 8824-1:1998).
+
+   [X.690]       International Telecommunication Union -
+                 Telecommunication Standardization Sector,
+                 "Specification of ASN.1 encoding rules: Basic Encoding
+                 Rules (BER), Canonical Encoding Rules (CER), and
+                 Distinguished Encoding Rules (DER)", X.690(1997) (also
+                 ISO/IEC 8825-1:1998).
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga                    Standards Track                     [Page 6]
+
+RFC 4527                LDAP Read Entry Controls               June 2006
+
+
+8.2.  Informative References
+
+   [RFC4520]     Zeilenga, K., "Internet Assigned Numbers Authority
+                 (IANA) Considerations for the Lightweight Directory
+                 Access Protocol (LDAP)", BCP 64, RFC 4520, June 2006.
+
+   [RFC4530]     Zeilenga, K., "Lightweight Directory Access Protocol
+                 (LDAP) EntryUUID Operational Attribute", RFC 4530, June
+                 2006.
+
+   [X.511]       International Telecommunication Union -
+                 Telecommunication Standardization Sector, "The
+                 Directory: Abstract Service Definition", X.511(1993)
+                 (also ISO/IEC 9594-3:1993).
+
+Author's Address
+
+   Kurt D. Zeilenga
+   OpenLDAP Foundation
+
+   EMail: Kurt@OpenLDAP.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga                    Standards Track                     [Page 7]
+
+RFC 4527                LDAP Read Entry Controls               June 2006
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2006).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Zeilenga                    Standards Track                     [Page 8]
+
diff --git a/source4/ldap_server/devdocs/rfc4528.txt b/source4/ldap_server/devdocs/rfc4528.txt
new file mode 100644
index 0000000000..5b1fee0c1b
--- /dev/null
+++ b/source4/ldap_server/devdocs/rfc4528.txt
@@ -0,0 +1,339 @@
+
+
+
+
+
+
+Network Working Group                                        K. Zeilenga
+Request for Comments: 4528                           OpenLDAP Foundation
+Category: Standards Track                                      June 2006
+
+
+              Lightweight Directory Access Protocol (LDAP)
+                           Assertion Control
+
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   This document defines the Lightweight Directory Access Protocol
+   (LDAP) Assertion Control, which allows a client to specify that a
+   directory operation should only be processed if an assertion applied
+   to the target entry of the operation is true.  It can be used to
+   construct "test and set", "test and clear", and other conditional
+   operations.
+
+Table of Contents
+
+   1. Overview ........................................................2
+   2. Terminology .....................................................2
+   3. The Assertion Control ...........................................2
+   4. Security Considerations .........................................3
+   5. IANA Considerations .............................................4
+      5.1. Object Identifier ..........................................4
+      5.2. LDAP Protocol Mechanism ....................................4
+      5.3. LDAP Result Code ...........................................4
+   6. Acknowledgements ................................................5
+   7. References ......................................................5
+      7.1. Normative References .......................................5
+      7.2. Informative References .....................................5
+
+
+
+
+
+
+
+Zeilenga                    Standards Track                     [Page 1]
+
+RFC 4528                 LDAP Assertion Control                June 2006
+
+
+1.  Overview
+
+   This document defines the Lightweight Directory Access Protocol
+   (LDAP) [RFC4510] assertion control.  The assertion control allows the
+   client to specify a condition that must be true for the operation to
+   be processed normally.  Otherwise, the operation is not performed.
+   For instance, the control can be used with the Modify operation
+   [RFC4511] to perform atomic "test and set" and "test and clear"
+   operations.
+
+   The control may be attached to any update operation to support
+   conditional addition, deletion, modification, and renaming of the
+   target object.  The asserted condition is evaluated as an integral
+   part the operation.
+
+   The control may also be used with the search operation.  Here, the
+   assertion is applied to the base object of the search before
+   searching for objects that match the search scope and filter.
+
+   The control may also be used with the compare operation.  Here, it
+   extends the compare operation to allow a more complex assertion.
+
+2. Terminology
+
+   Protocol elements are described using ASN.1 [X.680] with implicit
+   tags.  The term "BER-encoded" means the element is to be encoded
+   using the Basic Encoding Rules [X.690] under the restrictions
+   detailed in Section 5.1 of [RFC4511].
+
+   DSA stands for Directory System Agent (or server).
+   DSE stands for DSA-specific Entry.
+
+   In this document, the key words "MUST", "MUST NOT", "REQUIRED",
+   "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
+   and "OPTIONAL" are to be interpreted as described in BCP 14
+   [RFC2119].
+
+3.  The Assertion Control
+
+   The assertion control is an LDAP Control [RFC4511] whose controlType
+   is 1.3.6.1.1.12 and whose controlValue is a BER-encoded Filter
+   [Protocol, Section 4.5.1].  The criticality may be TRUE or FALSE.
+   There is no corresponding response control.
+
+   The control is appropriate for both LDAP interrogation and update
+   operations [RFC4511], including Add, Compare, Delete, Modify,
+   ModifyDN (rename), and Search.  It is inappropriate for Abandon,
+   Bind, Unbind, and StartTLS operations.
+
+
+
+Zeilenga                    Standards Track                     [Page 2]
+
+RFC 4528                 LDAP Assertion Control                June 2006
+
+
+   When the control is attached to an LDAP request, the processing of
+   the request is conditional on the evaluation of the Filter as applied
+   against the target of the operation.  If the Filter evaluates to
+   TRUE, then the request is processed normally.  If the Filter
+   evaluates to FALSE or Undefined, then assertionFailed (122)
+   resultCode is returned, and no further processing is performed.
+
+   For Add, Compare, and ModifyDN operations, the target is indicated by
+   the entry field in the request.  For Modify operations, the target is
+   indicated by the object field.  For Delete operations, the target is
+   indicated by the DelRequest type.  For Compare operations and all
+   update operations, the evaluation of the assertion MUST be performed
+   as an integral part of the operation.  That is, the evaluation of the
+   assertion and the normal processing of the operation SHALL be done as
+   one atomic action.
+
+   For Search operations, the target is indicated by the baseObject
+   field, and the evaluation is done after "finding" but before
+   "searching" [RFC4511].  Hence, no entries or continuations references
+   are returned if the assertion fails.
+
+   Servers implementing this technical specification SHOULD publish the
+   object identifier 1.3.6.1.1.12 as a value of the 'supportedControl'
+   attribute [RFC4512] in their root DSE.  A server MAY choose to
+   advertise this extension only when the client is authorized to use
+   it.
+
+   Other documents may specify how this control applies to other LDAP
+   operations.  In doing so, they must state how the target entry is
+   determined.
+
+4.  Security Considerations
+
+   The filter may, like other components of the request, contain
+   sensitive information.  When it does, this information should be
+   appropriately protected.
+
+   As with any general assertion mechanism, the mechanism can be used to
+   determine directory content.  Hence, this mechanism SHOULD be subject
+   to appropriate access controls.
+
+   Some assertions may be very complex, requiring significant time and
+   resources to evaluate.  Hence, this mechanism SHOULD be subject to
+   appropriate administrative controls.
+
+
+
+
+
+
+
+Zeilenga                    Standards Track                     [Page 3]
+
+RFC 4528                 LDAP Assertion Control                June 2006
+
+
+   Security considerations for the base operations [RFC4511] extended by
+   this control, as well as general LDAP security considerations
+   [RFC4510], generally apply to implementation and use of this
+   extension.
+
+5.  IANA Considerations
+
+5.1.  Object Identifier
+
+   The IANA has assigned an LDAP Object Identifier [RFC4520] to identify
+   the LDAP Assertion Control defined in this document.
+
+       Subject: Request for LDAP Object Identifier Registration
+       Person & email address to contact for further information:
+           Kurt Zeilenga <kurt@OpenLDAP.org>
+       Specification: RFC 4528
+       Author/Change Controller: IESG
+       Comments:
+           Identifies the LDAP Assertion Control
+
+5.2.  LDAP Protocol Mechanism
+
+   Registration of this protocol mechanism [RFC4520] is requested.
+
+       Subject: Request for LDAP Protocol Mechanism Registration
+       Object Identifier: 1.3.6.1.1.12
+       Description: Assertion Control
+       Person & email address to contact for further information:
+           Kurt Zeilenga <kurt@openldap.org>
+       Usage: Control
+       Specification: RFC 4528
+       Author/Change Controller: IESG
+       Comments: none
+
+5.3.  LDAP Result Code
+
+   The IANA has assigned an LDAP Result Code [RFC4520] called
+   'assertionFailed' (122).
+
+       Subject: LDAP Result Code Registration
+       Person & email address to contact for further information:
+           Kurt Zeilenga <kurt@OpenLDAP.org>
+       Result Code Name: assertionFailed
+       Specification: RFC 4528
+       Author/Change Controller: IESG
+       Comments:  none
+
+
+
+
+
+Zeilenga                    Standards Track                     [Page 4]
+
+RFC 4528                 LDAP Assertion Control                June 2006
+
+
+6.  Acknowledgements
+
+   The assertion control concept is attributed to Morteza Ansari.
+
+7.  References
+
+7.1.  Normative References
+
+   [RFC2119]     Bradner, S., "Key words for use in RFCs to Indicate
+                 Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC4510]     Zeilenga, K., Ed., "Lightweight Directory Access
+                 Protocol (LDAP): Technical Specification Road Map", RFC
+                 4510, June 2006.
+
+   [RFC4511]     Sermersheim, J., Ed., "Lightweight Directory Access
+                 Protocol (LDAP): The Protocol", RFC 4511, June 2006.
+
+   [RFC4512]     Zeilenga, K., "Lightweight Directory Access Protocol
+                 (LDAP): Directory Information Models", RFC 4512, June
+                 2006.
+
+   [X.680]       International Telecommunication Union -
+                 Telecommunication Standardization Sector, "Abstract
+                 Syntax Notation One (ASN.1) - Specification of Basic
+                 Notation", X.680(2002) (also ISO/IEC 8824-1:2002).
+
+   [X.690]       International Telecommunication Union -
+                 Telecommunication Standardization Sector,
+                 "Specification of ASN.1 encoding rules: Basic Encoding
+                 Rules (BER), Canonical Encoding Rules (CER), and
+                 Distinguished Encoding Rules (DER)", X.690(2002) (also
+                 ISO/IEC 8825-1:2002).
+
+7.2.  Informative References
+
+   [RFC4520]     Zeilenga, K., "Internet Assigned Numbers Authority
+                 (IANA) Considerations for the Lightweight Directory
+                 Access Protocol (LDAP)", BCP 64, RFC 4520, June 2006.
+
+Author's Address
+
+   Kurt D. Zeilenga
+   OpenLDAP Foundation
+
+   EMail: Kurt@OpenLDAP.org
+
+
+
+
+
+Zeilenga                    Standards Track                     [Page 5]
+
+RFC 4528                 LDAP Assertion Control                June 2006
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2006).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Zeilenga                    Standards Track                     [Page 6]
+
diff --git a/source4/ldap_server/devdocs/rfc4529.txt b/source4/ldap_server/devdocs/rfc4529.txt
new file mode 100644
index 0000000000..47449c040f
--- /dev/null
+++ b/source4/ldap_server/devdocs/rfc4529.txt
@@ -0,0 +1,339 @@
+
+
+
+
+
+
+Network Working Group                                        K. Zeilenga
+Request for Comments: 4529                           OpenLDAP Foundation
+Category: Informational                                        June 2006
+
+
+              Requesting Attributes by Object Class in the
+              Lightweight Directory Access Protocol (LDAP)
+
+Status of This Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   The Lightweight Directory Access Protocol (LDAP) search operation
+   provides mechanisms for clients to request all user application
+   attributes, all operational attributes, and/or attributes selected by
+   their description.  This document extends LDAP to support a mechanism
+   that LDAP clients may use to request the return of all attributes of
+   an object class.
+
+Table of Contents
+
+   1. Background and Intended Use .....................................1
+   2. Terminology .....................................................2
+   3. Return of all Attributes of an Object Class .....................2
+   4. Security Considerations .........................................3
+   5. IANA Considerations .............................................3
+   6. References ......................................................4
+      6.1. Normative References .......................................4
+      6.2. Informative References .....................................4
+
+1.  Background and Intended Use
+
+   In the Lightweight Directory Access Protocol (LDAP) [RFC4510], the
+   search operation [RFC4511] supports requesting the return of a set of
+   attributes.  This set is determined by a list of attribute
+   descriptions.  Two special descriptors are defined to request all
+   user attributes ("*") [RFC4511] and all operational attributes ("+")
+   [RFC3673].  However, there is no convenient mechanism for requesting
+   pre-defined sets of attributes such as the set of attributes used to
+   represent a particular class of object.
+
+
+
+Zeilenga                     Informational                      [Page 1]
+
+RFC 4529         Requesting Attributes by Object Class         June 2006
+
+
+   This document extends LDAP to allow an object class identifier to be
+   specified in attributes lists, such as in Search requests, to request
+   the return of all attributes belonging to an object class.  The
+   COMMERCIAL AT ("@", U+0040) character is used to distinguish an
+   object class identifier from an attribute descriptions.
+
+   For example, the attribute list of "@country" is equivalent to the
+   attribute list of 'c', 'searchGuide', 'description', and
+   'objectClass'.  This object class is described in [RFC4519].
+
+   This extension is intended primarily to be used where the user is in
+   direct control of the parameters of the LDAP search operation, for
+   instance when entering an LDAP URL [RFC4516] into a web browser, such
+   as <ldap:///dc=example,dc=com?@organization?base>.
+
+2.  Terminology
+
+   In this document, the key words "MUST", "MUST NOT", "REQUIRED",
+   "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
+   and "OPTIONAL" are to be interpreted as described in BCP 14
+   [RFC2119].
+
+   DSA stands for Directory System Agent (or server).
+   DSE stands for DSA-specific Entry.
+
+3.  Return of All Attributes of an Object Class
+
+   This extension allows object class identifiers to be provided in the
+   attributes field of the LDAP SearchRequest [RFC4511] or other request
+   values of the AttributeSelection data type (e.g., attributes field in
+   pre/post read controls [ReadEntry]) and/or <attributeSelector>
+   production (e.g., attributes of an LDAP URL [RFC4516]).  For each
+   object class identified in the attributes field, the request is to be
+   treated as if each attribute allowed by that class (by "MUST" or
+   "MAY", directly or by "SUP"erior) [RFC4512] were itself listed.
+
+   This extension extends the <attributeSelector> [RFC4511] production
+   as indicated by the following ABNF [RFC4234]:
+
+        attributeSelector =/ objectclassdescription
+        objectclassdescription = ATSIGN oid options
+        ATSIGN = %x40 ; COMMERCIAL AT ("@" U+0040)
+
+   where <oid> and <options> productions are as defined in [RFC4512].
+
+
+
+
+
+
+
+Zeilenga                     Informational                      [Page 2]
+
+RFC 4529         Requesting Attributes by Object Class         June 2006
+
+
+   The <oid> component of an <objectclassdescription> production
+   identifies the object class by short name (descr) or object
+   identifier (numericoid).  If the value of the <oid> component is
+   unrecognized or does not refer to an object class, the object class
+   description is to be treated as an unrecognized attribute
+   description.
+
+   The <options> production is included in the grammar for extensibility
+   purposes.  An object class description with an unrecognized or
+   inappropriate option is to be treated as unrecognized.
+
+   Although object class description options and attribute description
+   options share the same syntax, they are not semantically related.
+   This document does not define any object description option.
+
+   Servers supporting this feature SHOULD publish the object identifier
+   (OID) 1.3.6.1.4.1.4203.1.5.2 as a value of the 'supportedFeatures'
+   [RFC4512] attribute in the root DSE.  Clients supporting this feature
+   SHOULD NOT use the feature unless they know that the server supports
+   it.
+
+4.  Security Considerations
+
+   This extension provides a shorthand for requesting all attributes of
+   an object class.  Because these attributes could have been listed
+   individually, introduction of this shorthand is not believed to raise
+   additional security considerations.
+
+   Implementors of this LDAP extension should be familiar with security
+   considerations applicable to the LDAP search operation [RFC4511], as
+   well as with general LDAP security considerations [RFC4510].
+
+5.  IANA Considerations
+
+   Registration of the LDAP Protocol Mechanism [RFC4520] defined in this
+   document has been completed.
+
+       Subject: Request for LDAP Protocol Mechanism Registration
+       Object Identifier: 1.3.6.1.4.1.4203.1.5.2
+       Description: OC AD Lists
+       Person & email address to contact for further information:
+            Kurt Zeilenga <kurt@openldap.org>
+       Usage: Feature
+       Specification: RFC 4529
+       Author/Change Controller: Kurt Zeilenga <kurt@openldap.org>
+       Comments: none
+
+
+
+
+
+Zeilenga                     Informational                      [Page 3]
+
+RFC 4529         Requesting Attributes by Object Class         June 2006
+
+
+   This OID was assigned [ASSIGN] by OpenLDAP Foundation, under its
+   IANA-assigned private enterprise allocation [PRIVATE], for use in
+   this specification.
+
+6.  References
+
+6.1.  Normative References
+
+   [RFC2119]     Bradner, S., "Key words for use in RFCs to Indicate
+                 Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC4234]     Crocker, D., Ed. and P. Overell, "Augmented BNF for
+                 Syntax Specifications: ABNF", RFC 4234, October 2005.
+
+   [RFC4510]     Zeilenga, K., Ed., "Lightweight Directory Access
+                 Protocol (LDAP): Technical Specification Road Map", RFC
+                 4510, June 2006.
+
+   [RFC4511]     Sermersheim, J., Ed., "Lightweight Directory Access
+                 Protocol (LDAP): The Protocol", RFC 4511, June 2006.
+
+   [RFC4512]     Zeilenga, K., "Lightweight Directory Access Protocol
+                 (LDAP): Directory Information Models", RFC 4512, June
+                 2006.
+
+   [RFC4516]     Smith, M., Ed. and T. Howes, "Lightweight Directory
+                 Access Protocol (LDAP): Uniform Resource Locator", RFC
+                 4516, June 2006.
+
+   [X.680]       International Telecommunication Union -
+                 Telecommunication Standardization Sector, "Abstract
+                 Syntax Notation One (ASN.1) - Specification of Basic
+                 Notation", X.680(2002) (also ISO/IEC 8824-1:2002).
+
+6.2.  Informative References
+
+   [RFC3673]     Zeilenga, K., "Lightweight Directory Access Protocol
+                 version 3 (LDAPv3): All Operational Attributes", RFC
+                 3673, December 2003.
+
+   [RFC4519]     Sciberras, A., Ed., "Lightweight Directory Access
+                 Protocol (LDAP): Schema for User Applications", RFC
+                 4519, June 2006.
+
+   [RFC4520]     Zeilenga, K., "Internet Assigned Numbers Authority
+                 (IANA) Considerations for the Lightweight Directory
+                 Access Protocol (LDAP)", BCP 64, RFC 4520, June 2006.
+
+
+
+
+Zeilenga                     Informational                      [Page 4]
+
+RFC 4529         Requesting Attributes by Object Class         June 2006
+
+
+   [ReadEntry]   Zeilenga, K., "Lightweight Directory Access Protocol
+                 (LDAP) Read Entry Controls", RFC 4527, June 2006.
+
+   [ASSIGN]      OpenLDAP Foundation, "OpenLDAP OID Delegations",
+                 http://www.openldap.org/foundation/oid-delegate.txt.
+
+   [PRIVATE]     IANA, "Private Enterprise Numbers",
+                 http://www.iana.org/assignments/enterprise-numbers.
+
+Author's Address
+
+   Kurt D. Zeilenga
+   OpenLDAP Foundation
+
+   EMail: Kurt@OpenLDAP.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga                     Informational                      [Page 5]
+
+RFC 4529         Requesting Attributes by Object Class         June 2006
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2006).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Zeilenga                     Informational                      [Page 6]
+
diff --git a/source4/ldap_server/devdocs/rfc4530.txt b/source4/ldap_server/devdocs/rfc4530.txt
new file mode 100644
index 0000000000..219a7c2d0c
--- /dev/null
+++ b/source4/ldap_server/devdocs/rfc4530.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+Network Working Group                                        K. Zeilenga
+Request for Comments: 4530                           OpenLDAP Foundation
+Category: Standards Track                                      June 2006
+
+
+              Lightweight Directory Access Protocol (LDAP)
+                    entryUUID Operational Attribute
+
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   This document describes the LDAP/X.500 'entryUUID' operational
+   attribute and associated matching rules and syntax.  The attribute
+   holds a server-assigned Universally Unique Identifier (UUID) for the
+   object.  Directory clients may use this attribute to distinguish
+   objects identified by a distinguished name or to locate an object
+   after renaming.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga                    Standards Track                     [Page 1]
+
+RFC 4530                     LDAP entryUUID                    June 2006
+
+
+Table of Contents
+
+   1. Background and Intended Use .....................................2
+   2. UUID Schema Elements ............................................3
+      2.1. UUID Syntax ................................................3
+      2.2. 'uuidMatch' Matching Rule ..................................3
+      2.3. 'uuidOrderingMatch' Matching Rule ..........................3
+      2.4. 'entryUUID' Attribute ......................................4
+   3. Security Considerations .........................................4
+   4. IANA Considerations .............................................5
+      4.1. Object Identifier Registration .............................5
+      4.2. UUID Syntax Registration ...................................5
+      4.3. 'uuidMatch' Descriptor Registration ........................5
+      4.4. 'uuidOrderingMatch' Descriptor Registration ................5
+      4.5. 'entryUUID' Descriptor Registration ........................6
+   5. Acknowledgements ................................................6
+   6. References ......................................................6
+      6.1. Normative References .......................................6
+      6.2. Informative References .....................................7
+
+1.  Background and Intended Use
+
+   In X.500 Directory Services [X.501], such as those accessible using
+   the Lightweight Directory Access Protocol (LDAP) [RFC4510], an object
+   is identified by its distinguished name (DN).  However, DNs are not
+   stable identifiers.  That is, a new object may be identified by a DN
+   that previously identified another (now renamed or deleted) object.
+
+   A Universally Unique Identifier (UUID) is "an identifier unique
+   across both space and time, with respect to the space of all UUIDs"
+   [RFC4122].  UUIDs are used in a wide range of systems.
+
+   This document describes the 'entryUUID' operational attribute, which
+   holds the UUID assigned to the object by the server.  Clients may use
+   this attribute to distinguish objects identified by a particular
+   distinguished name or to locate a particular object after renaming.
+
+   This document defines the UUID syntax, the 'uuidMatch' and
+   'uuidOrderingMatch' matching rules, and the 'entryUUID' attribute
+   type.
+
+   Schema definitions are provided using LDAP description formats
+   [RFC4512].  Definitions provided here are formatted (line wrapped)
+   for readability.
+
+
+
+
+
+
+
+Zeilenga                    Standards Track                     [Page 2]
+
+RFC 4530                     LDAP entryUUID                    June 2006
+
+
+   In this document, the key words "MUST", "MUST NOT", "REQUIRED",
+   "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
+   and "OPTIONAL" are to be interpreted as described in BCP 14
+   [RFC2119].
+
+2.  UUID Schema Elements
+
+2.1.  UUID Syntax
+
+   A Universally Unique Identifier (UUID) [RFC4122] is a 16-octet (128-
+   bit) value that identifies an object.  The ASN.1 [X.680] type UUID is
+   defined to represent UUIDs as follows:
+
+       UUID ::= OCTET STRING (SIZE(16))
+             -- constrained to an UUID [RFC4122]
+
+   In LDAP, UUID values are encoded using the [ASCII] character string
+   representation described in [RFC4122].  For example,
+   "597ae2f6-16a6-1027-98f4-d28b5365dc14".
+
+   The following is an LDAP syntax description suitable for publication
+   in subschema subentries.
+
+       ( 1.3.6.1.1.16.1 DESC 'UUID' )
+
+2.2.  'uuidMatch' Matching Rule
+
+   The 'uuidMatch' matching rule compares an asserted UUID with a stored
+   UUID for equality.  Its semantics are the same as the
+   'octetStringMatch' [X.520][RFC4517] matching rule.  The rule differs
+   from 'octetStringMatch' in that the assertion value is encoded using
+   the UUID string representation instead of the normal OCTET STRING
+   string representation.
+
+   The following is an LDAP matching rule description suitable for
+   publication in subschema subentries.
+
+       ( 1.3.6.1.1.16.2 NAME 'uuidMatch'
+           SYNTAX 1.3.6.1.1.16.1 )
+
+2.3.  'uuidOrderingMatch' Matching Rule
+
+   The 'uuidOrderingMatch' matching rule compares an asserted UUID with
+   a stored UUID for ordering.  Its semantics are the same as the
+   'octetStringOrderingMatch' [X.520][RFC4517] matching rule.  The rule
+   differs from 'octetStringOrderingMatch' in that the assertion value
+   is encoded using the UUID string representation instead of the normal
+   OCTET STRING string representation.
+
+
+
+Zeilenga                    Standards Track                     [Page 3]
+
+RFC 4530                     LDAP entryUUID                    June 2006
+
+
+   The following is an LDAP matching rule description suitable for
+   publication in subschema subentries.
+
+       ( 1.3.6.1.1.16.3 NAME 'uuidOrderingMatch'
+           SYNTAX 1.3.6.1.1.16.1 )
+
+   Note that not all UUID variants have a defined ordering; and even
+   where it does, servers are not obligated to assign UUIDs in any
+   particular order.  This matching rule is provided for completeness.
+
+2.4.  'entryUUID' Attribute
+
+   The 'entryUUID' operational attribute provides the Universally Unique
+   Identifier (UUID) assigned to the entry.
+
+   The following is an LDAP attribute type description suitable for
+   publication in subschema subentries.
+
+       ( 1.3.6.1.1.16.4 NAME 'entryUUID'
+           DESC 'UUID of the entry'
+           EQUALITY uuidMatch
+           ORDERING uuidOrderingMatch
+           SYNTAX 1.3.6.1.1.16.1
+           SINGLE-VALUE
+           NO-USER-MODIFICATION
+           USAGE directoryOperation )
+
+   Servers SHALL generate and assign a new UUID to each entry upon its
+   addition to the directory and provide that UUID as the value of the
+   'entryUUID' operational attribute.  An entry's UUID is immutable.
+
+   UUID are to be generated in accordance with Section 4 of [RFC4122].
+   In particular, servers MUST ensure that each generated UUID is unique
+   in space and time.
+
+3.  Security Considerations
+
+   An entry's relative distinguish name (RDN) is composed from attribute
+   values of the entry, which are commonly descriptive of the object the
+   entry represents.  Although deployers are encouraged to use naming
+   attributes whose values are widely disclosable [RFC4514], entries are
+   often named using information that cannot be disclosed to all
+   parties.  As UUIDs do not contain any descriptive information of the
+   object they identify, UUIDs may be used to identify a particular
+   entry without disclosure of its contents.
+
+   General UUID security considerations [RFC4122] apply.
+
+
+
+
+Zeilenga                    Standards Track                     [Page 4]
+
+RFC 4530                     LDAP entryUUID                    June 2006
+
+
+   General LDAP security considerations [RFC4510] apply.
+
+4.  IANA Considerations
+
+   The IANA has registered the LDAP values [RFC4520] specified in this
+   document.
+
+4.1.  Object Identifier Registration
+
+       Subject: Request for LDAP OID Registration
+       Person & email address to contact for further information:
+           Kurt Zeilenga <kurt@OpenLDAP.org>
+       Specification: RFC 4530
+       Author/Change Controller: IESG
+       Comments:
+           Identifies the UUID schema elements
+
+4.2.  UUID Syntax Registration
+
+       Subject: Request for LDAP Syntax Registration
+       Object Identifier: 1.3.6.1.1.16.1
+       Description: UUID
+       Person & email address to contact for further information:
+           Kurt Zeilenga <kurt@OpenLDAP.org>
+       Specification: RFC 4530
+       Author/Change Controller: IESG
+       Comments:
+            Identifies the UUID syntax
+
+4.3.  'uuidMatch' Descriptor Registration
+
+       Subject: Request for LDAP Descriptor Registration
+       Descriptor (short name): uuidMatch
+       Object Identifier: 1.3.6.1.1.16.2
+       Person & email address to contact for further information:
+           Kurt Zeilenga <kurt@OpenLDAP.org>
+       Usage: Matching Rule
+       Specification: RFC 4530
+       Author/Change Controller: IESG
+
+4.4.  'uuidOrderingMatch' Descriptor Registration
+
+       Subject: Request for LDAP Descriptor Registration
+       Descriptor (short name): uuidOrderingMatch
+       Object Identifier: 1.3.6.1.1.16.3
+       Person & email address to contact for further information:
+           Kurt Zeilenga <kurt@OpenLDAP.org>
+       Usage: Matching Rule
+
+
+
+Zeilenga                    Standards Track                     [Page 5]
+
+RFC 4530                     LDAP entryUUID                    June 2006
+
+
+       Specification: RFC 4530
+       Author/Change Controller: IESG
+
+4.5.  'entryUUID' Descriptor Registration
+
+   The IANA has registered the LDAP 'entryUUID' descriptor.
+
+       Subject: Request for LDAP Descriptor Registration
+       Descriptor (short name): entryUUID
+       Object Identifier: 1.3.6.1.1.16.4
+       Person & email address to contact for further information:
+           Kurt Zeilenga <kurt@OpenLDAP.org>
+       Usage: Attribute Type
+       Specification: RFC 4530
+       Author/Change Controller: IESG
+
+5.  Acknowledgements
+
+   This document is based upon discussions in the LDAP Update and
+   Duplication Protocols (LDUP) WG.  Members of the LDAP Directorate
+   provided review.
+
+6.  References
+
+6.1.  Normative References
+
+   [RFC2119]     Bradner, S., "Key words for use in RFCs to Indicate
+                 Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC4122]     Leach, P., Mealling, M., and R. Salz, "A Universally
+                 Unique IDentifier (UUID) URN Namespace", RFC 4122, July
+                 2005.
+
+   [RFC4510]     Zeilenga, K., Ed., "Lightweight Directory Access
+                 Protocol (LDAP): Technical Specification Road Map", RFC
+                 4510, June 2006.
+
+   [RFC4512]     Zeilenga, K., "Lightweight Directory Access Protocol
+                 (LDAP): Directory Information Models", RFC 4512, June
+                 2006.
+
+   [RFC4517]     Legg, S., Ed., "Lightweight Directory Access Protocol
+                 (LDAP): Syntaxes and Matching Rules", RFC 4517, June
+                 2006.
+
+   [ASCII]       Coded Character Set--7-bit American Standard Code for
+                 Information Interchange, ANSI X3.4-1986.
+
+
+
+
+Zeilenga                    Standards Track                     [Page 6]
+
+RFC 4530                     LDAP entryUUID                    June 2006
+
+
+   [X.501]       International Telecommunication Union -
+                 Telecommunication Standardization Sector, "The
+                 Directory -- Models," X.501(1993) (also ISO/IEC 9594-
+                 2:1994).
+
+   [X.520]       International Telecommunication Union -
+                 Telecommunication Standardization Sector, "The
+                 Directory: Selected Attribute Types", X.520(1993) (also
+                 ISO/IEC 9594-6:1994).
+
+   [X.680]       International Telecommunication Union -
+                 Telecommunication Standardization Sector, "Abstract
+                 Syntax Notation One (ASN.1) - Specification of Basic
+                 Notation", X.680(2002) (also ISO/IEC 8824-1:2002).
+
+6.2.  Informative References
+
+   [RFC4514]     Zeilenga, K., Ed., "Lightweight Directory Access
+                 Protocol (LDAP): String Representation of Distinguished
+                 Names", RFC 4514, June 2006.
+
+   [RFC4520]     Zeilenga, K., "Internet Assigned Numbers Authority
+                 (IANA) Considerations for the Lightweight Directory
+                 Access Protocol (LDAP)", BCP 64, RFC 4520, June 2006.
+
+Author's Address
+
+   Kurt D. Zeilenga
+   OpenLDAP Foundation
+
+   EMail: Kurt@OpenLDAP.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga                    Standards Track                     [Page 7]
+
+RFC 4530                     LDAP entryUUID                    June 2006
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2006).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Zeilenga                    Standards Track                     [Page 8]
+
diff --git a/source4/ldap_server/devdocs/rfc4531.txt b/source4/ldap_server/devdocs/rfc4531.txt
new file mode 100644
index 0000000000..b551d441cb
--- /dev/null
+++ b/source4/ldap_server/devdocs/rfc4531.txt
@@ -0,0 +1,507 @@
+
+
+
+
+
+
+Network Working Group                                        K. Zeilenga
+Request for Comments: 4531                           OpenLDAP Foundation
+Category: Experimental                                         June 2006
+
+
+              Lightweight Directory Access Protocol (LDAP)
+                             Turn Operation
+
+
+Status of This Memo
+
+   This memo defines an Experimental Protocol for the Internet
+   community.  It does not specify an Internet standard of any kind.
+   Discussion and suggestions for improvement are requested.
+   Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   This specification describes a Lightweight Directory Access Protocol
+   (LDAP) extended operation to reverse (or "turn") the roles of client
+   and server for subsequent protocol exchanges in the session, or to
+   enable each peer to act as both client and server with respect to the
+   other.
+
+Table of Contents
+
+   1. Background and Intent of Use ....................................2
+      1.1. Terminology ................................................2
+   2. Turn Operation ..................................................2
+      2.1. Turn Request ...............................................3
+      2.2. Turn Response ..............................................3
+   3. Authentication ..................................................3
+      3.1. Use with TLS and Simple Authentication .....................4
+      3.2. Use with TLS and SASL EXTERNAL .............................4
+      3.3. Use of Mutual Authentication and SASL EXTERNAL .............4
+   4. TLS and SASL Security Layers ....................................5
+   5. Security Considerations .........................................6
+   6. IANA Considerations .............................................6
+      6.1. Object Identifier ..........................................6
+      6.2. LDAP Protocol Mechanism ....................................7
+   7. References ......................................................7
+      7.1. Normative References .......................................7
+      7.2. Informative References .....................................8
+
+
+
+
+Zeilenga                      Experimental                      [Page 1]
+
+RFC 4531                  LDAP Turn Operation                  June 2006
+
+
+1.  Background and Intent of Use
+
+   The Lightweight Directory Access Protocol (LDAP) [RFC4510][RFC4511]
+   is a client-server protocol that typically operates over reliable
+   octet-stream transports, such as the Transport Control Protocol
+   (TCP).  Generally, the client initiates the stream by connecting to
+   the server's listener at some well-known address.
+
+   There are cases where it is desirable for the server to initiate the
+   stream.  Although it certainly is possible to write a technical
+   specification detailing how to implement server-initiated LDAP
+   sessions, this would require the design of new authentication and
+   other security mechanisms to support server-initiated LDAP sessions.
+
+   Instead, this document introduces an operation, the Turn operation,
+   which may be used to reverse the client-server roles of the protocol
+   peers.  This allows the initiating protocol peer to become the server
+   (after the reversal).
+
+   As an additional feature, the Turn operation may be used to allow
+   both peers to act in both roles.  This is useful where both peers are
+   directory servers that desire to request, as LDAP clients, that
+   operations be performed by the other.  This may be useful in
+   replicated and/or distributed environments.
+
+   This operation is intended to be used between protocol peers that
+   have established a mutual agreement, by means outside of the
+   protocol, that requires reversal of client-server roles, or allows
+   both peers to act both as client and server.
+
+1.1.  Terminology
+
+   Protocol elements are described using ASN.1 [X.680] with implicit
+   tags.  The term "BER-encoded" means the element is to be encoded
+   using the Basic Encoding Rules [X.690] under the restrictions
+   detailed in Section 5.1 of [RFC4511].
+
+2.  Turn Operation
+
+   The Turn operation is defined as an LDAP-Extended Operation
+   [Protocol, Section 4.12] identified by the 1.3.6.1.1.19 OID.  The
+   function of the Turn Operation is to request that the client-server
+   roles be reversed, or, optionally, to request that both protocol
+   peers be able to act both as client and server in respect to the
+   other.
+
+
+
+
+
+
+Zeilenga                      Experimental                      [Page 2]
+
+RFC 4531                  LDAP Turn Operation                  June 2006
+
+
+2.1.  Turn Request
+
+   The Turn request is an ExtendedRequest where the requestName field
+   contains the 1.3.6.1.1.19 OID and the requestValue field is a BER-
+   encoded turnValue:
+
+        turnValue ::= SEQUENCE {
+             mutual         BOOLEAN DEFAULT FALSE,
+             identifier     LDAPString
+        }
+
+   A TRUE mutual field value indicates a request to allow both peers to
+   act both as client and server.  A FALSE mutual field value indicates
+   a request to reserve the client and server roles.
+
+   The value of the identifier field is a locally defined policy
+   identifier (typically associated with a mutual agreement for which
+   this turn is be executed as part of).
+
+2.2.  Turn Response
+
+   A Turn response is an ExtendedResponse where the responseName and
+   responseValue fields are absent.  A resultCode of success is returned
+   if and only if the responder is willing and able to turn the session
+   as requested.  Otherwise, a different resultCode is returned.
+
+3.  Authentication
+
+   This extension's authentication model assumes separate authentication
+   of the peers in each of their roles.  A separate Bind exchange is
+   expected between the peers in their new roles to establish identities
+   in these roles.
+
+   Upon completion of the Turn, the responding peer in its new client
+   role has an anonymous association at the initiating peer in its new
+   server role.  If the turn was mutual, the authentication association
+   of the initiating peer in its pre-existing client role is left intact
+   at the responding peer in its pre-existing server role.  If the turn
+   was not mutual, this association is void.
+
+   The responding peer may establish its identity in its client role by
+   requesting and successfully completing a Bind operation.
+
+   The remainder of this section discusses some authentication
+   scenarios.  In the protocol exchange illustrations, A refers to the
+   initiating peer (the original client) and B refers to the responding
+   peer (the original server).
+
+
+
+
+Zeilenga                      Experimental                      [Page 3]
+
+RFC 4531                  LDAP Turn Operation                  June 2006
+
+
+3.1.  Use with TLS and Simple Authentication
+
+       A->B: StartTLS Request
+       B->A: StartTLS(success) Response
+       A->B: Bind(Simple(cn=B,dc=example,dc=net,B's secret)) Request
+       B->A: Bind(success) Response
+       A->B: Turn(TRUE,"XXYYZ") Request
+       B->A: Turn(success) Response
+       B->A: Bind(Simple(cn=A,dc=example,dc=net,A's secret)) Request
+       A->B: Bind(success) Response
+
+   In this scenario, TLS (Transport Layer Security) [RFC4346] is started
+   and the initiating peer (the original client) establishes its
+   identity with the responding peer prior to the Turn using the
+   DN/password mechanism of the Simple method of the Bind operation.
+   After the turn, the responding peer, in its new client role,
+   establishes its identity with the initiating peer in its new server
+   role.
+
+3.2.  Use with TLS and SASL EXTERNAL
+
+       A->B: StartTLS Request
+       B->A: StartTLS(success) Response
+       A->B: Bind(SASL(EXTERNAL)) Request
+       B->A: Bind(success) Response
+       A->B: Turn(TRUE,"XXYYZ") Request
+       B->A: Turn(success) Response
+       B->A: Bind(SASL(EXTERNAL)) Request
+       A->B: Bind(success) Response
+
+   In this scenario, TLS is started (with each peer providing a valid
+   certificate), and the initiating peer (the original client)
+   establishes its identity through the use of the EXTERNAL mechanism of
+   the SASL (Simple Authentication and Security Layer) [RFC4422] method
+   of the Bind operation prior to the Turn.  After the turn, the
+   responding peer, in its new client role, establishes its identity
+   with the initiating peer in its new server role.
+
+3.3.  Use of Mutual Authentication and SASL EXTERNAL
+
+   A number of SASL mechanisms, such as GSSAPI [SASL-K5], support mutual
+   authentication.  The initiating peer, in its new server role, may use
+   the identity of the responding peer, established by a prior
+   authentication exchange, as its source for "external" identity in
+   subsequent EXTERNAL exchange.
+
+       A->B: Bind(SASL(GSSAPI)) Request
+       <intermediate messages>
+
+
+
+Zeilenga                      Experimental                      [Page 4]
+
+RFC 4531                  LDAP Turn Operation                  June 2006
+
+
+       B->A: Bind(success) Response
+       A->B: Turn(TRUE,"XXYYZ") Request
+       B->A: Turn(success) Response
+       B->A: Bind(SASL(EXTERNAL)) Request
+       A->B: Bind(success) Response
+
+   In this scenario, a GSSAPI mutual-authentication exchange is
+   completed between the initiating peer (the original client) and the
+   responding server (the original server) prior to the turn.  After the
+   turn, the responding peer, in its new client role, requests that the
+   initiating peer utilize an "external" identity to establish its LDAP
+   authorization identity.
+
+4.  TLS and SASL Security Layers
+
+   As described in [RFC4511], LDAP supports both Transport Layer
+   Security (TLS) [RFC4346] and Simple Authentication and Security Layer
+   (SASL) [RFC4422] security frameworks.  The following table
+   illustrates the relationship between the LDAP message layer, SASL
+   layer, TLS layer, and transport connection within an LDAP session.
+
+                  +----------------------+
+                  |  LDAP message layer  |
+                  +----------------------+ > LDAP PDUs
+                  +----------------------+ < data
+                  |      SASL layer      |
+                  +----------------------+ > SASL-protected data
+                  +----------------------+ < data
+                  |       TLS layer      |
+      Application +----------------------+ > TLS-protected data
+      ------------+----------------------+ < data
+        Transport | transport connection |
+                  +----------------------+
+
+   This extension does not alter this relationship, nor does it remove
+   the general restriction against multiple TLS layers, nor does it
+   remove the general restriction against multiple SASL layers.
+
+   As specified in [RFC4511], the StartTLS operation is used to initiate
+   negotiation of a TLS layer.  If a TLS is already installed, the
+   StartTLS operation must fail.  Upon establishment of the TLS layer,
+   regardless of which peer issued the request to start TLS, the peer
+   that initiated the LDAP session (the original client) performs the
+   "server identity check", as described in Section 3.1.5 of [RFC4513],
+   treating itself as the "client" and its peer as the "server".
+
+   As specified in [RFC4422], a newly negotiated SASL security layer
+   replaces the installed SASL security layer.  Though the client/server
+
+
+
+Zeilenga                      Experimental                      [Page 5]
+
+RFC 4531                  LDAP Turn Operation                  June 2006
+
+
+   roles in LDAP, and hence SASL, may be reversed in subsequent
+   exchanges, only one SASL security layer may be installed at any
+   instance.
+
+5.  Security Considerations
+
+   Implementors should be aware that the reversing of client/server
+   roles and/or allowing both peers to act as client and server likely
+   introduces security considerations not foreseen by the authors of
+   this document.  In particular, the security implications of the
+   design choices made in the authentication and data security models
+   for this extension (discussed in Sections 3 and 4, respectively) are
+   not fully studied.  It is hoped that experimentation with this
+   extension will lead to better understanding of the security
+   implications of these models and other aspects of this extension, and
+   that appropriate considerations will be documented in a future
+   document.  The following security considerations are apparent at this
+   time.
+
+   Implementors should take special care to process LDAP, SASL, TLS, and
+   other events in the appropriate roles for the peers.  Note that while
+   the Turn reverses the client/server roles with LDAP, and in SASL
+   authentication exchanges, it does not reverse the roles within the
+   TLS layer or the transport connection.
+
+   The responding server (the original server) should restrict use of
+   this operation to authorized clients.  Client knowledge of a valid
+   identifier should not be the sole factor in determining authorization
+   to turn.
+
+   Where the peers except to establish TLS, TLS should be started prior
+   to the Turn and any request to authenticate via the Bind operation.
+
+   LDAP security considerations [RFC4511][RFC4513] generally apply to
+   this extension.
+
+6.  IANA Considerations
+
+   The following values [RFC4520] have been registered by the IANA.
+
+6.1.  Object Identifier
+
+   The IANA has assigned an LDAP Object Identifier to identify the LDAP
+   Turn Operation, as defined in this document.
+
+
+
+
+
+
+
+Zeilenga                      Experimental                      [Page 6]
+
+RFC 4531                  LDAP Turn Operation                  June 2006
+
+
+       Subject: Request for LDAP Object Identifier Registration
+       Person & email address to contact for further information:
+            Kurt Zeilenga <kurt@OpenLDAP.org>
+       Specification: RFC 4531
+       Author/Change Controller: Author
+       Comments:
+            Identifies the LDAP Turn Operation
+
+6.2.  LDAP Protocol Mechanism
+
+   The IANA has registered the LDAP Protocol Mechanism described in this
+   document.
+
+       Subject: Request for LDAP Protocol Mechanism Registration
+       Object Identifier: 1.3.6.1.1.19
+       Description: LDAP Turn Operation
+       Person & email address to contact for further information:
+            Kurt Zeilenga <kurt@openldap.org>
+       Usage: Extended Operation
+       Specification: RFC 4531
+       Author/Change Controller: Author
+       Comments: none
+
+7.  References
+
+7.1.  Normative References
+
+   [RFC4346]     Dierks, T. and, E. Rescorla, "The Transport Layer
+                 Security (TLS) Protocol Version 1.1", RFC 4346, April
+                 2006.
+
+   [RFC4422]     Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple
+                 Authentication and Security Layer (SASL)", RFC 4422,
+                 June 2006.
+
+   [RFC4510]     Zeilenga, K., Ed., "Lightweight Directory Access
+                 Protocol (LDAP): Technical Specification Road Map", RFC
+                 4510, June 2006.
+
+   [RFC4511]     Sermersheim, J., Ed., "Lightweight Directory Access
+                 Protocol (LDAP): The Protocol", RFC 4511, June 2006.
+
+   [RFC4513]     Harrison, R., Ed., "Lightweight Directory Access
+                 Protocol (LDAP): Authentication Methods and Security
+                 Mechanisms", RFC 4513, June 2006.
+
+
+
+
+
+
+Zeilenga                      Experimental                      [Page 7]
+
+RFC 4531                  LDAP Turn Operation                  June 2006
+
+
+   [X.680]       International Telecommunication Union -
+                 Telecommunication Standardization Sector, "Abstract
+                 Syntax Notation One (ASN.1) - Specification of Basic
+                 Notation", X.680(2002) (also ISO/IEC 8824-1:2002).
+
+   [X.690]       International Telecommunication Union -
+                 Telecommunication Standardization Sector,
+                 "Specification of ASN.1 encoding rules: Basic Encoding
+                 Rules (BER), Canonical Encoding Rules (CER), and
+                 Distinguished Encoding Rules (DER)", X.690(2002) (also
+                 ISO/IEC 8825-1:2002).
+
+7.2.  Informative References
+
+   [RFC4520]     Zeilenga, K., "Internet Assigned Numbers Authority
+                 (IANA) Considerations for the Lightweight Directory
+                 Access Protocol (LDAP)", BCP 64, RFC 4520, June 2006.
+
+   [SASL-K5]     Melnikov, A., Ed., "The Kerberos V5 ("GSSAPI") SASL
+                 Mechanism", Work in Progress, May 2006.
+
+Author's Address
+
+   Kurt D. Zeilenga
+   OpenLDAP Foundation
+
+   EMail: Kurt@OpenLDAP.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga                      Experimental                      [Page 8]
+
+RFC 4531                  LDAP Turn Operation                  June 2006
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2006).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Zeilenga                      Experimental                      [Page 9]
+
diff --git a/source4/ldap_server/devdocs/rfc4532.txt b/source4/ldap_server/devdocs/rfc4532.txt
new file mode 100644
index 0000000000..277b3b7442
--- /dev/null
+++ b/source4/ldap_server/devdocs/rfc4532.txt
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+Network Working Group                                        K. Zeilenga
+Request for Comments: 4532                           OpenLDAP Foundation
+Category: Standards Track                                      June 2006
+
+
+              Lightweight Directory Access Protocol (LDAP)
+                         "Who am I?" Operation
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   This specification provides a mechanism for Lightweight Directory
+   Access Protocol (LDAP) clients to obtain the authorization identity
+   the server has associated with the user or application entity.  This
+   mechanism is specified as an LDAP extended operation called the LDAP
+   "Who am I?" operation.
+
+1.  Background and Intent of Use
+
+   This specification describes a Lightweight Directory Access Protocol
+   (LDAP) [RFC4510] operation that clients can use to obtain the primary
+   authorization identity, in its primary form, that the server has
+   associated with the user or application entity.  The operation is
+   called the "Who am I?" operation.
+
+   This specification is intended to replace the existing Authorization
+   Identity Controls [RFC3829] mechanism, which uses Bind request and
+   response controls to request and return the authorization identity.
+   Bind controls are not protected by security layers established by the
+   Bind operation that includes them.  While it is possible to establish
+   security layers using StartTLS [RFC4511][RFC4513] prior to the Bind
+   operation, it is often desirable to use security layers established
+   by the Bind operation.  An extended operation sent after a Bind
+   operation is protected by the security layers established by the Bind
+   operation.
+
+
+
+
+
+Zeilenga                    Standards Track                     [Page 1]
+
+RFC 4532               LDAP "Who am I?" Operation              June 2006
+
+
+   There are other cases where it is desirable to request the
+   authorization identity that the server associated with the client
+   separately from the Bind operation.  For example, the "Who am I?"
+   operation can be augmented with a Proxied Authorization Control
+   [RFC4370] to determine the authorization identity that the server
+   associates with the identity asserted in the Proxied Authorization
+   Control.  The "Who am I?" operation can also be used prior to the
+   Bind operation.
+
+   Servers often associate multiple authorization identities with the
+   client, and each authorization identity may be represented by
+   multiple authzId [RFC4513] strings.  This operation requests and
+   returns the authzId that the server considers primary.  In the
+   specification, the term "the authorization identity" and "the
+   authzId" are generally to be read as "the primary authorization
+   identity" and the "the primary authzId", respectively.
+
+1.1.  Conventions Used in This Document
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in BCP 14 [RFC2119].
+
+2.  The "Who am I?" Operation
+
+   The "Who am I?" operation is defined as an LDAP Extended Operation
+   [RFC4511] identified by the whoamiOID Object Identifier (OID).  This
+   section details the syntax of the operation's whoami request and
+   response messages.
+
+      whoamiOID ::= "1.3.6.1.4.1.4203.1.11.3"
+
+2.1.  The whoami Request
+
+   The whoami request is an ExtendedRequest with a requestName field
+   containing the whoamiOID OID and an absent requestValue field.  For
+   example, a whoami request could be encoded as the sequence of octets
+   (in hex):
+
+      30 1e 02 01 02 77 19 80  17 31 2e 33 2e 36 2e 31
+      2e 34 2e 31 2e 34 32 30  33 2e 31 2e 31 31 2e 33
+
+
+
+
+
+
+
+
+
+
+Zeilenga                    Standards Track                     [Page 2]
+
+RFC 4532               LDAP "Who am I?" Operation              June 2006
+
+
+2.2.  The whoami Response
+
+   The whoami response is an ExtendedResponse where the responseName
+   field is absent and the response field, if present, is empty or an
+   authzId [RFC4513].  For example, a whoami response returning the
+   authzId "u:xxyyz@EXAMPLE.NET" (in response to the example request)
+   would be encoded as the sequence of octets (in hex):
+
+      30 21 02 01 02 78 1c 0a  01 00 04 00 04 00 8b 13
+      75 3a 78 78 79 79 7a 40  45 58 41 4d 50 4c 45 2e
+      4e 45 54
+
+3.  Operational Semantics
+
+   The "Who am I?" operation provides a mechanism, a whoami Request, for
+   the client to request that the server return the authorization
+   identity it currently associates with the client.  It also provides a
+   mechanism, a whoami Response, for the server to respond to that
+   request.
+
+   Servers indicate their support for this extended operation by
+   providing a whoamiOID object identifier as a value of the
+   'supportedExtension' attribute type in their root DSE.  The server
+   SHOULD advertise this extension only when the client is willing and
+   able to perform this operation.
+
+   If the server is willing and able to provide the authorization
+   identity it associates with the client, the server SHALL return a
+   whoami Response with a success resultCode.  If the server is treating
+   the client as an anonymous entity, the response field is present but
+   empty.  Otherwise, the server provides the authzId [RFC4513]
+   representing the authorization identity it currently associates with
+   the client in the response field.
+
+   If the server is unwilling or unable to provide the authorization
+   identity it associates with the client, the server SHALL return a
+   whoami Response with an appropriate non-success resultCode (such as
+   operationsError, protocolError, confidentialityRequired,
+   insufficientAccessRights, busy, unavailable, unwillingToPerform, or
+   other) and an absent response field.
+
+   As described in [RFC4511] and [RFC4513], an LDAP session has an
+   "anonymous" association until the client has been successfully
+   authenticated using the Bind operation.  Clients MUST NOT invoke the
+   "Who am I?" operation while any Bind operation is in progress,
+   including between two Bind requests made as part of a multi-stage
+
+
+
+
+
+Zeilenga                    Standards Track                     [Page 3]
+
+RFC 4532               LDAP "Who am I?" Operation              June 2006
+
+
+   Bind operation.  Where a whoami Request is received in violation of
+   this absolute prohibition, the server should return a whoami Response
+   with an operationsError resultCode.
+
+4.  Extending the "Who am I?" Operation with Controls
+
+   Future specifications may extend the "Who am I?" operation using the
+   control mechanism [RFC4511].  When extended by controls, the "Who am
+   I?" operation requests and returns the authorization identity the
+   server associates with the client in a particular context indicated
+   by the controls.
+
+4.1.  Proxied Authorization Control
+
+   The Proxied Authorization Control [RFC4370] is used by clients to
+   request that the operation it is attached to operate under the
+   authorization of an assumed identity.  The client provides the
+   identity to assume in the Proxied Authorization request control.  If
+   the client is authorized to assume the requested identity, the server
+   executes the operation as if the requested identity had issued the
+   operation.
+
+   As servers often map the asserted authzId to another identity
+   [RFC4513], it is desirable to request that the server provide the
+   authzId it associates with the assumed identity.
+
+   When a Proxied Authorization Control is be attached to the "Who am
+   I?"  operation, the operation requests the return of the authzId the
+   server associates with the identity asserted in the Proxied
+   Authorization Control.  The authorizationDenied (123) result code is
+   used to indicate that the server does not allow the client to assume
+   the asserted identity.
+
+5.  Security Considerations
+
+   Identities associated with users may be sensitive information.  When
+   they are, security layers [RFC4511][RFC4513] should be established to
+   protect this information.  This mechanism is specifically designed to
+   allow security layers established by a Bind operation to protect the
+   integrity and/or confidentiality of the authorization identity.
+
+   Servers may place access control or other restrictions upon the use
+   of this operation.  As stated in Section 3, the server SHOULD
+   advertise this extension when it is willing and able to perform the
+   operation.
+
+   As with any other extended operations, general LDAP security
+   considerations [RFC4510] apply.
+
+
+
+Zeilenga                    Standards Track                     [Page 4]
+
+RFC 4532               LDAP "Who am I?" Operation              June 2006
+
+
+6.  IANA Considerations
+
+   The OID 1.3.6.1.4.1.4203.1.11.3 is used to identify the LDAP "Who am
+   I?" extended operation.  This OID was assigned [ASSIGN] by the
+   OpenLDAP Foundation, under its IANA-assigned private enterprise
+   allocation [PRIVATE], for use in this specification.
+
+   Registration of this protocol mechanism [RFC4520] has been completed
+   by the IANA.
+
+   Subject: Request for LDAP Protocol Mechanism Registration
+   Object Identifier: 1.3.6.1.4.1.4203.1.11.3
+   Description: Who am I?
+   Person & email address to contact for further information:
+        Kurt Zeilenga <kurt@openldap.org>
+   Usage: Extended Operation
+   Specification: RFC 4532
+   Author/Change Controller: IESG
+   Comments: none
+
+7.  Acknowledgement
+
+   This document borrows from prior work in this area, including
+   "Authentication Response Control" [RFC3829] by Rob Weltman, Mark
+   Smith, and Mark Wahl.
+
+   The LDAP "Who am I?" operation takes it's name from the UNIX
+   whoami(1) command.  The whoami(1) command displays the effective user
+   ID.
+
+8.  References
+
+8.1.  Normative References
+
+   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+             Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC4370] Weltman, R., "Lightweight Directory Access Protocol (LDAP)
+             Proxied Authorization Control", RFC 4370, February 2006.
+
+   [RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access Protocol
+             (LDAP): Technical Specification Road Map", RFC 4510, June
+             2006.
+
+   [RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access
+             Protocol (LDAP): The Protocol", RFC 4511, June 2006.
+
+
+
+
+
+Zeilenga                    Standards Track                     [Page 5]
+
+RFC 4532               LDAP "Who am I?" Operation              June 2006
+
+
+   [RFC4513] Harrison, R., Ed., "Lightweight Directory Access Protocol
+             (LDAP): Authentication Methods and Security Mechanisms",
+             RFC 4513, June 2006.
+
+8.2.  Informative References
+
+   [RFC3829] Weltman, R., Smith, M., and M. Wahl, "Lightweight Directory
+             Access Protocol (LDAP) Authorization Identity Request and
+             Response Controls", RFC 3829, July 2004.
+
+   [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
+             Considerations for the Lightweight Directory Access
+             Protocol (LDAP)", BCP 64, RFC 4520, June 2006.
+
+   [ASSIGN]  OpenLDAP Foundation, "OpenLDAP OID Delegations",
+             http://www.openldap.org/foundation/oid-delegate.txt.
+
+   [PRIVATE] IANA, "Private Enterprise Numbers",
+             http://www.iana.org/assignments/enterprise-numbers.
+
+Author's Address
+
+   Kurt D. Zeilenga
+   OpenLDAP Foundation
+
+   EMail: Kurt@OpenLDAP.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga                    Standards Track                     [Page 6]
+
+RFC 4532               LDAP "Who am I?" Operation              June 2006
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2006).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Zeilenga                    Standards Track                     [Page 7]
+
diff --git a/source4/ldap_server/devdocs/rfc4533.txt b/source4/ldap_server/devdocs/rfc4533.txt
new file mode 100644
index 0000000000..5f507ceae8
--- /dev/null
+++ b/source4/ldap_server/devdocs/rfc4533.txt
@@ -0,0 +1,1795 @@
+
+
+
+
+
+
+Network Working Group                                        K. Zeilenga
+Request for Comments: 4533                           OpenLDAP Foundation
+Category: Experimental                                         J.H. Choi
+                                                         IBM Corporation
+                                                               June 2006
+
+
+           The Lightweight Directory Access Protocol (LDAP)
+                   Content Synchronization Operation
+
+Status of This Memo
+
+   This memo defines an Experimental Protocol for the Internet
+   community.  It does not specify an Internet standard of any kind.
+   Discussion and suggestions for improvement are requested.
+   Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+IESG Note
+
+   The IESG notes that this work was originally discussed in the LDUP
+   working group.  The group came to consensus on a different approach,
+   documented in RFC 3928; that document is on the standards track and
+   should be reviewed by those considering implementation of this
+   proposal.
+
+Abstract
+
+   This specification describes the Lightweight Directory Access
+   Protocol (LDAP) Content Synchronization Operation.  The operation
+   allows a client to maintain a copy of a fragment of the Directory
+   Information Tree (DIT).  It supports both polling for changes and
+   listening for changes.  The operation is defined as an extension of
+   the LDAP Search Operation.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga & Choi               Experimental                      [Page 1]
+
+RFC 4533         LDAP Content Synchronization Operation        June 2006
+
+
+Table of Contents
+
+   1. Introduction ....................................................3
+      1.1. Background .................................................3
+      1.2. Intended Usage .............................................4
+      1.3. Overview ...................................................5
+      1.4. Conventions ................................................8
+   2. Elements of the Sync Operation ..................................8
+      2.1. Common ASN.1 Elements ......................................9
+      2.2. Sync Request Control .......................................9
+      2.3. Sync State Control ........................................10
+      2.4. Sync Done Control .........................................10
+      2.5. Sync Info Message .........................................11
+      2.6. Sync Result Codes .........................................11
+   3. Content Synchronization ........................................11
+      3.1. Synchronization Session ...................................12
+      3.2. Content Determination .....................................12
+      3.3. refreshOnly Mode ..........................................13
+      3.4. refreshAndPersist Mode ....................................16
+      3.5. Search Request Parameters .................................17
+      3.6. objectName ................................................18
+      3.7. Canceling the Sync Operation ..............................19
+      3.8. Refresh Required ..........................................19
+      3.9. Chattiness Considerations .................................20
+      3.10. Operation Multiplexing ...................................21
+   4. Meta Information Considerations ................................22
+      4.1. Entry DN ..................................................22
+      4.2. Operational Attributes ....................................22
+      4.3. Collective Attributes .....................................23
+      4.4. Access and Other Administrative Controls ..................23
+   5. Interaction with Other Controls ................................23
+      5.1. ManageDsaIT Control .......................................24
+      5.2. Subentries Control ........................................24
+   6. Shadowing Considerations .......................................24
+   7. Security Considerations ........................................25
+   8. IANA Considerations ............................................26
+      8.1. Object Identifier .........................................26
+      8.2. LDAP Protocol Mechanism ...................................26
+      8.3. LDAP Result Codes .........................................26
+   9. Acknowledgements ...............................................26
+   10. Normative References ..........................................27
+   11. Informative References ........................................28
+   Appendix A.  CSN-based Implementation Considerations ..............29
+
+
+
+
+
+
+
+
+Zeilenga & Choi               Experimental                      [Page 2]
+
+RFC 4533         LDAP Content Synchronization Operation        June 2006
+
+
+1.  Introduction
+
+   The Lightweight Directory Access Protocol (LDAP) [RFC4510] provides a
+   mechanism, the search operation [RFC4511], that allows a client to
+   request directory content matching a complex set of assertions and to
+   request that the server return this content, subject to access
+   control and other restrictions, to the client.  However, LDAP does
+   not provide (despite the introduction of numerous extensions in this
+   area) an effective and efficient mechanism for maintaining
+   synchronized copies of directory content.  This document introduces a
+   new mechanism specifically designed to meet the content
+   synchronization requirements of sophisticated directory applications.
+
+   This document defines the LDAP Content Synchronization Operation, or
+   Sync Operation for short, which allows a client to maintain a
+   synchronized copy of a fragment of a Directory Information Tree
+   (DIT).  The Sync Operation is defined as a set of controls and other
+   protocol elements that extend the Search Operation.
+
+1.1.  Background
+
+   Over the years, a number of content synchronization approaches have
+   been suggested for use in LDAP directory services.  These approaches
+   are inadequate for one or more of the following reasons:
+
+      -  failure to ensure a reasonable level of convergence;
+
+      -  failure to detect that convergence cannot be achieved (without
+         reload);
+
+      -  require pre-arranged synchronization agreements;
+
+      -  require the server to maintain histories of past changes to DIT
+         content and/or meta information;
+
+      -  require the server to maintain synchronization state on a per-
+         client basis; and/or
+
+      -  are overly chatty.
+
+   The Sync Operation provides eventual convergence of synchronized
+   content when possible and, when not, notification that a full reload
+   is required.
+
+   The Sync Operation does not require pre-arranged synchronization
+   agreements.
+
+
+
+
+
+Zeilenga & Choi               Experimental                      [Page 3]
+
+RFC 4533         LDAP Content Synchronization Operation        June 2006
+
+
+   The Sync Operation does not require that servers maintain or use any
+   history of past changes to the DIT or to meta information.  However,
+   servers may maintain and use histories (e.g., change logs,
+   tombstones, DIT snapshots) to reduce the number of messages generated
+   and to reduce their size.  As it is not always feasible to maintain
+   and use histories, the operation may be implemented using purely
+   (current) state-based approaches.  The Sync Operation allows use of
+   either the state-based approach or the history-based approach on an
+   operation-by-operation basis to balance the size of history and the
+   amount of traffic.  The Sync Operation also allows the combined use
+   of the state-based and the history-based approaches.
+
+   The Sync Operation does not require that servers maintain
+   synchronization state on a per-client basis.  However, servers may
+   maintain and use per-client state information to reduce the number of
+   messages generated and the size of such messages.
+
+   A synchronization mechanism can be considered overly chatty when
+   synchronization traffic is not reasonably bounded.  The Sync
+   Operation traffic is bounded by the size of updated (or new) entries
+   and the number of unchanged entries in the content.  The operation is
+   designed to avoid full content exchanges, even when the history
+   information available to the server is insufficient to determine the
+   client's state.  The operation is also designed to avoid transmission
+   of out-of-content history information, as its size is not bounded by
+   the content and it is not always feasible to transmit such history
+   information due to security reasons.
+
+   This document includes a number of non-normative appendices providing
+   additional information to server implementors.
+
+1.2.  Intended Usage
+
+   The Sync Operation is intended to be used in applications requiring
+   eventually-convergent content synchronization.  Upon completion of
+   each synchronization stage of the operation, all information to
+   construct a synchronized client copy of the content has been provided
+   to the client or the client has been notified that a complete content
+   reload is necessary.  Except for transient inconsistencies due to
+   concurrent operation (or other) processing at the server, the client
+   copy is an accurate reflection of the content held by the server.
+   Transient inconsistencies will be resolved by subsequent
+   synchronization operations.
+
+
+
+
+
+
+
+
+Zeilenga & Choi               Experimental                      [Page 4]
+
+RFC 4533         LDAP Content Synchronization Operation        June 2006
+
+
+   Possible uses include the following:
+
+      -  White page service applications may use the Sync Operation to
+         maintain a current copy of a DIT fragment, for example, a mail
+         user agent that uses the sync operation to maintain a local
+         copy of an enterprise address book.
+
+      -  Meta-information engines may use the Sync Operation to maintain
+         a copy of a DIT fragment.
+
+      -  Caching proxy services may use the Sync Operation to maintain a
+         coherent content cache.
+
+      -  Lightweight master-slave replication between heterogeneous
+         directory servers.  For example, the Sync Operation can be used
+         by a slave server to maintain a shadow copy of a DIT fragment.
+         (Note: The International Telephone Union (ITU) has defined the
+         X.500 Directory [X.500] Information Shadowing Protocol (DISP)
+         [X.525], which may be used for master-slave replication between
+         directory servers.  Other experimental LDAP replication
+         protocols also exist.)
+
+   This protocol is not intended to be used in applications requiring
+   transactional data consistency.
+
+   As this protocol transfers all visible values of entries belonging to
+   the content upon change instead of change deltas, this protocol is
+   not appropriate for bandwidth-challenged applications or deployments.
+
+1.3.  Overview
+
+   This section provides an overview of basic ways the Sync Operation
+   can be used to maintain a synchronized client copy of a DIT fragment.
+
+      -  Polling for changes: refreshOnly mode
+
+      -  Listening for changes: refreshAndPersist mode
+
+1.3.1.  Polling for Changes (refreshOnly)
+
+   To obtain its initial client copy, the client issues a Sync request:
+   a search request with the Sync Request Control with mode set to
+   refreshOnly.  The server, much like it would with a normal search
+   operation, returns (subject to access controls and other
+   restrictions) the content matching the search criteria (baseObject,
+   scope, filter, attributes).  Additionally, with each entry returned,
+   the server provides a Sync State Control indicating state add.  This
+   control contains the Universally Unique Identifier (UUID) [UUID] of
+
+
+
+Zeilenga & Choi               Experimental                      [Page 5]
+
+RFC 4533         LDAP Content Synchronization Operation        June 2006
+
+
+   the entry [RFC4530].  Unlike the Distinguished Name (DN), which may
+   change over time, an entry's UUID is stable.  The initial content is
+   followed by a SearchResultDone with a Sync Done Control.  The Sync
+   Done Control provides a syncCookie.  The syncCookie represents
+   session state.
+
+   To poll for updates to the client copy, the client reissues the Sync
+   Operation with the syncCookie previously returned.  The server, much
+   as it would with a normal search operation, determines which content
+   would be returned as if the operation were a normal search operation.
+   However, using the syncCookie as an indicator of what content the
+   client was sent previously, the server sends copies of entries that
+   have changed with a Sync State Control indicating state add.  For
+   each changed entry, all (modified or unmodified) attributes belonging
+   to the content are sent.
+
+   The server may perform either or both of the two distinct
+   synchronization phases that are distinguished by how to synchronize
+   entries deleted from the content: the present and the delete phases.
+   When the server uses a single phase for the refresh stage, each phase
+   is marked as ended by a SearchResultDone with a Sync Done Control.  A
+   present phase is identified by a FALSE refreshDeletes value in the
+   Sync Done Control.  A delete phase is identified by a TRUE
+   refreshDeletes value.  The present phase may be followed by a delete
+   phase.  The two phases are delimited by a refreshPresent Sync Info
+   Message having a FALSE refreshDone value.  In the case that both the
+   phases are used, the present phase is used to bring the client copy
+   up to the state at which the subsequent delete phase can begin.
+
+   In the present phase, the server sends an empty entry (i.e., no
+   attributes) with a Sync State Control indicating state present for
+   each unchanged entry.
+
+   The delete phase may be used when the server can reliably determine
+   which entries in the prior client copy are no longer present in the
+   content and the number of such entries is less than or equal to the
+   number of unchanged entries.  In the delete mode, the server sends an
+   empty entry with a Sync State Control indicating state delete for
+   each entry that is no longer in the content, instead of returning an
+   empty entry with state present for each present entry.
+
+   The server may send syncIdSet Sync Info Messages containing the set
+   of UUIDs of either unchanged present entries or deleted entries,
+   instead of sending multiple individual messages.  If refreshDeletes
+   of syncIdSet is set to FALSE, the UUIDs of unchanged present entries
+   are contained in the syncUUIDs set; if refreshDeletes of syncIdSet is
+   set to TRUE, the UUIDs of the entries no longer present in the
+   content are contained in the syncUUIDs set.  An optional cookie can
+
+
+
+Zeilenga & Choi               Experimental                      [Page 6]
+
+RFC 4533         LDAP Content Synchronization Operation        June 2006
+
+
+   be included in the syncIdSet to represent the state of the content
+   after synchronizing the presence or the absence of the entries
+   contained in the syncUUIDs set.
+
+   The synchronized copy of the DIT fragment is constructed by the
+   client.
+
+   If refreshDeletes of syncDoneValue is FALSE, the new copy includes
+   all changed entries returned by the reissued Sync Operation, as well
+   as all unchanged entries identified as being present by the reissued
+   Sync Operation, but whose content is provided by the previous Sync
+   Operation.  The unchanged entries not identified as being present are
+   deleted from the client content.  They had been either deleted,
+   moved, or otherwise scoped-out from the content.
+
+   If refreshDeletes of syncDoneValue is TRUE, the new copy includes all
+   changed entries returned by the reissued Sync Operation, as well as
+   all other entries of the previous copy except for those that are
+   identified as having been deleted from the content.
+
+   The client can, at some later time, re-poll for changes to this
+   synchronized client copy.
+
+1.3.2.  Listening for Changes (refreshAndPersist)
+
+   Polling for changes can be expensive in terms of server, client, and
+   network resources.  The refreshAndPersist mode allows for active
+   updates of changed entries in the content.
+
+   By selecting the refreshAndPersist mode, the client requests that the
+   server send updates of entries that are changed after the initial
+   refresh content is determined.  Instead of sending a SearchResultDone
+   Message as in polling, the server sends a Sync Info Message to the
+   client indicating that the refresh stage is complete and then enters
+   the persist stage.  After receipt of this Sync Info Message, the
+   client will construct a synchronized copy as described in Section
+   1.3.1.
+
+   The server may then send change notifications as the result of the
+   original Sync search request, which now remains persistent in the
+   server.  For entries to be added to the returned content, the server
+   sends a SearchResultEntry (with attributes) with a Sync State Control
+   indicating state add.  For entries to be deleted from the content,
+   the server sends a SearchResultEntry containing no attributes and a
+   Sync State Control indicating state delete.  For entries to be
+   modified in the return content, the server sends a SearchResultEntry
+   (with attributes) with a Sync State Control indicating state modify.
+
+
+
+
+Zeilenga & Choi               Experimental                      [Page 7]
+
+RFC 4533         LDAP Content Synchronization Operation        June 2006
+
+
+   Upon modification of an entry, all (modified or unmodified)
+   attributes belonging to the content are sent.
+
+   Note that renaming an entry of the DIT may cause an add state change
+   where the entry is renamed into the content, a delete state change
+   where the entry is renamed out of the content, and a modify state
+   change where the entry remains in the content.  Also note that a
+   modification of an entry of the DIT may cause an add, delete, or
+   modify state change to the content.
+
+   Upon receipt of a change notification, the client updates its copy of
+   the content.
+
+   If the server desires to update the syncCookie during the persist
+   stage, it may include the syncCookie in any Sync State Control or
+   Sync Info Message returned.
+
+   The operation persists until canceled [RFC3909] by the client or
+   terminated by the server.  A Sync Done Control shall be attached to
+   SearchResultDone Message to provide a new syncCookie.
+
+1.4.  Conventions
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in BCP 14 [RFC2119].
+
+   Protocol elements are described using ASN.1 [X.680] with implicit
+   tags.  The term "BER-encoded" means the element is to be encoded
+   using the Basic Encoding Rules [X.690] under the restrictions
+   detailed in Section 5.1 of [RFC4511].
+
+2.  Elements of the Sync Operation
+
+   The Sync Operation is defined as an extension to the LDAP Search
+   Operation [RFC4511] where the directory user agent (DUA or client)
+   submits a SearchRequest Message with a Sync Request Control and the
+   directory system agent (DSA or server) responds with zero or more
+   SearchResultEntry Messages, each with a Sync State Control; zero or
+   more SearchResultReference Messages, each with a Sync State Control;
+   zero or more Sync Info Intermediate Response Messages; and a
+   SearchResultDone Message with a Sync Done Control.
+
+   To allow clients to discover support for this operation, servers
+   implementing this operation SHOULD publish 1.3.6.1.4.1.4203.1.9.1.1
+   as a value of the 'supportedControl' attribute [RFC4512] of the root
+   DSA-specific entry (DSE).  A server MAY choose to advertise this
+   extension only when the client is authorized to use it.
+
+
+
+Zeilenga & Choi               Experimental                      [Page 8]
+
+RFC 4533         LDAP Content Synchronization Operation        June 2006
+
+
+2.1.  Common ASN.1 Elements
+
+2.1.1.  syncUUID
+
+   The syncUUID data type is an OCTET STRING holding a 128-bit
+   (16-octet) Universally Unique Identifier (UUID) [UUID].
+
+      syncUUID ::= OCTET STRING (SIZE(16))
+           -- constrained to UUID
+
+2.1.2.  syncCookie
+
+   The syncCookie is a notational convenience to indicate that, while
+   the syncCookie type is encoded as an OCTET STRING, its value is an
+   opaque value containing information about the synchronization session
+   and its state.  Generally, the session information would include a
+   hash of the operation parameters that the server requires not be
+   changed and the synchronization state information would include a
+   commit (log) sequence number, a change sequence number, or a time
+   stamp.  For convenience of description, the term "no cookie" refers
+   either to a null cookie or to a cookie with pre-initialized
+   synchronization state.
+
+      syncCookie ::= OCTET STRING
+
+2.2.  Sync Request Control
+
+   The Sync Request Control is an LDAP Control [RFC4511] where the
+   controlType is the object identifier 1.3.6.1.4.1.4203.1.9.1.1 and the
+   controlValue, an OCTET STRING, contains a BER-encoded
+   syncRequestValue.  The criticality field is either TRUE or FALSE.
+
+      syncRequestValue ::= SEQUENCE {
+          mode ENUMERATED {
+              -- 0 unused
+              refreshOnly       (1),
+              -- 2 reserved
+              refreshAndPersist (3)
+          },
+          cookie     syncCookie OPTIONAL,
+          reloadHint BOOLEAN DEFAULT FALSE
+      }
+
+   The Sync Request Control is only applicable to the SearchRequest
+   Message.
+
+
+
+
+
+
+Zeilenga & Choi               Experimental                      [Page 9]
+
+RFC 4533         LDAP Content Synchronization Operation        June 2006
+
+
+2.3.  Sync State Control
+
+   The Sync State Control is an LDAP Control [RFC4511] where the
+   controlType is the object identifier 1.3.6.1.4.1.4203.1.9.1.2 and the
+   controlValue, an OCTET STRING, contains a BER-encoded syncStateValue.
+   The criticality is FALSE.
+
+      syncStateValue ::= SEQUENCE {
+          state ENUMERATED {
+              present (0),
+              add (1),
+              modify (2),
+              delete (3)
+          },
+          entryUUID syncUUID,
+          cookie    syncCookie OPTIONAL
+      }
+
+   The Sync State Control is only applicable to SearchResultEntry and
+   SearchResultReference Messages.
+
+2.4.  Sync Done Control
+
+   The Sync Done Control is an LDAP Control [RFC4511] where the
+   controlType is the object identifier 1.3.6.1.4.1.4203.1.9.1.3 and the
+   controlValue contains a BER-encoded syncDoneValue.  The criticality
+   is FALSE (and hence absent).
+
+      syncDoneValue ::= SEQUENCE {
+          cookie          syncCookie OPTIONAL,
+          refreshDeletes  BOOLEAN DEFAULT FALSE
+      }
+
+   The Sync Done Control is only applicable to the SearchResultDone
+   Message.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga & Choi               Experimental                     [Page 10]
+
+RFC 4533         LDAP Content Synchronization Operation        June 2006
+
+
+2.5.  Sync Info Message
+
+   The Sync Info Message is an LDAP Intermediate Response Message
+   [RFC4511] where responseName is the object identifier
+   1.3.6.1.4.1.4203.1.9.1.4 and responseValue contains a BER-encoded
+   syncInfoValue.  The criticality is FALSE (and hence absent).
+
+      syncInfoValue ::= CHOICE {
+          newcookie      [0] syncCookie,
+          refreshDelete  [1] SEQUENCE {
+              cookie         syncCookie OPTIONAL,
+              refreshDone    BOOLEAN DEFAULT TRUE
+          },
+          refreshPresent [2] SEQUENCE {
+              cookie         syncCookie OPTIONAL,
+              refreshDone    BOOLEAN DEFAULT TRUE
+          },
+          syncIdSet      [3] SEQUENCE {
+              cookie         syncCookie OPTIONAL,
+              refreshDeletes BOOLEAN DEFAULT FALSE,
+              syncUUIDs      SET OF syncUUID
+          }
+      }
+
+2.6.  Sync Result Codes
+
+   The following LDAP resultCode [RFC4511] is defined:
+
+      e-syncRefreshRequired (4096)
+
+3.  Content Synchronization
+
+   The Sync Operation is invoked when the client sends a SearchRequest
+   Message with a Sync Request Control.
+
+   The absence of a cookie or an initialized synchronization state in a
+   cookie indicates a request for initial content, while the presence of
+   a cookie representing a state of a client copy indicates a request
+   for a content update.  Synchronization Sessions are discussed in
+   Section 3.1.  Content Determination is discussed in Section 3.2.
+
+   The mode is either refreshOnly or refreshAndPersist.  The refreshOnly
+   and refreshAndPersist modes are discussed in Sections 3.3 and 3.4,
+   respectively.  The refreshOnly mode consists only of a refresh stage,
+   while the refreshAndPersist mode consists of a refresh stage and a
+   subsequent persist stage.
+
+
+
+
+
+Zeilenga & Choi               Experimental                     [Page 11]
+
+RFC 4533         LDAP Content Synchronization Operation        June 2006
+
+
+3.1.  Synchronization Session
+
+   A sequence of Sync Operations where the last cookie returned by the
+   server for one operation is provided by the client in the next
+   operation is said to belong to the same Synchronization Session.
+
+   The client MUST specify the same content-controlling parameters (see
+   Section 3.5) in each Search Request of the session.  The client
+   SHOULD also issue each Sync request of a session under the same
+   authentication and authorization associations with equivalent
+   integrity and protections.  If the server does not recognize the
+   request cookie or the request is made under different associations or
+   non-equivalent protections, the server SHALL return the initial
+   content as if no cookie had been provided or return an empty content
+   with the e-syncRefreshRequired LDAP result code.  The decision
+   between the return of the initial content and the return of the empty
+   content with the e-syncRefreshRequired result code MAY be based on
+   reloadHint in the Sync Request Control from the client.  If the
+   server recognizes the request cookie as representing empty or initial
+   synchronization state of the client copy, the server SHALL return the
+   initial content.
+
+   A Synchronization Session may span multiple LDAP sessions between the
+   client and the server.  The client SHOULD issue each Sync request of
+   a session to the same server.  (Note: Shadowing considerations are
+   discussed in Section 6.)
+
+3.2.  Content Determination
+
+   The content to be provided is determined by parameters of the Search
+   Request, as described in [RFC4511], and possibly other controls.  The
+   same content parameters SHOULD be used in each Sync request of a
+   session.  If different content is requested and the server is
+   unwilling or unable to process the request, the server SHALL return
+   the initial content as if no cookie had been provided or return an
+   empty content with the e-syncRefreshRequired LDAP result code.  The
+   decision between the return of the initial content and the return of
+   the empty content with the e-syncRefreshRequired result code MAY be
+   based on reloadHint in the Sync Request Control from the client.
+
+   The content may not necessarily include all entries or references
+   that would be returned by a normal search operation, nor, for those
+   entries included, all attributes returned by a normal search.  When
+   the server is unwilling or unable to provide synchronization for any
+   attribute for a set of entries, the server MUST treat all filter
+   components matching against these attributes as Undefined and MUST
+   NOT return these attributes in SearchResultEntry responses.
+
+
+
+
+Zeilenga & Choi               Experimental                     [Page 12]
+
+RFC 4533         LDAP Content Synchronization Operation        June 2006
+
+
+   Servers SHOULD support synchronization for all non-collective user-
+   application attributes for all entries.
+
+   The server may also return continuation references to other servers
+   or to itself.  The latter is allowed as the server may partition the
+   entries it holds into separate synchronization contexts.
+
+   The client may chase all or some of these continuations, each as a
+   separate content synchronization session.
+
+3.3.  refreshOnly Mode
+
+   A Sync request with mode refreshOnly and with no cookie is a poll for
+   initial content.  A Sync request with mode refreshOnly and with a
+   cookie representing a synchronization state is a poll for content
+   update.
+
+3.3.1.  Initial Content Poll
+
+   Upon receipt of the request, the server provides the initial content
+   using a set of zero or more SearchResultEntry and
+   SearchResultReference Messages followed by a SearchResultDone
+   Message.
+
+   Each SearchResultEntry Message SHALL include a Sync State Control of
+   state add, an entryUUID containing the entry's UUID, and no cookie.
+   Each SearchResultReference Message SHALL include a Sync State Control
+   of state add, an entryUUID containing the UUID associated with the
+   reference (normally the UUID of the associated named referral
+   [RFC3296] object), and no cookie.  The SearchResultDone Message SHALL
+   include a Sync Done Control having refreshDeletes set to FALSE.
+
+   A resultCode value of success indicates that the operation
+   successfully completed.  Otherwise, the result code indicates the
+   nature of the failure.  The server may return e-syncRefreshRequired
+   result code on the initial content poll if it is safe to do so when
+   it is unable to perform the operation due to various reasons.
+   reloadHint is set to FALSE in the SearchRequest Message requesting
+   the initial content poll.
+
+   If the operation is successful, a cookie representing the
+   synchronization state of the current client copy SHOULD be returned
+   for use in subsequent Sync Operations.
+
+3.3.2.  Content Update Poll
+
+   Upon receipt of the request, the server provides the content refresh
+   using a set of zero or more SearchResultEntry and
+
+
+
+Zeilenga & Choi               Experimental                     [Page 13]
+
+RFC 4533         LDAP Content Synchronization Operation        June 2006
+
+
+   SearchResultReference Messages followed by a SearchResultDone
+   Message.
+
+   The server is REQUIRED to:
+
+      a) provide the sequence of messages necessary for eventual
+         convergence of the client's copy of the content to the server's
+         copy,
+
+      b) treat the request as an initial content request (e.g., ignore
+         the cookie or the synchronization state represented in the
+         cookie),
+
+      c) indicate that the incremental convergence is not possible by
+         returning e-syncRefreshRequired,
+
+      d) return a resultCode other than success or e-
+         syncRefreshRequired.
+
+   A Sync Operation may consist of a single present phase, a single
+   delete phase, or a present phase followed by a delete phase.
+
+   In each phase, for each entry or reference that has been added to the
+   content or been changed since the previous Sync Operation indicated
+   by the cookie, the server returns a SearchResultEntry or
+   SearchResultReference Message, respectively, each with a Sync State
+   Control consisting of state add, an entryUUID containing the UUID of
+   the entry or reference, and no cookie.  Each SearchResultEntry
+   Message represents the current state of a changed entry.  Each
+   SearchResultReference Message represents the current state of a
+   changed reference.
+
+   In the present phase, for each entry that has not been changed since
+   the previous Sync Operation, an empty SearchResultEntry is returned
+   whose objectName reflects the entry's current DN, whose attributes
+   field is empty, and whose Sync State Control consists of state
+   present, an entryUUID containing the UUID of the entry, and no
+   cookie.  For each reference that has not been changed since the
+   previous Sync Operation, an empty SearchResultReference containing an
+   empty SEQUENCE OF LDAPURL is returned with a Sync State Control
+   consisting of state present, an entryUUID containing the UUID of the
+   entry, and no cookie.  No messages are sent for entries or references
+   that are no longer in the content.
+
+   Multiple empty entries with a Sync State Control of state present
+   SHOULD be coalesced into one or more Sync Info Messages of syncIdSet
+   value with refreshDeletes set to FALSE.  syncUUIDs contain a set of
+   UUIDs of the entries and references unchanged since the last Sync
+
+
+
+Zeilenga & Choi               Experimental                     [Page 14]
+
+RFC 4533         LDAP Content Synchronization Operation        June 2006
+
+
+   Operation.  syncUUIDs may be empty.  The Sync Info Message of
+   syncIdSet may contain a cookie to represent the state of the content
+   after performing the synchronization of the entries in the set.
+
+   In the delete phase, for each entry no longer in the content, the
+   server returns a SearchResultEntry whose objectName reflects a past
+   DN of the entry or is empty, whose attributes field is empty, and
+   whose Sync State Control consists of state delete, an entryUUID
+   containing the UUID of the deleted entry, and no cookie.  For each
+   reference no longer in the content, a SearchResultReference
+   containing an empty SEQUENCE OF LDAPURL is returned with a Sync State
+   Control consisting of state delete, an entryUUID containing the UUID
+   of the deleted reference, and no cookie.
+
+   Multiple empty entries with a Sync State Control of state delete
+   SHOULD be coalesced into one or more Sync Info Messages of syncIdSet
+   value with refreshDeletes set to TRUE.  syncUUIDs contain a set of
+   UUIDs of the entries and references that have been deleted from the
+   content since the last Sync Operation.  syncUUIDs may be empty.  The
+   Sync Info Message of syncIdSet may contain a cookie to represent the
+   state of the content after performing the synchronization of the
+   entries in the set.
+
+   When a present phase is followed by a delete phase, the two phases
+   are delimited by a Sync Info Message containing syncInfoValue of
+   refreshPresent, which may contain a cookie representing the state
+   after completing the present phase.  The refreshPresent contains
+   refreshDone, which is always FALSE in the refreshOnly mode of Sync
+   Operation because it is followed by a delete phase.
+
+   If a Sync Operation consists of a single phase, each phase and hence
+   the Sync Operation are marked as ended by a SearchResultDone Message
+   with Sync Done Control, which SHOULD contain a cookie representing
+   the state of the content after completing the Sync Operation.  The
+   Sync Done Control contains refreshDeletes, which is set to FALSE for
+   the present phase and set to TRUE for the delete phase.
+
+   If a Sync Operation consists of a present phase followed by a delete
+   phase, the Sync Operation is marked as ended at the end of the delete
+   phase by a SearchResultDone Message with Sync Done Control, which
+   SHOULD contain a cookie representing the state of the content after
+   completing the Sync Operation.  The Sync Done Control contains
+   refreshDeletes, which is set to TRUE.
+
+   The client can specify whether it prefers to receive an initial
+   content by supplying reloadHint of TRUE or to receive a e-
+   syncRefreshRequired resultCode by supplying reloadHint of FALSE
+   (hence absent), in the case that the server determines that it is
+
+
+
+Zeilenga & Choi               Experimental                     [Page 15]
+
+RFC 4533         LDAP Content Synchronization Operation        June 2006
+
+
+   impossible or inefficient to achieve the eventual convergence by
+   continuing the current incremental synchronization thread.
+
+   A resultCode value of success indicates that the operation is
+   successfully completed.  A resultCode value of e-syncRefreshRequired
+   indicates that a full or partial refresh is needed.  Otherwise, the
+   result code indicates the nature of failure.  A cookie is provided in
+   the Sync Done Control for use in subsequent Sync Operations for
+   incremental synchronization.
+
+3.4.  refreshAndPersist Mode
+
+   A Sync request with mode refreshAndPersist asks for initial content
+   or content update (during the refresh stage) followed by change
+   notifications (during the persist stage).
+
+3.4.1.  refresh Stage
+
+   The content refresh is provided as described in Section 3.3, except
+   that the successful completion of content refresh is indicated by
+   sending a Sync Info Message of refreshDelete or refreshPresent with a
+   refreshDone value set to TRUE instead of a SearchResultDone Message
+   with resultCode success.  A cookie SHOULD be returned in the Sync
+   Info Message to represent the state of the content after finishing
+   the refresh stage of the Sync Operation.
+
+3.4.2.  persist Stage
+
+   Change notifications are provided during the persist stage.
+
+   As updates are made to the DIT, the server notifies the client of
+   changes to the content.  DIT updates may cause entries and references
+   to be added to the content, deleted from the content, or modified
+   within the content.  DIT updates may also cause references to be
+   added, deleted, or modified within the content.
+
+   Where DIT updates cause an entry to be added to the content, the
+   server provides a SearchResultEntry Message that represents the entry
+   as it appears in the content.  The message SHALL include a Sync State
+   Control with state of add, an entryUUID containing the entry's UUID,
+   and an optional cookie.
+
+   Where DIT updates cause a reference to be added to the content, the
+   server provides a SearchResultReference Message that represents the
+   reference in the content.  The message SHALL include a Sync State
+   Control with state of add, an entryUUID containing the UUID
+   associated with the reference, and an optional cookie.
+
+
+
+
+Zeilenga & Choi               Experimental                     [Page 16]
+
+RFC 4533         LDAP Content Synchronization Operation        June 2006
+
+
+   Where DIT updates cause an entry to be modified within the content,
+   the server provides a SearchResultEntry Message that represents the
+   entry as it appears in the content.  The message SHALL include a Sync
+   State Control with state of modify, an entryUUID containing the
+   entry's UUID, and an optional cookie.
+
+   Where DIT updates cause a reference to be modified within the
+   content, the server provides a SearchResultReference Message that
+   represents the reference in the content.  The message SHALL include a
+   Sync State Control with state of modify, an entryUUID containing the
+   UUID associated with the reference, and an optional cookie.
+
+   Where DIT updates cause an entry to be deleted from the content, the
+   server provides a SearchResultEntry Message with no attributes.  The
+   message SHALL include a Sync State Control with state of delete, an
+   entryUUID containing the entry's UUID, and an optional cookie.
+
+   Where DIT updates cause a reference to be deleted from the content,
+   the server provides a SearchResultReference Message with an empty
+   SEQUENCE OF LDAPURL.  The message SHALL include a Sync State Control
+   with state of delete, an entryUUID containing the UUID associated
+   with the reference, and an optional cookie.
+
+   Multiple empty entries with a Sync State Control of state delete
+   SHOULD be coalesced into one or more Sync Info Messages of syncIdSet
+   value with refreshDeletes set to TRUE. syncUUIDs contain a set of
+   UUIDs of the entries and references that have been deleted from the
+   content.  The Sync Info Message of syncIdSet may contain a cookie to
+   represent the state of the content after performing the
+   synchronization of the entries in the set.
+
+   With each of these messages, the server may provide a new cookie to
+   be used in subsequent Sync Operations.  Additionally, the server may
+   also return Sync Info Messages of choice newCookie to provide a new
+   cookie.  The client SHOULD use the newest (last) cookie it received
+   from the server in subsequent Sync Operations.
+
+3.5.  Search Request Parameters
+
+   As stated in Section 3.1, the client SHOULD specify the same
+   content-controlling parameters in each Search Request of the session.
+   All fields of the SearchRequest Message are considered content-
+   controlling parameters except for sizeLimit and timeLimit.
+
+
+
+
+
+
+
+
+Zeilenga & Choi               Experimental                     [Page 17]
+
+RFC 4533         LDAP Content Synchronization Operation        June 2006
+
+
+3.5.1.  baseObject
+
+   As with the normal search operation, the refresh and persist stages
+   are not isolated from DIT changes.  It is possible that the entry
+   referred to by the baseObject is deleted, renamed, or moved.  It is
+   also possible that the alias object used in finding the entry
+   referred to by the baseObject is changed such that the baseObject
+   refers to a different entry.
+
+   If the DIT is updated during processing of the Sync Operation in a
+   manner that causes the baseObject no longer to refer to any entry or
+   in a manner that changes the entry the baseObject refers to, the
+   server SHALL return an appropriate non-success result code, such as
+   noSuchObject, aliasProblem, aliasDereferencingProblem, referral, or
+   e-syncRefreshRequired.
+
+3.5.2.  derefAliases
+
+   This operation does not support alias dereferencing during searching.
+   The client SHALL specify neverDerefAliases or derefFindingBaseObj for
+   the SearchRequest derefAliases parameter.  The server SHALL treat
+   other values (e.g., derefInSearching, derefAlways) as protocol
+   errors.
+
+3.5.3.  sizeLimit
+
+   The sizeLimit applies only to entries (regardless of their state in
+   Sync State Control) returned during the refreshOnly operation or the
+   refresh stage of the refreshAndPersist operation.
+
+3.5.4.  timeLimit
+
+   For a refreshOnly Sync Operation, the timeLimit applies to the whole
+   operation.  For a refreshAndPersist operation, the timeLimit applies
+   only to the refresh stage including the generation of the Sync Info
+   Message with a refreshDone value of TRUE.
+
+3.5.5.  filter
+
+   The client SHOULD avoid filter assertions that apply to the values of
+   the attributes likely to be considered by the server as ones holding
+   meta-information.  See Section 4.
+
+3.6.  objectName
+
+   The Sync Operation uses entryUUID values provided in the Sync State
+   Control as the primary keys to entries.  The client MUST use these
+   entryUUIDs to correlate synchronization messages.
+
+
+
+Zeilenga & Choi               Experimental                     [Page 18]
+
+RFC 4533         LDAP Content Synchronization Operation        June 2006
+
+
+   In some circumstances, the DN returned may not reflect the entry's
+   current DN.  In particular, when the entry is being deleted from the
+   content, the server may provide an empty DN if the server does not
+   wish to disclose the entry's current DN (or, if deleted from the DIT,
+   the entry's last DN).
+
+   Also note that the entry's DN may be viewed as meta information (see
+   Section 4.1).
+
+3.7.  Canceling the Sync Operation
+
+   Servers MUST implement the LDAP Cancel [RFC3909] Operation and
+   support cancellation of outstanding Sync Operations as described
+   here.
+
+   To cancel an outstanding Sync Operation, the client issues an LDAP
+   Cancel [RFC3909] Operation.
+
+   If at any time the server becomes unwilling or unable to continue
+   processing a Sync Operation, the server SHALL return a
+   SearchResultDone with a non-success resultCode indicating the reason
+   for the termination of the operation.
+
+   Whether the client or the server initiated the termination, the
+   server may provide a cookie in the Sync Done Control for use in
+   subsequent Sync Operations.
+
+3.8.  Refresh Required
+
+   In order to achieve the eventually-convergent synchronization, the
+   server may terminate the Sync Operation in the refresh or persist
+   stages by returning an e-syncRefreshRequired resultCode to the
+   client.  If no cookie is provided, a full refresh is needed.  If a
+   cookie representing a synchronization state is provided in this
+   response, an incremental refresh is needed.
+
+   To obtain a full refresh, the client then issues a new
+   synchronization request with no cookie.  To obtain an incremental
+   reload, the client issues a new synchronization with the provided
+   cookie.
+
+   The server may choose to provide a full copy in the refresh stage
+   (e.g., ignore the cookie or the synchronization state represented in
+   the cookie) instead of providing an incremental refresh in order to
+   achieve the eventual convergence.
+
+
+
+
+
+
+Zeilenga & Choi               Experimental                     [Page 19]
+
+RFC 4533         LDAP Content Synchronization Operation        June 2006
+
+
+   The decision between the return of the initial content and the return
+   of the e-syncRefreshRequired result code may be based on reloadHint
+   in the Sync Request Control from the client.
+
+   In the case of persist stage Sync, the server returns the resultCode
+   of e-syncRefreshRequired to the client to indicate that the client
+   needs to issue a new Sync Operation in order to obtain a synchronized
+   copy of the content.  If no cookie is provided, a full refresh is
+   needed.  If a cookie representing a synchronization state is
+   provided, an incremental refresh is needed.
+
+   The server may also return e-syncRefreshRequired if it determines
+   that a refresh would be more efficient than sending all the messages
+   required for convergence.
+
+   Note that the client may receive one or more of SearchResultEntry,
+   SearchResultReference, and/or Sync Info Messages before it receives a
+   SearchResultDone Message with the e-syncRefreshRequired result code.
+
+3.9.  Chattiness Considerations
+
+   The server MUST ensure that the number of entry messages generated to
+   refresh the client content does not exceed the number of entries
+   presently in the content.  While there is no requirement for servers
+   to maintain history information, if the server has sufficient history
+   to allow it to reliably determine which entries in the prior client
+   copy are no longer present in the content and the number of such
+   entries is less than or equal to the number of unchanged entries, the
+   server SHOULD generate delete entry messages instead of present entry
+   messages (see Section 3.3.2).
+
+   When the amount of history information maintained in the server is
+   not enough for the clients to perform infrequent refreshOnly Sync
+   Operations, it is likely that the server has incomplete history
+   information (e.g., due to truncation) by the time those clients
+   connect again.
+
+   The server SHOULD NOT resort to full reload when the history
+   information is not enough to generate delete entry messages.  The
+   server SHOULD generate either present entry messages only or present
+   entry messages followed by delete entry messages to bring the client
+   copy to the current state.  In the latter case, the present entry
+   messages bring the client copy to a state covered by the history
+   information maintained in the server.
+
+   The server SHOULD maintain enough (current or historical) state
+   information (such as a context-wide last modify time stamp) to
+   determine if no changes were made in the context since the content
+
+
+
+Zeilenga & Choi               Experimental                     [Page 20]
+
+RFC 4533         LDAP Content Synchronization Operation        June 2006
+
+
+   refresh was provided and, when no changes were made, generate zero
+   delete entry messages instead of present messages.
+
+   The server SHOULD NOT use the history information when its use does
+   not reduce the synchronization traffic or when its use can expose
+   sensitive information not allowed to be received by the client.
+
+   The server implementor should also consider chattiness issues that
+   span multiple Sync Operations of a session.  As noted in Section 3.8,
+   the server may return e-syncRefreshRequired if it determines that a
+   reload would be more efficient than continuing under the current
+   operation.  If reloadHint in the Sync Request is TRUE, the server may
+   initiate a reload without directing the client to request a reload.
+
+   The server SHOULD transfer a new cookie frequently to avoid having to
+   transfer information already provided to the client.  Even where DIT
+   changes do not cause content synchronization changes to be
+   transferred, it may be advantageous to provide a new cookie using a
+   Sync Info Message.  However, the server SHOULD avoid overloading the
+   client or network with Sync Info Messages.
+
+   During persist mode, the server SHOULD coalesce multiple outstanding
+   messages updating the same entry.  The server MAY delay generation of
+   an entry update in anticipation of subsequent changes to that entry
+   that could be coalesced.  The length of the delay should be long
+   enough to allow coalescing of update requests issued back to back but
+   short enough that the transient inconsistency induced by the delay is
+   corrected in a timely manner.
+
+   The server SHOULD use the syncIdSet Sync Info Message when there are
+   multiple delete or present messages to reduce the amount of
+   synchronization traffic.
+
+   Also note that there may be many clients interested in a particular
+   directory change, and that servers attempting to service all of these
+   at once may cause congestion on the network.  The congestion issues
+   are magnified when the change requires a large transfer to each
+   interested client.  Implementors and deployers of servers should take
+   steps to prevent and manage network congestion.
+
+3.10.  Operation Multiplexing
+
+   The LDAP protocol model [RFC4511] allows operations to be multiplexed
+   over a single LDAP session.  Clients SHOULD NOT maintain multiple
+   LDAP sessions with the same server.  Servers SHOULD ensure that
+   responses from concurrently processed operations are interleaved
+   fairly.
+
+
+
+
+Zeilenga & Choi               Experimental                     [Page 21]
+
+RFC 4533         LDAP Content Synchronization Operation        June 2006
+
+
+   Clients SHOULD combine Sync Operations whose result set is largely
+   overlapping.  This avoids having to return multiple messages, once
+   for each overlapping session, for changes to entries in the overlap.
+
+   Clients SHOULD NOT combine Sync Operations whose result sets are
+   largely non-overlapping.  This ensures that an event requiring an
+   e-syncRefreshRequired response can be limited to as few result sets
+   as possible.
+
+4.  Meta Information Considerations
+
+4.1.  Entry DN
+
+   As an entry's DN is constructed from its relative DN (RDN) and the
+   entry's parent's DN, it is often viewed as meta information.
+
+   While renaming or moving to a new superior causes the entry's DN to
+   change, that change SHOULD NOT, by itself, cause synchronization
+   messages to be sent for that entry.  However, if the renaming or the
+   moving could cause the entry to be added or deleted from the content,
+   appropriate synchronization messages should be generated to indicate
+   this to the client.
+
+   When a server treats the entry's DN as meta information, the server
+   SHALL either
+
+      -  evaluate all MatchingRuleAssertions [RFC4511] to TRUE if
+         matching a value of an attribute of the entry, otherwise
+         Undefined, or
+
+      -  evaluate all MatchingRuleAssertion with dnAttributes of TRUE as
+         Undefined.
+
+   The latter choice is offered for ease of server implementation.
+
+4.2.  Operational Attributes
+
+   Where values of an operational attribute are determined by values not
+   held as part of the entry it appears in, the operational attribute
+   SHOULD NOT support synchronization of that operational attribute.
+
+   For example, in servers that implement the X.501 subschema model
+   [X.501], servers should not support synchronization of the
+   subschemaSubentry attribute as its value is determined by values held
+   and administrated in subschema subentries.
+
+
+
+
+
+
+Zeilenga & Choi               Experimental                     [Page 22]
+
+RFC 4533         LDAP Content Synchronization Operation        June 2006
+
+
+   As a counter example, servers that implement aliases [RFC4512][X.501]
+   can support synchronization of the aliasedObjectName attribute as its
+   values are held and administrated as part of the alias entries.
+
+   Servers SHOULD support synchronization of the following operational
+   attributes: createTimestamp, modifyTimestamp, creatorsName,
+   modifiersName [RFC4512].  Servers MAY support synchronization of
+   other operational attributes.
+
+4.3.  Collective Attributes
+
+   A collective attribute is "a user attribute whose values are the same
+   for each member of an entry collection" [X.501].  Use of collective
+   attributes in LDAP is discussed in [RFC3671].
+
+   Modification of a collective attribute generally affects the content
+   of multiple entries, which are the members of the collection.  It is
+   inefficient to include values of collective attributes visible in
+   entries of the collection, as a single modification of a collective
+   attribute requires transmission of multiple SearchResultEntry (one
+   for each entry of the collection that the modification affected).
+
+   Servers SHOULD NOT synchronize collective attributes appearing in
+   entries of any collection.  Servers MAY support synchronization of
+   collective attributes appearing in collective attribute subentries.
+
+4.4.  Access and Other Administrative Controls
+
+   Entries are commonly subject to access and other administrative
+   Controls.  While portions of the policy information governing a
+   particular entry may be held in the entry, policy information is
+   often held elsewhere (in superior entries, in subentries, in the root
+   DSE, in configuration files, etc.).  Because of this, changes to
+   policy information make it difficult to ensure eventual convergence
+   during incremental synchronization.
+
+   Where it is impractical or infeasible to generate content changes
+   resulting from a change to policy information, servers may opt to
+   return e-syncRefreshRequired or to treat the Sync Operation as an
+   initial content request (e.g., ignore the cookie or the
+   synchronization state represented in the cookie).
+
+5.  Interaction with Other Controls
+
+   The Sync Operation may be used with:
+
+      - ManageDsaIT Control [RFC3296]
+
+
+
+
+Zeilenga & Choi               Experimental                     [Page 23]
+
+RFC 4533         LDAP Content Synchronization Operation        June 2006
+
+
+      - Subentries Control [RFC3672]
+
+   as described below.  The Sync Operation may be used with other LDAP
+   extensions as detailed in other documents.
+
+5.1.  ManageDsaIT Control
+
+   The ManageDsaIT Control [RFC3296] indicates that the operation acts
+   upon the DSA Information Tree and causes referral and other special
+   entries to be treated as object entries with respect to the
+   operation.
+
+5.2.  Subentries Control
+
+   The Subentries Control is used with the search operation "to control
+   the visibility of entries and subentries which are within scope"
+   [RFC3672].  When used with the Sync Operation, the subentries control
+   and other factors (search scope, filter, etc.) are used to determine
+   whether an entry or subentry appears in the content.
+
+6.  Shadowing Considerations
+
+   As noted in [RFC4511], some servers may hold shadow copies of entries
+   that can be used to answer search and comparison queries.  Such
+   servers may also support content synchronization requests.  This
+   section discusses considerations for implementors and deployers for
+   the implementation and deployment of the Sync operation in shadowed
+   directories.
+
+   While a client may know of multiple servers that are equally capable
+   of being used to obtain particular directory content from, a client
+   SHOULD NOT assume that each of these servers is equally capable of
+   continuing a content synchronization session.  As stated in Section
+   3.1, the client SHOULD issue each Sync request of a Sync session to
+   the same server.
+
+   However, through domain naming or IP address redirection or other
+   techniques, multiple physical servers can be made to appear as one
+   logical server to a client.  Only servers that are equally capable in
+   regards to their support for the Sync operation and that hold equally
+   complete copies of the entries should be made to appear as one
+   logical server.  In particular, each physical server acting as one
+   logical server SHOULD be equally capable of continuing a content
+   synchronization based upon cookies provided by any of the other
+   physical servers without requiring a full reload.  Because there is
+   no standard LDAP shadowing mechanism, the specification of how to
+   independently implement equally capable servers (as well as the
+   precise definition of "equally capable") is left to future documents.
+
+
+
+Zeilenga & Choi               Experimental                     [Page 24]
+
+RFC 4533         LDAP Content Synchronization Operation        June 2006
+
+
+   Note that it may be difficult for the server to reliably determine
+   what content was provided to the client by another server, especially
+   in the shadowing environments that allow shadowing events to be
+   coalesced.  For these servers, the use of the delete phase discussed
+   in Section 3.3.2 may not be applicable.
+
+7.  Security Considerations
+
+   In order to maintain a synchronized copy of the content, a client is
+   to delete information from its copy of the content as described
+   above.  However, the client may maintain knowledge of information
+   disclosed to it by the server separate from its copy of the content
+   used for synchronization.  Management of this knowledge is beyond the
+   scope of this document.  Servers should be careful not to disclose
+   information for content the client is not authorized to have
+   knowledge of and/or about.
+
+   While the information provided by a series of refreshOnly Sync
+   Operations is similar to that provided by a series of Search
+   Operations, persist stage may disclose additional information.  A
+   client may be able to discern information about the particular
+   sequence of update operations that caused content change.
+
+   Implementors should take precautions against malicious cookie
+   content, including malformed cookies or valid cookies used with
+   different security associations and/or protections in an attempt to
+   obtain unauthorized access to information.  Servers may include a
+   digital signature in the cookie to detect tampering.
+
+   The operation may be the target of direct denial-of-service attacks.
+   Implementors should provide safeguards to ensure the operation is not
+   abused.  Servers may place access control or other restrictions upon
+   the use of this operation.
+
+   Note that even small updates to the directory may cause a significant
+   amount of traffic to be generated to clients using this operation.  A
+   user could abuse its update privileges to mount an indirect denial of
+   service to these clients, other clients, and/or portions of the
+   network.  Servers should provide safeguards to ensure that update
+   operations are not abused.
+
+   Implementors of this (or any) LDAP extension should be familiar with
+   general LDAP security considerations [RFC4510].
+
+
+
+
+
+
+
+
+Zeilenga & Choi               Experimental                     [Page 25]
+
+RFC 4533         LDAP Content Synchronization Operation        June 2006
+
+
+8.  IANA Considerations
+
+   Registration of the following values have been completed by the IANA
+   [RFC4520].
+
+8.1.  Object Identifier
+
+   The OID arc 1.3.6.1.4.1.4203.1.9.1 was assigned [ASSIGN] by the
+   OpenLDAP Foundation, under its IANA-assigned private enterprise
+   allocation [PRIVATE], for use in this specification.
+
+8.2.  LDAP Protocol Mechanism
+
+   The IANA has registered the LDAP Protocol Mechanism described in this
+   document.
+
+      Subject: Request for LDAP Protocol Mechanism Registration
+      Object Identifier: 1.3.6.1.4.1.4203.1.9.1.1
+      Description: LDAP Content Synchronization Control
+      Person & email address to contact for further information:
+          Kurt Zeilenga <kurt@openldap.org>
+      Usage: Control
+      Specification: RFC 4533
+      Author/Change Controller: Kurt D. Zeilenga, Jong Hyuk Choi
+      Comments: none
+
+8.3.  LDAP Result Codes
+
+   The IANA has registered the LDAP Result Code described in this
+   document.
+
+      Subject: LDAP Result Code Registration
+      Person & email address to contact for further information:
+          Kurt Zeilenga <kurt@OpenLDAP.org>
+      Result Code Name: e-syncRefreshRequired (4096)
+      Specification: RFC 4533
+      Author/Change Controller: Kurt D. Zeilenga, Jong Hyuk Choi
+      Comments:  none
+
+9.  Acknowledgements
+
+   This document borrows significantly from the LDAP Client Update
+   Protocol [RFC3928], a product of the IETF LDUP working group.  This
+   document also benefited from Persistent Search [PSEARCH], Triggered
+   Search [TSEARCH], and Directory Synchronization [DIRSYNC] works.
+   This document also borrows from "Lightweight Directory Access
+   Protocol (v3)" [RFC2251].
+
+
+
+
+Zeilenga & Choi               Experimental                     [Page 26]
+
+RFC 4533         LDAP Content Synchronization Operation        June 2006
+
+
+10.  Normative References
+
+   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
+               Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC3296]   Zeilenga, K., "Named Subordinate References in
+               Lightweight Directory Access Protocol (LDAP)
+               Directories", RFC 3296, July 2002.
+
+   [RFC3671]   Zeilenga, K., "Collective Attributes in the Lightweight
+               Directory Access Protocol (LDAP)", RFC 3671, December
+               2003.
+
+   [RFC3672]   Zeilenga, K., "Subentries in the Lightweight Directory
+               Access Protocol (LDAP)", RFC 3672, December 2003.
+
+   [RFC3909]   Zeilenga, K., "Lightweight Directory Access Protocol
+               (LDAP) Cancel Operation", RFC 3909, October 2004.
+
+   [RFC4510]   Zeilenga, K., Ed., "Lightweight Directory Access Protocol
+               (LDAP): Technical Specification Road Map", RFC 4510, June
+               2006.
+
+   [RFC4511]   Sermersheim, J., Ed., "Lightweight Directory Access
+               Protocol (LDAP): The Protocol", RFC 4511, June 2006.
+
+   [RFC4512]   Zeilenga, K., "Lightweight Directory Access Protocol
+               (LDAP): Directory Information Models", RFC 4512, June
+               2006.
+
+   [RFC4530]   Zeilenga, K., "Lightweight Directory Access Protocol
+               (LDAP) entryUUID Operational Attribute", RFC 4530, June
+               2006.
+
+   [UUID]      International Organization for Standardization (ISO),
+               "Information technology - Open Systems Interconnection -
+               Remote Procedure Call", ISO/IEC 11578:1996
+
+   [X.501]     International Telecommunication Union - Telecommunication
+               Standardization Sector, "The Directory -- Models,"
+               X.501(1993) (also ISO/IEC 9594-2:1994).
+
+   [X.680]     International Telecommunication Union - Telecommunication
+               Standardization Sector, "Abstract Syntax Notation One
+               (ASN.1) - Specification of Basic Notation", X.680(1997)
+               (also ISO/IEC 8824-1:1998).
+
+
+
+
+
+Zeilenga & Choi               Experimental                     [Page 27]
+
+RFC 4533         LDAP Content Synchronization Operation        June 2006
+
+
+   [X.690]     International Telecommunication Union - Telecommunication
+               Standardization Sector, "Specification of ASN.1 encoding
+               rules: Basic Encoding Rules (BER), Canonical Encoding
+               Rules (CER), and Distinguished Encoding Rules (DER)",
+               X.690(1997) (also ISO/IEC 8825-1:1998).
+
+11.  Informative References
+
+   [RFC2251]   Wahl, M., Howes, T., and S. Kille, "Lightweight Directory
+               Access Protocol (v3)", RFC 2251, December 1997.
+
+   [RFC3928]   Megginson, R., Ed., Smith, M., Natkovich, O., and J.
+               Parham, "Lightweight Directory Access Protocol (LDAP)
+               Client Update Protocol (LCUP)", RFC 3928, October 2004.
+
+   [RFC4520]   Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
+               Considerations for the Lightweight Directory Access
+               Protocol (LDAP)", BCP 64, RFC 4520, June 2006.
+
+   [PRIVATE]   IANA, "Private Enterprise Numbers",
+               http://www.iana.org/assignments/enterprise-numbers.
+
+   [ASSIGN]    OpenLDAP Foundation, "OpenLDAP OID Delegations",
+               http://www.openldap.org/foundation/oid-delegate.txt.
+
+   [X.500]     International Telecommunication Union - Telecommunication
+               Standardization Sector, "The Directory -- Overview of
+               concepts, models and services," X.500(1993) (also ISO/IEC
+               9594-1:1994).
+
+   [X.525]     International Telecommunication Union - Telecommunication
+               Standardization Sector, "The Directory: Replication",
+               X.525(1993).
+
+   [DIRSYNC]   Armijo, M., "Microsoft LDAP Control for Directory
+               Synchronization", Work in Progress.
+
+   [PSEARCH]   Smith, M., et al., "Persistent Search: A Simple LDAP
+               Change Notification Mechanism", Work in Progress.
+
+   [TSEARCH]   Wahl, M., "LDAPv3 Triggered Search Control", Work in
+               Progress.
+
+
+
+
+
+
+
+
+
+Zeilenga & Choi               Experimental                     [Page 28]
+
+RFC 4533         LDAP Content Synchronization Operation        June 2006
+
+
+Appendix A.  CSN-based Implementation Considerations
+
+   This appendix is provided for informational purposes only; it is not
+   a normative part of the LDAP Content Synchronization Operation's
+   technical specification.
+
+   This appendix discusses LDAP Content Synchronization Operation server
+   implementation considerations associated with Change Sequence Number
+   based approaches.
+
+   Change Sequence Number based approaches are targeted for use in
+   servers that do not maintain history information (e.g., change logs,
+   state snapshots) about changes made to the Directory and hence, must
+   rely on current directory state and minimal synchronization state
+   information embedded in Sync Cookie.  Servers that maintain history
+   information should consider other approaches that exploit the history
+   information.
+
+   A Change Sequence Number is effectively a time stamp that has
+   sufficient granularity to ensure that the precedence relationship in
+   time of two updates to the same object can be determined.  Change
+   Sequence Numbers are not to be confused with Commit Sequence Numbers
+   or Commit Log Record Numbers.  A Commit Sequence Number allows one to
+   determine how two commits (to the same object or different objects)
+   relate to each other in time.  A Change Sequence Number associated
+   with different entries may be committed out of order.  In the
+   remainder of this Appendix, the term CSN refers to a Change Sequence
+   Number.
+
+   In these approaches, the server not only maintains a CSN for each
+   directory entry (the entry CSN) but also maintains a value that we
+   will call the context CSN.  The context CSN is the greatest committed
+   entry CSN that is not greater than any outstanding (uncommitted)
+   entry CSNs for all entries in a directory context.  The values of
+   context CSN are used in syncCookie values as synchronization state
+   indicators.
+
+   As search operations are not isolated from individual directory
+   update operations and individual update operations cannot be assumed
+   to be serialized, one cannot assume that the returned content
+   incorporates each relevant change whose change sequence number is
+   less than or equal to the greatest entry CSN in the content.  The
+   content incorporates all the relevant changes whose change sequence
+   numbers are less than or equal to context CSN before search
+   processing.  The content may also incorporate any subset of the
+   changes whose change sequence number is greater than context CSN
+   before search processing but less than or equal to the context CSN
+   after search processing.  The content does not incorporate any of the
+
+
+
+Zeilenga & Choi               Experimental                     [Page 29]
+
+RFC 4533         LDAP Content Synchronization Operation        June 2006
+
+
+   changes whose CSN is greater than the context CSN after search
+   processing.
+
+   A simple server implementation could use the value of the context CSN
+   before search processing to indicate state.  Such an implementation
+   would embed this value into each SyncCookie returned.  We'll call
+   this the cookie CSN.  When a refresh was requested, the server would
+   simply generate "update" messages for all entries in the content
+   whose CSN is greater than the supplied cookie CSN and generate
+   "present" messages for all other entries in the content.  However, if
+   the current context CSN is the same as the cookie CSN, the server
+   should instead generate zero "updates" and zero "delete" messages and
+   indicate a refreshDeletes of TRUE, as the directory has not changed.
+
+   The implementation should also consider the impact of changes to meta
+   information, such as access controls, that affect content
+   determination.  One approach is for the server to maintain a
+   context-wide meta information CSN or meta CSN.  This meta CSN would
+   be updated whenever meta information affecting content determination
+   was changed.  If the value of the meta CSN is greater than the cookie
+   CSN, the server should ignore the cookie and treat the request as an
+   initial request for content.
+
+   Additionally, servers may want to consider maintaining some per-
+   session history information to reduce the number of messages needed
+   to be transferred during incremental refreshes.  Specifically, a
+   server could record information about entries as they leave the scope
+   of a disconnected sync session and later use this information to
+   generate delete messages instead of present messages.
+
+   When the history information is truncated, the CSN of the latest
+   truncated history information entry may be recorded as the truncated
+   CSN of the history information.  The truncated CSN may be used to
+   determine whether a client copy can be covered by the history
+   information by comparing it to the synchronization state contained in
+   the cookie supplied by the client.
+
+   When there is a large number of sessions, it may make sense to
+   maintain such history only for the selected clients.  Also, servers
+   taking this approach need to consider resource consumption issues to
+   ensure reasonable server operation and to protect against abuse.  It
+   may be appropriate to restrict this mode of operation by policy.
+
+
+
+
+
+
+
+
+
+Zeilenga & Choi               Experimental                     [Page 30]
+
+RFC 4533         LDAP Content Synchronization Operation        June 2006
+
+
+Authors' Addresses
+
+   Kurt D. Zeilenga
+   OpenLDAP Foundation
+
+   EMail: Kurt@OpenLDAP.org
+
+
+   Jong Hyuk Choi
+   IBM Corporation
+
+   EMail: jongchoi@us.ibm.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga & Choi               Experimental                     [Page 31]
+
+RFC 4533         LDAP Content Synchronization Operation        June 2006
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2006).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78 and at www.rfc-editor.org/copyright.html, and
+   except as set forth therein, the authors retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Zeilenga & Choi               Experimental                     [Page 32]
+