8 draft-ietf-ldapbis-syntaxes-11.txt eB2Bcom
9 Intended Category: Standards Track 23 June 2005
10 Obsoletes: RFC 2252, RFC 2256 Updates: RFC 3698
13 Lightweight Directory Access Protocol (LDAP):
14 Syntaxes and Matching Rules
16 Copyright (C) The Internet Society (2005). All Rights Reserved.
20 By submitting this Internet-draft, each author represents that any
21 applicable patent or other IPR claims of which he or she is aware
22 have been or will be disclosed, and any of which he or she becomes
23 aware will be disclosed, in accordance with Section 6 of BCP 79.
25 By submitting this Internet-draft, I accept the provisions of Section
28 Internet-Drafts are working documents of the Internet Engineering
29 Task Force (IETF), its areas, and its working groups. Note that
30 other groups may also distribute working documents as
33 Internet-Drafts are draft documents valid for a maximum of six months
34 and may be updated, replaced, or obsoleted by other documents at any
35 time. It is inappropriate to use Internet-Drafts as reference
36 material or to cite them other than as "work in progress".
38 The list of current Internet-Drafts can be accessed at
39 http://www.ietf.org/1id-abstracts.html
41 The list of Internet-Draft Shadow Directories can be accessed at
42 http://www.ietf.org/shadow.html
44 This document is intended to be, after appropriate review and
45 revision, submitted to the RFC Editor as a Standard Track document.
46 Distribution of this document is unlimited. Technical discussion of
47 this document should take place on the IETF LDAP Revision Working
48 Group (LDAPbis) mailing list <ietf-ldapbis@openldap.org>. Please
49 send editorial comments directly to the editor
50 <steven.legg@eb2bcom.com>.
52 This Internet-Draft expires on 23 December 2005.
58 Legg Expires 23 December 2005 [Page 1]
60 INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
63 Each attribute stored in a Lightweight Directory Access Protocol
64 (LDAP) directory, and whose values may be transfered in the LDAP
65 protocol, has a defined syntax which constrains the structure and
66 format of its values. The comparison semantics for values of a
67 syntax are not part of the syntax definition but are instead provided
68 through separately defined matching rules. Matching rules specify an
69 argument, an assertion value, which also has a defined syntax. This
70 document defines a base set of syntaxes and matching rules for use in
71 defining attributes for LDAP directories.
114 Legg Expires 23 December 2005 [Page 2]
116 INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
121 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
122 2. Conventions. . . . . . . . . . . . . . . . . . . . . . . . . . 5
123 3. Syntaxes . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
124 3.1. General Considerations . . . . . . . . . . . . . . . . . 6
125 3.2. Common Definitions . . . . . . . . . . . . . . . . . . . 7
126 3.3. Syntax Definitions . . . . . . . . . . . . . . . . . . . 7
127 3.3.1. Attribute Type Description . . . . . . . . . . . 7
128 3.3.2. Bit String . . . . . . . . . . . . . . . . . . . 8
129 3.3.3. Boolean. . . . . . . . . . . . . . . . . . . . . 8
130 3.3.4. Country String . . . . . . . . . . . . . . . . . 8
131 3.3.5. Delivery Method. . . . . . . . . . . . . . . . . 9
132 3.3.6. Directory String . . . . . . . . . . . . . . . . 9
133 3.3.7. DIT Content Rule Description . . . . . . . . . . 10
134 3.3.8. DIT Structure Rule Description . . . . . . . . . 11
135 3.3.9. DN . . . . . . . . . . . . . . . . . . . . . . . 11
136 3.3.10. Enhanced Guide . . . . . . . . . . . . . . . . . 12
137 3.3.11. Facsimile Telephone Number . . . . . . . . . . . 13
138 3.3.12. Fax. . . . . . . . . . . . . . . . . . . . . . . 13
139 3.3.13. Generalized Time . . . . . . . . . . . . . . . . 14
140 3.3.14. Guide. . . . . . . . . . . . . . . . . . . . . . 15
141 3.3.15. IA5 String . . . . . . . . . . . . . . . . . . . 16
142 3.3.16. Integer. . . . . . . . . . . . . . . . . . . . . 16
143 3.3.17. JPEG . . . . . . . . . . . . . . . . . . . . . . 16
144 3.3.18. LDAP Syntax Description. . . . . . . . . . . . . 17
145 3.3.19. Matching Rule Description. . . . . . . . . . . . 17
146 3.3.20. Matching Rule Use Description. . . . . . . . . . 18
147 3.3.21. Name and Optional UID. . . . . . . . . . . . . . 18
148 3.3.22. Name Form Description. . . . . . . . . . . . . . 19
149 3.3.23. Numeric String . . . . . . . . . . . . . . . . . 19
150 3.3.24. Object Class Description . . . . . . . . . . . . 19
151 3.3.25. Octet String . . . . . . . . . . . . . . . . . . 20
152 3.3.26. OID. . . . . . . . . . . . . . . . . . . . . . . 20
153 3.3.27. Other Mailbox. . . . . . . . . . . . . . . . . . 21
154 3.3.28. Postal Address . . . . . . . . . . . . . . . . . 21
155 3.3.29. Printable String . . . . . . . . . . . . . . . . 22
156 3.3.30. Substring Assertion. . . . . . . . . . . . . . . 23
157 3.3.31. Telephone Number . . . . . . . . . . . . . . . . 23
158 3.3.32. Teletex Terminal Identifier. . . . . . . . . . . 24
159 3.3.33. Telex Number . . . . . . . . . . . . . . . . . . 25
160 3.3.34. UTC Time . . . . . . . . . . . . . . . . . . . . 25
161 4. Matching Rules . . . . . . . . . . . . . . . . . . . . . . . . 26
162 4.1. General Considerations . . . . . . . . . . . . . . . . . 26
163 4.2. Matching Rule Definitions. . . . . . . . . . . . . . . . 28
164 4.2.1. bitStringMatch . . . . . . . . . . . . . . . . . 28
165 4.2.2. booleanMatch . . . . . . . . . . . . . . . . . . 29
166 4.2.3. caseExactIA5Match. . . . . . . . . . . . . . . . 29
170 Legg Expires 23 December 2005 [Page 3]
172 INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
175 4.2.4. caseExactMatch . . . . . . . . . . . . . . . . . 30
176 4.2.5. caseExactOrderingMatch . . . . . . . . . . . . . 30
177 4.2.6. caseExactSubstringsMatch . . . . . . . . . . . . 31
178 4.2.7. caseIgnoreIA5Match . . . . . . . . . . . . . . . 31
179 4.2.8. caseIgnoreIA5SubstringsMatch . . . . . . . . . . 32
180 4.2.9. caseIgnoreListMatch. . . . . . . . . . . . . . . 32
181 4.2.10. caseIgnoreListSubstringsMatch. . . . . . . . . . 33
182 4.2.11. caseIgnoreMatch. . . . . . . . . . . . . . . . . 33
183 4.2.12. caseIgnoreOrderingMatch. . . . . . . . . . . . . 34
184 4.2.13. caseIgnoreSubstringsMatch. . . . . . . . . . . . 34
185 4.2.14. directoryStringFirstComponentMatch . . . . . . . 35
186 4.2.15. distinguishedNameMatch . . . . . . . . . . . . . 36
187 4.2.16. generalizedTimeMatch . . . . . . . . . . . . . . 36
188 4.2.17. generalizedTimeOrderingMatch . . . . . . . . . . 37
189 4.2.18. integerFirstComponentMatch . . . . . . . . . . . 37
190 4.2.19. integerMatch . . . . . . . . . . . . . . . . . . 38
191 4.2.20. integerOrderingMatch . . . . . . . . . . . . . . 38
192 4.2.21. keywordMatch . . . . . . . . . . . . . . . . . . 38
193 4.2.22. numericStringMatch . . . . . . . . . . . . . . . 39
194 4.2.23. numericStringOrderingMatch . . . . . . . . . . . 39
195 4.2.24. numericStringSubstringsMatch . . . . . . . . . . 40
196 4.2.25. objectIdentifierFirstComponentMatch. . . . . . . 40
197 4.2.26. objectIdentifierMatch. . . . . . . . . . . . . . 41
198 4.2.27. octetStringMatch . . . . . . . . . . . . . . . . 41
199 4.2.28. octetStringOrderingMatch . . . . . . . . . . . . 42
200 4.2.29. telephoneNumberMatch . . . . . . . . . . . . . . 42
201 4.2.30. telephoneNumberSubstringsMatch . . . . . . . . . 43
202 4.2.31. uniqueMemberMatch. . . . . . . . . . . . . . . . 44
203 4.2.32. wordMatch. . . . . . . . . . . . . . . . . . . . 44
204 5. Security Considerations. . . . . . . . . . . . . . . . . . . . 44
205 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 45
206 7. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 45
207 Appendix A. Summary of Syntax Object Identifiers . . . . . . . . . 47
208 Appendix B. Changes from RFC 2252. . . . . . . . . . . . . . . . . 48
209 Normative References . . . . . . . . . . . . . . . . . . . . . . . 50
210 Informative References . . . . . . . . . . . . . . . . . . . . . . 52
211 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 53
212 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 53
216 Each attribute stored in a Lightweight Directory Access Protocol
217 (LDAP) directory [ROADMAP], and whose values may be transfered in the
218 LDAP protocol [PROT], has a defined syntax (i.e., data type) which
219 constrains the structure and format of its values. The comparison
220 semantics for values of a syntax are not part of the syntax
221 definition but are instead provided through separately defined
222 matching rules. Matching rules specify an argument, an assertion
226 Legg Expires 23 December 2005 [Page 4]
228 INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
231 value, which also has a defined syntax. This document defines a base
232 set of syntaxes and matching rules for use in defining attributes for
235 Readers are advised to familiarize themselves with the Directory
236 Information Models [MODELS] before reading the rest of this document.
237 Section 3 provides definitions for the base set of LDAP syntaxes.
238 Section 4 provides definitions for the base set of matching rules for
241 This document is a integral part of the LDAP technical specification
242 [ROADMAP] which obsoletes the previously defined LDAP technical
243 specification [RFC3377] in its entirety.
245 Sections 4, 5 and 7 of RFC 2252 [RFC2252] are obsoleted by [MODELS].
246 The remainder of RFC 2252 is obsoleted by this document. Sections 6
247 and 8 of RFC 2256 [RFC2256] are obsoleted by this document. The
248 remainder of RFC 2256 is obsoleted by [SCHEMA] and [MODELS]. All but
249 Section 2.11 of RFC 3698 [RFC3698] is obsoleted by this document.
251 A number of schema elements which were included in the previous
252 revision of the LDAP technical specification are not included in this
253 revision of LDAP. Public Key Infrastructure schema elements are now
254 specified in [LDAP-PKI]. Unless reintroduced in future technical
255 specifications, the remainder are to be considered Historic.
257 The changes with respect to RFC 2252 are described in Appendix B of
262 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
263 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
264 document are to be interpreted as described in BCP 14, RFC 2119
267 Syntax definitions are written according to the <SyntaxDescription>
268 ABNF [ABNF] rule specified in [MODELS], and matching rule definitions
269 are written according to the <MatchingRuleDescription> ABNF rule
270 specified in [MODELS], except that the syntax and matching rule
271 definitions provided in this document are line-wrapped for
272 readability. When such definitions are transfered as attribute
273 values in the LDAP protocol (e.g., as values of the ldapSyntaxes and
274 matchingRules attributes [MODELS] respectively) then those values
275 would not contain line breaks.
282 Legg Expires 23 December 2005 [Page 5]
284 INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
287 Syntax definitions constrain the structure of attribute values stored
288 in an LDAP directory, and determine the representation of attribute
289 and assertion values transfered in the LDAP protocol.
291 Syntaxes that are required for directory operation, or that are in
292 common use, are specified in this section. Servers SHOULD recognize
293 all the syntaxes listed in this document, but are not required to
294 otherwise support them, and MAY recognise or support other syntaxes.
295 However, the definition of additional arbitrary syntaxes is
296 discouraged since it will hinder interoperability. Client and server
297 implementations typically do not have the ability to dynamically
298 recognize new syntaxes.
300 3.1. General Considerations
302 The description of each syntax specifies how attribute or assertion
303 values conforming to the syntax are to be represented when transfered
304 in the LDAP protocol [PROT]. This representation is referred to as
305 the LDAP-specific encoding to distinguish it from other methods of
306 encoding attribute values (e.g., the Basic Encoding Rules (BER)
307 encoding [BER] used by X.500 [X.500] directories).
309 The LDAP-specific encoding of a given attribute syntax always
310 produces octet-aligned values. To the greatest extent possible,
311 encoding rules for LDAP syntaxes should produce character strings
312 that can be displayed with little or no translation by clients
313 implementing LDAP. However, clients MUST NOT assume that the
314 LDAP-specific encoding of a value of an unrecognized syntax is a
315 human-readable character string. There are a few cases (e.g., the
316 JPEG syntax) when it is not reasonable to produce a human-readable
319 Each LDAP syntax is uniquely identified with an object identifier
320 [ASN.1] represented in the dotted-decimal format (short descriptive
321 names are not defined for syntaxes). These object identifiers are
322 not intended to be displayed to users. The object identifiers for
323 the syntaxes defined in this document are summarized in Appendix A.
325 A suggested minimum upper bound on the number of characters in an
326 attribute value with a string-based syntax, or the number of octets
327 in a value for all other syntaxes, MAY be indicated by appending the
328 bound inside of curly braces following the syntax's OBJECT IDENTIFIER
329 in an attribute type definition (see the <noidlen> rule in [MODELS]).
330 Such a bound is not considered part of the syntax identifier.
332 For example, "1.3.6.1.4.1.1466.115.121.1.15{64}" in an attribute
333 definition suggests that the directory server will allow a value of
334 the attribute to be up to 64 characters long, although it may allow
338 Legg Expires 23 December 2005 [Page 6]
340 INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
343 longer character strings. Note that a single character of the
344 Directory String syntax can be encoded in more than one octet since
345 UTF-8 [UTF8] is a variable-length encoding. Therefore a 64 character
346 string may be more than 64 octets in length.
348 3.2. Common Definitions
350 The following ABNF rules are used in a number of the syntax
351 definitions in Section 3.3.
353 PrintableCharacter = ALPHA / DIGIT / SQUOTE / LPAREN / RPAREN /
354 PLUS / COMMA / HYPHEN / DOT / EQUALS /
355 SLASH / COLON / QUESTION / SPACE
356 PrintableString = 1*PrintableCharacter
357 IA5String = *(%x00-7F)
358 SLASH = %x2F ; forward slash ("/")
359 COLON = %x3A ; colon (":")
360 QUESTION = %x3F ; question mark ("?")
362 The <ALPHA>, <DIGIT>, <SQUOTE>, <LPAREN>, <RPAREN>, <PLUS>, <COMMA>,
363 <HYPHEN>, <DOT>, <EQUALS> and <SPACE> rules are defined in [MODELS].
365 3.3. Syntax Definitions
367 3.3.1. Attribute Type Description
369 A value of the Attribute Type Description syntax is the definition of
370 an attribute type. The LDAP-specific encoding of a value of this
371 syntax is defined by the <AttributeTypeDescription> rule in [MODELS].
373 For example, the following definition of the createTimestamp
374 attribute type from [MODELS] is also a value of the Attribute Type
375 Description syntax (note: line breaks have been added for
376 readability - they are not part of the value when transfered in
379 ( 2.5.18.1 NAME 'createTimestamp'
380 EQUALITY generalizedTimeMatch
381 ORDERING generalizedTimeOrderingMatch
382 SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
383 SINGLE-VALUE NO-USER-MODIFICATION
384 USAGE directoryOperation )
386 The LDAP definition for the Attribute Type Description syntax is:
388 ( 1.3.6.1.4.1.1466.115.121.1.3 DESC 'Attribute Type Description' )
390 This syntax corresponds to the AttributeTypeDescription ASN.1 type
394 Legg Expires 23 December 2005 [Page 7]
396 INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
403 A value of the Bit String syntax is a sequence of binary digits. The
404 LDAP-specific encoding of a value of this syntax is defined by the
407 BitString = SQUOTE *binary-digit SQUOTE "B"
408 binary-digit = "0" / "1"
410 The <SQUOTE> rule is defined in [MODELS].
415 The LDAP definition for the Bit String syntax is:
417 ( 1.3.6.1.4.1.1466.115.121.1.6 DESC 'Bit String' )
419 This syntax corresponds to the BIT STRING ASN.1 type from [ASN.1].
423 A value of the Boolean syntax is one of the Boolean values, true or
424 false. The LDAP-specific encoding of a value of this syntax is
425 defined by the following ABNF:
427 Boolean = "TRUE" / "FALSE"
429 The LDAP definition for the Boolean syntax is:
431 ( 1.3.6.1.4.1.1466.115.121.1.7 DESC 'Boolean' )
433 This syntax corresponds to the BOOLEAN ASN.1 type from [ASN.1].
435 3.3.4. Country String
437 A value of the Country String syntax is one of the two-character
438 codes from ISO 3166 [ISO3166] for representing a country. The
439 LDAP-specific encoding of a value of this syntax is defined by the
442 CountryString = 2(PrintableCharacter)
444 The <PrintableCharacter> rule is defined in Section 3.2.
450 Legg Expires 23 December 2005 [Page 8]
452 INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
458 The LDAP definition for the Country String syntax is:
460 ( 1.3.6.1.4.1.1466.115.121.1.11 DESC 'Country String' )
462 This syntax corresponds to the following ASN.1 type from [X.520]:
464 PrintableString (SIZE (2)) -- ISO 3166 codes only
466 3.3.5. Delivery Method
468 A value of the Delivery Method syntax is a sequence of items that
469 indicate, in preference order, the service(s) by which an entity is
470 willing and/or capable of receiving messages. The LDAP-specific
471 encoding of a value of this syntax is defined by the following ABNF:
473 DeliveryMethod = pdm *( WSP DOLLAR WSP pdm )
475 pdm = "any" / "mhs" / "physical" / "telex" / "teletex" /
476 "g3fax" / "g4fax" / "ia5" / "videotex" / "telephone"
478 The <WSP> and <DOLLAR> rules are defined in [MODELS].
483 The LDAP definition for the Delivery Method syntax is:
485 ( 1.3.6.1.4.1.1466.115.121.1.14 DESC 'Delivery Method' )
487 This syntax corresponds to the following ASN.1 type from [X.520]:
489 SEQUENCE OF INTEGER {
490 any-delivery-method (0),
492 physical-delivery (2),
494 teletex-delivery (4),
495 g3-facsimile-delivery (5),
496 g4-facsimile-delivery (6),
497 ia5-terminal-delivery (7),
498 videotex-delivery (8),
499 telephone-delivery (9) }
501 3.3.6. Directory String
506 Legg Expires 23 December 2005 [Page 9]
508 INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
511 A value of the Directory String syntax is a string of one or more
512 arbitrary characters from the Universal Character Set (UCS) [UCS]. A
513 zero length character string is not permitted. The LDAP-specific
514 encoding of a value of this syntax is the UTF-8 encoding [UTF8] of
515 the character string. Such encodings conform to the following ABNF:
517 DirectoryString = 1*UTF8
519 The <UTF8> rule is defined in [MODELS].
522 This is a value of Directory String containing #!%#@.
524 Servers and clients MUST be prepared to receive arbitrary UCS code
525 points, including code points outside the range of printable ASCII
526 and code points not presently assigned to any character.
528 Attribute type definitions using the Directory String syntax should
529 not restrict the format of Directory String values, e.g., by
530 requiring that the character string conforms to specific patterns
531 described by ABNF. A new syntax should be defined in such cases.
533 The LDAP definition for the Directory String syntax is:
535 ( 1.3.6.1.4.1.1466.115.121.1.15 DESC 'Directory String' )
537 This syntax corresponds to the DirectoryString parameterized ASN.1
540 The DirectoryString ASN.1 type allows a choice between the
541 TeletexString, PrintableString or UniversalString ASN.1 types from
542 [ASN.1]. However, note that the chosen alternative is not indicated
543 in the LDAP-specific encoding of a Directory String value.
545 Implementations which convert Directory String values from the
546 LDAP-specific encoding to the BER encoding used by X.500 must choose
547 an alternative that permits the particular characters in the string,
548 and must convert the characters from the UTF-8 encoding into the
549 character encoding of the chosen alternative. When converting
550 Directory String values from the BER encoding to the LDAP-specific
551 encoding the characters must be converted from the character encoding
552 of the chosen alternative into the UTF-8 encoding. These conversions
553 SHOULD be done in a manner consistent with the Transcode step of the
554 string preparation algorithms [PREP] for LDAP.
556 3.3.7. DIT Content Rule Description
558 A value of the DIT Content Rule Description syntax is the definition
562 Legg Expires 23 December 2005 [Page 10]
564 INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
567 of a DIT (Directory Information Tree) content rule. The
568 LDAP-specific encoding of a value of this syntax is defined by the
569 <DITContentRuleDescription> rule in [MODELS].
572 ( 2.5.6.4 DESC 'content rule for organization'
573 NOT ( x121Address $ telexNumber ) )
575 Note: a line break has been added for readability - it is not part
578 The LDAP definition for the DIT Content Rule Description syntax is:
580 ( 1.3.6.1.4.1.1466.115.121.1.16
581 DESC 'DIT Content Rule Description' )
583 This syntax corresponds to the DITContentRuleDescription ASN.1 type
586 3.3.8. DIT Structure Rule Description
588 A value of the DIT Structure Rule Description syntax is the
589 definition of a DIT structure rule. The LDAP-specific encoding of a
590 value of this syntax is defined by the <DITStructureRuleDescription>
594 ( 2 DESC 'organization structure rule' FORM 2.5.15.3 )
596 The LDAP definition for the DIT Structure Rule Description syntax is:
598 ( 1.3.6.1.4.1.1466.115.121.1.17
599 DESC 'DIT Structure Rule Description' )
601 This syntax corresponds to the DITStructureRuleDescription ASN.1 type
606 A value of the DN syntax is the (purported) distinguished name (DN)
607 of an entry [MODELS]. The LDAP-specific encoding of a value of this
608 syntax is defined by the <distinguishedName> rule from the string
609 representation of distinguished names [LDAPDN].
611 Examples (from [LDAPDN]):
612 UID=jsmith,DC=example,DC=net
613 OU=Sales+CN=J. Smith,DC=example,DC=net
614 CN=John Smith\, III,DC=example,DC=net
618 Legg Expires 23 December 2005 [Page 11]
620 INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
623 CN=Before\0dAfter,DC=example,DC=net
624 1.3.6.1.4.1.1466.0=#04024869,DC=example,DC=com
627 The LDAP definition for the DN syntax is:
629 ( 1.3.6.1.4.1.1466.115.121.1.12 DESC 'DN' )
631 The DN syntax corresponds to the DistinguishedName ASN.1 type from
632 [X.501]. Note that a BER encoded distinguished name (as used by
633 X.500) re-encoded into the LDAP-specific encoding is not necessarily
634 reversible to the original BER encoding since the chosen string type
635 in any DirectoryString components of the distinguished name is not
636 indicated in the LDAP-specific encoding of the distinguished name
639 3.3.10. Enhanced Guide
641 A value of the Enhanced Guide syntax suggests criteria, which consist
642 of combinations of attribute types and filter operators, to be used
643 in constructing filters to search for entries of particular object
644 classes. The Enhanced Guide syntax improves upon the Guide syntax by
645 allowing the recommended depth of the search to be specified.
647 The LDAP-specific encoding of a value of this syntax is defined by
650 EnhancedGuide = object-class SHARP WSP criteria WSP
652 object-class = WSP oid WSP
653 subset = "baseobject" / "oneLevel" / "wholeSubtree"
655 criteria = and-term *( BAR and-term )
656 and-term = term *( AMPERSAND term )
657 term = EXCLAIM term /
658 attributetype DOLLAR match-type /
659 LPAREN criteria RPAREN /
662 match-type = "EQ" / "SUBSTR" / "GE" / "LE" / "APPROX"
665 BAR = %x7C ; vertical bar ("|")
666 AMPERSAND = %x26 ; ampersand ("&")
667 EXCLAIM = %x21 ; exclamation mark ("!")
669 The <SHARP>, <WSP>, <oid>, <LPAREN>, <RPAREN>, <attributetype> and
670 <DOLLAR> rules are defined in [MODELS].
674 Legg Expires 23 December 2005 [Page 12]
676 INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
679 The LDAP definition for the Enhanced Guide syntax is:
681 ( 1.3.6.1.4.1.1466.115.121.1.21 DESC 'Enhanced Guide' )
685 person#(sn$EQ)#oneLevel
687 The Enhanced Guide syntax corresponds to the EnhancedGuide ASN.1 type
688 from [X.520]. The EnhancedGuide type references the Criteria ASN.1
689 type, also from [X.520]. The <true> rule above represents an empty
690 "and" expression in a value of the Criteria type. The <false> rule
691 above represents an empty "or" expression in a value of the Criteria
694 3.3.11. Facsimile Telephone Number
696 A value of the Facsimile Telephone Number syntax is a subscriber
697 number of a facsimile device on the public switched telephone
698 network. The LDAP-specific encoding of a value of this syntax is
699 defined by the following ABNF:
701 fax-number = telephone-number *( DOLLAR fax-parameter )
702 telephone-number = PrintableString
703 fax-parameter = "twoDimensional" /
711 The <telephone-number> is a string of printable characters that
712 complies with the internationally agreed format for representing
713 international telephone numbers [E.123]. The <PrintableString> rule
714 is defined in Section 3.2. The <DOLLAR> rule is defined in [MODELS].
716 The LDAP definition for the Facsimile Telephone Number syntax is:
718 ( 1.3.6.1.4.1.1466.115.121.1.22 DESC 'Facsimile Telephone Number')
720 The Facsimile Telephone Number syntax corresponds to the
721 FacsimileTelephoneNumber ASN.1 type from [X.520].
725 A value of the Fax syntax is an image which is produced using the
726 Group 3 facsimile process [FAX] to duplicate an object, such as a
730 Legg Expires 23 December 2005 [Page 13]
732 INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
735 memo. The LDAP-specific encoding of a value of this syntax is the
736 string of octets for a Group 3 Fax image as defined in [FAX].
738 The LDAP definition for the Fax syntax is:
740 ( 1.3.6.1.4.1.1466.115.121.1.23 DESC 'Fax' )
742 The ASN.1 type corresponding to the Fax syntax is defined as follows,
743 assuming EXPLICIT TAGS:
746 g3-facsimile [3] G3FacsimileBodyPart
749 The G3FacsimileBodyPart ASN.1 type is defined in [X.420].
751 3.3.13. Generalized Time
753 A value of the Generalized Time syntax is a character string
754 representing a date and time. The LDAP-specific encoding of a value
755 of this syntax is a restriction of the format defined in [ISO8601],
756 and is described by the following ABNF:
758 GeneralizedTime = century year month day hour
759 [ minute [ second / leap-second ] ]
763 century = 2(%x30-39) ; "00" to "99"
764 year = 2(%x30-39) ; "00" to "99"
765 month = ( %x30 %x31-39 ) ; "01" (January) to "09"
766 / ( %x31 %x30-32 ) ; "10" to "12"
767 day = ( %x30 %x31-39 ) ; "01" to "09"
768 / ( %x31-32 %x30-39 ) ; "10" to "29"
769 / ( %x33 %x30-31 ) ; "30" to "31"
770 hour = ( %x30-31 %x30-39 ) / ( %x32 %x30-33 ) ; "00" to "23"
771 minute = %x30-35 %x30-39 ; "00" to "59"
773 second = ( %x30-35 %x30-39 ) ; "00" to "59"
774 leap-second = ( %x36 %x30 ) ; "60"
776 fraction = ( DOT / COMMA ) 1*(%x30-39)
777 g-time-zone = %x5A ; "Z"
779 g-differential = ( MINUS / PLUS ) hour [ minute ]
780 MINUS = %x2D ; minus sign ("-")
782 The <DOT>, <COMMA> and <PLUS> rules are defined in [MODELS].
786 Legg Expires 23 December 2005 [Page 14]
788 INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
791 The above ABNF allows character strings which do not represent valid
792 dates (in the Gregorian calendar) and/or valid times (e.g., February
793 31, 1994). Such character strings SHOULD be considered invalid for
796 The time value represents coordinated universal time (equivalent to
797 Greenwich Mean Time) if the "Z" form of <g-time-zone> is used,
798 otherwise the value represents a local time in the time zone
799 indicated by <g-differential>. In the latter case, coordinated
800 universal time can be calculated by subtracting the differential from
801 the local time. The "Z" form of <g-time-zone> SHOULD be used in
802 preference to <g-differential>.
804 If <minute> is omitted then <fraction> represents a fraction of an
805 hour, otherwise if <second> and <leap-second> are omitted then
806 <fraction> represents a fraction of a minute, otherwise <fraction>
807 represents a fraction of a second.
813 Both example values represent the same coordinated universal time:
814 10:32 AM, December 16, 1994.
816 The LDAP definition for the Generalized Time syntax is:
818 ( 1.3.6.1.4.1.1466.115.121.1.24 DESC 'Generalized Time' )
820 This syntax corresponds to the GeneralizedTime ASN.1 type from
821 [ASN.1], with the constraint that local time without a differential
826 A value of the Guide syntax suggests criteria, which consist of
827 combinations of attribute types and filter operators, to be used in
828 constructing filters to search for entries of particular object
829 classes. The Guide syntax is obsolete and should not be used for
830 defining new attribute types.
832 The LDAP-specific encoding of a value of this syntax is defined by
835 Guide = [ object-class SHARP ] criteria
837 The <object-class> and <criteria> rules are defined in Section
838 3.3.10. The <SHARP> rule is defined in [MODELS].
842 Legg Expires 23 December 2005 [Page 15]
844 INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
847 The LDAP definition for the Guide syntax is:
849 ( 1.3.6.1.4.1.1466.115.121.1.25 DESC 'Guide' )
851 The Guide syntax corresponds to the Guide ASN.1 type from [X.520].
855 A value of the IA5 String syntax is a string of zero, one or more
856 characters from International Alphabet 5 (IA5) [T.50], the
857 international version of the ASCII character set. The LDAP-specific
858 encoding of a value of this syntax is the unconverted string of
859 characters, which conforms to the <IA5String> rule in Section 3.2.
861 The LDAP definition for the IA5 String syntax is:
863 ( 1.3.6.1.4.1.1466.115.121.1.26 DESC 'IA5 String' )
865 This syntax corresponds to the IA5String ASN.1 type from [ASN.1].
869 A value of the Integer syntax is a whole number of unlimited
870 magnitude. The LDAP-specific encoding of a value of this syntax is
871 the optionally signed decimal digit character string representation
872 of the number (so, for example, the number 1321 is represented by the
873 character string "1321"). The encoding is defined by the following
876 Integer = ( HYPHEN LDIGIT *DIGIT ) / number
878 The <HYPHEN>, <LDIGIT>, <DIGIT> and <number> rules are defined in
881 The LDAP definition for the Integer syntax is:
883 ( 1.3.6.1.4.1.1466.115.121.1.27 DESC 'INTEGER' )
885 This syntax corresponds to the INTEGER ASN.1 type from [ASN.1].
889 A value of the JPEG syntax is an image in the JPEG File Interchange
890 Format (JFIF), as described in [JPEG]. The LDAP-specific encoding of
891 a value of this syntax is the sequence of octets of the JFIF encoding
894 The LDAP definition for the JPEG syntax is:
898 Legg Expires 23 December 2005 [Page 16]
900 INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
903 ( 1.3.6.1.4.1.1466.115.121.1.28 DESC 'JPEG' )
905 The JPEG syntax corresponds to the following ASN.1 type:
907 JPEG ::= OCTET STRING (CONSTRAINED BY
908 { -- contents octets are an image in the --
909 -- JPEG File Interchange Format -- })
911 3.3.18. LDAP Syntax Description
913 A value of the LDAP Syntax Description syntax is the description of
914 an LDAP syntax. The LDAP-specific encoding of a value of this syntax
915 is defined by the <SyntaxDescription> rule in [MODELS].
917 The LDAP definition for the LDAP Syntax Description syntax is:
919 ( 1.3.6.1.4.1.1466.115.121.1.54 DESC 'LDAP Syntax Description' )
921 The above LDAP definition for the LDAP Syntax Description syntax is
922 itself a legal value of the LDAP Syntax Description syntax.
924 The ASN.1 type corresponding to the LDAP Syntax Description syntax is
925 defined as follows, assuming EXPLICIT TAGS:
927 LDAPSyntaxDescription ::= SEQUENCE {
928 identifier OBJECT IDENTIFIER,
929 description DirectoryString { ub-schema } OPTIONAL }
931 The DirectoryString parameterized ASN.1 type is defined in [X.520].
933 The value of ub-schema (an integer) is implementation defined. A
934 non-normative definition appears in [X.520].
936 3.3.19. Matching Rule Description
938 A value of the Matching Rule Description syntax is the definition of
939 a matching rule. The LDAP-specific encoding of a value of this
940 syntax is defined by the <MatchingRuleDescription> rule in [MODELS].
943 ( 2.5.13.2 NAME 'caseIgnoreMatch'
944 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
946 Note: a line break has been added for readability - it is not part of
949 The LDAP definition for the Matching Rule Description syntax is:
954 Legg Expires 23 December 2005 [Page 17]
956 INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
959 ( 1.3.6.1.4.1.1466.115.121.1.30 DESC 'Matching Rule Description' )
961 This syntax corresponds to the MatchingRuleDescription ASN.1 type
964 3.3.20. Matching Rule Use Description
966 A value of the Matching Rule Use Description syntax indicates the
967 attribute types to which a matching rule may be applied in an
968 extensibleMatch search filter [PROT]. The LDAP-specific encoding of
969 a value of this syntax is defined by the <MatchingRuleUseDescription>
973 ( 2.5.13.16 APPLIES ( givenName $ surname ) )
975 The LDAP definition for the Matching Rule Use Description syntax is:
977 ( 1.3.6.1.4.1.1466.115.121.1.31
978 DESC 'Matching Rule Use Description' )
980 This syntax corresponds to the MatchingRuleUseDescription ASN.1 type
983 3.3.21. Name and Optional UID
985 A value of the Name and Optional UID syntax is the distinguished name
986 [MODELS] of an entity optionally accompanied by a unique identifier
987 that serves to differentiate the entity from others with an identical
990 The LDAP-specific encoding of a value of this syntax is defined by
993 NameAndOptionalUID = distinguishedName [ SHARP BitString ]
995 The <BitString> rule is defined in Section 3.3.2. The
996 <distinguishedName> rule is defined in [LDAPDN]. The <SHARP> rule is
999 Note that although the '#' character may occur in the string
1000 representation of a distinguished name, no additional escaping of
1001 this character is performed when a <distinguishedName> is encoded in
1002 a <NameAndOptionalUID>.
1005 1.3.6.1.4.1.1466.0=#04024869,O=Test,C=GB#'0101'B
1010 Legg Expires 23 December 2005 [Page 18]
1012 INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
1015 The LDAP definition for the Name and Optional UID syntax is:
1017 ( 1.3.6.1.4.1.1466.115.121.1.34 DESC 'Name And Optional UID' )
1019 This syntax corresponds to the NameAndOptionalUID ASN.1 type from
1022 3.3.22. Name Form Description
1024 A value of the Name Form Description syntax is the definition of a
1025 name form, which regulates how entries may be named. The
1026 LDAP-specific encoding of a value of this syntax is defined by the
1027 <NameFormDescription> rule in [MODELS].
1030 ( 2.5.15.3 NAME 'orgNameForm' OC organization MUST o )
1032 The LDAP definition for the Name Form Description syntax is:
1034 ( 1.3.6.1.4.1.1466.115.121.1.35 DESC 'Name Form Description' )
1036 This syntax corresponds to the NameFormDescription ASN.1 type from
1039 3.3.23. Numeric String
1041 A value of the Numeric String syntax is a sequence of one or more
1042 numerals and spaces. The LDAP-specific encoding of a value of this
1043 syntax is the unconverted string of characters, which conforms to the
1046 NumericString = 1*(DIGIT / SPACE)
1048 The <DIGIT> and <SPACE> rules are defined in [MODELS].
1053 The LDAP definition for the Numeric String syntax is:
1055 ( 1.3.6.1.4.1.1466.115.121.1.36 DESC 'Numeric String' )
1057 This syntax corresponds to the NumericString ASN.1 type from [ASN.1].
1059 3.3.24. Object Class Description
1061 A value of the Object Class Description syntax is the definition of
1062 an object class. The LDAP-specific encoding of a value of this
1066 Legg Expires 23 December 2005 [Page 19]
1068 INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
1071 syntax is defined by the <ObjectClassDescription> rule in [MODELS].
1074 ( 2.5.6.2 NAME 'country' SUP top STRUCTURAL MUST c
1075 MAY ( searchGuide $ description ) )
1077 Note: a line break has been added for readability - it is not part of
1080 The LDAP definition for the Object Class Description syntax is:
1082 ( 1.3.6.1.4.1.1466.115.121.1.37 DESC 'Object Class Description' )
1084 This syntax corresponds to the ObjectClassDescription ASN.1 type from
1087 3.3.25. Octet String
1089 A value of the Octet String syntax is a sequence of zero, one or more
1090 arbitrary octets. The LDAP-specific encoding of a value of this
1091 syntax is the unconverted sequence of octets, which conforms to the
1094 OctetString = *OCTET
1096 The <OCTET> rule is defined in [MODELS]. Values of this syntax are
1097 not generally human-readable.
1099 The LDAP definition for the Octet String syntax is:
1101 ( 1.3.6.1.4.1.1466.115.121.1.40 DESC 'Octet String' )
1103 This syntax corresponds to the OCTET STRING ASN.1 type from [ASN.1].
1107 A value of the OID syntax is an object identifier; a sequence of two
1108 or more non-negative integers that uniquely identify some object or
1109 item of specification. Many of the object identifiers used in LDAP
1110 also have IANA registered names [RFC3383].
1112 The LDAP-specific encoding of a value of this syntax is defined by
1113 the <oid> rule in [MODELS].
1122 Legg Expires 23 December 2005 [Page 20]
1124 INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
1127 The LDAP definition for the OID syntax is:
1129 ( 1.3.6.1.4.1.1466.115.121.1.38 DESC 'OID' )
1131 This syntax corresponds to the OBJECT IDENTIFIER ASN.1 type from
1134 3.3.27. Other Mailbox
1136 A value of the Other Mailbox syntax identifies an electronic mailbox,
1137 in a particular named mail system. The LDAP-specific encoding of a
1138 value of this syntax is defined by the following ABNF:
1140 OtherMailbox = mailbox-type DOLLAR mailbox
1141 mailbox-type = PrintableString
1144 The <mailbox-type> rule represents the type of mail system in which
1145 the mailbox resides, for example "MCIMail", and <mailbox> is the
1146 actual mailbox in the mail system described by <mailbox-type>. The
1147 <PrintableString> and <IA5String> rules are defined in Section 3.2.
1148 The <DOLLAR> rule is defined in [MODELS].
1150 The LDAP definition for the Other Mailbox syntax is:
1152 ( 1.3.6.1.4.1.1466.115.121.1.39 DESC 'Other Mailbox' )
1154 The ASN.1 type corresponding to the Other Mailbox syntax is defined
1155 as follows, assuming EXPLICIT TAGS:
1157 OtherMailbox ::= SEQUENCE {
1158 mailboxType PrintableString,
1162 3.3.28. Postal Address
1164 A value of the Postal Address syntax is a sequence of strings of one
1165 or more arbitrary UCS characters, which form an address in a physical
1168 The LDAP-specific encoding of a value of this syntax is defined by
1171 PostalAddress = line *( DOLLAR line )
1174 / (%x5C "24") ; escaped "$"
1178 Legg Expires 23 December 2005 [Page 21]
1180 INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
1184 / (%x5C "5C") ; escaped "\"
1188 Each character string (i.e., <line>) of a postal address value is
1189 encoded as a UTF-8 [UTF8] string except that "\" and "$" characters,
1190 if they occur in the string, are escaped by a "\" character followed
1191 by the two hexadecimal digit code for the character. The <DOLLAR>
1192 and <UTFMB> rules are defined in [MODELS].
1194 Many servers limit the postal address to no more than six lines of no
1195 more than thirty characters each.
1198 1234 Main St.$Anytown, CA 12345$USA
1199 \241,000,000 Sweepstakes$PO Box 1000000$Anytown, CA 12345$USA
1201 The LDAP definition for the Postal Address syntax is:
1203 ( 1.3.6.1.4.1.1466.115.121.1.41 DESC 'Postal Address' )
1205 This syntax corresponds to the PostalAddress ASN.1 type from [X.520],
1208 PostalAddress ::= SEQUENCE SIZE(1..ub-postal-line) OF
1209 DirectoryString { ub-postal-string }
1211 The values of ub-postal-line and ub-postal-string (both integers) are
1212 implementation defined. Non-normative definitions appear in [X.520].
1214 3.3.29. Printable String
1216 A value of the Printable String syntax is a string of one or more
1217 latin alphabetic, numeric, and selected punctuation characters as
1218 specified by the <PrintableCharacter> rule in Section 3.2.
1220 The LDAP-specific encoding of a value of this syntax is the
1221 unconverted string of characters, which conforms to the
1222 <PrintableString> rule in Section 3.2.
1225 This is a PrintableString.
1227 The LDAP definition for the PrintableString syntax is:
1229 ( 1.3.6.1.4.1.1466.115.121.1.44 DESC 'Printable String' )
1234 Legg Expires 23 December 2005 [Page 22]
1236 INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
1239 This syntax corresponds to the PrintableString ASN.1 type from
1242 3.3.30. Substring Assertion
1244 A value of the Substring Assertion syntax is a sequence of zero, one
1245 or more character substrings used as an argument for substring
1246 extensible matching of character string attribute values, i.e., as
1247 the matchValue of a MatchingRuleAssertion [PROT]. Each substring is
1248 a string of one or more arbitrary characters from the Universal
1249 Character Set (UCS) [UCS]. A zero length substring is not permitted.
1251 The LDAP-specific encoding of a value of this syntax is defined by
1254 SubstringAssertion = [ initial ] any [ final ]
1257 any = ASTERISK *(substring ASTERISK)
1259 ASTERISK = %x2A ; asterisk ("*")
1261 substring = 1*substring-character
1262 substring-character = %x00-29
1263 / (%x5C "2A") ; escaped "*"
1265 / (%x5C "5C") ; escaped "\"
1269 Each <substring> of a Substring Assertion value is encoded as a UTF-8
1270 [UTF8] string, except that "\" and "*" characters, if they occur in
1271 the substring, are escaped by a "\" character followed by the two
1272 hexadecimal digit code for the character.
1274 The Substring Assertion syntax is used only as the syntax of
1275 assertion values in the extensible match. It is not used as an
1276 attribute syntax, or in the SubstringFilter [PROT].
1278 The LDAP definition for the Substring Assertion syntax is:
1280 ( 1.3.6.1.4.1.1466.115.121.1.58 DESC 'Substring Assertion' )
1282 This syntax corresponds to the SubstringAssertion ASN.1 type from
1285 3.3.31. Telephone Number
1290 Legg Expires 23 December 2005 [Page 23]
1292 INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
1295 A value of the Telephone Number syntax is a string of printable
1296 characters that complies with the internationally agreed format for
1297 representing international telephone numbers [E.123].
1299 The LDAP-specific encoding of a value of this syntax is the
1300 unconverted string of characters, which conforms to the
1301 <PrintableString> rule in Section 3.2.
1308 The LDAP definition for the Telephone Number syntax is:
1310 ( 1.3.6.1.4.1.1466.115.121.1.50 DESC 'Telephone Number' )
1312 The Telephone Number syntax corresponds to the following ASN.1 type
1315 PrintableString (SIZE(1..ub-telephone-number))
1317 The value of ub-telephone-number (an integer) is implementation
1318 defined. A non-normative definition appears in [X.520].
1320 3.3.32. Teletex Terminal Identifier
1322 A value of this syntax specifies the identifier and (optionally)
1323 parameters of a teletex terminal.
1325 The LDAP-specific encoding of a value of this syntax is defined by
1328 teletex-id = ttx-term *(DOLLAR ttx-param)
1329 ttx-term = PrintableString ; terminal identifier
1330 ttx-param = ttx-key COLON ttx-value ; parameter
1331 ttx-key = "graphic" / "control" / "misc" / "page" / "private"
1332 ttx-value = *ttx-value-octet
1334 ttx-value-octet = %x00-23
1335 / (%x5C "24") ; escaped "$"
1337 / (%x5C "5C") ; escaped "\"
1340 The <PrintableString> and <COLON> rules are defined in Section 3.2.
1341 The <DOLLAR> rule is defined in [MODELS].
1346 Legg Expires 23 December 2005 [Page 24]
1348 INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
1351 The LDAP definition for the Teletex Terminal Identifier syntax is:
1353 ( 1.3.6.1.4.1.1466.115.121.1.51
1354 DESC 'Teletex Terminal Identifier' )
1356 This syntax corresponds to the TeletexTerminalIdentifier ASN.1 type
1359 3.3.33. Telex Number
1361 A value of the Telex Number syntax specifies the telex number,
1362 country code and answerback code of a telex terminal.
1364 The LDAP-specific encoding of a value of this syntax is defined by
1367 telex-number = actual-number DOLLAR country-code
1369 actual-number = PrintableString
1370 country-code = PrintableString
1371 answerback = PrintableString
1373 The <PrintableString> rule is defined in Section 3.2. The <DOLLAR>
1374 rule is defined in [MODELS].
1376 The LDAP definition for the Telex Number syntax is:
1378 ( 1.3.6.1.4.1.1466.115.121.1.52 DESC 'Telex Number' )
1380 This syntax corresponds to the TelexNumber ASN.1 type from [X.520].
1384 A value of the UTC Time syntax is a character string representing a
1385 date and time to a precision of one minute or one second. The year
1386 is given as a two-digit number. The LDAP-specific encoding of a
1387 value of this syntax follows the format defined in [ASN.1] for the
1388 UTCTime type and is described by the following ABNF:
1390 UTCTime = year month day hour minute [ second ]
1392 u-time-zone = %x5A ; "Z"
1394 u-differential = ( MINUS / PLUS ) hour minute
1396 The <year>, <month>, <day>, <hour>, <minute>, <second> and <MINUS>
1397 rules are defined in Section 3.3.13. The <PLUS> rule is defined in
1402 Legg Expires 23 December 2005 [Page 25]
1404 INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
1407 The above ABNF allows character strings which do not represent valid
1408 dates (in the Gregorian calendar) and/or valid times. Such character
1409 strings SHOULD be considered invalid for this syntax.
1411 The time value represents coordinated universal time if the "Z" form
1412 of <u-time-zone> is used, otherwise the value represents a local
1413 time. In the latter case, if <u-differential> is provided then
1414 coordinated universal time can be calculated by subtracting the
1415 differential from the local time. The <u-time-zone> SHOULD be
1416 present in time values and the "Z" form of <u-time-zone> SHOULD be
1417 used in preference to <u-differential>.
1419 The LDAP definition for the UTC Time syntax is:
1421 ( 1.3.6.1.4.1.1466.115.121.1.53 DESC 'UTC Time' )
1423 Note: This syntax is deprecated in favor of the Generalized Time
1426 The UTC Time syntax corresponds to the UTCTime ASN.1 type from
1431 Matching rules are used by directory implementations to compare
1432 attribute values against assertion values when performing Search and
1433 Compare operations [PROT]. They are also used when comparing a
1434 purported distinguished name [MODELS] with the name of an entry.
1435 When modifying entries, matching rules are used to identify values to
1436 be deleted and to prevent an attribute from containing two equal
1439 Matching rules that are required for directory operation, or that are
1440 in common use, are specified in this section.
1442 4.1. General Considerations
1444 A matching rule is applied to attribute values through an
1445 AttributeValueAssertion or MatchingRuleAssertion [PROT]. The
1446 conditions under which an AttributeValueAssertion or
1447 MatchingRuleAssertion evaluates to Undefined are specified elsewhere
1448 [PROT]. If an assertion is not Undefined then the result of the
1449 assertion is the result of applying the selected matching rule. A
1450 matching rule evaluates to TRUE, and in some cases Undefined, as
1451 specified in the description of the matching rule, otherwise it
1454 Each assertion contains an assertion value. The definition of each
1458 Legg Expires 23 December 2005 [Page 26]
1460 INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
1463 matching rule specifies the syntax for the assertion value. The
1464 syntax of the assertion value is typically, but not necessarily, the
1465 same as the syntax of the attribute values to which the matching rule
1466 may be applied. Note that an AssertionValue in a SubstringFilter
1467 [PROT] conforms to the assertion syntax of the equality matching rule
1468 for the attribute type rather than the assertion syntax of the
1469 substrings matching rule for the attribute type. Conceptually, the
1470 entire SubstringFilter is converted into an assertion value of the
1471 substrings matching rule prior to applying the rule.
1473 The definition of each matching rule indicates the attribute syntaxes
1474 to which the rule may be applied, by specifying conditions the
1475 corresponding ASN.1 type of a candidate attribute syntax must
1476 satisfy. These conditions are also satisfied if the corresponding
1477 ASN.1 type is a tagged or constrained derivative of the ASN.1 type
1478 explicitly mentioned in the rule description (i.e., ASN.1 tags and
1479 constraints are ignored in checking applicability), or an alternative
1480 reference notation for the explicitly mentioned type. Each rule
1481 description lists as examples of applicable attribute syntaxes, the
1482 complete list of the syntaxes defined in this document to which the
1483 matching rule applies. A matching rule may be applicable to
1484 additional syntaxes defined in other documents if those syntaxes
1485 satisfy the conditions on the corresponding ASN.1 type.
1487 The description of each matching rule indicates whether the rule is
1488 suitable for use as the equality matching rule (EQUALITY), ordering
1489 matching rule (ORDERING) or substrings matching rule (SUBSTR) in an
1490 attribute type definition [MODELS].
1492 Each matching rule is uniquely identified with an object identifier.
1493 The definition of a matching rule should not be subsequently changed.
1494 If a change is desirable then a new matching rule with a different
1495 object identifier should be defined instead.
1497 Servers MAY implement the wordMatch and keywordMatch matching rules,
1498 but SHOULD implement the other matching rules in Section 4.2.
1499 Servers MAY implement additional matching rules.
1501 Servers which implement the extensibleMatch filter SHOULD allow the
1502 matching rules listed in Section 4.2 to be used in the
1503 extensibleMatch filter and SHOULD allow matching rules to be used
1504 with all attribute types known to the server, where the assertion
1505 syntax of the matching rule is the same as the value syntax of the
1508 Servers MUST publish in the matchingRules attribute, the definitions
1509 of matching rules referenced by values of the attributeTypes and
1510 matchingRuleUse attributes in the same subschema entry. Other
1514 Legg Expires 23 December 2005 [Page 27]
1516 INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
1519 unreferenced matching rules MAY be published in the matchingRules
1522 If the server supports the extensibleMatch filter, then the server
1523 MAY use the matchingRuleUse attribute to indicate the applicability
1524 (in an extensibleMatch filter) of selected matching rules to
1525 nominated attribute types.
1527 4.2. Matching Rule Definitions
1529 Nominated character strings in assertion and attribute values are
1530 prepared according to the string preparation algorithms [PREP] for
1531 LDAP when evaluating the following matching rules:
1534 numericStringSubstringsMatch,
1536 caseExactOrderingMatch,
1537 caseExactSubstringsMatch,
1540 caseIgnoreIA5SubstringsMatch,
1541 caseIgnoreListMatch,
1542 caseIgnoreListSubstringsMatch,
1544 caseIgnoreOrderingMatch,
1545 caseIgnoreSubstringsMatch,
1546 directoryStringFirstComponentMatch,
1547 telephoneNumberMatch,
1548 telephoneNumberSubstringsMatch and
1551 The Transcode, Normalize, Prohibit and Check bidi steps are the same
1552 for each of the matching rules. However, the Map and Insignificant
1553 Character Handling steps depends on the specific rule, as detailed in
1554 the description of these matching rules in the sections that follow.
1556 4.2.1. bitStringMatch
1558 The bitStringMatch rule compares an assertion value of the Bit String
1559 syntax to an attribute value of a syntax (e.g., the Bit String
1560 syntax) whose corresponding ASN.1 type is BIT STRING.
1562 If the corresponding ASN.1 type of the attribute syntax does not have
1563 a named bit list [ASN.1] (which is the case for the Bit String
1564 syntax) then the rule evaluates to TRUE if and only if the attribute
1565 value has the same number of bits as the assertion value and the bits
1566 match on a bitwise basis.
1570 Legg Expires 23 December 2005 [Page 28]
1572 INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
1575 If the corresponding ASN.1 type does have a named bit list then
1576 bitStringMatch operates as above except that trailing zero bits in
1577 the attribute and assertion values are treated as absent.
1579 The LDAP definition for the bitStringMatch rule is:
1581 ( 2.5.13.16 NAME 'bitStringMatch'
1582 SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 )
1584 The bitStringMatch rule is an equality matching rule.
1588 The booleanMatch rule compares an assertion value of the Boolean
1589 syntax to an attribute value of a syntax (e.g., the Boolean syntax)
1590 whose corresponding ASN.1 type is BOOLEAN.
1592 The rule evaluates to TRUE if and only if the attribute value and the
1593 assertion value are both TRUE or both FALSE.
1595 The LDAP definition for the booleanMatch rule is:
1597 ( 2.5.13.13 NAME 'booleanMatch'
1598 SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 )
1600 The booleanMatch rule is an equality matching rule.
1602 4.2.3. caseExactIA5Match
1604 The caseExactIA5Match rule compares an assertion value of the IA5
1605 String syntax to an attribute value of a syntax (e.g the IA5 String
1606 syntax) whose corresponding ASN.1 type is IA5String.
1608 The rule evaluates to TRUE if and only if the prepared attribute
1609 value character string and the prepared assertion value character
1610 string have the same number of characters and corresponding
1611 characters have the same code point.
1613 In preparing the attribute value and assertion value for comparison,
1614 characters are not case folded in the Map preparation step, and only
1615 Insignificant Space Handling is applied in the Insignificant
1616 Character Handling step.
1618 The LDAP definition for the caseExactIA5Match rule is:
1620 ( 1.3.6.1.4.1.1466.109.114.1 NAME 'caseExactIA5Match'
1621 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
1626 Legg Expires 23 December 2005 [Page 29]
1628 INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
1631 The caseExactIA5Match rule is an equality matching rule.
1633 4.2.4. caseExactMatch
1635 The caseExactMatch rule compares an assertion value of the Directory
1636 String syntax to an attribute value of a syntax (e.g., the Directory
1637 String, Printable String, Country String or Telephone Number syntax)
1638 whose corresponding ASN.1 type is DirectoryString or one of the
1639 alternative string types of DirectoryString, e.g., PrintableString
1640 (the other alternatives do not correspond to any syntax defined in
1643 The rule evaluates to TRUE if and only if the prepared attribute
1644 value character string and the prepared assertion value character
1645 string have the same number of characters and corresponding
1646 characters have the same code point.
1648 In preparing the attribute value and assertion value for comparison,
1649 characters are not case folded in the Map preparation step, and only
1650 Insignificant Space Handling is applied in the Insignificant
1651 Character Handling step.
1653 The LDAP definition for the caseExactMatch rule is:
1655 ( 2.5.13.5 NAME 'caseExactMatch'
1656 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
1658 The caseExactMatch rule is an equality matching rule.
1660 4.2.5. caseExactOrderingMatch
1662 The caseExactOrderingMatch rule compares an assertion value of the
1663 Directory String syntax to an attribute value of a syntax (e.g., the
1664 Directory String, Printable String, Country String or Telephone
1665 Number syntax) whose corresponding ASN.1 type is DirectoryString or
1666 one of its alternative string types.
1668 The rule evaluates to TRUE if, and only if, in the code point
1669 collation order, the prepared attribute value character string
1670 appears earlier than the prepared assertion value character string,
1671 i.e., the attribute value is "less than" the assertion value.
1673 In preparing the attribute value and assertion value for comparison,
1674 characters are not case folded in the Map preparation step, and only
1675 Insignificant Space Handling is applied in the Insignificant
1676 Character Handling step.
1678 The LDAP definition for the caseExactOrderingMatch rule is:
1682 Legg Expires 23 December 2005 [Page 30]
1684 INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
1687 ( 2.5.13.6 NAME 'caseExactOrderingMatch'
1688 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
1690 The caseExactOrderingMatch rule is an ordering matching rule.
1692 4.2.6. caseExactSubstringsMatch
1694 The caseExactSubstringsMatch rule compares an assertion value of the
1695 Substring Assertion syntax to an attribute value of a syntax (e.g.,
1696 the Directory String, Printable String, Country String or Telephone
1697 Number syntax) whose corresponding ASN.1 type is DirectoryString or
1698 one of its alternative string types.
1700 The rule evaluates to TRUE if and only if the prepared substrings of
1701 the assertion value match disjoint portions of the prepared attribute
1702 value character string in the order of the substrings in the
1703 assertion value, and an <initial> substring, if present, matches the
1704 beginning of the prepared attribute value character string, and a
1705 <final> substring, if present, matches the end of the prepared
1706 attribute value character string. A prepared substring matches a
1707 portion of the prepared attribute value character string if
1708 corresponding characters have the same code point.
1710 In preparing the attribute value and assertion value substrings for
1711 comparison, characters are not case folded in the Map preparation
1712 step, and only Insignificant Space Handling is applied in the
1713 Insignificant Character Handling step.
1715 The LDAP definition for the caseExactSubstringsMatch rule is:
1717 ( 2.5.13.7 NAME 'caseExactSubstringsMatch'
1718 SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
1720 The caseExactSubstringsMatch rule is a substrings matching rule.
1722 4.2.7. caseIgnoreIA5Match
1724 The caseIgnoreIA5Match rule compares an assertion value of the IA5
1725 String syntax to an attribute value of a syntax (e.g the IA5 String
1726 syntax) whose corresponding ASN.1 type is IA5String.
1728 The rule evaluates to TRUE if and only if the prepared attribute
1729 value character string and the prepared assertion value character
1730 string have the same number of characters and corresponding
1731 characters have the same code point.
1733 In preparing the attribute value and assertion value for comparison,
1734 characters are case folded in the Map preparation step, and only
1738 Legg Expires 23 December 2005 [Page 31]
1740 INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
1743 Insignificant Space Handling is applied in the Insignificant
1744 Character Handling step.
1746 The LDAP definition for the caseIgnoreIA5Match rule is:
1748 ( 1.3.6.1.4.1.1466.109.114.2 NAME 'caseIgnoreIA5Match'
1749 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
1751 The caseIgnoreIA5Match rule is an equality matching rule.
1753 4.2.8. caseIgnoreIA5SubstringsMatch
1755 The caseIgnoreIA5SubstringsMatch rule compares an assertion value of
1756 the Substring Assertion syntax to an attribute value of a syntax (e.g
1757 the IA5 String syntax) whose corresponding ASN.1 type is IA5String.
1759 The rule evaluates to TRUE if and only if the prepared substrings of
1760 the assertion value match disjoint portions of the prepared attribute
1761 value character string in the order of the substrings in the
1762 assertion value, and an <initial> substring, if present, matches the
1763 beginning of the prepared attribute value character string, and a
1764 <final> substring, if present, matches the end of the prepared
1765 attribute value character string. A prepared substring matches a
1766 portion of the prepared attribute value character string if
1767 corresponding characters have the same code point.
1769 In preparing the attribute value and assertion value substrings for
1770 comparison, characters are case folded in the Map preparation step,
1771 and only Insignificant Space Handling is applied in the Insignificant
1772 Character Handling step.
1774 ( 1.3.6.1.4.1.1466.109.114.3 NAME 'caseIgnoreIA5SubstringsMatch'
1775 SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
1777 The caseIgnoreIA5SubstringsMatch rule is a substrings matching rule.
1779 4.2.9. caseIgnoreListMatch
1781 The caseIgnoreListMatch rule compares an assertion value that is a
1782 sequence of strings to an attribute value of a syntax (e.g., the
1783 Postal Address syntax) whose corresponding ASN.1 type is a SEQUENCE
1784 OF the DirectoryString ASN.1 type.
1786 The rule evaluates to TRUE if and only if the attribute value and the
1787 assertion value have the same number of strings and corresponding
1788 strings (by position) match according to the caseIgnoreMatch matching
1794 Legg Expires 23 December 2005 [Page 32]
1796 INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
1799 In [X.520] the assertion syntax for this matching rule is defined to
1802 SEQUENCE OF DirectoryString {ub-match}
1804 i.e., different from the corresponding type for the Postal Address
1805 syntax. The choice of the Postal Address syntax for the assertion
1806 syntax of the caseIgnoreListMatch in LDAP should not be seen as
1807 limiting the matching rule to only apply to attributes with the
1808 Postal Address syntax.
1810 The LDAP definition for the caseIgnoreListMatch rule is:
1812 ( 2.5.13.11 NAME 'caseIgnoreListMatch'
1813 SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 )
1815 The caseIgnoreListMatch rule is an equality matching rule.
1817 4.2.10. caseIgnoreListSubstringsMatch
1819 The caseIgnoreListSubstringsMatch rule compares an assertion value of
1820 the Substring Assertion syntax to an attribute value of a syntax
1821 (e.g., the Postal Address syntax) whose corresponding ASN.1 type is a
1822 SEQUENCE OF the DirectoryString ASN.1 type.
1824 The rule evaluates to TRUE if and only if the assertion value
1825 matches, per the caseIgnoreSubstringsMatch rule, the character string
1826 formed by concatenating the strings of the attribute value, except
1827 that none of the <initial>, <any>, or <final> substrings of the
1828 assertion value are considered to match a substring of the
1829 concatenated string which spans more than one of the original strings
1830 of the attribute value.
1832 Note that, in terms of the LDAP-specific encoding of the Postal
1833 Address syntax, the concatenated string omits the <DOLLAR> line
1834 separator and the escaping of "\" and "$" characters.
1836 The LDAP definition for the caseIgnoreListSubstringsMatch rule is:
1838 ( 2.5.13.12 NAME 'caseIgnoreListSubstringsMatch'
1839 SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
1841 The caseIgnoreListSubstringsMatch rule is a substrings matching rule.
1843 4.2.11. caseIgnoreMatch
1845 The caseIgnoreMatch rule compares an assertion value of the Directory
1846 String syntax to an attribute value of a syntax (e.g., the Directory
1850 Legg Expires 23 December 2005 [Page 33]
1852 INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
1855 String, Printable String, Country String or Telephone Number syntax)
1856 whose corresponding ASN.1 type is DirectoryString or one of its
1857 alternative string types.
1859 The rule evaluates to TRUE if and only if the prepared attribute
1860 value character string and the prepared assertion value character
1861 string have the same number of characters and corresponding
1862 characters have the same code point.
1864 In preparing the attribute value and assertion value for comparison,
1865 characters are case folded in the Map preparation step, and only
1866 Insignificant Space Handling is applied in the Insignificant
1867 Character Handling step.
1869 The LDAP definition for the caseIgnoreMatch rule is:
1871 ( 2.5.13.2 NAME 'caseIgnoreMatch'
1872 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
1874 The caseIgnoreMatch rule is an equality matching rule.
1876 4.2.12. caseIgnoreOrderingMatch
1878 The caseIgnoreOrderingMatch rule compares an assertion value of the
1879 Directory String syntax to an attribute value of a syntax (e.g., the
1880 Directory String, Printable String, Country String or Telephone
1881 Number syntax) whose corresponding ASN.1 type is DirectoryString or
1882 one of its alternative string types.
1884 The rule evaluates to TRUE if, and only if, in the code point
1885 collation order, the prepared attribute value character string
1886 appears earlier than the prepared assertion value character string,
1887 i.e., the attribute value is "less than" the assertion value.
1889 In preparing the attribute value and assertion value for comparison,
1890 characters are case folded in the Map preparation step, and only
1891 Insignificant Space Handling is applied in the Insignificant
1892 Character Handling step.
1894 The LDAP definition for the caseIgnoreOrderingMatch rule is:
1896 ( 2.5.13.3 NAME 'caseIgnoreOrderingMatch'
1897 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
1899 The caseIgnoreOrderingMatch rule is an ordering matching rule.
1901 4.2.13. caseIgnoreSubstringsMatch
1906 Legg Expires 23 December 2005 [Page 34]
1908 INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
1911 The caseIgnoreSubstringsMatch rule compares an assertion value of the
1912 Substring Assertion syntax to an attribute value of a syntax (e.g.,
1913 the Directory String, Printable String, Country String or Telephone
1914 Number syntax) whose corresponding ASN.1 type is DirectoryString or
1915 one of its alternative string types.
1917 The rule evaluates to TRUE if and only if the prepared substrings of
1918 the assertion value match disjoint portions of the prepared attribute
1919 value character string in the order of the substrings in the
1920 assertion value, and an <initial> substring, if present, matches the
1921 beginning of the prepared attribute value character string, and a
1922 <final> substring, if present, matches the end of the prepared
1923 attribute value character string. A prepared substring matches a
1924 portion of the prepared attribute value character string if
1925 corresponding characters have the same code point.
1927 In preparing the attribute value and assertion value substrings for
1928 comparison, characters are case folded in the Map preparation step,
1929 and only Insignificant Space Handling is applied in the Insignificant
1930 Character Handling step.
1932 The LDAP definition for the caseIgnoreSubstringsMatch rule is:
1934 ( 2.5.13.4 NAME 'caseIgnoreSubstringsMatch'
1935 SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
1937 The caseIgnoreSubstringsMatch rule is a substrings matching rule.
1939 4.2.14. directoryStringFirstComponentMatch
1941 The directoryStringFirstComponentMatch rule compares an assertion
1942 value of the Directory String syntax to an attribute value of a
1943 syntax whose corresponding ASN.1 type is a SEQUENCE with a mandatory
1944 first component of the DirectoryString ASN.1 type.
1946 Note that the assertion syntax of this matching rule differs from the
1947 attribute syntax of attributes for which this is the equality
1950 The rule evaluates to TRUE if and only if the assertion value matches
1951 the first component of the attribute value using the rules of
1954 The LDAP definition for the directoryStringFirstComponentMatch
1957 ( 2.5.13.31 NAME 'directoryStringFirstComponentMatch'
1958 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
1962 Legg Expires 23 December 2005 [Page 35]
1964 INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
1967 The directoryStringFirstComponentMatch rule is an equality matching
1968 rule. When using directoryStringFirstComponentMatch to compare two
1969 attribute values (of an applicable syntax), an assertion value must
1970 first be derived from one of the attribute values. An assertion
1971 value can be derived from an attribute value by taking the first
1972 component of that attribute value.
1974 4.2.15. distinguishedNameMatch
1976 The distinguishedNameMatch rule compares an assertion value of the DN
1977 syntax to an attribute value of a syntax (e.g., the DN syntax) whose
1978 corresponding ASN.1 type is DistinguishedName.
1980 The rule evaluates to TRUE if and only if the attribute value and the
1981 assertion value have the same number of relative distinguished names
1982 and corresponding relative distinguished names (by position) are the
1983 same. A relative distinguished name (RDN) of the assertion value is
1984 the same as an RDN of the attribute value if and only if they have
1985 the same number of attribute value assertions and each attribute
1986 value assertion (AVA) of the first RDN is the same as the AVA of the
1987 second RDN with the same attribute type. The order of the AVAs is
1988 not significant. Also note that a particular attribute type may
1989 appear in at most one AVA in an RDN. Two AVAs with the same
1990 attribute type are the same if their values are equal according to
1991 the equality matching rule of the attribute type. If one or more of
1992 the AVA comparisons evaluate to Undefined and the remaining AVA
1993 comparisons return TRUE then the distinguishedNameMatch rule
1994 evaluates to Undefined.
1996 The LDAP definition for the distinguishedNameMatch rule is:
1998 ( 2.5.13.1 NAME 'distinguishedNameMatch'
1999 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
2001 The distinguishedNameMatch rule is an equality matching rule.
2003 4.2.16. generalizedTimeMatch
2005 The generalizedTimeMatch rule compares an assertion value of the
2006 Generalized Time syntax to an attribute value of a syntax (e.g the
2007 Generalized Time syntax) whose corresponding ASN.1 type is
2010 The rule evaluates to TRUE if and only if the attribute value
2011 represents the same universal coordinated time as the assertion
2012 value. If a time is specified with the minutes or seconds absent
2013 then the number of minutes or seconds (respectively) is assumed to be
2018 Legg Expires 23 December 2005 [Page 36]
2020 INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
2023 The LDAP definition for the generalizedTimeMatch rule is:
2025 ( 2.5.13.27 NAME 'generalizedTimeMatch'
2026 SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 )
2028 The generalizedTimeMatch rule is an equality matching rule.
2030 4.2.17. generalizedTimeOrderingMatch
2032 The generalizedTimeOrderingMatch rule compares the time ordering of
2033 an assertion value of the Generalized Time syntax to an attribute
2034 value of a syntax (e.g the Generalized Time syntax) whose
2035 corresponding ASN.1 type is GeneralizedTime.
2037 The rule evaluates to TRUE if and only if the attribute value
2038 represents a universal coordinated time which is earlier than the
2039 universal coordinated time represented by the assertion value.
2041 The LDAP definition for the generalizedTimeOrderingMatch rule is:
2043 ( 2.5.13.28 NAME 'generalizedTimeOrderingMatch'
2044 SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 )
2046 The generalizedTimeOrderingMatch rule is an ordering matching rule.
2048 4.2.18. integerFirstComponentMatch
2050 The integerFirstComponentMatch rule compares an assertion value of
2051 the Integer syntax to an attribute value of a syntax (e.g the DIT
2052 Structure Rule Description syntax) whose corresponding ASN.1 type is
2053 a SEQUENCE with a mandatory first component of the INTEGER ASN.1
2056 Note that the assertion syntax of this matching rule differs from the
2057 attribute syntax of attributes for which this is the equality
2060 The rule evaluates to TRUE if and only if the assertion value and the
2061 first component of the attribute value are the same integer value.
2063 The LDAP definition for the integerFirstComponentMatch matching rule
2066 ( 2.5.13.29 NAME 'integerFirstComponentMatch'
2067 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )
2069 The integerFirstComponentMatch rule is an equality matching rule.
2070 When using integerFirstComponentMatch to compare two attribute values
2074 Legg Expires 23 December 2005 [Page 37]
2076 INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
2079 (of an applicable syntax), an assertion value must first be derived
2080 from one of the attribute values. An assertion value can be derived
2081 from an attribute value by taking the first component of that
2084 4.2.19. integerMatch
2086 The integerMatch rule compares an assertion value of the Integer
2087 syntax to an attribute value of a syntax (e.g the Integer syntax)
2088 whose corresponding ASN.1 type is INTEGER.
2090 The rule evaluates to TRUE if and only if the attribute value and the
2091 assertion value are the same integer value.
2093 The LDAP definition for the integerMatch matching rule is:
2095 ( 2.5.13.14 NAME 'integerMatch'
2096 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )
2098 The integerMatch rule is an equality matching rule.
2100 4.2.20. integerOrderingMatch
2102 The integerOrderingMatch rule compares an assertion value of the
2103 Integer syntax to an attribute value of a syntax (e.g the Integer
2104 syntax) whose corresponding ASN.1 type is INTEGER.
2106 The rule evaluates to TRUE if and only if the integer value of the
2107 attribute value is less than the integer value the assertion value.
2109 The LDAP definition for the integerOrderingMatch matching rule is:
2111 ( 2.5.13.15 NAME 'integerOrderingMatch'
2112 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )
2114 The integerOrderingMatch rule is an ordering matching rule.
2116 4.2.21. keywordMatch
2118 The keywordMatch rule compares an assertion value of the Directory
2119 String syntax to an attribute value of a syntax (e.g., the Directory
2120 String syntax) whose corresponding ASN.1 type is DirectoryString.
2122 The rule evaluates to TRUE if and only if the assertion value
2123 character string matches any keyword in the attribute value. The
2124 identification of keywords in the attribute value and the exactness
2125 of the match are both implementation specific.
2130 Legg Expires 23 December 2005 [Page 38]
2132 INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
2135 The LDAP definition for the keywordMatch rule is:
2137 ( 2.5.13.33 NAME 'keywordMatch'
2138 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
2140 4.2.22. numericStringMatch
2142 The numericStringMatch rule compares an assertion value of the
2143 Numeric String syntax to an attribute value of a syntax (e.g the
2144 Numeric String syntax) whose corresponding ASN.1 type is
2147 The rule evaluates to TRUE if and only if the prepared attribute
2148 value character string and the prepared assertion value character
2149 string have the same number of characters and corresponding
2150 characters have the same code point.
2152 In preparing the attribute value and assertion value for comparison,
2153 characters are not case folded in the Map preparation step, and only
2154 numericString Insignificant Character Handling is applied in the
2155 Insignificant Character Handling step.
2157 The LDAP definition for the numericStringMatch matching rule is:
2159 ( 2.5.13.8 NAME 'numericStringMatch'
2160 SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 )
2162 The numericStringMatch rule is an equality matching rule.
2164 4.2.23. numericStringOrderingMatch
2166 The numericStringOrderingMatch rule compares an assertion value of
2167 the Numeric String syntax to an attribute value of a syntax (e.g the
2168 Numeric String syntax) whose corresponding ASN.1 type is
2171 The rule evaluates to TRUE if, and only if, in the code point
2172 collation order, the prepared attribute value character string
2173 appears earlier than the prepared assertion value character string,
2174 i.e., the attribute value is "less than" the assertion value.
2176 In preparing the attribute value and assertion value for comparison,
2177 characters are not case folded in the Map preparation step, and only
2178 numericString Insignificant Character Handling is applied in the
2179 Insignificant Character Handling step.
2181 The rule is identical to the caseIgnoreOrderingMatch rule except that
2182 all space characters are skipped during comparison (case is
2186 Legg Expires 23 December 2005 [Page 39]
2188 INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
2191 irrelevant as characters are numeric).
2193 The LDAP definition for the numericStringOrderingMatch matching rule
2196 ( 2.5.13.9 NAME 'numericStringOrderingMatch'
2197 SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 )
2199 The numericStringOrderingMatch rule is an ordering matching rule.
2201 4.2.24. numericStringSubstringsMatch
2203 The numericStringSubstringsMatch rule compares an assertion value of
2204 the Substring Assertion syntax to an attribute value of a syntax (e.g
2205 the Numeric String syntax) whose corresponding ASN.1 type is
2208 The rule evaluates to TRUE if and only if the prepared substrings of
2209 the assertion value match disjoint portions of the prepared attribute
2210 value character string in the order of the substrings in the
2211 assertion value, and an <initial> substring, if present, matches the
2212 beginning of the prepared attribute value character string, and a
2213 <final> substring, if present, matches the end of the prepared
2214 attribute value character string. A prepared substring matches a
2215 portion of the prepared attribute value character string if
2216 corresponding characters have the same code point.
2218 In preparing the attribute value and assertion value for comparison,
2219 characters are not case folded in the Map preparation step, and only
2220 numericString Insignificant Character Handling is applied in the
2221 Insignificant Character Handling step.
2223 The LDAP definition for the numericStringSubstringsMatch matching
2226 ( 2.5.13.10 NAME 'numericStringSubstringsMatch'
2227 SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
2229 The numericStringSubstringsMatch rule is a substrings matching rule.
2231 4.2.25. objectIdentifierFirstComponentMatch
2233 The objectIdentifierFirstComponentMatch rule compares an assertion
2234 value of the OID syntax to an attribute value of a syntax (e.g the
2235 Attribute Type Description, DIT Content Rule Description, LDAP Syntax
2236 Description, Matching Rule Description, Matching Rule Use
2237 Description, Name Form Description or Object Class Description
2238 syntax) whose corresponding ASN.1 type is a SEQUENCE with a mandatory
2242 Legg Expires 23 December 2005 [Page 40]
2244 INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
2247 first component of the OBJECT IDENTIFIER ASN.1 type.
2249 Note that the assertion syntax of this matching rule differs from the
2250 attribute syntax of attributes for which this is the equality
2253 The rule evaluates to TRUE if and only if the assertion value matches
2254 the first component of the attribute value using the rules of
2255 objectIdentifierMatch.
2257 The LDAP definition for the objectIdentifierFirstComponentMatch
2260 ( 2.5.13.30 NAME 'objectIdentifierFirstComponentMatch'
2261 SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
2263 The objectIdentifierFirstComponentMatch rule is an equality matching
2264 rule. When using objectIdentifierFirstComponentMatch to compare two
2265 attribute values (of an applicable syntax), an assertion value must
2266 first be derived from one of the attribute values. An assertion
2267 value can be derived from an attribute value by taking the first
2268 component of that attribute value.
2270 4.2.26. objectIdentifierMatch
2272 The objectIdentifierMatch rule compares an assertion value of the OID
2273 syntax to an attribute value of a syntax (e.g the OID syntax) whose
2274 corresponding ASN.1 type is OBJECT IDENTIFIER.
2276 The rule evaluates to TRUE if and only if the assertion value and the
2277 attribute value represent the same object identifier, that is, the
2278 same sequence of integers, whether represented explicitly in the
2279 <numericoid> form of <oid> or implicitly in the <descr> form (see
2282 If an LDAP client supplies an assertion value in the <descr> form,
2283 and the chosen descriptor is not recognized by the server, then the
2284 objectIdentifierMatch rule evaluates to Undefined.
2286 The LDAP definition for the objectIdentifierMatch matching rule is:
2288 ( 2.5.13.0 NAME 'objectIdentifierMatch'
2289 SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
2291 The objectIdentifierMatch rule is an equality matching rule.
2293 4.2.27. octetStringMatch
2298 Legg Expires 23 December 2005 [Page 41]
2300 INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
2303 The octetStringMatch rule compares an assertion value of the Octet
2304 String syntax to an attribute value of a syntax (e.g the Octet String
2305 or JPEG syntax) whose corresponding ASN.1 type is the OCTET STRING
2308 The rule evaluates to TRUE if and only if the attribute value and the
2309 assertion value are the same length and corresponding octets (by
2310 position) are the same.
2312 The LDAP definition for the octetStringMatch matching rule is:
2314 ( 2.5.13.17 NAME 'octetStringMatch'
2315 SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )
2317 The octetStringMatch rule is an equality matching rule.
2319 4.2.28. octetStringOrderingMatch
2321 The octetStringOrderingMatch rule compares an assertion value of the
2322 Octet String syntax to an attribute value of a syntax (e.g the Octet
2323 String or JPEG syntax) whose corresponding ASN.1 type is the OCTET
2326 The rule evaluates to TRUE if and only if the attribute value appears
2327 earlier in the collation order than the assertion value. The rule
2328 compares octet strings from the first octet to the last octet, and
2329 from the most significant bit to the least significant bit within the
2330 octet. The first occurrence of a different bit determines the
2331 ordering of the strings. A zero bit precedes a one bit. If the
2332 strings contain different numbers of octets but the longer string is
2333 identical to the shorter string up to the length of the shorter
2334 string then the shorter string precedes the longer string.
2336 The LDAP definition for the octetStringOrderingMatch matching rule
2339 ( 2.5.13.18 NAME 'octetStringOrderingMatch'
2340 SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )
2342 The octetStringOrderingMatch rule is an ordering matching rule.
2344 4.2.29. telephoneNumberMatch
2346 The telephoneNumberMatch rule compares an assertion value of the
2347 Telephone Number syntax to an attribute value of a syntax (e.g the
2348 Telephone Number syntax) whose corresponding ASN.1 type is a
2349 PrintableString representing a telephone number.
2354 Legg Expires 23 December 2005 [Page 42]
2356 INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
2359 The rule evaluates to TRUE if and only if the prepared attribute
2360 value character string and the prepared assertion value character
2361 string have the same number of characters and corresponding
2362 characters have the same code point.
2364 In preparing the attribute value and assertion value for comparison,
2365 characters are case folded in the Map preparation step, and only
2366 telephoneNumber Insignificant Character Handling is applied in the
2367 Insignificant Character Handling step.
2369 The LDAP definition for the telephoneNumberMatch matching rule is:
2371 ( 2.5.13.20 NAME 'telephoneNumberMatch'
2372 SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 )
2374 The telephoneNumberMatch rule is an equality matching rule.
2376 4.2.30. telephoneNumberSubstringsMatch
2378 The telephoneNumberSubstringsMatch rule compares an assertion value
2379 of the Substring Assertion syntax to an attribute value of a syntax
2380 (e.g the Telephone Number syntax) whose corresponding ASN.1 type is a
2381 PrintableString representing a telephone number.
2383 The rule evaluates to TRUE if and only if the prepared substrings of
2384 the assertion value match disjoint portions of the prepared attribute
2385 value character string in the order of the substrings in the
2386 assertion value, and an <initial> substring, if present, matches the
2387 beginning of the prepared attribute value character string, and a
2388 <final> substring, if present, matches the end of the prepared
2389 attribute value character string. A prepared substring matches a
2390 portion of the prepared attribute value character string if
2391 corresponding characters have the same code point.
2393 In preparing the attribute value and assertion value substrings for
2394 comparison, characters are case folded in the Map preparation step,
2395 and only telephoneNumber Insignificant Character Handling is applied
2396 in the Insignificant Character Handling step.
2398 The LDAP definition for the telephoneNumberSubstringsMatch matching
2401 ( 2.5.13.21 NAME 'telephoneNumberSubstringsMatch'
2402 SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
2404 The telephoneNumberSubstringsMatch rule is a substrings matching
2410 Legg Expires 23 December 2005 [Page 43]
2412 INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
2415 4.2.31. uniqueMemberMatch
2417 The uniqueMemberMatch rule compares an assertion value of the Name
2418 And Optional UID syntax to an attribute value of a syntax (e.g the
2419 Name And Optional UID syntax) whose corresponding ASN.1 type is
2422 The rule evaluates to TRUE if and only if the <distinguishedName>
2423 components of the assertion value and attribute value match according
2424 to the distinguishedNameMatch rule and either, the <BitString>
2425 component is absent from both the attribute value and assertion
2426 value, or the <BitString> component is present in both the attribute
2427 value and the assertion value and the <BitString> component of the
2428 assertion value matches the <BitString> component of the attribute
2429 value according to the bitStringMatch rule.
2431 Note that this matching rule has been altered from its description in
2432 X.520 [X.520] in order to make the matching rule commutative. Server
2433 implementors should consider using the original X.520 semantics
2434 (where the matching was less exact) for approximate matching of
2435 attributes with uniqueMemberMatch as the equality matching rule.
2437 The LDAP definition for the uniqueMemberMatch matching rule is:
2439 ( 2.5.13.23 NAME 'uniqueMemberMatch'
2440 SYNTAX 1.3.6.1.4.1.1466.115.121.1.34 )
2442 The uniqueMemberMatch rule is an equality matching rule.
2446 The wordMatch rule compares an assertion value of the Directory
2447 String syntax to an attribute value of a syntax (e.g., the Directory
2448 String syntax) whose corresponding ASN.1 type is DirectoryString.
2450 The rule evaluates to TRUE if and only if the assertion value word
2451 matches, according to the semantics of caseIgnoreMatch, any word in
2452 the attribute value. The precise definition of a word is
2453 implementation specific.
2455 The LDAP definition for the wordMatch rule is:
2457 ( 2.5.13.32 NAME 'wordMatch'
2458 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
2460 5. Security Considerations
2462 In general, the LDAP-specific encodings for syntaxes defined in this
2466 Legg Expires 23 December 2005 [Page 44]
2468 INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
2471 document do not define canonical encodings. That is, a
2472 transformation from an LDAP-specific encoding into some other
2473 encoding (e.g., BER) and back into the LDAP-specific encoding will
2474 not necessarily reproduce exactly the original octets of the
2475 LDAP-specific encoding. Therefore an LDAP-specific encoding should
2476 not be used where a canonical encoding is required.
2478 Furthermore, the LDAP-specific encodings do not necessarily enable an
2479 alternative encoding of values of the Directory String and DN
2480 syntaxes to be reconstructed, e.g., a transformation from a
2481 Distinguished Encoding Rules (DER) [BER] encoding to an LDAP-specific
2482 encoding and back to a DER encoding may not reproduce the original
2483 DER encoding. Therefore LDAP-specific encodings should not be used
2484 where reversibility to DER is needed, e.g., for the verification of
2485 digital signatures. Instead, DER or a DER-reversible encoding should
2488 When interpreting security-sensitive fields, and in particular fields
2489 used to grant or deny access, implementations MUST ensure that any
2490 matching rule comparisons are done on the underlying abstract value,
2491 regardless of the particular encoding used.
2495 This document is primarily a revision of RFC 2252 by M. Wahl, A.
2496 Coulbeck, T. Howes, and S. Kille. RFC 2252 was a product of the IETF
2499 This document is based upon input of the IETF LDAPBIS working group.
2500 The author would like to thank Kathy Dally for editing the early
2501 drafts of this revision, and Jim Sermersheim and Kurt Zeilenga for
2502 their significant contributions to this revision.
2504 7. IANA Considerations
2506 The Internet Assigned Numbers Authority (IANA) is requested to update
2507 the LDAP descriptors registry [BCP64] as indicated by the following
2510 Subject: Request for LDAP Descriptor Registration Update
2511 Descriptor (short name): see comment
2512 Object Identifier: see comment
2513 Person & email address to contact for further information:
2514 Steven Legg <steven.legg@eb2bcom.com>
2516 Specification: RFC XXXX
2517 Author/Change Controller: IESG
2522 Legg Expires 23 December 2005 [Page 45]
2524 INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
2527 The following descriptors (short names) should be updated to refer
2531 ------------------------------------------------------------------
2532 bitStringMatch M 2.5.13.16
2533 booleanMatch M 2.5.13.13
2534 caseExactIA5Match M 1.3.6.1.4.1.1466.109.114.1
2535 caseExactMatch M 2.5.13.5
2536 caseExactOrderingMatch M 2.5.13.6
2537 caseExactSubstringsMatch M 2.5.13.7
2538 caseIgnoreIA5Match M 1.3.6.1.4.1.1466.109.114.2
2539 caseIgnoreListMatch M 2.5.13.11
2540 caseIgnoreListSubstringsMatch M 2.5.13.12
2541 caseIgnoreMatch M 2.5.13.2
2542 caseIgnoreOrderingMatch M 2.5.13.3
2543 caseIgnoreSubstringsMatch M 2.5.13.4
2544 directoryStringFirstComponentMatch M 2.5.13.31
2545 distinguishedNameMatch M 2.5.13.1
2546 generalizedTimeMatch M 2.5.13.27
2547 generalizedTimeOrderingMatch M 2.5.13.28
2548 integerFirstComponentMatch M 2.5.13.29
2549 integerMatch M 2.5.13.14
2550 integerOrderingMatch M 2.5.13.15
2551 keywordMatch M 2.5.13.33
2552 numericStringMatch M 2.5.13.8
2553 numericStringOrderingMatch M 2.5.13.9
2554 numericStringSubstringsMatch M 2.5.13.10
2555 objectIdentifierFirstComponentMatch M 2.5.13.30
2556 octetStringMatch M 2.5.13.17
2557 octetStringOrderingMatch M 2.5.13.18
2558 telephoneNumberMatch M 2.5.13.20
2559 telephoneNumberSubstringsMatch M 2.5.13.21
2560 uniqueMemberMatch M 2.5.13.23
2561 wordMatch M 2.5.13.32
2563 The descriptor for the object identifier 2.5.13.0 was incorrectly
2564 registered as objectIdentifiersMatch (extraneous `s') in BCP 64.
2565 It should be changed to the following with a reference to
2569 ------------------------------------------------------------------
2570 objectIdentifierMatch M 2.5.13.0
2573 Subject: Request for LDAP Descriptor Registration
2574 Descriptor (short name): caseIgnoreIA5SubstringsMatch
2578 Legg Expires 23 December 2005 [Page 46]
2580 INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
2583 Object Identifier: 1.3.6.1.4.1.1466.109.114.3
2584 Person & email address to contact for further information:
2585 Steven Legg <steven.legg@eb2bcom.com>
2587 Specification: RFC XXXX
2588 Author/Change Controller: IESG
2590 Appendix A. Summary of Syntax Object Identifiers
2592 The following list summarizes the object identifiers assigned to the
2593 syntaxes defined in this document.
2595 Syntax OBJECT IDENTIFIER
2596 ==============================================================
2597 Attribute Type Description 1.3.6.1.4.1.1466.115.121.1.3
2598 Bit String 1.3.6.1.4.1.1466.115.121.1.6
2599 Boolean 1.3.6.1.4.1.1466.115.121.1.7
2600 Country String 1.3.6.1.4.1.1466.115.121.1.11
2601 Delivery Method 1.3.6.1.4.1.1466.115.121.1.14
2602 Directory String 1.3.6.1.4.1.1466.115.121.1.15
2603 DIT Content Rule Description 1.3.6.1.4.1.1466.115.121.1.16
2604 DIT Structure Rule Description 1.3.6.1.4.1.1466.115.121.1.17
2605 DN 1.3.6.1.4.1.1466.115.121.1.12
2606 Enhanced Guide 1.3.6.1.4.1.1466.115.121.1.21
2607 Facsimile Telephone Number 1.3.6.1.4.1.1466.115.121.1.22
2608 Fax 1.3.6.1.4.1.1466.115.121.1.23
2609 Generalized Time 1.3.6.1.4.1.1466.115.121.1.24
2610 Guide 1.3.6.1.4.1.1466.115.121.1.25
2611 IA5 String 1.3.6.1.4.1.1466.115.121.1.26
2612 Integer 1.3.6.1.4.1.1466.115.121.1.27
2613 JPEG 1.3.6.1.4.1.1466.115.121.1.28
2614 LDAP Syntax Description 1.3.6.1.4.1.1466.115.121.1.54
2615 Matching Rule Description 1.3.6.1.4.1.1466.115.121.1.30
2616 Matching Rule Use Description 1.3.6.1.4.1.1466.115.121.1.31
2617 Name And Optional UID 1.3.6.1.4.1.1466.115.121.1.34
2618 Name Form Description 1.3.6.1.4.1.1466.115.121.1.35
2619 Numeric String 1.3.6.1.4.1.1466.115.121.1.36
2620 Object Class Description 1.3.6.1.4.1.1466.115.121.1.37
2621 Octet String 1.3.6.1.4.1.1466.115.121.1.40
2622 OID 1.3.6.1.4.1.1466.115.121.1.38
2623 Other Mailbox 1.3.6.1.4.1.1466.115.121.1.39
2624 Postal Address 1.3.6.1.4.1.1466.115.121.1.41
2625 Printable String 1.3.6.1.4.1.1466.115.121.1.44
2626 Substring Assertion 1.3.6.1.4.1.1466.115.121.1.58
2627 Telephone Number 1.3.6.1.4.1.1466.115.121.1.50
2628 Teletex Terminal Identifier 1.3.6.1.4.1.1466.115.121.1.51
2629 Telex Number 1.3.6.1.4.1.1466.115.121.1.52
2630 UTC Time 1.3.6.1.4.1.1466.115.121.1.53
2634 Legg Expires 23 December 2005 [Page 47]
2636 INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
2639 Appendix B. Changes from RFC 2252
2641 This annex lists the significant differences between this
2642 specification and RFC 2252.
2644 This annex is provided for informational purposes only. It is not a
2645 normative part of this specification.
2647 1. The IESG Note has been removed.
2649 2. The major part of Sections 4, 5 and 7 has been moved to [MODELS]
2650 and revised. Changes to the parts of these sections moved to
2651 [MODELS] are detailed in [MODELS].
2653 3. BNF descriptions of syntax formats have been replaced by ABNF
2654 [ABNF] specifications.
2656 4. The ambiguous statement in RFC 2252, Section 4.3 regarding the
2657 use of a backslash quoting mechanism to escape separator symbols
2658 has been removed. The escaping mechanism is now explicitly
2659 represented in the ABNF for the syntaxes where this provision
2662 5. The description of each of the LDAP syntaxes has been expanded so
2663 that they are less dependent on knowledge of X.500 for
2666 6. The relationship of LDAP syntaxes to corresponding ASN.1 type
2667 definitions has been made explicit.
2669 7. The set of characters allowed in a <PrintableString> (formerly
2670 <printablestring>) has been corrected to align with the
2671 PrintableString ASN.1 type in [ASN.1]. Specifically, the double
2672 quote character has been removed and the single quote character
2673 and equals sign have been added.
2675 8. Values of the Directory String, Printable String and Telephone
2676 Number syntaxes are now required to have at least one character.
2678 9. The <DITContentRuleDescription>, <NameFormDescription> and
2679 <DITStructureRuleDescription> rules have been moved to [MODELS].
2681 10. The corresponding ASN.1 type for the Other Mailbox syntax has
2682 been incorporated from RFC 1274.
2684 11. A corresponding ASN.1 type for the LDAP Syntax Description syntax
2690 Legg Expires 23 December 2005 [Page 48]
2692 INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
2695 12. The Binary syntax has been removed because it was not adequately
2696 specified, implementations with different incompatible
2697 interpretations exist, and it was confused with the ;binary
2700 13. All discussion of transfer options, including the ";binary"
2701 option, has been removed. All imperatives regarding binary
2702 transfer of values have been removed.
2704 14. The Delivery Method, Enhanced Guide, Guide, Octet String, Teletex
2705 Terminal Identifier and Telex Number syntaxes from RFC 2256 have
2708 15. The <criteria> rule for the Enhanced Guide and Guide syntaxes has
2709 been extended to accommodate empty "and" and "or" expressions.
2711 16. An encoding for the <ttx-value> rule in the Teletex Terminal
2712 Identifier syntax has been defined.
2714 17. The PKI-related syntaxes (Certificate, Certificate List and
2715 Certificate Pair) have been removed. They are reintroduced in
2716 [LDAP-PKI] (as is the Supported Algorithm syntax from RFC 2256).
2718 18. The MHS OR Address syntax has been removed since its
2719 specification (in RFC 2156) is not at draft standard maturity.
2721 19. The DL Submit Permission syntax has been removed as it depends on
2722 the MHS OR Address syntax.
2724 20. The Presentation Address syntax has been removed since its
2725 specification (in RFC 1278) is not at draft standard maturity.
2727 21. The ACI Item, Access Point, Audio, Data Quality, DSA Quality, DSE
2728 Type, LDAP Schema Description, Master And Shadow Access Points,
2729 Modify Rights, Protocol Information, Subtree Specification,
2730 Supplier Information, Supplier Or Consumer and Supplier And
2731 Consumer syntaxes have been removed. These syntaxes are
2732 referenced in RFC 2252, but not defined.
2734 22. The LDAP Schema Definition syntax (defined in RFC 2927) and the
2735 Mail Preference syntax have been removed on the grounds that they
2736 are out of scope for the core specification.
2738 23. The description of each of the matching rules has been expanded
2739 so that they are less dependent on knowledge of X.500 for
2742 24. The caseIgnoreIA5SubstringsMatch matching rule from RFC 2798 has
2746 Legg Expires 23 December 2005 [Page 49]
2748 INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
2753 25. The caseIgnoreListSubstringsMatch, caseIgnoreOrderingMatch and
2754 caseIgnoreSubstringsMatch matching rules have been added to the
2755 list of matching rules for which the provisions for handling
2756 leading, trailing and multiple adjoining whitespace characters
2757 apply (now through string preparation). This is consistent with
2758 the definitions of these matching rules in X.500. The
2759 caseIgnoreIA5SubstringsMatch rule has also been added to the
2762 26. The specification of the octetStringMatch matching rule from
2763 RFC 2256 has been added to this document.
2765 27. The presentationAddressMatch matching rule has been removed as it
2766 depends on an assertion syntax (Presentation Address) that is not
2767 at draft standard maturity.
2769 28. The protocolInformationMatch matching rule has been removed as it
2770 depends on an undefined assertion syntax (Protocol Information).
2772 29. The definitive reference for ASN.1 has been changed from X.208 to
2773 X.680 since X.680 is the version of ASN.1 referred to by X.500.
2775 30. The specification of the caseIgnoreListSubstringsMatch matching
2776 rule from RFC 2798 & X.520 has been added.
2778 31. String preparation algorithms have been applied to the character
2779 string matching rules.
2781 32. The specifications of the booleanMatch, caseExactMatch,
2782 caseExactOrderingMatch, caseExactSubstringsMatch,
2783 directoryStringFirstComponentMatch, integerOrderingMatch,
2784 keywordMatch, numericStringOrderingMatch,
2785 octetStringOrderingMatch and wordMatch matching rules from
2786 RFC 3698 & X.520 have been added.
2788 Normative References
2790 [KEYWORD] Bradner, S., "Key words for use in RFCs to Indicate
2791 Requirement Levels", BCP 14, RFC 2119, March 1997.
2793 [UTF8] Yergeau, F., "UTF-8, a transformation format of ISO
2794 10646", RFC 3629, November 2003.
2796 [BCP64] Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
2797 Considerations for the Lightweight Directory Access
2798 Protocol (LDAP)", BCP 64, RFC 3383, September 2002.
2802 Legg Expires 23 December 2005 [Page 50]
2804 INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
2807 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
2808 Specifications: ABNF", draft-crocker-abnf-rfc2234bis-
2809 xx.txt, a work in progress, March 2005.
2811 [ROADMAP] Zeilenga, K., "Lightweight Directory Access Protocol
2812 (LDAP): Technical Specification Road Map", draft-ietf-
2813 ldapbis-roadmap-xx.txt, a work in progress, February 2005.
2815 [MODELS] Zeilenga, K., "LDAP: Directory Information Models", draft-
2816 ietf-ldapbis-models-xx.txt, a work in progress, February
2819 [PROT] Sermersheim, J., "LDAP: The Protocol", draft-ietf-ldapbis-
2820 protocol-xx.txt, a work in progress, May 2005.
2822 [LDAPDN] Zeilenga, K., "LDAP: String Representation of
2823 Distinguished Names", draft-ietf-ldapbis-dn-xx.txt, a work
2824 in progress, February 2005.
2826 [PREP] Zeilenga, K., "LDAP: Internationalized String
2827 Preparation", draft-ietf-ldapbis-strprep-xx.txt, a work in
2828 progress, February 2005.
2830 [E.123] Notation for national and international telephone numbers,
2831 ITU-T Recommendation E.123, 1988.
2833 [FAX] Standardization of Group 3 facsimile apparatus for
2834 document transmission - Terminal Equipment and Protocols
2835 for Telematic Services, ITU-T Recommendation T.4, 1993
2837 [T.50] International Reference Alphabet (IRA) (Formerly
2838 International Alphabet No. 5 or IA5) Information
2839 Technology - 7-Bit Coded Character Set for Information
2840 Interchange, ITU-T Recommendation T.50, 1992
2842 [X.420] ITU-T Recommendation X.420 (1996) | ISO/IEC 10021-7:1997,
2843 Information Technology - Message Handling Systems (MHS):
2844 Interpersonal messaging system
2846 [X.501] ITU-T Recommendation X.501 (1993) | ISO/IEC 9594-2:1994,
2847 Information Technology - Open Systems Interconnection -
2848 The Directory: Models
2850 [X.520] ITU-T Recommendation X.520 (1993) | ISO/IEC 9594-6:1994,
2851 Information Technology - Open Systems Interconnection -
2852 The Directory: Selected attribute types
2854 [ASN.1] ITU-T Recommendation X.680 (07/02) | ISO/IEC 8824-1:2002,
2858 Legg Expires 23 December 2005 [Page 51]
2860 INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
2863 Information technology - Abstract Syntax Notation One
2864 (ASN.1): Specification of basic notation
2866 [ISO3166] ISO 3166, "Codes for the representation of names of
2869 [ISO8601] ISO 8601:2004, "Data elements and interchange formats --
2870 Information interchange -- Representation of dates and
2873 [UCS] Universal Multiple-Octet Coded Character Set (UCS) -
2874 Architecture and Basic Multilingual Plane, ISO/IEC
2875 10646-1: 1993 (with amendments).
2877 [JPEG] JPEG File Interchange Format (Version 1.02). Eric
2878 Hamilton, C-Cube Microsystems, Milpitas, CA, September 1,
2881 Informative References
2883 [RFC2252] Wahl, M., Coulbeck, A., Howes, T. and S. Kille,
2884 "Lightweight Directory Access Protocol (v3): Attribute
2885 Syntax Definitions", RFC 2252, December 1997.
2887 [RFC2256] Wahl, M., "A Summary of the X.500(96) User Schema for use
2888 with LDAPv3", RFC 2256, December 1997.
2890 [RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access
2891 Protocol (v3): Technical Specification", RFC 3377,
2894 [RFC3698] Zeilenga, K., "Lightweight Directory Access Protocol
2895 (LDAP): Additional Matching Rules", RFC 3698, February
2898 [SCHEMA] Sciberras, A., "LDAP: Schema for User Applications",
2899 draft-ietf-ldapbis-user-schema-xx.txt, a work in progress,
2902 [LDAP-PKI] Zeilenga, K. D., "Lightweight Directory Access Protocol
2903 (LDAP) schema definitions for X.509 Certificates", draft-
2904 zeilenga-ldap-x509-xx.txt, a work in progress, February
2907 [X.500] ITU-T Recommendation X.500 (1993) | ISO/IEC 9594-1:1994,
2908 Information Technology - Open Systems Interconnection -
2909 The Directory: Overview of concepts, models and services
2914 Legg Expires 23 December 2005 [Page 52]
2916 INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
2919 [BER] ITU-T Recommendation X.690 (07/02) | ISO/IEC 8825-1:2002,
2920 Information technology - ASN.1 encoding rules:
2921 Specification of Basic Encoding Rules (BER), Canonical
2922 Encoding Rules (CER) and Distinguished Encoding Rules
2929 Suite3, Woodhouse Corporate Centre
2931 Box Hill North, Victoria 3129
2934 Phone: +61 3 9896 7830
2935 Fax: +61 3 9896 7801
2936 EMail: steven.legg@eb2bcom.com
2938 Full Copyright Statement
2940 Copyright (C) The Internet Society (2005).
2942 This document is subject to the rights, licenses and restrictions
2943 contained in BCP 78, and except as set forth therein, the authors
2944 retain all their rights.
2946 This document and the information contained herein are provided on an
2947 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
2948 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
2949 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
2950 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
2951 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
2952 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
2954 Intellectual Property
2956 The IETF takes no position regarding the validity or scope of any
2957 Intellectual Property Rights or other rights that might be claimed to
2958 pertain to the implementation or use of the technology described in
2959 this document or the extent to which any license under such rights
2960 might or might not be available; nor does it represent that it has
2961 made any independent effort to identify any such rights. Information
2962 on the procedures with respect to rights in RFC documents can be
2963 found in BCP 78 and BCP 79.
2965 Copies of IPR disclosures made to the IETF Secretariat and any
2966 assurances of licenses to be made available, or the result of an
2970 Legg Expires 23 December 2005 [Page 53]
2972 INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
2975 attempt made to obtain a general license or permission for the use of
2976 such proprietary rights by implementers or users of this
2977 specification can be obtained from the IETF on-line IPR repository at
2978 http://www.ietf.org/ipr.
2980 The IETF invites any interested party to bring to its attention any
2981 copyrights, patents or patent applications, or other proprietary
2982 rights that may cover technology that may be required to implement
2983 this standard. Please address the information to the IETF at
3026 Legg Expires 23 December 2005 [Page 54]