idnits 2.17.1 draft-smith-ldap-inetorgperson-00.txt: ** The Abstract section seems to be numbered 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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** 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. ** 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.) ** There are 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([X500]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 121: '...s attribute type MUST conform to the d...' RFC 2119 keyword, line 169: '... MAY (...' RFC 2119 keyword, line 184: '... MUST (...' RFC 2119 keyword, line 187: '... MAY (...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 259 has weird spacing: '...for the purpo...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (11 March 1998) is 9514 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Missing reference section? 'X500' on line 40 looks like a reference -- Missing reference section? 'RFC2251' on line 279 looks like a reference -- Missing reference section? 'RFC2252' on line 283 looks like a reference -- Missing reference section? 'RFC2256' on line 288 looks like a reference -- Missing reference section? 'RFC2079' on line 305 looks like a reference -- Missing reference section? 'RFC2068' on line 301 looks like a reference -- Missing reference section? 'RFC1847' on line 296 looks like a reference -- Missing reference section? 'PKCS12' on line 310 looks like a reference -- Missing reference section? 'LDIF' on line 200 looks like a reference Summary: 11 errors (**), 0 flaws (~~), 2 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 The LDAP inetOrgPerson Object Class Mark Smith 3 INTERNET-DRAFT Netscape Communications 4 Intended Category: Informational 11 March 1998 5 Expires: 11 September 1998 7 Definition of the inetOrgPerson LDAP Object Class 8 Filename: draft-smith-ldap-inetorgperson-00.txt 10 1. Status of this Memo 12 This draft document will be submitted to the RFC Editor as an Informa- 13 tional document. Distribution of this memo is unlimited. Please send 14 comments to the author . 16 This document is an Internet-Draft. Internet-Drafts are working docu- 17 ments of the Internet Engineering Task Force (IETF), its areas, and its 18 working groups. Note that other groups may also distribute working 19 documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference material 24 or to cite them other than as ``work in progress.'' 26 To learn the current status of any Internet-Draft, please check the 27 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 28 Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), 29 ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 31 Copyright (C) The Internet Society (1998). All Rights Reserved. 33 Please see the Copyright section near the end of this document for more 34 information. 36 This Internet Draft expires on 11 September 1998. 38 2. Abstract 40 While the X.500 standards [X500] define many useful attribute types and 41 object classes, they do not define a person object class that meets the 42 requirements found in today's Internet and Intranet directory service 43 deployments. We define a new object class called inetOrgPerson for use 44 in LDAP and X.500 directory services that extends the X.521 standard 45 organizationalPerson class to meet these needs. 47 3. Background and Intended Usage 49 The inetOrgPerson object class is a general purpose object class that 50 holds attributes about people. The attributes it holds were chosen to 51 accommodate information requirements found in typical Internet and 52 Intranet directory service deployments. The inetOrgPerson object class 53 is designed to be used within directory services based on the LDAP 54 [RFC2251] and the X.500 family of protocols, and it should be useful in 55 other contexts as well. 57 The attribute type and object class definitions are written using the 58 BNF form of AttributeTypeDescription and ObjectClassDescription given in 59 [RFC2252]. Lines have been folded for readability. 61 Attributes that are referenced but not defined in this document are 62 included in the standard and pilot attribute definitions [RFC2256] or in 63 the labeledURI object class [RFC2079] 65 4. New Attribute Types Used in the inetOrgPerson Object Class 67 4.1. Vehicle license plate tag. 69 This multivalued field is used to record the license plate tags associ- 70 ated with an individual. 72 ( 2.16.840.1.113730.3.1.1 73 NAME 'carLicense' 74 DESC 'vehicle license plate tag' 75 EQUALITY caseIgnoreMatch 76 SUBSTRINGS caseIgnoreSubstringsMatch 77 SYNTAX 'DirectoryString' 78 ) 80 4.2. Department number 82 Code for department to which a person belongs. This can also be 83 strictly numeric (e.g., 1234) or alphanumeric (e.g., ABC/123). 84 ( 2.16.840.1.113730.3.1.2 85 NAME 'departmentNumber' 86 DESC 'identifies a department within an organization' 87 EQUALITY caseIgnoreMatch 88 SUBSTRINGS caseIgnoreSubstringsMatch 89 SYNTAX 'DirectoryString' 90 ) 91 4.3. Employee Number 93 Numeric or alphanumeric identifier assigned to a person, typically based 94 on order of hire or association with an organization. Single valued. 95 ( 2.16.840.1.113730.3.1.3 96 NAME 'employeeNumber' 97 DESC 'numerically identifies an employee within an organization' 98 EQUALITY caseIgnoreMatch 99 SUBSTRINGS caseIgnoreSubstringsMatch 100 SYNTAX 'DirectoryString' 101 SINGLE-VALUE 102 ) 104 4.4. Employee Type 106 Used to identify the employer to employee relationship. Typical values 107 used will be "Contractor", "Employee", "Intern", "Temp", "External", and 108 "Unknown" but any value may be used. 109 ( 2.16.840.1.113730.3.1.4 110 NAME 'employeeType' 111 DESC 'a person's type of employment' 112 EQUALITY caseIgnoreMatch 113 SUBSTRINGS caseIgnoreSubstringsMatch 114 SYNTAX 'DirectoryString' 115 ) 117 4.5. Preferred Language 119 Used to indicate an individual's preferred written or spoken language. 120 This is useful for international correspondence or human-computer 121 interaction. Values for this attribute type MUST conform to the defini- 122 tion of the Accept-Language header field defined in [RFC2068] with one 123 exception: the sequence "Accept-Language" ":" should be omitted. This 124 is a single valued attribute type. 125 ( 2.16.840.1.113730.3.1.39 126 NAME 'preferredLanguage' 127 DESC 'a person's preferred written or spoken language' 128 EQUALITY caseIgnoreMatch 129 SUBSTRINGS caseIgnoreSubstringsMatch 130 SYNTAX 'DirectoryString' 131 SINGLE-VALUE 132 ) 133 4.6. User S/MIME Certificate 135 S/MIME [RFC1847] signed message with a zero-length body. This attribute 136 is to be stored and requested in binary form, as 137 'userSMIMECertificate;binary'. It contains the person's entire certifi- 138 cate chain and the signed attribute that describes their algorithm capa- 139 bilities, stored as an octetString. If available, this attribute is 140 preferred over the userCertificate attribute for S/MIME applications. 141 ( 2.16.840.1.113730.3.1.40 142 NAME 'userSMIMECertificate' 143 DESC 'signed message used to support S/MIME" 144 SYNTAX 'octetString' 145 ) 147 4.7. User PKCS #12 149 PKCS #12 [PKCS12] provides a format for exchange of personal identity 150 information. When such information is stored in a directory service, 151 the userPKCS12 attribute should be used. This attribute is to be stored 152 and requested in binary form, as 'userPKCS12;binary'. The attribute 153 values are PFX PDUs stored as octetStrings. 154 ( 2.16.840.1.113730.3.1.216 155 NAME 'userPKCS12' 156 DESC 'PKCS #12 PFX PDU for exchange of personal identity information' 157 SYNTAX 'octetString' 158 ) 160 5. Definition of the inetOrgPerson Object Class 162 The inetOrgPerson represents people who are associated with an organiza- 163 tion in some way. It is a structural class and is derived from the 164 organizationalPerson class. 165 ( 2.16.840.1.113730.3.2.2 166 NAME 'inetOrgPerson' 167 SUP organizationalPerson 168 STRUCTURAL 169 MAY ( 170 audio $ businessCategory $ carLicense $ departmentNumber $ 171 employeeNumber $ employeeType $ givenName $ homePhone $ 172 homePostalAddress $ initials $ jpegPhoto $ labeledURI $ 173 mail $ manager $ mobile $ pager $ 174 photo $ roomNumber $ secretary $ uid $ userCertificate $ 175 x500uniqueIdentifier $ preferredLanguage $ userSMIMECertificate $ 176 userPKCS12 177 ) 179 ) 181 For reference, we list the following additional attribute types which 182 are inherited from organizationalPerson (which in turn is derived from 183 the person object class): 184 MUST ( 185 objectClass $ sn $ cn 186 ) 187 MAY ( 188 description $ seeAlso $ telephoneNumber $ userPassword $ 189 destinationIndicator $ facsimileTelephoneNumber $ 190 internationaliSDNNumber $ l $ ou $ 191 physicalDeliveryOfficeName $ postOfficeBox $ postalAddress $ 192 postalCode $ preferredDeliveryMethod $ registeredAddress $ 193 st $ street $ telephoneNumber $ teletexTerminalIdentifier $ 194 telexNumber $ title $ x121Address $ 195 ) 197 6. Example of an inetOrgPerson Entry 199 The following example is expressed using the LDIF notation defined in 200 [LDIF]. 202 dn: cn=Barbara Jensen, ou=Product Development, o=Ace Industry, c=US 203 objectClass: top 204 objectClass: person 205 objectClass: organizationalPerson 206 objectClass: inetOrgPerson 207 cn: Barbara Jensen 208 cn: Babs Jensen 209 sn: Jensen 210 givenName: Barbara 211 initials: BJJ 212 title: manager, product development 213 uid: bjensen 214 mail: bjensen@aceindustry.com 215 telephoneNumber: +1 408 555 1862 216 facsimileTelephoneNumber: +1 408 555 1992 217 mobile: +1 408 555 1941 218 roomNumber: 0209 219 carLicense: 6ABC246 220 departmentNumber: 2604 221 employeeNumber: 42 222 employeeType: full time 223 preferredLanguage: fr, en-gb;q=0.8, en;q=0.7 224 labeledURI: http://www.aceindustry.com/users/bjensen My Home Page 225 7. Security Considerations 227 Attributes of directory entries are used to provide descriptive informa- 228 tion about the real-world objects they represent, which can be people, 229 organizations or devices. Most countries have privacy laws regarding 230 the publication of information about people. 232 Transfer of cleartext passwords are strongly discouraged where the 233 underlying transport service cannot guarantee confidentiality and may 234 result in disclosure of the password to unauthorized parties. 236 8. Acknowledgments 238 The Netscape Directory Server team created the inetOrgPerson object 239 class based on experience and customer requirements. Anil Bhavnani and 240 John Kristian in particular deserve credit for all of the early design 241 work. 243 Many members of the Internet community, in particular those in the IETF 244 ASID and LDAPEXT groups, also contributed to the design of this object 245 class. 247 9. Copyright 249 Copyright (C) The Internet Society (1998). All Rights Reserved. 251 This document and translations of it may be copied and furnished to oth- 252 ers, and derivative works that comment on or otherwise explain it or 253 assist in its implementation may be prepared, copied, published and dis- 254 tributed, in whole or in part, without restriction of any kind, provided 255 that the above copyright notice and this paragraph are included on all 256 such copies and derivative works. However, this document itself may not 257 be modified in any way, such as by removing the copyright notice or 258 references to the Internet Society or other Internet organizations, 259 except as needed for the purpose of developing Internet standards in 260 which case the procedures for copyrights defined in the Internet Stan- 261 dards process must be followed, or as required to translate it into 262 languages other than English. 264 The limited permissions granted above are perpetual and will not be 265 revoked by the Internet Society or its successors or assigns. 267 This document and the information contained herein is provided on an "AS 268 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 269 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 270 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 271 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FIT- 272 NESS FOR A PARTICULAR PURPOSE. 274 10. Bibliography 276 [X500]ITU-T Rec. X.500, "The Directory: Overview of Concepts, Models and 277 Service", 1993. 279 [RFC2251] 280 M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access Protocol 281 (v3)", RFC 2251, December 1997. 283 [RFC2252] 284 M. Wahl, A. Coulbeck, T. Howes, S. Kille, W. Yeong, C. Robbins, 285 "Lightweight Directory Access Protocol (v3): Attribute Syntax 286 Definitions", RFC 2252, December 1997. 288 [RFC2256] 289 M. Wahl, "A Summary of the X.500(96) User Schema for use with 290 LDAPv3", RFC 2256, December 1997. 292 [LDIF]G. Good, "The LDAP Data Interchange Format (LDIF) - Technical 293 Specification" "The LDAP Data Interchange Format (LDIF)", 294 INTERNET-DRAFT , 30 July 1997. 296 [RFC1847] 297 J. Galvin, S. Murphy, S. Crocker, N. Freed, "Security Multiparts 298 for MIME: Multipart/Signed and Multipart/Encrypted", RFC 2068, 299 October 1995. 301 [RFC2068] 302 R. Fielding, J. Gettys, J. Mogul, H. Frystyk, T. Berners-Lee, 303 "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, January 1997. 305 [RFC2079] 306 M. Smith, "Definition of an X.500 Attribute Type and an Object 307 Class to Hold Uniform Resource Identifiers (URIs)", RFC 2079, Janu- 308 ary 1997. 310 [PKCS12] 311 "PKCS #12: Personal Information Exchange Standard", Version 1.0 312 DRAFT, 30 April 1997. 314 11. Author's Address 316 Mark Smith 317 Netscape Communications Corp. 318 501 E. Middlefield Rd., Mailstop MV068 319 Mountain View, CA 94043, USA 320 Phone: +1 650 937-3477 321 EMail: mcs@netscape.com 323 11.1. Appendix A - Change History 325 Changes since draft-ietf-asid-inetorgperson-01.txt: 327 Renamed draft (The ASID group is going away). 329 Added userPKCS12 attribute type and reference to PKCS #12. 331 Changed syntax of userSMIMECertificate attribute type and clarified 332 usage. 334 Changed description of employeeNumber and departmentNumber attribute 335 type to allow alphanumeric codes to be used as well as strictly 336 numeric ones. 338 Updated references (LDAPv3 drafts are now RFCs). 340 Added Copyright information. 342 Removed Appendrix A - Open Issues. 344 This Internet Draft expires on 11 September 1998.