]> git.sur5r.net Git - openldap/blob - doc/rfc/rfc4517.txt
Merge remote branch 'origin/mdb.master' into OPENLDAP_REL_ENG_2_4
[openldap] / doc / rfc / rfc4517.txt
1
2
3
4
5
6
7 Network Working Group                                       S. Legg, Ed.
8 Request for Comments: 4517                                       eB2Bcom
9 Obsoletes: 2252, 2256                                          June 2006
10 Updates: 3698
11 Category: Standards Track
12
13
14              Lightweight Directory Access Protocol (LDAP):
15                       Syntaxes and Matching Rules
16
17
18 Status of This Memo
19
20    This document specifies an Internet standards track protocol for the
21    Internet community, and requests discussion and suggestions for
22    improvements.  Please refer to the current edition of the "Internet
23    Official Protocol Standards" (STD 1) for the standardization state
24    and status of this protocol.  Distribution of this memo is unlimited.
25
26 Copyright Notice
27
28    Copyright (C) The Internet Society (2006).
29
30 Abstract
31
32    Each attribute stored in a Lightweight Directory Access Protocol
33    (LDAP) directory, whose values may be transferred in the LDAP
34    protocol, has a defined syntax that constrains the structure and
35    format of its values.  The comparison semantics for values of a
36    syntax are not part of the syntax definition but are instead provided
37    through separately defined matching rules.  Matching rules specify an
38    argument, an assertion value, which also has a defined syntax.  This
39    document defines a base set of syntaxes and matching rules for use in
40    defining attributes for LDAP directories.
41
42 Table of Contents
43
44    1. Introduction ....................................................3
45    2. Conventions .....................................................4
46    3. Syntaxes ........................................................4
47       3.1. General Considerations .....................................5
48       3.2. Common Definitions .........................................5
49       3.3. Syntax Definitions .........................................6
50            3.3.1. Attribute Type Description ..........................6
51            3.3.2. Bit String ..........................................6
52            3.3.3. Boolean .............................................7
53            3.3.4. Country String ......................................7
54            3.3.5. Delivery Method .....................................8
55
56
57
58 Legg                        Standards Track                     [Page 1]
59 \f
60 RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
61
62
63            3.3.6. Directory String ....................................8
64            3.3.7. DIT Content Rule Description ........................9
65            3.3.8. DIT Structure Rule Description .....................10
66            3.3.9. DN .................................................10
67            3.3.10. Enhanced Guide ....................................11
68            3.3.11. Facsimile Telephone Number ........................12
69            3.3.12. Fax ...............................................12
70            3.3.13. Generalized Time ..................................13
71            3.3.14. Guide .............................................14
72            3.3.15. IA5 String ........................................15
73            3.3.16. Integer ...........................................15
74            3.3.17. JPEG ..............................................15
75            3.3.18. LDAP Syntax Description ...........................16
76            3.3.19. Matching Rule Description .........................16
77            3.3.20. Matching Rule Use Description .....................17
78            3.3.21. Name and Optional UID .............................17
79            3.3.22. Name Form Description .............................18
80            3.3.23. Numeric String ....................................18
81            3.3.24. Object Class Description ..........................18
82            3.3.25. Octet String ......................................19
83            3.3.26. OID ...............................................19
84            3.3.27. Other Mailbox .....................................20
85            3.3.28. Postal Address ....................................20
86            3.3.29. Printable String ..................................21
87            3.3.30. Substring Assertion ...............................22
88            3.3.31. Telephone Number ..................................23
89            3.3.32. Teletex Terminal Identifier .......................23
90            3.3.33. Telex Number ......................................24
91            3.3.34. UTC Time ..........................................24
92    4. Matching Rules .................................................25
93       4.1. General Considerations ....................................25
94       4.2. Matching Rule Definitions .................................27
95            4.2.1. bitStringMatch .....................................27
96            4.2.2. booleanMatch .......................................28
97            4.2.3. caseExactIA5Match ..................................28
98            4.2.4. caseExactMatch .....................................29
99            4.2.5. caseExactOrderingMatch .............................29
100            4.2.6. caseExactSubstringsMatch ...........................30
101            4.2.7. caseIgnoreIA5Match .................................30
102            4.2.8. caseIgnoreIA5SubstringsMatch .......................31
103            4.2.9. caseIgnoreListMatch ................................31
104            4.2.10. caseIgnoreListSubstringsMatch .....................32
105            4.2.11. caseIgnoreMatch ...................................33
106            4.2.12. caseIgnoreOrderingMatch ...........................33
107            4.2.13. caseIgnoreSubstringsMatch .........................34
108            4.2.14. directoryStringFirstComponentMatch ................34
109            4.2.15. distinguishedNameMatch ............................35
110            4.2.16. generalizedTimeMatch ..............................36
111
112
113
114 Legg                        Standards Track                     [Page 2]
115 \f
116 RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
117
118
119            4.2.17. generalizedTimeOrderingMatch ......................36
120            4.2.18. integerFirstComponentMatch ........................36
121            4.2.19. integerMatch ......................................37
122            4.2.20. integerOrderingMatch ..............................37
123            4.2.21. keywordMatch ......................................38
124            4.2.22. numericStringMatch ................................38
125            4.2.23. numericStringOrderingMatch ........................39
126            4.2.24. numericStringSubstringsMatch ......................39
127            4.2.25. objectIdentifierFirstComponentMatch ...............40
128            4.2.26. objectIdentifierMatch .............................40
129            4.2.27. octetStringMatch ..................................41
130            4.2.28. octetStringOrderingMatch ..........................41
131            4.2.29. telephoneNumberMatch ..............................42
132            4.2.30. telephoneNumberSubstringsMatch ....................42
133            4.2.31. uniqueMemberMatch .................................43
134            4.2.32. wordMatch .........................................44
135    5. Security Considerations ........................................44
136    6. Acknowledgements ...............................................44
137    7. IANA Considerations ............................................45
138    8. References .....................................................46
139       8.1. Normative References ......................................46
140       8.2. Informative References ....................................48
141    Appendix A. Summary of Syntax Object Identifiers ..................49
142    Appendix B. Changes from RFC 2252 .................................49
143
144 1.  Introduction
145
146    Each attribute stored in a Lightweight Directory Access Protocol
147    (LDAP) directory [RFC4510], whose values may be transferred in the
148    LDAP protocol [RFC4511], has a defined syntax (i.e., data type) that
149    constrains the structure and format of its values.  The comparison
150    semantics for values of a syntax are not part of the syntax
151    definition but are instead provided through separately defined
152    matching rules.  Matching rules specify an argument, an assertion
153    value, which also has a defined syntax.  This document defines a base
154    set of syntaxes and matching rules for use in defining attributes for
155    LDAP directories.
156
157    Readers are advised to familiarize themselves with the Directory
158    Information Models [RFC4512] before reading the rest of this
159    document.  Section 3 provides definitions for the base set of LDAP
160    syntaxes.  Section 4 provides definitions for the base set of
161    matching rules for LDAP.
162
163    This document is an integral part of the LDAP technical specification
164    [RFC4510], which obsoletes the previously defined LDAP technical
165    specification, RFC 3377, in its entirety.
166
167
168
169
170 Legg                        Standards Track                     [Page 3]
171 \f
172 RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
173
174
175    Sections 4, 5, and 7 of RFC 2252 are obsoleted by [RFC4512].  The
176    remainder of RFC 2252 is obsoleted by this document.  Sections 6 and
177    8 of RFC 2256 are obsoleted by this document.  The remainder of RFC
178    2256 is obsoleted by [RFC4519] and [RFC4512].  All but Section 2.11
179    of RFC 3698 is obsoleted by this document.
180
181    A number of schema elements that were included in the previous
182    revision of the LDAP technical specification are not included in this
183    revision of LDAP.  Public Key Infrastructure schema elements are now
184    specified in [RFC4523].  Unless reintroduced in future technical
185    specifications, the remainder are to be considered Historic.
186
187    The changes with respect to RFC 2252 are described in Appendix B of
188    this document.
189
190 2.  Conventions
191
192    In this document, the key words "MUST", "MUST NOT", "REQUIRED",
193    "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
194    and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119
195    [RFC2119].
196
197    Syntax definitions are written according to the <SyntaxDescription>
198    ABNF [RFC4234] rule specified in [RFC4512], and matching rule
199    definitions are written according to the <MatchingRuleDescription>
200    ABNF rule specified in [RFC4512], except that the syntax and matching
201    rule definitions provided in this document are line-wrapped for
202    readability.  When such definitions are transferred as attribute
203    values in the LDAP protocol (e.g., as values of the ldapSyntaxes and
204    matchingRules attributes [RFC4512], respectively), then those values
205    would not contain line breaks.
206
207 3.  Syntaxes
208
209    Syntax definitions constrain the structure of attribute values stored
210    in an LDAP directory, and determine the representation of attribute
211    and assertion values transferred in the LDAP protocol.
212
213    Syntaxes that are required for directory operation, or that are in
214    common use, are specified in this section.  Servers SHOULD recognize
215    all the syntaxes listed in this document, but are not required to
216    otherwise support them, and MAY recognise or support other syntaxes.
217    However, the definition of additional arbitrary syntaxes is
218    discouraged since it will hinder interoperability.  Client and server
219    implementations typically do not have the ability to dynamically
220    recognize new syntaxes.
221
222
223
224
225
226 Legg                        Standards Track                     [Page 4]
227 \f
228 RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
229
230
231 3.1.  General Considerations
232
233    The description of each syntax specifies how attribute or assertion
234    values conforming to the syntax are to be represented when
235    transferred in the LDAP protocol [RFC4511].  This representation is
236    referred to as the LDAP-specific encoding to distinguish it from
237    other methods of encoding attribute values (e.g., the Basic Encoding
238    Rules (BER) encoding [BER] used by X.500 [X.500] directories).
239
240    The LDAP-specific encoding of a given attribute syntax always
241    produces octet-aligned values.  To the greatest extent possible,
242    encoding rules for LDAP syntaxes should produce character strings
243    that can be displayed with little or no translation by clients
244    implementing LDAP.  However, clients MUST NOT assume that the LDAP-
245    specific encoding of a value of an unrecognized syntax is a human-
246    readable character string.  There are a few cases (e.g., the JPEG
247    syntax) when it is not reasonable to produce a human-readable
248    representation.
249
250    Each LDAP syntax is uniquely identified with an object identifier
251    [ASN.1] represented in the dotted-decimal format (short descriptive
252    names are not defined for syntaxes).  These object identifiers are
253    not intended to be displayed to users.  The object identifiers for
254    the syntaxes defined in this document are summarized in Appendix A.
255
256    A suggested minimum upper bound on the number of characters in an
257    attribute value with a string-based syntax, or the number of octets
258    in a value for all other syntaxes, MAY be indicated by appending the
259    bound inside of curly braces following the syntax's OBJECT IDENTIFIER
260    in an attribute type definition (see the <noidlen> rule in
261    [RFC4512]).  Such a bound is not considered part of the syntax
262    identifier.
263
264    For example, "1.3.6.1.4.1.1466.115.121.1.15{64}" in an attribute
265    definition suggests that the directory server will allow a value of
266    the attribute to be up to 64 characters long, although it may allow
267    longer character strings.  Note that a single character of the
268    Directory String syntax can be encoded in more than one octet, since
269    UTF-8 [RFC3629] is a variable-length encoding.  Therefore, a 64-
270    character string may be more than 64 octets in length.
271
272 3.2.  Common Definitions
273
274    The following ABNF rules are used in a number of the syntax
275    definitions in Section 3.3.
276
277       PrintableCharacter = ALPHA / DIGIT / SQUOTE / LPAREN / RPAREN /
278                            PLUS / COMMA / HYPHEN / DOT / EQUALS /
279
280
281
282 Legg                        Standards Track                     [Page 5]
283 \f
284 RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
285
286
287                            SLASH / COLON / QUESTION / SPACE
288       PrintableString    = 1*PrintableCharacter
289       IA5String          = *(%x00-7F)
290       SLASH              = %x2F  ; forward slash ("/")
291       COLON              = %x3A  ; colon (":")
292       QUESTION           = %x3F  ; question mark ("?")
293
294    The <ALPHA>, <DIGIT>, <SQUOTE>, <LPAREN>, <RPAREN>, <PLUS>, <COMMA>,
295    <HYPHEN>, <DOT>, <EQUALS>, and <SPACE> rules are defined in
296    [RFC4512].
297
298 3.3.  Syntax Definitions
299
300 3.3.1.  Attribute Type Description
301
302    A value of the Attribute Type Description syntax is the definition of
303    an attribute type.  The LDAP-specific encoding of a value of this
304    syntax is defined by the <AttributeTypeDescription> rule in
305    [RFC4512].
306
307       For example, the following definition of the createTimestamp
308       attribute type from [RFC4512] is also a value of the Attribute
309       Type Description syntax.  (Note: Line breaks have been added for
310       readability; they are not part of the value when transferred in
311       protocol.)
312
313          ( 2.5.18.1 NAME 'createTimestamp'
314             EQUALITY generalizedTimeMatch
315             ORDERING generalizedTimeOrderingMatch
316             SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
317             SINGLE-VALUE NO-USER-MODIFICATION
318             USAGE directoryOperation )
319
320    The LDAP definition for the Attribute Type Description syntax is:
321
322       ( 1.3.6.1.4.1.1466.115.121.1.3 DESC 'Attribute Type Description' )
323
324    This syntax corresponds to the AttributeTypeDescription ASN.1 type
325    from [X.501].
326
327 3.3.2.  Bit String
328
329    A value of the Bit String syntax is a sequence of binary digits.  The
330    LDAP-specific encoding of a value of this syntax is defined by the
331    following ABNF:
332
333       BitString    = SQUOTE *binary-digit SQUOTE "B"
334       binary-digit = "0" / "1"
335
336
337
338 Legg                        Standards Track                     [Page 6]
339 \f
340 RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
341
342
343    The <SQUOTE> rule is defined in [RFC4512].
344
345       Example:
346          '0101111101'B
347
348    The LDAP definition for the Bit String syntax is:
349
350       ( 1.3.6.1.4.1.1466.115.121.1.6 DESC 'Bit String' )
351
352    This syntax corresponds to the BIT STRING ASN.1 type from [ASN.1].
353
354 3.3.3.  Boolean
355
356    A value of the Boolean syntax is one of the Boolean values, true or
357    false.  The LDAP-specific encoding of a value of this syntax is
358    defined by the following ABNF:
359
360       Boolean = "TRUE" / "FALSE"
361
362    The LDAP definition for the Boolean syntax is:
363
364       ( 1.3.6.1.4.1.1466.115.121.1.7 DESC 'Boolean' )
365
366    This syntax corresponds to the BOOLEAN ASN.1 type from [ASN.1].
367
368 3.3.4.  Country String
369
370    A value of the Country String syntax is one of the two-character
371    codes from ISO 3166 [ISO3166] for representing a country.  The LDAP-
372    specific encoding of a value of this syntax is defined by the
373    following ABNF:
374
375       CountryString  = 2(PrintableCharacter)
376
377    The <PrintableCharacter> rule is defined in Section 3.2.
378
379       Examples:
380
381          US
382          AU
383
384    The LDAP definition for the Country String syntax is:
385
386       ( 1.3.6.1.4.1.1466.115.121.1.11 DESC 'Country String' )
387
388    This syntax corresponds to the following ASN.1 type from [X.520]:
389
390       PrintableString (SIZE (2)) -- ISO 3166 codes only
391
392
393
394 Legg                        Standards Track                     [Page 7]
395 \f
396 RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
397
398
399 3.3.5.  Delivery Method
400
401    A value of the Delivery Method syntax is a sequence of items that
402    indicate, in preference order, the service(s) by which an entity is
403    willing and/or capable of receiving messages.  The LDAP-specific
404    encoding of a value of this syntax is defined by the following ABNF:
405
406       DeliveryMethod = pdm *( WSP DOLLAR WSP pdm )
407
408       pdm = "any" / "mhs" / "physical" / "telex" / "teletex" /
409             "g3fax" / "g4fax" / "ia5" / "videotex" / "telephone"
410
411    The <WSP> and <DOLLAR> rules are defined in [RFC4512].
412
413       Example:
414          telephone $ videotex
415
416    The LDAP definition for the Delivery Method syntax is:
417
418       ( 1.3.6.1.4.1.1466.115.121.1.14 DESC 'Delivery Method' )
419
420    This syntax corresponds to the following ASN.1 type from [X.520]:
421
422       SEQUENCE OF INTEGER {
423           any-delivery-method     (0),
424           mhs-delivery            (1),
425           physical-delivery       (2),
426           telex-delivery          (3),
427           teletex-delivery        (4),
428           g3-facsimile-delivery   (5),
429           g4-facsimile-delivery   (6),
430           ia5-terminal-delivery   (7),
431           videotex-delivery       (8),
432           telephone-delivery      (9) }
433
434 3.3.6.  Directory String
435
436    A value of the Directory String syntax is a string of one or more
437    arbitrary characters from the Universal Character Set (UCS) [UCS].  A
438    zero-length character string is not permitted.  The LDAP-specific
439    encoding of a value of this syntax is the UTF-8 encoding [RFC3629] of
440    the character string.  Such encodings conform to the following ABNF:
441
442       DirectoryString = 1*UTF8
443
444    The <UTF8> rule is defined in [RFC4512].
445
446
447
448
449
450 Legg                        Standards Track                     [Page 8]
451 \f
452 RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
453
454
455       Example:
456          This is a value of Directory String containing #!%#@.
457
458    Servers and clients MUST be prepared to receive arbitrary UCS code
459    points, including code points outside the range of printable ASCII
460    and code points not presently assigned to any character.
461
462    Attribute type definitions using the Directory String syntax should
463    not restrict the format of Directory String values, e.g., by
464    requiring that the character string conforms to specific patterns
465    described by ABNF.  A new syntax should be defined in such cases.
466
467    The LDAP definition for the Directory String syntax is:
468
469       ( 1.3.6.1.4.1.1466.115.121.1.15 DESC 'Directory String' )
470
471    This syntax corresponds to the DirectoryString parameterized ASN.1
472    type from [X.520].
473
474    The DirectoryString ASN.1 type allows a choice between the
475    TeletexString, PrintableString, or UniversalString ASN.1 types from
476    [ASN.1].  However, note that the chosen alternative is not indicated
477    in the LDAP-specific encoding of a Directory String value.
478
479    Implementations that convert Directory String values from the LDAP-
480    specific encoding to the BER encoding used by X.500 must choose an
481    alternative that permits the particular characters in the string and
482    must convert the characters from the UTF-8 encoding into the
483    character encoding of the chosen alternative.  When converting
484    Directory String values from the BER encoding to the LDAP-specific
485    encoding, the characters must be converted from the character
486    encoding of the chosen alternative into the UTF-8 encoding.  These
487    conversions SHOULD be done in a manner consistent with the Transcode
488    step of the string preparation algorithms [RFC4518] for LDAP.
489
490 3.3.7.  DIT Content Rule Description
491
492    A value of the DIT Content Rule Description syntax is the definition
493    of a DIT (Directory Information Tree) content rule.  The LDAP-
494    specific encoding of a value of this syntax is defined by the
495    <DITContentRuleDescription> rule in [RFC4512].
496
497       Example:
498          ( 2.5.6.4 DESC 'content rule for organization'
499             NOT ( x121Address $ telexNumber ) )
500
501       Note: A line break has been added for readability; it is not part
502       of the value.
503
504
505
506 Legg                        Standards Track                     [Page 9]
507 \f
508 RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
509
510
511    The LDAP definition for the DIT Content Rule Description syntax is:
512
513       ( 1.3.6.1.4.1.1466.115.121.1.16
514          DESC 'DIT Content Rule Description' )
515
516    This syntax corresponds to the DITContentRuleDescription ASN.1 type
517    from [X.501].
518
519 3.3.8.  DIT Structure Rule Description
520
521    A value of the DIT Structure Rule Description syntax is the
522    definition of a DIT structure rule.  The LDAP-specific encoding of a
523    value of this syntax is defined by the <DITStructureRuleDescription>
524    rule in [RFC4512].
525
526       Example:
527          ( 2 DESC 'organization structure rule' FORM 2.5.15.3 )
528
529    The LDAP definition for the DIT Structure Rule Description syntax is:
530
531       ( 1.3.6.1.4.1.1466.115.121.1.17
532          DESC 'DIT Structure Rule Description' )
533
534    This syntax corresponds to the DITStructureRuleDescription ASN.1 type
535    from [X.501].
536
537 3.3.9.  DN
538
539    A value of the DN syntax is the (purported) distinguished name (DN)
540    of an entry [RFC4512].  The LDAP-specific encoding of a value of this
541    syntax is defined by the <distinguishedName> rule from the string
542    representation of distinguished names [RFC4514].
543
544       Examples (from [RFC4514]):
545          UID=jsmith,DC=example,DC=net
546          OU=Sales+CN=J. Smith,DC=example,DC=net
547          CN=John Smith\, III,DC=example,DC=net
548          CN=Before\0dAfter,DC=example,DC=net
549          1.3.6.1.4.1.1466.0=#04024869,DC=example,DC=com
550          CN=Lu\C4\8Di\C4\87
551
552    The LDAP definition for the DN syntax is:
553
554       ( 1.3.6.1.4.1.1466.115.121.1.12 DESC 'DN' )
555
556    The DN syntax corresponds to the DistinguishedName ASN.1 type from
557    [X.501].  Note that a BER encoded distinguished name (as used by
558    X.500) re-encoded into the LDAP-specific encoding is not necessarily
559
560
561
562 Legg                        Standards Track                    [Page 10]
563 \f
564 RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
565
566
567    reversible to the original BER encoding since the chosen string type
568    in any DirectoryString components of the distinguished name is not
569    indicated in the LDAP-specific encoding of the distinguished name
570    (see Section 3.3.6).
571
572 3.3.10.  Enhanced Guide
573
574    A value of the Enhanced Guide syntax suggests criteria, which consist
575    of combinations of attribute types and filter operators, to be used
576    in constructing filters to search for entries of particular object
577    classes.  The Enhanced Guide syntax improves upon the Guide syntax by
578    allowing the recommended depth of the search to be specified.
579
580    The LDAP-specific encoding of a value of this syntax is defined by
581    the following ABNF:
582
583       EnhancedGuide = object-class SHARP WSP criteria WSP
584                          SHARP WSP subset
585       object-class  = WSP oid WSP
586       subset        = "baseobject" / "oneLevel" / "wholeSubtree"
587
588       criteria   = and-term *( BAR and-term )
589       and-term   = term *( AMPERSAND term )
590       term       = EXCLAIM term /
591                    attributetype DOLLAR match-type /
592                    LPAREN criteria RPAREN /
593                    true /
594                    false
595       match-type = "EQ" / "SUBSTR" / "GE" / "LE" / "APPROX"
596       true       = "?true"
597       false      = "?false"
598       BAR        = %x7C  ; vertical bar ("|")
599       AMPERSAND  = %x26  ; ampersand ("&")
600       EXCLAIM    = %x21  ; exclamation mark ("!")
601
602    The <SHARP>, <WSP>, <oid>, <LPAREN>, <RPAREN>, <attributetype>, and
603    <DOLLAR> rules are defined in [RFC4512].
604
605    The LDAP definition for the Enhanced Guide syntax is:
606
607       ( 1.3.6.1.4.1.1466.115.121.1.21 DESC 'Enhanced Guide' )
608
609       Example:
610          person#(sn$EQ)#oneLevel
611
612    The Enhanced Guide syntax corresponds to the EnhancedGuide ASN.1 type
613    from [X.520].  The EnhancedGuide type references the Criteria ASN.1
614    type, also from [X.520].  The <true> rule, above, represents an empty
615
616
617
618 Legg                        Standards Track                    [Page 11]
619 \f
620 RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
621
622
623    "and" expression in a value of the Criteria type.  The <false> rule,
624    above, represents an empty "or" expression in a value of the Criteria
625    type.
626
627 3.3.11.  Facsimile Telephone Number
628
629    A value of the Facsimile Telephone Number syntax is a subscriber
630    number of a facsimile device on the public switched telephone
631    network.  The LDAP-specific encoding of a value of this syntax is
632    defined by the following ABNF:
633
634       fax-number       = telephone-number *( DOLLAR fax-parameter )
635       telephone-number = PrintableString
636       fax-parameter    = "twoDimensional" /
637                          "fineResolution" /
638                          "unlimitedLength" /
639                          "b4Length" /
640                          "a3Width" /
641                          "b4Width" /
642                          "uncompressed"
643
644    The <telephone-number> is a string of printable characters that
645    complies with the internationally agreed format for representing
646    international telephone numbers [E.123].  The <PrintableString> rule
647    is defined in Section 3.2.  The <DOLLAR> rule is defined in
648    [RFC4512].
649
650    The LDAP definition for the Facsimile Telephone Number syntax is:
651
652       ( 1.3.6.1.4.1.1466.115.121.1.22 DESC 'Facsimile Telephone Number')
653
654    The Facsimile Telephone Number syntax corresponds to the
655    FacsimileTelephoneNumber ASN.1 type from [X.520].
656
657 3.3.12.  Fax
658
659    A value of the Fax syntax is an image that is produced using the
660    Group 3 facsimile process [FAX] to duplicate an object, such as a
661    memo.  The LDAP-specific encoding of a value of this syntax is the
662    string of octets for a Group 3 Fax image as defined in [FAX].
663
664    The LDAP definition for the Fax syntax is:
665
666       ( 1.3.6.1.4.1.1466.115.121.1.23 DESC 'Fax' )
667
668    The ASN.1 type corresponding to the Fax syntax is defined as follows,
669    assuming EXPLICIT TAGS:
670
671
672
673
674 Legg                        Standards Track                    [Page 12]
675 \f
676 RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
677
678
679       Fax ::= CHOICE {
680         g3-facsimile  [3] G3FacsimileBodyPart
681       }
682
683    The G3FacsimileBodyPart ASN.1 type is defined in [X.420].
684
685 3.3.13.  Generalized Time
686
687    A value of the Generalized Time syntax is a character string
688    representing a date and time.  The LDAP-specific encoding of a value
689    of this syntax is a restriction of the format defined in [ISO8601],
690    and is described by the following ABNF:
691
692       GeneralizedTime = century year month day hour
693                            [ minute [ second / leap-second ] ]
694                            [ fraction ]
695                            g-time-zone
696
697       century = 2(%x30-39) ; "00" to "99"
698       year    = 2(%x30-39) ; "00" to "99"
699       month   =   ( %x30 %x31-39 ) ; "01" (January) to "09"
700                 / ( %x31 %x30-32 ) ; "10" to "12"
701       day     =   ( %x30 %x31-39 )    ; "01" to "09"
702                 / ( %x31-32 %x30-39 ) ; "10" to "29"
703                 / ( %x33 %x30-31 )    ; "30" to "31"
704       hour    = ( %x30-31 %x30-39 ) / ( %x32 %x30-33 ) ; "00" to "23"
705       minute  = %x30-35 %x30-39                        ; "00" to "59"
706
707       second      = ( %x30-35 %x30-39 ) ; "00" to "59"
708       leap-second = ( %x36 %x30 )       ; "60"
709
710       fraction        = ( DOT / COMMA ) 1*(%x30-39)
711       g-time-zone     = %x5A  ; "Z"
712                         / g-differential
713       g-differential  = ( MINUS / PLUS ) hour [ minute ]
714       MINUS           = %x2D  ; minus sign ("-")
715
716    The <DOT>, <COMMA>, and <PLUS> rules are defined in [RFC4512].
717
718    The above ABNF allows character strings that do not represent valid
719    dates (in the Gregorian calendar) and/or valid times (e.g., February
720    31, 1994).  Such character strings SHOULD be considered invalid for
721    this syntax.
722
723    The time value represents coordinated universal time (equivalent to
724    Greenwich Mean Time) if the "Z" form of <g-time-zone> is used;
725    otherwise, the value represents a local time in the time zone
726    indicated by <g-differential>.  In the latter case, coordinated
727
728
729
730 Legg                        Standards Track                    [Page 13]
731 \f
732 RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
733
734
735    universal time can be calculated by subtracting the differential from
736    the local time.  The "Z" form of <g-time-zone> SHOULD be used in
737    preference to <g-differential>.
738
739    If <minute> is omitted, then <fraction> represents a fraction of an
740    hour; otherwise, if <second> and <leap-second> are omitted, then
741    <fraction> represents a fraction of a minute; otherwise, <fraction>
742    represents a fraction of a second.
743
744       Examples:
745          199412161032Z
746          199412160532-0500
747
748    Both example values represent the same coordinated universal time:
749    10:32 AM, December 16, 1994.
750
751    The LDAP definition for the Generalized Time syntax is:
752
753       ( 1.3.6.1.4.1.1466.115.121.1.24 DESC 'Generalized Time' )
754
755    This syntax corresponds to the GeneralizedTime ASN.1 type from
756    [ASN.1], with the constraint that local time without a differential
757    SHALL NOT be used.
758
759 3.3.14.  Guide
760
761    A value of the Guide syntax suggests criteria, which consist of
762    combinations of attribute types and filter operators, to be used in
763    constructing filters to search for entries of particular object
764    classes.  The Guide syntax is obsolete and should not be used for
765    defining new attribute types.
766
767    The LDAP-specific encoding of a value of this syntax is defined by
768    the following ABNF:
769
770       Guide = [ object-class SHARP ] criteria
771
772    The <object-class> and <criteria> rules are defined in Section
773    3.3.10.  The <SHARP> rule is defined in [RFC4512].
774
775    The LDAP definition for the Guide syntax is:
776
777       ( 1.3.6.1.4.1.1466.115.121.1.25 DESC 'Guide' )
778
779    The Guide syntax corresponds to the Guide ASN.1 type from [X.520].
780
781
782
783
784
785
786 Legg                        Standards Track                    [Page 14]
787 \f
788 RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
789
790
791 3.3.15.  IA5 String
792
793    A value of the IA5 String syntax is a string of zero, one, or more
794    characters from International Alphabet 5 (IA5) [T.50], the
795    international version of the ASCII character set.  The LDAP-specific
796    encoding of a value of this syntax is the unconverted string of
797    characters, which conforms to the <IA5String> rule in Section 3.2.
798
799    The LDAP definition for the IA5 String syntax is:
800
801       ( 1.3.6.1.4.1.1466.115.121.1.26 DESC 'IA5 String' )
802
803    This syntax corresponds to the IA5String ASN.1 type from [ASN.1].
804
805 3.3.16.  Integer
806
807    A value of the Integer syntax is a whole number of unlimited
808    magnitude.  The LDAP-specific encoding of a value of this syntax is
809    the optionally signed decimal digit character string representation
810    of the number (for example, the number 1321 is represented by the
811    character string "1321").  The encoding is defined by the following
812    ABNF:
813
814       Integer = ( HYPHEN LDIGIT *DIGIT ) / number
815
816    The <HYPHEN>, <LDIGIT>, <DIGIT>, and <number> rules are defined in
817    [RFC4512].
818
819    The LDAP definition for the Integer syntax is:
820
821       ( 1.3.6.1.4.1.1466.115.121.1.27 DESC 'INTEGER' )
822
823    This syntax corresponds to the INTEGER ASN.1 type from [ASN.1].
824
825 3.3.17.  JPEG
826
827    A value of the JPEG syntax is an image in the JPEG File Interchange
828    Format (JFIF), as described in [JPEG].  The LDAP-specific encoding of
829    a value of this syntax is the sequence of octets of the JFIF encoding
830    of the image.
831
832    The LDAP definition for the JPEG syntax is:
833
834       ( 1.3.6.1.4.1.1466.115.121.1.28 DESC 'JPEG' )
835
836    The JPEG syntax corresponds to the following ASN.1 type:
837
838
839
840
841
842 Legg                        Standards Track                    [Page 15]
843 \f
844 RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
845
846
847       JPEG ::= OCTET STRING (CONSTRAINED BY
848                    { -- contents octets are an image in the --
849                      -- JPEG File Interchange Format -- })
850
851 3.3.18.  LDAP Syntax Description
852
853    A value of the LDAP Syntax Description syntax is the description of
854    an LDAP syntax.  The LDAP-specific encoding of a value of this syntax
855    is defined by the <SyntaxDescription> rule in [RFC4512].
856
857    The LDAP definition for the LDAP Syntax Description syntax is:
858
859       ( 1.3.6.1.4.1.1466.115.121.1.54 DESC 'LDAP Syntax Description' )
860
861    The above LDAP definition for the LDAP Syntax Description syntax is
862    itself a legal value of the LDAP Syntax Description syntax.
863
864    The ASN.1 type corresponding to the LDAP Syntax Description syntax is
865    defined as follows, assuming EXPLICIT TAGS:
866
867       LDAPSyntaxDescription ::= SEQUENCE {
868           identifier      OBJECT IDENTIFIER,
869           description     DirectoryString { ub-schema } OPTIONAL }
870
871    The DirectoryString parameterized ASN.1 type is defined in [X.520].
872
873    The value of ub-schema (an integer) is implementation defined.  A
874    non-normative definition appears in [X.520].
875
876 3.3.19.  Matching Rule Description
877
878    A value of the Matching Rule Description syntax is the definition of
879    a matching rule.  The LDAP-specific encoding of a value of this
880    syntax is defined by the <MatchingRuleDescription> rule in [RFC4512].
881
882       Example:
883          ( 2.5.13.2 NAME 'caseIgnoreMatch'
884             SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
885
886    Note: A line break has been added for readability; it is not part of
887    the syntax.
888
889    The LDAP definition for the Matching Rule Description syntax is:
890
891       ( 1.3.6.1.4.1.1466.115.121.1.30 DESC 'Matching Rule Description' )
892
893    This syntax corresponds to the MatchingRuleDescription ASN.1 type
894    from [X.501].
895
896
897
898 Legg                        Standards Track                    [Page 16]
899 \f
900 RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
901
902
903 3.3.20.  Matching Rule Use Description
904
905    A value of the Matching Rule Use Description syntax indicates the
906    attribute types to which a matching rule may be applied in an
907    extensibleMatch search filter [RFC4511].  The LDAP-specific encoding
908    of a value of this syntax is defined by the
909    <MatchingRuleUseDescription> rule in [RFC4512].
910
911       Example:
912          ( 2.5.13.16 APPLIES ( givenName $ surname ) )
913
914    The LDAP definition for the Matching Rule Use Description syntax is:
915
916       ( 1.3.6.1.4.1.1466.115.121.1.31
917          DESC 'Matching Rule Use Description' )
918
919    This syntax corresponds to the MatchingRuleUseDescription ASN.1 type
920    from [X.501].
921
922 3.3.21.  Name and Optional UID
923
924    A value of the Name and Optional UID syntax is the distinguished name
925    [RFC4512] of an entity optionally accompanied by a unique identifier
926    that serves to differentiate the entity from others with an identical
927    distinguished name.
928
929    The LDAP-specific encoding of a value of this syntax is defined by
930    the following ABNF:
931
932       NameAndOptionalUID = distinguishedName [ SHARP BitString ]
933
934    The <BitString> rule is defined in Section 3.3.2.  The
935    <distinguishedName> rule is defined in [RFC4514].  The <SHARP> rule
936    is defined in [RFC4512].
937
938    Note that although the '#' character may occur in the string
939    representation of a distinguished name, no additional escaping of
940    this character is performed when a <distinguishedName> is encoded in
941    a <NameAndOptionalUID>.
942
943       Example:
944          1.3.6.1.4.1.1466.0=#04024869,O=Test,C=GB#'0101'B
945
946    The LDAP definition for the Name and Optional UID syntax is:
947
948       ( 1.3.6.1.4.1.1466.115.121.1.34 DESC 'Name And Optional UID' )
949
950
951
952
953
954 Legg                        Standards Track                    [Page 17]
955 \f
956 RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
957
958
959    This syntax corresponds to the NameAndOptionalUID ASN.1 type from
960    [X.520].
961
962 3.3.22.  Name Form Description
963
964    A value of the Name Form Description syntax is the definition of a
965    name form, which regulates how entries may be named.  The LDAP-
966    specific encoding of a value of this syntax is defined by the
967    <NameFormDescription> rule in [RFC4512].
968
969       Example:
970          ( 2.5.15.3 NAME 'orgNameForm' OC organization MUST o )
971
972    The LDAP definition for the Name Form Description syntax is:
973
974       ( 1.3.6.1.4.1.1466.115.121.1.35 DESC 'Name Form Description' )
975
976    This syntax corresponds to the NameFormDescription ASN.1 type from
977    [X.501].
978
979 3.3.23.  Numeric String
980
981    A value of the Numeric String syntax is a sequence of one or more
982    numerals and spaces.  The LDAP-specific encoding of a value of this
983    syntax is the unconverted string of characters, which conforms to the
984    following ABNF:
985
986       NumericString = 1*(DIGIT / SPACE)
987
988    The <DIGIT> and <SPACE> rules are defined in [RFC4512].
989
990       Example:
991          15 079 672 281
992
993    The LDAP definition for the Numeric String syntax is:
994
995       ( 1.3.6.1.4.1.1466.115.121.1.36 DESC 'Numeric String' )
996
997    This syntax corresponds to the NumericString ASN.1 type from [ASN.1].
998
999 3.3.24.  Object Class Description
1000
1001    A value of the Object Class Description syntax is the definition of
1002    an object class.  The LDAP-specific encoding of a value of this
1003    syntax is defined by the <ObjectClassDescription> rule in [RFC4512].
1004
1005
1006
1007
1008
1009
1010 Legg                        Standards Track                    [Page 18]
1011 \f
1012 RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
1013
1014
1015       Example:
1016          ( 2.5.6.2 NAME 'country' SUP top STRUCTURAL MUST c
1017             MAY ( searchGuide $ description ) )
1018
1019    Note: A line break has been added for readability; it is not part of
1020    the syntax.
1021
1022    The LDAP definition for the Object Class Description syntax is:
1023
1024       ( 1.3.6.1.4.1.1466.115.121.1.37 DESC 'Object Class Description' )
1025
1026    This syntax corresponds to the ObjectClassDescription ASN.1 type from
1027    [X.501].
1028
1029 3.3.25.  Octet String
1030
1031    A value of the Octet String syntax is a sequence of zero, one, or
1032    more arbitrary octets.  The LDAP-specific encoding of a value of this
1033    syntax is the unconverted sequence of octets, which conforms to the
1034    following ABNF:
1035
1036       OctetString = *OCTET
1037
1038    The <OCTET> rule is defined in [RFC4512].  Values of this syntax are
1039    not generally human-readable.
1040
1041    The LDAP definition for the Octet String syntax is:
1042
1043       ( 1.3.6.1.4.1.1466.115.121.1.40 DESC 'Octet String' )
1044
1045    This syntax corresponds to the OCTET STRING ASN.1 type from [ASN.1].
1046
1047 3.3.26.  OID
1048
1049    A value of the OID syntax is an object identifier: a sequence of two
1050    or more non-negative integers that uniquely identify some object or
1051    item of specification.  Many of the object identifiers used in LDAP
1052    also have IANA registered names [RFC4520].
1053
1054    The LDAP-specific encoding of a value of this syntax is defined by
1055    the <oid> rule in [RFC4512].
1056
1057       Examples:
1058          1.2.3.4
1059          cn
1060
1061    The LDAP definition for the OID syntax is:
1062
1063
1064
1065
1066 Legg                        Standards Track                    [Page 19]
1067 \f
1068 RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
1069
1070
1071       ( 1.3.6.1.4.1.1466.115.121.1.38 DESC 'OID' )
1072
1073    This syntax corresponds to the OBJECT IDENTIFIER ASN.1 type from
1074    [ASN.1].
1075
1076 3.3.27.  Other Mailbox
1077
1078    A value of the Other Mailbox syntax identifies an electronic mailbox,
1079    in a particular named mail system.  The LDAP-specific encoding of a
1080    value of this syntax is defined by the following ABNF:
1081
1082       OtherMailbox = mailbox-type DOLLAR mailbox
1083       mailbox-type = PrintableString
1084       mailbox      = IA5String
1085
1086    The <mailbox-type> rule represents the type of mail system in which
1087    the mailbox resides (for example, "MCIMail"), and <mailbox> is the
1088    actual mailbox in the mail system described by <mailbox-type>.  The
1089    <PrintableString> and <IA5String> rules are defined in Section 3.2.
1090    The <DOLLAR> rule is defined in [RFC4512].
1091
1092    The LDAP definition for the Other Mailbox syntax is:
1093
1094       ( 1.3.6.1.4.1.1466.115.121.1.39 DESC 'Other Mailbox' )
1095
1096    The ASN.1 type corresponding to the Other Mailbox syntax is defined
1097    as follows, assuming EXPLICIT TAGS:
1098
1099       OtherMailbox ::= SEQUENCE {
1100           mailboxType  PrintableString,
1101           mailbox      IA5String
1102       }
1103
1104 3.3.28.  Postal Address
1105
1106    A value of the Postal Address syntax is a sequence of strings of one
1107    or more arbitrary UCS characters, which form an address in a physical
1108    mail system.
1109
1110    The LDAP-specific encoding of a value of this syntax is defined by
1111    the following ABNF:
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122 Legg                        Standards Track                    [Page 20]
1123 \f
1124 RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
1125
1126
1127       PostalAddress = line *( DOLLAR line )
1128       line          = 1*line-char
1129       line-char     = %x00-23
1130                       / (%x5C "24")  ; escaped "$"
1131                       / %x25-5B
1132                       / (%x5C "5C")  ; escaped "\"
1133                       / %x5D-7F
1134                       / UTFMB
1135
1136    Each character string (i.e., <line>) of a postal address value is
1137    encoded as a UTF-8 [RFC3629] string, except that "\" and "$"
1138    characters, if they occur in the string, are escaped by a "\"
1139    character followed by the two hexadecimal digit code for the
1140    character.  The <DOLLAR> and <UTFMB> rules are defined in [RFC4512].
1141
1142    Many servers limit the postal address to no more than six lines of no
1143    more than thirty characters each.
1144
1145       Example:
1146          1234 Main St.$Anytown, CA 12345$USA
1147          \241,000,000 Sweepstakes$PO Box 1000000$Anytown, CA 12345$USA
1148
1149    The LDAP definition for the Postal Address syntax is:
1150
1151       ( 1.3.6.1.4.1.1466.115.121.1.41 DESC 'Postal Address' )
1152
1153    This syntax corresponds to the PostalAddress ASN.1 type from [X.520];
1154    that is
1155
1156       PostalAddress ::= SEQUENCE SIZE(1..ub-postal-line) OF
1157           DirectoryString { ub-postal-string }
1158
1159    The values of ub-postal-line and ub-postal-string (both integers) are
1160    implementation defined.  Non-normative definitions appear in [X.520].
1161
1162 3.3.29.  Printable String
1163
1164    A value of the Printable String syntax is a string of one or more
1165    latin alphabetic, numeric, and selected punctuation characters as
1166    specified by the <PrintableCharacter> rule in Section 3.2.
1167
1168    The LDAP-specific encoding of a value of this syntax is the
1169    unconverted string of characters, which conforms to the
1170    <PrintableString> rule in Section 3.2.
1171
1172       Example:
1173          This is a PrintableString.
1174
1175
1176
1177
1178 Legg                        Standards Track                    [Page 21]
1179 \f
1180 RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
1181
1182
1183    The LDAP definition for the PrintableString syntax is:
1184
1185       ( 1.3.6.1.4.1.1466.115.121.1.44 DESC 'Printable String' )
1186
1187    This syntax corresponds to the PrintableString ASN.1 type from
1188    [ASN.1].
1189
1190 3.3.30.  Substring Assertion
1191
1192    A value of the Substring Assertion syntax is a sequence of zero, one,
1193    or more character substrings used as an argument for substring
1194    extensible matching of character string attribute values; i.e., as
1195    the matchValue of a MatchingRuleAssertion [RFC4511].  Each substring
1196    is a string of one or more arbitrary characters from the Universal
1197    Character Set (UCS) [UCS].  A zero-length substring is not permitted.
1198
1199    The LDAP-specific encoding of a value of this syntax is defined by
1200    the following ABNF:
1201
1202       SubstringAssertion = [ initial ] any [ final ]
1203
1204       initial  = substring
1205       any      = ASTERISK *(substring ASTERISK)
1206       final    = substring
1207       ASTERISK = %x2A  ; asterisk ("*")
1208
1209       substring           = 1*substring-character
1210       substring-character = %x00-29
1211                             / (%x5C "2A")  ; escaped "*"
1212                             / %x2B-5B
1213                             / (%x5C "5C")  ; escaped "\"
1214                             / %x5D-7F
1215                             / UTFMB
1216
1217    Each <substring> of a Substring Assertion value is encoded as a UTF-8
1218    [RFC3629] string, except that "\" and "*" characters, if they occur
1219    in the substring, are escaped by a "\" character followed by the two
1220    hexadecimal digit code for the character.
1221
1222    The Substring Assertion syntax is used only as the syntax of
1223    assertion values in the extensible match.  It is not used as an
1224    attribute syntax, or in the SubstringFilter [RFC4511].
1225
1226    The LDAP definition for the Substring Assertion syntax is:
1227
1228       ( 1.3.6.1.4.1.1466.115.121.1.58 DESC 'Substring Assertion' )
1229
1230
1231
1232
1233
1234 Legg                        Standards Track                    [Page 22]
1235 \f
1236 RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
1237
1238
1239    This syntax corresponds to the SubstringAssertion ASN.1 type from
1240    [X.520].
1241
1242 3.3.31.  Telephone Number
1243
1244    A value of the Telephone Number syntax is a string of printable
1245    characters that complies with the internationally agreed format for
1246    representing international telephone numbers [E.123].
1247
1248    The LDAP-specific encoding of a value of this syntax is the
1249    unconverted string of characters, which conforms to the
1250    <PrintableString> rule in Section 3.2.
1251
1252       Examples:
1253          +1 512 315 0280
1254          +1-512-315-0280
1255          +61 3 9896 7830
1256
1257    The LDAP definition for the Telephone Number syntax is:
1258
1259       ( 1.3.6.1.4.1.1466.115.121.1.50 DESC 'Telephone Number' )
1260
1261    The Telephone Number syntax corresponds to the following ASN.1 type
1262    from [X.520]:
1263
1264       PrintableString (SIZE(1..ub-telephone-number))
1265
1266    The value of ub-telephone-number (an integer) is implementation
1267    defined.  A non-normative definition appears in [X.520].
1268
1269 3.3.32.  Teletex Terminal Identifier
1270
1271    A value of this syntax specifies the identifier and (optionally)
1272    parameters of a teletex terminal.
1273
1274    The LDAP-specific encoding of a value of this syntax is defined by
1275    the following ABNF:
1276
1277       teletex-id = ttx-term *(DOLLAR ttx-param)
1278       ttx-term   = PrintableString          ; terminal identifier
1279       ttx-param  = ttx-key COLON ttx-value  ; parameter
1280       ttx-key    = "graphic" / "control" / "misc" / "page" / "private"
1281       ttx-value  = *ttx-value-octet
1282
1283       ttx-value-octet = %x00-23
1284                         / (%x5C "24")  ; escaped "$"
1285                         / %x25-5B
1286                         / (%x5C "5C")  ; escaped "\"
1287
1288
1289
1290 Legg                        Standards Track                    [Page 23]
1291 \f
1292 RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
1293
1294
1295                         / %x5D-FF
1296
1297    The <PrintableString> and <COLON> rules are defined in Section 3.2.
1298    The <DOLLAR> rule is defined in [RFC4512].
1299
1300    The LDAP definition for the Teletex Terminal Identifier syntax is:
1301
1302       ( 1.3.6.1.4.1.1466.115.121.1.51
1303          DESC 'Teletex Terminal Identifier' )
1304
1305    This syntax corresponds to the TeletexTerminalIdentifier ASN.1 type
1306    from [X.520].
1307
1308 3.3.33.  Telex Number
1309
1310    A value of the Telex Number syntax specifies the telex number,
1311    country code, and answerback code of a telex terminal.
1312
1313    The LDAP-specific encoding of a value of this syntax is defined by
1314    the following ABNF:
1315
1316       telex-number  = actual-number DOLLAR country-code
1317                          DOLLAR answerback
1318       actual-number = PrintableString
1319       country-code  = PrintableString
1320       answerback    = PrintableString
1321
1322    The <PrintableString> rule is defined in Section 3.2.  The <DOLLAR>
1323    rule is defined in [RFC4512].
1324
1325    The LDAP definition for the Telex Number syntax is:
1326
1327       ( 1.3.6.1.4.1.1466.115.121.1.52 DESC 'Telex Number' )
1328
1329    This syntax corresponds to the TelexNumber ASN.1 type from [X.520].
1330
1331 3.3.34.  UTC Time
1332
1333    A value of the UTC Time syntax is a character string representing a
1334    date and time to a precision of one minute or one second.  The year
1335    is given as a two-digit number.  The LDAP-specific encoding of a
1336    value of this syntax follows the format defined in [ASN.1] for the
1337    UTCTime type and is described by the following ABNF:
1338
1339       UTCTime         = year month day hour minute [ second ]
1340                            [ u-time-zone ]
1341       u-time-zone     = %x5A  ; "Z"
1342                         / u-differential
1343
1344
1345
1346 Legg                        Standards Track                    [Page 24]
1347 \f
1348 RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
1349
1350
1351       u-differential  = ( MINUS / PLUS ) hour minute
1352
1353    The <year>, <month>, <day>, <hour>, <minute>, <second>, and <MINUS>
1354    rules are defined in Section 3.3.13.  The <PLUS> rule is defined in
1355    [RFC4512].
1356
1357    The above ABNF allows character strings that do not represent valid
1358    dates (in the Gregorian calendar) and/or valid times.  Such character
1359    strings SHOULD be considered invalid for this syntax.
1360
1361    The time value represents coordinated universal time if the "Z" form
1362    of <u-time-zone> is used; otherwise, the value represents a local
1363    time.  In the latter case, if <u-differential> is provided, then
1364    coordinated universal time can be calculated by subtracting the
1365    differential from the local time.  The <u-time-zone> SHOULD be
1366    present in time values, and the "Z" form of <u-time-zone> SHOULD be
1367    used in preference to <u-differential>.
1368
1369    The LDAP definition for the UTC Time syntax is:
1370
1371       ( 1.3.6.1.4.1.1466.115.121.1.53 DESC 'UTC Time' )
1372
1373    Note: This syntax is deprecated in favor of the Generalized Time
1374    syntax.
1375
1376    The UTC Time syntax corresponds to the UTCTime ASN.1 type from
1377    [ASN.1].
1378
1379 4.  Matching Rules
1380
1381    Matching rules are used by directory implementations to compare
1382    attribute values against assertion values when performing Search and
1383    Compare operations [RFC4511].  They are also used when comparing a
1384    purported distinguished name [RFC4512] with the name of an entry.
1385    When modifying entries, matching rules are used to identify values to
1386    be deleted and to prevent an attribute from containing two equal
1387    values.
1388
1389    Matching rules that are required for directory operation, or that are
1390    in common use, are specified in this section.
1391
1392 4.1.  General Considerations
1393
1394    A matching rule is applied to attribute values through an
1395    AttributeValueAssertion or MatchingRuleAssertion [RFC4511].  The
1396    conditions under which an AttributeValueAssertion or
1397    MatchingRuleAssertion evaluates to Undefined are specified elsewhere
1398    [RFC4511].  If an assertion is not Undefined, then the result of the
1399
1400
1401
1402 Legg                        Standards Track                    [Page 25]
1403 \f
1404 RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
1405
1406
1407    assertion is the result of applying the selected matching rule.  A
1408    matching rule evaluates to TRUE, and in some cases Undefined, as
1409    specified in the description of the matching rule; otherwise, it
1410    evaluates to FALSE.
1411
1412    Each assertion contains an assertion value.  The definition of each
1413    matching rule specifies the syntax for the assertion value.  The
1414    syntax of the assertion value is typically, but not necessarily, the
1415    same as the syntax of the attribute values to which the matching rule
1416    may be applied.  Note that an AssertionValue in a SubstringFilter
1417    [RFC4511] conforms to the assertion syntax of the equality matching
1418    rule for the attribute type rather than to the assertion syntax of
1419    the substrings matching rule for the attribute type.  Conceptually,
1420    the entire SubstringFilter is converted into an assertion value of
1421    the substrings matching rule prior to applying the rule.
1422
1423    The definition of each matching rule indicates the attribute syntaxes
1424    to which the rule may be applied, by specifying conditions the
1425    corresponding ASN.1 type of a candidate attribute syntax must
1426    satisfy.  These conditions are also satisfied if the corresponding
1427    ASN.1 type is a tagged or constrained derivative of the ASN.1 type
1428    explicitly mentioned in the rule description (i.e., ASN.1 tags and
1429    constraints are ignored in checking applicability), or is an
1430    alternative reference notation for the explicitly mentioned type.
1431    Each rule description lists, as examples of applicable attribute
1432    syntaxes, the complete list of the syntaxes defined in this document
1433    to which the matching rule applies.  A matching rule may be
1434    applicable to additional syntaxes defined in other documents if those
1435    syntaxes satisfy the conditions on the corresponding ASN.1 type.
1436
1437    The description of each matching rule indicates whether the rule is
1438    suitable for use as the equality matching rule (EQUALITY), ordering
1439    matching rule (ORDERING), or substrings matching rule (SUBSTR) in an
1440    attribute type definition [RFC4512].
1441
1442    Each matching rule is uniquely identified with an object identifier.
1443    The definition of a matching rule should not subsequently be changed.
1444    If a change is desirable, then a new matching rule with a different
1445    object identifier should be defined instead.
1446
1447    Servers MAY implement the wordMatch and keywordMatch matching rules,
1448    but they SHOULD implement the other matching rules in Section 4.2.
1449    Servers MAY implement additional matching rules.
1450
1451    Servers that implement the extensibleMatch filter SHOULD allow the
1452    matching rules listed in Section 4.2 to be used in the
1453    extensibleMatch filter and SHOULD allow matching rules to be used
1454    with all attribute types known to the server, where the assertion
1455
1456
1457
1458 Legg                        Standards Track                    [Page 26]
1459 \f
1460 RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
1461
1462
1463    syntax of the matching rule is the same as the value syntax of the
1464    attribute.
1465
1466    Servers MUST publish, in the matchingRules attribute, the definitions
1467    of matching rules referenced by values of the attributeTypes and
1468    matchingRuleUse attributes in the same subschema entry.  Other
1469    unreferenced matching rules MAY be published in the matchingRules
1470    attribute.
1471
1472    If the server supports the extensibleMatch filter, then the server
1473    MAY use the matchingRuleUse attribute to indicate the applicability
1474    (in an extensibleMatch filter) of selected matching rules to
1475    nominated attribute types.
1476
1477 4.2.  Matching Rule Definitions
1478
1479    Nominated character strings in assertion and attribute values are
1480    prepared according to the string preparation algorithms [RFC4518] for
1481    LDAP when evaluating the following matching rules:
1482
1483       numericStringMatch,
1484       numericStringSubstringsMatch,
1485       caseExactMatch,
1486       caseExactOrderingMatch,
1487       caseExactSubstringsMatch,
1488       caseExactIA5Match,
1489       caseIgnoreIA5Match,
1490       caseIgnoreIA5SubstringsMatch,
1491       caseIgnoreListMatch,
1492       caseIgnoreListSubstringsMatch,
1493       caseIgnoreMatch,
1494       caseIgnoreOrderingMatch,
1495       caseIgnoreSubstringsMatch,
1496       directoryStringFirstComponentMatch,
1497       telephoneNumberMatch,
1498       telephoneNumberSubstringsMatch and
1499       wordMatch.
1500
1501    The Transcode, Normalize, Prohibit, and Check bidi steps are the same
1502    for each of the matching rules.  However, the Map and Insignificant
1503    Character Handling steps depend on the specific rule, as detailed in
1504    the description of these matching rules in the sections that follow.
1505
1506 4.2.1.  bitStringMatch
1507
1508    The bitStringMatch rule compares an assertion value of the Bit String
1509    syntax to an attribute value of a syntax (e.g., the Bit String
1510    syntax) whose corresponding ASN.1 type is BIT STRING.
1511
1512
1513
1514 Legg                        Standards Track                    [Page 27]
1515 \f
1516 RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
1517
1518
1519    If the corresponding ASN.1 type of the attribute syntax does not have
1520    a named bit list [ASN.1] (which is the case for the Bit String
1521    syntax), then the rule evaluates to TRUE if and only if the attribute
1522    value has the same number of bits as the assertion value and the bits
1523    match on a bitwise basis.
1524
1525    If the corresponding ASN.1 type does have a named bit list, then
1526    bitStringMatch operates as above, except that trailing zero bits in
1527    the attribute and assertion values are treated as absent.
1528
1529    The LDAP definition for the bitStringMatch rule is:
1530
1531       ( 2.5.13.16 NAME 'bitStringMatch'
1532          SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 )
1533
1534    The bitStringMatch rule is an equality matching rule.
1535
1536 4.2.2.  booleanMatch
1537
1538    The booleanMatch rule compares an assertion value of the Boolean
1539    syntax to an attribute value of a syntax (e.g., the Boolean syntax)
1540    whose corresponding ASN.1 type is BOOLEAN.
1541
1542    The rule evaluates to TRUE if and only if the attribute value and the
1543    assertion value are both TRUE or both FALSE.
1544
1545    The LDAP definition for the booleanMatch rule is:
1546
1547       ( 2.5.13.13 NAME 'booleanMatch'
1548          SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 )
1549
1550    The booleanMatch rule is an equality matching rule.
1551
1552 4.2.3.  caseExactIA5Match
1553
1554    The caseExactIA5Match rule compares an assertion value of the IA5
1555    String syntax to an attribute value of a syntax (e.g., the IA5 String
1556    syntax) whose corresponding ASN.1 type is IA5String.
1557
1558    The rule evaluates to TRUE if and only if the prepared attribute
1559    value character string and the prepared assertion value character
1560    string have the same number of characters and corresponding
1561    characters have the same code point.
1562
1563    In preparing the attribute value and assertion value for comparison,
1564    characters are not case folded in the Map preparation step, and only
1565    Insignificant Space Handling is applied in the Insignificant
1566    Character Handling step.
1567
1568
1569
1570 Legg                        Standards Track                    [Page 28]
1571 \f
1572 RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
1573
1574
1575    The LDAP definition for the caseExactIA5Match rule is:
1576
1577       ( 1.3.6.1.4.1.1466.109.114.1 NAME 'caseExactIA5Match'
1578          SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
1579
1580    The caseExactIA5Match rule is an equality matching rule.
1581
1582 4.2.4.  caseExactMatch
1583
1584    The caseExactMatch rule compares an assertion value of the Directory
1585    String syntax to an attribute value of a syntax (e.g., the Directory
1586    String, Printable String, Country String, or Telephone Number syntax)
1587    whose corresponding ASN.1 type is DirectoryString or one of the
1588    alternative string types of DirectoryString, such as PrintableString
1589    (the other alternatives do not correspond to any syntax defined in
1590    this document).
1591
1592    The rule evaluates to TRUE if and only if the prepared attribute
1593    value character string and the prepared assertion value character
1594    string have the same number of characters and corresponding
1595    characters have the same code point.
1596
1597    In preparing the attribute value and assertion value for comparison,
1598    characters are not case folded in the Map preparation step, and only
1599    Insignificant Space Handling is applied in the Insignificant
1600    Character Handling step.
1601
1602    The LDAP definition for the caseExactMatch rule is:
1603
1604       ( 2.5.13.5 NAME 'caseExactMatch'
1605          SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
1606
1607    The caseExactMatch rule is an equality matching rule.
1608
1609 4.2.5.  caseExactOrderingMatch
1610
1611    The caseExactOrderingMatch rule compares an assertion value of the
1612    Directory String syntax to an attribute value of a syntax (e.g., the
1613    Directory String, Printable String, Country String, or Telephone
1614    Number syntax) whose corresponding ASN.1 type is DirectoryString or
1615    one of its alternative string types.
1616
1617    The rule evaluates to TRUE if and only if, in the code point
1618    collation order, the prepared attribute value character string
1619    appears earlier than the prepared assertion value character string;
1620    i.e., the attribute value is "less than" the assertion value.
1621
1622
1623
1624
1625
1626 Legg                        Standards Track                    [Page 29]
1627 \f
1628 RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
1629
1630
1631    In preparing the attribute value and assertion value for comparison,
1632    characters are not case folded in the Map preparation step, and only
1633    Insignificant Space Handling is applied in the Insignificant
1634    Character Handling step.
1635
1636    The LDAP definition for the caseExactOrderingMatch rule is:
1637
1638       ( 2.5.13.6 NAME 'caseExactOrderingMatch'
1639          SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
1640
1641    The caseExactOrderingMatch rule is an ordering matching rule.
1642
1643 4.2.6.  caseExactSubstringsMatch
1644
1645    The caseExactSubstringsMatch rule compares an assertion value of the
1646    Substring Assertion syntax to an attribute value of a syntax (e.g.,
1647    the Directory String, Printable String, Country String, or Telephone
1648    Number syntax) whose corresponding ASN.1 type is DirectoryString or
1649    one of its alternative string types.
1650
1651    The rule evaluates to TRUE if and only if (1) the prepared substrings
1652    of the assertion value match disjoint portions of the prepared
1653    attribute value character string in the order of the substrings in
1654    the assertion value, (2) an <initial> substring, if present, matches
1655    the beginning of the prepared attribute value character string, and
1656    (3) a <final> substring, if present, matches the end of the prepared
1657    attribute value character string.  A prepared substring matches a
1658    portion of the prepared attribute value character string if
1659    corresponding characters have the same code point.
1660
1661    In preparing the attribute value and assertion value substrings for
1662    comparison, characters are not case folded in the Map preparation
1663    step, and only Insignificant Space Handling is applied in the
1664    Insignificant Character Handling step.
1665
1666    The LDAP definition for the caseExactSubstringsMatch rule is:
1667
1668       ( 2.5.13.7 NAME 'caseExactSubstringsMatch'
1669          SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
1670
1671    The caseExactSubstringsMatch rule is a substrings matching rule.
1672
1673 4.2.7.  caseIgnoreIA5Match
1674
1675    The caseIgnoreIA5Match rule compares an assertion value of the IA5
1676    String syntax to an attribute value of a syntax (e.g., the IA5 String
1677    syntax) whose corresponding ASN.1 type is IA5String.
1678
1679
1680
1681
1682 Legg                        Standards Track                    [Page 30]
1683 \f
1684 RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
1685
1686
1687    The rule evaluates to TRUE if and only if the prepared attribute
1688    value character string and the prepared assertion value character
1689    string have the same number of characters and corresponding
1690    characters have the same code point.
1691
1692    In preparing the attribute value and assertion value for comparison,
1693    characters are case folded in the Map preparation step, and only
1694    Insignificant Space Handling is applied in the Insignificant
1695    Character Handling step.
1696
1697    The LDAP definition for the caseIgnoreIA5Match rule is:
1698
1699       ( 1.3.6.1.4.1.1466.109.114.2 NAME 'caseIgnoreIA5Match'
1700          SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
1701
1702    The caseIgnoreIA5Match rule is an equality matching rule.
1703
1704 4.2.8.  caseIgnoreIA5SubstringsMatch
1705
1706    The caseIgnoreIA5SubstringsMatch rule compares an assertion value of
1707    the Substring Assertion syntax to an attribute value of a syntax
1708    (e.g., the IA5 String syntax) whose corresponding ASN.1 type is
1709    IA5String.
1710
1711    The rule evaluates to TRUE if and only if (1) the prepared substrings
1712    of the assertion value match disjoint portions of the prepared
1713    attribute value character string in the order of the substrings in
1714    the assertion value, (2) an <initial> substring, if present, matches
1715    the beginning of the prepared attribute value character string, and
1716    (3) a <final> substring, if present, matches the end of the prepared
1717    attribute value character string.  A prepared substring matches a
1718    portion of the prepared attribute value character string if
1719    corresponding characters have the same code point.
1720
1721    In preparing the attribute value and assertion value substrings for
1722    comparison, characters are case folded in the Map preparation step,
1723    and only Insignificant Space Handling is applied in the Insignificant
1724    Character Handling step.
1725
1726       ( 1.3.6.1.4.1.1466.109.114.3 NAME 'caseIgnoreIA5SubstringsMatch'
1727          SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
1728
1729    The caseIgnoreIA5SubstringsMatch rule is a substrings matching rule.
1730
1731 4.2.9.  caseIgnoreListMatch
1732
1733    The caseIgnoreListMatch rule compares an assertion value that is a
1734    sequence of strings to an attribute value of a syntax (e.g., the
1735
1736
1737
1738 Legg                        Standards Track                    [Page 31]
1739 \f
1740 RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
1741
1742
1743    Postal Address syntax) whose corresponding ASN.1 type is a SEQUENCE
1744    OF the DirectoryString ASN.1 type.
1745
1746    The rule evaluates to TRUE if and only if the attribute value and the
1747    assertion value have the same number of strings and corresponding
1748    strings (by position) match according to the caseIgnoreMatch matching
1749    rule.
1750
1751    In [X.520], the assertion syntax for this matching rule is defined to
1752    be:
1753
1754       SEQUENCE OF DirectoryString {ub-match}
1755
1756    That is, it is different from the corresponding type for the Postal
1757    Address syntax.  The choice of the Postal Address syntax for the
1758    assertion syntax of the caseIgnoreListMatch in LDAP should not be
1759    seen as limiting the matching rule to apply only to attributes with
1760    the Postal Address syntax.
1761
1762    The LDAP definition for the caseIgnoreListMatch rule is:
1763
1764       ( 2.5.13.11 NAME 'caseIgnoreListMatch'
1765          SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 )
1766
1767    The caseIgnoreListMatch rule is an equality matching rule.
1768
1769 4.2.10.  caseIgnoreListSubstringsMatch
1770
1771    The caseIgnoreListSubstringsMatch rule compares an assertion value of
1772    the Substring Assertion syntax to an attribute value of a syntax
1773    (e.g., the Postal Address syntax) whose corresponding ASN.1 type is a
1774    SEQUENCE OF the DirectoryString ASN.1 type.
1775
1776    The rule evaluates to TRUE if and only if the assertion value
1777    matches, per the caseIgnoreSubstringsMatch rule, the character string
1778    formed by concatenating the strings of the attribute value, except
1779    that none of the <initial>, <any>, or <final> substrings of the
1780    assertion value are considered to match a substring of the
1781    concatenated string which spans more than one of the original strings
1782    of the attribute value.
1783
1784    Note that, in terms of the LDAP-specific encoding of the Postal
1785    Address syntax, the concatenated string omits the <DOLLAR> line
1786    separator and the escaping of "\" and "$" characters.
1787
1788    The LDAP definition for the caseIgnoreListSubstringsMatch rule is:
1789
1790       ( 2.5.13.12 NAME 'caseIgnoreListSubstringsMatch'
1791
1792
1793
1794 Legg                        Standards Track                    [Page 32]
1795 \f
1796 RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
1797
1798
1799          SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
1800
1801    The caseIgnoreListSubstringsMatch rule is a substrings matching rule.
1802
1803 4.2.11.  caseIgnoreMatch
1804
1805    The caseIgnoreMatch rule compares an assertion value of the Directory
1806    String syntax to an attribute value of a syntax (e.g., the Directory
1807    String, Printable String, Country String, or Telephone Number syntax)
1808    whose corresponding ASN.1 type is DirectoryString or one of its
1809    alternative string types.
1810
1811    The rule evaluates to TRUE if and only if the prepared attribute
1812    value character string and the prepared assertion value character
1813    string have the same number of characters and corresponding
1814    characters have the same code point.
1815
1816    In preparing the attribute value and assertion value for comparison,
1817    characters are case folded in the Map preparation step, and only
1818    Insignificant Space Handling is applied in the Insignificant
1819    Character Handling step.
1820
1821    The LDAP definition for the caseIgnoreMatch rule is:
1822
1823       ( 2.5.13.2 NAME 'caseIgnoreMatch'
1824          SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
1825
1826    The caseIgnoreMatch rule is an equality matching rule.
1827
1828 4.2.12.  caseIgnoreOrderingMatch
1829
1830    The caseIgnoreOrderingMatch rule compares an assertion value of the
1831    Directory String syntax to an attribute value of a syntax (e.g., the
1832    Directory String, Printable String, Country String, or Telephone
1833    Number syntax) whose corresponding ASN.1 type is DirectoryString or
1834    one of its alternative string types.
1835
1836    The rule evaluates to TRUE if and only if, in the code point
1837    collation order, the prepared attribute value character string
1838    appears earlier than the prepared assertion value character string;
1839    i.e., the attribute value is "less than" the assertion value.
1840
1841    In preparing the attribute value and assertion value for comparison,
1842    characters are case folded in the Map preparation step, and only
1843    Insignificant Space Handling is applied in the Insignificant
1844    Character Handling step.
1845
1846    The LDAP definition for the caseIgnoreOrderingMatch rule is:
1847
1848
1849
1850 Legg                        Standards Track                    [Page 33]
1851 \f
1852 RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
1853
1854
1855       ( 2.5.13.3 NAME 'caseIgnoreOrderingMatch'
1856          SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
1857
1858    The caseIgnoreOrderingMatch rule is an ordering matching rule.
1859
1860 4.2.13.  caseIgnoreSubstringsMatch
1861
1862    The caseIgnoreSubstringsMatch rule compares an assertion value of the
1863    Substring Assertion syntax to an attribute value of a syntax (e.g.,
1864    the Directory String, Printable String, Country String, or Telephone
1865    Number syntax) whose corresponding ASN.1 type is DirectoryString or
1866    one of its alternative string types.
1867
1868    The rule evaluates to TRUE if and only if (1) the prepared substrings
1869    of the assertion value match disjoint portions of the prepared
1870    attribute value character string in the order of the substrings in
1871    the assertion value, (2) an <initial> substring, if present, matches
1872    the beginning of the prepared attribute value character string, and
1873    (3) a <final> substring, if present, matches the end of the prepared
1874    attribute value character string.  A prepared substring matches a
1875    portion of the prepared attribute value character string if
1876    corresponding characters have the same code point.
1877
1878    In preparing the attribute value and assertion value substrings for
1879    comparison, characters are case folded in the Map preparation step,
1880    and only Insignificant Space Handling is applied in the Insignificant
1881    Character Handling step.
1882
1883    The LDAP definition for the caseIgnoreSubstringsMatch rule is:
1884
1885       ( 2.5.13.4 NAME 'caseIgnoreSubstringsMatch'
1886          SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
1887
1888    The caseIgnoreSubstringsMatch rule is a substrings matching rule.
1889
1890 4.2.14.  directoryStringFirstComponentMatch
1891
1892    The directoryStringFirstComponentMatch rule compares an assertion
1893    value of the Directory String syntax to an attribute value of a
1894    syntax whose corresponding ASN.1 type is a SEQUENCE with a mandatory
1895    first component of the DirectoryString ASN.1 type.
1896
1897    Note that the assertion syntax of this matching rule differs from the
1898    attribute syntax of attributes for which this is the equality
1899    matching rule.
1900
1901
1902
1903
1904
1905
1906 Legg                        Standards Track                    [Page 34]
1907 \f
1908 RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
1909
1910
1911    The rule evaluates to TRUE if and only if the assertion value matches
1912    the first component of the attribute value using the rules of
1913    caseIgnoreMatch.
1914
1915    The LDAP definition for the directoryStringFirstComponentMatch
1916    matching rule is:
1917
1918       ( 2.5.13.31 NAME 'directoryStringFirstComponentMatch'
1919          SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
1920
1921    The directoryStringFirstComponentMatch rule is an equality matching
1922    rule.  When using directoryStringFirstComponentMatch to compare two
1923    attribute values (of an applicable syntax), an assertion value must
1924    first be derived from one of the attribute values.  An assertion
1925    value can be derived from an attribute value by taking the first
1926    component of that attribute value.
1927
1928 4.2.15.  distinguishedNameMatch
1929
1930    The distinguishedNameMatch rule compares an assertion value of the DN
1931    syntax to an attribute value of a syntax (e.g., the DN syntax) whose
1932    corresponding ASN.1 type is DistinguishedName.
1933
1934    The rule evaluates to TRUE if and only if the attribute value and the
1935    assertion value have the same number of relative distinguished names
1936    and corresponding relative distinguished names (by position) are the
1937    same.  A relative distinguished name (RDN) of the assertion value is
1938    the same as an RDN of the attribute value if and only if they have
1939    the same number of attribute value assertions and each attribute
1940    value assertion (AVA) of the first RDN is the same as the AVA of the
1941    second RDN with the same attribute type.  The order of the AVAs is
1942    not significant.  Also note that a particular attribute type may
1943    appear in at most one AVA in an RDN.  Two AVAs with the same
1944    attribute type are the same if their values are equal according to
1945    the equality matching rule of the attribute type.  If one or more of
1946    the AVA comparisons evaluate to Undefined and the remaining AVA
1947    comparisons return TRUE then the distinguishedNameMatch rule
1948    evaluates to Undefined.
1949
1950    The LDAP definition for the distinguishedNameMatch rule is:
1951
1952       ( 2.5.13.1 NAME 'distinguishedNameMatch'
1953          SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
1954
1955    The distinguishedNameMatch rule is an equality matching rule.
1956
1957
1958
1959
1960
1961
1962 Legg                        Standards Track                    [Page 35]
1963 \f
1964 RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
1965
1966
1967 4.2.16.  generalizedTimeMatch
1968
1969    The generalizedTimeMatch rule compares an assertion value of the
1970    Generalized Time syntax to an attribute value of a syntax (e.g., the
1971    Generalized Time syntax) whose corresponding ASN.1 type is
1972    GeneralizedTime.
1973
1974    The rule evaluates to TRUE if and only if the attribute value
1975    represents the same universal coordinated time as the assertion
1976    value.  If a time is specified with the minutes or seconds absent,
1977    then the number of minutes or seconds (respectively) is assumed to be
1978    zero.
1979
1980    The LDAP definition for the generalizedTimeMatch rule is:
1981
1982       ( 2.5.13.27 NAME 'generalizedTimeMatch'
1983          SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 )
1984
1985    The generalizedTimeMatch rule is an equality matching rule.
1986
1987 4.2.17.  generalizedTimeOrderingMatch
1988
1989    The generalizedTimeOrderingMatch rule compares the time ordering of
1990    an assertion value of the Generalized Time syntax to an attribute
1991    value of a syntax (e.g., the Generalized Time syntax) whose
1992    corresponding ASN.1 type is GeneralizedTime.
1993
1994    The rule evaluates to TRUE if and only if the attribute value
1995    represents a universal coordinated time that is earlier than the
1996    universal coordinated time represented by the assertion value.
1997
1998    The LDAP definition for the generalizedTimeOrderingMatch rule is:
1999
2000       ( 2.5.13.28 NAME 'generalizedTimeOrderingMatch'
2001          SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 )
2002
2003    The generalizedTimeOrderingMatch rule is an ordering matching rule.
2004
2005 4.2.18.  integerFirstComponentMatch
2006
2007    The integerFirstComponentMatch rule compares an assertion value of
2008    the Integer syntax to an attribute value of a syntax (e.g., the DIT
2009    Structure Rule Description syntax) whose corresponding ASN.1 type is
2010    a SEQUENCE with a mandatory first component of the INTEGER ASN.1
2011    type.
2012
2013
2014
2015
2016
2017
2018 Legg                        Standards Track                    [Page 36]
2019 \f
2020 RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
2021
2022
2023    Note that the assertion syntax of this matching rule differs from the
2024    attribute syntax of attributes for which this is the equality
2025    matching rule.
2026
2027    The rule evaluates to TRUE if and only if the assertion value and the
2028    first component of the attribute value are the same integer value.
2029
2030    The LDAP definition for the integerFirstComponentMatch matching rule
2031    is:
2032
2033       ( 2.5.13.29 NAME 'integerFirstComponentMatch'
2034          SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )
2035
2036    The integerFirstComponentMatch rule is an equality matching rule.
2037    When using integerFirstComponentMatch to compare two attribute values
2038    (of an applicable syntax), an assertion value must first be derived
2039    from one of the attribute values.  An assertion value can be derived
2040    from an attribute value by taking the first component of that
2041    attribute value.
2042
2043 4.2.19.  integerMatch
2044
2045    The integerMatch rule compares an assertion value of the Integer
2046    syntax to an attribute value of a syntax (e.g., the Integer syntax)
2047    whose corresponding ASN.1 type is INTEGER.
2048
2049    The rule evaluates to TRUE if and only if the attribute value and the
2050    assertion value are the same integer value.
2051
2052    The LDAP definition for the integerMatch matching rule is:
2053
2054       ( 2.5.13.14 NAME 'integerMatch'
2055          SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )
2056
2057    The integerMatch rule is an equality matching rule.
2058
2059 4.2.20.  integerOrderingMatch
2060
2061    The integerOrderingMatch rule compares an assertion value of the
2062    Integer syntax to an attribute value of a syntax (e.g., the Integer
2063    syntax) whose corresponding ASN.1 type is INTEGER.
2064
2065    The rule evaluates to TRUE if and only if the integer value of the
2066    attribute value is less than the integer value of the assertion
2067    value.
2068
2069    The LDAP definition for the integerOrderingMatch matching rule is:
2070
2071
2072
2073
2074 Legg                        Standards Track                    [Page 37]
2075 \f
2076 RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
2077
2078
2079       ( 2.5.13.15 NAME 'integerOrderingMatch'
2080          SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )
2081
2082    The integerOrderingMatch rule is an ordering matching rule.
2083
2084 4.2.21.  keywordMatch
2085
2086    The keywordMatch rule compares an assertion value of the Directory
2087    String syntax to an attribute value of a syntax (e.g., the Directory
2088    String syntax) whose corresponding ASN.1 type is DirectoryString.
2089
2090    The rule evaluates to TRUE if and only if the assertion value
2091    character string matches any keyword in the attribute value.  The
2092    identification of keywords in the attribute value and the exactness
2093    of the match are both implementation specific.
2094
2095    The LDAP definition for the keywordMatch rule is:
2096
2097       ( 2.5.13.33 NAME 'keywordMatch'
2098          SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
2099
2100 4.2.22.  numericStringMatch
2101
2102    The numericStringMatch rule compares an assertion value of the
2103    Numeric String syntax to an attribute value of a syntax (e.g., the
2104    Numeric String syntax) whose corresponding ASN.1 type is
2105    NumericString.
2106
2107    The rule evaluates to TRUE if and only if the prepared attribute
2108    value character string and the prepared assertion value character
2109    string have the same number of characters and corresponding
2110    characters have the same code point.
2111
2112    In preparing the attribute value and assertion value for comparison,
2113    characters are not case folded in the Map preparation step, and only
2114    numericString Insignificant Character Handling is applied in the
2115    Insignificant Character Handling step.
2116
2117    The LDAP definition for the numericStringMatch matching rule is:
2118
2119       ( 2.5.13.8 NAME 'numericStringMatch'
2120          SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 )
2121
2122    The numericStringMatch rule is an equality matching rule.
2123
2124
2125
2126
2127
2128
2129
2130 Legg                        Standards Track                    [Page 38]
2131 \f
2132 RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
2133
2134
2135 4.2.23.  numericStringOrderingMatch
2136
2137    The numericStringOrderingMatch rule compares an assertion value of
2138    the Numeric String syntax to an attribute value of a syntax (e.g.,
2139    the Numeric String syntax) whose corresponding ASN.1 type is
2140    NumericString.
2141
2142    The rule evaluates to TRUE if and only if, in the code point
2143    collation order, the prepared attribute value character string
2144    appears earlier than the prepared assertion value character string;
2145    i.e., the attribute value is "less than" the assertion value.
2146
2147    In preparing the attribute value and assertion value for comparison,
2148    characters are not case folded in the Map preparation step, and only
2149    numericString Insignificant Character Handling is applied in the
2150    Insignificant Character Handling step.
2151
2152    The rule is identical to the caseIgnoreOrderingMatch rule except that
2153    all space characters are skipped during comparison (case is
2154    irrelevant as the characters are numeric).
2155
2156    The LDAP definition for the numericStringOrderingMatch matching rule
2157    is:
2158
2159       ( 2.5.13.9 NAME 'numericStringOrderingMatch'
2160          SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 )
2161
2162    The numericStringOrderingMatch rule is an ordering matching rule.
2163
2164 4.2.24.  numericStringSubstringsMatch
2165
2166    The numericStringSubstringsMatch rule compares an assertion value of
2167    the Substring Assertion syntax to an attribute value of a syntax
2168    (e.g., the Numeric String syntax) whose corresponding ASN.1 type is
2169    NumericString.
2170
2171    The rule evaluates to TRUE if and only if (1) the prepared substrings
2172    of the assertion value match disjoint portions of the prepared
2173    attribute value character string in the order of the substrings in
2174    the assertion value, (2) an <initial> substring, if present, matches
2175    the beginning of the prepared attribute value character string, and
2176    (3) a <final> substring, if present, matches the end of the prepared
2177    attribute value character string.  A prepared substring matches a
2178    portion of the prepared attribute value character string if
2179    corresponding characters have the same code point.
2180
2181    In preparing the attribute value and assertion value for comparison,
2182    characters are not case folded in the Map preparation step, and only
2183
2184
2185
2186 Legg                        Standards Track                    [Page 39]
2187 \f
2188 RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
2189
2190
2191    numericString Insignificant Character Handling is applied in the
2192    Insignificant Character Handling step.
2193
2194    The LDAP definition for the numericStringSubstringsMatch matching
2195    rule is:
2196
2197       ( 2.5.13.10 NAME 'numericStringSubstringsMatch'
2198          SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
2199
2200    The numericStringSubstringsMatch rule is a substrings matching rule.
2201
2202 4.2.25.  objectIdentifierFirstComponentMatch
2203
2204    The objectIdentifierFirstComponentMatch rule compares an assertion
2205    value of the OID syntax to an attribute value of a syntax (e.g., the
2206    Attribute Type Description, DIT Content Rule Description, LDAP Syntax
2207    Description, Matching Rule Description, Matching Rule Use
2208    Description, Name Form Description, or Object Class Description
2209    syntax) whose corresponding ASN.1 type is a SEQUENCE with a mandatory
2210    first component of the OBJECT IDENTIFIER ASN.1 type.
2211
2212    Note that the assertion syntax of this matching rule differs from the
2213    attribute syntax of attributes for which this is the equality
2214    matching rule.
2215
2216    The rule evaluates to TRUE if and only if the assertion value matches
2217    the first component of the attribute value using the rules of
2218    objectIdentifierMatch.
2219
2220    The LDAP definition for the objectIdentifierFirstComponentMatch
2221    matching rule is:
2222
2223       ( 2.5.13.30 NAME 'objectIdentifierFirstComponentMatch'
2224          SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
2225
2226    The objectIdentifierFirstComponentMatch rule is an equality matching
2227    rule.  When using objectIdentifierFirstComponentMatch to compare two
2228    attribute values (of an applicable syntax), an assertion value must
2229    first be derived from one of the attribute values.  An assertion
2230    value can be derived from an attribute value by taking the first
2231    component of that attribute value.
2232
2233 4.2.26.  objectIdentifierMatch
2234
2235    The objectIdentifierMatch rule compares an assertion value of the OID
2236    syntax to an attribute value of a syntax (e.g., the OID syntax) whose
2237    corresponding ASN.1 type is OBJECT IDENTIFIER.
2238
2239
2240
2241
2242 Legg                        Standards Track                    [Page 40]
2243 \f
2244 RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
2245
2246
2247    The rule evaluates to TRUE if and only if the assertion value and the
2248    attribute value represent the same object identifier; that is, the
2249    same sequence of integers, whether represented explicitly in the
2250    <numericoid> form of <oid> or implicitly in the <descr> form (see
2251    [RFC4512]).
2252
2253    If an LDAP client supplies an assertion value in the <descr> form and
2254    the chosen descriptor is not recognized by the server, then the
2255    objectIdentifierMatch rule evaluates to Undefined.
2256
2257    The LDAP definition for the objectIdentifierMatch matching rule is:
2258
2259       ( 2.5.13.0 NAME 'objectIdentifierMatch'
2260          SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
2261
2262    The objectIdentifierMatch rule is an equality matching rule.
2263
2264 4.2.27.  octetStringMatch
2265
2266    The octetStringMatch rule compares an assertion value of the Octet
2267    String syntax to an attribute value of a syntax (e.g., the Octet
2268    String or JPEG syntax) whose corresponding ASN.1 type is the OCTET
2269    STRING ASN.1 type.
2270
2271    The rule evaluates to TRUE if and only if the attribute value and the
2272    assertion value are the same length and corresponding octets (by
2273    position) are the same.
2274
2275    The LDAP definition for the octetStringMatch matching rule is:
2276
2277       ( 2.5.13.17 NAME 'octetStringMatch'
2278          SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )
2279
2280    The octetStringMatch rule is an equality matching rule.
2281
2282 4.2.28.  octetStringOrderingMatch
2283
2284    The octetStringOrderingMatch rule compares an assertion value of the
2285    Octet String syntax to an attribute value of a syntax (e.g., the
2286    Octet String or JPEG syntax) whose corresponding ASN.1 type is the
2287    OCTET STRING ASN.1 type.
2288
2289    The rule evaluates to TRUE if and only if the attribute value appears
2290    earlier in the collation order than the assertion value.  The rule
2291    compares octet strings from the first octet to the last octet, and
2292    from the most significant bit to the least significant bit within the
2293    octet.  The first occurrence of a different bit determines the
2294    ordering of the strings.  A zero bit precedes a one bit.  If the
2295
2296
2297
2298 Legg                        Standards Track                    [Page 41]
2299 \f
2300 RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
2301
2302
2303    strings contain different numbers of octets but the longer string is
2304    identical to the shorter string up to the length of the shorter
2305    string, then the shorter string precedes the longer string.
2306
2307    The LDAP definition for the octetStringOrderingMatch matching rule
2308    is:
2309
2310       ( 2.5.13.18 NAME 'octetStringOrderingMatch'
2311          SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )
2312
2313    The octetStringOrderingMatch rule is an ordering matching rule.
2314
2315 4.2.29.  telephoneNumberMatch
2316
2317    The telephoneNumberMatch rule compares an assertion value of the
2318    Telephone Number syntax to an attribute value of a syntax (e.g., the
2319    Telephone Number syntax) whose corresponding ASN.1 type is a
2320    PrintableString representing a telephone number.
2321
2322    The rule evaluates to TRUE if and only if the prepared attribute
2323    value character string and the prepared assertion value character
2324    string have the same number of characters and corresponding
2325    characters have the same code point.
2326
2327    In preparing the attribute value and assertion value for comparison,
2328    characters are case folded in the Map preparation step, and only
2329    telephoneNumber Insignificant Character Handling is applied in the
2330    Insignificant Character Handling step.
2331
2332    The LDAP definition for the telephoneNumberMatch matching rule is:
2333
2334       ( 2.5.13.20 NAME 'telephoneNumberMatch'
2335          SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 )
2336
2337    The telephoneNumberMatch rule is an equality matching rule.
2338
2339 4.2.30.  telephoneNumberSubstringsMatch
2340
2341    The telephoneNumberSubstringsMatch rule compares an assertion value
2342    of the Substring Assertion syntax to an attribute value of a syntax
2343    (e.g., the Telephone Number syntax) whose corresponding ASN.1 type is
2344    a PrintableString representing a telephone number.
2345
2346    The rule evaluates to TRUE if and only if (1) the prepared substrings
2347    of the assertion value match disjoint portions of the prepared
2348    attribute value character string in the order of the substrings in
2349    the assertion value, (2) an <initial> substring, if present, matches
2350    the beginning of the prepared attribute value character string, and
2351
2352
2353
2354 Legg                        Standards Track                    [Page 42]
2355 \f
2356 RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
2357
2358
2359    (3) a <final> substring, if present, matches the end of the prepared
2360    attribute value character string.  A prepared substring matches a
2361    portion of the prepared attribute value character string if
2362    corresponding characters have the same code point.
2363
2364    In preparing the attribute value and assertion value substrings for
2365    comparison, characters are case folded in the Map preparation step,
2366    and only telephoneNumber Insignificant Character Handling is applied
2367    in the Insignificant Character Handling step.
2368
2369    The LDAP definition for the telephoneNumberSubstringsMatch matching
2370    rule is:
2371
2372       ( 2.5.13.21 NAME 'telephoneNumberSubstringsMatch'
2373          SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
2374
2375    The telephoneNumberSubstringsMatch rule is a substrings matching
2376    rule.
2377
2378 4.2.31.  uniqueMemberMatch
2379
2380    The uniqueMemberMatch rule compares an assertion value of the Name
2381    And Optional UID syntax to an attribute value of a syntax (e.g., the
2382    Name And Optional UID syntax) whose corresponding ASN.1 type is
2383    NameAndOptionalUID.
2384
2385    The rule evaluates to TRUE if and only if the <distinguishedName>
2386    components of the assertion value and attribute value match according
2387    to the distinguishedNameMatch rule and either, (1) the <BitString>
2388    component is absent from both the attribute value and assertion
2389    value, or (2) the <BitString> component is present in both the
2390    attribute value and the assertion value and the <BitString> component
2391    of the assertion value matches the <BitString> component of the
2392    attribute value according to the bitStringMatch rule.
2393
2394    Note that this matching rule has been altered from its description in
2395    X.520 [X.520] in order to make the matching rule commutative.  Server
2396    implementors should consider using the original X.520 semantics
2397    (where the matching was less exact) for approximate matching of
2398    attributes with uniqueMemberMatch as the equality matching rule.
2399
2400    The LDAP definition for the uniqueMemberMatch matching rule is:
2401
2402       ( 2.5.13.23 NAME 'uniqueMemberMatch'
2403          SYNTAX 1.3.6.1.4.1.1466.115.121.1.34 )
2404
2405    The uniqueMemberMatch rule is an equality matching rule.
2406
2407
2408
2409
2410 Legg                        Standards Track                    [Page 43]
2411 \f
2412 RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
2413
2414
2415 4.2.32.  wordMatch
2416
2417    The wordMatch rule compares an assertion value of the Directory
2418    String syntax to an attribute value of a syntax (e.g., the Directory
2419    String syntax) whose corresponding ASN.1 type is DirectoryString.
2420
2421    The rule evaluates to TRUE if and only if the assertion value word
2422    matches, according to the semantics of caseIgnoreMatch, any word in
2423    the attribute value.  The precise definition of a word is
2424    implementation specific.
2425
2426    The LDAP definition for the wordMatch rule is:
2427
2428       ( 2.5.13.32 NAME 'wordMatch'
2429          SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
2430
2431 5.  Security Considerations
2432
2433    In general, the LDAP-specific encodings for syntaxes defined in this
2434    document do not define canonical encodings.  That is, a
2435    transformation from an LDAP-specific encoding into some other
2436    encoding (e.g., BER) and back into the LDAP-specific encoding will
2437    not necessarily reproduce exactly the original octets of the LDAP-
2438    specific encoding.  Therefore, an LDAP-specific encoding should not
2439    be used where a canonical encoding is required.
2440
2441    Furthermore, the LDAP-specific encodings do not necessarily enable an
2442    alternative encoding of values of the Directory String and DN
2443    syntaxes to be reconstructed; e.g., a transformation from a
2444    Distinguished Encoding Rules (DER) [BER] encoding to an LDAP-specific
2445    encoding and back to a DER encoding may not reproduce the original
2446    DER encoding.  Therefore, LDAP-specific encodings should not be used
2447    where reversibility to DER is needed; e.g., for the verification of
2448    digital signatures.  Instead, DER or a DER-reversible encoding should
2449    be used.
2450
2451    When interpreting security-sensitive fields (in particular, fields
2452    used to grant or deny access), implementations MUST ensure that any
2453    matching rule comparisons are done on the underlying abstract value,
2454    regardless of the particular encoding used.
2455
2456 6.  Acknowledgements
2457
2458    This document is primarily a revision of RFC 2252 by M. Wahl, A.
2459    Coulbeck, T. Howes, and S. Kille.  RFC 2252 was a product of the IETF
2460    ASID Working Group.
2461
2462
2463
2464
2465
2466 Legg                        Standards Track                    [Page 44]
2467 \f
2468 RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
2469
2470
2471    This document is based on input from the IETF LDAPBIS working group.
2472    The author would like to thank Kathy Dally for editing the early
2473    drafts of this document, and Jim Sermersheim and Kurt Zeilenga for
2474    their significant contributions to this revision.
2475
2476 7.  IANA Considerations
2477
2478    The Internet Assigned Numbers Authority (IANA) has updated the LDAP
2479    descriptors registry [BCP64] as indicated by the following templates:
2480
2481       Subject: Request for LDAP Descriptor Registration Update
2482       Descriptor (short name): see comment
2483       Object Identifier: see comment
2484       Person & email address to contact for further information:
2485         Steven Legg <steven.legg@eb2bcom.com>
2486       Usage: see comment
2487       Specification: RFC 4517
2488       Author/Change Controller: IESG
2489
2490       NAME                              Type  OID
2491       ------------------------------------------------------------------
2492       bitStringMatch                       M  2.5.13.16
2493       booleanMatch                         M  2.5.13.13
2494       caseExactIA5Match                    M  1.3.6.1.4.1.1466.109.114.1
2495       caseExactMatch                       M  2.5.13.5
2496       caseExactOrderingMatch               M  2.5.13.6
2497       caseExactSubstringsMatch             M  2.5.13.7
2498       caseIgnoreIA5Match                   M  1.3.6.1.4.1.1466.109.114.2
2499       caseIgnoreListMatch                  M  2.5.13.11
2500       caseIgnoreListSubstringsMatch        M  2.5.13.12
2501       caseIgnoreMatch                      M  2.5.13.2
2502       caseIgnoreOrderingMatch              M  2.5.13.3
2503       caseIgnoreSubstringsMatch            M  2.5.13.4
2504       directoryStringFirstComponentMatch   M  2.5.13.31
2505       distinguishedNameMatch               M  2.5.13.1
2506       generalizedTimeMatch                 M  2.5.13.27
2507       generalizedTimeOrderingMatch         M  2.5.13.28
2508       integerFirstComponentMatch           M  2.5.13.29
2509       integerMatch                         M  2.5.13.14
2510       integerOrderingMatch                 M  2.5.13.15
2511       keywordMatch                         M  2.5.13.33
2512       numericStringMatch                   M  2.5.13.8
2513       numericStringOrderingMatch           M  2.5.13.9
2514       numericStringSubstringsMatch         M  2.5.13.10
2515       objectIdentifierFirstComponentMatch  M  2.5.13.30
2516       octetStringMatch                     M  2.5.13.17
2517       octetStringOrderingMatch             M  2.5.13.18
2518       telephoneNumberMatch                 M  2.5.13.20
2519
2520
2521
2522 Legg                        Standards Track                    [Page 45]
2523 \f
2524 RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
2525
2526
2527       telephoneNumberSubstringsMatch       M  2.5.13.21
2528       uniqueMemberMatch                    M  2.5.13.23
2529       wordMatch                            M  2.5.13.32
2530
2531       The descriptor for the object identifier 2.5.13.0 was incorrectly
2532       registered as objectIdentifiersMatch (extraneous \`s') in BCP 64.
2533       It has been changed to the following, with a reference to
2534       RFC 4517.
2535
2536       NAME                              Type  OID
2537       ------------------------------------------------------------------
2538       objectIdentifierMatch                M  2.5.13.0
2539
2540       Subject: Request for LDAP Descriptor Registration
2541       Descriptor (short name): caseIgnoreIA5SubstringsMatch
2542       Object Identifier: 1.3.6.1.4.1.1466.109.114.3
2543       Person & email address to contact for further information:
2544         Steven Legg <steven.legg@eb2bcom.com>
2545       Usage: other (M)
2546       Specification: RFC 4517
2547       Author/Change Controller: IESG
2548
2549 8.  References
2550
2551 8.1.  Normative References
2552
2553    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
2554               Requirement Levels", BCP 14, RFC 2119, March 1997.
2555
2556    [RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO
2557               10646", STD 63, RFC 3629, November 2003.
2558
2559    [RFC4234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
2560               Specifications: ABNF", RFC 4234, October 2005.
2561
2562    [RFC4510]  Zeilenga, K., Ed., "Lightweight Directory Access Protocol
2563               (LDAP): Technical Specification Road Map", RFC 4510, June
2564               2006.
2565
2566    [RFC4511]  Sermersheim, J., Ed., "Lightweight Directory Access
2567               Protocol (LDAP): The Protocol", RFC 4511, June 2006.
2568
2569    [RFC4512]  Zeilenga, K., "Lightweight Directory Access Protocol
2570               (LDAP): Directory Information Models", RFC 4512, June
2571               2006.
2572
2573
2574
2575
2576
2577
2578 Legg                        Standards Track                    [Page 46]
2579 \f
2580 RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
2581
2582
2583    [RFC4514]  Zeilenga, K., Ed., "Lightweight Directory Access Protocol
2584               (LDAP): String Representation of Distinguished Names", RFC
2585               4514, June 2006.
2586
2587    [RFC4518]  Zeilenga, K., "Lightweight Directory Access Protocol
2588               (LDAP): Internationalized String Preparation", RFC 4518,
2589               June 2006.
2590
2591    [RFC4520]  Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
2592               Considerations for the Lightweight Directory Access
2593               Protocol (LDAP)", BCP 64, RFC 4520, June 2006.
2594
2595    [E.123]    Notation for national and international telephone numbers,
2596               ITU-T Recommendation E.123, 1988.
2597
2598    [FAX]      Standardization of Group 3 facsimile apparatus for
2599               document transmission - Terminal Equipment and Protocols
2600               for Telematic Services, ITU-T Recommendation T.4, 1993
2601
2602    [T.50]     International Reference Alphabet (IRA) (Formerly
2603               International Alphabet No. 5 or IA5) Information
2604               Technology - 7-Bit Coded Character Set for Information
2605               Interchange, ITU-T Recommendation T.50, 1992
2606
2607    [X.420]    ITU-T Recommendation X.420 (1996) | ISO/IEC 10021-7:1997,
2608               Information Technology - Message Handling Systems (MHS):
2609               Interpersonal messaging system
2610
2611    [X.501]    ITU-T Recommendation X.501 (1993) | ISO/IEC 9594-2:1994,
2612               Information Technology - Open Systems Interconnection -
2613               The Directory: Models
2614
2615    [X.520]    ITU-T Recommendation X.520 (1993) | ISO/IEC 9594-6:1994,
2616               Information Technology - Open Systems Interconnection -
2617               The Directory: Selected attribute types
2618
2619    [ASN.1]    ITU-T Recommendation X.680 (07/02) | ISO/IEC 8824-1:2002,
2620               Information technology - Abstract Syntax Notation One
2621               (ASN.1): Specification of basic notation
2622
2623    [ISO3166]  ISO 3166, "Codes for the representation of names of
2624               countries".
2625
2626    [ISO8601]  ISO 8601:2004, "Data elements and interchange formats --
2627               Information interchange -- Representation of dates and
2628               times".
2629
2630
2631
2632
2633
2634 Legg                        Standards Track                    [Page 47]
2635 \f
2636 RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
2637
2638
2639    [UCS]      Universal Multiple-Octet Coded Character Set (UCS) -
2640               Architecture and Basic Multilingual Plane, ISO/IEC 10646-
2641               1:  1993 (with amendments).
2642
2643    [JPEG]     JPEG File Interchange Format (Version 1.02).  Eric
2644               Hamilton, C-Cube Microsystems, Milpitas, CA, September 1,
2645               1992.
2646
2647 8.2.  Informative References
2648
2649    [RFC4519]  Sciberras, A., Ed., "Lightweight Directory Access Protocol
2650               (LDAP): Schema for User Applications", RFC 4519, June
2651               2006.
2652
2653    [RFC4523]  Zeilenga, K., "Lightweight Directory Access Protocol
2654               (LDAP) Schema Definitions for X.509 Certificates", RFC
2655               4523, June 2006.
2656
2657    [X.500]    ITU-T Recommendation X.500 (1993) | ISO/IEC 9594-1:1994,
2658               Information Technology - Open Systems Interconnection -
2659               The Directory: Overview of concepts, models and services
2660
2661    [BER]      ITU-T Recommendation X.690 (07/02) | ISO/IEC 8825-1:2002,
2662               Information technology - ASN.1 encoding rules:
2663               Specification of Basic Encoding Rules (BER), Canonical
2664               Encoding Rules (CER) and Distinguished Encoding Rules
2665               (DER)
2666
2667
2668
2669
2670
2671
2672
2673
2674
2675
2676
2677
2678
2679
2680
2681
2682
2683
2684
2685
2686
2687
2688
2689
2690 Legg                        Standards Track                    [Page 48]
2691 \f
2692 RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
2693
2694
2695 Appendix A. Summary of Syntax Object Identifiers
2696
2697    The following list summarizes the object identifiers assigned to the
2698    syntaxes defined in this document.
2699
2700       Syntax                           OBJECT IDENTIFIER
2701       ==============================================================
2702       Attribute Type Description       1.3.6.1.4.1.1466.115.121.1.3
2703       Bit String                       1.3.6.1.4.1.1466.115.121.1.6
2704       Boolean                          1.3.6.1.4.1.1466.115.121.1.7
2705       Country String                   1.3.6.1.4.1.1466.115.121.1.11
2706       Delivery Method                  1.3.6.1.4.1.1466.115.121.1.14
2707       Directory String                 1.3.6.1.4.1.1466.115.121.1.15
2708       DIT Content Rule Description     1.3.6.1.4.1.1466.115.121.1.16
2709       DIT Structure Rule Description   1.3.6.1.4.1.1466.115.121.1.17
2710       DN                               1.3.6.1.4.1.1466.115.121.1.12
2711       Enhanced Guide                   1.3.6.1.4.1.1466.115.121.1.21
2712       Facsimile Telephone Number       1.3.6.1.4.1.1466.115.121.1.22
2713       Fax                              1.3.6.1.4.1.1466.115.121.1.23
2714       Generalized Time                 1.3.6.1.4.1.1466.115.121.1.24
2715       Guide                            1.3.6.1.4.1.1466.115.121.1.25
2716       IA5 String                       1.3.6.1.4.1.1466.115.121.1.26
2717       Integer                          1.3.6.1.4.1.1466.115.121.1.27
2718       JPEG                             1.3.6.1.4.1.1466.115.121.1.28
2719       LDAP Syntax Description          1.3.6.1.4.1.1466.115.121.1.54
2720       Matching Rule Description        1.3.6.1.4.1.1466.115.121.1.30
2721       Matching Rule Use Description    1.3.6.1.4.1.1466.115.121.1.31
2722       Name And Optional UID            1.3.6.1.4.1.1466.115.121.1.34
2723       Name Form Description            1.3.6.1.4.1.1466.115.121.1.35
2724       Numeric String                   1.3.6.1.4.1.1466.115.121.1.36
2725       Object Class Description         1.3.6.1.4.1.1466.115.121.1.37
2726       Octet String                     1.3.6.1.4.1.1466.115.121.1.40
2727       OID                              1.3.6.1.4.1.1466.115.121.1.38
2728       Other Mailbox                    1.3.6.1.4.1.1466.115.121.1.39
2729       Postal Address                   1.3.6.1.4.1.1466.115.121.1.41
2730       Printable String                 1.3.6.1.4.1.1466.115.121.1.44
2731       Substring Assertion              1.3.6.1.4.1.1466.115.121.1.58
2732       Telephone Number                 1.3.6.1.4.1.1466.115.121.1.50
2733       Teletex Terminal Identifier      1.3.6.1.4.1.1466.115.121.1.51
2734       Telex Number                     1.3.6.1.4.1.1466.115.121.1.52
2735       UTC Time                         1.3.6.1.4.1.1466.115.121.1.53
2736
2737 Appendix B. Changes from RFC 2252
2738
2739    This annex lists the significant differences between this
2740    specification and RFC 2252.
2741
2742
2743
2744
2745
2746 Legg                        Standards Track                    [Page 49]
2747 \f
2748 RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
2749
2750
2751    This annex is provided for informational purposes only.  It is not a
2752    normative part of this specification.
2753
2754    1.  The IESG Note has been removed.
2755
2756    2.  The major part of Sections 4, 5 and 7 has been moved to [RFC4512]
2757        and revised.  Changes to the parts of these sections moved to
2758        [RFC4512] are detailed in [RFC4512].
2759
2760    3.  BNF descriptions of syntax formats have been replaced by ABNF
2761        [RFC4234] specifications.
2762
2763    4.  The ambiguous statement in RFC 2252, Section 4.3 regarding the
2764        use of a backslash quoting mechanism to escape separator symbols
2765        has been removed.  The escaping mechanism is now explicitly
2766        represented in the ABNF for the syntaxes where this provision
2767        applies.
2768
2769    5.  The description of each of the LDAP syntaxes has been expanded so
2770        that they are less dependent on knowledge of X.500 for
2771        interpretation.
2772
2773    6.  The relationship of LDAP syntaxes to corresponding ASN.1 type
2774        definitions has been made explicit.
2775
2776    7.  The set of characters allowed in a <PrintableString> (formerly
2777        <printablestring>) has been corrected to align with the
2778        PrintableString ASN.1 type in [ASN.1].  Specifically, the double
2779        quote character has been removed and the single quote character
2780        and equals sign have been added.
2781
2782    8.  Values of the Directory String, Printable String and Telephone
2783        Number syntaxes are now required to have at least one character.
2784
2785    9.  The <DITContentRuleDescription>, <NameFormDescription> and
2786        <DITStructureRuleDescription> rules have been moved to [RFC4512].
2787
2788    10. The corresponding ASN.1 type for the Other Mailbox syntax has
2789        been incorporated from RFC 1274.
2790
2791    11. A corresponding ASN.1 type for the LDAP Syntax Description syntax
2792        has been invented.
2793
2794    12. The Binary syntax has been removed because it was not adequately
2795        specified, implementations with different incompatible
2796        interpretations exist, and it was confused with the ;binary
2797        transfer encoding.
2798
2799
2800
2801
2802 Legg                        Standards Track                    [Page 50]
2803 \f
2804 RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
2805
2806
2807    13. All discussion of transfer options, including the ";binary"
2808        option, has been removed.  All imperatives regarding binary
2809        transfer of values have been removed.
2810
2811    14. The Delivery Method, Enhanced Guide, Guide, Octet String, Teletex
2812        Terminal Identifier and Telex Number syntaxes from RFC 2256 have
2813        been incorporated.
2814
2815    15. The <criteria> rule for the Enhanced Guide and Guide syntaxes has
2816        been extended to accommodate empty "and" and "or" expressions.
2817
2818    16. An encoding for the <ttx-value> rule in the Teletex Terminal
2819        Identifier syntax has been defined.
2820
2821    17. The PKI-related syntaxes (Certificate, Certificate List and
2822        Certificate Pair) have been removed.  They are reintroduced in
2823        [RFC4523] (as is the Supported Algorithm syntax from RFC 2256).
2824
2825    18. The MHS OR Address syntax has been removed since its
2826        specification (in RFC 2156) is not at draft standard maturity.
2827
2828    19. The DL Submit Permission syntax has been removed as it depends on
2829        the MHS OR Address syntax.
2830
2831    20. The Presentation Address syntax has been removed since its
2832        specification (in RFC 1278) is not at draft standard maturity.
2833
2834    21. The ACI Item, Access Point, Audio, Data Quality, DSA Quality, DSE
2835        Type, LDAP Schema Description, Master And Shadow Access Points,
2836        Modify Rights, Protocol Information, Subtree Specification,
2837        Supplier Information, Supplier Or Consumer and Supplier And
2838        Consumer syntaxes have been removed.  These syntaxes are
2839        referenced in RFC 2252, but not defined.
2840
2841    22. The LDAP Schema Definition syntax (defined in RFC 2927) and the
2842        Mail Preference syntax have been removed on the grounds that they
2843        are out of scope for the core specification.
2844
2845    23. The description of each of the matching rules has been expanded
2846        so that they are less dependent on knowledge of X.500 for
2847        interpretation.
2848
2849    24. The caseIgnoreIA5SubstringsMatch matching rule from RFC 2798 has
2850        been added.
2851
2852    25. The caseIgnoreListSubstringsMatch, caseIgnoreOrderingMatch and
2853        caseIgnoreSubstringsMatch matching rules have been added to the
2854        list of matching rules for which the provisions for handling
2855
2856
2857
2858 Legg                        Standards Track                    [Page 51]
2859 \f
2860 RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
2861
2862
2863        leading, trailing and multiple adjoining whitespace characters
2864        apply (now through string preparation).  This is consistent with
2865        the definitions of these matching rules in X.500.  The
2866        caseIgnoreIA5SubstringsMatch rule has also been added to the
2867        list.
2868
2869    26. The specification of the octetStringMatch matching rule from
2870        RFC 2256 has been added to this document.
2871
2872    27. The presentationAddressMatch matching rule has been removed as it
2873        depends on an assertion syntax (Presentation Address) that is not
2874        at draft standard maturity.
2875
2876    28. The protocolInformationMatch matching rule has been removed as it
2877        depends on an undefined assertion syntax (Protocol Information).
2878
2879    29. The definitive reference for ASN.1 has been changed from X.208 to
2880        X.680 since X.680 is the version of ASN.1 referred to by X.500.
2881
2882    30. The specification of the caseIgnoreListSubstringsMatch matching
2883        rule from RFC 2798 & X.520 has been added.
2884
2885    31. String preparation algorithms have been applied to the character
2886        string matching rules.
2887
2888    32. The specifications of the booleanMatch, caseExactMatch,
2889        caseExactOrderingMatch, caseExactSubstringsMatch,
2890        directoryStringFirstComponentMatch, integerOrderingMatch,
2891        keywordMatch, numericStringOrderingMatch,
2892        octetStringOrderingMatch and wordMatch matching rules from
2893        RFC 3698 & X.520 have been added.
2894
2895 Author's Address
2896
2897    Steven Legg
2898    eB2Bcom
2899    Suite3, Woodhouse Corporate Centre
2900    935 Station Street
2901    Box Hill North, Victoria 3129
2902    AUSTRALIA
2903
2904    Phone: +61 3 9896 7830
2905    Fax: +61 3 9896 7801
2906    EMail: steven.legg@eb2bcom.com
2907
2908
2909
2910
2911
2912
2913
2914 Legg                        Standards Track                    [Page 52]
2915 \f
2916 RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
2917
2918
2919 Full Copyright Statement
2920
2921    Copyright (C) The Internet Society (2006).
2922
2923    This document is subject to the rights, licenses and restrictions
2924    contained in BCP 78, and except as set forth therein, the authors
2925    retain all their rights.
2926
2927    This document and the information contained herein are provided on an
2928    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
2929    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
2930    ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
2931    INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
2932    INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
2933    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
2934
2935 Intellectual Property
2936
2937    The IETF takes no position regarding the validity or scope of any
2938    Intellectual Property Rights or other rights that might be claimed to
2939    pertain to the implementation or use of the technology described in
2940    this document or the extent to which any license under such rights
2941    might or might not be available; nor does it represent that it has
2942    made any independent effort to identify any such rights.  Information
2943    on the procedures with respect to rights in RFC documents can be
2944    found in BCP 78 and BCP 79.
2945
2946    Copies of IPR disclosures made to the IETF Secretariat and any
2947    assurances of licenses to be made available, or the result of an
2948    attempt made to obtain a general license or permission for the use of
2949    such proprietary rights by implementers or users of this
2950    specification can be obtained from the IETF on-line IPR repository at
2951    http://www.ietf.org/ipr.
2952
2953    The IETF invites any interested party to bring to its attention any
2954    copyrights, patents or patent applications, or other proprietary
2955    rights that may cover technology that may be required to implement
2956    this standard.  Please address the information to the IETF at
2957    ietf-ipr@ietf.org.
2958
2959 Acknowledgement
2960
2961    Funding for the RFC Editor function is provided by the IETF
2962    Administrative Support Activity (IASA).
2963
2964
2965
2966
2967
2968
2969
2970 Legg                        Standards Track                    [Page 53]
2971 \f