Newer
Older
Network Working Group S. Legg, Ed.
Request for Comments: 4517 eB2Bcom
Obsoletes: 2252, 2256 June 2006
Updates: 3698
Category: Standards Track
Lightweight Directory Access Protocol (LDAP):
Syntaxes and Matching Rules
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright (C) The Internet Society (2006).
Each attribute stored in a Lightweight Directory Access Protocol
(LDAP) directory, whose values may be transferred in the LDAP
protocol, has a defined syntax that constrains the structure and
format of its values. The comparison semantics for values of a
syntax are not part of the syntax definition but are instead provided
through separately defined matching rules. Matching rules specify an
argument, an assertion value, which also has a defined syntax. This
document defines a base set of syntaxes and matching rules for use in
defining attributes for LDAP directories.
1. Introduction ....................................................3
2. Conventions .....................................................4
3. Syntaxes ........................................................4
3.1. General Considerations .....................................5
3.2. Common Definitions .........................................5
3.3. Syntax Definitions .........................................6
3.3.1. Attribute Type Description ..........................6
3.3.2. Bit String ..........................................6
3.3.3. Boolean .............................................7
3.3.4. Country String ......................................7
3.3.5. Delivery Method .....................................8
Legg Standards Track [Page 1]
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
3.3.6. Directory String ....................................8
3.3.7. DIT Content Rule Description ........................9
3.3.8. DIT Structure Rule Description .....................10
3.3.9. DN .................................................10
3.3.10. Enhanced Guide ....................................11
3.3.11. Facsimile Telephone Number ........................12
3.3.12. Fax ...............................................12
3.3.13. Generalized Time ..................................13
3.3.14. Guide .............................................14
3.3.15. IA5 String ........................................15
3.3.16. Integer ...........................................15
3.3.17. JPEG ..............................................15
3.3.18. LDAP Syntax Description ...........................16
3.3.19. Matching Rule Description .........................16
3.3.20. Matching Rule Use Description .....................17
3.3.21. Name and Optional UID .............................17
3.3.22. Name Form Description .............................18
3.3.23. Numeric String ....................................18
3.3.24. Object Class Description ..........................18
3.3.25. Octet String ......................................19
3.3.26. OID ...............................................19
3.3.27. Other Mailbox .....................................20
3.3.28. Postal Address ....................................20
3.3.29. Printable String ..................................21
3.3.30. Substring Assertion ...............................22
3.3.31. Telephone Number ..................................23
3.3.32. Teletex Terminal Identifier .......................23
3.3.33. Telex Number ......................................24
3.3.34. UTC Time ..........................................24
4. Matching Rules .................................................25
4.1. General Considerations ....................................25
4.2. Matching Rule Definitions .................................27
4.2.1. bitStringMatch .....................................27
4.2.2. booleanMatch .......................................28
4.2.3. caseExactIA5Match ..................................28
4.2.4. caseExactMatch .....................................29
4.2.5. caseExactOrderingMatch .............................29
4.2.6. caseExactSubstringsMatch ...........................30
4.2.7. caseIgnoreIA5Match .................................30
4.2.8. caseIgnoreIA5SubstringsMatch .......................31
4.2.9. caseIgnoreListMatch ................................31
4.2.10. caseIgnoreListSubstringsMatch .....................32
4.2.11. caseIgnoreMatch ...................................33
4.2.12. caseIgnoreOrderingMatch ...........................33
4.2.13. caseIgnoreSubstringsMatch .........................34
4.2.14. directoryStringFirstComponentMatch ................34
4.2.15. distinguishedNameMatch ............................35
4.2.16. generalizedTimeMatch ..............................36
Legg Standards Track [Page 2]
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
4.2.17. generalizedTimeOrderingMatch ......................36
4.2.18. integerFirstComponentMatch ........................36
4.2.19. integerMatch ......................................37
4.2.20. integerOrderingMatch ..............................37
4.2.21. keywordMatch ......................................38
4.2.22. numericStringMatch ................................38
4.2.23. numericStringOrderingMatch ........................39
4.2.24. numericStringSubstringsMatch ......................39
4.2.25. objectIdentifierFirstComponentMatch ...............40
4.2.26. objectIdentifierMatch .............................40
4.2.27. octetStringMatch ..................................41
4.2.28. octetStringOrderingMatch ..........................41
4.2.29. telephoneNumberMatch ..............................42
4.2.30. telephoneNumberSubstringsMatch ....................42
4.2.31. uniqueMemberMatch .................................43
4.2.32. wordMatch .........................................44
5. Security Considerations ........................................44
6. Acknowledgements ...............................................44
7. IANA Considerations ............................................45
8. References .....................................................46
8.1. Normative References ......................................46
8.2. Informative References ....................................48
Appendix A. Summary of Syntax Object Identifiers ..................49
Appendix B. Changes from RFC 2252 .................................49
Each attribute stored in a Lightweight Directory Access Protocol
(LDAP) directory [RFC4510], whose values may be transferred in the
LDAP protocol [RFC4511], has a defined syntax (i.e., data type) that
constrains the structure and format of its values. The comparison
semantics for values of a syntax are not part of the syntax
definition but are instead provided through separately defined
matching rules. Matching rules specify an argument, an assertion
value, which also has a defined syntax. This document defines a base
set of syntaxes and matching rules for use in defining attributes for
LDAP directories.
Readers are advised to familiarize themselves with the Directory
Information Models [RFC4512] before reading the rest of this
document. Section 3 provides definitions for the base set of LDAP
syntaxes. Section 4 provides definitions for the base set of
matching rules for LDAP.
This document is an integral part of the LDAP technical specification
[RFC4510], which obsoletes the previously defined LDAP technical
specification, RFC 3377, in its entirety.
Legg Standards Track [Page 3]
RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
Sections 4, 5, and 7 of RFC 2252 are obsoleted by [RFC4512]. The
remainder of RFC 2252 is obsoleted by this document. Sections 6 and
8 of RFC 2256 are obsoleted by this document. The remainder of RFC
2256 is obsoleted by [RFC4519] and [RFC4512]. All but Section 2.11
of RFC 3698 is obsoleted by this document.
A number of schema elements that were included in the previous
revision of the LDAP technical specification are not included in this
revision of LDAP. Public Key Infrastructure schema elements are now
specified in [RFC4523]. Unless reintroduced in future technical
specifications, the remainder are to be considered Historic.
The changes with respect to RFC 2252 are described in Appendix B of
In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119
[RFC2119].
Syntax definitions are written according to the <SyntaxDescription>
ABNF [RFC4234] rule specified in [RFC4512], and matching rule
definitions are written according to the <MatchingRuleDescription>
ABNF rule specified in [RFC4512], except that the syntax and matching
rule definitions provided in this document are line-wrapped for
readability. When such definitions are transferred as attribute
values in the LDAP protocol (e.g., as values of the ldapSyntaxes and
matchingRules attributes [RFC4512], respectively), then those values
Syntax definitions constrain the structure of attribute values stored
in an LDAP directory, and determine the representation of attribute
and assertion values transferred in the LDAP protocol.
Syntaxes that are required for directory operation, or that are in
common use, are specified in this section. Servers SHOULD recognize
all the syntaxes listed in this document, but are not required to
otherwise support them, and MAY recognise or support other syntaxes.
However, the definition of additional arbitrary syntaxes is
discouraged since it will hinder interoperability. Client and server
implementations typically do not have the ability to dynamically
recognize new syntaxes.
Legg Standards Track [Page 4]
RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
The description of each syntax specifies how attribute or assertion
values conforming to the syntax are to be represented when
transferred in the LDAP protocol [RFC4511]. This representation is
referred to as the LDAP-specific encoding to distinguish it from
other methods of encoding attribute values (e.g., the Basic Encoding
Rules (BER) encoding [BER] used by X.500 [X.500] directories).
The LDAP-specific encoding of a given attribute syntax always
produces octet-aligned values. To the greatest extent possible,
encoding rules for LDAP syntaxes should produce character strings
that can be displayed with little or no translation by clients
implementing LDAP. However, clients MUST NOT assume that the LDAP-
specific encoding of a value of an unrecognized syntax is a human-
readable character string. There are a few cases (e.g., the JPEG
syntax) when it is not reasonable to produce a human-readable
representation.
Each LDAP syntax is uniquely identified with an object identifier
[ASN.1] represented in the dotted-decimal format (short descriptive
names are not defined for syntaxes). These object identifiers are
not intended to be displayed to users. The object identifiers for
the syntaxes defined in this document are summarized in Appendix A.
A suggested minimum upper bound on the number of characters in an
attribute value with a string-based syntax, or the number of octets
in a value for all other syntaxes, MAY be indicated by appending the
bound inside of curly braces following the syntax's OBJECT IDENTIFIER
in an attribute type definition (see the <noidlen> rule in
[RFC4512]). Such a bound is not considered part of the syntax
identifier.
For example, "1.3.6.1.4.1.1466.115.121.1.15{64}" in an attribute
definition suggests that the directory server will allow a value of
the attribute to be up to 64 characters long, although it may allow
longer character strings. Note that a single character of the
Directory String syntax can be encoded in more than one octet, since
UTF-8 [RFC3629] is a variable-length encoding. Therefore, a 64-
character string may be more than 64 octets in length.
The following ABNF rules are used in a number of the syntax
PrintableCharacter = ALPHA / DIGIT / SQUOTE / LPAREN / RPAREN /
PLUS / COMMA / HYPHEN / DOT / EQUALS /
Legg Standards Track [Page 5]
RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
SLASH / COLON / QUESTION / SPACE
PrintableString = 1*PrintableCharacter
IA5String = *(%x00-7F)
SLASH = %x2F ; forward slash ("/")
COLON = %x3A ; colon (":")
QUESTION = %x3F ; question mark ("?")
The <ALPHA>, <DIGIT>, <SQUOTE>, <LPAREN>, <RPAREN>, <PLUS>, <COMMA>,
<HYPHEN>, <DOT>, <EQUALS>, and <SPACE> rules are defined in
[RFC4512].
A value of the Attribute Type Description syntax is the definition of
an attribute type. The LDAP-specific encoding of a value of this
syntax is defined by the <AttributeTypeDescription> rule in
[RFC4512].
For example, the following definition of the createTimestamp
attribute type from [RFC4512] is also a value of the Attribute
Type Description syntax. (Note: Line breaks have been added for
readability; they are not part of the value when transferred in
protocol.)
( 2.5.18.1 NAME 'createTimestamp'
EQUALITY generalizedTimeMatch
ORDERING generalizedTimeOrderingMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
SINGLE-VALUE NO-USER-MODIFICATION
USAGE directoryOperation )
The LDAP definition for the Attribute Type Description syntax is:
( 1.3.6.1.4.1.1466.115.121.1.3 DESC 'Attribute Type Description' )
This syntax corresponds to the AttributeTypeDescription ASN.1 type
from [X.501].
A value of the Bit String syntax is a sequence of binary digits. The
LDAP-specific encoding of a value of this syntax is defined by the
following ABNF:
BitString = SQUOTE *binary-digit SQUOTE "B"
Legg Standards Track [Page 6]
RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
The <SQUOTE> rule is defined in [RFC4512].
Example:
'0101111101'B
The LDAP definition for the Bit String syntax is:
( 1.3.6.1.4.1.1466.115.121.1.6 DESC 'Bit String' )
This syntax corresponds to the BIT STRING ASN.1 type from [ASN.1].
A value of the Boolean syntax is one of the Boolean values, true or
false. The LDAP-specific encoding of a value of this syntax is
defined by the following ABNF:
Boolean = "TRUE" / "FALSE"
The LDAP definition for the Boolean syntax is:
( 1.3.6.1.4.1.1466.115.121.1.7 DESC 'Boolean' )
This syntax corresponds to the BOOLEAN ASN.1 type from [ASN.1].
A value of the Country String syntax is one of the two-character
codes from ISO 3166 [ISO3166] for representing a country. The LDAP-
specific encoding of a value of this syntax is defined by the
following ABNF:
CountryString = 2(PrintableCharacter)
The <PrintableCharacter> rule is defined in Section 3.2.
( 1.3.6.1.4.1.1466.115.121.1.11 DESC 'Country String' )
This syntax corresponds to the following ASN.1 type from [X.520]:
PrintableString (SIZE (2)) -- ISO 3166 codes only
Legg Standards Track [Page 7]
RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
A value of the Delivery Method syntax is a sequence of items that
indicate, in preference order, the service(s) by which an entity is
willing and/or capable of receiving messages. The LDAP-specific
encoding of a value of this syntax is defined by the following ABNF:
DeliveryMethod = pdm *( WSP DOLLAR WSP pdm )
pdm = "any" / "mhs" / "physical" / "telex" / "teletex" /
"g3fax" / "g4fax" / "ia5" / "videotex" / "telephone"
The <WSP> and <DOLLAR> rules are defined in [RFC4512].
Example:
telephone $ videotex
The LDAP definition for the Delivery Method syntax is:
( 1.3.6.1.4.1.1466.115.121.1.14 DESC 'Delivery Method' )
This syntax corresponds to the following ASN.1 type from [X.520]:
SEQUENCE OF INTEGER {
any-delivery-method (0),
mhs-delivery (1),
physical-delivery (2),
telex-delivery (3),
teletex-delivery (4),
g3-facsimile-delivery (5),
g4-facsimile-delivery (6),
ia5-terminal-delivery (7),
videotex-delivery (8),
telephone-delivery (9) }
A value of the Directory String syntax is a string of one or more
arbitrary characters from the Universal Character Set (UCS) [UCS]. A
zero-length character string is not permitted. The LDAP-specific
encoding of a value of this syntax is the UTF-8 encoding [RFC3629] of
the character string. Such encodings conform to the following ABNF:
DirectoryString = 1*UTF8
The <UTF8> rule is defined in [RFC4512].
Legg Standards Track [Page 8]
RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
Example:
This is a value of Directory String containing #!%#@.
Servers and clients MUST be prepared to receive arbitrary UCS code
points, including code points outside the range of printable ASCII
and code points not presently assigned to any character.
Attribute type definitions using the Directory String syntax should
not restrict the format of Directory String values, e.g., by
requiring that the character string conforms to specific patterns
described by ABNF. A new syntax should be defined in such cases.
The LDAP definition for the Directory String syntax is:
( 1.3.6.1.4.1.1466.115.121.1.15 DESC 'Directory String' )
This syntax corresponds to the DirectoryString parameterized ASN.1
type from [X.520].
The DirectoryString ASN.1 type allows a choice between the
TeletexString, PrintableString, or UniversalString ASN.1 types from
[ASN.1]. However, note that the chosen alternative is not indicated
in the LDAP-specific encoding of a Directory String value.
Implementations that convert Directory String values from the LDAP-
specific encoding to the BER encoding used by X.500 must choose an
alternative that permits the particular characters in the string and
must convert the characters from the UTF-8 encoding into the
character encoding of the chosen alternative. When converting
Directory String values from the BER encoding to the LDAP-specific
encoding, the characters must be converted from the character
encoding of the chosen alternative into the UTF-8 encoding. These
conversions SHOULD be done in a manner consistent with the Transcode
step of the string preparation algorithms [RFC4518] for LDAP.
A value of the DIT Content Rule Description syntax is the definition
of a DIT (Directory Information Tree) content rule. The LDAP-
specific encoding of a value of this syntax is defined by the
<DITContentRuleDescription> rule in [RFC4512].
Example:
( 2.5.6.4 DESC 'content rule for organization'
NOT ( x121Address $ telexNumber ) )
Note: A line break has been added for readability; it is not part
Legg Standards Track [Page 9]
RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
The LDAP definition for the DIT Content Rule Description syntax is:
( 1.3.6.1.4.1.1466.115.121.1.16
DESC 'DIT Content Rule Description' )
This syntax corresponds to the DITContentRuleDescription ASN.1 type
from [X.501].
A value of the DIT Structure Rule Description syntax is the
definition of a DIT structure rule. The LDAP-specific encoding of a
value of this syntax is defined by the <DITStructureRuleDescription>
Example:
( 2 DESC 'organization structure rule' FORM 2.5.15.3 )
The LDAP definition for the DIT Structure Rule Description syntax is:
( 1.3.6.1.4.1.1466.115.121.1.17
DESC 'DIT Structure Rule Description' )
This syntax corresponds to the DITStructureRuleDescription ASN.1 type
from [X.501].
A value of the DN syntax is the (purported) distinguished name (DN)
of an entry [RFC4512]. The LDAP-specific encoding of a value of this
syntax is defined by the <distinguishedName> rule from the string
representation of distinguished names [RFC4514].
UID=jsmith,DC=example,DC=net
OU=Sales+CN=J. Smith,DC=example,DC=net
CN=John Smith\, III,DC=example,DC=net
CN=Before\0dAfter,DC=example,DC=net
1.3.6.1.4.1.1466.0=#04024869,DC=example,DC=com
CN=Lu\C4\8Di\C4\87
The LDAP definition for the DN syntax is:
( 1.3.6.1.4.1.1466.115.121.1.12 DESC 'DN' )
The DN syntax corresponds to the DistinguishedName ASN.1 type from
[X.501]. Note that a BER encoded distinguished name (as used by
X.500) re-encoded into the LDAP-specific encoding is not necessarily
Legg Standards Track [Page 10]
RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
reversible to the original BER encoding since the chosen string type
in any DirectoryString components of the distinguished name is not
indicated in the LDAP-specific encoding of the distinguished name
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
A value of the Enhanced Guide syntax suggests criteria, which consist
of combinations of attribute types and filter operators, to be used
in constructing filters to search for entries of particular object
classes. The Enhanced Guide syntax improves upon the Guide syntax by
allowing the recommended depth of the search to be specified.
The LDAP-specific encoding of a value of this syntax is defined by
the following ABNF:
EnhancedGuide = object-class SHARP WSP criteria WSP
SHARP WSP subset
object-class = WSP oid WSP
subset = "baseobject" / "oneLevel" / "wholeSubtree"
criteria = and-term *( BAR and-term )
and-term = term *( AMPERSAND term )
term = EXCLAIM term /
attributetype DOLLAR match-type /
LPAREN criteria RPAREN /
true /
false
match-type = "EQ" / "SUBSTR" / "GE" / "LE" / "APPROX"
true = "?true"
false = "?false"
BAR = %x7C ; vertical bar ("|")
AMPERSAND = %x26 ; ampersand ("&")
EXCLAIM = %x21 ; exclamation mark ("!")
The <SHARP>, <WSP>, <oid>, <LPAREN>, <RPAREN>, <attributetype>, and
<DOLLAR> rules are defined in [RFC4512].
The LDAP definition for the Enhanced Guide syntax is:
( 1.3.6.1.4.1.1466.115.121.1.21 DESC 'Enhanced Guide' )
Example:
person#(sn$EQ)#oneLevel
The Enhanced Guide syntax corresponds to the EnhancedGuide ASN.1 type
from [X.520]. The EnhancedGuide type references the Criteria ASN.1
type, also from [X.520]. The <true> rule, above, represents an empty
Legg Standards Track [Page 11]
RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
"and" expression in a value of the Criteria type. The <false> rule,
above, represents an empty "or" expression in a value of the Criteria
A value of the Facsimile Telephone Number syntax is a subscriber
number of a facsimile device on the public switched telephone
network. The LDAP-specific encoding of a value of this syntax is
defined by the following ABNF:
fax-number = telephone-number *( DOLLAR fax-parameter )
telephone-number = PrintableString
fax-parameter = "twoDimensional" /
"fineResolution" /
"unlimitedLength" /
"b4Length" /
"a3Width" /
"b4Width" /
"uncompressed"
The <telephone-number> is a string of printable characters that
complies with the internationally agreed format for representing
international telephone numbers [E.123]. The <PrintableString> rule
is defined in Section 3.2. The <DOLLAR> rule is defined in
[RFC4512].
The LDAP definition for the Facsimile Telephone Number syntax is:
( 1.3.6.1.4.1.1466.115.121.1.22 DESC 'Facsimile Telephone Number')
The Facsimile Telephone Number syntax corresponds to the
FacsimileTelephoneNumber ASN.1 type from [X.520].
A value of the Fax syntax is an image that is produced using the
Group 3 facsimile process [FAX] to duplicate an object, such as a
memo. The LDAP-specific encoding of a value of this syntax is the
string of octets for a Group 3 Fax image as defined in [FAX].
The LDAP definition for the Fax syntax is:
( 1.3.6.1.4.1.1466.115.121.1.23 DESC 'Fax' )
The ASN.1 type corresponding to the Fax syntax is defined as follows,
assuming EXPLICIT TAGS:
Legg Standards Track [Page 12]
RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
Fax ::= CHOICE {
g3-facsimile [3] G3FacsimileBodyPart
}
The G3FacsimileBodyPart ASN.1 type is defined in [X.420].
A value of the Generalized Time syntax is a character string
representing a date and time. The LDAP-specific encoding of a value
of this syntax is a restriction of the format defined in [ISO8601],
and is described by the following ABNF:
GeneralizedTime = century year month day hour
[ minute [ second / leap-second ] ]
[ fraction ]
g-time-zone
century = 2(%x30-39) ; "00" to "99"
year = 2(%x30-39) ; "00" to "99"
month = ( %x30 %x31-39 ) ; "01" (January) to "09"
/ ( %x31 %x30-32 ) ; "10" to "12"
day = ( %x30 %x31-39 ) ; "01" to "09"
/ ( %x31-32 %x30-39 ) ; "10" to "29"
/ ( %x33 %x30-31 ) ; "30" to "31"
hour = ( %x30-31 %x30-39 ) / ( %x32 %x30-33 ) ; "00" to "23"
minute = %x30-35 %x30-39 ; "00" to "59"
second = ( %x30-35 %x30-39 ) ; "00" to "59"
leap-second = ( %x36 %x30 ) ; "60"
fraction = ( DOT / COMMA ) 1*(%x30-39)
g-time-zone = %x5A ; "Z"
/ g-differential
g-differential = ( MINUS / PLUS ) hour [ minute ]
MINUS = %x2D ; minus sign ("-")
The <DOT>, <COMMA>, and <PLUS> rules are defined in [RFC4512].
The above ABNF allows character strings that do not represent valid
dates (in the Gregorian calendar) and/or valid times (e.g., February
31, 1994). Such character strings SHOULD be considered invalid for
this syntax.
The time value represents coordinated universal time (equivalent to
Greenwich Mean Time) if the "Z" form of <g-time-zone> is used;
otherwise, the value represents a local time in the time zone
indicated by <g-differential>. In the latter case, coordinated
Legg Standards Track [Page 13]
RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
universal time can be calculated by subtracting the differential from
the local time. The "Z" form of <g-time-zone> SHOULD be used in
preference to <g-differential>.
If <minute> is omitted, then <fraction> represents a fraction of an
hour; otherwise, if <second> and <leap-second> are omitted, then
<fraction> represents a fraction of a minute; otherwise, <fraction>
Examples:
199412161032Z
199412160532-0500
Both example values represent the same coordinated universal time:
The LDAP definition for the Generalized Time syntax is:
( 1.3.6.1.4.1.1466.115.121.1.24 DESC 'Generalized Time' )
This syntax corresponds to the GeneralizedTime ASN.1 type from
[ASN.1], with the constraint that local time without a differential
SHALL NOT be used.
A value of the Guide syntax suggests criteria, which consist of
combinations of attribute types and filter operators, to be used in
constructing filters to search for entries of particular object
classes. The Guide syntax is obsolete and should not be used for
defining new attribute types.
The LDAP-specific encoding of a value of this syntax is defined by
the following ABNF:
Guide = [ object-class SHARP ] criteria
The <object-class> and <criteria> rules are defined in Section
3.3.10. The <SHARP> rule is defined in [RFC4512].
The LDAP definition for the Guide syntax is:
( 1.3.6.1.4.1.1466.115.121.1.25 DESC 'Guide' )
The Guide syntax corresponds to the Guide ASN.1 type from [X.520].
Legg Standards Track [Page 14]
RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
A value of the IA5 String syntax is a string of zero, one, or more
characters from International Alphabet 5 (IA5) [T.50], the
international version of the ASCII character set. The LDAP-specific
encoding of a value of this syntax is the unconverted string of
characters, which conforms to the <IA5String> rule in Section 3.2.
( 1.3.6.1.4.1.1466.115.121.1.26 DESC 'IA5 String' )
This syntax corresponds to the IA5String ASN.1 type from [ASN.1].
A value of the Integer syntax is a whole number of unlimited
magnitude. The LDAP-specific encoding of a value of this syntax is
the optionally signed decimal digit character string representation
of the number (for example, the number 1321 is represented by the
character string "1321"). The encoding is defined by the following
ABNF:
Integer = ( HYPHEN LDIGIT *DIGIT ) / number
The <HYPHEN>, <LDIGIT>, <DIGIT>, and <number> rules are defined in
[RFC4512].
The LDAP definition for the Integer syntax is:
( 1.3.6.1.4.1.1466.115.121.1.27 DESC 'INTEGER' )
This syntax corresponds to the INTEGER ASN.1 type from [ASN.1].
A value of the JPEG syntax is an image in the JPEG File Interchange
Format (JFIF), as described in [JPEG]. The LDAP-specific encoding of
a value of this syntax is the sequence of octets of the JFIF encoding
of the image.
The LDAP definition for the JPEG syntax is:
( 1.3.6.1.4.1.1466.115.121.1.28 DESC 'JPEG' )
The JPEG syntax corresponds to the following ASN.1 type:
Legg Standards Track [Page 15]
RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
JPEG ::= OCTET STRING (CONSTRAINED BY
{ -- contents octets are an image in the --
-- JPEG File Interchange Format -- })
A value of the LDAP Syntax Description syntax is the description of
an LDAP syntax. The LDAP-specific encoding of a value of this syntax
is defined by the <SyntaxDescription> rule in [RFC4512].
The LDAP definition for the LDAP Syntax Description syntax is:
( 1.3.6.1.4.1.1466.115.121.1.54 DESC 'LDAP Syntax Description' )
The above LDAP definition for the LDAP Syntax Description syntax is
itself a legal value of the LDAP Syntax Description syntax.
The ASN.1 type corresponding to the LDAP Syntax Description syntax is
defined as follows, assuming EXPLICIT TAGS:
LDAPSyntaxDescription ::= SEQUENCE {
identifier OBJECT IDENTIFIER,
description DirectoryString { ub-schema } OPTIONAL }
The DirectoryString parameterized ASN.1 type is defined in [X.520].
The value of ub-schema (an integer) is implementation defined. A
non-normative definition appears in [X.520].
A value of the Matching Rule Description syntax is the definition of
a matching rule. The LDAP-specific encoding of a value of this
syntax is defined by the <MatchingRuleDescription> rule in [RFC4512].
Example:
( 2.5.13.2 NAME 'caseIgnoreMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
Note: A line break has been added for readability; it is not part of
the syntax.
The LDAP definition for the Matching Rule Description syntax is:
( 1.3.6.1.4.1.1466.115.121.1.30 DESC 'Matching Rule Description' )
This syntax corresponds to the MatchingRuleDescription ASN.1 type
from [X.501].
Legg Standards Track [Page 16]
RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
A value of the Matching Rule Use Description syntax indicates the
attribute types to which a matching rule may be applied in an
extensibleMatch search filter [RFC4511]. The LDAP-specific encoding
of a value of this syntax is defined by the
<MatchingRuleUseDescription> rule in [RFC4512].
Example:
( 2.5.13.16 APPLIES ( givenName $ surname ) )
The LDAP definition for the Matching Rule Use Description syntax is:
( 1.3.6.1.4.1.1466.115.121.1.31
DESC 'Matching Rule Use Description' )
This syntax corresponds to the MatchingRuleUseDescription ASN.1 type
from [X.501].
A value of the Name and Optional UID syntax is the distinguished name
[RFC4512] of an entity optionally accompanied by a unique identifier
that serves to differentiate the entity from others with an identical
distinguished name.
The LDAP-specific encoding of a value of this syntax is defined by
the following ABNF:
NameAndOptionalUID = distinguishedName [ SHARP BitString ]
The <BitString> rule is defined in Section 3.3.2. The
<distinguishedName> rule is defined in [RFC4514]. The <SHARP> rule
is defined in [RFC4512].
Note that although the '#' character may occur in the string
representation of a distinguished name, no additional escaping of
this character is performed when a <distinguishedName> is encoded in
a <NameAndOptionalUID>.
Example:
1.3.6.1.4.1.1466.0=#04024869,O=Test,C=GB#'0101'B
The LDAP definition for the Name and Optional UID syntax is:
( 1.3.6.1.4.1.1466.115.121.1.34 DESC 'Name And Optional UID' )
Legg Standards Track [Page 17]
RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
This syntax corresponds to the NameAndOptionalUID ASN.1 type from
[X.520].
A value of the Name Form Description syntax is the definition of a
name form, which regulates how entries may be named. The LDAP-
specific encoding of a value of this syntax is defined by the
<NameFormDescription> rule in [RFC4512].
Example:
( 2.5.15.3 NAME 'orgNameForm' OC organization MUST o )
The LDAP definition for the Name Form Description syntax is:
( 1.3.6.1.4.1.1466.115.121.1.35 DESC 'Name Form Description' )
This syntax corresponds to the NameFormDescription ASN.1 type from
[X.501].
A value of the Numeric String syntax is a sequence of one or more
numerals and spaces. The LDAP-specific encoding of a value of this
syntax is the unconverted string of characters, which conforms to the
following ABNF:
NumericString = 1*(DIGIT / SPACE)
The <DIGIT> and <SPACE> rules are defined in [RFC4512].
Example:
15 079 672 281
The LDAP definition for the Numeric String syntax is:
( 1.3.6.1.4.1.1466.115.121.1.36 DESC 'Numeric String' )
This syntax corresponds to the NumericString ASN.1 type from [ASN.1].