The inetOrgPerson Object Class Mark Smith INTERNET-DRAFT Netscape Communications Intended Category: Informational 30 July 1997 Expires: 30 January 1998 Definition of the inetOrgPerson Object Class Filename: draft-ietf-asid-inetorgperson-01.txt 1. Status of this Memo This document is an Internet-Draft. Internet-Drafts are working docu- ments of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). This document provides information to the Internet community. It does not specify any standard. Distribution of this memo is unlimited. Com- ments may be sent to the author (mcs@netscape.com). Public discussion will take place on the IETF ASID mailing list (ietf-asid@umich.edu). This Internet Draft expires on 30 January 1998. 2. Abstract While the X.500 standards [X500] define many useful attribute types and object classes, they do not define a person object class that meets the requirements found in today's Internet and Intranet directory service deployments. We define a new object class called inetOrgPerson that extends the X.521 standard organizationalPerson class to meet these needs. 3. Background and Intended Usage The inetOrgPerson object class is a general purpose object class that M. Smith IETF ASID Working Group [Page 1] INTERNET-DRAFT The inetOrgPerson Object Class 30 July 1997 holds attributes about people. The attributes it holds were chosen to accommodate information requirements found in typical Internet and Intranet directory service deployments. The inetOrgPerson object class is designed to be used within directory services based on the LDAP [LDAP] and the X.500 family of protocols, and it should be useful in other contexts as well. The attribute type and object class definitions are written using the BNF form of AttributeTypeDescription and ObjectClassDescription given in [ATTRSYNTAX]. Lines have been folded for readability. Attributes that are referenced but not defined in this document are included in the standard and pilot attribute definitions [STDATTRS] or in the labeledURI object class [RFC2079] 4. New Attribute Types Used in the inetOrgPerson Object Class 4.1. Vehicle license plate tag. This multivalued field is used to record the license plate tags associ- ated with an individual. ( 2.16.840.1.113730.3.1.1 NAME 'carLicense' DESC 'vehicle license plate tag' EQUALITY caseIgnoreMatch SUBSTRINGS caseIgnoreSubstringsMatch SYNTAX 'DirectoryString' ) 4.2. Department number Numerical department number to which a person belongs. ( 2.16.840.1.113730.3.1.2 NAME 'departmentNumber' DESC 'numerically identifies a department within an organization' EQUALITY caseIgnoreMatch SUBSTRINGS caseIgnoreSubstringsMatch SYNTAX 'DirectoryString' ) 4.3. Employee Number Numerical identity assigned to a person, typically based on order of M. Smith IETF ASID Working Group [Page 2] INTERNET-DRAFT The inetOrgPerson Object Class 30 July 1997 hire or association with an organization. Single valued. ( 2.16.840.1.113730.3.1.3 NAME 'employeeNumber' DESC 'numerically identifies an employee within an organization' EQUALITY caseIgnoreMatch SUBSTRINGS caseIgnoreSubstringsMatch SYNTAX 'DirectoryString' SINGLE-VALUE ) 4.4. Employee Type Used to identify the employer to employee relationship. Typical values used will be "Contractor", "Employee", "Intern", "Temp", and "Unknown" but any value may be used. ( 2.16.840.1.113730.3.1.4 NAME 'employeeType' DESC 'a person's type of employment' EQUALITY caseIgnoreMatch SUBSTRINGS caseIgnoreSubstringsMatch SYNTAX 'DirectoryString' ) 4.5. Preferred Language Used to indicate an individual's preferred written or spoken language. This is useful for international correspondence or human-computer interaction. Values for this attribute type MUST conform to the defini- tion of the Accept-Language header field defined in [RFC2068] with one exception: the sequence "Accept-Language" ":" should be omitted. This is a single valued attribute type. ( 2.16.840.1.113730.3.1.39 NAME 'preferredLanguage' DESC 'a person's preferred written or spoken language' EQUALITY caseIgnoreMatch SUBSTRINGS caseIgnoreSubstringsMatch SYNTAX 'DirectoryString' SINGLE-VALUE ) 4.6. User S/MIME Certificate Certificate used for S/MIME [RFC1847]. This attribute is to be stored and requested in binary form, as 'userCertificate;binary'. ( 2.16.840.1.113730.3.1.40 M. Smith IETF ASID Working Group [Page 3] INTERNET-DRAFT The inetOrgPerson Object Class 30 July 1997 NAME 'userSMIMECertificate' DESC 'certificate for S/MIME" SYNTAX 'Certificate' ) 5. Definition of the inetOrgPerson Object Class The inetOrgPerson represents people who are associated with an organiza- tion in some way. It is a structural class and is derived from the organizationalPerson class. ( 2.16.840.1.113730.3.2.2 NAME 'inetOrgPerson' SUP organizationalPerson STRUCTURAL MAY ( audio $ businessCategory $ carLicense $ departmentNumber $ employeeNumber $ employeeType $ givenName $ homePhone $ homePostalAddress $ initials $ jpegPhoto $ labeledURI $ mail $ manager $ mobile $ pager $ photo $ roomNumber $ secretary $ uid $ userCertificate $ x500uniqueIdentifier $ preferredLanguage $ userSMIMECertificate ) ) For reference, we list the following additional attribute types which are inherited from organizationalPerson (which in turn is derived from the person object class): MUST ( objectClass $ sn $ cn ) MAY ( description $ seeAlso $ telephoneNumber $ userPassword $ destinationIndicator $ facsimileTelephoneNumber $ internationaliSDNNumber $ l $ ou $ physicalDeliveryOfficeName $ postOfficeBox $ postalAddress $ postalCode $ preferredDeliveryMethod $ registeredAddress $ st $ street $ telephoneNumber $ teletexTerminalIdentifier $ telexNumber $ title $ x121Address $ ) 6. Example of an inetOrgPerson Entry The following example is expressed using the LDIF notation defined in [LDIF]. M. Smith IETF ASID Working Group [Page 4] INTERNET-DRAFT The inetOrgPerson Object Class 30 July 1997 dn: cn=Barbara Jensen, ou=Product Development, o=Ace Industry, c=US objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson cn: Barbara Jensen cn: Babs Jensen sn: Jensen givenName: Barbara initials: BJJ title: manager, product development uid: bjensen mail: bjensen@aceindustry.com telephoneNumber: +1 408 555 1862 facsimileTelephoneNumber: +1 408 555 1992 mobile: +1 408 555 1941 roomNumber: 0209 carLicense: 6ABC246 departmentNumber: 2604 employeeNumber: 42 employeeType: full time preferredLanguage: fr, en-gb;q=0.8, en;q=0.7 labeledURI: http://www.aceindustry.com/users/bjensen My Home Page 7. Security Considerations Attributes of directory entries are used to provide descriptive informa- tion about the real-world objects they represent, which can be people, organizations or devices. Most countries have privacy laws regarding the publication of information about people. Transfer of cleartext passwords are strongly discouraged where the underlying transport service cannot guarantee confidentiality and may result in disclosure of the password to unauthorized parties. 8. Acknowledgments The Netscape Directory Server team created the inetOrgPerson object class based on experience and customer requirements. Anil Bhavnani and John Kristian in particular deserve credit for all of the early design work. Many members of the Internet community, in particular those in the IETF ASID group, also contributed to the design of this object class. M. Smith IETF ASID Working Group [Page 5] INTERNET-DRAFT The inetOrgPerson Object Class 30 July 1997 9. Bibliography [X500]ITU-T Rec. X.500, "The Directory: Overview of Concepts, Models and Service", 1993. [LDAP]M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access Proto- col (v3)", INTERNET-DRAFT , 11 July 1997. [ATTRSYNTAX] M. Wahl, A. Coulbeck, T. Howes, S. Kille, W. Yeong, C. Robbins, "Lightweight X.500 Directory Access Protocol Attribute Syntax Definitions", INTERNET-DRAFT , July 1997. [STDATTRS] M. Wahl, A. Coulbeck, T. Howes, S. Kille, "Lightweight Directory Access Protocol (v3): Standard and Pilot Attribute Definitions", INTERNET-DRAFT , [LDIF]G. Good, "The LDAP Data Interchange Format (LDIF) - Technical Specification" "The LDAP Data Interchange Format (LDIF)", INTERNET-DRAFT , 30 July 1997. [RFC1847] J. Galvin, S. Murphy, S. Crocker, N. Freed, "Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", October 1995. [RFC2068] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, January 1997. [RFC2079] M. Smith, "Definition of an X.500 Attribute Type and an Object Class to Hold Uniform Resource Identifiers (URIs)", RFC 2079, Janu- ary 1997. 10. Author's Address Mark Smith Netscape Communications Corp. 501 E. Middlefield Rd., Mailstop MV068 Mountain View, CA 94043, USA Phone: +1 415 937-3477 EMail: mcs@netscape.com M. Smith IETF ASID Working Group [Page 6] INTERNET-DRAFT The inetOrgPerson Object Class 30 July 1997 10.1. Appendix A - Open Issues 11. jpegPhoto, photo, and audio syntaxes are too limiting We need to define more extensible image and audio attributes with exten- sible syntaxes (perhaps based on MIME content-types). 12. Structural or auxiliary class? Should inetOrgPerson be defined as an auxiliary object class instead of as a structural one? This Internet Draft expires on 30 January 1998. M. Smith IETF ASID Working Group [Page 7]