INTERNET-DRAFT                                          K. Dally, Editor
Intended Category:  Standard Track                       The MITRE Corp.
Expires:  27 August 2002  4 May 2003                                             S. Legg
Obsoletes:  RFC 2252 2252, RFC 2256                                    ADACEL
                                                        27 February
                                                         4 November 2002

              Lightweight Directory Access Protocol (v3):
                      Attribute Syntax Definitions
                    <draft-ietf-ldapbis-syntaxes-02>

                             LDAP:  Syntaxes
                    <draft-ietf-ldapbis-syntaxes-03>

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC 2026.

   This document is intended to be, after appropriate review and
   revision, submitted to the RFC Editor as a Standard Track document.
   Distribution of this memo is unlimited.  Technical discussion of
   this document will take place on the IETF LDAP Revision Working
   Group (LDAPbis) mailing list <ietf-ldapbis@openldap.org>.  Please
   send editorial comments directly to the author editor <kdally@mitre.org>.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.  Internet-Drafts are draft documents valid for a maximum of
   six months and may be updated, replaced, or obsoleted by other
   documents at any time.  It is inappropriate to use Internet-Drafts as
   reference material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.  The list of
   Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   Copyright 2002, The Internet Society.  All Rights Reserved.

   Please see the Copyright section near the end of this document for
   more information.

Abstract

   The Lightweight Directory Access Protocol (LDAP) [Prot] [Protocol] provides
   for exchanging AttributeValue fields in protocol.  This document
   defines a set of syntaxes for LDAP, and the rules by which attribute values
   of these syntaxes are represented in the LDAP protocol. protocol, and the
   matching rules which specify how values are compared.  Also, this
   document indicates the syntax support requirements on LDAP servers.
   The syntaxes and matching rules defined in this document are used by this and other in
   schema definition documents to
   define specify attribute types.  In addition, this document defines the set
   of attribute syntaxes, which LDAP servers support, and other schema
   elements (required and optional) that are common to all
   LDAP servers.

   [Editor's note:  This document is a modified version of the text parts of
   RFC 2252, 2252 and RFC 2256, in order to bring it then up to date.  This
   action is part of the maintenance activity that is needed in order
   to progress LDAP (v3) to Draft Standard.  The changes are described
   in Annex C of this document.  Open items are listed in Annex B.
   End of Editor's note]
                           Table of Contents

Status of this Memo....................................................1

Abstract...............................................................2

1.  Overview...........................................................6  Overview...........................................................5

2.  General Issues.....................................................6 Issues.....................................................5
2.1  Notation..........................................................6  Notation..........................................................5
2.2  Syntaxes..........................................................9  Syntaxes..........................................................5
2.2.1  LDAP-Specific Encodings.........................................6
2.2.2  Syntaxes Implementation Status..................................9
2.2.2  Syntax Object Identifiers...................................... 9 Status..................................6
2.2.3  Syntax Description.............................................10 Object Identifiers.......................................6
2.2.4  Example........................................................10  Syntax Description..............................................6
2.3  Matching Rules...................................................11 Rules....................................................7
2.3.1  Matching Rules Implementation Status...........................11 Status............................7
2.3.2  Matching Rule Description......................................11
2.3.3  Example........................................................12
2.4  Attribute Types..................................................12
2.4.1  Attribute Types Implementation Status..........................12
2.4.2  Attribute Types Description....................................13
2.4.3  Example........................................................15
2.5  Object Classes...................................................15
2.5.1  Object Classes Implementation Status...........................15
2.5.2  Object Class Description.......................................16
2.5.3  Example........................................................16 Description.......................................7

3.  Syntaxes..........................................................18  Syntaxes...........................................................8
3.1  Attribute Type Description.......................................18 Description........................................8
3.2  Bit String.......................................................18 String........................................................8
3.3  Boolean..........................................................19  Boolean...........................................................8
3.4  Country String...................................................19 String....................................................9
3.5  Delivery Method..................................................19 Method...................................................9
3.6  Directory String.................................................20 String..................................................9
3.7  DIT Content Rule Description.....................................20 Description.....................................10
3.8  DIT Structure Rule Description...................................21 Description...................................11
3.9  DN...............................................................22  DN...............................................................11
3.10 Enhanced Guide...................................................23 Guide...................................................12
3.11 Facsimile Telephone Number.......................................23 Number.......................................12
3.12 Fax..............................................................24 Fax..............................................................13
3.13 Generalized Time.................................................24 Time.................................................13
3.14 Guide............................................................25 Guide............................................................13
3.15 IA5 String.......................................................25 String.......................................................14
3.16 Integer..........................................................25 Integer..........................................................14
3.17 JPEG.............................................................26 JPEG.............................................................14
3.18 LDAP Syntax Description..........................................26 Description..........................................15
3.19 Matching Rule Description........................................26 Description........................................15
3.20 Matching Rule Use Description....................................26 Description....................................15
3.21 MHS OR Address...................................................27 Address...................................................15
3.22 Name and Optional UID............................................27 UID............................................16
3.23 Name Form Description............................................28 Description............................................16
3.24 Numeric String...................................................29 String...................................................16
3.25 Object Class Description.........................................29 Description.........................................17
3.26 Octet String.....................................................29 String.....................................................17
3.27 OID..............................................................30 OID..............................................................17
3.28 Other Mailbox....................................................30 Mailbox....................................................18
3.29 Postal Address...................................................30 Address...................................................18
3.30 Presentation Address.............................................31 Address.............................................19
3.31 Printable String.................................................33 String.................................................21
3.32 Substring Assertion       .......................................33       .......................................21
3.33 Telephone Number.................................................34 Number.................................................21
3.34 Teletex Terminal Identifier......................................34 Identifier......................................22

3.35 Telex Number.....................................................34 Number.....................................................22
3.36 UTC Time.........................................................35 Time.........................................................23

4.  Matching Rules....................................................36 Rules....................................................23
4.1  bitStringMatch...................................................36  bitStringMatch...................................................23
4.2  caseExactIA5Match................................................36  caseExactIA5Match................................................23
4.3  caseIgnoreIA5Match...............................................36  caseIgnoreIA5Match...............................................24
4.4  caseIgnoreListMatch..............................................36  caseIgnoreListMatch..............................................24
4.5  caseIgnoreMatch..................................................37  caseIgnoreMatch..................................................24
4.6  caseIgnoreOrderingMatch..........................................37  caseIgnoreOrderingMatch..........................................24
4.7  caseIgnoreSubstringsMatch........................................37  caseIgnoreSubstringsMatch........................................25
4.8  distinguishedNameMatch...........................................37  distinguishedNameMatch...........................................25
4.9  generalizedTimeMatch.............................................37  generalizedTimeMatch.............................................25
4.10 generalizedTimeOrderingMatch.....................................38 generalizedTimeOrderingMatch.....................................25
4.11 integerFirstComponentMatch.......................................38 integerFirstComponentMatch.......................................25
4.12 integerMatch.....................................................38 integerMatch.....................................................26
4.13 numericStringMatch...............................................38 numericStringMatch...............................................26
4.14 numericStringSubstringsMatch.....................................38 numericStringSubstringsMatch.....................................26
4.15 objectIdentifierFirstComponentMatch..............................39 objectIdentifierFirstComponentMatch..............................26
4.16 objectIdentifierMatch............................................39 objectIdentifierMatch............................................26
4.17 octetStringMatch.................................................39 octetStringMatch.................................................27
4.18 presentationAddressMatch.........................................40 presentationAddressMatch.........................................27
4.19 protocolInformationMatch.........................................40 protocolInformationMatch.........................................27
4.20 telephoneNumberMatch.............................................40 telephoneNumberMatch.............................................28
4.21 telephoneNumberSubstringsMatch...................................40 telephoneNumberSubstringsMatch...................................28
4.22 uniqueMemberMatch................................................40 uniqueMemberMatch................................................28

5.  Attribute Types...................................................41  Security Considerations...........................................28
5.1  altServer........................................................41  Disclosure.......................................................28
5.2  attributeTypes...................................................41
5.3  createTimestamp..................................................41
5.4  creatorsName.....................................................41
5.5  dITContentRules..................................................42
5.6  dITStructureRules................................................42
5.7  ldapSyntaxes.....................................................42
5.8  matchingRules....................................................42
5.9  matchingRuleUse..................................................42
5.10 modifiersName....................................................43
5.11 modifyTimestamp..................................................43
5.12 nameForms........................................................43
5.13 namingContexts...................................................43

5.14 objectClasses....................................................44
5.15 subschemaSubentry................................................44
5.16 supportedControl.................................................44
5.17 supportedExtension...............................................45
5.18 supportedLDAPVersion.............................................45
5.19 supportedSASLMechanisms..........................................45

6.  Object Classes....................................................46
6.1  Extensible Object Class..........................................46
6.2  subschema........................................................46

7.  Security Considerations...........................................47
7.1  Disclosure.......................................................47
7.2  Security Information Syntaxes....................................47
7.3  Use of Attribute Values in Security Applications.................47
7.4 Syntaxes....................................28
5.3  Securing the Directory...........................................47 Directory...........................................29

6.  Acknowledgements..................................................29

7.  Authors' Addresses................................................29

8.  Acknowledgements..................................................48  References........................................................30
8.1  Normative........................................................30
8.2  Informative......................................................31

9.  Author's Address..................................................48

10. References........................................................48
10.1  Normative.......................................................48
10.2  Informative.....................................................49

11. Full Copyright Statement..........................................50 Statement..................... .....................31

Annex A  Object Identifiers for Syntaxes..............................51 Syntaxes..............................32
Annex B  Topics to be Addressed in This Document......................52 Document......................33
Annex C  Change Log...................................................53 Log...................................................34

1.  Overview

   This document defines part of the framework for developing schemas
   for directories accessible via the Lightweight Directory Access
   Protocol (LDAP) [Prot]. [Protocol].

   Schema is the collection of attribute type definitions, object class
   definitions and other information which specify the entries and their
   contents that a server holds.  A server uses schema 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.  This document specifies syntaxes, which
   are used in defining attribute types, and matching rules.

   Therefore, Section 2 states the general requirements and notation
   for definition of attribute types, object classes, syntaxes and matching rules.

   Section 3 lists syntaxes, syntaxes and section 4 contains matching rules, section 5
   attribute types, and section 6 object classes. rules.

   Additional documents define schemas for representing real-world
   objects as directory entries.  See [Models], sections 2.4.1 and 2.6
   and [Schema] for the definitions of user objects and attributes from
   [X.501], [X.520], and [X.521].

2.  General Issues

   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 [Keywds]. BCP 14 [RFC2119].

   This document describes the syntaxes of data conveyed in an
   Internet protocol.

   Attribute Type and Object Class definitions are written in a string
   representation of the AttributeTypeDescription and
   ObjectClassDescription data types defined in X.501 [Models].

   Implementors are strongly advised to first read the description of
   how schema is represented in X.500 X.501 [X.501] before reading the rest
   of this document.

2.1  Notation

   For the purposes of defining the rules for describing attribute syntaxes and other schema elements, the following augmented matching rules,
   Augmented Backus-Naur Form (ABNF) definitions will be is used.  They  The ABNF productions
   used in this document are based on used by other documents in the ABNF styles of RFC 2234 [ABNF]. LDAP set
   and are listed in [Models].

   The schema definitions provided in this document are line-wrapped
   for readability.

   The definitions for ALPHA, DIGIT, ldapOID, number, DOT, LDIGIT, and
   HYPHEN

   In addition, the following ABNF productions are given used in the LDAP protocol specification [Prot].

   The definition of OCTET, from [ABNF], is:

      OCTET          =  %x00-FF
                        ; 8 bits of data

      hex-digit = DIGIT / "a" / "b" / "c" / "d" / "e" / "f" /
                 "A" / "B" / "C" / "D" / "E" / "F"

      k = ALPHA / DIGIT / HYPHEN

      octetstring = *OCTET

      p = ALPHA / DIGIT / "'" / "(" / ")" / "+" / "," / HYPHEN / "DOT" /
          "="/ "/" / ":" / "?" / " "

      numericstring = 1*DIGIT

      anhstring = 1*k

      keystring = ALPHA [ anhstring ]

      printablestring = 1*p

      space = 1*" "

      whsp = [ space ]

      utf8 = <any sequence of octets formed this
   document:

2.2  Syntaxes

   This section defines general requirements for LDAP attribute
   syntaxes.  All documents defining attribute syntaxes for use with
   LDAP are expected to conform to these requirements.  Syntaxes are
   also defined for matching rules whose assertion value syntax is
   different from the UTF-8 [UTF-8]
             transformation attribute value syntax.

2.2.1  LDAP-Specific Encodings

   In [Protocol], the encoding of a character from ISO 10646 [UCS]
             except "'">

      dstring = 1*( utf8 / "''" )
                         ; escaped utf8 string, each "'"
                         ; appearing in the value to be encoded LDAP protocol is
                         ; escaped by a preceding "'"

      qdstring = "'" dstring "'"

      qdstringlist = [ qdstring *( space qdstring ) ]

      qdstrings = qdstring / ( "(" whsp qdstringlist whsp ")" ) specified.  The
   protcol encapsulates values of attributes in many places.  In this
   specification, the following ABNF for the string representation encoding of OBJECT
   IDENTIFIERs, 'descr' is the syntactic representation values is specified, as part of an object
   descriptor, which consists
   each syntax definition.  These value encoding rules are termed
   "LDAP-specific encodings".  The LDAP-specific encoding of letters, digits, and hyphens starting
   with a letter.  An OBJECT IDENTIFIER in the numericoid format SHOULD
   NOT have leading zeroes (e.g., "0.9.3" value is permitted but "0.09.3"
   SHOULD NOT be generated).

   When 'oid' elements occur
   what is transmitted in the protocol.

   The LDAP-specific encoding of a value, given attribute syntax always
   produces octet-aligned values.  To the 'descr' notation option
   SHOULD be used in preference to greatest extent possible, the 'numericoid'.  An object
   descriptor is more readable than a numeric OBJECT IDENTIFIER, and
   LDAP-specific encoding of a
   descriptor (where assigned and known by the implementation) SHOULD value is supposed to be used in preference usable for
   display purposes.  In particular, encoding rules for attribute
   syntaxes defining non-binary values are supposed to numeric oids 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 human-readable representation.

2.2.2  Syntaxes Implementation Status

   Clients and servers need not implement all the greatest extent
   possible.  Examples of object descriptors syntaxes listed in LDAP are attribute
   type, object class,
   section 3, and matching rule names.

      oid = descr / numericoid

      descr = keystring

      numericoid = numericstring *( DOT numericstring )

      noidlen = numericoid [ "{" len "}" ]

      len = numericstring

      oids = oid / ( "(" space oidlist space ")" )
             ; set of oids of either form

      oidlist = oid *( space "$" space oid )

      qdescrs = qdescr / ( "(" whsp qdescrlist whsp ")" )
                ;  object descriptors used as schema element names

      qdescrlist = [ qdescr *( whsp qdescr ) ]

      qdescr = "'" descr "'"

      xstring = "X-" 1*( ALPHA / HYPHEN / "_" )

      extensions = *( space xstring space qdstrings )

   Note MAY implement other syntaxes.

   Clients MUST NOT assume that while lines have been folded for readability in the
   definitions of schema elements, (e.g., objectClassDescription
   attribute), the values transferred in protocol would not contain
   newlines.

   In cases where an arbitrary string, not a Distinguished Name or part LDAP-specific encoding of one, is used in a value
   of an attribute, a backslash quoting
   mechanism is used to escape the following separator symbol
   character, (such as, "'", "$" or "#") if it occurs in that
   string.  The backslash unrecognized syntax is followed by a pair of hexadecimal digits
   representing the next character.  A backslash itself in human-readable character string.

   Other documents define additional attribute syntaxes.  However, the string
   which forms part
   definition of a larger syntax is always represented as '\5C'
   or '\5c'.  An example additional arbitrary syntaxes is given in section 3.33, postalAddress syntax.

   Servers are strongly deprecated
   since it will hinder interoperability.  Today's client and server
   implementations generally do not required to provide the same or any text in the
   description part of have the subschema values they maintain.

2.2  Syntaxes

   This section defines general requirements for LDAP attribute value
   syntaxes.  All documents defining attribute syntaxes for use with
   LDAP are expected to conform ability to these requirements.
   Syntaxes are also defined for matching rules whose assertion value
   syntax is different from the attribute value syntax. dynamically
   recognize new syntaxes.

2.2.3  Syntax Object Identifiers

   In an LDAP schema, an a syntax is named by the Object Identifier (OID) is
   assigned to a
   syntax definition when the syntax is named. it.

   Syntaxes that are currently in use in this specification and the user schema specification [User]
   [Schema] and the models specification [Models] are specified in this
   document in
   Section section 3.  The object identifiers for assigned to these
   syntaxes are listed in Annex A, also.

   In X.501 A.

2.2.4  Syntax Description

   The SyntaxDescription ABNF specified in [Models] and X.520 [Attr], is the definition of method used
   in this document to define the values for each syntax.

   For example, the syntax is
   part description of the INTEGER syntax for whole
   number values is:

      ( 1.3.6.1.4.1.1466.115.121.1.27 DESC 'INTEGER' )

2.3  Matching Rules

   The matching rules specified in this document are defined in
   Section 4.

   Matching rules are used by servers to compare attribute specification values
   against assertion values when performing Search and a distinct OID for Compare
   operations.  They are also used to identify the syntax
   is not assigned.  As value to be added
   or deleted when modifying entries, and are used when comparing a result, X.501 does not define
   purported distinguished name with the name of an attribute for
   publishing syntaxes explicitly in a subschema entry.

   In [Prot], the encoding

   Most of the LDAP protocol is specified.  The
   protcol encapsulates values of attributes given in many places.  In this
   specification, the encoding of the values is specified, as part of
   each syntax definition.  These value encoding rules are termed
   "native LDAP encoding".  The native LDAP encoding of a value is what
   is transmitted in the protocol, unless a transfer option has been
   invoked for the value.  The transfer option mechanism and the Binary
   transfer option are defined in [Prot].

   The native LDAP encoding of a given attribute syntax always produces
   octet-aligned values.  To the greatest extent possible, the
   native LDAP encoding of a value user schema [Schema] have an
   equality matching rule defined.

...An OID is supposed to be usable for display
   purposes.  In particular, encoding rules for attribute syntaxes
   defining non-binary values are supposed assigned to produce strings that can
   be displayed with little or no translation by clients implementing
   LDAP.  There are a few cases (e.g., audio) however, matching rule when it is defined.  A
   matching rule definition ought not
   sensible to produce be changed without having a human-readable representation.

2.2.1  Syntaxes new
   OID assigned to it.

2.3.1  Matching Rules Implementation Status

   Clients

   Servers which support matching rules and servers need not the extensibleMatch SHOULD
   implement all the syntaxes listed, and
   MAY implement other syntaxes.

   Clients matching rules in section 4.

   Servers MUST NOT assume that publish in the native LDAP encoding of a value matchingRules attribute, the definitions
   of
   an unrecognized syntax is a human-readable character string.

2.2.2  Syntax Object Identifiers

   Syntaxes for use with LDAP are named matching rules referenced by OBJECT IDENTIFIERs, which
   are dotted-decimal strings.  These are not intended to be displayed
   to users.  Annex A lists values of the syntaxes that have been defined for
   LDAP attributeTypes and
   matchingRuleUse attributes in this document.

   Other documents define additional syntaxes.  However, the
   definition of additional arbitrary syntaxes is strongly deprecated
   since it will hinder interoperability.  Today's client and same subschema entry.  Other
   unreferenced matching rules MAY be published in the matchingRules
   attribute.

   If the server
   implementations generally do not have supports the ability to dynamically
   recognize new syntaxes.  In most cases, attributes will be defined
   with extensibleMatch, then the syntax for directory strings.

   A suggested minimum upper bound on server MAY use
   the number matchingRuleUse attribute to indicate the applicability of characters
   selected matching rules to designated attribute types in a
   value with a string-based syntax, or an
   extensibleMatch.

2.3.2  Matching Rule Description

   The SyntaxDescription ABNF specified in [Models] is the number of bytes method used
   The Matching Rule descriptions are specified according to the
   MatchingRule ABNF specified in a [Models].

3.  Syntaxes

3.1  Attribute Type Description

   A value
   for all other syntaxes, can be indicated by appending in this bound
   count inside of curly braces following the syntax name's OBJECT
   IDENTIFIER in is a definition of an attribute type definition.  See
   according to the "numericoid"
   production in paragraph 2.1.  Such a bound ABNF given [Models].  The LDAP-specific encoding is not part of
   the syntax
   name itself.  For instance, "1.3.6.4.1.1466.0{64}" suggests that
   server implementations would allow a string character codes in UTF-8 which correspond to be 64 the characters
   long, although they can allow longer strings.  Note that a single
   character of in
   the Directory String definition.

   This syntax can be encoded in more than
   one byte since UTF-8 [UTF-8] is the form in which schema attribute types are
   published in the directory in a variable-length encoding.

2.2.3  Syntax Description subentry.  The following ABNF is used in this document to associate a short
   description (e.g., a name) with a syntax OBJECT IDENTIFIER.  The
   productions for whsp, numericoid, qdescrs and qdstring are given in
   paragraph 2.1.  Implementors, note that future versions of
   description gives the OID assigned to this
   document could expand syntax:

      ( 1.3.6.1.4.1.1466.115.121.1.3 DESC 'Attribute Type Description' )

   For example, this is the definition to include additional terms.
   Terms whose identifier begins with "X-" are reserved from [User] of the
   businessCategory attribute type:

   ( 2.5.4.15 NAME 'businessCategory'
     EQUALITY caseIgnoreMatch
     SUBSTR caseIgnoreSubstringsMatch
     SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{128} )

   The syntax type for private
   experiments, and MUST be followed by a <space> and a <qdstrings>
   tokens.

      SyntaxDescription = "(" whsp
          numericoid
          [ space "DESC" space qdstring ]
          extensions
          whsp ")"

   Note that the SyntaxDescription ABNF businessCategory Attribute Type is also the ABNF that defines
   the native LDAP encoding of values Directory
   String.

   This example definition is a value of the LDAP Syntax Attribute Type Description
   syntax.

2.2.4  Example

   For example,  The LDAP-specific encoding of this value is the definition
   itself.

3.2  Bit String

   A value in this syntax descripion is a value of the INTEGER BIT STRING data type from
   ASN.1 [X.680].  The following syntax for whole
   number values is: description gives the OID
   assigned to this syntax:

      ( 1.3.6.1.4.1.1466.115.121.1.27 1.3.6.1.4.1.1466.115.121.1.6 DESC 'INTEGER' 'Bit String' )

2.3  Matching Rules

   The matching rules specified LDAP-specific encoding of a value is the following ABNF:

      bitstring = SQUOTE *binary-digit SQUOTE "B"

      binary-digit = "0" / "1"

   Example:  '0101111101'B

3.3  Boolean

   A value in this document are defined in
   section 4.

      ( 1.3.6.1.4.1.1466.115.121.1.27 DESC 'INTEGER' )

   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 syntax is a value of the BOOLEAN data type from
   ASN.1 [X.680].  That is, there are exactly two values:  one value to be added
   or deleted when modifying entries,
   representing logically true, and are used when comparing a
   purported distinguished name with the name of an entry.

   Most of other representing logically
   false.  The following syntax description gives the attributes given in this document have an equality
   matching rule defined.

...An OID is assigned to a matching rule when it
   this syntax:

      ( 1.3.6.1.4.1.1466.115.121.1.7 DESC 'Boolean' )

      The LDAP-specific encoding of a value is defined. the following ABNF:

      boolean = "TRUE" / "FALSE"

3.4  Country String

   A
   matching rule definition ought not be changed without having value in this syntax is two ASN.1 [X.680] printable string characters
   representing a new country.  The permitted values are as listed in
   ISO 3166 [ISO3166].  The following syntax description gives the OID
   assigned to it.

2.3.1  Matching Rules Implementation Status

   Servers which support matching rules and the extensibleMatch SHOULD
   implement all the matching rules in section 4.

   Servers MUST publish in the matchingRules attribute, the definitions
   of matching rules referenced by values this syntax:

      ( 1.3.6.1.4.1.1466.115.121.1.11 DESC 'Country String' )

   The LDAP-specific encoding of a value is the attributeTypes and
   matchingRuleUse attributes following ABNF:

      CountryString  = ALPHA ALPHA

      Example:  US

3.5  Delivery Method

   A value in this syntax is a set of the same subschema entry.  Other
   unreferenced matching rules MAY be published ASN.1 [X.680] enumerated
   INTEGER values that indicates, in preference order, the matchingRules
   attribute.

   If the server supports the extensibleMatch, then the server MAY use service(s)
   by which the matchingRuleUse attribute to indicate user, represented by the applicability entry, is willing and/or
   capable of
   selected matching rules to designated attribute types in an
   extensibleMatch.

2.3.2  Matching Rule Description

   Matching rule descriptions are written according to the receiving messages.

   The following
   ABNF. syntax description gives the OID assigned to this
   syntax:

      ( 1.3.6.1.4.1.1466.115.121.1.14 DESC 'Delivery Method' )

   The productions for numericoid, qdescrs, qdstring, oid, and
   whsp are given in section 2.1.  Implementors, note that future
   versions LDAP-specific encoding of this document could expand this ABNF to include
   additional terms.  Terms whose identifier begins with "X-" are
   reserved for private experiments, and MUST be followed by a <space>
   and a <qdstrings> tokens.

      MatchingRuleDescription = "(" whsp
         numericoid
         [ space "NAME" space qdescrs ]
         [ space "DESC" space qdstring ]
         [ space "OBSOLETE" ]
         space "SYNTAX" space numericoid
         extensions
         whsp ")"

   The first numericoid value is the identifier of the MatchingRule being
   described.

   Note that the MatchingRuleDescription ABNF following ABNF:

      delivery-value = pdm / ( WSP pdm SP DOLLAR SP delivery-value )

      pdm = "any" / "mhs" / "physical" / "telex" / "teletex" /
                "g3fax" / "g4fax" / "ia5" / "videotex" / "telephone"

   Example:  telephone $ videotex

3.6  Directory String

   A value in this syntax is also the ABNF that
   defines the native LDAP encoding a value of values one of the Matching Rule
   Description syntax.

2.3.3  Example

   For example, in specifying a server which implements TeletexString,
   PrintableString or UniversalString data types from ASN.1 [X.680].
   The minimum length of a privately-
   defined matching rule for performing sound-alike matches on Directory String-valued attributes, the matching rule could be
   written as (1.1.2.3.4.5 String value is an example, the OID of an actual matching
   rule would be different):

      matchingRule:  ( 1.1.2.3.4.5 NAME 'soundAlikeMatch'
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

   This description could be the one included in the subschema entry in character, that
   is, the server.  If this matching rule could string cannot be used with the attributes
   2.5.4.41 and 2.5.4.15, the 'empty'.  The following could be the use syntax description
   present in
   gives the subschema entry:

      matchingRuleUse: ( 1.1.2.3.4.5 APPLIES OID assigned to this syntax:

      ( givenName $ surname ) 1.3.6.1.4.1.1466.115.121.1.15 DESC 'Directory String' )

   A client could then make use
   The LDAP-specific encoding 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 value is "givenName" or "surName".

2.4  Attribute Types

   Attributes represent the characteristics of the real-world object
   which an entry represents. character string itself.

   Note:  The attributes defined in this document
   are given in section 5.

   An OID form of DirectoryString is assigned not indicated in protocol.
   Servers which convert to DAP MUST choose an attribute type when it is defined.  An
   attribute type definition ought not be changed without having a new
   OID assigned to it.

2.4.1  Attribute Types Implementation Status appropriate form.
   Servers MUST publish in the attributeTypes attribute NOT reject values merely because they contain legal
   Unicode characters outside of the same
   subschema entry, the definitions range of attribute types referenced by
   values printable ASCII.

   Servers and clients MUST be prepared to receive arbitrary Unicode
   characters, including characters not presently assigned to any
   character set.

   Example:
      This is a string of DirectoryString containing #!%#@.

   For characters in the objectClasses, nameForms, matchingRuleUse and
   dITContentRules attributes, and attribute types referenced by PrintableString form, the
   SUP field value in values of the attributeTypes attribute native
   LDAP encoding is the value itself.  Other
   unreferenced attribute types MAY be published in

   If the attributeTypes
   attribute.

   Schema developers MUST NOT create attribute type definitions whose
   names conflict with attribute types defined for use with LDAP string is in
   existing standards-track RFCs.  See the registry of names of
   attribute types maintained by IANA [Consid].

   All LDAP server implementations MUST recognize TeletexString form, then the attribute types
   defined characters are
   transliterated to their equivalents in section 5.

   Servers MUST maintain values of these attributes UniversalString, and encoded
   in accordance with UTF-8 [RFC2044].

   If the definitions string is in X.501(93):  createTimestamp, modifyTimestamp,
   creatorsName, modifiersName, subschemaSubentry, attributeTypes,
   objectClasses, matchingRules, and matchingRuleUse. the UniversalString or BMPString forms [ISO10646],
   UTF-8 is the LDAP-specific encoding.

3.7  DIT Content Rule Description

   The createTimestamp and creatorsName attributes SHOULD appear following syntax description gives the OID assigned to this
   syntax:

      ( 1.3.6.1.4.1.1466.115.121.1.16 DESC 'DIT Content Rule
         Description' )

   This syntax is the form in entries which were created using schema content rules are published
   in the Add operation.

   The modifyTimestamp and modifiersName attributes SHOULD appear directory in
   entries which have been modified using LDAP update operations.

   The subschemaSubentry attribute SHOULD appear a subentry.

   A value in all entries.

   Servers MUST recognize these attribute type names, but it this syntax is not
   required that a server provide values for these attributes, when the
   attribute corresponds to a feature which the server does not
   implement:  namingContexts, altServer, supportedExtension,
   supportedControl, supportedSASLMechanisms, and supportedLDAPVersion.

   Servers MAY use the ldapSyntaxes attribute to list the syntaxes
   which are implemented.

   All servers SHOULD recognize these attribute type names, although
   typically only X.500 servers will implement their functionality:
   dITStructureRules, nameForms, and ditContentRules.

   For the status of user schema attribute types, see Section 3 definition of [User].

2.4.2  Attribute Type Description

   Attribute types are expressed a DIT content rule
   according to the following ABNF.
   The productions for whsp, numericoid, qdescrs, qdstring, space,
   oid, and noidlen are given ABNF in paragraph 2.1.  Implementors,
   note that future versions [Models].

   The native LDAP encoding of this document could expand this ABNF to
   include additional terms.  Terms which begin with the characters
   "X-" are reserved for private experiments, and MUST be followed by a
   <space> and a <qdstrings> tokens.

      AttributeTypeDescription = "(" whsp
         numericoid
         [ space "NAME" qdescrs ]
         [ space "DESC" qdstring ]
         [ space "OBSOLETE" ]
         [ space "SUP" space oid ]
         [ space "EQUALITY" space oid ]
         [ space "ORDERING" space oid ]
         [ space "SUBSTR" space oid ]
         [ space "SYNTAX" space noidlen ]
         [ space "SINGLE-VALUE" ]
         [ space "COLLECTIVE" ]
         [ space "NO-USER-MODIFICATION" ]
         [ space "USAGE" space AttributeUsage ]
         extensions
         whsp ")"

   The numericoid value is the identifier of the AttributeType being
   described.

   The NAME character string
   (DirectoryString) itself.

   Note:  The form of DirectoryString is not indicated in protocol,
   unless the string registered with IANA [Consid] and ;binary option is used (see [Prot]).  Servers which
   convert to identify DAP MUST choose an appropriate form.  Servers MUST NOT
   reject values and value assertions merely because they contain legal Unicode characters
   outside of the attribute described.

   The SUP oid range of printable ASCII.

   Servers and clients MUST be prepared to receive arbitrary Unicode
   characters, including characters not presently assigned to any
   character set.

   Example:
      This is an identifier a string of DirectoryString containing #!%#@.

   For characters in the Attribute Type from which PrintableString form, the
   attribute described is derived (i.e., a subtype).

   The EQUALITY, ORDERING, AND SUBSTR oids name value in the Matching Rules for native
   LDAP encoding is the attribute being defined.

   See section 2.3 for the SYNTAX noidlen explanation.

   The default setting is "multi-valued" when SINGLE-VALUE is absent.

   The default setting is "not collective" when COLLECTIVE is absent.

   The default setting is "user modifiable" when NO-USER-MODIFICATION value itself.

   If it is absent.

   The default setting in the TeletexString form, then the characters are
   transliterated to their equivalents in UniversalString, and encoded
   in UTF-8 [UTF-8].

   If it is "userApplication" when USAGE in the UniversalString or BMPString forms [ISO10646], UTF-8
   is absent.

   Servers SHOULD provide at least one of the "SUP" and "SYNTAX" fields
   for each AttributeTypeDescription.

   An AttributeDescription (i.e., native LDAP encoding.

3.8  DIT Structure Rule Description

   The following syntax description gives the means of referring OID assigned to an attribute
   in this
   syntax:

      ( 1.3.6.1.4.1.1466.115.121.1.17 DESC 'DIT Structure Rule
         Description' )

   This syntax is the protocol [Prot]) can be used as form in which schema structure rules are published
   in the directory in a subentry.

   A value in the DIT Structure Rule Description syntax is a NAME part definition
   of
   an AttributeTypeDescription.  Note that these are case insensitive.

   Note that the AttributeTypeDescription does not list a schema Structure Rule according to the matching
   rules which can be used with that attribute type ABNF in an
   extensibleMatch search filter.  This [Models].

   The LDAP-specific encoding is done using the
   matchingRuleUseDescription described character codes in section 3.24.

   This document refines UTF-8 [UTF-8]
   which correspond to the schema description of X.501 [Models] by
   requiring that characters in the syntax field structure rule definition.

3.9  DN

   A value in an AttributeTypeDescription be a
   string representation of an OBJECT IDENTIFIER for the LDAP string Distinguished Name syntax definition, and is a possible indication structured set of the maximum length
   ASN.1 [X.680] data types that are included in the DirectoryString
   syntax.  The following syntax description gives the OID assigned to
   this syntax:

      ( 1.3.6.1.4.1.1466.115.121.1.12 DESC 'DN' )

   The LDAP-specific encoding of a value of this attribute (defined is defined in section 2.2.2). [LDAPDN].  Note
   that the AttributeTypeDescription ABNF LDAP-specific encoding is also the ABNF that
   defines not reversible to the Attribute Type Description syntax.

2.4.3  Example

   For example, it would be useful original BER
   encoding used in X.500 for Distinguished Names, as the directory to know when CHOICE of any
   DirectoryString element in an
   entry was put into the directory.  The following definition RDN is an
   Attribute Type Description that could be used to specify such
   an attribute.

      ( 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 SYNTAX oid indicates not evident in the Generalized Time syntax.

2.5  Object Classes

   Object classes are used to categorize LDAP-specific
   encoding..  See the kinds of entries stored note in
   the directory section 3.7.

   Examples (from [LDAPDN]):

      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 to determine what attributes are contained Runn,C=GB

      CN=Before\0DAfter,O=Test,C=GB
      1.1.3.6.1.4.1.1466.0=#04024869,O=Test,C=GB

      SN=Lu\C4\8Di\C4\87

3.10  Enhanced Guide

   A value in
   those entries.

   In general, every entry the Enhanced Guide syntax is defined in terms of an abstract class
   ("top"), at least one structural object class, the matching criteria and zero or more
   auxiliary object classes.

   Whether
   scope of operation in an object class is abstract, structural, or auxiliary is
   defined when Enhanced Filter.

   The following syntax description gives the object class OID is assigned.  An object class
   definition ought not be changed without having a new identifier assigned to it.

2.5.1  Object Classes Implementation Status

   Servers SHOULD implement the subschema object class.

   Implementing the extensibleObject object class is OPTIONAL.

   Servers MUST publish in the objectClasses attribute of the same
   subschema entry, the definitions of object classes referenced by
   values of the nameForms and dITContentRules attributes, and object
   classes referenced by the SUP field in values this syntax:

      ( 1.3.6.1.4.1.1466.115.121.1.21 DESC 'Enhanced Guide' )

   The LDAP-specific encoding of the objectClasses
   attribute itself.  Other unreferenced object classes MAY be
   published in the objectClasses attribute.

   Schema developers MUST NOT create object class definitions whose
   names conflict with object classes a value is defined for use with LDAP in
   existing standards-track RFCs.  See the registry of names of Object
   Classes maintained by IANA [Consid].

2.5.2  Object Class Description

   Object class descriptions are written according to the
   following
   ABNF.  The productions for whsp, numericoid, qdescrs, qdstring,
   space, and oids are given in section 2.1.  Implementors, note that
   future versions of this document could expand this definition to
   include additional terms.  Terms whose identifier begins with
   "X-" are reserved for private experiments, and MUST be followed by a
   <space> and a <qdstrings> tokens.

      ObjectClassDescription ABNF:

      EnhancedGuide = "(" whsp
         numericoid
         [ space "NAME" space qdescrs ]
         [ space "DESC" space qdstring ]
         [ space "OBSOLETE" ]
         [ space "SUP" space oids ]
         [ space ( "ABSTRACT" SP oid WSP SHARP WSP criteria WSP SHARP
                      WSP subset

      subset = "baseobject" / "oneLevel" / "STRUCTURAL" "wholeSubtree"

      criteria = or-term / "AUXILIARY" LPAREN or-term RPAREN

      or-term = and-term *( "|" and-term ) ]
         [ space "MUST" space oids ]
         [ space "MAY" space oids ]

      and-term = not-term *( "&" not-term )

      not-term = "!" not-term /
                 attributetype DOLLAR match-type /
                 LPAREN or-term RPAREN /
                 "?true" / ; AttributeTypes
         extensions
         whsp ")"

   The numericoid is the identifier of the ObjectClass being described.
                 "?false"

      match-type = "EQ" / "SUBSTR" / "GE" / "LE" / "APPROX"

   The NAME string is the string registered with IANA [Consid] and used
   to identify instances of ?true term alternative represents an empty "and" in the ObjectClass described. Criteria.
   The SUP oids are ?false alternative represents an empty "or" in the identifiers of Criteria.

   Example:

      person#(sn)#oneLevel

3.11  Facsimile Telephone Number

   A value in the Object Classes which are Facsimile Telephone Number syntax is a subscriber
   number on the
   superclasses (object classes) (public) telephone network of the Object Class defined. a facsimile device.  The default setting
   telephone number is "structural" when ABSTRACT, STRUCTURAL, and
   AUXILIARY are absent. a character string based on E.123 [E.123].  The MUST oids identify the Attribute Types that are required to have
   values in every instance of
   character string type is the Object Class. PrintableString data type from
   ASN.1 [X.680].  The MAY oids identify Attribute Types that can appear, as
   appropriate, in an instance of following syntax description gives the Object Class.

2.5.3  Example

   For example, information about an employee with respect OID
   assigned to their
   job this syntax:

      ( 1.3.6.1.4.1.1466.115.121.1.22 DESC 'Facsimile Telephone Number')
   The LDAP-specific encoding of a value is useful defined by the
   following ABNF:

      fax-number = printablestring [ "$" faxparameters ]
                   ; telephone number, possibly followed by facsimile
                   ; parameters

      printablestring = 1*p

      p = ALPHA / DIGIT / SQUOTE / LPAREN / RPAREN / PLUS / COMMA /
          HYPHEN / DOT / EQUALS / SLASH / COLON / QUESTION / SPACE

      faxparameters = faxparm / ( faxparm "$" faxparameters )

      faxparm = "twoDimensional" / "fineResolution" / "unlimitedLength"
         / "b4Length" / "a3Width" / "b4Width" / "uncompressed"

3.12  Fax

   A value in the Fax syntax is an application image which queries is produced using the directory.  The
   same pieces of information are needed in several kinds of entries,
   Group 3 facsimile process [Fax] to duplicate an object, such as manager, part-time, and exempt employees.  An auxiliary
   object class could be developed to be included in the structural
   object classes that represent the different kinds of employees.  The
   pieces of information could be:  name of the last training course
   attended, how many courses has the employee taken, category of
   training program.  The types of information could be named the
   lastCourse, coursesCount, program attributes, respectively.
   a memo.

   The following could be the syntax description of an auxiliary object class that
   provides for inclusion of gives the training information in different
   kinds of entries.  (The OID is artificial.)

      ( 1.1.3.170.2.65 NAME 'trainingInfo'
          AUXILIARY
          MUST program
          MAY assigned to this
   syntax:

      ( lastCourse $ coursesCount ) 1.3.6.1.4.1.1466.115.121.1.23 DESC 'Fax' )

3.  Syntaxes

3.1  Attribute Type Description

   A value

   Values in this syntax is a definition of an attribute type
   according to the ABNF given in paragraph 2.4.2.  The native LDAP
   encoding is the character codes are expressed as octet strings containing
   Group 3 Fax images as defined in UTF-8 which correspond to the
   characters [Fax].

3.13  Generalized Time

   A value in the definition.

   This Generalized Time syntax is the form in which schema attribute types are
   published in the directory in a subentry. date and time.  The year
   is given as a four-digit number.  The following syntax description
   gives the OID assigned to this syntax:

      ( 1.3.6.1.4.1.1466.115.121.1.3 1.3.6.1.4.1.1466.115.121.1.24 DESC 'Attribute Type Description' 'Generalized Time' )

   For example, this

   The LDAP-specific encoding is a value of the definition GeneralizedTime data type
   from [User] of ASN.1 [X.680].  Time zone MUST be present and SHOULD be GMT (Z).

   Example:
      199412161032Z means 10:32 a.m. Dec. 16, 1994 in the
   businessCategory attribute type: Greenwich
      Mean Time time zone.

3.14  Guide

   A value in the Guide syntax is the matching criteria in a Filter.

   The following syntax description gives the OID assigned to this
   syntax:

      ( 2.5.4.15 NAME 'businessCategory'
     EQUALITY caseIgnoreMatch
     SUBSTR caseIgnoreSubstringsMatch
     SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{128} 1.3.6.1.4.1.1466.115.121.1.25 DESC 'Guide' )
   The Guide syntax type for the businessCategory Attribute Type is Directory
   String.

   This example definition not intended to be used for defining new
   attributes.  It is a value important for backwards compatibility with LDAP
   systems that implement an earlier version of the Attribute Type Description
   syntax.  The native LDAP [RFC1778].

   The LDAP-specific encoding of this a value is defined by the definition
   itself.

3.2  Bit
   following ABNF:

      guide-value = [ object-class "#" ] criteria

      object-class = SP oid

   The criteria production is defined in the Enhanced Guide syntax in
   section 3.11.

3.15  IA5 String

   A value in this the IA5 String syntax is a value of the BIT STRING IA5String data
   type from ASN.1 [ASN1]. [X.680].  International Alphabet 5 (IA5) [IA5] is the
   international version of the ASCII character set.

   The following syntax description gives the OID assigned to this
   syntax:

      ( 1.3.6.1.4.1.1466.115.121.1.6 1.3.6.1.4.1.1466.115.121.1.27 DESC 'Bit 'IA5 String' )

   The native LDAP LDAP-specific encoding of a value in this syntax is the following ABNF:

      bitstring = "'" *binary-digit "'B"

      binary-digit = "0" / "1"

   Example:  '0101111101'B

3.3  Boolean character
   string value itself.

3.16  Integer

   A value in this the INTEGER syntax is a value of whole number as specified in the BOOLEAN
   INTEGER data type from ASN.1 [ASN1].  That is, there are exactly two values:  one value
   representing logically true, and the other representing logically
   false. [X.680].

   The following syntax description gives the OID assigned to this
   syntax:

      ( 1.3.6.1.4.1.1466.115.121.1.7 1.3.6.1.4.1.1466.115.121.1.27 DESC 'Boolean' 'INTEGER' )

   The native LDAP LDAP-specific encoding of a value is the following ABNF:

      boolean = "TRUE" / "FALSE"

3.4  Country String decimal representation of
   the value, with each decimal digit represented by the its character
   equivalent.  So, the number 1321 is represented by the character
   string "1321".

3.17  JPEG

   A value in this the JPEG syntax is two ASN.1 printable string characters
   representing a country.  The permitted values are as listed in
   ISO 3166 [Codes]. an image produced according to
   specific rules for light values.  The following syntax description
   gives the OID assigned to this syntax:

      ( 1.3.6.1.4.1.1466.115.121.1.11 1.3.6.1.4.1.1466.115.121.1.28 DESC 'Country String' 'JPEG' )

   The native LDAP LDAP-specific encoding of a value is an octet string of the following ABNF:

      CountryString  = p p

   The production for p is given in section 2.1.

      Example:  US

3.5  Delivery Method
   light values representing the image.

3.18  LDAP Syntax Description

   A value in this the LDAP Syntax Description syntax is a set definition of a
   LDAP syntax description according to the ASN.1 enumerated INTEGER
   values that indicates, ABNF given in preference order, [MODELS].

   This syntax is the service(s) by form in which schema syntax descriptions are
   published in the user, represented by the entry, is willing and/or capable of
   receiving messages. directory in a subentry.  The following syntax
   description gives the OID assigned to this syntax:

      ( 1.3.6.1.4.1.1466.115.121.1.14 1.3.6.1.4.1.1466.115.121.1.54 DESC 'Delivery Method' 'LDAP Syntax Description' )

   Note that, in X.520 [Attr], syntaxes are not labeled distinctly
   with respect to attributes.

   The native LDAP LDAP-specific encoding of a value is the following ABNF:

      delivery-value = pdm / ( whsp pdm space "$" space delivery-value )

      pdm = "any" / "mhs" / "physical" / "telex" / "teletex" /
                "g3fax" / "g4fax" / "ia5" / "videotex" / "telephone"
   The production for space is given character codes in section 2.1.

   Example:  telephone $ videotex

3.6  Directory String UTF-8 [ISO10646]
   which correspond to the characters in the definition.

3.19  Matching Rule Description

   A value in this the Matching Rule Description syntax is a value of one definition of
   a matching rule according to the TeletexString,
   PrintableString or UniversalString data types from ASN.1 [ASN1].  The
   minimum length of a Directory String value ABNF given in [MODELS].  This syntax
   is one character, that
   is, the string cannot be 'empty'. form in which schema matching rules are published in the
   directory in a subentry.  The following syntax description definition gives the
   OID assigned to this syntax:

      ( 1.3.6.1.4.1.1466.115.121.1.15 1.3.6.1.4.1.1466.115.121.1.31 DESC 'Directory String' 'Matching Rule Description' )

   The native LDAP LDAP-specific encoding of a value is the character string itself.

   Note:  The form of DirectoryString is not indicated codes in protocol,
   unless the ;binary option is used (see [Prot]).  Servers UTF-8 [ISO10646]
   which
   convert correspond to DAP MUST choose an appropriate form.  Servers MUST NOT
   reject values merely because they contain legal Unicode the characters
   outside in the definition of a Matching
   Rule.

3.20  Matching Rule Use Description

   A value in the range Matching Rule Use Description syntax is a definition
   of printable ASCII.

   Servers a matching Rule and clients MUST the attribute types with which the rule could
   be prepared used in an extensibleMatch search filter.  The values are
   specified according to receive arbitrary Unicode
   characters, including characters not presently the ABNF given in [MODELS].  The following
   syntax description gives the OID assigned to any
   character set.

   Example: this syntax:

      ( 1.3.6.1.4.1.1466.115.121.1.31 DESC 'Matching Rule Use
         Description' )

   This syntax is a string of DirectoryString containing #!%#@.

   For characters in the PrintableString form, the value form in which schema matching rule usage
   permissions are published in the native
   LDAP directory in a subentry.

   The LDAP-specific encoding is the value itself.

   If it is character codes in the TeletexString form, then UTF-8 [ISO10646]
   which correspond to the characters are
   transliterated to their equivalents in UniversalString, and encoded the definition.

3.21  MHS OR Address

   A value in UTF-8 [UTF-8].

   If it the MHS OR Address syntax is in the UniversalString or BMPString forms [UCS], UTF-8 is
   the native LDAP encoding.

3.7  DIT Content Rule Description

   A value in this syntax is a definition addressing information of
   a DIT content rule
   according to the following ABNF:

      DITContentRuleDescription = "(" whsp
         numericoid
         [ space "NAME" space qdescrs ]
         [ space "DESC" space qdstring ]
         [ space "OBSOLETE" ]
         [ space "AUX" space oids ]
         [ space "MUST" space oids ]
         [ space "MAY" space oids ]
         [ space "NOT" space oids ]
         extensions
         whsp ")"

   The numericoid is the identifier of the Structural Object Class to
   which the Content Rule being described applies.

   The MUST oids identify Attribute Types, besides those in the
   Structural Object Class, that must have values in every instance user of
   the Object Class.

...The MAY oids identify Attribute Types, besides those in the
   Structural and Auxiliary Object Classes, that are permitted to have
   values in an instance of the Structural Object Class. X.400 messaging service.  The NOT oids identify Attribute Types, which occur in the Structural
   and Auxiliary Object Classes, that are prohibited from having values LDAP-specific encoding is
   defined in an instance of the Structural Object Class. RFC 1327 [RFC1327].

   The AUX oids identify following syntax description gives the Auxiliary Object Classes which can be
   added OID assigned to instances of the Structural Object Class.

   The productions for whsp, numericoid, qdescrs, qdstring, space this
   syntax:

      ( 1.3.6.1.4.1.1466.115.121.1.33 DESC 'MHS OR Address' )

3.22  Name and
   oids are given in section 2.1.  Implementors, note that future
   versions Optional UID

   A value of this document could expand this ABNF to include
   additional terms.  Terms which begin with the characters "X-" are
   reserved for private experiments, and MUST be followed by a <space> Name and a <qdstrings> tokens.

   This Optional UID (Unique IDentifier) syntax is the form in which schema content rules are published
   in the directory a
   Distinguished Name as defined in section 3.9 plus a subentry. bit string
   that differentiates the value from otherwise identical names.     The following syntax description gives the OID assigned to this
   syntax:

      ( 1.3.6.1.4.1.1466.115.121.1.16 1.3.6.1.4.1.1466.115.121.1.34 DESC 'DIT Content Rule
         Description' 'Name And Optional UID' )

3.8  DIT Structure Rule Description

   A value in the DIT Structure Rule Description syntax is a definition

   The LDAP-specific encoding of a schema Structure Rule according to value is the following ABNF:

      DITStructureRuleDescription

      NameAndOptionalUID = "(" whsp
         ruleidentifier
         [ space "NAME" space qdescrs ]
         [ space "DESC" space qdstring ]
         [ space "OBSOLETE" ]
         space "FORM" space oid DistinguishedName [ space "SUP" ruleidentifiers "#" bitstring ]
         extensions
         whsp ")"
   The ruleidentifier is an integer which distinguishes one Structure
   Rule from

   Although the others used '#' character could occur in the same LDAP server.

   The FORM oid identifies the a string representation of
   a distinguished name, no additional special quoting is done.

   Example:
      1.3.6.1.4.1.1466.0=#04024869,O=Test,C=GB#'0101'B

3.23  Name Form that specifies the naming
   attribute(s) used at the point Description

   A value in the DIT Name Form Description syntax is a definition of a
   Name Form according to which the Structure
   Rule applies.

   The SUP ruleidentifiers indicate ABNF given in [MODELS].

   A value indicates the Structure Rules one or more attributes in an entry type (e.g.,
   person, device) that can be
   applied immediately ahead of are used as the subject Structure Rule in Relative Distinguished Name of
   the DIT.
   That is, entrY.

   This syntax is the RDN forms which can be one level higher form in the DIT.

      ruleidentifier = numericstring

      ruleidentifiers = ruleidentifier / "(" whsp ruleidentifierlist
         whsp ")"

      ruleidentifierlist = [ ruleidentifier *( space ruleidentifier ) ]

   The productions for whsp, numericstring, qdescrs, qdstring, space,
   and oid which schema name forms are given published in paragraph 2.1.
   the directory.  The native LDAP LDAP-specific encoding of a value is the
   character codes in UTF-8 [UTF-8] [ISO10646] which correspond to the
   characters in the structure rule definition.

   This syntax is the form in which schema structure rules are
   published in the directory in a subentry.

   The following syntax description gives the OID assigned to this
   syntax:

      ( 1.3.6.1.4.1.1466.115.121.1.17 1.3.6.1.4.1.1466.115.121.1.35 DESC 'DIT Structure Rule 'Name Form Description' )

3.9  DN

3.24  Numeric String

   A value in the Distinguished Name Numeric String syntax is a structured set series of the
   ASN.1 data types that are included numerals and
   spaces as specified in the DirectoryString syntax. NumericString data type from
   ASN.1 [X.680].  The following syntax description gives string states the OID assigned to
   this syntax:

      ( 1.3.6.1.4.1.1466.115.121.1.12 1.3.6.1.4.1.1466.115.121.1.36 DESC 'DN' 'Numeric String' )
   The native LDAP encoding representation of a value is defined string in [DN String].  Note
   that the native LDAP encoding this syntax is not reversible to the original BER
   encoding used in X.500 for Distinguished Names, as the CHOICE of any
   DirectoryString element in an RDN is not evident in the native LDAP
   encoding..  See the note in section 3.10.

   Examples (from [DN String]):

      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.1.3.6.1.4.1.1466.0=#04024869,O=Test,C=GB

      SN=Lu\C4\8Di\C4\87

3.10  Enhanced Guide

   A value in the Enhanced Guide syntax is the matching criteria and
   scope of operation in an Enhanced Filter.

   The native LDAP encoding of a string value is the following ABNF:

      EnhancedGuide = space oid whsp "#" whsp criteria whsp "#"
                      whsp subset

      subset = "baseobject" / "oneLevel" / "wholeSubtree"

      criteria = or-term / "(" or-term ")"

      or-term = and-term *( "|" and-term )

      and-term = not-term *( "&" not-term )

      not-term = "!" not-term /
                 attributetype "$" match-type /
                 "(" or-term ")" /
                 "?true" / ;
                 "?false"

   The ?true term alternative represents an empty "and" in the Criteria
   ASN.1 type.  The ?false alternative represents an empty "or" in the
   Criteria ASN.1 type.

      match-type = "EQ" / "SUBSTR" / "GE" / "LE" / "APPROX"

   The following syntax description gives the OID assigned to this syntax:

      ( 1.3.6.1.4.1.1466.115.121.1.21 DESC 'Enhanced Guide' )
   itself.

   Example:

      person#(sn)#oneLevel

3.11  Facsimile Telephone Number  1997

3.25  Object Class Description

   A value in the Facsimile Telephone Number this syntax is a subscriber
   number on character string which expresses the (public) telephone network of a facsimile device.  The
   native LDAP encoding
   definition of a value is an object class according to the following ABNF:

      fax-number = printablestring [ "$" faxparameters ]
                   ; telephone number, possibly followed by facsimile
                     parameters

      faxparameters = faxparm / ( faxparm "$" faxparameters )

      faxparm = "twoDimensional" / "fineResolution" / "unlimitedLength"
         / "b4Length" / "a3Width" / "b4Width" / "uncompressed"

   The production for printablestring is ABNF given in section 2.1.

   The telephone number is based on E.123 [Tel #].

   A printablestring is the PrintableString data type from ASN.1
   [ASN1].  The following syntax description gives the OID assigned
   to this syntax:

      ( 1.3.6.1.4.1.1466.115.121.1.22 DESC 'Facsimile Telephone Number')

3.12  Fax

   A value in the Fax syntax is an image which is produced using the
   Group 3 facsimile process [Fax] to duplicate an object, such as
   a memo.

   The following syntax description gives the OID assigned to this
   syntax:

      ( 1.3.6.1.4.1.1466.115.121.1.23 DESC 'Fax' )

   Values in this syntax are expressed as octet strings containing
   Group 3 Fax images as defined in [Fax].

3.13  Generalized Time

   A value in the Generalized Time syntax is a date and time.  The year
   is given as a four-digit number.

   The native LDAP encoding is a value of the GeneralizedTime data type
   from ASN.1 [ASN1].  Time zone MUST be present and SHOULD be GMT (Z).

   The following syntax description gives the OID assigned to this
   syntax:

      ( 1.3.6.1.4.1.1466.115.121.1.24 DESC 'Generalized Time' )

   Example:
      199412161032Z means 10:32 a.m. Dec. 16, 1994 in the Greenwich
      Mean Time time zone.

3.14  Guide

   A value in the Guide syntax is the matching criteria in a Filter.

   The following syntax description gives the OID assigned to this
   syntax:

      ( 1.3.6.1.4.1.1466.115.121.1.25 DESC 'Guide' )

   The Guide
   [MODELS].  This syntax is not intended to be used for defining new
   attributes.  It is important for backwards compatibility with LDAP
   systems that implement an earlier version of LDAP [LDAP '95].

   The native LDAP encoding of a value is defined by the following ABNF:

      guide-value = [ object-class "#" ] criteria

      object-class = space oid

   The criteria production is defined in the Enhanced Guide syntax in
   section 3.14.  The productions for oid and space are in section 2.1.

3.15  IA5 String

   A value in the IA5 String syntax is a value of the IA5String data
   type from ASN.1 [ASN1].  International Alphabet 5 (IA5) [IA5] is the
   international version of the ASCII character set.

   The following syntax description gives the OID assigned to this
   syntax:

      ( 1.3.6.1.4.1.1466.115.121.1.26 DESC 'IA5 String' )

   The native LDAP encoding of a value in this syntax is the character
   string value itself.

3.16  Integer

   A value in the INTEGER syntax is a whole number as specified in the
   INTEGER data type from ASN.1 [ASN1].

   The following syntax description gives the OID assigned to this
   syntax:

      ( 1.3.6.1.4.1.1466.115.121.1.27 DESC 'INTEGER' )

   The native LDAP encoding of a value is the decimal representation of
   the value, with each decimal digit represented by the its character
   equivalent.  So, the number 1321 is represented by the character
   string "1321".

3.17  JPEG

   A value in the JPEG syntax is an image produced according to
   specific rules for light values.  The native LDAP encoding of a
   value is strings containing JPEG images in the JPEG File Interchange
   Format (JFIF), as described in [JPEG].

   The following syntax description gives the OID assigned to this
   syntax:

      ( 1.3.6.1.4.1.1466.115.121.1.28 DESC 'JPEG' )

3.18  LDAP Syntax Description

   A value in the LDAP Syntax Description syntax is a definition of a
   LDAP syntax description according to the ABNF given in section 2.2.3.

   The native LDAP encoding is the character codes in UTF-8 [UTF-8]
   which correspond to the characters in the definition.

   This syntax is the form in which schema syntax descriptions are
   published in the directory in a subentry.  The following syntax
   description gives the OID assigned to this syntax:

      ( 1.3.6.1.4.1.1466.115.121.1.54 DESC 'LDAP Syntax Description' )

   Note that, in X.520 [Attr], syntaxes are not labeled distinctly
   with respect to attributes.

3.19  Matching Rule Description

   A value in the Matching Rule Description syntax is a definition of
   a matching rule according to the ABNF given in section 2.3.2.  The
   native LDAP encoding is the character codes in UTF-8 [UTF-8] which
   correspond to the characters in the definition of a Matching Rule.
   This syntax is the form in which schema matching rules are published
   in the directory in a subentry.  The following syntax definition
   gives the OID assigned to this syntax:

      ( 1.3.6.1.4.1.1466.115.121.1.31 DESC 'Matching Rule Description' )

3.20  Matching Rule Use Description

   A value in the Matching Rule Use Description syntax is a definition
   of a matching Rule and the attribute types with which the rule could
   be used in an extensibleMatch search filter according to the
   following ABNF:

      MatchingRuleUseDescription = "(" whsp
         numericoid
         [ space "NAME" space qdescrs ]
         [ space "DESC" space qdstring ]
         [ space "OBSOLETE" ]
         space "APPLIES" space oids    ;  AttributeType identifiers
         extensions
         whsp ")"

   The numericoid identifies the Matching Rule for which the usage is
   specified.

   The APPLIES oids identify the Attribute Types for which the Matching
   Rule can be used.

   The productions for whsp, numericoid, qdescrs, qdstring, space, and
   oids are given in paragraph 2.1.  Implementors, note that
   future versions of this document could expand this ABNF to include
   additional terms.  Terms whose identifier begins with "X-" are
   reserved for private experiments, and MUST be followed by a <space>
   and a <qdstrings> tokens.

   The native LDAP encoding is the character codes in UTF-8 [UTF-8]
   which correspond to the characters in the definition.

   The following syntax description gives the OID assigned to this
   syntax:

      ( 1.3.6.1.4.1.1466.115.121.1.31 DESC 'Matching Rule Use
         Description' )

   This syntax is the form in which schema matching rule usage
   permissions are published in the directory in a subentry.

3.21  MHS OR Address

   A value in the MHS OR Address syntax is the addressing information of
   a user of an X.400 messaging service.  The native LDAP encoding is
   defined in RFC 1327 [Map].

   The following syntax description gives the OID assigned to this
   syntax:

      ( 1.3.6.1.4.1.1466.115.121.1.33 DESC 'MHS OR Address' )

3.22  Name and Optional UID

   A value of the Name and Optional UID (Unique IDentifier) syntax is a
   Distinguished Name as defined in section 3.13 plus a bit string
   that differentiates the value from otherwise identical names.

   The native LDAP encoding of a value is the following ABNF:

      NameAndOptionalUID = DistinguishedName [ "#" bitstring ]
   The bitstring production is defined in section 3.3.

   Although the '#' character could occur in a string representation of
   a distinguished name, no additional special quoting is done.

   Example:
      1.3.6.1.4.1.1466.0=#04024869,O=Test,C=GB#'0101'B

   The following syntax description gives the OID assigned to this
   syntax:

      ( 1.3.6.1.4.1.1466.115.121.1.34 DESC 'Name And Optional UID' )

3.23  Name Form Description

   A value in the Name Form Description syntax is a definition of a
   Name Form according to the following ABNF:

      NameFormDescription = "(" whsp
         numericoid
         [ space "NAME" space qdescrs ]
         [ space "DESC" space qdstring ]
         [ space "OBSOLETE" ]
         space "OC" space oid
         space "MUST" space oids           ; AttributeTypes
         [ space "MAY" space oids ]        ; AttributeTypes
         extentions
         whsp ")"

   The numericoid identifies the Name Form being described.

   The OC oid identifies the Structural Object Class for instances of
   which the Name Form specifies the naming attributes (i.e., the RDN).

   The MUST oids identify the Attribute Types that are required to have
   a distinguished value in the RDN for a directory entry.

   The MAY oids identify Attribute Types that are optional in the RDN.

   The productions for whsp, numericoid, qdescrs, qdstring, oid, and
   oids are given in section 2.1.  Implementors, note that future
   versions of this document could have expanded this ABNF to include
   additional terms.

   A value indicates the one or more attributes in an entry type (e.g.,
   person, device) that are used as the Relative Distinguished Name of
   the entries.

   This syntax is the form in which schema name forms are published in
   the directory.  The native LDAP encoding of a value is the character
   codes in UTF-8 [UTF-8] which correspond to the characters in the
   definition.

   The following syntax description gives the OID assigned to this
   syntax:

      ( 1.3.6.1.4.1.1466.115.121.1.35 DESC 'Name Form Description' )

3.24  Numeric String

   A value in the Numeric String syntax is a series of numerals and
   spaces as specified in the NumericString data type from
   ASN.1 [ASN1].  The following string states the OID assigned to
   this syntax:

      ( 1.3.6.1.4.1.1466.115.121.1.36 DESC 'Numeric String' )

   The representation of a string in this syntax is the string value
   itself.

   Example:  1997

3.25  Object Class Description

   A value in this syntax is a character string which expresses the
   definition of an object class according to the ABNF given in
   section 2.5.2.  This syntax is the form in which schema object
   classes are published in the directory in a subentry.  The following
   string states the OID assigned to this syntax:

      ( 1.3.6.1.4.1.1466.115.121.1.37 DESC 'Object Class Description' )

   For example, the character string below specifies the country object
   class, which requires the c (country name) attribute and allows the
   searchGuide and description attributes.  All of these schema
   elements are specified in [User].

      ( 2.5.6.2 NAME 'country' SUP top STRUCTURAL MUST c
         MAY ( searchGuide $ description ) )

3.26  Octet String

   A value in the Octet String syntax is a value of the OCTET STRING
   data type from ASN.1 [ASN1].  The following string states the OID
   assigned to this syntax:

   ( 1.3.6.1.4.1.1466.115.121.1.40 DESC 'Octet String' )

   Values in this syntax are written as a series of 8-bit values,
   according to the octet string value notation specified in [ASN1].
   In the case of character strings, the characters themselves could be
   written.

   Example:
      secret

3.27  OID

   A value in the Object Identifier syntax is a series of integers,
   ordered as specified in the OBJECT IDENTIFIER data type from ASN.1
   [ASN1].  The following string states the OID assigned to this
   syntax:

      ( 1.3.6.1.4.1.1466.115.121.1.38 DESC 'OID' )

   Values in this syntax are expressed according to the ABNF in
   section 2.1 for "oid".

   Examples:  1.2.3.4
              cn

3.28  Other Mailbox

   A value in the Other Mailbox syntax gives a mail system name with
   the name of a mailbox in the system.  The following string states
   the OID assigned to this syntax:

      ( 1.3.6.1.4.1.1466.115.121.1.39 DESC 'Other Mailbox' )

   Values in this syntax are written according to the following ABNF:

      otherMailbox = mailbox-type "$" mailbox

      mailbox-type = printablestring

      mailbox = <an encoded IA5 String>

   The printablestring production is defined in section 2.1.

   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.

3.29  Postal Address

   A value in the Postal Address syntax is a series of strings which
   form an address in a physical mail system.  The following string
   states the OID assigned to this syntax:

   ( 1.3.6.1.4.1.1466.115.121.1.41 DESC 'Postal Address' )

   Values in this syntax are written according to the following ABNF:

      postal-address = dstring *( "$" dstring )

   In the above, each dstring component of a postal address value is
   written as a value of type Directory String syntax.  Backslashes and
   dollar characters, if they occur in the component, are quoted as
   described in section 2.1.  Many servers limit the postal address to
   six lines of up to thirty characters.

   The production for dstring is defined in section 2.1.

   Example:

      1234 Main St.$Anytown, CA 12345$USA
      \241,000,000 Sweepstakes$PO Box 1000000$Anytown, CA 12345$USA

3.30  Presentation Address

   A value in the Presentation Address syntax is an OSI Application
   Layer address of a remote application.  Logically, a presentation
   address consists of:

        o  A presentation selector

        o  A session selector

        o  A transport selector

        o  A set of network addresses

   The following string states the OID assigned to this syntax:
      ( 1.3.6.1.4.1.1466.115.121.1.43 DESC 'Presentation Address' )

   Values in this syntax are written according to the following ABNF:

      presentation-address = [[[ psel "/" ] ssel "/" ] tsel "/" ]
         network-address-list

      psel = selector
      ssel = selector
      tsel = selector

      network-address-list = network-address "_" network-address-list /
         network-address

      network-address = "NS" "+" dothexstring
        / afi "+" idi [ "+" dsp ]
        / idp "+" hexstring

   The first (NS) alternative is the Concrete Binary Representation.
   It is the compact encoding.

   The afi alternative is a user-oriented representation of a network
   address.

   The idp alternative is a form of network-address included for
   compatibility with ISO 8348 [NSAP].

      selector = """ otherstring """
                / "#" numericstring
                / "'" hexstring "'H"
                / ""

   The otherstring alternative for the selector is IA5 characters.

   The "" alternative for the selector expresses the case where the
   selector is present, but Empty.

      idp = numericstring

      dsp = "d" numericstring
         / "x" dothexstring
         / "l" otherstring
         / "RFC-1006" "+" prefix "+" ip [ "+" port [ "+" tset ]]
         / "X.25(80)" "+" prefix "+" dte [ "+" cudf-or-pid "+"
           hexstring ]
         / "ECMA-117-Binary" "+" hexstring "+" hexstring "+" hexstring
         / "ECMA-117-Decimal" "+" numericstring "+"
            numericstring "+" numericstring

   The d alternative is the Abstract Decimal form of the Domain
   Specific Part (dsp) in a network address.

   The x alternative is the Abstract Binary form of the dsp in a
   network address.

   The l alternative is IA5 characters and is only meaningful locally.

      idi = numericstring

      afi = "X121" / "DCC" / "TELEX" / "PSTN" / "ISDN" / "ICD" / "LOCAL"

      prefix = DIGIT DIGIT

      ip = numericstring
           ;  dotted decimal form (e.g., 10.0.0.6) or
              domain (e.g., twg.com)

      port = numericstring

      tset = numericstring

      dte = numericstring

      cudf-or-pid = "CUDF" / "PID"

      other = k / "+" / DOT

      domainchar = k / DOT
      hexoctet = hex-digit hex-digit

      decimal-octet = 1*3DIGIT

      otherstring = other otherstring / other

      domainstring = domainchar otherstring / domainchar

      hexstring = hexoctet hexstring / hexoctet

      dotstring = decimaloctet DOT dotstring /
         decimaloctet DOT decimaloctet

      dothexstring = dotstring / hexstring

3.31  Printable is the form in which schema object classes
   are published in the directory in a subentry.  The following string
   states the OID assigned to this syntax:

      ( 1.3.6.1.4.1.1466.115.121.1.37 DESC 'Object Class Description' )

   For example, the character string below specifies the country object
   class, which requires the c (country name) attribute and allows the
   searchGuide and description attributes.  All of these schema
   elements are specified in [Schema].

      ( 2.5.6.2 NAME 'country' SUP top STRUCTURAL MUST c
         MAY ( searchGuide $ description ) )

3.26  Octet String

   A value in the Printable Octet String syntax is a series value of alphabetic,
   numeric, and (limited) punctuation characters as specified in the
   PrintableString OCTET STRING
   data type from ASN.1 [ASN1] and in production p of
   section 2.1. [X.680].  The following string states the OID
   assigned to this syntax:

   ( 1.3.6.1.4.1.1466.115.121.1.40 DESC 'Octet String' )

   Values in this syntax are expressed written as a series of 8-bit values,
   according to the octet string
   itself. value notation specified in [X.680].
   In the case of character strings, the characters themselves could be
   written.

   Example:
      secret

3.27  OID

   A value in the Object Identifier syntax is a series of integers,
   ordered as specified in the OBJECT IDENTIFIER data type from ASN.1
   [X.680].  The following string states the OID assigned to this
   syntax:

      ( 1.3.6.1.4.1.1466.115.121.1.44 1.3.6.1.4.1.1466.115.121.1.38 DESC 'Printable String' 'OID' )

   Example:  This is a PrintableString.

3.32 Substring Assertion

   The Substring Assertion

   Values in this syntax is used are expressed according to the ABNF in rules which can be used
   [MODELS], section 1.3 for "oid".

   Examples:  1.2.3.4
              cn

3.28  Other Mailbox

   A value in
   substrings and extensible matching rules.  When using the Other Mailbox syntax gives a substrings
   assertion, substrings components are provided in mail system name with
   the name of a SubstringFilter
   sequence. mailbox in the system.  The following string states
   the OID assigned to this syntax:

      ( 1.3.6.1.4.1.1466.115.121.1.58 1.3.6.1.4.1.1466.115.121.1.39 DESC 'Substring Assertion' 'Other Mailbox' )

   When using a matching rule assertion, substring components

   Values in this syntax are
   encoded written according to the following ABNF and provided as the
   matchValue of the MatchingRuleAssertion:

      substring = [initial] any [final]

      initial ABNF:

      otherMailbox = value

      any mailbox-type DOLLAR mailbox

      mailbox-type = "*" *(value "*")

      final printableString

      mailbox = value <an encoded IA5 String>

   The <value> printableString production is a UTF-8 [UTF-8] string.  If a backslash or
   asterix character is present defined in a production section 3.11.

   In the above, mailbox-type represents the type of <value>, it mail system in
   which the mailbox resides, for example "MCIMail";  and mailbox is
   quoted as described
   the actual mailbox in section 2.1.

3.33  Telephone Number the mail system defined by mailbox-type.

   The representation of a string in this syntax is the string value
   itself.

3.29  Postal Address

   A value in the telephone number Postal Address syntax is the a series of characters
   that express a number (address) assigned to strings which
   form an address in a telephone system
   subscriber. physical mail system.  The following string
   states the OID assigned to this syntax:

   ( 1.3.6.1.4.1.1466.115.121.1.50 1.3.6.1.4.1.1466.115.121.1.41 DESC 'Telephone Number' 'Postal Address' )

   Values in this syntax are written according to the following ABNF:

      postal-address = dstring *( DOLLAR dstring )

   In the above, each dstring component of a postal address value is
   written as a value of type Directory String syntax.  Backslashes and
   dollar characters, if they were Printable String
   types.  Telephone numbers are defined occur in X.520 [Attr] to comply
   with the internationally agreed format for expressing international
   telephone numbers component, are quoted as
   described in Recommendation E.123 [Tel #]. [MODELS].  Many servers limit the postal address to
   six lines of up to thirty characters.

   Example:  +1 512 315 0280

3.34  Teletex Terminal Identifier

      1234 Main St.$Anytown, CA 12345$USA
      \241,000,000 Sweepstakes$PO Box 1000000$Anytown, CA 12345$USA

3.30  Presentation Address

   A value in this the Presentation Address syntax is a string an OSI Application
   Layer address of characters that express the
   identifier value assigned to a teletex service subscriber. remote application.  Logically, a presentation
   address consists of:

        o  A presentation selector

        o  A session selector

        o  A transport selector

        o  A set of network addresses

   The following string states the OID assigned to this syntax:

      ( 1.3.6.1.4.1.1466.115.121.1.51 1.3.6.1.4.1.1466.115.121.1.43 DESC 'Teletex Terminal
         Identifier' 'Presentation Address' )

   Values in this syntax are written according to the following ABNF:

      teletex-id

      presentation-address = [[[ psel "/" ] ssel "/" ] tsel "/" ]
         network-address-list

      psel = selector
      ssel = selector
      tsel = selector

      network-address-list = network-address USCORE
         network-address-list / network-address

      network-address = "NS" PLUS dothexstring
        / afi PLUS idi [ PLUS dsp ]
        / idp PLUS hexstring

   The first (NS) alternative is the Concrete Binary Representation.
   It is the compact encoding.

   The afi alternative is a user-oriented representation of a network
   address.

   The idp alternative is a form of network-address included for
   compatibility with ISO 8348 [ISO8348].

      selector = DQUOTE otherstring DQUOTE
                / SHARP numericstring
                / SQUOTE hexstring "'H"
                / ""

   The otherstring alternative for the selector is IA5 characters.

   The "" alternative for the selector expresses the case where the
   selector is present, but Empty.

      idp = numericstring
      dsp = "d" numericstring
         / "x" dothexstring
         / "l" otherstring
         / "RFC-1006" PLUS prefix PLUS ip [ PLUS port [ PLUS tset ]]
         / "X.25(80)" PLUS prefix PLUS dte [ PLUS cudf-or-pid PLUS
           hexstring ]
         / "ECMA-117-Binary" PLUS hexstring PLUS hexstring PLUS
         hexstring / "ECMA-117-Decimal" PLUS numericstring PLUS
            numericstring PLUS numericstring

   The d alternative is the Abstract Decimal form of the Domain
   Specific Part (dsp) in a network address.

   The x alternative is the Abstract Binary form of the dsp in a
   network address.

   The l alternative is IA5 characters and is only meaningful locally.

      idi = numericstring

      afi = "X121" / "DCC" / "TELEX" / "PSTN" / "ISDN" / "ICD" / "LOCAL"

      prefix = ttx-term  0*("$" ttx-param)

      ttx-term DIGIT DIGIT

      ip = printablestring

      ttx-param numericstring
           ;  dotted decimal form (e.g., 10.0.0.6) or
              domain (e.g., twg.com)

      port = ttx-key ":" ttx-value

      ttx-key numericstring

      tset = "graphic" numericstring

      dte = numericstring

      cudf-or-pid = "CUDF" / "control" "PID"

      other = keychar / "misc" PLUS / "page" DOT

      domainchar = keychar / "private"

      ttx-value DOT

      hexoctet = octetstring

   In the above, the first printablestring is the encoding of the first
   portion of the teletex terminal identifier to be encoded, and the
   subsequent 0 or more octetstrings are subsequent portions of the
   teletex terminal identifier.

   The productions for printablestring and octetstring are defined in
   section 2.1.

3.35  Telex Number HEX HEX

      decimal-octet = 1*3DIGIT

      otherstring = other otherstring / other

      domainstring = domainchar otherstring / domainchar

      hexstring = hexoctet hexstring / hexoctet

      dotstring = decimaloctet DOT dotstring /
         decimaloctet DOT decimaloctet

      dothexstring = dotstring / hexstring

3.31  Printable String

   A value in the Telex Number Printable String syntax is the number assigned to a telex
   system subscriber with the country and answerback values indicated.

   The following string states the OID assigned to this syntax:

      ( 1.3.6.1.4.1.1466.115.121.1.52 DESC 'Telex Number' )

   Values in this syntax are written according to the following ABNF:

      telex-number  = actual-number "$" country "$" answerback

      actual-number = printablestring

      country       = printablestring

      answerback    = printablestring

   In the above, actual-number is the syntactic representation of the
   number portion series of the TELEX number being written, country is the
   TELEX country code, alphabetic,
   numeric, and answerback is (limited) punctuation characters as specified in the answerback code of a TELEX
   terminal.

   The production for printablestring is defined
   PrintableString data type from ASN.1 [X.680] and in production p of
   section 2.1.

3.36  UTC Time

   A value 3.11.  Values in the UTC Time this syntax is a date and time indicating accuracy
   to minute or second.  The year is given are expressed as a two-digit number. the string
   itself.  The following string states the OID assigned to this syntax:

      ( 1.3.6.1.4.1.1466.115.121.1.53 1.3.6.1.4.1.1466.115.121.1.44 DESC 'UTC Time' 'Printable String' )

   Values in this syntax are written as if they were printable strings,
   formulated as specified for the UTCTime data type in ASN.1 [ASN1].
   It is strongly suggested that GMT time be used.

   Note:

   Example:  This is a PrintableString.

3.32 Substring Assertion

   The Substring Assertion syntax is deprecated used in favor of the Generalized Time
   syntax.

4.  Matching Rules

   When performing the caseExactMatch, caseIgnoreMatch,
   caseIgnoreListMatch, telephoneNumberMatch, caseExactIA5Match rules which can be used in
   substrings and
   caseIgnoreIA5Match, multiple adjoining whitespace characters extensible matching rules.  When using a substrings
   assertion, substrings components are
   treated the same as an individual space, and leading and trailing
   whitespace is ignored.

4.1  bitStringMatch provided in a SubstringFilter
   sequence.  The following ABNF associates the bitStringMatch rule with string states the Bit
   String OID assigned to this
   syntax:

      ( 2.5.13.16 NAME 'bitStringMatch'
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 1.3.6.1.4.1.1466.115.121.1.58 DESC 'Substring Assertion' )  ; Bit String

   This

   When using a matching rule is used assertion, substring components are
   encoded according to test equality.

4.2  caseExactIA5Match

   The the following ABNF associates and provided as the caseExactIA5Match rule with
   matchValue of the IA5
   String syntax:

      ( 1.3.6.1.4.1.1466.109.114.1 NAME 'caseExactIA5Match'
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )  ; IA5 String

   This matching rule MatchingRuleAssertion:

      substring = [initial] any [final]

      initial = value

      any = "*" *(value "*")

      final = value

   The <value> production is a UTF-8 [ISO10646] string.  If a backslash or
   asterix character is present in a production of <value>, it is used
   quoted as described in [MODELS].

3.33  Telephone Number

   A value in the telephone number syntax is the series of characters
   that express a number (address) assigned to test equality.

4.3  caseIgnoreIA5Match a telephone system
   subscriber.  The following ABNF associates the caseIgnoreIA5Match rule with string states the
   IA5 String OID assigned to this
   syntax:

      ( 1.3.6.1.4.1.1466.109.114.2 NAME 'caseIgnoreIA5Match'
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 1.3.6.1.4.1.1466.115.121.1.50 DESC 'Telephone Number' )  ; IA5

   Values in this syntax are written as if they were ASN.1 [X.680]
   Printable String

   This matching rule is used types.  Telephone numbers are defined in X.520
   [X.520] to test equality.

4.4  caseIgnoreListMatch

   The ABNF below associates the caseIgnoreListMatch rule comply with the
   Postal Address syntax.  The X.520 [Attr] syntax internationally agreed format for
   expressing international telephone numbers in Recommendation
   E.123 [E.123].

   The representation of a string in this matching
   rule syntax is a SEQUENCE Of DirectoryString.  Since the Postal Address string value
   itself.

   Example:  +1 512 315 0280

3.34  Teletex Terminal Identifier

   A value in this syntax is such a sequence, it is used in defining the matching rule
   for LDAP, although string of characters that express the matching rule can be used with any SEQUENCE
   OF DirectoryString syntax/assertion.

      ( 2.5.13.11 NAME 'caseIgnoreListMatch'
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 )  ; Postal Address

   This matching rule is used
   identifier value assigned to test equality.

4.5  caseIgnoreMatch a teletex service subscriber.  The
   following ABNF associates the caseIgnoreMatch rule with string states the
   Directory String OID assigned to this syntax:

      ( 2.5.13.2 NAME 'caseIgnoreMatch'
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 1.3.6.1.4.1.1466.115.121.1.51 DESC 'Teletex Terminal
         Identifier' )  ; Directory String

   This matching rule is used

   Values in this syntax are written according to test equality.

4.6  caseIgnoreOrderingMatch

   The the following ABNF associates ABNF:

      teletex-id = ttx-term  0*("$" ttx-param)

      ttx-term   = printablestring

      ttx-param  = ttx-key ":" ttx-value

      ttx-key    = "graphic" / "control" / "misc" / "page" / "private"

      ttx-value  = octetstring

   In the caseIgnoreOrderingMatch rule with above, the Directory String syntax:

      ( 2.5.13.3 NAME 'caseIgnoreOrderingMatch'
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )  ; Directory String

   This matching rule first printablestring is used the encoding of the first
   portion of the teletex terminal identifier to test inequality, i.e., greaterOrEqual be encoded, and the
   subsequent 0 or lessOrEqual. more octetstrings are subsequent portions of the
   teletex terminal identifier.

   The sort ordering for representation of a caseIgnoreOrderingMatch string in this syntax is implementation-
   dependent.

4.7  caseIgnoreSubstringsMatch

   The following ABNF associates the caseIgnoreSubstringsMatch rule with string value
   itself.

3.35  Telex Number

   A value in the Substring Assertion:

      ( 2.5.13.4 NAME 'caseIgnoreSubstringsMatch'
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )  ; Substring Assertion

   This matching rule Telex Number syntax is used to test substrings equality.

4.8  distinguishedNameMatch

   The following ABNF associates the distinguishedNameMatch rule number assigned to a telex
   system subscriber with the DN syntax:

      ( 2.5.13.1 NAME 'distinguishedNameMatch'
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )  ; DN

   This matching rule is used to test equality.

4.9  generalizedTimeMatch country and answerback values indicated.

   The following ABNF associates the generalizedTimeMatch rule with string states the
   Generalized Time syntax:

      ( 2.5.13.27 NAME 'generalizedTimeMatch'
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 )  ; Generalized Time
   This matching rule is used OID assigned to test equality.

4.10 generalizedTimeOrderingMatch this syntax:

      ( 2.5.13.28 NAME 'generalizedTimeOrderingMatch'
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 1.3.6.1.4.1.1466.115.121.1.52 DESC 'Telex Number' )  ; Generalized Time

   This matching rule is used

   Values in this syntax are written according to test inequality, i.e., greaterOrEqual
   or lessOrEqual.

4.11 integerFirstComponentMatch

   The following ABNF associates the integerFirstComponentMatch rule
   with following ABNF:

      telex-number  = actual-number "$" country "$" answerback

      actual-number = printablestring

      country       = printablestring

      answerback    = printablestring
   In the INTEGER syntax:

      ( 2.5.13.29 NAME 'integerFirstComponentMatch'
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )  ; INTEGER

   Implementors, note that above, actual-number is the assertion syntax syntactic representation of this matching
   rule, an INTEGER, is different from the value syntax
   number portion of attributes
   for which this the TELEX number being written, country is the equality matching rule.

   This matching rule
   TELEX country code, and answerback is used to test equality with the first component
   in answerback code of a compound syntax.

4.12 integerMatch TELEX
   terminal.

   The following ABNF associates representation of a string in this syntax is the integerMatch rule with string value
   itself.

3.36  UTC Time

   A value in the INTEGER
   syntax:

      ( 2.5.13.14 NAME 'integerMatch'
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )  ; INTEGER

   This matching rule UTC Time syntax is used a date and time indicating accuracy
   to test equality.

4.13  numericStringMatch minute or second.  The year is given as a two-digit number.  The
   following ABNF associates the numericStringMatch rule with string states the
   Numeric String OID assigned to this syntax:

      ( 2.5.13.8 NAME 'numericStringMatch'
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 1.3.6.1.4.1.1466.115.121.1.53 DESC 'UTC Time' )  ; Numeric String

   This matching rule

   Values in this syntax are written as if they were printable strings,
   formulated as specified for the UTCTime data type in ASN.1 [X.680].
   It is used to test equality.

4.14  numericStringSubstringsMatch

      ( 2.5.13.10 NAME 'numericStringSubstringsMatch'
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )  ; Substring Assertion strongly suggested that GMT time be used.

   Note:  This matching rule syntax is used to test substrings equality.

4.15  objectIdentifierFirstComponentMatch deprecated in favor of the Generalized Time
   syntax.

4.  Matching Rules

   When performing the caseExactMatch, 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.

4.1  bitStringMatch

   The following ABNF associates the
   objectIdentifierFirstComponentMatch bitStringMatch rule with the OID Bit
   String syntax:

     ( 2.5.13.31 2.5.13.16 NAME 'objectIdentifierFirstComponentMatch' 'bitStringMatch'
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 1.3.6.1.4.1.1466.115.121.1.6 )  ; OID

   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. Bit String

   This matching rule is used to test equality with the first component
   in a compound syntax.

4.16  objectIdentifierMatch equality.

4.2  caseExactIA5Match

   The following ABNF associates the objectIdentifierMatch caseExactIA5Match rule with the
   OID IA5
   String syntax:

      ( 2.5.13.0 1.3.6.1.4.1.1466.109.114.1 NAME 'objectIdentifierMatch' 'caseExactIA5Match'
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 1.3.6.1.4.1.1466.115.121.1.26 )  ; OID IA5 String

   This matching rule is used to test equality.

   Implementors, note that the assertion syntax of this matching
   rule, an OID, is different from the value syntax of attributes for
   which this is the equality matching rule.

   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.

4.17  octetStringMatch

   Servers which implement the extensibleMatch filter SHOULD allow the
   matching rule listed in this section to be used in the
   extensibleMatch.  In general these servers SHOULD allow matching
   rules to be used with all attribute types known to the server, when
   the assertion syntax of the matching rule is the same as the value
   syntax of the attribute.

   The Octet String Match rule compares for equality an asserted octet
   string with an attribute value of type OCTET STRING.

   The strings match if they are the same length and corresponding
   octets are identical.

   ( 2.5.13.17 NAME 'octetStringMatch'
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )

4.18  presentationAddressMatch

4.3  caseIgnoreIA5Match

   The following ABNF associates the presentationAddressMatch caseIgnoreIA5Match rule with the  Presentation Address
   IA5 String syntax:

      ( 2.5.13.22 1.3.6.1.4.1.1466.109.114.2 NAME 'presentationAddressMatch' 'caseIgnoreIA5Match'
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.43 1.3.6.1.4.1.1466.115.121.1.26 )  ; Presentation Address IA5 String

   This matching rule is used to test equality.

4.19  protocolInformationMatch

4.4  caseIgnoreListMatch

   The following ABNF below associates the protocolInformationMatch caseIgnoreListMatch rule with the Protocol Information syntax:
   Postal Address syntax.  The X.520 [X.520] syntax for this matching
   rule is a SEQUENCE Of DirectoryString.  Since the Postal Address
   syntax is such a sequence, it is used in defining the matching rule
   for LDAP, although the matching rule can be used with any SEQUENCE
   OF DirectoryString syntax/assertion.

      ( 2.5.13.24 2.5.13.11 NAME 'protocolInformationMatch' 'caseIgnoreListMatch'
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.42 1.3.6.1.4.1.1466.115.121.1.41 )  ; Protocol Information Postal Address

   This matching rule is used to test equality.

4.20 telephoneNumberMatch

4.5  caseIgnoreMatch

   The following ABNF associates the telephoneNumberMatch caseIgnoreMatch rule with the
   Telephone Number
   Directory String syntax:

      ( 2.5.13.20 2.5.13.2 NAME 'telephoneNumberMatch' 'caseIgnoreMatch'
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 1.3.6.1.4.1.1466.115.121.1.15 )  ; Telephone Number Directory String

   This matching rule is used to test equality.

4.21 telephoneNumberSubstringsMatch

4.6  caseIgnoreOrderingMatch

   The following ABNF associates the telephoneNumberSubstringsMatch caseIgnoreOrderingMatch rule with
   the Substring Assertion Directory String syntax:

      ( 2.5.13.21 2.5.13.3 NAME 'telephoneNumberSubstringsMatch' 'caseIgnoreOrderingMatch'
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 1.3.6.1.4.1.1466.115.121.1.15 )  ; Substring Assertion Directory String

   This matching rule is used to test substrings equality.

4.22 uniqueMemberMatch inequality, i.e., greaterOrEqual
   or lessOrEqual.

   The sort ordering for a caseIgnoreOrderingMatch is implementation-
   dependent.

4.7  caseIgnoreSubstringsMatch

   The following ABNF associates the uniqueMemberMatch caseIgnoreSubstringsMatch rule with
   the
   Name and Optional UID syntax: Substring Assertion:

      ( 2.5.13.23 2.5.13.4 NAME 'uniqueMemberMatch' 'caseIgnoreSubstringsMatch'
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.34 1.3.6.1.4.1.1466.115.121.1.58 )  ; Name And Optional UID Substring Assertion

   This matching rule is used to test substrings equality.

5.  Attribute Types

5.1  altServer

   The values of this attribute are URLs of other servers which could 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 can 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 )

   The SYNTAX oid indicates the IA5 String syntax.

   This attribute is only present in the root DSE (see [Prot]
   and [Models]).

5.2  attributeTypes

4.8  distinguishedNameMatch

   The attributeTypes attribute holds descriptions of the attributes in
   a schema.  This attribute is typically located in following ABNF associates 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 )

   The SYNTAX oid indicates distinguishedNameMatch rule with
   the Attribute Type Description syntax.

5.3  createTimestamp DN syntax:

      ( 2.5.18.1 2.5.13.1 NAME 'createTimestamp'
         EQUALITY generalizedTimeMatch
         ORDERING generalizedTimeOrderingMatch 'distinguishedNameMatch'
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
         SINGLE-VALUE
         NO-USER-MODIFICATION
         USAGE directoryOperation 1.3.6.1.4.1.1466.115.121.1.12 )  ; DN

   This matching rule is used to test equality.

4.9  generalizedTimeMatch

   The SYNTAX oid indicates following ABNF associates the generalizedTimeMatch rule with the
   Generalized Time syntax.

5.4  creatorsName syntax:

      ( 2.5.18.3 2.5.13.27 NAME 'creatorsName'
         EQUALITY distinguishedNameMatch 'generalizedTimeMatch'
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
         SINGLE-VALUE
         NO-USER-MODIFICATION
         USAGE directoryOperation 1.3.6.1.4.1.1466.115.121.1.24 )
   The SYNTAX oid indicates the DN syntax.

5.5  ditContentRules  ; Generalized Time

   This matching rule is used to test equality.

4.10 generalizedTimeOrderingMatch

      ( 2.5.21.2 2.5.13.28 NAME 'dITContentRules'
         EQUALITY objectIdentifierFirstComponentMatch 'generalizedTimeOrderingMatch'
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.16
         USAGE directoryOperation 1.3.6.1.4.1.1466.115.121.1.24 )

   The SYNTAX oid indicates the DIT Content Rule Description syntax.  ; Generalized Time

   This attribute matching rule is located in used to test inequality, i.e., greaterOrEqual
   or lessOrEqual.

4.11 integerFirstComponentMatch

   The following ABNF associates the subschema entry.

5.6  dITStructureRules integerFirstComponentMatch rule
   with the INTEGER syntax:

      ( 2.5.21.1 2.5.13.29 NAME 'dITStructureRules'
         EQUALITY integerFirstComponentMatch 'integerFirstComponentMatch'
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.17
         USAGE directoryOperation 1.3.6.1.4.1.1466.115.121.1.27 )

   The SYNTAX oid indicates  ; INTEGER

   Implementors, note that the DIT Structure Rule Description syntax.

   This attribute assertion syntax of this matching
   rule, an INTEGER, is located in different from the subschema entry.

5.7  ldapSyntaxes

   This attribute value syntax of attributes
   for which this is typically located in the subschema entry. equality matching rule.

   This attribute identifies the syntaxes implemented, with each value
   corresponding matching rule is used to one test equality with the first component
   in a compound 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 )

4.12 integerMatch

   The SYNTAX oid indicates following ABNF associates the LDAP Syntax Description syntax.

5.8  matchingRules

   This attribute is typically located in integerMatch rule with the subschema entry. INTEGER
   syntax:

      ( 2.5.21.4 2.5.13.14 NAME 'matchingRules'
         EQUALITY objectIdentifierFirstComponentMatch 'integerMatch'
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.31
         USAGE directoryOperation 1.3.6.1.4.1.1466.115.121.1.27 )

   The SYNTAX oid indicates the Matching Rule Description syntax.

5.9  matchingRuleUse  ; INTEGER

   This attribute matching rule 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 ) used to test equality.

4.13  numericStringMatch

   The SYNTAX oid indicates following ABNF associates the Matching Rule Use Description syntax.

5.10  modifiersName numericStringMatch rule with the
   Numeric String syntax:

      ( 2.5.18.4 2.5.13.8 NAME 'modifiersName'
         EQUALITY distinguishedNameMatch 'numericStringMatch'
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
         SINGLE-VALUE
         NO-USER-MODIFICATION
         USAGE directoryOperation 1.3.6.1.4.1.1466.115.121.1.36 )

   The SYNTAX oid indicates the DN syntax.

5.11  modifyTimestamp  ; Numeric String

   This matching rule is used to test equality.

4.14  numericStringSubstringsMatch

      ( 2.5.18.2 2.5.13.10 NAME 'modifyTimestamp'
         EQUALITY generalizedTimeMatch
         ORDERING generalizedTimeOrderingMatch 'numericStringSubstringsMatch'
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
         SINGLE-VALUE
         NO-USER-MODIFICATION
         USAGE directoryOperation 1.3.6.1.4.1.1466.115.121.1.58 )  ; Substring Assertion

   This matching rule is used to test substrings equality.

4.15  objectIdentifierFirstComponentMatch

   The SYNTAX oid indicates following ABNF associates the Generalized Time syntax.

5.12  nameForms
   objectIdentifierFirstComponentMatch rule with the OID syntax:

      ( 2.5.21.7 2.5.13.31 NAME 'nameForms'
         EQUALITY objectIdentifierFirstComponentMatch 'objectIdentifierFirstComponentMatch'
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.35
         USAGE directoryOperation 1.3.6.1.4.1.1466.115.121.1.38 )

   The SYNTAX oid indicates  ; OID

   If the Name Form Description syntax.

   This attribute client supplies an extensible filter using an
   objectIdentifierFirstComponentMatch whose matchValue is located in the subschema entry.

5.13  namingContexts

   The values of this attribute correspond to naming contexts which
   this server masters or shadows.  If
   "descr" form, and the server does not master any
   information (e.g. it OID is an LDAP gateway to a public X.500 directory)
   this attribute will be absent.  If not recognized by the server believes it contains server, then the entire directory,
   filter is Undefined.

   This matching rule is used to test equality with the attribute will have first component
   in a single value, and
   that value will be the empty string (indicating compound syntax.

4.16  objectIdentifierMatch

   The following ABNF associates the null DN of objectIdentifierMatch rule with the
   root).  This attribute will allow a client to choose suitable base
   objects for searching when it has contacted a server.
   OID syntax:

      ( 1.3.6.1.4.1.1466.101.120.5 2.5.13.0 NAME 'namingContexts' 'objectIdentifierMatch'
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
         USAGE dSAOperation 1.3.6.1.4.1.1466.115.121.1.38 )

   The SYNTAX oid indicates the DN syntax.

   This attribute is only present in the root DSE (see [Prot]
   and [Models]).

5.14  objectClasses  ; OID

   This attribute matching rule is typically located in used to test equality.

   Implementors, note that 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 )

   The SYNTAX oid indicates assertion syntax of this matching
   rule, an OID, is different from the Object Class Description syntax.

5.15  subschemaSubentry

   The value syntax of attributes for
   which this attribute is the name of a subschema entry (or
   subentry) where equality matching rule.

   If the server makes available attributes specifying client supplies a filter using an objectIdentifierMatch whose
   matchValue oid is in the
   schema controlling "descr" form, and the subject 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 SYNTAX oid indicates is not recognized
   by the DN syntax.

5.16  supportedControl

   The values of this attribute are server, then the OBJECT IDENTIFIERs identifying
   controls filter is Undefined.

4.17  octetStringMatch

   Servers which implement the server supports.  If extensibleMatch filter SHOULD allow the server does not support
   any controls,
   matching rule listed in this attribute will section to 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 )

   The SYNTAX oid indicates used in the OID syntax.

   This
   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 only present in the root DSE (see [Prot]
   and [Models]).

5.17  supportedExtension

   The values same as the value
   syntax of this the attribute.

   The Octet String Match rule compares for equality an asserted octet
   string with an attribute value of type OCTET STRING.

   The strings match if they are OBJECT IDENTIFIERs identifying the
   supported extended operations which same length and corresponding
   octets are identical.

   The following ABNF associates the server supports.

   If octetStringMatch rule with
   the server does not support any extensions this attribute will be
   absent. OCTET STRING syntax:

   ( 1.3.6.1.4.1.1466.101.120.7 2.5.13.17 NAME 'supportedExtension' 'octetStringMatch'
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
         USAGE dSAOperation 1.3.6.1.4.1.1466.115.121.1.40 )

4.18  presentationAddressMatch

   The SYNTAX oid indicates following ABNF associates the OID syntax. presentationAddressMatch rule with
   the  Presentation Address syntax:

      ( 2.5.13.22 NAME 'presentationAddressMatch'
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.43 )  ; Presentation Address

   This attribute matching rule is only present in the root DSE (see [Prot]
   and [Models]).

5.18  supportedLDAPVersion

   The values of this attribute are the versions of used to test equality.

4.19  protocolInformationMatch

   The following ABNF associates the LDAP protocol
   which protocolInformationMatch rule with
   the server implements. Protocol Information syntax:

      ( 1.3.6.1.4.1.1466.101.120.15 2.5.13.24 NAME 'supportedLDAPVersion' 'protocolInformationMatch'
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
         USAGE dSAOperation 1.3.6.1.4.1.1466.115.121.1.42 )

   The SYNTAX oid indicates the INTEGER syntax.  ; Protocol Information

   This attribute matching rule is only present in the root DSE (see [Prot]
   and [Models]).

5.19  supportedSASLMechanisms used to test equality.

4.20 telephoneNumberMatch

   The values of this attribute are the names of supported SASL
   mechanisms which following ABNF associates the server supports.  If telephoneNumberMatch rule with the server does not support
   any mechanisms this attribute will be absent.
   Telephone Number syntax:

      ( 1.3.6.1.4.1.1466.101.120.14 2.5.13.20 NAME 'supportedSASLMechanisms' 'telephoneNumberMatch'
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
         USAGE dSAOperation 1.3.6.1.4.1.1466.115.121.1.50 )

   The SYNTAX oid indicates the Directory String syntax.  ; Telephone Number

   This attribute matching rule is only present in the root DSE (see [Prot]
   and [Models]).

6.  Object Classes

6.1  Extensible Object Class

   The extensibleObject object class, if present in an entry, permits
   that entry used to hold any attribute. test equality.

4.21 telephoneNumberSubstringsMatch

   The "MAY" attribute list
   of this class is implicitly following ABNF associates the set of all attributes. telephoneNumberSubstringsMatch rule
   with the Substring Assertion syntax:

      ( 1.3.6.1.4.1.1466.101.120.111 2.5.13.21 NAME 'extensibleObject'
         SUP top
         AUXILIARY 'telephoneNumberSubstringsMatch'
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )  ;  MAY all attributes Substring Assertion

   This matching rule is implied

   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 used to add this object class.

   Note that, if the server implements the extensibleObject class but an
   attribute is not recognized, this is the same case as for any other
   object class.

6.2  subschema

   This object class contains a description of test substrings equality.

4.22 uniqueMemberMatch

   The following ABNF associates the schema that is
   applied in uniqueMemberMatch rule with the server
   Name and is used in the subschema entry. Optional UID syntax:

      ( 2.5.20.1 2.5.13.23 NAME 'subschema'
         AUXILIARY
         MAY ( dITStructureRules $
             nameForms $
             ditContentRules $
             objectClasses $
             attributeTypes $
             matchingRules $
             matchingRuleUse ) 'uniqueMemberMatch'
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.34 )

   The ldapSyntaxes operational attribute can also be present in
   subschema entries.

7.  ; Name And Optional UID

   This matching rule is used to test equality.

5. Security Considerations

7.1

5.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.

7.2

5.2  Security Information Syntaxes

   Several X.500 attributes, such as, the userCertificate attribute,
   are used to include key-based security information in directory
   entries.  The attribute syntaxes for these attributes are:

      Certificate
      CertificateList
      CertificatePair
      SupportedAlgorithm

   These syntaxes are specified for LDAP by the PKIX Working Group, and
   so, are not included in this document.

   The ABNF specifications of "User Certificate", "Authority Revocation
   List", and "Certificate Pair" in RFC 1778 [Syn String] are
   not to be used.

7.3  Use of Attribute Values in Security Applications

   The transformations of an AttributeValue value from its X.501 form
   to an LDAP string representation [RFC1778] are not always reversible back to
   the same BER or DER form.

   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 a
   value SHOULD NOT use the string LDAP native encoding when converting
   a value to LDAP format.  Instead the ;binary transfer option [Prot]
   SHOULD
   be used.

7.4

5.3  Securing the Directory

   In order to protect the directory and its contents, strong
   authentication MUST have been used to identify the Client when an
   update operation is requested.

8.

6.  Acknowledgements

   This document is an update of RFC 2252 by M. Wahl, A. Coulbeck,
   T. Howes, and S. Kille.  RFC 2252 was a product of the IETF ASID
   Working Group.

   This document is based upon input of the IETF LDAPBIS working group.
   The authors wish to thank J. Sermersheim and K. Zeilenga for their
   significant contribution to this update.

9.

7.  Authors' Addresses

   Kathy Dally
   The MITRE Corp.
   7515 Colshire Dr., ms-W650
   McLean VA 22102
   USA

   Phone:  +1 703 883 6058
   Fax:  +1 703 883 7142
   Email:  kdally@mitre.org

   Steven Legg
   Adacel Technologies Ltd.
   405-409 Ferntree Gully Road
   Mount Waverley, Victoria 3149
   AUSTRALIA

   Phone:  +61 3 9451 2107
   Fax:  +61 3 9541 2121
   EMail:  steven.legg@adacel.com.au

10

8. References

10.1

8.1  Normative

   [ABNF]  Crocker, D., Overell, P., "Augmented BNF for Syntax
      Specifications: ABNF", RFC 2234, November 1997

   [ASN1]  Information Technology - Abstract Syntax

   [E.123]  Notation One
      (ASN.1):  Specification of Basic Notation, ITU-T Recommendation
      X.680, 1994

   [Attr]  The Directory:  Selected Attribute Types.  ITU-T Recommendation
      X.520, 1993.

   [Codes]  ISO 3166, "Codes for the representation of names of countries".

   [DN String] draft-ietf-ldapbis-dn-xx, replacement for Wahl, M., Kille, S.,
        and T. Howes, "Lightweight Directory Access Protocol (v3):
        UTF-8 String Representation of Distinguished Names", RFC 2253,
        December 1997.

   [Fax]  Standardization of Group 3 facsimile apparatus for document
      transmission - Terminal Equipment national and Protocols for Telematic
      Services, international telephone numbers,
      ITU-T Recommendation T.4, 1993 E.123, 1988.

   [IA5] 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

   [ISO3166]  ISO 3166, "Codes for the representation of names
      of countries".

   [ISO10646] 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.

   [Keywds]  Bradner, S., "Key words for use

   [LDAPDN]  K. Zeilenga (editor), "LDAP: String Representation of
             Distinguished Names", draft-ietf-ldapbis-dn-xx.txt, (a
             work in RFCs to Indicate
      Requirement Levels", RFC 2119, March 1997.

   [Map] progress).

   [Protocol]  J. Sermersheim (editor), "LDAP: The Protocol",
             draft-ietf-ldapbis-protocol-xx.txt, a work in progress.

   [RFC1327]  Hardcastle-Kille, S., "Mapping between X.400(1988)/ISO X.400(1988)/
      ISO 10021 and RFC 822", RFC 1327, May 1992.

   [Models]  The Directory:  Models, ITU-T Recommendation X.501, 1993.

   [Prot]  draft-ietf-ldapbis-protocol-xx, replacement for Wahl, M.,
      Howes, T.,

   [RFC2044] Yergeau, F., "UTF-8, a transformation format of Unicode
      and S. Kille, "Lightweight Directory Access Protocol
      (v3)", ISO 10646", RFC 2251, December 1997.

   [Tel #]  Notation 2044, October 1996.

   [RFC2119]  Bradner, S., "Key words for national and international telephone numbers,
      ITU-T Recommendation E.123, 1988.

   [UCS] Universal Multiple-Octet Coded Character Set (UCS) -
        Architecture and Basic Multilingual Plane,
        ISO/IEC 10646-1:  1993 (with amendments).

   [User] use in RFCs to Indicate
      Requirement Levels", RFC 2119, March 1997.

   [RFC 2256]  draft-ietf-ldapbis-user-schema-xx, replacement for Wahl, M.,
      "A Summary of the X.500(96) User Schema for use with LDAPv3",
      RFC 2256, December 1997.

   [UTF-8] Yergeau, F., "UTF-8, a transformation format

   [T.4]  Standardization of Unicode Group 3 facsimile apparatus for document
      transmission - Terminal Equipment and
      ISO 10646", RFC 2044, October 1996.

10.2 Protocols for Telematic
      Services, ITU-T Recommendation T.4, 1993

   [X.501]    The Directory:  Models, ITU-T Recommendation X.501, 1993.

   [X.520]  The Directory:  Selected Attribute Types.  ITU-T
      Recommendation X.520, 1993.

   [X.680]  Information Technology - Abstract Syntax Notation One
      (ASN.1):  Specification of Basic Notation, ITU-T Recommendation
      X.680, 1994

8.2  Informative References

   [LDAP '95]

   [ISO8348]  Information technology -- Open Systems Interconnection --
      Network Service Definition, ISO/IEC 8348:1996

   [RFC1777]  Yeong, W., Howes, T., Kille, S., "Lightweight Directory
      Access Protocol", RFC 1777, March 1995

   [NSAP]  Information technology -- Open Systems Interconnection --
      Network Service Definition, ISO/IEC 8348:1996
   [Syn String]

   [RFC1778]  Howes, T., Kille, S., Yeong, W., Robbins, C., "The
      String Representation of Standard Attribute Syntaxes", RFC 1778,
      March 1995.

11.

   [RFC2253]  Wahl, M., Kille, S., and T. Howes, "Lightweight Directory
      Access Protocol (v3):  UTF-8 String Representation of
      Distinguished Names", RFC 2253, December 1997.

9.  Full Copyright Statement

Copyright (C) The Internet Society (2002).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph
   are included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other
   than English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET  ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

          Annex A  Object Identifiers of Syntaxes

   This list contains the object identifiers for the syntaxes used in
   this specification and in the user schema specification [User].

   Syntax of Value Represented              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.31
   Matching Rule Use Description           1.3.6.1.4.1.1466.115.121.1.31
   MHS OR Address                          1.3.6.1.4.1.1466.115.121.1.33
   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
   Presentation Address                    1.3.6.1.4.1.1466.115.121.1.43
   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
          Annex B  Topics Yet To Be Addressed In This Document

   This appendix is provided for informational purposes only, it is not
   a normative part of this specification.

   APPEARED:  -00
   Paragraph 2.2.3 - Should any syntaxes listed in the table be removed?
   Should any new syntaxes be added?
   RESOLUTION: Cannot add syntaxes.  Moving the table to an annex keeps
   a record of the OIDS that have been assigned.  Deleted unspecified
   syntaxes from the list. APPLIED:  -02

   APPEARED:  -00
   Paragraph 2.2.4 - Should attribute syntaxes be allowed to be referenced
   by a common name, and if so, where should the name come from?
   RESOLUTION:  Rejected because of adding functionality.  APPLIED:  -01

   APPEARED:  -00
   How does the data model draft <draft-wahl-ladpv3-defns-01.txt> affect
   this draft?
   RESOLUTION:  It does not.  The draft was preliminary to the revised
   Schema and Protocol I-Ds.  APPLIED:  -01

   APPEARED:  -00
   Section 3 - Should all listed syntaxes from paragraph 2.2.3 be
   detailed in this section?  Nearly half the listed syntaxes are not
   referenced in this section.
   RESOLUTION:  No, because many are not being used, currently.
   APPLIED:  -01

   APPEARED:  -01
   Section 4 - Should all of the X.520(1993) matching rules be included?
   In particular, how about caseExactMatch?  Also, should
   octetStringMatch be moved from updated RFC 2256?
   RESOLUTION:  caseExactMatch not included.  octetStringMatch moved to
   this document.  APPLIED:  -01

   APPEARED:  -00
   Section 6 - Recognized list of Object classes needs to be reconciled
   with updated RFC 2256 and the data model draft.
   RESOLUTION:  Not necessary.  APPLIED:  -01

   APPEARED:  -00
   Section 7 - Proper security statement needs to be formulated.
   RESOLUTION:  Text has been expanded since RFC 2252, but needs
   more work.  APPLIED:

                         Annex C  Change Log

   This annex lists the changes that have been made from RFC 2252 to
   this specification.

   This annex is provided for informational purposes only.  It is not
   a normative part of this specification.  Items 32 - end are new in
   the -02 version of this document.

-------
-00 changes

      1.  Removed the IESG Note.

      2.  Changed "types" to "syntaxes" in the last sentence of the
          Abstract.  Also, added to the last sentence in order to
          indicate that syntaxes are not the only schema elements
          defined in this document.

      3.  Reorganized the sections so that:

              * the schema element categories are specified in the
                order in which they build on one another:  syntaxes,
                matching rules, attributes, object classes

              * within each category the elements are specified in
                alphbetical order

      4.  Added an "Implementation Status" paragraph for each element,
          gathering the conformance statements.

      5.  Clarified schema description in the Overview.

      6.  Changed the "Common Encoding Aspects" section title to
          "Notation" and made corresponding changes throughout the
          document.  The purpose being to relegate all encoding issues
          to the Protocol specification [Prot]. [Protocol].

      7.  Added a MUST statement regarding the syntaxes required of
          servers.

      8.  Expanded the discussion of each of the syntaxes in section 3.

      9.  Added examples to some of the syntax descriptions.

      10. Added NAME option to the syntax description ABNF
          in 2.2.4.

          RESCINDED IN -01!!

      11. Added a note deprecating the UTCTime attribute syntax
          description in 3.41
      12. In the ABNF of the MatchingRuleDescription in paragraph 2.3.2,
          replaced "numericoid" with "oid".

      13. In paragraph 2.4.1, replaced the conformance statement about
          attributes in 2256 with a reference.

      14. Added caseIgnoreIA5Match as the EQUALITY matching rule for
          the altServer attribute type ABNF in paragraph 5.1.  Note that
          this could be caseExactIA5Match instead.  SHOULD IT BE??

          RESCINDED IN -01

      15. In paragraphs 5.10 and 5.11, changed "the MODIFY operation"
          to "LDAP update operations"

      16. Added distinguishedNameMatch as the EQUALITY matching rule
          for the namingContexts attribute type ABNF in paragraph 5.13.

          RESCINDED IN -01

      17. Reworded paragraph 5.15.

      18. Added distinguishedNameMatch as the EQUALITY matching rule
          for the namingContexts attribute type ABNF in paragraph 5.13.

          RESCINDED IN -01

      19. Added integerMatch as the EQUALITY and integerOrderingMatch
          as the Ordering matching rules for the supportedLDAPVersion
          attribute type ABNF in paragraph 5.18.

          RESCINDED IN -01

      20. Added caseIgnoreMatch as the EQUALITY matching rule for the
          supportedSASLMechanisms attribute type ABNF in paragraph 5.19.
          Note that this could be caseExactMatch instead.  SHOULD
          IT BE??

          RESCINDED IN -01

      21. Made corrections to the ABNF in paragraph 3.12.

      22. Added the seven syntax definitions from RFC 2256 and ordered
          the definitions alphabetically.

      23. Changed the "Bibliography" section title to "References".

      24. Replaced the X.208 reference with one to X.680(1994), since
          X.680 is the ASN.1 referred to in the X.500(1993)-series.

-------
-01 changes

      25. Moved the table listing the syntaxes and their oids from
          paragraph 2.2.3 to a new Annex A.

          REMOVED SYNTAXES NOT DEFINED IN THIS I-D FROM THE LIST - 02

      26. Moved the specification of the octetStringMatch matching rule
          from RFC 2256 to section 4 of this document.

      27. Throughout this I-D, cleaned up whitespace in the ABNF definitions.

      28. In Section 2.1:
             * Corrected the characters defined in the p rule to match
               the PrintableString syntax.
             * Deleted the letterstring rule.
             * Modified the utf8 and dstring rules according to a
               suggestion from K. Zeilenga.
             * Deleted ";" from the k keychar rule, which affects the
               anhstring, keystring, and descr rules.
             * Removed the length option from the numericoid rule

      29. In section 2.2, deleted the sentence about needing a new OID
          when a syntax is modified.

      30. In section 2.2, replaced the editor's proposal and subject
          text with explanation of the native LDAP LDAP-specific encoding of
          attribute values.

      31. Removed section 2.2.2 (and renumbered the remainder of
          section 2.2), leaving the description of binary encoding to
          the protocol I-D.

-------
-02 changes

      32. Revised specifications to use ABNF [ABNF] instead of BNF
          throughout the docment. document.

      33. Removed embedded comments from the ABNF productions
          throughout the document.

      34. Removed the Binary syntax because it was not adequately
          specified, implementations with different interpretations
          exist, and it was confused with the ;binary transfer encoding.

      35. Removed the syntaxes, which are not defined in this document,
          from the list in Annex A.  Consult RFC 2252 for the
          assignments made previously for syntaxes that have not been
          defined to date.

      36. Inserted the specification of the octetstring production, from
          RFC 2234 [ABNF].j
      37. Cleaned up the references;  adopted word instead of number
          tags;  split Section 10 into normative and non-normative informative
          subsections.

      38. Inserted ABNF from RFC 1278 in place of a reference.

      38.

      39. Deleted the certificate-related syntaxes and noted in the
          Security Considerations (Section 7) that they are covered
          in PKIX WG documents.

-------
-03 changes

   40. Removed all discussion of transfer options and the binary option.

   41. Aligned the text to the [MODELS] document.