r2758: keep docos handy while developing it

(This used to be commit 5f9b58c785950e9871ef6411ff2ef34f988959ed)

1 files changed, 1795 insertions, 0 deletions

diff --git a/source4/ldap_server/devdocs/rfc2252.txt b/source4/ldap_server/devdocs/rfc2252.txt
new file mode 100644
index 0000000000..5a72b7768a
--- /dev/null
+++ b/source4/ldap_server/devdocs/rfc2252.txt
@@ -0,0 +1,1795 @@
+
+
+
+
+
+
+Network Working Group                                            M. Wahl
+Request for Comments: 2252                           Critical Angle Inc.
+Category: Standards Track                                    A. Coulbeck
+                                                              Isode Inc.
+                                                                T. Howes
+                                           Netscape Communications Corp.
+                                                                S. Kille
+                                                           Isode Limited
+                                                           December 1997
+
+
+              Lightweight Directory Access Protocol (v3):
+                      Attribute Syntax Definitions
+
+1. Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (1997).  All Rights Reserved.
+
+IESG Note
+
+   This document describes a directory access protocol that provides
+   both read and update access.  Update access requires secure
+   authentication, but this document does not mandate implementation of
+   any satisfactory authentication mechanisms.
+
+   In accordance with RFC 2026, section 4.4.1, this specification is
+   being approved by IESG as a Proposed Standard despite this
+   limitation, for the following reasons:
+
+   a. to encourage implementation and interoperability testing of
+      these protocols (with or without update access) before they
+      are deployed, and
+
+   b. to encourage deployment and use of these protocols in read-only
+      applications.  (e.g. applications where LDAPv3 is used as
+      a query language for directories which are updated by some
+      secure mechanism other than LDAP), and
+
+
+
+
+
+
+Wahl, et. al.               Standards Track                     [Page 1]
+
+RFC 2252                   LADPv3 Attributes               December 1997
+
+
+   c. to avoid delaying the advancement and deployment of other Internet
+      standards-track protocols which require the ability to query, but
+      not update, LDAPv3 directory servers.
+
+   Readers are hereby warned that until mandatory authentication
+   mechanisms are standardized, clients and servers written according to
+   this specification which make use of update functionality are
+   UNLIKELY TO INTEROPERATE, or MAY INTEROPERATE ONLY IF AUTHENTICATION
+   IS REDUCED TO AN UNACCEPTABLY WEAK LEVEL.
+
+   Implementors are hereby discouraged from deploying LDAPv3 clients or
+   servers which implement the update functionality, until a Proposed
+   Standard for mandatory authentication in LDAPv3 has been approved and
+   published as an RFC.
+
+2. Abstract
+
+   The Lightweight Directory Access Protocol (LDAP) [1] requires that
+   the contents of AttributeValue fields in protocol elements be octet
+   strings.  This document defines a set of syntaxes for LDAPv3, and the
+   rules by which attribute values of these syntaxes are represented as
+   octet strings for transmission in the LDAP protocol.  The syntaxes
+   defined in this document are referenced by this and other documents
+   that define attribute types.  This document also defines the set of
+   attribute types which LDAP servers should support.
+
+3. Overview
+
+   This document defines the framework for developing schemas for
+   directories accessible via the Lightweight Directory Access Protocol.
+
+   Schema is the collection of attribute type definitions, object class
+   definitions and other information which a server uses to determine
+   how to match a filter or attribute value assertion (in a compare
+   operation) against the attributes of an entry, and whether to permit
+   add and modify operations.
+
+   Section 4 states the general requirements and notations for attribute
+   types, object classes, syntax and matching rule definitions.
+
+   Section 5 lists attributes, section 6 syntaxes and section 7 object
+   classes.
+
+   Additional documents define schemas for representing real-world
+   objects as directory entries.
+
+
+
+
+
+
+Wahl, et. al.               Standards Track                     [Page 2]
+
+RFC 2252                   LADPv3 Attributes               December 1997
+
+
+4. General Issues
+
+   This document describes encodings used in an Internet protocol.
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [4].
+
+   Attribute Type and Object Class definitions are written in a string
+   representation of the AttributeTypeDescription and
+   ObjectClassDescription data types defined in X.501(93) [3].
+   Implementors are strongly advised to first read the description of
+   how schema is represented in X.500 before reading the rest of this
+   document.
+
+4.1. Common Encoding Aspects
+
+   For the purposes of defining the encoding rules for attribute
+   syntaxes, the following BNF definitions will be used.  They are based
+   on the BNF styles of RFC 822 [13].
+
+    a     = "a" / "b" / "c" / "d" / "e" / "f" / "g" / "h" / "i" /
+            "j" / "k" / "l" / "m" / "n" / "o" / "p" / "q" / "r" /
+            "s" / "t" / "u" / "v" / "w" / "x" / "y" / "z" / "A" /
+            "B" / "C" / "D" / "E" / "F" / "G" / "H" / "I" / "J" /
+            "K" / "L" / "M" / "N" / "O" / "P" / "Q" / "R" / "S" /
+            "T" / "U" / "V" / "W" / "X" / "Y" / "Z"
+
+    d               = "0" / "1" / "2" / "3" / "4" /
+                      "5" / "6" / "7" / "8" / "9"
+
+    hex-digit       =  d / "a" / "b" / "c" / "d" / "e" / "f" /
+                           "A" / "B" / "C" / "D" / "E" / "F"
+
+    k               = a / d / "-" / ";"
+
+    p               = a / d / """ / "(" / ")" / "+" / "," /
+                      "-" / "." / "/" / ":" / "?" / " "
+
+    letterstring    = 1*a
+
+    numericstring   = 1*d
+
+    anhstring       = 1*k
+
+    keystring       = a [ anhstring ]
+
+    printablestring = 1*p
+
+
+
+Wahl, et. al.               Standards Track                     [Page 3]
+
+RFC 2252                   LADPv3 Attributes               December 1997
+
+
+    space           = 1*" "
+
+    whsp            = [ space ]
+
+    utf8            = <any sequence of octets formed from the UTF-8 [9]
+                       transformation of a character from ISO10646 [10]>
+
+    dstring         = 1*utf8
+
+    qdstring        = whsp "'" dstring "'" whsp
+
+    qdstringlist    = [ qdstring *( qdstring ) ]
+
+    qdstrings       = qdstring / ( whsp "(" qdstringlist ")" whsp )
+
+   In the following BNF for the string representation of OBJECT
+   IDENTIFIERs, descr is the syntactic representation of an object
+   descriptor, which consists of letters and digits, starting with a
+   letter.  An OBJECT IDENTIFIER in the numericoid format should not
+   have leading zeroes (e.g. "0.9.3" is permitted but "0.09.3" should
+   not be generated).
+
+   When encoding 'oid' elements in a value, the descr encoding option
+   SHOULD be used in preference to the numericoid. An object descriptor
+   is a more readable alias for a number OBJECT IDENTIFIER, and these
+   (where assigned and known by the implementation) SHOULD be used in
+   preference to numeric oids to the greatest extent possible.  Examples
+   of object descriptors in LDAP are attribute type, object class and
+   matching rule names.
+
+     oid             = descr / numericoid
+
+     descr           = keystring
+
+     numericoid      = numericstring *( "." numericstring )
+
+     woid            = whsp oid whsp
+
+     ; set of oids of either form
+     oids            = woid / ( "(" oidlist ")" )
+
+     oidlist         = woid *( "$" woid )
+
+     ; object descriptors used as schema element names
+     qdescrs         = qdescr / ( whsp "(" qdescrlist ")" whsp )
+
+     qdescrlist      = [ qdescr *( qdescr ) ]
+
+
+
+
+Wahl, et. al.               Standards Track                     [Page 4]
+
+RFC 2252                   LADPv3 Attributes               December 1997
+
+
+     qdescr          = whsp "'" descr "'" whsp
+
+4.2. Attribute Types
+
+   The attribute types are described by sample values for the subschema
+   "attributeTypes" attribute, which is written in the
+   AttributeTypeDescription syntax.  While lines have been folded for
+   readability, the values transferred in protocol would not contain
+   newlines.
+
+   The AttributeTypeDescription is encoded according to the following
+   BNF, and the productions for oid, qdescrs and qdstring are given in
+   section 4.1.  Implementors should note that future versions of this
+   document may have expanded this BNF to include additional terms.
+   Terms which begin with the characters "X-" are reserved for private
+   experiments, and MUST be followed by a <qdstrings>.
+
+      AttributeTypeDescription = "(" whsp
+            numericoid whsp              ; AttributeType identifier
+          [ "NAME" qdescrs ]             ; name used in AttributeType
+          [ "DESC" qdstring ]            ; description
+          [ "OBSOLETE" whsp ]
+          [ "SUP" woid ]                 ; derived from this other
+                                         ; AttributeType
+          [ "EQUALITY" woid              ; Matching Rule name
+          [ "ORDERING" woid              ; Matching Rule name
+          [ "SUBSTR" woid ]              ; Matching Rule name
+          [ "SYNTAX" whsp noidlen whsp ] ; see section 4.3
+          [ "SINGLE-VALUE" whsp ]        ; default multi-valued
+          [ "COLLECTIVE" whsp ]          ; default not collective
+          [ "NO-USER-MODIFICATION" whsp ]; default user modifiable
+          [ "USAGE" whsp AttributeUsage ]; default userApplications
+          whsp ")"
+
+      AttributeUsage =
+          "userApplications"     /
+          "directoryOperation"   /
+          "distributedOperation" / ; DSA-shared
+          "dSAOperation"          ; DSA-specific, value depends on server
+
+   Servers are not required to provide the same or any text in the
+   description part of the subschema values they maintain.  Servers
+   SHOULD provide at least one of the "SUP" and "SYNTAX" fields for each
+   AttributeTypeDescription.
+
+   Servers MUST implement all the attribute types referenced in sections
+   5.1, 5.2 and 5.3.
+
+
+
+
+Wahl, et. al.               Standards Track                     [Page 5]
+
+RFC 2252                   LADPv3 Attributes               December 1997
+
+
+   Servers MAY recognize additional names and attributes not listed in
+   this document, and if they do so, MUST publish the definitions of the
+   types in the attributeTypes attribute of their subschema entries.
+
+   Schema developers MUST NOT create attribute definitions whose names
+   conflict with attributes defined for use with LDAP in existing
+   standards-track RFCs.
+
+   An AttributeDescription can be used as the value in a NAME part of an
+   AttributeTypeDescription.  Note that these are case insensitive.
+
+   Note that the AttributeTypeDescription does not list the matching
+   rules which can can be used with that attribute type in an
+   extensibleMatch search filter.  This is done using the
+   matchingRuleUse attribute described in section 4.5.
+
+   This document refines the schema description of X.501 by requiring
+   that the syntax field in an AttributeTypeDescription be a string
+   representation of an OBJECT IDENTIFIER for the LDAP string syntax
+   definition, and an optional indication of the maximum length of a
+   value of this attribute (defined in section 4.3.2).
+
+4.3. Syntaxes
+
+   This section defines general requirements for LDAP attribute value
+   syntax encodings. All documents defining attribute syntax encodings
+   for use with LDAP are expected to conform to these requirements.
+
+   The encoding rules defined for a given attribute syntax must produce
+   octet strings.  To the greatest extent possible, encoded octet
+   strings should be usable in their native encoded form for display
+   purposes. In particular, encoding rules for attribute syntaxes
+   defining non-binary values should produce strings that can be
+   displayed with little or no translation by clients implementing LDAP.
+   There are a few cases (e.g. audio) however, when it is not sensible
+   to produce a printable representation, and clients MUST NOT assume
+   that an unrecognized syntax is a string representation.
+
+   In encodings where an arbitrary string, not a Distinguished Name, is
+   used as part of a larger production, and other than as part of a
+   Distinguished Name, a backslash quoting mechanism is used to escape
+   the following separator symbol character (such as "'", "$" or "#") if
+   it should occur in that string.  The backslash is followed by a pair
+   of hexadecimal digits representing the next character.  A backslash
+   itself in the string which forms part of a larger syntax is always
+   transmitted as '\5C' or '\5c'. An example is given in section 6.27.
+
+
+
+
+
+Wahl, et. al.               Standards Track                     [Page 6]
+
+RFC 2252                   LADPv3 Attributes               December 1997
+
+
+   Syntaxes are also defined for matching rules whose assertion value
+   syntax is different from the attribute value syntax.
+
+4.3.1  Binary Transfer of Values
+
+   This encoding format is used if the binary encoding is requested by
+   the client for an attribute, or if the attribute syntax name is
+   "1.3.6.1.4.1.1466.115.121.1.5".  The contents of the LDAP
+   AttributeValue or AssertionValue field is a BER-encoded instance of
+   the attribute value or a matching rule assertion value ASN.1 data
+   type as defined for use with X.500. (The first byte inside the OCTET
+   STRING wrapper is a tag octet.  However, the OCTET STRING is still
+   encoded in primitive form.)
+
+   All servers MUST implement this form for both generating attribute
+   values in search responses, and parsing attribute values in add,
+   compare and modify requests, if the attribute type is recognized and
+   the attribute syntax name is that of Binary.  Clients which request
+   that all attributes be returned from entries MUST be prepared to
+   receive values in binary (e.g. userCertificate;binary), and SHOULD
+   NOT simply display binary or unrecognized values to users.
+
+4.3.2. Syntax Object Identifiers
+
+   Syntaxes for use with LDAP are named by OBJECT IDENTIFIERs, which are
+   dotted-decimal strings.  These are not intended to be displayed to
+   users.
+
+   noidlen = numericoid [ "{" len "}" ]
+
+   len     = numericstring
+
+   The following table lists some of the syntaxes that have been defined
+   for LDAP thus far.  The H-R column suggests whether a value in that
+   syntax would likely be a human readable string.  Clients and servers
+   need not implement all the syntaxes listed here, and MAY implement
+   other syntaxes.
+
+   Other documents may define additional syntaxes.  However, the
+   definition of additional arbitrary syntaxes is strongly deprecated
+   since it will hinder interoperability: today's client and server
+   implementations generally do not have the ability to dynamically
+   recognize new syntaxes.  In most cases attributes will be defined
+   with the syntax for directory strings.
+
+
+
+
+
+
+
+Wahl, et. al.               Standards Track                     [Page 7]
+
+RFC 2252                   LADPv3 Attributes               December 1997
+
+
+   Value being represented        H-R OBJECT IDENTIFIER
+   =================================================================
+   ACI Item                        N  1.3.6.1.4.1.1466.115.121.1.1
+   Access Point                    Y  1.3.6.1.4.1.1466.115.121.1.2
+   Attribute Type Description      Y  1.3.6.1.4.1.1466.115.121.1.3
+   Audio                           N  1.3.6.1.4.1.1466.115.121.1.4
+   Binary                          N  1.3.6.1.4.1.1466.115.121.1.5
+   Bit String                      Y  1.3.6.1.4.1.1466.115.121.1.6
+   Boolean                         Y  1.3.6.1.4.1.1466.115.121.1.7
+   Certificate                     N  1.3.6.1.4.1.1466.115.121.1.8
+   Certificate List                N  1.3.6.1.4.1.1466.115.121.1.9
+   Certificate Pair                N  1.3.6.1.4.1.1466.115.121.1.10
+   Country String                  Y  1.3.6.1.4.1.1466.115.121.1.11
+   DN                              Y  1.3.6.1.4.1.1466.115.121.1.12
+   Data Quality Syntax             Y  1.3.6.1.4.1.1466.115.121.1.13
+   Delivery Method                 Y  1.3.6.1.4.1.1466.115.121.1.14
+   Directory String                Y  1.3.6.1.4.1.1466.115.121.1.15
+   DIT Content Rule Description    Y  1.3.6.1.4.1.1466.115.121.1.16
+   DIT Structure Rule Description  Y  1.3.6.1.4.1.1466.115.121.1.17
+   DL Submit Permission            Y  1.3.6.1.4.1.1466.115.121.1.18
+   DSA Quality Syntax              Y  1.3.6.1.4.1.1466.115.121.1.19
+   DSE Type                        Y  1.3.6.1.4.1.1466.115.121.1.20
+   Enhanced Guide                  Y  1.3.6.1.4.1.1466.115.121.1.21
+   Facsimile Telephone Number      Y  1.3.6.1.4.1.1466.115.121.1.22
+   Fax                             N  1.3.6.1.4.1.1466.115.121.1.23
+   Generalized Time                Y  1.3.6.1.4.1.1466.115.121.1.24
+   Guide                           Y  1.3.6.1.4.1.1466.115.121.1.25
+   IA5 String                      Y  1.3.6.1.4.1.1466.115.121.1.26
+   INTEGER                         Y  1.3.6.1.4.1.1466.115.121.1.27
+   JPEG                            N  1.3.6.1.4.1.1466.115.121.1.28
+   LDAP Syntax Description         Y  1.3.6.1.4.1.1466.115.121.1.54
+   LDAP Schema Definition          Y  1.3.6.1.4.1.1466.115.121.1.56
+   LDAP Schema Description         Y  1.3.6.1.4.1.1466.115.121.1.57
+   Master And Shadow Access Points Y  1.3.6.1.4.1.1466.115.121.1.29
+   Matching Rule Description       Y  1.3.6.1.4.1.1466.115.121.1.30
+   Matching Rule Use Description   Y  1.3.6.1.4.1.1466.115.121.1.31
+   Mail Preference                 Y  1.3.6.1.4.1.1466.115.121.1.32
+   MHS OR Address                  Y  1.3.6.1.4.1.1466.115.121.1.33
+   Modify Rights                   Y  1.3.6.1.4.1.1466.115.121.1.55
+   Name And Optional UID           Y  1.3.6.1.4.1.1466.115.121.1.34
+   Name Form Description           Y  1.3.6.1.4.1.1466.115.121.1.35
+   Numeric String                  Y  1.3.6.1.4.1.1466.115.121.1.36
+   Object Class Description        Y  1.3.6.1.4.1.1466.115.121.1.37
+   Octet String                    Y  1.3.6.1.4.1.1466.115.121.1.40
+   OID                             Y  1.3.6.1.4.1.1466.115.121.1.38
+   Other Mailbox                   Y  1.3.6.1.4.1.1466.115.121.1.39
+   Postal Address                  Y  1.3.6.1.4.1.1466.115.121.1.41
+   Protocol Information            Y  1.3.6.1.4.1.1466.115.121.1.42
+
+
+
+Wahl, et. al.               Standards Track                     [Page 8]
+
+RFC 2252                   LADPv3 Attributes               December 1997
+
+
+   Presentation Address            Y  1.3.6.1.4.1.1466.115.121.1.43
+   Printable String                Y  1.3.6.1.4.1.1466.115.121.1.44
+   Substring Assertion             Y  1.3.6.1.4.1.1466.115.121.1.58
+   Subtree Specification           Y  1.3.6.1.4.1.1466.115.121.1.45
+   Supplier Information            Y  1.3.6.1.4.1.1466.115.121.1.46
+   Supplier Or Consumer            Y  1.3.6.1.4.1.1466.115.121.1.47
+   Supplier And Consumer           Y  1.3.6.1.4.1.1466.115.121.1.48
+   Supported Algorithm             N  1.3.6.1.4.1.1466.115.121.1.49
+   Telephone Number                Y  1.3.6.1.4.1.1466.115.121.1.50
+   Teletex Terminal Identifier     Y  1.3.6.1.4.1.1466.115.121.1.51
+   Telex Number                    Y  1.3.6.1.4.1.1466.115.121.1.52
+   UTC Time                        Y  1.3.6.1.4.1.1466.115.121.1.53
+
+   A suggested minimum upper bound on the number of characters in value
+   with a string-based syntax, or the number of bytes in a value for all
+   other syntaxes, may be indicated by appending this bound count inside
+   of curly braces following the syntax name's OBJECT IDENTIFIER in an
+   Attribute Type Description.  This bound is not part of the syntax
+   name itself.  For instance, "1.3.6.4.1.1466.0{64}" suggests that
+   server implementations should allow a string to be 64 characters
+   long, although they may allow longer strings.  Note that a single
+   character of the Directory String syntax may be encoded in more than
+   one byte since UTF-8 is a variable-length encoding.
+
+4.3.3. Syntax Description
+
+   The following BNF may be used to associate a short description with a
+   syntax OBJECT IDENTIFIER. Implementors should note that future
+   versions of this document may expand this definition to include
+   additional terms.  Terms whose identifier begins with "X-" are
+   reserved for private experiments, and MUST be followed by a
+   <qdstrings>.
+
+      SyntaxDescription = "(" whsp
+          numericoid whsp
+          [ "DESC" qdstring ]
+          whsp ")"
+
+4.4. Object Classes
+
+   The format for representation of object classes is defined in X.501
+   [3]. In general every entry will contain an abstract class ("top" or
+   "alias"), at least one structural object class, and zero or more
+   auxiliary object classes.  Whether an object class is abstract,
+   structural or auxiliary is defined when the object class identifier
+   is assigned.  An object class definition should not be changed
+   without having a new identifier assigned to it.
+
+
+
+
+Wahl, et. al.               Standards Track                     [Page 9]
+
+RFC 2252                   LADPv3 Attributes               December 1997
+
+
+   Object class descriptions are written according to the following BNF.
+   Implementors should note that future versions of this document may
+   expand this definition to include additional terms.  Terms whose
+   identifier begins with "X-" are reserved for private experiments, and
+   MUST be followed by a <qdstrings> encoding.
+
+      ObjectClassDescription = "(" whsp
+          numericoid whsp      ; ObjectClass identifier
+          [ "NAME" qdescrs ]
+          [ "DESC" qdstring ]
+          [ "OBSOLETE" whsp ]
+          [ "SUP" oids ]       ; Superior ObjectClasses
+          [ ( "ABSTRACT" / "STRUCTURAL" / "AUXILIARY" ) whsp ]
+                               ; default structural
+          [ "MUST" oids ]      ; AttributeTypes
+          [ "MAY" oids ]       ; AttributeTypes
+      whsp ")"
+
+   These are described as sample values for the subschema
+   "objectClasses" attribute for a server which implements the LDAP
+   schema. While lines have been folded for readability, the values
+   transferred in protocol would not contain newlines.
+
+   Servers SHOULD implement all the object classes referenced in section
+   7, except for extensibleObject, which is optional. Servers MAY
+   implement additional object classes not listed in this document, and
+   if they do so, MUST publish the definitions of the classes in the
+   objectClasses attribute of their subschema entries.
+
+   Schema developers MUST NOT create object class definitions whose
+   names conflict with attributes defined for use with LDAP in existing
+   standards-track RFCs.
+
+4.5. Matching Rules
+
+   Matching rules are used by servers to compare attribute values
+   against assertion values when performing Search and Compare
+   operations.  They are also used to identify the value to be added or
+   deleted when modifying entries, and are used when comparing a
+   purported distinguished name with the name of an entry.
+
+   Most of the attributes given in this document will have an equality
+   matching rule defined.
+
+   Matching rule descriptions are written according to the following
+   BNF.  Implementors should note that future versions of this document
+   may have expanded this BNF to include additional terms.  Terms whose
+   identifier begins with "X-" are reserved for private experiments, and
+
+
+
+Wahl, et. al.               Standards Track                    [Page 10]
+
+RFC 2252                   LADPv3 Attributes               December 1997
+
+
+   MUST be followed by a <qdstrings> encoding.
+
+      MatchingRuleDescription = "(" whsp
+          numericoid whsp  ; MatchingRule identifier
+          [ "NAME" qdescrs ]
+          [ "DESC" qdstring ]
+          [ "OBSOLETE" whsp ]
+          "SYNTAX" numericoid
+      whsp ")"
+
+   Values of the matchingRuleUse list the attributes which are suitable
+   for use with an extensible matching rule.
+
+      MatchingRuleUseDescription = "(" whsp
+          numericoid whsp  ; MatchingRule identifier
+          [ "NAME" qdescrs ]
+          [ "DESC" qdstring ]
+          [ "OBSOLETE" ]
+         "APPLIES" oids    ; AttributeType identifiers
+      whsp ")"
+
+   Servers which support matching rules and the extensibleMatch SHOULD
+   implement all the matching rules in section 8.
+
+   Servers MAY implement additional matching rules not listed in this
+   document, and if they do so, MUST publish the definitions of the
+   matching rules in the matchingRules attribute of their subschema
+   entries. If the server supports the extensibleMatch, then the server
+   MUST publish the relationship between the matching rules and
+   attributes in the matchingRuleUse attribute.
+
+   For example, a server which implements a privately-defined matching
+   rule for performing sound-alike matches on Directory String-valued
+   attributes would include the following in the subschema entry
+   (1.2.3.4.5 is an example, the OID of an actual matching rule would be
+   different):
+
+   matchingRule: ( 1.2.3.4.5 NAME 'soundAlikeMatch'
+    SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+   If this matching rule could be used with the attributes 2.5.4.41 and
+   2.5.4.15, the following would also be present:
+
+   matchingRuleUse: ( 1.2.3.4.5 APPLIES (2.5.4.41 $ 2.5.4.15) )
+
+
+
+
+
+
+
+Wahl, et. al.               Standards Track                    [Page 11]
+
+RFC 2252                   LADPv3 Attributes               December 1997
+
+
+   A client could then make use of this matching rule by sending a
+   search operation in which the filter is of the extensibleMatch
+   choice, the matchingRule field is "soundAlikeMatch", and the type
+   field is "2.5.4.41" or "2.5.4.15".
+
+5. Attribute Types
+
+   All LDAP server implementations MUST recognize the attribute types
+   defined in this section.
+
+   Servers SHOULD also recognize all the attributes from section 5 of
+   [12].
+
+5.1. Standard Operational Attributes
+
+   Servers MUST maintain values of these attributes in accordance with
+   the definitions in X.501(93).
+
+5.1.1. createTimestamp
+
+   This attribute SHOULD appear in entries which were created using the
+   Add operation.
+
+    ( 2.5.18.1 NAME 'createTimestamp' EQUALITY generalizedTimeMatch
+      ORDERING generalizedTimeOrderingMatch
+      SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
+      SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation )
+
+5.1.2. modifyTimestamp
+
+   This attribute SHOULD appear in entries which have been modified
+   using the Modify operation.
+
+    ( 2.5.18.2 NAME 'modifyTimestamp' EQUALITY generalizedTimeMatch
+      ORDERING generalizedTimeOrderingMatch
+      SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
+      SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation )
+
+5.1.3. creatorsName
+
+   This attribute SHOULD appear in entries which were created using the
+   Add operation.
+
+    ( 2.5.18.3 NAME 'creatorsName' EQUALITY distinguishedNameMatch
+      SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
+      SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation )
+
+
+
+
+
+Wahl, et. al.               Standards Track                    [Page 12]
+
+RFC 2252                   LADPv3 Attributes               December 1997
+
+
+5.1.4. modifiersName
+
+   This attribute SHOULD appear in entries which have been modified
+   using the Modify operation.
+
+    ( 2.5.18.4 NAME 'modifiersName' EQUALITY distinguishedNameMatch
+      SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
+      SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation )
+
+5.1.5. subschemaSubentry
+
+   The value of this attribute is the name of a subschema entry (or
+   subentry if the server is based on X.500(93)) in which the server
+   makes available attributes specifying the schema.
+
+    ( 2.5.18.10 NAME 'subschemaSubentry'
+      EQUALITY distinguishedNameMatch
+      SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 NO-USER-MODIFICATION
+      SINGLE-VALUE USAGE directoryOperation )
+
+5.1.6. attributeTypes
+
+   This attribute is typically located in the subschema entry.
+
+    ( 2.5.21.5 NAME 'attributeTypes'
+      EQUALITY objectIdentifierFirstComponentMatch
+      SYNTAX 1.3.6.1.4.1.1466.115.121.1.3 USAGE directoryOperation )
+
+5.1.7. objectClasses
+
+   This attribute is typically located in the subschema entry.
+
+    ( 2.5.21.6 NAME 'objectClasses'
+      EQUALITY objectIdentifierFirstComponentMatch
+      SYNTAX 1.3.6.1.4.1.1466.115.121.1.37 USAGE directoryOperation )
+
+5.1.8. matchingRules
+
+   This attribute is typically located in the subschema entry.
+
+    ( 2.5.21.4 NAME 'matchingRules'
+      EQUALITY objectIdentifierFirstComponentMatch
+      SYNTAX 1.3.6.1.4.1.1466.115.121.1.30 USAGE directoryOperation )
+
+
+
+
+
+
+
+
+Wahl, et. al.               Standards Track                    [Page 13]
+
+RFC 2252                   LADPv3 Attributes               December 1997
+
+
+5.1.9. matchingRuleUse
+
+   This attribute is typically located in the subschema entry.
+
+    ( 2.5.21.8 NAME 'matchingRuleUse'
+      EQUALITY objectIdentifierFirstComponentMatch
+      SYNTAX 1.3.6.1.4.1.1466.115.121.1.31 USAGE directoryOperation )
+
+5.2. LDAP Operational Attributes
+
+   These attributes are only present in the root DSE (see [1] and [3]).
+
+   Servers MUST recognize these attribute names, but it is not required
+   that a server provide values for these attributes, when the attribute
+   corresponds to a feature which the server does not implement.
+
+5.2.1. namingContexts
+
+   The values of this attribute correspond to naming contexts which this
+   server masters or shadows.  If the server does not master any
+   information (e.g. it is an LDAP gateway to a public X.500 directory)
+   this attribute will be absent.  If the server believes it contains
+   the entire directory, the attribute will have a single value, and
+   that value will be the empty string (indicating the null DN of the
+   root). This attribute will allow a client to choose suitable base
+   objects for searching when it has contacted a server.
+
+    ( 1.3.6.1.4.1.1466.101.120.5 NAME 'namingContexts'
+     SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 USAGE dSAOperation )
+
+5.2.2. altServer
+
+   The values of this attribute are URLs of other servers which may be
+   contacted when this server becomes unavailable.  If the server does
+   not know of any other servers which could be used this attribute will
+   be absent. Clients may cache this information in case their preferred
+   LDAP server later becomes unavailable.
+
+    ( 1.3.6.1.4.1.1466.101.120.6 NAME 'altServer'
+     SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 USAGE dSAOperation )
+
+5.2.3. supportedExtension
+
+   The values of this attribute are OBJECT IDENTIFIERs identifying the
+   supported extended operations which the server supports.
+
+   If the server does not support any extensions this attribute will be
+   absent.
+
+
+
+Wahl, et. al.               Standards Track                    [Page 14]
+
+RFC 2252                   LADPv3 Attributes               December 1997
+
+
+    ( 1.3.6.1.4.1.1466.101.120.7 NAME 'supportedExtension'
+     SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 USAGE dSAOperation )
+
+5.2.4. supportedControl
+
+   The values of this attribute are the OBJECT IDENTIFIERs identifying
+   controls which the server supports.  If the server does not support
+   any controls, this attribute will be absent.
+
+    ( 1.3.6.1.4.1.1466.101.120.13 NAME 'supportedControl'
+     SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 USAGE dSAOperation )
+
+5.2.5. supportedSASLMechanisms
+
+   The values of this attribute are the names of supported SASL
+   mechanisms which the server supports.  If the server does not support
+   any mechanisms this attribute will be absent.
+
+    ( 1.3.6.1.4.1.1466.101.120.14 NAME 'supportedSASLMechanisms'
+     SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 USAGE dSAOperation )
+
+5.2.6. supportedLDAPVersion
+
+   The values of this attribute are the versions of the LDAP protocol
+   which the server implements.
+
+    ( 1.3.6.1.4.1.1466.101.120.15 NAME 'supportedLDAPVersion'
+     SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 USAGE dSAOperation )
+
+5.3. LDAP Subschema Attribute
+
+   This attribute is typically located in the subschema entry.
+
+5.3.1. ldapSyntaxes
+
+   Servers MAY use this attribute to list the syntaxes which are
+   implemented.  Each value corresponds to one syntax.
+
+    ( 1.3.6.1.4.1.1466.101.120.16 NAME 'ldapSyntaxes'
+      EQUALITY objectIdentifierFirstComponentMatch
+      SYNTAX 1.3.6.1.4.1.1466.115.121.1.54 USAGE directoryOperation )
+
+5.4. X.500 Subschema attributes
+
+   These attributes are located in the subschema entry.  All servers
+   SHOULD recognize their name, although typically only X.500 servers
+   will implement their functionality.
+
+
+
+
+Wahl, et. al.               Standards Track                    [Page 15]
+
+RFC 2252                   LADPv3 Attributes               December 1997
+
+
+5.4.1. dITStructureRules
+
+ ( 2.5.21.1 NAME 'dITStructureRules' EQUALITY integerFirstComponentMatch
+   SYNTAX 1.3.6.1.4.1.1466.115.121.1.17 USAGE directoryOperation )
+
+5.4.2. nameForms
+
+    ( 2.5.21.7 NAME 'nameForms'
+      EQUALITY objectIdentifierFirstComponentMatch
+      SYNTAX 1.3.6.1.4.1.1466.115.121.1.35 USAGE directoryOperation )
+
+5.4.3. ditContentRules
+
+    ( 2.5.21.2 NAME 'dITContentRules'
+      EQUALITY objectIdentifierFirstComponentMatch
+      SYNTAX 1.3.6.1.4.1.1466.115.121.1.16 USAGE directoryOperation )
+
+6. Syntaxes
+
+   Servers SHOULD recognize all the syntaxes described in this section.
+
+6.1. Attribute Type Description
+
+   ( 1.3.6.1.4.1.1466.115.121.1.3 DESC 'Attribute Type Description' )
+
+   Values in this syntax are encoded according to the BNF given at the
+   start of section 4.2. For example,
+
+        ( 2.5.4.0 NAME 'objectClass'
+          SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
+
+6.2. Binary
+
+   ( 1.3.6.1.4.1.1466.115.121.1.5 DESC 'Binary' )
+
+   Values in this syntax are encoded as described in section 4.3.1.
+
+6.3. Bit String
+
+   ( 1.3.6.1.4.1.1466.115.121.1.6 DESC 'Bit String' )
+
+   Values in this syntax are encoded according to the following BNF:
+
+      bitstring = "'" *binary-digit "'B"
+
+      binary-digit = "0" / "1"
+
+
+
+
+
+Wahl, et. al.               Standards Track                    [Page 16]
+
+RFC 2252                   LADPv3 Attributes               December 1997
+
+
+   Example:
+
+        '0101111101'B
+
+6.4. Boolean
+
+   ( 1.3.6.1.4.1.1466.115.121.1.7 DESC 'Boolean' )
+
+   Values in this syntax are encoded according to the following BNF:
+
+      boolean = "TRUE" / "FALSE"
+
+   Boolean values have an encoding of "TRUE" if they are logically true,
+   and have an encoding of "FALSE" otherwise.
+
+6.5. Certificate
+
+   ( 1.3.6.1.4.1.1466.115.121.1.8 DESC 'Certificate' )
+
+   Because of the changes from X.509(1988) and X.509(1993) and
+   additional changes to the ASN.1 definition to support certificate
+   extensions, no string representation is defined, and values in this
+   syntax MUST only be transferred using the binary encoding, by
+   requesting or returning the attributes with descriptions
+   "userCertificate;binary" or "caCertificate;binary".  The BNF notation
+   in RFC 1778 for "User Certificate" is not recommended to be used.
+
+6.6. Certificate List
+
+   ( 1.3.6.1.4.1.1466.115.121.1.9 DESC 'Certificate List' )
+
+   Because of the incompatibility of the X.509(1988) and X.509(1993)
+   definitions of revocation lists, values in this syntax MUST only be
+   transferred using a binary encoding, by requesting or returning the
+   attributes with descriptions "certificateRevocationList;binary" or
+   "authorityRevocationList;binary".  The BNF notation in RFC 1778 for
+   "Authority Revocation List" is not recommended to be used.
+
+6.7. Certificate Pair
+
+   ( 1.3.6.1.4.1.1466.115.121.1.10 DESC 'Certificate Pair' )
+
+   Because the Certificate is being carried in binary, values in this
+   syntax MUST only be transferred using a binary encoding, by
+   requesting or returning the attribute description
+   "crossCertificatePair;binary". The BNF notation in RFC 1778 for
+   "Certificate Pair" is not recommended to be used.
+
+
+
+
+Wahl, et. al.               Standards Track                    [Page 17]
+
+RFC 2252                   LADPv3 Attributes               December 1997
+
+
+6.8. Country String
+
+   ( 1.3.6.1.4.1.1466.115.121.1.11 DESC 'Country String' )
+
+   A value in this syntax is encoded the same as a value of Directory
+   String syntax.  Note that this syntax is limited to values of exactly
+   two printable string characters, as listed in ISO 3166 [14].
+
+      CountryString  = p p
+
+   Example:
+      US
+
+6.9. DN
+
+   ( 1.3.6.1.4.1.1466.115.121.1.12 DESC 'DN' )
+
+   Values in the Distinguished Name syntax are encoded to have the
+   representation defined in [5].  Note that this representation is not
+   reversible to an ASN.1 encoding used in X.500 for Distinguished
+   Names, as the CHOICE of any DirectoryString element in an RDN is no
+   longer known.
+
+   Examples (from [5]):
+      CN=Steve Kille,O=Isode Limited,C=GB
+      OU=Sales+CN=J. Smith,O=Widget Inc.,C=US
+      CN=L. Eagle,O=Sue\, Grabbit and Runn,C=GB
+      CN=Before\0DAfter,O=Test,C=GB
+      1.3.6.1.4.1.1466.0=#04024869,O=Test,C=GB
+      SN=Lu\C4\8Di\C4\87
+
+6.10. Directory String
+
+   ( 1.3.6.1.4.1.1466.115.121.1.15 DESC 'Directory String' )
+
+   A string in this syntax is encoded in the UTF-8 form of ISO 10646 (a
+   superset of Unicode).  Servers and clients MUST be prepared to
+   receive encodings of arbitrary Unicode characters, including
+   characters not presently assigned to any character set.
+
+   For characters in the PrintableString form, the value is encoded as
+   the string value itself.
+
+   If it is of the TeletexString form, then the characters are
+   transliterated to their equivalents in UniversalString, and encoded
+   in UTF-8 [9].
+
+
+
+
+
+Wahl, et. al.               Standards Track                    [Page 18]
+
+RFC 2252                   LADPv3 Attributes               December 1997
+
+
+   If it is of the UniversalString or BMPString forms [10], UTF-8 is
+   used to encode them.
+
+   Note: the form of DirectoryString is not indicated in protocol unless
+   the attribute value is carried in binary.  Servers which convert to
+   DAP MUST choose an appropriate form.  Servers MUST NOT reject values
+   merely because they contain legal Unicode characters outside of the
+   range of printable ASCII.
+
+   Example:
+
+      This is a string of DirectoryString containing #!%#@
+
+6.11. DIT Content Rule Description
+
+   ( 1.3.6.1.4.1.1466.115.121.1.16 DESC 'DIT Content Rule Description' )
+
+   Values in this syntax are encoded according to the following BNF.
+   Implementors should note that future versions of this document may
+   have expanded this BNF to include additional terms.
+
+
+      DITContentRuleDescription = "("
+          numericoid   ; Structural ObjectClass identifier
+          [ "NAME" qdescrs ]
+          [ "DESC" qdstring ]
+          [ "OBSOLETE" ]
+          [ "AUX" oids ]    ; Auxiliary ObjectClasses
+          [ "MUST" oids ]   ; AttributeType identifiers
+          [ "MAY" oids ]    ; AttributeType identifiers
+          [ "NOT" oids ]    ; AttributeType identifiers
+         ")"
+
+6.12. Facsimile Telephone Number
+
+
+   ( 1.3.6.1.4.1.1466.115.121.1.22 DESC 'Facsimile Telephone Number' )
+
+   Values in this syntax are encoded according to the following BNF:
+
+      fax-number    = printablestring [ "$" faxparameters ]
+
+      faxparameters = faxparm / ( faxparm "$" faxparameters )
+
+      faxparm = "twoDimensional" / "fineResolution" /
+                "unlimitedLength" /
+                "b4Length" / "a3Width" / "b4Width" / "uncompressed"
+
+
+
+
+Wahl, et. al.               Standards Track                    [Page 19]
+
+RFC 2252                   LADPv3 Attributes               December 1997
+
+
+   In the above, the first printablestring is the telephone number,
+   based on E.123 [15], and the faxparm tokens represent fax parameters.
+
+6.13. Fax
+
+   ( 1.3.6.1.4.1.1466.115.121.1.23 DESC 'Fax' )
+
+   Values in this syntax are encoded as if they were octet strings
+   containing Group 3 Fax images as defined in [7].
+
+6.14. Generalized Time
+
+   ( 1.3.6.1.4.1.1466.115.121.1.24 DESC 'Generalized Time' )
+
+   Values in this syntax are encoded as printable strings, represented
+   as specified in X.208.  Note that the time zone must be specified.
+   It is strongly recommended that GMT time be used.  For example,
+
+                199412161032Z
+
+6.15. IA5 String
+
+   ( 1.3.6.1.4.1.1466.115.121.1.26 DESC 'IA5 String' )
+
+   The encoding of a value in this syntax is the string value itself.
+
+6.16. INTEGER
+
+   ( 1.3.6.1.4.1.1466.115.121.1.27 DESC 'INTEGER' )
+
+   Values in this syntax are encoded as the decimal representation of
+   their values, with each decimal digit represented by the its
+   character equivalent. So the number 1321 is represented by the
+   character string "1321".
+
+6.17. JPEG
+
+   ( 1.3.6.1.4.1.1466.115.121.1.28 DESC 'JPEG' )
+
+   Values in this syntax are encoded as strings containing JPEG images
+   in the JPEG File Interchange Format (JFIF), as described in [8].
+
+6.18. Matching Rule Description
+
+   ( 1.3.6.1.4.1.1466.115.121.1.30 DESC 'Matching Rule Description' )
+
+   Values of type matchingRules are encoded as strings according to the
+   BNF given in section 4.5.
+
+
+
+Wahl, et. al.               Standards Track                    [Page 20]
+
+RFC 2252                   LADPv3 Attributes               December 1997
+
+
+6.19. Matching Rule Use Description
+
+   ( 1.3.6.1.4.1.1466.115.121.1.31 DESC 'Matching Rule Use Description'
+   )
+
+   Values of type matchingRuleUse are encoded as strings according to
+   the BNF given in section 4.5.
+
+6.20. MHS OR Address
+
+   ( 1.3.6.1.4.1.1466.115.121.1.33 DESC 'MHS OR Address' )
+
+   Values in this syntax are encoded as strings, according to the format
+   defined in [11].
+
+6.21. Name And Optional UID
+
+   ( 1.3.6.1.4.1.1466.115.121.1.34 DESC 'Name And Optional UID' )
+
+   Values in this syntax are encoded according to the following BNF:
+
+      NameAndOptionalUID = DistinguishedName [ "#" bitstring ]
+
+   Although the '#' character may occur in a string representation of a
+   distinguished name, no additional special quoting is done.  This
+   syntax has been added subsequent to RFC 1778.
+
+   Example:
+
+      1.3.6.1.4.1.1466.0=#04024869,O=Test,C=GB#'0101'B
+
+6.22. Name Form Description
+
+   ( 1.3.6.1.4.1.1466.115.121.1.35 DESC 'Name Form Description' )
+
+   Values in this syntax are encoded according to the following BNF.
+   Implementors should note that future versions of this document may
+   have expanded this BNF to include additional terms.
+
+      NameFormDescription = "(" whsp
+          numericoid whsp  ; NameForm identifier
+          [ "NAME" qdescrs ]
+          [ "DESC" qdstring ]
+          [ "OBSOLETE" whsp ]
+          "OC" woid         ; Structural ObjectClass
+          "MUST" oids       ; AttributeTypes
+          [ "MAY" oids ]    ; AttributeTypes
+      whsp ")"
+
+
+
+Wahl, et. al.               Standards Track                    [Page 21]
+
+RFC 2252                   LADPv3 Attributes               December 1997
+
+
+6.23. Numeric String
+
+   ( 1.3.6.1.4.1.1466.115.121.1.36 DESC 'Numeric String' )
+
+   The encoding of a string in this syntax is the string value itself.
+   Example:
+
+      1997
+
+6.24. Object Class Description
+
+   ( 1.3.6.1.4.1.1466.115.121.1.37 DESC 'Object Class Description' )
+
+   Values in this syntax are encoded according to the BNF in section
+   4.4.
+
+6.25. OID
+
+   ( 1.3.6.1.4.1.1466.115.121.1.38 DESC 'OID' )
+
+   Values in the Object Identifier syntax are encoded according to
+   the BNF in section 4.1 for "oid".
+
+   Example:
+
+      1.2.3.4
+      cn
+
+6.26. Other Mailbox
+
+   ( 1.3.6.1.4.1.1466.115.121.1.39 DESC 'Other Mailbox' )
+
+   Values in this syntax are encoded according to the following BNF:
+
+      otherMailbox = mailbox-type "$" mailbox
+
+      mailbox-type = printablestring
+
+      mailbox = <an encoded IA5 String>
+
+   In the above, mailbox-type represents the type of mail system in
+   which the mailbox resides, for example "MCIMail"; and mailbox is the
+   actual mailbox in the mail system defined by mailbox-type.
+
+6.27. Postal Address
+
+   ( 1.3.6.1.4.1.1466.115.121.1.41 DESC 'Postal Address' )
+
+
+
+
+Wahl, et. al.               Standards Track                    [Page 22]
+
+RFC 2252                   LADPv3 Attributes               December 1997
+
+
+   Values in this syntax are encoded according to the following BNF:
+
+      postal-address = dstring *( "$" dstring )
+
+   In the above, each dstring component of a postal address value is
+   encoded as a value of type Directory String syntax.  Backslashes and
+   dollar characters, if they occur in the component, are quoted as
+   described in section 4.3.   Many servers limit the postal address to
+   six lines of up to thirty characters.
+
+   Example:
+
+      1234 Main St.$Anytown, CA 12345$USA
+      \241,000,000 Sweepstakes$PO Box 1000000$Anytown, CA 12345$USA
+
+6.28. Presentation Address
+
+   ( 1.3.6.1.4.1.1466.115.121.1.43 DESC 'Presentation Address' )
+
+   Values in this syntax are encoded with the representation described
+   in RFC 1278 [6].
+
+6.29. Printable String
+
+   ( 1.3.6.1.4.1.1466.115.121.1.44 DESC 'Printable String' )
+
+   The encoding of a value in this syntax is the string value itself.
+   PrintableString is limited to the characters in production p of
+   section 4.1.
+
+   Example:
+
+      This is a PrintableString
+
+6.30. Telephone Number
+
+   ( 1.3.6.1.4.1.1466.115.121.1.50 DESC 'Telephone Number' )
+
+   Values in this syntax are encoded as if they were Printable String
+   types.  Telephone numbers are recommended in X.520 to be in
+   international form, as described in E.123 [15].
+
+   Example:
+
+      +1 512 305 0280
+
+
+
+
+
+
+Wahl, et. al.               Standards Track                    [Page 23]
+
+RFC 2252                   LADPv3 Attributes               December 1997
+
+
+6.31. UTC Time
+
+   ( 1.3.6.1.4.1.1466.115.121.1.53 DESC 'UTC Time' )
+
+   Values in this syntax are encoded as if they were printable strings
+   with the strings containing a UTCTime value.  This is historical; new
+   attribute definitions SHOULD use GeneralizedTime instead.
+
+6.32. LDAP Syntax Description
+
+   ( 1.3.6.1.4.1.1466.115.121.1.54 DESC 'LDAP Syntax Description' )
+
+   Values in this syntax are encoded according to the BNF in section
+   4.3.3.
+
+6.33. DIT Structure Rule Description
+
+   ( 1.3.6.1.4.1.1466.115.121.1.17 DESC 'DIT Structure Rule Description'
+   )
+
+   Values with this syntax are encoded according to the following BNF:
+
+      DITStructureRuleDescription = "(" whsp
+          ruleidentifier whsp            ; DITStructureRule identifier
+          [ "NAME" qdescrs ]
+          [ "DESC" qdstring ]
+          [ "OBSOLETE" whsp ]
+          "FORM" woid whsp               ; NameForm
+          [ "SUP" ruleidentifiers whsp ] ; superior DITStructureRules
+      ")"
+
+      ruleidentifier = integer
+
+      ruleidentifiers = ruleidentifier |
+          "(" whsp ruleidentifierlist whsp ")"
+
+      ruleidentifierlist = [ ruleidentifier *( ruleidentifier ) ]
+
+7. Object Classes
+
+   Servers SHOULD recognize all the names of standard classes from
+   section 7 of [12].
+
+7.1. Extensible Object Class
+
+   The extensibleObject object class, if present in an entry, permits
+   that entry to optionally hold any attribute.  The MAY attribute list
+   of this class is implicitly the set of all attributes.
+
+
+
+Wahl, et. al.               Standards Track                    [Page 24]
+
+RFC 2252                   LADPv3 Attributes               December 1997
+
+
+    ( 1.3.6.1.4.1.1466.101.120.111 NAME 'extensibleObject'
+      SUP top AUXILIARY )
+
+   The mandatory attributes of the other object classes of this entry
+   are still required to be present.
+
+   Note that not all servers will implement this object class, and those
+   which do not will reject requests to add entries which contain this
+   object class, or modify an entry to add this object class.
+
+7.2. subschema
+
+   This object class is used in the subschema entry.
+
+    ( 2.5.20.1 NAME 'subschema' AUXILIARY
+      MAY ( dITStructureRules $ nameForms $ ditContentRules $
+      objectClasses $ attributeTypes $ matchingRules $
+      matchingRuleUse ) )
+
+   The ldapSyntaxes operational attribute may also be present in
+   subschema entries.
+
+8. Matching Rules
+
+   Servers which implement the extensibleMatch filter SHOULD allow all
+   the matching rules listed in this section to be used in the
+   extensibleMatch.  In general these servers SHOULD allow matching
+   rules to be used with all attribute types known to the server, when
+   the assertion syntax of the matching rule is the same as the value
+   syntax of the attribute.
+
+   Servers MAY implement additional matching rules.
+
+8.1. Matching Rules used in Equality Filters
+
+   Servers SHOULD be capable of performing the following matching rules.
+
+   For all these rules, the assertion syntax is the same as the value
+   syntax.
+
+    ( 2.5.13.0 NAME 'objectIdentifierMatch'
+      SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
+
+   If the client supplies a filter using an objectIdentifierMatch whose
+   matchValue oid is in the "descr" form, and the oid is not recognized
+   by the server, then the filter is Undefined.
+
+    ( 2.5.13.1 NAME 'distinguishedNameMatch'
+
+
+
+Wahl, et. al.               Standards Track                    [Page 25]
+
+RFC 2252                   LADPv3 Attributes               December 1997
+
+
+      SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
+
+    ( 2.5.13.2 NAME 'caseIgnoreMatch'
+      SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+    ( 2.5.13.8 NAME 'numericStringMatch'
+      SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 )
+
+    ( 2.5.13.11 NAME 'caseIgnoreListMatch'
+      SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 )
+
+    ( 2.5.13.14 NAME 'integerMatch'
+      SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )
+
+    ( 2.5.13.16 NAME 'bitStringMatch'
+      SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 )
+
+    ( 2.5.13.20 NAME 'telephoneNumberMatch'
+      SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 )
+
+    ( 2.5.13.22 NAME 'presentationAddressMatch'
+      SYNTAX 1.3.6.1.4.1.1466.115.121.1.43 )
+
+    ( 2.5.13.23 NAME 'uniqueMemberMatch'
+      SYNTAX 1.3.6.1.4.1.1466.115.121.1.34 )
+
+    ( 2.5.13.24 NAME 'protocolInformationMatch'
+      SYNTAX 1.3.6.1.4.1.1466.115.121.1.42 )
+
+    ( 2.5.13.27 NAME 'generalizedTimeMatch'
+      SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 )
+
+    ( 1.3.6.1.4.1.1466.109.114.1 NAME 'caseExactIA5Match'
+      SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
+
+    ( 1.3.6.1.4.1.1466.109.114.2 NAME 'caseIgnoreIA5Match'
+      SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
+
+   When performing the caseIgnoreMatch, caseIgnoreListMatch,
+   telephoneNumberMatch, caseExactIA5Match and caseIgnoreIA5Match,
+   multiple adjoining whitespace characters are treated the same as an
+   individual space, and leading and trailing whitespace is ignored.
+
+   Clients MUST NOT assume that servers are capable of transliteration
+   of Unicode values.
+
+
+
+
+
+
+Wahl, et. al.               Standards Track                    [Page 26]
+
+RFC 2252                   LADPv3 Attributes               December 1997
+
+
+8.2. Matching Rules used in Inequality Filters
+
+   Servers SHOULD be capable of performing the following matching rules,
+   which are used in greaterOrEqual and lessOrEqual filters.
+
+    ( 2.5.13.28 NAME 'generalizedTimeOrderingMatch'
+      SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 )
+
+    ( 2.5.13.3 NAME 'caseIgnoreOrderingMatch'
+      SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+   The sort ordering for a caseIgnoreOrderingMatch is implementation-
+   dependent.
+
+8.3. Syntax and Matching Rules used in Substring Filters
+
+   The Substring Assertion syntax is used only as the syntax of
+   assertion values in the extensible match.  It is not used as the
+   syntax of attributes, or in the substring filter.
+
+   ( 1.3.6.1.4.1.1466.115.121.1.58 DESC 'Substring Assertion' )
+
+   The Substring Assertion is encoded according to the following BNF:
+
+      substring = [initial] any [final]
+      initial = value
+      any = "*" *(value "*")
+      final = value
+
+   The <value> production is UTF-8 encoded string.  Should the backslash
+   or asterix characters be present in a production of <value>, they are
+   quoted as described in section 4.3.
+
+   Servers SHOULD be capable of performing the following matching rules,
+   which are used in substring filters.
+
+   ( 2.5.13.4 NAME 'caseIgnoreSubstringsMatch'
+    SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
+
+   ( 2.5.13.21 NAME 'telephoneNumberSubstringsMatch'
+    SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
+
+   ( 2.5.13.10 NAME 'numericStringSubstringsMatch'
+    SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
+
+
+
+
+
+
+
+Wahl, et. al.               Standards Track                    [Page 27]
+
+RFC 2252                   LADPv3 Attributes               December 1997
+
+
+8.4. Matching Rules for Subschema Attributes
+
+   Servers which allow subschema entries to be modified by clients MUST
+   support the following matching rules, as they are the equality
+   matching rules for several of the subschema attributes.
+
+   ( 2.5.13.29 NAME 'integerFirstComponentMatch'
+     SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )
+
+   ( 2.5.13.30 NAME 'objectIdentifierFirstComponentMatch'
+     SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
+
+   Implementors should note that the assertion syntax of these matching
+   rules, an INTEGER or OID, is different from the value syntax of
+   attributes for which this is the equality matching rule.
+
+   If the client supplies an extensible filter using an
+   objectIdentifierFirstComponentMatch whose matchValue is in the
+   "descr" form, and the OID is not recognized by the server, then the
+   filter is Undefined.
+
+9. Security Considerations
+
+9.1. Disclosure
+
+   Attributes of directory entries are used to provide descriptive
+   information about the real-world objects they represent, which can be
+   people, organizations or devices.  Most countries have privacy laws
+   regarding the publication of information about people.
+
+9.2. Use of Attribute Values in Security Applications
+
+   The transformations of an AttributeValue value from its X.501 form to
+   an LDAP string representation are not always reversible back to the
+   same BER or DER form.  An example of a situation which requires the
+   DER form of a distinguished name is the verification of an X.509
+   certificate.
+
+   For example, a distinguished name consisting of one RDN with one AVA,
+   in which the type is commonName and the value is of the TeletexString
+   choice with the letters 'Sam' would be represented in LDAP as the
+   string CN=Sam.  Another distinguished name in which the value is
+   still 'Sam' but of the PrintableString choice would have the same
+   representation CN=Sam.
+
+   Applications which require the reconstruction of the DER form of the
+   value SHOULD NOT use the string representation of attribute syntaxes
+   when converting a value to LDAP format.  Instead it SHOULD use the
+
+
+
+Wahl, et. al.               Standards Track                    [Page 28]
+
+RFC 2252                   LADPv3 Attributes               December 1997
+
+
+   Binary syntax.
+
+10. Acknowledgements
+
+   This document is based substantially on RFC 1778, written by Tim
+   Howes, Steve Kille, Wengyik Yeong and Colin Robbins.
+
+   Many of the attribute syntax encodings defined in this and related
+   documents are adapted from those used in the QUIPU and the IC R3
+   X.500 implementations. The contributions of the authors of both these
+   implementations in the specification of syntaxes are gratefully
+   acknowledged.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wahl, et. al.               Standards Track                    [Page 29]
+
+RFC 2252                   LADPv3 Attributes               December 1997
+
+
+11. Authors' Addresses
+
+   Mark Wahl
+   Critical Angle Inc.
+   4815 West Braker Lane #502-385
+   Austin, TX 78759
+   USA
+
+   Phone:  +1 512 372-3160
+   EMail:  M.Wahl@critical-angle.com
+
+   Andy Coulbeck
+   Isode Inc.
+   9390 Research Blvd Suite 305
+   Austin, TX 78759
+   USA
+
+   Phone:  +1 512 231-8993
+   EMail:  A.Coulbeck@isode.com
+
+   Tim Howes
+   Netscape Communications Corp.
+   501 E. Middlefield Rd, MS MV068
+   Mountain View, CA 94043
+   USA
+
+   Phone:  +1 650 937-3419
+   EMail:   howes@netscape.com
+
+   Steve Kille
+   Isode Limited
+   The Dome, The Square
+   Richmond
+   TW9 1DT
+   UK
+
+   Phone:  +44-181-332-9091
+   EMail:  S.Kille@isode.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wahl, et. al.               Standards Track                    [Page 30]
+
+RFC 2252                   LADPv3 Attributes               December 1997
+
+
+12. Bibliography
+
+   [1] Wahl, M., Howes, T., and S. Kille, "Lightweight Directory Access
+       Protocol (v3)", RFC 2251, December 1997.
+
+   [2] The Directory: Selected Attribute Types.  ITU-T Recommendation
+       X.520, 1993.
+
+   [3] The Directory: Models. ITU-T Recommendation X.501, 1993.
+
+   [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+       Levels", RFC 2119, March 1997.
+
+   [5] Wahl, M., Kille, S., and T. Howes, "Lightweight Directory Access
+       Protocol (v3): UTF-8 String Representation of
+       Distinguished Names", RFC 2253, December 1997.
+
+   [6] Kille, S., "A String Representation for Presentation Addresses",
+       RFC 1278, November 1991.
+
+   [7] Terminal Equipment and Protocols for Telematic Services -
+       Standardization of Group 3 facsimile apparatus for document
+       transmission.  CCITT, Recommendation T.4.
+
+   [8] JPEG File Interchange Format (Version 1.02).  Eric Hamilton,
+       C-Cube Microsystems, Milpitas, CA, September 1, 1992.
+
+   [9] Yergeau, F., "UTF-8, a transformation format of Unicode and ISO
+       10646", RFC 2044, October 1996.
+
+   [10] Universal Multiple-Octet Coded Character Set (UCS) -
+        Architecture and Basic Multilingual Plane, ISO/IEC 10646-1 :
+        1993 (With amendments).
+
+   [11] Hardcastle-Kille, S., "Mapping between X.400(1988) / ISO 10021
+        and RFC 822", RFC 1327, May 1992.
+
+   [12] Wahl, M., "A Summary of the X.500(96) User Schema for use
+        with LDAPv3", RFC 2256, December 1997.
+
+   [13] Crocker, D., "Standard of the Format of ARPA-Internet Text
+        Messages", STD 11, RFC 822, August 1982.
+
+   [14] ISO 3166, "Codes for the representation of names of countries".
+
+   [15] ITU-T Rec. E.123, Notation for national and international
+        telephone numbers, 1988.
+
+
+
+
+Wahl, et. al.               Standards Track                    [Page 31]
+
+RFC 2252                   LADPv3 Attributes               December 1997
+
+
+13.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (1997).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wahl, et. al.               Standards Track                    [Page 32]
+