INTERNET-DRAFT                                          K. Dally,                                           S. Legg, Editor
draft-ietf-ldapbis-syntaxes-04.txt                   Adacel Technologies
Intended Category: Standard Track                       The MITRE Corp.
Expires:  4 May 2003                                             S. Legg                               K. Dally
Obsoletes: RFC 2252, RFC 2256                                    ADACEL
                                                         4 November                            The MITRE Corp.
                                                        20 December 2002

                   LDAP: Syntaxes
                    <draft-ietf-ldapbis-syntaxes-03> and Matching Rules

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

   Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of 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 editor <kdally@mitre.org>. RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.
   Internet-Drafts.

   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." progress".

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.
   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

   This document is intended to be, after appropriate review and
   revision, submitted to the end RFC Editor as a Standard Track document.
   Distribution of this document for
   more information. is unlimited.  Technical discussion of
   this document should take place on the IETF LDAP Revision Working
   Group (LDAPbis) mailing list <ietf-ldapbis@openldap.org>.  Please
   send editorial comments directly to the editor
   <steven.legg@adacel.com.au>.

   This Internet-Draft expires on 20 June 2003.

Abstract

   The

   Each attribute stored in a Lightweight Directory Access Protocol
   (LDAP) [Protocol] provides
   for exchanging AttributeValue fields in protocol.  This document
   defines a set of syntaxes for LDAP, rules by which attribute directory, and whose values
   of these syntaxes are represented may be transfered in the LDAP
   protocol, and the
   matching rules has a defined syntax which specify how constrains the structure and
   format of its values.  The comparison semantics for values of a
   syntax are compared.  Also, this
   document indicates not part of the syntax support requirements on LDAP servers.
   The syntaxes and definition but are instead provided
   through separately defined matching rules.  Matching rules defined in this document are used in
   schema definition documents to specify attribute types.

   [Editor's note: an
   argument, an assertion value, which also has a defined syntax.  This
   document is defines a modified version of parts base set of
   RFC 2252 syntaxes and RFC 2256, in order to bring then up to date.  This
   action is part of the maintenance activity that is needed matching rules for use in order
   to progress
   defining attributes for 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] directories.

1. Table of Contents

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

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

      Abstract ......................................................  1
   1.  Overview...........................................................5 Table of Contents .............................................  3
   2.  General Issues.....................................................5
2.1  Notation..........................................................5
2.2  Syntaxes..........................................................5
2.2.1  LDAP-Specific Encodings.........................................6
2.2.2 Introduction ..................................................  4
   3. Conventions ...................................................  5
   4. Syntaxes Implementation Status..................................6
2.2.3  Syntax Object Identifiers.......................................6
2.2.4 ......................................................  5
      4.1 General Considerations ....................................  5
      4.2 Common Definitions ........................................  6
      4.3 Syntax Description..............................................6
2.3  Matching Rules....................................................7
2.3.1  Matching Rules Implementation Status............................7
2.3.2  Matching Rule Description.......................................7

3.  Syntaxes...........................................................8
3.1 Definitions ........................................  7
         4.3.1 Attribute Type Description........................................8
3.2 Description ...........................  7
         4.3.2 Bit String........................................................8
3.3  Boolean...........................................................8
3.4 String ...........................................  7
         4.3.3 Boolean ..............................................  8
         4.3.4 Country String....................................................9
3.5 String .......................................  8
         4.3.5 Delivery Method...................................................9
3.6 Method ......................................  9
         4.3.6 Directory String..................................................9
3.7 String .....................................  9
         4.3.7 DIT Content Rule Description.....................................10
3.8 Description ......................... 10
         4.3.8 DIT Structure Rule Description...................................11
3.9  DN...............................................................11
3.10 Description ....................... 11
         4.3.9 DN ................................................... 11
         4.3.10 Enhanced Guide...................................................12
3.11 Guide ...................................... 12
         4.3.11 Facsimile Telephone Number.......................................12
3.12 Fax..............................................................13
3.13 Number .......................... 13
         4.3.12 Fax ................................................. 13
         4.3.13 Generalized Time.................................................13
3.14 Guide............................................................13
3.15 Time .................................... 14
         4.3.14 Guide ............................................... 15
         4.3.15 IA5 String.......................................................14
3.16 Integer..........................................................14
3.17 JPEG.............................................................14
3.18 String .......................................... 15
         4.3.16 Integer ............................................. 16
         4.3.17 JPEG ................................................ 16
         4.3.18 LDAP Syntax Description..........................................15
3.19 Description ............................. 16
         4.3.19 Matching Rule Description........................................15
3.20 Description ........................... 17
         4.3.20 Matching Rule Use Description....................................15
3.21 MHS OR Address...................................................15
3.22 Description ....................... 17
         4.3.21 Name and Optional UID............................................16
3.23 UID ............................... 18
         4.3.22 Name Form Description............................................16
3.24 Description ............................... 18
         4.3.23 Numeric String...................................................16
3.25 String ...................................... 19
         4.3.24 Object Class Description.........................................17
3.26 Description ............................ 19
         4.3.25 Octet String.....................................................17
3.27 OID..............................................................17
3.28 String ........................................ 20
         4.3.26 OID ................................................. 20
         4.3.27 Other Mailbox....................................................18
3.29 Mailbox ....................................... 20
         4.3.28 Postal Address...................................................18
3.30 Presentation Address.............................................19
3.31 Address ...................................... 21
         4.3.29 Printable String.................................................21
3.32 String .................................... 22
         4.3.30 Substring Assertion       .......................................21
3.33 ................................. 22
         4.3.31 Telephone Number.................................................21
3.34 Number .................................... 23
         4.3.32 Teletex Terminal Identifier......................................22

3.35 Identifier ......................... 24
         4.3.33 Telex Number.....................................................22
3.36 Number ........................................ 24
         4.3.34 UTC Time.........................................................23

4.  Matching Rules....................................................23
4.1  bitStringMatch...................................................23
4.2  caseExactIA5Match................................................23
4.3  caseIgnoreIA5Match...............................................24
4.4  caseIgnoreListMatch..............................................24
4.5  caseIgnoreMatch..................................................24
4.6  caseIgnoreOrderingMatch..........................................24
4.7  caseIgnoreSubstringsMatch........................................25
4.8  distinguishedNameMatch...........................................25
4.9  generalizedTimeMatch.............................................25
4.10 generalizedTimeOrderingMatch.....................................25
4.11 integerFirstComponentMatch.......................................25
4.12 integerMatch.....................................................26
4.13 numericStringMatch...............................................26
4.14 numericStringSubstringsMatch.....................................26
4.15 objectIdentifierFirstComponentMatch..............................26
4.16 objectIdentifierMatch............................................26
4.17 octetStringMatch.................................................27
4.18 presentationAddressMatch.........................................27
4.19 protocolInformationMatch.........................................27
4.20 telephoneNumberMatch.............................................28
4.21 telephoneNumberSubstringsMatch...................................28
4.22 uniqueMemberMatch................................................28 Time ............................................ 25
   5.  Security Considerations...........................................28 Matching Rules ................................................ 26
      5.1  Disclosure.......................................................28 General Considerations .................................... 26
      5.2  Security Information Syntaxes....................................28
5.3  Securing the Directory...........................................29 Matching Rule Definitions ................................. 27
         5.2.1 bitStringMatch ....................................... 27
         5.2.2 caseExactIA5Match .................................... 28
         5.2.3 caseIgnoreIA5Match ................................... 28
         5.2.4 caseIgnoreIA5SubstringsMatch ......................... 29
         5.2.5 caseIgnoreListMatch .................................. 29
         5.2.6 caseIgnoreMatch ...................................... 30
         5.2.7 caseIgnoreOrderingMatch .............................. 30
         5.2.8 caseIgnoreSubstringsMatch ............................ 31
         5.2.9 distinguishedNameMatch ............................... 31
         5.2.10 generalizedTimeMatch ................................ 32
         5.2.11 generalizedTimeOrderingMatch ........................ 32
         5.2.12 integerFirstComponentMatch .......................... 32
         5.2.13 integerMatch ........................................ 33
         5.2.14 numericStringMatch .................................. 33
         5.2.15 numericStringSubstringsMatch ........................ 34
         5.2.16 objectIdentifierFirstComponentMatch ................. 34
         5.2.17 objectIdentifierMatch ............................... 35
         5.2.18 octetStringMatch .................................... 35
         5.2.19 telephoneNumberMatch ................................ 36
         5.2.20 telephoneNumberSubstringsMatch ...................... 36
         5.2.21 uniqueMemberMatch ................................... 37
   6.  Acknowledgements..................................................29 Security Considerations ....................................... 37
   7.  Authors' Addresses................................................29 Acknowledgements .............................................. 38
   8.  References........................................................30
8.1  Normative........................................................30
8.2  Informative......................................................31 IANA Considerations ........................................... 38
   9. Full Normative References .......................................... 39
   10. Informative References ....................................... 40
   11. Authors' Addresses ........................................... 41
   12. Copyright Statement..................... .....................31

Annex A Notice ............................................. 41
   Appendix A. Summary of Syntax Object Identifiers for Syntaxes..............................32
Annex B  Topics to be Addressed ................. 42
   Appendix B. Changes from RFC 2252 & RFC 2256 ..................... 43

2. Introduction

   Each attribute stored in This Document......................33
Annex C  Change Log...................................................34

1.  Overview

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

   Schema is the collection of attribute type definitions, object class
   definitions directory [ROADMAP], and other information whose values may be transfered in the
   LDAP protocol [PROT], has a defined syntax (i.e. data type) which specify
   constrains the entries structure and their
   contents that a server holds.  A server uses schema to determine how
   to match a filter or attribute value assertion (in format of its values.  The comparison
   semantics for values of a compare
   operation) against the attributes syntax are not part of an entry, and whether to permit
   add and modify operations.  This document specifies syntaxes, which the syntax
   definition but are used in defining attribute types, and instead provided through separately defined
   matching rules.

   Therefore, Section 2 states the general requirements and notation
   for definition  Matching rules specify an argument, an assertion
   value, which also has a defined syntax.  This document defines a base
   set of syntaxes and matching rules. rules for use in defining attributes for
   LDAP directories.

   Readers are advised to familiarize themselves with the Directory
   Information Models [MODELS] before reading the rest of this document.
   Section 3 lists syntaxes and section 4 contains matching rules.

   Additional documents define schemas for representing real-world
   objects as directory entries.  See [Models], sections 2.4.1 and 2.6
   and [Schema] provides definitions for the base set of LDAP syntaxes.
   Section 5 provides definitions for the base set of matching rules for
   LDAP.

   This document is a integral part of user objects the LDAP technical specification
   [ROADMAP] which obsoletes the previously defined LDAP technical
   specification [RFC3377] in its entirety.

   Sections 4, 5 and attributes 7 of RFC 2252 [RFC2252] are obsoleted by [MODELS].
   The remainder of RFC 2252 is obsoleted by this document.  Sections 6
   and 8 of RFC 2256 are obsoleted by this document.  The changes from
   [X.501], [X.520],
   RFC 2252 and [X.521].

2.  General Issues RFC 2256 [RFC2256] are described in Appendix B of this
   document.

3. Conventions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and  "OPTIONAL" in this
   document are to be interpreted as described in BCP 14 [RFC2119].

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

   Implementors RFC 2119 [KEYWORD].

   Syntax definitions are strongly advised written according to first read the description of
   how schema is represented <SyntaxDescription>
   ABNF [ABNF] rule specified in X.501 [X.501] before reading the rest
   of this document.

2.1  Notation

   For the purposes of defining attribute syntaxes [MODELS], and matching rules,
   Augmented Backus-Naur Form (ABNF) is used.  The ABNF productions
   used in this document rule definitions
   are used by other documents written according to the <MatchingRuleDescription> ABNF rule
   specified in [MODELS], except that the LDAP set syntax and are listed in [Models].

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

   In addition, the following ABNF productions  When such definitions are used in this
   document:

2.2  Syntaxes

   This section defines general requirements for LDAP attribute
   syntaxes.  All documents defining transfered as attribute syntaxes for use with
   values in the LDAP are expected to conform to these requirements. protocol (e.g. as values of the ldapSyntaxes and
   matchingRules attributes [MODELS] respectively) then those values
   would not contain line breaks.

4. Syntaxes are
   also defined for matching rules whose assertion value syntax is
   different from

   Syntax definitions constrain the structure of attribute value syntax.

2.2.1  LDAP-Specific Encodings

   In [Protocol], values stored
   in an LDAP directory, and determine the encoding representation of attribute
   and assertion values transfered in the LDAP protocol is specified.  The
   protcol encapsulates values of attributes protocol.

   Syntaxes that are required for directory operation, or that are in
   common use, are specified in this section.  Servers SHOULD recognize
   all the syntaxes listed in many places.  In this
   specification, document, but are NOT REQUIRED to
   otherwise support them, and MAY recognise or support other syntaxes.
   However, the encoding definition of the values additional arbitrary syntaxes is specified, as part
   discouraged since it will hinder interoperability.  Client and server
   implementations typically do not have the ability to dynamically
   recognize new syntaxes.

4.1 General Considerations
   The description of each syntax definition.  These value encoding rules specifies how attribute or assertion
   values conforming to the syntax are termed
   "LDAP-specific encodings".  The to be represented when transfered
   in the LDAP protocol [PROT].  This representation is referred to as
   the LDAP-specific encoding to distinguish it from other methods of a value is
   what is transmitted in
   encoding attribute values (e.g. the protocol. BER encoding [BER] used by X.500
   [X.500] directories).

   The LDAP-specific encoding of a given attribute syntax always
   produces octet-aligned values.  To the greatest extent possible, the
   LDAP-specific encoding of a value is supposed to be usable for
   display purposes.  In particular,
   encoding rules for attribute LDAP syntaxes defining non-binary values are supposed to should produce character 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 syntaxes listed in
   section 3, and MAY implement other syntaxes.

   Clients  However, clients MUST NOT assume that the
   LDAP-specific encoding of a value of an unrecognized syntax is a
   human-readable character string.

   Other documents define additional attribute syntaxes.  However,  There are a few cases (e.g. the
   definition of additional arbitrary syntaxes is strongly deprecated
   since
   JPEG syntax) when it will hinder interoperability.  Today's client and server
   implementations generally do is not have the ability reasonable to dynamically
   recognize new syntaxes.

2.2.3  Syntax Object Identifiers

   In an LDAP schema, produce a human-readable
   representation.

   Each LDAP syntax is named by the Object Identifier (OID)
   assigned to it.

   Syntaxes that are currently in use uniquely identified with an object identifier
   [ASN.1] represented in the user schema specification
   [Schema] and the models specification [Models] dotted-decimal format (short descriptive
   names are specified in this
   document in section 3.  The not defined for syntaxes).  These object identifiers assigned to these
   syntaxes are listed in Annex A.

2.2.4  Syntax Description

   The SyntaxDescription ABNF specified in [Models] is the method used
   in this document
   not intended to define the values be displayed to users.  The object identifiers for each syntax.

   For example, the syntax 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 syntaxes defined in this document are defined summarized in
   Section 4.

   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 Appendix A.

   A suggested minimum upper bound on the number of characters in an
   attribute value to be added
   or deleted when modifying entries, and are used when comparing a
   purported distinguished name with a string-based syntax, or the name number of an entry.

   Most octets
   in a value for all other syntaxes, MAY be indicated by appending the
   bound inside of curly braces following the attributes given syntax's OBJECT IDENTIFIER
   in the user schema [Schema] have an
   equality matching attribute type definition (see the <noidlen> rule defined.

...An OID is assigned to in [MODELS]).
   Such a matching rule when it bound is defined.  A
   matching rule definition ought not be changed without having a new
   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 considered part of the attributeTypes and
   matchingRuleUse attributes in the same subschema entry.  Other
   unreferenced matching rules MAY be published syntax identifier.

   For example, "1.3.6.1.4.1.1466.115.121.1.15{64}" in an attribute
   definition suggests that the matchingRules
   attribute.

   If the server supports the extensibleMatch, then the directory server MAY use will allow a value of
   the matchingRuleUse attribute to indicate the applicability of
   selected matching rules be up to designated attribute types 64 characters long, although it may allow
   longer character strings.  Note that a single character of the
   Directory String syntax can be encoded in an
   extensibleMatch.

2.3.2  Matching Rule Description more than one octet since
   UTF-8 [UTF-8] is a variable-length encoding.  Therefore a 64
   character string may be more than 64 octets in length.

4.2 Common Definitions

   The SyntaxDescription following ABNF specified rules are used in [Models] is a number of the method used
   The Matching Rule descriptions syntax
   definitions in Section 4.3.

      PrintableCharacter = ALPHA / DIGIT / SQUOTE / LPAREN / RPAREN /
                           PLUS / COMMA / HYPHEN / DOT / EQUALS /
                           SLASH / COLON / QUESTION / SPACE
      PrintableString    = 1*PrintableCharacter
      IA5String          = *(%x00-7F)
      HEX-DIGIT          = DIGIT / "A" / "B" / "C" / "D" / "E" / "F"
                                 ; N.B. allows upper and lower case
      SLASH              = %x2F  ; forward slash ("/")
      COLON              = %x3A  ; colon (":")
      QUESTION           = %x3F  ; question mark ("?")

   The <OCTET>, <ALPHA>, <DIGIT>, <SQUOTE>, <LPAREN>, <RPAREN>, <PLUS>,
   <COMMA>, <HYPHEN>, <DOT>, <EQUALS> and <SPACE> rules are specified according to the
   MatchingRule ABNF specified defined in [Models].

3.  Syntaxes

3.1
   [MODELS].

4.3 Syntax Definitions

4.3.1 Attribute Type Description

   A value in this of the Attribute Type Description syntax is a the definition of
   an attribute type
   according to the ABNF given [Models]. type.  The LDAP-specific encoding of a value of this
   syntax is defined by the character codes <AttributeTypeDescription> rule in UTF-8 which correspond to [MODELS].
   For example, the characters in following definition of the definition.

   This syntax createTimestamp
   attribute type from [MODELS] is also a value of the form in which schema attribute types 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.3 DESC 'Attribute Attribute Type Description' )

   For example, this is the definition from [User]
   Description syntax (note: line breaks have been added for readability
   - they are not part of the
   businessCategory attribute type: value when transfered in protocol).

      ( 2.5.4.15 2.5.18.1 NAME 'businessCategory' 'createTimestamp'
         EQUALITY caseIgnoreMatch
     SUBSTR caseIgnoreSubstringsMatch generalizedTimeMatch
         ORDERING generalizedTimeOrderingMatch
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{128} 1.3.6.1.4.1.1466.115.121.1.24
         SINGLE-VALUE NO-USER-MODIFICATION
         USAGE directoryOperation )

   The syntax type for the businessCategory Attribute Type is Directory
   String.

   This example LDAP definition is a value of for the Attribute Type Description
   syntax.  The LDAP-specific encoding of this value is syntax is:

      ( 1.3.6.1.4.1.1466.115.121.1.3 DESC 'Attribute Type Description' )

   This syntax corresponds to the definition
   itself.

3.2 AttributeTypeDescription ASN.1 type
   from [X.501].

4.3.2 Bit String

   A value in this of the Bit String syntax is a value sequence of the BIT STRING data type from
   ASN.1 [X.680].  The following syntax description gives the OID
   assigned to this syntax:

      ( 1.3.6.1.4.1.1466.115.121.1.6 DESC 'Bit String' ) binary digits.  The
   LDAP-specific encoding of a value of this syntax is defined by the
   following ABNF:

      bitstring

      BitString    = SQUOTE *binary-digit SQUOTE "B"
      binary-digit = "0" / "1"
   The <SQUOTE> rule is defined in [MODELS].

      Example:
         '0101111101'B

3.3  Boolean

   A value in this

   The LDAP definition for the Bit String syntax is a value of is:

      ( 1.3.6.1.4.1.1466.115.121.1.6 DESC 'Bit String' )

   This syntax corresponds to the BOOLEAN data BIT STRING ASN.1 type from
   ASN.1 [X.680].  That is, there are exactly two values:  one [ASN.1].

4.3.3 Boolean

   A value
   representing logically true, and of the other representing logically
   false.  The following Boolean syntax description gives is one of the OID assigned to
   this syntax:

      ( 1.3.6.1.4.1.1466.115.121.1.7 DESC 'Boolean' ) Boolean values, true or
   false.  The LDAP-specific encoding of a value of this syntax is
   defined by the following ABNF:

      boolean

      Boolean = "TRUE" / "FALSE"

3.4

   The LDAP definition for the Boolean syntax is:

      ( 1.3.6.1.4.1.1466.115.121.1.7 DESC 'Boolean' )

   This syntax corresponds to the BOOLEAN ASN.1 type from [ASN.1].

4.3.4 Country String

   A value in this of the Country String syntax is two ASN.1 [X.680] printable string characters one of the two-character
   codes from ISO 3166 [ISO3166] for representing a country.  The permitted values are as listed in
   ISO 3166 [ISO3166].  The following syntax description gives the OID
   assigned to this syntax:

      ( 1.3.6.1.4.1.1466.115.121.1.11 DESC 'Country String' )

   The
   LDAP-specific encoding of a value of this syntax is defined by the
   following ABNF:

      CountryString  = ALPHA ALPHA

      Example: 2(PrintableCharacter)

   The <PrintableCharacter> rule is defined in Section 4.2.

      Examples:
         US

3.5
         AU

   The LDAP definition for the Country String syntax is:

      ( 1.3.6.1.4.1.1466.115.121.1.11 DESC 'Country String' )

   This syntax corresponds to the following ASN.1 type from [X.520]:

      PrintableString (SIZE (2)) -- IS 3166 codes only

4.3.5 Delivery Method

   A value in this of the Delivery Method syntax is a set sequence of the ASN.1 [X.680] enumerated
   INTEGER values items that indicates,
   indicate, in preference order, the service(s) by which the user, represented by the entry, an entity is
   willing and/or capable of receiving messages.  The following syntax description gives the OID assigned to this
   syntax:

      ( 1.3.6.1.4.1.1466.115.121.1.14 DESC 'Delivery Method' )

   The LDAP-specific
   encoding of a value of this syntax is defined by the following ABNF:

      delivery-value

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

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

   The <WSP> and <DOLLAR> rules are defined in [MODELS].

      Example:
         telephone $ videotex

3.6

   The LDAP definition for the Delivery Method syntax is:

      ( 1.3.6.1.4.1.1466.115.121.1.14 DESC 'Delivery Method' )

   This syntax corresponds to the following ASN.1 type from [X.520]:

      SEQUENCE OF INTEGER {
          any-delivery-method     (0),
          mhs-delivery            (1),
          physical-delivery       (2),
          telex-delivery          (3),
          teletex-delivery        (4),
          g3-facsimile-delivery   (5),
          g4-facsimile-delivery   (6),
          ia5-terminal-delivery   (7),
          videotex-delivery       (8),
          telephone-delivery      (9) }

4.3.6 Directory String

   A value in this of the Directory String syntax is a value string of one of the TeletexString,
   PrintableString or UniversalString data types more
   arbitrary characters from ASN.1 [X.680].
   The minimum length of a Directory String value is one character, that
   is, the Universal Character Set (UCS) [UCS].  A
   zero length character string cannot be 'empty'.  The following syntax description
   gives the OID assigned to this syntax:

      ( 1.3.6.1.4.1.1466.115.121.1.15 DESC 'Directory String' ) is not permitted.  The LDAP-specific
   encoding of a value of this syntax is the character string itself.

   Note:  The form UTF-8 encoding [UTF-8] of
   the character string.  Such encodings conform to the following ABNF:

      DirectoryString = 1*UTF8
   The <UTF8> rule is not indicated defined in protocol.
   Servers which convert to DAP MUST choose an appropriate form.
   Servers MUST NOT reject values merely because they contain legal
   Unicode characters outside of the range [MODELS].

      Example:
         This is a value of printable ASCII. Directory String containing #!%#@.

   Servers and clients MUST be prepared to receive arbitrary Unicode
   characters, UCS code
   points, including characters not presently assigned code points outside the range of printable ASCII
   and code points not presently assigned to any character.

   Attribute type definitions using the Directory String syntax should
   not restrict the format of Directory String values, e.g. by requiring
   that the character set.

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

   For characters conforms to specific patterns described by
   ABNF.  A new syntax should be defined in such cases.

   The LDAP definition for the Directory String syntax is:

      ( 1.3.6.1.4.1.1466.115.121.1.15 DESC 'Directory String' )

   This syntax corresponds to the DirectoryString parameterized ASN.1
   type from [X.520].

   The DirectoryString ASN.1 type allows a choice between the
   TeletexString, PrintableString form, or UniversalString ASN.1 types from
   [ASN.1].  However, note that the value chosen alternative is not indicated
   in the native
   LDAP LDAP-specific encoding is the value itself.

   If of a Directory String value.

   Implementations which convert Directory String values from the string is in
   LDAP-specific encoding to the TeletexString form, then BER encoding used by X.500 must choose
   an alternative that permits the particular characters are
   transliterated to their equivalents in UniversalString, the string,
   and encoded
   in UTF-8 [RFC2044].

   If must convert the string is in characters from the UniversalString or BMPString forms [ISO10646], UTF-8 is encoding into the
   character encoding of the chosen alternative.

   When converting Directory String values from the BER encoding to the
   LDAP-specific encoding the characters must be converted from the
   character encoding of the chosen alternative into the UTF-8 encoding.

3.7

4.3.7 DIT Content Rule Description

   The following syntax description gives

   A value of the OID assigned to this
   syntax:

      ( 1.3.6.1.4.1.1466.115.121.1.16 DESC 'DIT DIT Content Rule
         Description' )

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

   A value in this syntax is a definition
   of a DIT content rule
   according to the ABNF in [Models]. rule.  The native LDAP LDAP-specific encoding of a value is the character string
   (DirectoryString) itself.

   Note:  The form of DirectoryString this
   syntax is not indicated in protocol,
   unless defined by the ;binary option is used (see [Prot]).  Servers which
   convert to DAP MUST choose an appropriate form.  Servers MUST NOT
   reject values merely because they contain legal Unicode characters
   outside of the range of printable ASCII.

   Servers and clients MUST be prepared to receive arbitrary Unicode
   characters, including characters not presently assigned to any
   character set. <DITContentRuleDescription> rule in
   [MODELS].

      Example:
      This is
         ( 2.5.6.4 DESC 'content rule for organization'
            NOT ( x121Address $ telexNumber ) )
   Note: a string of DirectoryString containing #!%#@.

   For characters in the PrintableString form, the value in the native
   LDAP encoding is the value itself.

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

   If line break has been added for readability - it is in the UniversalString or BMPString forms [ISO10646], UTF-8
   is not part of
   the native value.

   The LDAP encoding.

3.8 definition for the DIT Structure Content Rule Description

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

      ( 1.3.6.1.4.1.1466.115.121.1.17 1.3.6.1.4.1.1466.115.121.1.16
         DESC 'DIT Structure Content Rule Description' )

   This syntax is the form in which schema structure rules are published
   in corresponds to the directory in a subentry. DITContentRuleDescription ASN.1 type
   from [X.501].

4.3.8 DIT Structure Rule Description

   A value in of the DIT Structure Rule Description syntax is a the
   definition of a schema Structure Rule according to the ABNF in [Models]. DIT structure rule.  The LDAP-specific encoding of a
   value of this syntax is defined by the character codes <DITStructureRuleDescription>
   rule in UTF-8 [UTF-8]
   which correspond to [MODELS].

      Example:
         ( 2 DESC 'organization structure rule' FORM 2.5.15.3 )

   The LDAP definition for the characters in DIT Structure Rule Description syntax is:

      ( 1.3.6.1.4.1.1466.115.121.1.17
         DESC 'DIT Structure Rule Description' )

   This syntax corresponds to the structure rule definition.

3.9 DITStructureRuleDescription ASN.1 type
   from [X.501].

4.3.9 DN

   A value in the Distinguished Name syntax is a structured set of the
   ASN.1 [X.680] data types that are included in the DirectoryString
   syntax.  The following DN syntax description gives is the OID assigned to
   this syntax:

      ( 1.3.6.1.4.1.1466.115.121.1.12 DESC 'DN' ) (purported) distinguished name of an
   entry [MODELS].  The LDAP-specific encoding of a value of this syntax
   is defined by the <distinguishedName> rule in [LDAPDN].  Note
   that the LDAP-specific encoding

      Examples (from [LDAPDN]):
         UID=jsmith,DC=example,DC=net
         OU=Sales+CN=J. Smith,DC=example,DC=net
         CN=John Smith\, III,DC=example,DC=net
         CN=Before\0dAfter,DC=example,DC=net
         1.3.6.1.4.1.1466.0=#04024869,DC=example,DC=com
         CN=Lu\C4\8Di\C4\87

   The LDAP definition for the DN syntax is:

      ( 1.3.6.1.4.1.1466.115.121.1.12 DESC 'DN' )
   The DN syntax corresponds to the DistinguishedName ASN.1 type from
   [X.501].  Note that a BER encoded distinguished name (as used by
   X.500) re-encoded into the LDAP-specific encoding is not necessarily
   reversible to the original BER encoding used in X.500 for Distinguished Names, as since the CHOICE of chosen string type
   in any DirectoryString element in an RDN components of the distinguished name is not evident
   indicated in the LDAP-specific
   encoding..  See encoding of the note in 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 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 distinguished name
   (see Section 4.3.6).

4.3.10 Enhanced Guide

   A value in of the Enhanced Guide syntax is the matching criteria and
   scope suggests criteria, which consist
   of combinations of operation attribute types and filter operators, to be used
   in an Enhanced Filter. constructing filters to search for entries of particular object
   classes.  The following Enhanced Guide syntax description gives improves upon the OID assigned Guide syntax by
   allowing the recommended depth of the search to this syntax:

      ( 1.3.6.1.4.1.1466.115.121.1.21 DESC 'Enhanced Guide' ) be specified.

   The LDAP-specific encoding of a value of this syntax is defined by
   the following ABNF:

      EnhancedGuide = SP oid WSP object-class SHARP WSP criteria WSP
                         SHARP WSP subset
      object-class  = WSP oid WSP
      subset        = "baseobject" / "oneLevel" / "wholeSubtree"

      criteria   = or-term / LPAREN or-term RPAREN

      or-term = and-term *( "|" BAR and-term )
      and-term   = not-term term *( "&" not-term AMPERSAND term )

      not-term
      term       = "!" not-term EXCLAIM term /
                   attributetype DOLLAR match-type /
                   LPAREN or-term criteria RPAREN /
                 "?true"
                   true / ;
                 "?false"
                   false
      match-type = "EQ" / "SUBSTR" / "GE" / "LE" / "APPROX"
      true       = "?true"
      false      = "?false"
      BAR        = %x7C  ; vertical bar ("|")
      AMPERSAND  = %x26  ; ampersand ("&")
      EXCLAIM    = %x21  ; exclamation mark ("!")

   The <SHARP>, <WSP>, <oid>, <LPAREN>, <RPAREN>, <attributetype> and
   <DOLLAR> rules are defined in [MODELS].

   The ?true term alternative LDAP definition for the Enhanced Guide syntax is:

      ( 1.3.6.1.4.1.1466.115.121.1.21 DESC 'Enhanced Guide' )

      Example:

         person#(sn$EQ)#oneLevel

   The Enhanced Guide syntax corresponds to the EnhancedGuide ASN.1 type
   from [X.520].  The EnhancedGuide type references the Criteria ASN.1
   type, also from [X.520].  The <true> rule above represents an empty
   "and" expression in a value of the Criteria. Criteria type.  The ?false alternative <false> rule
   above represents an empty "or" expression in a value of the Criteria.

   Example:

      person#(sn)#oneLevel

3.11 Criteria
   type.

4.3.11 Facsimile Telephone Number

   A value in of the Facsimile Telephone Number syntax is a subscriber
   number on the (public) telephone network of a facsimile device.  The
   telephone number is a character string based device on E.123 [E.123].  The
   character string type is the PrintableString data type from
   ASN.1 [X.680].  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') public switched telephone
   network.  The LDAP-specific encoding of a value of this syntax is
   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 telephone-number *( DOLLAR fax-parameter )

      faxparm
      telephone-number = PrintableString
      fax-parameter    = "twoDimensional" /
                         "fineResolution" /
                         "unlimitedLength" /
                         "b4Length" /
                         "a3Width" /
                         "b4Width" /
                         "uncompressed"

3.12

   The <telephone-number> is a string of printable characters that
   complies with the internationally agreed format for representing
   international telephone numbers [E.123].  The <PrintableString> rule
   is defined in Section 4.2.  The <DOLLAR> rule is defined in [MODELS].

   The LDAP definition for the Facsimile Telephone Number syntax is:

      ( 1.3.6.1.4.1.1466.115.121.1.22 DESC 'Facsimile Telephone Number')

   The Facsimile Telephone Number syntax corresponds to the
   FacsimileTelephoneNumber ASN.1 type from [X.520].

4.3.12 Fax

   A value in of the Fax syntax is an image which is produced using the
   Group 3 facsimile process [Fax] [FAX] to duplicate an object, such as a
   memo.  The following LDAP-specific encoding of a value of this syntax description gives is the OID assigned to this
   syntax:
   string of octets for a Group 3 Fax image as defined in [FAX].

   The LDAP definition for the Fax syntax is:

      ( 1.3.6.1.4.1.1466.115.121.1.23 DESC 'Fax' )

   Values in this

   The ASN.1 type corresponding to the Fax syntax are expressed is defined as octet strings containing
   Group 3 follows,
   assuming EXPLICIT TAGS:

      Fax images as ::= CHOICE {
        g3-facsimile  [3] G3FacsimileBodyPart
      }

   The G3FacsimileBodyPart ASN.1 type is defined in [Fax].

3.13 [X.420].

4.3.13 Generalized Time

   A value in of the Generalized Time syntax is a character string
   representing a 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.24 DESC 'Generalized Time' )

   The LDAP-specific encoding is of a value
   of the GeneralizedTime data type
   from 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 Greenwich
      Mean Time time zone.

3.14  Guide

   A value in the Guide this syntax is a restriction of the matching criteria format defined in a Filter.

   The following syntax description gives [ISO8601],
   and is described by the OID assigned following ABNF:

      century = 2(%x30-39) ; "00" to this
   syntax: "99"
      year    = 2(%x30-39) ; "00" to "99"
      month   =   ( 1.3.6.1.4.1.1466.115.121.1.25 DESC 'Guide' %x30 %x31-39 )
   The Guide syntax is not intended ; "01" (January) to "09"
                / ( %x31 %x30-32 ) ; "10" to "12"
      day     =   ( %x30 %x31-39 )    ; "01" to "09"
                / ( %x31-32 %x30-39 ) ; "10" to "29"
                / ( %x32 %x30-31 )    ; "30" to "31"
      hour    = ( %x30-31 %x30-39 ) / ( %x32 %x30-33 ) ; "00" to "23"
      minute  = %x30-36 %x30-39                        ; "00" to "59"
      second  = %x30-36 %x30-39                        ; "00" to "59"

      GeneralizedTime = century year month day hour
                           [ minute [ second ] ] [ fraction ]
                           g-time-zone
      fraction        = ( DOT / COMMA ) 1*(%x30-39)
      g-time-zone     = %x5A  ; "Z"
                        / g-differential
      g-differential  = ( MINUS / PLUS ) hour [ minute ]
      MINUS           = %x2D  ; minus sign ("-")

   The <DOT>, <COMMA> and <PLUS> rules are defined in [MODELS].

   The time value represents coordinated universal time (equivalent to
   Greenwich Mean Time) if the "Z" form of <g-time-zone> is used,
   otherwise the value represents a local time in the time zone
   indicated by <g-differential>.  In the latter case, coordinated
   universal time can be calculated by subtracting the differential from
   the local time.  The "Z" form of <g-time-zone> SHOULD be used in
   preference to <g-differential>.

      Examples:
         199412161032Z
         199412160532-0500

   Both example values represent the same coordinated universal time:
   40:32 am, December 16, 1994.

   The LDAP definition for defining new
   attributes.  It is important for backwards compatibility the Generalized Time syntax is:

      ( 1.3.6.1.4.1.1466.115.121.1.24 DESC 'Generalized Time' )

   This syntax corresponds to the GeneralizedTime ASN.1 type from
   [ASN.1], with LDAP
   systems the constraint that implement an earlier version local time without a differential
   SHALL NOT be used.

4.3.14 Guide

   A value of LDAP [RFC1778]. the Guide syntax suggests criteria, which consist of
   combinations of attribute types and filter operators, to be used in
   constructing filters to search for entries of particular object
   classes.  The Guide syntax is obsolete and should not be used for
   defining new attribute types.

   The LDAP-specific encoding of a value of this syntax is defined by
   the following ABNF:

      guide-value

      Guide = [ object-class "#" SHARP ] criteria

      object-class = SP oid

   The criteria production <object-class> and <criteria> rules are defined in Section
   4.3.10.  The <SHARP> rule is defined in [MODELS].

   The LDAP definition for the Enhanced Guide syntax in
   section 3.11.

3.15 is:

      ( 1.3.6.1.4.1.1466.115.121.1.25 DESC 'Guide' )

   The Guide syntax corresponds to the Guide ASN.1 type from [X.520].

4.3.15 IA5 String

   A value in of the IA5 String syntax is a value string of the IA5String data
   type zero, one or more
   characters from ASN.1 [X.680]. International Alphabet 5 (IA5) [IA5] is [T.50], 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.27 DESC 'IA5 String' )

   The LDAP-specific
   encoding of a value in of this syntax is the character unconverted string value itself.

3.16 of
   characters, which conforms to the <IA5String> rule in Section 4.2.

   The LDAP definition for the IA5 String syntax is:

      ( 1.3.6.1.4.1.1466.115.121.1.26 DESC 'IA5 String' )

   This syntax corresponds to the IA5String ASN.1 type from [ASN.1].

4.3.16 Integer

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

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

      ( 1.3.6.1.4.1.1466.115.121.1.27 DESC 'INTEGER' ) of unlimited
   magnitude.  The LDAP-specific encoding of a value of this syntax is
   the optionally signed decimal digit character string representation
   of the value, with each decimal digit represented by the its character
   equivalent.  So, number (so, for example, the number 1321 is represented by the
   character string "1321".

3.17 "1321").  The encoding is defined by the following
   ABNF:

      Integer = [ HYPHEN ] number

   The <HYPHEN> and <number> rules are defined in [MODELS].

   The LDAP definition for the Integer syntax is:

      ( 1.3.6.1.4.1.1466.115.121.1.27 DESC 'INTEGER' )

   This syntax corresponds to the INTEGER ASN.1 type from [ASN.1].

4.3.17 JPEG

   A value in of the JPEG syntax is an image produced according to
   specific rules for light values.  The following syntax description
   gives in the OID assigned to this syntax:

      ( 1.3.6.1.4.1.1466.115.121.1.28 DESC 'JPEG' ) JPEG File Interchange
   Format (JFIF), as described in [JPEG].  The LDAP-specific encoding of
   a value of this syntax is an octet string the sequence of octets of the
   light values representing JFIF encoding
   of the image.

3.18

   The LDAP definition for the JPEG syntax is:

      ( 1.3.6.1.4.1.1466.115.121.1.28 DESC 'JPEG' )

   The JPEG syntax corresponds to the following ASN.1 type:

      JPEG ::= OCTET STRING (CONSTRAINED BY
                   { -- contents octets are an image in the --
                     -- JPEG File Interchange Format -- })

4.3.18 LDAP Syntax Description

   A value in of the LDAP Syntax Description syntax is a definition the description of a
   an LDAP syntax.  The LDAP-specific encoding of a value of this syntax description according to
   is defined by the ABNF given <SyntaxDescription> rule in [MODELS].

   This syntax is

   The LDAP definition for the form in which schema syntax descriptions are
   published in the directory in a subentry.  The following LDAP Syntax Description syntax
   description gives the OID assigned to this syntax: is:

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

   The LDAP-specific encoding above LDAP definition for the LDAP Syntax Description syntax is
   itself a legal value of the character codes in UTF-8 [ISO10646]
   which correspond LDAP Syntax Description syntax.

   The ASN.1 type corresponding to the characters LDAP Syntax Description syntax is
   defined as follows, assuming EXPLICIT TAGS:

      LDAPSyntaxDescription ::= SEQUENCE {
          identifier      OBJECT IDENTIFIER,
          description     DirectoryString { ub-schema } OPTIONAL }

   The DirectoryString parameterized ASN.1 type is defined in the definition.

3.19 [X.520].
   The value of ub-schema is implementation defined.

4.3.19 Matching Rule Description

   A value in of the Matching Rule Description syntax is a the definition of
   a matching rule according to the ABNF given in [MODELS].  This rule.  The LDAP-specific encoding of a value of this
   syntax is defined by the form in which schema matching rules are published in the
   directory <MatchingRuleDescription> rule in [MODELS].

      Example:
         ( 2.5.13.2 NAME 'caseIgnoreMatch'
            SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

   Note: a subentry. line break has been added for readability - it is not part of
   the syntax.

   The following syntax LDAP definition gives for the
   OID assigned to this syntax: Matching Rule Description syntax is:

      ( 1.3.6.1.4.1.1466.115.121.1.31 1.3.6.1.4.1.1466.115.121.1.30 DESC 'Matching Rule Description' )

   The LDAP-specific encoding is the character codes in UTF-8 [ISO10646]
   which correspond

   This syntax corresponds to the characters in the definition of a Matching
   Rule.

3.20 MatchingRuleDescription ASN.1 type
   from [X.501].

4.3.20 Matching Rule Use Description

   A value in of the Matching Rule Use Description syntax is a definition
   of a matching Rule and indicates the
   attribute types with to which the a matching rule could may be used applied in an
   extensibleMatch search filter. filter [PROT].  The values are
   specified according to LDAP-specific encoding of
   a value of this syntax is defined by the ABNF given <MatchingRuleUseDescription>
   rule in [MODELS].

      Example:

         ( 2.5.13.16 APPLIES ( givenName $ surname ) )

   The following
   syntax description gives LDAP definition for the OID assigned to this syntax: Matching Rule Use Description syntax is:

      ( 1.3.6.1.4.1.1466.115.121.1.31
         DESC 'Matching Rule Use Description' )

   This syntax corresponds to the MatchingRuleUseDescription ASN.1 type
   from [X.501].

4.3.21 Name and Optional UID

   A value of the Name and Optional UID syntax is the form in which schema matching rule usage
   permissions are published in the directory in a subentry.

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

3.21  MHS OR Address

   A value in the MHS OR Address syntax is the addressing information of
   a user distinguished name
   [MODELS] of an X.400 messaging service.  The LDAP-specific encoding is
   defined in RFC 1327 [RFC1327].

   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.9 plus entity optionally accompanied by a bit string unique identifier
   that differentiates serves to differentiate the value entity from otherwise others with an identical names.     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' )
   distinguished name.

   The LDAP-specific encoding of a value of this syntax is defined by
   the following ABNF:

      NameAndOptionalUID = DistinguishedName distinguishedName [ "#" bitstring SHARP BitString ]

   Although

   The <BitString> rule is defined in Section 4.3.2.  The
   <distinguishedName> rule is defined in [LDAPDN].  The <SHARP> rule is
   defined in [MODELS].

   Note that although the '#' character could may occur in a the string
   representation of a distinguished name, no additional special quoting escaping of
   this character is performed when a <distinguishedName> is done. encoded in
   a <NameAndOptionalUID>.

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

3.23

   The LDAP definition for the Name and Optional UID syntax is:

      ( 1.3.6.1.4.1.1466.115.121.1.34 DESC 'Name And Optional UID' )

   This syntax corresponds to the NameAndOptionalUID ASN.1 type from
   [X.520].

4.3.22 Name Form Description

   A value in of the Name Form Description syntax is a the definition of a
   Name Form according to the ABNF given in [MODELS].

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

   This syntax is the form in which schema
   name forms are published in
   the directory. form, which regulates how entries may be named.  The
   LDAP-specific encoding of a value of this syntax is defined by the
   character codes in UTF-8 [ISO10646] which correspond to the
   characters
   <NameFormDescription> rule in the definition. [MODELS].

      Example:
         ( 2.5.15.3 NAME 'orgNameForm' OC organization MUST o )

   The following syntax description gives LDAP definition for the OID assigned to this
   syntax: Name Form Description syntax is:

      ( 1.3.6.1.4.1.1466.115.121.1.35 DESC 'Name Form Description' )

3.24

   This syntax corresponds to the NameFormDescription ASN.1 type from
   [X.501].

4.3.23 Numeric String

   A value in of the Numeric String syntax is a series sequence of one or more
   numerals and
   spaces as specified in spaces.  The LDAP-specific encoding of a value of this
   syntax is the unconverted string of characters, which conforms to the
   following ABNF:

      NumericString data type from
   ASN.1 [X.680]. = 1*(DIGIT / SPACE)

   The following string states <DIGIT> and <SPACE> rules are defined in [MODELS].

      Example:
         15 079 672 281

   The LDAP definition for the OID assigned to
   this syntax: Numeric String syntax is:

      ( 1.3.6.1.4.1.1466.115.121.1.36 DESC 'Numeric String' )
   The representation of a string in this

   This syntax is corresponds to the string value
   itself.

   Example:  1997

3.25 NumericString ASN.1 type from [ASN.1].

4.3.24 Object Class Description

   A value in this of the Object Class Description syntax is a character string which expresses the definition of
   an object class according to the ABNF given in
   [MODELS].  This syntax is the form in which schema object classes
   are published in the directory in a subentry. class.  The following string
   states the OID assigned to LDAP-specific encoding of a value of 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
   syntax is defined by the
   searchGuide and description attributes.  All of these schema
   elements are specified <ObjectClassDescription> rule in [Schema]. [MODELS].

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

3.26

   Note: a line break has been added for readability - it is not part of
   the syntax.

   The LDAP definition for the Object Class Description syntax is:

      ( 1.3.6.1.4.1.1466.115.121.1.37 DESC 'Object Class Description' )

   This syntax corresponds to the ObjectClassDescription ASN.1 type from
   [X.501].

4.3.25 Octet String

   A value in of the Octet String syntax is a value sequence of the OCTET STRING
   data type from ASN.1 [X.680]. zero, one or more
   arbitrary octets.  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 LDAP-specific encoding of a value of this
   syntax are written as a series is the unconverted sequence of 8-bit values,
   according octets, which conforms to the octet string value notation specified
   following ABNF:

      OctetString = *OCTET

   The <OCTET> rule is defined in [X.680].
   In the case [MODELS].  Values of character strings, this syntax are
   not generally human-readable.

   The LDAP definition for the characters themselves could be
   written.

   Example:
      secret

3.27 Octet String syntax is:

      ( 1.3.6.1.4.1.1466.115.121.1.40 DESC 'Octet String' )

   This syntax corresponds to the OCTET STRING ASN.1 type from [ASN.1].

4.3.26 OID

   A value in of the Object Identifier OID syntax is an object identifier; a series sequence of integers,
   ordered as specified two
   or more non-negative integers that uniquely identify some object or
   item of specification.  Many of the object identifiers used in LDAP
   also have IANA registered names [RFC3383].

   The LDAP-specific encoding of a value of this syntax is defined by
   the OBJECT IDENTIFIER data type from ASN.1
   [X.680]. <oid> rule in [MODELS].

      Examples:
         1.2.3.4
         cn

   The following string states LDAP definition for the OID assigned to this
   syntax: syntax is:

      ( 1.3.6.1.4.1.1466.115.121.1.38 DESC 'OID' )

   Values in this

   This syntax are expressed according corresponds to the ABNF in
   [MODELS], section 1.3 for "oid".

   Examples:  1.2.3.4
              cn

3.28 OBJECT IDENTIFIER ASN.1 type from
   [ASN.1].

4.3.27 Other Mailbox
   A value in of the Other Mailbox syntax gives identifies an electronic mailbox,
   in a particular named 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 LDAP-specific encoding of a
   value of this syntax are written according to is defined by the following ABNF:

      otherMailbox

      OtherMailbox = mailbox-type DOLLAR mailbox
      mailbox-type = printableString PrintableString
      mailbox      = <an encoded IA5 String> IA5String

   The printableString production is defined in section 3.11.

   In the above, mailbox-type <mailbox-type> rule represents the type of mail system in which
   the mailbox resides, for example "MCIMail"; "MCIMail", and mailbox <mailbox> is the
   actual mailbox in the mail system defined described by mailbox-type. <mailbox-type>.  The representation of a string
   <PrintableString> and <IA5String> rules are defined in this syntax Section 4.2.
   The <DOLLAR> rule is defined in [MODELS].

   The LDAP definition for the string value
   itself.

3.29 Other Mailbox syntax is:

      ( 1.3.6.1.4.1.1466.115.121.1.39 DESC 'Other Mailbox' )

   The ASN.1 type corresponding to the Other Mailbox syntax is defined
   as follows, assuming EXPLICIT TAGS:

      OtherMailbox ::= SEQUENCE {
          mailboxType  PrintableString,
          mailbox      IA5String
      }

4.3.28 Postal Address

   A value in of 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 LDAP-specific encoding of a value of this syntax are written according to is defined by
   the following ABNF:

      postal-address

      PostalAddress = dstring line *( DOLLAR dstring line )

   In the above, each dstring component
      line          = 1*line-char
      line-char     = %x00-23
                      / (%x5C "24")  ; escaped "$"
                      / %x25-5B
                      / (%x5C "5C")  ; escaped "\"
                      / %x5D-7F
                      / UTFMB

   Each <line> of a postal address value is
   written encoded as a value of type Directory String syntax.  Backslashes UTF-8 [UTF-8]
   string except that "\" and
   dollar "$" characters, if they occur in the component, line,
   are quoted as
   described escaped by a "\" character followed by the two hexadecimal digit
   code for the character.  The <HEX-DIGIT> rule is defined in Section
   4.2.  The <DOLLAR> and <UTFMB> rules are defined in [MODELS].

   Many servers limit the postal address to no more than six lines of up to no
   more than thirty characters. characters each.

      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 LDAP definition for the Presentation Postal 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: is:

      ( 1.3.6.1.4.1.1466.115.121.1.43 1.3.6.1.4.1.1466.115.121.1.41 DESC 'Presentation 'Postal Address' )

   Values in this

   This syntax are written according corresponds to the following ABNF:

      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 PostalAddress ASN.1 type from [X.520],
   i.e.

      PostalAddress ::= SEQUENCE SIZE(1..ub-postal-line) OF
          DirectoryString(ub-postal-string)

4.3.29 Printable String

   A value of the Concrete Binary Representation.
   It Printable String syntax is a string of latin
   alphabetic, numeric, and (limited) punctuation characters as
   specified by the compact encoding. <PrintableCharacter> rule in Section 4.2.

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

   The idp alternative value of this syntax is a form the
   unconverted string of network-address included for
   compatibility with ISO 8348 [ISO8348].

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

   The otherstring alternative for characters, which conforms to the selector
   <PrintableString> rule in Section 4.2.

      Example:
         This is IA5 characters. a PrintableString.

   The "" alternative LDAP definition for the selector expresses PrintableString syntax is:

      ( 1.3.6.1.4.1.1466.115.121.1.44 DESC 'Printable String' )

   This syntax corresponds to the case where PrintableString ASN.1 type from
   [ASN.1].

4.3.30 Substring Assertion

   A value of the
   selector Substring Assertion syntax 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 a sequence of zero, one
   or more character substrings used as an argument for substring
   extensible matching of character string attribute values, i.e. as the Domain
   Specific Part (dsp) in
   matchValue of a network address.

   The x alternative MatchingRuleAssertion [PROT].  Each substring is the Abstract Binary form a
   string of one or more arbitrary characters from the dsp in a
   network address.

   The l alternative Universal
   Character Set (UCS) [UCS].  A zero length substring is IA5 characters and not permitted.

   The LDAP-specific encoding of a value of this syntax 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 defined by
   the following ABNF:

      SubstringAssertion = numericstring

      cudf-or-pid [ initial ] any [ final ]

      initial  = "CUDF" / "PID"

      other substring
      any      = keychar / PLUS / DOT

      domainchar ASTERISK *(substring ASTERISK)
      final    = keychar / DOT

      hexoctet substring
      ASTERISK = HEX HEX

      decimal-octet %x2A  ; asterisk ("*")

      substring           = 1*3DIGIT

      otherstring 1*substring-character
      substring-character = other otherstring %x00-29
                            / other

      domainstring = domainchar otherstring (%x5C "2A")  ; escaped "*"
                            / domainchar

      hexstring = hexoctet hexstring %x2B-5B
                            / hexoctet

      dotstring = decimaloctet DOT dotstring (%x5C "5C")  ; escaped "\"
                            /
         decimaloctet DOT decimaloctet

      dothexstring = dotstring %x5D-7F
                            / hexstring

3.31  Printable String

   A UTFMB

   Each <substring> of a Substring Assertion value in the Printable String syntax is encoded as a series of alphabetic,
   numeric, UTF-8
   [UTF-8] string, except that "\" and (limited) punctuation characters as specified "*" characters, if they occur in
   the
   PrintableString data type from ASN.1 [X.680] and in production p of
   section 3.11.  Values in this syntax substring, are expressed as escaped by a "\" character followed by the string
   itself.  The following string states two
   hexadecimal digit code for the OID assigned to this syntax:

      ( 1.3.6.1.4.1.1466.115.121.1.44 DESC 'Printable String' )

   Example:  This is a PrintableString.

3.32 Substring Assertion character.

   The Substring Assertion syntax is used only as the syntax of
   assertion values in rules which can be used in
   substrings and the extensible matching rules.  When using a substrings
   assertion, substrings components are provided match.  It is not used as an
   attribute syntax, or in a the SubstringFilter
   sequence. [PROT].

   The following string states the OID assigned to this
   syntax: LDAP definition for the Substring Assertion syntax is:

      ( 1.3.6.1.4.1.1466.115.121.1.58 DESC 'Substring Assertion' )

   When using a matching rule assertion, substring components are
   encoded according

   This syntax corresponds to the following ABNF and provided as the
   matchValue of the 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
   quoted as described in [MODELS].

3.33 SubstringAssertion ASN.1 type from
   [X.520].

4.3.31 Telephone Number

   A value in of the telephone number Telephone Number syntax is the series a string of printable
   characters that express a number (address) assigned to a telephone system
   subscriber.  The following string states the OID assigned to this
   syntax:

      ( 1.3.6.1.4.1.1466.115.121.1.50 DESC 'Telephone Number' )

   Values in this syntax are written as if they were ASN.1 [X.680]
   Printable String types.  Telephone numbers are defined in X.520
   [X.520] to comply complies with the internationally agreed format for
   expressing
   representing international telephone numbers in Recommendation
   E.123 [E.123].

   The representation LDAP-specific encoding of a string in value of this syntax is the
   unconverted string value
   itself. of characters, which conforms to the
   <PrintableString> rule in Section 4.2.

      Example:  +1 512 315 0280

3.34
   The LDAP definition for the Telephone Number syntax is:

      ( 1.3.6.1.4.1.1466.115.121.1.50 DESC 'Telephone Number' )

   The Telephone Number syntax corresponds to the following ASN.1 type
   from [X.520]:

      PrintableString (SIZE(1..ub-telephone-number))

   The value of ub-telephone-number is implementation defined.

4.3.32 Teletex Terminal Identifier

   A value in of this syntax is a string of characters that express specifies the identifier value assigned to and (optionally)
   parameters of a teletex service subscriber. terminal.

   The
   following string states the OID assigned to this syntax:

      ( 1.3.6.1.4.1.1466.115.121.1.51 DESC 'Teletex Terminal
         Identifier' )

   Values in LDAP-specific encoding of a value of this syntax are written according to is defined by
   the following ABNF:

      teletex-id = ttx-term  0*("$" *(DOLLAR ttx-param)
      ttx-term   = printablestring PrintableString          ; terminal identifier
      ttx-param  = ttx-key ":" COLON ttx-value  ; parameter
      ttx-key    = "graphic" / "control" / "misc" / "page" / "private"
      ttx-value  = octetstring

   In the above, the first printablestring is the encoding of the first
   portion of the teletex terminal identifier to be encoded, *ttx-value-char

      ttx-value-char = %x00-23
                       / (%x5C "24")  ; escaped "$"
                       / %x25-5B
                       / (%x5C "5C")  ; escaped "\"
                       / %x5D-FF

   The <PrintableString> and the
   subsequent 0 or more octetstrings <COLON> rules are subsequent portions of the
   teletex terminal identifier. defined in Section 4.2.
   The representation of a string <DOLLAR> rule is defined in this [MODELS].

   The LDAP definition for the Teletex Terminal Identifier syntax is is:

      ( 1.3.6.1.4.1.1466.115.121.1.51
         DESC 'Teletex Terminal Identifier' )

   This syntax corresponds to the string value
   itself.

3.35 TeletexTerminalIdentifier ASN.1 type
   from [X.520].

4.3.33 Telex Number

   A value in of the Telex Number syntax is specifies the number assigned to a telex
   system subscriber with the number,
   country code and answerback values indicated. code of a telex terminal.

   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 LDAP-specific encoding of a value of this syntax are written according to is defined by
   the following ABNF:

      telex-number  = actual-number "$" country "$" DOLLAR country-code
                         DOLLAR answerback
      actual-number = printablestring

      country PrintableString
      country-code  = printablestring PrintableString
      answerback    = printablestring
   In the above, actual-number is the syntactic representation of the
   number portion of the TELEX number being written, country is the
   TELEX country code, and answerback PrintableString

   The <PrintableString> rule is the answerback code of a TELEX
   terminal. defined in Section 4.2.  The representation of a string <DOLLAR>
   rule is defined in this [MODELS].

   The LDAP definition for the Telex Number syntax is is:

      ( 1.3.6.1.4.1.1466.115.121.1.52 DESC 'Telex Number' )

   This syntax corresponds to the string value
   itself.

3.36 TelexNumber ASN.1 type from [X.520].

4.3.34 UTC Time

   A value in of the UTC Time syntax is a character string representing a
   date and time indicating accuracy to a precision of one minute or one second.  The year
   is given as a two-digit number.  The
   following string states the OID assigned to this syntax:

      ( 1.3.6.1.4.1.1466.115.121.1.53 DESC 'UTC Time' )

   Values in LDAP-specific encoding of a
   value of this syntax are written as if they were printable strings,
   formulated as specified follows the format defined in [ASN.1] for the
   UTCTime data type in ASN.1 [X.680].
   It is strongly suggested that GMT time be used.

   Note:  This syntax and is deprecated in favor of the Generalized Time
   syntax.

4.  Matching Rules

   When performing described by the caseExactMatch, caseIgnoreMatch,
   caseIgnoreListMatch, telephoneNumberMatch, caseExactIA5Match following ABNF:

      UTCTime         = year month day hour minute [ second ]
                           [ u-time-zone ]
      u-time-zone     = %x5A  ; "Z"
                        / u-differential
      u-differential  = ( MINUS / PLUS ) hour minute

   The <year>, <month>, <day>, <hour>, <minute>, <second> and
   caseIgnoreIA5Match, multiple adjoining whitespace characters <MINUS>
   rules are
   treated the same as an individual space, and leading and trailing
   whitespace is ignored.

4.1  bitStringMatch defined in Section 4.3.13.  The following ABNF associates the bitStringMatch rule with the Bit
   String syntax:

     ( 2.5.13.16 NAME 'bitStringMatch'
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 )  ; Bit String

   This matching <DOLLAR> rule is used to test equality.

4.2  caseExactIA5Match defined in
   [MODELS].

   The following ABNF associates the caseExactIA5Match rule with time value represents coordinated universal time if 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 "Z" form
   of <u-time-zone> is used to test equality.

4.3  caseIgnoreIA5Match

   The following ABNF associates used, otherwise the caseIgnoreIA5Match rule with value represents a local
   time.  In the
   IA5 String 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 )  ; IA5 String

   This matching rule latter case, if <u-differential> is used to test equality.

4.4  caseIgnoreListMatch

   The ABNF below associates provided then
   coordinated universal time can be calculated by subtracting the caseIgnoreListMatch rule with
   differential from the
   Postal Address syntax. local time.  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 <u-time-zone> SHOULD be
   present in defining the matching rule
   for LDAP, although time values and the matching rule can "Z" form of <u-time-zone> SHOULD 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 in preference to test equality.

4.5  caseIgnoreMatch <u-differential>.

   The following ABNF associates the caseIgnoreMatch rule with LDAP definition for the
   Directory String syntax: UTC Time syntax is:

      ( 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.53 DESC 'UTC Time' )  ; Directory String
   Note: This matching rule syntax is used to test equality.

4.6  caseIgnoreOrderingMatch

   The following ABNF associates deprecated in favor of the caseIgnoreOrderingMatch rule with Generalized Time
   syntax.

   The UTC Time syntax corresponds to 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 is UTCTime ASN.1 type from
   [ASN.1].

5. Matching Rules

   Matching rules are used by directory implementations to test inequality, i.e., greaterOrEqual
   or lessOrEqual.

   The sort ordering for compare
   attribute values against assertion values when performing Search and
   Compare operations [PROT].  They are also used when comparing a caseIgnoreOrderingMatch is implementation-
   dependent.

4.7  caseIgnoreSubstringsMatch

   The following ABNF associates the caseIgnoreSubstringsMatch rule
   purported distinguished name [MODELS] with the Substring Assertion:

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

   This name of an entry.
   When modifying entries, matching rule is rules are used to test substrings equality.

4.8  distinguishedNameMatch

   The following ABNF associates the distinguishedNameMatch rule 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 identify values to test equality.

4.9  generalizedTimeMatch

   The following ABNF associates the generalizedTimeMatch rule with 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
   be deleted and to test equality.

4.10 generalizedTimeOrderingMatch

      ( 2.5.13.28 NAME 'generalizedTimeOrderingMatch'
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 )  ; Generalized Time

   This prevent an attribute from containing two equal
   values.

   Matching rules that are required for directory operation, or that are
   in common use, are specified in this section.

5.1 General Considerations

   A matching rule is used applied to test inequality, i.e., greaterOrEqual attribute values through an
   AttributeValueAssertion or lessOrEqual.

4.11 integerFirstComponentMatch MatchingRuleAssertion [PROT].  The following ABNF associates the integerFirstComponentMatch rule
   with
   conditions under which an AttributeValueAssertion or
   MatchingRuleAssertion evaluates to Undefined are specified in [PROT].
   If an assertion is not Undefined then 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 result of the assertion syntax of this matching
   rule, an INTEGER, is different from
   the value syntax result of attributes
   for which this is applying the equality selected matching rule.

   This  A matching rule is used
   evaluates to test equality with the first component TRUE, and in some cases Undefined, as specified in a compound syntax.

4.12 integerMatch

   The following ABNF associates the integerMatch rule with
   description of 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 is used rule, otherwise it evaluates to test equality.

4.13  numericStringMatch FALSE.

   Each assertion contains an assertion value.  The following ABNF associates the numericStringMatch rule with the
   Numeric String syntax:

      ( 2.5.13.8 NAME 'numericStringMatch'
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 )  ; Numeric String

   This matching rule 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

   This definition of each
   matching rule is used to test substrings equality.

4.15  objectIdentifierFirstComponentMatch

   The following ABNF associates specifies the
   objectIdentifierFirstComponentMatch rule with syntax for the OID syntax:

      ( 2.5.13.31 NAME 'objectIdentifierFirstComponentMatch'
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )  ; OID

   If assertion value.  The
   syntax of the client supplies an extensible filter using an
   objectIdentifierFirstComponentMatch whose matchValue assertion value is in typically, but not necessarily, the
   "descr" form, and
   same as the OID is not recognized by syntax of the server, then attribute values to which the
   filter is Undefined.

   This matching rule is used to test equality with
   may be applied.  Note that the first component AssertionValue in a compound syntax.

4.16  objectIdentifierMatch

   The following ABNF associates the objectIdentifierMatch rule with the
   OID syntax:

      ( 2.5.13.0 NAME 'objectIdentifierMatch'
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )  ; OID

   This matching rule is used SubstringFilter
   [PROT] MUST conform to test equality.

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

   If rule for the client supplies a filter using an objectIdentifierMatch whose
   matchValue oid attribute type.  The entire
   SubstringFilter is in the "descr" form, and converted into an assertion value of the oid is not recognized
   by
   substrings matching rule prior to applying the server, then rule.

   The description of each matching rule indicates whether the filter rule is Undefined.

4.17  octetStringMatch

   Servers which implement the extensibleMatch filter SHOULD allow
   suitable for use as the equality matching rule listed (EQUALITY), ordering
   matching rule (ORDERING) or substrings matching rule (SUBSTR) in this section an
   attribute type definition [MODELS].

   Each matching rule is uniquely identified with an object identifier.

   The definition of a matching rule should not be subsequently changed.
   If a change is desirable then a new matching rule with a different
   object identifier should be defined instead.

   Servers SHOULD implement all the matching rules in Section 5.2.
   Servers MAY implement additional matching rules.

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

   Servers MUST publish in the matchingRules attribute, the definitions
   of matching rules referenced by values of the attributeTypes and
   matchingRuleUse attributes in the same subschema entry.  Other
   unreferenced matching rules MAY be published in the matchingRules
   attribute.

   If the server supports the extensibleMatch filter, then the server
   MAY use the matchingRuleUse attribute to indicate the applicability
   (in an extensibleMatch filter) of selected matching rules to
   nominated attribute types.

5.2 Matching Rule Definitions

   When evaluating the caseExactIA5Match, caseIgnoreIA5Match,
   caseIgnoreIA5SubstringsMatch, caseIgnoreListMatch, caseIgnoreMatch,
   caseIgnoreOrderingMatch and caseIgnoreSubstringsMatch matching rules
   multiple adjoining whitespace characters are treated the same as an
   individual space, and leading and trailing whitespace is ignored.

5.2.1 bitStringMatch

   The Octet String Match bitStringMatch rule compares for equality an asserted octet
   string with assertion value of the Bit String
   syntax to an attribute value of a syntax (e.g. the Bit String syntax)
   whose corresponding ASN.1 type OCTET is BIT STRING.

   The strings match if they are

   If the same length and corresponding
   octets are identical.

   The following ABNF associates ASN.1 type of the octetStringMatch rule with attribute syntax does not have
   a named bit list (which is the OCTET STRING syntax:

   ( 2.5.13.17 NAME 'octetStringMatch'
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )

4.18  presentationAddressMatch

   The following ABNF associates case for the presentationAddressMatch rule with Bit String syntax) then
   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 matching rule is used evaluates to test equality.

4.19  protocolInformationMatch TRUE if and only if the attribute value has the
   same number of bits as the assertion value and the bits match on a
   bitwise basis.

   If the corresponding ASN.1 type does have a named bit list then
   bitStringMatch operates as above except that trailing zero bits in
   the attribute and assertion values are treated as absent.

   The following ABNF associates LDAP definition for the protocolInformationMatch bitStringMatch rule with
   the Protocol Information syntax: is:

      ( 2.5.13.24 2.5.13.16 NAME 'protocolInformationMatch' 'bitStringMatch'
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.42 1.3.6.1.4.1.1466.115.121.1.6 )  ; Protocol Information

   This

   The bitStringMatch rule is an equality matching rule.

5.2.2 caseExactIA5Match

   The caseExactIA5Match rule compares an assertion value of the IA5
   String syntax to an attribute value of a syntax (e.g the IA5 String
   syntax) whose corresponding ASN.1 type is used IA5String.

   The rule evaluates to test equality.

4.20 telephoneNumberMatch TRUE if and only if the attribute value and the
   assertion value have the same number of characters and corresponding
   characters are the same.  Letter case is significant in the
   comparison.

   The following ABNF associates LDAP definition for the telephoneNumberMatch caseExactIA5Match rule with the
   Telephone Number syntax: is:

      ( 2.5.13.20 1.3.6.1.4.1.1466.109.114.1 NAME 'telephoneNumberMatch' 'caseExactIA5Match'
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 1.3.6.1.4.1.1466.115.121.1.26 )  ; Telephone Number

   This

   The caseExactIA5Match rule is an equality matching rule.

5.2.3 caseIgnoreIA5Match

   The caseIgnoreIA5Match rule compares an assertion value of the IA5
   String syntax to an attribute value of a syntax (e.g the IA5 String
   syntax) whose corresponding ASN.1 type is used IA5String.

   The rule evaluates to test equality.

4.21 telephoneNumberSubstringsMatch TRUE if and only if the attribute value and the
   assertion value have the same number of characters and corresponding
   characters are the same, ignoring the case of letters.

   The following ABNF associates LDAP definition for the telephoneNumberSubstringsMatch caseIgnoreIA5Match rule
   with the Substring Assertion syntax: is:

      ( 2.5.13.21 1.3.6.1.4.1.1466.109.114.2 NAME 'telephoneNumberSubstringsMatch' 'caseIgnoreIA5Match'
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 1.3.6.1.4.1.1466.115.121.1.26 )  ; Substring Assertion

   This matching

   The caseIgnoreIA5Match rule is used to test substrings equality.

4.22 uniqueMemberMatch an equality matching rule.

5.2.4 caseIgnoreIA5SubstringsMatch

   The following ABNF associates the uniqueMemberMatch caseIgnoreIA5SubstringsMatch rule with compares an assertion value of
   the
   Name and Optional UID syntax:

      ( 2.5.13.23 NAME 'uniqueMemberMatch'
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.34 )  ; Name And Optional UID

   This matching rule is used Substring Assertion syntax to test equality.

5. Security Considerations

5.1  Disclosure

   Attributes an attribute value of directory entries are used a syntax (e.g
   the IA5 String syntax) whose corresponding ASN.1 type is IA5String.

   The rule evaluates to provide descriptive
   information about TRUE if and only if the real-world objects they represent, which can
   be people, organizations or devices.  Most countries have privacy
   laws regarding substrings of the publication
   assertion value match disjoint portions of information about people.

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 value in this document.

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

5.3  Securing the Directory

   In order to protect assertion value, and an <initial>
   substring, if present, matches the directory beginning of the attribute value,
   and its contents, strong
   authentication MUST have been used to identify a <final> substring, if present, matches the Client when an
   update operation end of the attribute
   value.  A substring matches a portion of the attribute value if
   corresponding characters are the same, ignoring the case of letters.

      ( 1.3.6.1.4.1.1466.109.114.3 NAME 'caseIgnoreIA5SubstringsMatch'
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )

   The caseIgnoreIA5SubstringsMatch rule is requested.

6.  Acknowledgements

   This document a substrings matching rule.

5.2.5 caseIgnoreListMatch

   The caseIgnoreListMatch rule compares an assertion value that is a
   sequence of strings to an update attribute value of RFC 2252 by M. Wahl, A. Coulbeck,
   T. Howes, and S. Kille.  RFC 2252 was a product of syntax (e.g. the IETF ASID
   Working Group.

   This document
   Postal Address syntax) whose corresponding ASN.1 type is based upon input a sequence
   of the IETF LDAPBIS working group. DirectoryString ASN.1 type.

   The authors wish rule evaluates to thank J. Sermersheim TRUE if and only if the attribute value and the
   assertion value have the same number of strings and corresponding
   strings (by position) match according to the caseIgnoreMatch matching
   rule.

   In [X.520] the assertion syntax for this matching rule is defined to
   be:

      SEQUENCE OF DirectoryString {ub-match}

   i.e. different from the corresponding type for the Postal Address
   syntax.  The choice of the Postal Address syntax for the assertion
   syntax of the caseIgnoreListMatch in LDAP should not be seen as
   limiting the matching rule to only apply to attributes with the
   Postal Address syntax.

   The LDAP definition for the caseIgnoreListMatch rule is:

      ( 2.5.13.11 NAME 'caseIgnoreListMatch'
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 )
   The caseIgnoreListMatch rule is an equality matching rule.

5.2.6 caseIgnoreMatch

   The caseIgnoreMatch rule compares an assertion value of the Directory
   String syntax to an attribute value of a syntax (e.g. the Directory
   String, Printable String, Country String or Telephone Number syntax)
   whose corresponding ASN.1 type is DirectoryString or one of its
   alternative string types, e.g. PrintableString.

   The rule evaluates to TRUE if and only if the attribute value and the
   assertion value have the same number of characters and corresponding
   characters are the same, ignoring the case of letters.

   The LDAP definition for the caseIgnoreMatch rule is:

      ( 2.5.13.2 NAME 'caseIgnoreMatch'
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

   The caseIgnoreMatch rule is an equality matching rule.

5.2.7 caseIgnoreOrderingMatch

   The caseIgnoreOrderingMatch rule compares an assertion value of the
   Directory String syntax to an attribute value of a syntax (e.g. the
   Directory String, Printable String, Country String or Telephone
   Number syntax) whose corresponding ASN.1 type is DirectoryString or
   one of its alternative string types.

   The rule evaluates to TRUE if, and only if, in the normal collation
   order for the attribute syntax after lower-case letters in both the
   attribute and assertion values have been replaced by their upper-case
   equivalents, the attribute value appears earlier than the assertion
   value, i.e.  the attribute value is "less than" the assertion value.

   The collation order for values of the DirectoryString syntax is
   implementation-defined.  [Editor's note: this will be specified by a
   stringprep profile before final publication.]

   The LDAP definition for the caseIgnoreOrderingMatch rule is:

      ( 2.5.13.3 NAME 'caseIgnoreOrderingMatch'
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

   The caseIgnoreOrderingMatch rule is an ordering matching rule.

5.2.8 caseIgnoreSubstringsMatch

   The caseIgnoreSubstringsMatch rule compares an assertion value of the
   Substring Assertion syntax to an attribute value of a syntax (e.g.
   the Directory String, Printable String, Country String or Telephone
   Number syntax) whose corresponding ASN.1 type is DirectoryString or
   one of its alternative string types.

   The rule evaluates to TRUE if and only if the substrings of the
   assertion value match disjoint portions of the attribute value in the
   order of the substrings in the assertion value, and an <initial>
   substring, if present, matches the beginning of the attribute value,
   and a <final> substring, if present, matches the end of the attribute
   value.  A substring matches a portion of the attribute value if
   corresponding characters are the same, ignoring the case of letters.

   The LDAP definition for the caseIgnoreSubstringsMatch rule is:

      ( 2.5.13.4 NAME 'caseIgnoreSubstringsMatch'
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )

   The caseIgnoreSubstringsMatch rule is a substrings matching rule.

5.2.9 distinguishedNameMatch

   The distinguishedNameMatch rule compares an assertion value of the DN
   syntax to an attribute value of a syntax (e.g. the DN syntax) whose
   corresponding ASN.1 type is DistinguishedName.

   The rule evaluates to TRUE if and only if the attribute value and the
   assertion value have the same number of RDNs and corresponding RDNs
   (by position) are the same.  An RDN of the assertion value is the
   same as an RDN of the attribute value if and only if they have the
   same number of attribute value assertions (AVAs) and each AVA of the
   first RDN is the same as the AVA of the second RDN with the same
   attribute type.  The order of the AVAs is not significant.  Also note
   that a particular attribute type may appear in at most one AVA in an
   RDN.  Two AVAs with the same attribute type are the same if their
   values are equal according to the equality matching rule of the
   attribute type.  If one or more of the AVA comparisons evaluate to
   Undefined and the remaining AVA comparisons return TRUE then the
   distinguishedNameMatch rule evaluates to Undefined.

   The LDAP definition for the distinguishedNameMatch rule is:

      ( 2.5.13.1 NAME 'distinguishedNameMatch'
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
   The distinguishedNameMatch rule is an equality matching rule.

5.2.10 generalizedTimeMatch

   The generalizedTimeMatch rule compares an assertion value of the
   Generalized Time syntax to an attribute value of a syntax (e.g the
   Generalized Time syntax) whose corresponding ASN.1 type is
   GeneralizedTime.

   The rule evaluates to TRUE if and only if the attribute value
   represents the same universal coordinated time as the assertion
   value.  If a time is specified with the minutes or seconds absent
   then the number of minutes or seconds (respectively) is assumed to be
   zero.

   The LDAP definition for the generalizedTimeMatch rule is:

      ( 2.5.13.27 NAME 'generalizedTimeMatch'
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 )

   The generalizedTimeMatch rule is an equality matching rule.

5.2.11 generalizedTimeOrderingMatch

   The generalizedTimeMatch rule compares the time ordering of an
   assertion value of the Generalized Time syntax to an attribute value
   of a syntax (e.g the Generalized Time syntax) whose corresponding
   ASN.1 type is GeneralizedTime.

   The rule evaluates to TRUE if and only if the attribute value
   represents a universal coordinated time which is earlier than the
   universal coordinated time represented by the assertion value.

   The LDAP definition for the generalizedTimeOrderingMatch rule is:

      ( 2.5.13.28 NAME 'generalizedTimeOrderingMatch'
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 )

   The generalizedTimeOrderingMatch rule is an ordering matching rule.

5.2.12 integerFirstComponentMatch

   The integerFirstComponentMatch rule compares an assertion value of
   the Integer syntax to an attribute value of a syntax (e.g the DIT
   Structure Rule Description syntax) whose corresponding ASN.1 type is
   a SEQUENCE with a mandatory first component of the INTEGER ASN.1
   type.

   Note that the assertion syntax of this matching rule differs from the
   attribute syntax of attributes for which this is the equality
   matching rule.

   The rule evaluates to TRUE if and only if the assertion value and the
   first component of the attribute value are the same integer value.

   The LDAP definition for the integerFirstComponentMatch matching rule
   is:

      ( 2.5.13.29 NAME 'integerFirstComponentMatch'
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )

   The integerFirstComponentMatch rule is an equality matching rule.
   When using integerFirstComponentMatch to compare two attribute values
   (of an applicable syntax), an assertion value must first be derived
   from one of the attribute values.  An assertion value can be derived
   from an attribute value by taking the first component of that
   attribute value.

5.2.13 integerMatch

   The integerMatch rule compares an assertion value of the Integer
   syntax to an attribute value of a syntax (e.g the Integer syntax)
   whose corresponding ASN.1 type is INTEGER.

   The rule evaluates to TRUE if and only if the attribute value and the
   assertion value are the same integer value.

   The LDAP definition for the integerMatch matching rule is:

      ( 2.5.13.14 NAME 'integerMatch'
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )

   The integerMatch rule is an equality matching rule.

5.2.14 numericStringMatch

   The numericStringMatch rule compares an assertion value of the
   Numeric String syntax to an attribute value of a syntax (e.g the
   Numeric String syntax) whose corresponding ASN.1 type is
   NumericString.

   The rule evaluates to TRUE if and only if the attribute value and the
   assertion value are the same string of numerals, ignoring any space
   characters.

   The LDAP definition for the numericStringMatch matching rule is:

      ( 2.5.13.8 NAME 'numericStringMatch'
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 )

   The numericStringMatch rule is an equality matching rule.

5.2.15 numericStringSubstringsMatch

   The numericStringSubstringsMatch rule compares an assertion value of
   the Substring Assertion syntax to an attribute value of a syntax (e.g
   the Numeric String syntax) whose corresponding ASN.1 type is
   NumericString.

   The rule evaluates to TRUE if and only if the substrings of the
   assertion value match disjoint portions of the attribute value in the
   order of the substrings in the assertion value, and an <initial>
   substring, if present, matches the beginning of the attribute value,
   and a <final> substring, if present, matches the end of the attribute
   value.  A substring matches a portion of the attribute value if
   corresponding characters are the same, ignoring any space characters.

      ( 2.5.13.10 NAME 'numericStringSubstringsMatch'
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )

   The numericStringSubstringsMatch rule is a substrings matching rule.

5.2.16 objectIdentifierFirstComponentMatch

   The objectIdentifierFirstComponentMatch rule compares an assertion
   value of the OID syntax to an attribute value of a syntax (e.g the
   Attribute Type Description, DIT Content Rule Description, LDAP Syntax
   Description, Matching Rule Description, Matching Rule Use
   Description, Name Form Description or Object Class Description
   syntax) whose corresponding ASN.1 type is a SEQUENCE with a mandatory
   first component of the OBJECT IDENTIFIER ASN.1 type.

   Note that the assertion syntax of this matching rule differs from the
   attribute syntax of attributes for which this is the equality
   matching rule.

   The rule evaluates to TRUE if and only if the assertion value matches
   the first component of the attribute value using the rules of
   objectIdentifierMatch.

   The LDAP definition for the objectIdentifierFirstComponentMatch
   matching rule is:

      ( 2.5.13.31 NAME 'objectIdentifierFirstComponentMatch'
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )

   The objectIdentifierFirstComponentMatch rule is an equality matching
   rule.  When using objectIdentifierFirstComponentMatch to compare two
   attribute values (of an applicable syntax), an assertion value must
   first be derived from one of the attribute values.  An assertion
   value can be derived from an attribute value by taking the first
   component of that attribute value.

5.2.17 objectIdentifierMatch

   The objectIdentifierMatch rule compares an assertion value of the OID
   syntax to an attribute value of a syntax (e.g the OID syntax) whose
   corresponding ASN.1 type is OBJECT IDENTIFIER.

   The rule evaluates to TRUE if and only if the assertion value and the
   attribute value represent the same object identifier, that is, the
   same sequence of integers, whether represented explicitly in the
   <numericoid> form of <oid> or implicitly in the <descr> form (see
   [MODELS]).

   If an LDAP client supplies an assertion value in the <descr> form,
   and the chosen descriptor is not recognized by the server, then the
   objectIdentifierMatch rule evaluates to Undefined.

   The LDAP definition for the objectIdentifierMatch matching rule is:

      ( 2.5.13.0 NAME 'objectIdentifierMatch'
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )

   The objectIdentifierMatch rule is an equality matching rule.

5.2.18 octetStringMatch

   The octetStringMatch rule compares an assertion value of the Octet
   String syntax to an attribute value of a syntax (e.g the Octet String
   or JPEG syntax) whose corresponding ASN.1 type is the OCTET STRING
   ASN.1 type.

   The rule evaluates to TRUE if and only if the attribute value and the
   assertion value are the same length and corresponding octets (by
   position) are the same.

   The LDAP definition for the octetStringMatch matching rule is:

      ( 2.5.13.17 NAME 'octetStringMatch'
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )

   The octetStringMatch rule is an equality matching rule.

5.2.19 telephoneNumberMatch

   The telephoneNumberMatch rule compares an assertion value of the
   Telephone Number syntax to an attribute value of a syntax (e.g the
   Telephone Number syntax) whose corresponding ASN.1 type is a
   PrintableString representing a telephone number.

   The rule evaluates to TRUE if and only if the attribute value and the
   assertion value have the same number of characters and corresponding
   characters are the same, ignoring the case of letters, and ignoring
   space and `-' characters.

   The LDAP definition for the telephoneNumberMatch matching rule is:

      ( 2.5.13.20 NAME 'telephoneNumberMatch'
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 )

   The telephoneNumberMatch rule is an equality matching rule.

5.2.20 telephoneNumberSubstringsMatch

   The telephoneNumberSubstringsMatch rule compares an assertion value
   of the Substring Assertion syntax to an attribute value of a syntax
   (e.g the Telephone Number syntax) whose corresponding ASN.1 type is a
   PrintableString representing a telephone number.

   The rule evaluates to TRUE if and only if the substrings of the
   assertion value match disjoint portions of the attribute value in the
   order of the substrings in the assertion value, and an <initial>
   substring, if present, matches the beginning of the attribute value,
   and a <final> substring, if present, matches the end of the attribute
   value.  A substring matches a portion of the attribute value if
   corresponding characters are the same, ignoring the case of letters,
   and ignoring space and `-' characters.

   The LDAP definition for the telephoneNumberSubstringsMatch matching
   rule is:

      ( 2.5.13.21 NAME 'telephoneNumberSubstringsMatch'
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )

   The telephoneNumberSubstringsMatch rule is a substrings matching
   rule.

5.2.21 uniqueMemberMatch

   The uniqueMemberMatch rule compares an assertion value of the Name
   And Optional UID syntax to an attribute value of a syntax (e.g the
   Name And Optional UID syntax) whose corresponding ASN.1 type is
   NameAndOptionalUID.

   The rule evaluates to TRUE if and only if the <distinguishedName>
   components of the assertion value and attribute value match according
   to the distinguishedNameMatch rule and the <BitString> component is
   absent from the attribute value or matches the <BitString> component
   of the assertion value according to the bitStringMatch rule.

   The LDAP definition for the uniqueMemberMatch matching rule is:

      ( 2.5.13.23 NAME 'uniqueMemberMatch'
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.34 )

   The uniqueMemberMatch rule is an equality matching rule.

6. Security Considerations

   In general, the LDAP-specific encodings for syntaxes defined in this
   document do not define canonical encodings.  That is, a
   transformation from an LDAP-specific encoding into some other
   encoding (e.g. BER) and back into the LDAP-specific encoding will not
   necessarily reproduce exactly the original octets of the
   LDAP-specific encoding.  Therefore an LDAP-specific encoding should
   not be used where a canonical encoding is required.

   Furthermore, the LDAP-specific encodings do not necessarily enable an
   alternative encoding of values of the Directory String and DN
   syntaxes to be reconstructed, e.g.  a transformation from DER to
   LDAP-specific encoding and back to DER may not reproduce the original
   DER encoding.  Therefore LDAP-specific encodings should not be used
   where reversibility to DER is needed, e.g. for the verification of
   digital signatures.  Instead, DER or a DER-reversible encoding should
   be used.

   When interpreting security-sensitive fields, and in particular fields
   used to grant or deny access, implementations MUST ensure that any
   matching rule comparisons are done on the underlying abstract value,
   regardless of the particular encoding used.

7. Acknowledgements

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

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

7.  Authors' Addresses

   Kathy Dally this revision.

8. IANA Considerations

   It is requested that the Internet Assigned Numbers Authority (IANA)
   update the LDAP descriptors registry as indicated by the following
   two templates:

      Subject: Request for LDAP Descriptor Registration Update
      Descriptor (short name): see comment
      Object Identifier: see comment
      Person & email address to contact for further information:
        Steven Legg <steven.legg@adacel.com.au>
      Usage: see comment
      Specification: RFC XXXX
      Author/Change Controller: IESG
      Comments:

      The following descriptors (short names) should be updated to refer
      to RFC XXXX.

      NAME                              Type  OID
      ------------------------------------------------------------------
      bitStringMatch                       M  2.5.13.16
      caseExactIA5Match                    M  1.3.6.1.4.1.1466.109.114.1
      caseIgnoreIA5Match                   M  1.3.6.1.4.1.1466.109.114.2
      caseIgnoreListMatch                  M  2.5.13.11
      caseIgnoreMatch                      M  2.5.13.2
      caseIgnoreOrderingMatch              M  2.5.13.3
      caseIgnoreSubstringsMatch            M  2.5.13.4
      distinguishedNameMatch               M  2.5.13.1
      generalizedTimeMatch                 M  2.5.13.27
      generalizedTimeOrderingMatch         M  2.5.13.28
      integerFirstComponentMatch           M  2.5.13.29
      integerMatch                         M  2.5.13.14
      numericStringMatch                   M  2.5.13.8
      numericStringSubstringsMatch         M  2.5.13.10
      objectIdentifierFirstComponentMatch  M  2.5.13.31
      octetStringMatch                     M  2.5.13.17
      telephoneNumberMatch                 M  2.5.13.20
      telephoneNumberSubstringsMatch       M  2.5.13.21
      uniqueMemberMatch                    M  2.5.13.23

      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 descriptor for the object identifier 2.5.13.0 was incorrectly
      registered as objectIdentifiersMatch (extraneous `s') in RFC 3383.
      It should be changed to the following with a reference to RFC
      XXXX.

      NAME                              Type  OID
      ------------------------------------------------------------------
      objectIdentifierMatch                M  2.5.13.0

      Subject: Request for LDAP Descriptor Registration
      Descriptor (short name): caseIgnoreIA5SubstringsMatch
      Object Identifier: 1.3.6.1.4.1.1466.109.114.3
      Person & email address to contact for further information:
        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

8. References

8.1 <steven.legg@adacel.com.au>
      Usage: other (M)
      Specification: RFC XXXX
      Author/Change Controller: IESG

9. Normative References

   [KEYWORD]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

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

   [UTF-8]    Yergeau, F., "UTF-8, a transformation format of ISO
              10646", RFC 2279, January 1998.

   [RFC3383]  Zeilenga, K., "IANA Considerations for LDAP", BCP 64, RFC
              3383, September 2002.

   [LDAPDN]   Zeilenga, K., "LDAP: String Representation of
              Distinguished Names", draft-ietf-ldapbis-dn-xx.txt, a work
              in progress, August 2002.

   [PROT]     Sermersheim, J., "LDAP: The Protocol", draft-ietf-ldapbis-
              protocol-xx.txt, a work in progress, December 2002.

   [E.123]    Notation for national and international telephone numbers,
              ITU-T Recommendation E.123, 1988.

   [IA5]

   [FAX]      Standardization of Group 3 facsimile apparatus for
              document transmission - Terminal Equipment and Protocols
              for Telematic Services, ITU-T Recommendation T.4, 1993

   [T.50]     International Reference Alphabet (IRA) (Formerly
              International Alphabet No. 5 or IA5) Information
              Technology - 7-Bit Coded
        Character Set for Information Interchange, 7-Bit Coded Character Set for Information
              Interchange, ITU-T Recommendation T.50, 1992

   [X.420]    ITU-T Recommendation X.420 (1996) | ISO/IEC 10021-7:1997,
              Information Technology - Message Handling Systems (MHS):
              Interpersonal messaging system

   [X.501]    ITU-T Recommendation X.501 (1993) | ISO/IEC 9594-2:1994,
              Information Technology - Open Systems Interconnection -
              The Directory: Models

   [X.520]    ITU-T Recommendation X.520 (1993) | ISO/IEC 9594-6:1994,
              Information Technology - Open Systems Interconnection -
              The Directory: Selected attribute types

   [ASN.1]    ITU-T Recommendation
        T.50, 1992 X.680 (1997) | ISO/IEC 8824-1:1998
              Information Technology - Abstract Syntax Notation One
              (ASN.1): Specification of basic notation

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

   [ISO10646]

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

   [JPEG]     JPEG File Interchange Format (Version 1.02).  Eric
              Hamilton, C-Cube Microsystems, Milpitas, CA, September 1,
              1992.

   [LDAPDN]  K. Zeilenga (editor), "LDAP: String Representation of
             Distinguished Names", draft-ietf-ldapbis-dn-xx.txt, (a
             work in 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 10021 and RFC 822", RFC 1327, May 1992.

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

10. Informative References

   [RFC2252]  Wahl, M., Coulbeck, A., Howes, T. and ISO 10646", RFC 2044, October 1996.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
      Requirement Levels", S. Kille,
              "Lightweight Directory Access Protocol (v3): Attribute
              Syntax Definitions", RFC 2119, March 2252, December 1997.

   [RFC 2256]  draft-ietf-ldapbis-user-schema-xx, replacement for

   [RFC2256]  Wahl, M., "A Summary of the X.500(96) User Schema for use
              with LDAPv3", RFC 2256, December 1997.

   [T.4]  Standardization of Group 3 facsimile apparatus for document
      transmission - Terminal Equipment

   [RFC3377]  Hodges, J. and Protocols for Telematic
      Services, ITU-T Recommendation T.4, 1993

   [X.501]    The Directory:  Models, R. Morgan, "Lightweight Directory Access
              Protocol (v3): Technical Specification", RFC 3377,
              September 2002.

   [X.500]    ITU-T Recommendation X.501, 1993.

   [X.520] X.500 (1993) | ISO/IEC 9594-1:1994,
              Information Technology - Open Systems Interconnection -
              The Directory:  Selected Attribute Types. Overview of concepts, models and services

   [BER]      ITU-T Recommendation X.520, 1993.

   [X.680] X.690 (1997) | ISO/IEC 8825-1:1998
              Information Technology - Abstract Syntax Notation One
      (ASN.1): ASN.1 encoding rules:
              Specification of Basic Notation, ITU-T Recommendation
      X.680, 1994

8.2  Informative References

   [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

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

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

9.  Full Encoding Rules
              (DER)

11.  Authors' Addresses

   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

   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

12. Copyright Statement Notice

      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

Appendix A. Summary of Syntax Object Identifiers of Syntaxes

   This

   The following list contains summarizes the object identifiers for assigned to the
   syntaxes used defined in this specification and in the user schema specification [User]. document.

      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 String                 1.3.6.1.4.1.1466.115.121.1.15
      DIT Content Rule Description     1.3.6.1.4.1.1466.115.121.1.16
      DIT Structure Rule Description   1.3.6.1.4.1.1466.115.121.1.17
      DN                               1.3.6.1.4.1.1466.115.121.1.12
      Enhanced Guide                   1.3.6.1.4.1.1466.115.121.1.21
      Facsimile Telephone Number       1.3.6.1.4.1.1466.115.121.1.22
      Fax                              1.3.6.1.4.1.1466.115.121.1.23
      Generalized Time                 1.3.6.1.4.1.1466.115.121.1.24
      Guide                            1.3.6.1.4.1.1466.115.121.1.25
      IA5 String                       1.3.6.1.4.1.1466.115.121.1.26
      Integer                          1.3.6.1.4.1.1466.115.121.1.27
      JPEG                             1.3.6.1.4.1.1466.115.121.1.28
      LDAP Syntax Description          1.3.6.1.4.1.1466.115.121.1.54
      Matching Rule Description        1.3.6.1.4.1.1466.115.121.1.30
      Matching Rule Use Description    1.3.6.1.4.1.1466.115.121.1.31
      Name And Optional UID            1.3.6.1.4.1.1466.115.121.1.34
      Name Form Description            1.3.6.1.4.1.1466.115.121.1.35
      Numeric String                   1.3.6.1.4.1.1466.115.121.1.36
      Object Class Description         1.3.6.1.4.1.1466.115.121.1.37
      Octet String                     1.3.6.1.4.1.1466.115.121.1.40
      OID                              1.3.6.1.4.1.1466.115.121.1.38
      Other Mailbox                    1.3.6.1.4.1.1466.115.121.1.39
      Postal Address                   1.3.6.1.4.1.1466.115.121.1.41
      Printable String                 1.3.6.1.4.1.1466.115.121.1.44
      Substring Assertion              1.3.6.1.4.1.1466.115.121.1.58
      Telephone Number                 1.3.6.1.4.1.1466.115.121.1.50
      Teletex Terminal Identifier      1.3.6.1.4.1.1466.115.121.1.51
      Telex Number                     1.3.6.1.4.1.1466.115.121.1.52
      UTC Time                         1.3.6.1.4.1.1466.115.121.1.53

Appendix B. Changes from 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 2252 & 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 significant differences between this
   specification and RFC 2252 to
   this specification. and Sections 6 and 8 of RFC 2256.

   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  The IESG Note. Note has been removed.

   2.  Changed "types" to "syntaxes" in the last sentence  The major part 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" Sections 4, 5 and made corresponding changes throughout the
          document.  The purpose being 7 has been moved to relegate all encoding issues [MODELS]
       and revised. Changes to the Protocol specification [Protocol].

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

      8.  Expanded the discussion of each parts of the syntaxes these sections moved to
       [MODELS] are detailed in section [MODELS].

   3.

      9.  Added examples to some  BNF descriptions of the syntax descriptions.

      10. Added NAME option to the syntax description formats have been replaced by ABNF
       [ABNF] specifications.

   4.  The ambiguous statement in 2.2.4.

          RESCINDED IN -01!!

      11. Added a note deprecating the UTCTime attribute syntax
          description in 3.41
      12. In RFC 2252, Section 4.3 regarding the ABNF
       use 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 backslash quoting mechanism to escape separator symbols
       has been removed. The escaping mechanism is now explicitly
       represented in the EQUALITY matching rule ABNF for the altServer attribute type ABNF in paragraph 5.1.  Note that syntaxes where 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 provision
       applies.

   5.  The description of each of the EQUALITY matching rule LDAP syntaxes has been expanded so
       that they are less dependent on knowledge of X.500 for the namingContexts attribute
       interpretation.

   6.  The relationship of LDAP syntaxes to corresponding ASN.1 type ABNF
       definitions has been made explicit.

   7.  The set of characters allowed in paragraph 5.13.

          RESCINDED IN -01

      17. Reworded paragraph 5.15.

      18. Added distinguishedNameMatch as the EQUALITY matching rule
          for a <PrintableString> (formerly
       <printablestring>) has been corrected to align with the namingContexts attribute
       PrintableString ASN.1 type ABNF in paragraph 5.13.

          RESCINDED IN -01

      19. Added integerMatch as [ASN.1].  Specifically, the EQUALITY double
       quote character has been removed and integerOrderingMatch
          as the Ordering matching single quote character
       and equals sign have been added.

   8.  Values of the Directory String, Printable String and Telephone
       Number syntaxes are now required to have at least one character.

   9.  The <DITContentRuleDescription>, <NameFormDescription> and
       <DITStructureRuleDescription> rules have been moved to [MODELS].

   10. The corresponding ASN.1 type for the supportedLDAPVersion
          attribute Other Mailbox syntax has
       been incorporated from RFC 1274.

   11. A corresponding ASN.1 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 LDAP Syntax Description syntax
       has been invented.

   12. The Binary syntax has been removed because it was not adequately
       specified, implementations with different incompatible
       interpretations exist, and it was confused with the ABNF in paragraph 3.12.

      22. Added ;binary
       transfer encoding.

   13. All discussion of transfer options, including the seven syntax definitions ";binary"
       option, has been removed. All imperatives regarding binary
       transfer of values have been removed.

   14. The Delivery Method, Enhanced Guide, Guide, Octet String, Teletex
       Terminal Identifier and Telex Number syntaxes from RFC 2256 and ordered
          the definitions alphabetically.

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

      24. Replaced have
       been incorporated.

   15. The <criteria> rule for the X.208 reference with one Enhanced Guide and Guide syntaxes has
       been extended to X.680(1994), since
          X.680 is accommodate empty "and" and "or" expressions.

   16. An encoding for the ASN.1 referred to <ttx-value> rule in the X.500(1993)-series.

-------
-01 changes

      25. Moved the table listing the Teletex Terminal
       Identifier syntax has been defined.

   17. The PKI-related syntaxes (Certificate, Certificate List and their oids
       Certificate Pair 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 RFC 2252, and Supported Algorithm syntax
       from RFC 2256 2256) have been removed.  They are 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 be reintroduced in
       PKIX documents.

   18. The MHS OR Address syntax has been removed since its
       specification (in RFC 2156) is not at draft standard maturity.

   19. The DL Submit Permission syntax has been removed as it depends on
       the p rule to match
               the PrintableString MHS OR Address syntax.
             * Deleted the letterstring rule.
             * Modified the utf8 and dstring rules according to a
               suggestion from K. Zeilenga.
             * Deleted ";" from the keychar rule, which affects the
               anhstring, keystring,

   20. The Presentation Address syntax has been removed since its
       specification (in RFC 1278) is not at draft standard maturity.

   21. The ACI Item, Access Point, Audio, Data Quality, DSA Quality, DSE
       Type, LDAP Schema Description, Master And Shadow Access Points,
       Modify Rights, Protocol Information, Subtree Specification,
       Supplier Information, Supplier Or Consumer and 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 Supplier And
       Consumer syntaxes have been removed.  These syntaxes are
       referenced in RFC 2252, but not defined.

   22. The LDAP Schema Definition syntax is modified.

      30. In section 2.2, replaced the editor's proposal (defined in RFC 2927) and subject
          text with explanation of the LDAP-specific encoding of
          attribute values.

      31. Removed section 2.2.2 (and renumbered
       Mail Preference syntax have been removed on the remainder grounds that they
       are out of
          section 2.2), leaving the scope for a core specification.

   23. The description of binary encoding to
          the protocol I-D.

-------
-02 changes

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

      33. Removed embedded comments matching rules has been expanded
       so that they are less dependent on knowledge of X.500 for
       interpretation.

   24. The caseIgnoreIA5SubstringsMatch matching rule from RFC 2798 has
       been added.

   25. The caseIgnoreIA5SubstringsMatch, caseIgnoreOrderingMatch and
       caseIgnoreSubstringsMatch matching rules have been added to the ABNF productions
          throughout the document.

      34. Removed
       list of matching rules for which the Binary syntax because it was not adequately
          specified, implementations with different interpretations
          exist, provisions for handling
       leading, trailing and it was confused multiple adjoining whitespace characters
       apply.  This is consistent with the ;binary transfer encoding.

      35. Removed the syntaxes, which are not defined definitions of these matching
       rules in this document, X.500.  The telephoneNumberMatch rule has been removed
       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 since it completely ignores all space characters.

   26. The specification of the octetstring production, octetStringMatch matching rule from RFC 2234 [ABNF].j
      37. Cleaned up the references;  adopted word instead of number
          tags;  split Section 10 into normative and informative
          subsections.

      38. Inserted ABNF
       2256 has been added to this document.

   27. The presentationAddressMatch matching rule has been removed as it
       depends on an assertion syntax (Presentation Address) that is not
       at draft standard maturity.

   28. The protocolInformationMatch matching rule has been removed as it
       depends on an undefined assertion syntax (Protocol Information).

   29. The definitive reference for ASN.1 has been changed from RFC 1278 in place of a reference.

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

-------
-03 changes

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

   41. Aligned the text ASN.1 referred to the [MODELS] document. by X.500.