idnits 2.17.1 draft-zeilenga-ldap-user-schema-05.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 document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** 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 14 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 817 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 (29 January 2002) is 8123 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: 10 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: 29 July 2002 29 January 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.7. 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.4. destinationIndicator 84 3.5. documentAuthor 85 3.6. documentIdentifier 9 86 3.7. documentLocation 87 3.8. documentPublisher 88 3.9. documentTitle 89 3.10. documentVersion 90 3.11. drink 10 91 3.12. houseIdentifier 92 3.13. homePhone 93 3.14. homePostalAddress 94 3.15. host 11 95 3.16. info 96 3.17. mail 97 3.18. manager 12 98 3.19. mobile 99 3.20. organizationalStatus 100 3.21. otherMailbox 101 3.22. pager 13 102 3.23. personalTitle 103 3.24. roomNumber 104 3.25. secretary 105 3.26. uid 14 106 3.27. uniqueIdentifier 107 3.28. userClass 108 4. Object Classes 15 109 4.1. account 110 4.2. document 111 4.3. documentSeries 112 4.4. domainRelatedObject 16 113 4.5. friendlyCountry 114 4.6. rFC822LocalPart 115 4.7. room 17 116 4.8. simpleSecurityObject 117 5. Security Considerations 118 6. Acknowledgments 119 7. Author's Address 120 8. Normative References 18 121 9. Informative References 122 Full Copyright 19 124 1. Background and Intended Use 126 This document provides descriptions [RFC2252] of user schema for use 127 with LDAP [LDAPTS] collected from numerous sources. 129 This document includes a summary of select schema introduced for the 130 COSINE and Internet X.500 pilot projects [RFC1274]. This document 131 obsoletes RFC 1274. 133 This document includes a summary of X.500 user schema [X.520] not 134 previously specified for use with LDAP. Some of these items were 135 described in the inetOrgPerson [RFC2798] schema. This document 136 supersedes these descriptions, replacing sections 9.1.3 and 9.3.3 of 137 RFC 2798. 139 2. Matching Rules 141 This section introduces LDAP matching rules based upon descriptions of 142 their X.500 counterparts. 144 2.1. booleanMatch 146 BooleanMatch compares for equality a asserted Boolean value with an 147 attribute value of BOOLEAN syntax. The rule returns TRUE if and only 148 if the values are the same, i.e. both are TRUE or both are FALSE. 149 (Source: X.520) 151 ( 2.5.13.13 NAME 'booleanMatch' 152 SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 ) 154 2.2. caseExactMatch 156 CaseExactMatch compares for equality the asserted value with an 157 attribute value of DirectoryString syntax. The rule is identical to 158 the caseIgnoreMatch [RFC2252] rule except that case is not ignored. 159 (Source: X.520) 161 ( 2.5.13.5 NAME 'caseExactMatch' 162 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 164 2.3. caseExactOrderingMatch 166 CaseExactOrderingMatch compares the collation order of the asserted 167 string with an attribute value of DirectoryString syntax. The rule is 168 identical to the caseIgnoreOrderingMatch [RFC2252] rule except that 169 letters are not folded. (Source: X.520) 171 ( 2.5.13.6 NAME 'caseExactOrderingMatch' 172 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 174 2.3. caseExactSubstringsMatch 176 CaseExactSubstringsMatch determines whether the asserted value(s) are 177 substrings of an attribute value of DirectoryString syntax. The rule 178 is identical to the caseIgnoreSubstringsMatch [RFC2252] rule except 179 that case is not ignored. (Source: X.520) 181 ( 2.5.13.7 NAME 'caseExactSubstringsMatch' 182 SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 ) 184 2.4. caseIgnoreListSubstringsMatch 186 CaseIgnoreListSubstringMatch compares the asserted substring with an 187 attribute value which is a sequence of DirectoryStrings, but where the 188 case (upper or lower) is not significant for comparison purposes. The 189 asserted value matches a stored value if and only if the asserted 190 value matches the string formed by concatenating the strings of the 191 stored value. This matching is done according to the 192 caseIgnoreSubstringsMatch [RFC2252] rule; however, none of the 193 initial, any, or final values of the asserted value are considered to 194 match a substring of the concatenated string which spans more than one 195 of the strings of the stored value. (Source: X.520) 197 ( 2.5.13.12 NAME 'caseIgnoreListSubstringsMatch' 198 SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 ) 200 2.5. directoryStringFirstComponentMatch 202 DirectoryStringFirstComponentMatch compares for equality the asserted 203 DirectoryString value with an attribute value of type SEQUENCE whose 204 first component is mandatory and of type DirectoryString. The rule 205 returns TRUE if and only if the attribute value has a first component 206 whose value matches the asserted DirectoryString using the rules of 207 caseIgnoreMatch [RFC2252]. A value of the assertion syntax is derived 208 from a value of the attribute syntax by using the value of the first 209 component of the SEQUENCE. (Source: X.520) 211 ( 2.5.13.31 NAME 'directoryStringFirstComponentMatch' 212 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 214 2.6. integerOrderingMatch 216 The integerOrderingMatch rule compares the ordering of the asserted 217 integer with an attribute value of Integer syntax. The rule returns 218 True if the attribute value is less than the asserted value. (Source: 219 X.520) 221 ( 2.5.13.15 NAME 'integerOrderingMatch' 222 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 ) 224 2.7. keywordMatch 226 The keywordMatch rule compares the asserted string with keywords in an 227 attribute value of DirectoryString syntax. The rule returns TRUE if 228 and only if the asserted value matches any keyword in the attribute 229 value. The identification of keywords in an attribute value and of 230 the exactness of match are both implementation specific. (Source: 231 X.520) 233 ( 2.5.13.32 NAME 'keywordMatch' 234 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 236 2.8. numericStringOrderingMatch 238 NumericStringOrderingMatch compares the collation order of the 239 asserted string with an attribute value of NumericString syntax. The 240 rule is identical to the caseIgnoreOrderingMatch [RFC2252] rule except 241 that all space characters are skipped during comparison (case is 242 irrelevant as characters are numeric). (Source: X.520) 244 ( 2.5.13.9 NAME 'numericStringOrderingMatch' 245 SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 ) 247 2.9. octetStringOrderingMatch 249 OctetStringOrderingMatch compares the collation order of the asserted 250 octet string with an attribute value of OCTET STRING syntax. The rule 251 compares octet strings from first octet to last octet, and from the 252 most significant bit to the least significant bit within the octet. 253 The first occurrence of a different bit determines the ordering of the 254 strings. A zero bit precedes a one bit. If the strings are identical 255 but contain different numbers of octets, the shorter string precedes 256 the longer string. (Source: X.520) 258 ( 2.5.13.18 NAME 'octetStringOrderingMatch' 259 SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 ) 261 2.10. storedPrefixMatch 263 StoredPrefixMatch determines whether an attribute value, whose syntax 264 is DirectoryString, is a prefix (i.e. initial substring) of the 265 asserted value, without regard to the case (upper or lower) of the 266 strings. The rule returns TRUE if and only if the attribute value is 267 an initial substring of the asserted value with corresponding 268 characters identical except possibly with regard to case. (Source: 269 X.520) 271 ( 2.5.13.41 NAME 'storedPrefixMatch' 272 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 274 Note: This rule can be used, for example, to compare values in the 275 Directory which are telephone area codes with a purported value 276 which is a telephone number. 278 2.11. wordMatch 280 The wordMatch rule compares the asserted string with words in an 281 attribute value of DirectoryString syntax. The rule returns TRUE if 282 and only if the asserted word matches any word in the attribute value. 283 Individual word matching is as for the caseIgnoreMatch [RFC2252] 284 matching rule. The precise definition of a "word" is implementation 285 specific. (Source: X.520) 287 ( 2.5.13.32 NAME 'wordMatch' 288 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 290 3. Attribute Types 292 This section details attribute types for use in LDAP. 294 3.1. associatedDomain 296 The associatedDomain attribute type specifies a DNS domain [RFC1034] 297 which is associated with an object. For example, the entry in the DIT 298 with a distinguished name "DC=example,DC=com" might have an associated 299 domain of "example.com". (Source: RFC 1274) 301 ( 0.9.2342.19200300.100.1.37 NAME 'associatedDomain' 302 EQUALITY caseIgnoreIA5Match 303 SUBSTR caseIgnoreIA5SubstringsMatch 304 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) 306 3.2. associatedName 308 The associatedName attribute type specifies an entry in the 309 organizational DIT associated with a DNS domain [RFC1034]. (Source: 310 RFC 1274) 312 ( 0.9.2342.19200300.100.1.38 NAME 'associatedName' 313 EQUALITY distinguishedNameMatch 314 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 ) 316 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.4. destinationIndicator 342 The destinationIndicator attribute type specifies (according to CCITT 343 Recommendation F.1 and CCITT Recommendation F.31) the country and city 344 associated with the object (the addressee) needed to provide the 345 Public Telegram Service. An attribute value for Destination Indicator 346 is a printable string containing only alphabetical characters. 347 (Source: X.520) 349 ( 2.5.4.27 NAME 'destinationIndicator' 350 EQUALITY caseIgnoreMatch 351 SUBSTR caseIgnoreSubstringsMatch 352 SYNTAX 1.3.6.1.4.1.1466.115.121.1.44{128} ) 354 3.5. documentAuthor 356 The documentAuthor attribute type specifies the distinguished name of 357 the author of a document. (Source: RFC 1274) 359 ( 0.9.2342.19200300.100.1.14 NAME 'documentAuthor' 360 EQUALITY distinguishedNameMatch 361 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 ) 363 3.6. documentIdentifier 365 The documentIdentifier attribute type specifies a unique identifier 366 for a document. (Source: RFC 1274) 368 ( 0.9.2342.19200300.100.1.11 NAME 'documentIdentifier' 369 EQUALITY caseIgnoreMatch 370 SUBSTR caseIgnoreSubstringsMatch 371 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) 373 3.7. documentLocation 375 The documentLocation attribute type specifies the location of the 376 document original. (Source: RFC 1274) 378 ( 0.9.2342.19200300.100.1.15 NAME 'documentLocation' 379 EQUALITY caseIgnoreMatch 380 SUBSTR caseIgnoreSubstringsMatch 381 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) 383 3.8. documentPublisher 385 The documentPublisher attribute is the person and/or organization that 386 published a document. (Source: RFC 1274) 388 ( 0.9.2342.19200300.100.1.56 NAME 'documentPublisher' 389 EQUALITY caseIgnoreMatch 390 SUBSTR caseIgnoreSubstringsMatch 391 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 393 3.9. documentTitle 395 The documentTitle attribute type specifies the title of a document. 396 (Source: RFC 1274) 398 ( 0.9.2342.19200300.100.1.12 NAME 'documentTitle' 399 EQUALITY caseIgnoreMatch 400 SUBSTR caseIgnoreSubstringsMatch 401 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) 403 3.10. documentVersion 405 The documentVersion attribute type specifies the version number of a 406 document. (Source: RFC 1274) 407 ( 0.9.2342.19200300.100.1.13 NAME 'documentVersion' 408 EQUALITY caseIgnoreMatch 409 SUBSTR caseIgnoreSubstringsMatch 410 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) 412 3.11. drink 414 The drink (Favourite Drink) attribute type specifies the favorite 415 drink of an object (or person). (Source: RFC 1274) 417 ( 0.9.2342.19200300.100.1.5 NAME ( 'drink' 'favouriteDrink' ) 418 EQUALITY caseIgnoreMatch 419 SUBSTR caseIgnoreSubstringsMatch 420 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) 422 3.12. houseIdentifier 424 The houseIdentifier attribute type specifies a linguistic construct 425 used to identify a particular building, for example a house number or 426 house name relative to a street, avenue, town or city, etc. An 427 attribute value for houseIdentifier is a string, e.g. "14". (Source: 428 X.520) 430 ( 2.5.4.51 NAME 'houseIdentifier' 431 EQUALITY caseIgnoreMatch 432 SUBSTR caseIgnoreSubstringsMatch 433 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} ) 435 3.13. homePhone 437 The homePhone (Home Telephone Number) attribute type specifies a home 438 telephone number (e.g., "+44 71 123 4567") associated with a person. 439 (Source: RFC 1274) 441 ( 0.9.2342.19200300.100.1.20 442 NAME ( 'homePhone' 'homeTelephoneNumber' ) 443 EQUALITY telephoneNumberMatch 444 SUBSTR telephoneNumberSubstringsMatch 445 SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 ) 447 3.14. homePostalAddress 449 The homePostalAddress attribute type specifies a home postal address 450 for an object. This SHOULD be limited to up to 6 lines of 30 451 characters each. (Source: RFC 1274) 453 ( 0.9.2342.19200300.100.1.39 454 NAME 'homePostalAddress' 455 EQUALITY caseIgnoreListMatch 456 SUBSTR caseIgnoreListSubstringsMatch 457 SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 ) 459 3.15. host 461 The host attribute type specifies a host computer. (Source: RFC 1274) 463 ( 0.9.2342.19200300.100.1.9 464 NAME 'host' 465 EQUALITY caseIgnoreMatch 466 SUBSTR caseIgnoreSubstringsMatch 467 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) 469 3.16. info 471 The info (Information) attribute type specifies any general 472 information pertinent to an object. It is RECOMMENDED that specific 473 usage of this attribute type is avoided, and that specific 474 requirements are met by other (possibly additional) attribute types. 475 Note that the description attribute type [RFC2256] is available for 476 specifying descriptive information pertinent to an object. (Source: 477 RFC 1274) 479 ( 0.9.2342.19200300.100.1.4 480 NAME 'info' 481 EQUALITY caseIgnoreMatch 482 SUBSTR caseIgnoreSubstringsMatch 483 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{2048} ) 485 3.17. mail 487 The mail (rfc822mailbox) attribute type holds an the electronic mail 488 address in [RFC822] form (e.g.: user@example.com). Note that this 489 attribute SHOULD NOT be used to hold non-Internet addresses. (Source: 490 RFC 1274) 492 ( 0.9.2342.19200300.100.1.3 493 NAME ( 'mail' 'rfc822Mailbox' ) 494 EQUALITY caseIgnoreIA5Match 495 SUBSTR caseIgnoreIA5SubstringsMatch 496 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} ) 498 3.18. manager 500 The Manager attribute type specifies the manager of an object 501 represented by an entry. (Source: RFC 1274) 503 ( 0.9.2342.19200300.100.1.10 504 NAME 'manager' 505 EQUALITY distinguishedNameMatch 506 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 ) 508 3.19. mobile 510 The mobile (Mobile Telephone Number) attribute type specifies a mobile 511 telephone number (e.g., "+44 71 123 4567") associated with a person. 512 (Source: RFC 1274) 514 ( 0.9.2342.19200300.100.1.41 515 NAME ( 'mobile' 'mobileTelephoneNumber' ) 516 EQUALITY telephoneNumberMatch 517 SUBSTR telephoneNumberSubstringsMatch 518 SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 ) 520 3.20. organizationalStatus 522 The organizationalStatus attribute type specifies a category by which 523 a person is often referred to in an organization. Examples of usage 524 in academia might include undergraduate student, researcher, lecturer, 525 etc. 527 A Directory administrator SHOULD consider carefully the distinctions 528 between this and the title and userClass attributes. (Source: RFC 529 1274) 531 ( 0.9.2342.19200300.100.1.45 532 NAME 'organizationalStatus' 533 EQUALITY caseIgnoreMatch 534 SUBSTR caseIgnoreSubstringsMatch 535 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) 537 3.21. otherMailbox 538 The otherMailbox attribute type specifies values for electronic 539 mailbox types other than X.400 and RFC822. (Source: RFC 1274) 541 ( 0.9.2342.19200300.100.1.22 542 NAME 'otherMailbox' 543 SYNTAX 1.3.6.1.4.1.1466.115.121.1.39 ) 545 3.22. pager 547 The pager (Pager Telephone Number) attribute type specifies a pager 548 telephone number (e.g., "+44 71 123 4567") for an object. (Source: 549 RFC 1274) 551 ( 0.9.2342.19200300.100.1.42 552 NAME ( 'pager' 'pagerTelephoneNumber' ) 553 EQUALITY telephoneNumberMatch 554 SUBSTR telephoneNumberSubstringsMatch 555 SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 ) 557 3.23. personalTitle 559 The personalTitle attribute type specifies a personal title for a 560 person. Examples of personal titles are "Frau", "Dr", "Herr", and 561 "Prof". (Source: RFC 1274) 563 ( 0.9.2342.19200300.100.1.40 564 NAME 'personalTitle' 565 EQUALITY caseIgnoreMatch 566 SUBSTR caseIgnoreSubstringsMatch 567 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) 569 3.24. roomNumber 571 The roomNumber attribute type specifies the room number of an object. 572 Note that the cn (commonName) attribute type SHOULD be used for naming 573 room objects. (Source: RFC 1274) 575 ( 0.9.2342.19200300.100.1.6 576 NAME 'roomNumber' 577 EQUALITY caseIgnoreMatch 578 SUBSTR caseIgnoreSubstringsMatch 579 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) 581 3.25. secretary 582 The secretary attribute type specifies the secretary of a person. The 583 attribute value for Secretary is a distinguished name. (Source: RFC 584 1274) 586 ( 0.9.2342.19200300.100.1.21 587 NAME 'secretary' 588 EQUALITY distinguishedNameMatch 589 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 ) 591 3.26. uid 593 The uid (userid) attribute type specifies a computer system login 594 name. (Source: RFC 1274) 596 ( 0.9.2342.19200300.100.1.1 597 NAME ( 'uid' 'userid' ) 598 EQUALITY caseIgnoreMatch 599 SUBSTR caseIgnoreSubstringsMatch 600 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) 602 3.27. uniqueIdentifier 604 The Unique Identifier attribute type specifies a "unique identifier" 605 for an object represented in the Directory. The domain within which 606 the identifier is unique, and the exact semantics of the identifier, 607 are for local definition. For a person, this might be an institution- 608 wide payroll number. For an organizational unit, it might be a 609 department code. An attribute value for uniqueIdentifier is a 610 directoryString. (Source: RFC 1274) 612 ( 0.9.2342.19200300.100.1.14 NAME 'uniqueIdentifier' 613 EQUALITY caseIgnoreMatch 614 SUBSTR caseIgnoreSubstringsMatch 615 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) 617 Note: X.520 describes an attribute also called 'uniqueIdentifier' 618 (2.5.4.45) which is called 'x500UniqueIdentifier' in LDAP 619 [RFC2256]. The attribute detailed here ought not be confused 620 with x500UniqueIdentifier. 622 3.28. userClass 624 The userClass attribute type specifies a category of computer user. 625 The semantics placed on this attribute are for local interpretation. 626 Examples of current usage od this attribute in academia are 627 undergraduate student, researcher, lecturer, etc. Note that the 628 organizationalStatus attribute type is now often be preferred as it 629 makes no distinction between computer users and others. (Source: RFC 630 1274) 632 ( 0.9.2342.19200300.100.1.8 NAME 'userClass' 633 EQUALITY caseIgnoreMatch 634 SUBSTR caseIgnoreSubstringsMatch 635 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) 637 4. Object Classes 639 This section details object classes for use in LDAP. 641 4.1. account 643 The account object class is used to define entries representing 644 computer accounts. The uid (userid) attribute SHOULD be used for 645 naming entries of this object class. (Source: RFC 1274) 647 ( 0.9.2342.19200300.100.4.5 648 NAME 'account' 649 SUP top STRUCTURAL 650 MUST uid 651 MAY ( description $ seeAlso $ l $ o $ ou $ host ) ) 653 4.2. document 655 The document object class is used to define entries which represent 656 documents. (Source: RFC 1274) 658 ( 0.9.2342.19200300.100.4.6 659 NAME 'document' 660 SUP top STRUCTURAL 661 MUST documentIdentifier 662 MAY ( cn $ description $ seeAlso $ l $ o $ ou $ 663 documentTitle $ documentVersion $ documentAuthor $ 664 documentLocation $ documentPublisher ) ) 666 4.3. documentSeries 668 The documentSeries object class is used to define an entry which 669 represents a series of documents (e.g., The Request For Comments 670 memos). (Source: RFC 1274) 671 ( 0.9.2342.19200300.100.4.9 672 NAME 'documentSeries' 673 SUP top STRUCTURAL 674 MUST cn 675 MAY ( description $ l $ o $ ou $ seeAlso $ 676 telephonenumber ) ) 678 4.4. domainRelatedObject 680 The domainRelatedObject object class is used to define entries which 681 represent DNS domains which are "equivalent" to an X.500 domain: e.g., 682 an organization or organizational unit. (Source: RFC 1274) 684 ( 0.9.2342.19200300.100.4.17 685 NAME 'domainRelatedObject' 686 SUP top AUXILIARY 687 MUST associatedDomain ) 689 4.5. friendlyCountry 691 The friendlyCountry object class is used to define country entries in 692 the DIT. The object class is used to allow friendlier naming of 693 countries than that allowed by the object class country [RFC2256]. 694 (Source: RFC 1274) 696 ( 0.9.2342.19200300.100.4.18 697 NAME 'friendlyCountry' 698 SUP country STRUCTURAL 699 MUST co ) 701 4.6. rFC822LocalPart 703 The rFC822LocalPart object class is used to define entries which 704 represent the local part of [RFC822] mail addresses. This treats this 705 part of an RFC 822 address as a domain [RFC2247]. (Source: RFC 1274) 707 ( 0.9.2342.19200300.100.4.14 708 NAME 'rFC822localPart' 709 SUP domain STRUCTURAL 710 MAY ( cn $ description $ destinationIndicator $ 711 facsimileTelephoneNumber $ internationaliSDNNumber $ 712 physicalDeliveryOfficeName $ postalAddress $ 713 postalCode $ postOfficeBox $ preferredDeliveryMethod $ 714 registeredAddress $ seeAlso $ sn $ street $ 715 telephoneNumber $ teletexTerminalIdentifier $ 716 telexNumber $ x121Address ) ) 718 4.7. room 720 The room object class is used to define entries representing rooms. 721 The cn (commonName) attribute SHOULD be used for naming entries of 722 this object class. (Source: RFC 1274) 724 ( 0.9.2342.19200300.100.4.7 NAME 'room' 725 SUP top STRUCTURAL 726 MUST cn 727 MAY ( roomNumber $ description $ 728 seeAlso $ telephoneNumber ) ) 730 4.8. simpleSecurityObject 732 The simpleSecurityObject object class is used to require an entry to 733 have a userPassword attribute when the entry's structural object class 734 does not require (or allow) the userPassword attribute. (Source: RFC 735 1274) 737 ( 0.9.2342.19200300.100.4.19 NAME 'simpleSecurityObject' 738 SUP top AUXILIARY 739 MUST userPassword ) 741 Note: Security considerations related to the use of simple 742 authentication mechanisms in LDAP are discussed in RFC 2829 743 [RFC2829]. 745 5. Security Considerations 747 General LDAP security considerations [LDAPTS] is applicable to the use 748 of this schema. Additional considerations are noted above where 749 appropriate. 751 6. Acknowledgments 753 This document borrows from a number of IETF documents including RFC 754 1274 by Paul Barker and Steve Kille. This document also borrows from 755 a number of ITU documents including X.520. 757 7. Author's Address 758 Kurt D. Zeilenga 759 OpenLDAP Foundation 760 762 8. Normative References 764 [RFC822] D. Crocker, "Standard for the format of ARPA Internet text 765 messages", STD 11 (also RFC 822), August 1982. 767 [RFC1034] P.V. Mockapetris, "Domain names - concepts and facilities", 768 STD 13 (also RFC 1034), November 1987. 770 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 771 Requirement Levels", BCP 14 (also RFC 2119), March 1997. 773 [RFC2247] S. Kille, M. Wahl, A. Grimstad, R. Huber, S. Sataluri, 774 "Using Domains in LDAP/X.500 Distinguished Names", January 775 1998. 777 [RFC2252] M. Wahl, A. Coulbeck, T. Howes, S. Kille, "Lightweight 778 Directory Access Protocol (v3): Attribute Syntax 779 Definitions", RFC 2252, December 1997. 781 [RFC2256] M. Wahl, "A Summary of the X.500(96) User Schema for use 782 with LDAPv3", RFC 2256, December 1997. 784 [RFC2829] M. Wahl, H. Alvestrand, J. Hodges, R. Morgan, 785 "Authentication Methods for LDAP", RFC 2829, May 2000. 787 [LDAPTS] J. Hodges, R. Morgan, "Lightweight Directory Access Protocol 788 (v3): Technical Specification", draft-ietf-ldapbis- 789 ldapv3-ts-00.txt. 791 9. Informative References 793 [ISO3166] International Standards Organization, "Codes for the 794 representation of names of countries", ISO 3166. 796 [RFC1274] P. Barker, S. Kille, "The COSINE and Internet X.500 Schema", 797 November 1991. 799 [RFC2798] M. Smith, "The LDAP inetOrgPerson Object Class", RFC 2798, 800 April 2000. 802 [X.520] International Telephone Union, "The Directory: Selected 803 Attribute Types", X.520, 1997. 805 Full Copyright 807 Copyright 2002, The Internet Society. All Rights Reserved. 809 This document and translations of it may be copied and furnished to 810 others, and derivative works that comment on or otherwise explain it 811 or assist in its implementation may be prepared, copied, published and 812 distributed, in whole or in part, without restriction of any kind, 813 provided that the above copyright notice and this paragraph are 814 included on all such copies and derivative works. However, this 815 document itself may not be modified in any way, such as by removing 816 the copyright notice or references to the Internet Society or other 817 Internet organizations, except as needed for the purpose of 818 developing Internet standards in which case the procedures for 819 copyrights defined in the Internet Standards process must be followed, 820 or as required to translate it into languages other than English. 822 The limited permissions granted above are perpetual and will not be 823 revoked by the Internet Society or its successors or assigns. 825 This document and the information contained herein is provided on an 826 "AS IS" basis and THE AUTHORS, THE INTERNET SOCIETY, AND THE INTERNET 827 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, 828 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 829 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 830 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.