idnits 2.17.1 draft-zeilenga-ldap-user-schema-mr-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 24 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 404 has weird spacing: '...for the purpo...' -- 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 (5 June 2003) is 7624 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) == Unused Reference: 'RFC2119' is defined on line 339, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2252 (Obsoleted by RFC 4510, RFC 4512, RFC 4517, RFC 4523) ** Obsolete normative reference: RFC 3377 (Obsoleted by RFC 4510) -- Obsolete informational reference (is this intentional?): RFC 3383 (Obsoleted by RFC 4520) Summary: 6 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Editor: Kurt D. Zeilenga 3 Intended Category: Standard Track OpenLDAP Foundation 4 Expires in six months 5 June 2003 5 Updates: RFC 2798 7 LDAP: Additional Matching Rules 8 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with all 13 provisions of Section 10 of RFC2026. 15 This document is a subset of technical specification offered in 16 draft-zeilenga-ldap-user-schema-xx.txt. 18 This document is intended to be, after appropriate review and 19 revision, submitted to the RFC Editor as a Standard Track document. 20 Distribution of this memo is unlimited. Technical discussion of this 21 document will take place on the IETF Directory Interest mailing list 22 . Please send editorial comments directly to 23 the author . 25 Internet-Drafts are working documents of the Internet Engineering Task 26 Force (IETF), its areas, and its working groups. Note that other 27 groups may also distribute working documents as 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 . The list of 35 Internet-Draft Shadow Directories can be accessed at 36 . 38 Copyright (C) The Internet Society (2003). All Rights Reserved. 40 Please see the Full Copyright section near the end of this document 41 for more information. 43 Abstract 45 This document provides a collection of matching rules for use with the 46 Lightweight Directory Access Protocol (LDAP). As these matching rules 47 are simple adaptations of matching rules specified for use with the 48 X.500 Directory, most are already in wide use. 50 Table of Contents (to be expanded by editor) 52 Status of this Memo 1 53 Abstract 2 54 Table of Contents 55 1. Background and Intended Use 56 2. Matching Rules 3 57 2.1. booleanMatch 58 2.2. caseExactMatch 59 2.3. caseExactOrderingMatch 60 2.4. caseExactSubstringsMatch 4 61 2.5. caseIgnoreListSubstringsMatch 62 2.6. directoryStringFirstComponentMatch 63 2.7. integerOrderingMatch 5 64 2.8. keywordMatch 65 2.9. numericStringOrderingMatch 66 2.10. octetStringOrderingMatch 6 67 2.11. storedPrefixMatch 68 2.12. wordMatch 69 3. Security Considerations 7 70 4. IANA Considerations 71 5. Acknowledgments 8 72 6. Author's Address 73 7. Normative References 74 8. Informative References 75 Intellectual Property Rights 9 76 Full Copyright 78 1. Background and Intended Use 80 This document adapts additional X.500 Directory [X.500] matching rules 81 [X.520] for use with the Lightweight Directory Access Protocol (LDAP) 82 [RFC3377]. Most of these rules are widely used today on the Internet, 83 such as in support of the inetOrgPerson [RFC2798] and Policy Core 84 Information Model [PCIM] LDAP schemas. The rules are applicable to 85 many other applications. 87 This document supersedes the informational matching rules descriptions 88 provided in RFC 2798 that are now provided in this document. 90 Specifically, section 2 of this document replaces section 9.3.3 of RFC 91 2798. 93 Schema definitions are provided using LDAP description formats 94 [RFC2252]. Definitions provided here are formatted (line wrapped) for 95 readability. 97 2. Matching Rules 99 2.1. booleanMatch 101 The booleanMatch rule compares for equality a asserted Boolean value 102 with an attribute value of BOOLEAN syntax. The rule returns TRUE if 103 and only if the values are the same, i.e. both are TRUE or both are 104 FALSE. (Source: X.520) 106 ( 2.5.13.13 NAME 'booleanMatch' 107 SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 ) 109 The BOOLEAN (1.3.6.1.4.1.1466.115.121.1.7) syntax is described in 110 [RFC2252]. 112 2.2. caseExactMatch 114 The caseExactMatch rule compares for equality the asserted value with 115 an attribute value of DirectoryString syntax. The rule is identical 116 to the caseIgnoreMatch [RFC2252] rule except that case is not ignored. 117 (Source: X.520) 119 ( 2.5.13.5 NAME 'caseExactMatch' 120 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 122 The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax is 123 described in [RFC2252]. 125 2.3. caseExactOrderingMatch 127 The caseExactOrderingMatch rule compares the collation order of the 128 asserted string with an attribute value of DirectoryString syntax. 129 The rule is identical to the caseIgnoreOrderingMatch [RFC2252] rule 130 except that letters are not folded. (Source: X.520) 132 ( 2.5.13.6 NAME 'caseExactOrderingMatch' 133 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 135 The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax is 136 described in [RFC2252]. 138 2.4. caseExactSubstringsMatch 140 The caseExactSubstringsMatch rule determines whether the asserted 141 value(s) are substrings of an attribute value of DirectoryString 142 syntax. The rule is identical to the caseIgnoreSubstringsMatch 143 [RFC2252] rule except that case is not ignored. (Source: X.520) 145 ( 2.5.13.7 NAME 'caseExactSubstringsMatch' 146 SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 ) 148 The SubstringsAssertion (1.3.6.1.4.1.1466.115.121.1.58) syntax is 149 described in [RFC2252]. 151 2.5. caseIgnoreListSubstringsMatch 153 The caseIgnoreListSubstringMatch rule compares the asserted substring 154 with an attribute value which is a sequence of DirectoryStrings, but 155 where the case (upper or lower) is not significant for comparison 156 purposes. The asserted value matches a stored value if and only if 157 the asserted value matches the string formed by concatenating the 158 strings of the stored value. This matching is done according to the 159 caseIgnoreSubstringsMatch [RFC2252] rule; however, none of the 160 initial, any, or final values of the asserted value are considered to 161 match a substring of the concatenated string which spans more than one 162 of the strings of the stored value. (Source: X.520) 164 ( 2.5.13.12 NAME 'caseIgnoreListSubstringsMatch' 165 SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 ) 167 The SubstringsAssertion (1.3.6.1.4.1.1466.115.121.1.58) syntax is 168 described in [RFC2252]. 170 2.6. directoryStringFirstComponentMatch 172 The directoryStringFirstComponentMatch rule compares for equality the 173 asserted DirectoryString value with an attribute value of type 174 SEQUENCE whose first component is mandatory and of type 175 DirectoryString. The rule returns TRUE if and only if the attribute 176 value has a first component whose value matches the asserted 177 DirectoryString using the rules of caseIgnoreMatch [RFC2252]. A value 178 of the assertion syntax is derived from a value of the attribute 179 syntax by using the value of the first component of the SEQUENCE. 181 (Source: X.520) 183 ( 2.5.13.31 NAME 'directoryStringFirstComponentMatch' 184 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 186 The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax is 187 described in [RFC2252]. 189 2.7. integerOrderingMatch 191 The integerOrderingMatch rule compares the ordering of the asserted 192 integer with an attribute value of INTEGER syntax. The rule returns 193 True if the attribute value is less than the asserted value. (Source: 194 X.520) 196 ( 2.5.13.15 NAME 'integerOrderingMatch' 197 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 ) 199 The INTEGER (1.3.6.1.4.1.1466.115.121.1.27) syntax is described in 200 [RFC2252]. 202 2.8. keywordMatch 204 The keywordMatch rule compares the asserted string with keywords in an 205 attribute value of DirectoryString syntax. The rule returns TRUE if 206 and only if the asserted value matches any keyword in the attribute 207 value. The identification of keywords in an attribute value and of 208 the exactness of match are both implementation specific. (Source: 209 X.520) 211 ( 2.5.13.32 NAME 'keywordMatch' 212 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 214 The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax is 215 described in [RFC2252]. 217 2.9. numericStringOrderingMatch 219 The numericStringOrderingMatch rule compares the collation order of 220 the asserted string with an attribute value of NumericString syntax. 221 The rule is identical to the caseIgnoreOrderingMatch [RFC2252] rule 222 except that all space characters are skipped during comparison (case 223 is irrelevant as characters are numeric). (Source: X.520) 225 ( 2.5.13.9 NAME 'numericStringOrderingMatch' 226 SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 ) 228 The NumericString (1.3.6.1.4.1.1466.115.121.1.36) syntax is described 229 in [RFC2252]. 231 2.10. octetStringOrderingMatch 233 The octetStringOrderingMatch rule compares the collation order of the 234 asserted octet string with an attribute value of OCTET STRING syntax. 235 The rule compares octet strings from first octet to last octet, and 236 from the most significant bit to the least significant bit within the 237 octet. The first occurrence of a different bit determines the ordering 238 of the strings. A zero bit precedes a one bit. If the strings are 239 identical but contain different numbers of octets, the shorter string 240 precedes the longer string. (Source: X.520) 242 ( 2.5.13.18 NAME 'octetStringOrderingMatch' 243 SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 ) 245 The OCTET STRING (1.3.6.1.4.1.1466.115.121.1.40) syntax is described 246 in [RFC2252]. 248 2.11. storedPrefixMatch 250 The storedPrefixMatch rule determines whether an attribute value, 251 whose syntax is DirectoryString is a prefix (i.e. initial substring) 252 of the asserted value, without regard to the case (upper or lower) of 253 the strings. The rule returns TRUE if and only if the attribute value 254 is an initial substring of the asserted value with corresponding 255 characters identical except possibly with regard to case. (Source: 256 X.520) 258 ( 2.5.13.41 NAME 'storedPrefixMatch' 259 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 261 Note: This rule can be used, for example, to compare values in the 262 Directory which are telephone area codes with a purported value 263 which is a telephone number. 265 The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax is 266 described in [RFC2252]. 268 2.12. wordMatch 270 The wordMatch rule compares the asserted string with words in an 271 attribute value of DirectoryString syntax. The rule returns TRUE if 272 and only if the asserted word matches any word in the attribute value. 273 Individual word matching is as for the caseIgnoreMatch [RFC2252] 274 matching rule. The precise definition of a "word" is implementation 275 specific. (Source: X.520) 277 ( 2.5.13.32 NAME 'wordMatch' 278 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 280 The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax is 281 described in [RFC2252]. 283 3. Security Considerations 285 General LDAP security considerations [RFC3377] is applicable to the 286 use of this schema. Additional considerations are noted above where 287 appropriate. 289 4. IANA Considerations 291 It is requested that the Internet Assigned Numbers Authority (IANA) 292 update upon Standard Action the LDAP descriptors registry [RFC3383] as 293 indicated the following template: 295 Subject: Request for LDAP Descriptor Registration Update 296 Descriptor (short name): see comment 297 Object Identifier: see comments 298 Person & email address to contact for further information: 299 Kurt Zeilenga 300 Usage: see comments 301 Specification: RFC XXXX 302 Author/Change Controller: IESG 303 Comments: 305 The following descriptors should be added: 307 NAME Type OID 308 ------------------------ ---- --------- 309 booleanMatch M 2.5.13.13 310 caseExactMatch M 2.5.13.5 311 caseExactOrderingMatch M 2.5.13.6 312 caseExactSubstringsMatch M 2.5.13.7 313 caseIgnoreListSubstringsMatch M 2.5.13.12 314 directoryStringFirstComponentMatch M 2.5.13.31 315 integerOrderingMatch M 2.5.13.15 316 keywordMatch M 2.5.13.32 317 numericStringOrderingMatch M 2.5.13.9 318 octetStringOrderingMatch M 2.5.13.18 319 storedPrefixMatch M 2.5.13.41 320 wordMatch M 2.5.13.32 322 where Type M is Matching Rule. 324 This document make no new OID assignments. It only associates LDAP 325 matching rule descriptions with existing X.500 matching rules. 327 5. Acknowledgments 329 This document borrows from [X.520], an ITU-T Recommendation. 331 6. Author's Address 333 Kurt D. Zeilenga 334 OpenLDAP Foundation 335 337 7. Normative References 339 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 340 Requirement Levels", BCP 14 (also RFC 2119), March 1997. 342 [RFC2252] Wahl, M., A. Coulbeck, T. Howes, and S. Kille, 343 "Lightweight Directory Access Protocol (v3): Attribute 344 Syntax Definitions", RFC 2252, December 1997. 346 [RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access 347 Protocol (v3): Technical Specification", RFC 3377, 348 September 2002. 350 8. Informative References 352 [RFC2798] Smith, M., "The LDAP inetOrgPerson Object Class", RFC 353 2798, April 2000. 355 [RFC3383] Zeilenga, K., "IANA Considerations for LDAP", BCP 64 356 (also RFC 3383), September 2002. 358 [X.500] International Telecommunication Union - 359 Telecommunication Standardization Sector, "The Directory 360 -- Overview of concepts, models and services," 361 X.500(1993) (also ISO/IEC 9594-1:1994). 363 [X.520] International Telecommunication Union - 364 Telecommunication Standardization Sector, "The 365 Directory: Selected Attribute Types", X.520(1997). 367 [PCIM] Strassner, J., B. Moore, R. Moats, E. Ellesson, "Policy 368 Core LDAP Schema", a work in progress. 370 Intellectual Property Rights 372 The IETF takes no position regarding the validity or scope of any 373 intellectual property or other rights that might be claimed to pertain 374 to the implementation or use of the technology described in this 375 document or the extent to which any license under such rights might or 376 might not be available; neither does it represent that it has made any 377 effort to identify any such rights. Information on the IETF's 378 procedures with respect to rights in standards-track and 379 standards-related documentation can be found in BCP-11. Copies of 380 claims of rights made available for publication and any assurances of 381 licenses to be made available, or the result of an attempt made to 382 obtain a general license or permission for the use of such proprietary 383 rights by implementors or users of this specification can be obtained 384 from the IETF Secretariat. 386 The IETF invites any interested party to bring to its attention any 387 copyrights, patents or patent applications, or other proprietary 388 rights which may cover technology that may be required to practice 389 this standard. Please address the information to the IETF Executive 390 Director. 392 Full Copyright 394 Copyright (C) The Internet Society (2003). All Rights Reserved. 396 This document and translations of it may be copied and furnished to 397 others, and derivative works that comment on or otherwise explain it 398 or assist in its implmentation may be prepared, copied, published and 399 distributed, in whole or in part, without restriction of any kind, 400 provided that the above copyright notice and this paragraph are 401 included on all such copies and derivative works. However, this 402 document itself may not be modified in any way, such as by removing 403 the copyright notice or references to the Internet Society or other 404 Internet organizations, except as needed for the purpose of 405 developing Internet standards in which case the procedures for 406 copyrights defined in the Internet Standards process must be followed, 407 or as required to translate it into languages other than English.