idnits 2.17.1 draft-ietf-ldapbis-syntaxes-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.5 on line 2497. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2508. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2515. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2521. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 2489), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 11. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to 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 67 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 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated 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. -- The draft header indicates that this document updates RFC18, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC3698, 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 -- No information found for rfc18 - is the name correct? -- 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 (18 February 2005) is 7006 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 599 == Missing Reference: 'ISO8601' is mentioned on line 608, but not defined == Missing Reference: 'RFC3383' is mentioned on line 914, but not defined ** Obsolete undefined reference: RFC 3383 (Obsoleted by RFC 4520) ** Obsolete normative reference: RFC 2234 (ref. 'ABNF') (Obsoleted by RFC 4234) ** 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-zeilenga-ldap-x509-xx - is the name correct? Summary: 8 errors (**), 0 flaws (~~), 6 warnings (==), 31 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-10.txt eB2Bcom 4 Intended Category: Standards Track K. Dally 5 Obsoletes: RFC 2252, RFC 2256 The MITRE Corp. 6 Updates: RFC 3698 18 February 2005 8 Lightweight Directory Access Protocol (LDAP): 9 Syntaxes and Matching Rules 11 Copyright (C) The Internet Society (2005). All Rights Reserved. 13 Status of this Memo 15 By submitting this Internet-draft, we certify that any applicable 16 patent or other IPR claims of which we are aware have been disclosed, 17 or will be disclosed, and any of which we become aware will be 18 disclosed, in accordance with RFC 3668. 20 By submitting this Internet-draft, we accept the provisions of 21 Section 3 of RFC 3667. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as 26 Internet-Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress". 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This document is intended to be, after appropriate review and 40 revision, submitted to the RFC Editor as a Standard Track document. 41 Distribution of this document is unlimited. Technical discussion of 42 this document should take place on the IETF LDAP Revision Working 43 Group (LDAPbis) mailing list . Please 44 send editorial comments directly to the editor 45 . 47 This Internet-Draft expires on 18 August 2005. 49 Abstract 51 Each attribute stored in a Lightweight Directory Access Protocol 52 (LDAP) directory, and whose values may be transfered in the LDAP 53 protocol, has a defined syntax which constrains the structure and 54 format of its values. The comparison semantics for values of a 55 syntax are not part of the syntax definition but are instead provided 56 through separately defined matching rules. Matching rules specify an 57 argument, an assertion value, which also has a defined syntax. This 58 document defines a base set of syntaxes and matching rules for use in 59 defining attributes for LDAP directories. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 2. Conventions. . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 3. Syntaxes . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 3.1. General Considerations . . . . . . . . . . . . . . . . . 6 67 3.2. Common Definitions . . . . . . . . . . . . . . . . . . . 7 68 3.3. Syntax Definitions . . . . . . . . . . . . . . . . . . . 7 69 3.3.1. Attribute Type Description . . . . . . . . . . . 7 70 3.3.2. Bit String . . . . . . . . . . . . . . . . . . . 8 71 3.3.3. Boolean. . . . . . . . . . . . . . . . . . . . . 8 72 3.3.4. Country String . . . . . . . . . . . . . . . . . 8 73 3.3.5. Delivery Method. . . . . . . . . . . . . . . . . 9 74 3.3.6. Directory String . . . . . . . . . . . . . . . . 9 75 3.3.7. DIT Content Rule Description . . . . . . . . . . 10 76 3.3.8. DIT Structure Rule Description . . . . . . . . . 11 77 3.3.9. DN . . . . . . . . . . . . . . . . . . . . . . . 11 78 3.3.10. Enhanced Guide . . . . . . . . . . . . . . . . . 12 79 3.3.11. Facsimile Telephone Number . . . . . . . . . . . 13 80 3.3.12. Fax. . . . . . . . . . . . . . . . . . . . . . . 13 81 3.3.13. Generalized Time . . . . . . . . . . . . . . . . 14 82 3.3.14. Guide. . . . . . . . . . . . . . . . . . . . . . 15 83 3.3.15. IA5 String . . . . . . . . . . . . . . . . . . . 16 84 3.3.16. Integer. . . . . . . . . . . . . . . . . . . . . 16 85 3.3.17. JPEG . . . . . . . . . . . . . . . . . . . . . . 16 86 3.3.18. LDAP Syntax Description. . . . . . . . . . . . . 17 87 3.3.19. Matching Rule Description. . . . . . . . . . . . 17 88 3.3.20. Matching Rule Use Description. . . . . . . . . . 18 89 3.3.21. Name and Optional UID. . . . . . . . . . . . . . 18 90 3.3.22. Name Form Description. . . . . . . . . . . . . . 19 91 3.3.23. Numeric String . . . . . . . . . . . . . . . . . 19 92 3.3.24. Object Class Description . . . . . . . . . . . . 19 93 3.3.25. Octet String . . . . . . . . . . . . . . . . . . 20 94 3.3.26. OID. . . . . . . . . . . . . . . . . . . . . . . 20 95 3.3.27. Other Mailbox. . . . . . . . . . . . . . . . . . 21 96 3.3.28. Postal Address . . . . . . . . . . . . . . . . . 21 97 3.3.29. Printable String . . . . . . . . . . . . . . . . 22 98 3.3.30. Substring Assertion. . . . . . . . . . . . . . . 22 99 3.3.31. Telephone Number . . . . . . . . . . . . . . . . 23 100 3.3.32. Teletex Terminal Identifier. . . . . . . . . . . 24 101 3.3.33. Telex Number . . . . . . . . . . . . . . . . . . 25 102 3.3.34. UTC Time . . . . . . . . . . . . . . . . . . . . 25 103 4. Matching Rules . . . . . . . . . . . . . . . . . . . . . . . . 26 104 4.1. General Considerations . . . . . . . . . . . . . . . . . 26 105 4.2. Matching Rule Definitions. . . . . . . . . . . . . . . . 28 106 4.2.1. bitStringMatch . . . . . . . . . . . . . . . . . 28 107 4.2.2. booleanMatch . . . . . . . . . . . . . . . . . . 29 108 4.2.3. caseExactIA5Match. . . . . . . . . . . . . . . . 29 109 4.2.4. caseExactMatch . . . . . . . . . . . . . . . . . 29 110 4.2.5. caseExactOrderingMatch . . . . . . . . . . . . . 30 111 4.2.6. caseExactSubstringsMatch . . . . . . . . . . . . 30 112 4.2.7. caseIgnoreIA5Match . . . . . . . . . . . . . . . 31 113 4.2.8. caseIgnoreIA5SubstringsMatch . . . . . . . . . . 32 114 4.2.9. caseIgnoreListMatch. . . . . . . . . . . . . . . 32 115 4.2.10. caseIgnoreListSubstringsMatch. . . . . . . . . . 33 116 4.2.11. caseIgnoreMatch. . . . . . . . . . . . . . . . . 33 117 4.2.12. caseIgnoreOrderingMatch. . . . . . . . . . . . . 34 118 4.2.13. caseIgnoreSubstringsMatch. . . . . . . . . . . . 34 119 4.2.14. directoryStringFirstComponentMatch . . . . . . . 35 120 4.2.15. distinguishedNameMatch . . . . . . . . . . . . . 35 121 4.2.16. generalizedTimeMatch . . . . . . . . . . . . . . 36 122 4.2.17. generalizedTimeOrderingMatch . . . . . . . . . . 36 123 4.2.18. integerFirstComponentMatch . . . . . . . . . . . 37 124 4.2.19. integerMatch . . . . . . . . . . . . . . . . . . 37 125 4.2.20. integerOrderingMatch . . . . . . . . . . . . . . 38 126 4.2.21. keywordMatch . . . . . . . . . . . . . . . . . . 38 127 4.2.22. numericStringMatch . . . . . . . . . . . . . . . 38 128 4.2.23. numericStringOrderingMatch . . . . . . . . . . . 39 129 4.2.24. numericStringSubstringsMatch . . . . . . . . . . 40 130 4.2.25. objectIdentifierFirstComponentMatch. . . . . . . 40 131 4.2.26. objectIdentifierMatch. . . . . . . . . . . . . . 41 132 4.2.27. octetStringMatch . . . . . . . . . . . . . . . . 41 133 4.2.28. octetStringOrderingMatch . . . . . . . . . . . . 42 134 4.2.29. telephoneNumberMatch . . . . . . . . . . . . . . 42 135 4.2.30. telephoneNumberSubstringsMatch . . . . . . . . . 43 136 4.2.31. uniqueMemberMatch. . . . . . . . . . . . . . . . 43 137 4.2.32. wordMatch. . . . . . . . . . . . . . . . . . . . 44 138 5. Security Considerations. . . . . . . . . . . . . . . . . . . . 44 139 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 45 140 7. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 45 141 Appendix A. Summary of Syntax Object Identifiers . . . . . . . . . 46 142 Appendix B. Changes from RFC 2252. . . . . . . . . . . . . . . . . 47 143 Normative References . . . . . . . . . . . . . . . . . . . . . . . 50 144 Informative References . . . . . . . . . . . . . . . . . . . . . . 52 145 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 52 146 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 53 148 1. Introduction 150 Each attribute stored in a Lightweight Directory Access Protocol 151 (LDAP) directory [ROADMAP], and whose values may be transfered in the 152 LDAP protocol [PROT], has a defined syntax (i.e., data type) which 153 constrains the structure and format of its values. The comparison 154 semantics for values of a syntax are not part of the syntax 155 definition but are instead provided through separately defined 156 matching rules. Matching rules specify an argument, an assertion 157 value, which also has a defined syntax. This document defines a base 158 set of syntaxes and matching rules for use in defining attributes for 159 LDAP directories. 161 Readers are advised to familiarize themselves with the Directory 162 Information Models [MODELS] before reading the rest of this document. 163 Section 3 provides definitions for the base set of LDAP syntaxes. 164 Section 4 provides definitions for the base set of matching rules for 165 LDAP. 167 This document is a integral part of the LDAP technical specification 168 [ROADMAP] which obsoletes the previously defined LDAP technical 169 specification [RFC3377] in its entirety. 171 Sections 4, 5 and 7 of RFC 2252 [RFC2252] are obsoleted by [MODELS]. 172 The remainder of RFC 2252 is obsoleted by this document. Sections 6 173 and 8 of RFC 2256 [RFC2256] are obsoleted by this document. The 174 remainder of RFC 2256 is obsoleted by [SCHEMA] and [MODELS]. All but 175 Section 2.11 of RFC 3698 [RFC3698] is obsoleted by this document. 177 A number of schema elements which were included in the previous 178 revision of the LDAP technical specification are not included in this 179 revision of LDAP. Public Key Infrastructure schema elements are now 180 specified in [LDAP-PKI]. Unless reintroduced in future technical 181 specifications, the remainder are to be considered Historic. 183 The changes with respect to RFC 2252 are described in Appendix B of 184 this document. 186 2. Conventions 188 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 189 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 190 document are to be interpreted as described in BCP 14, RFC 2119 191 [KEYWORD]. 193 Syntax definitions are written according to the 194 ABNF [ABNF] rule specified in [MODELS], and matching rule definitions 195 are written according to the ABNF rule 196 specified in [MODELS], except that the syntax and matching rule 197 definitions provided in this document are line-wrapped for 198 readability. When such definitions are transfered as attribute 199 values in the LDAP protocol (e.g., as values of the ldapSyntaxes and 200 matchingRules attributes [MODELS] respectively) then those values 201 would not contain line breaks. 203 3. Syntaxes 204 Syntax definitions constrain the structure of attribute values stored 205 in an LDAP directory, and determine the representation of attribute 206 and assertion values transfered in the LDAP protocol. 208 Syntaxes that are required for directory operation, or that are in 209 common use, are specified in this section. Servers SHOULD recognize 210 all the syntaxes listed in this document, but are not required to 211 otherwise support them, and MAY recognise or support other syntaxes. 212 However, the definition of additional arbitrary syntaxes is 213 discouraged since it will hinder interoperability. Client and server 214 implementations typically do not have the ability to dynamically 215 recognize new syntaxes. 217 3.1. General Considerations 219 The description of each syntax specifies how attribute or assertion 220 values conforming to the syntax are to be represented when transfered 221 in the LDAP protocol [PROT]. This representation is referred to as 222 the LDAP-specific encoding to distinguish it from other methods of 223 encoding attribute values (e.g., the Basic Encoding Rules (BER) 224 encoding [BER] used by X.500 [X.500] directories). 226 The LDAP-specific encoding of a given attribute syntax always 227 produces octet-aligned values. To the greatest extent possible, 228 encoding rules for LDAP syntaxes should produce character strings 229 that can be displayed with little or no translation by clients 230 implementing LDAP. However, clients MUST NOT assume that the 231 LDAP-specific encoding of a value of an unrecognized syntax is a 232 human-readable character string. There are a few cases (e.g., the 233 JPEG syntax) when it is not reasonable to produce a human-readable 234 representation. 236 Each LDAP syntax is uniquely identified with an object identifier 237 [ASN.1] represented in the dotted-decimal format (short descriptive 238 names are not defined for syntaxes). These object identifiers are 239 not intended to be displayed to users. The object identifiers for 240 the syntaxes defined in this document are summarized in Appendix A. 242 A suggested minimum upper bound on the number of characters in an 243 attribute value with a string-based syntax, or the number of octets 244 in a value for all other syntaxes, MAY be indicated by appending the 245 bound inside of curly braces following the syntax's OBJECT IDENTIFIER 246 in an attribute type definition (see the rule in [MODELS]). 247 Such a bound is not considered part of the syntax identifier. 249 For example, "1.3.6.1.4.1.1466.115.121.1.15{64}" in an attribute 250 definition suggests that the directory server will allow a value of 251 the attribute to be up to 64 characters long, although it may allow 252 longer character strings. Note that a single character of the 253 Directory String syntax can be encoded in more than one octet since 254 UTF-8 [UTF8] is a variable-length encoding. Therefore a 64 character 255 string may be more than 64 octets in length. 257 3.2. Common Definitions 259 The following ABNF rules are used in a number of the syntax 260 definitions in Section 3.3. 262 PrintableCharacter = ALPHA / DIGIT / SQUOTE / LPAREN / RPAREN / 263 PLUS / COMMA / HYPHEN / DOT / EQUALS / 264 SLASH / COLON / QUESTION / SPACE 265 PrintableString = 1*PrintableCharacter 266 IA5String = *(%x00-7F) 267 SLASH = %x2F ; forward slash ("/") 268 COLON = %x3A ; colon (":") 269 QUESTION = %x3F ; question mark ("?") 271 The , , , , , , , 272 , , and rules are defined in [MODELS]. 274 3.3. Syntax Definitions 276 3.3.1. Attribute Type Description 278 A value of the Attribute Type Description syntax is the definition of 279 an attribute type. The LDAP-specific encoding of a value of this 280 syntax is defined by the rule in [MODELS]. 282 For example, the following definition of the createTimestamp 283 attribute type from [MODELS] is also a value of the Attribute Type 284 Description syntax (note: line breaks have been added for 285 readability - they are not part of the value when transfered in 286 protocol). 288 ( 2.5.18.1 NAME 'createTimestamp' 289 EQUALITY generalizedTimeMatch 290 ORDERING generalizedTimeOrderingMatch 291 SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 292 SINGLE-VALUE NO-USER-MODIFICATION 293 USAGE directoryOperation ) 295 The LDAP definition for the Attribute Type Description syntax is: 297 ( 1.3.6.1.4.1.1466.115.121.1.3 DESC 'Attribute Type Description' ) 299 This syntax corresponds to the AttributeTypeDescription ASN.1 type 300 from [X.501]. 302 3.3.2. Bit String 304 A value of the Bit String syntax is a sequence of binary digits. The 305 LDAP-specific encoding of a value of this syntax is defined by the 306 following ABNF: 308 BitString = SQUOTE *binary-digit SQUOTE "B" 309 binary-digit = "0" / "1" 311 The rule is defined in [MODELS]. 313 Example: 314 '0101111101'B 316 The LDAP definition for the Bit String syntax is: 318 ( 1.3.6.1.4.1.1466.115.121.1.6 DESC 'Bit String' ) 320 This syntax corresponds to the BIT STRING ASN.1 type from [ASN.1]. 322 3.3.3. Boolean 324 A value of the Boolean syntax is one of the Boolean values, true or 325 false. The LDAP-specific encoding of a value of this syntax is 326 defined by the following ABNF: 328 Boolean = "TRUE" / "FALSE" 330 The LDAP definition for the Boolean syntax is: 332 ( 1.3.6.1.4.1.1466.115.121.1.7 DESC 'Boolean' ) 334 This syntax corresponds to the BOOLEAN ASN.1 type from [ASN.1]. 336 3.3.4. Country String 338 A value of the Country String syntax is one of the two-character 339 codes from ISO 3166 [ISO3166] for representing a country. The 340 LDAP-specific encoding of a value of this syntax is defined by the 341 following ABNF: 343 CountryString = 2(PrintableCharacter) 345 The rule is defined in Section 3.2. 347 Examples: 349 US 350 AU 352 The LDAP definition for the Country String syntax is: 354 ( 1.3.6.1.4.1.1466.115.121.1.11 DESC 'Country String' ) 356 This syntax corresponds to the following ASN.1 type from [X.520]: 358 PrintableString (SIZE (2)) -- ISO 3166 codes only 360 3.3.5. Delivery Method 362 A value of the Delivery Method syntax is a sequence of items that 363 indicate, in preference order, the service(s) by which an entity is 364 willing and/or capable of receiving messages. The LDAP-specific 365 encoding of a value of this syntax is defined by the following ABNF: 367 DeliveryMethod = pdm *( WSP DOLLAR WSP pdm ) 369 pdm = "any" / "mhs" / "physical" / "telex" / "teletex" / 370 "g3fax" / "g4fax" / "ia5" / "videotex" / "telephone" 372 The and rules are defined in [MODELS]. 374 Example: 375 telephone $ videotex 377 The LDAP definition for the Delivery Method syntax is: 379 ( 1.3.6.1.4.1.1466.115.121.1.14 DESC 'Delivery Method' ) 381 This syntax corresponds to the following ASN.1 type from [X.520]: 383 SEQUENCE OF INTEGER { 384 any-delivery-method (0), 385 mhs-delivery (1), 386 physical-delivery (2), 387 telex-delivery (3), 388 teletex-delivery (4), 389 g3-facsimile-delivery (5), 390 g4-facsimile-delivery (6), 391 ia5-terminal-delivery (7), 392 videotex-delivery (8), 393 telephone-delivery (9) } 395 3.3.6. Directory String 396 A value of the Directory String syntax is a string of one or more 397 arbitrary characters from the Universal Character Set (UCS) [UCS]. A 398 zero length character string is not permitted. The LDAP-specific 399 encoding of a value of this syntax is the UTF-8 encoding [UTF8] of 400 the character string. Such encodings conform to the following ABNF: 402 DirectoryString = 1*UTF8 404 The rule is defined in [MODELS]. 406 Example: 407 This is a value of Directory String containing #!%#@. 409 Servers and clients MUST be prepared to receive arbitrary UCS code 410 points, including code points outside the range of printable ASCII 411 and code points not presently assigned to any character. 413 Attribute type definitions using the Directory String syntax should 414 not restrict the format of Directory String values, e.g., by 415 requiring that the character string conforms to specific patterns 416 described by ABNF. A new syntax should be defined in such cases. 418 The LDAP definition for the Directory String syntax is: 420 ( 1.3.6.1.4.1.1466.115.121.1.15 DESC 'Directory String' ) 422 This syntax corresponds to the DirectoryString parameterized ASN.1 423 type from [X.520]. 425 The DirectoryString ASN.1 type allows a choice between the 426 TeletexString, PrintableString or UniversalString ASN.1 types from 427 [ASN.1]. However, note that the chosen alternative is not indicated 428 in the LDAP-specific encoding of a Directory String value. 430 Implementations which convert Directory String values from the 431 LDAP-specific encoding to the BER encoding used by X.500 must choose 432 an alternative that permits the particular characters in the string, 433 and must convert the characters from the UTF-8 encoding into the 434 character encoding of the chosen alternative. When converting 435 Directory String values from the BER encoding to the LDAP-specific 436 encoding the characters must be converted from the character encoding 437 of the chosen alternative into the UTF-8 encoding. These conversions 438 SHOULD be done in a manner consistent with the Transcode step of the 439 string preparation algorithms [PREP] for LDAP. 441 3.3.7. DIT Content Rule Description 443 A value of the DIT Content Rule Description syntax is the definition 444 of a DIT (Directory Information Tree) content rule. The 445 LDAP-specific encoding of a value of this syntax is defined by the 446 rule in [MODELS]. 448 Example: 449 ( 2.5.6.4 DESC 'content rule for organization' 450 NOT ( x121Address $ telexNumber ) ) 452 Note: a line break has been added for readability - it is not part 453 of the value. 455 The LDAP definition for the DIT Content Rule Description syntax is: 457 ( 1.3.6.1.4.1.1466.115.121.1.16 458 DESC 'DIT Content Rule Description' ) 460 This syntax corresponds to the DITContentRuleDescription ASN.1 type 461 from [X.501]. 463 3.3.8. DIT Structure Rule Description 465 A value of the DIT Structure Rule Description syntax is the 466 definition of a DIT structure rule. The LDAP-specific encoding of a 467 value of this syntax is defined by the 468 rule in [MODELS]. 470 Example: 471 ( 2 DESC 'organization structure rule' FORM 2.5.15.3 ) 473 The LDAP definition for the DIT Structure Rule Description syntax is: 475 ( 1.3.6.1.4.1.1466.115.121.1.17 476 DESC 'DIT Structure Rule Description' ) 478 This syntax corresponds to the DITStructureRuleDescription ASN.1 type 479 from [X.501]. 481 3.3.9. DN 483 A value of the DN syntax is the (purported) distinguished name (DN) 484 of an entry [MODELS]. The LDAP-specific encoding of a value of this 485 syntax is defined by the rule from the string 486 representation of distinguished names [LDAPDN]. 488 Examples (from [LDAPDN]): 489 UID=jsmith,DC=example,DC=net 490 OU=Sales+CN=J. Smith,DC=example,DC=net 491 CN=John Smith\, III,DC=example,DC=net 492 CN=Before\0dAfter,DC=example,DC=net 493 1.3.6.1.4.1.1466.0=#04024869,DC=example,DC=com 494 CN=Lu\C4\8Di\C4\87 496 The LDAP definition for the DN syntax is: 498 ( 1.3.6.1.4.1.1466.115.121.1.12 DESC 'DN' ) 500 The DN syntax corresponds to the DistinguishedName ASN.1 type from 501 [X.501]. Note that a BER encoded distinguished name (as used by 502 X.500) re-encoded into the LDAP-specific encoding is not necessarily 503 reversible to the original BER encoding since the chosen string type 504 in any DirectoryString components of the distinguished name is not 505 indicated in the LDAP-specific encoding of the distinguished name 506 (see Section 3.3.6). 508 3.3.10. Enhanced Guide 510 A value of the Enhanced Guide syntax suggests criteria, which consist 511 of combinations of attribute types and filter operators, to be used 512 in constructing filters to search for entries of particular object 513 classes. The Enhanced Guide syntax improves upon the Guide syntax by 514 allowing the recommended depth of the search to be specified. 516 The LDAP-specific encoding of a value of this syntax is defined by 517 the following ABNF: 519 EnhancedGuide = object-class SHARP WSP criteria WSP 520 SHARP WSP subset 521 object-class = WSP oid WSP 522 subset = "baseobject" / "oneLevel" / "wholeSubtree" 524 criteria = and-term *( BAR and-term ) 525 and-term = term *( AMPERSAND term ) 526 term = EXCLAIM term / 527 attributetype DOLLAR match-type / 528 LPAREN criteria RPAREN / 529 true / 530 false 531 match-type = "EQ" / "SUBSTR" / "GE" / "LE" / "APPROX" 532 true = "?true" 533 false = "?false" 534 BAR = %x7C ; vertical bar ("|") 535 AMPERSAND = %x26 ; ampersand ("&") 536 EXCLAIM = %x21 ; exclamation mark ("!") 538 The , , , , , and 539 rules are defined in [MODELS]. 541 The LDAP definition for the Enhanced Guide syntax is: 543 ( 1.3.6.1.4.1.1466.115.121.1.21 DESC 'Enhanced Guide' ) 545 Example: 546 person#(sn$EQ)#oneLevel 548 The Enhanced Guide syntax corresponds to the EnhancedGuide ASN.1 type 549 from [X.520]. The EnhancedGuide type references the Criteria ASN.1 550 type, also from [X.520]. The rule above represents an empty 551 "and" expression in a value of the Criteria type. The rule 552 above represents an empty "or" expression in a value of the Criteria 553 type. 555 3.3.11. Facsimile Telephone Number 557 A value of the Facsimile Telephone Number syntax is a subscriber 558 number of a facsimile device on the public switched telephone 559 network. The LDAP-specific encoding of a value of this syntax is 560 defined by the following ABNF: 562 fax-number = telephone-number *( DOLLAR fax-parameter ) 563 telephone-number = PrintableString 564 fax-parameter = "twoDimensional" / 565 "fineResolution" / 566 "unlimitedLength" / 567 "b4Length" / 568 "a3Width" / 569 "b4Width" / 570 "uncompressed" 572 The is a string of printable characters that 573 complies with the internationally agreed format for representing 574 international telephone numbers [E.123]. The rule 575 is defined in Section 3.2. The rule is defined in [MODELS]. 577 The LDAP definition for the Facsimile Telephone Number syntax is: 579 ( 1.3.6.1.4.1.1466.115.121.1.22 DESC 'Facsimile Telephone Number') 581 The Facsimile Telephone Number syntax corresponds to the 582 FacsimileTelephoneNumber ASN.1 type from [X.520]. 584 3.3.12. Fax 586 A value of the Fax syntax is an image which is produced using the 587 Group 3 facsimile process [FAX] to duplicate an object, such as a 588 memo. The LDAP-specific encoding of a value of this syntax is the 589 string of octets for a Group 3 Fax image as defined in [FAX]. 591 The LDAP definition for the Fax syntax is: 593 ( 1.3.6.1.4.1.1466.115.121.1.23 DESC 'Fax' ) 595 The ASN.1 type corresponding to the Fax syntax is defined as follows, 596 assuming EXPLICIT TAGS: 598 Fax ::= CHOICE { 599 g3-facsimile [3] G3FacsimileBodyPart 600 } 602 The G3FacsimileBodyPart ASN.1 type is defined in [X.420]. 604 3.3.13. Generalized Time 606 A value of the Generalized Time syntax is a character string 607 representing a date and time. The LDAP-specific encoding of a value 608 of this syntax is a restriction of the format defined in [ISO8601], 609 and is described by the following ABNF: 611 GeneralizedTime = century year month day hour 612 [ minute [ second / leap-second ] ] 613 [ fraction ] 614 g-time-zone 616 century = 2(%x30-39) ; "00" to "99" 617 year = 2(%x30-39) ; "00" to "99" 618 month = ( %x30 %x31-39 ) ; "01" (January) to "09" 619 / ( %x31 %x30-32 ) ; "10" to "12" 620 day = ( %x30 %x31-39 ) ; "01" to "09" 621 / ( %x31-32 %x30-39 ) ; "10" to "29" 622 / ( %x33 %x30-31 ) ; "30" to "31" 623 hour = ( %x30-31 %x30-39 ) / ( %x32 %x30-33 ) ; "00" to "23" 624 minute = %x30-35 %x30-39 ; "00" to "59" 626 second = ( %x30-35 %x30-39 ) ; "00" to "59" 627 leap-second = ( %x36 %x30 ) ; "60" 629 fraction = ( DOT / COMMA ) 1*(%x30-39) 630 g-time-zone = %x5A ; "Z" 631 / g-differential 632 g-differential = ( MINUS / PLUS ) hour [ minute ] 633 MINUS = %x2D ; minus sign ("-") 635 The , and rules are defined in [MODELS]. 637 The above ABNF allows character strings which do not represent valid 638 dates (in the Gregorian calendar) and/or valid times (e.g., February 639 31, 1994). Such character strings SHOULD be considered invalid for 640 this syntax. 642 The time value represents coordinated universal time (equivalent to 643 Greenwich Mean Time) if the "Z" form of is used, 644 otherwise the value represents a local time in the time zone 645 indicated by . In the latter case, coordinated 646 universal time can be calculated by subtracting the differential from 647 the local time. The "Z" form of SHOULD be used in 648 preference to . 650 Examples: 651 199412161032Z 652 199412160532-0500 654 Both example values represent the same coordinated universal time: 655 10:32 AM, December 16, 1994. 657 The LDAP definition for the Generalized Time syntax is: 659 ( 1.3.6.1.4.1.1466.115.121.1.24 DESC 'Generalized Time' ) 661 This syntax corresponds to the GeneralizedTime ASN.1 type from 662 [ASN.1], with the constraint that local time without a differential 663 SHALL NOT be used. 665 3.3.14. Guide 667 A value of the Guide syntax suggests criteria, which consist of 668 combinations of attribute types and filter operators, to be used in 669 constructing filters to search for entries of particular object 670 classes. The Guide syntax is obsolete and should not be used for 671 defining new attribute types. 673 The LDAP-specific encoding of a value of this syntax is defined by 674 the following ABNF: 676 Guide = [ object-class SHARP ] criteria 678 The and rules are defined in Section 679 3.3.10. The rule is defined in [MODELS]. 681 The LDAP definition for the Guide syntax is: 683 ( 1.3.6.1.4.1.1466.115.121.1.25 DESC 'Guide' ) 685 The Guide syntax corresponds to the Guide ASN.1 type from [X.520]. 687 3.3.15. IA5 String 689 A value of the IA5 String syntax is a string of zero, one or more 690 characters from International Alphabet 5 (IA5) [T.50], the 691 international version of the ASCII character set. The LDAP-specific 692 encoding of a value of this syntax is the unconverted string of 693 characters, which conforms to the rule in Section 3.2. 695 The LDAP definition for the IA5 String syntax is: 697 ( 1.3.6.1.4.1.1466.115.121.1.26 DESC 'IA5 String' ) 699 This syntax corresponds to the IA5String ASN.1 type from [ASN.1]. 701 3.3.16. Integer 703 A value of the Integer syntax is a whole number of unlimited 704 magnitude. The LDAP-specific encoding of a value of this syntax is 705 the optionally signed decimal digit character string representation 706 of the number (so, for example, the number 1321 is represented by the 707 character string "1321"). The encoding is defined by the following 708 ABNF: 710 Integer = ( HYPHEN LDIGIT *DIGIT ) / number 712 The , , and rules are defined in 713 [MODELS]. 715 The LDAP definition for the Integer syntax is: 717 ( 1.3.6.1.4.1.1466.115.121.1.27 DESC 'INTEGER' ) 719 This syntax corresponds to the INTEGER ASN.1 type from [ASN.1]. 721 3.3.17. JPEG 723 A value of the JPEG syntax is an image in the JPEG File Interchange 724 Format (JFIF), as described in [JPEG]. The LDAP-specific encoding of 725 a value of this syntax is the sequence of octets of the JFIF encoding 726 of the image. 728 The LDAP definition for the JPEG syntax is: 730 ( 1.3.6.1.4.1.1466.115.121.1.28 DESC 'JPEG' ) 732 The JPEG syntax corresponds to the following ASN.1 type: 734 JPEG ::= OCTET STRING (CONSTRAINED BY 735 { -- contents octets are an image in the -- 736 -- JPEG File Interchange Format -- }) 738 3.3.18. LDAP Syntax Description 740 A value of the LDAP Syntax Description syntax is the description of 741 an LDAP syntax. The LDAP-specific encoding of a value of this syntax 742 is defined by the rule in [MODELS]. 744 The LDAP definition for the LDAP Syntax Description syntax is: 746 ( 1.3.6.1.4.1.1466.115.121.1.54 DESC 'LDAP Syntax Description' ) 748 The above LDAP definition for the LDAP Syntax Description syntax is 749 itself a legal value of the LDAP Syntax Description syntax. 751 The ASN.1 type corresponding to the LDAP Syntax Description syntax is 752 defined as follows, assuming EXPLICIT TAGS: 754 LDAPSyntaxDescription ::= SEQUENCE { 755 identifier OBJECT IDENTIFIER, 756 description DirectoryString { ub-schema } OPTIONAL } 758 The DirectoryString parameterized ASN.1 type is defined in [X.520]. 760 The value of ub-schema (an integer) is implementation defined. A 761 non-normative definition appears in [X.520]. 763 3.3.19. Matching Rule Description 765 A value of the Matching Rule Description syntax is the definition of 766 a matching rule. The LDAP-specific encoding of a value of this 767 syntax is defined by the rule in [MODELS]. 769 Example: 770 ( 2.5.13.2 NAME 'caseIgnoreMatch' 771 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 773 Note: a line break has been added for readability - it is not part of 774 the syntax. 776 The LDAP definition for the Matching Rule Description syntax is: 778 ( 1.3.6.1.4.1.1466.115.121.1.30 DESC 'Matching Rule Description' ) 780 This syntax corresponds to the MatchingRuleDescription ASN.1 type 781 from [X.501]. 783 3.3.20. Matching Rule Use Description 785 A value of the Matching Rule Use Description syntax indicates the 786 attribute types to which a matching rule may be applied in an 787 extensibleMatch search filter [PROT]. The LDAP-specific encoding of 788 a value of this syntax is defined by the 789 rule in [MODELS]. 791 Example: 792 ( 2.5.13.16 APPLIES ( givenName $ surname ) ) 794 The LDAP definition for the Matching Rule Use Description syntax is: 796 ( 1.3.6.1.4.1.1466.115.121.1.31 797 DESC 'Matching Rule Use Description' ) 799 This syntax corresponds to the MatchingRuleUseDescription ASN.1 type 800 from [X.501]. 802 3.3.21. Name and Optional UID 804 A value of the Name and Optional UID syntax is the distinguished name 805 [MODELS] of an entity optionally accompanied by a unique identifier 806 that serves to differentiate the entity from others with an identical 807 distinguished name. 809 The LDAP-specific encoding of a value of this syntax is defined by 810 the following ABNF: 812 NameAndOptionalUID = distinguishedName [ SHARP BitString ] 814 The rule is defined in Section 3.3.2. The 815 rule is defined in [LDAPDN]. The rule is 816 defined in [MODELS]. 818 Note that although the '#' character may occur in the string 819 representation of a distinguished name, no additional escaping of 820 this character is performed when a is encoded in 821 a . 823 Example: 824 1.3.6.1.4.1.1466.0=#04024869,O=Test,C=GB#'0101'B 826 The LDAP definition for the Name and Optional UID syntax is: 828 ( 1.3.6.1.4.1.1466.115.121.1.34 DESC 'Name And Optional UID' ) 830 This syntax corresponds to the NameAndOptionalUID ASN.1 type from 832 [X.520]. 834 3.3.22. Name Form Description 836 A value of the Name Form Description syntax is the definition of a 837 name form, which regulates how entries may be named. The 838 LDAP-specific encoding of a value of this syntax is defined by the 839 rule in [MODELS]. 841 Example: 842 ( 2.5.15.3 NAME 'orgNameForm' OC organization MUST o ) 844 The LDAP definition for the Name Form Description syntax is: 846 ( 1.3.6.1.4.1.1466.115.121.1.35 DESC 'Name Form Description' ) 848 This syntax corresponds to the NameFormDescription ASN.1 type from 849 [X.501]. 851 3.3.23. Numeric String 853 A value of the Numeric String syntax is a sequence of one or more 854 numerals and spaces. The LDAP-specific encoding of a value of this 855 syntax is the unconverted string of characters, which conforms to the 856 following ABNF: 858 NumericString = 1*(DIGIT / SPACE) 860 The and rules are defined in [MODELS]. 862 Example: 863 15 079 672 281 865 The LDAP definition for the Numeric String syntax is: 867 ( 1.3.6.1.4.1.1466.115.121.1.36 DESC 'Numeric String' ) 869 This syntax corresponds to the NumericString ASN.1 type from [ASN.1]. 871 3.3.24. Object Class Description 873 A value of the Object Class Description syntax is the definition of 874 an object class. The LDAP-specific encoding of a value of this 875 syntax is defined by the rule in [MODELS]. 877 Example: 878 ( 2.5.6.2 NAME 'country' SUP top STRUCTURAL MUST c 879 MAY ( searchGuide $ description ) ) 881 Note: a line break has been added for readability - it is not part of 882 the syntax. 884 The LDAP definition for the Object Class Description syntax is: 886 ( 1.3.6.1.4.1.1466.115.121.1.37 DESC 'Object Class Description' ) 888 This syntax corresponds to the ObjectClassDescription ASN.1 type from 889 [X.501]. 891 3.3.25. Octet String 893 A value of the Octet String syntax is a sequence of zero, one or more 894 arbitrary octets. The LDAP-specific encoding of a value of this 895 syntax is the unconverted sequence of octets, which conforms to the 896 following ABNF: 898 OctetString = *OCTET 900 The rule is defined in [MODELS]. Values of this syntax are 901 not generally human-readable. 903 The LDAP definition for the Octet String syntax is: 905 ( 1.3.6.1.4.1.1466.115.121.1.40 DESC 'Octet String' ) 907 This syntax corresponds to the OCTET STRING ASN.1 type from [ASN.1]. 909 3.3.26. OID 911 A value of the OID syntax is an object identifier; a sequence of two 912 or more non-negative integers that uniquely identify some object or 913 item of specification. Many of the object identifiers used in LDAP 914 also have IANA registered names [RFC3383]. 916 The LDAP-specific encoding of a value of this syntax is defined by 917 the rule in [MODELS]. 919 Examples: 920 1.2.3.4 921 cn 923 The LDAP definition for the OID syntax is: 925 ( 1.3.6.1.4.1.1466.115.121.1.38 DESC 'OID' ) 927 This syntax corresponds to the OBJECT IDENTIFIER ASN.1 type from 928 [ASN.1]. 930 3.3.27. Other Mailbox 932 A value of the Other Mailbox syntax identifies an electronic mailbox, 933 in a particular named mail system. The LDAP-specific encoding of a 934 value of this syntax is defined by the following ABNF: 936 OtherMailbox = mailbox-type DOLLAR mailbox 937 mailbox-type = PrintableString 938 mailbox = IA5String 940 The rule represents the type of mail system in which 941 the mailbox resides, for example "MCIMail", and is the 942 actual mailbox in the mail system described by . The 943 and rules are defined in Section 3.2. 944 The rule is defined in [MODELS]. 946 The LDAP definition for the Other Mailbox syntax is: 948 ( 1.3.6.1.4.1.1466.115.121.1.39 DESC 'Other Mailbox' ) 950 The ASN.1 type corresponding to the Other Mailbox syntax is defined 951 as follows, assuming EXPLICIT TAGS: 953 OtherMailbox ::= SEQUENCE { 954 mailboxType PrintableString, 955 mailbox IA5String 956 } 958 3.3.28. Postal Address 960 A value of the Postal Address syntax is a sequence of strings of one 961 or more arbitrary UCS characters, which form an address in a physical 962 mail system. 964 The LDAP-specific encoding of a value of this syntax is defined by 965 the following ABNF: 967 PostalAddress = line *( DOLLAR line ) 968 line = 1*line-char 969 line-char = %x00-23 970 / (%x5C "24") ; escaped "$" 971 / %x25-5B 972 / (%x5C "5C") ; escaped "\" 973 / %x5D-7F 974 / UTFMB 976 Each character string (i.e., ) of a postal address value is 977 encoded as a UTF-8 [UTF8] string except that "\" and "$" characters, 978 if they occur in the string, are escaped by a "\" character followed 979 by the two hexadecimal digit code for the character. The 980 and rules are defined in [MODELS]. 982 Many servers limit the postal address to no more than six lines of no 983 more than thirty characters each. 985 Example: 986 1234 Main St.$Anytown, CA 12345$USA 987 \241,000,000 Sweepstakes$PO Box 1000000$Anytown, CA 12345$USA 989 The LDAP definition for the Postal Address syntax is: 991 ( 1.3.6.1.4.1.1466.115.121.1.41 DESC 'Postal Address' ) 993 This syntax corresponds to the PostalAddress ASN.1 type from [X.520], 994 i.e., 996 PostalAddress ::= SEQUENCE SIZE(1..ub-postal-line) OF 997 DirectoryString { ub-postal-string } 999 The values of ub-postal-line and ub-postal-string (both integers) are 1000 implementation defined. Non-normative definitions appear in [X.520]. 1002 3.3.29. Printable String 1004 A value of the Printable String syntax is a string of one or more 1005 latin alphabetic, numeric, and selected punctuation characters as 1006 specified by the rule in Section 3.2. 1008 The LDAP-specific encoding of a value of this syntax is the 1009 unconverted string of characters, which conforms to the 1010 rule in Section 3.2. 1012 Example: 1013 This is a PrintableString. 1015 The LDAP definition for the PrintableString syntax is: 1017 ( 1.3.6.1.4.1.1466.115.121.1.44 DESC 'Printable String' ) 1019 This syntax corresponds to the PrintableString ASN.1 type from 1020 [ASN.1]. 1022 3.3.30. Substring Assertion 1024 A value of the Substring Assertion syntax is a sequence of zero, one 1025 or more character substrings used as an argument for substring 1026 extensible matching of character string attribute values, i.e., as 1027 the matchValue of a MatchingRuleAssertion [PROT]. Each substring is 1028 a string of one or more arbitrary characters from the Universal 1029 Character Set (UCS) [UCS]. A zero length substring is not permitted. 1031 The LDAP-specific encoding of a value of this syntax is defined by 1032 the following ABNF: 1034 SubstringAssertion = [ initial ] any [ final ] 1036 initial = substring 1037 any = ASTERISK *(substring ASTERISK) 1038 final = substring 1039 ASTERISK = %x2A ; asterisk ("*") 1041 substring = 1*substring-character 1042 substring-character = %x00-29 1043 / (%x5C "2A") ; escaped "*" 1044 / %x2B-5B 1045 / (%x5C "5C") ; escaped "\" 1046 / %x5D-7F 1047 / UTFMB 1049 Each of a Substring Assertion value is encoded as a UTF-8 1050 [UTF8] string, except that "\" and "*" characters, if they occur in 1051 the substring, are escaped by a "\" character followed by the two 1052 hexadecimal digit code for the character. 1054 The Substring Assertion syntax is used only as the syntax of 1055 assertion values in the extensible match. It is not used as an 1056 attribute syntax, or in the SubstringFilter [PROT]. 1058 The LDAP definition for the Substring Assertion syntax is: 1060 ( 1.3.6.1.4.1.1466.115.121.1.58 DESC 'Substring Assertion' ) 1062 This syntax corresponds to the SubstringAssertion ASN.1 type from 1063 [X.520]. 1065 3.3.31. Telephone Number 1067 A value of the Telephone Number syntax is a string of printable 1068 characters that complies with the internationally agreed format for 1069 representing international telephone numbers [E.123]. 1071 The LDAP-specific encoding of a value of this syntax is the 1072 unconverted string of characters, which conforms to the 1073 rule in Section 3.2. 1075 Examples: 1076 +1 512 315 0280 1077 +1-512-315-0280 1078 +61 3 9896 7830 1080 The LDAP definition for the Telephone Number syntax is: 1082 ( 1.3.6.1.4.1.1466.115.121.1.50 DESC 'Telephone Number' ) 1084 The Telephone Number syntax corresponds to the following ASN.1 type 1085 from [X.520]: 1087 PrintableString (SIZE(1..ub-telephone-number)) 1089 The value of ub-telephone-number (an integer) is implementation 1090 defined. A non-normative definition appears in [X.520]. 1092 3.3.32. Teletex Terminal Identifier 1094 A value of this syntax specifies the identifier and (optionally) 1095 parameters of a teletex terminal. 1097 The LDAP-specific encoding of a value of this syntax is defined by 1098 the following ABNF: 1100 teletex-id = ttx-term *(DOLLAR ttx-param) 1101 ttx-term = PrintableString ; terminal identifier 1102 ttx-param = ttx-key COLON ttx-value ; parameter 1103 ttx-key = "graphic" / "control" / "misc" / "page" / "private" 1104 ttx-value = *ttx-value-octet 1106 ttx-value-octet = %x00-23 1107 / (%x5C "24") ; escaped "$" 1108 / %x25-5B 1109 / (%x5C "5C") ; escaped "\" 1110 / %x5D-FF 1112 The and rules are defined in Section 3.2. 1113 The rule is defined in [MODELS]. 1115 The LDAP definition for the Teletex Terminal Identifier syntax is: 1117 ( 1.3.6.1.4.1.1466.115.121.1.51 1118 DESC 'Teletex Terminal Identifier' ) 1120 This syntax corresponds to the TeletexTerminalIdentifier ASN.1 type 1121 from [X.520]. 1123 3.3.33. Telex Number 1125 A value of the Telex Number syntax specifies the telex number, 1126 country code and answerback code of a telex terminal. 1128 The LDAP-specific encoding of a value of this syntax is defined by 1129 the following ABNF: 1131 telex-number = actual-number DOLLAR country-code 1132 DOLLAR answerback 1133 actual-number = PrintableString 1134 country-code = PrintableString 1135 answerback = PrintableString 1137 The rule is defined in Section 3.2. The 1138 rule is defined in [MODELS]. 1140 The LDAP definition for the Telex Number syntax is: 1142 ( 1.3.6.1.4.1.1466.115.121.1.52 DESC 'Telex Number' ) 1144 This syntax corresponds to the TelexNumber ASN.1 type from [X.520]. 1146 3.3.34. UTC Time 1148 A value of the UTC Time syntax is a character string representing a 1149 date and time to a precision of one minute or one second. The year 1150 is given as a two-digit number. The LDAP-specific encoding of a 1151 value of this syntax follows the format defined in [ASN.1] for the 1152 UTCTime type and is described by the following ABNF: 1154 UTCTime = year month day hour minute [ second ] 1155 [ u-time-zone ] 1156 u-time-zone = %x5A ; "Z" 1157 / u-differential 1158 u-differential = ( MINUS / PLUS ) hour minute 1160 The , , , , , and 1161 rules are defined in Section 3.3.13. The rule is defined in 1162 [MODELS]. 1164 The above ABNF allows character strings which do not represent valid 1165 dates (in the Gregorian calendar) and/or valid times. Such character 1166 strings SHOULD be considered invalid for this syntax. 1168 The time value represents coordinated universal time if the "Z" form 1169 of is used, otherwise the value represents a local 1170 time. In the latter case, if is provided then 1171 coordinated universal time can be calculated by subtracting the 1172 differential from the local time. The SHOULD be 1173 present in time values and the "Z" form of SHOULD be 1174 used in preference to . 1176 The LDAP definition for the UTC Time syntax is: 1178 ( 1.3.6.1.4.1.1466.115.121.1.53 DESC 'UTC Time' ) 1180 Note: This syntax is deprecated in favor of the Generalized Time 1181 syntax. 1183 The UTC Time syntax corresponds to the UTCTime ASN.1 type from 1184 [ASN.1]. 1186 4. Matching Rules 1188 Matching rules are used by directory implementations to compare 1189 attribute values against assertion values when performing Search and 1190 Compare operations [PROT]. They are also used when comparing a 1191 purported distinguished name [MODELS] with the name of an entry. 1192 When modifying entries, matching rules are used to identify values to 1193 be deleted and to prevent an attribute from containing two equal 1194 values. 1196 Matching rules that are required for directory operation, or that are 1197 in common use, are specified in this section. 1199 4.1. General Considerations 1201 A matching rule is applied to attribute values through an 1202 AttributeValueAssertion or MatchingRuleAssertion [PROT]. The 1203 conditions under which an AttributeValueAssertion or 1204 MatchingRuleAssertion evaluates to Undefined are specified elsewhere 1205 [PROT]. If an assertion is not Undefined then the result of the 1206 assertion is the result of applying the selected matching rule. A 1207 matching rule evaluates to TRUE, and in some cases Undefined, as 1208 specified in the description of the matching rule, otherwise it 1209 evaluates to FALSE. 1211 Each assertion contains an assertion value. The definition of each 1212 matching rule specifies the syntax for the assertion value. The 1213 syntax of the assertion value is typically, but not necessarily, the 1214 same as the syntax of the attribute values to which the matching rule 1215 may be applied. Note that an AssertionValue in a SubstringFilter 1216 [PROT] conforms to the assertion syntax of the equality matching rule 1217 for the attribute type rather than the assertion syntax of the 1218 substrings matching rule for the attribute type. Conceptually, the 1219 entire SubstringFilter is converted into an assertion value of the 1220 substrings matching rule prior to applying the rule. 1222 The definition of each matching rule indicates the attribute syntaxes 1223 to which the rule may be applied, by specifying conditions the 1224 corresponding ASN.1 type of a candidate attribute syntax must 1225 satisfy. These conditions are also satisfied if the corresponding 1226 ASN.1 type is a tagged or constrained derivative of the ASN.1 type 1227 explicitly mentioned in the rule description (i.e., ASN.1 tags and 1228 constraints are ignored in checking applicability), or an alternative 1229 reference notation for the explicitly mentioned type. Each rule 1230 description lists as examples of applicable attribute syntaxes, the 1231 complete list of the syntaxes defined in this document to which the 1232 matching rule applies. A matching rule may be applicable to 1233 additional syntaxes defined in other documents if those syntaxes 1234 satisfy the conditions on the corresponding ASN.1 type. 1236 The description of each matching rule indicates whether the rule is 1237 suitable for use as the equality matching rule (EQUALITY), ordering 1238 matching rule (ORDERING) or substrings matching rule (SUBSTR) in an 1239 attribute type definition [MODELS]. 1241 Each matching rule is uniquely identified with an object identifier. 1242 The definition of a matching rule should not be subsequently changed. 1243 If a change is desirable then a new matching rule with a different 1244 object identifier should be defined instead. 1246 Servers MAY implement the wordMatch and keywordMatch matching rules, 1247 but SHOULD implement the other matching rules in Section 4.2. 1248 Servers MAY implement additional matching rules. 1250 Servers which implement the extensibleMatch filter SHOULD allow the 1251 matching rules listed in Section 4.2 to be used in the 1252 extensibleMatch filter and SHOULD allow matching rules to be used 1253 with all attribute types known to the server, where the assertion 1254 syntax of the matching rule is the same as the value syntax of the 1255 attribute. 1257 Servers MUST publish in the matchingRules attribute, the definitions 1258 of matching rules referenced by values of the attributeTypes and 1259 matchingRuleUse attributes in the same subschema entry. Other 1260 unreferenced matching rules MAY be published in the matchingRules 1261 attribute. 1263 If the server supports the extensibleMatch filter, then the server 1264 MAY use the matchingRuleUse attribute to indicate the applicability 1265 (in an extensibleMatch filter) of selected matching rules to 1266 nominated attribute types. 1268 4.2. Matching Rule Definitions 1270 Nominated character strings in assertion and attribute values are 1271 prepared according to the string preparation algorithms [PREP] for 1272 LDAP when evaluating the following matching rules: 1274 numericStringMatch, 1275 numericStringSubstringsMatch, 1276 caseExactMatch, 1277 caseExactOrderingMatch, 1278 caseExactSubstringsMatch, 1279 caseExactIA5Match, 1280 caseIgnoreIA5Match, 1281 caseIgnoreIA5SubstringsMatch, 1282 caseIgnoreListMatch, 1283 caseIgnoreListSubstringsMatch, 1284 caseIgnoreMatch, 1285 caseIgnoreOrderingMatch, 1286 caseIgnoreSubstringsMatch, 1287 directoryStringFirstComponentMatch, 1288 telephoneNumberMatch, 1289 telephoneNumberSubstringsMatch and 1290 wordMatch. 1292 The Transcode, Normalize, Prohibit and Check bidi steps are the same 1293 for each of the matching rules. However, the Map and Insignificant 1294 Character Handling steps depends on the specific rule, as detailed in 1295 the description of these matching rules in the sections that follow. 1297 4.2.1. bitStringMatch 1299 The bitStringMatch rule compares an assertion value of the Bit String 1300 syntax to an attribute value of a syntax (e.g., the Bit String 1301 syntax) whose corresponding ASN.1 type is BIT STRING. 1303 If the corresponding ASN.1 type of the attribute syntax does not have 1304 a named bit list [ASN.1] (which is the case for the Bit String 1305 syntax) then the rule evaluates to TRUE if and only if the attribute 1306 value has the same number of bits as the assertion value and the bits 1307 match on a bitwise basis. 1309 If the corresponding ASN.1 type does have a named bit list then 1310 bitStringMatch operates as above except that trailing zero bits in 1311 the attribute and assertion values are treated as absent. 1313 The LDAP definition for the bitStringMatch rule is: 1315 ( 2.5.13.16 NAME 'bitStringMatch' 1316 SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 ) 1318 The bitStringMatch rule is an equality matching rule. 1320 4.2.2. booleanMatch 1322 The booleanMatch rule compares an assertion value of the Boolean 1323 syntax to an attribute value of a syntax (e.g., the Boolean syntax) 1324 whose corresponding ASN.1 type is BOOLEAN. 1326 The rule evaluates to TRUE if and only if the attribute value and the 1327 assertion value are both TRUE or both FALSE. 1329 The LDAP definition for the booleanMatch rule is: 1331 ( 2.5.13.13 NAME 'booleanMatch' 1332 SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 ) 1334 The booleanMatch rule is an equality matching rule. 1336 4.2.3. caseExactIA5Match 1338 The caseExactIA5Match rule compares an assertion value of the IA5 1339 String syntax to an attribute value of a syntax (e.g the IA5 String 1340 syntax) whose corresponding ASN.1 type is IA5String. 1342 The rule evaluates to TRUE if and only if the prepared attribute 1343 value character string and the prepared assertion value character 1344 string have the same number of characters and corresponding 1345 characters have the same code point. 1347 In preparing the attribute value and assertion value for comparison, 1348 characters are not case folded in the Map preparation step, and only 1349 Insignificant Space Handling is applied in the Insignificant 1350 Character Handling step. 1352 The LDAP definition for the caseExactIA5Match rule is: 1354 ( 1.3.6.1.4.1.1466.109.114.1 NAME 'caseExactIA5Match' 1355 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) 1357 The caseExactIA5Match rule is an equality matching rule. 1359 4.2.4. caseExactMatch 1361 The caseExactMatch rule compares an assertion value of the Directory 1362 String syntax to an attribute value of a syntax (e.g., the Directory 1363 String, Printable String, Country String or Telephone Number syntax) 1364 whose corresponding ASN.1 type is DirectoryString or one of the 1365 alternative string types of DirectoryString, e.g., PrintableString 1366 (the other alternatives do not correspond to any syntax defined in 1367 this document). 1369 The rule evaluates to TRUE if and only if the prepared attribute 1370 value character string and the prepared assertion value character 1371 string have the same number of characters and corresponding 1372 characters have the same code point. 1374 In preparing the attribute value and assertion value for comparison, 1375 characters are not case folded in the Map preparation step, and only 1376 Insignificant Space Handling is applied in the Insignificant 1377 Character Handling step. 1379 The LDAP definition for the caseExactMatch rule is: 1381 ( 2.5.13.5 NAME 'caseExactMatch' 1382 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 1384 The caseExactMatch rule is an equality matching rule. 1386 4.2.5. caseExactOrderingMatch 1388 The caseExactOrderingMatch rule compares an assertion value of the 1389 Directory String syntax to an attribute value of a syntax (e.g., the 1390 Directory String, Printable String, Country String or Telephone 1391 Number syntax) whose corresponding ASN.1 type is DirectoryString or 1392 one of its alternative string types. 1394 The rule evaluates to TRUE if, and only if, in the code point 1395 collation order, the prepared attribute value character string 1396 appears earlier than the prepared assertion value character string, 1397 i.e., the attribute value is "less than" the assertion value. 1399 In preparing the attribute value and assertion value for comparison, 1400 characters are not case folded in the Map preparation step, and only 1401 Insignificant Space Handling is applied in the Insignificant 1402 Character Handling step. 1404 The LDAP definition for the caseExactOrderingMatch rule is: 1406 ( 2.5.13.6 NAME 'caseExactOrderingMatch' 1407 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 1409 The caseExactOrderingMatch rule is an ordering matching rule. 1411 4.2.6. caseExactSubstringsMatch 1412 The caseExactSubstringsMatch rule compares an assertion value of the 1413 Substring Assertion syntax to an attribute value of a syntax (e.g., 1414 the Directory String, Printable String, Country String or Telephone 1415 Number syntax) whose corresponding ASN.1 type is DirectoryString or 1416 one of its alternative string types. 1418 The rule evaluates to TRUE if and only if the prepared substrings of 1419 the assertion value match disjoint portions of the prepared attribute 1420 value character string in the order of the substrings in the 1421 assertion value, and an substring, if present, matches the 1422 beginning of the prepared attribute value character string, and a 1423 substring, if present, matches the end of the prepared 1424 attribute value character string. A prepared substring matches a 1425 portion of the prepared attribute value character string if 1426 corresponding characters have the same code point. 1428 In preparing the attribute value and assertion value substrings for 1429 comparison, characters are not case folded in the Map preparation 1430 step, and only Insignificant Space Handling is applied in the 1431 Insignificant Character Handling step. 1433 The LDAP definition for the caseExactSubstringsMatch rule is: 1435 ( 2.5.13.7 NAME 'caseExactSubstringsMatch' 1436 SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 ) 1438 The caseExactSubstringsMatch rule is a substrings matching rule. 1440 4.2.7. caseIgnoreIA5Match 1442 The caseIgnoreIA5Match rule compares an assertion value of the IA5 1443 String syntax to an attribute value of a syntax (e.g the IA5 String 1444 syntax) whose corresponding ASN.1 type is IA5String. 1446 The rule evaluates to TRUE if and only if the prepared attribute 1447 value character string and the prepared assertion value character 1448 string have the same number of characters and corresponding 1449 characters have the same code point. 1451 In preparing the attribute value and assertion value for comparison, 1452 characters are case folded in the Map preparation step, and only 1453 Insignificant Space Handling is applied in the Insignificant 1454 Character Handling step. 1456 The LDAP definition for the caseIgnoreIA5Match rule is: 1458 ( 1.3.6.1.4.1.1466.109.114.2 NAME 'caseIgnoreIA5Match' 1459 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) 1461 The caseIgnoreIA5Match rule is an equality matching rule. 1463 4.2.8. caseIgnoreIA5SubstringsMatch 1465 The caseIgnoreIA5SubstringsMatch rule compares an assertion value of 1466 the Substring Assertion syntax to an attribute value of a syntax (e.g 1467 the IA5 String syntax) whose corresponding ASN.1 type is IA5String. 1469 The rule evaluates to TRUE if and only if the prepared substrings of 1470 the assertion value match disjoint portions of the prepared attribute 1471 value character string in the order of the substrings in the 1472 assertion value, and an substring, if present, matches the 1473 beginning of the prepared attribute value character string, and a 1474 substring, if present, matches the end of the prepared 1475 attribute value character string. A prepared substring matches a 1476 portion of the prepared attribute value character string if 1477 corresponding characters have the same code point. 1479 In preparing the attribute value and assertion value substrings for 1480 comparison, characters are case folded in the Map preparation step, 1481 and only Insignificant Space Handling is applied in the Insignificant 1482 Character Handling step. 1484 ( 1.3.6.1.4.1.1466.109.114.3 NAME 'caseIgnoreIA5SubstringsMatch' 1485 SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 ) 1487 The caseIgnoreIA5SubstringsMatch rule is a substrings matching rule. 1489 4.2.9. caseIgnoreListMatch 1491 The caseIgnoreListMatch rule compares an assertion value that is a 1492 sequence of strings to an attribute value of a syntax (e.g., the 1493 Postal Address syntax) whose corresponding ASN.1 type is a SEQUENCE 1494 OF the DirectoryString ASN.1 type. 1496 The rule evaluates to TRUE if and only if the attribute value and the 1497 assertion value have the same number of strings and corresponding 1498 strings (by position) match according to the caseIgnoreMatch matching 1499 rule. 1501 In [X.520] the assertion syntax for this matching rule is defined to 1502 be: 1504 SEQUENCE OF DirectoryString {ub-match} 1506 i.e., different from the corresponding type for the Postal Address 1507 syntax. The choice of the Postal Address syntax for the assertion 1508 syntax of the caseIgnoreListMatch in LDAP should not be seen as 1509 limiting the matching rule to only apply to attributes with the 1510 Postal Address syntax. 1512 The LDAP definition for the caseIgnoreListMatch rule is: 1514 ( 2.5.13.11 NAME 'caseIgnoreListMatch' 1515 SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 ) 1517 The caseIgnoreListMatch rule is an equality matching rule. 1519 4.2.10. caseIgnoreListSubstringsMatch 1521 The caseIgnoreListSubstringsMatch rule compares an assertion value of 1522 the Substring Assertion syntax to an attribute value of a syntax 1523 (e.g., the Postal Address syntax) whose corresponding ASN.1 type is a 1524 SEQUENCE OF the DirectoryString ASN.1 type. 1526 The rule evaluates to TRUE if and only if the assertion value 1527 matches, per the caseIgnoreSubstringsMatch rule, the character string 1528 formed by concatenating the strings of the attribute value, except 1529 that none of the , , or substrings of the 1530 assertion value are considered to match a substring of the 1531 concatenated string which spans more than one of the original strings 1532 of the attribute value. 1534 Note that, in terms of the LDAP-specific encoding of the Postal 1535 Address syntax, the concatenated string omits the line 1536 separator and the escaping of "\" and "$" characters. 1538 The LDAP definition for the caseIgnoreListSubstringsMatch rule is: 1540 ( 2.5.13.12 NAME 'caseIgnoreListSubstringsMatch' 1541 SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 ) 1543 The caseIgnoreListSubstringsMatch rule is a substrings matching rule. 1545 4.2.11. caseIgnoreMatch 1547 The caseIgnoreMatch rule compares an assertion value of the Directory 1548 String syntax to an attribute value of a syntax (e.g., the Directory 1549 String, Printable String, Country String or Telephone Number syntax) 1550 whose corresponding ASN.1 type is DirectoryString or one of its 1551 alternative string types. 1553 The rule evaluates to TRUE if and only if the prepared attribute 1554 value character string and the prepared assertion value character 1555 string have the same number of characters and corresponding 1556 characters have the same code point. 1558 In preparing the attribute value and assertion value for comparison, 1559 characters are case folded in the Map preparation step, and only 1560 Insignificant Space Handling is applied in the Insignificant 1561 Character Handling step. 1563 The LDAP definition for the caseIgnoreMatch rule is: 1565 ( 2.5.13.2 NAME 'caseIgnoreMatch' 1566 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 1568 The caseIgnoreMatch rule is an equality matching rule. 1570 4.2.12. caseIgnoreOrderingMatch 1572 The caseIgnoreOrderingMatch rule compares an assertion value of the 1573 Directory String syntax to an attribute value of a syntax (e.g., the 1574 Directory String, Printable String, Country String or Telephone 1575 Number syntax) whose corresponding ASN.1 type is DirectoryString or 1576 one of its alternative string types. 1578 The rule evaluates to TRUE if, and only if, in the code point 1579 collation order, the prepared attribute value character string 1580 appears earlier than the prepared assertion value character string, 1581 i.e., the attribute value is "less than" the assertion value. 1583 In preparing the attribute value and assertion value for comparison, 1584 characters are case folded in the Map preparation step, and only 1585 Insignificant Space Handling is applied in the Insignificant 1586 Character Handling step. 1588 The LDAP definition for the caseIgnoreOrderingMatch rule is: 1590 ( 2.5.13.3 NAME 'caseIgnoreOrderingMatch' 1591 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 1593 The caseIgnoreOrderingMatch rule is an ordering matching rule. 1595 4.2.13. caseIgnoreSubstringsMatch 1597 The caseIgnoreSubstringsMatch rule compares an assertion value of the 1598 Substring Assertion syntax to an attribute value of a syntax (e.g., 1599 the Directory String, Printable String, Country String or Telephone 1600 Number syntax) whose corresponding ASN.1 type is DirectoryString or 1601 one of its alternative string types. 1603 The rule evaluates to TRUE if and only if the prepared substrings of 1604 the assertion value match disjoint portions of the prepared attribute 1605 value character string in the order of the substrings in the 1606 assertion value, and an substring, if present, matches the 1607 beginning of the prepared attribute value character string, and a 1608 substring, if present, matches the end of the prepared 1609 attribute value character string. A prepared substring matches a 1610 portion of the prepared attribute value character string if 1611 corresponding characters have the same code point. 1613 In preparing the attribute value and assertion value substrings for 1614 comparison, characters are case folded in the Map preparation step, 1615 and only Insignificant Space Handling is applied in the Insignificant 1616 Character Handling step. 1618 The LDAP definition for the caseIgnoreSubstringsMatch rule is: 1620 ( 2.5.13.4 NAME 'caseIgnoreSubstringsMatch' 1621 SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 ) 1623 The caseIgnoreSubstringsMatch rule is a substrings matching rule. 1625 4.2.14. directoryStringFirstComponentMatch 1627 The directoryStringFirstComponentMatch rule compares an assertion 1628 value of the Directory String syntax to an attribute value of a 1629 syntax whose corresponding ASN.1 type is a SEQUENCE with a mandatory 1630 first component of the DirectoryString ASN.1 type. 1632 Note that the assertion syntax of this matching rule differs from the 1633 attribute syntax of attributes for which this is the equality 1634 matching rule. 1636 The rule evaluates to TRUE if and only if the assertion value matches 1637 the first component of the attribute value using the rules of 1638 caseIgnoreMatch. 1640 The LDAP definition for the directoryStringFirstComponentMatch 1641 matching rule is: 1643 ( 2.5.13.31 NAME 'directoryStringFirstComponentMatch' 1644 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 1646 The directoryStringFirstComponentMatch rule is an equality matching 1647 rule. When using directoryStringFirstComponentMatch to compare two 1648 attribute values (of an applicable syntax), an assertion value must 1649 first be derived from one of the attribute values. An assertion 1650 value can be derived from an attribute value by taking the first 1651 component of that attribute value. 1653 4.2.15. distinguishedNameMatch 1654 The distinguishedNameMatch rule compares an assertion value of the DN 1655 syntax to an attribute value of a syntax (e.g., the DN syntax) whose 1656 corresponding ASN.1 type is DistinguishedName. 1658 The rule evaluates to TRUE if and only if the attribute value and the 1659 assertion value have the same number of relative distinguished names 1660 and corresponding relative distinguished names (by position) are the 1661 same. A relative distinguished name (RDN) of the assertion value is 1662 the same as an RDN of the attribute value if and only if they have 1663 the same number of attribute value assertions and each attribute 1664 value assertion (AVA) of the first RDN is the same as the AVA of the 1665 second RDN with the same attribute type. The order of the AVAs is 1666 not significant. Also note that a particular attribute type may 1667 appear in at most one AVA in an RDN. Two AVAs with the same 1668 attribute type are the same if their values are equal according to 1669 the equality matching rule of the attribute type. If one or more of 1670 the AVA comparisons evaluate to Undefined and the remaining AVA 1671 comparisons return TRUE then the distinguishedNameMatch rule 1672 evaluates to Undefined. 1674 The LDAP definition for the distinguishedNameMatch rule is: 1676 ( 2.5.13.1 NAME 'distinguishedNameMatch' 1677 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 ) 1679 The distinguishedNameMatch rule is an equality matching rule. 1681 4.2.16. generalizedTimeMatch 1683 The generalizedTimeMatch rule compares an assertion value of the 1684 Generalized Time syntax to an attribute value of a syntax (e.g the 1685 Generalized Time syntax) whose corresponding ASN.1 type is 1686 GeneralizedTime. 1688 The rule evaluates to TRUE if and only if the attribute value 1689 represents the same universal coordinated time as the assertion 1690 value. If a time is specified with the minutes or seconds absent 1691 then the number of minutes or seconds (respectively) is assumed to be 1692 zero. 1694 The LDAP definition for the generalizedTimeMatch rule is: 1696 ( 2.5.13.27 NAME 'generalizedTimeMatch' 1697 SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 ) 1699 The generalizedTimeMatch rule is an equality matching rule. 1701 4.2.17. generalizedTimeOrderingMatch 1702 The generalizedTimeOrderingMatch rule compares the time ordering of 1703 an assertion value of the Generalized Time syntax to an attribute 1704 value of a syntax (e.g the Generalized Time syntax) whose 1705 corresponding ASN.1 type is GeneralizedTime. 1707 The rule evaluates to TRUE if and only if the attribute value 1708 represents a universal coordinated time which is earlier than the 1709 universal coordinated time represented by the assertion value. 1711 The LDAP definition for the generalizedTimeOrderingMatch rule is: 1713 ( 2.5.13.28 NAME 'generalizedTimeOrderingMatch' 1714 SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 ) 1716 The generalizedTimeOrderingMatch rule is an ordering matching rule. 1718 4.2.18. integerFirstComponentMatch 1720 The integerFirstComponentMatch rule compares an assertion value of 1721 the Integer syntax to an attribute value of a syntax (e.g the DIT 1722 Structure Rule Description syntax) whose corresponding ASN.1 type is 1723 a SEQUENCE with a mandatory first component of the INTEGER ASN.1 1724 type. 1726 Note that the assertion syntax of this matching rule differs from the 1727 attribute syntax of attributes for which this is the equality 1728 matching rule. 1730 The rule evaluates to TRUE if and only if the assertion value and the 1731 first component of the attribute value are the same integer value. 1733 The LDAP definition for the integerFirstComponentMatch matching rule 1734 is: 1736 ( 2.5.13.29 NAME 'integerFirstComponentMatch' 1737 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 ) 1739 The integerFirstComponentMatch rule is an equality matching rule. 1740 When using integerFirstComponentMatch to compare two attribute values 1741 (of an applicable syntax), an assertion value must first be derived 1742 from one of the attribute values. An assertion value can be derived 1743 from an attribute value by taking the first component of that 1744 attribute value. 1746 4.2.19. integerMatch 1748 The integerMatch rule compares an assertion value of the Integer 1749 syntax to an attribute value of a syntax (e.g the Integer syntax) 1750 whose corresponding ASN.1 type is INTEGER. 1752 The rule evaluates to TRUE if and only if the attribute value and the 1753 assertion value are the same integer value. 1755 The LDAP definition for the integerMatch matching rule is: 1757 ( 2.5.13.14 NAME 'integerMatch' 1758 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 ) 1760 The integerMatch rule is an equality matching rule. 1762 4.2.20. integerOrderingMatch 1764 The integerOrderingMatch rule compares an assertion value of the 1765 Integer syntax to an attribute value of a syntax (e.g the Integer 1766 syntax) whose corresponding ASN.1 type is INTEGER. 1768 The rule evaluates to TRUE if and only if the integer value of the 1769 attribute value is less than the integer value the assertion value. 1771 The LDAP definition for the integerOrderingMatch matching rule is: 1773 ( 2.5.13.15 NAME 'integerOrderingMatch' 1774 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 ) 1776 The integerOrderingMatch rule is an ordering matching rule. 1778 4.2.21. keywordMatch 1780 The keywordMatch rule compares an assertion value of the Directory 1781 String syntax to an attribute value of a syntax (e.g., the Directory 1782 String syntax) whose corresponding ASN.1 type is DirectoryString. 1784 The rule evaluates to TRUE if and only if the assertion value 1785 character string matches any keyword in the attribute value. The 1786 identification of keywords in the attribute value and the exactness 1787 of the match are both implementation specific. 1789 The LDAP definition for the keywordMatch rule is: 1791 ( 2.5.13.33 NAME 'keywordMatch' 1792 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 1794 4.2.22. numericStringMatch 1796 The numericStringMatch rule compares an assertion value of the 1797 Numeric String syntax to an attribute value of a syntax (e.g the 1798 Numeric String syntax) whose corresponding ASN.1 type is 1799 NumericString. 1801 The rule evaluates to TRUE if and only if the prepared attribute 1802 value character string and the prepared assertion value character 1803 string have the same number of characters and corresponding 1804 characters have the same code point. 1806 In preparing the attribute value and assertion value for comparison, 1807 characters are not case folded in the Map preparation step, and only 1808 numericString Insignificant Character Handling is applied in the 1809 Insignificant Character Handling step. 1811 The LDAP definition for the numericStringMatch matching rule is: 1813 ( 2.5.13.8 NAME 'numericStringMatch' 1814 SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 ) 1816 The numericStringMatch rule is an equality matching rule. 1818 4.2.23. numericStringOrderingMatch 1820 The numericStringOrderingMatch rule compares an assertion value of 1821 the Numeric String syntax to an attribute value of a syntax (e.g the 1822 Numeric String syntax) whose corresponding ASN.1 type is 1823 NumericString. 1825 The rule evaluates to TRUE if, and only if, in the code point 1826 collation order, the prepared attribute value character string 1827 appears earlier than the prepared assertion value character string, 1828 i.e., the attribute value is "less than" the assertion value. 1830 In preparing the attribute value and assertion value for comparison, 1831 characters are not case folded in the Map preparation step, and only 1832 numericString Insignificant Character Handling is applied in the 1833 Insignificant Character Handling step. 1835 The rule is identical to the caseIgnoreOrderingMatch rule except that 1836 all space characters are skipped during comparison (case is 1837 irrelevant as characters are numeric). 1839 The LDAP definition for the numericStringOrderingMatch matching rule 1840 is: 1842 ( 2.5.13.9 NAME 'numericStringOrderingMatch' 1843 SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 ) 1845 The numericStringOrderingMatch rule is an ordering matching rule. 1847 4.2.24. numericStringSubstringsMatch 1849 The numericStringSubstringsMatch rule compares an assertion value of 1850 the Substring Assertion syntax to an attribute value of a syntax (e.g 1851 the Numeric String syntax) whose corresponding ASN.1 type is 1852 NumericString. 1854 The rule evaluates to TRUE if and only if the prepared substrings of 1855 the assertion value match disjoint portions of the prepared attribute 1856 value character string in the order of the substrings in the 1857 assertion value, and an substring, if present, matches the 1858 beginning of the prepared attribute value character string, and a 1859 substring, if present, matches the end of the prepared 1860 attribute value character string. A prepared substring matches a 1861 portion of the prepared attribute value character string if 1862 corresponding characters have the same code point. 1864 In preparing the attribute value and assertion value for comparison, 1865 characters are not case folded in the Map preparation step, and only 1866 numericString Insignificant Character Handling is applied in the 1867 Insignificant Character Handling step. 1869 The LDAP definition for the numericStringSubstringsMatch matching 1870 rule is: 1872 ( 2.5.13.10 NAME 'numericStringSubstringsMatch' 1873 SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 ) 1875 The numericStringSubstringsMatch rule is a substrings matching rule. 1877 4.2.25. objectIdentifierFirstComponentMatch 1879 The objectIdentifierFirstComponentMatch rule compares an assertion 1880 value of the OID syntax to an attribute value of a syntax (e.g the 1881 Attribute Type Description, DIT Content Rule Description, LDAP Syntax 1882 Description, Matching Rule Description, Matching Rule Use 1883 Description, Name Form Description or Object Class Description 1884 syntax) whose corresponding ASN.1 type is a SEQUENCE with a mandatory 1885 first component of the OBJECT IDENTIFIER ASN.1 type. 1887 Note that the assertion syntax of this matching rule differs from the 1888 attribute syntax of attributes for which this is the equality 1889 matching rule. 1891 The rule evaluates to TRUE if and only if the assertion value matches 1892 the first component of the attribute value using the rules of 1893 objectIdentifierMatch. 1895 The LDAP definition for the objectIdentifierFirstComponentMatch 1896 matching rule is: 1898 ( 2.5.13.30 NAME 'objectIdentifierFirstComponentMatch' 1899 SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 ) 1901 The objectIdentifierFirstComponentMatch rule is an equality matching 1902 rule. When using objectIdentifierFirstComponentMatch to compare two 1903 attribute values (of an applicable syntax), an assertion value must 1904 first be derived from one of the attribute values. An assertion 1905 value can be derived from an attribute value by taking the first 1906 component of that attribute value. 1908 4.2.26. objectIdentifierMatch 1910 The objectIdentifierMatch rule compares an assertion value of the OID 1911 syntax to an attribute value of a syntax (e.g the OID syntax) whose 1912 corresponding ASN.1 type is OBJECT IDENTIFIER. 1914 The rule evaluates to TRUE if and only if the assertion value and the 1915 attribute value represent the same object identifier, that is, the 1916 same sequence of integers, whether represented explicitly in the 1917 form of or implicitly in the form (see 1918 [MODELS]). 1920 If an LDAP client supplies an assertion value in the form, 1921 and the chosen descriptor is not recognized by the server, then the 1922 objectIdentifierMatch rule evaluates to Undefined. 1924 The LDAP definition for the objectIdentifierMatch matching rule is: 1926 ( 2.5.13.0 NAME 'objectIdentifierMatch' 1927 SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 ) 1929 The objectIdentifierMatch rule is an equality matching rule. 1931 4.2.27. octetStringMatch 1933 The octetStringMatch rule compares an assertion value of the Octet 1934 String syntax to an attribute value of a syntax (e.g the Octet String 1935 or JPEG syntax) whose corresponding ASN.1 type is the OCTET STRING 1936 ASN.1 type. 1938 The rule evaluates to TRUE if and only if the attribute value and the 1939 assertion value are the same length and corresponding octets (by 1940 position) are the same. 1942 The LDAP definition for the octetStringMatch matching rule is: 1944 ( 2.5.13.17 NAME 'octetStringMatch' 1945 SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 ) 1947 The octetStringMatch rule is an equality matching rule. 1949 4.2.28. octetStringOrderingMatch 1951 The octetStringOrderingMatch rule compares an assertion value of the 1952 Octet String syntax to an attribute value of a syntax (e.g the Octet 1953 String or JPEG syntax) whose corresponding ASN.1 type is the OCTET 1954 STRING ASN.1 type. 1956 The rule evaluates to TRUE if and only if the attribute value appears 1957 earlier in the collation order than the assertion value. The rule 1958 compares octet strings from the first octet to the last octet, and 1959 from the most significant bit to the least significant bit within the 1960 octet. The first occurrence of a different bit determines the 1961 ordering of the strings. A zero bit precedes a one bit. If the 1962 strings contain different numbers of octets but the longer string is 1963 identical to the shorter string up to the length of the shorter 1964 string then the shorter string precedes the longer string. 1966 The LDAP definition for the octetStringOrderingMatch matching rule 1967 is: 1969 ( 2.5.13.18 NAME 'octetStringOrderingMatch' 1970 SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 ) 1972 The octetStringOrderingMatch rule is an ordering matching rule. 1974 4.2.29. telephoneNumberMatch 1976 The telephoneNumberMatch rule compares an assertion value of the 1977 Telephone Number syntax to an attribute value of a syntax (e.g the 1978 Telephone Number syntax) whose corresponding ASN.1 type is a 1979 PrintableString representing a telephone number. 1981 The rule evaluates to TRUE if and only if the prepared attribute 1982 value character string and the prepared assertion value character 1983 string have the same number of characters and corresponding 1984 characters have the same code point. 1986 In preparing the attribute value and assertion value for comparison, 1987 characters are case folded in the Map preparation step, and only 1988 telephoneNumber Insignificant Character Handling is applied in the 1989 Insignificant Character Handling step. 1991 The LDAP definition for the telephoneNumberMatch matching rule is: 1993 ( 2.5.13.20 NAME 'telephoneNumberMatch' 1994 SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 ) 1996 The telephoneNumberMatch rule is an equality matching rule. 1998 4.2.30. telephoneNumberSubstringsMatch 2000 The telephoneNumberSubstringsMatch rule compares an assertion value 2001 of the Substring Assertion syntax to an attribute value of a syntax 2002 (e.g the Telephone Number syntax) whose corresponding ASN.1 type is a 2003 PrintableString representing a telephone number. 2005 The rule evaluates to TRUE if and only if the prepared substrings of 2006 the assertion value match disjoint portions of the prepared attribute 2007 value character string in the order of the substrings in the 2008 assertion value, and an substring, if present, matches the 2009 beginning of the prepared attribute value character string, and a 2010 substring, if present, matches the end of the prepared 2011 attribute value character string. A prepared substring matches a 2012 portion of the prepared attribute value character string if 2013 corresponding characters have the same code point. 2015 In preparing the attribute value and assertion value substrings for 2016 comparison, characters are case folded in the Map preparation step, 2017 and only telephoneNumber Insignificant Character Handling is applied 2018 in the Insignificant Character Handling step. 2020 The LDAP definition for the telephoneNumberSubstringsMatch matching 2021 rule is: 2023 ( 2.5.13.21 NAME 'telephoneNumberSubstringsMatch' 2024 SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 ) 2026 The telephoneNumberSubstringsMatch rule is a substrings matching 2027 rule. 2029 4.2.31. uniqueMemberMatch 2031 The uniqueMemberMatch rule compares an assertion value of the Name 2032 And Optional UID syntax to an attribute value of a syntax (e.g the 2033 Name And Optional UID syntax) whose corresponding ASN.1 type is 2034 NameAndOptionalUID. 2036 The rule evaluates to TRUE if and only if the 2037 components of the assertion value and attribute value match according 2038 to the distinguishedNameMatch rule and either, the 2039 component is absent from both the attribute value and assertion 2040 value, or the component is present in both the attribute 2041 value and the assertion value and the component of the 2042 assertion value matches the component of the attribute 2043 value according to the bitStringMatch rule. 2045 Note that this matching rule has been altered from its description in 2046 X.520 [X.520] in order to make the matching rule commutative. Server 2047 implementors should consider using the original X.520 semantics 2048 (where the matching was less exact) for approximate matching of 2049 attributes with uniqueMemberMatch as the equality matching rule. 2051 The LDAP definition for the uniqueMemberMatch matching rule is: 2053 ( 2.5.13.23 NAME 'uniqueMemberMatch' 2054 SYNTAX 1.3.6.1.4.1.1466.115.121.1.34 ) 2056 The uniqueMemberMatch rule is an equality matching rule. 2058 4.2.32. wordMatch 2060 The wordMatch rule compares an assertion value of the Directory 2061 String syntax to an attribute value of a syntax (e.g., the Directory 2062 String syntax) whose corresponding ASN.1 type is DirectoryString. 2064 The rule evaluates to TRUE if and only if the assertion value word 2065 matches, according to the semantics of caseIgnoreMatch, any word in 2066 the attribute value. The precise definition of a word is 2067 implementation specific. 2069 The LDAP definition for the wordMatch rule is: 2071 ( 2.5.13.32 NAME 'wordMatch' 2072 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 2074 5. Security Considerations 2076 In general, the LDAP-specific encodings for syntaxes defined in this 2077 document do not define canonical encodings. That is, a 2078 transformation from an LDAP-specific encoding into some other 2079 encoding (e.g., BER) and back into the LDAP-specific encoding will 2080 not necessarily reproduce exactly the original octets of the 2081 LDAP-specific encoding. Therefore an LDAP-specific encoding should 2082 not be used where a canonical encoding is required. 2084 Furthermore, the LDAP-specific encodings do not necessarily enable an 2085 alternative encoding of values of the Directory String and DN 2086 syntaxes to be reconstructed, e.g., a transformation from a 2087 Distinguished Encoding Rules (DER) [BER] encoding to an LDAP-specific 2088 encoding and back to a DER encoding may not reproduce the original 2089 DER encoding. Therefore LDAP-specific encodings should not be used 2090 where reversibility to DER is needed, e.g., for the verification of 2091 digital signatures. Instead, DER or a DER-reversible encoding should 2092 be used. 2094 When interpreting security-sensitive fields, and in particular fields 2095 used to grant or deny access, implementations MUST ensure that any 2096 matching rule comparisons are done on the underlying abstract value, 2097 regardless of the particular encoding used. 2099 6. Acknowledgements 2101 This document is primarily a revision of RFC 2252 by M. Wahl, A. 2102 Coulbeck, T. Howes, and S. Kille. RFC 2252 was a product of the IETF 2103 ASID Working Group. 2105 This document is based upon input of the IETF LDAPBIS working group. 2106 The authors wish to thank J. Sermersheim and K. Zeilenga for their 2107 significant contribution to this revision. 2109 7. IANA Considerations 2111 The Internet Assigned Numbers Authority (IANA) is requested to update 2112 the LDAP descriptors registry [BCP64] as indicated by the following 2113 templates: 2115 Subject: Request for LDAP Descriptor Registration Update 2116 Descriptor (short name): see comment 2117 Object Identifier: see comment 2118 Person & email address to contact for further information: 2119 Steven Legg 2120 Usage: see comment 2121 Specification: RFC XXXX 2122 Author/Change Controller: IESG 2123 Comments: 2125 The following descriptors (short names) should be updated to refer 2126 to RFC XXXX. 2128 NAME Type OID 2129 ------------------------------------------------------------------ 2130 bitStringMatch M 2.5.13.16 2131 booleanMatch M 2.5.13.13 2132 caseExactIA5Match M 1.3.6.1.4.1.1466.109.114.1 2133 caseExactMatch M 2.5.13.5 2134 caseExactOrderingMatch M 2.5.13.6 2135 caseExactSubstringsMatch M 2.5.13.7 2136 caseIgnoreIA5Match M 1.3.6.1.4.1.1466.109.114.2 2137 caseIgnoreListMatch M 2.5.13.11 2138 caseIgnoreListSubstringsMatch M 2.5.13.12 2139 caseIgnoreMatch M 2.5.13.2 2140 caseIgnoreOrderingMatch M 2.5.13.3 2141 caseIgnoreSubstringsMatch M 2.5.13.4 2142 directoryStringFirstComponentMatch M 2.5.13.31 2143 distinguishedNameMatch M 2.5.13.1 2144 generalizedTimeMatch M 2.5.13.27 2145 generalizedTimeOrderingMatch M 2.5.13.28 2146 integerFirstComponentMatch M 2.5.13.29 2147 integerMatch M 2.5.13.14 2148 integerOrderingMatch M 2.5.13.15 2149 keywordMatch M 2.5.13.33 2150 numericStringMatch M 2.5.13.8 2151 numericStringOrderingMatch M 2.5.13.9 2152 numericStringSubstringsMatch M 2.5.13.10 2153 objectIdentifierFirstComponentMatch M 2.5.13.30 2154 octetStringMatch M 2.5.13.17 2155 octetStringOrderingMatch M 2.5.13.18 2156 telephoneNumberMatch M 2.5.13.20 2157 telephoneNumberSubstringsMatch M 2.5.13.21 2158 uniqueMemberMatch M 2.5.13.23 2159 wordMatch M 2.5.13.32 2161 The descriptor for the object identifier 2.5.13.0 was incorrectly 2162 registered as objectIdentifiersMatch (extraneous `s') in BCP 64. 2163 It should be changed to the following with a reference to 2164 RFC XXXX. 2166 NAME Type OID 2167 ------------------------------------------------------------------ 2168 objectIdentifierMatch M 2.5.13.0 2170 Subject: Request for LDAP Descriptor Registration 2171 Descriptor (short name): caseIgnoreIA5SubstringsMatch 2172 Object Identifier: 1.3.6.1.4.1.1466.109.114.3 2173 Person & email address to contact for further information: 2174 Steven Legg 2175 Usage: other (M) 2176 Specification: RFC XXXX 2177 Author/Change Controller: IESG 2179 Appendix A. Summary of Syntax Object Identifiers 2181 The following list summarizes the object identifiers assigned to the 2182 syntaxes defined in this document. 2184 Syntax OBJECT IDENTIFIER 2185 ============================================================== 2186 Attribute Type Description 1.3.6.1.4.1.1466.115.121.1.3 2187 Bit String 1.3.6.1.4.1.1466.115.121.1.6 2188 Boolean 1.3.6.1.4.1.1466.115.121.1.7 2189 Country String 1.3.6.1.4.1.1466.115.121.1.11 2190 Delivery Method 1.3.6.1.4.1.1466.115.121.1.14 2191 Directory String 1.3.6.1.4.1.1466.115.121.1.15 2192 DIT Content Rule Description 1.3.6.1.4.1.1466.115.121.1.16 2193 DIT Structure Rule Description 1.3.6.1.4.1.1466.115.121.1.17 2194 DN 1.3.6.1.4.1.1466.115.121.1.12 2195 Enhanced Guide 1.3.6.1.4.1.1466.115.121.1.21 2196 Facsimile Telephone Number 1.3.6.1.4.1.1466.115.121.1.22 2197 Fax 1.3.6.1.4.1.1466.115.121.1.23 2198 Generalized Time 1.3.6.1.4.1.1466.115.121.1.24 2199 Guide 1.3.6.1.4.1.1466.115.121.1.25 2200 IA5 String 1.3.6.1.4.1.1466.115.121.1.26 2201 Integer 1.3.6.1.4.1.1466.115.121.1.27 2202 JPEG 1.3.6.1.4.1.1466.115.121.1.28 2203 LDAP Syntax Description 1.3.6.1.4.1.1466.115.121.1.54 2204 Matching Rule Description 1.3.6.1.4.1.1466.115.121.1.30 2205 Matching Rule Use Description 1.3.6.1.4.1.1466.115.121.1.31 2206 Name And Optional UID 1.3.6.1.4.1.1466.115.121.1.34 2207 Name Form Description 1.3.6.1.4.1.1466.115.121.1.35 2208 Numeric String 1.3.6.1.4.1.1466.115.121.1.36 2209 Object Class Description 1.3.6.1.4.1.1466.115.121.1.37 2210 Octet String 1.3.6.1.4.1.1466.115.121.1.40 2211 OID 1.3.6.1.4.1.1466.115.121.1.38 2212 Other Mailbox 1.3.6.1.4.1.1466.115.121.1.39 2213 Postal Address 1.3.6.1.4.1.1466.115.121.1.41 2214 Printable String 1.3.6.1.4.1.1466.115.121.1.44 2215 Substring Assertion 1.3.6.1.4.1.1466.115.121.1.58 2216 Telephone Number 1.3.6.1.4.1.1466.115.121.1.50 2217 Teletex Terminal Identifier 1.3.6.1.4.1.1466.115.121.1.51 2218 Telex Number 1.3.6.1.4.1.1466.115.121.1.52 2219 UTC Time 1.3.6.1.4.1.1466.115.121.1.53 2221 Appendix B. Changes from RFC 2252 2223 This annex lists the significant differences between this 2224 specification and RFC 2252. 2226 This annex is provided for informational purposes only. It is not a 2227 normative part of this specification. 2229 1. The IESG Note has been removed. 2231 2. The major part of Sections 4, 5 and 7 has been moved to [MODELS] 2232 and revised. Changes to the parts of these sections moved to 2233 [MODELS] are detailed in [MODELS]. 2235 3. BNF descriptions of syntax formats have been replaced by ABNF 2236 [ABNF] specifications. 2238 4. The ambiguous statement in RFC 2252, Section 4.3 regarding the 2239 use of a backslash quoting mechanism to escape separator symbols 2240 has been removed. The escaping mechanism is now explicitly 2241 represented in the ABNF for the syntaxes where this provision 2242 applies. 2244 5. The description of each of the LDAP syntaxes has been expanded so 2245 that they are less dependent on knowledge of X.500 for 2246 interpretation. 2248 6. The relationship of LDAP syntaxes to corresponding ASN.1 type 2249 definitions has been made explicit. 2251 7. The set of characters allowed in a (formerly 2252 ) has been corrected to align with the 2253 PrintableString ASN.1 type in [ASN.1]. Specifically, the double 2254 quote character has been removed and the single quote character 2255 and equals sign have been added. 2257 8. Values of the Directory String, Printable String and Telephone 2258 Number syntaxes are now required to have at least one character. 2260 9. The , and 2261 rules have been moved to [MODELS]. 2263 10. The corresponding ASN.1 type for the Other Mailbox syntax has 2264 been incorporated from RFC 1274. 2266 11. A corresponding ASN.1 type for the LDAP Syntax Description syntax 2267 has been invented. 2269 12. The Binary syntax has been removed because it was not adequately 2270 specified, implementations with different incompatible 2271 interpretations exist, and it was confused with the ;binary 2272 transfer encoding. 2274 13. All discussion of transfer options, including the ";binary" 2275 option, has been removed. All imperatives regarding binary 2276 transfer of values have been removed. 2278 14. The Delivery Method, Enhanced Guide, Guide, Octet String, Teletex 2279 Terminal Identifier and Telex Number syntaxes from RFC 2256 have 2280 been incorporated. 2282 15. The rule for the Enhanced Guide and Guide syntaxes has 2283 been extended to accommodate empty "and" and "or" expressions. 2285 16. An encoding for the rule in the Teletex Terminal 2286 Identifier syntax has been defined. 2288 17. The PKI-related syntaxes (Certificate, Certificate List and 2289 Certificate Pair) have been removed. They are reintroduced in 2290 [LDAP-PKI] (as is the Supported Algorithm syntax from RFC 2256). 2292 18. The MHS OR Address syntax has been removed since its 2293 specification (in RFC 2156) is not at draft standard maturity. 2295 19. The DL Submit Permission syntax has been removed as it depends on 2296 the MHS OR Address syntax. 2298 20. The Presentation Address syntax has been removed since its 2299 specification (in RFC 1278) is not at draft standard maturity. 2301 21. The ACI Item, Access Point, Audio, Data Quality, DSA Quality, DSE 2302 Type, LDAP Schema Description, Master And Shadow Access Points, 2303 Modify Rights, Protocol Information, Subtree Specification, 2304 Supplier Information, Supplier Or Consumer and Supplier And 2305 Consumer syntaxes have been removed. These syntaxes are 2306 referenced in RFC 2252, but not defined. 2308 22. The LDAP Schema Definition syntax (defined in RFC 2927) and the 2309 Mail Preference syntax have been removed on the grounds that they 2310 are out of scope for the core specification. 2312 23. The description of each of the matching rules has been expanded 2313 so that they are less dependent on knowledge of X.500 for 2314 interpretation. 2316 24. The caseIgnoreIA5SubstringsMatch matching rule from RFC 2798 has 2317 been added. 2319 25. The caseIgnoreListSubstringsMatch, caseIgnoreOrderingMatch and 2320 caseIgnoreSubstringsMatch matching rules have been added to the 2321 list of matching rules for which the provisions for handling 2322 leading, trailing and multiple adjoining whitespace characters 2323 apply (now through string preparation). This is consistent with 2324 the definitions of these matching rules in X.500. The 2325 caseIgnoreIA5SubstringsMatch rule has also been added to the 2326 list. 2328 26. The specification of the octetStringMatch matching rule from 2329 RFC 2256 has been added to this document. 2331 27. The presentationAddressMatch matching rule has been removed as it 2332 depends on an assertion syntax (Presentation Address) that is not 2333 at draft standard maturity. 2335 28. The protocolInformationMatch matching rule has been removed as it 2336 depends on an undefined assertion syntax (Protocol Information). 2338 29. The definitive reference for ASN.1 has been changed from X.208 to 2339 X.680 since X.680 is the version of ASN.1 referred to by X.500. 2341 30. The specification of the caseIgnoreListSubstringsMatch matching 2342 rule from RFC 2798 & X.520 has been added. 2344 31. String preparation algorithms have been applied to the character 2345 string matching rules. 2347 32. The specifications of the booleanMatch, caseExactMatch, 2348 caseExactOrderingMatch, caseExactSubstringsMatch, 2349 directoryStringFirstComponentMatch, integerOrderingMatch, 2350 keywordMatch, numericStringOrderingMatch, 2351 octetStringOrderingMatch and wordMatch matching rules from 2352 RFC 3698 & X.520 have been added. 2354 Normative References 2356 [KEYWORD] Bradner, S., "Key words for use in RFCs to Indicate 2357 Requirement Levels", BCP 14, RFC 2119, March 1997. 2359 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax 2360 Specifications: ABNF", RFC 2234, November 1997. 2362 [UTF8] Yergeau, F., "UTF-8, a transformation format of ISO 2363 10646", RFC 3629, November 2003. 2365 [BCP64] Zeilenga, K., "Internet Assigned Numbers Authority (IANA) 2366 Considerations for the Lightweight Directory Access 2367 Protocol (LDAP)", BCP 64, RFC 3383, September 2002. 2369 [LDAPDN] Zeilenga, K., "LDAP: String Representation of 2370 Distinguished Names", draft-ietf-ldapbis-dn-xx.txt, a work 2371 in progress, February 2005. 2373 [PROT] Sermersheim, J., "LDAP: The Protocol", draft-ietf-ldapbis- 2374 protocol-xx.txt, a work in progress, February 2005. 2376 [E.123] Notation for national and international telephone numbers, 2377 ITU-T Recommendation E.123, 1988. 2379 [FAX] Standardization of Group 3 facsimile apparatus for 2380 document transmission - Terminal Equipment and Protocols 2381 for Telematic Services, ITU-T Recommendation T.4, 1993 2383 [T.50] International Reference Alphabet (IRA) (Formerly 2384 International Alphabet No. 5 or IA5) Information 2385 Technology - 7-Bit Coded Character Set for Information 2386 Interchange, ITU-T Recommendation T.50, 1992 2388 [X.420] ITU-T Recommendation X.420 (1996) | ISO/IEC 10021-7:1997, 2389 Information Technology - Message Handling Systems (MHS): 2390 Interpersonal messaging system 2392 [X.501] ITU-T Recommendation X.501 (1993) | ISO/IEC 9594-2:1994, 2393 Information Technology - Open Systems Interconnection - 2394 The Directory: Models 2396 [X.520] ITU-T Recommendation X.520 (1993) | ISO/IEC 9594-6:1994, 2397 Information Technology - Open Systems Interconnection - 2398 The Directory: Selected attribute types 2400 [ASN.1] ITU-T Recommendation X.680 (07/02) | ISO/IEC 8824-1:2002, 2401 Information technology - Abstract Syntax Notation One 2402 (ASN.1): Specification of basic notation 2404 [ISO3166] ISO 3166, "Codes for the representation of names of 2405 countries". 2407 [UCS] Universal Multiple-Octet Coded Character Set (UCS) - 2408 Architecture and Basic Multilingual Plane, ISO/IEC 2409 10646-1: 1993 (with amendments). 2411 [JPEG] JPEG File Interchange Format (Version 1.02). Eric 2412 Hamilton, C-Cube Microsystems, Milpitas, CA, September 1, 2413 1992. 2415 [ROADMAP] Zeilenga, K., "Lightweight Directory Access Protocol 2416 (LDAP): Technical Specification Road Map", draft-ietf- 2417 ldapbis-roadmap-xx.txt, a work in progress, February 2005. 2419 [MODELS] Zeilenga, K., "LDAP: Directory Information Models", draft- 2420 ietf-ldapbis-models-xx.txt, a work in progress, February 2421 2005. 2423 [PREP] Zeilenga, K., "LDAP: Internationalized String 2424 Preparation", draft-ietf-ldapbis-strprep-xx.txt, a work in 2425 progress, February 2005. 2427 Informative References 2429 [RFC2252] Wahl, M., Coulbeck, A., Howes, T. and S. Kille, 2430 "Lightweight Directory Access Protocol (v3): Attribute 2431 Syntax Definitions", RFC 2252, December 1997. 2433 [RFC2256] Wahl, M., "A Summary of the X.500(96) User Schema for use 2434 with LDAPv3", RFC 2256, December 1997. 2436 [RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access 2437 Protocol (v3): Technical Specification", RFC 3377, 2438 September 2002. 2440 [RFC3698] Zeilenga, K., "Lightweight Directory Access Protocol 2441 (LDAP): Additional Matching Rules", RFC 3698, February 2442 2004. 2444 [SCHEMA] Dally, K., "LDAP: Schema for User Applications", draft- 2445 ietf-ldapbis-user-schema-xx.txt, a work in progress, July 2446 2004. 2448 [LDAP-PKI] Zeilenga, K. D., "Lightweight Directory Access Protocol 2449 (LDAP) schema definitions for X.509 Certificates", draft- 2450 zeilenga-ldap-x509-xx.txt, a work in progress, February 2451 2005. 2453 [X.500] ITU-T Recommendation X.500 (1993) | ISO/IEC 9594-1:1994, 2454 Information Technology - Open Systems Interconnection - 2455 The Directory: Overview of concepts, models and services 2457 [BER] ITU-T Recommendation X.690 (07/02) | ISO/IEC 8825-1:2002, 2458 Information technology - ASN.1 encoding rules: 2459 Specification of Basic Encoding Rules (BER), Canonical 2460 Encoding Rules (CER) and Distinguished Encoding Rules 2461 (DER) 2463 Authors' Addresses 2465 Steven Legg 2466 eB2Bcom 2467 Suite3, Woodhouse Corporate Centre 2468 935 Station Street 2469 Box Hill North, Victoria 3129 2470 AUSTRALIA 2471 Phone: +61 3 9896 7830 2472 Fax: +61 3 9896 7801 2473 EMail: steven.legg@eb2bcom.com 2475 Kathy Dally 2476 The MITRE Corp. 2477 7515 Colshire Dr., ms-W650 2478 McLean VA 22102 2479 USA 2481 Phone: +1 703 883 6058 2482 Fax: +1 703 883 7142 2483 Email: kdally@mitre.org 2485 Full Copyright Statement 2487 Copyright (C) The Internet Society (2005). This document is subject 2488 to the rights, licenses and restrictions contained in BCP 78, and 2489 except as set forth therein, the authors retain all their rights. 2491 This document and the information contained herein are provided on an 2492 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2493 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 2494 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 2495 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 2496 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2497 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2499 Intellectual Property 2501 The IETF takes no position regarding the validity or scope of any 2502 Intellectual Property Rights or other rights that might be claimed to 2503 pertain to the implementation or use of the technology described in 2504 this document or the extent to which any license under such rights 2505 might or might not be available; nor does it represent that it has 2506 made any independent effort to identify any such rights. Information 2507 on the procedures with respect to rights in RFC documents can be 2508 found in BCP 78 and BCP 79. 2510 Copies of IPR disclosures made to the IETF Secretariat and any 2511 assurances of licenses to be made available, or the result of an 2512 attempt made to obtain a general license or permission for the use of 2513 such proprietary rights by implementers or users of this 2514 specification can be obtained from the IETF on-line IPR repository at 2515 http://www.ietf.org/ipr. 2517 The IETF invites any interested party to bring to its attention any 2518 copyrights, patents or patent applications, or other proprietary 2519 rights that may cover technology that may be required to implement 2520 this standard. Please address the information to the IETF at 2521 ietf-ipr@ietf.org. 2523 This Internet-Draft expires on 18 August 2005.