idnits 2.17.1 draft-ietf-ldapbis-syntaxes-04.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 45 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 exact meaning of the all-uppercase expression 'NOT REQUIRED' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. -- 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 (20 December 2002) is 7798 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) == Missing Reference: 'ROADMAP' is mentioned on line 153, but not defined == Missing Reference: 'MODELS' is mentioned on line 1976, but not defined -- Looks like a reference, but probably isn't: '3' on line 574 == Missing Reference: 'ISO8601' is mentioned on line 583, but not defined ** Obsolete normative reference: RFC 2234 (ref. 'ABNF') (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 2279 (ref. 'UTF-8') (Obsoleted by RFC 3629) ** Obsolete normative reference: RFC 3383 (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' -- 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) Summary: 4 errors (**), 0 flaws (~~), 6 warnings (==), 17 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-04.txt Adacel Technologies 4 Intended Category: Standard Track K. Dally 5 Obsoletes: RFC 2252, RFC 2256 The MITRE Corp. 6 20 December 2002 8 LDAP: Syntaxes and Matching Rules 10 Copyright (C) The Internet Society (2002). 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 20 June 2003. 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 1. Table of Contents 57 Abstract ...................................................... 1 58 1. Table of Contents ............................................. 3 59 2. Introduction .................................................. 4 60 3. Conventions ................................................... 5 61 4. Syntaxes ...................................................... 5 62 4.1 General Considerations .................................... 5 63 4.2 Common Definitions ........................................ 6 64 4.3 Syntax Definitions ........................................ 7 65 4.3.1 Attribute Type Description ........................... 7 66 4.3.2 Bit String ........................................... 7 67 4.3.3 Boolean .............................................. 8 68 4.3.4 Country String ....................................... 8 69 4.3.5 Delivery Method ...................................... 9 70 4.3.6 Directory String ..................................... 9 71 4.3.7 DIT Content Rule Description ......................... 10 72 4.3.8 DIT Structure Rule Description ....................... 11 73 4.3.9 DN ................................................... 11 74 4.3.10 Enhanced Guide ...................................... 12 75 4.3.11 Facsimile Telephone Number .......................... 13 76 4.3.12 Fax ................................................. 13 77 4.3.13 Generalized Time .................................... 14 78 4.3.14 Guide ............................................... 15 79 4.3.15 IA5 String .......................................... 15 80 4.3.16 Integer ............................................. 16 81 4.3.17 JPEG ................................................ 16 82 4.3.18 LDAP Syntax Description ............................. 16 83 4.3.19 Matching Rule Description ........................... 17 84 4.3.20 Matching Rule Use Description ....................... 17 85 4.3.21 Name and Optional UID ............................... 18 86 4.3.22 Name Form Description ............................... 18 87 4.3.23 Numeric String ...................................... 19 88 4.3.24 Object Class Description ............................ 19 89 4.3.25 Octet String ........................................ 20 90 4.3.26 OID ................................................. 20 91 4.3.27 Other Mailbox ....................................... 20 92 4.3.28 Postal Address ...................................... 21 93 4.3.29 Printable String .................................... 22 94 4.3.30 Substring Assertion ................................. 22 95 4.3.31 Telephone Number .................................... 23 96 4.3.32 Teletex Terminal Identifier ......................... 24 97 4.3.33 Telex Number ........................................ 24 98 4.3.34 UTC Time ............................................ 25 99 5. Matching Rules ................................................ 26 100 5.1 General Considerations .................................... 26 101 5.2 Matching Rule Definitions ................................. 27 102 5.2.1 bitStringMatch ....................................... 27 103 5.2.2 caseExactIA5Match .................................... 28 104 5.2.3 caseIgnoreIA5Match ................................... 28 105 5.2.4 caseIgnoreIA5SubstringsMatch ......................... 29 106 5.2.5 caseIgnoreListMatch .................................. 29 107 5.2.6 caseIgnoreMatch ...................................... 30 108 5.2.7 caseIgnoreOrderingMatch .............................. 30 109 5.2.8 caseIgnoreSubstringsMatch ............................ 31 110 5.2.9 distinguishedNameMatch ............................... 31 111 5.2.10 generalizedTimeMatch ................................ 32 112 5.2.11 generalizedTimeOrderingMatch ........................ 32 113 5.2.12 integerFirstComponentMatch .......................... 32 114 5.2.13 integerMatch ........................................ 33 115 5.2.14 numericStringMatch .................................. 33 116 5.2.15 numericStringSubstringsMatch ........................ 34 117 5.2.16 objectIdentifierFirstComponentMatch ................. 34 118 5.2.17 objectIdentifierMatch ............................... 35 119 5.2.18 octetStringMatch .................................... 35 120 5.2.19 telephoneNumberMatch ................................ 36 121 5.2.20 telephoneNumberSubstringsMatch ...................... 36 122 5.2.21 uniqueMemberMatch ................................... 37 123 6. Security Considerations ....................................... 37 124 7. Acknowledgements .............................................. 38 125 8. IANA Considerations ........................................... 38 126 9. Normative References .......................................... 39 127 10. Informative References ....................................... 40 128 11. Authors' Addresses ........................................... 41 129 12. Copyright Notice ............................................. 41 130 Appendix A. Summary of Syntax Object Identifiers ................. 42 131 Appendix B. Changes from RFC 2252 & RFC 2256 ..................... 43 133 2. Introduction 135 Each attribute stored in a Lightweight Directory Access Protocol 136 (LDAP) directory [ROADMAP], and whose values may be transfered in the 137 LDAP protocol [PROT], has a defined syntax (i.e. data type) which 138 constrains the structure and format of its values. The comparison 139 semantics for values of a syntax are not part of the syntax 140 definition but are instead provided through separately defined 141 matching rules. Matching rules specify an argument, an assertion 142 value, which also has a defined syntax. This document defines a base 143 set of syntaxes and matching rules for use in defining attributes for 144 LDAP directories. 146 Readers are advised to familiarize themselves with the Directory 147 Information Models [MODELS] before reading the rest of this document. 148 Section 4 provides definitions for the base set of LDAP syntaxes. 149 Section 5 provides definitions for the base set of matching rules for 150 LDAP. 152 This document is a integral part of the LDAP technical specification 153 [ROADMAP] which obsoletes the previously defined LDAP technical 154 specification [RFC3377] in its entirety. 156 Sections 4, 5 and 7 of RFC 2252 [RFC2252] are obsoleted by [MODELS]. 157 The remainder of RFC 2252 is obsoleted by this document. Sections 6 158 and 8 of RFC 2256 are obsoleted by this document. The changes from 159 RFC 2252 and RFC 2256 [RFC2256] are described in Appendix B of this 160 document. 162 3. Conventions 164 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 165 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 166 document are to be interpreted as described in RFC 2119 [KEYWORD]. 168 Syntax definitions are written according to the 169 ABNF [ABNF] rule specified in [MODELS], and matching rule definitions 170 are written according to the ABNF rule 171 specified in [MODELS], except that the syntax and matching rule 172 definitions provided in this document are line-wrapped for 173 readability. When such definitions are transfered as attribute 174 values in the LDAP protocol (e.g. as values of the ldapSyntaxes and 175 matchingRules attributes [MODELS] respectively) then those values 176 would not contain line breaks. 178 4. Syntaxes 180 Syntax definitions constrain the structure of attribute values stored 181 in an LDAP directory, and determine the representation of attribute 182 and assertion values transfered in the LDAP protocol. 184 Syntaxes that are required for directory operation, or that are in 185 common use, are specified in this section. Servers SHOULD recognize 186 all the syntaxes listed in this document, but are NOT REQUIRED to 187 otherwise support them, and MAY recognise or support other syntaxes. 188 However, the definition of additional arbitrary syntaxes is 189 discouraged since it will hinder interoperability. Client and server 190 implementations typically do not have the ability to dynamically 191 recognize new syntaxes. 193 4.1 General Considerations 194 The description of each syntax specifies how attribute or assertion 195 values conforming to the syntax are to be represented when transfered 196 in the LDAP protocol [PROT]. This representation is referred to as 197 the LDAP-specific encoding to distinguish it from other methods of 198 encoding attribute values (e.g. the BER encoding [BER] used by X.500 199 [X.500] directories). 201 The LDAP-specific encoding of a given attribute syntax always 202 produces octet-aligned values. To the greatest extent possible, 203 encoding rules for LDAP syntaxes should produce character strings 204 that can be displayed with little or no translation by clients 205 implementing LDAP. However, clients MUST NOT assume that the 206 LDAP-specific encoding of a value of an unrecognized syntax is a 207 human-readable character string. There are a few cases (e.g. the 208 JPEG syntax) when it is not reasonable to produce a human-readable 209 representation. 211 Each LDAP syntax is uniquely identified with an object identifier 212 [ASN.1] represented in the dotted-decimal format (short descriptive 213 names are not defined for syntaxes). These object identifiers are 214 not intended to be displayed to users. The object identifiers for 215 the syntaxes defined in this document are summarized in Appendix A. 217 A suggested minimum upper bound on the number of characters in an 218 attribute value with a string-based syntax, or the number of octets 219 in a value for all other syntaxes, MAY be indicated by appending the 220 bound inside of curly braces following the syntax's OBJECT IDENTIFIER 221 in an attribute type definition (see the rule in [MODELS]). 222 Such a bound is not considered part of the syntax identifier. 224 For example, "1.3.6.1.4.1.1466.115.121.1.15{64}" in an attribute 225 definition suggests that the directory server will allow a value of 226 the attribute to be up to 64 characters long, although it may allow 227 longer character strings. Note that a single character of the 228 Directory String syntax can be encoded in more than one octet since 229 UTF-8 [UTF-8] is a variable-length encoding. Therefore a 64 230 character string may be more than 64 octets in length. 232 4.2 Common Definitions 234 The following ABNF rules are used in a number of the syntax 235 definitions in Section 4.3. 237 PrintableCharacter = ALPHA / DIGIT / SQUOTE / LPAREN / RPAREN / 238 PLUS / COMMA / HYPHEN / DOT / EQUALS / 239 SLASH / COLON / QUESTION / SPACE 240 PrintableString = 1*PrintableCharacter 241 IA5String = *(%x00-7F) 242 HEX-DIGIT = DIGIT / "A" / "B" / "C" / "D" / "E" / "F" 243 ; N.B. allows upper and lower case 244 SLASH = %x2F ; forward slash ("/") 245 COLON = %x3A ; colon (":") 246 QUESTION = %x3F ; question mark ("?") 248 The , , , , , , , 249 , , , and rules are defined in 250 [MODELS]. 252 4.3 Syntax Definitions 254 4.3.1 Attribute Type Description 256 A value of the Attribute Type Description syntax is the definition of 257 an attribute type. The LDAP-specific encoding of a value of this 258 syntax is defined by the rule in [MODELS]. 259 For example, the following definition of the createTimestamp 260 attribute type from [MODELS] is also a value of the Attribute Type 261 Description syntax (note: line breaks have been added for readability 262 - they are not part of the value when transfered in protocol). 264 ( 2.5.18.1 NAME 'createTimestamp' 265 EQUALITY generalizedTimeMatch 266 ORDERING generalizedTimeOrderingMatch 267 SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 268 SINGLE-VALUE NO-USER-MODIFICATION 269 USAGE directoryOperation ) 271 The LDAP definition for the Attribute Type Description syntax is: 273 ( 1.3.6.1.4.1.1466.115.121.1.3 DESC 'Attribute Type Description' ) 275 This syntax corresponds to the AttributeTypeDescription ASN.1 type 276 from [X.501]. 278 4.3.2 Bit String 280 A value of the Bit String syntax is a sequence of binary digits. The 281 LDAP-specific encoding of a value of this syntax is defined by the 282 following ABNF: 284 BitString = SQUOTE *binary-digit SQUOTE "B" 285 binary-digit = "0" / "1" 287 The rule is defined in [MODELS]. 289 Example: 290 '0101111101'B 292 The LDAP definition for the Bit String syntax is: 294 ( 1.3.6.1.4.1.1466.115.121.1.6 DESC 'Bit String' ) 296 This syntax corresponds to the BIT STRING ASN.1 type from [ASN.1]. 298 4.3.3 Boolean 300 A value of the Boolean syntax is one of the Boolean values, true or 301 false. The LDAP-specific encoding of a value of this syntax is 302 defined by the following ABNF: 304 Boolean = "TRUE" / "FALSE" 306 The LDAP definition for the Boolean syntax is: 308 ( 1.3.6.1.4.1.1466.115.121.1.7 DESC 'Boolean' ) 310 This syntax corresponds to the BOOLEAN ASN.1 type from [ASN.1]. 312 4.3.4 Country String 314 A value of the Country String syntax is one of the two-character 315 codes from ISO 3166 [ISO3166] for representing a country. The 316 LDAP-specific encoding of a value of this syntax is defined by the 317 following ABNF: 319 CountryString = 2(PrintableCharacter) 321 The rule is defined in Section 4.2. 323 Examples: 324 US 325 AU 327 The LDAP definition for the Country String syntax is: 329 ( 1.3.6.1.4.1.1466.115.121.1.11 DESC 'Country String' ) 331 This syntax corresponds to the following ASN.1 type from [X.520]: 333 PrintableString (SIZE (2)) -- IS 3166 codes only 335 4.3.5 Delivery Method 337 A value of the Delivery Method syntax is a sequence of items that 338 indicate, in preference order, the service(s) by which an entity is 339 willing and/or capable of receiving messages. The LDAP-specific 340 encoding of a value of this syntax is defined by the following ABNF: 342 DeliveryMethod = pdm *( WSP DOLLAR WSP pdm ) 344 pdm = "any" / "mhs" / "physical" / "telex" / "teletex" / 345 "g3fax" / "g4fax" / "ia5" / "videotex" / "telephone" 347 The and rules are defined in [MODELS]. 349 Example: 350 telephone $ videotex 352 The LDAP definition for the Delivery Method syntax is: 354 ( 1.3.6.1.4.1.1466.115.121.1.14 DESC 'Delivery Method' ) 356 This syntax corresponds to the following ASN.1 type from [X.520]: 358 SEQUENCE OF INTEGER { 359 any-delivery-method (0), 360 mhs-delivery (1), 361 physical-delivery (2), 362 telex-delivery (3), 363 teletex-delivery (4), 364 g3-facsimile-delivery (5), 365 g4-facsimile-delivery (6), 366 ia5-terminal-delivery (7), 367 videotex-delivery (8), 368 telephone-delivery (9) } 370 4.3.6 Directory String 372 A value of the Directory String syntax is a string of one or more 373 arbitrary characters from the Universal Character Set (UCS) [UCS]. A 374 zero length character string is not permitted. The LDAP-specific 375 encoding of a value of this syntax is the UTF-8 encoding [UTF-8] of 376 the character string. Such encodings conform to the following ABNF: 378 DirectoryString = 1*UTF8 380 The rule is defined in [MODELS]. 382 Example: 383 This is a value of Directory String containing #!%#@. 385 Servers and clients MUST be prepared to receive arbitrary UCS code 386 points, including code points outside the range of printable ASCII 387 and code points not presently assigned to any character. 389 Attribute type definitions using the Directory String syntax should 390 not restrict the format of Directory String values, e.g. by requiring 391 that the character string conforms to specific patterns described by 392 ABNF. A new syntax should be defined in such cases. 394 The LDAP definition for the Directory String syntax is: 396 ( 1.3.6.1.4.1.1466.115.121.1.15 DESC 'Directory String' ) 398 This syntax corresponds to the DirectoryString parameterized ASN.1 399 type from [X.520]. 401 The DirectoryString ASN.1 type allows a choice between the 402 TeletexString, PrintableString or UniversalString ASN.1 types from 403 [ASN.1]. However, note that the chosen alternative is not indicated 404 in the LDAP-specific encoding of a Directory String value. 406 Implementations which convert Directory String values from the 407 LDAP-specific encoding to the BER encoding used by X.500 must choose 408 an alternative that permits the particular characters in the string, 409 and must convert the characters from the UTF-8 encoding into the 410 character encoding of the chosen alternative. 412 When converting Directory String values from the BER encoding to the 413 LDAP-specific encoding the characters must be converted from the 414 character encoding of the chosen alternative into the UTF-8 encoding. 416 4.3.7 DIT Content Rule Description 418 A value of the DIT Content Rule Description syntax is the definition 419 of a DIT content rule. The LDAP-specific encoding of a value of this 420 syntax is defined by the rule in 421 [MODELS]. 423 Example: 424 ( 2.5.6.4 DESC 'content rule for organization' 425 NOT ( x121Address $ telexNumber ) ) 427 Note: a line break has been added for readability - it is not part of 428 the value. 430 The LDAP definition for the DIT Content Rule Description syntax is: 432 ( 1.3.6.1.4.1.1466.115.121.1.16 433 DESC 'DIT Content Rule Description' ) 435 This syntax corresponds to the DITContentRuleDescription ASN.1 type 436 from [X.501]. 438 4.3.8 DIT Structure Rule Description 440 A value of the DIT Structure Rule Description syntax is the 441 definition of a DIT structure rule. The LDAP-specific encoding of a 442 value of this syntax is defined by the 443 rule in [MODELS]. 445 Example: 446 ( 2 DESC 'organization structure rule' FORM 2.5.15.3 ) 448 The LDAP definition for the DIT Structure Rule Description syntax is: 450 ( 1.3.6.1.4.1.1466.115.121.1.17 451 DESC 'DIT Structure Rule Description' ) 453 This syntax corresponds to the DITStructureRuleDescription ASN.1 type 454 from [X.501]. 456 4.3.9 DN 458 A value of the DN syntax is the (purported) distinguished name of an 459 entry [MODELS]. The LDAP-specific encoding of a value of this syntax 460 is defined by the rule in [LDAPDN]. 462 Examples (from [LDAPDN]): 463 UID=jsmith,DC=example,DC=net 464 OU=Sales+CN=J. Smith,DC=example,DC=net 465 CN=John Smith\, III,DC=example,DC=net 466 CN=Before\0dAfter,DC=example,DC=net 467 1.3.6.1.4.1.1466.0=#04024869,DC=example,DC=com 468 CN=Lu\C4\8Di\C4\87 470 The LDAP definition for the DN syntax is: 472 ( 1.3.6.1.4.1.1466.115.121.1.12 DESC 'DN' ) 474 The DN syntax corresponds to the DistinguishedName ASN.1 type from 475 [X.501]. Note that a BER encoded distinguished name (as used by 476 X.500) re-encoded into the LDAP-specific encoding is not necessarily 477 reversible to the original BER encoding since the chosen string type 478 in any DirectoryString components of the distinguished name is not 479 indicated in the LDAP-specific encoding of the distinguished name 480 (see Section 4.3.6). 482 4.3.10 Enhanced Guide 484 A value of the Enhanced Guide syntax suggests criteria, which consist 485 of combinations of attribute types and filter operators, to be used 486 in constructing filters to search for entries of particular object 487 classes. The Enhanced Guide syntax improves upon the Guide syntax by 488 allowing the recommended depth of the search to be specified. 490 The LDAP-specific encoding of a value of this syntax is defined by 491 the following ABNF: 493 EnhancedGuide = object-class SHARP WSP criteria WSP 494 SHARP WSP subset 495 object-class = WSP oid WSP 496 subset = "baseobject" / "oneLevel" / "wholeSubtree" 498 criteria = and-term *( BAR and-term ) 499 and-term = term *( AMPERSAND term ) 500 term = EXCLAIM term / 501 attributetype DOLLAR match-type / 502 LPAREN criteria RPAREN / 503 true / 504 false 505 match-type = "EQ" / "SUBSTR" / "GE" / "LE" / "APPROX" 506 true = "?true" 507 false = "?false" 508 BAR = %x7C ; vertical bar ("|") 509 AMPERSAND = %x26 ; ampersand ("&") 510 EXCLAIM = %x21 ; exclamation mark ("!") 512 The , , , , , and 513 rules are defined in [MODELS]. 515 The LDAP definition for the Enhanced Guide syntax is: 517 ( 1.3.6.1.4.1.1466.115.121.1.21 DESC 'Enhanced Guide' ) 519 Example: 521 person#(sn$EQ)#oneLevel 523 The Enhanced Guide syntax corresponds to the EnhancedGuide ASN.1 type 524 from [X.520]. The EnhancedGuide type references the Criteria ASN.1 525 type, also from [X.520]. The rule above represents an empty 526 "and" expression in a value of the Criteria type. The rule 527 above represents an empty "or" expression in a value of the Criteria 528 type. 530 4.3.11 Facsimile Telephone Number 532 A value of the Facsimile Telephone Number syntax is a subscriber 533 number of a facsimile device on the public switched telephone 534 network. The LDAP-specific encoding of a value of this syntax is 535 defined by the following ABNF: 537 fax-number = telephone-number *( DOLLAR fax-parameter ) 538 telephone-number = PrintableString 539 fax-parameter = "twoDimensional" / 540 "fineResolution" / 541 "unlimitedLength" / 542 "b4Length" / 543 "a3Width" / 544 "b4Width" / 545 "uncompressed" 547 The is a string of printable characters that 548 complies with the internationally agreed format for representing 549 international telephone numbers [E.123]. The rule 550 is defined in Section 4.2. The rule is defined in [MODELS]. 552 The LDAP definition for the Facsimile Telephone Number syntax is: 554 ( 1.3.6.1.4.1.1466.115.121.1.22 DESC 'Facsimile Telephone Number') 556 The Facsimile Telephone Number syntax corresponds to the 557 FacsimileTelephoneNumber ASN.1 type from [X.520]. 559 4.3.12 Fax 561 A value of the Fax syntax is an image which is produced using the 562 Group 3 facsimile process [FAX] to duplicate an object, such as a 563 memo. The LDAP-specific encoding of a value of this syntax is the 564 string of octets for a Group 3 Fax image as defined in [FAX]. 566 The LDAP definition for the Fax syntax is: 568 ( 1.3.6.1.4.1.1466.115.121.1.23 DESC 'Fax' ) 570 The ASN.1 type corresponding to the Fax syntax is defined as follows, 571 assuming EXPLICIT TAGS: 573 Fax ::= CHOICE { 574 g3-facsimile [3] G3FacsimileBodyPart 575 } 577 The G3FacsimileBodyPart ASN.1 type is defined in [X.420]. 579 4.3.13 Generalized Time 581 A value of the Generalized Time syntax is a character string 582 representing a date and time. The LDAP-specific encoding of a value 583 of this syntax is a restriction of the format defined in [ISO8601], 584 and is described by the following ABNF: 586 century = 2(%x30-39) ; "00" to "99" 587 year = 2(%x30-39) ; "00" to "99" 588 month = ( %x30 %x31-39 ) ; "01" (January) to "09" 589 / ( %x31 %x30-32 ) ; "10" to "12" 590 day = ( %x30 %x31-39 ) ; "01" to "09" 591 / ( %x31-32 %x30-39 ) ; "10" to "29" 592 / ( %x32 %x30-31 ) ; "30" to "31" 593 hour = ( %x30-31 %x30-39 ) / ( %x32 %x30-33 ) ; "00" to "23" 594 minute = %x30-36 %x30-39 ; "00" to "59" 595 second = %x30-36 %x30-39 ; "00" to "59" 597 GeneralizedTime = century year month day hour 598 [ minute [ second ] ] [ fraction ] 599 g-time-zone 600 fraction = ( DOT / COMMA ) 1*(%x30-39) 601 g-time-zone = %x5A ; "Z" 602 / g-differential 603 g-differential = ( MINUS / PLUS ) hour [ minute ] 604 MINUS = %x2D ; minus sign ("-") 606 The , and rules are defined in [MODELS]. 608 The time value represents coordinated universal time (equivalent to 609 Greenwich Mean Time) if the "Z" form of is used, 610 otherwise the value represents a local time in the time zone 611 indicated by . In the latter case, coordinated 612 universal time can be calculated by subtracting the differential from 613 the local time. The "Z" form of SHOULD be used in 614 preference to . 616 Examples: 617 199412161032Z 618 199412160532-0500 620 Both example values represent the same coordinated universal time: 621 40:32 am, December 16, 1994. 623 The LDAP definition for the Generalized Time syntax is: 625 ( 1.3.6.1.4.1.1466.115.121.1.24 DESC 'Generalized Time' ) 627 This syntax corresponds to the GeneralizedTime ASN.1 type from 628 [ASN.1], with the constraint that local time without a differential 629 SHALL NOT be used. 631 4.3.14 Guide 633 A value of the Guide syntax suggests criteria, which consist of 634 combinations of attribute types and filter operators, to be used in 635 constructing filters to search for entries of particular object 636 classes. The Guide syntax is obsolete and should not be used for 637 defining new attribute types. 639 The LDAP-specific encoding of a value of this syntax is defined by 640 the following ABNF: 642 Guide = [ object-class SHARP ] criteria 644 The and rules are defined in Section 645 4.3.10. The rule is defined in [MODELS]. 647 The LDAP definition for the Guide syntax is: 649 ( 1.3.6.1.4.1.1466.115.121.1.25 DESC 'Guide' ) 651 The Guide syntax corresponds to the Guide ASN.1 type from [X.520]. 653 4.3.15 IA5 String 655 A value of the IA5 String syntax is a string of zero, one or more 656 characters from International Alphabet 5 (IA5) [T.50], the 657 international version of the ASCII character set. The LDAP-specific 658 encoding of a value of this syntax is the unconverted string of 659 characters, which conforms to the rule in Section 4.2. 661 The LDAP definition for the IA5 String syntax is: 663 ( 1.3.6.1.4.1.1466.115.121.1.26 DESC 'IA5 String' ) 665 This syntax corresponds to the IA5String ASN.1 type from [ASN.1]. 667 4.3.16 Integer 669 A value of the Integer syntax is a whole number of unlimited 670 magnitude. The LDAP-specific encoding of a value of this syntax is 671 the optionally signed decimal digit character string representation 672 of the number (so, for example, the number 1321 is represented by the 673 character string "1321"). The encoding is defined by the following 674 ABNF: 676 Integer = [ HYPHEN ] number 678 The and rules are defined in [MODELS]. 680 The LDAP definition for the Integer syntax is: 682 ( 1.3.6.1.4.1.1466.115.121.1.27 DESC 'INTEGER' ) 684 This syntax corresponds to the INTEGER ASN.1 type from [ASN.1]. 686 4.3.17 JPEG 688 A value of the JPEG syntax is an image in the JPEG File Interchange 689 Format (JFIF), as described in [JPEG]. The LDAP-specific encoding of 690 a value of this syntax is the sequence of octets of the JFIF encoding 691 of the image. 693 The LDAP definition for the JPEG syntax is: 695 ( 1.3.6.1.4.1.1466.115.121.1.28 DESC 'JPEG' ) 697 The JPEG syntax corresponds to the following ASN.1 type: 699 JPEG ::= OCTET STRING (CONSTRAINED BY 700 { -- contents octets are an image in the -- 701 -- JPEG File Interchange Format -- }) 703 4.3.18 LDAP Syntax Description 705 A value of the LDAP Syntax Description syntax is the description of 706 an LDAP syntax. The LDAP-specific encoding of a value of this syntax 707 is defined by the rule in [MODELS]. 709 The LDAP definition for the LDAP Syntax Description syntax is: 711 ( 1.3.6.1.4.1.1466.115.121.1.54 DESC 'LDAP Syntax Description' ) 713 The above LDAP definition for the LDAP Syntax Description syntax is 714 itself a legal value of the LDAP Syntax Description syntax. 716 The ASN.1 type corresponding to the LDAP Syntax Description syntax is 717 defined as follows, assuming EXPLICIT TAGS: 719 LDAPSyntaxDescription ::= SEQUENCE { 720 identifier OBJECT IDENTIFIER, 721 description DirectoryString { ub-schema } OPTIONAL } 723 The DirectoryString parameterized ASN.1 type is defined in [X.520]. 724 The value of ub-schema is implementation defined. 726 4.3.19 Matching Rule Description 728 A value of the Matching Rule Description syntax is the definition of 729 a matching rule. The LDAP-specific encoding of a value of this 730 syntax is defined by the rule in [MODELS]. 732 Example: 733 ( 2.5.13.2 NAME 'caseIgnoreMatch' 734 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 736 Note: a line break has been added for readability - it is not part of 737 the syntax. 739 The LDAP definition for the Matching Rule Description syntax is: 741 ( 1.3.6.1.4.1.1466.115.121.1.30 DESC 'Matching Rule Description' ) 743 This syntax corresponds to the MatchingRuleDescription ASN.1 type 744 from [X.501]. 746 4.3.20 Matching Rule Use Description 748 A value of the Matching Rule Use Description syntax indicates the 749 attribute types to which a matching rule may be applied in an 750 extensibleMatch search filter [PROT]. The LDAP-specific encoding of 751 a value of this syntax is defined by the 752 rule in [MODELS]. 754 Example: 756 ( 2.5.13.16 APPLIES ( givenName $ surname ) ) 758 The LDAP definition for the Matching Rule Use Description syntax is: 760 ( 1.3.6.1.4.1.1466.115.121.1.31 761 DESC 'Matching Rule Use Description' ) 763 This syntax corresponds to the MatchingRuleUseDescription ASN.1 type 764 from [X.501]. 766 4.3.21 Name and Optional UID 768 A value of the Name and Optional UID syntax is the distinguished name 769 [MODELS] of an entity optionally accompanied by a unique identifier 770 that serves to differentiate the entity from others with an identical 771 distinguished name. 773 The LDAP-specific encoding of a value of this syntax is defined by 774 the following ABNF: 776 NameAndOptionalUID = distinguishedName [ SHARP BitString ] 778 The rule is defined in Section 4.3.2. The 779 rule is defined in [LDAPDN]. The rule is 780 defined in [MODELS]. 782 Note that although the '#' character may occur in the string 783 representation of a distinguished name, no additional escaping of 784 this character is performed when a is encoded in 785 a . 787 Example: 788 1.3.6.1.4.1.1466.0=#04024869,O=Test,C=GB#'0101'B 790 The LDAP definition for the Name and Optional UID syntax is: 792 ( 1.3.6.1.4.1.1466.115.121.1.34 DESC 'Name And Optional UID' ) 794 This syntax corresponds to the NameAndOptionalUID ASN.1 type from 795 [X.520]. 797 4.3.22 Name Form Description 799 A value of the Name Form Description syntax is the definition of a 800 name form, which regulates how entries may be named. The 801 LDAP-specific encoding of a value of this syntax is defined by the 802 rule in [MODELS]. 804 Example: 805 ( 2.5.15.3 NAME 'orgNameForm' OC organization MUST o ) 807 The LDAP definition for the Name Form Description syntax is: 809 ( 1.3.6.1.4.1.1466.115.121.1.35 DESC 'Name Form Description' ) 811 This syntax corresponds to the NameFormDescription ASN.1 type from 812 [X.501]. 814 4.3.23 Numeric String 816 A value of the Numeric String syntax is a sequence of one or more 817 numerals and spaces. The LDAP-specific encoding of a value of this 818 syntax is the unconverted string of characters, which conforms to the 819 following ABNF: 821 NumericString = 1*(DIGIT / SPACE) 823 The and rules are defined in [MODELS]. 825 Example: 826 15 079 672 281 828 The LDAP definition for the Numeric String syntax is: 830 ( 1.3.6.1.4.1.1466.115.121.1.36 DESC 'Numeric String' ) 832 This syntax corresponds to the NumericString ASN.1 type from [ASN.1]. 834 4.3.24 Object Class Description 836 A value of the Object Class Description syntax is the definition of 837 an object class. The LDAP-specific encoding of a value of this 838 syntax is defined by the rule in [MODELS]. 840 Example: 841 ( 2.5.6.2 NAME 'country' SUP top STRUCTURAL MUST c 842 MAY ( searchGuide $ description ) ) 844 Note: a line break has been added for readability - it is not part of 845 the syntax. 847 The LDAP definition for the Object Class Description syntax is: 849 ( 1.3.6.1.4.1.1466.115.121.1.37 DESC 'Object Class Description' ) 851 This syntax corresponds to the ObjectClassDescription ASN.1 type from 852 [X.501]. 854 4.3.25 Octet String 856 A value of the Octet String syntax is a sequence of zero, one or more 857 arbitrary octets. The LDAP-specific encoding of a value of this 858 syntax is the unconverted sequence of octets, which conforms to the 859 following ABNF: 861 OctetString = *OCTET 863 The rule is defined in [MODELS]. Values of this syntax are 864 not generally human-readable. 866 The LDAP definition for the Octet String syntax is: 868 ( 1.3.6.1.4.1.1466.115.121.1.40 DESC 'Octet String' ) 870 This syntax corresponds to the OCTET STRING ASN.1 type from [ASN.1]. 872 4.3.26 OID 874 A value of the OID syntax is an object identifier; a sequence of two 875 or more non-negative integers that uniquely identify some object or 876 item of specification. Many of the object identifiers used in LDAP 877 also have IANA registered names [RFC3383]. 879 The LDAP-specific encoding of a value of this syntax is defined by 880 the rule in [MODELS]. 882 Examples: 883 1.2.3.4 884 cn 886 The LDAP definition for the OID syntax is: 888 ( 1.3.6.1.4.1.1466.115.121.1.38 DESC 'OID' ) 890 This syntax corresponds to the OBJECT IDENTIFIER ASN.1 type from 891 [ASN.1]. 893 4.3.27 Other Mailbox 894 A value of the Other Mailbox syntax identifies an electronic mailbox, 895 in a particular named mail system. The LDAP-specific encoding of a 896 value of this syntax is defined by the following ABNF: 898 OtherMailbox = mailbox-type DOLLAR mailbox 899 mailbox-type = PrintableString 900 mailbox = IA5String 902 The rule represents the type of mail system in which 903 the mailbox resides, for example "MCIMail", and is the 904 actual mailbox in the mail system described by . The 905 and rules are defined in Section 4.2. 906 The rule is defined in [MODELS]. 908 The LDAP definition for the Other Mailbox syntax is: 910 ( 1.3.6.1.4.1.1466.115.121.1.39 DESC 'Other Mailbox' ) 912 The ASN.1 type corresponding to the Other Mailbox syntax is defined 913 as follows, assuming EXPLICIT TAGS: 915 OtherMailbox ::= SEQUENCE { 916 mailboxType PrintableString, 917 mailbox IA5String 918 } 920 4.3.28 Postal Address 922 A value of the Postal Address syntax is a series of strings which 923 form an address in a physical mail system. 925 The LDAP-specific encoding of a value of this syntax is defined by 926 the following ABNF: 928 PostalAddress = line *( DOLLAR line ) 929 line = 1*line-char 930 line-char = %x00-23 931 / (%x5C "24") ; escaped "$" 932 / %x25-5B 933 / (%x5C "5C") ; escaped "\" 934 / %x5D-7F 935 / UTFMB 937 Each of a postal address value is encoded as a UTF-8 [UTF-8] 938 string except that "\" and "$" characters, if they occur in the line, 939 are escaped by a "\" character followed by the two hexadecimal digit 940 code for the character. The rule is defined in Section 941 4.2. The and rules are defined in [MODELS]. 943 Many servers limit the postal address to no more than six lines of no 944 more than thirty characters each. 946 Example: 947 1234 Main St.$Anytown, CA 12345$USA 948 \241,000,000 Sweepstakes$PO Box 1000000$Anytown, CA 12345$USA 950 The LDAP definition for the Postal Address syntax is: 952 ( 1.3.6.1.4.1.1466.115.121.1.41 DESC 'Postal Address' ) 954 This syntax corresponds to the PostalAddress ASN.1 type from [X.520], 955 i.e. 957 PostalAddress ::= SEQUENCE SIZE(1..ub-postal-line) OF 958 DirectoryString(ub-postal-string) 960 4.3.29 Printable String 962 A value of the Printable String syntax is a string of latin 963 alphabetic, numeric, and (limited) punctuation characters as 964 specified by the rule in Section 4.2. 966 The LDAP-specific encoding of a value of this syntax is the 967 unconverted string of characters, which conforms to the 968 rule in Section 4.2. 970 Example: 971 This is a PrintableString. 973 The LDAP definition for the PrintableString syntax is: 975 ( 1.3.6.1.4.1.1466.115.121.1.44 DESC 'Printable String' ) 977 This syntax corresponds to the PrintableString ASN.1 type from 978 [ASN.1]. 980 4.3.30 Substring Assertion 982 A value of the Substring Assertion syntax is a sequence of zero, one 983 or more character substrings used as an argument for substring 984 extensible matching of character string attribute values, i.e. as the 985 matchValue of a MatchingRuleAssertion [PROT]. Each substring is a 986 string of one or more arbitrary characters from the Universal 987 Character Set (UCS) [UCS]. A zero length substring is not permitted. 989 The LDAP-specific encoding of a value of this syntax is defined by 990 the following ABNF: 992 SubstringAssertion = [ initial ] any [ final ] 994 initial = substring 995 any = ASTERISK *(substring ASTERISK) 996 final = substring 997 ASTERISK = %x2A ; asterisk ("*") 999 substring = 1*substring-character 1000 substring-character = %x00-29 1001 / (%x5C "2A") ; escaped "*" 1002 / %x2B-5B 1003 / (%x5C "5C") ; escaped "\" 1004 / %x5D-7F 1005 / UTFMB 1007 Each of a Substring Assertion value is encoded as a UTF-8 1008 [UTF-8] string, except that "\" and "*" characters, if they occur in 1009 the substring, are escaped by a "\" character followed by the two 1010 hexadecimal digit code for the character. 1012 The Substring Assertion syntax is used only as the syntax of 1013 assertion values in the extensible match. It is not used as an 1014 attribute syntax, or in the SubstringFilter [PROT]. 1016 The LDAP definition for the Substring Assertion syntax is: 1018 ( 1.3.6.1.4.1.1466.115.121.1.58 DESC 'Substring Assertion' ) 1020 This syntax corresponds to the SubstringAssertion ASN.1 type from 1021 [X.520]. 1023 4.3.31 Telephone Number 1025 A value of the Telephone Number syntax is a string of printable 1026 characters that complies with the internationally agreed format for 1027 representing international telephone numbers [E.123]. 1029 The LDAP-specific encoding of a value of this syntax is the 1030 unconverted string of characters, which conforms to the 1031 rule in Section 4.2. 1033 Example: +1 512 315 0280 1035 The LDAP definition for the Telephone Number syntax is: 1037 ( 1.3.6.1.4.1.1466.115.121.1.50 DESC 'Telephone Number' ) 1039 The Telephone Number syntax corresponds to the following ASN.1 type 1040 from [X.520]: 1042 PrintableString (SIZE(1..ub-telephone-number)) 1044 The value of ub-telephone-number is implementation defined. 1046 4.3.32 Teletex Terminal Identifier 1048 A value of this syntax specifies the identifier and (optionally) 1049 parameters of a teletex terminal. 1051 The LDAP-specific encoding of a value of this syntax is defined by 1052 the following ABNF: 1054 teletex-id = ttx-term *(DOLLAR ttx-param) 1055 ttx-term = PrintableString ; terminal identifier 1056 ttx-param = ttx-key COLON ttx-value ; parameter 1057 ttx-key = "graphic" / "control" / "misc" / "page" / "private" 1058 ttx-value = *ttx-value-char 1060 ttx-value-char = %x00-23 1061 / (%x5C "24") ; escaped "$" 1062 / %x25-5B 1063 / (%x5C "5C") ; escaped "\" 1064 / %x5D-FF 1066 The and rules are defined in Section 4.2. 1067 The rule is defined in [MODELS]. 1069 The LDAP definition for the Teletex Terminal Identifier syntax is: 1071 ( 1.3.6.1.4.1.1466.115.121.1.51 1072 DESC 'Teletex Terminal Identifier' ) 1074 This syntax corresponds to the TeletexTerminalIdentifier ASN.1 type 1075 from [X.520]. 1077 4.3.33 Telex Number 1079 A value of the Telex Number syntax specifies the telex number, 1080 country code and answerback code of a telex terminal. 1082 The LDAP-specific encoding of a value of this syntax is defined by 1083 the following ABNF: 1085 telex-number = actual-number DOLLAR country-code 1086 DOLLAR answerback 1087 actual-number = PrintableString 1088 country-code = PrintableString 1089 answerback = PrintableString 1091 The rule is defined in Section 4.2. The 1092 rule is defined in [MODELS]. 1094 The LDAP definition for the Telex Number syntax is: 1096 ( 1.3.6.1.4.1.1466.115.121.1.52 DESC 'Telex Number' ) 1098 This syntax corresponds to the TelexNumber ASN.1 type from [X.520]. 1100 4.3.34 UTC Time 1102 A value of the UTC Time syntax is a character string representing a 1103 date and time to a precision of one minute or one second. The year 1104 is given as a two-digit number. The LDAP-specific encoding of a 1105 value of this syntax follows the format defined in [ASN.1] for the 1106 UTCTime type and is described by the following ABNF: 1108 UTCTime = year month day hour minute [ second ] 1109 [ u-time-zone ] 1110 u-time-zone = %x5A ; "Z" 1111 / u-differential 1112 u-differential = ( MINUS / PLUS ) hour minute 1114 The , , , , , and 1115 rules are defined in Section 4.3.13. The rule is defined in 1116 [MODELS]. 1118 The time value represents coordinated universal time if the "Z" form 1119 of is used, otherwise the value represents a local 1120 time. In the latter case, if is provided then 1121 coordinated universal time can be calculated by subtracting the 1122 differential from the local time. The SHOULD be 1123 present in time values and the "Z" form of SHOULD be 1124 used in preference to . 1126 The LDAP definition for the UTC Time syntax is: 1128 ( 1.3.6.1.4.1.1466.115.121.1.53 DESC 'UTC Time' ) 1130 Note: This syntax is deprecated in favor of the Generalized Time 1131 syntax. 1133 The UTC Time syntax corresponds to the UTCTime ASN.1 type from 1134 [ASN.1]. 1136 5. Matching Rules 1138 Matching rules are used by directory implementations to compare 1139 attribute values against assertion values when performing Search and 1140 Compare operations [PROT]. They are also used when comparing a 1141 purported distinguished name [MODELS] with the name of an entry. 1142 When modifying entries, matching rules are used to identify values to 1143 be deleted and to prevent an attribute from containing two equal 1144 values. 1146 Matching rules that are required for directory operation, or that are 1147 in common use, are specified in this section. 1149 5.1 General Considerations 1151 A matching rule is applied to attribute values through an 1152 AttributeValueAssertion or MatchingRuleAssertion [PROT]. The 1153 conditions under which an AttributeValueAssertion or 1154 MatchingRuleAssertion evaluates to Undefined are specified in [PROT]. 1155 If an assertion is not Undefined then the result of the assertion is 1156 the result of applying the selected matching rule. A matching rule 1157 evaluates to TRUE, and in some cases Undefined, as specified in the 1158 description of the matching rule, otherwise it evaluates to FALSE. 1160 Each assertion contains an assertion value. The definition of each 1161 matching rule specifies the syntax for the assertion value. The 1162 syntax of the assertion value is typically, but not necessarily, the 1163 same as the syntax of the attribute values to which the matching rule 1164 may be applied. Note that the AssertionValue in a SubstringFilter 1165 [PROT] MUST conform to the assertion syntax of the equality matching 1166 rule for the attribute type rather than the assertion syntax of the 1167 substrings matching rule for the attribute type. The entire 1168 SubstringFilter is converted into an assertion value of the 1169 substrings matching rule prior to applying the rule. 1171 The description of each matching rule indicates whether the rule is 1172 suitable for use as the equality matching rule (EQUALITY), ordering 1173 matching rule (ORDERING) or substrings matching rule (SUBSTR) in an 1174 attribute type definition [MODELS]. 1176 Each matching rule is uniquely identified with an object identifier. 1178 The definition of a matching rule should not be subsequently changed. 1179 If a change is desirable then a new matching rule with a different 1180 object identifier should be defined instead. 1182 Servers SHOULD implement all the matching rules in Section 5.2. 1183 Servers MAY implement additional matching rules. 1185 Servers which implement the extensibleMatch filter SHOULD allow the 1186 matching rules listed in Section 5.2 to be used in the 1187 extensibleMatch filter and SHOULD allow matching rules to be used 1188 with all attribute types known to the server, where the assertion 1189 syntax of the matching rule is the same as the value syntax of the 1190 attribute. 1192 Servers MUST publish in the matchingRules attribute, the definitions 1193 of matching rules referenced by values of the attributeTypes and 1194 matchingRuleUse attributes in the same subschema entry. Other 1195 unreferenced matching rules MAY be published in the matchingRules 1196 attribute. 1198 If the server supports the extensibleMatch filter, then the server 1199 MAY use the matchingRuleUse attribute to indicate the applicability 1200 (in an extensibleMatch filter) of selected matching rules to 1201 nominated attribute types. 1203 5.2 Matching Rule Definitions 1205 When evaluating the caseExactIA5Match, caseIgnoreIA5Match, 1206 caseIgnoreIA5SubstringsMatch, caseIgnoreListMatch, caseIgnoreMatch, 1207 caseIgnoreOrderingMatch and caseIgnoreSubstringsMatch matching rules 1208 multiple adjoining whitespace characters are treated the same as an 1209 individual space, and leading and trailing whitespace is ignored. 1211 5.2.1 bitStringMatch 1213 The bitStringMatch rule compares an assertion value of the Bit String 1214 syntax to an attribute value of a syntax (e.g. the Bit String syntax) 1215 whose corresponding ASN.1 type is BIT STRING. 1217 If the corresponding ASN.1 type of the attribute syntax does not have 1218 a named bit list (which is the case for the Bit String syntax) then 1219 the rule evaluates to TRUE if and only if the attribute value has the 1220 same number of bits as the assertion value and the bits match on a 1221 bitwise basis. 1223 If the corresponding ASN.1 type does have a named bit list then 1224 bitStringMatch operates as above except that trailing zero bits in 1225 the attribute and assertion values are treated as absent. 1227 The LDAP definition for the bitStringMatch rule is: 1229 ( 2.5.13.16 NAME 'bitStringMatch' 1230 SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 ) 1232 The bitStringMatch rule is an equality matching rule. 1234 5.2.2 caseExactIA5Match 1236 The caseExactIA5Match rule compares an assertion value of the IA5 1237 String syntax to an attribute value of a syntax (e.g the IA5 String 1238 syntax) whose corresponding ASN.1 type is IA5String. 1240 The rule evaluates to TRUE if and only if the attribute value and the 1241 assertion value have the same number of characters and corresponding 1242 characters are the same. Letter case is significant in the 1243 comparison. 1245 The LDAP definition for the caseExactIA5Match rule is: 1247 ( 1.3.6.1.4.1.1466.109.114.1 NAME 'caseExactIA5Match' 1248 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) 1250 The caseExactIA5Match rule is an equality matching rule. 1252 5.2.3 caseIgnoreIA5Match 1254 The caseIgnoreIA5Match rule compares an assertion value of the IA5 1255 String syntax to an attribute value of a syntax (e.g the IA5 String 1256 syntax) whose corresponding ASN.1 type is IA5String. 1258 The rule evaluates to TRUE if and only if the attribute value and the 1259 assertion value have the same number of characters and corresponding 1260 characters are the same, ignoring the case of letters. 1262 The LDAP definition for the caseIgnoreIA5Match rule is: 1264 ( 1.3.6.1.4.1.1466.109.114.2 NAME 'caseIgnoreIA5Match' 1265 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) 1267 The caseIgnoreIA5Match rule is an equality matching rule. 1269 5.2.4 caseIgnoreIA5SubstringsMatch 1271 The caseIgnoreIA5SubstringsMatch rule compares an assertion value of 1272 the Substring Assertion syntax to an attribute value of a syntax (e.g 1273 the IA5 String syntax) whose corresponding ASN.1 type is IA5String. 1275 The rule evaluates to TRUE if and only if the substrings of the 1276 assertion value match disjoint portions of the attribute value in the 1277 order of the substrings in the assertion value, and an 1278 substring, if present, matches the beginning of the attribute value, 1279 and a substring, if present, matches the end of the attribute 1280 value. A substring matches a portion of the attribute value if 1281 corresponding characters are the same, ignoring the case of letters. 1283 ( 1.3.6.1.4.1.1466.109.114.3 NAME 'caseIgnoreIA5SubstringsMatch' 1284 SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 ) 1286 The caseIgnoreIA5SubstringsMatch rule is a substrings matching rule. 1288 5.2.5 caseIgnoreListMatch 1290 The caseIgnoreListMatch rule compares an assertion value that is a 1291 sequence of strings to an attribute value of a syntax (e.g. the 1292 Postal Address syntax) whose corresponding ASN.1 type is a sequence 1293 of the DirectoryString ASN.1 type. 1295 The rule evaluates to TRUE if and only if the attribute value and the 1296 assertion value have the same number of strings and corresponding 1297 strings (by position) match according to the caseIgnoreMatch matching 1298 rule. 1300 In [X.520] the assertion syntax for this matching rule is defined to 1301 be: 1303 SEQUENCE OF DirectoryString {ub-match} 1305 i.e. different from the corresponding type for the Postal Address 1306 syntax. The choice of the Postal Address syntax for the assertion 1307 syntax of the caseIgnoreListMatch in LDAP should not be seen as 1308 limiting the matching rule to only apply to attributes with the 1309 Postal Address syntax. 1311 The LDAP definition for the caseIgnoreListMatch rule is: 1313 ( 2.5.13.11 NAME 'caseIgnoreListMatch' 1314 SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 ) 1316 The caseIgnoreListMatch rule is an equality matching rule. 1318 5.2.6 caseIgnoreMatch 1320 The caseIgnoreMatch rule compares an assertion value of the Directory 1321 String syntax to an attribute value of a syntax (e.g. the Directory 1322 String, Printable String, Country String or Telephone Number syntax) 1323 whose corresponding ASN.1 type is DirectoryString or one of its 1324 alternative string types, e.g. PrintableString. 1326 The rule evaluates to TRUE if and only if the attribute value and the 1327 assertion value have the same number of characters and corresponding 1328 characters are the same, ignoring the case of letters. 1330 The LDAP definition for the caseIgnoreMatch rule is: 1332 ( 2.5.13.2 NAME 'caseIgnoreMatch' 1333 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 1335 The caseIgnoreMatch rule is an equality matching rule. 1337 5.2.7 caseIgnoreOrderingMatch 1339 The caseIgnoreOrderingMatch rule compares an assertion value of the 1340 Directory String syntax to an attribute value of a syntax (e.g. the 1341 Directory String, Printable String, Country String or Telephone 1342 Number syntax) whose corresponding ASN.1 type is DirectoryString or 1343 one of its alternative string types. 1345 The rule evaluates to TRUE if, and only if, in the normal collation 1346 order for the attribute syntax after lower-case letters in both the 1347 attribute and assertion values have been replaced by their upper-case 1348 equivalents, the attribute value appears earlier than the assertion 1349 value, i.e. the attribute value is "less than" the assertion value. 1351 The collation order for values of the DirectoryString syntax is 1352 implementation-defined. [Editor's note: this will be specified by a 1353 stringprep profile before final publication.] 1355 The LDAP definition for the caseIgnoreOrderingMatch rule is: 1357 ( 2.5.13.3 NAME 'caseIgnoreOrderingMatch' 1358 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 1360 The caseIgnoreOrderingMatch rule is an ordering matching rule. 1362 5.2.8 caseIgnoreSubstringsMatch 1364 The caseIgnoreSubstringsMatch rule compares an assertion value of the 1365 Substring Assertion syntax to an attribute value of a syntax (e.g. 1366 the Directory String, Printable String, Country String or Telephone 1367 Number syntax) whose corresponding ASN.1 type is DirectoryString or 1368 one of its alternative string types. 1370 The rule evaluates to TRUE if and only if the substrings of the 1371 assertion value match disjoint portions of the attribute value in the 1372 order of the substrings in the assertion value, and an 1373 substring, if present, matches the beginning of the attribute value, 1374 and a substring, if present, matches the end of the attribute 1375 value. A substring matches a portion of the attribute value if 1376 corresponding characters are the same, ignoring the case of letters. 1378 The LDAP definition for the caseIgnoreSubstringsMatch rule is: 1380 ( 2.5.13.4 NAME 'caseIgnoreSubstringsMatch' 1381 SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 ) 1383 The caseIgnoreSubstringsMatch rule is a substrings matching rule. 1385 5.2.9 distinguishedNameMatch 1387 The distinguishedNameMatch rule compares an assertion value of the DN 1388 syntax to an attribute value of a syntax (e.g. the DN syntax) whose 1389 corresponding ASN.1 type is DistinguishedName. 1391 The rule evaluates to TRUE if and only if the attribute value and the 1392 assertion value have the same number of RDNs and corresponding RDNs 1393 (by position) are the same. An RDN of the assertion value is the 1394 same as an RDN of the attribute value if and only if they have the 1395 same number of attribute value assertions (AVAs) and each AVA of the 1396 first RDN is the same as the AVA of the second RDN with the same 1397 attribute type. The order of the AVAs is not significant. Also note 1398 that a particular attribute type may appear in at most one AVA in an 1399 RDN. Two AVAs with the same attribute type are the same if their 1400 values are equal according to the equality matching rule of the 1401 attribute type. If one or more of the AVA comparisons evaluate to 1402 Undefined and the remaining AVA comparisons return TRUE then the 1403 distinguishedNameMatch rule evaluates to Undefined. 1405 The LDAP definition for the distinguishedNameMatch rule is: 1407 ( 2.5.13.1 NAME 'distinguishedNameMatch' 1408 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 ) 1410 The distinguishedNameMatch rule is an equality matching rule. 1412 5.2.10 generalizedTimeMatch 1414 The generalizedTimeMatch rule compares an assertion value of the 1415 Generalized Time syntax to an attribute value of a syntax (e.g the 1416 Generalized Time syntax) whose corresponding ASN.1 type is 1417 GeneralizedTime. 1419 The rule evaluates to TRUE if and only if the attribute value 1420 represents the same universal coordinated time as the assertion 1421 value. If a time is specified with the minutes or seconds absent 1422 then the number of minutes or seconds (respectively) is assumed to be 1423 zero. 1425 The LDAP definition for the generalizedTimeMatch rule is: 1427 ( 2.5.13.27 NAME 'generalizedTimeMatch' 1428 SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 ) 1430 The generalizedTimeMatch rule is an equality matching rule. 1432 5.2.11 generalizedTimeOrderingMatch 1434 The generalizedTimeMatch rule compares the time ordering of an 1435 assertion value of the Generalized Time syntax to an attribute value 1436 of a syntax (e.g the Generalized Time syntax) whose corresponding 1437 ASN.1 type is GeneralizedTime. 1439 The rule evaluates to TRUE if and only if the attribute value 1440 represents a universal coordinated time which is earlier than the 1441 universal coordinated time represented by the assertion value. 1443 The LDAP definition for the generalizedTimeOrderingMatch rule is: 1445 ( 2.5.13.28 NAME 'generalizedTimeOrderingMatch' 1446 SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 ) 1448 The generalizedTimeOrderingMatch rule is an ordering matching rule. 1450 5.2.12 integerFirstComponentMatch 1452 The integerFirstComponentMatch rule compares an assertion value of 1453 the Integer syntax to an attribute value of a syntax (e.g the DIT 1454 Structure Rule Description syntax) whose corresponding ASN.1 type is 1455 a SEQUENCE with a mandatory first component of the INTEGER ASN.1 1456 type. 1458 Note that the assertion syntax of this matching rule differs from the 1459 attribute syntax of attributes for which this is the equality 1460 matching rule. 1462 The rule evaluates to TRUE if and only if the assertion value and the 1463 first component of the attribute value are the same integer value. 1465 The LDAP definition for the integerFirstComponentMatch matching rule 1466 is: 1468 ( 2.5.13.29 NAME 'integerFirstComponentMatch' 1469 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 ) 1471 The integerFirstComponentMatch rule is an equality matching rule. 1472 When using integerFirstComponentMatch to compare two attribute values 1473 (of an applicable syntax), an assertion value must first be derived 1474 from one of the attribute values. An assertion value can be derived 1475 from an attribute value by taking the first component of that 1476 attribute value. 1478 5.2.13 integerMatch 1480 The integerMatch rule compares an assertion value of the Integer 1481 syntax to an attribute value of a syntax (e.g the Integer syntax) 1482 whose corresponding ASN.1 type is INTEGER. 1484 The rule evaluates to TRUE if and only if the attribute value and the 1485 assertion value are the same integer value. 1487 The LDAP definition for the integerMatch matching rule is: 1489 ( 2.5.13.14 NAME 'integerMatch' 1490 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 ) 1492 The integerMatch rule is an equality matching rule. 1494 5.2.14 numericStringMatch 1496 The numericStringMatch rule compares an assertion value of the 1497 Numeric String syntax to an attribute value of a syntax (e.g the 1498 Numeric String syntax) whose corresponding ASN.1 type is 1499 NumericString. 1501 The rule evaluates to TRUE if and only if the attribute value and the 1502 assertion value are the same string of numerals, ignoring any space 1503 characters. 1505 The LDAP definition for the numericStringMatch matching rule is: 1507 ( 2.5.13.8 NAME 'numericStringMatch' 1508 SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 ) 1510 The numericStringMatch rule is an equality matching rule. 1512 5.2.15 numericStringSubstringsMatch 1514 The numericStringSubstringsMatch rule compares an assertion value of 1515 the Substring Assertion syntax to an attribute value of a syntax (e.g 1516 the Numeric String syntax) whose corresponding ASN.1 type is 1517 NumericString. 1519 The rule evaluates to TRUE if and only if the substrings of the 1520 assertion value match disjoint portions of the attribute value in the 1521 order of the substrings in the assertion value, and an 1522 substring, if present, matches the beginning of the attribute value, 1523 and a substring, if present, matches the end of the attribute 1524 value. A substring matches a portion of the attribute value if 1525 corresponding characters are the same, ignoring any space characters. 1527 ( 2.5.13.10 NAME 'numericStringSubstringsMatch' 1528 SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 ) 1530 The numericStringSubstringsMatch rule is a substrings matching rule. 1532 5.2.16 objectIdentifierFirstComponentMatch 1534 The objectIdentifierFirstComponentMatch rule compares an assertion 1535 value of the OID syntax to an attribute value of a syntax (e.g the 1536 Attribute Type Description, DIT Content Rule Description, LDAP Syntax 1537 Description, Matching Rule Description, Matching Rule Use 1538 Description, Name Form Description or Object Class Description 1539 syntax) whose corresponding ASN.1 type is a SEQUENCE with a mandatory 1540 first component of the OBJECT IDENTIFIER ASN.1 type. 1542 Note that the assertion syntax of this matching rule differs from the 1543 attribute syntax of attributes for which this is the equality 1544 matching rule. 1546 The rule evaluates to TRUE if and only if the assertion value matches 1547 the first component of the attribute value using the rules of 1548 objectIdentifierMatch. 1550 The LDAP definition for the objectIdentifierFirstComponentMatch 1551 matching rule is: 1553 ( 2.5.13.31 NAME 'objectIdentifierFirstComponentMatch' 1554 SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 ) 1556 The objectIdentifierFirstComponentMatch rule is an equality matching 1557 rule. When using objectIdentifierFirstComponentMatch to compare two 1558 attribute values (of an applicable syntax), an assertion value must 1559 first be derived from one of the attribute values. An assertion 1560 value can be derived from an attribute value by taking the first 1561 component of that attribute value. 1563 5.2.17 objectIdentifierMatch 1565 The objectIdentifierMatch rule compares an assertion value of the OID 1566 syntax to an attribute value of a syntax (e.g the OID syntax) whose 1567 corresponding ASN.1 type is OBJECT IDENTIFIER. 1569 The rule evaluates to TRUE if and only if the assertion value and the 1570 attribute value represent the same object identifier, that is, the 1571 same sequence of integers, whether represented explicitly in the 1572 form of or implicitly in the form (see 1573 [MODELS]). 1575 If an LDAP client supplies an assertion value in the form, 1576 and the chosen descriptor is not recognized by the server, then the 1577 objectIdentifierMatch rule evaluates to Undefined. 1579 The LDAP definition for the objectIdentifierMatch matching rule is: 1581 ( 2.5.13.0 NAME 'objectIdentifierMatch' 1582 SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 ) 1584 The objectIdentifierMatch rule is an equality matching rule. 1586 5.2.18 octetStringMatch 1588 The octetStringMatch rule compares an assertion value of the Octet 1589 String syntax to an attribute value of a syntax (e.g the Octet String 1590 or JPEG syntax) whose corresponding ASN.1 type is the OCTET STRING 1591 ASN.1 type. 1593 The rule evaluates to TRUE if and only if the attribute value and the 1594 assertion value are the same length and corresponding octets (by 1595 position) are the same. 1597 The LDAP definition for the octetStringMatch matching rule is: 1599 ( 2.5.13.17 NAME 'octetStringMatch' 1600 SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 ) 1602 The octetStringMatch rule is an equality matching rule. 1604 5.2.19 telephoneNumberMatch 1606 The telephoneNumberMatch rule compares an assertion value of the 1607 Telephone Number syntax to an attribute value of a syntax (e.g the 1608 Telephone Number syntax) whose corresponding ASN.1 type is a 1609 PrintableString representing a telephone number. 1611 The rule evaluates to TRUE if and only if the attribute value and the 1612 assertion value have the same number of characters and corresponding 1613 characters are the same, ignoring the case of letters, and ignoring 1614 space and `-' characters. 1616 The LDAP definition for the telephoneNumberMatch matching rule is: 1618 ( 2.5.13.20 NAME 'telephoneNumberMatch' 1619 SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 ) 1621 The telephoneNumberMatch rule is an equality matching rule. 1623 5.2.20 telephoneNumberSubstringsMatch 1625 The telephoneNumberSubstringsMatch rule compares an assertion value 1626 of the Substring Assertion syntax to an attribute value of a syntax 1627 (e.g the Telephone Number syntax) whose corresponding ASN.1 type is a 1628 PrintableString representing a telephone number. 1630 The rule evaluates to TRUE if and only if the substrings of the 1631 assertion value match disjoint portions of the attribute value in the 1632 order of the substrings in the assertion value, and an 1633 substring, if present, matches the beginning of the attribute value, 1634 and a substring, if present, matches the end of the attribute 1635 value. A substring matches a portion of the attribute value if 1636 corresponding characters are the same, ignoring the case of letters, 1637 and ignoring space and `-' characters. 1639 The LDAP definition for the telephoneNumberSubstringsMatch matching 1640 rule is: 1642 ( 2.5.13.21 NAME 'telephoneNumberSubstringsMatch' 1643 SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 ) 1645 The telephoneNumberSubstringsMatch rule is a substrings matching 1646 rule. 1648 5.2.21 uniqueMemberMatch 1650 The uniqueMemberMatch rule compares an assertion value of the Name 1651 And Optional UID syntax to an attribute value of a syntax (e.g the 1652 Name And Optional UID syntax) whose corresponding ASN.1 type is 1653 NameAndOptionalUID. 1655 The rule evaluates to TRUE if and only if the 1656 components of the assertion value and attribute value match according 1657 to the distinguishedNameMatch rule and the component is 1658 absent from the attribute value or matches the component 1659 of the assertion value according to the bitStringMatch rule. 1661 The LDAP definition for the uniqueMemberMatch matching rule is: 1663 ( 2.5.13.23 NAME 'uniqueMemberMatch' 1664 SYNTAX 1.3.6.1.4.1.1466.115.121.1.34 ) 1666 The uniqueMemberMatch rule is an equality matching rule. 1668 6. Security Considerations 1670 In general, the LDAP-specific encodings for syntaxes defined in this 1671 document do not define canonical encodings. That is, a 1672 transformation from an LDAP-specific encoding into some other 1673 encoding (e.g. BER) and back into the LDAP-specific encoding will not 1674 necessarily reproduce exactly the original octets of the 1675 LDAP-specific encoding. Therefore an LDAP-specific encoding should 1676 not be used where a canonical encoding is required. 1678 Furthermore, the LDAP-specific encodings do not necessarily enable an 1679 alternative encoding of values of the Directory String and DN 1680 syntaxes to be reconstructed, e.g. a transformation from DER to 1681 LDAP-specific encoding and back to DER may not reproduce the original 1682 DER encoding. Therefore LDAP-specific encodings should not be used 1683 where reversibility to DER is needed, e.g. for the verification of 1684 digital signatures. Instead, DER or a DER-reversible encoding should 1685 be used. 1687 When interpreting security-sensitive fields, and in particular fields 1688 used to grant or deny access, implementations MUST ensure that any 1689 matching rule comparisons are done on the underlying abstract value, 1690 regardless of the particular encoding used. 1692 7. Acknowledgements 1694 This document is an revision of RFC 2252 by M. Wahl, A. Coulbeck, T. 1695 Howes, and S. Kille. RFC 2252 was a product of the IETF ASID Working 1696 Group. 1698 This document is based upon input of the IETF LDAPBIS working group. 1699 The authors wish to thank J. Sermersheim and K. Zeilenga for their 1700 significant contribution to this revision. 1702 8. IANA Considerations 1704 It is requested that the Internet Assigned Numbers Authority (IANA) 1705 update the LDAP descriptors registry as indicated by the following 1706 two templates: 1708 Subject: Request for LDAP Descriptor Registration Update 1709 Descriptor (short name): see comment 1710 Object Identifier: see comment 1711 Person & email address to contact for further information: 1712 Steven Legg 1713 Usage: see comment 1714 Specification: RFC XXXX 1715 Author/Change Controller: IESG 1716 Comments: 1718 The following descriptors (short names) should be updated to refer 1719 to RFC XXXX. 1721 NAME Type OID 1722 ------------------------------------------------------------------ 1723 bitStringMatch M 2.5.13.16 1724 caseExactIA5Match M 1.3.6.1.4.1.1466.109.114.1 1725 caseIgnoreIA5Match M 1.3.6.1.4.1.1466.109.114.2 1726 caseIgnoreListMatch M 2.5.13.11 1727 caseIgnoreMatch M 2.5.13.2 1728 caseIgnoreOrderingMatch M 2.5.13.3 1729 caseIgnoreSubstringsMatch M 2.5.13.4 1730 distinguishedNameMatch M 2.5.13.1 1731 generalizedTimeMatch M 2.5.13.27 1732 generalizedTimeOrderingMatch M 2.5.13.28 1733 integerFirstComponentMatch M 2.5.13.29 1734 integerMatch M 2.5.13.14 1735 numericStringMatch M 2.5.13.8 1736 numericStringSubstringsMatch M 2.5.13.10 1737 objectIdentifierFirstComponentMatch M 2.5.13.31 1738 octetStringMatch M 2.5.13.17 1739 telephoneNumberMatch M 2.5.13.20 1740 telephoneNumberSubstringsMatch M 2.5.13.21 1741 uniqueMemberMatch M 2.5.13.23 1743 The descriptor for the object identifier 2.5.13.0 was incorrectly 1744 registered as objectIdentifiersMatch (extraneous `s') in RFC 3383. 1745 It should be changed to the following with a reference to RFC 1746 XXXX. 1748 NAME Type OID 1749 ------------------------------------------------------------------ 1750 objectIdentifierMatch M 2.5.13.0 1752 Subject: Request for LDAP Descriptor Registration 1753 Descriptor (short name): caseIgnoreIA5SubstringsMatch 1754 Object Identifier: 1.3.6.1.4.1.1466.109.114.3 1755 Person & email address to contact for further information: 1756 Steven Legg 1757 Usage: other (M) 1758 Specification: RFC XXXX 1759 Author/Change Controller: IESG 1761 9. Normative References 1763 [KEYWORD] Bradner, S., "Key words for use in RFCs to Indicate 1764 Requirement Levels", BCP 14, RFC 2119, March 1997. 1766 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1767 Specifications: ABNF", RFC 2234, November 1997. 1769 [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 1770 10646", RFC 2279, January 1998. 1772 [RFC3383] Zeilenga, K., "IANA Considerations for LDAP", BCP 64, RFC 1773 3383, September 2002. 1775 [LDAPDN] Zeilenga, K., "LDAP: String Representation of 1776 Distinguished Names", draft-ietf-ldapbis-dn-xx.txt, a work 1777 in progress, August 2002. 1779 [PROT] Sermersheim, J., "LDAP: The Protocol", draft-ietf-ldapbis- 1780 protocol-xx.txt, a work in progress, December 2002. 1782 [E.123] Notation for national and international telephone numbers, 1783 ITU-T Recommendation E.123, 1988. 1785 [FAX] Standardization of Group 3 facsimile apparatus for 1786 document transmission - Terminal Equipment and Protocols 1787 for Telematic Services, ITU-T Recommendation T.4, 1993 1789 [T.50] International Reference Alphabet (IRA) (Formerly 1790 International Alphabet No. 5 or IA5) Information 1791 Technology - 7-Bit Coded Character Set for Information 1792 Interchange, ITU-T Recommendation T.50, 1992 1794 [X.420] ITU-T Recommendation X.420 (1996) | ISO/IEC 10021-7:1997, 1795 Information Technology - Message Handling Systems (MHS): 1796 Interpersonal messaging system 1798 [X.501] ITU-T Recommendation X.501 (1993) | ISO/IEC 9594-2:1994, 1799 Information Technology - Open Systems Interconnection - 1800 The Directory: Models 1802 [X.520] ITU-T Recommendation X.520 (1993) | ISO/IEC 9594-6:1994, 1803 Information Technology - Open Systems Interconnection - 1804 The Directory: Selected attribute types 1806 [ASN.1] ITU-T Recommendation X.680 (1997) | ISO/IEC 8824-1:1998 1807 Information Technology - Abstract Syntax Notation One 1808 (ASN.1): Specification of basic notation 1810 [ISO3166] ISO 3166, "Codes for the representation of names of 1811 countries". 1813 [UCS] Universal Multiple-Octet Coded Character Set (UCS) - 1814 Architecture and Basic Multilingual Plane, ISO/IEC 1815 10646-1: 1993 (with amendments). 1817 [JPEG] JPEG File Interchange Format (Version 1.02). Eric 1818 Hamilton, C-Cube Microsystems, Milpitas, CA, September 1, 1819 1992. 1821 10. Informative References 1823 [RFC2252] Wahl, M., Coulbeck, A., Howes, T. and S. Kille, 1824 "Lightweight Directory Access Protocol (v3): Attribute 1825 Syntax Definitions", RFC 2252, December 1997. 1827 [RFC2256] Wahl, M., "A Summary of the X.500(96) User Schema for use 1828 with LDAPv3", RFC 2256, December 1997. 1830 [RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access 1831 Protocol (v3): Technical Specification", RFC 3377, 1832 September 2002. 1834 [X.500] ITU-T Recommendation X.500 (1993) | ISO/IEC 9594-1:1994, 1835 Information Technology - Open Systems Interconnection - 1836 The Directory: Overview of concepts, models and services 1838 [BER] ITU-T Recommendation X.690 (1997) | ISO/IEC 8825-1:1998 1839 Information Technology - ASN.1 encoding rules: 1840 Specification of Basic Encoding Rules (BER), Canonical 1841 Encoding Rules (CER) and Distinguished Encoding Rules 1842 (DER) 1844 11. Authors' Addresses 1846 Steven Legg 1847 Adacel Technologies Ltd. 1848 405-409 Ferntree Gully Road 1849 Mount Waverley, Victoria 3149 1850 AUSTRALIA 1852 Phone: +61 3 9451 2107 1853 Fax: +61 3 9541 2121 1854 Email: steven.legg@adacel.com.au 1856 Kathy Dally 1857 The MITRE Corp. 1858 7515 Colshire Dr., ms-W650 1859 McLean VA 22102 1860 USA 1862 Phone: +1 703 883 6058 1863 Fax: +1 703 883 7142 1864 Email: kdally@mitre.org 1866 12. Copyright Notice 1868 Copyright (C) The Internet Society (2002). All Rights Reserved. 1870 This document and translations of it may be copied and furnished to 1871 others, and derivative works that comment on or otherwise explain it 1872 or assist in its implementation may be prepared, copied, published 1873 and distributed, in whole or in part, without restriction of any 1874 kind, provided that the above copyright notice and this paragraph are 1875 included on all such copies and derivative works. However, this 1876 document itself may not be modified in any way, such as by removing 1877 the copyright notice or references to the Internet Society or other 1878 Internet organizations, except as needed for the purpose of 1879 developing Internet standards in which case the procedures for 1880 copyrights defined in the Internet Standards process must be 1881 followed, or as required to translate it into languages other than 1882 English. 1884 The limited permissions granted above are perpetual and will not be 1885 revoked by the Internet Society or its successors or assigns. 1887 This document and the information contained herein is provided on an 1888 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1889 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1890 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1891 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1892 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1894 Appendix A. Summary of Syntax Object Identifiers 1896 The following list summarizes the object identifiers assigned to the 1897 syntaxes defined in this document. 1899 Syntax OBJECT IDENTIFIER 1900 ============================================================== 1901 Attribute Type Description 1.3.6.1.4.1.1466.115.121.1.3 1902 Bit String 1.3.6.1.4.1.1466.115.121.1.6 1903 Boolean 1.3.6.1.4.1.1466.115.121.1.7 1904 Country String 1.3.6.1.4.1.1466.115.121.1.11 1905 Delivery Method 1.3.6.1.4.1.1466.115.121.1.14 1906 Directory String 1.3.6.1.4.1.1466.115.121.1.15 1907 DIT Content Rule Description 1.3.6.1.4.1.1466.115.121.1.16 1908 DIT Structure Rule Description 1.3.6.1.4.1.1466.115.121.1.17 1909 DN 1.3.6.1.4.1.1466.115.121.1.12 1910 Enhanced Guide 1.3.6.1.4.1.1466.115.121.1.21 1911 Facsimile Telephone Number 1.3.6.1.4.1.1466.115.121.1.22 1912 Fax 1.3.6.1.4.1.1466.115.121.1.23 1913 Generalized Time 1.3.6.1.4.1.1466.115.121.1.24 1914 Guide 1.3.6.1.4.1.1466.115.121.1.25 1915 IA5 String 1.3.6.1.4.1.1466.115.121.1.26 1916 Integer 1.3.6.1.4.1.1466.115.121.1.27 1917 JPEG 1.3.6.1.4.1.1466.115.121.1.28 1918 LDAP Syntax Description 1.3.6.1.4.1.1466.115.121.1.54 1919 Matching Rule Description 1.3.6.1.4.1.1466.115.121.1.30 1920 Matching Rule Use Description 1.3.6.1.4.1.1466.115.121.1.31 1921 Name And Optional UID 1.3.6.1.4.1.1466.115.121.1.34 1922 Name Form Description 1.3.6.1.4.1.1466.115.121.1.35 1923 Numeric String 1.3.6.1.4.1.1466.115.121.1.36 1924 Object Class Description 1.3.6.1.4.1.1466.115.121.1.37 1925 Octet String 1.3.6.1.4.1.1466.115.121.1.40 1926 OID 1.3.6.1.4.1.1466.115.121.1.38 1927 Other Mailbox 1.3.6.1.4.1.1466.115.121.1.39 1928 Postal Address 1.3.6.1.4.1.1466.115.121.1.41 1929 Printable String 1.3.6.1.4.1.1466.115.121.1.44 1930 Substring Assertion 1.3.6.1.4.1.1466.115.121.1.58 1931 Telephone Number 1.3.6.1.4.1.1466.115.121.1.50 1932 Teletex Terminal Identifier 1.3.6.1.4.1.1466.115.121.1.51 1933 Telex Number 1.3.6.1.4.1.1466.115.121.1.52 1934 UTC Time 1.3.6.1.4.1.1466.115.121.1.53 1936 Appendix B. Changes from RFC 2252 & RFC 2256 1938 This annex lists the significant differences between this 1939 specification and RFC 2252 and Sections 6 and 8 of RFC 2256. 1941 This annex is provided for informational purposes only. It is not a 1942 normative part of this specification. 1944 1. The IESG Note has been removed. 1946 2. The major part of Sections 4, 5 and 7 has been moved to [MODELS] 1947 and revised. Changes to the parts of these sections moved to 1948 [MODELS] are detailed in [MODELS]. 1950 3. BNF descriptions of syntax formats have been replaced by ABNF 1951 [ABNF] specifications. 1953 4. The ambiguous statement in RFC 2252, Section 4.3 regarding the 1954 use of a backslash quoting mechanism to escape separator symbols 1955 has been removed. The escaping mechanism is now explicitly 1956 represented in the ABNF for the syntaxes where this provision 1957 applies. 1959 5. The description of each of the LDAP syntaxes has been expanded so 1960 that they are less dependent on knowledge of X.500 for 1961 interpretation. 1963 6. The relationship of LDAP syntaxes to corresponding ASN.1 type 1964 definitions has been made explicit. 1966 7. The set of characters allowed in a (formerly 1967 ) has been corrected to align with the 1968 PrintableString ASN.1 type in [ASN.1]. Specifically, the double 1969 quote character has been removed and the single quote character 1970 and equals sign have been added. 1972 8. Values of the Directory String, Printable String and Telephone 1973 Number syntaxes are now required to have at least one character. 1975 9. The , and 1976 rules have been moved to [MODELS]. 1978 10. The corresponding ASN.1 type for the Other Mailbox syntax has 1979 been incorporated from RFC 1274. 1981 11. A corresponding ASN.1 type for the LDAP Syntax Description syntax 1982 has been invented. 1984 12. The Binary syntax has been removed because it was not adequately 1985 specified, implementations with different incompatible 1986 interpretations exist, and it was confused with the ;binary 1987 transfer encoding. 1989 13. All discussion of transfer options, including the ";binary" 1990 option, has been removed. All imperatives regarding binary 1991 transfer of values have been removed. 1993 14. The Delivery Method, Enhanced Guide, Guide, Octet String, Teletex 1994 Terminal Identifier and Telex Number syntaxes from RFC 2256 have 1995 been incorporated. 1997 15. The rule for the Enhanced Guide and Guide syntaxes has 1998 been extended to accommodate empty "and" and "or" expressions. 2000 16. An encoding for the rule in the Teletex Terminal 2001 Identifier syntax has been defined. 2003 17. The PKI-related syntaxes (Certificate, Certificate List and 2004 Certificate Pair from RFC 2252, and Supported Algorithm syntax 2005 from RFC 2256) have been removed. They are to be reintroduced in 2006 PKIX documents. 2008 18. The MHS OR Address syntax has been removed since its 2009 specification (in RFC 2156) is not at draft standard maturity. 2011 19. The DL Submit Permission syntax has been removed as it depends on 2012 the MHS OR Address syntax. 2014 20. The Presentation Address syntax has been removed since its 2015 specification (in RFC 1278) is not at draft standard maturity. 2017 21. The ACI Item, Access Point, Audio, Data Quality, DSA Quality, DSE 2018 Type, LDAP Schema Description, Master And Shadow Access Points, 2019 Modify Rights, Protocol Information, Subtree Specification, 2020 Supplier Information, Supplier Or Consumer and Supplier And 2021 Consumer syntaxes have been removed. These syntaxes are 2022 referenced in RFC 2252, but not defined. 2024 22. The LDAP Schema Definition syntax (defined in RFC 2927) and the 2025 Mail Preference syntax have been removed on the grounds that they 2026 are out of scope for a core specification. 2028 23. The description of each of the matching rules has been expanded 2029 so that they are less dependent on knowledge of X.500 for 2030 interpretation. 2032 24. The caseIgnoreIA5SubstringsMatch matching rule from RFC 2798 has 2033 been added. 2035 25. The caseIgnoreIA5SubstringsMatch, caseIgnoreOrderingMatch and 2036 caseIgnoreSubstringsMatch matching rules have been added to the 2037 list of matching rules for which the provisions for handling 2038 leading, trailing and multiple adjoining whitespace characters 2039 apply. This is consistent with the definitions of these matching 2040 rules in X.500. The telephoneNumberMatch rule has been removed 2041 from the list since it completely ignores all space characters. 2043 26. The specification of the octetStringMatch matching rule from RFC 2044 2256 has been added to this document. 2046 27. The presentationAddressMatch matching rule has been removed as it 2047 depends on an assertion syntax (Presentation Address) that is not 2048 at draft standard maturity. 2050 28. The protocolInformationMatch matching rule has been removed as it 2051 depends on an undefined assertion syntax (Protocol Information). 2053 29. The definitive reference for ASN.1 has been changed from X.208 to 2054 X.680 since X.680 is the version of ASN.1 referred to by X.500.