idnits 2.17.1 draft-ietf-ldapbis-user-schema-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1460. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1431. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1438. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1444. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 1448), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 10. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([Roadmap]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 112 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == The 'Obsoletes: ' line in the draft header should list only the _numbers_ of the RFCs which will be obsoleted by this document (if approved); it should not include the word 'RFC' in the list. == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. -- The draft header indicates that this document updates RFC2798, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC2377, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC2247, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == In addition to RFC 3978, Section 5.1 boilerplate, a section with a similar start was also found: By submitting this Internet-Draft, I accept the provisions of Section 3 of BCP 78. == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year (Using the creation date from RFC2247, updated by this document, for RFC5378 checks: 1996-08-01) -- 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 (January 30, 2006) is 6660 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: 'LDAP-CRL' is mentioned on line 1497, but not defined == Missing Reference: 'LDAP-CERT' is mentioned on line 1497, but not defined == Missing Reference: 'ROADMAP' is mentioned on line 1544, but not defined == Missing Reference: 'RoadMap' is mentioned on line 1545, but not defined == Missing Reference: 'AUTHMETH' is mentioned on line 1545, but not defined == Missing Reference: 'SASLprep' is mentioned on line 1599, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO3166' -- No information found for draft-ietf-ldapbis-models-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'Models' ** Obsolete normative reference: RFC 3490 (Obsoleted by RFC 5890, RFC 5891) ** Obsolete normative reference: RFC 4013 (Obsoleted by RFC 7613) ** Obsolete normative reference: RFC 4234 (Obsoleted by RFC 5234) -- No information found for draft-ietf-ldapbis-roadmap-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'Roadmap' -- No information found for draft-ietf-ldapbis-syntaxes-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'Syntaxes' -- No information found for draft-ietf-ldapbis-authmeth-xx - is the name correct? -- No information found for draft-zeilenga-ldap-x509-xx - is the name correct? -- Obsolete informational reference (is this intentional?): RFC 1274 (Obsoleted by RFC 4524) Summary: 8 errors (**), 0 flaws (~~), 11 warnings (==), 20 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Editor: A. Sciberras 3 Intended Category: Standard Track eB2Bcom 4 Updates: RFC 2247, RFC 2798, RFC 2377 January 30, 2006 5 Obsoletes: RFC 2256 7 LDAP: Schema for User Applications 8 draft-ietf-ldapbis-user-schema-11.txt 10 Copyright (C) The Internet Society (2006). All Rights Reserved. 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 By submitting this Internet-Draft, I accept the provisions of Section 20 3 of BCP 78. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as 25 Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress". 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/1id-abstracts.html 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html 38 This document is intended to be, after appropriate review and 39 revision, submitted to the RFC Editor as a Standard Track document. 40 Distribution of this document is unlimited. Technical discussion of 41 this document should take place on the IETF LDAP Revision Working 42 Group (LDAPbis) mailing list . Please 43 send editorial comments directly to the editor 44 . 46 This Internet-Draft expires on 30 July 2006. 48 Abstract 50 This document is an integral part of the Lightweight Directory Access 51 Protocol (LDAP) technical specification [Roadmap]. It provides a 52 technical specification of attribute types and object classes 53 intended for use by LDAP directory clients for many directory 54 services, such as, White Pages. These objects are widely used as a 55 basis for the schema in many LDAP directories. This document does 56 not cover attributes used for the administration of directory 57 servers, nor does it include directory objects defined for specific 58 uses in other documents. 60 Table of Contents 62 Status of this Memo . . . . . . . . . . . . . . . . . . . . . . . 1 63 Copyright Notice. . . . . . . . . . . . . . . . . . . . . . . . . 1 64 Abstract. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 65 Table of Contents . . . . . . . . . . . . . . . . . . . . . . . . 3 66 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 5 67 1.1 Relationship with other specifications . . . . . . . . . 5 68 1.2 Conventions. . . . . . . . . . . . . . . . . . . . . . . 5 69 1.3 General Issues . . . . . . . . . . . . . . . . . . . . . 5 71 2. Attribute Types . . . . . . . . . . . . . . . . . . . . . . . 6 72 2.1 'businessCategory' . . . . . . . . . . . . . . . . . . . 6 73 2.2 'c'. . . . . . . . . . . . . . . . . . . . . . . . . . . 6 74 2.3 'cn' . . . . . . . . . . . . . . . . . . . . . . . . . . 7 75 2.4 'dc' . . . . . . . . . . . . . . . . . . . . . . . . . . 7 76 2.5 'description'. . . . . . . . . . . . . . . . . . . . . . 8 77 2.6 'destinationIndicator' . . . . . . . . . . . . . . . . . 8 78 2.7 'distinguishedName'. . . . . . . . . . . . . . . . . . . 8 79 2.8 'dnQualifier'. . . . . . . . . . . . . . . . . . . . . . 9 80 2.9 'enhancedSearchGuide'. . . . . . . . . . . . . . . . . . 9 81 2.10 'facsimileTelephoneNumber' . . . . . . . . . . . . . . . 10 82 2.11 'generationQualifier'. . . . . . . . . . . . . . . . . . 10 83 2.12 'givenName'. . . . . . . . . . . . . . . . . . . . . . . 10 84 2.13 'houseIdentifier'. . . . . . . . . . . . . . . . . . . . 11 85 2.14 'initials' . . . . . . . . . . . . . . . . . . . . . . . 11 86 2.15 'internationalISDNNumber'. . . . . . . . . . . . . . . . 11 87 2.16 'l'. . . . . . . . . . . . . . . . . . . . . . . . . . . 12 88 2.17 'member' . . . . . . . . . . . . . . . . . . . . . . . . 12 89 2.18 'name' . . . . . . . . . . . . . . . . . . . . . . . . . 12 90 2.19 'o'. . . . . . . . . . . . . . . . . . . . . . . . . . . 13 91 2.20 'ou' . . . . . . . . . . . . . . . . . . . . . . . . . . 13 92 2.21 'owner'. . . . . . . . . . . . . . . . . . . . . . . . . 13 93 2.22 'physicalDeliveryOfficeName' . . . . . . . . . . . . . . 13 94 2.23 'postalAddress'. . . . . . . . . . . . . . . . . . . . . 14 95 2.24 'postalCode' . . . . . . . . . . . . . . . . . . . . . . 14 96 2.25 'postOfficeBox'. . . . . . . . . . . . . . . . . . . . . 14 97 2.26 'preferredDeliveryMethod'. . . . . . . . . . . . . . . . 15 98 2.27 'registeredAddress'. . . . . . . . . . . . . . . . . . . 15 99 2.28 'roleOccupant' . . . . . . . . . . . . . . . . . . . . . 16 100 2.29 'searchGuide'. . . . . . . . . . . . . . . . . . . . . . 16 101 2.30 'seeAlso'. . . . . . . . . . . . . . . . . . . . . . . . 16 102 2.31 'serialNumber' . . . . . . . . . . . . . . . . . . . . . 17 103 2.32 'sn' . . . . . . . . . . . . . . . . . . . . . . . . . . 17 104 2.33 'st' . . . . . . . . . . . . . . . . . . . . . . . . . . 17 105 2.34 'street' . . . . . . . . . . . . . . . . . . . . . . . . 18 106 2.35 'telephoneNumber'. . . . . . . . . . . . . . . . . . . . 18 107 2.36 'teletexTerminalIdentifier'. . . . . . . . . . . . . . . 18 108 2.37 'telexNumber'. . . . . . . . . . . . . . . . . . . . . . 19 109 2.38 'title'. . . . . . . . . . . . . . . . . . . . . . . . . 19 110 2.39 'uid'. . . . . . . . . . . . . . . . . . . . . . . . . . 19 111 2.40 'uniqueMember' . . . . . . . . . . . . . . . . . . . . . 19 112 2.41 'userPassword' . . . . . . . . . . . . . . . . . . . . . 20 113 2.42 'x121Address'. . . . . . . . . . . . . . . . . . . . . . 21 114 2.43 'x500UniqueIdentifier' . . . . . . . . . . . . . . . . . 21 116 3. Object Classes. . . . . . . . . . . . . . . . . . . . . . . . 22 117 3.1 'applicationProcess' . . . . . . . . . . . . . . . . . . 22 118 3.2 'country'. . . . . . . . . . . . . . . . . . . . . . . . 22 119 3.3 'dcObject' . . . . . . . . . . . . . . . . . . . . . . . 22 120 3.4 'device' . . . . . . . . . . . . . . . . . . . . . . . . 23 121 3.5 'groupOfNames' . . . . . . . . . . . . . . . . . . . . . 23 122 3.6 'groupOfUniqueNames' . . . . . . . . . . . . . . . . . . 23 123 3.7 'locality' . . . . . . . . . . . . . . . . . . . . . . . 24 124 3.8 'organization' . . . . . . . . . . . . . . . . . . . . . 24 125 3.9 'organizationalPerson' . . . . . . . . . . . . . . . . . 24 126 3.10 'organizationalRole' . . . . . . . . . . . . . . . . . . 25 127 3.11 'organizationalUnit' . . . . . . . . . . . . . . . . . . 25 128 3.12 'person' . . . . . . . . . . . . . . . . . . . . . . . . 26 129 3.13 'residentialPerson'. . . . . . . . . . . . . . . . . . . 26 130 3.14 'uidObject'. . . . . . . . . . . . . . . . . . . . . . . 26 132 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 134 5. Security Considerations . . . . . . . . . . . . . . . . . . . 28 136 6. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . 29 138 7. References. . . . . . . . . . . . . . . . . . . . . . . . . . 30 139 7.1 Normative. . . . . . . . . . . . . . . . . . . . . . . . 30 140 7.2 Informative. . . . . . . . . . . . . . . . . . . . . . . 31 142 8. Author's Address. . . . . . . . . . . . . . . . . . . . . . . 31 144 9. Intellectual Property Statement . . . . . . . . . . . . . . . 32 146 10. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 32 148 1. Introduction 150 This document provides an overview of attribute types and object 151 classes intended for use by Lightweight Directory Access Protocol 152 (LDAP) directory clients for many directory services, such as, White 153 Pages. Originally specified in the X.500 [X.500] documents, these 154 objects are widely used as a basis for the schema in many LDAP 155 directories. This document does not cover attributes used for the 156 administration of directory servers, nor does it include directory 157 objects defined for specific uses in other documents. 159 1.1 Relationship with other specifications 161 This document is an integral part of the LDAP technical specification 162 [Roadmap] which obsoletes the previously defined LDAP technical 163 specification, RFC 3377, in its entirety. In terms of RFC 2256, 164 Sections 6 and 8 of RFC 2256 are obsoleted by [Syntaxes]. Sections 165 5.1, 5.2, 7.1 and 7.2 of RFC 2256 are obsoleted by [Models]. The 166 remainder of RFC 2256 is obsoleted by this document. Section 2.4 of 167 this document supersedes the technical specification for the 'dc' 168 attribute type and 'dcObject' object class found in RFC 2247. The 169 remainder of RFC 2247 remains in force. 171 This document updates RFC 2798 by replacing the informative 172 description of the 'uid' attribute type, with the definitive 173 description provided in Section 2.39 of this document. 175 A number of schema elements which were included in the previous 176 revision of the LDAP Technical Specification are not included in this 177 revision of LDAP. PKI-related schema elements are now specified in 178 [LDAP-PKI]. Unless reintroduced in future technical specifications, 179 the remainder are to be considered Historic. 181 The descriptions in this document SHALL be considered definitive for 182 use in LDAP. 184 1.2 Conventions 186 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 187 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 188 document are to be interpreted as described in RFC 2119 [RFC2119]. 190 1.3 General Issues 192 This document references Syntaxes defined in Section 3 of [Syntaxes] 193 and Matching Rules defined in Section 4 of [Syntaxes]. 195 The definitions of Attribute Types and Object Classes are written 196 using the Augmented Backus-Naur Form (ABNF) [RFC4234] of 197 AttributeTypeDescription and ObjectClassDescription given in 198 [Models]. Lines have been folded for readability. When such values 199 are transferred as attribute values in the LDAP Protocol the values 200 will not contain line breaks. 202 2. Attribute Types 204 The Attribute Types contained in this section hold user information. 206 There is no requirement that servers implement the 'searchGuide' and 207 'teletexTerminalIdentifier' attribute types. In fact, their use is 208 greatly discouraged. 210 An LDAP server implementation SHOULD recognize the rest of the 211 attribute types described in this section. 213 2.1 'businessCategory' 215 The 'businessCategory' attribute type describes the kinds of business 216 performed by an organization. Each kind is one value of this 217 multi-valued attribute. 218 (Source: X.520 [X.520]) 220 ( 2.5.4.15 NAME 'businessCategory' 221 EQUALITY caseIgnoreMatch 222 SUBSTR caseIgnoreSubstringsMatch 223 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 225 1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax 226 [Syntaxes]. 228 Examples: "banking", "transportation" and "real estate". 230 2.2 'c' 232 The 'c' ('countryName' in X.500) attribute type contains a two-letter 233 ISO 3166 [ISO3166] country code. 234 (Source: X.520 [X.520]) 236 ( 2.5.4.6 NAME 'c' 237 SUP name 238 SYNTAX 1.3.6.1.4.1.1466.115.121.1.11 239 SINGLE-VALUE ) 241 1.3.6.1.4.1.1466.115.121.1.11 refers to the Country String syntax 242 [Syntaxes]. 244 Examples: "DE", "AU" and "FR". 246 2.3 'cn' 248 The 'cn' ('commonName' in X.500) attribute type contains names of an 249 object. Each name is one value of this multi-valued attribute. If 250 the object corresponds to a person, it is typically the person's full 251 name. 252 (Source: X.520 [X.520]) 254 ( 2.5.4.3 NAME 'cn' 255 SUP name ) 257 Examples: "Martin K Smith", "Marty Smith" and "printer12". 259 2.4 'dc' 261 The 'dc' ('domainComponent' in RFC 2247) attribute type is a string 262 holding one component, a label, of a DNS domain name [RFC1034]. The 263 encoding of IA5String for use in LDAP is simply the characters of the 264 ASCII label. The equality matching rule is case insensitive, as is 265 today's DNS. 266 (Source: RFC 2247 [RFC2247]) 268 ( 0.9.2342.19200300.100.1.25 NAME 'dc' 269 EQUALITY caseIgnoreIA5Match 270 SUBSTR caseIgnoreIA5SubstringsMatch 271 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 272 SINGLE-VALUE ) 274 1.3.6.1.4.1.1466.115.121.1.26 refers to the IA5 String syntax 275 [Syntaxes]. 277 Examples: Valid values include "example" and "com". The value 278 "example.com" is invalid, because it contains two label 279 components. 281 Directory applications supporting International Domain Names SHALL 282 use the ToASCII method [RFC3490] to produce the domain name component 283 label. The special considerations discussed in section 4 of RFC 3490 284 [RFC3490] should be taken, depending on whether the domain component 285 is used for "stored" or "query" purposes. 287 2.5 'description' 289 The 'description' attribute type contains human-readable descriptive 290 phrases about the object. Each description is one value of this 291 multi-valued attribute. 292 (Source: X.520 [X.520]) 294 ( 2.5.4.13 NAME 'description' 295 EQUALITY caseIgnoreMatch 296 SUBSTR caseIgnoreSubstringsMatch 297 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 299 1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax 300 [Syntaxes]. 302 Examples: "a color printer", "Maintenance is done every Monday, at 303 1pm." and "distribution list for all technical staff". 305 2.6 'destinationIndicator' 307 The 'destinationIndicator' attribute type contains country and city 308 strings, associated with the object (the addressee), needed to 309 provide the Public Telegram Service. The strings are composed in 310 accordance with CCITT Recommendations F.1 [F.1] and F.31 [F.31]. 311 Each string is one value of this multi-valued attribute. 312 (Source: X.520 [X.520]) 314 ( 2.5.4.27 NAME 'destinationIndicator' 315 EQUALITY caseIgnoreMatch 316 SUBSTR caseIgnoreSubstringsMatch 317 SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 ) 319 1.3.6.1.4.1.1466.115.121.1.44 refers to the Printable String syntax 320 [Syntaxes]. 322 Examples: "AASD" as a destination indicator for Sydney, Australia. 323 "GBLD" as a destination indicator for London, United 324 Kingdom. 326 It is noted that the directory will not ensure that values of this 327 attribute conform to the F.1 and F.30 CCITT Recommendations. It is 328 the application's responsibility to ensure destination indicators 329 that it stores in this attribute are appropriately constructed. 331 2.7 'distinguishedName' 333 The 'distinguishedName' attribute type is not used as the name of the 334 object itself, but it is instead a base type from which some user 335 attribute types with a DN syntax can inherit. 337 It is unlikely that values of this type itself will occur in an 338 entry. LDAP server implementations which do not support attribute 339 subtyping need not recognize this attribute in requests. Client 340 implementations MUST NOT assume that LDAP servers are capable of 341 performing attribute subtyping. 342 (Source: X.520 [X.520]) 344 ( 2.5.4.49 NAME 'distinguishedName' 345 EQUALITY distinguishedNameMatch 346 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 ) 348 1.3.6.1.4.1.1466.115.121.1.12 refers to the DN syntax [Syntaxes]. 350 2.8 'dnQualifier' 352 The 'dnQualifier' attribute type contains disambiguating information 353 strings to add to the relative distinguished name of an entry. The 354 information is intended for use when merging data from multiple 355 sources in order to prevent conflicts between entries which would 356 otherwise have the same name. Each string is one value of this 357 multi-valued attribute. It is recommended that a value of the 358 'dnQualifier' attribute be the same for all entries from a particular 359 source. 360 (Source: X.520 [X.520]) 362 ( 2.5.4.46 NAME 'dnQualifier' 363 EQUALITY caseIgnoreMatch 364 ORDERING caseIgnoreOrderingMatch 365 SUBSTR caseIgnoreSubstringsMatch 366 SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 ) 368 1.3.6.1.4.1.1466.115.121.1.44 refers to the Printable String syntax 369 [Syntaxes]. 371 Examples: "20050322123345Z" - timestamps can be used to disambiguate 372 information. 373 "123456A" - serial numbers can be used to disambiguate 374 information. 376 2.9 'enhancedSearchGuide' 378 The 'enhancedSearchGuide' attribute type contains sets of information 379 for use by directory clients in constructing search filters. Each 380 set is one value of this multi-valued attribute. 381 (Source: X.520 [X.520]) 382 ( 2.5.4.47 NAME 'enhancedSearchGuide' 383 SYNTAX 1.3.6.1.4.1.1466.115.121.1.21 ) 385 1.3.6.1.4.1.1466.115.121.1.21 refers to the Enhanced Guide syntax 386 [Syntaxes]. 388 Examples: "person#(sn$APPROX)#wholeSubtree" and 389 "organizationalUnit#(ou$SUBSTR)#oneLevel". 391 2.10 'facsimileTelephoneNumber' 393 The 'facsimileTelephoneNumber' attribute type contains telephone 394 numbers (and, optionally, the parameters) for facsimile terminals. 395 Each telephone number is one value of this multi-valued attribute. 396 (Source: X.520 [X.520]) 398 ( 2.5.4.23 NAME 'facsimileTelephoneNumber' 399 SYNTAX 1.3.6.1.4.1.1466.115.121.1.22 ) 401 1.3.6.1.4.1.1466.115.121.1.22 refers to the Facsimile Telephone 402 Number syntax [Syntaxes]. 404 Examples: "+61 3 9896 7801" and "+81 3 347 7418$fineResolution". 406 2.11 'generationQualifier' 408 The 'generationQualifier' attribute type contains name strings that 409 are the part of a person's name which typically is the suffix. Each 410 string is one value of this multi-valued attribute. 411 (Source: X.520 [X.520]) 413 ( 2.5.4.44 NAME 'generationQualifier' 414 SUP name ) 416 Examples: "III", "3rd" and "Jr.". 418 2.12 'givenName' 420 The 'givenName' attribute type contains name strings that are the 421 part of a person's name which is not their surname. Each string is 422 one value of this multi-valued attribute. 423 (Source: X.520 [X.520]) 425 ( 2.5.4.42 NAME 'givenName' 426 SUP name ) 428 Examples: "Andrew", "Charles" and "Joanne". 430 2.13 'houseIdentifier' 432 The 'houseIdentifier' attribute type contains identifiers for a 433 building within a location. Each identifier is one value of this 434 multi-valued attribute. 435 (Source: X.520 [X.520]) 437 ( 2.5.4.51 NAME 'houseIdentifier' 438 EQUALITY caseIgnoreMatch 439 SUBSTR caseIgnoreSubstringsMatch 440 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 442 1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax 443 [Syntaxes]. 445 Examples: "20" to represent the house number 20. 447 2.14 'initials' 449 The 'initials' attribute type contains strings of initials of some or 450 all of an individual's names, except the surname(s). Each string is 451 one value of this multi-valued attribute. 452 (Source: X.520 [X.520]) 454 ( 2.5.4.43 NAME 'initials' 455 SUP name ) 457 Examples: "K. A." and "K". 459 2.15 'internationalISDNNumber' 461 The 'internationalISDNNumber' attribute type contains Integrated 462 Services Digital Network (ISDN) addresses, as defined in the 463 International Telecommunication Union (ITU) Recommendation E.164 464 [E.164]. Each address is one value of this multi-valued attribute. 465 (Source: X.520 [X.520]) 467 ( 2.5.4.25 NAME 'internationalISDNNumber' 468 EQUALITY numericStringMatch 469 SUBSTR numericStringSubstringsMatch 470 SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 ) 472 1.3.6.1.4.1.1466.115.121.1.36 refers to the Numeric String syntax 473 [Syntaxes]. 475 Example: "0198 333 333". 477 2.16 'l' 479 The 'l' ('localityName' in X.500) attribute type contains names of a 480 locality or place, such as a city, county or other geographic region. 481 Each name is one value of this multi-valued attribute. 482 (Source: X.520 [X.520]) 484 ( 2.5.4.7 NAME 'l' 485 SUP name ) 487 Examples: "Geneva", "Paris" and "Edinburgh". 489 2.17 'member' 491 The 'member' attribute type contains the Distinguished Names of 492 objects that are on a list or in a group. Each name is one value of 493 this multi-valued attribute. 494 (Source: X.520 [X.520]) 496 ( 2.5.4.31 NAME 'member' 497 SUP distinguishedName ) 499 Examples: "cn=James Clarke,ou=Finance,o=Widget\, Inc." and 500 "cn=John Xerri,ou=Finance,o=Widget\, Inc." may 501 be two members of the financial team (group) at Widget, 502 Inc. In which case, both of these distinguished names would 503 be present as individual values of the member attribute. 505 2.18 'name' 507 The 'name' attribute type is the attribute supertype from which user 508 attribute types with the name syntax inherit. Such attribute types 509 are typically used for naming. The attribute type is multi-valued. 511 It is unlikely that values of this type itself will occur in an 512 entry. LDAP server implementations which do not support attribute 513 subtyping need not recognize this attribute in requests. Client 514 implementations MUST NOT assume that LDAP servers are capable of 515 performing attribute subtyping. 516 (Source: X.520 [X.520]) 518 ( 2.5.4.41 NAME 'name' 519 EQUALITY caseIgnoreMatch 520 SUBSTR caseIgnoreSubstringsMatch 521 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 523 1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax 524 [Syntaxes]. 526 2.19 'o' 528 The 'o' ('organizationName' in X.500) attribute type contains the 529 names of an organization. Each name is one value of this 530 multi-valued attribute. 531 (Source: X.520 [X.520]) 533 ( 2.5.4.10 NAME 'o' 534 SUP name ) 536 Examples: "Widget", "Widget, Inc." and "Widget, Incorporated.". 538 2.20 'ou' 540 The 'ou' ('organizationalUnitName' in X.500) attribute type contains 541 the names of an organizational unit. Each name is one value of this 542 multi-valued attribute. 543 (Source: X.520 [X.520]) 545 ( 2.5.4.11 NAME 'ou' 546 SUP name ) 548 Examples: "Finance", "Human Resources" and "Research and 549 Development". 551 2.21 'owner' 553 The 'owner' attribute type contains the Distinguished Names of 554 objects that have an ownership responsibility for the object that is 555 owned. Each owner's name is one value of this multi-valued 556 attribute. 557 (Source: X.520 [X.520]) 559 ( 2.5.4.32 NAME 'owner' 560 SUP distinguishedName ) 562 Example: The mailing list object, whose DN is "cn=All Employees, 563 ou=Mailing List,o=Widget\, Inc.", is owned by the Human 564 Resources Director. 565 Therefore, the value of the 'owner' attribute within the 566 mailing list object, would be the DN of the director (role): 567 "cn=Human Resources Director,ou=employee,o=Widget\, Inc.". 569 2.22 'physicalDeliveryOfficeName' 571 The 'physicalDeliveryOfficeName' attribute type contains names that a 572 Postal Service uses to identify a post office. 573 (Source: X.520 [X.520]) 574 ( 2.5.4.19 NAME 'physicalDeliveryOfficeName' 575 EQUALITY caseIgnoreMatch 576 SUBSTR caseIgnoreSubstringsMatch 577 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 579 1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax 580 [Syntaxes]. 582 Examples: "Bremerhaven, Main" and "Bremerhaven, Bonnstrasse". 584 2.23 'postalAddress' 586 The 'postalAddress' attribute type contains addresses used by a 587 Postal Service to perform services for the object. Each address is 588 one value of this multi-valued attribute. 589 (Source: X.520 [X.520]) 591 ( 2.5.4.16 NAME 'postalAddress' 592 EQUALITY caseIgnoreListMatch 593 SUBSTR caseIgnoreListSubstringsMatch 594 SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 ) 596 1.3.6.1.4.1.1466.115.121.1.41 refers to the Postal Address syntax 597 [Syntaxes]. 599 Example: "15 Main St.$Ottawa$Canada". 601 2.24 'postalCode' 603 The 'postalCode' attribute type contains codes used by a Postal 604 Service to identify postal service zones. Each code is one value of 605 this multi-valued attribute. 606 (Source: X.520 [X.520]) 608 ( 2.5.4.17 NAME 'postalCode' 609 EQUALITY caseIgnoreMatch 610 SUBSTR caseIgnoreSubstringsMatch 611 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 613 1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax 614 [Syntaxes]. 616 Example: "22180", to identify Vienna, VA in the USA. 618 2.25 'postOfficeBox' 620 The 'postOfficeBox' attribute type contains postal box identifiers 621 that a Postal Service uses when a customer arranges to receive mail 622 at a box on premises of the Postal Service. Each postal box 623 identifier is a single value of this multi-valued attribute. 624 (Source: X.520 [X.520]) 626 ( 2.5.4.18 NAME 'postOfficeBox' 627 EQUALITY caseIgnoreMatch 628 SUBSTR caseIgnoreSubstringsMatch 629 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 631 1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax 632 [Syntaxes]. 634 Example: "Box 45". 636 2.26 'preferredDeliveryMethod' 638 The 'preferredDeliveryMethod' attribute type contains an indication 639 of the preferred method of getting a message to the object. 640 (Source: X.520 [X.520]) 642 ( 2.5.4.28 NAME 'preferredDeliveryMethod' 643 SYNTAX 1.3.6.1.4.1.1466.115.121.1.14 644 SINGLE-VALUE ) 646 1.3.6.1.4.1.1466.115.121.1.14 refers to the Delivery Method syntax 647 [Syntaxes]. 649 Example: If the mhs-delivery Delivery Method is preferred over 650 telephone-delivery, which is preferred over all other 651 methods, the value would be: "mhs $ telephone". 653 2.27 'registeredAddress' 655 The 'registeredAddress' attribute type contains postal addresses 656 suitable for reception of telegrams or expedited documents, where it 657 is necessary to have the recipient accept delivery. Each address is 658 one value of this multi-valued attribute. 659 (Source: X.520 [X.520]) 661 ( 2.5.4.26 NAME 'registeredAddress' 662 SUP postalAddress 663 SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 ) 665 1.3.6.1.4.1.1466.115.121.1.41 refers to the Postal Address syntax 666 [Syntaxes]. 668 Example: "Receptionist$Widget, Inc.$15 Main St.$Ottawa$Canada". 670 2.28 'roleOccupant' 672 The 'roleOccupant' attribute type contains the Distinguished Names of 673 objects (normally people) that fulfill the responsibilities of a role 674 object. Each distinguished name is one value of this multi-valued 675 attribute. 676 (Source: X.520 [X.520]) 678 ( 2.5.4.33 NAME 'roleOccupant' 679 SUP distinguishedName ) 681 Example: The role object, "cn=Human Resources 682 Director,ou=Position,o=Widget\, Inc.", is fulfilled by two 683 people whose object names are "cn=Mary 684 Smith,ou=employee,o=Widget\, Inc." and "cn=James 685 Brown,ou=employee,o=Widget\, Inc.". The 'roleOccupant' 686 attribute will contain both of these distinguished names, 687 since they are the occupants of this role. 689 2.29 'searchGuide' 691 The 'searchGuide' attribute type contains sets of information for use 692 by clients in constructing search filters. It is superseded by 693 'enhancedSearchGuide', described above in section 2.9. Each set is 694 one value of this multi-valued attribute. 695 (Source: X.520 [X.520]) 697 ( 2.5.4.14 NAME 'searchGuide' 698 SYNTAX 1.3.6.1.4.1.1466.115.121.1.25 ) 700 1.3.6.1.4.1.1466.115.121.1.25 refers to the Guide syntax [Syntaxes]. 702 Example: "person#sn$EQ". 704 2.30 'seeAlso' 706 The 'seeAlso' attribute type contains Distinguished Names of objects 707 that are related to the subject object. Each related object name is 708 one value of this multi-valued attribute. 709 (Source: X.520 [X.520]) 711 ( 2.5.4.34 NAME 'seeAlso' 712 SUP distinguishedName ) 714 Example: The person object, "cn=James Brown,ou=employee,o=Widget\, 715 Inc." is related to the role objects, "cn=Football Team 716 Captain,ou=sponsored activities,o=Widget\, Inc." and 717 "cn=Chess Team,ou=sponsored activities,o=Widget\, Inc.". 719 Since the role objects are related to the person object, the 720 'seeAlso' attribute will contain the distinguished name of 721 each role object as separate values. 723 2.31 'serialNumber' 725 The 'serialNumber' attribute type contains the serial numbers of 726 devices. Each serial number is one value of this multi-valued 727 attribute. 728 (Source: X.520 [X.520]) 730 ( 2.5.4.5 NAME 'serialNumber' 731 EQUALITY caseIgnoreMatch 732 SUBSTR caseIgnoreSubstringsMatch 733 SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 ) 735 1.3.6.1.4.1.1466.115.121.1.44 refers to the Printable String syntax 736 [Syntaxes]. 738 Examples: "WI-3005" and "XF551426". 740 2.32 'sn' 742 The 'sn' ('surname' in X.500) attribute type contains name strings 743 for the family names of a person. Each string is one value of this 744 multi-valued attribute. 745 (Source: X.520 [X.520]) 747 ( 2.5.4.4 NAME 'sn' 748 SUP name ) 750 Example: "Smith". 752 2.33 'st' 754 The 'st' ('stateOrProvinceName' in X.500) attribute type contains the 755 full names of states or provinces. Each name is one value of this 756 multi-valued attribute. 757 (Source: X.520 [X.520]) 759 ( 2.5.4.8 NAME 'st' 760 SUP name ) 762 Example: "California". 764 2.34 'street' 766 The 'street' ('streetAddress' in X.500) attribute type contains site 767 information from a postal address (i.e., the street name, place, 768 avenue, and the house number.). Each street is one value of this 769 multi-valued attribute. 770 (Source: X.520 [X.520]) 772 ( 2.5.4.9 NAME 'street' 773 EQUALITY caseIgnoreMatch 774 SUBSTR caseIgnoreSubstringsMatch 775 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 777 1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax 778 [Syntaxes]. 780 Example: "15 Main St.". 782 2.35 'telephoneNumber' 784 The 'telephoneNumber' attribute type contains telephone numbers that 785 comply with the ITU Recommendation E.123 [E.123]. Each number is one 786 value of this multi-valued attribute. 787 (Source: X.520 [X.520]) 789 ( 2.5.4.20 NAME 'telephoneNumber' 790 EQUALITY telephoneNumberMatch 791 SUBSTR telephoneNumberSubstringsMatch 792 SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 ) 794 1.3.6.1.4.1.1466.115.121.1.50 refers to the Telephone Number syntax 795 [Syntaxes]. 797 Example: "+1 234 567 8901". 799 2.36 'teletexTerminalIdentifier' 801 The withdrawal of Rec. F.200 has resulted in the withdrawal of this 802 attribute. 803 (Source: X.520 [X.520]) 805 ( 2.5.4.22 NAME 'teletexTerminalIdentifier' 806 SYNTAX 1.3.6.1.4.1.1466.115.121.1.51 ) 808 1.3.6.1.4.1.1466.115.121.1.51 refers to the Teletex Terminal 809 Identifier syntax [Syntaxes]. 811 2.37 'telexNumber' 813 The 'telexNumber' attribute type contains sets of strings which are a 814 telex number, country code, and answerback code of a telex terminal. 815 Each set is one value of this multi-valued attribute. 816 (Source: X.520 [X.520]) 818 ( 2.5.4.21 NAME 'telexNumber' 819 SYNTAX 1.3.6.1.4.1.1466.115.121.1.52 ) 821 1.3.6.1.4.1.1466.115.121.1.52 refers to the Telex Number syntax 822 [Syntaxes]. 824 Example: "12345$023$ABCDE". 826 2.38 'title' 828 The 'title' attribute type contains the title of a person in their 829 organizational context. Each title is one value of this multi-valued 830 attribute. 831 (Source: X.520 [X.520]) 833 ( 2.5.4.12 NAME 'title' 834 SUP name ) 835 Examples: "Vice President", "Software Engineer" and "CEO". 837 2.39 'uid' 839 The 'uid' ('userid' in RFC 1274) attribute type contains computer 840 system login names associated with the object. Each name is one 841 value of this multi-valued attribute. 842 (Source: RFC 2798 [RFC2798] and RFC 1274 [RFC1274]) 844 ( 0.9.2342.19200300.100.1.1 NAME 'uid' 845 EQUALITY caseIgnoreMatch 846 SUBSTR caseIgnoreSubstringsMatch 847 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 849 1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax 850 [Syntaxes]. 852 Examples: "s9709015", "admin" and "Administrator". 854 2.40 'uniqueMember' 856 The 'uniqueMember' attribute type contains the Distinguished Names of 857 an object that is on a list or in a group, where the Relative 858 Distinguished Names of the object include a value that distinguishes 859 between objects when a distinguished name has been reused. Each 860 distinguished name is one value of this multi-valued attribute. 861 (Source: X.520 [X.520]) 863 ( 2.5.4.50 NAME 'uniqueMember' 864 EQUALITY uniqueMemberMatch 865 SYNTAX 1.3.6.1.4.1.1466.115.121.1.34 ) 867 1.3.6.1.4.1.1466.115.121.1.34 refers to the Name and Optional UID 868 syntax [Syntaxes]. 870 Example: If "ou=1st Battalion,o=Defense,c=US" is a battalion that was 871 disbanded, establishing a new battalion with the "same" name 872 would have a unique identifier value added, resulting in 873 "ou=1st Battalion, o=Defense,c=US#'010101'B". 875 2.41 'userPassword' 877 The 'userPassword' attribute contains octet strings that are known 878 only to the user and the system to which the user has access. Each 879 string is one value of this multi-valued attribute. 881 The application SHOULD prepare textual strings used as passwords by 882 transcoding them to Unicode, applying SASLprep [RFC4013], and 883 encoding as UTF-8. The determination of whether a password is 884 textual is a local client matter. 885 (Source: X.509 [X.509]) 887 ( 2.5.4.35 NAME 'userPassword' 888 EQUALITY octetStringMatch 889 SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 ) 891 1.3.6.1.4.1.1466.115.121.1.40 refers to the Octet String syntax 892 [Syntaxes]. 894 Passwords are stored using an Octet String syntax and are not 895 encrypted. Transfer of cleartext passwords is strongly discouraged 896 where the underlying transport service cannot guarantee 897 confidentiality and may result in disclosure of the password to 898 unauthorized parties. 900 An example of a need for multiple values in the 'userPassword' 901 attribute is an environment where every month the user was expected 902 to use a different password generated by some automated system. 903 During transitional periods, like the last and first day of the 904 periods, it may be necessary to allow two passwords for the two 905 consecutive periods to be valid in the system. 907 2.42 'x121Address' 909 The 'x121Address' attribute type contains data network addresses as 910 defined by ITU Recommendation X.121 [X.121]. Each address is one 911 value of this multi-valued attribute. 912 (Source: X.520 [X.520]) 914 ( 2.5.4.24 NAME 'x121Address' 915 EQUALITY numericStringMatch 916 SUBSTR numericStringSubstringsMatch 917 SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 ) 919 1.3.6.1.4.1.1466.115.121.1.36 refers to the Numeric String syntax 920 [Syntaxes]. 922 Example: "36111222333444555". 924 2.43 'x500UniqueIdentifier' 926 The 'x500UniqueIdentifier' attribute type contains binary strings 927 that are used to distinguish between objects when a distinguished 928 name has been reused. Each string is one value of this multi-valued 929 attribute. 930 In X.520 [X.520], this attribute type is called 'uniqueIdentifier'. 931 This is a different attribute type from both the 'uid' and 932 'uniqueIdentifier' LDAP attribute types. The 'uniqueIdentifier' 933 attribute type is defined in [RFC1274]. 934 (Source: X.520 [X.520]) 936 ( 2.5.4.45 NAME 'x500UniqueIdentifier' 937 EQUALITY bitStringMatch 938 SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 ) 940 1.3.6.1.4.1.1466.115.121.1.6 refers to the Bit String syntax 941 [Syntaxes]. 943 3. Object Classes 945 LDAP servers SHOULD recognize all the Object Classes listed here as 946 values of the 'objectClass' attribute (see [Models]). 948 3.1 'applicationProcess' 950 The 'applicationProcess' object class definition is the basis of an 951 entry which represents an application executing in a computer system. 952 (Source: X.521 [X.521]) 954 ( 2.5.6.11 NAME 'applicationProcess' 955 SUP top 956 STRUCTURAL 957 MUST cn 958 MAY ( seeAlso $ 959 ou $ 960 l $ 961 description ) ) 963 3.2 'country' 965 The 'country' object class definition is the basis of an entry which 966 represents a country. 967 (Source: X.521 [X.521]) 969 ( 2.5.6.2 NAME 'country' 970 SUP top 971 STRUCTURAL 972 MUST c 973 MAY ( searchGuide $ 974 description ) ) 976 3.3 'dcObject' 978 The 'dcObject' object class permits an entry to contains domain 979 component information. This object class is defined as auxiliary, 980 because it will be used in conjunction with an existing structural 981 object class. 982 (Source: RFC 2247 [RFC2247]) 984 ( 1.3.6.1.4.1.1466.344 NAME 'dcObject' 985 SUP top 986 AUXILIARY 987 MUST dc ) 989 3.4 'device' 991 The 'device' object class is the basis of an entry which represents 992 an appliance, computer or network element. 993 (Source: X.521 [X.521]) 995 ( 2.5.6.14 NAME 'device' 996 SUP top 997 STRUCTURAL 998 MUST cn 999 MAY ( serialNumber $ 1000 seeAlso $ 1001 owner $ 1002 ou $ 1003 o $ 1004 l $ 1005 description ) ) 1007 3.5 'groupOfNames' 1009 The 'groupOfNames' object class is the basis of an entry which 1010 represents a set of named objects including information related to 1011 the purpose or maintenance of the set. 1012 (Source: X.521 [X.521]) 1014 ( 2.5.6.9 NAME 'groupOfNames' 1015 SUP top 1016 STRUCTURAL 1017 MUST ( member $ 1018 cn ) 1019 MAY ( businessCategory $ 1020 seeAlso $ 1021 owner $ 1022 ou $ 1023 o $ 1024 description ) ) 1026 3.6 'groupOfUniqueNames' 1028 The 'groupOfUniqueNames' object class is the same as the 1029 'groupOfNames' object class except that the object names are not 1030 repeated or reassigned within a set scope. 1031 (Source: X.521 [X.521]) 1033 ( 2.5.6.17 NAME 'groupOfUniqueNames' 1034 SUP top 1035 STRUCTURAL 1036 MUST ( uniqueMember $ 1037 cn ) 1038 MAY ( businessCategory $ 1039 seeAlso $ 1040 owner $ 1041 ou $ 1042 o $ 1043 description ) ) 1045 3.7 'locality' 1047 The 'locality' object class is the basis of an entry which represents 1048 a place in the physical world. 1049 (Source: X.521 [X.521]) 1051 ( 2.5.6.3 NAME 'locality' 1052 SUP top 1053 STRUCTURAL 1054 MAY ( street $ 1055 seeAlso $ 1056 searchGuide $ 1057 st $ 1058 l $ 1059 description ) ) 1061 3.8 'organization' 1063 The 'organization' object class is the basis of an entry which 1064 represents a structured group of people. 1065 (Source: X.521 [X.521]) 1067 ( 2.5.6.4 NAME 'organization' 1068 SUP top 1069 STRUCTURAL 1070 MUST o 1071 MAY ( userPassword $ searchGuide $ seeAlso $ 1072 businessCategory $ x121Address $ registeredAddress $ 1073 destinationIndicator $ preferredDeliveryMethod $ 1074 telexNumber $ teletexTerminalIdentifier $ 1075 telephoneNumber $ internationaliSDNNumber $ 1076 facsimileTelephoneNumber $ street $ postOfficeBox $ 1077 postalCode $ postalAddress $ physicalDeliveryOfficeName $ 1078 st $ l $ description ) ) 1080 3.9 'organizationalPerson' 1082 The 'organizationalPerson' object class is the basis of an entry 1083 which represents a person in relation to an organization. 1084 (Source: X.521 [X.521]) 1085 ( 2.5.6.7 NAME 'organizationalPerson' 1086 SUP person 1087 STRUCTURAL 1088 MAY ( title $ x121Address $ registeredAddress $ 1089 destinationIndicator $ preferredDeliveryMethod $ 1090 telexNumber $ teletexTerminalIdentifier $ 1091 telephoneNumber $ internationaliSDNNumber $ 1092 facsimileTelephoneNumber $ street $ postOfficeBox $ 1093 postalCode $ postalAddress $ physicalDeliveryOfficeName $ 1094 ou $ st $ l ) ) 1096 3.10 'organizationalRole' 1098 The 'organizationalRole' object class is the basis of an entry which 1099 represents a job, function or position in an organization. 1100 (Source: X.521 [X.521]) 1102 ( 2.5.6.8 NAME 'organizationalRole' 1103 SUP top 1104 STRUCTURAL 1105 MUST cn 1106 MAY ( x121Address $ registeredAddress $ destinationIndicator $ 1107 preferredDeliveryMethod $ telexNumber $ 1108 teletexTerminalIdentifier $ telephoneNumber $ 1109 internationaliSDNNumber $ facsimileTelephoneNumber $ 1110 seeAlso $ roleOccupant $ preferredDeliveryMethod $ 1111 street $ postOfficeBox $ postalCode $ postalAddress $ 1112 physicalDeliveryOfficeName $ ou $ st $ l $ 1113 description ) ) 1115 3.11 'organizationalUnit' 1117 The 'organizationalUnit' object class is the basis of an entry which 1118 represents a piece of an organization. 1119 (Source: X.521 [X.521]) 1121 ( 2.5.6.5 NAME 'organizationalUnit' 1122 SUP top 1123 STRUCTURAL 1124 MUST ou 1125 MAY ( businessCategory $ description $ destinationIndicator $ 1126 facsimileTelephoneNumber $ internationaliSDNNumber $ l $ 1127 physicalDeliveryOfficeName $ postalAddress $ postalCode $ 1128 postOfficeBox $ preferredDeliveryMethod $ 1129 registeredAddress $ searchGuide $ seeAlso $ st $ street $ 1130 telephoneNumber $ teletexTerminalIdentifier $ 1131 telexNumber $ userPassword $ x121Address ) ) 1133 3.12 'person' 1135 The 'person' object class is the basis of an entry which represents a 1136 human being. 1137 (Source: X.521 [X.521]) 1139 ( 2.5.6.6 NAME 'person' 1140 SUP top 1141 STRUCTURAL 1142 MUST ( sn $ 1143 cn ) 1144 MAY ( userPassword $ 1145 telephoneNumber $ 1146 seeAlso $ description ) ) 1148 3.13 'residentialPerson' 1150 The 'residentialPerson' object class is the basis of an entry which 1151 includes a person's residence in the representation of the person. 1152 (Source: X.521 [X.521]) 1154 ( 2.5.6.10 NAME 'residentialPerson' 1155 SUP person 1156 STRUCTURAL 1157 MUST l 1158 MAY ( businessCategory $ x121Address $ registeredAddress $ 1159 destinationIndicator $ preferredDeliveryMethod $ 1160 telexNumber $ teletexTerminalIdentifier $ 1161 telephoneNumber $ internationaliSDNNumber $ 1162 facsimileTelephoneNumber $ preferredDeliveryMethod $ 1163 street $ postOfficeBox $ postalCode $ postalAddress $ 1164 physicalDeliveryOfficeName $ st $ l ) ) 1166 3.14 'uidObject' 1168 The 'uidObject' object class permits an entry to contains user 1169 identification information. This object class is defined as 1170 auxiliary, because it will be used in conjunction with an existing 1171 structural object class. 1172 (Source: RFC 2377 [RFC2377]) 1174 ( 1.3.6.1.1.3.1 NAME 'uidObject' 1175 SUP top 1176 AUXILIARY 1177 MUST uid ) 1179 4. IANA Considerations 1181 It is requested that the Internet Assigned Numbers Authority (IANA) 1182 update the LDAP descriptors registry as indicated in the following 1183 template: 1185 Subject: Request for LDAP Descriptor Registration Update 1186 Descriptor (short name): see comment 1187 Object Identifier: see comment 1188 Person & email address to contact for further information: 1189 Andrew Sciberras 1190 Usage: (A = attribute type, O = Object Class) see comment 1191 Specification: RFC XXXX [editor's note: The RFC number will be 1192 the one assigned to this document.] 1193 Author/Change Controller: IESG 1194 Comments 1195 In the LDAP descriptors registry, the following descriptors (short 1196 names) should be updated to refer to RFC XXXX [editor's note: This 1197 document]. Names that need to be reserved, rather than assigned to 1198 an Object Identifier, will contain an Object Identifier value of 1199 RESERVED. 1201 NAME Type OID 1202 ------------------------ ---- ---------------------------- 1203 applicationProcess O 2.5.6.11 1204 businessCategory A 2.5.4.15 1205 c A 2.5.4.6 1206 cn A 2.5.4.3 1207 commonName A 2.5.4.3 1208 country O 2.5.6.2 1209 countryName A 2.5.4.6 1210 DC A 0.9.2342.19200300.100.1.25 1211 dcObject O 1.3.6.1.4.1.1466.344 1212 description A 2.5.4.13 1213 destinationIndicator A 2.5.4.27 1214 device O 2.5.6.14 1215 distinguishedName A 2.5.4.49 1216 dnQualifier A 2.5.4.46 1217 domainComponent A 0.9.2342.19200300.100.1.25 1218 enhancedSearchGuide A 2.5.4.47 1219 facsimileTelephoneNumber A 2.5.4.23 1220 generationQualifier A 2.5.4.44 1221 givenName A 2.5.4.42 1222 GN A RESERVED 1223 groupOfNames O 2.5.6.9 1224 groupOfUniqueNames O 2.5.6.17 1225 houseIdentifier A 2.5.4.51 1226 initials A 2.5.4.43 1227 internationalISDNNumber A 2.5.4.25 1228 L A 2.5.4.7 1229 locality O 2.5.6.3 1230 localityName A 2.5.4.7 1231 member A 2.5.4.31 1232 name A 2.5.4.41 1233 o A 2.5.4.10 1234 organization O 2.5.6.4 1235 organizationName A 2.5.4.10 1236 organizationalPerson O 2.5.6.7 1237 organizationalRole O 2.5.6.8 1238 organizationalUnit O 2.5.6.5 1239 organizationalUnitName A 2.5.4.11 1240 ou A 2.5.4.11 1241 owner A 2.5.4.32 1242 person O 2.5.6.6 1243 physicalDeliveryOfficeName A 2.5.4.19 1244 postalAddress A 2.5.4.16 1245 postalCode A 2.5.4.17 1246 postOfficeBox A 2.5.4.18 1247 preferredDeliveryMethod A 2.5.4.28 1248 registeredAddress A 2.5.4.26 1249 residentialPerson O 2.5.6.10 1250 roleOccupant A 2.5.4.33 1251 searchGuide A 2.5.4.14 1252 seeAlso A 2.5.4.34 1253 serialNumber A 2.5.4.5 1254 sn A 2.5.4.4 1255 st A 2.5.4.8 1256 street A 2.5.4.9 1257 surname A 2.5.4.4 1258 telephoneNumber A 2.5.4.20 1259 teletexTerminalIdentifier A 2.5.4.22 1260 telexNumber A 2.5.4.21 1261 title A 2.5.4.12 1262 uid A 0.9.2342.19200300.100.1.1 1263 uidObject O 1.3.6.1.1.3.1 1264 uniqueMember A 2.5.4.50 1265 userId A 0.9.2342.19200300.100.1.1 1266 userPassword A 2.5.4.35 1267 x121Address A 2.5.4.24 1268 x500UniqueIdentifier A 2.5.4.45 1270 5. Security Considerations 1272 Attributes of directory entries are used to provide descriptive 1273 information about the real-world objects they represent, which can be 1274 people, organizations or devices. Most countries have privacy laws 1275 regarding the publication of information about people. 1277 Transfer of cleartext passwords is strongly discouraged where the 1278 underlying transport service cannot guarantee confidentiality and 1279 integrity, since this may result in disclosure of the password to 1280 unauthorized parties. 1282 Multiple attribute values for the 'userPassword' attribute need to be 1283 used with care. Especially reset/deletion of a password by an admin 1284 without knowing the old user password gets tricky or impossible if 1285 multiple values for different applications are present. 1287 Certainly, applications which intend to replace the 'userPassword' 1288 value(s) with new value(s) should use modify/replaceValues (or 1289 modify/deleteAttribute+addAttribute). Additionally, server 1290 implementations are encouraged to provide administrative controls 1291 which, if enabled, restrict the 'userPassword' attribute to one 1292 value. 1294 Note that when used for authentication purposes [AuthMeth], the user 1295 need only prove knowledge of one of the values, not all of the 1296 values. 1298 6. Acknowledgements 1300 The definitions, on which this document is based, have been developed 1301 by committees for telecommunications and international standards. 1303 This document is an update of RFC 2256 by Mark Wahl. RFC 2256 was a 1304 product of the IETF ASID Working Group. 1306 The 'dc' attribute type definition and the 'dcObject' object class 1307 definition in this document supersede the specification in RFC 2247 1308 by S. Kille, M. Wahl, A. Grimstad, R. Huber, and S. Sataluri. 1310 The 'uid' attribute type definition in this document supersedes the 1311 specification of the 'userid' in RFC 1274 by P. Barker and S. Kille 1312 and of the uid in RFC 2798 by M. Smith. 1314 The 'uidObject' object class definition in this document supersedes 1315 the specification of the 'uidObject' in RFC 2377 by A. Grimstad, R. 1316 Huber, S. Sataluri and M. Smith. 1318 This document is based upon input of the IETF LDAPBIS working group. 1319 The author wishes to thank S. Legg and K. Zeilenga for their 1320 significant contribution to this update. The author would also like 1321 to thank Kathy Dally who edited early drafts of this document. 1323 7. References 1325 7.1 Normative 1327 [E.123] Notation for national and international telephone 1328 numbers, ITU-T Recommendation E.123, 1988 1330 [E.164] The international public telecommunication numbering 1331 plan, ITU-T Recommendation E.164, 1997 1333 [F.1] Operational Provisions For The International Public 1334 Telegram Service Transmission System, CCITT 1335 Recommendation F.1, 1992 1337 [F.31] Telegram Retransmission System, CCITT Recommendation 1338 F.31, 1988 1340 [ISO3166] ISO 3166, "Codes for the representation of names of 1341 countries". 1343 [Models] K. Zeilenga, "LDAP: The Models", draft-ietf-ldapbis- 1344 models-xx (a work in progress) 1346 [RFC1034] P. Mockapetris, " DOMAIN NAMES - CONCEPTS AND 1347 FACILITIES", RFC 1034, January 1987 1349 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1350 Requirement Levels", RFC 2119, March 1997 1352 [RFC3490] Faltstrom P., Hoffman P., Costello A., 1353 "Internationalizing Domain Names in Applications 1354 (IDNA)", RFC 3490, March 2003 1356 [RFC4013] Zeilenga K., "SASLprep: Stringprep profile for User 1357 Names and Passwords", RFC 4013, February 2005. 1359 [RFC4234] Crocker, D., Overell P., "Augmented BNF for Syntax 1360 Specifications: ABNF", RFC 4234, October 2005 1362 [Roadmap] Zeilenga, K., "LDAP: Technical Specification Road 1363 Map", draft-ietf-ldapbis-roadmap-xx (a work in 1364 progress) 1366 [Syntaxes] S. Legg (editor), "LDAP: Syntaxes", draft-ietf-ldapbis- 1367 syntaxes-xx (a work in progress) 1369 [X.121] International numbering plan for public data networks, 1370 ITU-T Recommendation X.121, 1996 1372 [X.509] The Directory: Authentication Framework, ITU-T 1373 Recommendation X.509, 1993 1375 [X.520] The Directory: Selected Attribute Types, ITU-T 1376 Recommendation X.520, 1993 1378 [X.521] The Directory: Selected Object Classes. ITU-T 1379 Recommendation X.521, 1993 1381 7.2 Informative 1383 [AuthMeth] Harrison R., "LDAP: Authentication Methods and 1384 Connection Level Security Mechanisms", draft-ietf- 1385 ldapbis-authmeth-xx (a work in progress) 1387 [LDAP-PKI] Zeilenga, K., "Lightweight Directory Access Protocol 1388 (LDAP) schema definitions for X.509 Certificates", 1389 draft-zeilenga-ldap-x509-xx (a work in progress) 1391 [RFC1274] Barker, P., Kille, S.,"The COSINE and Internet X.500 1392 Schema", RFC 1274, November 1991 1394 [RFC2247] Kille, S., Wahl, M., Grimstad, A., Huber, R., and 1395 Sataluri, S., "Using Domains in LDAP/X.500 1396 Distinguished Names", RFC 2247, January 1998 1398 [RFC2377] Grimstad, A., Huber, R., Sataluri, S., and Wahl, M., 1399 "Naming Plan for Internet-Enabled Applications", RFC 1400 2377, September 1998. 1402 [RFC2798] Smith, M., "Definition of the inetOrgPerson LDAP Object 1403 Class", RFC 2798, April 2000 1405 [X.500] ITU-T Recommendations X.500 (1993) | ISO/IEC 1406 9594-1:1994, Information Technology - Open Systems 1407 Interconnection - The Directory: Overview of concepts, 1408 models and services. 1410 8. Author's Address 1412 Andrew Sciberras 1413 eB2Bcom 1414 Suite 3, Woodhouse Corporate Centre, 1415 935 Station Street, 1416 Box Hill North, Victoria 3129 1417 AUSTRALIA 1419 Phone: +61 3 9896 7833 1420 Email: andrew.sciberras@eb2bcom.com 1422 9. Intellectual Property Statement 1424 The IETF takes no position regarding the validity or scope of any 1425 Intellectual Property Rights or other rights that might be claimed to 1426 pertain to the implementation or use of the technology described in 1427 this document or the extent to which any license under such rights 1428 might or might not be available; nor does it represent that it has 1429 made any independent effort to identify any such rights. Information 1430 on the procedures with respect to rights in RFC documents can be 1431 found in BCP 78 and BCP 79. 1433 Copies of IPR disclosures made to the IETF Secretariat and any 1434 assurances of licenses to be made available, or the result of an 1435 attempt made to obtain a general license or permission for the use of 1436 such proprietary rights by implementers or users of this 1437 specification can be obtained from the IETF on-line IPR repository at 1438 http://www.ietf.org/ipr. 1440 The IETF invites any interested party to bring to its attention any 1441 copyrights, patents or patent applications, or other proprietary 1442 rights that may cover technology that may be required to implement 1443 this standard. Please address the information to the IETF at 1444 ietf-ipr@ietf.org. 1446 10. Full Copyright Statement 1448 Copyright (C) The Internet Society (2006). 1450 This document is subject to the rights, licenses and restrictions 1451 contained in BCP 78, and except as set forth therein, the authors 1452 retain all their rights. 1454 This document and the information contained herein are provided on an 1455 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1456 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1457 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1458 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1459 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1460 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1462 Appendix A Changes Made Since RFC 2256 1464 This appendix lists the changes that have been made from RFC 2256 to 1465 this I-D. 1467 This appendix is not a normative part of this specification, which 1468 has been provided for informational purposes only. 1470 1. Replaced the document title. 1472 2. Removed the IESG Note. 1474 3. Dependencies on RFC 1274 have been eliminated. 1476 4. Added a Security Considerations section and an IANA 1477 considerations section. 1479 5. Deleted the conformance requirement for subschema object 1480 classes in favor of a statement in [Syntaxes]. 1482 6. Added explanation to attribute types and to each object class. 1484 7. Removed Section 4, Syntaxes, and Section 6, Matching Rules, 1485 (moved to [Syntaxes]). 1487 8. Removed the certificate-related attribute types: 1488 authorityRevocationList, cACertificate, 1489 certificateRevocationList, crossCertificatePair, 1490 deltaRevocationList, supportedAlgorithms, and userCertificate. 1492 Removed the certificate-related Object Classes: 1493 certificationAuthority, certificationAuthority-V2, 1494 cRLDistributionPoint, strongAuthenticationUser, and 1495 userSecurityInformation 1497 LDAP PKI is now discussed in [LDAP-CRL] and [LDAP-CERT]. 1499 9. Removed the dmdName, knowledgeInformation, 1500 presentationAddress, protocolInformation, and 1501 supportedApplicationContext attribute types and the dmd, 1502 applicationEntity, and dSA object classes. 1504 10. Deleted the aliasedObjectName and objectClass attribute type 1505 definitions. Deleted the alias and top object class 1506 definitions. They are included in [Models]. 1508 11. Added the 'dc' attribute type from RFC 2247. 1510 12. Numerous edititorial changes. 1512 13. Removed upper bound after the SYNTAX oid in all attribute 1513 definitions where it appeared. 1515 14. Added text about Unicode, SASLprep and UTF-8 for userPassword. 1517 changes since 07: 1519 15. Corrected examples in preferredDeliveryMethod, uniqueMember, 1520 postalAddress, and registeredAddress attribute types. 1522 16. Clarified and corrected examples in owner and roleOccupant 1523 attribute types. 1525 17. Added RFC 2234 to normative references. 1527 18. Added RFC 1274 and RFC 2798 to informative references. 1529 19. Removed the statement about RFC 2026 conformance. 1531 20. Added the IPR Disclosure and Notice 1533 21. Updated the Copyright text. 1535 changes since 08: 1537 22. Included RFC 2377 into Updates header and Informative 1538 References 1540 23. Changed Editor information to Andrew Sciberras. 1542 24. Updated I-D Template information. 1544 25. References made consistent with other LDAPbis ID's. [ROADMAP] 1545 -> [RoadMap] and [AUTHMETH] -> [AuthMeth]. 1547 26. Changed Introduction to include an (LDAP) acronym after the 1548 first usage. 1550 27. Renamed section 1.1 to "Relationship with other 1551 specifications" from "Situation". 1553 28. Included definitions, comments and references for 'dcObject' 1554 and 'uidObject'. 1556 29. Replaced PKI schema references to use draft-zeilenga-ldap- 1557 x509-xx 1559 30. Spelt out and referenced ABNF on first usage. 1561 31. Removed Section 2.4 (Source). Replaced the source table with 1562 explicit references for each definition. 1564 32. All references to an attribute type or object class are 1565 enclosed in single quotes. 1567 33. The layout of attribute type definitions has been changed to 1568 provide consistency throughout the document: 1569 > Section Heading 1570 > Description of Attribute type 1571 > Multivalued description 1572 > Source Information 1573 > Definition 1574 > Example 1575 > Additional Comments 1577 Adding this consistent output included the addition of 1578 examples to some definitions. 1580 34. References to alternate names for attributes types are 1581 provided with a reference to where they were originally 1582 specified. 1584 35. Clarification of the description of 'distinguishedName' and 1585 'name', in regards to these attribute types being supertypes. 1587 36. Spelt out ISDN on first usage. 1589 37. Inserted a reference to [Syntaxes] for the 1590 'teletexTerminalIdentifier' definition's SYNTAX OID. 1592 38. Additional names were added to the IANA Considerations. Names 1593 include 'commonName', 'dcObject', 'domainComponent', 'GN', 1594 'localityName', 'organizationName', 'organizationUnitName', 1595 'surname', 'uidObject' and 'userid'. 1597 39. Renamed all instances of supercede to supersede. 1599 40. Moved [F.1], [F.30] and [SASLprep] from informative to 1600 normative references. 1602 41. Changed the 'c' definition to be consistent with X.500. 1604 42. Added text to 'dc', making the distinction between 'stored' 1605 and 'query' values when preparing IDN strings.