diff options
Diffstat (limited to 'source4/ldap_server/devdocs/rfc4517.txt')
| -rw-r--r-- | source4/ldap_server/devdocs/rfc4517.txt | 2971 |
1 files changed, 2971 insertions, 0 deletions
diff --git a/source4/ldap_server/devdocs/rfc4517.txt b/source4/ldap_server/devdocs/rfc4517.txt new file mode 100644 index 0000000000..177e08b2ac --- /dev/null +++ b/source4/ldap_server/devdocs/rfc4517.txt @@ -0,0 +1,2971 @@ + + + + + + +Network Working Group S. Legg, Ed. +Request for Comments: 4517 eB2Bcom +Obsoletes: 2252, 2256 June 2006 +Updates: 3698 +Category: Standards Track + + + Lightweight Directory Access Protocol (LDAP): + Syntaxes and Matching Rules + + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2006). + +Abstract + + Each attribute stored in a Lightweight Directory Access Protocol + (LDAP) directory, whose values may be transferred in the LDAP + protocol, has a defined syntax that constrains the structure and + format of its values. The comparison semantics for values of a + syntax are not part of the syntax definition but are instead provided + through separately defined matching rules. Matching rules specify an + argument, an assertion value, which also has a defined syntax. This + document defines a base set of syntaxes and matching rules for use in + defining attributes for LDAP directories. + +Table of Contents + + 1. Introduction ....................................................3 + 2. Conventions .....................................................4 + 3. Syntaxes ........................................................4 + 3.1. General Considerations .....................................5 + 3.2. Common Definitions .........................................5 + 3.3. Syntax Definitions .........................................6 + 3.3.1. Attribute Type Description ..........................6 + 3.3.2. Bit String ..........................................6 + 3.3.3. Boolean .............................................7 + 3.3.4. Country String ......................................7 + 3.3.5. Delivery Method .....................................8 + + + +Legg Standards Track [Page 1] + +RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 + + + 3.3.6. Directory String ....................................8 + 3.3.7. DIT Content Rule Description ........................9 + 3.3.8. DIT Structure Rule Description .....................10 + 3.3.9. DN .................................................10 + 3.3.10. Enhanced Guide ....................................11 + 3.3.11. Facsimile Telephone Number ........................12 + 3.3.12. Fax ...............................................12 + 3.3.13. Generalized Time ..................................13 + 3.3.14. Guide .............................................14 + 3.3.15. IA5 String ........................................15 + 3.3.16. Integer ...........................................15 + 3.3.17. JPEG ..............................................15 + 3.3.18. LDAP Syntax Description ...........................16 + 3.3.19. Matching Rule Description .........................16 + 3.3.20. Matching Rule Use Description .....................17 + 3.3.21. Name and Optional UID .............................17 + 3.3.22. Name Form Description .............................18 + 3.3.23. Numeric String ....................................18 + 3.3.24. Object Class Description ..........................18 + 3.3.25. Octet String ......................................19 + 3.3.26. OID ...............................................19 + 3.3.27. Other Mailbox .....................................20 + 3.3.28. Postal Address ....................................20 + 3.3.29. Printable String ..................................21 + 3.3.30. Substring Assertion ...............................22 + 3.3.31. Telephone Number ..................................23 + 3.3.32. Teletex Terminal Identifier .......................23 + 3.3.33. Telex Number ......................................24 + 3.3.34. UTC Time ..........................................24 + 4. Matching Rules .................................................25 + 4.1. General Considerations ....................................25 + 4.2. Matching Rule Definitions .................................27 + 4.2.1. bitStringMatch .....................................27 + 4.2.2. booleanMatch .......................................28 + 4.2.3. caseExactIA5Match ..................................28 + 4.2.4. caseExactMatch .....................................29 + 4.2.5. caseExactOrderingMatch .............................29 + 4.2.6. caseExactSubstringsMatch ...........................30 + 4.2.7. caseIgnoreIA5Match .................................30 + 4.2.8. caseIgnoreIA5SubstringsMatch .......................31 + 4.2.9. caseIgnoreListMatch ................................31 + 4.2.10. caseIgnoreListSubstringsMatch .....................32 + 4.2.11. caseIgnoreMatch ...................................33 + 4.2.12. caseIgnoreOrderingMatch ...........................33 + 4.2.13. caseIgnoreSubstringsMatch .........................34 + 4.2.14. directoryStringFirstComponentMatch ................34 + 4.2.15. distinguishedNameMatch ............................35 + 4.2.16. generalizedTimeMatch ..............................36 + + + +Legg Standards Track [Page 2] + +RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 + + + 4.2.17. generalizedTimeOrderingMatch ......................36 + 4.2.18. integerFirstComponentMatch ........................36 + 4.2.19. integerMatch ......................................37 + 4.2.20. integerOrderingMatch ..............................37 + 4.2.21. keywordMatch ......................................38 + 4.2.22. numericStringMatch ................................38 + 4.2.23. numericStringOrderingMatch ........................39 + 4.2.24. numericStringSubstringsMatch ......................39 + 4.2.25. objectIdentifierFirstComponentMatch ...............40 + 4.2.26. objectIdentifierMatch .............................40 + 4.2.27. octetStringMatch ..................................41 + 4.2.28. octetStringOrderingMatch ..........................41 + 4.2.29. telephoneNumberMatch ..............................42 + 4.2.30. telephoneNumberSubstringsMatch ....................42 + 4.2.31. uniqueMemberMatch .................................43 + 4.2.32. wordMatch .........................................44 + 5. Security Considerations ........................................44 + 6. Acknowledgements ...............................................44 + 7. IANA Considerations ............................................45 + 8. References .....................................................46 + 8.1. Normative References ......................................46 + 8.2. Informative References ....................................48 + Appendix A. Summary of Syntax Object Identifiers ..................49 + Appendix B. Changes from RFC 2252 .................................49 + +1. Introduction + + Each attribute stored in a Lightweight Directory Access Protocol + (LDAP) directory [RFC4510], whose values may be transferred in the + LDAP protocol [RFC4511], has a defined syntax (i.e., data type) that + constrains the structure and format of its values. The comparison + semantics for values of a syntax are not part of the syntax + definition but are instead provided through separately defined + matching rules. Matching rules specify an argument, an assertion + value, which also has a defined syntax. This document defines a base + set of syntaxes and matching rules for use in defining attributes for + LDAP directories. + + Readers are advised to familiarize themselves with the Directory + Information Models [RFC4512] before reading the rest of this + document. Section 3 provides definitions for the base set of LDAP + syntaxes. Section 4 provides definitions for the base set of + matching rules for LDAP. + + This document is an integral part of the LDAP technical specification + [RFC4510], which obsoletes the previously defined LDAP technical + specification, RFC 3377, in its entirety. + + + + +Legg Standards Track [Page 3] + +RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 + + + Sections 4, 5, and 7 of RFC 2252 are obsoleted by [RFC4512]. The + remainder of RFC 2252 is obsoleted by this document. Sections 6 and + 8 of RFC 2256 are obsoleted by this document. The remainder of RFC + 2256 is obsoleted by [RFC4519] and [RFC4512]. All but Section 2.11 + of RFC 3698 is obsoleted by this document. + + A number of schema elements that were included in the previous + revision of the LDAP technical specification are not included in this + revision of LDAP. Public Key Infrastructure schema elements are now + specified in [RFC4523]. Unless reintroduced in future technical + specifications, the remainder are to be considered Historic. + + The changes with respect to RFC 2252 are described in Appendix B of + this document. + +2. Conventions + + In this document, the key words "MUST", "MUST NOT", "REQUIRED", + "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", + and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 + [RFC2119]. + + Syntax definitions are written according to the <SyntaxDescription> + ABNF [RFC4234] rule specified in [RFC4512], and matching rule + definitions are written according to the <MatchingRuleDescription> + ABNF rule specified in [RFC4512], except that the syntax and matching + rule definitions provided in this document are line-wrapped for + readability. When such definitions are transferred as attribute + values in the LDAP protocol (e.g., as values of the ldapSyntaxes and + matchingRules attributes [RFC4512], respectively), then those values + would not contain line breaks. + +3. Syntaxes + + Syntax definitions constrain the structure of attribute values stored + in an LDAP directory, and determine the representation of attribute + and assertion values transferred in the LDAP protocol. + + Syntaxes that are required for directory operation, or that are in + common use, are specified in this section. Servers SHOULD recognize + all the syntaxes listed in this document, but are not required to + otherwise support them, and MAY recognise or support other syntaxes. + However, the definition of additional arbitrary syntaxes is + discouraged since it will hinder interoperability. Client and server + implementations typically do not have the ability to dynamically + recognize new syntaxes. + + + + + +Legg Standards Track [Page 4] + +RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 + + +3.1. General Considerations + + The description of each syntax specifies how attribute or assertion + values conforming to the syntax are to be represented when + transferred in the LDAP protocol [RFC4511]. This representation is + referred to as the LDAP-specific encoding to distinguish it from + other methods of encoding attribute values (e.g., the Basic Encoding + Rules (BER) encoding [BER] used by X.500 [X.500] directories). + + The LDAP-specific encoding of a given attribute syntax always + produces octet-aligned values. To the greatest extent possible, + encoding rules for LDAP syntaxes should produce character strings + that can be displayed with little or no translation by clients + implementing LDAP. However, clients MUST NOT assume that the LDAP- + specific encoding of a value of an unrecognized syntax is a human- + readable character string. There are a few cases (e.g., the JPEG + syntax) when it is not reasonable to produce a human-readable + representation. + + Each LDAP syntax is uniquely identified with an object identifier + [ASN.1] represented in the dotted-decimal format (short descriptive + names are not defined for syntaxes). These object identifiers are + not intended to be displayed to users. The object identifiers for + the syntaxes defined in this document are summarized in Appendix A. + + A suggested minimum upper bound on the number of characters in an + attribute value with a string-based syntax, or the number of octets + in a value for all other syntaxes, MAY be indicated by appending the + bound inside of curly braces following the syntax's OBJECT IDENTIFIER + in an attribute type definition (see the <noidlen> rule in + [RFC4512]). Such a bound is not considered part of the syntax + identifier. + + For example, "1.3.6.1.4.1.1466.115.121.1.15{64}" in an attribute + definition suggests that the directory server will allow a value of + the attribute to be up to 64 characters long, although it may allow + longer character strings. Note that a single character of the + Directory String syntax can be encoded in more than one octet, since + UTF-8 [RFC3629] is a variable-length encoding. Therefore, a 64- + character string may be more than 64 octets in length. + +3.2. Common Definitions + + The following ABNF rules are used in a number of the syntax + definitions in Section 3.3. + + PrintableCharacter = ALPHA / DIGIT / SQUOTE / LPAREN / RPAREN / + PLUS / COMMA / HYPHEN / DOT / EQUALS / + + + +Legg Standards Track [Page 5] + +RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 + + + SLASH / COLON / QUESTION / SPACE + PrintableString = 1*PrintableCharacter + IA5String = *(%x00-7F) + SLASH = %x2F ; forward slash ("/") + COLON = %x3A ; colon (":") + QUESTION = %x3F ; question mark ("?") + + The <ALPHA>, <DIGIT>, <SQUOTE>, <LPAREN>, <RPAREN>, <PLUS>, <COMMA>, + <HYPHEN>, <DOT>, <EQUALS>, and <SPACE> rules are defined in + [RFC4512]. + +3.3. Syntax Definitions + +3.3.1. Attribute Type Description + + A value of the Attribute Type Description syntax is the definition of + an attribute type. The LDAP-specific encoding of a value of this + syntax is defined by the <AttributeTypeDescription> rule in + [RFC4512]. + + For example, the following definition of the createTimestamp + attribute type from [RFC4512] is also a value of the Attribute + Type Description syntax. (Note: Line breaks have been added for + readability; they are not part of the value when transferred in + protocol.) + + ( 2.5.18.1 NAME 'createTimestamp' + EQUALITY generalizedTimeMatch + ORDERING generalizedTimeOrderingMatch + SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 + SINGLE-VALUE NO-USER-MODIFICATION + USAGE directoryOperation ) + + The LDAP definition for the Attribute Type Description syntax is: + + ( 1.3.6.1.4.1.1466.115.121.1.3 DESC 'Attribute Type Description' ) + + This syntax corresponds to the AttributeTypeDescription ASN.1 type + from [X.501]. + +3.3.2. Bit String + + A value of the Bit String syntax is a sequence of binary digits. The + LDAP-specific encoding of a value of this syntax is defined by the + following ABNF: + + BitString = SQUOTE *binary-digit SQUOTE "B" + binary-digit = "0" / "1" + + + +Legg Standards Track [Page 6] + +RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 + + + The <SQUOTE> rule is defined in [RFC4512]. + + Example: + '0101111101'B + + The LDAP definition for the Bit String syntax is: + + ( 1.3.6.1.4.1.1466.115.121.1.6 DESC 'Bit String' ) + + This syntax corresponds to the BIT STRING ASN.1 type from [ASN.1]. + +3.3.3. Boolean + + A value of the Boolean syntax is one of the Boolean values, true or + false. The LDAP-specific encoding of a value of this syntax is + defined by the following ABNF: + + Boolean = "TRUE" / "FALSE" + + The LDAP definition for the Boolean syntax is: + + ( 1.3.6.1.4.1.1466.115.121.1.7 DESC 'Boolean' ) + + This syntax corresponds to the BOOLEAN ASN.1 type from [ASN.1]. + +3.3.4. Country String + + A value of the Country String syntax is one of the two-character + codes from ISO 3166 [ISO3166] for representing a country. The LDAP- + specific encoding of a value of this syntax is defined by the + following ABNF: + + CountryString = 2(PrintableCharacter) + + The <PrintableCharacter> rule is defined in Section 3.2. + + Examples: + + US + AU + + The LDAP definition for the Country String syntax is: + + ( 1.3.6.1.4.1.1466.115.121.1.11 DESC 'Country String' ) + + This syntax corresponds to the following ASN.1 type from [X.520]: + + PrintableString (SIZE (2)) -- ISO 3166 codes only + + + +Legg Standards Track [Page 7] + +RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 + + +3.3.5. Delivery Method + + A value of the Delivery Method syntax is a sequence of items that + indicate, in preference order, the service(s) by which an entity is + willing and/or capable of receiving messages. The LDAP-specific + encoding of a value of this syntax is defined by the following ABNF: + + DeliveryMethod = pdm *( WSP DOLLAR WSP pdm ) + + pdm = "any" / "mhs" / "physical" / "telex" / "teletex" / + "g3fax" / "g4fax" / "ia5" / "videotex" / "telephone" + + The <WSP> and <DOLLAR> rules are defined in [RFC4512]. + + Example: + telephone $ videotex + + The LDAP definition for the Delivery Method syntax is: + + ( 1.3.6.1.4.1.1466.115.121.1.14 DESC 'Delivery Method' ) + + This syntax corresponds to the following ASN.1 type from [X.520]: + + SEQUENCE OF INTEGER { + any-delivery-method (0), + mhs-delivery (1), + physical-delivery (2), + telex-delivery (3), + teletex-delivery (4), + g3-facsimile-delivery (5), + g4-facsimile-delivery (6), + ia5-terminal-delivery (7), + videotex-delivery (8), + telephone-delivery (9) } + +3.3.6. Directory String + + A value of the Directory String syntax is a string of one or more + arbitrary characters from the Universal Character Set (UCS) [UCS]. A + zero-length character string is not permitted. The LDAP-specific + encoding of a value of this syntax is the UTF-8 encoding [RFC3629] of + the character string. Such encodings conform to the following ABNF: + + DirectoryString = 1*UTF8 + + The <UTF8> rule is defined in [RFC4512]. + + + + + +Legg Standards Track [Page 8] + +RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 + + + Example: + This is a value of Directory String containing #!%#@. + + Servers and clients MUST be prepared to receive arbitrary UCS code + points, including code points outside the range of printable ASCII + and code points not presently assigned to any character. + + Attribute type definitions using the Directory String syntax should + not restrict the format of Directory String values, e.g., by + requiring that the character string conforms to specific patterns + described by ABNF. A new syntax should be defined in such cases. + + The LDAP definition for the Directory String syntax is: + + ( 1.3.6.1.4.1.1466.115.121.1.15 DESC 'Directory String' ) + + This syntax corresponds to the DirectoryString parameterized ASN.1 + type from [X.520]. + + The DirectoryString ASN.1 type allows a choice between the + TeletexString, PrintableString, or UniversalString ASN.1 types from + [ASN.1]. However, note that the chosen alternative is not indicated + in the LDAP-specific encoding of a Directory String value. + + Implementations that convert Directory String values from the LDAP- + specific encoding to the BER encoding used by X.500 must choose an + alternative that permits the particular characters in the string and + must convert the characters from the UTF-8 encoding into the + character encoding of the chosen alternative. When converting + Directory String values from the BER encoding to the LDAP-specific + encoding, the characters must be converted from the character + encoding of the chosen alternative into the UTF-8 encoding. These + conversions SHOULD be done in a manner consistent with the Transcode + step of the string preparation algorithms [RFC4518] for LDAP. + +3.3.7. DIT Content Rule Description + + A value of the DIT Content Rule Description syntax is the definition + of a DIT (Directory Information Tree) content rule. The LDAP- + specific encoding of a value of this syntax is defined by the + <DITContentRuleDescription> rule in [RFC4512]. + + Example: + ( 2.5.6.4 DESC 'content rule for organization' + NOT ( x121Address $ telexNumber ) ) + + Note: A line break has been added for readability; it is not part + of the value. + + + +Legg Standards Track [Page 9] + +RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 + + + The LDAP definition for the DIT Content Rule Description syntax is: + + ( 1.3.6.1.4.1.1466.115.121.1.16 + DESC 'DIT Content Rule Description' ) + + This syntax corresponds to the DITContentRuleDescription ASN.1 type + from [X.501]. + +3.3.8. DIT Structure Rule Description + + A value of the DIT Structure Rule Description syntax is the + definition of a DIT structure rule. The LDAP-specific encoding of a + value of this syntax is defined by the <DITStructureRuleDescription> + rule in [RFC4512]. + + Example: + ( 2 DESC 'organization structure rule' FORM 2.5.15.3 ) + + The LDAP definition for the DIT Structure Rule Description syntax is: + + ( 1.3.6.1.4.1.1466.115.121.1.17 + DESC 'DIT Structure Rule Description' ) + + This syntax corresponds to the DITStructureRuleDescription ASN.1 type + from [X.501]. + +3.3.9. DN + + A value of the DN syntax is the (purported) distinguished name (DN) + of an entry [RFC4512]. The LDAP-specific encoding of a value of this + syntax is defined by the <distinguishedName> rule from the string + representation of distinguished names [RFC4514]. + + Examples (from [RFC4514]): + UID=jsmith,DC=example,DC=net + OU=Sales+CN=J. Smith,DC=example,DC=net + CN=John Smith\, III,DC=example,DC=net + CN=Before\0dAfter,DC=example,DC=net + 1.3.6.1.4.1.1466.0=#04024869,DC=example,DC=com + CN=Lu\C4\8Di\C4\87 + + The LDAP definition for the DN syntax is: + + ( 1.3.6.1.4.1.1466.115.121.1.12 DESC 'DN' ) + + The DN syntax corresponds to the DistinguishedName ASN.1 type from + [X.501]. Note that a BER encoded distinguished name (as used by + X.500) re-encoded into the LDAP-specific encoding is not necessarily + + + +Legg Standards Track [Page 10] + +RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 + + + reversible to the original BER encoding since the chosen string type + in any DirectoryString components of the distinguished name is not + indicated in the LDAP-specific encoding of the distinguished name + (see Section 3.3.6). + +3.3.10. Enhanced Guide + + A value of the Enhanced Guide syntax suggests criteria, which consist + of combinations of attribute types and filter operators, to be used + in constructing filters to search for entries of particular object + classes. The Enhanced Guide syntax improves upon the Guide syntax by + allowing the recommended depth of the search to be specified. + + The LDAP-specific encoding of a value of this syntax is defined by + the following ABNF: + + EnhancedGuide = object-class SHARP WSP criteria WSP + SHARP WSP subset + object-class = WSP oid WSP + subset = "baseobject" / "oneLevel" / "wholeSubtree" + + criteria = and-term *( BAR and-term ) + and-term = term *( AMPERSAND term ) + term = EXCLAIM term / + attributetype DOLLAR match-type / + LPAREN criteria RPAREN / + true / + false + match-type = "EQ" / "SUBSTR" / "GE" / "LE" / "APPROX" + true = "?true" + false = "?false" + BAR = %x7C ; vertical bar ("|") + AMPERSAND = %x26 ; ampersand ("&") + EXCLAIM = %x21 ; exclamation mark ("!") + + The <SHARP>, <WSP>, <oid>, <LPAREN>, <RPAREN>, <attributetype>, and + <DOLLAR> rules are defined in [RFC4512]. + + The LDAP definition for the Enhanced Guide syntax is: + + ( 1.3.6.1.4.1.1466.115.121.1.21 DESC 'Enhanced Guide' ) + + Example: + person#(sn$EQ)#oneLevel + + The Enhanced Guide syntax corresponds to the EnhancedGuide ASN.1 type + from [X.520]. The EnhancedGuide type references the Criteria ASN.1 + type, also from [X.520]. The <true> rule, above, represents an empty + + + +Legg Standards Track [Page 11] + +RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 + + + "and" expression in a value of the Criteria type. The <false> rule, + above, represents an empty "or" expression in a value of the Criteria + type. + +3.3.11. Facsimile Telephone Number + + A value of the Facsimile Telephone Number syntax is a subscriber + number of a facsimile device on the public switched telephone + network. The LDAP-specific encoding of a value of this syntax is + defined by the following ABNF: + + fax-number = telephone-number *( DOLLAR fax-parameter ) + telephone-number = PrintableString + fax-parameter = "twoDimensional" / + "fineResolution" / + "unlimitedLength" / + "b4Length" / + "a3Width" / + "b4Width" / + "uncompressed" + + The <telephone-number> is a string of printable characters that + complies with the internationally agreed format for representing + international telephone numbers [E.123]. The <PrintableString> rule + is defined in Section 3.2. The <DOLLAR> rule is defined in + [RFC4512]. + + The LDAP definition for the Facsimile Telephone Number syntax is: + + ( 1.3.6.1.4.1.1466.115.121.1.22 DESC 'Facsimile Telephone Number') + + The Facsimile Telephone Number syntax corresponds to the + FacsimileTelephoneNumber ASN.1 type from [X.520]. + +3.3.12. Fax + + A value of the Fax syntax is an image that is produced using the + Group 3 facsimile process [FAX] to duplicate an object, such as a + memo. The LDAP-specific encoding of a value of this syntax is the + string of octets for a Group 3 Fax image as defined in [FAX]. + + The LDAP definition for the Fax syntax is: + + ( 1.3.6.1.4.1.1466.115.121.1.23 DESC 'Fax' ) + + The ASN.1 type corresponding to the Fax syntax is defined as follows, + assuming EXPLICIT TAGS: + + + + +Legg Standards Track [Page 12] + +RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 + + + Fax ::= CHOICE { + g3-facsimile [3] G3FacsimileBodyPart + } + + The G3FacsimileBodyPart ASN.1 type is defined in [X.420]. + +3.3.13. Generalized Time + + A value of the Generalized Time syntax is a character string + representing a date and time. The LDAP-specific encoding of a value + of this syntax is a restriction of the format defined in [ISO8601], + and is described by the following ABNF: + + GeneralizedTime = century year month day hour + [ minute [ second / leap-second ] ] + [ fraction ] + g-time-zone + + century = 2(%x30-39) ; "00" to "99" + year = 2(%x30-39) ; "00" to "99" + month = ( %x30 %x31-39 ) ; "01" (January) to "09" + / ( %x31 %x30-32 ) ; "10" to "12" + day = ( %x30 %x31-39 ) ; "01" to "09" + / ( %x31-32 %x30-39 ) ; "10" to "29" + / ( %x33 %x30-31 ) ; "30" to "31" + hour = ( %x30-31 %x30-39 ) / ( %x32 %x30-33 ) ; "00" to "23" + minute = %x30-35 %x30-39 ; "00" to "59" + + second = ( %x30-35 %x30-39 ) ; "00" to "59" + leap-second = ( %x36 %x30 ) ; "60" + + fraction = ( DOT / COMMA ) 1*(%x30-39) + g-time-zone = %x5A ; "Z" + / g-differential + g-differential = ( MINUS / PLUS ) hour [ minute ] + MINUS = %x2D ; minus sign ("-") + + The <DOT>, <COMMA>, and <PLUS> rules are defined in [RFC4512]. + + The above ABNF allows character strings that do not represent valid + dates (in the Gregorian calendar) and/or valid times (e.g., February + 31, 1994). Such character strings SHOULD be considered invalid for + this syntax. + + The time value represents coordinated universal time (equivalent to + Greenwich Mean Time) if the "Z" form of <g-time-zone> is used; + otherwise, the value represents a local time in the time zone + indicated by <g-differential>. In the latter case, coordinated + + + +Legg Standards Track [Page 13] + +RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 + + + universal time can be calculated by subtracting the differential from + the local time. The "Z" form of <g-time-zone> SHOULD be used in + preference to <g-differential>. + + If <minute> is omitted, then <fraction> represents a fraction of an + hour; otherwise, if <second> and <leap-second> are omitted, then + <fraction> represents a fraction of a minute; otherwise, <fraction> + represents a fraction of a second. + + Examples: + 199412161032Z + 199412160532-0500 + + Both example values represent the same coordinated universal time: + 10:32 AM, December 16, 1994. + + The LDAP definition for the Generalized Time syntax is: + + ( 1.3.6.1.4.1.1466.115.121.1.24 DESC 'Generalized Time' ) + + This syntax corresponds to the GeneralizedTime ASN.1 type from + [ASN.1], with the constraint that local time without a differential + SHALL NOT be used. + +3.3.14. Guide + + A value of the Guide syntax suggests criteria, which consist of + combinations of attribute types and filter operators, to be used in + constructing filters to search for entries of particular object + classes. The Guide syntax is obsolete and should not be used for + defining new attribute types. + + The LDAP-specific encoding of a value of this syntax is defined by + the following ABNF: + + Guide = [ object-class SHARP ] criteria + + The <object-class> and <criteria> rules are defined in Section + 3.3.10. The <SHARP> rule is defined in [RFC4512]. + + The LDAP definition for the Guide syntax is: + + ( 1.3.6.1.4.1.1466.115.121.1.25 DESC 'Guide' ) + + The Guide syntax corresponds to the Guide ASN.1 type from [X.520]. + + + + + + +Legg Standards Track [Page 14] + +RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 + + +3.3.15. IA5 String + + A value of the IA5 String syntax is a string of zero, one, or more + characters from International Alphabet 5 (IA5) [T.50], the + international version of the ASCII character set. The LDAP-specific + encoding of a value of this syntax is the unconverted string of + characters, which conforms to the <IA5String> rule in Section 3.2. + + The LDAP definition for the IA5 String syntax is: + + ( 1.3.6.1.4.1.1466.115.121.1.26 DESC 'IA5 String' ) + + This syntax corresponds to the IA5String ASN.1 type from [ASN.1]. + +3.3.16. Integer + + A value of the Integer syntax is a whole number of unlimited + magnitude. The LDAP-specific encoding of a value of this syntax is + the optionally signed decimal digit character string representation + of the number (for example, the number 1321 is represented by the + character string "1321"). The encoding is defined by the following + ABNF: + + Integer = ( HYPHEN LDIGIT *DIGIT ) / number + + The <HYPHEN>, <LDIGIT>, <DIGIT>, and <number> rules are defined in + [RFC4512]. + + The LDAP definition for the Integer syntax is: + + ( 1.3.6.1.4.1.1466.115.121.1.27 DESC 'INTEGER' ) + + This syntax corresponds to the INTEGER ASN.1 type from [ASN.1]. + +3.3.17. JPEG + + A value of the JPEG syntax is an image in the JPEG File Interchange + Format (JFIF), as described in [JPEG]. The LDAP-specific encoding of + a value of this syntax is the sequence of octets of the JFIF encoding + of the image. + + The LDAP definition for the JPEG syntax is: + + ( 1.3.6.1.4.1.1466.115.121.1.28 DESC 'JPEG' ) + + The JPEG syntax corresponds to the following ASN.1 type: + + + + + +Legg Standards Track [Page 15] + +RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 + + + JPEG ::= OCTET STRING (CONSTRAINED BY + { -- contents octets are an image in the -- + -- JPEG File Interchange Format -- }) + +3.3.18. LDAP Syntax Description + + A value of the LDAP Syntax Description syntax is the description of + an LDAP syntax. The LDAP-specific encoding of a value of this syntax + is defined by the <SyntaxDescription> rule in [RFC4512]. + + The LDAP definition for the LDAP Syntax Description syntax is: + + ( 1.3.6.1.4.1.1466.115.121.1.54 DESC 'LDAP Syntax Description' ) + + The above LDAP definition for the LDAP Syntax Description syntax is + itself a legal value of the LDAP Syntax Description syntax. + + The ASN.1 type corresponding to the LDAP Syntax Description syntax is + defined as follows, assuming EXPLICIT TAGS: + + LDAPSyntaxDescription ::= SEQUENCE { + identifier OBJECT IDENTIFIER, + description DirectoryString { ub-schema } OPTIONAL } + + The DirectoryString parameterized ASN.1 type is defined in [X.520]. + + The value of ub-schema (an integer) is implementation defined. A + non-normative definition appears in [X.520]. + +3.3.19. Matching Rule Description + + A value of the Matching Rule Description syntax is the definition of + a matching rule. The LDAP-specific encoding of a value of this + syntax is defined by the <MatchingRuleDescription> rule in [RFC4512]. + + Example: + ( 2.5.13.2 NAME 'caseIgnoreMatch' + SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) + + Note: A line break has been added for readability; it is not part of + the syntax. + + The LDAP definition for the Matching Rule Description syntax is: + + ( 1.3.6.1.4.1.1466.115.121.1.30 DESC 'Matching Rule Description' ) + + This syntax corresponds to the MatchingRuleDescription ASN.1 type + from [X.501]. + + + +Legg Standards Track [Page 16] + +RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 + + +3.3.20. Matching Rule Use Description + + A value of the Matching Rule Use Description syntax indicates the + attribute types to which a matching rule may be applied in an + extensibleMatch search filter [RFC4511]. The LDAP-specific encoding + of a value of this syntax is defined by the + <MatchingRuleUseDescription> rule in [RFC4512]. + + Example: + ( 2.5.13.16 APPLIES ( givenName $ surname ) ) + + The LDAP definition for the Matching Rule Use Description syntax is: + + ( 1.3.6.1.4.1.1466.115.121.1.31 + DESC 'Matching Rule Use Description' ) + + This syntax corresponds to the MatchingRuleUseDescription ASN.1 type + from [X.501]. + +3.3.21. Name and Optional UID + + A value of the Name and Optional UID syntax is the distinguished name + [RFC4512] of an entity optionally accompanied by a unique identifier + that serves to differentiate the entity from others with an identical + distinguished name. + + The LDAP-specific encoding of a value of this syntax is defined by + the following ABNF: + + NameAndOptionalUID = distinguishedName [ SHARP BitString ] + + The <BitString> rule is defined in Section 3.3.2. The + <distinguishedName> rule is defined in [RFC4514]. The <SHARP> rule + is defined in [RFC4512]. + + Note that although the '#' character may occur in the string + representation of a distinguished name, no additional escaping of + this character is performed when a <distinguishedName> is encoded in + a <NameAndOptionalUID>. + + Example: + 1.3.6.1.4.1.1466.0=#04024869,O=Test,C=GB#'0101'B + + The LDAP definition for the Name and Optional UID syntax is: + + ( 1.3.6.1.4.1.1466.115.121.1.34 DESC 'Name And Optional UID' ) + + + + + +Legg Standards Track [Page 17] + +RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 + + + This syntax corresponds to the NameAndOptionalUID ASN.1 type from + [X.520]. + +3.3.22. Name Form Description + + A value of the Name Form Description syntax is the definition of a + name form, which regulates how entries may be named. The LDAP- + specific encoding of a value of this syntax is defined by the + <NameFormDescription> rule in [RFC4512]. + + Example: + ( 2.5.15.3 NAME 'orgNameForm' OC organization MUST o ) + + The LDAP definition for the Name Form Description syntax is: + + ( 1.3.6.1.4.1.1466.115.121.1.35 DESC 'Name Form Description' ) + + This syntax corresponds to the NameFormDescription ASN.1 type from + [X.501]. + +3.3.23. Numeric String + + A value of the Numeric String syntax is a sequence of one or more + numerals and spaces. The LDAP-specific encoding of a value of this + syntax is the unconverted string of characters, which conforms to the + following ABNF: + + NumericString = 1*(DIGIT / SPACE) + + The <DIGIT> and <SPACE> rules are defined in [RFC4512]. + + Example: + 15 079 672 281 + + The LDAP definition for the Numeric String syntax is: + + ( 1.3.6.1.4.1.1466.115.121.1.36 DESC 'Numeric String' ) + + This syntax corresponds to the NumericString ASN.1 type from [ASN.1]. + +3.3.24. Object Class Description + + A value of the Object Class Description syntax is the definition of + an object class. The LDAP-specific encoding of a value of this + syntax is defined by the <ObjectClassDescription> rule in [RFC4512]. + + + + + + +Legg Standards Track [Page 18] + +RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 + + + Example: + ( 2.5.6.2 NAME 'country' SUP top STRUCTURAL MUST c + MAY ( searchGuide $ description ) ) + + Note: A line break has been added for readability; it is not part of + the syntax. + + The LDAP definition for the Object Class Description syntax is: + + ( 1.3.6.1.4.1.1466.115.121.1.37 DESC 'Object Class Description' ) + + This syntax corresponds to the ObjectClassDescription ASN.1 type from + [X.501]. + +3.3.25. Octet String + + A value of the Octet String syntax is a sequence of zero, one, or + more arbitrary octets. The LDAP-specific encoding of a value of this + syntax is the unconverted sequence of octets, which conforms to the + following ABNF: + + OctetString = *OCTET + + The <OCTET> rule is defined in [RFC4512]. Values of this syntax are + not generally human-readable. + + The LDAP definition for the Octet String syntax is: + + ( 1.3.6.1.4.1.1466.115.121.1.40 DESC 'Octet String' ) + + This syntax corresponds to the OCTET STRING ASN.1 type from [ASN.1]. + +3.3.26. OID + + A value of the OID syntax is an object identifier: a sequence of two + or more non-negative integers that uniquely identify some object or + item of specification. Many of the object identifiers used in LDAP + also have IANA registered names [RFC4520]. + + The LDAP-specific encoding of a value of this syntax is defined by + the <oid> rule in [RFC4512]. + + Examples: + 1.2.3.4 + cn + + The LDAP definition for the OID syntax is: + + + + +Legg Standards Track [Page 19] + +RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 + + + ( 1.3.6.1.4.1.1466.115.121.1.38 DESC 'OID' ) + + This syntax corresponds to the OBJECT IDENTIFIER ASN.1 type from + [ASN.1]. + +3.3.27. Other Mailbox + + A value of the Other Mailbox syntax identifies an electronic mailbox, + in a particular named mail system. The LDAP-specific encoding of a + value of this syntax is defined by the following ABNF: + + OtherMailbox = mailbox-type DOLLAR mailbox + mailbox-type = PrintableString + mailbox = IA5String + + The <mailbox-type> rule represents the type of mail system in which + the mailbox resides (for example, "MCIMail"), and <mailbox> is the + actual mailbox in the mail system described by <mailbox-type>. The + <PrintableString> and <IA5String> rules are defined in Section 3.2. + The <DOLLAR> rule is defined in [RFC4512]. + + The LDAP definition for the Other Mailbox syntax is: + + ( 1.3.6.1.4.1.1466.115.121.1.39 DESC 'Other Mailbox' ) + + The ASN.1 type corresponding to the Other Mailbox syntax is defined + as follows, assuming EXPLICIT TAGS: + + OtherMailbox ::= SEQUENCE { + mailboxType PrintableString, + mailbox IA5String + } + +3.3.28. Postal Address + + A value of the Postal Address syntax is a sequence of strings of one + or more arbitrary UCS characters, which form an address in a physical + mail system. + + The LDAP-specific encoding of a value of this syntax is defined by + the following ABNF: + + + + + + + + + + +Legg Standards Track [Page 20] + +RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 + + + PostalAddress = line *( DOLLAR line ) + line = 1*line-char + line-char = %x00-23 + / (%x5C "24") ; escaped "$" + / %x25-5B + / (%x5C "5C") ; escaped "\" + / %x5D-7F + / UTFMB + + Each character string (i.e., <line>) of a postal address value is + encoded as a UTF-8 [RFC3629] string, except that "\" and "$" + characters, if they occur in the string, are escaped by a "\" + character followed by the two hexadecimal digit code for the + character. The <DOLLAR> and <UTFMB> rules are defined in [RFC4512]. + + Many servers limit the postal address to no more than six lines of no + more than thirty characters each. + + Example: + 1234 Main St.$Anytown, CA 12345$USA + \241,000,000 Sweepstakes$PO Box 1000000$Anytown, CA 12345$USA + + The LDAP definition for the Postal Address syntax is: + + ( 1.3.6.1.4.1.1466.115.121.1.41 DESC 'Postal Address' ) + + This syntax corresponds to the PostalAddress ASN.1 type from [X.520]; + that is + + PostalAddress ::= SEQUENCE SIZE(1..ub-postal-line) OF + DirectoryString { ub-postal-string } + + The values of ub-postal-line and ub-postal-string (both integers) are + implementation defined. Non-normative definitions appear in [X.520]. + +3.3.29. Printable String + + A value of the Printable String syntax is a string of one or more + latin alphabetic, numeric, and selected punctuation characters as + specified by the <PrintableCharacter> rule in Section 3.2. + + The LDAP-specific encoding of a value of this syntax is the + unconverted string of characters, which conforms to the + <PrintableString> rule in Section 3.2. + + Example: + This is a PrintableString. + + + + +Legg Standards Track [Page 21] + +RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 + + + The LDAP definition for the PrintableString syntax is: + + ( 1.3.6.1.4.1.1466.115.121.1.44 DESC 'Printable String' ) + + This syntax corresponds to the PrintableString ASN.1 type from + [ASN.1]. + +3.3.30. Substring Assertion + + A value of the Substring Assertion syntax is a sequence of zero, one, + or more character substrings used as an argument for substring + extensible matching of character string attribute values; i.e., as + the matchValue of a MatchingRuleAssertion [RFC4511]. Each substring + is a string of one or more arbitrary characters from the Universal + Character Set (UCS) [UCS]. A zero-length substring is not permitted. + + The LDAP-specific encoding of a value of this syntax is defined by + the following ABNF: + + SubstringAssertion = [ initial ] any [ final ] + + initial = substring + any = ASTERISK *(substring ASTERISK) + final = substring + ASTERISK = %x2A ; asterisk ("*") + + substring = 1*substring-character + substring-character = %x00-29 + / (%x5C "2A") ; escaped "*" + / %x2B-5B + / (%x5C "5C") ; escaped "\" + / %x5D-7F + / UTFMB + + Each <substring> of a Substring Assertion value is encoded as a UTF-8 + [RFC3629] string, except that "\" and "*" characters, if they occur + in the substring, are escaped by a "\" character followed by the two + hexadecimal digit code for the character. + + The Substring Assertion syntax is used only as the syntax of + assertion values in the extensible match. It is not used as an + attribute syntax, or in the SubstringFilter [RFC4511]. + + The LDAP definition for the Substring Assertion syntax is: + + ( 1.3.6.1.4.1.1466.115.121.1.58 DESC 'Substring Assertion' ) + + + + + +Legg Standards Track [Page 22] + +RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 + + + This syntax corresponds to the SubstringAssertion ASN.1 type from + [X.520]. + +3.3.31. Telephone Number + + A value of the Telephone Number syntax is a string of printable + characters that complies with the internationally agreed format for + representing international telephone numbers [E.123]. + + The LDAP-specific encoding of a value of this syntax is the + unconverted string of characters, which conforms to the + <PrintableString> rule in Section 3.2. + + Examples: + +1 512 315 0280 + +1-512-315-0280 + +61 3 9896 7830 + + The LDAP definition for the Telephone Number syntax is: + + ( 1.3.6.1.4.1.1466.115.121.1.50 DESC 'Telephone Number' ) + + The Telephone Number syntax corresponds to the following ASN.1 type + from [X.520]: + + PrintableString (SIZE(1..ub-telephone-number)) + + The value of ub-telephone-number (an integer) is implementation + defined. A non-normative definition appears in [X.520]. + +3.3.32. Teletex Terminal Identifier + + A value of this syntax specifies the identifier and (optionally) + parameters of a teletex terminal. + + The LDAP-specific encoding of a value of this syntax is defined by + the following ABNF: + + teletex-id = ttx-term *(DOLLAR ttx-param) + ttx-term = PrintableString ; terminal identifier + ttx-param = ttx-key COLON ttx-value ; parameter + ttx-key = "graphic" / "control" / "misc" / "page" / "private" + ttx-value = *ttx-value-octet + + ttx-value-octet = %x00-23 + / (%x5C "24") ; escaped "$" + / %x25-5B + / (%x5C "5C") ; escaped "\" + + + +Legg Standards Track [Page 23] + +RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 + + + / %x5D-FF + + The <PrintableString> and <COLON> rules are defined in Section 3.2. + The <DOLLAR> rule is defined in [RFC4512]. + + The LDAP definition for the Teletex Terminal Identifier syntax is: + + ( 1.3.6.1.4.1.1466.115.121.1.51 + DESC 'Teletex Terminal Identifier' ) + + This syntax corresponds to the TeletexTerminalIdentifier ASN.1 type + from [X.520]. + +3.3.33. Telex Number + + A value of the Telex Number syntax specifies the telex number, + country code, and answerback code of a telex terminal. + + The LDAP-specific encoding of a value of this syntax is defined by + the following ABNF: + + telex-number = actual-number DOLLAR country-code + DOLLAR answerback + actual-number = PrintableString + country-code = PrintableString + answerback = PrintableString + + The <PrintableString> rule is defined in Section 3.2. The <DOLLAR> + rule is defined in [RFC4512]. + + The LDAP definition for the Telex Number syntax is: + + ( 1.3.6.1.4.1.1466.115.121.1.52 DESC 'Telex Number' ) + + This syntax corresponds to the TelexNumber ASN.1 type from [X.520]. + +3.3.34. UTC Time + + A value of the UTC Time syntax is a character string representing a + date and time to a precision of one minute or one second. The year + is given as a two-digit number. The LDAP-specific encoding of a + value of this syntax follows the format defined in [ASN.1] for the + UTCTime type and is described by the following ABNF: + + UTCTime = year month day hour minute [ second ] + [ u-time-zone ] + u-time-zone = %x5A ; "Z" + / u-differential + + + +Legg Standards Track [Page 24] + +RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 + + + u-differential = ( MINUS / PLUS ) hour minute + + The <year>, <month>, <day>, <hour>, <minute>, <second>, and <MINUS> + rules are defined in Section 3.3.13. The <PLUS> rule is defined in + [RFC4512]. + + The above ABNF allows character strings that do not represent valid + dates (in the Gregorian calendar) and/or valid times. Such character + strings SHOULD be considered invalid for this syntax. + + The time value represents coordinated universal time if the "Z" form + of <u-time-zone> is used; otherwise, the value represents a local + time. In the latter case, if <u-differential> is provided, then + coordinated universal time can be calculated by subtracting the + differential from the local time. The <u-time-zone> SHOULD be + present in time values, and the "Z" form of <u-time-zone> SHOULD be + used in preference to <u-differential>. + + The LDAP definition for the UTC Time syntax is: + + ( 1.3.6.1.4.1.1466.115.121.1.53 DESC 'UTC Time' ) + + Note: This syntax is deprecated in favor of the Generalized Time + syntax. + + The UTC Time syntax corresponds to the UTCTime ASN.1 type from + [ASN.1]. + +4. Matching Rules + + Matching rules are used by directory implementations to compare + attribute values against assertion values when performing Search and + Compare operations [RFC4511]. They are also used when comparing a + purported distinguished name [RFC4512] with the name of an entry. + When modifying entries, matching rules are used to identify values to + be deleted and to prevent an attribute from containing two equal + values. + + Matching rules that are required for directory operation, or that are + in common use, are specified in this section. + +4.1. General Considerations + + A matching rule is applied to attribute values through an + AttributeValueAssertion or MatchingRuleAssertion [RFC4511]. The + conditions under which an AttributeValueAssertion or + MatchingRuleAssertion evaluates to Undefined are specified elsewhere + [RFC4511]. If an assertion is not Undefined, then the result of the + + + +Legg Standards Track [Page 25] + +RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 + + + assertion is the result of applying the selected matching rule. A + matching rule evaluates to TRUE, and in some cases Undefined, as + specified in the description of the matching rule; otherwise, it + evaluates to FALSE. + + Each assertion contains an assertion value. The definition of each + matching rule specifies the syntax for the assertion value. The + syntax of the assertion value is typically, but not necessarily, the + same as the syntax of the attribute values to which the matching rule + may be applied. Note that an AssertionValue in a SubstringFilter + [RFC4511] conforms to the assertion syntax of the equality matching + rule for the attribute type rather than to the assertion syntax of + the substrings matching rule for the attribute type. Conceptually, + the entire SubstringFilter is converted into an assertion value of + the substrings matching rule prior to applying the rule. + + The definition of each matching rule indicates the attribute syntaxes + to which the rule may be applied, by specifying conditions the + corresponding ASN.1 type of a candidate attribute syntax must + satisfy. These conditions are also satisfied if the corresponding + ASN.1 type is a tagged or constrained derivative of the ASN.1 type + explicitly mentioned in the rule description (i.e., ASN.1 tags and + constraints are ignored in checking applicability), or is an + alternative reference notation for the explicitly mentioned type. + Each rule description lists, as examples of applicable attribute + syntaxes, the complete list of the syntaxes defined in this document + to which the matching rule applies. A matching rule may be + applicable to additional syntaxes defined in other documents if those + syntaxes satisfy the conditions on the corresponding ASN.1 type. + + The description of each matching rule indicates whether the rule is + suitable for use as the equality matching rule (EQUALITY), ordering + matching rule (ORDERING), or substrings matching rule (SUBSTR) in an + attribute type definition [RFC4512]. + + Each matching rule is uniquely identified with an object identifier. + The definition of a matching rule should not subsequently be changed. + If a change is desirable, then a new matching rule with a different + object identifier should be defined instead. + + Servers MAY implement the wordMatch and keywordMatch matching rules, + but they SHOULD implement the other matching rules in Section 4.2. + Servers MAY implement additional matching rules. + + Servers that implement the extensibleMatch filter SHOULD allow the + matching rules listed in Section 4.2 to be used in the + extensibleMatch filter and SHOULD allow matching rules to be used + with all attribute types known to the server, where the assertion + + + +Legg Standards Track [Page 26] + +RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 + + + syntax of the matching rule is the same as the value syntax of the + attribute. + + Servers MUST publish, in the matchingRules attribute, the definitions + of matching rules referenced by values of the attributeTypes and + matchingRuleUse attributes in the same subschema entry. Other + unreferenced matching rules MAY be published in the matchingRules + attribute. + + If the server supports the extensibleMatch filter, then the server + MAY use the matchingRuleUse attribute to indicate the applicability + (in an extensibleMatch filter) of selected matching rules to + nominated attribute types. + +4.2. Matching Rule Definitions + + Nominated character strings in assertion and attribute values are + prepared according to the string preparation algorithms [RFC4518] for + LDAP when evaluating the following matching rules: + + numericStringMatch, + numericStringSubstringsMatch, + caseExactMatch, + caseExactOrderingMatch, + caseExactSubstringsMatch, + caseExactIA5Match, + caseIgnoreIA5Match, + caseIgnoreIA5SubstringsMatch, + caseIgnoreListMatch, + caseIgnoreListSubstringsMatch, + caseIgnoreMatch, + caseIgnoreOrderingMatch, + caseIgnoreSubstringsMatch, + directoryStringFirstComponentMatch, + telephoneNumberMatch, + telephoneNumberSubstringsMatch and + wordMatch. + + The Transcode, Normalize, Prohibit, and Check bidi steps are the same + for each of the matching rules. However, the Map and Insignificant + Character Handling steps depend on the specific rule, as detailed in + the description of these matching rules in the sections that follow. + +4.2.1. bitStringMatch + + The bitStringMatch rule compares an assertion value of the Bit String + syntax to an attribute value of a syntax (e.g., the Bit String + syntax) whose corresponding ASN.1 type is BIT STRING. + + + +Legg Standards Track [Page 27] + +RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 + + + If the corresponding ASN.1 type of the attribute syntax does not have + a named bit list [ASN.1] (which is the case for the Bit String + syntax), then the rule evaluates to TRUE if and only if the attribute + value has the same number of bits as the assertion value and the bits + match on a bitwise basis. + + If the corresponding ASN.1 type does have a named bit list, then + bitStringMatch operates as above, except that trailing zero bits in + the attribute and assertion values are treated as absent. + + The LDAP definition for the bitStringMatch rule is: + + ( 2.5.13.16 NAME 'bitStringMatch' + SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 ) + + The bitStringMatch rule is an equality matching rule. + +4.2.2. booleanMatch + + The booleanMatch rule compares an assertion value of the Boolean + syntax to an attribute value of a syntax (e.g., the Boolean syntax) + whose corresponding ASN.1 type is BOOLEAN. + + The rule evaluates to TRUE if and only if the attribute value and the + assertion value are both TRUE or both FALSE. + + The LDAP definition for the booleanMatch rule is: + + ( 2.5.13.13 NAME 'booleanMatch' + SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 ) + + The booleanMatch rule is an equality matching rule. + +4.2.3. caseExactIA5Match + + The caseExactIA5Match rule compares an assertion value of the IA5 + String syntax to an attribute value of a syntax (e.g., the IA5 String + syntax) whose corresponding ASN.1 type is IA5String. + + The rule evaluates to TRUE if and only if the prepared attribute + value character string and the prepared assertion value character + string have the same number of characters and corresponding + characters have the same code point. + + In preparing the attribute value and assertion value for comparison, + characters are not case folded in the Map preparation step, and only + Insignificant Space Handling is applied in the Insignificant + Character Handling step. + + + +Legg Standards Track [Page 28] + +RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 + + + The LDAP definition for the caseExactIA5Match rule is: + + ( 1.3.6.1.4.1.1466.109.114.1 NAME 'caseExactIA5Match' + SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) + + The caseExactIA5Match rule is an equality matching rule. + +4.2.4. caseExactMatch + + The caseExactMatch rule compares an assertion value of the Directory + String syntax to an attribute value of a syntax (e.g., the Directory + String, Printable String, Country String, or Telephone Number syntax) + whose corresponding ASN.1 type is DirectoryString or one of the + alternative string types of DirectoryString, such as PrintableString + (the other alternatives do not correspond to any syntax defined in + this document). + + The rule evaluates to TRUE if and only if the prepared attribute + value character string and the prepared assertion value character + string have the same number of characters and corresponding + characters have the same code point. + + In preparing the attribute value and assertion value for comparison, + characters are not case folded in the Map preparation step, and only + Insignificant Space Handling is applied in the Insignificant + Character Handling step. + + The LDAP definition for the caseExactMatch rule is: + + ( 2.5.13.5 NAME 'caseExactMatch' + SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) + + The caseExactMatch rule is an equality matching rule. + +4.2.5. caseExactOrderingMatch + + The caseExactOrderingMatch rule compares an assertion value of the + Directory String syntax to an attribute value of a syntax (e.g., the + Directory String, Printable String, Country String, or Telephone + Number syntax) whose corresponding ASN.1 type is DirectoryString or + one of its alternative string types. + + The rule evaluates to TRUE if and only if, in the code point + collation order, the prepared attribute value character string + appears earlier than the prepared assertion value character string; + i.e., the attribute value is "less than" the assertion value. + + + + + +Legg Standards Track [Page 29] + +RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 + + + In preparing the attribute value and assertion value for comparison, + characters are not case folded in the Map preparation step, and only + Insignificant Space Handling is applied in the Insignificant + Character Handling step. + + The LDAP definition for the caseExactOrderingMatch rule is: + + ( 2.5.13.6 NAME 'caseExactOrderingMatch' + SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) + + The caseExactOrderingMatch rule is an ordering matching rule. + +4.2.6. caseExactSubstringsMatch + + The caseExactSubstringsMatch rule compares an assertion value of the + Substring Assertion syntax to an attribute value of a syntax (e.g., + the Directory String, Printable String, Country String, or Telephone + Number syntax) whose corresponding ASN.1 type is DirectoryString or + one of its alternative string types. + + The rule evaluates to TRUE if and only if (1) the prepared substrings + of the assertion value match disjoint portions of the prepared + attribute value character string in the order of the substrings in + the assertion value, (2) an <initial> substring, if present, matches + the beginning of the prepared attribute value character string, and + (3) a <final> substring, if present, matches the end of the prepared + attribute value character string. A prepared substring matches a + portion of the prepared attribute value character string if + corresponding characters have the same code point. + + In preparing the attribute value and assertion value substrings for + comparison, characters are not case folded in the Map preparation + step, and only Insignificant Space Handling is applied in the + Insignificant Character Handling step. + + The LDAP definition for the caseExactSubstringsMatch rule is: + + ( 2.5.13.7 NAME 'caseExactSubstringsMatch' + SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 ) + + The caseExactSubstringsMatch rule is a substrings matching rule. + +4.2.7. caseIgnoreIA5Match + + The caseIgnoreIA5Match rule compares an assertion value of the IA5 + String syntax to an attribute value of a syntax (e.g., the IA5 String + syntax) whose corresponding ASN.1 type is IA5String. + + + + +Legg Standards Track [Page 30] + +RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 + + + The rule evaluates to TRUE if and only if the prepared attribute + value character string and the prepared assertion value character + string have the same number of characters and corresponding + characters have the same code point. + + In preparing the attribute value and assertion value for comparison, + characters are case folded in the Map preparation step, and only + Insignificant Space Handling is applied in the Insignificant + Character Handling step. + + The LDAP definition for the caseIgnoreIA5Match rule is: + + ( 1.3.6.1.4.1.1466.109.114.2 NAME 'caseIgnoreIA5Match' + SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) + + The caseIgnoreIA5Match rule is an equality matching rule. + +4.2.8. caseIgnoreIA5SubstringsMatch + + The caseIgnoreIA5SubstringsMatch rule compares an assertion value of + the Substring Assertion syntax to an attribute value of a syntax + (e.g., the IA5 String syntax) whose corresponding ASN.1 type is + IA5String. + + The rule evaluates to TRUE if and only if (1) the prepared substrings + of the assertion value match disjoint portions of the prepared + attribute value character string in the order of the substrings in + the assertion value, (2) an <initial> substring, if present, matches + the beginning of the prepared attribute value character string, and + (3) a <final> substring, if present, matches the end of the prepared + attribute value character string. A prepared substring matches a + portion of the prepared attribute value character string if + corresponding characters have the same code point. + + In preparing the attribute value and assertion value substrings for + comparison, characters are case folded in the Map preparation step, + and only Insignificant Space Handling is applied in the Insignificant + Character Handling step. + + ( 1.3.6.1.4.1.1466.109.114.3 NAME 'caseIgnoreIA5SubstringsMatch' + SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 ) + + The caseIgnoreIA5SubstringsMatch rule is a substrings matching rule. + +4.2.9. caseIgnoreListMatch + + The caseIgnoreListMatch rule compares an assertion value that is a + sequence of strings to an attribute value of a syntax (e.g., the + + + +Legg Standards Track [Page 31] + +RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 + + + Postal Address syntax) whose corresponding ASN.1 type is a SEQUENCE + OF the DirectoryString ASN.1 type. + + The rule evaluates to TRUE if and only if the attribute value and the + assertion value have the same number of strings and corresponding + strings (by position) match according to the caseIgnoreMatch matching + rule. + + In [X.520], the assertion syntax for this matching rule is defined to + be: + + SEQUENCE OF DirectoryString {ub-match} + + That is, it is different from the corresponding type for the Postal + Address syntax. The choice of the Postal Address syntax for the + assertion syntax of the caseIgnoreListMatch in LDAP should not be + seen as limiting the matching rule to apply only to attributes with + the Postal Address syntax. + + The LDAP definition for the caseIgnoreListMatch rule is: + + ( 2.5.13.11 NAME 'caseIgnoreListMatch' + SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 ) + + The caseIgnoreListMatch rule is an equality matching rule. + +4.2.10. caseIgnoreListSubstringsMatch + + The caseIgnoreListSubstringsMatch rule compares an assertion value of + the Substring Assertion syntax to an attribute value of a syntax + (e.g., the Postal Address syntax) whose corresponding ASN.1 type is a + SEQUENCE OF the DirectoryString ASN.1 type. + + The rule evaluates to TRUE if and only if the assertion value + matches, per the caseIgnoreSubstringsMatch rule, the character string + formed by concatenating the strings of the attribute value, except + that none of the <initial>, <any>, or <final> substrings of the + assertion value are considered to match a substring of the + concatenated string which spans more than one of the original strings + of the attribute value. + + Note that, in terms of the LDAP-specific encoding of the Postal + Address syntax, the concatenated string omits the <DOLLAR> line + separator and the escaping of "\" and "$" characters. + + The LDAP definition for the caseIgnoreListSubstringsMatch rule is: + + ( 2.5.13.12 NAME 'caseIgnoreListSubstringsMatch' + + + +Legg Standards Track [Page 32] + +RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 + + + SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 ) + + The caseIgnoreListSubstringsMatch rule is a substrings matching rule. + +4.2.11. caseIgnoreMatch + + The caseIgnoreMatch rule compares an assertion value of the Directory + String syntax to an attribute value of a syntax (e.g., the Directory + String, Printable String, Country String, or Telephone Number syntax) + whose corresponding ASN.1 type is DirectoryString or one of its + alternative string types. + + The rule evaluates to TRUE if and only if the prepared attribute + value character string and the prepared assertion value character + string have the same number of characters and corresponding + characters have the same code point. + + In preparing the attribute value and assertion value for comparison, + characters are case folded in the Map preparation step, and only + Insignificant Space Handling is applied in the Insignificant + Character Handling step. + + The LDAP definition for the caseIgnoreMatch rule is: + + ( 2.5.13.2 NAME 'caseIgnoreMatch' + SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) + + The caseIgnoreMatch rule is an equality matching rule. + +4.2.12. caseIgnoreOrderingMatch + + The caseIgnoreOrderingMatch rule compares an assertion value of the + Directory String syntax to an attribute value of a syntax (e.g., the + Directory String, Printable String, Country String, or Telephone + Number syntax) whose corresponding ASN.1 type is DirectoryString or + one of its alternative string types. + + The rule evaluates to TRUE if and only if, in the code point + collation order, the prepared attribute value character string + appears earlier than the prepared assertion value character string; + i.e., the attribute value is "less than" the assertion value. + + In preparing the attribute value and assertion value for comparison, + characters are case folded in the Map preparation step, and only + Insignificant Space Handling is applied in the Insignificant + Character Handling step. + + The LDAP definition for the caseIgnoreOrderingMatch rule is: + + + +Legg Standards Track [Page 33] + +RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 + + + ( 2.5.13.3 NAME 'caseIgnoreOrderingMatch' + SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) + + The caseIgnoreOrderingMatch rule is an ordering matching rule. + +4.2.13. caseIgnoreSubstringsMatch + + The caseIgnoreSubstringsMatch rule compares an assertion value of the + Substring Assertion syntax to an attribute value of a syntax (e.g., + the Directory String, Printable String, Country String, or Telephone + Number syntax) whose corresponding ASN.1 type is DirectoryString or + one of its alternative string types. + + The rule evaluates to TRUE if and only if (1) the prepared substrings + of the assertion value match disjoint portions of the prepared + attribute value character string in the order of the substrings in + the assertion value, (2) an <initial> substring, if present, matches + the beginning of the prepared attribute value character string, and + (3) a <final> substring, if present, matches the end of the prepared + attribute value character string. A prepared substring matches a + portion of the prepared attribute value character string if + corresponding characters have the same code point. + + In preparing the attribute value and assertion value substrings for + comparison, characters are case folded in the Map preparation step, + and only Insignificant Space Handling is applied in the Insignificant + Character Handling step. + + The LDAP definition for the caseIgnoreSubstringsMatch rule is: + + ( 2.5.13.4 NAME 'caseIgnoreSubstringsMatch' + SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 ) + + The caseIgnoreSubstringsMatch rule is a substrings matching rule. + +4.2.14. directoryStringFirstComponentMatch + + The directoryStringFirstComponentMatch rule compares an assertion + value of the Directory String syntax to an attribute value of a + syntax whose corresponding ASN.1 type is a SEQUENCE with a mandatory + first component of the DirectoryString ASN.1 type. + + Note that the assertion syntax of this matching rule differs from the + attribute syntax of attributes for which this is the equality + matching rule. + + + + + + +Legg Standards Track [Page 34] + +RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 + + + The rule evaluates to TRUE if and only if the assertion value matches + the first component of the attribute value using the rules of + caseIgnoreMatch. + + The LDAP definition for the directoryStringFirstComponentMatch + matching rule is: + + ( 2.5.13.31 NAME 'directoryStringFirstComponentMatch' + SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) + + The directoryStringFirstComponentMatch rule is an equality matching + rule. When using directoryStringFirstComponentMatch to compare two + attribute values (of an applicable syntax), an assertion value must + first be derived from one of the attribute values. An assertion + value can be derived from an attribute value by taking the first + component of that attribute value. + +4.2.15. distinguishedNameMatch + + The distinguishedNameMatch rule compares an assertion value of the DN + syntax to an attribute value of a syntax (e.g., the DN syntax) whose + corresponding ASN.1 type is DistinguishedName. + + The rule evaluates to TRUE if and only if the attribute value and the + assertion value have the same number of relative distinguished names + and corresponding relative distinguished names (by position) are the + same. A relative distinguished name (RDN) of the assertion value is + the same as an RDN of the attribute value if and only if they have + the same number of attribute value assertions and each attribute + value assertion (AVA) of the first RDN is the same as the AVA of the + second RDN with the same attribute type. The order of the AVAs is + not significant. Also note that a particular attribute type may + appear in at most one AVA in an RDN. Two AVAs with the same + attribute type are the same if their values are equal according to + the equality matching rule of the attribute type. If one or more of + the AVA comparisons evaluate to Undefined and the remaining AVA + comparisons return TRUE then the distinguishedNameMatch rule + evaluates to Undefined. + + The LDAP definition for the distinguishedNameMatch rule is: + + ( 2.5.13.1 NAME 'distinguishedNameMatch' + SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 ) + + The distinguishedNameMatch rule is an equality matching rule. + + + + + + +Legg Standards Track [Page 35] + +RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 + + +4.2.16. generalizedTimeMatch + + The generalizedTimeMatch rule compares an assertion value of the + Generalized Time syntax to an attribute value of a syntax (e.g., the + Generalized Time syntax) whose corresponding ASN.1 type is + GeneralizedTime. + + The rule evaluates to TRUE if and only if the attribute value + represents the same universal coordinated time as the assertion + value. If a time is specified with the minutes or seconds absent, + then the number of minutes or seconds (respectively) is assumed to be + zero. + + The LDAP definition for the generalizedTimeMatch rule is: + + ( 2.5.13.27 NAME 'generalizedTimeMatch' + SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 ) + + The generalizedTimeMatch rule is an equality matching rule. + +4.2.17. generalizedTimeOrderingMatch + + The generalizedTimeOrderingMatch rule compares the time ordering of + an assertion value of the Generalized Time syntax to an attribute + value of a syntax (e.g., the Generalized Time syntax) whose + corresponding ASN.1 type is GeneralizedTime. + + The rule evaluates to TRUE if and only if the attribute value + represents a universal coordinated time that is earlier than the + universal coordinated time represented by the assertion value. + + The LDAP definition for the generalizedTimeOrderingMatch rule is: + + ( 2.5.13.28 NAME 'generalizedTimeOrderingMatch' + SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 ) + + The generalizedTimeOrderingMatch rule is an ordering matching rule. + +4.2.18. integerFirstComponentMatch + + The integerFirstComponentMatch rule compares an assertion value of + the Integer syntax to an attribute value of a syntax (e.g., the DIT + Structure Rule Description syntax) whose corresponding ASN.1 type is + a SEQUENCE with a mandatory first component of the INTEGER ASN.1 + type. + + + + + + +Legg Standards Track [Page 36] + +RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 + + + Note that the assertion syntax of this matching rule differs from the + attribute syntax of attributes for which this is the equality + matching rule. + + The rule evaluates to TRUE if and only if the assertion value and the + first component of the attribute value are the same integer value. + + The LDAP definition for the integerFirstComponentMatch matching rule + is: + + ( 2.5.13.29 NAME 'integerFirstComponentMatch' + SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 ) + + The integerFirstComponentMatch rule is an equality matching rule. + When using integerFirstComponentMatch to compare two attribute values + (of an applicable syntax), an assertion value must first be derived + from one of the attribute values. An assertion value can be derived + from an attribute value by taking the first component of that + attribute value. + +4.2.19. integerMatch + + The integerMatch rule compares an assertion value of the Integer + syntax to an attribute value of a syntax (e.g., the Integer syntax) + whose corresponding ASN.1 type is INTEGER. + + The rule evaluates to TRUE if and only if the attribute value and the + assertion value are the same integer value. + + The LDAP definition for the integerMatch matching rule is: + + ( 2.5.13.14 NAME 'integerMatch' + SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 ) + + The integerMatch rule is an equality matching rule. + +4.2.20. integerOrderingMatch + + The integerOrderingMatch rule compares an assertion value of the + Integer syntax to an attribute value of a syntax (e.g., the Integer + syntax) whose corresponding ASN.1 type is INTEGER. + + The rule evaluates to TRUE if and only if the integer value of the + attribute value is less than the integer value of the assertion + value. + + The LDAP definition for the integerOrderingMatch matching rule is: + + + + +Legg Standards Track [Page 37] + +RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 + + + ( 2.5.13.15 NAME 'integerOrderingMatch' + SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 ) + + The integerOrderingMatch rule is an ordering matching rule. + +4.2.21. keywordMatch + + The keywordMatch rule compares an assertion value of the Directory + String syntax to an attribute value of a syntax (e.g., the Directory + String syntax) whose corresponding ASN.1 type is DirectoryString. + + The rule evaluates to TRUE if and only if the assertion value + character string matches any keyword in the attribute value. The + identification of keywords in the attribute value and the exactness + of the match are both implementation specific. + + The LDAP definition for the keywordMatch rule is: + + ( 2.5.13.33 NAME 'keywordMatch' + SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) + +4.2.22. numericStringMatch + + The numericStringMatch rule compares an assertion value of the + Numeric String syntax to an attribute value of a syntax (e.g., the + Numeric String syntax) whose corresponding ASN.1 type is + NumericString. + + The rule evaluates to TRUE if and only if the prepared attribute + value character string and the prepared assertion value character + string have the same number of characters and corresponding + characters have the same code point. + + In preparing the attribute value and assertion value for comparison, + characters are not case folded in the Map preparation step, and only + numericString Insignificant Character Handling is applied in the + Insignificant Character Handling step. + + The LDAP definition for the numericStringMatch matching rule is: + + ( 2.5.13.8 NAME 'numericStringMatch' + SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 ) + + The numericStringMatch rule is an equality matching rule. + + + + + + + +Legg Standards Track [Page 38] + +RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 + + +4.2.23. numericStringOrderingMatch + + The numericStringOrderingMatch rule compares an assertion value of + the Numeric String syntax to an attribute value of a syntax (e.g., + the Numeric String syntax) whose corresponding ASN.1 type is + NumericString. + + The rule evaluates to TRUE if and only if, in the code point + collation order, the prepared attribute value character string + appears earlier than the prepared assertion value character string; + i.e., the attribute value is "less than" the assertion value. + + In preparing the attribute value and assertion value for comparison, + characters are not case folded in the Map preparation step, and only + numericString Insignificant Character Handling is applied in the + Insignificant Character Handling step. + + The rule is identical to the caseIgnoreOrderingMatch rule except that + all space characters are skipped during comparison (case is + irrelevant as the characters are numeric). + + The LDAP definition for the numericStringOrderingMatch matching rule + is: + + ( 2.5.13.9 NAME 'numericStringOrderingMatch' + SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 ) + + The numericStringOrderingMatch rule is an ordering matching rule. + +4.2.24. numericStringSubstringsMatch + + The numericStringSubstringsMatch rule compares an assertion value of + the Substring Assertion syntax to an attribute value of a syntax + (e.g., the Numeric String syntax) whose corresponding ASN.1 type is + NumericString. + + The rule evaluates to TRUE if and only if (1) the prepared substrings + of the assertion value match disjoint portions of the prepared + attribute value character string in the order of the substrings in + the assertion value, (2) an <initial> substring, if present, matches + the beginning of the prepared attribute value character string, and + (3) a <final> substring, if present, matches the end of the prepared + attribute value character string. A prepared substring matches a + portion of the prepared attribute value character string if + corresponding characters have the same code point. + + In preparing the attribute value and assertion value for comparison, + characters are not case folded in the Map preparation step, and only + + + +Legg Standards Track [Page 39] + +RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 + + + numericString Insignificant Character Handling is applied in the + Insignificant Character Handling step. + + The LDAP definition for the numericStringSubstringsMatch matching + rule is: + + ( 2.5.13.10 NAME 'numericStringSubstringsMatch' + SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 ) + + The numericStringSubstringsMatch rule is a substrings matching rule. + +4.2.25. objectIdentifierFirstComponentMatch + + The objectIdentifierFirstComponentMatch rule compares an assertion + value of the OID syntax to an attribute value of a syntax (e.g., the + Attribute Type Description, DIT Content Rule Description, LDAP Syntax + Description, Matching Rule Description, Matching Rule Use + Description, Name Form Description, or Object Class Description + syntax) whose corresponding ASN.1 type is a SEQUENCE with a mandatory + first component of the OBJECT IDENTIFIER ASN.1 type. + + Note that the assertion syntax of this matching rule differs from the + attribute syntax of attributes for which this is the equality + matching rule. + + The rule evaluates to TRUE if and only if the assertion value matches + the first component of the attribute value using the rules of + objectIdentifierMatch. + + The LDAP definition for the objectIdentifierFirstComponentMatch + matching rule is: + + ( 2.5.13.30 NAME 'objectIdentifierFirstComponentMatch' + SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 ) + + The objectIdentifierFirstComponentMatch rule is an equality matching + rule. When using objectIdentifierFirstComponentMatch to compare two + attribute values (of an applicable syntax), an assertion value must + first be derived from one of the attribute values. An assertion + value can be derived from an attribute value by taking the first + component of that attribute value. + +4.2.26. objectIdentifierMatch + + The objectIdentifierMatch rule compares an assertion value of the OID + syntax to an attribute value of a syntax (e.g., the OID syntax) whose + corresponding ASN.1 type is OBJECT IDENTIFIER. + + + + +Legg Standards Track [Page 40] + +RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 + + + The rule evaluates to TRUE if and only if the assertion value and the + attribute value represent the same object identifier; that is, the + same sequence of integers, whether represented explicitly in the + <numericoid> form of <oid> or implicitly in the <descr> form (see + [RFC4512]). + + If an LDAP client supplies an assertion value in the <descr> form and + the chosen descriptor is not recognized by the server, then the + objectIdentifierMatch rule evaluates to Undefined. + + The LDAP definition for the objectIdentifierMatch matching rule is: + + ( 2.5.13.0 NAME 'objectIdentifierMatch' + SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 ) + + The objectIdentifierMatch rule is an equality matching rule. + +4.2.27. octetStringMatch + + The octetStringMatch rule compares an assertion value of the Octet + String syntax to an attribute value of a syntax (e.g., the Octet + String or JPEG syntax) whose corresponding ASN.1 type is the OCTET + STRING ASN.1 type. + + The rule evaluates to TRUE if and only if the attribute value and the + assertion value are the same length and corresponding octets (by + position) are the same. + + The LDAP definition for the octetStringMatch matching rule is: + + ( 2.5.13.17 NAME 'octetStringMatch' + SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 ) + + The octetStringMatch rule is an equality matching rule. + +4.2.28. octetStringOrderingMatch + + The octetStringOrderingMatch rule compares an assertion value of the + Octet String syntax to an attribute value of a syntax (e.g., the + Octet String or JPEG syntax) whose corresponding ASN.1 type is the + OCTET STRING ASN.1 type. + + The rule evaluates to TRUE if and only if the attribute value appears + earlier in the collation order than the assertion value. The rule + compares octet strings from the first octet to the last octet, and + from the most significant bit to the least significant bit within the + octet. The first occurrence of a different bit determines the + ordering of the strings. A zero bit precedes a one bit. If the + + + +Legg Standards Track [Page 41] + +RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 + + + strings contain different numbers of octets but the longer string is + identical to the shorter string up to the length of the shorter + string, then the shorter string precedes the longer string. + + The LDAP definition for the octetStringOrderingMatch matching rule + is: + + ( 2.5.13.18 NAME 'octetStringOrderingMatch' + SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 ) + + The octetStringOrderingMatch rule is an ordering matching rule. + +4.2.29. telephoneNumberMatch + + The telephoneNumberMatch rule compares an assertion value of the + Telephone Number syntax to an attribute value of a syntax (e.g., the + Telephone Number syntax) whose corresponding ASN.1 type is a + PrintableString representing a telephone number. + + The rule evaluates to TRUE if and only if the prepared attribute + value character string and the prepared assertion value character + string have the same number of characters and corresponding + characters have the same code point. + + In preparing the attribute value and assertion value for comparison, + characters are case folded in the Map preparation step, and only + telephoneNumber Insignificant Character Handling is applied in the + Insignificant Character Handling step. + + The LDAP definition for the telephoneNumberMatch matching rule is: + + ( 2.5.13.20 NAME 'telephoneNumberMatch' + SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 ) + + The telephoneNumberMatch rule is an equality matching rule. + +4.2.30. telephoneNumberSubstringsMatch + + The telephoneNumberSubstringsMatch rule compares an assertion value + of the Substring Assertion syntax to an attribute value of a syntax + (e.g., the Telephone Number syntax) whose corresponding ASN.1 type is + a PrintableString representing a telephone number. + + The rule evaluates to TRUE if and only if (1) the prepared substrings + of the assertion value match disjoint portions of the prepared + attribute value character string in the order of the substrings in + the assertion value, (2) an <initial> substring, if present, matches + the beginning of the prepared attribute value character string, and + + + +Legg Standards Track [Page 42] + +RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 + + + (3) a <final> substring, if present, matches the end of the prepared + attribute value character string. A prepared substring matches a + portion of the prepared attribute value character string if + corresponding characters have the same code point. + + In preparing the attribute value and assertion value substrings for + comparison, characters are case folded in the Map preparation step, + and only telephoneNumber Insignificant Character Handling is applied + in the Insignificant Character Handling step. + + The LDAP definition for the telephoneNumberSubstringsMatch matching + rule is: + + ( 2.5.13.21 NAME 'telephoneNumberSubstringsMatch' + SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 ) + + The telephoneNumberSubstringsMatch rule is a substrings matching + rule. + +4.2.31. uniqueMemberMatch + + The uniqueMemberMatch rule compares an assertion value of the Name + And Optional UID syntax to an attribute value of a syntax (e.g., the + Name And Optional UID syntax) whose corresponding ASN.1 type is + NameAndOptionalUID. + + The rule evaluates to TRUE if and only if the <distinguishedName> + components of the assertion value and attribute value match according + to the distinguishedNameMatch rule and either, (1) the <BitString> + component is absent from both the attribute value and assertion + value, or (2) the <BitString> component is present in both the + attribute value and the assertion value and the <BitString> component + of the assertion value matches the <BitString> component of the + attribute value according to the bitStringMatch rule. + + Note that this matching rule has been altered from its description in + X.520 [X.520] in order to make the matching rule commutative. Server + implementors should consider using the original X.520 semantics + (where the matching was less exact) for approximate matching of + attributes with uniqueMemberMatch as the equality matching rule. + + The LDAP definition for the uniqueMemberMatch matching rule is: + + ( 2.5.13.23 NAME 'uniqueMemberMatch' + SYNTAX 1.3.6.1.4.1.1466.115.121.1.34 ) + + The uniqueMemberMatch rule is an equality matching rule. + + + + +Legg Standards Track [Page 43] + +RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 + + +4.2.32. wordMatch + + The wordMatch rule compares an assertion value of the Directory + String syntax to an attribute value of a syntax (e.g., the Directory + String syntax) whose corresponding ASN.1 type is DirectoryString. + + The rule evaluates to TRUE if and only if the assertion value word + matches, according to the semantics of caseIgnoreMatch, any word in + the attribute value. The precise definition of a word is + implementation specific. + + The LDAP definition for the wordMatch rule is: + + ( 2.5.13.32 NAME 'wordMatch' + SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) + +5. Security Considerations + + In general, the LDAP-specific encodings for syntaxes defined in this + document do not define canonical encodings. That is, a + transformation from an LDAP-specific encoding into some other + encoding (e.g., BER) and back into the LDAP-specific encoding will + not necessarily reproduce exactly the original octets of the LDAP- + specific encoding. Therefore, an LDAP-specific encoding should not + be used where a canonical encoding is required. + + Furthermore, the LDAP-specific encodings do not necessarily enable an + alternative encoding of values of the Directory String and DN + syntaxes to be reconstructed; e.g., a transformation from a + Distinguished Encoding Rules (DER) [BER] encoding to an LDAP-specific + encoding and back to a DER encoding may not reproduce the original + DER encoding. Therefore, LDAP-specific encodings should not be used + where reversibility to DER is needed; e.g., for the verification of + digital signatures. Instead, DER or a DER-reversible encoding should + be used. + + When interpreting security-sensitive fields (in particular, fields + used to grant or deny access), implementations MUST ensure that any + matching rule comparisons are done on the underlying abstract value, + regardless of the particular encoding used. + +6. Acknowledgements + + This document is primarily a revision of RFC 2252 by M. Wahl, A. + Coulbeck, T. Howes, and S. Kille. RFC 2252 was a product of the IETF + ASID Working Group. + + + + + +Legg Standards Track [Page 44] + +RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 + + + This document is based on input from the IETF LDAPBIS working group. + The author would like to thank Kathy Dally for editing the early + drafts of this document, and Jim Sermersheim and Kurt Zeilenga for + their significant contributions to this revision. + +7. IANA Considerations + + The Internet Assigned Numbers Authority (IANA) has updated the LDAP + descriptors registry [BCP64] as indicated by the following templates: + + Subject: Request for LDAP Descriptor Registration Update + Descriptor (short name): see comment + Object Identifier: see comment + Person & email address to contact for further information: + Steven Legg <steven.legg@eb2bcom.com> + Usage: see comment + Specification: RFC 4517 + Author/Change Controller: IESG + + NAME Type OID + ------------------------------------------------------------------ + bitStringMatch M 2.5.13.16 + booleanMatch M 2.5.13.13 + caseExactIA5Match M 1.3.6.1.4.1.1466.109.114.1 + caseExactMatch M 2.5.13.5 + caseExactOrderingMatch M 2.5.13.6 + caseExactSubstringsMatch M 2.5.13.7 + caseIgnoreIA5Match M 1.3.6.1.4.1.1466.109.114.2 + caseIgnoreListMatch M 2.5.13.11 + caseIgnoreListSubstringsMatch M 2.5.13.12 + caseIgnoreMatch M 2.5.13.2 + caseIgnoreOrderingMatch M 2.5.13.3 + caseIgnoreSubstringsMatch M 2.5.13.4 + directoryStringFirstComponentMatch M 2.5.13.31 + distinguishedNameMatch M 2.5.13.1 + generalizedTimeMatch M 2.5.13.27 + generalizedTimeOrderingMatch M 2.5.13.28 + integerFirstComponentMatch M 2.5.13.29 + integerMatch M 2.5.13.14 + integerOrderingMatch M 2.5.13.15 + keywordMatch M 2.5.13.33 + numericStringMatch M 2.5.13.8 + numericStringOrderingMatch M 2.5.13.9 + numericStringSubstringsMatch M 2.5.13.10 + objectIdentifierFirstComponentMatch M 2.5.13.30 + octetStringMatch M 2.5.13.17 + octetStringOrderingMatch M 2.5.13.18 + telephoneNumberMatch M 2.5.13.20 + + + +Legg Standards Track [Page 45] + +RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 + + + telephoneNumberSubstringsMatch M 2.5.13.21 + uniqueMemberMatch M 2.5.13.23 + wordMatch M 2.5.13.32 + + The descriptor for the object identifier 2.5.13.0 was incorrectly + registered as objectIdentifiersMatch (extraneous \`s') in BCP 64. + It has been changed to the following, with a reference to + RFC 4517. + + NAME Type OID + ------------------------------------------------------------------ + objectIdentifierMatch M 2.5.13.0 + + Subject: Request for LDAP Descriptor Registration + Descriptor (short name): caseIgnoreIA5SubstringsMatch + Object Identifier: 1.3.6.1.4.1.1466.109.114.3 + Person & email address to contact for further information: + Steven Legg <steven.legg@eb2bcom.com> + Usage: other (M) + Specification: RFC 4517 + Author/Change Controller: IESG + +8. References + +8.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO + 10646", STD 63, RFC 3629, November 2003. + + [RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax + Specifications: ABNF", RFC 4234, October 2005. + + [RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access Protocol + (LDAP): Technical Specification Road Map", RFC 4510, June + 2006. + + [RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access + Protocol (LDAP): The Protocol", RFC 4511, June 2006. + + [RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol + (LDAP): Directory Information Models", RFC 4512, June + 2006. + + + + + + +Legg Standards Track [Page 46] + +RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 + + + [RFC4514] Zeilenga, K., Ed., "Lightweight Directory Access Protocol + (LDAP): String Representation of Distinguished Names", RFC + 4514, June 2006. + + [RFC4518] Zeilenga, K., "Lightweight Directory Access Protocol + (LDAP): Internationalized String Preparation", RFC 4518, + June 2006. + + [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority (IANA) + Considerations for the Lightweight Directory Access + Protocol (LDAP)", BCP 64, RFC 4520, June 2006. + + [E.123] Notation for national and international telephone numbers, + ITU-T Recommendation E.123, 1988. + + [FAX] Standardization of Group 3 facsimile apparatus for + document transmission - Terminal Equipment and Protocols + for Telematic Services, ITU-T Recommendation T.4, 1993 + + [T.50] International Reference Alphabet (IRA) (Formerly + International Alphabet No. 5 or IA5) Information + Technology - 7-Bit Coded Character Set for Information + Interchange, ITU-T Recommendation T.50, 1992 + + [X.420] ITU-T Recommendation X.420 (1996) | ISO/IEC 10021-7:1997, + Information Technology - Message Handling Systems (MHS): + Interpersonal messaging system + + [X.501] ITU-T Recommendation X.501 (1993) | ISO/IEC 9594-2:1994, + Information Technology - Open Systems Interconnection - + The Directory: Models + + [X.520] ITU-T Recommendation X.520 (1993) | ISO/IEC 9594-6:1994, + Information Technology - Open Systems Interconnection - + The Directory: Selected attribute types + + [ASN.1] ITU-T Recommendation X.680 (07/02) | ISO/IEC 8824-1:2002, + Information technology - Abstract Syntax Notation One + (ASN.1): Specification of basic notation + + [ISO3166] ISO 3166, "Codes for the representation of names of + countries". + + [ISO8601] ISO 8601:2004, "Data elements and interchange formats -- + Information interchange -- Representation of dates and + times". + + + + + +Legg Standards Track [Page 47] + +RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 + + + [UCS] Universal Multiple-Octet Coded Character Set (UCS) - + Architecture and Basic Multilingual Plane, ISO/IEC 10646- + 1: 1993 (with amendments). + + [JPEG] JPEG File Interchange Format (Version 1.02). Eric + Hamilton, C-Cube Microsystems, Milpitas, CA, September 1, + 1992. + +8.2. Informative References + + [RFC4519] Sciberras, A., Ed., "Lightweight Directory Access Protocol + (LDAP): Schema for User Applications", RFC 4519, June + 2006. + + [RFC4523] Zeilenga, K., "Lightweight Directory Access Protocol + (LDAP) Schema Definitions for X.509 Certificates", RFC + 4523, June 2006. + + [X.500] ITU-T Recommendation X.500 (1993) | ISO/IEC 9594-1:1994, + Information Technology - Open Systems Interconnection - + The Directory: Overview of concepts, models and services + + [BER] ITU-T Recommendation X.690 (07/02) | ISO/IEC 8825-1:2002, + Information technology - ASN.1 encoding rules: + Specification of Basic Encoding Rules (BER), Canonical + Encoding Rules (CER) and Distinguished Encoding Rules + (DER) + + + + + + + + + + + + + + + + + + + + + + + + +Legg Standards Track [Page 48] + +RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 + + +Appendix A. Summary of Syntax Object Identifiers + + The following list summarizes the object identifiers assigned to the + syntaxes defined in this document. + + Syntax OBJECT IDENTIFIER + ============================================================== + Attribute Type Description 1.3.6.1.4.1.1466.115.121.1.3 + Bit String 1.3.6.1.4.1.1466.115.121.1.6 + Boolean 1.3.6.1.4.1.1466.115.121.1.7 + Country String 1.3.6.1.4.1.1466.115.121.1.11 + Delivery Method 1.3.6.1.4.1.1466.115.121.1.14 + Directory String 1.3.6.1.4.1.1466.115.121.1.15 + DIT Content Rule Description 1.3.6.1.4.1.1466.115.121.1.16 + DIT Structure Rule Description 1.3.6.1.4.1.1466.115.121.1.17 + DN 1.3.6.1.4.1.1466.115.121.1.12 + Enhanced Guide 1.3.6.1.4.1.1466.115.121.1.21 + Facsimile Telephone Number 1.3.6.1.4.1.1466.115.121.1.22 + Fax 1.3.6.1.4.1.1466.115.121.1.23 + Generalized Time 1.3.6.1.4.1.1466.115.121.1.24 + Guide 1.3.6.1.4.1.1466.115.121.1.25 + IA5 String 1.3.6.1.4.1.1466.115.121.1.26 + Integer 1.3.6.1.4.1.1466.115.121.1.27 + JPEG 1.3.6.1.4.1.1466.115.121.1.28 + LDAP Syntax Description 1.3.6.1.4.1.1466.115.121.1.54 + Matching Rule Description 1.3.6.1.4.1.1466.115.121.1.30 + Matching Rule Use Description 1.3.6.1.4.1.1466.115.121.1.31 + Name And Optional UID 1.3.6.1.4.1.1466.115.121.1.34 + Name Form Description 1.3.6.1.4.1.1466.115.121.1.35 + Numeric String 1.3.6.1.4.1.1466.115.121.1.36 + Object Class Description 1.3.6.1.4.1.1466.115.121.1.37 + Octet String 1.3.6.1.4.1.1466.115.121.1.40 + OID 1.3.6.1.4.1.1466.115.121.1.38 + Other Mailbox 1.3.6.1.4.1.1466.115.121.1.39 + Postal Address 1.3.6.1.4.1.1466.115.121.1.41 + Printable String 1.3.6.1.4.1.1466.115.121.1.44 + Substring Assertion 1.3.6.1.4.1.1466.115.121.1.58 + Telephone Number 1.3.6.1.4.1.1466.115.121.1.50 + Teletex Terminal Identifier 1.3.6.1.4.1.1466.115.121.1.51 + Telex Number 1.3.6.1.4.1.1466.115.121.1.52 + UTC Time 1.3.6.1.4.1.1466.115.121.1.53 + +Appendix B. Changes from RFC 2252 + + This annex lists the significant differences between this + specification and RFC 2252. + + + + + +Legg Standards Track [Page 49] + +RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 + + + This annex is provided for informational purposes only. It is not a + normative part of this specification. + + 1. The IESG Note has been removed. + + 2. The major part of Sections 4, 5 and 7 has been moved to [RFC4512] + and revised. Changes to the parts of these sections moved to + [RFC4512] are detailed in [RFC4512]. + + 3. BNF descriptions of syntax formats have been replaced by ABNF + [RFC4234] specifications. + + 4. The ambiguous statement in RFC 2252, Section 4.3 regarding the + use of a backslash quoting mechanism to escape separator symbols + has been removed. The escaping mechanism is now explicitly + represented in the ABNF for the syntaxes where this provision + applies. + + 5. The description of each of the LDAP syntaxes has been expanded so + that they are less dependent on knowledge of X.500 for + interpretation. + + 6. The relationship of LDAP syntaxes to corresponding ASN.1 type + definitions has been made explicit. + + 7. The set of characters allowed in a <PrintableString> (formerly + <printablestring>) has been corrected to align with the + PrintableString ASN.1 type in [ASN.1]. Specifically, the double + quote character has been removed and the single quote character + and equals sign have been added. + + 8. Values of the Directory String, Printable String and Telephone + Number syntaxes are now required to have at least one character. + + 9. The <DITContentRuleDescription>, <NameFormDescription> and + <DITStructureRuleDescription> rules have been moved to [RFC4512]. + + 10. The corresponding ASN.1 type for the Other Mailbox syntax has + been incorporated from RFC 1274. + + 11. A corresponding ASN.1 type for the LDAP Syntax Description syntax + has been invented. + + 12. The Binary syntax has been removed because it was not adequately + specified, implementations with different incompatible + interpretations exist, and it was confused with the ;binary + transfer encoding. + + + + +Legg Standards Track [Page 50] + +RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 + + + 13. All discussion of transfer options, including the ";binary" + option, has been removed. All imperatives regarding binary + transfer of values have been removed. + + 14. The Delivery Method, Enhanced Guide, Guide, Octet String, Teletex + Terminal Identifier and Telex Number syntaxes from RFC 2256 have + been incorporated. + + 15. The <criteria> rule for the Enhanced Guide and Guide syntaxes has + been extended to accommodate empty "and" and "or" expressions. + + 16. An encoding for the <ttx-value> rule in the Teletex Terminal + Identifier syntax has been defined. + + 17. The PKI-related syntaxes (Certificate, Certificate List and + Certificate Pair) have been removed. They are reintroduced in + [RFC4523] (as is the Supported Algorithm syntax from RFC 2256). + + 18. The MHS OR Address syntax has been removed since its + specification (in RFC 2156) is not at draft standard maturity. + + 19. The DL Submit Permission syntax has been removed as it depends on + the MHS OR Address syntax. + + 20. The Presentation Address syntax has been removed since its + specification (in RFC 1278) is not at draft standard maturity. + + 21. The ACI Item, Access Point, Audio, Data Quality, DSA Quality, DSE + Type, LDAP Schema Description, Master And Shadow Access Points, + Modify Rights, Protocol Information, Subtree Specification, + Supplier Information, Supplier Or Consumer and Supplier And + Consumer syntaxes have been removed. These syntaxes are + referenced in RFC 2252, but not defined. + + 22. The LDAP Schema Definition syntax (defined in RFC 2927) and the + Mail Preference syntax have been removed on the grounds that they + are out of scope for the core specification. + + 23. The description of each of the matching rules has been expanded + so that they are less dependent on knowledge of X.500 for + interpretation. + + 24. The caseIgnoreIA5SubstringsMatch matching rule from RFC 2798 has + been added. + + 25. The caseIgnoreListSubstringsMatch, caseIgnoreOrderingMatch and + caseIgnoreSubstringsMatch matching rules have been added to the + list of matching rules for which the provisions for handling + + + +Legg Standards Track [Page 51] + +RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 + + + leading, trailing and multiple adjoining whitespace characters + apply (now through string preparation). This is consistent with + the definitions of these matching rules in X.500. The + caseIgnoreIA5SubstringsMatch rule has also been added to the + list. + + 26. The specification of the octetStringMatch matching rule from + RFC 2256 has been added to this document. + + 27. The presentationAddressMatch matching rule has been removed as it + depends on an assertion syntax (Presentation Address) that is not + at draft standard maturity. + + 28. The protocolInformationMatch matching rule has been removed as it + depends on an undefined assertion syntax (Protocol Information). + + 29. The definitive reference for ASN.1 has been changed from X.208 to + X.680 since X.680 is the version of ASN.1 referred to by X.500. + + 30. The specification of the caseIgnoreListSubstringsMatch matching + rule from RFC 2798 & X.520 has been added. + + 31. String preparation algorithms have been applied to the character + string matching rules. + + 32. The specifications of the booleanMatch, caseExactMatch, + caseExactOrderingMatch, caseExactSubstringsMatch, + directoryStringFirstComponentMatch, integerOrderingMatch, + keywordMatch, numericStringOrderingMatch, + octetStringOrderingMatch and wordMatch matching rules from + RFC 3698 & X.520 have been added. + +Author's Address + + Steven Legg + eB2Bcom + Suite3, Woodhouse Corporate Centre + 935 Station Street + Box Hill North, Victoria 3129 + AUSTRALIA + + Phone: +61 3 9896 7830 + Fax: +61 3 9896 7801 + EMail: steven.legg@eb2bcom.com + + + + + + + +Legg Standards Track [Page 52] + +RFC 4517 LDAP: Syntaxes and Matching Rules June 2006 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2006). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is provided by the IETF + Administrative Support Activity (IASA). + + + + + + + +Legg Standards Track [Page 53] + |