WDIFF

draft-ietf-ldapbis-syntaxes-02.txt --> draft-ietf-ldapbis-syntaxes-04.txt

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

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

LDAP: Syntaxes and Matching Rules

Status of this Memo

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

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

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.

Dally, 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

Each attribute stored in a Lightweight Directory Access Protocol
(LDAP) directory, and whose values may be transfered in the LDAP

Legg & Dally Expires 27 August 2002 20 June 2003 [Page 1]

INTERNET-DRAFT draft-ietf-ldapbis-syntaxes-02 27 February LDAP: Syntaxes and Matching Rules December 20, 2002

Abstract

protocol, has a defined syntax which constrains the structure and
format of its values. The Lightweight Directory Access Protocol (LDAP) [Prot] provides comparison semantics for
exchanging AttributeValue fields in protocol. values of a
syntax are not part of the syntax definition but are instead provided
through separately defined matching rules. Matching rules specify an
argument, an assertion value, which also has a defined syntax. This
document defines a base set of syntaxes for LDAP, and the matching rules by which attribute values
of these syntaxes are represented in the LDAP protocol. The syntaxes
defined in this document are used by this and other documents to
define attribute types. In addition, this document defines the set
of attribute syntaxes, which LDAP servers support, and other schema
elements (required and optional) that are common to all
LDAP servers.

[Editor's note: This document is a modified version of the text of
RFC 2252, in order to bring it up to date. This action is part of
the maintenance activity that is needed 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]

Dally, directories.

Legg & Dally Expires 27 August 2002 20 June 2003 [Page 2]

INTERNET-DRAFT draft-ietf-ldapbis-syntaxes-02 27 February LDAP: Syntaxes and Matching Rules December 20, 2002

1. Table of Contents

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

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

Abstract ...................................................... 1
1. Overview...........................................................6 Table of Contents ............................................. 3
2. Introduction .................................................. 4
3. Conventions ................................................... 5
4. Syntaxes ...................................................... 5
4.1 General Issues.....................................................6
2.1 Notation..........................................................6
2.2 Syntaxes..........................................................9
2.2.1 Syntaxes Implementation Status..................................9
2.2.2 Syntax Object Identifiers...................................... 9
2.2.3 Considerations .................................... 5
4.2 Common Definitions ........................................ 6
4.3 Syntax Description.............................................10
2.2.4 Example........................................................10
2.3 Matching Rules...................................................11
2.3.1 Matching Rules Implementation Status...........................11
2.3.2 Matching Rule Description......................................11
2.3.3 Example........................................................12
2.4 Attribute Types..................................................12
2.4.1 Attribute Types Implementation Status..........................12
2.4.2 Attribute Types Description....................................13
2.4.3 Example........................................................15
2.5 Object Classes...................................................15
2.5.1 Object Classes Implementation Status...........................15
2.5.2 Object Class Description.......................................16
2.5.3 Example........................................................16

3. Syntaxes..........................................................18
3.1 Definitions ........................................ 7
4.3.1 Attribute Type Description.......................................18
3.2 Description ........................... 7
4.3.2 Bit String.......................................................18
3.3 Boolean..........................................................19
3.4 String ........................................... 7
4.3.3 Boolean .............................................. 8
4.3.4 Country String...................................................19
3.5 String ....................................... 8
4.3.5 Delivery Method..................................................19
3.6 Method ...................................... 9
4.3.6 Directory String.................................................20
3.7 String ..................................... 9
4.3.7 DIT Content Rule Description.....................................20
3.8 Description ......................... 10
4.3.8 DIT Structure Rule Description...................................21
3.9 DN...............................................................22
3.10 Description ....................... 11
4.3.9 DN ................................................... 11
4.3.10 Enhanced Guide...................................................23
3.11 Guide ...................................... 12
4.3.11 Facsimile Telephone Number.......................................23
3.12 Fax..............................................................24
3.13 Number .......................... 13
4.3.12 Fax ................................................. 13
4.3.13 Generalized Time.................................................24
3.14 Guide............................................................25
3.15 Time .................................... 14
4.3.14 Guide ............................................... 15
4.3.15 IA5 String.......................................................25
3.16 Integer..........................................................25
3.17 JPEG.............................................................26
3.18 String .......................................... 15
4.3.16 Integer ............................................. 16
4.3.17 JPEG ................................................ 16
4.3.18 LDAP Syntax Description..........................................26
3.19 Description ............................. 16
4.3.19 Matching Rule Description........................................26
3.20 Description ........................... 17
4.3.20 Matching Rule Use Description....................................26
3.21 MHS OR Address...................................................27
3.22 Description ....................... 17
4.3.21 Name and Optional UID............................................27
3.23 UID ............................... 18
4.3.22 Name Form Description............................................28

Dally, Legg Expires 27 August 2002 [Page 3]
INTERNET-DRAFT draft-ietf-ldapbis-syntaxes-02 27 February 2002

3.24 Description ............................... 18
4.3.23 Numeric String...................................................29
3.25 String ...................................... 19
4.3.24 Object Class Description.........................................29
3.26 Description ............................ 19
4.3.25 Octet String.....................................................29
3.27 OID..............................................................30
3.28 String ........................................ 20
4.3.26 OID ................................................. 20
4.3.27 Other Mailbox....................................................30
3.29 Mailbox ....................................... 20
4.3.28 Postal Address...................................................30
3.30 Presentation Address.............................................31
3.31 Address ...................................... 21
4.3.29 Printable String.................................................33
3.32 String .................................... 22
4.3.30 Substring Assertion .......................................33
3.33 ................................. 22
4.3.31 Telephone Number.................................................34
3.34 Number .................................... 23
4.3.32 Teletex Terminal Identifier......................................34
3.35 Identifier ......................... 24
4.3.33 Telex Number.....................................................34
3.36 Number ........................................ 24
4.3.34 UTC Time.........................................................35

4. Matching Rules....................................................36
4.1 bitStringMatch...................................................36
4.2 caseExactIA5Match................................................36
4.3 caseIgnoreIA5Match...............................................36
4.4 caseIgnoreListMatch..............................................36
4.5 caseIgnoreMatch..................................................37
4.6 caseIgnoreOrderingMatch..........................................37
4.7 caseIgnoreSubstringsMatch........................................37
4.8 distinguishedNameMatch...........................................37
4.9 generalizedTimeMatch.............................................37
4.10 generalizedTimeOrderingMatch.....................................38
4.11 integerFirstComponentMatch.......................................38
4.12 integerMatch.....................................................38
4.13 numericStringMatch...............................................38
4.14 numericStringSubstringsMatch.....................................38
4.15 objectIdentifierFirstComponentMatch..............................39
4.16 objectIdentifierMatch............................................39
4.17 octetStringMatch.................................................39
4.18 presentationAddressMatch.........................................40
4.19 protocolInformationMatch.........................................40
4.20 telephoneNumberMatch.............................................40
4.21 telephoneNumberSubstringsMatch...................................40
4.22 uniqueMemberMatch................................................40 Time ............................................ 25
5. Attribute Types...................................................41 Matching Rules ................................................ 26
5.1 altServer........................................................41 General Considerations .................................... 26
5.2 attributeTypes...................................................41
5.3 createTimestamp..................................................41
5.4 creatorsName.....................................................41
5.5 dITContentRules..................................................42
5.6 dITStructureRules................................................42
5.7 ldapSyntaxes.....................................................42
5.8 matchingRules....................................................42
5.9 matchingRuleUse..................................................42
5.10 modifiersName....................................................43
5.11 modifyTimestamp..................................................43
5.12 nameForms........................................................43
5.13 namingContexts...................................................43

Dally, Legg Expires Matching Rule Definitions ................................. 27 August 2002 [Page 4]
INTERNET-DRAFT draft-ietf-ldapbis-syntaxes-02
5.2.1 bitStringMatch ....................................... 27 February 2002

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

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

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

8. Acknowledgements..................................................48

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

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

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

Annex A Object Identifiers for Syntaxes..............................51

Annex B Topics to be Addressed in This Document......................52

Annex C Change Log...................................................53

Dally,

Legg & Dally Expires 27 August 2002 20 June 2003 [Page 5] 3]

INTERNET-DRAFT draft-ietf-ldapbis-syntaxes-02 27 February LDAP: Syntaxes and Matching Rules December 20, 2002

1. Overview

This document defines the framework for developing schemas for
directories accessible via the

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. Security Considerations ....................................... 37
7. Acknowledgements .............................................. 38
8. IANA Considerations ........................................... 38
9. Normative References .......................................... 39
10. Informative References ....................................... 40
11. Authors' Addresses ........................................... 41
12. Copyright Notice ............................................. 41
Appendix A. Summary of Syntax Object Identifiers ................. 42
Appendix B. Changes from RFC 2252 & RFC 2256 ..................... 43

2. Introduction

Each attribute stored in a Lightweight Directory Access Protocol
(LDAP) [Prot].

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.

Therefore, Section 2 states the general requirements and notation
for syntax
definition of attribute types, object classes, syntaxes and but are instead provided through separately defined
matching rules.

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

Additional documents define schemas for representing real-world
objects as directory entries.

2. General Issues

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [Keywds]. Matching rules specify an argument, an assertion
value, which also has a defined syntax. This document describes the syntaxes of data conveyed in an
Internet protocol.

Attribute Type and Object Class definitions are written in defines a string
representation base
set of the AttributeTypeDescription syntaxes and
ObjectClassDescription data types defined matching rules for use in X.501 [Models].
Implementors defining attributes for
LDAP directories.

Readers are strongly advised to first read familiarize themselves with the description of
how schema is represented in X.500 Directory
Information Models [MODELS] before reading the rest of this document.

2.1 Notation

For
Section 4 provides definitions for the purposes base set of defining LDAP syntaxes.
Section 5 provides definitions for the base set of matching rules for describing attribute
syntaxes

Legg & Dally Expires 20 June 2003 [Page 4]

INTERNET-DRAFT LDAP: Syntaxes and other schema elements, Matching Rules December 20, 2002

LDAP.

This document is a integral part of the following augmented
Backus-Naur Form (ABNF) definitions will be used. They are based on LDAP technical specification
[ROADMAP] which obsoletes the ABNF styles previously defined LDAP technical
specification [RFC3377] in its entirety.

Sections 4, 5 and 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 2234 [ABNF]. 2256 are obsoleted by this document. The changes from
RFC 2252 and RFC 2256 [RFC2256] are described in Appendix B of this
document.

3. Conventions

The schema key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [KEYWORD].

Syntax definitions are written according to the <SyntaxDescription>
ABNF [ABNF] rule specified in [MODELS], and matching rule definitions
are written according to the <MatchingRuleDescription> ABNF rule
specified in [MODELS], except that the syntax and matching rule
definitions provided in this document are line-wrapped for
readability.

The When such definitions for ALPHA, DIGIT, ldapOID, number, DOT, LDIGIT, and
HYPHEN are given transfered as attribute
values in the LDAP protocol specification [Prot].

Dally, Legg Expires 27 August 2002 [Page 6]
INTERNET-DRAFT draft-ietf-ldapbis-syntaxes-02 27 February 2002

The definition (e.g. as values of OCTET, from [ABNF], is:

OCTET = %x00-FF
; 8 bits the ldapSyntaxes and
matchingRules attributes [MODELS] respectively) then those values
would not contain line breaks.

4. Syntaxes

Syntax definitions constrain the structure of data

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

k = ALPHA / DIGIT / HYPHEN

octetstring = *OCTET

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

numericstring = 1*DIGIT

anhstring = 1*k

keystring = ALPHA [ anhstring ]

printablestring = 1*p

space = 1*" "

whsp = [ space ]

utf8 = <any sequence of octets formed from the UTF-8 [UTF-8]
transformation of a character from ISO 10646 [UCS]
except "'">

dstring = 1*( utf8 / "''" )
; escaped utf8 string, each "'"
; appearing attribute values stored
in an LDAP directory, and determine the value to be encoded is
; escaped by a preceding "'"

qdstring = "'" dstring "'"

qdstringlist = [ qdstring *( space qdstring ) ]

qdstrings = qdstring / ( "(" whsp qdstringlist whsp ")" )

In the following ABNF for the string representation of OBJECT
IDENTIFIERs, 'descr' is the syntactic representation of an object
descriptor, which consists of letters, digits, attribute
and hyphens starting
with a letter. An OBJECT IDENTIFIER assertion values transfered in the numericoid format SHOULD
NOT have leading zeroes (e.g., "0.9.3" is permitted but "0.09.3"
SHOULD NOT be generated).

When 'oid' elements occur LDAP protocol.

Syntaxes that are required for directory operation, or that are in a value, the 'descr' notation option
common use, are specified in this section. Servers SHOULD be used recognize
all the syntaxes listed in preference this document, but are NOT REQUIRED to
otherwise support them, and MAY recognise or support other syntaxes.
However, the 'numericoid'. An object
descriptor definition of additional arbitrary syntaxes is more readable than a numeric OBJECT IDENTIFIER,
discouraged since it will hinder interoperability. Client and a

Dally, server
implementations typically do not have the ability to dynamically
recognize new syntaxes.

4.1 General Considerations

Legg & Dally Expires 27 August 2002 20 June 2003 [Page 7] 5]

INTERNET-DRAFT draft-ietf-ldapbis-syntaxes-02 27 February 2002

descriptor (where assigned LDAP: Syntaxes and known by Matching Rules December 20, 2002

The description of each syntax specifies how attribute or assertion
values conforming to the implementation) SHOULD syntax are to be used represented when transfered
in preference to numeric oids the LDAP protocol [PROT]. This representation is referred to as
the greatest extent
possible. Examples LDAP-specific encoding to distinguish it from other methods of object descriptors in LDAP are
encoding attribute
type, object class, and matching rule names.

oid = descr / numericoid

descr = keystring

numericoid = numericstring *( DOT numericstring )

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

len = numericstring

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

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

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

qdescrlist = [ qdescr *( whsp qdescr ) ]

qdescr = "'" descr "'"

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

extensions = *( space xstring space qdstrings )

Note that while lines have been folded for readability in values (e.g. the
definitions BER encoding [BER] used by X.500
[X.500] directories).

The LDAP-specific encoding of schema elements, (e.g., objectClassDescription
attribute), the values transferred in protocol would not contain
newlines.

In cases where an arbitrary string, not a Distinguished Name given attribute syntax always
produces octet-aligned values. To the greatest extent possible,
encoding rules for LDAP syntaxes should produce character strings
that can be displayed with little or part no translation by clients
implementing LDAP. However, clients MUST NOT assume that the
LDAP-specific encoding of one, is used in a value of an attribute, a backslash quoting
mechanism unrecognized syntax is used to escape the following separator symbol
character, (such as, "'", "$" or "#") if it occurs in that a
human-readable character string. The backslash is followed by There are a pair of hexadecimal digits
representing the next character. A backslash itself in few cases (e.g. the string
which forms part of
JPEG syntax) when it is not reasonable to produce a larger human-readable
representation.

Each LDAP syntax is always uniquely identified with an object identifier
[ASN.1] represented as '\5C'
or '\5c'. An example is given in section 3.33, postalAddress syntax.

Servers the dotted-decimal format (short descriptive
names are not required defined for syntaxes). These object identifiers are
not intended to be displayed to provide users. The object identifiers for
the same or any text syntaxes defined in this document are summarized in Appendix A.

A suggested minimum upper bound on the
description part number of the subschema values they maintain.

Dally, Legg Expires 27 August 2002 [Page 8]
INTERNET-DRAFT draft-ietf-ldapbis-syntaxes-02 27 February 2002

2.2 Syntaxes

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

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

Syntaxes that are currently in use in this specification and string-based syntax, or the
user schema specification [User] are specified in this document number of octets
in
Section 3. The object identifiers a value for these syntaxes are listed in
Annex A, also.

In X.501 [Models] and X.520 [Attr], all other syntaxes, MAY be indicated by appending the definition
bound inside of curly braces following the syntax syntax's OBJECT IDENTIFIER
in an attribute type definition (see the <noidlen> rule in [MODELS]).
Such a bound is not considered part of the attribute specification and a distinct OID for the syntax
is not assigned. As a result, X.501 does not define identifier.

For example, "1.3.6.1.4.1.1466.115.121.1.15{64}" in an attribute for
publishing syntaxes explicitly in
definition suggests that the directory server will allow a subschema entry.

In [Prot], value of
the encoding attribute to be up to 64 characters long, although it may allow
longer character strings. Note that a single character of the LDAP protocol
Directory String syntax can be encoded in more than one octet since
UTF-8 [UTF-8] is specified. a variable-length encoding. Therefore a 64
character string may be more than 64 octets in length.

4.2 Common Definitions

The
protcol encapsulates values of attributes following ABNF rules are used in many places. In this
specification, the encoding a number of the values is specified, as part of
each syntax definition. These value encoding rules are termed
"native LDAP encoding". The native LDAP encoding of a value is what
is transmitted
definitions in the protocol, unless a transfer option has been
invoked for the value. The transfer option mechanism Section 4.3.

PrintableCharacter = ALPHA / DIGIT / SQUOTE / LPAREN / RPAREN /
PLUS / COMMA / HYPHEN / DOT / EQUALS /
SLASH / COLON / QUESTION / SPACE
PrintableString = 1*PrintableCharacter

Legg & Dally Expires 20 June 2003 [Page 6]

INTERNET-DRAFT LDAP: Syntaxes and the Binary
transfer option Matching Rules December 20, 2002

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 defined in [Prot].

The native LDAP encoding
[MODELS].

4.3 Syntax Definitions

4.3.1 Attribute Type Description

A value of a given attribute syntax always produces
octet-aligned values. To the greatest extent possible, Attribute Type Description syntax is the
native LDAP definition of
an attribute type. The LDAP-specific encoding of a value of this
syntax is supposed to be usable for display
purposes. In particular, encoding rules for attribute syntaxes
defining non-binary values are supposed to produce strings that can
be displayed with little or no translation defined 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.1 Syntaxes Implementation Status

Clients and servers need not implement all the syntaxes listed, and
MAY implement other syntaxes.

Clients MUST NOT assume that <AttributeTypeDescription> rule in [MODELS].
For example, the native LDAP encoding following definition of the createTimestamp
attribute type from [MODELS] is also a value of
an unrecognized the Attribute Type
Description syntax is a human-readable character string.

2.2.2 Syntax Object Identifiers

Syntaxes (note: line breaks have been added for use with LDAP are named by OBJECT IDENTIFIERs, which
are dotted-decimal strings. These readability
- they are not intended to be displayed

Dally Expires 27 August 2002 [Page 9]
INTERNET-DRAFT draft-ietf-ldapbis-syntaxes-02 27 February 2002

to users. Annex A lists part of the syntaxes that have been defined for
LDAP value when transfered in this document.

Other documents define additional syntaxes. However, the protocol).

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

The LDAP definition of additional arbitrary syntaxes is strongly deprecated
since it will hinder interoperability. Today's client and server
implementations generally do not have for the ability Attribute Type Description syntax is:

( 1.3.6.1.4.1.1466.115.121.1.3 DESC 'Attribute Type Description' )

This syntax corresponds to dynamically
recognize new syntaxes. In most cases, attributes will be defined
with the syntax for directory strings. AttributeTypeDescription ASN.1 type
from [X.501].

4.3.2 Bit String

A suggested minimum upper bound on the number of characters in a value with a string-based syntax, or of the number Bit String syntax is a sequence of binary digits. The
LDAP-specific encoding of bytes in a value
for all other syntaxes, can be indicated by appending this bound
count inside of curly braces this syntax is defined by the
following ABNF:

BitString = SQUOTE *binary-digit SQUOTE "B"
binary-digit = "0" / "1"

Legg & Dally Expires 20 June 2003 [Page 7]

INTERNET-DRAFT LDAP: Syntaxes and Matching Rules December 20, 2002

The <SQUOTE> rule is defined in [MODELS].

Example:
'0101111101'B

The LDAP definition for the Bit String syntax name's OBJECT
IDENTIFIER in an attribute is:

( 1.3.6.1.4.1.1466.115.121.1.6 DESC 'Bit String' )

This syntax corresponds to the BIT STRING ASN.1 type definition. See from [ASN.1].

4.3.3 Boolean

A value of the "numericoid"
production in paragraph 2.1. Such a bound Boolean syntax is not part one of the syntax
name itself. For instance, "1.3.6.4.1.1466.0{64}" suggests that
server implementations would allow a string to be 64 characters
long, although they can allow longer strings. Note that Boolean values, true or
false. The LDAP-specific encoding of a single
character value of the Directory String this syntax can be encoded in more than
one byte since UTF-8 [UTF-8] is a variable-length encoding.

2.2.3 Syntax Description

The
defined by the following ABNF is used in this document to associate a short
description (e.g., a name) with a syntax OBJECT IDENTIFIER. ABNF:

Boolean = "TRUE" / "FALSE"

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

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

Note that the SyntaxDescription ABNF is also Boolean syntax is:

( 1.3.6.1.4.1.1466.115.121.1.7 DESC 'Boolean' )

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

4.3.4 Country String

A value of the native LDAP Country String syntax is one of the two-character
codes from ISO 3166 [ISO3166] for representing a country. The
LDAP-specific encoding of values a value of this syntax is defined by the
following ABNF:

CountryString = 2(PrintableCharacter)

The <PrintableCharacter> rule is defined in Section 4.2.

Examples:
US
AU

The LDAP Syntax Description
syntax.

2.2.4 Example

For example, the syntax descripion of definition for the INTEGER Country String syntax for whole
number values is:

( 1.3.6.1.4.1.1466.115.121.1.27 1.3.6.1.4.1.1466.115.121.1.11 DESC 'INTEGER' 'Country String' )

Dally,

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

Legg & Dally Expires 27 August 2002 20 June 2003 [Page 10] 8]

INTERNET-DRAFT draft-ietf-ldapbis-syntaxes-02 27 February 2002

2.3 LDAP: Syntaxes and Matching Rules

The matching rules specified December 20, 2002

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

4.3.5 Delivery Method

A value of the Delivery Method syntax is a sequence of items that
indicate, in preference order, the service(s) by which an entity is
willing and/or capable of receiving messages. The LDAP-specific
encoding of a value of this document are syntax is defined in
section 4.

( 1.3.6.1.4.1.1466.115.121.1.27 DESC 'INTEGER' by the following ABNF:

DeliveryMethod = pdm *( WSP DOLLAR WSP pdm )

Matching

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

The <WSP> and <DOLLAR> rules are used by servers to compare attribute values
against assertion values when performing Search and Compare
operations. They are also used to identify the value to be added
or deleted when modifying entries, and are used when comparing a
purported distinguished name with the name of an entry.

Most of the attributes given in this document have an equality
matching rule defined.

...An OID is assigned to a matching rule when it 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 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, then the server MAY use
the matchingRuleUse attribute to indicate the applicability of
selected matching rules to designated attribute types in an
extensibleMatch.

2.3.2 Matching Rule Description

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

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

Dally, Legg Expires 27 August 2002 [Page 11]
INTERNET-DRAFT draft-ietf-ldapbis-syntaxes-02 27 February 2002

extensions
whsp ")"

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

Note that the MatchingRuleDescription ABNF is also the ABNF that
defines the native LDAP encoding of values of the Matching Rule
Description syntax.

2.3.3 Example

For example, in specifying a server which implements a privately-
defined matching rule for performing sound-alike matches on
Directory String-valued attributes, the matching rule could be
written as (1.1.2.3.4.5 is an example, the OID of an actual matching
rule would be different):

matchingRule: ( 1.1.2.3.4.5 NAME 'soundAlikeMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

This description could be the one included in the subschema entry in
the server. If this matching rule could be used with the attributes
2.5.4.41 and 2.5.4.15, the following could be the use description
present in the subschema entry:

matchingRuleUse: ( 1.1.2.3.4.5 APPLIES ( givenName $ surname ) )

A client could then make use of this matching rule by sending a
search operation in which the filter is of the extensibleMatch
choice, the matchingRule field is "soundAlikeMatch", and the type
field is "givenName" or "surName".

2.4 Attribute Types

Attributes represent the characteristics of the real-world object
which an entry represents. The attributes defined in this document
are given in section 5.

An OID is assigned to an attribute type when it is defined. An
attribute type definition ought not be changed without having a new
OID assigned to it.

2.4.1 Attribute Types Implementation Status

Servers MUST publish in the attributeTypes attribute of the same
subschema entry, the definitions of attribute types referenced by
values of the objectClasses, nameForms, matchingRuleUse and
dITContentRules attributes, and attribute types referenced by the
SUP field in values of the attributeTypes attribute itself. Other
unreferenced attribute types MAY be published in the attributeTypes
attribute.

Dally, Legg Expires 27 August 2002 [Page 12]
INTERNET-DRAFT draft-ietf-ldapbis-syntaxes-02 27 February 2002

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

All LDAP server implementations MUST recognize the attribute types
defined in section 5.

Servers MUST maintain values of these attributes in accordance with
the definitions in X.501(93): createTimestamp, modifyTimestamp,
creatorsName, modifiersName, subschemaSubentry, attributeTypes,
objectClasses, matchingRules, and matchingRuleUse.

The createTimestamp and creatorsName attributes SHOULD appear
in entries which were created using the Add operation.

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

The subschemaSubentry attribute SHOULD appear in all entries.

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

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

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

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

2.4.2 Attribute Type Description

Attribute types are expressed according to the following ABNF.
The productions for whsp, numericoid, qdescrs, qdstring, space,
oid, and noidlen are given in paragraph 2.1. Implementors,
note that future versions of this document could expand this ABNF to
include additional terms. Terms which begin with the characters
"X-" are reserved for private experiments, and MUST be followed by a
<space> and a <qdstrings> tokens.

AttributeTypeDescription = "(" whsp
numericoid
[ space "NAME" qdescrs ]
[ space "DESC" qdstring ]
[ space "OBSOLETE" ]

Dally, Legg Expires 27 August 2002 [Page 13]
INTERNET-DRAFT draft-ietf-ldapbis-syntaxes-02 27 February 2002

[ space "SUP" space oid ]
[ space "EQUALITY" space oid ]
[ space "ORDERING" space oid ]
[ space "SUBSTR" space oid ]
[ space "SYNTAX" space noidlen ]
[ space "SINGLE-VALUE" ]
[ space "COLLECTIVE" ]
[ space "NO-USER-MODIFICATION" ]
[ space "USAGE" space AttributeUsage ]
extensions
whsp ")"

The numericoid is the identifier of the AttributeType being
described.

The NAME string is the string registered with IANA [Consid] and used
to identify values and value assertions of the attribute described.

The SUP oid is an identifier of the Attribute Type from which the
attribute described is derived (i.e., a subtype).

The EQUALITY, ORDERING, AND SUBSTR oids name the Matching Rules for
the attribute being defined.

See section 2.3 for the SYNTAX noidlen explanation.

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

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

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

The default setting is "userApplication" when USAGE is absent.

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

An AttributeDescription (i.e., the means of referring to an attribute
in the protocol [Prot]) can be used as the value in a NAME part of
an AttributeTypeDescription. Note that these are case insensitive.

Note that the AttributeTypeDescription does not list the matching
rules which can be used with that attribute type in an
extensibleMatch search filter. This is done using the
matchingRuleUseDescription described defined in section 3.24. [MODELS].

Example:
telephone $ videotex

The LDAP definition for the Delivery Method syntax is:

( 1.3.6.1.4.1.1466.115.121.1.14 DESC 'Delivery Method' )

This document refines syntax corresponds to the schema description 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 of X.501 [Models] by
requiring that the Directory String syntax field in an AttributeTypeDescription be is a string representation of an OBJECT IDENTIFIER for the LDAP string
syntax definition, and a possible indication of one or more
arbitrary characters from the maximum Universal Character Set (UCS) [UCS]. A
zero length character string is not permitted. The LDAP-specific
encoding of a value of this attribute (defined in section 2.2.2).

Dally, Legg Expires 27 August 2002 [Page 14]
INTERNET-DRAFT draft-ietf-ldapbis-syntaxes-02 27 February 2002

Note that the AttributeTypeDescription ABNF syntax is also the ABNF that
defines the Attribute Type Description syntax.

2.4.3 Example

For example, it would be useful for UTF-8 encoding [UTF-8] of
the directory character string. Such encodings conform to know when an
entry was put into the directory. The following definition is an
Attribute Type Description that could be used to specify such
an attribute.

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

The SYNTAX oid indicates the Generalized Time syntax.

2.5 Object Classes

Object classes are used to categorize the kinds of entries stored in
the directory ABNF:

DirectoryString = 1*UTF8

Legg & Dally Expires 20 June 2003 [Page 9]

INTERNET-DRAFT LDAP: Syntaxes and to determine what attributes are contained in
those entries.

In general, every entry Matching Rules December 20, 2002

The <UTF8> rule is defined in terms of an abstract class
("top"), at least one structural object class, and zero or more
auxiliary object classes.

Whether an object class is abstract, structural, or auxiliary is
defined when the object class OID is assigned. An object class
definition ought not be changed without having a new identifier
assigned to it.

2.5.1 Object Classes Implementation Status

Servers SHOULD implement the subschema object class.

Implementing the extensibleObject object class [MODELS].

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

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

Attribute type definitions using the same
subschema entry, Directory String syntax should
not restrict the definitions format of object classes referenced Directory String values, e.g. by
values of requiring
that the nameForms and dITContentRules attributes, and object
classes referenced character string conforms to specific patterns described by the SUP field in values of the objectClasses
attribute itself. Other unreferenced object classes MAY
ABNF. A new syntax should be
published in the objectClasses attribute.

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

Dally, Legg Expires 27 August 2002 [Page 15]
INTERNET-DRAFT draft-ietf-ldapbis-syntaxes-02 27 February 2002

2.5.2 Object Class Description

Object class descriptions are written according to the following
ABNF. such cases.

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

ObjectClassDescription = "(" whsp
numericoid
[ space "NAME" space qdescrs ]
[ space "DESC" space qdstring ]
[ space "OBSOLETE" ]
[ space "SUP" space oids ]
[ space the Directory String syntax is:

( "ABSTRACT" / "STRUCTURAL" / "AUXILIARY" 1.3.6.1.4.1.1466.115.121.1.15 DESC 'Directory String' ) ]
[ space "MUST" space oids ]
[ space "MAY" space oids ] ; AttributeTypes
extensions
whsp ")"

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

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

Implementations which convert Directory String values from the ObjectClass being described.

The NAME string is
LDAP-specific encoding to the BER encoding used by X.500 must choose
an alternative that permits the string registered with IANA [Consid] and used
to identify instances of particular characters in the ObjectClass described.

The SUP oids are string,
and must convert the identifiers of characters from the Object Classes which are UTF-8 encoding into the
superclasses (object classes)
character encoding of the Object Class defined.

The default setting is "structural" when ABSTRACT, STRUCTURAL, and
AUXILIARY are absent.

The MUST oids identify chosen alternative.

When converting Directory String values from the Attribute Types that are required BER encoding to have
values in every instance of the Object Class.

The MAY oids identify Attribute Types that can appear, as
appropriate, in an instance of
LDAP-specific encoding the Object Class.

2.5.3 Example

For example, information about an employee with respect to their
job is useful in an application which queries characters must be converted from the directory. The
same pieces of information are needed in several kinds
character encoding of entries,
such as manager, part-time, and exempt employees. An auxiliary
object class could be developed to be included in the structural
object classes that represent chosen alternative into the different kinds of employees. The
pieces of information could be: name UTF-8 encoding.

4.3.7 DIT Content Rule Description

A value of the last training course
attended, how many courses has DIT Content Rule Description syntax is the employee taken, category of
training program. The types definition
of information could be named the
lastCourse, coursesCount, program attributes, respectively. a DIT content rule. The
following could be the description LDAP-specific encoding of an auxiliary object class that

Dally, Legg Expires 27 August 2002 [Page 16]
INTERNET-DRAFT draft-ietf-ldapbis-syntaxes-02 27 February 2002

provides for inclusion a value of this
syntax is defined by the training information <DITContentRuleDescription> rule in different
kinds of entries. (The OID is artificial.)
[MODELS].

Example:
( 1.1.3.170.2.65 NAME 'trainingInfo'
AUXILIARY
MUST program
MAY 2.5.6.4 DESC 'content rule for organization'
NOT ( lastCourse x121Address $ coursesCount telexNumber ) )

Dally,

Legg & Dally Expires 27 August 2002 20 June 2003 [Page 17] 10]

INTERNET-DRAFT draft-ietf-ldapbis-syntaxes-02 27 February 2002

3. LDAP: Syntaxes

3.1 Attribute Type and Matching Rules December 20, 2002

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

The LDAP definition for the DIT Content Rule Description syntax is:

( 1.3.6.1.4.1.1466.115.121.1.16
DESC 'DIT Content Rule Description' )

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

4.3.8 DIT Structure Rule Description

A value of the DIT Structure Rule Description

A value in this syntax is a the
definition of an attribute type
according to the ABNF given in paragraph 2.4.2. a DIT structure rule. The native LDAP LDAP-specific encoding is the character codes in UTF-8 which correspond to the
characters in the definition.

This of a
value of this syntax is defined by the form in which schema attribute types are
published in the directory <DITStructureRuleDescription>
rule in a subentry. [MODELS].

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

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

( 1.3.6.1.4.1.1466.115.121.1.3 1.3.6.1.4.1.1466.115.121.1.17
DESC 'Attribute Type 'DIT Structure Rule Description' )

For example,

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

4.3.9 DN

A value of the DN syntax is the (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].

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 from [User] of for the
businessCategory attribute type: DN syntax is:

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

Legg & Dally Expires 20 June 2003 [Page 11]

INTERNET-DRAFT LDAP: Syntaxes and Matching Rules December 20, 2002

The DN syntax corresponds to the DistinguishedName ASN.1 type for from
[X.501]. Note that a BER encoded distinguished name (as used by
X.500) re-encoded into the businessCategory Attribute Type is Directory
String.

This example definition LDAP-specific encoding is a value of not necessarily
reversible to the Attribute Type Description
syntax. The native LDAP original BER encoding since the chosen string type
in any DirectoryString components of this value the distinguished name is not
indicated in the definition
itself.

3.2 Bit String LDAP-specific encoding of the distinguished name
(see Section 4.3.6).

4.3.10 Enhanced Guide

A value in this syntax is a value of the BIT STRING data type from
ASN.1 [ASN1]. Enhanced Guide syntax suggests criteria, which consist
of combinations of attribute types and filter operators, to be used
in constructing filters to search for entries of particular object
classes. The 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.6 DESC 'Bit String' ) be specified.

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

bitstring

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

binary-digit object-class SHARP WSP criteria WSP
SHARP WSP subset
object-class = "0" WSP oid WSP
subset = "baseobject" / "1" "oneLevel" / "wholeSubtree"

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

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

The LDAP definition for the Enhanced Guide syntax is:

( 1.3.6.1.4.1.1466.115.121.1.21 DESC 'Enhanced Guide' )

Example: '0101111101'B

Dally,

Legg & Dally Expires 27 August 2002 20 June 2003 [Page 18] 12]

INTERNET-DRAFT draft-ietf-ldapbis-syntaxes-02 27 February LDAP: Syntaxes and Matching Rules December 20, 2002

3.3 Boolean

A value in this

person#(sn$EQ)#oneLevel

The Enhanced Guide syntax is a value of corresponds to the BOOLEAN data EnhancedGuide ASN.1 type
from
ASN.1 [ASN1]. That is, there are exactly two values: one value
representing logically true, and the other representing logically
false. The following syntax description gives the OID assigned to
this syntax:

( 1.3.6.1.4.1.1466.115.121.1.7 DESC 'Boolean' ) [X.520]. The native LDAP encoding of a value is EnhancedGuide type references the following ABNF:

boolean = "TRUE" / "FALSE"

3.4 Country String

A value in this syntax is two Criteria ASN.1 printable string characters
representing a country.
type, also from [X.520]. The permitted values are as listed <true> rule above represents an empty
"and" expression in
ISO 3166 [Codes]. 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 native LDAP encoding of a value is of the following ABNF:

CountryString = p p Criteria type. The production for p is given in section 2.1.

Example: US

3.5 Delivery Method

A value <false> rule
above represents an empty "or" expression in this syntax is a set value of the ASN.1 enumerated INTEGER
values that indicates, in preference order, the service(s) by which
the user, represented by Criteria
type.

4.3.11 Facsimile Telephone Number

A value of the entry, Facsimile Telephone Number syntax is willing and/or capable a subscriber
number of
receiving messages.

The following syntax description gives a facsimile device on the OID assigned to this
syntax:

( 1.3.6.1.4.1.1466.115.121.1.14 DESC 'Delivery Method' ) public switched telephone
network. The native LDAP LDAP-specific encoding of a value of this syntax is
defined by the following ABNF:

delivery-value

fax-number = pdm / ( whsp pdm space "$" space delivery-value telephone-number *( DOLLAR fax-parameter )

pdm
telephone-number = "any" / "mhs" / "physical" / "telex" PrintableString
fax-parameter = "twoDimensional" / "teletex"
"fineResolution" /
"g3fax"
"unlimitedLength" / "g4fax"
"b4Length" / "ia5"
"a3Width" / "videotex"
"b4Width" / "telephone"

Dally, Legg Expires 27 August 2002 [Page 19]
INTERNET-DRAFT draft-ietf-ldapbis-syntaxes-02 27 February 2002
"uncompressed"

The production for space is given in section 2.1.

Example: telephone $ videotex

3.6 Directory String

A value in this syntax <telephone-number> is a value of one of the TeletexString,
PrintableString or UniversalString data types from ASN.1 [ASN1]. The
minimum length of a Directory String value is one character, that
is, the 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' )

The native LDAP encoding of a value is printable characters that
complies with the character string itself.

Note: internationally agreed format for representing
international telephone numbers [E.123]. The form of DirectoryString <PrintableString> rule
is not indicated defined in protocol,
unless 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.

Example:
This Section 4.2. The <DOLLAR> rule is a string of DirectoryString containing #!%#@.

For characters defined in [MODELS].

The LDAP definition for the PrintableString form, 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 native
LDAP encoding Fax syntax is an image which is produced using the
Group 3 facsimile process [FAX] to duplicate an object, such as a
memo. The LDAP-specific encoding of a value itself.

If it of this syntax is in the TeletexString form, then the characters are
transliterated to their equivalents
string of octets for a Group 3 Fax image as defined in UniversalString, [FAX].

The LDAP definition for the Fax syntax is:

Legg & Dally Expires 20 June 2003 [Page 13]

INTERNET-DRAFT LDAP: Syntaxes and encoded
in UTF-8 [UTF-8].

If it Matching Rules December 20, 2002

( 1.3.6.1.4.1.1466.115.121.1.23 DESC 'Fax' )

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

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

The G3FacsimileBodyPart ASN.1 type is defined in [X.420].

4.3.13 Generalized Time

A value of the UniversalString or BMPString forms [UCS], UTF-8 Generalized Time syntax is
the native LDAP encoding.

3.7 DIT Content Rule Description

A a character string
representing a date and time. The LDAP-specific encoding of a value in
of this syntax is a definition restriction of a DIT content rule
according to the format defined in [ISO8601],
and is described by the following ABNF:

DITContentRuleDescription

century = "(" whsp
numericoid
[ space "NAME" space qdescrs ]
[ space "DESC" space qdstring ] 2(%x30-39) ; "00" to "99"
year = 2(%x30-39) ; "00" to "99"
month = ( %x30 %x31-39 ) ; "01" (January) to "09"
/ ( %x31 %x30-32 ) ; "10" to "12"
day = ( %x30 %x31-39 ) ; "01" to "09"
/ ( %x31-32 %x30-39 ) ; "10" to "29"
/ ( %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
[ space "OBSOLETE" ] minute [ space "AUX" space oids second ]
[ space "MUST" space oids ] [ space "MAY" space oids fraction ]

Dally, Legg Expires 27 August 2002 [Page 20]
INTERNET-DRAFT draft-ietf-ldapbis-syntaxes-02 27 February 2002
g-time-zone
fraction = ( DOT / COMMA ) 1*(%x30-39)
g-time-zone = %x5A ; "Z"
/ g-differential
g-differential = ( MINUS / PLUS ) hour [ space "NOT" space oids minute ]
extensions
whsp ")"
MINUS = %x2D ; minus sign ("-")

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

The time value represents coordinated universal time (equivalent to
Greenwich Mean Time) if the identifier "Z" form of <g-time-zone> is used,
otherwise the Structural Object Class to
which the Content Rule being described applies.

The MUST oids identify Attribute Types, besides those value represents a local time in the
Structural Object Class, that must have values in every instance of time zone
indicated by <g-differential>. In the Object Class.

...The MAY oids identify Attribute Types, besides those in latter case, coordinated
universal time can be calculated by subtracting the
Structural and Auxiliary Object Classes, that are permitted to have
values in an instance of differential from
the Structural Object Class. local time. The NOT oids identify Attribute Types, which occur "Z" form of <g-time-zone> SHOULD be used in the Structural
preference to <g-differential>.

Legg & Dally Expires 20 June 2003 [Page 14]

INTERNET-DRAFT LDAP: Syntaxes and Auxiliary Object Classes, that are prohibited from having Matching Rules December 20, 2002

Examples:
199412161032Z
199412160532-0500

Both example values
in an instance of represent the Structural Object Class. same coordinated universal time:
40:32 am, December 16, 1994.

The AUX oids identify LDAP definition for the Auxiliary Object Classes which can be
added Generalized Time syntax is:

( 1.3.6.1.4.1.1466.115.121.1.24 DESC 'Generalized Time' )

This syntax corresponds to instances the GeneralizedTime ASN.1 type from
[ASN.1], with the constraint that local time without a differential
SHALL NOT be used.

4.3.14 Guide

A value of the Structural Object Class.

The productions for whsp, numericoid, qdescrs, qdstring, space Guide syntax suggests criteria, which consist of
combinations of attribute types and
oids are given filter operators, to be used in section 2.1. Implementors, note that future
versions of this document could expand this ABNF
constructing filters to include
additional terms. Terms which begin with the characters "X-" are
reserved search for private experiments, entries of particular object
classes. The Guide syntax is obsolete and MUST should not be followed by a <space>
and used for
defining new attribute types.

The LDAP-specific encoding of a <qdstrings> tokens.

This value of this syntax is defined by
the form in which schema content following ABNF:

Guide = [ object-class SHARP ] criteria

The <object-class> and <criteria> rules are published defined in the directory Section
4.3.10. The <SHARP> rule is defined in a subentry. [MODELS].

The following syntax description
gives LDAP definition for the OID assigned to this syntax: Guide syntax is:

( 1.3.6.1.4.1.1466.115.121.1.16 1.3.6.1.4.1.1466.115.121.1.25 DESC 'DIT Content Rule
Description' 'Guide' )

3.8 DIT Structure Rule Description

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

4.3.15 IA5 String

A value in of the DIT Structure Rule Description IA5 String syntax is a definition string of a schema Structure Rule according to the following ABNF:

DITStructureRuleDescription = "(" whsp
ruleidentifier
[ space "NAME" space qdescrs ]
[ space "DESC" space qdstring ]
[ space "OBSOLETE" ]
space "FORM" space oid
[ space "SUP" ruleidentifiers ]
extensions
whsp ")"

Dally, Legg Expires 27 August 2002 [Page 21]
INTERNET-DRAFT draft-ietf-ldapbis-syntaxes-02 27 February 2002

The ruleidentifier is an integer which distinguishes zero, one Structure
Rule or more
characters from International Alphabet 5 (IA5) [T.50], the others used in
international version of the same LDAP server. ASCII character set. The FORM oid identifies the Name Form that specifies LDAP-specific
encoding of a value of this syntax is the naming
attribute(s) used at unconverted string of
characters, which conforms to the point <IA5String> rule in Section 4.2.

The LDAP definition for the DIT IA5 String syntax is:

Legg & Dally Expires 20 June 2003 [Page 15]

INTERNET-DRAFT LDAP: Syntaxes and Matching Rules December 20, 2002

( 1.3.6.1.4.1.1466.115.121.1.26 DESC 'IA5 String' )

This syntax corresponds to which the Structure
Rule applies. IA5String ASN.1 type from [ASN.1].

4.3.16 Integer

A value of the Integer syntax is a whole number of unlimited
magnitude. The SUP ruleidentifiers indicate LDAP-specific encoding of a value of this syntax is
the Structure Rules that can be
applied immediately ahead optionally signed decimal digit character string representation
of the subject Structure Rule in number (so, for example, the DIT.
That is, number 1321 is represented by the RDN forms which can be one level higher in
character string "1321"). The encoding is defined by the DIT.

ruleidentifier = numericstring

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

ruleidentifierlist following
ABNF:

Integer = [ ruleidentifier *( space ruleidentifier ) HYPHEN ] number

The productions for whsp, numericstring, qdescrs, qdstring, space, <HYPHEN> and oid <number> rules are given defined in paragraph 2.1. [MODELS].

The native LDAP encoding is definition for the character codes in UTF-8 [UTF-8]
which correspond Integer syntax is:

( 1.3.6.1.4.1.1466.115.121.1.27 DESC 'INTEGER' )

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

4.3.17 JPEG

A value of the structure rule definition.

This JPEG syntax is the form in which schema structure rules are
published an image in the directory JPEG File Interchange
Format (JFIF), as described in a subentry. [JPEG]. The following LDAP-specific encoding of
a value of this syntax
description gives is the OID assigned to this syntax: sequence of octets of the JFIF encoding
of the image.

The LDAP definition for the JPEG syntax is:

( 1.3.6.1.4.1.1466.115.121.1.17 1.3.6.1.4.1.1466.115.121.1.28 DESC 'DIT Structure Rule
Description' 'JPEG' )

3.9 DN

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 Distinguished Name LDAP Syntax Description syntax is the description of
an LDAP syntax. The LDAP-specific encoding of a structured set value of this syntax
is defined by the
ASN.1 data types that are included <SyntaxDescription> rule in the DirectoryString syntax. [MODELS].

Legg & Dally Expires 20 June 2003 [Page 16]

INTERNET-DRAFT LDAP: Syntaxes and Matching Rules December 20, 2002

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

( 1.3.6.1.4.1.1466.115.121.1.12 1.3.6.1.4.1.1466.115.121.1.54 DESC 'DN' 'LDAP Syntax Description' )

The native above LDAP encoding of definition for the LDAP Syntax Description syntax is
itself a legal value of the LDAP Syntax Description syntax.

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

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

The DirectoryString parameterized ASN.1 type is defined in [DN String]. Note
that [X.520].
The value of ub-schema is implementation defined.

4.3.19 Matching Rule Description

A value of the native LDAP encoding Matching Rule Description syntax is not reversible to the original BER definition of
a matching rule. The LDAP-specific encoding used in X.500 for Distinguished Names, as the CHOICE of any
DirectoryString element a value of this
syntax is defined by the <MatchingRuleDescription> rule in an RDN [MODELS].

Example:
( 2.5.13.2 NAME 'caseIgnoreMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

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

The LDAP
encoding.. See definition for the note in section 3.10.

Examples (from [DN String]):

CN=Steve Kille,O=Isode Limited,C=GB

OU=Sales+CN=J. Smith,O=Widget Inc.,C=US

Dally, Legg Expires 27 August 2002 [Page 22]
INTERNET-DRAFT draft-ietf-ldapbis-syntaxes-02 27 February 2002

CN=L. Eagle,O=Sue\, Grabbit and Runn,C=GB

CN=Before\0DAfter,O=Test,C=GB

1.1.3.6.1.4.1.1466.0=#04024869,O=Test,C=GB

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

3.10 Enhanced Guide Matching Rule Description syntax is:

( 1.3.6.1.4.1.1466.115.121.1.30 DESC 'Matching Rule Description' )

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

4.3.20 Matching Rule Use Description

A value in of the Enhanced Guide Matching Rule Use Description syntax is indicates the
attribute types to which a matching criteria and
scope of operation rule may be applied in an Enhanced Filter.
extensibleMatch search filter [PROT]. The native LDAP LDAP-specific encoding of
a value of this syntax is defined by the following ABNF:

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

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

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

or-term = and-term *( "|" and-term <MatchingRuleUseDescription>
rule in [MODELS].

Example:

Legg & Dally Expires 20 June 2003 [Page 17]

INTERNET-DRAFT LDAP: Syntaxes and Matching Rules December 20, 2002

( 2.5.13.16 APPLIES ( givenName $ surname )

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

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

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

The ?false alternative represents an empty "or" in LDAP definition for the
Criteria ASN.1 type.

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

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

( 1.3.6.1.4.1.1466.115.121.1.21 1.3.6.1.4.1.1466.115.121.1.31
DESC 'Enhanced Guide' 'Matching Rule Use Description' )

Example:

person#(sn)#oneLevel

3.11 Facsimile Telephone Number

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

4.3.21 Name and Optional UID

A value in of the Facsimile Telephone Number Name and Optional UID syntax is a subscriber
number on is the (public) telephone network distinguished name
[MODELS] of an entity optionally accompanied by a facsimile device. unique identifier
that serves to differentiate the entity from others with an identical
distinguished name.

The

Dally, Legg Expires 27 August 2002 [Page 23]
INTERNET-DRAFT draft-ietf-ldapbis-syntaxes-02 27 February 2002

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

fax-number

NameAndOptionalUID = printablestring distinguishedName [ "$" faxparameters SHARP BitString ]
; telephone number, possibly followed by facsimile
parameters

faxparameters = faxparm / ( faxparm "$" faxparameters )

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

The production for printablestring <BitString> rule is given defined in section 2.1. Section 4.3.2. The telephone number is based on E.123 [Tel #].

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

( 1.3.6.1.4.1.1466.115.121.1.22 DESC 'Facsimile Telephone Number')

3.12 Fax

A value defined in the Fax syntax is an image which is produced using the
Group 3 facsimile process [Fax] to duplicate an object, such as
a memo. [LDAPDN]. The following syntax description gives the OID assigned to this
syntax:

( 1.3.6.1.4.1.1466.115.121.1.23 DESC 'Fax' )

Values in this syntax are expressed as octet strings containing
Group 3 Fax images as <SHARP> rule is
defined in [Fax].

3.13 Generalized Time

A value [MODELS].

Note that although the '#' character may occur in the Generalized Time syntax string
representation of a distinguished name, no additional escaping of
this character is performed when a date and time. The year <distinguishedName> is given as encoded in
a four-digit number. <NameAndOptionalUID>.

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

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

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

( 1.3.6.1.4.1.1466.115.121.1.24 1.3.6.1.4.1.1466.115.121.1.34 DESC 'Generalized Time' 'Name And Optional UID' )

Example:
199412161032Z means 10:32 a.m. Dec. 16, 1994 in

This syntax corresponds to the Greenwich
Mean Time time zone.

Dally, Legg Expires 27 August 2002 [Page 24]
INTERNET-DRAFT draft-ietf-ldapbis-syntaxes-02 27 February 2002

3.14 Guide NameAndOptionalUID ASN.1 type from
[X.520].

4.3.22 Name Form Description

A value in of the Guide Name Form Description syntax is the matching criteria in definition of a Filter.

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

( 1.3.6.1.4.1.1466.115.121.1.25 DESC 'Guide' )

The Guide syntax is not intended to
name form, which regulates how entries may be used for defining new
attributes. It is important for backwards compatibility with LDAP
systems that implement an earlier version of LDAP [LDAP '95]. named. The native LDAP
LDAP-specific encoding of a value of this syntax is defined by the following ABNF:

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

object-class = space oid

The criteria production is defined in the Enhanced Guide syntax

Legg & Dally Expires 20 June 2003 [Page 18]

INTERNET-DRAFT LDAP: Syntaxes and Matching Rules December 20, 2002

<NameFormDescription> rule in
section 3.14. [MODELS].

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

The productions LDAP definition for oid and space are in section 2.1.

3.15 IA5 the Name Form Description syntax is:

( 1.3.6.1.4.1.1466.115.121.1.35 DESC 'Name Form Description' )

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

4.3.23 Numeric String

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

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

( 1.3.6.1.4.1.1466.115.121.1.26 DESC 'IA5 String' ) one or more
numerals and spaces. The native LDAP LDAP-specific encoding of a value in of this
syntax is the character unconverted string value itself.

3.16 Integer

A value in the INTEGER syntax is a whole number as specified in of characters, which conforms to the
INTEGER data type from ASN.1 [ASN1].

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

( 1.3.6.1.4.1.1466.115.121.1.27 DESC 'INTEGER' ) ABNF:

NumericString = 1*(DIGIT / SPACE)

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

Example:
15 079 672 281

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

Dally, Legg Expires 27 August 2002 [Page 25]
INTERNET-DRAFT draft-ietf-ldapbis-syntaxes-02 27 February 2002

3.17 JPEG Numeric String syntax is:

( 1.3.6.1.4.1.1466.115.121.1.36 DESC 'Numeric String' )

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

4.3.24 Object Class Description

A value in of the JPEG Object Class Description syntax is the definition of
an image produced according to
specific rules for light values. object class. The native LDAP LDAP-specific encoding of a value of this
syntax is strings containing JPEG images in defined by the JPEG File Interchange
Format (JFIF), as described <ObjectClassDescription> rule in [JPEG].

The following syntax [MODELS].

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

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

The LDAP definition for the Object Class Description syntax is:

Legg & Dally Expires 20 June 2003 [Page 19]

INTERNET-DRAFT LDAP: Syntaxes and Matching Rules December 20, 2002

( 1.3.6.1.4.1.1466.115.121.1.28 1.3.6.1.4.1.1466.115.121.1.37 DESC 'JPEG' 'Object Class Description' )

3.18 LDAP Syntax Description

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

4.3.25 Octet String

A value in of the LDAP Syntax Description Octet String syntax is a definition sequence of a
LDAP syntax description according to the ABNF given in section 2.2.3. zero, one or more
arbitrary octets. The native LDAP LDAP-specific encoding of a value of this
syntax is the character codes in UTF-8 [UTF-8] unconverted sequence of octets, which correspond conforms to the characters in the definition.

This syntax
following ABNF:

OctetString = *OCTET

The <OCTET> rule is the form defined in which schema [MODELS]. Values of this syntax descriptions are
published in the directory in a subentry.
not generally human-readable.

The following syntax
description gives LDAP definition for the OID assigned to this syntax: Octet String syntax is:

( 1.3.6.1.4.1.1466.115.121.1.54 1.3.6.1.4.1.1466.115.121.1.40 DESC 'LDAP Syntax Description' 'Octet String' )

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

This syntax corresponds to attributes.

3.19 Matching Rule Description the OCTET STRING ASN.1 type from [ASN.1].

4.3.26 OID

A value in of the Matching Rule Description OID syntax is an object identifier; a definition sequence of two
or more non-negative integers that uniquely identify some object or
item of specification. Many of
a matching rule according to the ABNF given object identifiers used in section 2.3.2. The
native LDAP
also have IANA registered names [RFC3383].

The LDAP-specific encoding is the character codes in UTF-8 [UTF-8] which
correspond to the characters in the definition of a Matching Rule.
This value of this syntax is defined by
the form in which schema matching rules are published
in the directory <oid> rule in a subentry. [MODELS].

Examples:
1.2.3.4
cn

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

( 1.3.6.1.4.1.1466.115.121.1.31 1.3.6.1.4.1.1466.115.121.1.38 DESC 'Matching Rule Description' 'OID' )

3.20

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

4.3.27 Other Mailbox

Legg & Dally Expires 20 June 2003 [Page 20]

INTERNET-DRAFT LDAP: Syntaxes and Matching Rule Use Description Rules December 20, 2002

A value in of the Matching Rule Use Description Other Mailbox syntax is identifies an electronic mailbox,
in a definition particular named mail system. The LDAP-specific encoding of a matching Rule and the attribute types with which the rule could
be used in an extensibleMatch search filter according to
value of this syntax is defined by the following ABNF:

MatchingRuleUseDescription

OtherMailbox = "(" whsp
numericoid
[ space "NAME" space qdescrs ]

Dally, Legg Expires 27 August 2002 [Page 26]
INTERNET-DRAFT draft-ietf-ldapbis-syntaxes-02 27 February 2002

[ space "DESC" space qdstring ]
[ space "OBSOLETE" ]
space "APPLIES" space oids ; AttributeType identifiers
extensions
whsp ")"

The numericoid identifies the Matching Rule for which the usage is
specified. mailbox-type DOLLAR mailbox
mailbox-type = PrintableString
mailbox = IA5String

The APPLIES oids identify <mailbox-type> rule represents the Attribute Types for type of mail system in which
the Matching
Rule can be used.

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

The native LDAP encoding <mailbox> is the character codes
actual mailbox in UTF-8 [UTF-8]
which correspond to the characters mail system described by <mailbox-type>. The
<PrintableString> and <IA5String> rules are defined in the definition. Section 4.2.
The following syntax description gives <DOLLAR> rule is defined in [MODELS].

The LDAP definition for the OID assigned to this
syntax: Other Mailbox syntax is:

( 1.3.6.1.4.1.1466.115.121.1.31 1.3.6.1.4.1.1466.115.121.1.39 DESC 'Matching Rule Use
Description' 'Other Mailbox' )

This

The ASN.1 type corresponding to the Other Mailbox syntax is the form in which schema matching rule usage
permissions are published in the directory in a subentry.

3.21 MHS OR defined
as follows, assuming EXPLICIT TAGS:

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

4.3.28 Postal Address

A value in of the MHS OR Postal Address syntax is the addressing information of a user series of strings which
form an X.400 messaging service. address in a physical mail system.

The native LDAP LDAP-specific encoding of a value of this syntax is defined in RFC 1327 [Map].

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

( 1.3.6.1.4.1.1466.115.121.1.33 DESC 'MHS OR Address' following ABNF:

PostalAddress = line *( DOLLAR line )

3.22 Name and Optional UID

A value
line = 1*line-char
line-char = %x00-23
/ (%x5C "24") ; escaped "$"
/ %x25-5B
/ (%x5C "5C") ; escaped "\"
/ %x5D-7F
/ UTFMB

Each <line> of the Name and Optional UID (Unique IDentifier) syntax is a
Distinguished Name postal address value is encoded as defined in section 3.13 plus a bit UTF-8 [UTF-8]
string except that differentiates "\" and "$" characters, if they occur in the value from otherwise identical names.

The native LDAP encoding of line,
are escaped by a value is "\" character followed by the following ABNF:

NameAndOptionalUID = DistinguishedName [ "#" bitstring ]

Dally, two hexadecimal digit
code for the character. The <HEX-DIGIT> rule is defined in Section

Legg & Dally Expires 27 August 2002 20 June 2003 [Page 27] 21]

INTERNET-DRAFT draft-ietf-ldapbis-syntaxes-02 27 February LDAP: Syntaxes and Matching Rules December 20, 2002

4.2. The bitstring production is <DOLLAR> and <UTFMB> rules are defined in section 3.3.

Although [MODELS].

Many servers limit the '#' character could occur in a string representation postal address to no more than six lines of
a distinguished name, no additional special quoting is done.
more than thirty characters each.

Example:
1.3.6.1.4.1.1466.0=#04024869,O=Test,C=GB#'0101'B
1234 Main St.$Anytown, CA 12345$USA
\241,000,000 Sweepstakes$PO Box 1000000$Anytown, CA 12345$USA

The following syntax description gives LDAP definition for the OID assigned to this
syntax: Postal Address syntax is:

( 1.3.6.1.4.1.1466.115.121.1.34 1.3.6.1.4.1.1466.115.121.1.41 DESC 'Name And Optional UID' 'Postal Address' )

3.23 Name Form Description

This syntax corresponds to the 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 in of the Name Form Description Printable String syntax is a definition string of a
Name Form according to the following ABNF:

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

The numericoid identifies latin
alphabetic, numeric, and (limited) punctuation characters as
specified by the Name Form being described. <PrintableCharacter> rule in Section 4.2.

The OC oid identifies LDAP-specific encoding of a value of this syntax is the Structural Object Class for instances
unconverted string of characters, which the Name Form specifies the naming attributes (i.e., the RDN).

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

The MAY oids identify Attribute Types that are optional
<PrintableString> rule in the RDN. Section 4.2.

Example:
This is a PrintableString.

The productions LDAP definition for whsp, numericoid, qdescrs, qdstring, oid, and
oids are given in section 2.1. Implementors, note that future
versions of this document could have expanded this ABNF the PrintableString syntax is:

( 1.3.6.1.4.1.1466.115.121.1.44 DESC 'Printable String' )

This syntax corresponds to include
additional terms. the PrintableString ASN.1 type from
[ASN.1].

4.3.30 Substring Assertion

A value indicates of the Substring Assertion syntax is a sequence of zero, one
or more attributes in an entry type (e.g.,
person, device) that are character substrings used as the Relative Distinguished Name an argument for substring
extensible matching of character string attribute values, i.e. as the entries.

This syntax is the form in which schema name forms are published in
the directory. The native LDAP encoding
matchValue of a value MatchingRuleAssertion [PROT]. Each substring is the character
codes in UTF-8 [UTF-8] which correspond to the a
string of one or more arbitrary characters in from the
definition.

Dally, Universal

Legg & Dally Expires 27 August 2002 20 June 2003 [Page 28] 22]

INTERNET-DRAFT draft-ietf-ldapbis-syntaxes-02 27 February LDAP: Syntaxes and Matching Rules December 20, 2002

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

( 1.3.6.1.4.1.1466.115.121.1.35 DESC 'Name Form Description' )

3.24 Numeric String

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

( 1.3.6.1.4.1.1466.115.121.1.36 DESC 'Numeric String' ) not permitted.

The representation LDAP-specific encoding of a string in value of this syntax is defined by
the string value
itself.

Example: 1997

3.25 Object Class Description

A following ABNF:

SubstringAssertion = [ initial ] any [ final ]

initial = substring
any = ASTERISK *(substring ASTERISK)
final = substring
ASTERISK = %x2A ; asterisk ("*")

substring = 1*substring-character
substring-character = %x00-29
/ (%x5C "2A") ; escaped "*"
/ %x2B-5B
/ (%x5C "5C") ; escaped "\"
/ %x5D-7F
/ UTFMB

Each <substring> of a Substring Assertion value in this syntax is encoded as a UTF-8
[UTF-8] string, except that "\" and "*" characters, if they occur in
the substring, are escaped by a "\" character string which expresses followed by the
definition of an object class according to two
hexadecimal digit code for the ABNF given in
section 2.5.2. This character.

The Substring Assertion syntax is used only as the form in which schema object
classes are published syntax of
assertion values in the directory extensible match. It is not used as an
attribute syntax, or in a subentry. the SubstringFilter [PROT].

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

( 1.3.6.1.4.1.1466.115.121.1.37 1.3.6.1.4.1.1466.115.121.1.58 DESC 'Object Class Description' )

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

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

3.26 Octet String

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

4.3.31 Telephone Number

A value in of the Octet String Telephone Number syntax is a value string of printable
characters that complies with the OCTET STRING
data type from ASN.1 [ASN1]. internationally agreed format for
representing international telephone numbers [E.123].

The following string states the OID
assigned to this syntax:

( 1.3.6.1.4.1.1466.115.121.1.40 DESC 'Octet String' )

Values in this syntax are written as LDAP-specific encoding of a series value of 8-bit values,
according to this syntax is the octet
unconverted string value notation specified in [ASN1].
In the case of character strings, characters, which conforms to the characters themselves could be
written.
<PrintableString> rule in Section 4.2.

Example:
secret

Dally, +1 512 315 0280

Legg & Dally Expires 27 August 2002 20 June 2003 [Page 29] 23]

INTERNET-DRAFT draft-ietf-ldapbis-syntaxes-02 27 February LDAP: Syntaxes and Matching Rules December 20, 2002

3.27 OID

A value in the Object Identifier syntax is a series of integers,
ordered as specified in the OBJECT IDENTIFIER data type from ASN.1
[ASN1].

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

( 1.3.6.1.4.1.1466.115.121.1.38 1.3.6.1.4.1.1466.115.121.1.50 DESC 'OID' 'Telephone Number' )

Values in this

The Telephone Number syntax are expressed according corresponds to the ABNF in
section 2.1 for "oid".

Examples: 1.2.3.4
cn

3.28 Other Mailbox 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 the Other Mailbox of this syntax gives a mail system name with specifies the name identifier and (optionally)
parameters of a mailbox in the system. teletex terminal.

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

teletex-id = mailbox-type "$" mailbox

mailbox-type ttx-term *(DOLLAR ttx-param)
ttx-term = printablestring

mailbox PrintableString ; terminal identifier
ttx-param = ttx-key COLON ttx-value ; parameter
ttx-key = "graphic" / "control" / "misc" / "page" / "private"
ttx-value = *ttx-value-char

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

The printablestring production is defined in section 2.1.

In the above, mailbox-type represents the type of mail system in
which the mailbox resides, for example "MCIMail"; <PrintableString> and mailbox is
the actual mailbox in the mail system <COLON> rules are defined by mailbox-type.

3.29 Postal Address

A value in the Postal Address syntax Section 4.2.
The <DOLLAR> rule is a series of strings which
form an address defined in a physical mail system. [MODELS].

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

( 1.3.6.1.4.1.1466.115.121.1.41 1.3.6.1.4.1.1466.115.121.1.51
DESC 'Postal Address' 'Teletex Terminal Identifier' )

Values in this

This syntax are written according corresponds to the following ABNF:

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

In the above, each dstring component of a postal address value is
written as a TeletexTerminalIdentifier ASN.1 type
from [X.520].

4.3.33 Telex Number

A value of type Directory String syntax. Backslashes and
dollar characters, if they occur in the component, are quoted as

Dally, Telex Number syntax specifies the telex number,
country code and answerback code of a telex terminal.

Legg & Dally Expires 27 August 2002 20 June 2003 [Page 30] 24]

INTERNET-DRAFT draft-ietf-ldapbis-syntaxes-02 27 February LDAP: Syntaxes and Matching Rules December 20, 2002

described in section 2.1. Many servers limit the postal address to
six lines

The LDAP-specific encoding of up to thirty characters. a value of this syntax is defined by
the following ABNF:

telex-number = actual-number DOLLAR country-code
DOLLAR answerback
actual-number = PrintableString
country-code = PrintableString
answerback = PrintableString

The production for dstring <PrintableString> rule is defined in section 2.1.

Example:

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

3.30 Presentation Address

A value in the Presentation Address syntax Section 4.2. The <DOLLAR>
rule 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 defined in [MODELS].

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

( 1.3.6.1.4.1.1466.115.121.1.43 1.3.6.1.4.1.1466.115.121.1.52 DESC 'Presentation Address' 'Telex Number' )

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 "_" network-address-list /
network-address

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

The first (NS) alternative is the Concrete Binary Representation.
It is TelexNumber ASN.1 type from [X.520].

4.3.34 UTC Time

A value of the compact encoding.

The afi alternative UTC Time syntax is a user-oriented representation of character string representing a network
address.

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

Dally, Legg Expires 27 August 2002 [Page 31]
INTERNET-DRAFT draft-ietf-ldapbis-syntaxes-02 27 February 2002

selector = """ otherstring """
/ "#" numericstring
/ "'" hexstring "'H"
/ "" one minute or one second. The otherstring alternative for the selector year
is IA5 characters. given as a two-digit number. The "" alternative for the selector expresses LDAP-specific encoding of a
value of this syntax follows the case where format defined in [ASN.1] for the
selector
UTCTime type and is present, but Empty.

idp = numericstring

dsp described by the following ABNF:

UTCTime = "d" numericstring
/ "x" dothexstring
/ "l" otherstring
/ "RFC-1006" "+" prefix "+" ip [ "+" port year month day hour minute [ "+" tset ]]
/ "X.25(80)" "+" prefix "+" dte second ]
[ "+" cudf-or-pid "+"
hexstring u-time-zone ]
u-time-zone = %x5A ; "Z"
/ u-differential
u-differential = ( MINUS / "ECMA-117-Binary" "+" hexstring "+" hexstring "+" hexstring
/ "ECMA-117-Decimal" "+" numericstring "+"
numericstring "+" numericstring PLUS ) hour minute

The d alternative is the Abstract Decimal form of the Domain
Specific Part (dsp) <year>, <month>, <day>, <hour>, <minute>, <second> and <MINUS>
rules are defined in a network address. Section 4.3.13. The x alternative <DOLLAR> rule is defined in
[MODELS].

The time value represents coordinated universal time if the Abstract Binary "Z" form
of the dsp in a
network address.

The l alternative <u-time-zone> is IA5 characters and is only meaningful locally.

idi = numericstring

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

prefix = DIGIT DIGIT

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

port = numericstring

tset = numericstring

dte = numericstring

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

other = k / "+" / DOT

domainchar = k / DOT

Dally, Legg Expires 27 August 2002 [Page 32]
INTERNET-DRAFT draft-ietf-ldapbis-syntaxes-02 27 February 2002

hexoctet = hex-digit hex-digit

decimal-octet = 1*3DIGIT

otherstring = other otherstring / other

domainstring = domainchar otherstring / domainchar

hexstring = hexoctet hexstring / hexoctet

dotstring = decimaloctet DOT dotstring /
decimaloctet DOT decimaloctet

dothexstring = dotstring / hexstring

3.31 Printable String

A used, otherwise the value in represents a local
time. In the Printable String syntax latter case, if <u-differential> is a series of alphabetic,
numeric, and (limited) punctuation characters as specified in provided then
coordinated universal time can be calculated by subtracting the
PrintableString data type
differential from ASN.1 [ASN1] and the local time. The <u-time-zone> SHOULD be
present in production p time values and the "Z" form of
section 2.1. Values <u-time-zone> SHOULD be
used in this syntax are expressed as the string
itself. preference to <u-differential>.

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

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

Example:

Legg & Dally Expires 20 June 2003 [Page 25]

INTERNET-DRAFT LDAP: Syntaxes and Matching Rules December 20, 2002

Note: This is a PrintableString.

3.32 Substring Assertion

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

The UTC Time syntax corresponds to the UTCTime ASN.1 type from
[ASN.1].

5. Matching Rules

Matching rules which can be are used in
substrings by directory implementations to compare
attribute values against assertion values when performing Search and extensible matching rules. When using a substrings
assertion, substrings components
Compare operations [PROT]. They are provided in also used when comparing a SubstringFilter
sequence. The following string states
purported distinguished name [MODELS] with the OID assigned to this
syntax:

( 1.3.6.1.4.1.1466.115.121.1.58 DESC 'Substring Assertion' ) name of an entry.
When using a modifying entries, matching rule assertion, substring components rules are
encoded according used to the following ABNF identify values to
be deleted 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 [UTF-8] string. If a backslash to prevent an attribute from containing two equal
values.

Matching rules that are required for directory operation, or
asterix character is present that are
in a production of <value>, it is
quoted as described common use, are specified in section 2.1.

Dally, Legg Expires 27 August 2002 [Page 33]
INTERNET-DRAFT draft-ietf-ldapbis-syntaxes-02 27 February 2002

3.33 Telephone Number this section.

5.1 General Considerations

A value matching rule is applied to attribute values through an
AttributeValueAssertion or MatchingRuleAssertion [PROT]. The
conditions under which an AttributeValueAssertion or
MatchingRuleAssertion evaluates to Undefined are specified in [PROT].
If an assertion is not Undefined then the telephone number syntax result of the assertion is
the series result of characters
that express a number (address) assigned to a telephone system
subscriber. The following string states applying the OID assigned selected matching rule. A matching rule
evaluates to this
syntax:

( 1.3.6.1.4.1.1466.115.121.1.50 DESC 'Telephone Number' )

Values TRUE, and in this syntax are written some cases Undefined, as if they were Printable String
types. Telephone numbers are defined specified in X.520 [Attr] to comply
with the internationally agreed format for expressing international
telephone numbers in Recommendation E.123 [Tel #].

Example: +1 512 315 0280

3.34 Teletex Terminal Identifier

A value in this syntax is a string
description of characters that express the
identifier value assigned matching rule, otherwise it evaluates to a teletex service subscriber. FALSE.

Each assertion contains an assertion value. The
following string states definition of each
matching rule specifies the OID assigned to this syntax:

( 1.3.6.1.4.1.1466.115.121.1.51 DESC 'Teletex Terminal
Identifier' )

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

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

ttx-term = printablestring

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

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

ttx-value = octetstring

In for the above, assertion value. The
syntax of the first printablestring assertion value is typically, but not necessarily, the encoding of
same as the first
portion syntax of the teletex terminal identifier attribute values to be encoded, and which the
subsequent 0 or more octetstrings are subsequent portions of matching rule
may be applied. Note that the
teletex terminal identifier.

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

3.35 Telex Number

A value AssertionValue in a SubstringFilter
[PROT] MUST conform to the Telex Number assertion syntax is of the number assigned to a telex
system subscriber with equality matching
rule for the country and answerback values indicated.

Dally, Legg Expires 27 August 2002 [Page 34]
INTERNET-DRAFT draft-ietf-ldapbis-syntaxes-02 27 February 2002

The following string states attribute type rather than the OID assigned to this syntax:

( 1.3.6.1.4.1.1466.115.121.1.52 DESC 'Telex Number' )

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

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

actual-number = printablestring

country = printablestring

answerback = printablestring

In
substrings matching rule for the above, actual-number attribute type. The entire
SubstringFilter is the syntactic representation converted into an assertion value of the
number portion
substrings matching rule prior to applying the rule.

The description of each matching rule indicates whether the TELEX number being written, country rule is
suitable for use as the
TELEX country code, and answerback equality matching rule (EQUALITY), ordering
matching rule (ORDERING) or substrings matching rule (SUBSTR) in an
attribute type definition [MODELS].

Each matching rule is the answerback code uniquely identified with an object identifier.

Legg & Dally Expires 20 June 2003 [Page 26]

INTERNET-DRAFT LDAP: Syntaxes and Matching Rules December 20, 2002

The definition of a TELEX
terminal.

The production for printablestring 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 2.1.

3.36 UTC Time

A value 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 UTC Time syntax is a date
extensibleMatch filter and time indicating accuracy SHOULD allow matching rules to minute or second. The year be used
with all attribute types known to the server, where the assertion
syntax of the matching rule is given the same 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 this value syntax are written as if they were printable strings,
formulated as specified for of the
attribute.

Servers MUST publish in the matchingRules attribute, the definitions
of matching rules referenced by values of the UTCTime data type attributeTypes and
matchingRuleUse attributes in ASN.1 [ASN1].
It is strongly suggested that GMT time the same subschema entry. Other
unreferenced matching rules MAY be used.

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

Dally, Legg Expires 27 August 2002 [Page 35]
INTERNET-DRAFT draft-ietf-ldapbis-syntaxes-02 27 February 2002

4. 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 Rules Rule Definitions

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

4.1

5.2.1 bitStringMatch

The following ABNF associates the bitStringMatch rule with compares an assertion value of the Bit String syntax:

( 2.5.13.16 NAME 'bitStringMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 ) ;
syntax to an attribute value of a syntax (e.g. the Bit String

This matching rule syntax)
whose corresponding ASN.1 type is used to test equality.

4.2 caseExactIA5Match

The following ABNF associates BIT STRING.

If the caseExactIA5Match rule with corresponding ASN.1 type of the IA5
String syntax:

( 1.3.6.1.4.1.1466.109.114.1 NAME 'caseExactIA5Match'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) ; IA5 attribute syntax does not have
a named bit list (which is the case for the Bit String

This matching syntax) then
the rule is used evaluates to test equality.

4.3 caseIgnoreIA5Match 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

Legg & Dally Expires 20 June 2003 [Page 27]

INTERNET-DRAFT LDAP: Syntaxes and Matching Rules December 20, 2002

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 caseIgnoreIA5Match bitStringMatch rule with the
IA5 String syntax: is:

( 1.3.6.1.4.1.1466.109.114.2 2.5.13.16 NAME 'caseIgnoreIA5Match' 'bitStringMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 1.3.6.1.4.1.1466.115.121.1.6 ) ; IA5 String

This matching

The bitStringMatch rule is used to test equality.

4.4 caseIgnoreListMatch an equality matching rule.

5.2.2 caseExactIA5Match

The ABNF below associates the caseIgnoreListMatch caseExactIA5Match rule with compares an assertion value of the
Postal Address syntax. The X.520 [Attr] IA5
String syntax for this matching
rule is to an attribute value of a SEQUENCE Of DirectoryString. Since the Postal Address syntax (e.g the IA5 String
syntax) whose corresponding ASN.1 type is such a sequence, it IA5String.

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. Letter case is used significant in defining the matching rule
comparison.

The LDAP definition for LDAP, although the matching caseExactIA5Match rule can be used with any SEQUENCE
OF DirectoryString syntax/assertion. is:

( 2.5.13.11 1.3.6.1.4.1.1466.109.114.1 NAME 'caseIgnoreListMatch' 'caseExactIA5Match'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 1.3.6.1.4.1.1466.115.121.1.26 ) ; Postal Address

This matching rule is used to test equality.

Dally, Legg Expires 27 August 2002 [Page 36]
INTERNET-DRAFT draft-ietf-ldapbis-syntaxes-02 27 February 2002

4.5 caseIgnoreMatch

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

( 2.5.13.2 NAME 'caseIgnoreMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) ; Directory String

This matching caseExactIA5Match rule is used to test equality.

4.6 caseIgnoreOrderingMatch an equality matching rule.

5.2.3 caseIgnoreIA5Match

The following ABNF associates the caseIgnoreOrderingMatch caseIgnoreIA5Match rule with compares an assertion value of the Directory String syntax:

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

This matching rule is used syntax to test inequality, i.e., greaterOrEqual
or lessOrEqual.

The sort ordering for an attribute value of a caseIgnoreOrderingMatch syntax (e.g the IA5 String
syntax) whose corresponding ASN.1 type is implementation-
dependent.

4.7 caseIgnoreSubstringsMatch IA5String.

The following ABNF associates the caseIgnoreSubstringsMatch rule 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 matching rule is used evaluates to test substrings equality.

4.8 distinguishedNameMatch

The following ABNF associates TRUE if and only if the attribute value and the
assertion value have the same number of characters and corresponding
characters are the distinguishedNameMatch rule with same, ignoring the DN syntax:

( 2.5.13.1 NAME 'distinguishedNameMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 ) ; DN

This matching rule is used to test equality.

4.9 generalizedTimeMatch case of letters.

The following ABNF associates LDAP definition for the generalizedTimeMatch caseIgnoreIA5Match rule with the
Generalized Time syntax: is:

( 2.5.13.27 1.3.6.1.4.1.1466.109.114.2 NAME 'generalizedTimeMatch' 'caseIgnoreIA5Match'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 1.3.6.1.4.1.1466.115.121.1.26 ) ; Generalized Time

Dally,

The caseIgnoreIA5Match rule is an equality matching rule.

Legg & Dally Expires 27 August 2002 20 June 2003 [Page 37] 28]

INTERNET-DRAFT draft-ietf-ldapbis-syntaxes-02 27 February LDAP: Syntaxes and Matching Rules December 20, 2002

This matching

5.2.4 caseIgnoreIA5SubstringsMatch

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

The rule evaluates to test equality.

4.10 generalizedTimeOrderingMatch 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.

( 2.5.13.28 1.3.6.1.4.1.1466.109.114.3 NAME 'generalizedTimeOrderingMatch' 'caseIgnoreIA5SubstringsMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 1.3.6.1.4.1.1466.115.121.1.58 ) ; Generalized Time

This

The caseIgnoreIA5SubstringsMatch rule is a substrings matching rule.

5.2.5 caseIgnoreListMatch

The caseIgnoreListMatch rule compares an assertion value that is used a
sequence of strings to test inequality, i.e., greaterOrEqual
or lessOrEqual.

4.11 integerFirstComponentMatch

The following ABNF associates an attribute value of a syntax (e.g. the integerFirstComponentMatch
Postal Address syntax) whose corresponding ASN.1 type is a sequence
of the DirectoryString ASN.1 type.

The rule
with evaluates to TRUE if and only if 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 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 of for this matching
rule, an INTEGER, rule is defined to
be:

SEQUENCE OF DirectoryString {ub-match}

i.e. different from the value syntax corresponding type for the Postal Address
syntax. The choice of attributes the Postal Address syntax for which this is the equality matching rule.

This assertion
syntax of the caseIgnoreListMatch in LDAP should not be seen as
limiting the matching rule is used to test equality only apply to attributes with the first component
in a compound
Postal Address syntax.

4.12 integerMatch

The following ABNF associates LDAP definition for the integerMatch caseIgnoreListMatch rule with the INTEGER
syntax: is:

( 2.5.13.14 2.5.13.11 NAME 'integerMatch' 'caseIgnoreListMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 1.3.6.1.4.1.1466.115.121.1.41 ) ; INTEGER

This matching

Legg & Dally Expires 20 June 2003 [Page 29]

INTERNET-DRAFT LDAP: Syntaxes and Matching Rules December 20, 2002

The caseIgnoreListMatch rule is used to test equality.

4.13 numericStringMatch an equality matching rule.

5.2.6 caseIgnoreMatch

The following ABNF associates the numericStringMatch caseIgnoreMatch rule with compares an assertion value of the
Numeric Directory
String syntax:

( 2.5.13.8 NAME 'numericStringMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 ) ; Numeric syntax to an attribute value of a syntax (e.g. the Directory
String, Printable String, Country String

This matching rule or Telephone Number syntax)
whose corresponding ASN.1 type is used DirectoryString or one of its
alternative string types, e.g. PrintableString.

The rule evaluates to test equality.

4.14 numericStringSubstringsMatch 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.10 2.5.13.2 NAME 'numericStringSubstringsMatch' 'caseIgnoreMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 1.3.6.1.4.1.1466.115.121.1.15 ) ; Substring Assertion

This matching

The caseIgnoreMatch rule is used an equality matching rule.

5.2.7 caseIgnoreOrderingMatch

The caseIgnoreOrderingMatch rule compares an assertion value of the
Directory String syntax to test substrings equality.

Dally, Legg Expires 27 August 2002 [Page 38]
INTERNET-DRAFT draft-ietf-ldapbis-syntaxes-02 27 February 2002

4.15 objectIdentifierFirstComponentMatch 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 following ABNF associates the
objectIdentifierFirstComponentMatch rule with evaluates to TRUE if, and only if, in the OID syntax:

( 2.5.13.31 NAME 'objectIdentifierFirstComponentMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 ) ; OID

If normal collation
order for the client supplies an extensible filter using an
objectIdentifierFirstComponentMatch whose matchValue is attribute syntax after lower-case letters in both the
"descr" form,
attribute and the OID is not recognized assertion values have been replaced by their upper-case
equivalents, the server, then attribute value appears earlier than the
filter is Undefined.

This matching rule assertion
value, i.e. the attribute value is used to test equality with "less than" the first component
in assertion value.

The collation order for values of the DirectoryString syntax is
implementation-defined. [Editor's note: this will be specified by a compound syntax.

4.16 objectIdentifierMatch
stringprep profile before final publication.]

The following ABNF associates LDAP definition for the objectIdentifierMatch caseIgnoreOrderingMatch rule with the
OID syntax: is:

( 2.5.13.0 2.5.13.3 NAME 'objectIdentifierMatch' 'caseIgnoreOrderingMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 1.3.6.1.4.1.1466.115.121.1.15 ) ; OID

This matching

The caseIgnoreOrderingMatch rule is used to test equality.

Implementors, note that the assertion syntax of this an ordering matching
rule, rule.

Legg & Dally Expires 20 June 2003 [Page 30]

INTERNET-DRAFT LDAP: Syntaxes and Matching Rules December 20, 2002

5.2.8 caseIgnoreSubstringsMatch

The caseIgnoreSubstringsMatch rule compares an OID, is different from the assertion value syntax of attributes for
which this is the equality matching rule.

If the client supplies a filter using
Substring Assertion syntax to an objectIdentifierMatch attribute value of a syntax (e.g.
the Directory String, Printable String, Country String or Telephone
Number syntax) whose
matchValue oid corresponding ASN.1 type is in the "descr" form, DirectoryString or
one of its alternative string types.

The rule evaluates to TRUE if and only if the oid is not recognized
by the server, then the filter is Undefined.

4.17 octetStringMatch

Servers which implement substrings of the extensibleMatch filter SHOULD allow
assertion value match disjoint portions of the
matching rule listed in this section to be used attribute value in the
extensibleMatch. In general these servers SHOULD allow matching
rules to be used with all attribute types known to
order of the server, when substrings in the assertion syntax value, and an <initial>
substring, if present, matches the beginning of the matching rule is attribute value,
and a <final> substring, if present, matches the same as end of the attribute
value. A substring matches a portion of the attribute value
syntax if
corresponding characters are the same, ignoring the case of letters.

The LDAP definition for the attribute. caseIgnoreSubstringsMatch rule is:

( 2.5.13.4 NAME 'caseIgnoreSubstringsMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )

The Octet String Match caseIgnoreSubstringsMatch rule is a substrings matching rule.

5.2.9 distinguishedNameMatch

The distinguishedNameMatch rule compares for equality an asserted octet
string with assertion value of the DN
syntax to an attribute value of a syntax (e.g. the DN syntax) whose
corresponding ASN.1 type OCTET STRING. is DistinguishedName.

The strings match rule evaluates to TRUE if they are and only if the attribute value and the
assertion value have the same length number of RDNs and corresponding
octets RDNs
(by position) are identical.

( 2.5.13.17 NAME 'octetStringMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )

Dally, Legg Expires 27 August 2002 [Page 39]
INTERNET-DRAFT draft-ietf-ldapbis-syntaxes-02 27 February 2002

4.18 presentationAddressMatch

The following ABNF associates the presentationAddressMatch rule with same. An RDN of 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 assertion value is used to test equality.

4.19 protocolInformationMatch

The following ABNF associates the protocolInformationMatch rule with
same as an RDN of the Protocol Information syntax:

( 2.5.13.24 NAME 'protocolInformationMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.42 ) ; Protocol Information

This matching rule attribute value if and only if they have the
same number of attribute value assertions (AVAs) and each AVA of the
first RDN is used to test equality.

4.20 telephoneNumberMatch the same as the AVA of the second RDN with the same
attribute type. The following ABNF associates order of the telephoneNumberMatch rule 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
Telephone Number syntax:

( 2.5.13.20 NAME 'telephoneNumberMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 ) ; Telephone Number

This matching rule is used same attribute type are the same if their
values are equal according to test equality.

4.21 telephoneNumberSubstringsMatch

The following ABNF associates the telephoneNumberSubstringsMatch equality matching rule
with of the Substring Assertion syntax:

( 2.5.13.21 NAME 'telephoneNumberSubstringsMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 ) ; Substring Assertion

This matching
attribute type. If one or more of the AVA comparisons evaluate to
Undefined and the remaining AVA comparisons return TRUE then the
distinguishedNameMatch rule is used evaluates to test substrings equality.

4.22 uniqueMemberMatch Undefined.

The following ABNF associates LDAP definition for the uniqueMemberMatch distinguishedNameMatch rule with the
Name and Optional UID syntax: is:

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

This matching rule is used to test equality.

Dally,

Legg & Dally Expires 27 August 2002 20 June 2003 [Page 40] 31]

INTERNET-DRAFT draft-ietf-ldapbis-syntaxes-02 27 February LDAP: Syntaxes and Matching Rules December 20, 2002

5. Attribute Types

5.1 altServer

The values distinguishedNameMatch rule is an equality matching rule.

5.2.10 generalizedTimeMatch

The generalizedTimeMatch rule compares an assertion value of this the
Generalized Time syntax to an attribute are URLs value of other servers which could be
contacted when this server becomes unavailable. 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 server does
not know minutes or seconds absent
then the number of any other servers which could be used this attribute will minutes or seconds (respectively) is assumed to be absent. Clients can cache this information in case their
preferred
zero.

The LDAP server later becomes unavailable. definition for the generalizedTimeMatch rule is:

( 1.3.6.1.4.1.1466.101.120.6 2.5.13.27 NAME 'altServer' 'generalizedTimeMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
USAGE dSAOperation 1.3.6.1.4.1.1466.115.121.1.24 )

The SYNTAX oid indicates generalizedTimeMatch rule is an equality matching rule.

5.2.11 generalizedTimeOrderingMatch

The generalizedTimeMatch rule compares the IA5 String syntax.

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

5.2 attributeTypes

The attributeTypes attribute holds descriptions of the attributes in value
represents a schema. This attribute universal coordinated time which is typically located in earlier than the subschema
entry.

( 2.5.21.5 NAME 'attributeTypes'
EQUALITY objectIdentifierFirstComponentMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.3
USAGE directoryOperation )
universal coordinated time represented by the assertion value.

The SYNTAX oid indicates LDAP definition for the Attribute Type Description syntax.

5.3 createTimestamp generalizedTimeOrderingMatch rule is:

( 2.5.18.1 2.5.13.28 NAME 'createTimestamp'
EQUALITY generalizedTimeMatch
ORDERING generalizedTimeOrderingMatch 'generalizedTimeOrderingMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
SINGLE-VALUE
NO-USER-MODIFICATION
USAGE directoryOperation )

The SYNTAX oid indicates generalizedTimeOrderingMatch rule is an ordering matching rule.

5.2.12 integerFirstComponentMatch

The integerFirstComponentMatch rule compares an assertion value of
the Generalized Time syntax.

5.4 creatorsName

( 2.5.18.3 NAME 'creatorsName'
EQUALITY distinguishedNameMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
SINGLE-VALUE
NO-USER-MODIFICATION
USAGE directoryOperation )

Dally, Integer syntax to an attribute value of a syntax (e.g the DIT
Structure Rule Description syntax) whose corresponding ASN.1 type is

Legg & Dally Expires 27 August 2002 20 June 2003 [Page 41] 32]

INTERNET-DRAFT draft-ietf-ldapbis-syntaxes-02 27 February LDAP: Syntaxes and Matching Rules December 20, 2002

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 SYNTAX oid indicates rule evaluates to TRUE if and only if the DN syntax.

5.5 ditContentRules 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.21.2 2.5.13.29 NAME 'dITContentRules'
EQUALITY objectIdentifierFirstComponentMatch 'integerFirstComponentMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.16
USAGE directoryOperation 1.3.6.1.4.1.1466.115.121.1.27 )

The SYNTAX oid indicates the DIT Content Rule Description syntax.

This 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 is located in values. An assertion value can be derived
from an attribute value by taking the subschema entry.

5.6 dITStructureRules

( 2.5.21.1 NAME 'dITStructureRules'
EQUALITY integerFirstComponentMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.17
USAGE directoryOperation ) first component of that
attribute value.

5.2.13 integerMatch

The SYNTAX oid indicates integerMatch rule compares an assertion value of the DIT Structure Rule Description syntax.

This Integer
syntax to an attribute is located in value of a syntax (e.g the subschema entry.

5.7 ldapSyntaxes

This attribute Integer syntax)
whose corresponding ASN.1 type is typically located in INTEGER.

The rule evaluates to TRUE if and only if the subschema entry.

This attribute identifies value and the syntaxes implemented, with each
assertion value
corresponding to one syntax.

( 1.3.6.1.4.1.1466.101.120.16 NAME 'ldapSyntaxes'
EQUALITY objectIdentifierFirstComponentMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.54
USAGE directoryOperation )

The SYNTAX oid indicates are the same integer value.

The LDAP Syntax Description syntax.

5.8 matchingRules

This attribute is typically located in definition for the subschema entry. integerMatch matching rule is:

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

The SYNTAX oid indicates integerMatch rule is an equality matching rule.

5.2.14 numericStringMatch

The numericStringMatch rule compares an assertion value of the Matching Rule Description syntax.

5.9 matchingRuleUse

This
Numeric String syntax to an attribute is typically located in value of a syntax (e.g the subschema entry.

Dally,
Numeric String syntax) whose corresponding ASN.1 type is
NumericString.

Legg & Dally Expires 27 August 2002 20 June 2003 [Page 42] 33]

INTERNET-DRAFT draft-ietf-ldapbis-syntaxes-02 27 February LDAP: Syntaxes and Matching Rules December 20, 2002

( 2.5.21.8 NAME 'matchingRuleUse'
EQUALITY objectIdentifierFirstComponentMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.31
USAGE directoryOperation )

The SYNTAX oid indicates rule evaluates to TRUE if and only if the Matching Rule Use Description syntax.

5.10 modifiersName

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

The SYNTAX oid indicates attribute value and the DN syntax.

5.11 modifyTimestamp

( 2.5.18.2 NAME 'modifyTimestamp'
EQUALITY generalizedTimeMatch
ORDERING generalizedTimeOrderingMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
SINGLE-VALUE
NO-USER-MODIFICATION
USAGE directoryOperation )
assertion value are the same string of numerals, ignoring any space
characters.

The SYNTAX oid indicates LDAP definition for the Generalized Time syntax.

5.12 nameForms numericStringMatch matching rule is:

( 2.5.21.7 2.5.13.8 NAME 'nameForms'
EQUALITY objectIdentifierFirstComponentMatch 'numericStringMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.35
USAGE directoryOperation 1.3.6.1.4.1.1466.115.121.1.36 )

The SYNTAX oid indicates the Name Form Description syntax.

This attribute numericStringMatch rule is located in the subschema entry.

5.13 namingContexts an equality matching rule.

5.2.15 numericStringSubstringsMatch

The values numericStringSubstringsMatch rule compares an assertion value of this attribute correspond
the Substring Assertion syntax to naming contexts which
this server masters or shadows. If an attribute value of a syntax (e.g
the server does not master any
information (e.g. it Numeric String syntax) whose corresponding ASN.1 type is an LDAP gateway
NumericString.

The rule evaluates to a public X.500 directory)
this TRUE if and only if the substrings of the
assertion value match disjoint portions of the attribute will be absent. If value in the server believes it contains
order of the entire directory, substrings in the assertion value, and an <initial>
substring, if present, matches the beginning of the attribute will have a single value,
and
that value will be a <final> substring, if present, matches the empty string (indicating end of the null DN attribute
value. A substring matches a portion of the
root). This attribute will allow 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 client substrings matching rule.

5.2.16 objectIdentifierFirstComponentMatch

The objectIdentifierFirstComponentMatch rule compares an assertion
value of the OID syntax to choose suitable base
objects 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 searching when it has contacted a server.

Dally, which this is the equality
matching rule.

The rule evaluates to TRUE if and only if the assertion value matches

Legg & Dally Expires 27 August 2002 20 June 2003 [Page 43] 34]

INTERNET-DRAFT draft-ietf-ldapbis-syntaxes-02 27 February LDAP: Syntaxes and Matching Rules December 20, 2002

( 1.3.6.1.4.1.1466.101.120.5 NAME 'namingContexts'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
USAGE dSAOperation )

The SYNTAX oid indicates

the DN syntax.

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

5.14 objectClasses

This attribute is typically located in value using the subschema entry. rules of
objectIdentifierMatch.

The LDAP definition for the objectIdentifierFirstComponentMatch
matching rule is:

( 2.5.21.6 2.5.13.31 NAME 'objectClasses'
EQUALITY objectIdentifierFirstComponentMatch 'objectIdentifierFirstComponentMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.37
USAGE directoryOperation 1.3.6.1.4.1.1466.115.121.1.38 )

The SYNTAX oid indicates 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 Object Class Description syntax.

5.15 subschemaSubentry

The attribute values. An assertion
value can be derived from an attribute value by taking the first
component of this that attribute is value.

5.2.17 objectIdentifierMatch

The objectIdentifierMatch rule compares an assertion value of the name OID
syntax to an attribute value of a subschema entry (or
subentry) where syntax (e.g the server makes available attributes specifying OID syntax) whose
corresponding ASN.1 type is OBJECT IDENTIFIER.

The rule evaluates to TRUE if and only if the
schema controlling assertion value and the subject entry.

( 2.5.18.10 NAME 'subschemaSubentry'
EQUALITY distinguishedNameMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
SINGLE-VALUE
NO-USER-MODIFICATION
USAGE directoryOperation )

The SYNTAX oid indicates
attribute value represent the DN syntax.

5.16 supportedControl

The values same object identifier, that is, the
same sequence of this attribute are integers, whether represented explicitly in the OBJECT IDENTIFIERs identifying
controls which
<numericoid> form of <oid> or implicitly in the server supports. <descr> form (see
[MODELS]).

If an LDAP client supplies an assertion value in the server does <descr> form,
and the chosen descriptor is not support
any controls, this attribute will be absent. recognized by the server, then the
objectIdentifierMatch rule evaluates to Undefined.

The LDAP definition for the objectIdentifierMatch matching rule is:

( 1.3.6.1.4.1.1466.101.120.13 2.5.13.0 NAME 'supportedControl' 'objectIdentifierMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
USAGE dSAOperation )

The SYNTAX oid indicates objectIdentifierMatch rule is an equality matching rule.

5.2.18 octetStringMatch

The octetStringMatch rule compares an assertion value of the OID syntax.

This Octet
String syntax to an attribute value of a syntax (e.g the Octet String
or JPEG syntax) whose corresponding ASN.1 type is only present in the root DSE (see [Prot]
and [Models]).

Dally, OCTET STRING
ASN.1 type.

Legg & Dally Expires 27 August 2002 20 June 2003 [Page 44] 35]

INTERNET-DRAFT draft-ietf-ldapbis-syntaxes-02 27 February LDAP: Syntaxes and Matching Rules December 20, 2002

5.17 supportedExtension

The values of this attribute are OBJECT IDENTIFIERs identifying the
supported extended operations which the server supports.

If rule evaluates to TRUE if and only if the server does not support any extensions this attribute will be
absent.

( 1.3.6.1.4.1.1466.101.120.7 NAME 'supportedExtension'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
USAGE dSAOperation )

The SYNTAX oid indicates value and the OID syntax.

This attribute is only present in
assertion value are the root DSE (see [Prot] same length and [Models]).

5.18 supportedLDAPVersion

The values of this attribute corresponding octets (by
position) are the versions of the same.

The LDAP protocol
which definition for the server implements. octetStringMatch matching rule is:

( 1.3.6.1.4.1.1466.101.120.15 2.5.13.17 NAME 'supportedLDAPVersion' 'octetStringMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
USAGE dSAOperation 1.3.6.1.4.1.1466.115.121.1.40 )

The SYNTAX oid indicates the INTEGER syntax.

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

5.19 supportedSASLMechanisms an equality matching rule.

5.2.19 telephoneNumberMatch

The values of this attribute are the names telephoneNumberMatch rule compares an assertion value of supported SASL
mechanisms which the server supports. If the server does not support
any mechanisms this
Telephone Number syntax to an attribute will be absent.

( 1.3.6.1.4.1.1466.101.120.14 NAME 'supportedSASLMechanisms'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
USAGE dSAOperation )

The SYNTAX oid indicates value of a syntax (e.g the Directory String syntax.

This attribute
Telephone Number syntax) whose corresponding ASN.1 type is only present in the root DSE (see [Prot]
and [Models]).

Dally, Legg Expires 27 August 2002 [Page 45]
INTERNET-DRAFT draft-ietf-ldapbis-syntaxes-02 27 February 2002

6. Object Classes

6.1 Extensible Object Class a
PrintableString representing a telephone number.

The extensibleObject object class, if present in an entry, permits
that entry rule evaluates to hold any attribute. The "MAY" TRUE if and only if the attribute list value and the
assertion value have the same number of this class is implicitly characters and corresponding
characters are the set same, ignoring the case of all attributes. letters, and ignoring
space and `-' characters.

The LDAP definition for the telephoneNumberMatch matching rule is:

( 1.3.6.1.4.1.1466.101.120.111 2.5.13.20 NAME 'extensibleObject'
SUP top
AUXILIARY 'telephoneNumberMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 )
; MAY all attributes

The telephoneNumberMatch rule is implied an equality matching rule.

5.2.20 telephoneNumberSubstringsMatch

The mandatory attributes telephoneNumberSubstringsMatch rule compares an assertion value
of the other object classes of this entry
are still required to be present.

Note that not all servers will implement this object class, and those
which do not will reject requests Substring Assertion syntax to add entries which contain this
object class, or modify an entry 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 add this object class.

Note that, TRUE if and only if the server implements substrings of the
assertion value match disjoint portions of the extensibleObject class but an attribute is not recognized, this is value in the same case as for any other
object class.

6.2 subschema

This object class contains a description
order of the schema that is
applied substrings in the server assertion value, and is used in an <initial>
substring, if present, matches the beginning of the subschema entry.

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

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

Dally, Legg Expires 27 August 2002 [Page 46]
INTERNET-DRAFT draft-ietf-ldapbis-syntaxes-02 27 February 2002

7. Security Considerations

7.1 Disclosure

Attributes value,
and a <final> substring, if present, matches the end of directory entries the attribute
value. A substring matches a portion of the attribute value if
corresponding characters are used to provide descriptive
information about the real-world objects they represent, which can
be people, organizations or devices. Most countries have privacy
laws regarding same, ignoring the publication case of information about people.

7.2 Security Information letters,
and ignoring space and `-' characters.

Legg & Dally Expires 20 June 2003 [Page 36]

INTERNET-DRAFT LDAP: Syntaxes

Several X.500 attributes, such as, the userCertificate attribute,
are used to include key-based security information in directory
entries. and Matching Rules December 20, 2002

The attribute syntaxes for these attributes are:

Certificate
CertificateList
CertificatePair
SupportedAlgorithm

These syntaxes are specified for LDAP by definition for the PKIX Working Group, and
so, are not included in this document. telephoneNumberSubstringsMatch matching
rule is:

( 2.5.13.21 NAME 'telephoneNumberSubstringsMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )

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

7.3 Use of Attribute Values in Security Applications telephoneNumberSubstringsMatch rule is a substrings matching
rule.

5.2.21 uniqueMemberMatch

The transformations of uniqueMemberMatch rule compares an AttributeValue assertion value from its X.501 form of the Name
And Optional UID syntax to an LDAP string representation are not always reversible back to
the same BER or DER form.

For example, a distinguished name consisting attribute value of one RDN with one AVA,
in which a syntax (e.g the
Name And Optional UID syntax) whose corresponding ASN.1 type is commonName
NameAndOptionalUID.

The rule evaluates to TRUE if and only if the value is <distinguishedName>
components of the
TeletexString choice with assertion value and attribute value match according
to the letters 'Sam' would be represented in
LDAP as distinguishedNameMatch rule and the string cn=Sam. Another distinguished name in which <BitString> component is
absent from the attribute value is still 'Sam' but or matches the <BitString> component
of the PrintableString choice would have assertion value according to the
same representation cn=Sam.

Applications which require 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 reconstruction of LDAP-specific encoding will not
necessarily reproduce exactly the DER form original octets of a
value SHOULD NOT use the string LDAP native
LDAP-specific encoding. Therefore an LDAP-specific encoding when converting should
not be used where a value to LDAP format. Instead canonical encoding is required.

Furthermore, the ;binary transfer option [Prot]
SHOULD be used.

7.4 Securing LDAP-specific encodings do not necessarily enable an
alternative encoding of values of the Directory

In order String and DN
syntaxes to protect the directory be reconstructed, e.g. a transformation from DER to
LDAP-specific encoding and its contents, strong
authentication MUST have been used back to identify DER may not reproduce the Client when an
update operation original
DER encoding. Therefore LDAP-specific encodings should not be used
where reversibility to DER is requested.

Dally, needed, e.g. for the verification of
digital signatures. Instead, DER or a DER-reversible encoding should

Legg & Dally Expires 27 August 2002 20 June 2003 [Page 47] 37]

INTERNET-DRAFT draft-ietf-ldapbis-syntaxes-02 27 February LDAP: Syntaxes and Matching Rules December 20, 2002

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 update 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 their
significant contribution to 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

Legg & Dally Expires 20 June 2003 [Page 38]

INTERNET-DRAFT LDAP: Syntaxes and Matching Rules December 20, 2002

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 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 this update.

9. Authors' Addresses

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

Phone: +1 703 883 6058
Fax: +1 703 883 7142
Email: kdally@mitre.org 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

10 References

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

[ASN1] Information Technology - Abstract Syntax Notation One
(ASN.1): Specification 1997.

[UTF-8] Yergeau, F., "UTF-8, a transformation format of Basic Notation, ITU-T Recommendation
X.680, 1994

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

[Codes] ISO 3166, "Codes
10646", RFC 2279, January 1998.

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

[LDAPDN] Zeilenga, K., "LDAP: String Representation of countries".

Dally,
Distinguished Names", draft-ietf-ldapbis-dn-xx.txt, a work

Legg & Dally Expires 27 August 2002 20 June 2003 [Page 48] 39]

INTERNET-DRAFT draft-ietf-ldapbis-syntaxes-02 27 February LDAP: Syntaxes and Matching Rules December 20, 2002

[DN String] draft-ietf-ldapbis-dn-xx, replacement

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 Wahl, M., Kille, S., national and T. Howes, "Lightweight Directory Access Protocol (v3):
UTF-8 String Representation of Distinguished Names", RFC 2253,
December 1997.

[Fax] international telephone numbers,
ITU-T Recommendation E.123, 1988.

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

[IA5]

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

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

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

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

[ASN.1] ITU-T Recommendation X.680 (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".

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

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

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

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

[Prot] draft-ietf-ldapbis-protocol-xx, replacement for

10. Informative References

[RFC2252] Wahl, M., Coulbeck, A., Howes, T., T. and S. Kille,

Legg & Dally Expires 20 June 2003 [Page 40]

INTERNET-DRAFT LDAP: Syntaxes and Matching Rules December 20, 2002

"Lightweight Directory Access Protocol
(v3)", (v3): Attribute
Syntax Definitions", RFC 2251, 2252, December 1997.

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

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

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

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

[RFC3377] Hodges, J. and
ISO 10646", RFC 2044, October 1996.

10.2 Informative References

[LDAP '95] Yeong, W., Howes, T., Kille, S., R. Morgan, "Lightweight Directory Access Protocol",
Protocol (v3): Technical Specification", RFC 1777, March 1995

[NSAP] 3377,
September 2002.

[X.500] ITU-T Recommendation X.500 (1993) | ISO/IEC 9594-1:1994,
Information technology -- Technology - Open Systems Interconnection --
Network Service Definition, -
The Directory: Overview of concepts, models and services

[BER] ITU-T Recommendation X.690 (1997) | ISO/IEC 8348:1996

Dally, Legg Expires 27 August 2002 [Page 49]
INTERNET-DRAFT draft-ietf-ldapbis-syntaxes-02 27 February 2002

[Syn String] Howes, T., Kille, S., Yeong, W., Robbins, C., "The
String Representation 8825-1:1998
Information Technology - ASN.1 encoding rules:
Specification of Standard Attribute Syntaxes", RFC 1778,
March 1995. Basic Encoding Rules (BER), Canonical
Encoding Rules (CER) and Distinguished Encoding Rules
(DER)

11. Full 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

Legg & Dally Expires 20 June 2003 [Page 41]

INTERNET-DRAFT LDAP: Syntaxes and Matching Rules December 20, 2002

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.

Dally, Legg Expires 27 August 2002 [Page 50]
INTERNET-DRAFT draft-ietf-ldapbis-syntaxes-02 27 February 2002

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 in
this specification and defined in the user schema specification [User]. this 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

Dally, Legg Expires 27 August 2002 [Page 51]
INTERNET-DRAFT draft-ietf-ldapbis-syntaxes-02 27 February 2002

Annex B Topics Yet To Be Addressed In This Document

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

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

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

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

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

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

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

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

Dally,
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

Legg & Dally Expires 27 August 2002 20 June 2003 [Page 52] 42]

INTERNET-DRAFT draft-ietf-ldapbis-syntaxes-02 27 February LDAP: Syntaxes and Matching Rules December 20, 2002

Annex C Change Log

JPEG 1.3.6.1.4.1.1466.115.121.1.28
LDAP Syntax Description 1.3.6.1.4.1.1466.115.121.1.54
Matching Rule Description 1.3.6.1.4.1.1466.115.121.1.30
Matching Rule Use Description 1.3.6.1.4.1.1466.115.121.1.31
Name And Optional UID 1.3.6.1.4.1.1466.115.121.1.34
Name Form Description 1.3.6.1.4.1.1466.115.121.1.35
Numeric String 1.3.6.1.4.1.1466.115.121.1.36
Object Class Description 1.3.6.1.4.1.1466.115.121.1.37
Octet String 1.3.6.1.4.1.1466.115.121.1.40
OID 1.3.6.1.4.1.1466.115.121.1.38
Other Mailbox 1.3.6.1.4.1.1466.115.121.1.39
Postal Address 1.3.6.1.4.1.1466.115.121.1.41
Printable String 1.3.6.1.4.1.1466.115.121.1.44
Substring Assertion 1.3.6.1.4.1.1466.115.121.1.58
Telephone Number 1.3.6.1.4.1.1466.115.121.1.50
Teletex Terminal Identifier 1.3.6.1.4.1.1466.115.121.1.51
Telex Number 1.3.6.1.4.1.1466.115.121.1.52
UTC Time 1.3.6.1.4.1.1466.115.121.1.53

Appendix B. Changes from RFC 2252 & RFC 2256

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.

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 Sections 4, 5 and 7 has been moved to the last sentence in order [MODELS]
and revised. Changes to
indicate that syntaxes are not the only schema elements
defined in this document.

3. Reorganized the parts of these 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 moved to
[MODELS] are specified detailed in
alphbetical order [MODELS].

3. BNF descriptions of syntax formats have been replaced by ABNF
[ABNF] specifications.

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

5. Clarified schema description The ambiguous statement in RFC 2252, Section 4.3 regarding the Overview.

6. Changed the "Common Encoding Aspects" section title
use of a backslash quoting mechanism to
"Notation" and made corresponding changes throughout the
document. escape separator symbols
has been removed. The purpose being to relegate all encoding issues
to escaping mechanism is now explicitly
represented in the Protocol specification [Prot].

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

8. Expanded the discussion where this provision
applies.

5. The description of each of the LDAP syntaxes in section 3.

9. Added examples to some has been expanded so
that they are less dependent on knowledge of the syntax descriptions.

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

RESCINDED IN -01!!

11. Added a note deprecating the UTCTime attribute syntax
description in 3.41

12. In the ABNF X.500 for
interpretation.

6. The relationship of the MatchingRuleDescription in paragraph 2.3.2,
replaced "numericoid" with "oid".

Dally, LDAP syntaxes to corresponding ASN.1 type

Legg & Dally Expires 27 August 2002 20 June 2003 [Page 53] 43]

INTERNET-DRAFT draft-ietf-ldapbis-syntaxes-02 27 February LDAP: Syntaxes and Matching Rules December 20, 2002

13. In paragraph 2.4.1, replaced the conformance statement about
attributes

definitions has been made explicit.

7. The set of characters allowed in 2256 with a reference.

14. Added caseIgnoreIA5Match as the EQUALITY matching rule for <PrintableString> (formerly
<printablestring>) has been corrected to align with the altServer attribute
PrintableString ASN.1 type ABNF in paragraph 5.1. Note that
this could be caseExactIA5Match instead. SHOULD IT BE??

RESCINDED IN -01

15. In paragraphs 5.10 [ASN.1]. Specifically, the double
quote character has been removed and 5.11, changed "the MODIFY operation"
to "LDAP update operations"

16. Added distinguishedNameMatch as the EQUALITY matching rule
for single quote character
and equals sign have been added.

8. Values of the namingContexts attribute 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 ABNF in paragraph 5.13.

RESCINDED IN -01

17. Reworded paragraph 5.15.

18. Added distinguishedNameMatch as the EQUALITY matching rule for the namingContexts attribute Other Mailbox syntax has
been incorporated from RFC 1274.

11. A corresponding ASN.1 type ABNF in paragraph 5.13.

RESCINDED IN -01

19. Added integerMatch as for the EQUALITY 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 integerOrderingMatch
as the Ordering matching rules for it was confused with the supportedLDAPVersion
attribute type ABNF in paragraph 5.18.

RESCINDED IN -01

20. Added caseIgnoreMatch as ;binary
transfer encoding.

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

14. The Delivery Method, Enhanced Guide, Guide, Octet String, Teletex
Terminal Identifier and Telex Number syntaxes from RFC 2256 have
been incorporated.

15. The <criteria> rule for the
supportedSASLMechanisms attribute type ABNF in paragraph 5.19.
Note that this could be caseExactMatch instead. SHOULD
IT BE??

RESCINDED IN -01

21. Made corrections Enhanced Guide and Guide syntaxes has
been extended to accommodate empty "and" and "or" expressions.

16. An encoding for the ABNF <ttx-value> rule in paragraph 3.12.

22. Added the seven Teletex Terminal
Identifier syntax definitions has been defined.

17. The PKI-related syntaxes (Certificate, Certificate List and
Certificate Pair from RFC 2256 2252, and ordered
the definitions alphabetically.

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

24. Replaced the X.208 reference with one Supported Algorithm syntax
from RFC 2256) have been removed. They are to X.680(1994), be reintroduced in
PKIX documents.

18. The MHS OR Address syntax has been removed since
X.680 its
specification (in RFC 2156) is the ASN.1 referred to in the X.500(1993)-series.

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

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

Dally, not at draft standard maturity.

19. The DL Submit Permission syntax has been removed as it depends on

Legg & Dally Expires 27 August 2002 20 June 2003 [Page 54] 44]

INTERNET-DRAFT draft-ietf-ldapbis-syntaxes-02 27 February LDAP: Syntaxes and Matching Rules December 20, 2002

26. Moved

the MHS OR Address syntax.

20. The Presentation Address syntax has been removed since its
specification of the octetStringMatch matching rule
from (in RFC 2256 to section 4 of this document.

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

28. In Section 2.1:
* Corrected the characters defined in the p rule to match
the PrintableString syntax.
* Deleted the letterstring rule.
* Modified the utf8 and dstring rules according to a
suggestion from K. Zeilenga.
* Deleted ";" from the k rule, which affects the anhstring,
keystring, 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 native LDAP 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.

-------

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

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 non-normative
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.

Dally, Legg Expires 27 August 2002 [Page 55]
INTERNET-DRAFT draft-ietf-ldapbis-syntaxes-02 27 February 2002

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

Dally, version of ASN.1 referred to by X.500.

Legg & Dally Expires 27 August 2002 20 June 2003 [Page 56] 45]

----