draft-ietf-ldapbis-syntaxes-02.txt   draft-ietf-ldapbis-syntaxes-03.txt 
INTERNET-DRAFT K. Dally, Editor INTERNET-DRAFT K. Dally, Editor
Intended Category: Standard Track The MITRE Corp. Intended Category: Standard Track The MITRE Corp.
Expires: 27 August 2002 S. Legg Expires: 4 May 2003 S. Legg
Obsoletes: RFC 2252 ADACEL Obsoletes: RFC 2252, RFC 2256 ADACEL
27 February 2002 4 November 2002
Lightweight Directory Access Protocol (v3): LDAP: Syntaxes
Attribute Syntax Definitions <draft-ietf-ldapbis-syntaxes-03>
<draft-ietf-ldapbis-syntaxes-02>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026. all provisions of Section 10 of RFC 2026.
This document is intended to be, after appropriate review and This document is intended to be, after appropriate review and
revision, submitted to the RFC Editor as a Standard Track document. revision, submitted to the RFC Editor as a Standard Track document.
Distribution of this memo is unlimited. Technical discussion of Distribution of this memo is unlimited. Technical discussion of
this document will take place on the IETF LDAP Revision Working this document will take place on the IETF LDAP Revision Working
Group (LDAPbis) mailing list <ietf-ldapbis@openldap.org>. Please Group (LDAPbis) mailing list <ietf-ldapbis@openldap.org>. Please
send editorial comments directly to the author <kdally@mitre.org>. send editorial comments directly to the editor <kdally@mitre.org>.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Internet-Drafts are draft documents valid for a maximum of Drafts. Internet-Drafts are draft documents valid for a maximum of
six months and may be updated, replaced, or obsoleted by other six months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts as documents at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress." reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
skipping to change at page 2, line 7 skipping to change at page 2, line 7
Internet-Draft Shadow Directories can be accessed at Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Copyright 2002, The Internet Society. All Rights Reserved. Copyright 2002, The Internet Society. All Rights Reserved.
Please see the Copyright section near the end of this document for Please see the Copyright section near the end of this document for
more information. more information.
Abstract Abstract
The Lightweight Directory Access Protocol (LDAP) [Prot] provides for The Lightweight Directory Access Protocol (LDAP) [Protocol] provides
exchanging AttributeValue fields in protocol. This document defines for exchanging AttributeValue fields in protocol. This document
a set of syntaxes for LDAP, and the rules by which attribute values defines a set of syntaxes for LDAP, rules by which attribute values
of these syntaxes are represented in the LDAP protocol. The syntaxes of these syntaxes are represented in the LDAP protocol, and the
defined in this document are used by this and other documents to matching rules which specify how values are compared. Also, this
define attribute types. In addition, this document defines the set document indicates the syntax support requirements on LDAP servers.
of attribute syntaxes, which LDAP servers support, and other schema The syntaxes and matching rules defined in this document are used in
elements (required and optional) that are common to all schema definition documents to specify attribute types.
LDAP servers.
[Editor's note: This document is a modified version of the text of [Editor's note: This document is a modified version of parts of
RFC 2252, in order to bring it up to date. This action is part of RFC 2252 and RFC 2256, in order to bring then up to date. This
the maintenance activity that is needed in order to progress action is part of the maintenance activity that is needed in order
LDAP (v3) to Draft Standard. The changes are described in Annex C to progress LDAP (v3) to Draft Standard. The changes are described
of this document. Open items are listed in Annex B. in Annex C of this document. Open items are listed in Annex B.
End of Editor's note] End of Editor's note]
Table of Contents Table of Contents
Status of this Memo....................................................1 Status of this Memo....................................................1
Abstract...............................................................2 Abstract...............................................................2
1. Overview...........................................................6 1. Overview...........................................................5
2. 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 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 Attribute Type Description.......................................18
3.2 Bit String.......................................................18
3.3 Boolean..........................................................19
3.4 Country String...................................................19
3.5 Delivery Method..................................................19
3.6 Directory String.................................................20
3.7 DIT Content Rule Description.....................................20
3.8 DIT Structure Rule Description...................................21
3.9 DN...............................................................22
3.10 Enhanced Guide...................................................23
3.11 Facsimile Telephone Number.......................................23
3.12 Fax..............................................................24
3.13 Generalized Time.................................................24
3.14 Guide............................................................25
3.15 IA5 String.......................................................25
3.16 Integer..........................................................25
3.17 JPEG.............................................................26
3.18 LDAP Syntax Description..........................................26
3.19 Matching Rule Description........................................26
3.20 Matching Rule Use Description....................................26
3.21 MHS OR Address...................................................27
3.22 Name and Optional UID............................................27
3.23 Name Form Description............................................28
3.24 Numeric String...................................................29
3.25 Object Class Description.........................................29
3.26 Octet String.....................................................29
3.27 OID..............................................................30
3.28 Other Mailbox....................................................30
3.29 Postal Address...................................................30
3.30 Presentation Address.............................................31
3.31 Printable String.................................................33
3.32 Substring Assertion .......................................33
3.33 Telephone Number.................................................34
3.34 Teletex Terminal Identifier......................................34
3.35 Telex Number.....................................................34
3.36 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
5. Attribute Types...................................................41
5.1 altServer........................................................41
5.2 attributeTypes...................................................41
5.3 createTimestamp..................................................41
5.4 creatorsName.....................................................41
5.5 dITContentRules..................................................42
5.6 dITStructureRules................................................42
5.7 ldapSyntaxes.....................................................42
5.8 matchingRules....................................................42
5.9 matchingRuleUse..................................................42
5.10 modifiersName....................................................43
5.11 modifyTimestamp..................................................43
5.12 nameForms........................................................43
5.13 namingContexts...................................................43
5.14 objectClasses....................................................44 2. General Issues.....................................................5
5.15 subschemaSubentry................................................44 2.1 Notation..........................................................5
5.16 supportedControl.................................................44 2.2 Syntaxes..........................................................5
5.17 supportedExtension...............................................45 2.2.1 LDAP-Specific Encodings.........................................6
5.18 supportedLDAPVersion.............................................45 2.2.2 Syntaxes Implementation Status..................................6
5.19 supportedSASLMechanisms..........................................45 2.2.3 Syntax Object Identifiers.......................................6
2.2.4 Syntax Description..............................................6
2.3 Matching Rules....................................................7
2.3.1 Matching Rules Implementation Status............................7
2.3.2 Matching Rule Description.......................................7
6. Object Classes....................................................46 3. Syntaxes...........................................................8
6.1 Extensible Object Class..........................................46 3.1 Attribute Type Description........................................8
6.2 subschema........................................................46 3.2 Bit String........................................................8
3.3 Boolean...........................................................8
3.4 Country String....................................................9
3.5 Delivery Method...................................................9
3.6 Directory String..................................................9
3.7 DIT Content Rule Description.....................................10
3.8 DIT Structure Rule Description...................................11
3.9 DN...............................................................11
3.10 Enhanced Guide...................................................12
3.11 Facsimile Telephone Number.......................................12
3.12 Fax..............................................................13
3.13 Generalized Time.................................................13
3.14 Guide............................................................13
3.15 IA5 String.......................................................14
3.16 Integer..........................................................14
3.17 JPEG.............................................................14
3.18 LDAP Syntax Description..........................................15
3.19 Matching Rule Description........................................15
3.20 Matching Rule Use Description....................................15
3.21 MHS OR Address...................................................15
3.22 Name and Optional UID............................................16
3.23 Name Form Description............................................16
3.24 Numeric String...................................................16
3.25 Object Class Description.........................................17
3.26 Octet String.....................................................17
3.27 OID..............................................................17
3.28 Other Mailbox....................................................18
3.29 Postal Address...................................................18
3.30 Presentation Address.............................................19
3.31 Printable String.................................................21
3.32 Substring Assertion .......................................21
3.33 Telephone Number.................................................21
3.34 Teletex Terminal Identifier......................................22
7. Security Considerations...........................................47 3.35 Telex Number.....................................................22
7.1 Disclosure.......................................................47 3.36 UTC Time.........................................................23
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 4. Matching Rules....................................................23
4.1 bitStringMatch...................................................23
4.2 caseExactIA5Match................................................23
4.3 caseIgnoreIA5Match...............................................24
4.4 caseIgnoreListMatch..............................................24
4.5 caseIgnoreMatch..................................................24
4.6 caseIgnoreOrderingMatch..........................................24
4.7 caseIgnoreSubstringsMatch........................................25
4.8 distinguishedNameMatch...........................................25
4.9 generalizedTimeMatch.............................................25
4.10 generalizedTimeOrderingMatch.....................................25
4.11 integerFirstComponentMatch.......................................25
4.12 integerMatch.....................................................26
4.13 numericStringMatch...............................................26
4.14 numericStringSubstringsMatch.....................................26
4.15 objectIdentifierFirstComponentMatch..............................26
4.16 objectIdentifierMatch............................................26
4.17 octetStringMatch.................................................27
4.18 presentationAddressMatch.........................................27
4.19 protocolInformationMatch.........................................27
4.20 telephoneNumberMatch.............................................28
4.21 telephoneNumberSubstringsMatch...................................28
4.22 uniqueMemberMatch................................................28
9. Author's Address..................................................48 5. Security Considerations...........................................28
5.1 Disclosure.......................................................28
5.2 Security Information Syntaxes....................................28
5.3 Securing the Directory...........................................29
10. References........................................................48 6. Acknowledgements..................................................29
10.1 Normative.......................................................48
10.2 Informative.....................................................49
11. Full Copyright Statement..........................................50 7. Authors' Addresses................................................29
Annex A Object Identifiers for Syntaxes..............................51 8. References........................................................30
8.1 Normative........................................................30
8.2 Informative......................................................31
Annex B Topics to be Addressed in This Document......................52 9. Full Copyright Statement..................... .....................31
Annex C Change Log...................................................53 Annex A Object Identifiers for Syntaxes..............................32
Annex B Topics to be Addressed in This Document......................33
Annex C Change Log...................................................34
1. Overview 1. Overview
This document defines the framework for developing schemas for This document defines part of the framework for developing schemas
directories accessible via the Lightweight Directory Access for directories accessible via the Lightweight Directory Access
Protocol (LDAP) [Prot]. Protocol (LDAP) [Protocol].
Schema is the collection of attribute type definitions, object class Schema is the collection of attribute type definitions, object class
definitions and other information which specify the entries and their definitions and other information which specify the entries and their
contents that a server holds. A server uses schema to determine how contents that a server holds. A server uses schema to determine how
to match a filter or attribute value assertion (in a compare to match a filter or attribute value assertion (in a compare
operation) against the attributes of an entry, and whether to permit operation) against the attributes of an entry, and whether to permit
add and modify operations. add and modify operations. This document specifies syntaxes, which
are used in defining attribute types, and matching rules.
Therefore, Section 2 states the general requirements and notation Therefore, Section 2 states the general requirements and notation
for definition of attribute types, object classes, syntaxes and for definition of syntaxes and matching rules.
matching rules.
Section 3 lists syntaxes, section 4 matching rules, section 5 Section 3 lists syntaxes and section 4 contains matching rules.
attribute types, and section 6 object classes.
Additional documents define schemas for representing real-world Additional documents define schemas for representing real-world
objects as directory entries. objects as directory entries. See [Models], sections 2.4.1 and 2.6
and [Schema] for the definitions of user objects and attributes from
[X.501], [X.520], and [X.521].
2. General Issues 2. General Issues
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [Keywds]. document are to be interpreted as described in BCP 14 [RFC2119].
This document describes the syntaxes of data conveyed in an This document describes the syntaxes of data conveyed in an
Internet protocol. Internet protocol.
Attribute Type and Object Class definitions are written in a string
representation of the AttributeTypeDescription and
ObjectClassDescription data types defined in X.501 [Models].
Implementors are strongly advised to first read the description of Implementors are strongly advised to first read the description of
how schema is represented in X.500 before reading the rest of this how schema is represented in X.501 [X.501] before reading the rest
document. of this document.
2.1 Notation 2.1 Notation
For the purposes of defining the rules for describing attribute For the purposes of defining attribute syntaxes and matching rules,
syntaxes and other schema elements, the following augmented Augmented Backus-Naur Form (ABNF) is used. The ABNF productions
Backus-Naur Form (ABNF) definitions will be used. They are based on used in this document are used by other documents in the LDAP set
the ABNF styles of RFC 2234 [ABNF]. and are listed in [Models].
The schema definitions provided in this document are line-wrapped The schema definitions provided in this document are line-wrapped
for readability. for readability.
The definitions for ALPHA, DIGIT, ldapOID, number, DOT, LDIGIT, and In addition, the following ABNF productions are used in this
HYPHEN are given in the LDAP protocol specification [Prot]. document:
The definition of OCTET, from [ABNF], is:
OCTET = %x00-FF
; 8 bits of data
hex-digit = DIGIT / "a" / "b" / "c" / "d" / "e" / "f" /
"A" / "B" / "C" / "D" / "E" / "F"
k = ALPHA / DIGIT / HYPHEN
octetstring = *OCTET
p = ALPHA / DIGIT / "'" / "(" / ")" / "+" / "," / HYPHEN / "DOT" /
"="/ "/" / ":" / "?" / " "
numericstring = 1*DIGIT
anhstring = 1*k
keystring = ALPHA [ anhstring ]
printablestring = 1*p
space = 1*" "
whsp = [ space ]
utf8 = <any sequence of octets formed from the UTF-8 [UTF-8]
transformation of a character from ISO 10646 [UCS]
except "'">
dstring = 1*( utf8 / "''" )
; escaped utf8 string, each "'"
; appearing in 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, and hyphens starting
with a letter. An OBJECT IDENTIFIER in the numericoid format SHOULD
NOT have leading zeroes (e.g., "0.9.3" is permitted but "0.09.3"
SHOULD NOT be generated).
When 'oid' elements occur in a value, the 'descr' notation option
SHOULD be used in preference to the 'numericoid'. An object
descriptor is more readable than a numeric OBJECT IDENTIFIER, and a
descriptor (where assigned and known by the implementation) SHOULD
be used in preference to numeric oids to the greatest extent
possible. Examples of object descriptors in LDAP are attribute
type, object class, and matching rule names.
oid = descr / numericoid
descr = keystring
numericoid = numericstring *( 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 the
definitions of schema elements, (e.g., objectClassDescription
attribute), the values transferred in protocol would not contain
newlines.
In cases where an arbitrary string, not a Distinguished Name or part
of one, is used in a value of an attribute, a backslash quoting
mechanism is used to escape the following separator symbol
character, (such as, "'", "$" or "#") if it occurs in that
string. The backslash is followed by a pair of hexadecimal digits
representing the next character. A backslash itself in the string
which forms part of a larger syntax is always represented as '\5C'
or '\5c'. An example is given in section 3.33, postalAddress syntax.
Servers are not required to provide the same or any text in the
description part of the subschema values they maintain.
2.2 Syntaxes 2.2 Syntaxes
This section defines general requirements for LDAP attribute value This section defines general requirements for LDAP attribute
syntaxes. All documents defining attribute syntaxes for use with syntaxes. All documents defining attribute syntaxes for use with
LDAP are expected to conform to these requirements. LDAP are expected to conform to these requirements. Syntaxes are
Syntaxes are also defined for matching rules whose assertion value also defined for matching rules whose assertion value syntax is
syntax is different from the attribute value syntax. 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 the
user schema specification [User] are specified in this document in
Section 3. The object identifiers for these syntaxes are listed in
Annex A, also.
In X.501 [Models] and X.520 [Attr], the definition of the syntax is 2.2.1 LDAP-Specific Encodings
part of the attribute specification and a distinct OID for the syntax
is not assigned. As a result, X.501 does not define an attribute for
publishing syntaxes explicitly in a subschema entry.
In [Prot], the encoding of the LDAP protocol is specified. The In [Protocol], the encoding of the LDAP protocol is specified. The
protcol encapsulates values of attributes in many places. In this protcol encapsulates values of attributes in many places. In this
specification, the encoding of the values is specified, as part of specification, the encoding of the values is specified, as part of
each syntax definition. These value encoding rules are termed each syntax definition. These value encoding rules are termed
"native LDAP encoding". The native LDAP encoding of a value is what "LDAP-specific encodings". The LDAP-specific encoding of a value is
is transmitted in the protocol, unless a transfer option has been what is transmitted in the protocol.
invoked for the value. The transfer option mechanism and the Binary
transfer option are defined in [Prot].
The native LDAP encoding of a given attribute syntax always produces
octet-aligned values. To the greatest extent possible, the
native LDAP encoding of a value 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 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 The LDAP-specific encoding of a given attribute syntax always
MAY implement other syntaxes. produces octet-aligned values. To the greatest extent possible, the
LDAP-specific encoding of a value is supposed to be usable for
display purposes. In particular, encoding rules for attribute
syntaxes defining non-binary values are supposed to produce strings
that can be displayed with little or no translation by clients
implementing LDAP. There are a few cases (e.g., audio) however,
when it is not sensible to produce a human-readable representation.
Clients MUST NOT assume that the native LDAP encoding of a value of 2.2.2 Syntaxes Implementation Status
an unrecognized syntax is a human-readable character string.
2.2.2 Syntax Object Identifiers Clients and servers need not implement all the syntaxes listed in
section 3, and MAY implement other syntaxes.
Syntaxes for use with LDAP are named by OBJECT IDENTIFIERs, which Clients MUST NOT assume that the LDAP-specific encoding of a value
are dotted-decimal strings. These are not intended to be displayed of an unrecognized syntax is a human-readable character string.
to users. Annex A lists the syntaxes that have been defined for
LDAP in this document.
Other documents define additional syntaxes. However, the Other documents define additional attribute syntaxes. However, the
definition of additional arbitrary syntaxes is strongly deprecated definition of additional arbitrary syntaxes is strongly deprecated
since it will hinder interoperability. Today's client and server since it will hinder interoperability. Today's client and server
implementations generally do not have the ability to dynamically implementations generally do not have the ability to dynamically
recognize new syntaxes. In most cases, attributes will be defined recognize new syntaxes.
with the syntax for directory strings.
A suggested minimum upper bound on the number of characters in a
value with a string-based syntax, or the number of bytes in a value
for all other syntaxes, can be indicated by appending this bound
count inside of curly braces following the syntax name's OBJECT
IDENTIFIER in an attribute type definition. See the "numericoid"
production in paragraph 2.1. Such a bound is not part of the syntax
name itself. For instance, "1.3.6.4.1.1466.0{64}" suggests that
server implementations would allow a string to be 64 characters
long, although they can allow longer strings. Note that a single
character of the Directory String syntax can be encoded in more than
one byte since UTF-8 [UTF-8] is a variable-length encoding.
2.2.3 Syntax Description 2.2.3 Syntax Object Identifiers
The following ABNF is used in this document to associate a short In an LDAP schema, a syntax is named by the Object Identifier (OID)
description (e.g., a name) with a syntax OBJECT IDENTIFIER. The assigned to it.
productions for whsp, numericoid, qdescrs and qdstring are given in
paragraph 2.1. Implementors, note that future versions of this
document could expand this definition to include additional terms.
Terms whose identifier begins with "X-" are reserved for private
experiments, and MUST be followed by a <space> and a <qdstrings>
tokens.
SyntaxDescription = "(" whsp Syntaxes that are currently in use in the user schema specification
numericoid [Schema] and the models specification [Models] are specified in this
[ space "DESC" space qdstring ] document in section 3. The object identifiers assigned to these
extensions syntaxes are listed in Annex A.
whsp ")"
Note that the SyntaxDescription ABNF is also the ABNF that defines 2.2.4 Syntax Description
the native LDAP encoding of values of the LDAP Syntax Description
syntax.
2.2.4 Example The SyntaxDescription ABNF specified in [Models] is the method used
in this document to define the values for each syntax.
For example, the syntax descripion of the INTEGER syntax for whole For example, the syntax description of the INTEGER syntax for whole
number values is: number values is:
( 1.3.6.1.4.1.1466.115.121.1.27 DESC 'INTEGER' ) ( 1.3.6.1.4.1.1466.115.121.1.27 DESC 'INTEGER' )
2.3 Matching Rules 2.3 Matching Rules
The matching rules specified in this document are defined in The matching rules specified in this document are defined in
section 4. Section 4.
( 1.3.6.1.4.1.1466.115.121.1.27 DESC 'INTEGER' )
Matching rules are used by servers to compare attribute values Matching rules are used by servers to compare attribute values
against assertion values when performing Search and Compare against assertion values when performing Search and Compare
operations. They are also used to identify the value to be added operations. They are also used to identify the value to be added
or deleted when modifying entries, and are used when comparing a or deleted when modifying entries, and are used when comparing a
purported distinguished name with the name of an entry. purported distinguished name with the name of an entry.
Most of the attributes given in this document have an equality Most of the attributes given in the user schema [Schema] have an
matching rule defined. equality matching rule defined.
...An OID is assigned to a matching rule when it is defined. A ...An OID is assigned to a matching rule when it is defined. A
matching rule definition ought not be changed without having a new matching rule definition ought not be changed without having a new
OID assigned to it. OID assigned to it.
2.3.1 Matching Rules Implementation Status 2.3.1 Matching Rules Implementation Status
Servers which support matching rules and the extensibleMatch SHOULD Servers which support matching rules and the extensibleMatch SHOULD
implement all the matching rules in section 4. implement all the matching rules in section 4.
skipping to change at page 11, line 43 skipping to change at page 7, line 46
unreferenced matching rules MAY be published in the matchingRules unreferenced matching rules MAY be published in the matchingRules
attribute. attribute.
If the server supports the extensibleMatch, then the server MAY use If the server supports the extensibleMatch, then the server MAY use
the matchingRuleUse attribute to indicate the applicability of the matchingRuleUse attribute to indicate the applicability of
selected matching rules to designated attribute types in an selected matching rules to designated attribute types in an
extensibleMatch. extensibleMatch.
2.3.2 Matching Rule Description 2.3.2 Matching Rule Description
Matching rule descriptions are written according to the following The SyntaxDescription ABNF specified in [Models] is the method used
ABNF. The productions for numericoid, qdescrs, qdstring, oid, and The Matching Rule descriptions are specified according to the
whsp are given in section 2.1. Implementors, note that future MatchingRule ABNF specified in [Models].
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
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.
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" ]
[ 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 in section 3.24.
This document refines the schema description of X.501 [Models] by
requiring that the syntax field in an AttributeTypeDescription be a
string representation of an OBJECT IDENTIFIER for the LDAP string
syntax definition, and a possible indication of the maximum length
of a value of this attribute (defined in section 2.2.2).
Note that the AttributeTypeDescription ABNF is also the ABNF that
defines the Attribute Type Description syntax.
2.4.3 Example
For example, it would be useful for the directory 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 and to determine what attributes are contained in
those entries.
In general, every entry 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 is OPTIONAL.
Servers MUST publish in the objectClasses attribute of the same
subschema entry, the definitions of object classes referenced by
values of the nameForms and dITContentRules attributes, and object
classes referenced by the SUP field in values of the objectClasses
attribute itself. Other unreferenced object classes MAY be
published in the objectClasses attribute.
Schema developers MUST NOT create object class definitions whose
names conflict with object classes defined for use with LDAP in
existing standards-track RFCs. See the registry of names of Object
Classes maintained by IANA [Consid].
2.5.2 Object Class Description
Object class descriptions are written according to the following
ABNF. The productions for whsp, numericoid, qdescrs, qdstring,
space, and oids are given in section 2.1. Implementors, note that
future versions of this document could expand this definition to
include additional terms. Terms whose identifier begins with
"X-" are reserved for private experiments, and MUST be followed by a
<space> and a <qdstrings> tokens.
ObjectClassDescription = "(" whsp
numericoid
[ space "NAME" space qdescrs ]
[ space "DESC" space qdstring ]
[ space "OBSOLETE" ]
[ space "SUP" space oids ]
[ space ( "ABSTRACT" / "STRUCTURAL" / "AUXILIARY" ) ]
[ space "MUST" space oids ]
[ space "MAY" space oids ] ; AttributeTypes
extensions
whsp ")"
The numericoid is the identifier of the ObjectClass being described.
The NAME string is the string registered with IANA [Consid] and used
to identify instances of the ObjectClass described.
The SUP oids are the identifiers of the Object Classes which are the
superclasses (object classes) of the Object Class defined.
The default setting is "structural" when ABSTRACT, STRUCTURAL, and
AUXILIARY are absent.
The MUST oids identify the Attribute Types that are required 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 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 the directory. The
same pieces of information are needed in several kinds 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 the different kinds of employees. The
pieces of information could be: name of the last training course
attended, how many courses has the employee taken, category of
training program. The types of information could be named the
lastCourse, coursesCount, program attributes, respectively. The
following could be the description of an auxiliary object class that
provides for inclusion of the training information in different
kinds of entries. (The OID is artificial.)
( 1.1.3.170.2.65 NAME 'trainingInfo'
AUXILIARY
MUST program
MAY ( lastCourse $ coursesCount ) )
3. Syntaxes 3. Syntaxes
3.1 Attribute Type Description 3.1 Attribute Type Description
A value in this syntax is a definition of an attribute type A value in this syntax is a definition of an attribute type
according to the ABNF given in paragraph 2.4.2. The native LDAP according to the ABNF given [Models]. The LDAP-specific encoding is
encoding is the character codes in UTF-8 which correspond to the the character codes in UTF-8 which correspond to the characters in
characters in the definition. the definition.
This syntax is the form in which schema attribute types are This syntax is the form in which schema attribute types are
published in the directory in a subentry. The following syntax published in the directory in a subentry. The following syntax
description gives the OID assigned to this syntax: description gives the OID assigned to this syntax:
( 1.3.6.1.4.1.1466.115.121.1.3 DESC 'Attribute Type Description' ) ( 1.3.6.1.4.1.1466.115.121.1.3 DESC 'Attribute Type Description' )
For example, this is the definition from [User] of the For example, this is the definition from [User] of the
businessCategory attribute type: businessCategory attribute type:
( 2.5.4.15 NAME 'businessCategory' ( 2.5.4.15 NAME 'businessCategory'
EQUALITY caseIgnoreMatch EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{128} ) SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{128} )
The syntax type for the businessCategory Attribute Type is Directory The syntax type for the businessCategory Attribute Type is Directory
String. String.
This example definition is a value of the Attribute Type Description This example definition is a value of the Attribute Type Description
syntax. The native LDAP encoding of this value is the definition syntax. The LDAP-specific encoding of this value is the definition
itself. itself.
3.2 Bit String 3.2 Bit String
A value in this syntax is a value of the BIT STRING data type from A value in this syntax is a value of the BIT STRING data type from
ASN.1 [ASN1]. The following syntax description gives the OID ASN.1 [X.680]. The following syntax description gives the OID
assigned to this syntax: assigned to this syntax:
( 1.3.6.1.4.1.1466.115.121.1.6 DESC 'Bit String' ) ( 1.3.6.1.4.1.1466.115.121.1.6 DESC 'Bit String' )
The native LDAP encoding of a value is the following ABNF: The LDAP-specific encoding of a value is the following ABNF:
bitstring = "'" *binary-digit "'B" bitstring = SQUOTE *binary-digit SQUOTE "B"
binary-digit = "0" / "1" binary-digit = "0" / "1"
Example: '0101111101'B Example: '0101111101'B
3.3 Boolean 3.3 Boolean
A value in this syntax is a value of the BOOLEAN data type from A value in this syntax is a value of the BOOLEAN data type from
ASN.1 [ASN1]. That is, there are exactly two values: one value ASN.1 [X.680]. That is, there are exactly two values: one value
representing logically true, and the other representing logically representing logically true, and the other representing logically
false. The following syntax description gives the OID assigned to false. The following syntax description gives the OID assigned to
this syntax: this syntax:
( 1.3.6.1.4.1.1466.115.121.1.7 DESC 'Boolean' ) ( 1.3.6.1.4.1.1466.115.121.1.7 DESC 'Boolean' )
The native LDAP encoding of a value is the following ABNF: The LDAP-specific encoding of a value is the following ABNF:
boolean = "TRUE" / "FALSE" boolean = "TRUE" / "FALSE"
3.4 Country String 3.4 Country String
A value in this syntax is two ASN.1 printable string characters A value in this syntax is two ASN.1 [X.680] printable string characters
representing a country. The permitted values are as listed in representing a country. The permitted values are as listed in
ISO 3166 [Codes]. The following syntax description gives the OID ISO 3166 [ISO3166]. The following syntax description gives the OID
assigned to this syntax: assigned to this syntax:
( 1.3.6.1.4.1.1466.115.121.1.11 DESC 'Country String' ) ( 1.3.6.1.4.1.1466.115.121.1.11 DESC 'Country String' )
The native LDAP encoding of a value is the following ABNF: The LDAP-specific encoding of a value is the following ABNF:
CountryString = p p
The production for p is given in section 2.1. CountryString = ALPHA ALPHA
Example: US Example: US
3.5 Delivery Method 3.5 Delivery Method
A value in this syntax is a set of the ASN.1 enumerated INTEGER A value in this syntax is a set of the ASN.1 [X.680] enumerated
values that indicates, in preference order, the service(s) by which INTEGER values that indicates, in preference order, the service(s)
the user, represented by the entry, is willing and/or capable of by which the user, represented by the entry, is willing and/or
receiving messages. capable of receiving messages.
The following syntax description gives the OID assigned to this The following syntax description gives the OID assigned to this
syntax: syntax:
( 1.3.6.1.4.1.1466.115.121.1.14 DESC 'Delivery Method' ) ( 1.3.6.1.4.1.1466.115.121.1.14 DESC 'Delivery Method' )
The native LDAP encoding of a value is the following ABNF: The LDAP-specific encoding of a value is the following ABNF:
delivery-value = pdm / ( whsp pdm space "$" space delivery-value ) delivery-value = pdm / ( WSP pdm SP DOLLAR SP delivery-value )
pdm = "any" / "mhs" / "physical" / "telex" / "teletex" / pdm = "any" / "mhs" / "physical" / "telex" / "teletex" /
"g3fax" / "g4fax" / "ia5" / "videotex" / "telephone" "g3fax" / "g4fax" / "ia5" / "videotex" / "telephone"
The production for space is given in section 2.1.
Example: telephone $ videotex Example: telephone $ videotex
3.6 Directory String 3.6 Directory String
A value in this syntax is a value of one of the TeletexString, A value in this syntax is a value of one of the TeletexString,
PrintableString or UniversalString data types from ASN.1 [ASN1]. The PrintableString or UniversalString data types from ASN.1 [X.680].
minimum length of a Directory String value is one character, that The minimum length of a Directory String value is one character, that
is, the string cannot be 'empty'. The following syntax description is, the string cannot be 'empty'. The following syntax description
gives the OID assigned to this syntax: gives the OID assigned to this syntax:
( 1.3.6.1.4.1.1466.115.121.1.15 DESC 'Directory String' ) ( 1.3.6.1.4.1.1466.115.121.1.15 DESC 'Directory String' )
The LDAP-specific encoding of a value is the character string itself.
The native LDAP encoding of a value is the character string itself. Note: The form of DirectoryString is not indicated in protocol.
Servers which convert to DAP MUST choose an appropriate form.
Note: The form of DirectoryString is not indicated in protocol, Servers MUST NOT reject values merely because they contain legal
unless the ;binary option is used (see [Prot]). Servers which Unicode characters outside of the range of printable ASCII.
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 Servers and clients MUST be prepared to receive arbitrary Unicode
characters, including characters not presently assigned to any characters, including characters not presently assigned to any
character set. character set.
Example: Example:
This is a string of DirectoryString containing #!%#@. This is a string of DirectoryString containing #!%#@.
For characters in the PrintableString form, the value in the native For characters in the PrintableString form, the value in the native
LDAP encoding is the value itself. LDAP encoding is the value itself.
If it is in the TeletexString form, then the characters are If the string is in the TeletexString form, then the characters are
transliterated to their equivalents in UniversalString, and encoded transliterated to their equivalents in UniversalString, and encoded
in UTF-8 [UTF-8]. in UTF-8 [RFC2044].
If it is in the UniversalString or BMPString forms [UCS], UTF-8 is If the string is in the UniversalString or BMPString forms [ISO10646],
the native LDAP encoding. UTF-8 is the LDAP-specific encoding.
3.7 DIT Content Rule Description 3.7 DIT Content Rule Description
A value in this syntax is a definition of a DIT content rule The following syntax description gives the OID assigned to this
according to the following ABNF: syntax:
DITContentRuleDescription = "(" whsp
numericoid
[ space "NAME" space qdescrs ]
[ space "DESC" space qdstring ]
[ space "OBSOLETE" ]
[ space "AUX" space oids ]
[ space "MUST" space oids ]
[ space "MAY" space oids ]
[ space "NOT" space oids ]
extensions
whsp ")"
The numericoid is the identifier of the Structural Object Class to
which the Content Rule being described applies.
The MUST oids identify Attribute Types, besides those in the
Structural Object Class, that must have values in every instance of
the Object Class.
...The MAY oids identify Attribute Types, besides those in the
Structural and Auxiliary Object Classes, that are permitted to have
values in an instance of the Structural Object Class.
The NOT oids identify Attribute Types, which occur in the Structural
and Auxiliary Object Classes, that are prohibited from having values
in an instance of the Structural Object Class.
The AUX oids identify the Auxiliary Object Classes which can be
added to instances of the Structural Object Class.
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 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.
This syntax is the form in which schema content rules are published
in the directory in a subentry. The following syntax description
gives the OID assigned to this syntax:
( 1.3.6.1.4.1.1466.115.121.1.16 DESC 'DIT Content Rule ( 1.3.6.1.4.1.1466.115.121.1.16 DESC 'DIT Content Rule
Description' ) Description' )
3.8 DIT Structure Rule Description This syntax is the form in which schema content rules are published
in the directory in a subentry.
A value in the DIT Structure Rule Description syntax is a definition A value in this syntax is a definition of a DIT content rule
of a schema Structure Rule according to the following ABNF: according to the ABNF in [Models].
DITStructureRuleDescription = "(" whsp The native LDAP encoding of a value is the character string
ruleidentifier (DirectoryString) itself.
[ space "NAME" space qdescrs ]
[ space "DESC" space qdstring ]
[ space "OBSOLETE" ]
space "FORM" space oid
[ space "SUP" ruleidentifiers ]
extensions
whsp ")"
The ruleidentifier is an integer which distinguishes one Structure
Rule from the others used in the same LDAP server.
The FORM oid identifies the Name Form that specifies the naming Note: The form of DirectoryString is not indicated in protocol,
attribute(s) used at the point in the DIT to which the Structure unless the ;binary option is used (see [Prot]). Servers which
Rule applies. 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.
The SUP ruleidentifiers indicate the Structure Rules that can be Servers and clients MUST be prepared to receive arbitrary Unicode
applied immediately ahead of the subject Structure Rule in the DIT. characters, including characters not presently assigned to any
That is, the RDN forms which can be one level higher in the DIT. character set.
ruleidentifier = numericstring Example:
This is a string of DirectoryString containing #!%#@.
ruleidentifiers = ruleidentifier / "(" whsp ruleidentifierlist For characters in the PrintableString form, the value in the native
whsp ")" LDAP encoding is the value itself.
ruleidentifierlist = [ ruleidentifier *( space ruleidentifier ) ] If it is in the TeletexString form, then the characters are
transliterated to their equivalents in UniversalString, and encoded
in UTF-8 [UTF-8].
The productions for whsp, numericstring, qdescrs, qdstring, space, If it is in the UniversalString or BMPString forms [ISO10646], UTF-8
and oid are given in paragraph 2.1. is the native LDAP encoding.
The native LDAP encoding is the character codes in UTF-8 [UTF-8] 3.8 DIT Structure Rule Description
which correspond to the characters in the structure rule definition.
This syntax is the form in which schema structure rules are The following syntax description gives the OID assigned to this
published in the directory in a subentry. The following syntax syntax:
description gives the OID assigned to this syntax:
( 1.3.6.1.4.1.1466.115.121.1.17 DESC 'DIT Structure Rule ( 1.3.6.1.4.1.1466.115.121.1.17 DESC 'DIT Structure Rule
Description' ) Description' )
This syntax is the form in which schema structure rules are published
in the directory in a subentry.
A value in the DIT Structure Rule Description syntax is a definition
of a schema Structure Rule according to the ABNF in [Models].
The LDAP-specific encoding is the character codes in UTF-8 [UTF-8]
which correspond to the characters in the structure rule definition.
3.9 DN 3.9 DN
A value in the Distinguished Name syntax is a structured set of the A value in the Distinguished Name syntax is a structured set of the
ASN.1 data types that are included in the DirectoryString syntax. ASN.1 [X.680] data types that are included in the DirectoryString
The following syntax description gives the OID assigned to this syntax. The following syntax description gives the OID assigned to
syntax: this syntax:
( 1.3.6.1.4.1.1466.115.121.1.12 DESC 'DN' ) ( 1.3.6.1.4.1.1466.115.121.1.12 DESC 'DN' )
The native LDAP encoding of a value is defined in [DN String]. Note The LDAP-specific encoding of a value is defined in [LDAPDN]. Note
that the native LDAP encoding is not reversible to the original BER that the LDAP-specific encoding is not reversible to the original BER
encoding used in X.500 for Distinguished Names, as the CHOICE of any encoding used in X.500 for Distinguished Names, as the CHOICE of any
DirectoryString element in an RDN is not evident in the native LDAP DirectoryString element in an RDN is not evident in the LDAP-specific
encoding.. See the note in section 3.10. encoding.. See the note in section 3.7.
Examples (from [DN String]): Examples (from [LDAPDN]):
CN=Steve Kille,O=Isode Limited,C=GB CN=Steve Kille,O=Isode Limited,C=GB
OU=Sales+CN=J. Smith,O=Widget Inc.,C=US OU=Sales+CN=J. Smith,O=Widget Inc.,C=US
CN=L. Eagle,O=Sue\, Grabbit and Runn,C=GB CN=L. Eagle,O=Sue\, Grabbit and Runn,C=GB
CN=Before\0DAfter,O=Test,C=GB CN=Before\0DAfter,O=Test,C=GB
1.1.3.6.1.4.1.1466.0=#04024869,O=Test,C=GB 1.1.3.6.1.4.1.1466.0=#04024869,O=Test,C=GB
SN=Lu\C4\8Di\C4\87 SN=Lu\C4\8Di\C4\87
3.10 Enhanced Guide 3.10 Enhanced Guide
A value in the Enhanced Guide syntax is the matching criteria and A value in the Enhanced Guide syntax is the matching criteria and
scope of operation in an Enhanced Filter. scope of operation in an Enhanced Filter.
The native LDAP encoding of a value is the following ABNF: The following syntax description gives the OID assigned to this syntax:
EnhancedGuide = space oid whsp "#" whsp criteria whsp "#" ( 1.3.6.1.4.1.1466.115.121.1.21 DESC 'Enhanced Guide' )
whsp subset
The LDAP-specific encoding of a value is defined by the
following ABNF:
EnhancedGuide = SP oid WSP SHARP WSP criteria WSP SHARP
WSP subset
subset = "baseobject" / "oneLevel" / "wholeSubtree" subset = "baseobject" / "oneLevel" / "wholeSubtree"
criteria = or-term / "(" or-term ")" criteria = or-term / LPAREN or-term RPAREN
or-term = and-term *( "|" and-term ) or-term = and-term *( "|" and-term )
and-term = not-term *( "&" not-term ) and-term = not-term *( "&" not-term )
not-term = "!" not-term / not-term = "!" not-term /
attributetype "$" match-type / attributetype DOLLAR match-type /
"(" or-term ")" / LPAREN or-term RPAREN /
"?true" / ; "?true" / ;
"?false" "?false"
The ?true term alternative represents an empty "and" in the Criteria
ASN.1 type. The ?false alternative represents an empty "or" in the
Criteria ASN.1 type.
match-type = "EQ" / "SUBSTR" / "GE" / "LE" / "APPROX" match-type = "EQ" / "SUBSTR" / "GE" / "LE" / "APPROX"
The following syntax description gives the OID assigned to this syntax: The ?true term alternative represents an empty "and" in the Criteria.
The ?false alternative represents an empty "or" in the Criteria.
( 1.3.6.1.4.1.1466.115.121.1.21 DESC 'Enhanced Guide' )
Example: Example:
person#(sn)#oneLevel person#(sn)#oneLevel
3.11 Facsimile Telephone Number 3.11 Facsimile Telephone Number
A value in the Facsimile Telephone Number syntax is a subscriber A value in the Facsimile Telephone Number syntax is a subscriber
number on the (public) telephone network of a facsimile device. The number on the (public) telephone network of a facsimile device. The
native LDAP encoding of a value is the following ABNF: telephone number is a character string based on E.123 [E.123]. The
character string type is the PrintableString data type from
ASN.1 [X.680]. The following syntax description gives the OID
assigned to this syntax:
( 1.3.6.1.4.1.1466.115.121.1.22 DESC 'Facsimile Telephone Number')
The LDAP-specific encoding of a value is defined by the
following ABNF:
fax-number = printablestring [ "$" faxparameters ] fax-number = printablestring [ "$" faxparameters ]
; telephone number, possibly followed by facsimile ; telephone number, possibly followed by facsimile
parameters ; parameters
printablestring = 1*p
p = ALPHA / DIGIT / SQUOTE / LPAREN / RPAREN / PLUS / COMMA /
HYPHEN / DOT / EQUALS / SLASH / COLON / QUESTION / SPACE
faxparameters = faxparm / ( faxparm "$" faxparameters ) faxparameters = faxparm / ( faxparm "$" faxparameters )
faxparm = "twoDimensional" / "fineResolution" / "unlimitedLength" faxparm = "twoDimensional" / "fineResolution" / "unlimitedLength"
/ "b4Length" / "a3Width" / "b4Width" / "uncompressed" / "b4Length" / "a3Width" / "b4Width" / "uncompressed"
The production for printablestring is given in section 2.1.
The telephone number is based on E.123 [Tel #].
A printablestring is the PrintableString data type from ASN.1
[ASN1]. The following syntax description gives the OID assigned
to this syntax:
( 1.3.6.1.4.1.1466.115.121.1.22 DESC 'Facsimile Telephone Number')
3.12 Fax 3.12 Fax
A value in the Fax syntax is an image which is produced using the A value in the Fax syntax is an image which is produced using the
Group 3 facsimile process [Fax] to duplicate an object, such as Group 3 facsimile process [Fax] to duplicate an object, such as
a memo. a memo.
The following syntax description gives the OID assigned to this The following syntax description gives the OID assigned to this
syntax: syntax:
( 1.3.6.1.4.1.1466.115.121.1.23 DESC 'Fax' ) ( 1.3.6.1.4.1.1466.115.121.1.23 DESC 'Fax' )
Values in this syntax are expressed as octet strings containing Values in this syntax are expressed as octet strings containing
Group 3 Fax images as defined in [Fax]. Group 3 Fax images as defined in [Fax].
3.13 Generalized Time 3.13 Generalized Time
A value in the Generalized Time syntax is a date and time. The year A value in the Generalized Time syntax is a date and time. The year
is given as a four-digit number. is given as a four-digit number. The following syntax description
gives the OID assigned to this syntax:
The native LDAP encoding is a value of the GeneralizedTime data type
from ASN.1 [ASN1]. Time zone MUST be present and SHOULD be GMT (Z).
The following syntax description gives the OID assigned to this
syntax:
( 1.3.6.1.4.1.1466.115.121.1.24 DESC 'Generalized Time' ) ( 1.3.6.1.4.1.1466.115.121.1.24 DESC 'Generalized Time' )
The LDAP-specific encoding is a value of the GeneralizedTime data type
from ASN.1 [X.680]. Time zone MUST be present and SHOULD be GMT (Z).
Example: Example:
199412161032Z means 10:32 a.m. Dec. 16, 1994 in the Greenwich 199412161032Z means 10:32 a.m. Dec. 16, 1994 in the Greenwich
Mean Time time zone. Mean Time time zone.
3.14 Guide 3.14 Guide
A value in the Guide syntax is the matching criteria in a Filter. A value in the Guide syntax is the matching criteria in a Filter.
The following syntax description gives the OID assigned to this The following syntax description gives the OID assigned to this
syntax: syntax:
skipping to change at page 25, line 13 skipping to change at page 14, line 4
Mean Time time zone. Mean Time time zone.
3.14 Guide 3.14 Guide
A value in the Guide syntax is the matching criteria in a Filter. A value in the Guide syntax is the matching criteria in a Filter.
The following syntax description gives the OID assigned to this The following syntax description gives the OID assigned to this
syntax: syntax:
( 1.3.6.1.4.1.1466.115.121.1.25 DESC 'Guide' ) ( 1.3.6.1.4.1.1466.115.121.1.25 DESC 'Guide' )
The Guide syntax is not intended to be used for defining new The Guide syntax is not intended to be used for defining new
attributes. It is important for backwards compatibility with LDAP attributes. It is important for backwards compatibility with LDAP
systems that implement an earlier version of LDAP [LDAP '95]. systems that implement an earlier version of LDAP [RFC1778].
The native LDAP encoding of a value is defined by the following ABNF: The LDAP-specific encoding of a value is defined by the
following ABNF:
guide-value = [ object-class "#" ] criteria guide-value = [ object-class "#" ] criteria
object-class = space oid object-class = SP oid
The criteria production is defined in the Enhanced Guide syntax in The criteria production is defined in the Enhanced Guide syntax in
section 3.14. The productions for oid and space are in section 2.1. section 3.11.
3.15 IA5 String 3.15 IA5 String
A value in the IA5 String syntax is a value of the IA5String data A value in the IA5 String syntax is a value of the IA5String data
type from ASN.1 [ASN1]. International Alphabet 5 (IA5) [IA5] is the type from ASN.1 [X.680]. International Alphabet 5 (IA5) [IA5] is the
international version of the ASCII character set. international version of the ASCII character set.
The following syntax description gives the OID assigned to this The following syntax description gives the OID assigned to this
syntax: syntax:
( 1.3.6.1.4.1.1466.115.121.1.26 DESC 'IA5 String' ) ( 1.3.6.1.4.1.1466.115.121.1.27 DESC 'IA5 String' )
The native LDAP encoding of a value in this syntax is the character The LDAP-specific encoding of a value in this syntax is the character
string value itself. string value itself.
3.16 Integer 3.16 Integer
A value in the INTEGER syntax is a whole number as specified in the A value in the INTEGER syntax is a whole number as specified in the
INTEGER data type from ASN.1 [ASN1]. INTEGER data type from ASN.1 [X.680].
The following syntax description gives the OID assigned to this The following syntax description gives the OID assigned to this
syntax: syntax:
( 1.3.6.1.4.1.1466.115.121.1.27 DESC 'INTEGER' ) ( 1.3.6.1.4.1.1466.115.121.1.27 DESC 'INTEGER' )
The native LDAP encoding of a value is the decimal representation of The LDAP-specific encoding of a value is the decimal representation of
the value, with each decimal digit represented by the its character the value, with each decimal digit represented by the its character
equivalent. So, the number 1321 is represented by the character equivalent. So, the number 1321 is represented by the character
string "1321". string "1321".
3.17 JPEG 3.17 JPEG
A value in the JPEG syntax is an image produced according to A value in the JPEG syntax is an image produced according to
specific rules for light values. The native LDAP encoding of a specific rules for light values. The following syntax description
value is strings containing JPEG images in the JPEG File Interchange gives the OID assigned to this syntax:
Format (JFIF), as described in [JPEG].
The following syntax description gives the OID assigned to this
syntax:
( 1.3.6.1.4.1.1466.115.121.1.28 DESC 'JPEG' ) ( 1.3.6.1.4.1.1466.115.121.1.28 DESC 'JPEG' )
The LDAP-specific encoding of a value is an octet string of the
light values representing the image.
3.18 LDAP Syntax Description 3.18 LDAP Syntax Description
A value in the LDAP Syntax Description syntax is a definition of a A value in the LDAP Syntax Description syntax is a definition of a
LDAP syntax description according to the ABNF given in section 2.2.3. LDAP syntax description according to the ABNF given in [MODELS].
The native LDAP encoding is the character codes in UTF-8 [UTF-8]
which correspond to the characters in the definition.
This syntax is the form in which schema syntax descriptions are This syntax is the form in which schema syntax descriptions are
published in the directory in a subentry. The following syntax published in the directory in a subentry. The following syntax
description gives the OID assigned to this syntax: description gives the OID assigned to this syntax:
( 1.3.6.1.4.1.1466.115.121.1.54 DESC 'LDAP Syntax Description' ) ( 1.3.6.1.4.1.1466.115.121.1.54 DESC 'LDAP Syntax Description' )
Note that, in X.520 [Attr], syntaxes are not labeled distinctly Note that, in X.520 [Attr], syntaxes are not labeled distinctly
with respect to attributes. with respect to attributes.
The LDAP-specific encoding is the character codes in UTF-8 [ISO10646]
which correspond to the characters in the definition.
3.19 Matching Rule Description 3.19 Matching Rule Description
A value in the Matching Rule Description syntax is a definition of A value in the Matching Rule Description syntax is a definition of
a matching rule according to the ABNF given in section 2.3.2. The a matching rule according to the ABNF given in [MODELS]. This syntax
native LDAP encoding is the character codes in UTF-8 [UTF-8] which is the form in which schema matching rules are published in the
correspond to the characters in the definition of a Matching Rule. directory in a subentry. The following syntax definition gives the
This syntax is the form in which schema matching rules are published OID assigned to this syntax:
in the directory in a subentry. The following syntax definition
gives the OID assigned to this syntax:
( 1.3.6.1.4.1.1466.115.121.1.31 DESC 'Matching Rule Description' ) ( 1.3.6.1.4.1.1466.115.121.1.31 DESC 'Matching Rule Description' )
The LDAP-specific encoding is the character codes in UTF-8 [ISO10646]
which correspond to the characters in the definition of a Matching
Rule.
3.20 Matching Rule Use Description 3.20 Matching Rule Use Description
A value in the Matching Rule Use Description syntax is a definition A value in the Matching Rule Use Description syntax is a definition
of a matching Rule and the attribute types with which the rule could of a matching Rule and the attribute types with which the rule could
be used in an extensibleMatch search filter according to the be used in an extensibleMatch search filter. The values are
following ABNF: specified according to the ABNF given in [MODELS]. The following
syntax description gives the OID assigned to this syntax:
MatchingRuleUseDescription = "(" whsp
numericoid
[ space "NAME" space qdescrs ]
[ space "DESC" space qdstring ]
[ space "OBSOLETE" ]
space "APPLIES" space oids ; AttributeType identifiers
extensions
whsp ")"
The numericoid identifies the Matching Rule for which the usage is
specified.
The APPLIES oids identify the Attribute Types for which the Matching
Rule can be used.
The productions for whsp, numericoid, qdescrs, qdstring, space, and
oids are given in paragraph 2.1. Implementors, note that
future versions of this document could expand this ABNF to include
additional terms. Terms whose identifier begins with "X-" are
reserved for private experiments, and MUST be followed by a <space>
and a <qdstrings> tokens.
The native LDAP encoding is the character codes in UTF-8 [UTF-8]
which correspond to the characters in the definition.
The following syntax description gives the OID assigned to this
syntax:
( 1.3.6.1.4.1.1466.115.121.1.31 DESC 'Matching Rule Use ( 1.3.6.1.4.1.1466.115.121.1.31 DESC 'Matching Rule Use
Description' ) Description' )
This syntax is the form in which schema matching rule usage This syntax is the form in which schema matching rule usage
permissions are published in the directory in a subentry. permissions are published in the directory in a subentry.
The LDAP-specific encoding is the character codes in UTF-8 [ISO10646]
which correspond to the characters in the definition.
3.21 MHS OR Address 3.21 MHS OR Address
A value in the MHS OR Address syntax is the addressing information of A value in the MHS OR Address syntax is the addressing information of
a user of an X.400 messaging service. The native LDAP encoding is a user of an X.400 messaging service. The LDAP-specific encoding is
defined in RFC 1327 [Map]. defined in RFC 1327 [RFC1327].
The following syntax description gives the OID assigned to this The following syntax description gives the OID assigned to this
syntax: syntax:
( 1.3.6.1.4.1.1466.115.121.1.33 DESC 'MHS OR Address' ) ( 1.3.6.1.4.1.1466.115.121.1.33 DESC 'MHS OR Address' )
3.22 Name and Optional UID 3.22 Name and Optional UID
A value of the Name and Optional UID (Unique IDentifier) syntax is a A value of the Name and Optional UID (Unique IDentifier) syntax is a
Distinguished Name as defined in section 3.13 plus a bit string Distinguished Name as defined in section 3.9 plus a bit string
that differentiates the value from otherwise identical names. that differentiates the value from otherwise identical names. The following syntax description gives the OID assigned to this
syntax:
The native LDAP encoding of a value is the following ABNF: ( 1.3.6.1.4.1.1466.115.121.1.34 DESC 'Name And Optional UID' )
The LDAP-specific encoding of a value is the following ABNF:
NameAndOptionalUID = DistinguishedName [ "#" bitstring ] NameAndOptionalUID = DistinguishedName [ "#" bitstring ]
The bitstring production is defined in section 3.3.
Although the '#' character could occur in a string representation of Although the '#' character could occur in a string representation of
a distinguished name, no additional special quoting is done. a distinguished name, no additional special quoting is done.
Example: Example:
1.3.6.1.4.1.1466.0=#04024869,O=Test,C=GB#'0101'B 1.3.6.1.4.1.1466.0=#04024869,O=Test,C=GB#'0101'B
The following syntax description gives the OID assigned to this
syntax:
( 1.3.6.1.4.1.1466.115.121.1.34 DESC 'Name And Optional UID' )
3.23 Name Form Description 3.23 Name Form Description
A value in the Name Form Description syntax is a definition of a A value in the Name Form Description syntax is a definition of a
Name Form according to the following ABNF: Name Form according to the ABNF given in [MODELS].
NameFormDescription = "(" whsp
numericoid
[ space "NAME" space qdescrs ]
[ space "DESC" space qdstring ]
[ space "OBSOLETE" ]
space "OC" space oid
space "MUST" space oids ; AttributeTypes
[ space "MAY" space oids ] ; AttributeTypes
extentions
whsp ")"
The numericoid identifies the Name Form being described.
The OC oid identifies the Structural Object Class for instances of
which the Name Form specifies the naming attributes (i.e., the RDN).
The MUST oids identify the Attribute Types that are required to have
a distinguished value in the RDN for a directory entry.
The MAY oids identify Attribute Types that are optional in the RDN.
The productions for whsp, numericoid, qdescrs, qdstring, oid, and
oids are given in section 2.1. Implementors, note that future
versions of this document could have expanded this ABNF to include
additional terms.
A value indicates the one or more attributes in an entry type (e.g., A value indicates the one or more attributes in an entry type (e.g.,
person, device) that are used as the Relative Distinguished Name of person, device) that are used as the Relative Distinguished Name of
the entries. the entrY.
This syntax is the form in which schema name forms are published in This syntax is the form in which schema name forms are published in
the directory. The native LDAP encoding of a value is the character the directory. The LDAP-specific encoding of a value is the
codes in UTF-8 [UTF-8] which correspond to the characters in the character codes in UTF-8 [ISO10646] which correspond to the
definition. characters in the definition.
The following syntax description gives the OID assigned to this The following syntax description gives the OID assigned to this
syntax: syntax:
( 1.3.6.1.4.1.1466.115.121.1.35 DESC 'Name Form Description' ) ( 1.3.6.1.4.1.1466.115.121.1.35 DESC 'Name Form Description' )
3.24 Numeric String 3.24 Numeric String
A value in the Numeric String syntax is a series of numerals and A value in the Numeric String syntax is a series of numerals and
spaces as specified in the NumericString data type from spaces as specified in the NumericString data type from
ASN.1 [ASN1]. The following string states the OID assigned to ASN.1 [X.680]. The following string states the OID assigned to
this syntax: this syntax:
( 1.3.6.1.4.1.1466.115.121.1.36 DESC 'Numeric String' ) ( 1.3.6.1.4.1.1466.115.121.1.36 DESC 'Numeric String' )
The representation of a string in this syntax is the string value The representation of a string in this syntax is the string value
itself. itself.
Example: 1997 Example: 1997
3.25 Object Class Description 3.25 Object Class Description
A value in this syntax is a character string which expresses the A value in this syntax is a character string which expresses the
definition of an object class according to the ABNF given in definition of an object class according to the ABNF given in
section 2.5.2. This syntax is the form in which schema object [MODELS]. This syntax is the form in which schema object classes
classes are published in the directory in a subentry. The following are published in the directory in a subentry. The following string
string states the OID assigned to this syntax: states the OID assigned to this syntax:
( 1.3.6.1.4.1.1466.115.121.1.37 DESC 'Object Class Description' ) ( 1.3.6.1.4.1.1466.115.121.1.37 DESC 'Object Class Description' )
For example, the character string below specifies the country object For example, the character string below specifies the country object
class, which requires the c (country name) attribute and allows the class, which requires the c (country name) attribute and allows the
searchGuide and description attributes. All of these schema searchGuide and description attributes. All of these schema
elements are specified in [User]. elements are specified in [Schema].
( 2.5.6.2 NAME 'country' SUP top STRUCTURAL MUST c ( 2.5.6.2 NAME 'country' SUP top STRUCTURAL MUST c
MAY ( searchGuide $ description ) ) MAY ( searchGuide $ description ) )
3.26 Octet String 3.26 Octet String
A value in the Octet String syntax is a value of the OCTET STRING A value in the Octet String syntax is a value of the OCTET STRING
data type from ASN.1 [ASN1]. The following string states the OID data type from ASN.1 [X.680]. The following string states the OID
assigned to this syntax: assigned to this syntax:
( 1.3.6.1.4.1.1466.115.121.1.40 DESC 'Octet String' ) ( 1.3.6.1.4.1.1466.115.121.1.40 DESC 'Octet String' )
Values in this syntax are written as a series of 8-bit values, Values in this syntax are written as a series of 8-bit values,
according to the octet string value notation specified in [ASN1]. according to the octet string value notation specified in [X.680].
In the case of character strings, the characters themselves could be In the case of character strings, the characters themselves could be
written. written.
Example: Example:
secret secret
3.27 OID 3.27 OID
A value in the Object Identifier syntax is a series of integers, A value in the Object Identifier syntax is a series of integers,
ordered as specified in the OBJECT IDENTIFIER data type from ASN.1 ordered as specified in the OBJECT IDENTIFIER data type from ASN.1
[ASN1]. The following string states the OID assigned to this [X.680]. The following string states the OID assigned to this
syntax: syntax:
( 1.3.6.1.4.1.1466.115.121.1.38 DESC 'OID' ) ( 1.3.6.1.4.1.1466.115.121.1.38 DESC 'OID' )
Values in this syntax are expressed according to the ABNF in Values in this syntax are expressed according to the ABNF in
section 2.1 for "oid". [MODELS], section 1.3 for "oid".
Examples: 1.2.3.4 Examples: 1.2.3.4
cn cn
3.28 Other Mailbox 3.28 Other Mailbox
A value in the Other Mailbox syntax gives a mail system name with A value in the Other Mailbox syntax gives a mail system name with
the name of a mailbox in the system. The following string states the name of a mailbox in the system. The following string states
the OID assigned to this syntax: the OID assigned to this syntax:
( 1.3.6.1.4.1.1466.115.121.1.39 DESC 'Other Mailbox' ) ( 1.3.6.1.4.1.1466.115.121.1.39 DESC 'Other Mailbox' )
Values in this syntax are written according to the following ABNF: Values in this syntax are written according to the following ABNF:
otherMailbox = mailbox-type "$" mailbox otherMailbox = mailbox-type DOLLAR mailbox
mailbox-type = printablestring mailbox-type = printableString
mailbox = <an encoded IA5 String> mailbox = <an encoded IA5 String>
The printablestring production is defined in section 2.1. The printableString production is defined in section 3.11.
In the above, mailbox-type represents the type of mail system in In the above, mailbox-type represents the type of mail system in
which the mailbox resides, for example "MCIMail"; and mailbox is which the mailbox resides, for example "MCIMail"; and mailbox is
the actual mailbox in the mail system defined by mailbox-type. the actual mailbox in the mail system defined by mailbox-type.
The representation of a string in this syntax is the string value
itself.
3.29 Postal Address 3.29 Postal Address
A value in the Postal Address syntax is a series of strings which A value in the Postal Address syntax is a series of strings which
form an address in a physical mail system. The following string form an address in a physical mail system. The following string
states the OID assigned to this syntax: states the OID assigned to this syntax:
( 1.3.6.1.4.1.1466.115.121.1.41 DESC 'Postal Address' ) ( 1.3.6.1.4.1.1466.115.121.1.41 DESC 'Postal Address' )
Values in this syntax are written according to the following ABNF: Values in this syntax are written according to the following ABNF:
postal-address = dstring *( "$" dstring ) postal-address = dstring *( DOLLAR dstring )
In the above, each dstring component of a postal address value is In the above, each dstring component of a postal address value is
written as a value of type Directory String syntax. Backslashes and written as a value of type Directory String syntax. Backslashes and
dollar characters, if they occur in the component, are quoted as dollar characters, if they occur in the component, are quoted as
described in section 2.1. Many servers limit the postal address to described in [MODELS]. Many servers limit the postal address to
six lines of up to thirty characters. six lines of up to thirty characters.
The production for dstring is defined in section 2.1.
Example: Example:
1234 Main St.$Anytown, CA 12345$USA 1234 Main St.$Anytown, CA 12345$USA
\241,000,000 Sweepstakes$PO Box 1000000$Anytown, CA 12345$USA \241,000,000 Sweepstakes$PO Box 1000000$Anytown, CA 12345$USA
3.30 Presentation Address 3.30 Presentation Address
A value in the Presentation Address syntax is an OSI Application A value in the Presentation Address syntax is an OSI Application
Layer address of a remote application. Logically, a presentation Layer address of a remote application. Logically, a presentation
address consists of: address consists of:
skipping to change at page 31, line 40 skipping to change at page 19, line 32
Values in this syntax are written according to the following ABNF: Values in this syntax are written according to the following ABNF:
presentation-address = [[[ psel "/" ] ssel "/" ] tsel "/" ] presentation-address = [[[ psel "/" ] ssel "/" ] tsel "/" ]
network-address-list network-address-list
psel = selector psel = selector
ssel = selector ssel = selector
tsel = selector tsel = selector
network-address-list = network-address "_" network-address-list / network-address-list = network-address USCORE
network-address network-address-list / network-address
network-address = "NS" "+" dothexstring network-address = "NS" PLUS dothexstring
/ afi "+" idi [ "+" dsp ] / afi PLUS idi [ PLUS dsp ]
/ idp "+" hexstring / idp PLUS hexstring
The first (NS) alternative is the Concrete Binary Representation. The first (NS) alternative is the Concrete Binary Representation.
It is the compact encoding. It is the compact encoding.
The afi alternative is a user-oriented representation of a network The afi alternative is a user-oriented representation of a network
address. address.
The idp alternative is a form of network-address included for The idp alternative is a form of network-address included for
compatibility with ISO 8348 [NSAP]. compatibility with ISO 8348 [ISO8348].
selector = """ otherstring """ selector = DQUOTE otherstring DQUOTE
/ "#" numericstring / SHARP numericstring
/ "'" hexstring "'H" / SQUOTE hexstring "'H"
/ "" / ""
The otherstring alternative for the selector is IA5 characters. The otherstring alternative for the selector is IA5 characters.
The "" alternative for the selector expresses the case where the The "" alternative for the selector expresses the case where the
selector is present, but Empty. selector is present, but Empty.
idp = numericstring idp = numericstring
dsp = "d" numericstring dsp = "d" numericstring
/ "x" dothexstring / "x" dothexstring
/ "l" otherstring / "l" otherstring
/ "RFC-1006" "+" prefix "+" ip [ "+" port [ "+" tset ]] / "RFC-1006" PLUS prefix PLUS ip [ PLUS port [ PLUS tset ]]
/ "X.25(80)" "+" prefix "+" dte [ "+" cudf-or-pid "+" / "X.25(80)" PLUS prefix PLUS dte [ PLUS cudf-or-pid PLUS
hexstring ] hexstring ]
/ "ECMA-117-Binary" "+" hexstring "+" hexstring "+" hexstring / "ECMA-117-Binary" PLUS hexstring PLUS hexstring PLUS
/ "ECMA-117-Decimal" "+" numericstring "+" hexstring / "ECMA-117-Decimal" PLUS numericstring PLUS
numericstring "+" numericstring numericstring PLUS numericstring
The d alternative is the Abstract Decimal form of the Domain The d alternative is the Abstract Decimal form of the Domain
Specific Part (dsp) in a network address. Specific Part (dsp) in a network address.
The x alternative is the Abstract Binary form of the dsp in a The x alternative is the Abstract Binary form of the dsp in a
network address. network address.
The l alternative is IA5 characters and is only meaningful locally. The l alternative is IA5 characters and is only meaningful locally.
idi = numericstring idi = numericstring
skipping to change at page 32, line 53 skipping to change at page 20, line 40
domain (e.g., twg.com) domain (e.g., twg.com)
port = numericstring port = numericstring
tset = numericstring tset = numericstring
dte = numericstring dte = numericstring
cudf-or-pid = "CUDF" / "PID" cudf-or-pid = "CUDF" / "PID"
other = k / "+" / DOT other = keychar / PLUS / DOT
domainchar = k / DOT domainchar = keychar / DOT
hexoctet = hex-digit hex-digit
hexoctet = HEX HEX
decimal-octet = 1*3DIGIT decimal-octet = 1*3DIGIT
otherstring = other otherstring / other otherstring = other otherstring / other
domainstring = domainchar otherstring / domainchar domainstring = domainchar otherstring / domainchar
hexstring = hexoctet hexstring / hexoctet hexstring = hexoctet hexstring / hexoctet
dotstring = decimaloctet DOT dotstring / dotstring = decimaloctet DOT dotstring /
decimaloctet DOT decimaloctet decimaloctet DOT decimaloctet
dothexstring = dotstring / hexstring dothexstring = dotstring / hexstring
3.31 Printable String 3.31 Printable String
A value in the Printable String syntax is a series of alphabetic, A value in the Printable String syntax is a series of alphabetic,
numeric, and (limited) punctuation characters as specified in the numeric, and (limited) punctuation characters as specified in the
PrintableString data type from ASN.1 [ASN1] and in production p of PrintableString data type from ASN.1 [X.680] and in production p of
section 2.1. Values in this syntax are expressed as the string section 3.11. Values in this syntax are expressed as the string
itself. The following string states the OID assigned to this syntax: itself. The following string states the OID assigned to this syntax:
( 1.3.6.1.4.1.1466.115.121.1.44 DESC 'Printable String' ) ( 1.3.6.1.4.1.1466.115.121.1.44 DESC 'Printable String' )
Example: This is a PrintableString. Example: This is a PrintableString.
3.32 Substring Assertion 3.32 Substring Assertion
The Substring Assertion syntax is used in rules which can be used in The Substring Assertion syntax is used in rules which can be used in
substrings and extensible matching rules. When using a substrings substrings and extensible matching rules. When using a substrings
skipping to change at page 33, line 53 skipping to change at page 21, line 39
matchValue of the MatchingRuleAssertion: matchValue of the MatchingRuleAssertion:
substring = [initial] any [final] substring = [initial] any [final]
initial = value initial = value
any = "*" *(value "*") any = "*" *(value "*")
final = value final = value
The <value> production is a UTF-8 [UTF-8] string. If a backslash or The <value> production is a UTF-8 [ISO10646] string. If a backslash or
asterix character is present in a production of <value>, it is asterix character is present in a production of <value>, it is
quoted as described in section 2.1. quoted as described in [MODELS].
3.33 Telephone Number 3.33 Telephone Number
A value in the telephone number syntax is the series of characters A value in the telephone number syntax is the series of characters
that express a number (address) assigned to a telephone system that express a number (address) assigned to a telephone system
subscriber. The following string states the OID assigned to this subscriber. The following string states the OID assigned to this
syntax: syntax:
( 1.3.6.1.4.1.1466.115.121.1.50 DESC 'Telephone Number' ) ( 1.3.6.1.4.1.1466.115.121.1.50 DESC 'Telephone Number' )
Values in this syntax are written as if they were Printable String Values in this syntax are written as if they were ASN.1 [X.680]
types. Telephone numbers are defined in X.520 [Attr] to comply Printable String types. Telephone numbers are defined in X.520
with the internationally agreed format for expressing international [X.520] to comply with the internationally agreed format for
telephone numbers in Recommendation E.123 [Tel #]. expressing international telephone numbers in Recommendation
E.123 [E.123].
The representation of a string in this syntax is the string value
itself.
Example: +1 512 315 0280 Example: +1 512 315 0280
3.34 Teletex Terminal Identifier 3.34 Teletex Terminal Identifier
A value in this syntax is a string of characters that express the A value in this syntax is a string of characters that express the
identifier value assigned to a teletex service subscriber. The identifier value assigned to a teletex service subscriber. The
following string states the OID assigned to this syntax: following string states the OID assigned to this syntax:
( 1.3.6.1.4.1.1466.115.121.1.51 DESC 'Teletex Terminal ( 1.3.6.1.4.1.1466.115.121.1.51 DESC 'Teletex Terminal
skipping to change at page 34, line 47 skipping to change at page 22, line 36
ttx-key = "graphic" / "control" / "misc" / "page" / "private" ttx-key = "graphic" / "control" / "misc" / "page" / "private"
ttx-value = octetstring ttx-value = octetstring
In the above, the first printablestring is the encoding of the first In the above, the first printablestring is the encoding of the first
portion of the teletex terminal identifier to be encoded, and the portion of the teletex terminal identifier to be encoded, and the
subsequent 0 or more octetstrings are subsequent portions of the subsequent 0 or more octetstrings are subsequent portions of the
teletex terminal identifier. teletex terminal identifier.
The productions for printablestring and octetstring are defined in The representation of a string in this syntax is the string value
section 2.1. itself.
3.35 Telex Number 3.35 Telex Number
A value in the Telex Number syntax is the number assigned to a telex A value in the Telex Number syntax is the number assigned to a telex
system subscriber with the country and answerback values indicated. system subscriber with the country and answerback values indicated.
The following string states the OID assigned to this syntax: The following string states the OID assigned to this syntax:
( 1.3.6.1.4.1.1466.115.121.1.52 DESC 'Telex Number' ) ( 1.3.6.1.4.1.1466.115.121.1.52 DESC 'Telex Number' )
skipping to change at page 35, line 18 skipping to change at page 23, line 4
Values in this syntax are written according to the following ABNF: Values in this syntax are written according to the following ABNF:
telex-number = actual-number "$" country "$" answerback telex-number = actual-number "$" country "$" answerback
actual-number = printablestring actual-number = printablestring
country = printablestring country = printablestring
answerback = printablestring answerback = printablestring
In the above, actual-number is the syntactic representation of the In the above, actual-number is the syntactic representation of the
number portion of the TELEX number being written, country is the number portion of the TELEX number being written, country is the
TELEX country code, and answerback is the answerback code of a TELEX TELEX country code, and answerback is the answerback code of a TELEX
terminal. terminal.
The production for printablestring is defined in section 2.1. The representation of a string in this syntax is the string value
itself.
3.36 UTC Time 3.36 UTC Time
A value in the UTC Time syntax is a date and time indicating accuracy A value in the UTC Time syntax is a date and time indicating accuracy
to minute or second. The year is given as a two-digit number. The to minute or second. The year is given as a two-digit number. The
following string states the OID assigned to this syntax: following string states the OID assigned to this syntax:
( 1.3.6.1.4.1.1466.115.121.1.53 DESC 'UTC Time' ) ( 1.3.6.1.4.1.1466.115.121.1.53 DESC 'UTC Time' )
Values in this syntax are written as if they were printable strings, Values in this syntax are written as if they were printable strings,
formulated as specified for the UTCTime data type in ASN.1 [ASN1]. formulated as specified for the UTCTime data type in ASN.1 [X.680].
It is strongly suggested that GMT time be used. It is strongly suggested that GMT time be used.
Note: This syntax is deprecated in favor of the Generalized Time Note: This syntax is deprecated in favor of the Generalized Time
syntax. syntax.
4. Matching Rules 4. Matching Rules
When performing the caseExactMatch, caseIgnoreMatch, When performing the caseExactMatch, caseIgnoreMatch,
caseIgnoreListMatch, telephoneNumberMatch, caseExactIA5Match and caseIgnoreListMatch, telephoneNumberMatch, caseExactIA5Match and
caseIgnoreIA5Match, multiple adjoining whitespace characters are caseIgnoreIA5Match, multiple adjoining whitespace characters are
skipping to change at page 36, line 46 skipping to change at page 24, line 18
IA5 String syntax: IA5 String syntax:
( 1.3.6.1.4.1.1466.109.114.2 NAME 'caseIgnoreIA5Match' ( 1.3.6.1.4.1.1466.109.114.2 NAME 'caseIgnoreIA5Match'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) ; IA5 String SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) ; IA5 String
This matching rule is used to test equality. This matching rule is used to test equality.
4.4 caseIgnoreListMatch 4.4 caseIgnoreListMatch
The ABNF below associates the caseIgnoreListMatch rule with the The ABNF below associates the caseIgnoreListMatch rule with the
Postal Address syntax. The X.520 [Attr] syntax for this matching Postal Address syntax. The X.520 [X.520] syntax for this matching
rule is a SEQUENCE Of DirectoryString. Since the Postal Address rule is a SEQUENCE Of DirectoryString. Since the Postal Address
syntax is such a sequence, it is used in defining the matching rule syntax is such a sequence, it is used in defining the matching rule
for LDAP, although the matching rule can be used with any SEQUENCE for LDAP, although the matching rule can be used with any SEQUENCE
OF DirectoryString syntax/assertion. OF DirectoryString syntax/assertion.
( 2.5.13.11 NAME 'caseIgnoreListMatch' ( 2.5.13.11 NAME 'caseIgnoreListMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 ) ; Postal Address SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 ) ; Postal Address
This matching rule is used to test equality. This matching rule is used to test equality.
skipping to change at page 39, line 54 skipping to change at page 27, line 28
rules to be used with all attribute types known to the server, when rules to be used with all attribute types known to the server, when
the assertion syntax of the matching rule is the same as the value the assertion syntax of the matching rule is the same as the value
syntax of the attribute. syntax of the attribute.
The Octet String Match rule compares for equality an asserted octet The Octet String Match rule compares for equality an asserted octet
string with an attribute value of type OCTET STRING. string with an attribute value of type OCTET STRING.
The strings match if they are the same length and corresponding The strings match if they are the same length and corresponding
octets are identical. octets are identical.
The following ABNF associates the octetStringMatch rule with
the OCTET STRING syntax:
( 2.5.13.17 NAME 'octetStringMatch' ( 2.5.13.17 NAME 'octetStringMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 ) SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )
4.18 presentationAddressMatch 4.18 presentationAddressMatch
The following ABNF associates the presentationAddressMatch rule with The following ABNF associates the presentationAddressMatch rule with
the Presentation Address syntax: the Presentation Address syntax:
( 2.5.13.22 NAME 'presentationAddressMatch' ( 2.5.13.22 NAME 'presentationAddressMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.43 ) ; Presentation Address SYNTAX 1.3.6.1.4.1.1466.115.121.1.43 ) ; Presentation Address
skipping to change at page 41, line 5 skipping to change at page 28, line 35
4.22 uniqueMemberMatch 4.22 uniqueMemberMatch
The following ABNF associates the uniqueMemberMatch rule with the The following ABNF associates the uniqueMemberMatch rule with the
Name and Optional UID syntax: Name and Optional UID syntax:
( 2.5.13.23 NAME 'uniqueMemberMatch' ( 2.5.13.23 NAME 'uniqueMemberMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.34 ) ; Name And Optional UID SYNTAX 1.3.6.1.4.1.1466.115.121.1.34 ) ; Name And Optional UID
This matching rule is used to test equality. This matching rule is used to test equality.
5. Attribute Types 5. Security Considerations
5.1 altServer
The values of this attribute are URLs of other servers which could be
contacted when this server becomes unavailable. If the server does
not know of any other servers which could be used this attribute will
be absent. Clients can cache this information in case their
preferred LDAP server later becomes unavailable.
( 1.3.6.1.4.1.1466.101.120.6 NAME 'altServer'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
USAGE dSAOperation )
The SYNTAX oid indicates the IA5 String syntax.
This attribute is only present in the root DSE (see [Prot]
and [Models]).
5.2 attributeTypes
The attributeTypes attribute holds descriptions of the attributes in
a schema. This attribute is typically located in the subschema
entry.
( 2.5.21.5 NAME 'attributeTypes'
EQUALITY objectIdentifierFirstComponentMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.3
USAGE directoryOperation )
The SYNTAX oid indicates the Attribute Type Description syntax.
5.3 createTimestamp
( 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.
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 )
The SYNTAX oid indicates the DN syntax.
5.5 ditContentRules
( 2.5.21.2 NAME 'dITContentRules'
EQUALITY objectIdentifierFirstComponentMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.16
USAGE directoryOperation )
The SYNTAX oid indicates the DIT Content Rule Description syntax.
This attribute is located in 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 )
The SYNTAX oid indicates the DIT Structure Rule Description syntax.
This attribute is located in the subschema entry.
5.7 ldapSyntaxes
This attribute is typically located in the subschema entry.
This attribute identifies the syntaxes implemented, with each 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 the LDAP Syntax Description syntax.
5.8 matchingRules
This attribute is typically located in the subschema entry.
( 2.5.21.4 NAME 'matchingRules'
EQUALITY objectIdentifierFirstComponentMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.31
USAGE directoryOperation )
The SYNTAX oid indicates the Matching Rule Description syntax.
5.9 matchingRuleUse
This attribute is typically located in the subschema entry.
( 2.5.21.8 NAME 'matchingRuleUse'
EQUALITY objectIdentifierFirstComponentMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.31
USAGE directoryOperation )
The SYNTAX oid indicates 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 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 )
The SYNTAX oid indicates the Generalized Time syntax.
5.12 nameForms
( 2.5.21.7 NAME 'nameForms'
EQUALITY objectIdentifierFirstComponentMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.35
USAGE directoryOperation )
The SYNTAX oid indicates the Name Form Description syntax.
This attribute is located in the subschema entry.
5.13 namingContexts
The values of this attribute correspond to naming contexts which
this server masters or shadows. If the server does not master any
information (e.g. it is an LDAP gateway to a public X.500 directory)
this attribute will be absent. If the server believes it contains
the entire directory, the attribute will have a single value, and
that value will be the empty string (indicating the null DN of the
root). This attribute will allow a client to choose suitable base
objects for searching when it has contacted a server.
( 1.3.6.1.4.1.1466.101.120.5 NAME 'namingContexts'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
USAGE dSAOperation )
The SYNTAX oid indicates the DN syntax.
This attribute is only present in the root DSE (see [Prot]
and [Models]).
5.14 objectClasses
This attribute is typically located in the subschema entry.
( 2.5.21.6 NAME 'objectClasses'
EQUALITY objectIdentifierFirstComponentMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.37
USAGE directoryOperation )
The SYNTAX oid indicates the Object Class Description syntax.
5.15 subschemaSubentry
The value of this attribute is the name of a subschema entry (or
subentry) where the server makes available attributes specifying the
schema controlling 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 the DN syntax.
5.16 supportedControl
The values of this attribute are the OBJECT IDENTIFIERs identifying
controls which the server supports. If the server does not support
any controls, this attribute will be absent.
( 1.3.6.1.4.1.1466.101.120.13 NAME 'supportedControl'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
USAGE dSAOperation )
The SYNTAX oid indicates the OID syntax.
This attribute is only present in the root DSE (see [Prot]
and [Models]).
5.17 supportedExtension
The values of this attribute are OBJECT IDENTIFIERs identifying the
supported extended operations which the server supports.
If the server does not support any extensions this attribute will be
absent.
( 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 the OID syntax.
This attribute is only present in the root DSE (see [Prot]
and [Models]).
5.18 supportedLDAPVersion
The values of this attribute are the versions of the LDAP protocol
which the server implements.
( 1.3.6.1.4.1.1466.101.120.15 NAME 'supportedLDAPVersion'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
USAGE dSAOperation )
The SYNTAX oid indicates the INTEGER syntax.
This attribute is only present in the root DSE (see [Prot]
and [Models]).
5.19 supportedSASLMechanisms
The values of this attribute are the names of supported SASL
mechanisms which the server supports. If the server does not support
any mechanisms this attribute will be absent.
( 1.3.6.1.4.1.1466.101.120.14 NAME 'supportedSASLMechanisms'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
USAGE dSAOperation )
The SYNTAX oid indicates the Directory String syntax.
This attribute is only present in the root DSE (see [Prot]
and [Models]).
6. Object Classes
6.1 Extensible Object Class
The extensibleObject object class, if present in an entry, permits
that entry to hold any attribute. The "MAY" attribute list
of this class is implicitly the set of all attributes.
( 1.3.6.1.4.1.1466.101.120.111 NAME 'extensibleObject'
SUP top
AUXILIARY )
; MAY all attributes is implied
The mandatory attributes of the other object classes of this entry
are still required to be present.
Note that not all servers will implement this object class, and those
which do not will reject requests to add entries which contain this
object class, or modify an entry to add this object class.
Note that, if the server implements the extensibleObject class but an
attribute is not recognized, this is the same case as for any other
object class.
6.2 subschema
This object class contains a description of the schema that is
applied in the server and is used in the subschema entry.
( 2.5.20.1 NAME 'subschema'
AUXILIARY
MAY ( dITStructureRules $
nameForms $
ditContentRules $
objectClasses $
attributeTypes $
matchingRules $
matchingRuleUse ) )
The ldapSyntaxes operational attribute can also be present in
subschema entries.
7. Security Considerations
7.1 Disclosure 5.1 Disclosure
Attributes of directory entries are used to provide descriptive Attributes of directory entries are used to provide descriptive
information about the real-world objects they represent, which can information about the real-world objects they represent, which can
be people, organizations or devices. Most countries have privacy be people, organizations or devices. Most countries have privacy
laws regarding the publication of information about people. laws regarding the publication of information about people.
7.2 Security Information Syntaxes 5.2 Security Information Syntaxes
Several X.500 attributes, such as, the userCertificate attribute, Several X.500 attributes, such as, the userCertificate attribute,
are used to include key-based security information in directory are used to include key-based security information in directory
entries. The attribute syntaxes for these attributes are: entries. The attribute syntaxes for these attributes are:
Certificate Certificate
CertificateList CertificateList
CertificatePair CertificatePair
SupportedAlgorithm SupportedAlgorithm
These syntaxes are specified for LDAP by the PKIX Working Group, and These syntaxes are specified for LDAP by the PKIX Working Group, and
so, are not included in this document. so, are not included in this document.
The ABNF specifications of "User Certificate", "Authority Revocation The ABNF specifications of "User Certificate", "Authority Revocation
List", and "Certificate Pair" in RFC 1778 [Syn String] are List", and "Certificate Pair" in RFC 1778 [RFC1778] are not to
not to be used. be used.
7.3 Use of Attribute Values in Security Applications
The transformations of an AttributeValue value from its X.501 form
to an LDAP string representation are not always reversible back to
the same BER or DER form.
For example, a distinguished name consisting of one RDN with one AVA,
in which the type is commonName and the value is of the
TeletexString choice with the letters 'Sam' would be represented in
LDAP as the string cn=Sam. Another distinguished name in which the
value is still 'Sam' but of the PrintableString choice would have the
same representation cn=Sam.
Applications which require the reconstruction of the DER form of a
value SHOULD NOT use the string LDAP native encoding when converting
a value to LDAP format. Instead the ;binary transfer option [Prot]
SHOULD be used.
7.4 Securing the Directory 5.3 Securing the Directory
In order to protect the directory and its contents, strong In order to protect the directory and its contents, strong
authentication MUST have been used to identify the Client when an authentication MUST have been used to identify the Client when an
update operation is requested. update operation is requested.
8. Acknowledgements 6. Acknowledgements
This document is an update of RFC 2252 by M. Wahl, A. Coulbeck, This document is an update of RFC 2252 by M. Wahl, A. Coulbeck,
T. Howes, and S. Kille. RFC 2252 was a product of the IETF ASID T. Howes, and S. Kille. RFC 2252 was a product of the IETF ASID
Working Group. Working Group.
This document is based upon input of the IETF LDAPBIS 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 The authors wish to thank J. Sermersheim and K. Zeilenga for their
significant contribution to this update. significant contribution to this update.
9. Authors' Addresses 7. Authors' Addresses
Kathy Dally Kathy Dally
The MITRE Corp. The MITRE Corp.
7515 Colshire Dr., ms-W650 7515 Colshire Dr., ms-W650
McLean VA 22102 McLean VA 22102
USA USA
Phone: +1 703 883 6058 Phone: +1 703 883 6058
Fax: +1 703 883 7142 Fax: +1 703 883 7142
Email: kdally@mitre.org Email: kdally@mitre.org
skipping to change at page 48, line 37 skipping to change at page 30, line 5
Steven Legg Steven Legg
Adacel Technologies Ltd. Adacel Technologies Ltd.
405-409 Ferntree Gully Road 405-409 Ferntree Gully Road
Mount Waverley, Victoria 3149 Mount Waverley, Victoria 3149
AUSTRALIA AUSTRALIA
Phone: +61 3 9451 2107 Phone: +61 3 9451 2107
Fax: +61 3 9541 2121 Fax: +61 3 9541 2121
EMail: steven.legg@adacel.com.au EMail: steven.legg@adacel.com.au
10 References 8. References
10.1 Normative 8.1 Normative
[ABNF] Crocker, D., Overell, P., "Augmented BNF for Syntax [ABNF] Crocker, D., Overell, P., "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997 Specifications: ABNF", RFC 2234, November 1997
[ASN1] Information Technology - Abstract Syntax Notation One [E.123] Notation for national and international telephone numbers,
(ASN.1): Specification of Basic Notation, ITU-T Recommendation ITU-T Recommendation E.123, 1988.
X.680, 1994
[Attr] The Directory: Selected Attribute Types. ITU-T Recommendation
X.520, 1993.
[Codes] ISO 3166, "Codes for the representation of names of countries".
[DN String] draft-ietf-ldapbis-dn-xx, replacement for Wahl, M., Kille, S.,
and T. Howes, "Lightweight Directory Access Protocol (v3):
UTF-8 String Representation of Distinguished Names", RFC 2253,
December 1997.
[Fax] Standardization of Group 3 facsimile apparatus for document
transmission - Terminal Equipment and Protocols for Telematic
Services, ITU-T Recommendation T.4, 1993
[IA5] International Reference Alphabet (IRA) (Formerly International [IA5] International Reference Alphabet (IRA) (Formerly International
Alphabet No. 5 or IA5) Information Technology - 7-Bit Coded Alphabet No. 5 or IA5) Information Technology - 7-Bit Coded
Character Set for Information Interchange, ITU-T Recommendation Character Set for Information Interchange, ITU-T Recommendation
T.50, 1992 T.50, 1992
[ISO3166] ISO 3166, "Codes for the representation of names
of countries".
[ISO10646] Universal Multiple-Octet Coded Character Set (UCS) -
Architecture and Basic Multilingual Plane,
ISO/IEC 10646-1: 1993 (with amendments).
[JPEG] JPEG File Interchange Format (Version 1.02). Eric Hamilton, [JPEG] JPEG File Interchange Format (Version 1.02). Eric Hamilton,
C-Cube Microsystems, Milpitas, CA, September 1, 1992. C-Cube Microsystems, Milpitas, CA, September 1, 1992.
[Keywds] Bradner, S., "Key words for use in RFCs to Indicate [LDAPDN] K. Zeilenga (editor), "LDAP: String Representation of
Requirement Levels", RFC 2119, March 1997. Distinguished Names", draft-ietf-ldapbis-dn-xx.txt, (a
work in progress).
[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. [Protocol] J. Sermersheim (editor), "LDAP: The Protocol",
draft-ietf-ldapbis-protocol-xx.txt, a work in progress.
[Prot] draft-ietf-ldapbis-protocol-xx, replacement for Wahl, M., [RFC1327] Hardcastle-Kille, S., "Mapping between X.400(1988)/
Howes, T., and S. Kille, "Lightweight Directory Access Protocol ISO 10021 and RFC 822", RFC 1327, May 1992.
(v3)", RFC 2251, December 1997.
[Tel #] Notation for national and international telephone numbers, [RFC2044] Yergeau, F., "UTF-8, a transformation format of Unicode
ITU-T Recommendation E.123, 1988. and ISO 10646", RFC 2044, October 1996.
[UCS] Universal Multiple-Octet Coded Character Set (UCS) - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Architecture and Basic Multilingual Plane, Requirement Levels", RFC 2119, March 1997.
ISO/IEC 10646-1: 1993 (with amendments).
[User] draft-ietf-ldapbis-user-schema-xx, replacement for Wahl, M., [RFC 2256] draft-ietf-ldapbis-user-schema-xx, replacement for Wahl, M.,
"A Summary of the X.500(96) User Schema for use with LDAPv3", "A Summary of the X.500(96) User Schema for use with LDAPv3",
RFC 2256, December 1997. RFC 2256, December 1997.
[UTF-8] Yergeau, F., "UTF-8, a transformation format of Unicode and [T.4] Standardization of Group 3 facsimile apparatus for document
ISO 10646", RFC 2044, October 1996. transmission - Terminal Equipment and Protocols for Telematic
Services, ITU-T Recommendation T.4, 1993
10.2 Informative References [X.501] The Directory: Models, ITU-T Recommendation X.501, 1993.
[LDAP '95] Yeong, W., Howes, T., Kille, S., "Lightweight Directory [X.520] The Directory: Selected Attribute Types. ITU-T
Access Protocol", RFC 1777, March 1995 Recommendation X.520, 1993.
[NSAP] Information technology -- Open Systems Interconnection -- [X.680] Information Technology - Abstract Syntax Notation One
(ASN.1): Specification of Basic Notation, ITU-T Recommendation
X.680, 1994
8.2 Informative References
[ISO8348] Information technology -- Open Systems Interconnection --
Network Service Definition, ISO/IEC 8348:1996 Network Service Definition, ISO/IEC 8348:1996
[Syn String] Howes, T., Kille, S., Yeong, W., Robbins, C., "The
[RFC1777] Yeong, W., Howes, T., Kille, S., "Lightweight Directory
Access Protocol", RFC 1777, March 1995
[RFC1778] Howes, T., Kille, S., Yeong, W., Robbins, C., "The
String Representation of Standard Attribute Syntaxes", RFC 1778, String Representation of Standard Attribute Syntaxes", RFC 1778,
March 1995. March 1995.
11. Full Copyright Statement [RFC2253] Wahl, M., Kille, S., and T. Howes, "Lightweight Directory
Access Protocol (v3): UTF-8 String Representation of
Distinguished Names", RFC 2253, December 1997.
9. Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved. Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
skipping to change at page 53, line 14 skipping to change at page 34, line 14
Annex C Change Log Annex C Change Log
This annex lists the changes that have been made from RFC 2252 to This annex lists the changes that have been made from RFC 2252 to
this specification. this specification.
This annex is provided for informational purposes only. It is not This annex is provided for informational purposes only. It is not
a normative part of this specification. Items 32 - end are new in a normative part of this specification. Items 32 - end are new in
the -02 version of this document. the -02 version of this document.
-------
-00 changes
1. Removed the IESG Note. 1. Removed the IESG Note.
2. Changed "types" to "syntaxes" in the last sentence of the 2. Changed "types" to "syntaxes" in the last sentence of the
Abstract. Also, added to the last sentence in order to Abstract. Also, added to the last sentence in order to
indicate that syntaxes are not the only schema elements indicate that syntaxes are not the only schema elements
defined in this document. defined in this document.
3. Reorganized the sections so that: 3. Reorganized the sections so that:
* the schema element categories are specified in the * the schema element categories are specified in the
skipping to change at page 53, line 38 skipping to change at page 34, line 41
alphbetical order alphbetical order
4. Added an "Implementation Status" paragraph for each element, 4. Added an "Implementation Status" paragraph for each element,
gathering the conformance statements. gathering the conformance statements.
5. Clarified schema description in the Overview. 5. Clarified schema description in the Overview.
6. Changed the "Common Encoding Aspects" section title to 6. Changed the "Common Encoding Aspects" section title to
"Notation" and made corresponding changes throughout the "Notation" and made corresponding changes throughout the
document. The purpose being to relegate all encoding issues document. The purpose being to relegate all encoding issues
to the Protocol specification [Prot]. to the Protocol specification [Protocol].
7. Added a MUST statement regarding the syntaxes required of 7. Added a MUST statement regarding the syntaxes required of
servers. servers.
8. Expanded the discussion of each of the syntaxes in section 3. 8. Expanded the discussion of each of the syntaxes in section 3.
9. Added examples to some of the syntax descriptions. 9. Added examples to some of the syntax descriptions.
10. Added NAME option to the syntax description ABNF 10. Added NAME option to the syntax description ABNF
in 2.2.4. in 2.2.4.
skipping to change at page 54, line 52 skipping to change at page 36, line 5
21. Made corrections to the ABNF in paragraph 3.12. 21. Made corrections to the ABNF in paragraph 3.12.
22. Added the seven syntax definitions from RFC 2256 and ordered 22. Added the seven syntax definitions from RFC 2256 and ordered
the definitions alphabetically. the definitions alphabetically.
23. Changed the "Bibliography" section title to "References". 23. Changed the "Bibliography" section title to "References".
24. Replaced the X.208 reference with one to X.680(1994), since 24. Replaced the X.208 reference with one to X.680(1994), since
X.680 is the ASN.1 referred to in the X.500(1993)-series. X.680 is the ASN.1 referred to in the X.500(1993)-series.
-------
-01 changes
25. Moved the table listing the syntaxes and their oids from 25. Moved the table listing the syntaxes and their oids from
paragraph 2.2.3 to a new Annex A. paragraph 2.2.3 to a new Annex A.
REMOVED SYNTAXES NOT DEFINED IN THIS I-D FROM THE LIST - 02 REMOVED SYNTAXES NOT DEFINED IN THIS I-D FROM THE LIST - 02
26. Moved the specification of the octetStringMatch matching rule 26. Moved the specification of the octetStringMatch matching rule
from RFC 2256 to section 4 of this document. from RFC 2256 to section 4 of this document.
27. Throughout this I-D, cleaned up whitespace in the ABNF definitions. 27. Throughout this I-D, cleaned up whitespace in the ABNF definitions.
28. In Section 2.1: 28. In Section 2.1:
* Corrected the characters defined in the p rule to match * Corrected the characters defined in the p rule to match
the PrintableString syntax. the PrintableString syntax.
* Deleted the letterstring rule. * Deleted the letterstring rule.
* Modified the utf8 and dstring rules according to a * Modified the utf8 and dstring rules according to a
skipping to change at page 55, line 15 skipping to change at page 36, line 24
from RFC 2256 to section 4 of this document. from RFC 2256 to section 4 of this document.
27. Throughout this I-D, cleaned up whitespace in the ABNF definitions. 27. Throughout this I-D, cleaned up whitespace in the ABNF definitions.
28. In Section 2.1: 28. In Section 2.1:
* Corrected the characters defined in the p rule to match * Corrected the characters defined in the p rule to match
the PrintableString syntax. the PrintableString syntax.
* Deleted the letterstring rule. * Deleted the letterstring rule.
* Modified the utf8 and dstring rules according to a * Modified the utf8 and dstring rules according to a
suggestion from K. Zeilenga. suggestion from K. Zeilenga.
* Deleted ";" from the k rule, which affects the anhstring, * Deleted ";" from the keychar rule, which affects the
keystring, and descr rules. anhstring, keystring, and descr rules.
* Removed the length option from the numericoid rule * Removed the length option from the numericoid rule
29. In section 2.2, deleted the sentence about needing a new OID 29. In section 2.2, deleted the sentence about needing a new OID
when a syntax is modified. when a syntax is modified.
30. In section 2.2, replaced the editor's proposal and subject 30. In section 2.2, replaced the editor's proposal and subject
text with explanation of the native LDAP encoding of text with explanation of the LDAP-specific encoding of
attribute values. attribute values.
31. Removed section 2.2.2 (and renumbered the remainder of 31. Removed section 2.2.2 (and renumbered the remainder of
section 2.2), leaving the description of binary encoding to section 2.2), leaving the description of binary encoding to
the protocol I-D. the protocol I-D.
------- -------
-02 changes
32. Revised specifications to use ABNF [ABNF] instead of BNF 32. Revised specifications to use ABNF [ABNF] instead of BNF
throughout the docment. throughout the document.
33. Removed embedded comments from the ABNF productions 33. Removed embedded comments from the ABNF productions
throughout the document. throughout the document.
34. Removed the Binary syntax because it was not adequately 34. Removed the Binary syntax because it was not adequately
specified, implementations with different interpretations specified, implementations with different interpretations
exist, and it was confused with the ;binary transfer encoding. exist, and it was confused with the ;binary transfer encoding.
35. Removed the syntaxes, which are not defined in this document, 35. Removed the syntaxes, which are not defined in this document,
from the list in Annex A. Consult RFC 2252 for the from the list in Annex A. Consult RFC 2252 for the
skipping to change at page 55, line 49 skipping to change at page 37, line 4
specified, implementations with different interpretations specified, implementations with different interpretations
exist, and it was confused with the ;binary transfer encoding. exist, and it was confused with the ;binary transfer encoding.
35. Removed the syntaxes, which are not defined in this document, 35. Removed the syntaxes, which are not defined in this document,
from the list in Annex A. Consult RFC 2252 for the from the list in Annex A. Consult RFC 2252 for the
assignments made previously for syntaxes that have not been assignments made previously for syntaxes that have not been
defined to date. defined to date.
36. Inserted the specification of the octetstring production, from 36. Inserted the specification of the octetstring production, from
RFC 2234 [ABNF].j RFC 2234 [ABNF].j
37. Cleaned up the references; adopted word instead of number 37. Cleaned up the references; adopted word instead of number
tags; split Section 10 into normative and non-normative tags; split Section 10 into normative and informative
subsections. subsections.
38. Inserted ABNF from RFC 1278 in place of a reference. 38. Inserted ABNF from RFC 1278 in place of a reference.
38. Deleted the certificate-related syntaxes and noted in the 39. Deleted the certificate-related syntaxes and noted in the
Security Considerations (Section 7) that they are covered Security Considerations (Section 7) that they are covered
in PKIX WG documents. in PKIX WG documents.
-------
-03 changes
40. Removed all discussion of transfer options and the binary option.
41. Aligned the text to the [MODELS] document.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/