doc: Add RFC documents

1 files changed, 1123 insertions, 0 deletions

diff --git a/doc/rfc/rfc2798.txt b/doc/rfc/rfc2798.txt
new file mode 100644
index 0000000..3ad08a2
--- /dev/null
+++ b/doc/rfc/rfc2798.txt
@@ -0,0 +1,1123 @@
+
+
+
+
+
+
+Network Working Group                                          M. Smith
+Request for Comments: 2798                      Netscape Communications
+Category: Informational                                      April 2000
+
+
+           Definition of the inetOrgPerson LDAP Object Class
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2000).  All Rights Reserved.
+
+Abstract
+
+   While the X.500 standards define many useful attribute types [X520]
+   and object classes [X521], 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 for use in LDAP and X.500 directory services that
+   extends the X.521 standard organizationalPerson class to meet these
+   needs.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Smith                        Informational                      [Page 1]
+
+RFC 2798          The LDAP inetOrgPerson Object Class         April 2000
+
+
+Table of Contents
+
+   1.     Background and Intended Usage...............................2
+   2.     New Attribute Types Used in the inetOrgPerson Object Class..3
+   2.1.      Vehicle license or registration plate....................3
+   2.2.      Department number........................................3
+   2.3.      Display Name.............................................4
+   2.4.      Employee Number..........................................4
+   2.5.      Employee Type............................................4
+   2.6.      JPEG Photograph..........................................5
+   2.7.      Preferred Language.......................................5
+   2.8.      User S/MIME Certificate..................................5
+   2.9.      User PKCS #12............................................6
+   3.     Definition of the inetOrgPerson Object Class................6
+   4.     Example of an inetOrgPerson Entry...........................7
+   5.     Security Considerations.....................................8
+   6.     Acknowledgments.............................................8
+   7.     Bibliography................................................8
+   8.     Author's Address............................................9
+   9.     Appendix A - inetOrgPerson Schema Summary..................10
+   9.1.     Attribute Types..........................................10
+   9.1.1.      New attribute types that are defined in this document.10
+   9.1.2.      Attribute types from RFC 2256.........................12
+   9.1.3.      Attribute types from RFC 1274.........................15
+   9.1.4.      Attribute type from RFC 2079..........................16
+   9.2.     Syntaxes.................................................17
+   9.2.1.      Syntaxes from RFC 2252................................17
+   9.2.2.      Syntaxes from RFC 2256................................17
+   9.3.     Matching Rules...........................................17
+   9.3.1.      Matching rules from RFC 2252..........................17
+   9.3.2.      Matching rule from RFC 2256...........................18
+   9.3.3.      Additional matching rules from X.520..................18
+   9.3.4.      Matching rules not defined in any referenced document.19
+   10.    Full Copyright Statement...................................20
+
+1.  Background and Intended Usage
+
+   The inetOrgPerson object class is a general purpose object class that
+   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 [RFC2251] and the X.500 family of protocols, and it should be
+   useful in other contexts as well.  There is no requirement for
+   directory services implementors to use the inetOrgPerson object
+   class; it is simply presented as well-documented class that
+   implementors can choose to use if they find it useful.
+
+
+
+
+Smith                        Informational                      [Page 2]
+
+RFC 2798          The LDAP inetOrgPerson Object Class         April 2000
+
+
+   The attribute type and object class definitions in this document are
+   written using the BNF form of AttributeTypeDescription and
+   ObjectClassDescription given in [RFC2252].  In some cases lines have
+   been folded for readability.
+
+   Attributes that are referenced but not defined in this document are
+   included in one of the following documents:
+
+      The COSINE and Internet X.500 Schema [RFC1274]
+
+      Definition of an X.500 Attribute Type and an Object Class to Hold
+      Uniform Resource Identifiers (URIs) [RFC2079]
+
+      A Summary of the X.500(96) User Schema for use with LDAPv3
+      [RFC2256]
+
+   See Appendix A for a summary of the attribute types, associated
+   syntaxes, and matching rules used in this document.
+
+2.  New Attribute Types Used in the inetOrgPerson Object Class
+
+2.1.  Vehicle license or registration plate.
+
+   This multivalued field is used to record the values of the license or
+   registration plate associated with an individual.
+
+    ( 2.16.840.1.113730.3.1.1 NAME 'carLicense'
+      DESC 'vehicle license or registration plate'
+      EQUALITY caseIgnoreMatch
+      SUBSTR caseIgnoreSubstringsMatch
+      SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+2.2.  Department number
+
+   Code for department to which a person belongs.  This can also be
+   strictly numeric (e.g., 1234) or alphanumeric (e.g., ABC/123).
+
+    ( 2.16.840.1.113730.3.1.2
+      NAME 'departmentNumber'
+      DESC 'identifies a department within an organization'
+      EQUALITY caseIgnoreMatch
+      SUBSTR caseIgnoreSubstringsMatch
+      SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+
+
+
+
+
+
+
+Smith                        Informational                      [Page 3]
+
+RFC 2798          The LDAP inetOrgPerson Object Class         April 2000
+
+
+2.3.  Display Name
+
+   When displaying an entry, especially within a one-line summary list,
+   it is useful to be able to identify a name to be used.  Since other
+   attribute types such as 'cn' are multivalued, an additional attribute
+   type is needed.  Display name is defined for this purpose.
+
+  ( 2.16.840.1.113730.3.1.241
+    NAME 'displayName'
+    DESC 'preferred name of a person to be used when displaying entries'
+    EQUALITY caseIgnoreMatch
+    SUBSTR caseIgnoreSubstringsMatch
+    SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+    SINGLE-VALUE )
+
+2.4.  Employee Number
+
+   Numeric or alphanumeric identifier assigned to a person, typically
+   based on order of 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
+      SUBSTR caseIgnoreSubstringsMatch
+      SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+      SINGLE-VALUE )
+
+2.5.  Employee Type
+
+   Used to identify the employer to employee relationship.  Typical
+   values used will be "Contractor", "Employee", "Intern", "Temp",
+   "External", and "Unknown" but any value may be used.
+
+    ( 2.16.840.1.113730.3.1.4
+      NAME 'employeeType'
+      DESC 'type of employment for a person'
+      EQUALITY caseIgnoreMatch
+      SUBSTR caseIgnoreSubstringsMatch
+      SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+
+
+
+
+
+
+
+
+
+Smith                        Informational                      [Page 4]
+
+RFC 2798          The LDAP inetOrgPerson Object Class         April 2000
+
+
+2.6.  JPEG Photograph
+
+   Used to store one or more images of a person using the JPEG File
+   Interchange Format [JFIF].
+
+    ( 0.9.2342.19200300.100.1.60
+      NAME 'jpegPhoto'
+      DESC 'a JPEG image'
+      SYNTAX 1.3.6.1.4.1.1466.115.121.1.28 )
+
+   Note that the jpegPhoto attribute type was defined for use in the
+   Internet X.500 pilots but no referencable definition for it could be
+   located.
+
+2.7.  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 definition 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 'preferred written or spoken language for a person'
+      EQUALITY caseIgnoreMatch
+      SUBSTR caseIgnoreSubstringsMatch
+      SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+      SINGLE-VALUE )
+   )
+
+2.8.  User S/MIME Certificate
+
+   A PKCS#7 [RFC2315] SignedData, where the content that is signed is
+   ignored by consumers of userSMIMECertificate values.  It is
+   recommended that values have a `contentType' of data with an absent
+   `content' field.  Values of this attribute contain a person's entire
+   certificate chain and an smimeCapabilities field [RFC2633] that at a
+   minimum describes their SMIME algorithm capabilities.  Values for
+   this attribute are to be stored and requested in binary form, as
+   'userSMIMECertificate;binary'.  If available, this attribute is
+   preferred over the userCertificate attribute for S/MIME applications.
+
+    ( 2.16.840.1.113730.3.1.40
+      NAME 'userSMIMECertificate'
+      DESC 'PKCS#7 SignedData used to support S/MIME'
+      SYNTAX 1.3.6.1.4.1.1466.115.121.1.5 )
+
+
+
+Smith                        Informational                      [Page 5]
+
+RFC 2798          The LDAP inetOrgPerson Object Class         April 2000
+
+
+2.9.  User PKCS #12
+
+   PKCS #12 [PKCS12] provides a format for exchange of personal identity
+   information.  When such information is stored in a directory service,
+   the userPKCS12 attribute should be used. This attribute is to be
+   stored and requested in binary form, as 'userPKCS12;binary'.  The
+   attribute values are PFX PDUs stored as binary data.
+
+( 2.16.840.1.113730.3.1.216
+  NAME 'userPKCS12'
+  DESC 'PKCS #12 PFX PDU for exchange of personal identity information'
+  SYNTAX 1.3.6.1.4.1.1466.115.121.1.5 )
+
+3.  Definition of the inetOrgPerson Object Class
+
+   The inetOrgPerson represents people who are associated with an
+   organization in some way.  It is a structural class and is derived
+   from the organizationalPerson class which is defined in X.521 [X521].
+
+( 2.16.840.1.113730.3.2.2
+    NAME 'inetOrgPerson'
+    SUP organizationalPerson
+    STRUCTURAL
+    MAY (
+        audio $ businessCategory $ carLicense $ departmentNumber $
+        displayName $ employeeNumber $ employeeType $ givenName $
+        homePhone $ homePostalAddress $ initials $ jpegPhoto $
+        labeledURI $ mail $ manager $ mobile $ o $ pager $
+        photo $ roomNumber $ secretary $ uid $ userCertificate $
+        x500uniqueIdentifier $ preferredLanguage $
+        userSMIMECertificate $ userPKCS12
+    )
+)
+
+   For reference, we list the following additional attribute types that
+   are part of the inetOrgPerson object class.  These attribute types
+   are inherited from organizationalPerson (which in turn is derived
+   from the person object class):
+
+
+
+
+
+
+
+
+
+
+
+
+
+Smith                        Informational                      [Page 6]
+
+RFC 2798          The LDAP inetOrgPerson Object Class         April 2000
+
+
+    MUST (
+        cn $ objectClass $ sn
+    )
+    MAY (
+        description $ destinationIndicator $ facsimileTelephoneNumber $
+        internationaliSDNNumber $ l $ ou $ physicalDeliveryOfficeName $
+        postalAddress $ postalCode $ postOfficeBox $
+        preferredDeliveryMethod $ registeredAddress $ seeAlso $
+        st $ street $ telephoneNumber $ teletexTerminalIdentifier $
+        telexNumber $ title $ userPassword $ x121Address
+    )
+
+4.  Example of an inetOrgPerson Entry
+
+   The following example is expressed using the LDIF notation defined in
+   [LDIF].
+
+   version: 1
+   dn: cn=Barbara Jensen,ou=Product Development,dc=siroe,dc=com
+   objectClass: top
+   objectClass: person
+   objectClass: organizationalPerson
+   objectClass: inetOrgPerson
+   cn: Barbara Jensen
+   cn: Babs Jensen
+   displayName: Babs Jensen
+   sn: Jensen
+   givenName: Barbara
+   initials: BJJ
+   title: manager, product development
+   uid: bjensen
+   mail: bjensen@siroe.com
+   telephoneNumber: +1 408 555 1862
+   facsimileTelephoneNumber: +1 408 555 1992
+   mobile: +1 408 555 1941
+   roomNumber: 0209
+   carLicense: 6ABC246
+   o: Siroe
+   ou: Product Development
+   departmentNumber: 2604
+   employeeNumber: 42
+   employeeType: full time
+   preferredLanguage: fr, en-gb;q=0.8, en;q=0.7
+   labeledURI: http://www.siroe.com/users/bjensen My Home Page
+
+
+
+
+
+
+
+Smith                        Informational                      [Page 7]
+
+RFC 2798          The LDAP inetOrgPerson Object Class         April 2000
+
+
+5.  Security Considerations
+
+   Attributes of directory entries are used to provide descriptive
+   information 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.
+
+6.  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 and LDAPEXT groups, also contributed to the design of this
+   object class.
+
+7.  Bibliography
+
+   [JFIF]    E. Hamilton, "JPEG File Interchange Format (Version 1.02)",
+             C-Cube Microsystems, Milpitas, CA, September 1, 1992.
+
+   [LDIF]    G. Good, "The LDAP Data Interchange Format (LDIF) -
+             Technical Specification", Work in Progress.
+
+   [PKCS12]  "PKCS #12: Personal Information Exchange Standard", Version
+             1.0 Draft, 30 April 1997.
+
+   [RFC1274] Barker, P. and S. Kille, "The COSINE and Internet X.500
+             Schema", RFC 1274, November 1991.
+
+   [RFC1847] Galvin, J., Murphy, S., Crocker, S. and N. Freed, "Security
+             Multiparts for MIME:  Multipart/Signed and
+             Multipart/Encrypted", RFC 1847, October 1995.
+
+   [RFC2068] Fielding, R., Gettys, J., Mogul, J., Frystyk, H. and T.
+             Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC
+             2068, January 1997.
+
+   [RFC2079] Smith, M., "Definition of an X.500 Attribute Type and an
+             Object Class to Hold Uniform Resource Identifiers (URIs)",
+             RFC 2079, January 1997.
+
+
+
+
+Smith                        Informational                      [Page 8]
+
+RFC 2798          The LDAP inetOrgPerson Object Class         April 2000
+
+
+   [RFC2251] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory
+             Access Protocol (v3)", RFC 2251, December 1997.
+
+   [RFC2252] Wahl, M., Coulbeck, A., Howes, T., Kille, S., Yeong, W. and
+             C. Robbins, "Lightweight Directory Access Protocol (v3):
+             Attribute Syntax Definitions", RFC 2252, December 1997.
+
+   [RFC2256] Wahl, M., "A Summary of the X.500(96) User Schema for use
+             with LDAPv3", RFC 2256, December 1997.
+
+   [RFC2315] Kaliski, B., "PKCS #7: Cryptographic Message Syntax Version
+             1.5", RFC 2315, March 1998.
+
+   [RFC2633] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC
+             2633, June 1999.
+
+   [X520]    ITU-T Rec. X.520, "The Directory: Selected Attribute
+             Types", 1996.
+
+   [X521]    ITU-T Rec. X.521, "The Directory: Selected Object Classes",
+             1996.
+
+8.  Author's Address
+
+   Mark Smith
+   Netscape Communications Corp.
+   501 E. Middlefield Rd., Mailstop MV068
+   Mountain View, CA 94043, USA
+
+   Phone:  +1 650 937-3477
+   EMail:  mcs@netscape.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Smith                        Informational                      [Page 9]
+
+RFC 2798          The LDAP inetOrgPerson Object Class         April 2000
+
+
+9.  Appendix A - inetOrgPerson Schema Summary
+
+   This appendix provides definitions of all the attribute types
+   included in the inetOrgPerson object class along with their
+   associated syntaxes and matching rules.
+
+9.1.  Attribute Types
+
+9.1.1.  New attribute types that are defined in this document
+
+  ( 2.16.840.1.113730.3.1.1 NAME 'carLicense'
+    DESC 'vehicle license or registration plate'
+    EQUALITY caseIgnoreMatch
+    SUBSTR caseIgnoreSubstringsMatch
+    SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+  ( 2.16.840.1.113730.3.1.2
+    NAME 'departmentNumber'
+    DESC 'identifies a department within an organization'
+    EQUALITY caseIgnoreMatch
+    SUBSTR caseIgnoreSubstringsMatch
+    SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+  ( 2.16.840.1.113730.3.1.241
+    NAME 'displayName'
+    DESC 'preferred name of a person to be used when displaying entries'
+    EQUALITY caseIgnoreMatch
+    SUBSTR caseIgnoreSubstringsMatch
+    SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+    SINGLE-VALUE )
+
+  ( 2.16.840.1.113730.3.1.3
+    NAME 'employeeNumber'
+    DESC 'numerically identifies an employee within an organization'
+    EQUALITY caseIgnoreMatch
+    SUBSTR caseIgnoreSubstringsMatch
+    SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+    SINGLE-VALUE )
+
+  ( 2.16.840.1.113730.3.1.4
+    NAME 'employeeType'
+    DESC 'type of employment for a person'
+    EQUALITY caseIgnoreMatch
+    SUBSTR caseIgnoreSubstringsMatch
+    SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+
+
+
+
+
+Smith                        Informational                     [Page 10]
+
+RFC 2798          The LDAP inetOrgPerson Object Class         April 2000
+
+
+  ( 0.9.2342.19200300.100.1.60
+    NAME 'jpegPhoto'
+    DESC 'a JPEG image'
+    SYNTAX 1.3.6.1.4.1.1466.115.121.1.28 )
+  Note: The jpegPhoto attribute type was defined for use in the
+    Internet X.500 pilots but no referencable definition for it
+    could be located.
+
+  ( 2.16.840.1.113730.3.1.39
+    NAME 'preferredLanguage'
+    DESC 'preferred written or spoken language for a person'
+    EQUALITY caseIgnoreMatch
+    SUBSTR caseIgnoreSubstringsMatch
+    SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+    SINGLE-VALUE )
+
+  ( 2.16.840.1.113730.3.1.40
+    NAME 'userSMIMECertificate'
+    DESC 'signed message used to support S/MIME'
+    SYNTAX 1.3.6.1.4.1.1466.115.121.1.5 )
+
+  ( 2.16.840.1.113730.3.1.216
+    NAME 'userPKCS12'
+    DESC 'PKCS #12 PFX PDU for exchange of personal identity information'
+    SYNTAX 1.3.6.1.4.1.1466.115.121.1.5 )
+
+9.1.2.  Attribute types from RFC 2256
+
+   Note that the original definitions of these types can be found in
+   X.520.
+
+    ( 2.5.4.15
+      NAME 'businessCategory'
+      EQUALITY caseIgnoreMatch
+      SUBSTR caseIgnoreSubstringsMatch
+      SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{128} )
+
+    ( 2.5.4.3
+      NAME 'cn'
+      SUP name )
+
+    ( 2.5.4.13
+      NAME 'description'
+      EQUALITY caseIgnoreMatch
+      SUBSTR caseIgnoreSubstringsMatch
+      SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{1024} )
+
+
+
+
+
+Smith                        Informational                     [Page 11]
+
+RFC 2798          The LDAP inetOrgPerson Object Class         April 2000
+
+
+    ( 2.5.4.27
+      NAME 'destinationIndicator'
+      EQUALITY caseIgnoreMatch
+      SUBSTR caseIgnoreSubstringsMatch
+      SYNTAX 1.3.6.1.4.1.1466.115.121.1.44{128} )
+
+    ( 2.5.4.23
+      NAME 'facsimileTelephoneNumber'
+      SYNTAX 1.3.6.1.4.1.1466.115.121.1.22 )
+
+    ( 2.5.4.42
+      NAME 'givenName'
+      SUP name )
+
+    ( 2.5.4.43
+      NAME 'initials'
+      SUP name )
+
+    ( 2.5.4.25
+      NAME 'internationaliSDNNumber'
+      EQUALITY numericStringMatch
+      SUBSTR numericStringSubstringsMatch
+      SYNTAX 1.3.6.1.4.1.1466.115.121.1.36{16} )
+
+    ( 2.5.4.7
+      NAME 'l'
+      SUP name )
+
+    ( 2.5.4.0
+      NAME 'objectClass'
+      EQUALITY objectIdentifierMatch
+      SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
+
+    ( 2.5.4.10
+      NAME 'o'
+      SUP name )
+
+    ( 2.5.4.11
+      NAME 'ou'
+      SUP name )
+
+    ( 2.5.4.19
+      NAME 'physicalDeliveryOfficeName'
+      EQUALITY caseIgnoreMatch
+      SUBSTR caseIgnoreSubstringsMatch
+      SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{128} )
+
+
+
+
+
+Smith                        Informational                     [Page 12]
+
+RFC 2798          The LDAP inetOrgPerson Object Class         April 2000
+
+
+    ( 2.5.4.18
+      NAME 'postOfficeBox'
+      EQUALITY caseIgnoreMatch
+      SUBSTR caseIgnoreSubstringsMatch
+      SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{40} )
+
+    ( 2.5.4.16
+      NAME 'postalAddress'
+      EQUALITY caseIgnoreListMatch
+      SUBSTR caseIgnoreListSubstringsMatch
+      SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 )
+
+    ( 2.5.4.17
+      NAME 'postalCode'
+      EQUALITY caseIgnoreMatch
+      SUBSTR caseIgnoreSubstringsMatch
+      SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{40} )
+
+    ( 2.5.4.28
+      NAME 'preferredDeliveryMethod'
+      SYNTAX 1.3.6.1.4.1.1466.115.121.1.14
+      SINGLE-VALUE )
+
+    ( 2.5.4.26
+      NAME 'registeredAddress'
+      SUP postalAddress
+      SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 )
+
+    ( 2.5.4.34
+      NAME 'seeAlso'
+      SUP distinguishedName )
+
+    ( 2.5.4.4
+      NAME 'sn'
+      SUP name )
+
+    ( 2.5.4.8
+      NAME 'st'
+      SUP name )
+
+    ( 2.5.4.9
+      NAME 'street'
+      EQUALITY caseIgnoreMatch
+      SUBSTR caseIgnoreSubstringsMatch
+      SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{128} )
+
+
+
+
+
+
+Smith                        Informational                     [Page 13]
+
+RFC 2798          The LDAP inetOrgPerson Object Class         April 2000
+
+
+    ( 2.5.4.20
+      NAME 'telephoneNumber'
+      EQUALITY telephoneNumberMatch
+      SUBSTR telephoneNumberSubstringsMatch
+      SYNTAX 1.3.6.1.4.1.1466.115.121.1.50{32} )
+
+    ( 2.5.4.22
+      NAME 'teletexTerminalIdentifier'
+      SYNTAX 1.3.6.1.4.1.1466.115.121.1.51 )
+
+    ( 2.5.4.21
+      NAME 'telexNumber'
+      SYNTAX 1.3.6.1.4.1.1466.115.121.1.52 )
+
+    ( 2.5.4.12
+      NAME 'title'
+      SUP name )
+
+    ( 2.5.4.36
+      NAME 'userCertificate'
+      SYNTAX 1.3.6.1.4.1.1466.115.121.1.8 )
+
+    ( 2.5.4.35
+      NAME 'userPassword'
+      EQUALITY octetStringMatch
+      SYNTAX 1.3.6.1.4.1.1466.115.121.1.40{128} )
+
+    ( 2.5.4.24
+      NAME 'x121Address'
+      EQUALITY numericStringMatch
+      SUBSTR numericStringSubstringsMatch
+      SYNTAX 1.3.6.1.4.1.1466.115.121.1.36{15} )
+
+    ( 2.5.4.45
+      NAME 'x500UniqueIdentifier'
+      EQUALITY bitStringMatch
+      SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 )
+
+   Some attribute types included in inetOrgPerson are derived from the
+   'name' and 'distinguishedName' attribute supertypes:
+
+    ( 2.5.4.41
+      NAME 'name'
+      EQUALITY caseIgnoreMatch
+      SUBSTR caseIgnoreSubstringsMatch
+      SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} )
+
+
+
+
+
+Smith                        Informational                     [Page 14]
+
+RFC 2798          The LDAP inetOrgPerson Object Class         April 2000
+
+
+    ( 2.5.4.49
+      NAME 'distinguishedName'
+      EQUALITY distinguishedNameMatch
+      SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
+
+9.1.3.  Attribute types from RFC 1274
+
+    ( 0.9.2342.19200300.100.1.55
+      NAME 'audio'
+      EQUALITY octetStringMatch
+      SYNTAX 1.3.6.1.4.1.1466.115.121.1.40{250000} )
+    Note: The syntax used here for the audio attribute type is Octet
+      String. RFC 1274 uses a syntax called audio which is not defined
+      in RFC 1274.
+
+    ( 0.9.2342.19200300.100.1.20
+      NAME 'homePhone'
+      EQUALITY telephoneNumberMatch
+      SUBSTR telephoneNumberSubstringsMatch
+      SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 )
+    Note: RFC 1274 uses the longer name 'homeTelephoneNumber'.
+
+    ( 0.9.2342.19200300.100.1.39
+      NAME 'homePostalAddress'
+      EQUALITY caseIgnoreListMatch
+      SUBSTR caseIgnoreListSubstringsMatch
+      SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 )
+
+    ( 0.9.2342.19200300.100.1.3
+      NAME 'mail'
+      EQUALITY caseIgnoreIA5Match
+      SUBSTR caseIgnoreIA5SubstringsMatch
+      SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} )
+    Note: RFC 1274 uses the longer name 'rfc822Mailbox' and syntax OID
+      of 0.9.2342.19200300.100.3.5.  All recent LDAP documents and most
+      deployed LDAP implementations refer to this attribute as 'mail'
+      and define the IA5 String syntax using using the OID
+      1.3.6.1.4.1.1466.115.121.1.26, as is done here.
+
+    ( 0.9.2342.19200300.100.1.10
+      NAME 'manager'
+      EQUALITY distinguishedNameMatch
+      SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
+
+
+
+
+
+
+
+
+Smith                        Informational                     [Page 15]
+
+RFC 2798          The LDAP inetOrgPerson Object Class         April 2000
+
+
+    ( 0.9.2342.19200300.100.1.41
+      NAME 'mobile'
+      EQUALITY telephoneNumberMatch
+      SUBSTR telephoneNumberSubstringsMatch
+      SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 )
+    Note: RFC 1274 uses the longer name 'mobileTelephoneNumber'.
+
+    ( 0.9.2342.19200300.100.1.42
+      NAME 'pager'
+      EQUALITY telephoneNumberMatch
+      SUBSTR telephoneNumberSubstringsMatch
+      SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 )
+    Note: RFC 1274 uses the longer name 'pagerTelephoneNumber'.
+
+    ( 0.9.2342.19200300.100.1.7
+      NAME 'photo' )
+    Note: Photo attribute values are encoded in G3 fax format with an
+      ASN.1 wrapper. Please refer to RFC 1274 section 9.3.7 for
+      detailed syntax information for this attribute.
+
+    ( 0.9.2342.19200300.100.1.6
+      NAME 'roomNumber'
+      EQUALITY caseIgnoreMatch
+      SUBSTR caseIgnoreSubstringsMatch
+      SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
+
+    ( 0.9.2342.19200300.100.1.21
+      NAME 'secretary'
+      EQUALITY distinguishedNameMatch
+      SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
+
+    ( 0.9.2342.19200300.100.1.1
+      NAME 'uid'
+      EQUALITY caseIgnoreMatch
+      SUBSTR caseIgnoreSubstringsMatch
+      SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
+    Note: RFC 1274 uses the longer name 'userid'.
+
+9.1.4.  Attribute type from RFC 2079
+
+    ( 1.3.6.1.4.1.250.1.57
+      NAME 'labeledURI'
+      EQUALITY caseExactMatch
+      SUBSTR caseExactSubstringsMatch
+      SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+
+
+
+
+
+Smith                        Informational                     [Page 16]
+
+RFC 2798          The LDAP inetOrgPerson Object Class         April 2000
+
+
+9.2.  Syntaxes
+
+9.2.1.  Syntaxes from RFC 2252
+
+    ( 1.3.6.1.4.1.1466.115.121.1.5 DESC 'Binary' )
+
+    ( 1.3.6.1.4.1.1466.115.121.1.6 DESC 'Bit String' )
+
+    ( 1.3.6.1.4.1.1466.115.121.1.8 DESC 'Certificate' )
+
+    ( 1.3.6.1.4.1.1466.115.121.1.12 DESC 'DN' )
+
+    ( 1.3.6.1.4.1.1466.115.121.1.15 DESC 'Directory String' )
+
+    ( 1.3.6.1.4.1.1466.115.121.1.22 DESC 'Facsimile Telephone Number' )
+
+    ( 1.3.6.1.4.1.1466.115.121.1.26 DESC 'IA5 String' )
+
+    ( 1.3.6.1.4.1.1466.115.121.1.28 DESC 'JPEG' )
+
+    ( 1.3.6.1.4.1.1466.115.121.1.36 DESC 'Numeric String' )
+
+    ( 1.3.6.1.4.1.1466.115.121.1.38 DESC 'OID' )
+
+    ( 1.3.6.1.4.1.1466.115.121.1.41 DESC 'Postal Address' )
+
+    ( 1.3.6.1.4.1.1466.115.121.1.44 DESC 'Printable String' )
+
+    ( 1.3.6.1.4.1.1466.115.121.1.50 DESC 'Telephone Number' )
+
+9.2.2.  Syntaxes from RFC 2256
+
+    ( 1.3.6.1.4.1.1466.115.121.1.14 DESC 'Delivery Method' )
+
+    ( 1.3.6.1.4.1.1466.115.121.1.40 DESC 'Octet String' )
+
+    ( 1.3.6.1.4.1.1466.115.121.1.51 DESC 'Teletex Terminal Identifier' )
+
+    ( 1.3.6.1.4.1.1466.115.121.1.52 DESC 'Telex Number' )
+
+9.3.  Matching Rules
+
+9.3.1.  Matching rules from RFC 2252
+
+   Note that the original definition of many of these matching rules can
+   be found in X.520.
+
+
+
+
+
+Smith                        Informational                     [Page 17]
+
+RFC 2798          The LDAP inetOrgPerson Object Class         April 2000
+
+
+    ( 2.5.13.16 NAME 'bitStringMatch'
+      SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 )
+
+    ( 1.3.6.1.4.1.1466.109.114.2 NAME 'caseIgnoreIA5Match'
+      SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
+
+    ( 2.5.13.11 NAME 'caseIgnoreListMatch'
+      SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 )
+
+    ( 2.5.13.2 NAME 'caseIgnoreMatch'
+      SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+    ( 2.5.13.1 NAME 'distinguishedNameMatch'
+      SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
+
+    ( 2.5.13.8 NAME 'numericStringMatch'
+      SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 )
+
+    ( 2.5.13.0 NAME 'objectIdentifierMatch'
+      SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
+
+    ( 2.5.13.20 NAME 'telephoneNumberMatch'
+      SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 )
+
+9.3.2.  Matching rule from RFC 2256
+
+   Note that the original definition of this matching rule can be found
+   in X.520.
+
+    ( 2.5.13.17 NAME 'octetStringMatch'
+      SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )
+
+9.3.3.  Additional matching rules from X.520
+
+   caseExactMatch
+
+       ( 2.5.13.5 NAME 'caseExactMatch'
+         SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+   This rule determines whether a presented string exactly matches an
+   attribute value of syntax DirectoryString.  It is identical to
+   caseIgnoreMatch except that case is not ignored.  Multiple adjoining
+   whitespace characters are treated the same as an individual space,
+   and leading and trailing whitespace is ignored.
+
+
+
+
+
+
+
+Smith                        Informational                     [Page 18]
+
+RFC 2798          The LDAP inetOrgPerson Object Class         April 2000
+
+
+   caseExactSubstringsMatch
+
+       ( 2.5.13.7 NAME 'caseExactSubstringsMatch'
+         SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
+
+   This rules determines whether the initial, any and final substring
+   elements in a presented value are present in an attribute value of
+   syntax DirectoryString.  It is identical to caseIgnoreSubstringsMatch
+   except that case is not ignored.
+
+   caseIgnoreListSubstringsMatch
+
+       ( 2.5.13.12 NAME 'caseIgnoreListSubstringsMatch'
+         SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
+
+   This rule compares a presented substring with an attribute value
+   which is a sequence of DirectoryStrings, but where the case of
+   letters is not significant for comparison purposes.  A presented
+   value matches a stored value if and only if the presented value
+   matches the string formed by concatenating the strings of the stored
+   value.  Matching is done according to the caseIgnoreSubstringsMatch
+   rule except that none of the initial, final, or any values of the
+   presented value match a substring of the concatenated string which
+   spans more than one of the strings of the stored value.
+
+9.3.4.  Matching rules not defined in any referenced document
+
+   caseIgnoreIA5SubstringsMatch
+
+       ( 1.3.6.1.4.1.1466.109.114.3 NAME 'caseIgnoreIA5SubstringsMatch'
+         SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
+
+   This rules determines whether the initial, any and final substring
+   elements in a presented value are present in an attribute value of
+   syntax IA5 String without regard to the case of the letters in the
+   strings.  It is expected that this matching rule will be added to an
+   update of RFC 2252.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Smith                        Informational                     [Page 19]
+
+RFC 2798          The LDAP inetOrgPerson Object Class         April 2000
+
+
+10.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2000).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Smith                        Informational                     [Page 20]
+