idnits 2.17.1 draft-zeilenga-ldap-user-schema-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** 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 15 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 814 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. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: The key words "SHALL", "SHALL NOT", "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "MAY" and "MAY NOT" used in this document are to be interpreted as described in BCP 14 [RFC2119]. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (20 November 2001) is 8192 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'ISO 3166' is mentioned on line 330, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO3166' ** 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 (~~), 8 warnings (==), 4 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: 20 May 2002 20 November 2001 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 2001, 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 collected from numerous sources including RFC 1274, X.501, 45 and X.520. 47 Conventions 49 Schema definitions are provided using LDAPv3 description formats 50 [RFC2252]. Definitions provided here are formatted (line wrapped) for 51 readability. 53 The key words "SHALL", "SHALL NOT", "MUST", "MUST NOT", "SHOULD", 54 "SHOULD NOT", "MAY" and "MAY NOT" used in this document are to be 55 interpreted as described in BCP 14 [RFC2119]. 57 Table of Contents (to be expanded by editor) 59 Status of this Memo 1 60 Abstract 61 Conventions 2 62 Table of Contents 63 1. Background and Intended Use 3 64 2. Matching Rules 65 2.1. booleanMatch 4 66 2.2. caseExactMatch 67 2.3. caseExactOrderingMatch 68 2.4. caseExactSubstringsMatch 69 2.5. caseIgnoreListSubstringsMatch 70 2.6. directoryStringFirstComponentMatch 5 71 2.7. integerOrderingMatch 72 2.7. keywordMatch 73 2.9. numericStringOrderingMatch 6 74 2.10. octetStringOrderingMatch 75 2.11. storedPrefixMatch 76 2.12. wordMatch 7 77 3. Attribute Types 78 3.1. associatedDomain 79 3.2. associatedName 80 3.3. buildingName 81 3.3. co 8 82 3.4. destinationIndicator 83 3.5. documentAuthor 84 3.6. documentIdentifier 9 85 3.7. documentLocation 86 3.8. documentPublisher 87 3.9. documentTitle 88 3.10. documentVersion 89 3.11. drink 10 90 3.12. houseIdentifier 91 3.13. homePhone 92 3.14. homePostalAddress 93 3.15. host 11 94 3.16. info 95 3.17. mail 96 3.18. manager 12 97 3.19. mobile 98 3.20. organizationalStatus 99 3.21. otherMailbox 100 3.22. pager 13 101 3.23. personalTitle 102 3.24. roomNumber 103 3.25. secretary 104 3.26. uid 14 105 3.27. uniqueIdentifier 106 3.28. userClass 107 4. Object Classes 15 108 4.1. account 109 4.2. document 110 4.3. documentSeries 111 4.4. domainRelatedObject 16 112 4.5. friendlyCountry 113 4.6. rFC822LocalPart 114 4.7. room 17 115 4.8. simpleSecurityObject 116 5. Security Considerations 117 6. Acknowledgments 118 7. Author's Address 119 8. Normative References 18 120 9. Informative References 121 Full Copyright 19 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 contains a summary of X.500 user schema [X.520] not 133 included in LDAPv3 [RFC2252][RFC2256]. 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 139 This section introduces LDAP matching rules based upon descriptions of 140 their X.500 counterparts. 142 2.1. booleanMatch 144 BooleanMatch compares for equality a asserted Boolean value with an 145 attribute value of BOOLEAN syntax. The rule returns TRUE if and only 146 if the values are the same, i.e. both are TRUE or both are FALSE. 147 (Source: X.520) 149 ( 2.5.13.13 NAME 'booleanMatch' 150 SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 ) 152 2.2. caseExactMatch 154 CaseExactMatch compares for equality the asserted value with an 155 attribute value of DirectoryString syntax. The rule is identical to 156 the caseIgnoreMatch [RFC2252] rule except that case is not ignored. 157 (Source: X.520) 159 ( 2.5.13.5 NAME 'caseExactMatch' 160 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 162 2.3. caseExactOrderingMatch 164 CaseExactOrderingMatch compares the collation order of the asserted 165 string with an attribute value of DirectoryString syntax. The rule is 166 identical to the caseIgnoreOrderingMatch [RFC2252] rule except that 167 letters are not folded. (Source: X.520) 169 ( 2.5.13.6 NAME 'caseExactOrderingMatch' 170 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 172 2.3. caseExactSubstringsMatch 174 CaseExactSubstringsMatch determines whether the asserted value are 175 substrings of an attribute value of DirectoryString syntax. The rule 176 is identical to the caseIgnoreSubstringsMatch [RFC2252] rule except 177 that case is not ignored. (Source: X.520) 179 ( 2.5.13.7 NAME 'caseExactSubstringsMatch' 180 SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 ) 182 2.4. 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.5. 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.6. 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.7. 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: 229 X.520) 231 ( 2.5.13.32 NAME 'keywordMatch' 232 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 234 2.8. numericStringOrderingMatch 236 NumericStringOrderingMatch compares the collation order of the 237 asserted string with an attribute value of NumericString syntax. The 238 rule is identical to the caseIgnoreOrderingMatch [RFC2252] rule except 239 that all space characters are skipped during comparison (case is 240 irrelevant as characters are numeric). (Source: X.520) 242 ( 2.5.13.9 NAME 'NumericStringOrderingMatch' 243 SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 ) 245 2.9. octetStringOrderingMatch 247 OctetStringOrderingMatch compares the collation order of the asserted 248 octet string with an attribute value of OCTET STRING syntax. The rule 249 compares octet strings from first octet to last octet, and from the 250 most significant bit to the least significant bit within the octet. 251 The first occurrence of a different bit determines the ordering of the 252 strings. A zero bit precedes a one bit. If the strings are identical 253 but contain different numbers of octets, the shorter string precedes 254 the longer string. (Source: X.520) 256 ( 2.5.13.18 NAME 'octetStringOrderingMatch' 257 SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 ) 259 2.10. storedPrefixMatch 261 StoredPrefixMatch determines whether an attribute value, whose syntax 262 is DirectoryString, is a prefix (i.e. initial substring) of the 263 asserted value, without regard to the case (upper or lower) of the 264 strings. The rule returns TRUE if and only if the attribute value is 265 an initial substring of the asserted value with corresponding 266 characters identical except possibly with regard to case. (Source: 267 X.520) 269 ( 2.5.13.41 NAME 'storedPrefixMatch' 270 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 272 Note: This rule can be used, for example, to compare values in the 273 Directory which are telephone area codes with a purported value 274 which is a telephone number. 276 2.11. wordMatch 278 The wordMatch rule compares the asserted string with words in an 279 attribute value of DirectoryString syntax. The rule returns TRUE if 280 and only if the asserted word matches any word in the attribute value. 281 Individual word matching is as for the caseIgnoreMatch [RFC2252] 282 matching rule. The precise definition of a "word" is implementation 283 specific. (Source: X.520) 285 ( 2.5.13.32 NAME 'wordMatch' 286 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 288 3. Attribute Types 290 This section details attribute types for use in LDAP based upon their 291 X.500 descriptions. 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. The standard attribute country 330 name must be one of the two-letter codes defined in [ISO 3166]. 331 (Source: RFC 1274) 333 ( 0.9.2342.19200300.100.1.43 334 NAME ( 'co' 'friendlyCountryName' ) 335 EQUALITY caseIgnoreMatch 336 SUBSTR caseIgnoreSubstringsMatch 337 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 339 3.4. destinationIndicator 341 The destinationIndicator attribute type specifies (according to CCITT 342 Recommendation F.1 and CCITT Recommendation F.31) the country and city 343 associated with the object (the addressee) needed to provide the 344 Public Telegram Service. An attribute value for Destination Indicator 345 is a printable string containing only alphabetical characters. 346 (Source: X.520) 348 ( 2.5.4.27 NAME 'destinationIndicator' 349 EQUALITY caseIgnoreMatch 350 SUBSTR caseIgnoreSubstringsMatch 351 SYNTAX 1.3.6.1.4.1.1466.115.121.1.44{128} ) 353 3.5. documentAuthor 355 The documentAuthor attribute type specifies the distinguished name of 356 the author of a document. (Source: RFC 1274) 358 ( 0.9.2342.19200300.100.1.14 NAME 'documentAuthor' 359 EQUALITY distinguishedNameMatch 360 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 ) 362 3.6. documentIdentifier 364 The documentIdentifier attribute type specifies a unique identifier 365 for a document. (Source: RFC 1274) 367 ( 0.9.2342.19200300.100.1.11 NAME 'documentIdentifier' 368 EQUALITY caseIgnoreMatch 369 SUBSTR caseIgnoreSubstringsMatch 370 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) 372 3.7. documentLocation 374 The documentLocation attribute type specifies the location of the 375 document original. (Source: RFC 1274) 377 ( 0.9.2342.19200300.100.1.15 NAME 'documentLocation' 378 EQUALITY caseIgnoreMatch 379 SUBSTR caseIgnoreSubstringsMatch 380 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) 382 3.8. documentPublisher 384 The documentPublisher attribute is the person and/or organization that 385 published a document. (Source: RFC 1274) 387 ( 0.9.2342.19200300.100.1.56 NAME 'documentPublisher' 388 EQUALITY caseIgnoreMatch 389 SUBSTR caseIgnoreSubstringsMatch 390 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 392 3.9. documentTitle 394 The documentTitle attribute type specifies the title of a document. 395 (Source: RFC 1274) 397 ( 0.9.2342.19200300.100.1.12 NAME 'documentTitle' 398 EQUALITY caseIgnoreMatch 399 SUBSTR caseIgnoreSubstringsMatch 400 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) 402 3.10. documentVersion 403 The documentVersion attribute type specifies the version number of a 404 document. (Source: RFC 1274) 406 ( 0.9.2342.19200300.100.1.13 NAME 'documentVersion' 407 EQUALITY caseIgnoreMatch 408 SUBSTR caseIgnoreSubstringsMatch 409 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) 411 3.11. drink 413 The drink (Favourite Drink) attribute type specifies the favorite 414 drink of an object (or person). (Source: RFC 1274) 416 ( 0.9.2342.19200300.100.1.5 NAME ( 'drink' 'favouriteDrink' ) 417 EQUALITY caseIgnoreMatch 418 SUBSTR caseIgnoreSubstringsMatch 419 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) 421 3.12. houseIdentifier 423 The houseIdentifier attribute type specifies a linguistic construct 424 used to identify a particular building, for example a house number or 425 house name relative to a street, avenue, town or city, etc. An 426 attribute value for houseIdentifier is a string, e.g. "14". (Source: 427 X.520) 429 ( 2.5.4.51 NAME 'houseIdentifier' 430 EQUALITY caseIgnoreMatch 431 SUBSTR caseIgnoreSubstringsMatch 432 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} ) 434 3.13. homePhone 436 The homePhone (Home Telephone Number) attribute type specifies a home 437 telephone number (e.g., "+44 71 123 4567") associated with a person. 438 (Source: RFC 1274) 440 ( 0.9.2342.19200300.100.1.20 441 NAME ( 'homePhone' 'homeTelephoneNumber' ) 442 EQUALITY telephoneNumberMatch 443 SUBSTR telephoneNumberSubstringsMatch 444 SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 ) 446 3.14. homePostalAddress 447 The homePostalAddress attribute type specifies a home postal address 448 for an object. This should be limited to up to 6 lines of 30 449 characters each. (Source: RFC 1274) 451 ( 0.9.2342.19200300.100.1.39 452 NAME 'homePostalAddress' 453 EQUALITY caseIgnoreListMatch 454 SUBSTR caseIgnoreListSubstringsMatch 455 SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 ) 457 3.15. host 459 The host attribute type specifies a host computer. (Source: RFC 1274) 461 ( 0.9.2342.19200300.100.1.9 462 NAME 'host' 463 EQUALITY caseIgnoreMatch 464 SUBSTR caseIgnoreSubstringsMatch 465 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) 467 3.16. info 469 The info (Information) attribute type specifies any general 470 information pertinent to an object. It is RECOMMENDED that specific 471 usage of this attribute type is avoided, and that specific 472 requirements are met by other (possibly additional) attribute types. 473 It is noted the description attribute [RFC2256] for specifying 474 descriptive information pertinent to an object. (Source: RFC 1274) 476 ( 0.9.2342.19200300.100.1.4 477 NAME 'info' 478 EQUALITY caseIgnoreMatch 479 SUBSTR caseIgnoreSubstringsMatch 480 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{2048} ) 482 3.17. mail 484 The mail (rfc822mailbox) attribute type holds an the electronic mail 485 address in [RFC822] form (e.g.: user@example.com). Note that this 486 attribute SHOULD NOT be used to hold non-Internet addresses. (Source: 487 RFC 1274) 489 ( 0.9.2342.19200300.100.1.3 490 NAME ( 'mail' 'rfc822Mailbox' ) 491 EQUALITY caseIgnoreIA5Match 492 SUBSTR caseIgnoreIA5SubstringsMatch 493 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} ) 495 3.18. manager 497 The Manager attribute type specifies the manager of an object 498 represented by an entry. (Source: RFC 1274) 500 ( 0.9.2342.19200300.100.1.10 501 NAME 'manager' 502 EQUALITY distinguishedNameMatch 503 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 ) 505 3.19. mobile 507 The mobile (Mobile Telephone Number) attribute type specifies a mobile 508 telephone number (e.g., "+44 71 123 4567") associated with a person. 509 (Source: RFC 1274) 511 ( 0.9.2342.19200300.100.1.41 512 NAME ( 'mobile' 'mobileTelephoneNumber' ) 513 EQUALITY telephoneNumberMatch 514 SUBSTR telephoneNumberSubstringsMatch 515 SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 ) 517 3.20. organizationalStatus 519 The organizationalStatus attribute type specifies a category by which 520 a person is often referred to in an organization. Examples of usage 521 in academia might include undergraduate student, researcher, lecturer, 522 etc. 524 A Directory administrator should probably consider carefully the 525 distinctions between this and the title and userClass attributes. 526 (Source: RFC 1274) 528 ( 0.9.2342.19200300.100.1.45 529 NAME 'organizationalStatus' 530 EQUALITY caseIgnoreMatch 531 SUBSTR caseIgnoreSubstringsMatch 532 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) 534 3.21. otherMailbox 535 The otherMailbox attribute type specifies values for electronic 536 mailbox types other than X.400 and RFC822. (Source: RFC 1274) 538 ( 0.9.2342.19200300.100.1.22 539 NAME 'otherMailbox' 540 SYNTAX 1.3.6.1.4.1.1466.115.121.1.39 ) 542 3.22. pager 544 The pager (Pager Telephone Number) attribute type specifies a pager 545 telephone number (e.g., "+44 71 123 4567") for an object. (Source: 546 RFC 1274) 548 ( 0.9.2342.19200300.100.1.42 549 NAME ( 'pager' 'pagerTelephoneNumber' ) 550 EQUALITY telephoneNumberMatch 551 SUBSTR telephoneNumberSubstringsMatch 552 SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 ) 554 3.23. personalTitle 556 The personalTitle attribute type specifies a personal title for a 557 person. Examples of personal titles are "Frau", "Dr", "Herr", and 558 "Prof". (Source: RFC 1274) 560 ( 0.9.2342.19200300.100.1.40 561 NAME 'personalTitle' 562 EQUALITY caseIgnoreMatch 563 SUBSTR caseIgnoreSubstringsMatch 564 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) 566 3.24. roomNumber 568 The roomNumber attribute type specifies the room number of an object. 569 Note that the cn (commonName) attribute should be used for naming room 570 objects. (Source: RFC 1274) 572 ( 0.9.2342.19200300.100.1.6 573 NAME 'roomNumber' 574 EQUALITY caseIgnoreMatch 575 SUBSTR caseIgnoreSubstringsMatch 576 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) 578 3.25. secretary 579 The secretary attribute type specifies the secretary of a person. The 580 attribute value for Secretary is a distinguished name. (Source: RFC 581 1274) 583 ( 0.9.2342.19200300.100.1.21 584 NAME 'secretary' 585 EQUALITY distinguishedNameMatch 586 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 ) 588 3.26. uid 590 The uid (userid) attribute type specifies a computer system login 591 name. (Source: RFC 1274) 593 ( 0.9.2342.19200300.100.1.1 594 NAME ( 'uid' 'userid' ) 595 EQUALITY caseIgnoreMatch 596 SUBSTR caseIgnoreSubstringsMatch 597 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) 599 3.27. uniqueIdentifier 601 The Unique Identifier attribute type specifies a "unique identifier" 602 for an object represented in the Directory. The domain within which 603 the identifier is unique, and the exact semantics of the identifier, 604 are for local definition. For a person, this might be an institution- 605 wide payroll number. For an organizational unit, it might be a 606 department code. An attribute value for uniqueIdentifier is a 607 directoryString. (Source: RFC 1274) 609 ( 2.5.4.45 NAME 'uniqueIdentifier' 610 EQUALITY caseIgnoreMatch 611 SUBSTR caseIgnoreSubstringsMatch 612 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) 614 Note: X.520 describes an attribute also called 'uniqueIdentifier' 615 (2.5.4.45) which is called 'x500UniqueIdentifier' in LDAP 616 [RFC2256]. The attribute detailed here ought not be confused 617 with x500UniqueIdentifier. 619 3.28. userClass 621 The userClass attribute type specifies a category of computer user. 622 The semantics placed on this attribute are for local interpretation. 623 Examples of current usage od this attribute in academia are 624 undergraduate student, researcher, lecturer, etc. Note that the 625 organizationalStatus attribute may now often be preferred as it makes 626 no distinction between computer users and others. (Source: RFC 1274) 628 ( 0.9.2342.19200300.100.1.8 NAME 'userClass' 629 EQUALITY caseIgnoreMatch 630 SUBSTR caseIgnoreSubstringsMatch 631 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) 633 4. Object Classes 635 This section details attribute types for use in LDAP based upon their 636 X.500 descriptions. 638 4.1. account 640 The account object class is used to define entries representing 641 computer accounts. The uid (userid) attribute should be used for 642 naming entries of this object class. (Source: RFC 1274) 644 ( 0.9.2342.19200300.100.4.5 645 NAME 'account' 646 SUP top STRUCTURAL 647 MUST uid 648 MAY ( description $ seeAlso $ l $ o $ ou $ host ) ) 650 4.2. document 652 The document object class is used to define entries which represent 653 documents. (Source: RFC 1274) 655 ( 0.9.2342.19200300.100.4.6 656 NAME 'document' 657 SUP top STRUCTURAL 658 MUST documentIdentifier 659 MAY ( cn $ description $ seeAlso $ l $ o $ ou $ 660 documentTitle $ documentVersion $ documentAuthor $ 661 documentLocation $ documentPublisher ) ) 663 4.3. documentSeries 665 The documentSeries object class is used to define an entry which 666 represents a series of documents (e.g., The Request For Comments 667 memos). (Source: RFC 1274) 668 ( 0.9.2342.19200300.100.4.9 669 NAME 'documentSeries' 670 SUP top STRUCTURAL 671 MUST cn 672 MAY ( description $ l $ o $ ou $ seeAlso $ 673 telephonenumber ) ) 675 4.4. domainRelatedObject 677 The domainRelatedObject object class is used to define entries which 678 represent DNS domains which are "equivalent" to an X.500 domain: e.g., 679 an organization or organizational unit. (Source: RFC 1274) 681 ( 0.9.2342.19200300.100.4.17 682 NAME 'domainRelatedObject' 683 SUP top AUXILIARY 684 MUST associatedDomain ) 686 4.5. friendlyCountry 688 The friendlyCountry object class is used to define country entries in 689 the DIT. The object class is used to allow friendlier naming of 690 countries than that allowed by the object class country. The naming 691 attribute of object class country, c (countryName), has to be a 2 692 letter string defined in [ISO3166]. (Source: RFC 1274) 694 ( 0.9.2342.19200300.100.4.18 695 NAME 'friendlyCountry' 696 SUP country STRUCTURAL 697 MUST co ) 699 4.6. rFC822LocalPart 701 The rFC822LocalPart object class is used to define entries which 702 represent the local part of [RFC822] mail addresses. This treats this 703 part of an RFC 822 address as a domain [RFC2247]. (Source: RFC 1274) 705 ( 0.9.2342.19200300.100.4.14 706 NAME 'rFC822localPart' 707 SUP domain STRUCTURAL 708 MAY ( cn $ description $ destinationIndicator $ 709 facsimileTelephoneNumber $ internationaliSDNNumber $ 710 physicalDeliveryOfficeName $ postalAddress $ 711 postalCode $ postOfficeBox $ preferredDeliveryMethod $ 712 registeredAddress $ seeAlso $ sn $ street $ 713 telephoneNumber $ teletexTerminalIdentifier $ 714 telexNumber $ x121Address ) ) 716 4.7. room 718 The room object class is used to define entries representing rooms. 719 The cn (commonName) attribute should be used for naming entries of 720 this object class. (Source: RFC 1274) 722 ( 0.9.2342.19200300.100.4.7 NAME 'room' 723 SUP top STRUCTURAL 724 MUST cn 725 MAY ( roomNumber $ description $ 726 seeAlso $ telephoneNumber ) ) 728 4.8. simpleSecurityObject 730 The simpleSecurityObject object class is used to allow an entry to 731 have a userPassword attribute when an entry's principal object classes 732 do not allow userPassword as an attribute type. (Source: RFC 1274) 734 ( 0.9.2342.19200300.100.4.19 NAME 'simpleSecurityObject' 735 SUP top AUXILIARY 736 MUST userPassword ) 738 Note: Security considerations related to the use of simple 739 authentication mechanisms in LDAP are discussed in RFC 2829 740 [RFC2829]. 742 5. Security Considerations 744 General LDAP security considerations [LDAPTS] is applicable to the use 745 of this schema. Additional considerations are noted above where 746 appropriate. 748 6. Acknowledgments 750 This document borrows from a number of IETF documents including RFC 751 1274 by Paul Barker and Steve Kille. This document also borrows from 752 a number of ITU documents including X.520. 754 7. Author's Address 755 Kurt D. Zeilenga 756 OpenLDAP Foundation 757 759 8. Normative References 761 [ISO3166] International Standards Organization, "Codes for the 762 representation of names of countries", ISO 3166. 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 [RFC1274] P. Barker, S. Kille, "The COSINE and Internet X.500 Schema", 794 November 1991. 796 [RFC2798] M. Smith, "The LDAP inetOrgPerson Object Class", RFC 2798, 797 April 2000. 799 [X.520] International Telephone Union, "The Directory: Selected 800 Attribute Types", X.520, 1997. 802 Full Copyright 804 Copyright 2001, The Internet Society. All Rights Reserved. 806 This document and translations of it may be copied and furnished to 807 others, and derivative works that comment on or otherwise explain it 808 or assist in its implementation may be prepared, copied, published and 809 distributed, in whole or in part, without restriction of any kind, 810 provided that the above copyright notice and this paragraph are 811 included on all such copies and derivative works. However, this 812 document itself may not be modified in any way, such as by removing 813 the copyright notice or references to the Internet Society or other 814 Internet organizations, except as needed for the purpose of 815 developing Internet standards in which case the procedures for 816 copyrights defined in the Internet Standards process must be followed, 817 or as required to translate it into languages other than English. 819 The limited permissions granted above are perpetual and will not be 820 revoked by the Internet Society or its successors or assigns. 822 This document and the information contained herein is provided on an 823 "AS IS" basis and THE AUTHORS, THE INTERNET SOCIETY, AND THE INTERNET 824 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, 825 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 826 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 827 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.