draft-ietf-ldapbis-syntaxes-00.txt   draft-ietf-ldapbis-syntaxes-01.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 19 December 2001 19 June 2001 Expires 20 May 2002 S. Legg
Obsoletes: RFC 2252 Obsoletes: RFC 2252 ADACEL
20 November 2001
Lightweight Directory Access Protocol (v3): Lightweight Directory Access Protocol (v3):
Attribute Syntax Definitions Attribute Syntax Definitions
<draft-ietf-ldapbis-syntaxes-00> <draft-ietf-ldapbis-syntaxes-01>
[Editor's note: [Editor's note:
This Internet-Draft (I-D) is a modified version of the text of This Internet-Draft (I-D) is a modified version of the text of
RFC 2252, in order to bring it up to date. This action is part of RFC 2252, in order to bring it up to date. This action is part of
the maintenance activity that is needed in order to progress LDAPv3 the maintenance activity that is needed in order to progress LDAPv3
to Draft Standard. The changes are described in Annex B of this to Draft Standard. The changes are described in Annex C of this
document. Open items are listed in Annex A. document. Open items are listed in Annex B.
End of Editor's note] End of Editor's note]
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
skipping to change at page 2, line 23 skipping to change at page 3, line 11
In addition to defining the set of attribute syntaxes which LDAP In addition to defining the set of attribute syntaxes which LDAP
servers should support, this document defines other schema elements servers should support, this document defines other schema elements
(mandatory and optional) that are common to all LDAP servers. (mandatory and optional) that are common to all LDAP servers.
Table of Contents Table of Contents
Status of Memo.........................................................1 Status of Memo.........................................................1
Abstract...............................................................2 Abstract...............................................................2
1. Overview...........................................................5 1. Overview...........................................................6
2. General Issues.....................................................6 2. General Issues.....................................................6
2.1 Notation..........................................................6 2.1 Notation..........................................................6
2.2 Syntaxes..........................................................8 2.2 Syntaxes..........................................................9
2.2.1 Syntaxes Implementation Status..................................9 2.2.1 Syntaxes Implementation Status..................................9
2.2.2 Binary Transfer of Values.......................................9 2.2.2 Syntax Object Identifiers......................................10
2.2.3 Syntax Object Identifiers.......................................9 2.2.3 Syntax Description.............................................10
2.2.4 Syntax Description.............................................11 2.2.4 Example........................................................11
2.2.5 Example........................................................12 2.3 Matching Rules...................................................11
2.3 Matching Rules...................................................12 2.3.1 Matching Rules Implementation Status...........................11
2.3.1 Matching Rules Implementation Status...........................12 2.3.2 Matching Rule Description......................................11
2.3.2 Matching Rule Description......................................12 2.3.3 Example........................................................12
2.3.3 Matching Rule Usage Description................................13 2.4 Attribute Types..................................................12
2.3.4 Example........................................................13 2.4.1 Attribute Types Implementation Status..........................13
2.4 Attribute Types..................................................14 2.4.2 Attribute Types Description....................................13
2.4.1 Attributes Implementation Status...............................14 2.4.3 Example........................................................15
2.4.2 Attribute Description..........................................15 2.5 Object Classes...................................................15
2.4.3 Example........................................................16 2.5.1 Object Classes Implementation Status...........................15
2.5 Object Classes...................................................16
2.5.1 Object Classes Implementation Status...........................16
2.5.2 Object Class Description.......................................16 2.5.2 Object Class Description.......................................16
2.5.3 Example........................................................17 2.5.3 Example........................................................16
3. Syntaxes..........................................................18 3. Syntaxes..........................................................17
3.1 Attribute Type Description.......................................18 3.1 Attribute Type Description.......................................17
3.2 Binary...........................................................18 3.2 Binary...........................................................17
3.3 Bit String.......................................................18 3.3 Bit String.......................................................18
3.4 Boolean..........................................................18 3.4 Boolean..........................................................19
3.5 Certificate......................................................19 3.5 Certificate......................................................19
3.6 Certificate List.................................................19 3.6 Certificate List.................................................19
3.7 Certificate Pair.................................................19 3.7 Certificate Pair.................................................20
3.8 Country String...................................................20 3.8 Country String...................................................20
3.9 Delivery Method..................................................20 3.9 Delivery Method..................................................20
3.10 Directory String.................................................20 3.10 Directory String.................................................21
3.11 DIT Content Rule.................................................21 3.11 DIT Content Rule.................................................21
3.12 DIT Structure Rule Description...................................22 3.12 DIT Structure Rule Description...................................22
3.13 DN...............................................................22 3.13 DN...............................................................23
3.14 Enhanced Guide...................................................23 3.14 Enhanced Guide...................................................23
3.15 Facsimile Telephone Number.......................................23 3.15 Facsimile Telephone Number.......................................24
3.16 Fax..............................................................24 3.16 Fax..............................................................24
3.17 Generalized Time.................................................24 3.17 Generalized Time.................................................25
3.18 Guide............................................................24 3.18 Guide............................................................25
3.19 IA5 String.......................................................25 3.19 IA5 String.......................................................26
3.20 Integer..........................................................25 3.20 Integer..........................................................26
3.21 JPEG.............................................................25 3.21 JPEG.............................................................26
3.22 LDAP Syntax Description..........................................25
3.23 Matching Rule Description........................................26
3.24 Matching Rule Use Description....................................26
3.25 MHS OR Address...................................................26
3.26 Name and Optional UID............................................26
3.27 Name Form Description............................................27
3.28 Numeric String...................................................27
3.29 Object Class Description.........................................28
3.30 Octet String.....................................................28
3.31 OID..............................................................28
3.32 Other Mailbox....................................................28
3.33 Postal Address...................................................29
3.34 Presentation Address.............................................29
3.35 Printable String.................................................30
3.36 Substring Assertion Syntax.......................................30
3.37 Supported Algorithm..............................................30
3.38 Telephone Number.................................................31
3.39 Teletex Terminal Identifier......................................31
3.40 Telex Number.....................................................31
3.41 UTC Time.........................................................32
4. Matching Rules....................................................33 3.22 LDAP Syntax Description..........................................26
4.1 bitStringMatch...................................................33 3.23 Matching Rule Description........................................27
4.2 caseExactIA5Match................................................33 3.24 Matching Rule Use Description....................................27
4.3 caseIgnoreIA5Match...............................................33 3.25 MHS OR Address...................................................28
4.4 caseIgnoreListMatch..............................................33 3.26 Name and Optional UID............................................28
4.5 caseIgnoreMatch..................................................34 3.27 Name Form Description............................................28
4.6 caseIgnoreOrderingMatch..........................................34 3.28 Numeric String...................................................29
4.7 caseIgnoreSubstringsMatch........................................34 3.29 Object Class Description.........................................29
4.8 distinguishedNameMatch...........................................34 3.30 Octet String.....................................................30
4.9 generalizedTimeMatch.............................................34 3.31 OID..............................................................30
4.10 generalizedTimeOrderingMatch.....................................35 3.32 Other Mailbox....................................................30
4.11 integerFirstComponentMatch.......................................35 3.33 Postal Address...................................................31
4.12 integerMatch.....................................................35 3.34 Presentation Address.............................................31
4.13 numericStringMatch...............................................35 3.35 Printable String.................................................31
4.14 numericStringSubstringsMatch.....................................35 3.36 Substring Assertion Syntax.......................................32
4.15 objectIdentifierFirstComponentMatch..............................36 3.37 Supported Algorithm..............................................32
4.16 objectIdentifierMatch............................................36 3.38 Telephone Number.................................................33
3.39 Teletex Terminal Identifier......................................33
3.40 Telex Number.....................................................34
3.41 UTC Time.........................................................34
4.17 presentationAddressMatch.........................................36 4. Matching Rules....................................................35
4.18 protocolInformationMatch.........................................36 4.1 bitStringMatch...................................................35
4.19 telephoneNumberMatch.............................................37 4.2 caseExactIA5Match................................................35
4.20 telephoneNumberSubstringsMatch...................................37 4.3 caseIgnoreIA5Match...............................................35
4.21 uniqueMemberMatch................................................37 4.4 caseIgnoreListMatch..............................................35
4.5 caseIgnoreMatch..................................................36
4.6 caseIgnoreOrderingMatch..........................................36
4.7 caseIgnoreSubstringsMatch........................................36
4.8 distinguishedNameMatch...........................................36
4.9 generalizedTimeMatch.............................................36
4.10 generalizedTimeOrderingMatch.....................................37
4.11 integerFirstComponentMatch.......................................37
4.12 integerMatch.....................................................37
4.13 numericStringMatch...............................................37
4.14 numericStringSubstringsMatch.....................................38
4.15 objectIdentifierFirstComponentMatch..............................38
4.16 objectIdentifierMatch............................................38
4.17 octetStringMatch.................................................38
4.18 presentationAddressMatch.........................................39
4.19 protocolInformationMatch.........................................39
4.20 telephoneNumberMatch.............................................39
4.21 telephoneNumberSubstringsMatch...................................39
4.22 uniqueMemberMatch................................................40
5. Attribute Types...................................................38 5. Attribute Types...................................................40
5.1 altServer........................................................38 5.1 altServer........................................................40
5.2 attributeTypes...................................................38 5.2 attributeTypes...................................................40
5.3 createTimestamp..................................................38 5.3 createTimestamp..................................................40
5.4 creatorsName.....................................................38 5.4 creatorsName.....................................................41
5.5 dITContentRules..................................................38
5.6 dITStructureRules................................................39
5.7 ldapSyntaxes.....................................................39
5.8 matchingRules....................................................39
5.9 matchingRuleUse..................................................39
5.10 modifiersName....................................................40
5.11 modifyTimestamp..................................................40
5.12 nameForms........................................................40
5.13 namingContexts...................................................40
5.14 objectClasses....................................................40
5.15 subschemaSubentry................................................41
5.16 supportedControl.................................................41
5.17 supportedExtension...............................................41
5.18 supportedLDAPVersion.............................................41
5.19 supportedSASLMechanisms..........................................42
6. Object Classes....................................................43 5.5 dITContentRules..................................................41
6.1 Extensible Object Class..........................................43 5.6 dITStructureRules................................................41
6.2 subschema........................................................43 5.7 ldapSyntaxes.....................................................41
5.8 matchingRules....................................................41
5.9 matchingRuleUse..................................................42
5.10 modifiersName....................................................42
5.11 modifyTimestamp..................................................42
5.12 nameForms........................................................42
5.13 namingContexts...................................................42
5.14 objectClasses....................................................43
5.15 subschemaSubentry................................................43
5.16 supportedControl.................................................43
5.17 supportedExtension...............................................44
5.18 supportedLDAPVersion.............................................44
5.19 supportedSASLMechanisms..........................................44
7. Security Considerations...........................................44 6. Object Classes....................................................45
7.1 Disclosure.......................................................44 6.1 Extensible Object Class..........................................45
7.2 Use of Attribute Values in Security Applications.................44 6.2 subschema........................................................45
7.3 Securing the Directory...........................................44
8. Acknowledgements..................................................44 7. Security Considerations...........................................46
7.1 Disclosure.......................................................46
7.2 Use of Attribute Values in Security Applications.................46
7.3 Securing the Directory...........................................46
9. Author's Address..................................................45 8. Acknowledgements..................................................46
10. References........................................................45 9. Author's Address..................................................47
11. Full Copyright Statement..........................................47 10. References........................................................47
Annex A Topics to be Addressed in This Document......................48 11. Full Copyright Statement..........................................48
Annex B Change Log...................................................49 Annex A Object Identifiers for Syntaxes..............................49
Annex B Topics to be Addressed in This Document......................50
Annex C Change Log...................................................51
1. Overview 1. Overview
This document defines the framework for developing schemas for This document defines the framework for developing schemas for
directories accessible via the Lightweight Directory Access Protocol. directories accessible via the Lightweight Directory Access 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.
Section 2 states the general requirements and notations for Therefore, Section 2 states the general requirements and notations
definition of attribute types, object classes, syntaxes and for definition of attribute types, object classes, syntaxes and
matching rules. matching rules.
Section 3 lists syntaxes, section 4 matching rules, section 5 Section 3 lists syntaxes, section 4 matching rules, section 5
attribute types, and section 6 object classes. 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.
2. General Issues 2. General Issues
skipping to change at page 6, line 40 skipping to change at page 7, line 12
"u" / "v" / "w" / "x" / "y" / "z" / "A" / "B" / "C" / "D" / "u" / "v" / "w" / "x" / "y" / "z" / "A" / "B" / "C" / "D" /
"E" / "F" / "G" / "H" / "I" / "J" / "K" / "L" / "M" / "N" / "E" / "F" / "G" / "H" / "I" / "J" / "K" / "L" / "M" / "N" /
"O" / "P" / "Q" / "R" / "S" / "T" / "U" / "V" / "W" / "X" / "O" / "P" / "Q" / "R" / "S" / "T" / "U" / "V" / "W" / "X" /
"Y" / "Z" "Y" / "Z"
d = "0" / "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9" d = "0" / "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9"
hex-digit = d / "a" / "b" / "c" / "d" / "e" / "f" / hex-digit = d / "a" / "b" / "c" / "d" / "e" / "f" /
"A" / "B" / "C" / "D" / "E" / "F" "A" / "B" / "C" / "D" / "E" / "F"
k = a / d / "-" / ";" k = a / d / "-"
p = a / d / """ / "(" / ")" / "+" / "," / "-" / "." / p = a / d / "'" / "(" / ")" / "+" / "," / "-" / "." / "="/
"/" / ":" / "?" / " " "/" / ":" / "?" / " "
letterstring = 1*a
numericstring = 1*d numericstring = 1*d
anhstring = 1*k anhstring = 1*k
keystring = a [ anhstring ] keystring = a [ anhstring ]
printablestring = 1*p printablestring = 1*p
space = 1*" " space = 1*" "
whsp = [ space ] whsp = [ space ]
utf8 = <any sequence of octets formed from the UTF-8 [9] utf8 = <any sequence of octets formed from the UTF-8 [9]
transformation of a character from ISO10646 [10]>
dstring = 1*utf8 transformation of a character from ISO 10646[10]
qdstring = whsp "'" dstring "'" whsp except "'">
qdstringlist = [ qdstring *( qdstring ) ] dstring = 1*( utf8 / "''" ) ; escaped utf8 string, each "'"
qdstrings = qdstring / ( whsp "(" qdstringlist ")" whsp ) ; 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 BNF for the string representation of OBJECT In the following BNF for the string representation of OBJECT
IDENTIFIERs, descr is the syntactic representation of an object IDENTIFIERs, 'descr' is the syntactic representation of an object
descriptor, which consists of letters and digits, starting with a descriptor, which consists of letters, digits, and hyphens starting
letter. An OBJECT IDENTIFIER in the numericoid format should not with a letter. An OBJECT IDENTIFIER in the numericoid format should
have leading zeroes (e.g. "0.9.3" is permitted but "0.09.3" should not have leading zeroes (e.g. "0.9.3" is permitted but "0.09.3"
not be generated). should not be generated).
When 'oid' elements occur in a value, the descr notation option When 'oid' elements occur in a value, the 'descr' notation option
SHOULD be used in preference to the numericoid. An object descriptor SHOULD be used in preference to the 'numericoid'. An object
is more readable than a numeric OBJECT IDENTIFIER, and a descriptor descriptor is more readable than a numeric OBJECT IDENTIFIER, and a
(where assigned and known by the implementation) SHOULD be used in descriptor (where assigned and known by the implementation) SHOULD
preference to numeric oids to the greatest extent possible. Examples be used in preference to numeric oids to the greatest extent
of object descriptors in LDAP are attribute type, object class and possible. Examples of object descriptors in LDAP are attribute
matching rule names. type, object class, and matching rule names.
oid = descr / numericoid oid = descr / numericoid
descr = keystring descr = keystring
numericoid = numericstring *( "." numericstring ) [ "{" len "}" ] numericoid = numericstring *( "." numericstring )
len = numericstring noidlen = numericoid [ "{" len "}" ]
woid = whsp oid whsp len = numericstring
oids = woid / ( "(" oidlist ")" ) ; set of oids of either form oids = oid / ( "(" space oidlist space ")" ) ; set of oids of
; either form
oidlist = woid *( "$" woid ) oidlist = oid *( space "$" space oid )
qdescrs = qdescr / ( whsp "(" qdescrlist ")" whsp ) ; object qdescrs = qdescr / ( "(" whsp qdescrlist whsp ")" ) ; object
; descriptors used as schema element names ; descriptors used as schema element names
qdescrlist = [ qdescr *( qdescr ) ] qdescrlist = [ qdescr *( whsp qdescr ) ]
qdescr = whsp "'" descr "'" whsp qdescr = "'" descr "'"
xstring = "X-" 1*( a / "-" / "_" )
extensions = *( space xstring space qdstrings )
Note that while lines have been folded for readability in the Note that while lines have been folded for readability in the
definitions of schema elements (e.g., objectClassDescription definitions of schema elements, (e.g., objectClassDescription
attribute), the values transferred in protocol would not contain attribute), the values transferred in protocol would not contain
newlines. newlines.
In cases where an arbitrary string, not a Distinguished Name or part 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 of one, is used in a value of an attribute, a backslash quoting
mechanism is used to escape the following separator symbol character mechanism is used to escape the following separator symbol
(such as "'", "$" or "#") if it should occur in that string. The character, (such as "'", "$" or "#") if it should occur in that
backslash is followed by a pair of hexadecimal digits representing string. The backslash is followed by a pair of hexadecimal digits
the next character. A backslash itself in the string which forms representing the next character. A backslash itself in the string
part of a larger syntax is always represented as '\5C' or '\5c'. An which forms part of a larger syntax is always represented as '\5C'
example is given in section ?? postalAddress attribute. 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 Servers are not required to provide the same or any text in the
description part of the subschema values they maintain. description part of the subschema values they maintain.
2.2 Syntaxes 2.2 Syntaxes
This section defines general requirements for LDAPv3 attribute value This section defines general requirements for LDAPv3 attribute value
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. LDAPv3 are expected to conform to these requirements.
Syntaxes are also defined for matching rules whose assertion value Syntaxes are also defined for matching rules whose assertion value
syntax is different from the attribute value syntax. syntax is different from the attribute value syntax.
The syntaxes specified in this document are defined in section 3.
In an LDAP schema, an Object Identifier (OID) is assigned to a In an LDAP schema, an Object Identifier (OID) is assigned to a
syntax definition when the syntax is named. The syntaxes defined syntax definition when the syntax is named.
for LDAP, are listed in paragraph 2.2.3. A syntax definition should
not be changed without having a new OID assigned to it. Syntaxes that are currently in use in this I-D and the user schema
I-D[18] are specified in this document in Section 3. The object
identifiers for these syntaxes are listed in Annex A, also. The
object identifiers for syntaxes not specified in this document are
listed in the IANA _______. [Editor's note: For the time being,
the undocumented syntaxes are listed at the end of Annex A.
End editor's note.]
In X.501 [3] and X.520 [9], the definition of the syntax is part of In X.501 [3] and X.520 [9], the definition of the syntax is part of
the attribute specification and a distinct OID for the syntax is not the attribute specification and a distinct OID for the syntax is not
assigned. As a result, X.501 does not define an attribute for assigned. As a result, X.501 does not define an attribute for
publishing syntaxes explicitly in a subschema entry. publishing syntaxes explicitly in a subschema entry.
[Editor's proposal: In [1] the encoding of the LDAPv3 protocol is specified. The
The following paragraph should be moved to the draft-ietf-ldapbis- protcol encapsulates values of attributes in many places. In this
protocol-xx I-D, because it specifies encoding principles. I-D, the encoding of the values is specified, as part of each syntax
End of Editor's proposal] definition. These value encoding rules are termed "native LDAP
The encoding rules defined for a given attribute syntax must produce encoding". The native LDAP encoding of a value is what is
octet strings. To the greatest extent possible, encoded octet transmitted in the protocol, unless a transfer option has been
strings should be usable in their native encoded form for display invoked for the value. The transfer option mechanism and the Binary
transfer option are defined in [1].
The native LDAP encoding defined for a given attribute syntax must
produce octet-aligned values. To the greatest extent possible, the
native LDAP encoding of a value should be usable for display
purposes. In particular, encoding rules for attribute syntaxes purposes. In particular, encoding rules for attribute syntaxes
defining non-binary values should produce strings that can be defining non-binary values should produce strings that can be
displayed with little or no translation by clients implementing LDAP. displayed with little or no translation by clients implementing
There are a few cases (e.g. audio) however, when it is not sensible LDAP. There are a few cases (e.g. audio) however, when it is not
to produce a printable representation. sensible to produce a human-readable representation.
2.2.1 Syntaxes Implementation Status 2.2.1 Syntaxes Implementation Status
The syntaxes that have been identified for LDAP are listed in
section 2.2.3. The specifications of the syntaxes that are further
defined this document are given in section 3.
Clients and servers need not implement all the syntaxes listed, and Clients and servers need not implement all the syntaxes listed, and
MAY implement other syntaxes. MAY implement other syntaxes.
[Editor's Note: The following statement is a new MUST statement Clients MUST NOT assume that the native LDAP encoding of a value of
that seems to be logical. End of Editor's Note] Servers MUST an unrecognized syntax is a human-readable character string.
implement the syntaxes specified for the attribute types that are
implemented.
Clients MUST NOT assume that an unrecognized syntax is a string
representation.
2.2.2 Binary Transfer of Values
The binary encoding format specified in draft-ietf-ldapbis-
protocol-xx [1] is used,for returning an attribute value, if binary
format is requested by the client or if the attribute syntax is
"binary", i.e., "1.3.6.1.4.1.1466.115.121.1.5". [EDITOR'S NOTE:
The remainder of this paragraph plus the next paragraph should be
moved to the draft-ietf-ldapbis-protocol-xx I-D. END.] The contents
of the LDAP AttributeValue or AssertionValue field is a BER-encoded
instance of the attribute value or a matching rule assertion value
ASN.1 data type as defined for use with X.500. (The first byte
inside the OCTET STRING wrapper is a tag octet. However, the OCTET
STRING is still encoded in primitive form.)
All servers MUST implement this form for both generating attribute
values in search responses, and parsing attribute values in add,
compare, and modify requests, if the attribute type is recognized
and the attribute syntax name is that of Binary. Clients which
request that all attributes be returned from entries MUST be prepared
to receive values in binary (e.g. userCertificate;binary), and SHOULD
NOT simply display binary or unrecognized values to users.
2.2.3 Syntax Object Identifiers 2.2.2 Syntax Object Identifiers
Syntaxes for use with LDAP are named by OBJECT IDENTIFIERs, which Syntaxes for use with LDAPv3 are named by OBJECT IDENTIFIERs, which
are dotted-decimal strings. These are not intended to be displayed are dotted-decimal strings. These are not intended to be displayed
to users. to users.
The following table lists the syntaxes that have been defined for The table in Annex A lists the syntaxes that have been defined for
LDAP, thus far. The H-R column suggests whether a value of that LDAPv3, thus far.
syntax is likely to be a human readable string.
Other documents may define additional syntaxes. However, the Other documents may define additional 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. In most cases, attributes will be defined
with the syntax for directory strings. with the syntax for directory strings.
Value being represented H-R OBJECT IDENTIFIER
=====================================================================
ACI Item N 1.3.6.1.4.1.1466.115.121.1.1
Access Point Y 1.3.6.1.4.1.1466.115.121.1.2
Attribute Type Description Y 1.3.6.1.4.1.1466.115.121.1.3
Audio N 1.3.6.1.4.1.1466.115.121.1.4
Binary N 1.3.6.1.4.1.1466.115.121.1.5
Bit String Y 1.3.6.1.4.1.1466.115.121.1.6
Boolean Y 1.3.6.1.4.1.1466.115.121.1.7
Certificate N 1.3.6.1.4.1.1466.115.121.1.8
Certificate List N 1.3.6.1.4.1.1466.115.121.1.9
Certificate Pair N 1.3.6.1.4.1.1466.115.121.1.10
Country String Y 1.3.6.1.4.1.1466.115.121.1.11
DN Y 1.3.6.1.4.1.1466.115.121.1.12
Data Quality Syntax Y 1.3.6.1.4.1.1466.115.121.1.13
Delivery Method Y 1.3.6.1.4.1.1466.115.121.1.14
Directory String Y 1.3.6.1.4.1.1466.115.121.1.15
DIT Content Rule Description Y 1.3.6.1.4.1.1466.115.121.1.16
DIT Structure Rule Description Y 1.3.6.1.4.1.1466.115.121.1.17
DL Submit Permission Y 1.3.6.1.4.1.1466.115.121.1.18
DSA Quality Syntax Y 1.3.6.1.4.1.1466.115.121.1.19
DSE Type Y 1.3.6.1.4.1.1466.115.121.1.20
Enhanced Guide Y 1.3.6.1.4.1.1466.115.121.1.21
Facsimile Telephone Number Y 1.3.6.1.4.1.1466.115.121.1.22
Fax N 1.3.6.1.4.1.1466.115.121.1.23
Generalized Time Y 1.3.6.1.4.1.1466.115.121.1.24
Guide Y 1.3.6.1.4.1.1466.115.121.1.25
IA5 String Y 1.3.6.1.4.1.1466.115.121.1.26
INTEGER Y 1.3.6.1.4.1.1466.115.121.1.27
JPEG N 1.3.6.1.4.1.1466.115.121.1.28
LDAP Syntax Description Y 1.3.6.1.4.1.1466.115.121.1.54
LDAP Schema Definition Y 1.3.6.1.4.1.1466.115.121.1.56
LDAP Schema Description Y 1.3.6.1.4.1.1466.115.121.1.57
Master And Shadow Access Points Y 1.3.6.1.4.1.1466.115.121.1.29
Matching Rule Description Y 1.3.6.1.4.1.1466.115.121.1.30
Matching Rule Use Description Y 1.3.6.1.4.1.1466.115.121.1.31
Mail Preference Y 1.3.6.1.4.1.1466.115.121.1.32
MHS OR Address Y 1.3.6.1.4.1.1466.115.121.1.33
Modify Rights Y 1.3.6.1.4.1.1466.115.121.1.55
Name And Optional UID Y 1.3.6.1.4.1.1466.115.121.1.34
Name Form Description Y 1.3.6.1.4.1.1466.115.121.1.35
Numeric String Y 1.3.6.1.4.1.1466.115.121.1.36
Object Class Description Y 1.3.6.1.4.1.1466.115.121.1.37
Octet String Y 1.3.6.1.4.1.1466.115.121.1.40
OID Y 1.3.6.1.4.1.1466.115.121.1.38
Other Mailbox Y 1.3.6.1.4.1.1466.115.121.1.39
Postal Address Y 1.3.6.1.4.1.1466.115.121.1.41
Value being represented H-R OBJECT IDENTIFIER
=====================================================================
Protocol Information Y 1.3.6.1.4.1.1466.115.121.1.42
Presentation Address Y 1.3.6.1.4.1.1466.115.121.1.43
Printable String Y 1.3.6.1.4.1.1466.115.121.1.44
Substring Assertion Y 1.3.6.1.4.1.1466.115.121.1.58
Subtree Specification Y 1.3.6.1.4.1.1466.115.121.1.45
Supplier Information Y 1.3.6.1.4.1.1466.115.121.1.46
Supplier Or Consumer Y 1.3.6.1.4.1.1466.115.121.1.47
Supplier And Consumer Y 1.3.6.1.4.1.1466.115.121.1.48
Supported Algorithm N 1.3.6.1.4.1.1466.115.121.1.49
Telephone Number Y 1.3.6.1.4.1.1466.115.121.1.50
Teletex Terminal Identifier Y 1.3.6.1.4.1.1466.115.121.1.51
Telex Number Y 1.3.6.1.4.1.1466.115.121.1.52
UTC Time Y 1.3.6.1.4.1.1466.115.121.1.53
A suggested minimum upper bound on the number of characters in a 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 value with a string-based syntax, or the number of bytes in a value
for all other syntaxes, may be indicated by appending this bound for all other syntaxes, may be indicated by appending this bound
count inside of curly braces following the syntax name's OBJECT count inside of curly braces following the syntax name's OBJECT
IDENTIFIER in an attribute type definition. See the "numericoid" IDENTIFIER in an attribute type definition. See the "numericoid"
production in paragraph 2.1. Such a bound is not part of the syntax 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 name itself. For instance, "1.3.6.4.1.1466.0{64}" suggests that
server implementations should allow a string to be 64 characters server implementations should allow a string to be 64 characters
long, although they may allow longer strings. Note that a single long, although they may allow longer strings. Note that a single
character of the Directory String syntax may be encoded in more than character of the Directory String syntax may be encoded in more than
one byte since UTF-8 is a variable-length encoding. one byte since UTF-8 is a variable-length encoding.
2.2.4 Syntax Description 2.2.3 Syntax Description
The following BNF is used in this document to associate a short The following BNF is used in this document to associate a short
description (e.g., a name) with a syntax OBJECT IDENTIFIER. The description (e.g., a name) with a syntax OBJECT IDENTIFIER. The
productions for whsp, numericoid, qdescrs and qdstring are given in productions for whsp, numericoid, qdescrs and qdstring are given in
paragraph 2.1. Implementors should note that future versions of this paragraph 2.1. Implementors should note that future versions of this
document may expand this definition to include additional terms. document may expand this definition to include additional terms.
Terms whose identifier begins with "X-" are reserved for private Terms whose identifier begins with "X-" are reserved for private
experiments, and MUST be followed by a <qdstrings> token. experiments, and MUST be followed by a <space> and a <qdstrings>
tokens.
SyntaxDescription = "(" whsp SyntaxDescription = "(" whsp
numericoid whsp numericoid
["NAME" qdescrs ] [ space "DESC" space qdstring ]
[ "DESC" qdstring ] extensions
whsp ")" whsp ")"
Note that the SyntaxDescription BNF is also the BNF that defines the Note that the SyntaxDescription BNF is also the BNF that defines the
LDAP Syntax Description syntax. native LDAP encoding of values of the LDAP Syntax Description syntax.
2.2.5 Example 2.2.4 Example
For example, the INTEGER syntax for whole number values could be For example, the syntax descripion of the INTEGER syntax for whole
written as: 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.
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
skipping to change at page 12, line 35 skipping to change at page 11, line 35
...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 should not be changed without having a new matching rule definition should 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.
Servers MAY implement additional matching rules not listed in this Servers MUST publish in the matchingRules attribute, the definitions
document, and if they do so, MUST publish the definitions of the of matching rules referenced by values of the attributeTypes and
matching rules in the matchingRules attribute of their subschema matchingRuleUse attributes in the same subschema entry. Other
entries. If the server supports the extensibleMatch, then the unreferenced matching rules MAY be published in the matchingRules
server MUST publish the relationship between the matching rules and attribute.
attributes using the matchingRuleUse attribute.
Clients MUST NOT assume that servers are capable of transliteration If the server supports the extensibleMatch, then the server MAY use
of Unicode values. the matchingRuleUse attribute to indicate the applicability of
selected matching rules to designated attribute types in an
extensibleMatch.
2.3.2 Matching Rule Description 2.3.2 Matching Rule Description
Matching rule descriptions are written according to the following Matching rule descriptions are written according to the following
BNF. The productions for numericoid, qdescrs, qdstring, oid, and BNF. The productions for numericoid, qdescrs, qdstring, oid, and
whsp are given in paragraph 2.1. Implementors should note that whsp are given in paragraph 2.1. Implementors should note that
future versions of this document may expand this BNF to include future versions of this document may expand this BNF to include
additional terms. Terms whose identifier begins with "X-" are additional terms. Terms whose identifier begins with "X-" are
reserved for private experiments, and MUST be followed by a reserved for private experiments, and MUST be followed by a <space>
<qdstrings> token. and a <qdstrings> tokens.
MatchingRuleDescription = "(" whsp MatchingRuleDescription = "(" whsp
numericoid whsp ; MatchingRule identifier numericoid ; MatchingRule identifier
[ "NAME" qdescrs ] [ space "NAME" space qdescrs ]
[ "DESC" qdstring ] [ space "DESC" space qdstring ]
[ "OBSOLETE" whsp ] [ space "OBSOLETE" ]
"SYNTAX" oid space "SYNTAX" space numericoid
; oid corrected to numericoid
extensions
whsp ")" whsp ")"
Note that the MatchingRuleDescription BNF is also the BNF that Note that the MatchingRuleDescription BNF is also the BNF that
defines the Matching Rule Description syntax. defines the native LDAP encoding of values of the Matching Rule
Description syntax.
2.3.3 Matching Rule Use Description
Matching Rule Use Descriptions list the attributes which are
suitable for use in an extensibleMatch that employs the associated
matching rule. See paragraph xxx of [1]. The following BNF is used
when writing Matching Rule Use Descriptions:
MatchingRuleUseDescription = "(" whsp
numericoid whsp ; MatchingRule identifier
[ "NAME" qdescrs ]
[ "DESC" qdstring ]
[ "OBSOLETE" ]
"APPLIES" oids ; AttributeType identifiers
whsp ")"
The productions for whsp, numericoid, qdescrs, qdstring, and oids
are given in paragraph 2.1. Implementors should note that future
versions of this document may expand this BNF to include additional
terms. Terms whose identifier begins with "X-" are reserved for
private experiments, and MUST be followed by a <qdstrings> token.
Note that the MatchingRuleUseDescription BNF is also the BNF that
defines the Matching Rule Use Description syntax.
2.3.4 Example 2.3.3 Example
For example, in specifying a server which implements a privately- For example, in specifying a server which implements a privately-
defined matching rule for performing sound-alike matches on defined matching rule for performing sound-alike matches on
Directory String-valued attributes, the matching rule could be Directory String-valued attributes, the matching rule could be
written as (1.2.3.4.5 is an example, the OID of an actual matching written as (1.2.3.4.5 is an example, the OID of an actual matching
rule would be different): rule would be different):
matchingRule: ( 1.2.3.4.5 NAME 'soundAlikeMatch' matchingRule: ( 1.2.3.4.5 NAME 'soundAlikeMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
This description could be the one included in the subschema entry in This description could be the one included in the subschema entry in
the server. If this matching rule could be used with the attributes 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 2.5.4.41 and 2.5.4.15, the following could be the use description
present in the subschema entry: present in the subschema entry:
matchingRuleUse: ( 1.2.3.4.5 APPLIES (2.5.4.41 $ 2.5.4.15) ) matchingRuleUse: ( 1.2.3.4.5 APPLIES ( givenName $ surname ) )
A client could then make use of this matching rule by sending a A client could then make use of this matching rule by sending a
search operation in which the filter is of the extensibleMatch search operation in which the filter is of the extensibleMatch
choice, the matchingRule field is "soundAlikeMatch", and the type choice, the matchingRule field is "soundAlikeMatch", and the type
field is "2.5.4.41" or "2.5.4.15". field is "givenName" or "surName".
2.4 Attribute Types 2.4 Attribute Types
Attributes represent the characteristics of the real-world object Attributes represent the characteristics of the real-world object
which an entry represents. The attributes defined in this document which an entry represents. The attributes defined in this document
are given in section 5. are given in section 5.
An OID is assigned to an attribute when the attribute is defined. An OID is assigned to an attribute type when it is defined. An
An attribute definition should not be changed without having a new attribute type definition should not be changed without having a new
OID assigned to it. OID assigned to it.
2.4.1 Attributes Implementation Status 2.4.1 Attribute Types Implementation Status
Servers MUST implement all the attribute types referenced in
section 5.
Servers MAY recognize additional attribute types not listed in this Servers MUST publish in the attributeTypes attribute of the same
document, and if they do so, MUST publish the definitions of the subschema entry, the definitions of attribute types referenced by
types in the attributeTypes attribute of their subschema entries. 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 definitions whose names Schema developers MUST NOT create attribute type definitions whose
conflict with attributes defined for use with LDAP in existing names conflict with attribute types defined for use with LDAP in
standards-track RFCs. existing standards-track RFCs.
All LDAP server implementations MUST recognize the attribute types All LDAP server implementations MUST recognize the attribute types
defined in section 5. defined in section 5.
Servers MUST maintain values of these attributes in accordance with Servers MUST maintain values of these attributes in accordance with
the definitions in X.501(93): createTimestamp, modifyTimestamp, the definitions in X.501(93): createTimestamp, modifyTimestamp,
creatorsName, modifiersName, subschemaSubentry, attributeTypes, creatorsName, modifiersName, subschemaSubentry, attributeTypes,
objectClasses, matchingRules, and matchingRuleUse. objectClasses, matchingRules, and matchingRuleUse.
The createTimestamp and creatorsName attributes SHOULD appear The createTimestamp and creatorsName attributes SHOULD appear
in entries which were created using the Add operation. in entries which were created using the Add operation.
The modifyTimestamp and modifiersName attributes SHOULD appear in The modifyTimestamp and modifiersName attributes SHOULD appear in
entries which have been modified using LDAP update operations. entries which have been modified using LDAP update operations.
The subschemaSubentry attribute SHOULD appear in all entries. The subschemaSubentry attribute SHOULD appear in all entries.
Servers MUST recognize these attribute names, but it is not required Servers MUST recognize these attribute type names, but it is not
that a server provide values for these attributes, when the attribute required that a server provide values for these attributes, when the
corresponds to a feature which the server does not implement: attribute corresponds to a feature which the server does not
namingContexts, altServer, supportedExtension, supportedControl, implement: namingContexts, altServer, supportedExtension,
supportedSASLMechanisms, supportedLDAPVersion, supportedControl, supportedSASLMechanisms, supportedLDAPVersion,
Servers MAY use the ldapSyntaxes attribute to list the syntaxes Servers MAY use the ldapSyntaxes attribute to list the syntaxes
which are implemented. which are implemented.
All servers SHOULD recognize these attribute names, although All servers SHOULD recognize these attribute type names, although
typically only X.500 servers will implement their functionality: typically only X.500 servers will implement their functionality:
dITStructureRules, nameForms, and ditContentRules. dITStructureRules, nameForms, and ditContentRules.
For the status of user schema attribute types see section 5 of [12]. For the status of user schema attribute types see section 3 of [12].
2.4.2 Attribute Description 2.4.2 Attribute Type Description
Attribute types are expressed according to the following BNF. Attribute types are expressed according to the following BNF.
The productions for whsp, numericoid, qdescrs, qdstring, woid, and The productions for whsp, numericoid, qdescrs, qdstring, space,
noidlen are given in paragraph 2.1. Implementors should note that oid, and noidlen are given in paragraph 2.1. Implementors should
future versions of this document may expand this BNF to include note that future versions of this document may expand this BNF to
additional terms. Terms which begin with the characters "X-" are include additional terms. Terms which begin with the characters
reserved for private experiments, and MUST be followed by a "X-" are reserved for private experiments, and MUST be followed by a
<qdstrings> token. <space> and a <qdstrings> tokens.
AttributeTypeDescription = "(" whsp AttributeTypeDescription = "(" whsp
numericoid whsp ; AttributeType identifier numericoid ; AttributeType identifier
[ "NAME" qdescrs ] ; name used in AttributeType [ space "NAME" qdescrs ] ; name used in AttributeType
[ "DESC" qdstring ] ; description [ space "DESC" qdstring ] ; description
[ "OBSOLETE" whsp ] [ space "OBSOLETE" ]
[ "SUP" woid ] ; derived from this other [ space "SUP" space oid ] ; derived from this other
; AttributeType ; AttributeType
[ "EQUALITY" woid ] ; Matching Rule name [ space "EQUALITY" space oid ] ; Matching Rule name
[ "ORDERING" woid ] ; Matching Rule name [ space "ORDERING" space oid ] ; Matching Rule name
[ "SUBSTR" woid ] ; Matching Rule name [ space "SUBSTR" space oid ] ; Matching Rule name
[ "SYNTAX" whsp noidlen whsp ] ; see section 2.3 [ space "SYNTAX" space noidlen ] ; see section 2.3
[ "SINGLE-VALUE" whsp ] ; default multi-valued [ space "SINGLE-VALUE" ] ; default multi-valued
[ "COLLECTIVE" whsp ] ; default not collective [ space "COLLECTIVE" ] ; default not collective
[ "NO-USER-MODIFICATION" whsp ] ; default user modifiable [ space "NO-USER-MODIFICATION" ] ; default user modifiable
[ "USAGE" whsp AttributeUsage ] ; default userApplications [ space "USAGE" space AttributeUsage ]
; default userApplications
extensions
whsp ")" whsp ")"
Servers SHOULD provide at least one of the "SUP" and "SYNTAX" fields Servers SHOULD provide at least one of the "SUP" and "SYNTAX" fields
for each AttributeTypeDescription. for each AttributeTypeDescription.
An AttributeDescription (i.e., the means of referring to an attribute An AttributeDescription (i.e., the means of referring to an attribute
in the protocol [1]) can be used as the value in a NAME part of in the protocol [1]) can be used as the value in a NAME part of
an AttributeTypeDescription. Note that these are case insensitive. an AttributeTypeDescription. Note that these are case insensitive.
[Editor's Note: The preceding paragraph seems to be circular in [Editor's Note: The preceding paragraph seems to be circular in
nature, especially when looking at the AttributeType explanation in nature, especially when looking at the AttributeType explanation in
[1]. What is the fix? End of Editor's Note] [1]. What is the fix? End of Editor's Note]
Note that the AttributeTypeDescription does not list the matching Note that the AttributeTypeDescription does not list the matching
rules which can be used with that attribute type in an rules which can be used with that attribute type in an
extensibleMatch search filter. This is done using the extensibleMatch search filter. This is done using the
matchingRuleUseDescription described in paragraph 2.3.3. matchingRuleUseDescription described in paragraph 3.24.
This document refines the schema description of X.501 [3] by This document refines the schema description of X.501 [3] by
requiring that the syntax field in an AttributeTypeDescription be a requiring that the syntax field in an AttributeTypeDescription be a
string representation of an OBJECT IDENTIFIER for the LDAP string string representation of an OBJECT IDENTIFIER for the LDAP string
syntax definition, and an optional indication of the maximum length syntax definition, and an optional indication of the maximum length
of a value of this attribute (defined in section 2.2.3). of a value of this attribute (defined in section 2.2.2).
Note that the AttributeTypeDescription BNF is also the BNF that Note that the AttributeTypeDescription BNF is also the BNF that
defines the Attribute Type Description syntax. defines the Attribute Type Description syntax.
2.4.3 Example 2.4.3 Example
For example, it would be useful for the directory to know when an For example, it would be useful for the directory to know when an
entry was put into the directory. The following definition is an entry was put into the directory. The following definition is an
Attribute Type Description that could be used to specify such Attribute Type Description that could be used to specify such
an attribute. an attribute.
skipping to change at page 16, line 26 skipping to change at page 15, line 22
( 2.5.18.1 NAME 'createTimestamp' ( 2.5.18.1 NAME 'createTimestamp'
EQUALITY generalizedTimeMatch EQUALITY generalizedTimeMatch
ORDERING generalizedTimeOrderingMatch ORDERING generalizedTimeOrderingMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 ; Generalized Time SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 ; Generalized Time
SINGLE-VALUE SINGLE-VALUE
NO-USER-MODIFICATION NO-USER-MODIFICATION
USAGE directoryOperation ) USAGE directoryOperation )
2.5 Object Classes 2.5 Object Classes
Object classes are the components of an entry. In general, every Object classes are used to categorize the kinds of entries stored in
entry is defined in terms of an abstract class ("top"), at least one the directory and to determine what attributes are contained in
structural object class, and zero or more auxiliary object classes. 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 Whether an object class is abstract, structural, or auxiliary is
defined when the object class OID is assigned. An object class defined when the object class OID is assigned. An object class
definition should not be changed without having a new identifier definition should not be changed without having a new identifier
assigned to it. assigned to it.
2.5.1 Object Classes Implementation Status 2.5.1 Object Classes Implementation Status
Servers SHOULD implement the subschema object class. Servers SHOULD implement the subschema object class.
Implementing the extensibleObject object class is optional. Implementing the extensibleObject object class is optional.
Servers MAY implement additional object classes not listed in this Servers MUST publish in the objectClasses attribute of the same
document, and if they do so, MUST publish the definitions of the subschema entry, the definitions of object classes referenced by
classes in the objectClasses attribute of their subschema entries. 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 Schema developers MUST NOT create object class definitions whose
names conflict with object classes defined for use with LDAP in names conflict with object classes defined for use with LDAP in
existing standards-track RFCs. existing standards-track RFCs.
2.5.2 Object Class Description 2.5.2 Object Class Description
Object class descriptions are written according to the following BNF. Object class descriptions are written according to the following BNF.
The productions for whsp, numericoid, qdescrs, qdstring, and oids The productions for whsp, numericoid, qdescrs, qdstring, space, and
are given in paragraph 2.1. Implementors should note that future oids are given in paragraph 2.1. Implementors should note that
versions of this document may expand this definition to include future versions of this document may expand this definition to
additional terms. Terms whose identifier begins with "X-" are include additional terms. Terms whose identifier begins with
reserved for private experiments, and MUST be followed by a "X-" are reserved for private experiments, and MUST be followed by a
<qdstrings> token. <space> and a <qdstrings> tokens.
ObjectClassDescription = "(" whsp ObjectClassDescription = "(" whsp
numericoid whsp ; ObjectClass identifier numericoid ; ObjectClass identifier
[ "NAME" qdescrs ] [ space "NAME" space qdescrs ]
[ "DESC" qdstring ] [ space "DESC" space qdstring ]
[ "OBSOLETE" whsp ] [ space "OBSOLETE" ]
[ "SUP" oids ] ; Superior ObjectClasses [ space "SUP" space oids ] ; Superior ObjectClasses
[ ( "ABSTRACT" / "STRUCTURAL" / "AUXILIARY" ) whsp ] [ space ( "ABSTRACT" / "STRUCTURAL" / "AUXILIARY" ) ]
; default structural ; default structural
[ "MUST" oids ] ; AttributeTypes [ space "MUST" space oids ] ; AttributeTypes
[ "MAY" oids ] ; AttributeTypes [ space "MAY" space oids ] ; AttributeTypes
extensions
whsp ")" whsp ")"
2.5.3 Example 2.5.3 Example
For example, information about an employee with respect to their For example, information about an employee with respect to their
job is useful in an application which queries the directory. The job is useful in an application which queries the directory. The
same pieces of information are needed in several kinds of entries, same pieces of information are needed in several kinds of entries,
such as manager, part-time, and exempt employees. An auxiliary such as manager, part-time, and exempt employees. An auxiliary
object class could be developed to be included in the structural object class could be developed to be included in the structural
object classes that represent the different kinds of employees. The object classes that represent the different kinds of employees. The
skipping to change at page 18, line 9 skipping to change at page 17, line 9
( 1.3.170.2.65 NAME 'trainingInfo' ( 1.3.170.2.65 NAME 'trainingInfo'
AUXILIARY AUXILIARY
MUST program MUST program
MAY ( lastCourse $ coursesCount ) ) MAY ( lastCourse $ coursesCount ) )
3. Syntaxes 3. Syntaxes
3.1 Attribute Type Description 3.1 Attribute Type Description
A value in this syntax is a character string which expresses the A value in this syntax is a definition of an attribute type
definition of an attribute type according to the BNF given in according to the BNF given in paragraph 2.4.2. The native LDAP
paragraph 2.4.2. This syntax is the form in which schema attribute encoding is the character codes in UTF-8 which correspond to the
types are published in the directory. The following string states characters in the definition.
This syntax is the form in which schema attribute types are
published in the directory. The following syntax description gives
the OID assigned to this syntax: 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 character string specifies the objectClass For example, this is the definition from [18] of the
attribute, whose values are OIDs: businessCategory attribute type:
( 2.5.4.0 NAME 'objectClass' ( 2.5.4.15 NAME 'businessCategory'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 ) EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{128} ) ; DirectoryString
This definition is a value of the Attribute Type Description
syntax. The native LDAP encoding of this value is the definition
itself.
3.2 Binary 3.2 Binary
A value in this syntax is a series of 0's and 1's. The length of [Editor's note: The binary syntax is not used in the core LDAPv3
the series is octet-aligned (i.e., evenly divisible by eight). The I-Ds and could be removed. However, the syntax needs to be
series is expressed as described in paragraph 2.2.2. The following documented because documents external to the core are already using
string states the OID assigned to this syntax: it (e.g., RFC 2798). What should be done?? End editor's note.]
A value in this syntax is a value of any ASN.1 type. The native
LDAP encoding of a value of an attribute represented in this syntax
is the BER encoding of a chosen ASN.1 type. The ASN.1 type is
typically named in the "DESC" field of the attribute type definition.
The following syntax description gives the OID assigned to this
syntax:
( 1.3.6.1.4.1.1466.115.121.1.5 DESC 'Binary' ) ( 1.3.6.1.4.1.1466.115.121.1.5 DESC 'Binary' )
For example, the ASN.1 type "NotarySeal" could be:
The interpretation of a value is part of the definition of the NotarySeal ::= SEQUENCE {
attribute which contains the value. notarizingAuthority DirectoryString{256},
notaryName IA5String,
seal OCTET STRING } -- The digital signature
-- of the notary.
An attribute type (with artificial OID) defined to hold a NotarySeal
value could be:
( 1.2.3.0 NAME 'officialSeal'
DESC 'the NotarySeal of the witnessing official'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.5 ) ; Binary
The encoding of an officialSeal value, where the value of
NotarySeal is:
headTeller NotarySeal ::= { "Chief Judge",
"Kathleen Dally",
'AB 01 4F 09 09 05 FC AF AF CD EA'H }
would be:
'30 2A 13 0B 43 68 69 65 66 20 4A 75 64 67 65 16
0E 4B 61 74 68 6C 65 65 66 20 44 61 6C 6C 79 04
0B AB 01 4F 09 09 05 FC AF AF CD EA'H
In the protocol, this value would be a member of a SET which is
the 'vals' part of the type/vals pair in an attribute list element
of the result of an operation.
3.3 Bit String 3.3 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 [5]. The following string states the OID assigned to ASN.1 [5]. The following syntax description gives the OID assigned
this syntax: 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' )
Values in this syntax are expressed according to the following BNF: The native LDAP encoding of a value is the following BNF:
bitstring = "'" *binary-digit "'B" bitstring = "'" *binary-digit "'B"
binary-digit = "0" / "1" binary-digit = "0" / "1"
Example: '0101111101'B Example: '0101111101'B
3.4 Boolean 3.4 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 [5]. That is, there are exactly two values: one value ASN.1 [5]. 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 string states the OID assigned to this syntax: false. The following syntax description gives the OID assigned to
this syntax:
( 1.3.6.1.4.1.1466.115.121.1.7 DESC 'Boolean' ) ( 1.3.6.1.4.1.1466.115.121.1.7 DESC 'Boolean' )
Values in this syntax are expressed according to the following BNF: The native LDAP encoding of a value is the following BNF:
boolean = "TRUE" / "FALSE" boolean = "TRUE" / "FALSE"
3.5 Certificate 3.5 Certificate
A value in this syntax is the binary string that results from A value in this syntax is the binary string that results from
BER/DER-encoding an X.509 [6] public key certificate. The following BER/DER-encoding an X.509 [6] public key certificate. The following
string states the OID assigned to this syntax: syntax description gives the OID assigned to this syntax:
( 1.3.6.1.4.1.1466.115.121.1.8 DESC 'Certificate' ) ( 1.3.6.1.4.1.1466.115.121.1.8 DESC 'Certificate' )
Due to the changes from X.509(1988) to X.509(1993) and subsequent Due to the changes from X.509(1988) to X.509(1993) and subsequent
changes to the ASN.1 definition to support certificate extensions, changes to the ASN.1 definition to support certificate extensions,
no string representation is defined, and values in this syntax MUST the native LDAP encoding has not been completed for this syntax.
only be transferred using the binary encoding, by requesting or Values in this syntax MUST only be transferred using the Binary
returning the attributes with descriptions "userCertificate;binary" transfer option (see [1]). The BNF for this syntax is being
or "caCertificate;binary". The BNF notation in RFC 1778 [7] for developed in the PKIX WG.
"User Certificate" is not recommended to be used.
The BNF notation in RFC 1778 [7] for "User Certificate" is not
recommended to be used.
3.6 Certificate List 3.6 Certificate List
A value in this syntax is the binary string that results from A value in this syntax is the binary string that results from
BER/DER-encoding an X.509 certificate revocation list. The BER/DER-encoding an X.509 [6] certificate revocation list. The
following string states the OID assigned to this syntax: following syntax description gives the OID assigned to this syntax:
( 1.3.6.1.4.1.1466.115.121.1.9 DESC 'Certificate List' ) ( 1.3.6.1.4.1.1466.115.121.1.9 DESC 'Certificate List' )
Due to the incompatibility of the X.509(1988) and X.509(1993) [6] Due to incompatibility of the X.509(1988) and X.509(1993)[6]
definitions of revocation lists, values in this syntax MUST only be ASN.1, the native LDAP encoding has not been completed for this
transferred using a binary encoding, by requesting or returning the syntax. Values in this syntax MUST only be transferred using the
attributes with descriptions "certificateRevocationList;binary" or Binary transfer option (see [1]). The BNF for this syntax is being
"authorityRevocationList;binary". The BNF notation in RFC 1778 [7] developed in the PKIX WG.
for "Authority Revocation List" is not recommended to be used.
The BNF notation in RFC 1778[7] for "Authority Revocation List" is
not recommended to be used.
3.7 Certificate Pair 3.7 Certificate Pair
A value in this syntax is the binary string that results from A value in this syntax is the binary string that results from
BER/DER-encoding an X.509 [6] public key certificate pair. The BER/DER-encoding an X.509 [6] public key certificate pair. The
following string states the OID assigned to this syntax: following syntax description gives the OID assigned to this syntax:
( 1.3.6.1.4.1.1466.115.121.1.10 DESC 'Certificate Pair' ) ( 1.3.6.1.4.1.1466.115.121.1.10 DESC 'Certificate Pair' )
Due to the Certificate Pair being carried in binary, values in The BNF notation in RFC 1778 [7] for "Certificate Pair" is not
this syntax MUST only be transferred using a binary encoding, by recommended to be used.
requesting or returning the attribute description
"crossCertificatePair;binary". The BNF notation in RFC 1778 [7] for
"Certificate Pair" is not recommended to be used.
3.8 Country String 3.8 Country String
A value in this syntax is two printable string characters A value in this syntax is two ASN.1 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 [8]. The following string states the OID assigned to this ISO 3166[8]. The following syntax description gives the OID
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' )
A value in this syntax is expressed according to the following BNF: The native LDAP encoding of a value is the following BNF:
CountryString = p p CountryString = p p
The production for p is given in paragraph 2.1. The production for p is given in paragraph 2.1.
Example: US Example: US
3.9 Delivery Method 3.9 Delivery Method
A value in the Delivery Method syntax is a character string that A value in this syntax is a set of the ASN.1 enumerated INTEGER
indicates, in preference order, the service(s) by which the user, values that indicates, in preference order, the service(s) by which
represented by the entry, is willing and/or capable of receiving the user, represented by the entry, is willing and/or capable of
messages. The following string states the OID assigned to this receiving messages.
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' )
A value in this syntax is expressed according to the following BNF: The native LDAP encoding of a value is the following BNF:
delivery-value = pdm / ( pdm whsp "$" whsp delivery-value ) delivery-value = pdm / ( whsp pdm space "$" space 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 whsp is given in paragraph 2.1. The production for space is given in paragraph 2.1.
Example: telephone Example: telephone $ videotex
3.10 Directory String 3.10 Directory String
A value in Directory String syntax is a string of Unicode A value in this syntax is a value of one of the TeletexString,
characters. See [ ??? ]. The following string states the OID PrintableString or UniversalString data types from ASN.1[5]. The
assigned to this syntax: following syntax description 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' )
In X.520 [9], a directory string is defined to be in one of The native LDAP encoding of a value is the character string itself.
these forms: PrintableString, TeletexString, UniversalString, or
BMPString. (All of the forms are data types from ASN.1 [5].)
[Editor's note: What should the BNF be for this syntax? End of
Editor's note].
Note: The form of DirectoryString is not indicated in protocol Note: The form of DirectoryString is not indicated in protocol
unless the attribute value is carried in binary. Servers unless the binary option is used. Servers
which convert to DAP MUST choose an appropriate form. Servers which convert to DAP MUST choose an appropriate form. Servers
MUST NOT reject values merely because they contain legal MUST NOT reject values merely because they contain legal
Unicode characters outside of the range of printable ASCII. 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 characters, including characters not presently assigned to
any character set. any character set.
Example: This is a string of DirectoryString containing #!%#@. Example:
This is a string of DirectoryString containing #!%#@.
[Editor's note: the following three paragraphs should be moved
to [1] (paragraph ???). End of Editor's note]
For characters in the PrintableString form, the value is encoded as For characters in the PrintableString form, the value is the native
the string value itself. LDAP encoding is the value itself.
If it is of the TeletexString form, then the characters are If it 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 [11]. in UTF-8 [11].
If it is of the UniversalString or BMPString forms [10], UTF-8 is If it is in the UniversalString or BMPString forms [10], UTF-8 is
used to encode them. the native LDAP encoding.
3.11 DIT Content Rule Description 3.11 DIT Content Rule Description
A value in the DIT Content Rule Description syntax is a string that A value in this syntax is a definition of a DIT content rule
expresses the definition of a schema Content Rule. This syntax is according to the following BNF:
the form in which schema content rules are published in the
directory. The following string states the OID assigned to this
syntax:
( 1.3.6.1.4.1.1466.115.121.1.16 DESC 'DIT Content Rule
Description' )
Values in this syntax are written according to the following BNF.
The productions for whsp, numericoid, qdescrs, qdstring, and oids
are given in paragraph 2.1. Implementors should note that future
versions of this document may expand this BNF to include additional
terms.
DITContentRuleDescription = "(" DITContentRuleDescription = "(" whsp
numericoid ; Structural ObjectClass identifier numericoid ; Structural ObjectClass identifier
[ "NAME" qdescrs ] [ space "NAME" space qdescrs ]
[ "DESC" qdstring ] [ space "DESC" space qdstring ]
[ "OBSOLETE" ] [ space "OBSOLETE" ]
[ "AUX" oids ] ; Auxiliary ObjectClasses [ space "AUX" space oids ] ; Auxiliary ObjectClasses
[ "MUST" oids ] ; AttributeType identifiers [ space "MUST" space oids ] ; AttributeType identifiers
[ "MAY" oids ] ; AttributeType identifiers [ space "MAY" space oids ] ; AttributeType identifiers
[ "NOT" oids ] ; AttributeType identifiers [ space "NOT" space oids ] ; AttributeType identifiers
")" extensions
whsp ")"
3.12 DIT Structure Rule Description The productions for whsp, numericoid, qdescrs, qdstring, space and
oids are given in paragraph 2.1. Implementors should note that future
versions of this document may expand this BNF 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.
A value in the DIT Structure Rule Description syntax is a string that This syntax is the form in which schema content rules are published in the
expresses the definition of a schema Structure Rule. This syntax is directory. The following syntax description gives the OID assigned to
the form in which schema structure rules are published in the this syntax:
directory. The following string states 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.16 DESC 'DIT Content Rule
Description' ) Description' )
Values with this syntax are written according to the following BNF: 3.12 DIT Structure Rule Description
A value in the DIT Structure Rule Description syntax is a definition
of a schema Structure Rule according to the following BNF:
DITStructureRuleDescription = "(" whsp DITStructureRuleDescription = "(" whsp
ruleidentifier whsp ; DITStructureRule identifier ruleidentifier ; DITStructureRule identifier
[ "NAME" qdescrs ] [ space "NAME" space qdescrs ]
[ "DESC" qdstring ] [ space "DESC" space qdstring ]
[ "OBSOLETE" whsp ] [ space "OBSOLETE" ]
"FORM" woid whsp ; NameForm space "FORM" space oid ; NameForm
[ "SUP" ruleidentifiers whsp ] ; superior DITStructureRules [ space "SUP" ruleidentifiers ] ; superior DITStructureRules
")" extensions
whsp ")"
ruleidentifier = numericstring ruleidentifier = numericstring
ruleidentifiers = ruleidentifier | "(" whsp ruleidentifierlist ruleidentifiers = ruleidentifier | "(" whsp ruleidentifierlist
whsp ")" whsp ")"
ruleidentifierlist = [ ruleidentifier *( whsp "$" whsp ruleidentifierlist = [ ruleidentifier *( space ruleidentifier ) ]
ruleidentifier ) ]
The productions for whsp, numericstring, qdescrs, qdstring, and woid [Editor's note: In all the manipulation, using $ as the separator
are given in paragraph 2.1. in ruleidentifierlist has disappeared. I think that a required
space is the separator now. Is this true about space and is there
a lost $ problem? End editor's note]
The productions for whsp, numericstring, qdescrs, qdstring, space,
and oid are given in paragraph 2.1.
The native LDAP encoding is the character codes in UTF-8 which
correspond to the characters in the structure rule definition.
This syntax is the form in which schema structure rules are
published in the directory.
The following syntax description gives the OID assigned to this
syntax:
( 1.3.6.1.4.1.1466.115.121.1.17 DESC 'DIT Structure Rule
Description' )
3.13 DN 3.13 DN
A value in the Distinguished Name syntax is the sequence of A value in the Distinguished Name syntax is a structured set of the
name values that traverse the DIT to the named entry. The following ASN.1 data types that are included in the DirectoryString syntax.
string states the OID assigned to this syntax: The following syntax description gives the OID assigned to this
syntax:
( 1.3.6.1.4.1.1466.115.121.1.12 DESC 'DN' ) ( 1.3.6.1.4.1.1466.115.121.1.12 DESC 'DN' )
Values in the Distinguished Name syntax are expressed by the The native LDAP encoding of a value is defined in [12]. Note that
representation defined in [12]. Note that this representation is not the native LDAP encoding is not reversible to the original BER
reversible to an ASN.1 encoding used in X.500 for Distinguished encoding used in X.500 for Distinguished Names, as the CHOICE of any
Names, as the CHOICE of any DirectoryString element in an RDN is no DirectoryString element in an RDN is not evident in the native LDAP
longer known. encoding.. See the note in section 3.10.
Examples (from [12]): Examples (from [12]):
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.3.6.1.4.1.1466.0=#04024869,O=Test,C=GB 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.14 Enhanced Guide 3.14 Enhanced Guide
skipping to change at page 23, line 14 skipping to change at page 23, line 42
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.3.6.1.4.1.1466.0=#04024869,O=Test,C=GB 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.14 Enhanced Guide 3.14 Enhanced Guide
A value in the Enhanced Guide syntax gives the matching criteria and A value in the Enhanced Guide syntax is the matching criteria and
scope of operation in an Enhanced Filter. The following string scope of operation in an Enhanced Filter.
states the OID assigned to this syntax:
( 1.3.6.1.4.1.1466.115.121.1.21 DESC 'Enhanced Guide' )
Values in this syntax are expressed according to the following BNF: The native LDAP encoding of a value is the following BNF:
EnhancedGuide = woid whsp "#" whsp criteria whsp "#" whsp subset EnhancedGuide = space oid whsp "#" whsp criteria whsp "#" whsp subset
subset = "baseobject" / "oneLevel" / "wholeSubtree" subset = "baseobject" / "oneLevel" / "wholeSubtree"
criteria = criteria-item / criteria-set / ( "!" criteria ) criteria = or-term / "(" or-term ")"
criteria-set = ( [ "(" ] criteria "&" criteria-set [ ")" ] ) / or-term = and-term *( "|" and-term )
( [ "(" ] criteria "|" criteria-set [ ")" ] ) and-term = not-term *( "&" not-term )
criteria-item = [ "(" ] attributetype "$" match-type [ ")" ] not-term = "!" not-term /
attributetype "$" match-type /
"(" or-term ")" /
"?true" / ; an empty "and" in the Criteria ASN.1 type
"?false" ; an empty "or" in the Criteria ASN.1 type
match-type = "EQ" / "SUBSTR" / "GE" / "LE" / "APPROX" match-type = "EQ" / "SUBSTR" / "GE" / "LE" / "APPROX"
This syntax has been added subsequent to RFC 1778 [7]. The following syntax description gives the OID assigned to this syntax:
( 1.3.6.1.4.1.1466.115.121.1.21 DESC 'Enhanced Guide' )
Example: Example:
person#(sn)#oneLevel person#(sn)#oneLevel
3.15 Facsimile Telephone Number 3.15 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
following string states the OID assigned to this syntax: native LDAP encoding of a value is the following BNF:
( 1.3.6.1.4.1.1466.115.121.1.22 DESC 'Facsimile Telephone Number' )
Values in this syntax are expressed according to the following BNF:
fax-number = printablestring [ "$" faxparameters ] fax-number = printablestring [ "$" faxparameters ] ; telephone
$ number, optionally
$ followed by facsimile
$parameters
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 paragraph 2.1. In The production for printablestring is given in paragraph 2.1.
the above, the first printablestring is the telephone number, based
on E.123 [13], and the faxparm tokens represent fax parameters. The telephone number is based on E.123 [13].
A printablestring is the PrintableString data type from ASN.1 [5]. A printablestring is the PrintableString data type from ASN.1 [5].
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.16 Fax 3.16 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 [14] to duplicate an object, such as a Group 3 facsimile process [14] to duplicate an object, such as a
memo. The following string states the OID assigned to this syntax: memo.
The following syntax description gives the OID assigned to this
syntax:
( 1.3.6.1.4.1.1466.115.121.1.23 DESC 'Fax' ) ( 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 [14]. Group 3 Fax images as defined in [14].
3.17 Generalized Time 3.17 Generalized Time
A value in the Generalized Time syntax is a date and time indicating A value in the Generalized Time syntax is a date and time. The year
accuracy to second or tenth of a second. The year is given as a is given as a four-digit number.
four-digit number. The following string states the OID assigned to
this syntax:
( 1.3.6.1.4.1.1466.115.121.1.24 DESC 'Generalized Time' ) The native LDAP encoding is a value of the GeneralizeTime data type
from ASN.1[5]. Note that the time zone must be specified. It is
strongly recommended that GMT time be used.
Values in this syntax are written as if they were printable strings, [NEW Editor's Note: Neither X.208 or X.680 require the time zone.
formulated as specified for the GeneralizeTime data type in ASN.1 I propose that the sentence be deleted. If necessary, individual
[5]. Note that the time zone must be specified. It is strongly attribute types can restrict time values to ones that indicate the
recommended that GMT time be used. time zone, i.e., the GMT time zone or the differential to it from
the local time zone. To date, none of the X.500 and LDAPv3 standard
attributes has made this restriction. End of Editor's Note]
For example: 199412161032Z means 10:32 a.m. Dec. 16, 1994 in the The following syntax description gives the OID assigned to this
Greenwich Mean Time time zone. syntax:
( 1.3.6.1.4.1.1466.115.121.1.24 DESC 'Generalized Time' )
Example:
199412161032Z means 10:32 a.m. Dec. 16, 1994 in the Greenwich
Mean Time time zone.
3.18 Guide 3.18 Guide
A value in the Guide syntax gives the matching criteria in a Filter. A value in the Guide syntax is the matching criteria in a Filter.
The following string states the OID assigned to this syntax:
The following syntax description gives the OID assigned to this
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 should not be used for defining new attributes. It The Guide syntax should not be used for defining new attributes. It
is important for backwards compatibility with LDAPv2 systems. is important for backwards compatibility with LDAPv2 systems.
Values in this syntax are encoded according to the following BNF: The native LDAP encoding of a value is the following BNF:
guide-value = [ object-class "#" ] criteria guide-value = [ object-class "#" ] criteria
object-class = woid object-class = space oid
The criteria production is defined in the Enhanced Guide syntax in The criteria production is defined in the Enhanced Guide syntax in
paragraph 3.14. The production for woid is in paragraph 2.1. paragraph 3.14. The productions for oid and space are in
paragraph 2.1.
3.19 IA5 String 3.19 IA5 String
A value in the IA5 String syntax is a string of characters from the A value in the IA5 String syntax is a value of the IA5String data
International Alphabet 5 [15] (international version of ASCII) type from ASN.1[5]. International Alphabet 5 [15] (IA5) is the
character set. The following string states the OID assigned to this international version of the ASCII character set.
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.26 DESC 'IA5 String' )
The written representation of a value in this syntax is the string The native LDAP encoding of a value in this syntax is the character
value itself. Also, IA5String is an ASN.1 data type from X.680 [5]. string value itself.
3.20 INTEGER 3.20 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 [5]. The following string states the INTEGER data type from ASN.1 [5].
OID assigned to this syntax:
The following syntax description gives the OID assigned to this
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' )
Values in this syntax are expressed as the decimal representation of The native LDAP encoding of a value is the decimal representation of
their values, with each decimal digit represented by the its the value, with each decimal digit represented by the its character
character equivalent. So, the number 1321 is represented by the equivalent. So, the number 1321 is represented by the character
character string "1321". string "1321".
3.21 JPEG 3.21 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 following string states the specific rules for light values. The native LDAP encoding of a
OID assigned to this syntax: value is strings containing JPEG images in the JPEG File Interchange
Format (JFIF), as described in [16].
( 1.3.6.1.4.1.1466.115.121.1.28 DESC 'JPEG' ) The following syntax description gives the OID assigned to this
syntax:
Values in this syntax are expressed as strings containing JPEG images ( 1.3.6.1.4.1.1466.115.121.1.28 DESC 'JPEG' )
in the JPEG File Interchange Format (JFIF), as described in [16].
3.22 LDAP Syntax Description 3.22 LDAP Syntax Description
A value in the LDAP Syntax Description syntax is a string that A value in the LDAP Syntax Description syntax is a definition of a
expresses the definition of a schema Syntax Description in LDAP. LDAP syntax description according to the BNF given in section 2.2.3.
The native LDAP encoding is the character codes in 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. The following string states the OID published in the directory. The following syntax description gives
assigned to this syntax: 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 [9], syntaxes are not labeled distinctly with Note that, in X.520 [9], syntaxes are not labeled distinctly with
respect to attributes. respect to attributes.
Values in this syntax are written according to the BNF in
section 2.2.4.
3.23 Matching Rule Description 3.23 Matching Rule Description
A value in the Matching Rule Description syntax is a string that A value in the Matching Rule Description syntax is a definition of
expresses the definition of a schema Matching Rule. This syntax is a matching rule according to the BNF given in section 2.3.2. The
the form in which schema matching rules are published in the native LDAP encoding is the character codes in UTF-8 which
directory. The following string states the OID assigned to this correspond to the characters in the definition of a Matching Rule.
syntax: This syntax is the form in which schema matching rules are published
in the directory. The following syntax definition gives the OID
assigned to this syntax:
( 1.3.6.1.4.1.1466.115.121.1.30 DESC 'Matching Rule Description' ) ( 1.3.6.1.4.1.1466.115.121.1.30 DESC 'Matching Rule Description' )
Values of type matchingRules are written as strings according to the
BNF given in section 2.3.2.
3.24 Matching Rule Use Description 3.24 Matching Rule Use Description
A value in the Matching Rule Use Description syntax is a string that A value in the Matching Rule Use Description syntax is a definition
expresses, for one of the Matching Rules implemented by the server, of a matching Rule and the attribute types with which the rule may
the attribute types with which the rule may be used in an be used in an extensibleMatch search filter according to the
extensibleMatch search filter. The following string states the OID following BNF:
assigned to this syntax:
MatchingRuleUseDescription = "(" whsp
numericoid ; MatchingRule identifier
[ space "NAME" space qdescrs ]
[ space "DESC" space qdstring ]
[ space "OBSOLETE" ]
space "APPLIES" space oids ; AttributeType identifiers
extensions
whsp ")"
The productions for whsp, numericoid, qdescrs, qdstring, space, and
oids are given in paragraph 2.1. Implementors should note that
future versions of this document may expand this BNF 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 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' )
Values of type matchingRuleUse are written as strings according to This syntax is the form in which schema matching rule usage
the BNF given in section 2.3.3. permissions are published in the directory.
3.25 MHS OR Address 3.25 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 following string states a user of an X.400 messaging service. The native LDAP encoding is
the OID assigned to this syntax: defined in RFC 1327 [17].
( 1.3.6.1.4.1.1466.115.121.1.33 DESC 'MHS OR Address' ) The following syntax description gives the OID assigned to this
syntax:
Values in this syntax are expressed as strings, according to the ( 1.3.6.1.4.1.1466.115.121.1.33 DESC 'MHS OR Address' )
format defined in RFC 1327 [17].
3.26 Name and Optional UID 3.26 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 paragraph 3.13 plus a bit string Distinguished Name as defined in paragraph 3.13 plus a bit string
that differentiates the value from otherwise identical names. The that differentiates the value from otherwise identical names.
following string states the OID assigned to this syntax:
( 1.3.6.1.4.1.1466.115.121.1.34 DESC 'Name And Optional UID' )
Values in this syntax are expressed according to the following BNF: The native LDAP encoding of a value is the following BNF:
NameAndOptionalUID = DistinguishedName [ "#" bitstring ] NameAndOptionalUID = DistinguishedName [ "#" bitstring ]
The bitstring production is defined in [Editor's note: Where is The bitstring production is defined in section 3.3.
bitstring?? End of Editor note].
Although the '#' character may occur in a string representation of a Although the '#' character may occur in a string representation of a
distinguished name, no additional special quoting is done. This distinguished name, no additional special quoting is done.
syntax has been added subsequent to RFC 1778 [7].
Example: 1.3.6.1.4.1.1466.0=#04024869,O=Test,C=GB#'0101'B Example:
1.3.6.1.4.1.1466.0=#04024869,O=Test,C=GB#'0101'B
The following syntax description gives the OID assigned to this
syntax:
( 1.3.6.1.4.1.1466.115.121.1.34 DESC 'Name And Optional UID' )
3.27 Name Form Description 3.27 Name Form Description
A value in the Name Form Description syntax is a string that A value in the Name Form Description syntax is a definition of a
indicates the one or more attributes in an entry type (e.g., person, name form according to the following BNF:
device) that are used as the Relative Distinguished Name of the
entries. This syntax is the form in which schema name forms are
published in the directory. The following string states the OID
assigned to this syntax:
( 1.3.6.1.4.1.1466.115.121.1.35 DESC 'Name Form Description' ) NameFormDescription = "(" whsp
numericoid ; NameForm identifier
[ space "NAME" space qdescrs ]
[ space "DESC" space qdstring ]
[ space "OBSOLETE" ]
space "OC" space oid ; Structural ObjectClass
space "MUST" space oids ; AttributeTypes
[ space "MAY" space oids ] ; AttributeTypes
extentions
whsp ")"
Values in this syntax are expressed according to the following BNF. The productions for whsp, numericoid, qdescrs, qdstring, oid, and
The productions for whsp, numericoid, qdescrs, qdstring, woid, and
oids are given in paragraph 2.1. Implementors should note that oids are given in paragraph 2.1. Implementors should note that
future versions of this document may have expanded this BNF to future versions of this document may have expanded this BNF to
include additional terms. include additional terms.
NameFormDescription = "(" whsp A value indicates the one or more attributes in an entry type (e.g.,
numericoid whsp ; NameForm identifier person, device) that are used as the Relative Distinguished Name of
[ "NAME" qdescrs ] the entries.
[ "DESC" qdstring ]
[ "OBSOLETE" whsp ] This syntax is the form in which schema name forms are published in
"OC" woid ; Structural ObjectClass the directory. The native LDAP encoding of a value is the character
"MUST" oids ; AttributeTypes codes in UTF-8 which correspond to the characters in the definition.
[ "MAY" oids ] ; AttributeTypes
whsp ")" The following syntax description gives the OID assigned to this
syntax:
( 1.3.6.1.4.1.1466.115.121.1.35 DESC 'Name Form Description' )
3.28 Numeric String 3.28 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 ASN.1 [5]. spaces as specified in the NumericString data type from ASN.1 [5].
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.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
skipping to change at page 30, line 21 skipping to change at page 32, line 13
PrintableString data type from ASN.1 [5] and in production p of PrintableString data type from ASN.1 [5] and in production p of
paragraph 2.1. Values in this syntax are expressed as the string paragraph 2.1. 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.36 Substring Assertion Syntax 3.36 Substring Assertion Syntax
The Substring Assertion syntax is used only as the syntax of The Substring Assertion syntax is used in rules which may be used in
assertion values in the extensible match. It is not used as the substrings and extensible matching rules. When using a substrings
syntax of attributes, or in the substring filter. assertion, substrings components are provided in a SubstringFilter
sequence. The following string states the OID assigned to this syntax:
( 1.3.6.1.4.1.1466.115.121.1.58 DESC 'Substring Assertion' ) ( 1.3.6.1.4.1.1466.115.121.1.58 DESC 'Substring Assertion' )
The Substring Assertion is expressed according to the following BNF: When using a matching rule assertion, substring components are
encoded according to the following BNF and provided as the
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 UTF-8 string. Should the backslash or The <value> production is UTF-8 string. Should the backslash or
skipping to change at page 32, line 42 skipping to change at page 34, line 47
( 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 [5]. formulated as specified for the UTCTime data type in ASN.1 [5].
Note that the time zone must be specified. It is strongly Note that the time zone must be specified. It is strongly
recommended that GMT time be used. recommended 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.
[Editors note: The convention for interpretation of 2-digit year [Editor's note: The convention for interpretation of 2-digit year
values should be here (at least by reference), but where is the LDAP values should be here (at least by reference), but where is the LDAP
convention specified? Is LDAP referring to X.500 for this? If so, convention specified? Is LDAP referring to X.500 for this? If so,
where? End of Editor's note] where? End of Editor's note]
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
treated the same as an individual space, and leading and trailing treated the same as an individual space, and leading and trailing
skipping to change at page 36, line 40 skipping to change at page 38, line 47
This matching rule is used to test equality. This matching rule is used to test equality.
Implementors should note that the assertion syntax of this matching Implementors should note that the assertion syntax of this matching
rule, an OID, is different from the value syntax of attributes for rule, an OID, is different from the value syntax of attributes for
which this is the equality matching rule. which this is the equality matching rule.
If the client supplies a filter using an objectIdentifierMatch whose If the client supplies a filter using an objectIdentifierMatch whose
matchValue oid is in the "descr" form, and the oid is not recognized matchValue oid is in the "descr" form, and the oid is not recognized
by the server, then the filter is Undefined. by the server, then the filter is Undefined.
4.17 presentationAddressMatch 4.17 octetStringMatch
Servers which implement the extensibleMatch filter SHOULD allow the
matching rule listed in this section to be used in the
extensibleMatch. In general these servers SHOULD allow matching
rules to be used with all attribute types known to the server, when
the assertion syntax of the matching rule is the same as the value
syntax of the attribute.
The Octet String Match rule compares for equality an asserted octet
string with an attribute value of type OCTET STRING.
The strings match if they are the same length and corresponding
octets are identical.
( 2.5.13.17 NAME 'octetStringMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )
4.18 presentationAddressMatch
The following BNF associates the presentationAddressMatch rule with The following BNF 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
This matching rule is used to test equality. This matching rule is used to test equality.
4.18 protocolInformationMatch 4.19 protocolInformationMatch
The following BNF associates the protocolInformationMatch rule with The following BNF associates the protocolInformationMatch rule with
the Protocol Information syntax: the Protocol Information syntax:
( 2.5.13.24 NAME 'protocolInformationMatch' ( 2.5.13.24 NAME 'protocolInformationMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.42 ) ; Protocol Information SYNTAX 1.3.6.1.4.1.1466.115.121.1.42 ) ; Protocol Information
This matching rule is used to test equality. This matching rule is used to test equality.
4.19 telephoneNumberMatch 4.20 telephoneNumberMatch
The following BNF associates the telephoneNumberMatch rule with the The following BNF associates the telephoneNumberMatch rule with the
Telephone Number syntax: Telephone Number syntax:
( 2.5.13.20 NAME 'telephoneNumberMatch' ( 2.5.13.20 NAME 'telephoneNumberMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 ) ; Telephone Number SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 ) ; Telephone Number
This matching rule is used to test equality. This matching rule is used to test equality.
4.20 telephoneNumberSubstringsMatch 4.21 telephoneNumberSubstringsMatch
The following BNF associates the telephoneNumberSubstringsMatch rule The following BNF associates the telephoneNumberSubstringsMatch rule
with the Substring Assertion syntax: with the Substring Assertion syntax:
( 2.5.13.21 NAME 'telephoneNumberSubstringsMatch' ( 2.5.13.21 NAME 'telephoneNumberSubstringsMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 ) ; Substring Assertion SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 ) ; Substring Assertion
This matching rule is used to test substrings equality. This matching rule is used to test substrings equality.
4.21 uniqueMemberMatch 4.22 uniqueMemberMatch
The following BNF associates the uniqueMemberMatch rule with the The following BNF 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. Attribute Types
5.1 altServer 5.1 altServer
The values of this attribute are URLs of other servers which may be The values of this attribute are URLs of other servers which may be
contacted when this server becomes unavailable. If the server does contacted when this server becomes unavailable. If the server does
not know of any other servers which could be used this attribute will not know of any other servers which could be used this attribute will
be absent. Clients may cache this information in case their be absent. Clients may cache this information in case their
preferred LDAP server later becomes unavailable. preferred LDAP server later becomes unavailable.
( 1.3.6.1.4.1.1466.101.120.6 NAME 'altServer' ( 1.3.6.1.4.1.1466.101.120.6 NAME 'altServer'
EQUALITY caseIgnoreIA5Match ; [Editor's Note: DELETE EQUALITY caseIgnoreIA5Match
; OR SHOULD THIS BE caseExactIA5Match?? ; OR SHOULD THIS BE caseExactIA5Match?? End Editor's Note]
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
USAGE dSAOperation ) USAGE dSAOperation )
This attribute is only present in the root DSE (see [1] and [3]). This attribute is only present in the root DSE (see [1] and [3]).
5.2 attributeTypes 5.2 attributeTypes
This attribute is typically located in the subschema entry. This attribute is typically located in the subschema entry.
( 2.5.21.5 NAME 'attributeTypes' ( 2.5.21.5 NAME 'attributeTypes'
skipping to change at page 40, line 45 skipping to change at page 43, line 8
The values of this attribute correspond to naming contexts which The values of this attribute correspond to naming contexts which
this server masters or shadows. If the server does not master any 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) 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 this attribute will be absent. If the server believes it contains
the entire directory, the attribute will have a single value, and the entire directory, the attribute will have a single value, and
that value will be the empty string (indicating the null DN of the that value will be the empty string (indicating the null DN of the
root). This attribute will allow a client to choose suitable base root). This attribute will allow a client to choose suitable base
objects for searching when it has contacted a server. objects for searching when it has contacted a server.
( 1.3.6.1.4.1.1466.101.120.5 NAME 'namingContexts' ( 1.3.6.1.4.1.1466.101.120.5 NAME 'namingContexts'
EQUALITY distinguishedNameMatch ; [Editor's Note: DELETE EQUALITY distinguishedNameMatch
; End of Editor's Note]
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 ; DN SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 ; DN
USAGE dSAOperation ) USAGE dSAOperation )
This attribute is only present in the root DSE (see [1] and [3]). This attribute is only present in the root DSE (see [1] and [3]).
5.14 objectClasses 5.14 objectClasses
This attribute is typically located in the subschema entry. This attribute is typically located in the subschema entry.
( 2.5.21.6 NAME 'objectClasses' ( 2.5.21.6 NAME 'objectClasses'
skipping to change at page 41, line 28 skipping to change at page 43, line 45
SINGLE-VALUE SINGLE-VALUE
USAGE directoryOperation ) USAGE directoryOperation )
5.16 supportedControl 5.16 supportedControl
The values of this attribute are the OBJECT IDENTIFIERs identifying The values of this attribute are the OBJECT IDENTIFIERs identifying
controls which the server supports. If the server does not support controls which the server supports. If the server does not support
any controls, this attribute will be absent. any controls, this attribute will be absent.
( 1.3.6.1.4.1.1466.101.120.13 NAME 'supportedControl' ( 1.3.6.1.4.1.1466.101.120.13 NAME 'supportedControl'
EQUALITY objectIdentifierMatch ; [Editor's Note: DELETE EQUALITY objectIdentifierMatch End
; of Editor's Note]
SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 ; OID SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 ; OID
USAGE dSAOperation ) USAGE dSAOperation )
This attribute is only present in the root DSE (see [1] and [3]). This attribute is only present in the root DSE (see [1] and [3]).
5.17 supportedExtension 5.17 supportedExtension
The values of this attribute are OBJECT IDENTIFIERs identifying the The values of this attribute are OBJECT IDENTIFIERs identifying the
supported extended operations which the server supports. supported extended operations which the server supports.
If the server does not support any extensions this attribute will be If the server does not support any extensions this attribute will be
absent. absent.
( 1.3.6.1.4.1.1466.101.120.7 NAME 'supportedExtension' ( 1.3.6.1.4.1.1466.101.120.7 NAME 'supportedExtension'
EQUALITY objectIdentifierMatch ; [Editor's Note: DELETE EQUALITY objectIdentifierMatch End
; of Editor's Note]
SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 ; OID SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 ; OID
USAGE dSAOperation ) USAGE dSAOperation )
This attribute is only present in the root DSE (see [1] and [3]). This attribute is only present in the root DSE (see [1] and [3]).
5.18 supportedLDAPVersion 5.18 supportedLDAPVersion
The values of this attribute are the versions of the LDAP protocol The values of this attribute are the versions of the LDAP protocol
which the server implements. which the server implements.
( 1.3.6.1.4.1.1466.101.120.15 NAME 'supportedLDAPVersion' ( 1.3.6.1.4.1.1466.101.120.15 NAME 'supportedLDAPVersion'
EQUALITY integerMatch ; Editor's Note: DELETE EQUALITY integerMatch
ORDERING integerOrderingMatch ; ORDERING integerOrderingMatch End of Editor's Note]
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 ; INTEGER SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 ; INTEGER
USAGE dSAOperation ) USAGE dSAOperation )
This attribute is only present in the root DSE (see [1] and [3]). This attribute is only present in the root DSE (see [1] and [3]).
5.19 supportedSASLMechanisms 5.19 supportedSASLMechanisms
The values of this attribute are the names of supported SASL The values of this attribute are the names of supported SASL
mechanisms which the server supports. If the server does not support mechanisms which the server supports. If the server does not support
any mechanisms this attribute will be absent. any mechanisms this attribute will be absent.
( 1.3.6.1.4.1.1466.101.120.14 NAME 'supportedSASLMechanisms' ( 1.3.6.1.4.1.1466.101.120.14 NAME 'supportedSASLMechanisms'
EQUALITY caseIgnoreMatch ; OR SHOULD THIS BE caseExactMatch?? ; [Editor's Note: DELETE EQUALITY caseIgnoreMatch ; OR
; SHOULD THIS BE caseExactMatch?? End of Editor's Note]
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ; Directory String SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ; Directory String
USAGE dSAOperation ) USAGE dSAOperation )
This attribute is only present in the root DSE (see [1] and [3]). This attribute is only present in the root DSE (see [1] and [3]).
6. Object Classes 6. Object Classes
6.1 Extensible Object Class 6.1 Extensible Object Class
The extensibleObject object class, if present in an entry, permits The extensibleObject object class, if present in an entry, permits
skipping to change at page 44, line 50 skipping to change at page 46, line 50
suggestion. There is probably more to be said. Input please! End suggestion. There is probably more to be said. Input please! End
of Editor's Note] of Editor's Note]
8. Acknowledgements 8. 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 ___ for their significant contribution to The authors wish to thank ____, J. Sermersheim, and K. Zeilenga for
this update. their significant contribution to this update.
9. Author's Address 9. Author's Address
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
skipping to change at page 48, line 5 skipping to change at page 49, line 15
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Annex A Topics Yet To Be Addressed In This Document Annex A Object Identifiers of Syntaxes
This list contains the object identifiers for the syntaxes used in
this I-D and in the user schema I-D. The complete list of syntax
object identifiers is maintained by IANA. See ____ for more
information about IANA services.
Syntax of Value Represented OBJECT IDENTIFIER
=====================================================================
Attribute Type Description 1.3.6.1.4.1.1466.115.121.1.3
Bit String 1.3.6.1.4.1.1466.115.121.1.6
Certificate 1.3.6.1.4.1.1466.115.121.1.8
Certificate List 1.3.6.1.4.1.1466.115.121.1.9
Certificate Pair 1.3.6.1.4.1.1466.115.121.1.10
DN 1.3.6.1.4.1.1466.115.121.1.12
Delivery Method 1.3.6.1.4.1.1466.115.121.1.14
Directory String 1.3.6.1.4.1.1466.115.121.1.15
DIT Content Rule Description 1.3.6.1.4.1.1466.115.121.1.16
DIT Structure Rule Description 1.3.6.1.4.1.1466.115.121.1.17
Enhanced Guide 1.3.6.1.4.1.1466.115.121.1.21
Facsimile Telephone Number 1.3.6.1.4.1.1466.115.121.1.22
Generalized Time 1.3.6.1.4.1.1466.115.121.1.24
Guide 1.3.6.1.4.1.1466.115.121.1.25
IA5 String 1.3.6.1.4.1.1466.115.121.1.26
INTEGER 1.3.6.1.4.1.1466.115.121.1.27
LDAP Syntax Description 1.3.6.1.4.1.1466.115.121.1.54
LDAP Schema Definition 1.3.6.1.4.1.1466.115.121.1.56
LDAP Schema Description 1.3.6.1.4.1.1466.115.121.1.57
Master And Shadow Access Points 1.3.6.1.4.1.1466.115.121.1.29
Matching Rule Description 1.3.6.1.4.1.1466.115.121.1.30
Matching Rule Use Description 1.3.6.1.4.1.1466.115.121.1.31
Mail Preference 1.3.6.1.4.1.1466.115.121.1.32
MHS OR Address 1.3.6.1.4.1.1466.115.121.1.33
Modify Rights 1.3.6.1.4.1.1466.115.121.1.55
Name And Optional UID 1.3.6.1.4.1.1466.115.121.1.34
Name Form Description 1.3.6.1.4.1.1466.115.121.1.35
Numeric String 1.3.6.1.4.1.1466.115.121.1.36
Object Class Description 1.3.6.1.4.1.1466.115.121.1.37
Octet String 1.3.6.1.4.1.1466.115.121.1.40
OID 1.3.6.1.4.1.1466.115.121.1.38
Other Mailbox 1.3.6.1.4.1.1466.115.121.1.39
Postal Address 1.3.6.1.4.1.1466.115.121.1.41
Protocol Information 1.3.6.1.4.1.1466.115.121.1.42
Presentation Address 1.3.6.1.4.1.1466.115.121.1.43
Printable String 1.3.6.1.4.1.1466.115.121.1.44
Substring Assertion 1.3.6.1.4.1.1466.115.121.1.58
Subtree Specification 1.3.6.1.4.1.1466.115.121.1.45
Supplier Information 1.3.6.1.4.1.1466.115.121.1.46
Supplier Or Consumer 1.3.6.1.4.1.1466.115.121.1.47
Supplier And Consumer 1.3.6.1.4.1.1466.115.121.1.48
Supported Algorithm 1.3.6.1.4.1.1466.115.121.1.49
Telephone Number 1.3.6.1.4.1.1466.115.121.1.50
Teletex Terminal Identifier 1.3.6.1.4.1.1466.115.121.1.51
Telex Number 1.3.6.1.4.1.1466.115.121.1.52
UTC Time 1.3.6.1.4.1.1466.115.121.1.53
Annex B Topics Yet To Be Addressed In This Document
This appendix is provided for informational purposes only, it is not This appendix is provided for informational purposes only, it is not
a normative part of this specification. a normative part of this specification.
Paragraph 2.2.3 - Should attribute syntaxes be allowed to be referenced APPEARED: -00
by a common name, and if so, where should the name come from? An
optional NAME has been added to the BNF for SyntaxDescription in
paragraph 2.2.4.
Paragraph 2.2.3 - Should any syntaxes listed in the table be removed? Paragraph 2.2.3 - Should any syntaxes listed in the table be removed?
Should any new syntaxes be added? Should any new syntaxes be added?
RESOLUTION: Cannot add syntaxes. Moving the table to an annex keeps
a record of the OIDS that have been assigned. APPLIED:
How does the data model draft <draft-wahl-ladpv3-defns-00.txt> affect APPEARED: -00
Paragraph 2.2.4 - Should attribute syntaxes be allowed to be referenced
by a common name, and if so, where should the name come from?
RESOLUTION: Rejected because of adding functionality. APPLIED: -01
APPEARED: -00
How does the data model draft <draft-wahl-ladpv3-defns-01.txt> affect
this draft? this draft?
RESOLUTION: It does not. The draft was preliminary to the revised
Schema and Protocol I-Ds. APPLIED: -01
APPEARED: -00
Section 3 - Should all listed syntaxes from paragraph 2.2.3 be Section 3 - Should all listed syntaxes from paragraph 2.2.3 be
detailed in this section? Nearly half the listed syntaxes are not detailed in this section? Nearly half the listed syntaxes are not
referenced in this section. referenced in this section.
RESOLUTION: No, because many are not being used, currently.
APPLIED: -01
APPEARED: -01
Section 4 - Should all of the X.520(1993) matching rules be included?
In particular, how about caseExactMatch? Also, should
octetStringMatch be moved from updated RFC 2256?
RESOLUTION: APPLIED:
APPEARED: -00
Section 6 - Recognized list of Object classes needs to be reconciled Section 6 - Recognized list of Object classes needs to be reconciled
with updated RFC 2256 and the data model draft. with updated RFC 2256 and the data model draft.
RESOLUTION: Not necessary. APPLIED: -01
APPEARED: -00
Section 7 - Proper security statement needs to be formulated. Section 7 - Proper security statement needs to be formulated.
RESOLUTION: Text has been expanded since RFC 2252, but needs
more work.
Annex B 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 I-D. this I-D.
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. a normative part of this specification.
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
skipping to change at page 49, line 49 skipping to change at page 52, line 20
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 BNF 10. Added NAME option to the syntax description BNF
in 2.2.4. in 2.2.4.
RESCINDED IN -01!!
11. Added a note deprecating the UTCTime attribute syntax 11. Added a note deprecating the UTCTime attribute syntax
description in 3.41 description in 3.41
12. In the BNF of the MatchingRuleDescription in paragraph 2.3.2, 12. In the BNF of the MatchingRuleDescription in paragraph 2.3.2,
replaced "numericoid" with "oid". replaced "numericoid" with "oid".
13. In paragraph 2.4.1, replaced the conformance statement about 13. In paragraph 2.4.1, replaced the conformance statement about
attributes in 2256 with a reference. attributes in 2256 with a reference.
14. Added caseIgnoreIA5Match as the EQUALITY matching rule for 14. Added caseIgnoreIA5Match as the EQUALITY matching rule for
the altServer attribute type BNF in paragraph 5.1. Note that the altServer attribute type BNF in paragraph 5.1. Note that
this could be caseExactIA5Match instead. SHOULD IT BE?? this could be caseExactIA5Match instead. SHOULD IT BE??
RESCINDED IN -01
15. In paragraphs 5.10 and 5.11, changed "the MODIFY operation" 15. In paragraphs 5.10 and 5.11, changed "the MODIFY operation"
to "LDAP update operations" to "LDAP update operations"
16. Added distinguishedNameMatch as the EQUALITY matching rule 16. Added distinguishedNameMatch as the EQUALITY matching rule
for the namingContexts attribute type BNF in paragraph 5.13. for the namingContexts attribute type BNF in paragraph 5.13.
RESCINDED IN -01
17. Reworded paragraph 5.15. 17. Reworded paragraph 5.15.
18. Added objectIdentifierMatch as the EQUALITY matching rule for 18. Added distinguishedNameMatch as the EQUALITY matching rule
the supportedControl and supportedExtension attribute types for the namingContexts attribute type BNF in paragraph 5.13.
BNF in paragraphs 5.16 and 5.17.
RESCINDED IN -01
19. Added integerMatch as the EQUALITY and integerOrderingMatch 19. Added integerMatch as the EQUALITY and integerOrderingMatch
as the Ordering matching rules for the supportedLDAPVersion as the Ordering matching rules for the supportedLDAPVersion
attribute type BNF in paragraph 5.18. attribute type BNF in paragraph 5.18.
RESCINDED IN -01
20. Added caseIgnoreMatch as the EQUALITY matching rule for the 20. Added caseIgnoreMatch as the EQUALITY matching rule for the
supportedSASLMechanisms attribute type BNF in paragraph 5.19. supportedSASLMechanisms attribute type BNF in paragraph 5.19.
Note that this could be caseExactMatch instead. SHOULD Note that this could be caseExactMatch instead. SHOULD
IT BE?? IT BE??
RESCINDED IN -01
21. Made corrections to the BNF in paragraph 3.12. 21. Made corrections to the BNF 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 on 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.
-------
25. Moved the table listing the syntaxes and their oids from
paragraph 2.2.3 to a new Annex A.
26. Moved the specification of the octetStringMatch matching rule
from RFC 2256 to section 4 of this document.
27. Throughout this I-D, cleaned up whitespace in the BNF definitions.
28. Added the specification of the octetStringSubstringAssertion
syntax to section 3 of this document.
29. In Section 2.1:
* Corrected the characters defined in the p rule to match
the PrintableString syntax.
* Deleted the letterstring rule.
* Modified the utf8 and dstring rules according to a
suggestion from K. Zeilenga.
* Deleted ";" from the k rule, which affects the anhstring,
keystring, and descr rules.
* Removed the length option from the numericoid rule
30. In section 2.2, deleted the sentence about needing a new OID
when a syntax is modified.
31. In section 2.2, replaced the editor's proposal and subject
text with explanation of the native LDAP encoding of
attribute values.
32. Removed section 2.2.2 (and renumbered the remainder of
section 2.2), leaving the description of binary encoding to
the protocol I-D.
 End of changes. 

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