idnits 2.17.1 draft-zeilenga-ldap-user-schema-06.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC2119], [RFC2252]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == 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 '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. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 881 has weird spacing: '...for the purpo...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (17 May 2002) is 8015 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) ** Obsolete normative reference: RFC 822 (Obsoleted by RFC 2822) ** Obsolete normative reference: RFC 2252 (Obsoleted by RFC 4510, RFC 4512, RFC 4517, RFC 4523) ** Obsolete normative reference: RFC 2256 (Obsoleted by RFC 4510, RFC 4512, RFC 4517, RFC 4519, RFC 4523) ** Obsolete normative reference: RFC 2829 (Obsoleted by RFC 4510, RFC 4513) == Outdated reference: A later version (-01) exists of draft-ietf-ldapbis-ldapv3-ts-00 -- Obsolete informational reference (is this intentional?): RFC 1274 (Obsoleted by RFC 4524) Summary: 9 errors (**), 0 flaws (~~), 6 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 17 May 2002 5 Obsoletes: RFC 1274 6 Updates: RFC 2798 8 LDAPv3: A Collection of User Schema 9 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with all 14 provisions of Section 10 of RFC2026. 16 This document is intended to be, after appropriate review and 17 revision, submitted to the RFC Editor as a Standard Track document. 18 Distribution of this memo is unlimited. Technical discussion of this 19 document will take place on the IETF Directory Interest mailing list 20 . Please send editorial comments directly to 21 the author . 23 Internet-Drafts are working documents of the Internet Engineering Task 24 Force (IETF), its areas, and its working groups. Note that other 25 groups may also distribute working documents as Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as ``work in progress.'' 31 The list of current Internet-Drafts can be accessed at 32 . The list of 33 Internet-Draft Shadow Directories can be accessed at 34 . 36 Copyright 2002, The Internet Society. All Rights Reserved. 38 Please see the Copyright section near the end of this document for 39 more information. 41 Abstract 43 This document provides a collection of user schema elements for use 44 with LDAP (Lightweight Directory Access Protocol) from both ITU-T 45 Recommendations for the X.500 Directory and COSINE and Internet X.500 46 pilot projects. 48 Conventions 50 Schema definitions are provided using LDAPv3 description formats 51 [RFC2252]. Definitions provided here are formatted (line wrapped) for 52 readability. 54 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 55 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 56 document are to be interpreted as described in BCP 14 [RFC2119]. 58 Table of Contents (to be expanded by editor) 60 Status of this Memo 1 61 Abstract 62 Conventions 2 63 Table of Contents 64 1. Background and Intended Use 3 65 2. Matching Rules 66 2.1. booleanMatch 4 67 2.2. caseExactMatch 68 2.3. caseExactOrderingMatch 69 2.4. caseExactSubstringsMatch 70 2.5. caseIgnoreListSubstringsMatch 71 2.6. directoryStringFirstComponentMatch 5 72 2.7. integerOrderingMatch 73 2.8. keywordMatch 74 2.9. numericStringOrderingMatch 6 75 2.10. octetStringOrderingMatch 76 2.11. storedPrefixMatch 77 2.12. wordMatch 7 78 3. Attribute Types 79 3.1. associatedDomain 80 3.2. associatedName 81 3.3. buildingName 82 3.3. co 8 83 3.5. documentAuthor 84 3.6. documentIdentifier 85 3.7. documentLocation 86 3.8. documentPublisher 9 87 3.9. documentTitle 88 3.10. documentVersion 89 3.11. drink 90 3.12. homePhone 10 91 3.13. homePostalAddress 92 3.14. host 93 3.16. info 94 3.17. mail 11 95 3.18. manager 96 3.19. mobile 97 3.20. organizationalStatus 98 3.21. otherMailbox 12 99 3.22. pager 100 3.23. personalTitle 101 3.24. roomNumber 13 102 3.25. secretary 103 3.26. uid 104 3.27. uniqueIdentifier 105 3.28. userClass 14 106 4. Object Classes 107 4.1. account 108 4.2. document 15 109 4.3. documentSeries 110 4.4. domainRelatedObject 111 4.5. friendlyCountry 112 4.6. rFC822LocalPart 16 113 4.7. room 114 4.8. simpleSecurityObject 115 5. Security Considerations 17 116 6. IANA Considerations 117 7. Acknowledgments 19 118 8. Author's Address 119 9. Normative References 120 10. Informative References 121 Full Copyright 20 123 1. Background and Intended Use 125 This document provides descriptions [RFC2252] of user schema for use 126 with LDAP [LDAPTS] collected from numerous sources. 128 This document includes a summary of select schema introduced for the 129 COSINE and Internet X.500 pilot projects [RFC1274]. This document 130 obsoletes RFC 1274. 132 This document includes a summary of X.500 user schema [X.520] not 133 previously specified for use with LDAP. Some of these items were 134 described in the inetOrgPerson [RFC2798] schema. This document 135 supersedes these descriptions, replacing sections 9.1.3 and 9.3.3 of 136 RFC 2798. 138 2. Matching Rules 140 This section introduces LDAP matching rules based upon descriptions of 141 their X.500 counterparts. 143 2.1. booleanMatch 145 BooleanMatch compares for equality a asserted Boolean value with an 146 attribute value of BOOLEAN syntax. The rule returns TRUE if and only 147 if the values are the same, i.e. both are TRUE or both are FALSE. 148 (Source: X.520) 150 ( 2.5.13.13 NAME 'booleanMatch' 151 SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 ) 153 2.2. caseExactMatch 155 CaseExactMatch compares for equality the asserted value with an 156 attribute value of DirectoryString syntax. The rule is identical to 157 the caseIgnoreMatch [RFC2252] rule except that case is not ignored. 158 (Source: X.520) 160 ( 2.5.13.5 NAME 'caseExactMatch' 161 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 163 2.3. caseExactOrderingMatch 165 CaseExactOrderingMatch compares the collation order of the asserted 166 string with an attribute value of DirectoryString syntax. The rule is 167 identical to the caseIgnoreOrderingMatch [RFC2252] rule except that 168 letters are not folded. (Source: X.520) 170 ( 2.5.13.6 NAME 'caseExactOrderingMatch' 171 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 173 2.4. caseExactSubstringsMatch 175 CaseExactSubstringsMatch determines whether the asserted value(s) are 176 substrings of an attribute value of DirectoryString syntax. The rule 177 is identical to the caseIgnoreSubstringsMatch [RFC2252] rule except 178 that case is not ignored. (Source: X.520) 180 ( 2.5.13.7 NAME 'caseExactSubstringsMatch' 181 SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 ) 183 2.5. caseIgnoreListSubstringsMatch 184 CaseIgnoreListSubstringMatch compares the asserted substring with an 185 attribute value which is a sequence of DirectoryStrings, but where the 186 case (upper or lower) is not significant for comparison purposes. The 187 asserted value matches a stored value if and only if the asserted 188 value matches the string formed by concatenating the strings of the 189 stored value. This matching is done according to the 190 caseIgnoreSubstringsMatch [RFC2252] rule; however, none of the 191 initial, any, or final values of the asserted value are considered to 192 match a substring of the concatenated string which spans more than one 193 of the strings of the stored value. (Source: X.520) 195 ( 2.5.13.12 NAME 'caseIgnoreListSubstringsMatch' 196 SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 ) 198 2.6. directoryStringFirstComponentMatch 200 DirectoryStringFirstComponentMatch compares for equality the asserted 201 DirectoryString value with an attribute value of type SEQUENCE whose 202 first component is mandatory and of type DirectoryString. The rule 203 returns TRUE if and only if the attribute value has a first component 204 whose value matches the asserted DirectoryString using the rules of 205 caseIgnoreMatch [RFC2252]. A value of the assertion syntax is derived 206 from a value of the attribute syntax by using the value of the first 207 component of the SEQUENCE. (Source: X.520) 209 ( 2.5.13.31 NAME 'directoryStringFirstComponentMatch' 210 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 212 2.7. integerOrderingMatch 214 The integerOrderingMatch rule compares the ordering of the asserted 215 integer with an attribute value of Integer syntax. The rule returns 216 True if the attribute value is less than the asserted value. (Source: 217 X.520) 219 ( 2.5.13.15 NAME 'integerOrderingMatch' 220 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 ) 222 2.8. keywordMatch 224 The keywordMatch rule compares the asserted string with keywords in an 225 attribute value of DirectoryString syntax. The rule returns TRUE if 226 and only if the asserted value matches any keyword in the attribute 227 value. The identification of keywords in an attribute value and of 228 the exactness of match are both implementation specific. (Source: 230 X.520) 232 ( 2.5.13.32 NAME 'keywordMatch' 233 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 235 2.9. numericStringOrderingMatch 237 NumericStringOrderingMatch compares the collation order of the 238 asserted string with an attribute value of NumericString syntax. The 239 rule is identical to the caseIgnoreOrderingMatch [RFC2252] rule except 240 that all space characters are skipped during comparison (case is 241 irrelevant as characters are numeric). (Source: X.520) 243 ( 2.5.13.9 NAME 'numericStringOrderingMatch' 244 SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 ) 246 2.10. octetStringOrderingMatch 248 OctetStringOrderingMatch compares the collation order of the asserted 249 octet string with an attribute value of OCTET STRING syntax. The rule 250 compares octet strings from first octet to last octet, and from the 251 most significant bit to the least significant bit within the octet. 252 The first occurrence of a different bit determines the ordering of the 253 strings. A zero bit precedes a one bit. If the strings are identical 254 but contain different numbers of octets, the shorter string precedes 255 the longer string. (Source: X.520) 257 ( 2.5.13.18 NAME 'octetStringOrderingMatch' 258 SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 ) 260 2.11. storedPrefixMatch 262 StoredPrefixMatch determines whether an attribute value, whose syntax 263 is DirectoryString, is a prefix (i.e. initial substring) of the 264 asserted value, without regard to the case (upper or lower) of the 265 strings. The rule returns TRUE if and only if the attribute value is 266 an initial substring of the asserted value with corresponding 267 characters identical except possibly with regard to case. (Source: 268 X.520) 270 ( 2.5.13.41 NAME 'storedPrefixMatch' 271 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 273 Note: This rule can be used, for example, to compare values in the 274 Directory which are telephone area codes with a purported value 275 which is a telephone number. 277 2.12. wordMatch 279 The wordMatch rule compares the asserted string with words in an 280 attribute value of DirectoryString syntax. The rule returns TRUE if 281 and only if the asserted word matches any word in the attribute value. 282 Individual word matching is as for the caseIgnoreMatch [RFC2252] 283 matching rule. The precise definition of a "word" is implementation 284 specific. (Source: X.520) 286 ( 2.5.13.32 NAME 'wordMatch' 287 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 289 3. Attribute Types 291 This section details attribute types for use in LDAP. 293 3.1. associatedDomain 295 The associatedDomain attribute type specifies a DNS domain [RFC1034] 296 which is associated with an object. For example, the entry in the DIT 297 with a distinguished name "DC=example,DC=com" might have an associated 298 domain of "example.com". (Source: RFC 1274) 300 ( 0.9.2342.19200300.100.1.37 NAME 'associatedDomain' 301 EQUALITY caseIgnoreIA5Match 302 SUBSTR caseIgnoreIA5SubstringsMatch 303 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) 305 3.2. associatedName 307 The associatedName attribute type specifies an entry in the 308 organizational DIT associated with a DNS domain [RFC1034]. (Source: 309 RFC 1274) 311 ( 0.9.2342.19200300.100.1.38 NAME 'associatedName' 312 EQUALITY distinguishedNameMatch 313 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 ) 315 3.3. buildingName 317 The buildingName attribute type specifies the name of the building 318 where an organization or organizational unit is based. (Source: RFC 319 1274) 321 ( 0.9.2342.19200300.100.1.48 NAME 'buildingName' 322 EQUALITY caseIgnoreMatch 323 SUBSTR caseIgnoreSubstringsMatch 324 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) 326 3.3. co 328 The co (Friendly Country Name) attribute type specifies names of 329 countries in human readable format. It is commonly used in 330 conjunction with the c (Country Name) [RFC2256] attribute type (which 331 restricted to one of the two-letter codes defined in [ISO3166]). 332 (Source: RFC 1274) 334 ( 0.9.2342.19200300.100.1.43 335 NAME ( 'co' 'friendlyCountryName' ) 336 EQUALITY caseIgnoreMatch 337 SUBSTR caseIgnoreSubstringsMatch 338 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 340 3.5. documentAuthor 342 The documentAuthor attribute type specifies the distinguished name of 343 the author of a document. (Source: RFC 1274) 345 ( 0.9.2342.19200300.100.1.14 NAME 'documentAuthor' 346 EQUALITY distinguishedNameMatch 347 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 ) 349 3.6. documentIdentifier 351 The documentIdentifier attribute type specifies a unique identifier 352 for a document. (Source: RFC 1274) 354 ( 0.9.2342.19200300.100.1.11 NAME 'documentIdentifier' 355 EQUALITY caseIgnoreMatch 356 SUBSTR caseIgnoreSubstringsMatch 357 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) 359 3.7. documentLocation 361 The documentLocation attribute type specifies the location of the 362 document original. (Source: RFC 1274) 364 ( 0.9.2342.19200300.100.1.15 NAME 'documentLocation' 365 EQUALITY caseIgnoreMatch 366 SUBSTR caseIgnoreSubstringsMatch 367 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) 369 3.8. documentPublisher 371 The documentPublisher attribute is the person and/or organization that 372 published a document. (Source: RFC 1274) 374 ( 0.9.2342.19200300.100.1.56 NAME 'documentPublisher' 375 EQUALITY caseIgnoreMatch 376 SUBSTR caseIgnoreSubstringsMatch 377 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 379 3.9. documentTitle 381 The documentTitle attribute type specifies the title of a document. 382 (Source: RFC 1274) 384 ( 0.9.2342.19200300.100.1.12 NAME 'documentTitle' 385 EQUALITY caseIgnoreMatch 386 SUBSTR caseIgnoreSubstringsMatch 387 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) 389 3.10. documentVersion 391 The documentVersion attribute type specifies the version number of a 392 document. (Source: RFC 1274) 394 ( 0.9.2342.19200300.100.1.13 NAME 'documentVersion' 395 EQUALITY caseIgnoreMatch 396 SUBSTR caseIgnoreSubstringsMatch 397 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) 399 3.11. drink 401 The drink (Favourite Drink) attribute type specifies the favorite 402 drink of an object (or person). (Source: RFC 1274) 404 ( 0.9.2342.19200300.100.1.5 NAME ( 'drink' 'favouriteDrink' ) 405 EQUALITY caseIgnoreMatch 406 SUBSTR caseIgnoreSubstringsMatch 407 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) 409 3.12. homePhone 411 The homePhone (Home Telephone Number) attribute type specifies a home 412 telephone number (e.g., "+44 71 123 4567") associated with a person. 413 (Source: RFC 1274) 415 ( 0.9.2342.19200300.100.1.20 416 NAME ( 'homePhone' 'homeTelephoneNumber' ) 417 EQUALITY telephoneNumberMatch 418 SUBSTR telephoneNumberSubstringsMatch 419 SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 ) 421 3.13. homePostalAddress 423 The homePostalAddress attribute type specifies a home postal address 424 for an object. This SHOULD be limited to up to 6 lines of 30 425 characters each. (Source: RFC 1274) 427 ( 0.9.2342.19200300.100.1.39 428 NAME 'homePostalAddress' 429 EQUALITY caseIgnoreListMatch 430 SUBSTR caseIgnoreListSubstringsMatch 431 SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 ) 433 3.14. host 435 The host attribute type specifies a host computer. (Source: RFC 1274) 437 ( 0.9.2342.19200300.100.1.9 438 NAME 'host' 439 EQUALITY caseIgnoreMatch 440 SUBSTR caseIgnoreSubstringsMatch 441 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) 443 3.16. info 445 The info (Information) attribute type specifies any general 446 information pertinent to an object. It is RECOMMENDED that specific 447 usage of this attribute type is avoided, and that specific 448 requirements are met by other (possibly additional) attribute types. 449 Note that the description attribute type [RFC2256] is available for 450 specifying descriptive information pertinent to an object. (Source: 451 RFC 1274) 453 ( 0.9.2342.19200300.100.1.4 454 NAME 'info' 455 EQUALITY caseIgnoreMatch 456 SUBSTR caseIgnoreSubstringsMatch 457 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{2048} ) 459 3.17. mail 461 The mail (rfc822mailbox) attribute type holds an the electronic mail 462 address in [RFC822] form (e.g.: user@example.com). Note that this 463 attribute SHOULD NOT be used to hold non-Internet addresses. (Source: 464 RFC 1274) 466 ( 0.9.2342.19200300.100.1.3 467 NAME ( 'mail' 'rfc822Mailbox' ) 468 EQUALITY caseIgnoreIA5Match 469 SUBSTR caseIgnoreIA5SubstringsMatch 470 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} ) 472 3.18. manager 474 The Manager attribute type specifies the manager of an object 475 represented by an entry. (Source: RFC 1274) 477 ( 0.9.2342.19200300.100.1.10 478 NAME 'manager' 479 EQUALITY distinguishedNameMatch 480 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 ) 482 3.19. mobile 484 The mobile (Mobile Telephone Number) attribute type specifies a mobile 485 telephone number (e.g., "+44 71 123 4567") associated with a person. 486 (Source: RFC 1274) 488 ( 0.9.2342.19200300.100.1.41 489 NAME ( 'mobile' 'mobileTelephoneNumber' ) 490 EQUALITY telephoneNumberMatch 491 SUBSTR telephoneNumberSubstringsMatch 492 SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 ) 494 3.20. organizationalStatus 496 The organizationalStatus attribute type specifies a category by which 497 a person is often referred to in an organization. Examples of usage 498 in academia might include undergraduate student, researcher, lecturer, 499 etc. 501 A Directory administrator SHOULD consider carefully the distinctions 502 between this and the title and userClass attributes. (Source: RFC 503 1274) 505 ( 0.9.2342.19200300.100.1.45 506 NAME 'organizationalStatus' 507 EQUALITY caseIgnoreMatch 508 SUBSTR caseIgnoreSubstringsMatch 509 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) 511 3.21. otherMailbox 513 The otherMailbox attribute type specifies values for electronic 514 mailbox types other than X.400 and RFC822. (Source: RFC 1274) 516 ( 0.9.2342.19200300.100.1.22 517 NAME 'otherMailbox' 518 SYNTAX 1.3.6.1.4.1.1466.115.121.1.39 ) 520 3.22. pager 522 The pager (Pager Telephone Number) attribute type specifies a pager 523 telephone number (e.g., "+44 71 123 4567") for an object. (Source: 524 RFC 1274) 526 ( 0.9.2342.19200300.100.1.42 527 NAME ( 'pager' 'pagerTelephoneNumber' ) 528 EQUALITY telephoneNumberMatch 529 SUBSTR telephoneNumberSubstringsMatch 530 SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 ) 532 3.23. personalTitle 534 The personalTitle attribute type specifies a personal title for a 535 person. Examples of personal titles are "Frau", "Dr", "Herr", and 536 "Prof". (Source: RFC 1274) 538 ( 0.9.2342.19200300.100.1.40 539 NAME 'personalTitle' 540 EQUALITY caseIgnoreMatch 541 SUBSTR caseIgnoreSubstringsMatch 542 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) 544 3.24. roomNumber 546 The roomNumber attribute type specifies the room number of an object. 547 Note that the cn (commonName) attribute type SHOULD be used for naming 548 room objects. (Source: RFC 1274) 550 ( 0.9.2342.19200300.100.1.6 551 NAME 'roomNumber' 552 EQUALITY caseIgnoreMatch 553 SUBSTR caseIgnoreSubstringsMatch 554 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) 556 3.25. secretary 558 The secretary attribute type specifies the secretary of a person. The 559 attribute value for Secretary is a distinguished name. (Source: RFC 560 1274) 562 ( 0.9.2342.19200300.100.1.21 563 NAME 'secretary' 564 EQUALITY distinguishedNameMatch 565 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 ) 567 3.26. uid 569 The uid (userid) attribute type specifies a computer system login 570 name. (Source: RFC 1274) 572 ( 0.9.2342.19200300.100.1.1 573 NAME ( 'uid' 'userid' ) 574 EQUALITY caseIgnoreMatch 575 SUBSTR caseIgnoreSubstringsMatch 576 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) 578 3.27. uniqueIdentifier 580 The Unique Identifier attribute type specifies a "unique identifier" 581 for an object represented in the Directory. The domain within which 582 the identifier is unique, and the exact semantics of the identifier, 583 are for local definition. For a person, this might be an institution- 584 wide payroll number. For an organizational unit, it might be a 585 department code. An attribute value for uniqueIdentifier is a 586 directoryString. (Source: RFC 1274) 588 ( 0.9.2342.19200300.100.1.44 NAME 'uniqueIdentifier' 589 EQUALITY caseIgnoreMatch 590 SUBSTR caseIgnoreSubstringsMatch 591 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) 593 Note: X.520 describes an attribute also called 'uniqueIdentifier' 594 (2.5.4.45) which is called 'x500UniqueIdentifier' in LDAP 595 [RFC2256]. The attribute detailed here ought not be confused 596 with x500UniqueIdentifier. 598 3.28. userClass 600 The userClass attribute type specifies a category of computer user. 601 The semantics placed on this attribute are for local interpretation. 602 Examples of current usage od this attribute in academia are 603 undergraduate student, researcher, lecturer, etc. Note that the 604 organizationalStatus attribute type is now often be preferred as it 605 makes no distinction between computer users and others. (Source: RFC 606 1274) 608 ( 0.9.2342.19200300.100.1.8 NAME 'userClass' 609 EQUALITY caseIgnoreMatch 610 SUBSTR caseIgnoreSubstringsMatch 611 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) 613 4. Object Classes 615 This section details object classes for use in LDAP. 617 4.1. account 619 The account object class is used to define entries representing 620 computer accounts. The uid (userid) attribute SHOULD be used for 621 naming entries of this object class. (Source: RFC 1274) 623 ( 0.9.2342.19200300.100.4.5 624 NAME 'account' 625 SUP top STRUCTURAL 626 MUST uid 627 MAY ( description $ seeAlso $ l $ o $ ou $ host ) ) 629 4.2. document 631 The document object class is used to define entries which represent 632 documents. (Source: RFC 1274) 634 ( 0.9.2342.19200300.100.4.6 635 NAME 'document' 636 SUP top STRUCTURAL 637 MUST documentIdentifier 638 MAY ( cn $ description $ seeAlso $ l $ o $ ou $ 639 documentTitle $ documentVersion $ documentAuthor $ 640 documentLocation $ documentPublisher ) ) 642 4.3. documentSeries 644 The documentSeries object class is used to define an entry which 645 represents a series of documents (e.g., The Request For Comments 646 memos). (Source: RFC 1274) 648 ( 0.9.2342.19200300.100.4.9 649 NAME 'documentSeries' 650 SUP top STRUCTURAL 651 MUST cn 652 MAY ( description $ l $ o $ ou $ seeAlso $ 653 telephonenumber ) ) 655 4.4. domainRelatedObject 657 The domainRelatedObject object class is used to define entries which 658 represent DNS domains which are "equivalent" to an X.500 domain: e.g., 659 an organization or organizational unit. (Source: RFC 1274) 661 ( 0.9.2342.19200300.100.4.17 662 NAME 'domainRelatedObject' 663 SUP top AUXILIARY 664 MUST associatedDomain ) 666 4.5. friendlyCountry 668 The friendlyCountry object class is used to define country entries in 669 the DIT. The object class is used to allow friendlier naming of 670 countries than that allowed by the object class country [RFC2256]. 671 (Source: RFC 1274) 673 ( 0.9.2342.19200300.100.4.18 674 NAME 'friendlyCountry' 675 SUP country STRUCTURAL 676 MUST co ) 678 4.6. rFC822LocalPart 680 The rFC822LocalPart object class is used to define entries which 681 represent the local part of [RFC822] mail addresses. This treats this 682 part of an RFC 822 address as a domain [RFC2247]. (Source: RFC 1274) 684 ( 0.9.2342.19200300.100.4.14 685 NAME 'rFC822localPart' 686 SUP domain STRUCTURAL 687 MAY ( cn $ description $ destinationIndicator $ 688 facsimileTelephoneNumber $ internationaliSDNNumber $ 689 physicalDeliveryOfficeName $ postalAddress $ 690 postalCode $ postOfficeBox $ preferredDeliveryMethod $ 691 registeredAddress $ seeAlso $ sn $ street $ 692 telephoneNumber $ teletexTerminalIdentifier $ 693 telexNumber $ x121Address ) ) 695 4.7. room 697 The room object class is used to define entries representing rooms. 698 The cn (commonName) attribute SHOULD be used for naming entries of 699 this object class. (Source: RFC 1274) 701 ( 0.9.2342.19200300.100.4.7 NAME 'room' 702 SUP top STRUCTURAL 703 MUST cn 704 MAY ( roomNumber $ description $ 705 seeAlso $ telephoneNumber ) ) 707 4.8. simpleSecurityObject 709 The simpleSecurityObject object class is used to require an entry to 710 have a userPassword attribute when the entry's structural object class 711 does not require (or allow) the userPassword attribute. (Source: RFC 712 1274) 714 ( 0.9.2342.19200300.100.4.19 NAME 'simpleSecurityObject' 715 SUP top AUXILIARY 716 MUST userPassword ) 718 Note: Security considerations related to the use of simple 719 authentication mechanisms in LDAP are discussed in RFC 2829 720 [RFC2829]. 722 5. Security Considerations 724 General LDAP security considerations [LDAPTS] is applicable to the use 725 of this schema. Additional considerations are noted above where 726 appropriate. 728 6. IANA Considerations 730 It is requested that IANA update the LDAP descriptors registry as 731 indicated the following template: 733 Subject: Request for LDAP Descriptor Registration Update 734 Descriptor (short name): see comment 735 Object Identifier: see comment 736 Person & email address to contact for further information: 737 Kurt Zeilenga 738 Usage: see comment 739 Specification: RFCXXXX 740 Author/Change Controller: IESG 741 Comments: 743 The following descriptors should be added: 745 NAME Type OID 746 ------------------------ ---- --------- 747 booleanMatch M 2.5.13.13 748 caseExactMatch M 2.5.13.5 749 caseExactOrderingMatch M 2.5.13.6 750 caseExactSubstringsMatch M 2.5.13.7 751 caseIgnoreListSubstringsMatch M 2.5.13.12 752 directoryStringFirstComponentMatch M 2.5.13.31 753 integerOrderingMatch M 2.5.13.15 754 keywordMatch M 2.5.13.32 755 numericStringOrderingMatch M 2.5.13.9 756 octetStringOrderingMatch M 2.5.13.18 757 storedPrefixMatch M 2.5.13.41 758 wordMatch M 2.5.13.32 760 The following descriptors should be updated to refer to RFC XXXX. 762 NAME Type OID 763 ------------------------ ---- -------------------------- 764 account O 0.9.2342.19200300.100.4.5 765 associatedDomain A 0.9.2342.19200300.100.1.37 766 associatedName A 0.9.2342.19200300.100.1.38 767 buildingName A 0.9.2342.19200300.100.1.48 768 co A 0.9.2342.19200300.100.1.43 769 document O 0.9.2342.19200300.100.4.6 770 documentAuthor A 0.9.2342.19200300.100.1.14 771 documentIdentifier A 0.9.2342.19200300.100.1.11 772 documentLocation A 0.9.2342.19200300.100.1.15 773 documentPublisher A 0.9.2342.19200300.100.1.56 774 documentSeries O 0.9.2342.19200300.100.4.8 775 documentTitle A 0.9.2342.19200300.100.1.12 776 documentVersion A 0.9.2342.19200300.100.1.13 777 domainRelatedObject O 0.9.2342.19200300.100.4.17 778 drink A 0.9.2342.19200300.100.1.5 779 favouriteDrink A 0.9.2342.19200300.100.1.5 780 friendlyCountry O 0.9.2342.19200300.100.4.18 781 friendlyCountryName A 0.9.2342.19200300.100.1.43 782 homePhone A 0.9.2342.19200300.100.1.20 783 homePostalAddress A 0.9.2342.19200300.100.1.39 784 homeTelephone A 0.9.2342.19200300.100.1.20 785 host A 0.9.2342.19200300.100.1.9 786 info A 0.9.2342.19200300.100.1.4 787 mail A 0.9.2342.19200300.100.1.3 788 manager A 0.9.2342.19200300.100.1.10 789 mobile A 0.9.2342.19200300.100.1.41 790 mobileTelephoneNumber A 0.9.2342.19200300.100.1.41 791 organizationalStatus A 0.9.2342.19200300.100.1.45 792 otherMailbox A 0.9.2342.19200300.100.1.22 793 pager A 0.9.2342.19200300.100.1.42 794 pagerTelephoneNumber A 0.9.2342.19200300.100.1.42 795 personalTitle A 0.9.2342.19200300.100.1.40 796 RFC822LocalPart O 0.9.2342.19200300.100.4.14 797 RFC822Mailbox A 0.9.2342.19200300.100.1.3 798 room O 0.9.2342.19200300.100.4.7 799 roomNumber A 0.9.2342.19200300.100.1.6 800 secretary A 0.9.2342.19200300.100.1.21 801 simpleSecurityObject O 0.9.2342.19200300.100.4.19 802 singleLevelQuality A 0.9.2342.19200300.100.1.50 803 uid A 0.9.2342.19200300.100.1.1 804 uniqueIdentifier A 0.9.2342.19200300.100.1.44 805 userClass A 0.9.2342.19200300.100.1.8 806 userId A 0.9.2342.19200300.100.1.1 808 where Type A is Attribute, Type O is ObjectClass, and Type M 809 is Matching Rule. 811 This document make no OID assignments, it only associates LDAP schema 812 descriptions with existing elements of X.500 schema. 814 7. Acknowledgments 816 This document borrows from a number of IETF documents including RFC 817 1274 by Paul Barker and Steve Kille. This document also borrows from 818 a number of ITU documents including X.520. 820 8. Author's Address 822 Kurt D. Zeilenga 823 OpenLDAP Foundation 824 826 9. Normative References 828 [RFC822] D. Crocker, "Standard for the format of ARPA Internet text 829 messages", STD 11 (also RFC 822), August 1982. 831 [RFC1034] P.V. Mockapetris, "Domain names - concepts and facilities", 832 STD 13 (also RFC 1034), November 1987. 834 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 835 Requirement Levels", BCP 14 (also RFC 2119), March 1997. 837 [RFC2247] S. Kille, M. Wahl, A. Grimstad, R. Huber, S. Sataluri, 838 "Using Domains in LDAP/X.500 Distinguished Names", January 839 1998. 841 [RFC2252] M. Wahl, A. Coulbeck, T. Howes, S. Kille, "Lightweight 842 Directory Access Protocol (v3): Attribute Syntax 843 Definitions", RFC 2252, December 1997. 845 [RFC2256] M. Wahl, "A Summary of the X.500(96) User Schema for use 846 with LDAPv3", RFC 2256, December 1997. 848 [RFC2829] M. Wahl, H. Alvestrand, J. Hodges, R. Morgan, 849 "Authentication Methods for LDAP", RFC 2829, May 2000. 851 [LDAPTS] J. Hodges, R. Morgan, "Lightweight Directory Access Protocol 852 (v3): Technical Specification", draft-ietf-ldapbis- 853 ldapv3-ts-00.txt. 855 10. Informative References 857 [ISO3166] International Standards Organization, "Codes for the 858 representation of names of countries", ISO 3166. 860 [RFC1274] P. Barker, S. Kille, "The COSINE and Internet X.500 Schema", 861 November 1991. 863 [RFC2798] M. Smith, "The LDAP inetOrgPerson Object Class", RFC 2798, 864 April 2000. 866 [X.520] International Telephone Union, "The Directory: Selected 867 Attribute Types", X.520, 1997. 869 Full Copyright 871 Copyright 2002, The Internet Society. All Rights Reserved. 873 This document and translations of it may be copied and furnished to 874 others, and derivative works that comment on or otherwise explain it 875 or assist in its implementation may be prepared, copied, published and 876 distributed, in whole or in part, without restriction of any kind, 877 provided that the above copyright notice and this paragraph are 878 included on all such copies and derivative works. However, this 879 document itself may not be modified in any way, such as by removing 880 the copyright notice or references to the Internet Society or other 881 Internet organizations, except as needed for the purpose of 882 developing Internet standards in which case the procedures for 883 copyrights defined in the Internet Standards process must be followed, 884 or as required to translate it into languages other than English. 886 The limited permissions granted above are perpetual and will not be 887 revoked by the Internet Society or its successors or assigns. 889 This document and the information contained herein is provided on an 890 "AS IS" basis and THE AUTHORS, THE INTERNET SOCIETY, AND THE INTERNET 891 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, 892 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 893 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 894 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.