idnits 2.17.1 draft-ietf-ldapbis-syntaxes-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 47 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == The 'Obsoletes: ' line in the draft header should list only the _numbers_ of the RFCs which will be obsoleted by this document (if approved); it should not include the word 'RFC' in the list. -- The draft header indicates that this document obsoletes RFC2252, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document obsoletes RFC2256, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (27 October 2003) is 7480 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '3' on line 584 == Missing Reference: 'ISO8601' is mentioned on line 593, but not defined == Missing Reference: 'RFC3383' is mentioned on line 890, but not defined ** Obsolete undefined reference: RFC 3383 (Obsoleted by RFC 4520) ** Obsolete normative reference: RFC 2234 (ref. 'ABNF') (Obsoleted by RFC 4234) -- No information found for draft-yergeau-rfc2279bis-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'UTF8' ** Obsolete normative reference: RFC 3383 (ref. 'BCP64') (Obsoleted by RFC 4520) -- No information found for draft-ietf-ldapbis-dn-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'LDAPDN' -- No information found for draft-ietf-ldapbis-protocol-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'PROT' -- Possible downref: Non-RFC (?) normative reference: ref. 'FAX' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO3166' -- Possible downref: Non-RFC (?) normative reference: ref. 'UCS' -- Possible downref: Non-RFC (?) normative reference: ref. 'JPEG' -- No information found for draft-ietf-ldapbis-roadmap-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'ROADMAP' -- No information found for draft-ietf-ldapbis-models-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'MODELS' -- No information found for draft-ietf-ldapbis-strprep-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'PREP' -- Obsolete informational reference (is this intentional?): RFC 2252 (Obsoleted by RFC 4510, RFC 4512, RFC 4517, RFC 4523) -- Obsolete informational reference (is this intentional?): RFC 2256 (Obsoleted by RFC 4510, RFC 4512, RFC 4517, RFC 4519, RFC 4523) -- Obsolete informational reference (is this intentional?): RFC 3377 (Obsoleted by RFC 4510) -- No information found for draft-ietf-ldapbis-user-schema-xx - is the name correct? -- No information found for draft-ietf-pkix-ldap-pki-schema-xx - is the name correct? Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 26 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT S. Legg, Editor 3 draft-ietf-ldapbis-syntaxes-07.txt Adacel Technologies 4 Intended Category: Standards Track K. Dally 5 Obsoletes: RFC 2252, RFC 2256 The MITRE Corp. 6 27 October 2003 8 LDAP: Syntaxes and Matching Rules 10 Copyright (C) The Internet Society (2003). All Rights Reserved. 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as 20 Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress". 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This document is intended to be, after appropriate review and 34 revision, submitted to the RFC Editor as a Standard Track document. 35 Distribution of this document is unlimited. Technical discussion of 36 this document should take place on the IETF LDAP Revision Working 37 Group (LDAPbis) mailing list . Please 38 send editorial comments directly to the editor 39 . 41 This Internet-Draft expires on 27 April 2004. 43 Abstract 45 Each attribute stored in a Lightweight Directory Access Protocol 46 (LDAP) directory, and whose values may be transfered in the LDAP 47 protocol, has a defined syntax which constrains the structure and 48 format of its values. The comparison semantics for values of a 49 syntax are not part of the syntax definition but are instead provided 50 through separately defined matching rules. Matching rules specify an 51 argument, an assertion value, which also has a defined syntax. This 52 document defines a base set of syntaxes and matching rules for use in 53 defining attributes for LDAP directories. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 2. Conventions. . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 3. Syntaxes . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 3.1. General Considerations . . . . . . . . . . . . . . . . . 6 61 3.2. Common Definitions . . . . . . . . . . . . . . . . . . . 6 62 3.3. Syntax Definitions . . . . . . . . . . . . . . . . . . . 7 63 3.3.1. Attribute Type Description . . . . . . . . . . . 7 64 3.3.2. Bit String . . . . . . . . . . . . . . . . . . . 7 65 3.3.3. Boolean. . . . . . . . . . . . . . . . . . . . . 8 66 3.3.4. Country String . . . . . . . . . . . . . . . . . 8 67 3.3.5. Delivery Method. . . . . . . . . . . . . . . . . 9 68 3.3.6. Directory String . . . . . . . . . . . . . . . . 9 69 3.3.7. DIT Content Rule Description . . . . . . . . . . 10 70 3.3.8. DIT Structure Rule Description . . . . . . . . . 11 71 3.3.9. DN . . . . . . . . . . . . . . . . . . . . . . . 11 72 3.3.10. Enhanced Guide . . . . . . . . . . . . . . . . . 12 73 3.3.11. Facsimile Telephone Number . . . . . . . . . . . 13 74 3.3.12. Fax. . . . . . . . . . . . . . . . . . . . . . . 13 75 3.3.13. Generalized Time . . . . . . . . . . . . . . . . 14 76 3.3.14. Guide. . . . . . . . . . . . . . . . . . . . . . 15 77 3.3.15. IA5 String . . . . . . . . . . . . . . . . . . . 15 78 3.3.16. Integer. . . . . . . . . . . . . . . . . . . . . 15 79 3.3.17. JPEG . . . . . . . . . . . . . . . . . . . . . . 16 80 3.3.18. LDAP Syntax Description. . . . . . . . . . . . . 16 81 3.3.19. Matching Rule Description. . . . . . . . . . . . 17 82 3.3.20. Matching Rule Use Description. . . . . . . . . . 17 83 3.3.21. Name and Optional UID. . . . . . . . . . . . . . 18 84 3.3.22. Name Form Description. . . . . . . . . . . . . . 18 85 3.3.23. Numeric String . . . . . . . . . . . . . . . . . 19 86 3.3.24. Object Class Description . . . . . . . . . . . . 19 87 3.3.25. Octet String . . . . . . . . . . . . . . . . . . 19 88 3.3.26. OID. . . . . . . . . . . . . . . . . . . . . . . 20 89 3.3.27. Other Mailbox. . . . . . . . . . . . . . . . . . 20 90 3.3.28. Postal Address . . . . . . . . . . . . . . . . . 21 91 3.3.29. Printable String . . . . . . . . . . . . . . . . 22 92 3.3.30. Substring Assertion. . . . . . . . . . . . . . . 22 93 3.3.31. Telephone Number . . . . . . . . . . . . . . . . 23 94 3.3.32. Teletex Terminal Identifier. . . . . . . . . . . 24 95 3.3.33. Telex Number . . . . . . . . . . . . . . . . . . 24 96 3.3.34. UTC Time . . . . . . . . . . . . . . . . . . . . 25 97 4. Matching Rules . . . . . . . . . . . . . . . . . . . . . . . . 25 98 4.1. General Considerations . . . . . . . . . . . . . . . . . 26 99 4.2. Matching Rule Definitions. . . . . . . . . . . . . . . . 27 100 4.2.1. bitStringMatch . . . . . . . . . . . . . . . . . 27 101 4.2.2. caseExactIA5Match. . . . . . . . . . . . . . . . 28 102 4.2.3. caseIgnoreIA5Match . . . . . . . . . . . . . . . 28 103 4.2.4. caseIgnoreIA5SubstringsMatch . . . . . . . . . . 29 104 4.2.5. caseIgnoreListMatch. . . . . . . . . . . . . . . 29 105 4.2.6. caseIgnoreListSubstringsMatch. . . . . . . . . . 30 106 4.2.7. caseIgnoreMatch. . . . . . . . . . . . . . . . . 31 107 4.2.8. caseIgnoreOrderingMatch. . . . . . . . . . . . . 31 108 4.2.9. caseIgnoreSubstringsMatch. . . . . . . . . . . . 32 109 4.2.10. distinguishedNameMatch . . . . . . . . . . . . . 32 110 4.2.11. generalizedTimeMatch . . . . . . . . . . . . . . 33 111 4.2.12. generalizedTimeOrderingMatch . . . . . . . . . . 33 112 4.2.13. integerFirstComponentMatch . . . . . . . . . . . 34 113 4.2.14. integerMatch . . . . . . . . . . . . . . . . . . 34 114 4.2.15. numericStringMatch . . . . . . . . . . . . . . . 35 115 4.2.16. numericStringSubstringsMatch . . . . . . . . . . 35 116 4.2.17. objectIdentifierFirstComponentMatch. . . . . . . 36 117 4.2.18. objectIdentifierMatch. . . . . . . . . . . . . . 36 118 4.2.19. octetStringMatch . . . . . . . . . . . . . . . . 37 119 4.2.20. telephoneNumberMatch . . . . . . . . . . . . . . 37 120 4.2.21. telephoneNumberSubstringsMatch . . . . . . . . . 38 121 4.2.22. uniqueMemberMatch. . . . . . . . . . . . . . . . 38 122 5. Security Considerations. . . . . . . . . . . . . . . . . . . . 39 123 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 39 124 7. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 39 125 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 41 126 8.1. Normative References . . . . . . . . . . . . . . . . . . 41 127 8.2. Informative References . . . . . . . . . . . . . . . . . 42 128 9. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 43 129 10. Intellectual Property Notice . . . . . . . . . . . . . . . . . 44 130 Appendix A. Summary of Syntax Object Identifiers . . . . . . . . . 44 131 Appendix B. Changes from RFC 2252 & RFC 2256 . . . . . . . . . . . 45 132 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 47 134 1. Introduction 136 Each attribute stored in a Lightweight Directory Access Protocol 137 (LDAP) directory [ROADMAP], and whose values may be transfered in the 138 LDAP protocol [PROT], has a defined syntax (i.e., data type) which 139 constrains the structure and format of its values. The comparison 140 semantics for values of a syntax are not part of the syntax 141 definition but are instead provided through separately defined 142 matching rules. Matching rules specify an argument, an assertion 143 value, which also has a defined syntax. This document defines a base 144 set of syntaxes and matching rules for use in defining attributes for 145 LDAP directories. 147 Readers are advised to familiarize themselves with the Directory 148 Information Models [MODELS] before reading the rest of this document. 149 Section 3 provides definitions for the base set of LDAP syntaxes. 150 Section 4 provides definitions for the base set of matching rules for 151 LDAP. 153 This document is a integral part of the LDAP technical specification 154 [ROADMAP] which obsoletes the previously defined LDAP technical 155 specification [RFC3377] in its entirety. 157 Sections 4, 5 and 7 of RFC 2252 [RFC2252] are obsoleted by [MODELS]. 158 The remainder of RFC 2252 is obsoleted by this document. Sections 6 159 and 8 of RFC 2256 [RFC2256] are obsoleted by this document. The 160 remainder of RFC 2256 is obsoleted by [SCHEMA] and [MODELS]. 162 A number of schema elements which were included in the previous 163 revision of the LDAP technical specification are not included in this 164 revision of LDAP. Public Key Infrastructure schema elements are now 165 specified in [LDAP-PKI]. Unless reintroduced in future technical 166 specifications, the remainder are to be considered Historic. 168 The changes from RFC 2252 and RFC 2256 are described in Appendix B of 169 this document. 171 2. Conventions 173 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 174 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 175 document are to be interpreted as described in BCP 14, RFC 2119 176 [KEYWORD]. 178 Syntax definitions are written according to the 179 ABNF [ABNF] rule specified in [MODELS], and matching rule definitions 180 are written according to the ABNF rule 181 specified in [MODELS], except that the syntax and matching rule 182 definitions provided in this document are line-wrapped for 183 readability. When such definitions are transfered as attribute 184 values in the LDAP protocol (e.g., as values of the ldapSyntaxes and 185 matchingRules attributes [MODELS] respectively) then those values 186 would not contain line breaks. 188 3. Syntaxes 190 Syntax definitions constrain the structure of attribute values stored 191 in an LDAP directory, and determine the representation of attribute 192 and assertion values transfered in the LDAP protocol. 194 Syntaxes that are required for directory operation, or that are in 195 common use, are specified in this section. Servers SHOULD recognize 196 all the syntaxes listed in this document, but are not required to 197 otherwise support them, and MAY recognise or support other syntaxes. 198 However, the definition of additional arbitrary syntaxes is 199 discouraged since it will hinder interoperability. Client and server 200 implementations typically do not have the ability to dynamically 201 recognize new syntaxes. 203 3.1. General Considerations 205 The description of each syntax specifies how attribute or assertion 206 values conforming to the syntax are to be represented when transfered 207 in the LDAP protocol [PROT]. This representation is referred to as 208 the LDAP-specific encoding to distinguish it from other methods of 209 encoding attribute values (e.g., the Basic Encoding Rules (BER) 210 encoding [BER] used by X.500 [X.500] directories). 212 The LDAP-specific encoding of a given attribute syntax always 213 produces octet-aligned values. To the greatest extent possible, 214 encoding rules for LDAP syntaxes should produce character strings 215 that can be displayed with little or no translation by clients 216 implementing LDAP. However, clients MUST NOT assume that the 217 LDAP-specific encoding of a value of an unrecognized syntax is a 218 human-readable character string. There are a few cases (e.g., the 219 JPEG syntax) when it is not reasonable to produce a human-readable 220 representation. 222 Each LDAP syntax is uniquely identified with an object identifier 223 [ASN.1] represented in the dotted-decimal format (short descriptive 224 names are not defined for syntaxes). These object identifiers are 225 not intended to be displayed to users. The object identifiers for 226 the syntaxes defined in this document are summarized in Appendix A. 228 A suggested minimum upper bound on the number of characters in an 229 attribute value with a string-based syntax, or the number of octets 230 in a value for all other syntaxes, MAY be indicated by appending the 231 bound inside of curly braces following the syntax's OBJECT IDENTIFIER 232 in an attribute type definition (see the rule in [MODELS]). 233 Such a bound is not considered part of the syntax identifier. 235 For example, "1.3.6.1.4.1.1466.115.121.1.15{64}" in an attribute 236 definition suggests that the directory server will allow a value of 237 the attribute to be up to 64 characters long, although it may allow 238 longer character strings. Note that a single character of the 239 Directory String syntax can be encoded in more than one octet since 240 UTF-8 [UTF8] is a variable-length encoding. Therefore a 64 character 241 string may be more than 64 octets in length. 243 3.2. Common Definitions 245 The following ABNF rules are used in a number of the syntax 246 definitions in Section 3.3. 248 PrintableCharacter = ALPHA / DIGIT / SQUOTE / LPAREN / RPAREN / 249 PLUS / COMMA / HYPHEN / DOT / EQUALS / 250 SLASH / COLON / QUESTION / SPACE 251 PrintableString = 1*PrintableCharacter 252 IA5String = *(%x00-7F) 253 HEX-DIGIT = DIGIT / "A" / "B" / "C" / "D" / "E" / "F" 254 ; N.B. allows upper and lower case 255 SLASH = %x2F ; forward slash ("/") 256 COLON = %x3A ; colon (":") 257 QUESTION = %x3F ; question mark ("?") 259 The , , , , , , , 260 , , , and rules are defined in 261 [MODELS]. 263 3.3. Syntax Definitions 265 3.3.1. Attribute Type Description 267 A value of the Attribute Type Description syntax is the definition of 268 an attribute type. The LDAP-specific encoding of a value of this 269 syntax is defined by the rule in [MODELS]. 270 For example, the following definition of the createTimestamp 271 attribute type from [MODELS] is also a value of the Attribute Type 272 Description syntax (note: line breaks have been added for readability 273 - they are not part of the value when transfered in protocol). 275 ( 2.5.18.1 NAME 'createTimestamp' 276 EQUALITY generalizedTimeMatch 277 ORDERING generalizedTimeOrderingMatch 278 SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 279 SINGLE-VALUE NO-USER-MODIFICATION 280 USAGE directoryOperation ) 282 The LDAP definition for the Attribute Type Description syntax is: 284 ( 1.3.6.1.4.1.1466.115.121.1.3 DESC 'Attribute Type Description' ) 286 This syntax corresponds to the AttributeTypeDescription ASN.1 type 287 from [X.501]. 289 3.3.2. Bit String 291 A value of the Bit String syntax is a sequence of binary digits. The 292 LDAP-specific encoding of a value of this syntax is defined by the 293 following ABNF: 295 BitString = SQUOTE *binary-digit SQUOTE "B" 296 binary-digit = "0" / "1" 298 The rule is defined in [MODELS]. 300 Example: 301 '0101111101'B 303 The LDAP definition for the Bit String syntax is: 305 ( 1.3.6.1.4.1.1466.115.121.1.6 DESC 'Bit String' ) 307 This syntax corresponds to the BIT STRING ASN.1 type from [ASN.1]. 309 3.3.3. Boolean 311 A value of the Boolean syntax is one of the Boolean values, true or 312 false. The LDAP-specific encoding of a value of this syntax is 313 defined by the following ABNF: 315 Boolean = "TRUE" / "FALSE" 317 The LDAP definition for the Boolean syntax is: 319 ( 1.3.6.1.4.1.1466.115.121.1.7 DESC 'Boolean' ) 321 This syntax corresponds to the BOOLEAN ASN.1 type from [ASN.1]. 323 3.3.4. Country String 325 A value of the Country String syntax is one of the two-character 326 codes from ISO 3166 [ISO3166] for representing a country. The 327 LDAP-specific encoding of a value of this syntax is defined by the 328 following ABNF: 330 CountryString = 2(PrintableCharacter) 332 The rule is defined in Section 3.2. 334 Examples: 335 US 336 AU 338 The LDAP definition for the Country String syntax is: 340 ( 1.3.6.1.4.1.1466.115.121.1.11 DESC 'Country String' ) 342 This syntax corresponds to the following ASN.1 type from [X.520]: 344 PrintableString (SIZE (2)) -- ISO 3166 codes only 346 3.3.5. Delivery Method 348 A value of the Delivery Method syntax is a sequence of items that 349 indicate, in preference order, the service(s) by which an entity is 350 willing and/or capable of receiving messages. The LDAP-specific 351 encoding of a value of this syntax is defined by the following ABNF: 353 DeliveryMethod = pdm *( WSP DOLLAR WSP pdm ) 355 pdm = "any" / "mhs" / "physical" / "telex" / "teletex" / 356 "g3fax" / "g4fax" / "ia5" / "videotex" / "telephone" 358 The and rules are defined in [MODELS]. 360 Example: 361 telephone $ videotex 363 The LDAP definition for the Delivery Method syntax is: 365 ( 1.3.6.1.4.1.1466.115.121.1.14 DESC 'Delivery Method' ) 367 This syntax corresponds to the following ASN.1 type from [X.520]: 369 SEQUENCE OF INTEGER { 370 any-delivery-method (0), 371 mhs-delivery (1), 372 physical-delivery (2), 373 telex-delivery (3), 374 teletex-delivery (4), 375 g3-facsimile-delivery (5), 376 g4-facsimile-delivery (6), 377 ia5-terminal-delivery (7), 378 videotex-delivery (8), 379 telephone-delivery (9) } 381 3.3.6. Directory String 383 A value of the Directory String syntax is a string of one or more 384 arbitrary characters from the Universal Character Set (UCS) [UCS]. A 385 zero length character string is not permitted. The LDAP-specific 386 encoding of a value of this syntax is the UTF-8 encoding [UTF8] of 387 the character string. Such encodings conform to the following ABNF: 389 DirectoryString = 1*UTF8 391 The rule is defined in [MODELS]. 393 Example: 394 This is a value of Directory String containing #!%#@. 396 Servers and clients MUST be prepared to receive arbitrary UCS code 397 points, including code points outside the range of printable ASCII 398 and code points not presently assigned to any character. 400 Attribute type definitions using the Directory String syntax should 401 not restrict the format of Directory String values, e.g., by 402 requiring that the character string conforms to specific patterns 403 described by ABNF. A new syntax should be defined in such cases. 405 The LDAP definition for the Directory String syntax is: 407 ( 1.3.6.1.4.1.1466.115.121.1.15 DESC 'Directory String' ) 409 This syntax corresponds to the DirectoryString parameterized ASN.1 410 type from [X.520]. 412 The DirectoryString ASN.1 type allows a choice between the 413 TeletexString, PrintableString or UniversalString ASN.1 types from 414 [ASN.1]. However, note that the chosen alternative is not indicated 415 in the LDAP-specific encoding of a Directory String value. 417 Implementations which convert Directory String values from the 418 LDAP-specific encoding to the BER encoding used by X.500 must choose 419 an alternative that permits the particular characters in the string, 420 and must convert the characters from the UTF-8 encoding into the 421 character encoding of the chosen alternative. 423 When converting Directory String values from the BER encoding to the 424 LDAP-specific encoding the characters must be converted from the 425 character encoding of the chosen alternative into the UTF-8 encoding. 427 3.3.7. DIT Content Rule Description 429 A value of the DIT Content Rule Description syntax is the definition 430 of a DIT (Directory Information Tree) content rule. The 431 LDAP-specific encoding of a value of this syntax is defined by the 432 rule in [MODELS]. 434 Example: 435 ( 2.5.6.4 DESC 'content rule for organization' 436 NOT ( x121Address $ telexNumber ) ) 438 Note: a line break has been added for readability - it is not part of 439 the value. 441 The LDAP definition for the DIT Content Rule Description syntax is: 443 ( 1.3.6.1.4.1.1466.115.121.1.16 444 DESC 'DIT Content Rule Description' ) 446 This syntax corresponds to the DITContentRuleDescription ASN.1 type 447 from [X.501]. 449 3.3.8. DIT Structure Rule Description 451 A value of the DIT Structure Rule Description syntax is the 452 definition of a DIT structure rule. The LDAP-specific encoding of a 453 value of this syntax is defined by the 454 rule in [MODELS]. 456 Example: 457 ( 2 DESC 'organization structure rule' FORM 2.5.15.3 ) 459 The LDAP definition for the DIT Structure Rule Description syntax is: 461 ( 1.3.6.1.4.1.1466.115.121.1.17 462 DESC 'DIT Structure Rule Description' ) 464 This syntax corresponds to the DITStructureRuleDescription ASN.1 type 465 from [X.501]. 467 3.3.9. DN 469 A value of the DN syntax is the (purported) distinguished name (DN) 470 of an entry [MODELS]. The LDAP-specific encoding of a value of this 471 syntax is defined by the rule in [LDAPDN]. 473 Examples (from [LDAPDN]): 474 UID=jsmith,DC=example,DC=net 475 OU=Sales+CN=J. Smith,DC=example,DC=net 476 CN=John Smith\, III,DC=example,DC=net 477 CN=Before\0dAfter,DC=example,DC=net 478 1.3.6.1.4.1.1466.0=#04024869,DC=example,DC=com 479 CN=Lu\C4\8Di\C4\87 481 The LDAP definition for the DN syntax is: 483 ( 1.3.6.1.4.1.1466.115.121.1.12 DESC 'DN' ) 485 The DN syntax corresponds to the DistinguishedName ASN.1 type from 486 [X.501]. Note that a BER encoded distinguished name (as used by 487 X.500) re-encoded into the LDAP-specific encoding is not necessarily 488 reversible to the original BER encoding since the chosen string type 489 in any DirectoryString components of the distinguished name is not 490 indicated in the LDAP-specific encoding of the distinguished name 491 (see Section 3.3.6). 493 3.3.10. Enhanced Guide 495 A value of the Enhanced Guide syntax suggests criteria, which consist 496 of combinations of attribute types and filter operators, to be used 497 in constructing filters to search for entries of particular object 498 classes. The Enhanced Guide syntax improves upon the Guide syntax by 499 allowing the recommended depth of the search to be specified. 501 The LDAP-specific encoding of a value of this syntax is defined by 502 the following ABNF: 504 EnhancedGuide = object-class SHARP WSP criteria WSP 505 SHARP WSP subset 506 object-class = WSP oid WSP 507 subset = "baseobject" / "oneLevel" / "wholeSubtree" 509 criteria = and-term *( BAR and-term ) 510 and-term = term *( AMPERSAND term ) 511 term = EXCLAIM term / 512 attributetype DOLLAR match-type / 513 LPAREN criteria RPAREN / 514 true / 515 false 516 match-type = "EQ" / "SUBSTR" / "GE" / "LE" / "APPROX" 517 true = "?true" 518 false = "?false" 519 BAR = %x7C ; vertical bar ("|") 520 AMPERSAND = %x26 ; ampersand ("&") 521 EXCLAIM = %x21 ; exclamation mark ("!") 523 The , , , , , and 524 rules are defined in [MODELS]. 526 The LDAP definition for the Enhanced Guide syntax is: 528 ( 1.3.6.1.4.1.1466.115.121.1.21 DESC 'Enhanced Guide' ) 530 Example: 531 person#(sn$EQ)#oneLevel 533 The Enhanced Guide syntax corresponds to the EnhancedGuide ASN.1 type 534 from [X.520]. The EnhancedGuide type references the Criteria ASN.1 535 type, also from [X.520]. The rule above represents an empty 536 "and" expression in a value of the Criteria type. The rule 537 above represents an empty "or" expression in a value of the Criteria 538 type. 540 3.3.11. Facsimile Telephone Number 542 A value of the Facsimile Telephone Number syntax is a subscriber 543 number of a facsimile device on the public switched telephone 544 network. The LDAP-specific encoding of a value of this syntax is 545 defined by the following ABNF: 547 fax-number = telephone-number *( DOLLAR fax-parameter ) 548 telephone-number = PrintableString 549 fax-parameter = "twoDimensional" / 550 "fineResolution" / 551 "unlimitedLength" / 552 "b4Length" / 553 "a3Width" / 554 "b4Width" / 555 "uncompressed" 557 The is a string of printable characters that 558 complies with the internationally agreed format for representing 559 international telephone numbers [E.123]. The rule 560 is defined in Section 3.2. The rule is defined in [MODELS]. 562 The LDAP definition for the Facsimile Telephone Number syntax is: 564 ( 1.3.6.1.4.1.1466.115.121.1.22 DESC 'Facsimile Telephone Number') 566 The Facsimile Telephone Number syntax corresponds to the 567 FacsimileTelephoneNumber ASN.1 type from [X.520]. 569 3.3.12. Fax 571 A value of the Fax syntax is an image which is produced using the 572 Group 3 facsimile process [FAX] to duplicate an object, such as a 573 memo. The LDAP-specific encoding of a value of this syntax is the 574 string of octets for a Group 3 Fax image as defined in [FAX]. 576 The LDAP definition for the Fax syntax is: 578 ( 1.3.6.1.4.1.1466.115.121.1.23 DESC 'Fax' ) 580 The ASN.1 type corresponding to the Fax syntax is defined as follows, 581 assuming EXPLICIT TAGS: 583 Fax ::= CHOICE { 584 g3-facsimile [3] G3FacsimileBodyPart 585 } 587 The G3FacsimileBodyPart ASN.1 type is defined in [X.420]. 589 3.3.13. Generalized Time 591 A value of the Generalized Time syntax is a character string 592 representing a date and time. The LDAP-specific encoding of a value 593 of this syntax is a restriction of the format defined in [ISO8601], 594 and is described by the following ABNF: 596 century = 2(%x30-39) ; "00" to "99" 597 year = 2(%x30-39) ; "00" to "99" 598 month = ( %x30 %x31-39 ) ; "01" (January) to "09" 599 / ( %x31 %x30-32 ) ; "10" to "12" 600 day = ( %x30 %x31-39 ) ; "01" to "09" 601 / ( %x31-32 %x30-39 ) ; "10" to "29" 602 / ( %x33 %x30-31 ) ; "30" to "31" 603 hour = ( %x30-31 %x30-39 ) / ( %x32 %x30-33 ) ; "00" to "23" 604 minute = %x30-35 %x30-39 ; "00" to "59" 605 second = ( %x30-35 %x30-39 ) ; "00" to "59" 606 / ( %x36 %x30 ) ; "60" (a leap second) 608 GeneralizedTime = century year month day hour 609 [ minute [ second ] ] [ fraction ] 610 g-time-zone 611 fraction = ( DOT / COMMA ) 1*(%x30-39) 612 g-time-zone = %x5A ; "Z" 613 / g-differential 614 g-differential = ( MINUS / PLUS ) hour [ minute ] 615 MINUS = %x2D ; minus sign ("-") 617 The , and rules are defined in [MODELS]. 619 The time value represents coordinated universal time (equivalent to 620 Greenwich Mean Time) if the "Z" form of is used, 621 otherwise the value represents a local time in the time zone 622 indicated by . In the latter case, coordinated 623 universal time can be calculated by subtracting the differential from 624 the local time. The "Z" form of SHOULD be used in 625 preference to . 627 Examples: 628 199412161032Z 629 199412160532-0500 631 Both example values represent the same coordinated universal time: 633 10:32 AM, December 16, 1994. 635 The LDAP definition for the Generalized Time syntax is: 637 ( 1.3.6.1.4.1.1466.115.121.1.24 DESC 'Generalized Time' ) 639 This syntax corresponds to the GeneralizedTime ASN.1 type from 640 [ASN.1], with the constraint that local time without a differential 641 SHALL NOT be used. 643 3.3.14. Guide 645 A value of the Guide syntax suggests criteria, which consist of 646 combinations of attribute types and filter operators, to be used in 647 constructing filters to search for entries of particular object 648 classes. The Guide syntax is obsolete and should not be used for 649 defining new attribute types. 651 The LDAP-specific encoding of a value of this syntax is defined by 652 the following ABNF: 654 Guide = [ object-class SHARP ] criteria 656 The and rules are defined in Section 657 3.3.10. The rule is defined in [MODELS]. 659 The LDAP definition for the Guide syntax is: 661 ( 1.3.6.1.4.1.1466.115.121.1.25 DESC 'Guide' ) 663 The Guide syntax corresponds to the Guide ASN.1 type from [X.520]. 665 3.3.15. IA5 String 667 A value of the IA5 String syntax is a string of zero, one or more 668 characters from International Alphabet 5 (IA5) [T.50], the 669 international version of the ASCII character set. The LDAP-specific 670 encoding of a value of this syntax is the unconverted string of 671 characters, which conforms to the rule in Section 3.2. 673 The LDAP definition for the IA5 String syntax is: 675 ( 1.3.6.1.4.1.1466.115.121.1.26 DESC 'IA5 String' ) 677 This syntax corresponds to the IA5String ASN.1 type from [ASN.1]. 679 3.3.16. Integer 680 A value of the Integer syntax is a whole number of unlimited 681 magnitude. The LDAP-specific encoding of a value of this syntax is 682 the optionally signed decimal digit character string representation 683 of the number (so, for example, the number 1321 is represented by the 684 character string "1321"). The encoding is defined by the following 685 ABNF: 687 Integer = ( HYPHEN LDIGIT *DIGIT ) / number 689 The , , and rules are defined in 690 [MODELS]. 692 The LDAP definition for the Integer syntax is: 694 ( 1.3.6.1.4.1.1466.115.121.1.27 DESC 'INTEGER' ) 696 This syntax corresponds to the INTEGER ASN.1 type from [ASN.1]. 698 3.3.17. JPEG 700 A value of the JPEG syntax is an image in the JPEG File Interchange 701 Format (JFIF), as described in [JPEG]. The LDAP-specific encoding of 702 a value of this syntax is the sequence of octets of the JFIF encoding 703 of the image. 705 The LDAP definition for the JPEG syntax is: 707 ( 1.3.6.1.4.1.1466.115.121.1.28 DESC 'JPEG' ) 709 The JPEG syntax corresponds to the following ASN.1 type: 711 JPEG ::= OCTET STRING (CONSTRAINED BY 712 { -- contents octets are an image in the -- 713 -- JPEG File Interchange Format -- }) 715 3.3.18. LDAP Syntax Description 717 A value of the LDAP Syntax Description syntax is the description of 718 an LDAP syntax. The LDAP-specific encoding of a value of this syntax 719 is defined by the rule in [MODELS]. 721 The LDAP definition for the LDAP Syntax Description syntax is: 723 ( 1.3.6.1.4.1.1466.115.121.1.54 DESC 'LDAP Syntax Description' ) 725 The above LDAP definition for the LDAP Syntax Description syntax is 726 itself a legal value of the LDAP Syntax Description syntax. 728 The ASN.1 type corresponding to the LDAP Syntax Description syntax is 729 defined as follows, assuming EXPLICIT TAGS: 731 LDAPSyntaxDescription ::= SEQUENCE { 732 identifier OBJECT IDENTIFIER, 733 description DirectoryString { ub-schema } OPTIONAL } 735 The DirectoryString parameterized ASN.1 type is defined in [X.520]. 737 The value of ub-schema (an integer) is implementation defined. A 738 non-normative definition appears in [X.520]. 740 3.3.19. Matching Rule Description 742 A value of the Matching Rule Description syntax is the definition of 743 a matching rule. The LDAP-specific encoding of a value of this 744 syntax is defined by the rule in [MODELS]. 746 Example: 747 ( 2.5.13.2 NAME 'caseIgnoreMatch' 748 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 750 Note: a line break has been added for readability - it is not part of 751 the syntax. 753 The LDAP definition for the Matching Rule Description syntax is: 755 ( 1.3.6.1.4.1.1466.115.121.1.30 DESC 'Matching Rule Description' ) 757 This syntax corresponds to the MatchingRuleDescription ASN.1 type 758 from [X.501]. 760 3.3.20. Matching Rule Use Description 762 A value of the Matching Rule Use Description syntax indicates the 763 attribute types to which a matching rule may be applied in an 764 extensibleMatch search filter [PROT]. The LDAP-specific encoding of 765 a value of this syntax is defined by the 766 rule in [MODELS]. 768 Example: 769 ( 2.5.13.16 APPLIES ( givenName $ surname ) ) 771 The LDAP definition for the Matching Rule Use Description syntax is: 773 ( 1.3.6.1.4.1.1466.115.121.1.31 774 DESC 'Matching Rule Use Description' ) 776 This syntax corresponds to the MatchingRuleUseDescription ASN.1 type 777 from [X.501]. 779 3.3.21. Name and Optional UID 781 A value of the Name and Optional UID syntax is the distinguished name 782 [MODELS] of an entity optionally accompanied by a unique identifier 783 that serves to differentiate the entity from others with an identical 784 distinguished name. 786 The LDAP-specific encoding of a value of this syntax is defined by 787 the following ABNF: 789 NameAndOptionalUID = distinguishedName [ SHARP BitString ] 791 The rule is defined in Section 3.3.2. The 792 rule is defined in [LDAPDN]. The rule is 793 defined in [MODELS]. 795 Note that although the '#' character may occur in the string 796 representation of a distinguished name, no additional escaping of 797 this character is performed when a is encoded in 798 a . 800 Example: 801 1.3.6.1.4.1.1466.0=#04024869,O=Test,C=GB#'0101'B 803 The LDAP definition for the Name and Optional UID syntax is: 805 ( 1.3.6.1.4.1.1466.115.121.1.34 DESC 'Name And Optional UID' ) 807 This syntax corresponds to the NameAndOptionalUID ASN.1 type from 808 [X.520]. 810 3.3.22. Name Form Description 812 A value of the Name Form Description syntax is the definition of a 813 name form, which regulates how entries may be named. The 814 LDAP-specific encoding of a value of this syntax is defined by the 815 rule in [MODELS]. 817 Example: 818 ( 2.5.15.3 NAME 'orgNameForm' OC organization MUST o ) 820 The LDAP definition for the Name Form Description syntax is: 822 ( 1.3.6.1.4.1.1466.115.121.1.35 DESC 'Name Form Description' ) 824 This syntax corresponds to the NameFormDescription ASN.1 type from 825 [X.501]. 827 3.3.23. Numeric String 829 A value of the Numeric String syntax is a sequence of one or more 830 numerals and spaces. The LDAP-specific encoding of a value of this 831 syntax is the unconverted string of characters, which conforms to the 832 following ABNF: 834 NumericString = 1*(DIGIT / SPACE) 836 The and rules are defined in [MODELS]. 838 Example: 839 15 079 672 281 841 The LDAP definition for the Numeric String syntax is: 843 ( 1.3.6.1.4.1.1466.115.121.1.36 DESC 'Numeric String' ) 845 This syntax corresponds to the NumericString ASN.1 type from [ASN.1]. 847 3.3.24. Object Class Description 849 A value of the Object Class Description syntax is the definition of 850 an object class. The LDAP-specific encoding of a value of this 851 syntax is defined by the rule in [MODELS]. 853 Example: 854 ( 2.5.6.2 NAME 'country' SUP top STRUCTURAL MUST c 855 MAY ( searchGuide $ description ) ) 857 Note: a line break has been added for readability - it is not part of 858 the syntax. 860 The LDAP definition for the Object Class Description syntax is: 862 ( 1.3.6.1.4.1.1466.115.121.1.37 DESC 'Object Class Description' ) 864 This syntax corresponds to the ObjectClassDescription ASN.1 type from 865 [X.501]. 867 3.3.25. Octet String 869 A value of the Octet String syntax is a sequence of zero, one or more 870 arbitrary octets. The LDAP-specific encoding of a value of this 871 syntax is the unconverted sequence of octets, which conforms to the 872 following ABNF: 874 OctetString = *OCTET 876 The rule is defined in [MODELS]. Values of this syntax are 877 not generally human-readable. 879 The LDAP definition for the Octet String syntax is: 881 ( 1.3.6.1.4.1.1466.115.121.1.40 DESC 'Octet String' ) 883 This syntax corresponds to the OCTET STRING ASN.1 type from [ASN.1]. 885 3.3.26. OID 887 A value of the OID syntax is an object identifier; a sequence of two 888 or more non-negative integers that uniquely identify some object or 889 item of specification. Many of the object identifiers used in LDAP 890 also have IANA registered names [RFC3383]. 892 The LDAP-specific encoding of a value of this syntax is defined by 893 the rule in [MODELS]. 895 Examples: 896 1.2.3.4 897 cn 899 The LDAP definition for the OID syntax is: 901 ( 1.3.6.1.4.1.1466.115.121.1.38 DESC 'OID' ) 903 This syntax corresponds to the OBJECT IDENTIFIER ASN.1 type from 904 [ASN.1]. 906 3.3.27. Other Mailbox 908 A value of the Other Mailbox syntax identifies an electronic mailbox, 909 in a particular named mail system. The LDAP-specific encoding of a 910 value of this syntax is defined by the following ABNF: 912 OtherMailbox = mailbox-type DOLLAR mailbox 913 mailbox-type = PrintableString 914 mailbox = IA5String 916 The rule represents the type of mail system in which 917 the mailbox resides, for example "MCIMail", and is the 918 actual mailbox in the mail system described by . The 919 and rules are defined in Section 3.2. 921 The rule is defined in [MODELS]. 923 The LDAP definition for the Other Mailbox syntax is: 925 ( 1.3.6.1.4.1.1466.115.121.1.39 DESC 'Other Mailbox' ) 927 The ASN.1 type corresponding to the Other Mailbox syntax is defined 928 as follows, assuming EXPLICIT TAGS: 930 OtherMailbox ::= SEQUENCE { 931 mailboxType PrintableString, 932 mailbox IA5String 933 } 935 3.3.28. Postal Address 937 A value of the Postal Address syntax is a sequence of strings of one 938 or more arbitrary UCS characters, which form an address in a physical 939 mail system. 941 The LDAP-specific encoding of a value of this syntax is defined by 942 the following ABNF: 944 PostalAddress = line *( DOLLAR line ) 945 line = 1*line-char 946 line-char = %x00-23 947 / (%x5C "24") ; escaped "$" 948 / %x25-5B 949 / (%x5C "5C") ; escaped "\" 950 / %x5D-7F 951 / UTFMB 953 Each character string (i.e., ) of a postal address value is 954 encoded as a UTF-8 [UTF8] string except that "\" and "$" characters, 955 if they occur in the string, are escaped by a "\" character followed 956 by the two hexadecimal digit code for the character. The 957 rule is defined in Section 3.2. The and rules are 958 defined in [MODELS]. 960 Many servers limit the postal address to no more than six lines of no 961 more than thirty characters each. 963 Example: 964 1234 Main St.$Anytown, CA 12345$USA 965 \241,000,000 Sweepstakes$PO Box 1000000$Anytown, CA 12345$USA 967 The LDAP definition for the Postal Address syntax is: 969 ( 1.3.6.1.4.1.1466.115.121.1.41 DESC 'Postal Address' ) 971 This syntax corresponds to the PostalAddress ASN.1 type from [X.520], 972 i.e., 974 PostalAddress ::= SEQUENCE SIZE(1..ub-postal-line) OF 975 DirectoryString { ub-postal-string } 977 The values of ub-postal-line and ub-postal-string (both integers) are 978 implementation defined. Non-normative definitions appear in [X.520]. 980 3.3.29. Printable String 982 A value of the Printable String syntax is a string of one or more 983 latin alphabetic, numeric, and selected punctuation characters as 984 specified by the rule in Section 3.2. 986 The LDAP-specific encoding of a value of this syntax is the 987 unconverted string of characters, which conforms to the 988 rule in Section 3.2. 990 Example: 991 This is a PrintableString. 993 The LDAP definition for the PrintableString syntax is: 995 ( 1.3.6.1.4.1.1466.115.121.1.44 DESC 'Printable String' ) 997 This syntax corresponds to the PrintableString ASN.1 type from 998 [ASN.1]. 1000 3.3.30. Substring Assertion 1002 A value of the Substring Assertion syntax is a sequence of zero, one 1003 or more character substrings used as an argument for substring 1004 extensible matching of character string attribute values, i.e., as 1005 the matchValue of a MatchingRuleAssertion [PROT]. Each substring is 1006 a string of one or more arbitrary characters from the Universal 1007 Character Set (UCS) [UCS]. A zero length substring is not permitted. 1009 The LDAP-specific encoding of a value of this syntax is defined by 1010 the following ABNF: 1012 SubstringAssertion = [ initial ] any [ final ] 1014 initial = substring 1015 any = ASTERISK *(substring ASTERISK) 1016 final = substring 1017 ASTERISK = %x2A ; asterisk ("*") 1019 substring = 1*substring-character 1020 substring-character = %x00-29 1021 / (%x5C "2A") ; escaped "*" 1022 / %x2B-5B 1023 / (%x5C "5C") ; escaped "\" 1024 / %x5D-7F 1025 / UTFMB 1027 Each of a Substring Assertion value is encoded as a UTF-8 1028 [UTF8] string, except that "\" and "*" characters, if they occur in 1029 the substring, are escaped by a "\" character followed by the two 1030 hexadecimal digit code for the character. 1032 The Substring Assertion syntax is used only as the syntax of 1033 assertion values in the extensible match. It is not used as an 1034 attribute syntax, or in the SubstringFilter [PROT]. 1036 The LDAP definition for the Substring Assertion syntax is: 1038 ( 1.3.6.1.4.1.1466.115.121.1.58 DESC 'Substring Assertion' ) 1040 This syntax corresponds to the SubstringAssertion ASN.1 type from 1041 [X.520]. 1043 3.3.31. Telephone Number 1045 A value of the Telephone Number syntax is a string of printable 1046 characters that complies with the internationally agreed format for 1047 representing international telephone numbers [E.123]. 1049 The LDAP-specific encoding of a value of this syntax is the 1050 unconverted string of characters, which conforms to the 1051 rule in Section 3.2. 1053 Example: +1 512 315 0280 1055 The LDAP definition for the Telephone Number syntax is: 1057 ( 1.3.6.1.4.1.1466.115.121.1.50 DESC 'Telephone Number' ) 1059 The Telephone Number syntax corresponds to the following ASN.1 type 1060 from [X.520]: 1062 PrintableString (SIZE(1..ub-telephone-number)) 1064 The value of ub-telephone-number (an integer) is implementation 1065 defined. A non-normative definition appears in [X.520]. 1067 3.3.32. Teletex Terminal Identifier 1069 A value of this syntax specifies the identifier and (optionally) 1070 parameters of a teletex terminal. 1072 The LDAP-specific encoding of a value of this syntax is defined by 1073 the following ABNF: 1075 teletex-id = ttx-term *(DOLLAR ttx-param) 1076 ttx-term = PrintableString ; terminal identifier 1077 ttx-param = ttx-key COLON ttx-value ; parameter 1078 ttx-key = "graphic" / "control" / "misc" / "page" / "private" 1079 ttx-value = *ttx-value-char 1081 ttx-value-char = %x00-23 1082 / (%x5C "24") ; escaped "$" 1083 / %x25-5B 1084 / (%x5C "5C") ; escaped "\" 1085 / %x5D-FF 1087 The and rules are defined in Section 3.2. 1088 The rule is defined in [MODELS]. 1090 The LDAP definition for the Teletex Terminal Identifier syntax is: 1092 ( 1.3.6.1.4.1.1466.115.121.1.51 1093 DESC 'Teletex Terminal Identifier' ) 1095 This syntax corresponds to the TeletexTerminalIdentifier ASN.1 type 1096 from [X.520]. 1098 3.3.33. Telex Number 1100 A value of the Telex Number syntax specifies the telex number, 1101 country code and answerback code of a telex terminal. 1103 The LDAP-specific encoding of a value of this syntax is defined by 1104 the following ABNF: 1106 telex-number = actual-number DOLLAR country-code 1107 DOLLAR answerback 1108 actual-number = PrintableString 1109 country-code = PrintableString 1110 answerback = PrintableString 1112 The rule is defined in Section 3.2. The 1113 rule is defined in [MODELS]. 1115 The LDAP definition for the Telex Number syntax is: 1117 ( 1.3.6.1.4.1.1466.115.121.1.52 DESC 'Telex Number' ) 1119 This syntax corresponds to the TelexNumber ASN.1 type from [X.520]. 1121 3.3.34. UTC Time 1123 A value of the UTC Time syntax is a character string representing a 1124 date and time to a precision of one minute or one second. The year 1125 is given as a two-digit number. The LDAP-specific encoding of a 1126 value of this syntax follows the format defined in [ASN.1] for the 1127 UTCTime type and is described by the following ABNF: 1129 UTCTime = year month day hour minute [ second ] 1130 [ u-time-zone ] 1131 u-time-zone = %x5A ; "Z" 1132 / u-differential 1133 u-differential = ( MINUS / PLUS ) hour minute 1135 The , , , , , and 1136 rules are defined in Section 3.3.13. The rule is defined in 1137 [MODELS]. 1139 The time value represents coordinated universal time if the "Z" form 1140 of is used, otherwise the value represents a local 1141 time. In the latter case, if is provided then 1142 coordinated universal time can be calculated by subtracting the 1143 differential from the local time. The SHOULD be 1144 present in time values and the "Z" form of SHOULD be 1145 used in preference to . 1147 The LDAP definition for the UTC Time syntax is: 1149 ( 1.3.6.1.4.1.1466.115.121.1.53 DESC 'UTC Time' ) 1151 Note: This syntax is deprecated in favor of the Generalized Time 1152 syntax. 1154 The UTC Time syntax corresponds to the UTCTime ASN.1 type from 1155 [ASN.1]. 1157 4. Matching Rules 1159 Matching rules are used by directory implementations to compare 1160 attribute values against assertion values when performing Search and 1161 Compare operations [PROT]. They are also used when comparing a 1162 purported distinguished name [MODELS] with the name of an entry. 1163 When modifying entries, matching rules are used to identify values to 1164 be deleted and to prevent an attribute from containing two equal 1165 values. 1167 Matching rules that are required for directory operation, or that are 1168 in common use, are specified in this section. 1170 4.1. General Considerations 1172 A matching rule is applied to attribute values through an 1173 AttributeValueAssertion or MatchingRuleAssertion [PROT]. The 1174 conditions under which an AttributeValueAssertion or 1175 MatchingRuleAssertion evaluates to Undefined are specified in [PROT]. 1176 If an assertion is not Undefined then the result of the assertion is 1177 the result of applying the selected matching rule. A matching rule 1178 evaluates to TRUE, and in some cases Undefined, as specified in the 1179 description of the matching rule, otherwise it evaluates to FALSE. 1181 Each assertion contains an assertion value. The definition of each 1182 matching rule specifies the syntax for the assertion value. The 1183 syntax of the assertion value is typically, but not necessarily, the 1184 same as the syntax of the attribute values to which the matching rule 1185 may be applied. Note that the AssertionValue in a SubstringFilter 1186 [PROT] MUST conform to the assertion syntax of the equality matching 1187 rule for the attribute type rather than the assertion syntax of the 1188 substrings matching rule for the attribute type. The entire 1189 SubstringFilter is converted into an assertion value of the 1190 substrings matching rule prior to applying the rule. 1192 The definition of each matching rule indicates the attribute syntaxes 1193 to which the rule may be applied, by specifying conditions the 1194 corresponding ASN.1 type of a candidate attribute syntax must 1195 satisfy. These conditions are also satisfied if the corresponding 1196 ASN.1 type is a tagged or constrained derivative of the ASN.1 type 1197 explicitly mentioned in the rule description (i.e., ASN.1 tags and 1198 constraints are ignored in checking applicability), or an alternative 1199 reference notation for the explicitly mentioned type. Each rule 1200 description lists as examples of applicable attribute syntaxes, the 1201 complete list of the syntaxes defined in this document to which the 1202 matching rule applies. A matching rule may be applicable to 1203 additional syntaxes defined in other documents if those syntaxes 1204 satisfy the conditions on the corresponding ASN.1 type. 1206 The description of each matching rule indicates whether the rule is 1207 suitable for use as the equality matching rule (EQUALITY), ordering 1208 matching rule (ORDERING) or substrings matching rule (SUBSTR) in an 1209 attribute type definition [MODELS]. 1211 Each matching rule is uniquely identified with an object identifier. 1212 The definition of a matching rule should not be subsequently changed. 1213 If a change is desirable then a new matching rule with a different 1214 object identifier should be defined instead. 1216 Servers SHOULD implement all the matching rules in Section 4.2. 1217 Servers MAY implement additional matching rules. 1219 Servers which implement the extensibleMatch filter SHOULD allow the 1220 matching rules listed in Section 4.2 to be used in the 1221 extensibleMatch filter and SHOULD allow matching rules to be used 1222 with all attribute types known to the server, where the assertion 1223 syntax of the matching rule is the same as the value syntax of the 1224 attribute. 1226 Servers MUST publish in the matchingRules attribute, the definitions 1227 of matching rules referenced by values of the attributeTypes and 1228 matchingRuleUse attributes in the same subschema entry. Other 1229 unreferenced matching rules MAY be published in the matchingRules 1230 attribute. 1232 If the server supports the extensibleMatch filter, then the server 1233 MAY use the matchingRuleUse attribute to indicate the applicability 1234 (in an extensibleMatch filter) of selected matching rules to 1235 nominated attribute types. 1237 4.2. Matching Rule Definitions 1239 When evaluating the numericStringMatch, numericStringSubstringsMatch, 1240 caseExactIA5Match, caseIgnoreIA5Match, caseIgnoreIA5SubstringsMatch, 1241 caseIgnoreListMatch, caseIgnoreListSubstringsMatch, caseIgnoreMatch, 1242 caseIgnoreOrderingMatch, caseIgnoreSubstringsMatch, 1243 telephoneNumberMatch and telephoneNumberSubstringsMatch matching 1244 rules the assertion value and attribute value are prepared according 1245 to the string preparation algorithms [PREP] for LDAP before being 1246 compared. The Transcode, Normalize, Prohibit and Check bidi steps 1247 are the same for each of the matching rules. However, the Map and 1248 Insignificant Character Removal steps depends on the specific rule, 1249 as detailed in the description of these matching rules in the 1250 sections that follow. 1252 4.2.1. bitStringMatch 1254 The bitStringMatch rule compares an assertion value of the Bit String 1255 syntax to an attribute value of a syntax (e.g., the Bit String 1256 syntax) whose corresponding ASN.1 type is BIT STRING. 1258 If the corresponding ASN.1 type of the attribute syntax does not have 1259 a named bit list (which is the case for the Bit String syntax) then 1260 the rule evaluates to TRUE if and only if the attribute value has the 1261 same number of bits as the assertion value and the bits match on a 1262 bitwise basis. 1264 If the corresponding ASN.1 type does have a named bit list then 1265 bitStringMatch operates as above except that trailing zero bits in 1266 the attribute and assertion values are treated as absent. 1268 The LDAP definition for the bitStringMatch rule is: 1270 ( 2.5.13.16 NAME 'bitStringMatch' 1271 SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 ) 1273 The bitStringMatch rule is an equality matching rule. 1275 4.2.2. caseExactIA5Match 1277 The caseExactIA5Match rule compares an assertion value of the IA5 1278 String syntax to an attribute value of a syntax (e.g the IA5 String 1279 syntax) whose corresponding ASN.1 type is IA5String. 1281 The rule evaluates to TRUE if and only if the prepared attribute 1282 value character string and the prepared assertion value character 1283 string have the same number of characters and corresponding 1284 characters have the same code point. 1286 In preparing the attribute value and assertion value for comparison, 1287 characters are not case folded in the Map preparation step, and only 1288 Insignificant Space Removal is applied in the Insignificant Character 1289 Removal step. 1291 The LDAP definition for the caseExactIA5Match rule is: 1293 ( 1.3.6.1.4.1.1466.109.114.1 NAME 'caseExactIA5Match' 1294 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) 1296 The caseExactIA5Match rule is an equality matching rule. 1298 4.2.3. caseIgnoreIA5Match 1300 The caseIgnoreIA5Match rule compares an assertion value of the IA5 1301 String syntax to an attribute value of a syntax (e.g the IA5 String 1302 syntax) whose corresponding ASN.1 type is IA5String. 1304 The rule evaluates to TRUE if and only if the prepared attribute 1305 value character string and the prepared assertion value character 1306 string have the same number of characters and corresponding 1307 characters have the same code point. 1309 In preparing the attribute value and assertion value for comparison, 1310 characters are case folded in the Map preparation step, and only 1311 Insignificant Space Removal is applied in the Insignificant Character 1312 Removal step. 1314 The LDAP definition for the caseIgnoreIA5Match rule is: 1316 ( 1.3.6.1.4.1.1466.109.114.2 NAME 'caseIgnoreIA5Match' 1317 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) 1319 The caseIgnoreIA5Match rule is an equality matching rule. 1321 4.2.4. caseIgnoreIA5SubstringsMatch 1323 The caseIgnoreIA5SubstringsMatch rule compares an assertion value of 1324 the Substring Assertion syntax to an attribute value of a syntax (e.g 1325 the IA5 String syntax) whose corresponding ASN.1 type is IA5String. 1327 The rule evaluates to TRUE if and only if the prepared substrings of 1328 the assertion value match disjoint portions of the prepared attribute 1329 value character string in the order of the substrings in the 1330 assertion value, and an substring, if present, matches the 1331 beginning of the prepared attribute value character string, and a 1332 substring, if present, matches the end of the prepared 1333 attribute value character string. A prepared substring matches a 1334 portion of the prepared attribute value character string if 1335 corresponding characters have the same code point. 1337 In preparing the attribute value and assertion value substrings for 1338 comparison, characters are case folded in the Map preparation step, 1339 and only Insignificant Space Removal is applied in the Insignificant 1340 Character Removal step. 1342 ( 1.3.6.1.4.1.1466.109.114.3 NAME 'caseIgnoreIA5SubstringsMatch' 1343 SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 ) 1345 The caseIgnoreIA5SubstringsMatch rule is a substrings matching rule. 1347 4.2.5. caseIgnoreListMatch 1349 The caseIgnoreListMatch rule compares an assertion value that is a 1350 sequence of strings to an attribute value of a syntax (e.g., the 1351 Postal Address syntax) whose corresponding ASN.1 type is a SEQUENCE 1352 OF the DirectoryString ASN.1 type. 1354 The rule evaluates to TRUE if and only if the attribute value and the 1355 assertion value have the same number of strings and corresponding 1356 strings (by position) match according to the caseIgnoreMatch matching 1357 rule. 1359 In [X.520] the assertion syntax for this matching rule is defined to 1360 be: 1362 SEQUENCE OF DirectoryString {ub-match} 1364 i.e., different from the corresponding type for the Postal Address 1365 syntax. The choice of the Postal Address syntax for the assertion 1366 syntax of the caseIgnoreListMatch in LDAP should not be seen as 1367 limiting the matching rule to only apply to attributes with the 1368 Postal Address syntax. 1370 The LDAP definition for the caseIgnoreListMatch rule is: 1372 ( 2.5.13.11 NAME 'caseIgnoreListMatch' 1373 SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 ) 1375 The caseIgnoreListMatch rule is an equality matching rule. 1377 4.2.6. caseIgnoreListSubstringsMatch 1379 The caseIgnoreListSubstringsMatch rule compares an assertion value of 1380 the Substring Assertion syntax to an attribute value of a syntax 1381 (e.g., the Postal Address syntax) whose corresponding ASN.1 type is a 1382 SEQUENCE OF the DirectoryString ASN.1 type. 1384 The rule evaluates to TRUE if and only if the assertion value 1385 matches, per the caseIgnoreSubstringsMatch rule, the character string 1386 formed by concatenating the strings of the attribute value, except 1387 that none of the , , or substrings of the 1388 assertion value are considered to match a substring of the 1389 concatenated string which spans more than one of the original strings 1390 of the attribute value. 1392 Note that, in terms of the LDAP-specific encoding of the Postal 1393 Address syntax, the concatenated string omits the line 1394 separator and the escaping of "\" and "$" characters. 1396 The LDAP definition for the caseIgnoreListSubstringsMatch rule is: 1398 ( 2.5.13.12 NAME 'caseIgnoreListSubstringsMatch' 1399 SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 ) 1401 The caseIgnoreListSubstringsMatch rule is a substrings matching rule. 1403 4.2.7. caseIgnoreMatch 1405 The caseIgnoreMatch rule compares an assertion value of the Directory 1406 String syntax to an attribute value of a syntax (e.g., the Directory 1407 String, Printable String, Country String or Telephone Number syntax) 1408 whose corresponding ASN.1 type is DirectoryString or one of the 1409 alternative string types of DirectoryString, e.g., PrintableString 1410 (the other alternatives do not correspond to any syntax defined in 1411 this document). 1413 The rule evaluates to TRUE if and only if the prepared attribute 1414 value character string and the prepared assertion value character 1415 string have the same number of characters and corresponding 1416 characters have the same code point. 1418 In preparing the attribute value and assertion value for comparison, 1419 characters are case folded in the Map preparation step, and only 1420 Insignificant Space Removal is applied in the Insignificant Character 1421 Removal step. 1423 The LDAP definition for the caseIgnoreMatch rule is: 1425 ( 2.5.13.2 NAME 'caseIgnoreMatch' 1426 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 1428 The caseIgnoreMatch rule is an equality matching rule. 1430 4.2.8. caseIgnoreOrderingMatch 1432 The caseIgnoreOrderingMatch rule compares an assertion value of the 1433 Directory String syntax to an attribute value of a syntax (e.g., the 1434 Directory String, Printable String, Country String or Telephone 1435 Number syntax) whose corresponding ASN.1 type is DirectoryString or 1436 one of its alternative string types. 1438 The rule evaluates to TRUE if, and only if, in the code point 1439 collation order, the prepared attribute value character string 1440 appears earlier than the prepared assertion value character string, 1441 i.e., the attribute value is "less than" the assertion value. 1443 In preparing the attribute value and assertion value for comparison, 1444 characters are case folded in the Map preparation step, and only 1445 Insignificant Space Removal is applied in the Insignificant Character 1446 Removal step. 1448 The LDAP definition for the caseIgnoreOrderingMatch rule is: 1450 ( 2.5.13.3 NAME 'caseIgnoreOrderingMatch' 1451 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 1453 The caseIgnoreOrderingMatch rule is an ordering matching rule. 1455 4.2.9. caseIgnoreSubstringsMatch 1457 The caseIgnoreSubstringsMatch rule compares an assertion value of the 1458 Substring Assertion syntax to an attribute value of a syntax (e.g., 1459 the Directory String, Printable String, Country String or Telephone 1460 Number syntax) whose corresponding ASN.1 type is DirectoryString or 1461 one of its alternative string types. 1463 The rule evaluates to TRUE if and only if the prepared substrings of 1464 the assertion value match disjoint portions of the prepared attribute 1465 value character string in the order of the substrings in the 1466 assertion value, and an substring, if present, matches the 1467 beginning of the prepared attribute value character string, and a 1468 substring, if present, matches the end of the prepared 1469 attribute value character string. A prepared substring matches a 1470 portion of the prepared attribute value character string if 1471 corresponding characters have the same code point. 1473 In preparing the attribute value and assertion value substrings for 1474 comparison, characters are case folded in the Map preparation step, 1475 and only Insignificant Space Removal is applied in the Insignificant 1476 Character Removal step. 1478 The LDAP definition for the caseIgnoreSubstringsMatch rule is: 1480 ( 2.5.13.4 NAME 'caseIgnoreSubstringsMatch' 1481 SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 ) 1483 The caseIgnoreSubstringsMatch rule is a substrings matching rule. 1485 4.2.10. distinguishedNameMatch 1487 The distinguishedNameMatch rule compares an assertion value of the DN 1488 syntax to an attribute value of a syntax (e.g., the DN syntax) whose 1489 corresponding ASN.1 type is DistinguishedName. 1491 The rule evaluates to TRUE if and only if the attribute value and the 1492 assertion value have the same number of relative distinguished names 1493 and corresponding relative distinguished names (by position) are the 1494 same. A relative distinguished name (RDN) of the assertion value is 1495 the same as an RDN of the attribute value if and only if they have 1496 the same number of attribute value assertions and each attribute 1497 value assertion (AVA) of the first RDN is the same as the AVA of the 1498 second RDN with the same attribute type. The order of the AVAs is 1499 not significant. Also note that a particular attribute type may 1500 appear in at most one AVA in an RDN. Two AVAs with the same 1501 attribute type are the same if their values are equal according to 1502 the equality matching rule of the attribute type. If one or more of 1503 the AVA comparisons evaluate to Undefined and the remaining AVA 1504 comparisons return TRUE then the distinguishedNameMatch rule 1505 evaluates to Undefined. 1507 The LDAP definition for the distinguishedNameMatch rule is: 1509 ( 2.5.13.1 NAME 'distinguishedNameMatch' 1510 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 ) 1512 The distinguishedNameMatch rule is an equality matching rule. 1514 4.2.11. generalizedTimeMatch 1516 The generalizedTimeMatch rule compares an assertion value of the 1517 Generalized Time syntax to an attribute value of a syntax (e.g the 1518 Generalized Time syntax) whose corresponding ASN.1 type is 1519 GeneralizedTime. 1521 The rule evaluates to TRUE if and only if the attribute value 1522 represents the same universal coordinated time as the assertion 1523 value. If a time is specified with the minutes or seconds absent 1524 then the number of minutes or seconds (respectively) is assumed to be 1525 zero. 1527 The LDAP definition for the generalizedTimeMatch rule is: 1529 ( 2.5.13.27 NAME 'generalizedTimeMatch' 1530 SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 ) 1532 The generalizedTimeMatch rule is an equality matching rule. 1534 4.2.12. generalizedTimeOrderingMatch 1536 The generalizedTimeOrderingMatch rule compares the time ordering of 1537 an assertion value of the Generalized Time syntax to an attribute 1538 value of a syntax (e.g the Generalized Time syntax) whose 1539 corresponding ASN.1 type is GeneralizedTime. 1541 The rule evaluates to TRUE if and only if the attribute value 1542 represents a universal coordinated time which is earlier than the 1543 universal coordinated time represented by the assertion value. 1545 The LDAP definition for the generalizedTimeOrderingMatch rule is: 1547 ( 2.5.13.28 NAME 'generalizedTimeOrderingMatch' 1548 SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 ) 1550 The generalizedTimeOrderingMatch rule is an ordering matching rule. 1552 4.2.13. integerFirstComponentMatch 1554 The integerFirstComponentMatch rule compares an assertion value of 1555 the Integer syntax to an attribute value of a syntax (e.g the DIT 1556 Structure Rule Description syntax) whose corresponding ASN.1 type is 1557 a SEQUENCE with a mandatory first component of the INTEGER ASN.1 1558 type. 1560 Note that the assertion syntax of this matching rule differs from the 1561 attribute syntax of attributes for which this is the equality 1562 matching rule. 1564 The rule evaluates to TRUE if and only if the assertion value and the 1565 first component of the attribute value are the same integer value. 1567 The LDAP definition for the integerFirstComponentMatch matching rule 1568 is: 1570 ( 2.5.13.29 NAME 'integerFirstComponentMatch' 1571 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 ) 1573 The integerFirstComponentMatch rule is an equality matching rule. 1574 When using integerFirstComponentMatch to compare two attribute values 1575 (of an applicable syntax), an assertion value must first be derived 1576 from one of the attribute values. An assertion value can be derived 1577 from an attribute value by taking the first component of that 1578 attribute value. 1580 4.2.14. integerMatch 1582 The integerMatch rule compares an assertion value of the Integer 1583 syntax to an attribute value of a syntax (e.g the Integer syntax) 1584 whose corresponding ASN.1 type is INTEGER. 1586 The rule evaluates to TRUE if and only if the attribute value and the 1587 assertion value are the same integer value. 1589 The LDAP definition for the integerMatch matching rule is: 1591 ( 2.5.13.14 NAME 'integerMatch' 1592 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 ) 1594 The integerMatch rule is an equality matching rule. 1596 4.2.15. numericStringMatch 1598 The numericStringMatch rule compares an assertion value of the 1599 Numeric String syntax to an attribute value of a syntax (e.g the 1600 Numeric String syntax) whose corresponding ASN.1 type is 1601 NumericString. 1603 The rule evaluates to TRUE if and only if the prepared attribute 1604 value character string and the prepared assertion value character 1605 string have the same number of characters and corresponding 1606 characters have the same code point. 1608 In preparing the attribute value and assertion value for comparison, 1609 characters are not case folded in the Map preparation step, and only 1610 numericString Insignificant Character Removal is applied in the 1611 Insignificant Character Removal step. 1613 The LDAP definition for the numericStringMatch matching rule is: 1615 ( 2.5.13.8 NAME 'numericStringMatch' 1616 SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 ) 1618 The numericStringMatch rule is an equality matching rule. 1620 4.2.16. numericStringSubstringsMatch 1622 The numericStringSubstringsMatch rule compares an assertion value of 1623 the Substring Assertion syntax to an attribute value of a syntax (e.g 1624 the Numeric String syntax) whose corresponding ASN.1 type is 1625 NumericString. 1627 The rule evaluates to TRUE if and only if the prepared substrings of 1628 the assertion value match disjoint portions of the prepared attribute 1629 value character string in the order of the substrings in the 1630 assertion value, and an substring, if present, matches the 1631 beginning of the prepared attribute value character string, and a 1632 substring, if present, matches the end of the prepared 1633 attribute value character string. A prepared substring matches a 1634 portion of the prepared attribute value character string if 1635 corresponding characters have the same code point. 1637 In preparing the attribute value and assertion value for comparison, 1638 characters are not case folded in the Map preparation step, and only 1639 numericString Insignificant Character Removal is applied in the 1640 Insignificant Character Removal step. 1642 The LDAP definition for the numericStringSubstringsMatch matching 1643 rule is: 1645 ( 2.5.13.10 NAME 'numericStringSubstringsMatch' 1646 SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 ) 1648 The numericStringSubstringsMatch rule is a substrings matching rule. 1650 4.2.17. objectIdentifierFirstComponentMatch 1652 The objectIdentifierFirstComponentMatch rule compares an assertion 1653 value of the OID syntax to an attribute value of a syntax (e.g the 1654 Attribute Type Description, DIT Content Rule Description, LDAP Syntax 1655 Description, Matching Rule Description, Matching Rule Use 1656 Description, Name Form Description or Object Class Description 1657 syntax) whose corresponding ASN.1 type is a SEQUENCE with a mandatory 1658 first component of the OBJECT IDENTIFIER ASN.1 type. 1660 Note that the assertion syntax of this matching rule differs from the 1661 attribute syntax of attributes for which this is the equality 1662 matching rule. 1664 The rule evaluates to TRUE if and only if the assertion value matches 1665 the first component of the attribute value using the rules of 1666 objectIdentifierMatch. 1668 The LDAP definition for the objectIdentifierFirstComponentMatch 1669 matching rule is: 1671 ( 2.5.13.31 NAME 'objectIdentifierFirstComponentMatch' 1672 SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 ) 1674 The objectIdentifierFirstComponentMatch rule is an equality matching 1675 rule. When using objectIdentifierFirstComponentMatch to compare two 1676 attribute values (of an applicable syntax), an assertion value must 1677 first be derived from one of the attribute values. An assertion 1678 value can be derived from an attribute value by taking the first 1679 component of that attribute value. 1681 4.2.18. objectIdentifierMatch 1683 The objectIdentifierMatch rule compares an assertion value of the OID 1684 syntax to an attribute value of a syntax (e.g the OID syntax) whose 1685 corresponding ASN.1 type is OBJECT IDENTIFIER. 1687 The rule evaluates to TRUE if and only if the assertion value and the 1688 attribute value represent the same object identifier, that is, the 1689 same sequence of integers, whether represented explicitly in the 1690 form of or implicitly in the form (see 1691 [MODELS]). 1693 If an LDAP client supplies an assertion value in the form, 1694 and the chosen descriptor is not recognized by the server, then the 1695 objectIdentifierMatch rule evaluates to Undefined. 1697 The LDAP definition for the objectIdentifierMatch matching rule is: 1699 ( 2.5.13.0 NAME 'objectIdentifierMatch' 1700 SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 ) 1702 The objectIdentifierMatch rule is an equality matching rule. 1704 4.2.19. octetStringMatch 1706 The octetStringMatch rule compares an assertion value of the Octet 1707 String syntax to an attribute value of a syntax (e.g the Octet String 1708 or JPEG syntax) whose corresponding ASN.1 type is the OCTET STRING 1709 ASN.1 type. 1711 The rule evaluates to TRUE if and only if the attribute value and the 1712 assertion value are the same length and corresponding octets (by 1713 position) are the same. 1715 The LDAP definition for the octetStringMatch matching rule is: 1717 ( 2.5.13.17 NAME 'octetStringMatch' 1718 SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 ) 1720 The octetStringMatch rule is an equality matching rule. 1722 4.2.20. telephoneNumberMatch 1724 The telephoneNumberMatch rule compares an assertion value of the 1725 Telephone Number syntax to an attribute value of a syntax (e.g the 1726 Telephone Number syntax) whose corresponding ASN.1 type is a 1727 PrintableString representing a telephone number. 1729 The rule evaluates to TRUE if and only if the prepared attribute 1730 value character string and the prepared assertion value character 1731 string have the same number of characters and corresponding 1732 characters have the same code point. 1734 In preparing the attribute value and assertion value for comparison, 1735 characters are case folded in the Map preparation step, and only 1736 telephoneNumber Insignificant Character Removal is applied in the 1737 Insignificant Character Removal step. 1739 The LDAP definition for the telephoneNumberMatch matching rule is: 1741 ( 2.5.13.20 NAME 'telephoneNumberMatch' 1742 SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 ) 1744 The telephoneNumberMatch rule is an equality matching rule. 1746 4.2.21. telephoneNumberSubstringsMatch 1748 The telephoneNumberSubstringsMatch rule compares an assertion value 1749 of the Substring Assertion syntax to an attribute value of a syntax 1750 (e.g the Telephone Number syntax) whose corresponding ASN.1 type is a 1751 PrintableString representing a telephone number. 1753 The rule evaluates to TRUE if and only if the prepared substrings of 1754 the assertion value match disjoint portions of the prepared attribute 1755 value character string in the order of the substrings in the 1756 assertion value, and an substring, if present, matches the 1757 beginning of the prepared attribute value character string, and a 1758 substring, if present, matches the end of the prepared 1759 attribute value character string. A prepared substring matches a 1760 portion of the prepared attribute value character string if 1761 corresponding characters have the same code point. 1763 In preparing the attribute value and assertion value substrings for 1764 comparison, characters are case folded in the Map preparation step, 1765 and only telephoneNumber Insignificant Character Removal is applied 1766 in the Insignificant Character Removal step. 1768 The LDAP definition for the telephoneNumberSubstringsMatch matching 1769 rule is: 1771 ( 2.5.13.21 NAME 'telephoneNumberSubstringsMatch' 1772 SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 ) 1774 The telephoneNumberSubstringsMatch rule is a substrings matching 1775 rule. 1777 4.2.22. uniqueMemberMatch 1779 The uniqueMemberMatch rule compares an assertion value of the Name 1780 And Optional UID syntax to an attribute value of a syntax (e.g the 1781 Name And Optional UID syntax) whose corresponding ASN.1 type is 1782 NameAndOptionalUID. 1784 The rule evaluates to TRUE if and only if the 1785 components of the assertion value and attribute value match according 1786 to the distinguishedNameMatch rule and the component is 1787 absent from the attribute value or matches the component 1788 of the assertion value according to the bitStringMatch rule. 1790 The LDAP definition for the uniqueMemberMatch matching rule is: 1792 ( 2.5.13.23 NAME 'uniqueMemberMatch' 1793 SYNTAX 1.3.6.1.4.1.1466.115.121.1.34 ) 1795 The uniqueMemberMatch rule is an equality matching rule. 1797 5. Security Considerations 1799 In general, the LDAP-specific encodings for syntaxes defined in this 1800 document do not define canonical encodings. That is, a 1801 transformation from an LDAP-specific encoding into some other 1802 encoding (e.g., BER) and back into the LDAP-specific encoding will 1803 not necessarily reproduce exactly the original octets of the 1804 LDAP-specific encoding. Therefore an LDAP-specific encoding should 1805 not be used where a canonical encoding is required. 1807 Furthermore, the LDAP-specific encodings do not necessarily enable an 1808 alternative encoding of values of the Directory String and DN 1809 syntaxes to be reconstructed, e.g., a transformation from a 1810 Distinguished Encoding Rules (DER) [BER] encoding to an LDAP-specific 1811 encoding and back to a DER encoding may not reproduce the original 1812 DER encoding. Therefore LDAP-specific encodings should not be used 1813 where reversibility to DER is needed, e.g., for the verification of 1814 digital signatures. Instead, DER or a DER-reversible encoding should 1815 be used. 1817 When interpreting security-sensitive fields, and in particular fields 1818 used to grant or deny access, implementations MUST ensure that any 1819 matching rule comparisons are done on the underlying abstract value, 1820 regardless of the particular encoding used. 1822 6. Acknowledgements 1824 This document is an revision of RFC 2252 by M. Wahl, A. Coulbeck, T. 1825 Howes, and S. Kille. RFC 2252 was a product of the IETF ASID Working 1826 Group. 1828 This document is based upon input of the IETF LDAPBIS working group. 1829 The authors wish to thank J. Sermersheim and K. Zeilenga for their 1830 significant contribution to this revision. 1832 7. IANA Considerations 1834 The Internet Assigned Numbers Authority (IANA) is requested to update 1835 the LDAP descriptors registry [BCP64] as indicated by the following 1836 templates: 1838 Subject: Request for LDAP Descriptor Registration Update 1839 Descriptor (short name): see comment 1840 Object Identifier: see comment 1841 Person & email address to contact for further information: 1842 Steven Legg 1843 Usage: see comment 1844 Specification: RFC XXXX 1845 Author/Change Controller: IESG 1846 Comments: 1848 The following descriptors (short names) should be updated to refer 1849 to RFC XXXX. 1851 NAME Type OID 1852 ------------------------------------------------------------------ 1853 bitStringMatch M 2.5.13.16 1854 caseExactIA5Match M 1.3.6.1.4.1.1466.109.114.1 1855 caseIgnoreIA5Match M 1.3.6.1.4.1.1466.109.114.2 1856 caseIgnoreListMatch M 2.5.13.11 1857 caseIgnoreMatch M 2.5.13.2 1858 caseIgnoreOrderingMatch M 2.5.13.3 1859 caseIgnoreSubstringsMatch M 2.5.13.4 1860 distinguishedNameMatch M 2.5.13.1 1861 generalizedTimeMatch M 2.5.13.27 1862 generalizedTimeOrderingMatch M 2.5.13.28 1863 integerFirstComponentMatch M 2.5.13.29 1864 integerMatch M 2.5.13.14 1865 numericStringMatch M 2.5.13.8 1866 numericStringSubstringsMatch M 2.5.13.10 1867 objectIdentifierFirstComponentMatch M 2.5.13.31 1868 octetStringMatch M 2.5.13.17 1869 telephoneNumberMatch M 2.5.13.20 1870 telephoneNumberSubstringsMatch M 2.5.13.21 1871 uniqueMemberMatch M 2.5.13.23 1873 The descriptor for the object identifier 2.5.13.0 was incorrectly 1874 registered as objectIdentifiersMatch (extraneous `s') in BCP 64. 1875 It should be changed to the following with a reference to RFC 1876 XXXX. 1878 NAME Type OID 1879 ------------------------------------------------------------------ 1880 objectIdentifierMatch M 2.5.13.0 1882 Subject: Request for LDAP Descriptor Registration 1883 Descriptor (short name): caseIgnoreIA5SubstringsMatch 1884 Object Identifier: 1.3.6.1.4.1.1466.109.114.3 1885 Person & email address to contact for further information: 1886 Steven Legg 1887 Usage: other (M) 1888 Specification: RFC XXXX 1889 Author/Change Controller: IESG 1891 Subject: Request for LDAP Descriptor Registration 1892 Descriptor (short name): caseIgnoreListSubstringsMatch 1893 Object Identifier: 2.5.13.12 1894 Person & email address to contact for further information: 1895 Steven Legg 1896 Usage: other (M) 1897 Specification: RFC XXXX 1898 Author/Change Controller: IESG 1900 8. References 1902 8.1. Normative References 1904 [KEYWORD] Bradner, S., "Key words for use in RFCs to Indicate 1905 Requirement Levels", BCP 14, RFC 2119, March 1997. 1907 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1908 Specifications: ABNF", RFC 2234, November 1997. 1910 [UTF8] Yergeau, F., "UTF-8, a transformation format of ISO 1911 10646", draft-yergeau-rfc2279bis-xx.txt, a work in 1912 progress, June 2003. 1914 [BCP64] Zeilenga, K., "Internet Assigned Numbers Authority (IANA) 1915 Considerations for the Lightweight Directory Access 1916 Protocol (LDAP)", BCP 64, RFC 3383, September 2002. 1918 [LDAPDN] Zeilenga, K., "LDAP: String Representation of 1919 Distinguished Names", draft-ietf-ldapbis-dn-xx.txt, a work 1920 in progress, June 2003. 1922 [PROT] Sermersheim, J., "LDAP: The Protocol", draft-ietf-ldapbis- 1923 protocol-xx.txt, a work in progress, September 2003. 1925 [E.123] Notation for national and international telephone numbers, 1926 ITU-T Recommendation E.123, 1988. 1928 [FAX] Standardization of Group 3 facsimile apparatus for 1929 document transmission - Terminal Equipment and Protocols 1930 for Telematic Services, ITU-T Recommendation T.4, 1993 1932 [T.50] International Reference Alphabet (IRA) (Formerly 1933 International Alphabet No. 5 or IA5) Information 1934 Technology - 7-Bit Coded Character Set for Information 1935 Interchange, ITU-T Recommendation T.50, 1992 1937 [X.420] ITU-T Recommendation X.420 (1996) | ISO/IEC 10021-7:1997, 1938 Information Technology - Message Handling Systems (MHS): 1939 Interpersonal messaging system 1941 [X.501] ITU-T Recommendation X.501 (1993) | ISO/IEC 9594-2:1994, 1942 Information Technology - Open Systems Interconnection - 1943 The Directory: Models 1945 [X.520] ITU-T Recommendation X.520 (1993) | ISO/IEC 9594-6:1994, 1946 Information Technology - Open Systems Interconnection - 1947 The Directory: Selected attribute types 1949 [ASN.1] ITU-T Recommendation X.680 (07/02) | ISO/IEC 8824-1:2002, 1950 Information technology - Abstract Syntax Notation One 1951 (ASN.1): Specification of basic notation 1953 [ISO3166] ISO 3166, "Codes for the representation of names of 1954 countries". 1956 [UCS] Universal Multiple-Octet Coded Character Set (UCS) - 1957 Architecture and Basic Multilingual Plane, ISO/IEC 1958 10646-1: 1993 (with amendments). 1960 [JPEG] JPEG File Interchange Format (Version 1.02). Eric 1961 Hamilton, C-Cube Microsystems, Milpitas, CA, September 1, 1962 1992. 1964 [ROADMAP] Zeilenga, K., "LDAP: Technical Specification Road Map", 1965 draft-ietf-ldapbis-roadmap-xx.txt, a work in progress, 1966 June 2003. 1968 [MODELS] Zeilenga, K., "LDAP: Directory Information Models", draft- 1969 ietf-ldapbis-models-xx.txt, a work in progress, June 2003. 1971 [PREP] Zeilenga, K., "LDAP: Internationalized String 1972 Preparation", draft-ietf-ldapbis-strprep-xx.txt, a work in 1973 progress, June 2003. 1975 8.2. Informative References 1977 [RFC2252] Wahl, M., Coulbeck, A., Howes, T. and S. Kille, 1978 "Lightweight Directory Access Protocol (v3): Attribute 1979 Syntax Definitions", RFC 2252, December 1997. 1981 [RFC2256] Wahl, M., "A Summary of the X.500(96) User Schema for use 1982 with LDAPv3", RFC 2256, December 1997. 1984 [RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access 1985 Protocol (v3): Technical Specification", RFC 3377, 1986 September 2002. 1988 [SCHEMA] Dally, K., "LDAP: Schema for User Applications", draft- 1989 ietf-ldapbis-user-schema-xx.txt, a work in progress, June 1990 2003. 1992 [LDAP-PKI] Chadwick, D. W. and S. Legg, "LDAP Schema and Syntaxes for 1993 PKIs", draft-ietf-pkix-ldap-pki-schema-xx.txt, a work in 1994 progress, July 2002. 1996 [X.500] ITU-T Recommendation X.500 (1993) | ISO/IEC 9594-1:1994, 1997 Information Technology - Open Systems Interconnection - 1998 The Directory: Overview of concepts, models and services 2000 [BER] ITU-T Recommendation X.690 (07/02) | ISO/IEC 8825-1:2002, 2001 Information technology - ASN.1 encoding rules: 2002 Specification of Basic Encoding Rules (BER), Canonical 2003 Encoding Rules (CER) and Distinguished Encoding Rules 2004 (DER) 2006 9. Authors' Addresses 2008 Steven Legg 2009 Adacel Technologies Ltd. 2010 250 Bay Street 2011 Brighton, Victoria 3186 2012 AUSTRALIA 2014 Phone: +61 3 8530 7710 2015 Fax: +61 3 8530 7888 2016 Email: steven.legg@adacel.com.au 2018 Kathy Dally 2019 The MITRE Corp. 2020 7515 Colshire Dr., ms-W650 2021 McLean VA 22102 2022 USA 2024 Phone: +1 703 883 6058 2025 Fax: +1 703 883 7142 2026 Email: kdally@mitre.org 2028 10. Intellectual Property Notice 2030 The IETF takes no position regarding the validity or scope of any 2031 intellectual property or other rights that might be claimed to 2032 pertain to the implementation or use of the technology described in 2033 this document or the extent to which any license under such rights 2034 might or might not be available; neither does it represent that it 2035 has made any effort to identify any such rights. Information on the 2036 IETF's procedures with respect to rights in standards-track and 2037 standards-related documentation can be found in BCP-11. Copies of 2038 claims of rights made available for publication and any assurances of 2039 licenses to be made available, or the result of an attempt made to 2040 obtain a general license or permission for the use of such 2041 proprietary rights by implementors or users of this specification can 2042 be obtained from the IETF Secretariat. 2044 The IETF invites any interested party to bring to its attention any 2045 copyrights, patents or patent applications, or other proprietary 2046 rights which may cover technology that may be required to practice 2047 this standard. Please address the information to the IETF Executive 2048 Director. 2050 Appendix A. Summary of Syntax Object Identifiers 2052 The following list summarizes the object identifiers assigned to the 2053 syntaxes defined in this document. 2055 Syntax OBJECT IDENTIFIER 2056 ============================================================== 2057 Attribute Type Description 1.3.6.1.4.1.1466.115.121.1.3 2058 Bit String 1.3.6.1.4.1.1466.115.121.1.6 2059 Boolean 1.3.6.1.4.1.1466.115.121.1.7 2060 Country String 1.3.6.1.4.1.1466.115.121.1.11 2061 Delivery Method 1.3.6.1.4.1.1466.115.121.1.14 2062 Directory String 1.3.6.1.4.1.1466.115.121.1.15 2063 DIT Content Rule Description 1.3.6.1.4.1.1466.115.121.1.16 2064 DIT Structure Rule Description 1.3.6.1.4.1.1466.115.121.1.17 2065 DN 1.3.6.1.4.1.1466.115.121.1.12 2066 Enhanced Guide 1.3.6.1.4.1.1466.115.121.1.21 2067 Facsimile Telephone Number 1.3.6.1.4.1.1466.115.121.1.22 2068 Fax 1.3.6.1.4.1.1466.115.121.1.23 2069 Generalized Time 1.3.6.1.4.1.1466.115.121.1.24 2070 Guide 1.3.6.1.4.1.1466.115.121.1.25 2071 IA5 String 1.3.6.1.4.1.1466.115.121.1.26 2072 Integer 1.3.6.1.4.1.1466.115.121.1.27 2073 JPEG 1.3.6.1.4.1.1466.115.121.1.28 2074 LDAP Syntax Description 1.3.6.1.4.1.1466.115.121.1.54 2075 Matching Rule Description 1.3.6.1.4.1.1466.115.121.1.30 2076 Matching Rule Use Description 1.3.6.1.4.1.1466.115.121.1.31 2077 Name And Optional UID 1.3.6.1.4.1.1466.115.121.1.34 2078 Name Form Description 1.3.6.1.4.1.1466.115.121.1.35 2079 Numeric String 1.3.6.1.4.1.1466.115.121.1.36 2080 Object Class Description 1.3.6.1.4.1.1466.115.121.1.37 2081 Octet String 1.3.6.1.4.1.1466.115.121.1.40 2082 OID 1.3.6.1.4.1.1466.115.121.1.38 2083 Other Mailbox 1.3.6.1.4.1.1466.115.121.1.39 2084 Postal Address 1.3.6.1.4.1.1466.115.121.1.41 2085 Printable String 1.3.6.1.4.1.1466.115.121.1.44 2086 Substring Assertion 1.3.6.1.4.1.1466.115.121.1.58 2087 Telephone Number 1.3.6.1.4.1.1466.115.121.1.50 2088 Teletex Terminal Identifier 1.3.6.1.4.1.1466.115.121.1.51 2089 Telex Number 1.3.6.1.4.1.1466.115.121.1.52 2090 UTC Time 1.3.6.1.4.1.1466.115.121.1.53 2092 Appendix B. Changes from RFC 2252 & RFC 2256 2094 This annex lists the significant differences between this 2095 specification and RFC 2252 and Sections 6 and 8 of RFC 2256. 2097 This annex is provided for informational purposes only. It is not a 2098 normative part of this specification. 2100 1. The IESG Note has been removed. 2102 2. The major part of Sections 4, 5 and 7 has been moved to [MODELS] 2103 and revised. Changes to the parts of these sections moved to 2104 [MODELS] are detailed in [MODELS]. 2106 3. BNF descriptions of syntax formats have been replaced by ABNF 2107 [ABNF] specifications. 2109 4. The ambiguous statement in RFC 2252, Section 4.3 regarding the 2110 use of a backslash quoting mechanism to escape separator symbols 2111 has been removed. The escaping mechanism is now explicitly 2112 represented in the ABNF for the syntaxes where this provision 2113 applies. 2115 5. The description of each of the LDAP syntaxes has been expanded so 2116 that they are less dependent on knowledge of X.500 for 2117 interpretation. 2119 6. The relationship of LDAP syntaxes to corresponding ASN.1 type 2120 definitions has been made explicit. 2122 7. The set of characters allowed in a (formerly 2123 ) has been corrected to align with the 2124 PrintableString ASN.1 type in [ASN.1]. Specifically, the double 2125 quote character has been removed and the single quote character 2126 and equals sign have been added. 2128 8. Values of the Directory String, Printable String and Telephone 2129 Number syntaxes are now required to have at least one character. 2131 9. The , and 2132 rules have been moved to [MODELS]. 2134 10. The corresponding ASN.1 type for the Other Mailbox syntax has 2135 been incorporated from RFC 1274. 2137 11. A corresponding ASN.1 type for the LDAP Syntax Description syntax 2138 has been invented. 2140 12. The Binary syntax has been removed because it was not adequately 2141 specified, implementations with different incompatible 2142 interpretations exist, and it was confused with the ;binary 2143 transfer encoding. 2145 13. All discussion of transfer options, including the ";binary" 2146 option, has been removed. All imperatives regarding binary 2147 transfer of values have been removed. 2149 14. The Delivery Method, Enhanced Guide, Guide, Octet String, Teletex 2150 Terminal Identifier and Telex Number syntaxes from RFC 2256 have 2151 been incorporated. 2153 15. The rule for the Enhanced Guide and Guide syntaxes has 2154 been extended to accommodate empty "and" and "or" expressions. 2156 16. An encoding for the rule in the Teletex Terminal 2157 Identifier syntax has been defined. 2159 17. The PKI-related syntaxes (Certificate, Certificate List and 2160 Certificate Pair from RFC 2252, and Supported Algorithm syntax 2161 from RFC 2256) have been removed. They are to be reintroduced in 2162 PKIX documents. 2164 18. The MHS OR Address syntax has been removed since its 2165 specification (in RFC 2156) is not at draft standard maturity. 2167 19. The DL Submit Permission syntax has been removed as it depends on 2168 the MHS OR Address syntax. 2170 20. The Presentation Address syntax has been removed since its 2171 specification (in RFC 1278) is not at draft standard maturity. 2173 21. The ACI Item, Access Point, Audio, Data Quality, DSA Quality, DSE 2174 Type, LDAP Schema Description, Master And Shadow Access Points, 2175 Modify Rights, Protocol Information, Subtree Specification, 2176 Supplier Information, Supplier Or Consumer and Supplier And 2177 Consumer syntaxes have been removed. These syntaxes are 2178 referenced in RFC 2252, but not defined. 2180 22. The LDAP Schema Definition syntax (defined in RFC 2927) and the 2181 Mail Preference syntax have been removed on the grounds that they 2182 are out of scope for a core specification. 2184 23. The description of each of the matching rules has been expanded 2185 so that they are less dependent on knowledge of X.500 for 2186 interpretation. 2188 24. The caseIgnoreIA5SubstringsMatch matching rule from RFC 2798 has 2189 been added. 2191 25. The caseIgnoreListSubstringsMatch, caseIgnoreOrderingMatch and 2192 caseIgnoreSubstringsMatch matching rules have been added to the 2193 list of matching rules for which the provisions for handling 2194 leading, trailing and multiple adjoining whitespace characters 2195 apply (now through string preparation). This is consistent with 2196 the definitions of these matching rules in X.500. The 2197 caseIgnoreIA5SubstringsMatch rule has also been added to the 2198 list. 2200 26. The specification of the octetStringMatch matching rule from RFC 2201 2256 has been added to this document. 2203 27. The presentationAddressMatch matching rule has been removed as it 2204 depends on an assertion syntax (Presentation Address) that is not 2205 at draft standard maturity. 2207 28. The protocolInformationMatch matching rule has been removed as it 2208 depends on an undefined assertion syntax (Protocol Information). 2210 29. The definitive reference for ASN.1 has been changed from X.208 to 2211 X.680 since X.680 is the version of ASN.1 referred to by X.500. 2213 30. The specification of the caseIgnoreListSubstringsMatch matching 2214 rule from RFC 2798 & X.520 has been added to this document. 2216 31. String preparation algorithms have been applied to the character 2217 string matching rules. 2219 Full Copyright Statement 2220 Copyright (C) The Internet Society (2003). All Rights Reserved. 2222 This document and translations of it may be copied and furnished to 2223 others, and derivative works that comment on or otherwise explain it 2224 or assist in its implementation may be prepared, copied, published 2225 and distributed, in whole or in part, without restriction of any 2226 kind, provided that the above copyright notice and this paragraph are 2227 included on all such copies and derivative works. However, this 2228 document itself may not be modified in any way, such as by removing 2229 the copyright notice or references to the Internet Society or other 2230 Internet organizations, except as needed for the purpose of 2231 developing Internet standards in which case the procedures for 2232 copyrights defined in the Internet Standards process must be 2233 followed, or as required to translate it into languages other than 2234 English. 2236 The limited permissions granted above are perpetual and will not be 2237 revoked by the Internet Society or its successors or assignees. 2239 This document and the information contained herein is provided on an 2240 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 2241 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 2242 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 2243 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 2244 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.