openldap/doc/drafts/draft-zeilenga-ldap-user-schema-xx.txt

INTERNET-DRAFT                           Editor:  Kurt D. Zeilenga
Intended Category: Standard Track                 OpenLDAP Foundation
Expires in six months                             17 May 2002
Obsoletes: RFC 1274
Updates: RFC 2798


                   LDAPv3: A Collection of User Schema
                 <draft-zeilenga-ldap-user-schema-06.txt>


Status of this Memo

  This document is an Internet-Draft and is in full conformance with all
  provisions of Section 10 of RFC2026.

  This document is intended to be, after appropriate review and
  revision, submitted to the RFC Editor as a Standard Track document.
  Distribution of this memo is unlimited.  Technical discussion of this
  document will take place on the IETF Directory Interest mailing list
  <directory@apps.ietf.org>.  Please send editorial comments directly to
  the author <Kurt@OpenLDAP.org>.

  Internet-Drafts are working documents 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.''

  The list of current Internet-Drafts can be accessed at
  <http://www.ietf.org/ietf/1id-abstracts.txt>. The list of
  Internet-Draft Shadow Directories can be accessed at
  <http://www.ietf.org/shadow.html>.

  Copyright 2002, The Internet Society.  All Rights Reserved.

  Please see the Copyright section near the end of this document for
  more information.


Abstract

  This document provides a collection of user schema elements for use
  with LDAP (Lightweight Directory Access Protocol) from both ITU-T
  Recommendations for the X.500 Directory and COSINE and Internet X.500
  pilot projects.



Zeilenga           draft-zeilenga-ldap-user-schema-06           [Page 1]

INTERNET-DRAFT     LDAPv3: A Collection of User Schema       17 May 2002


Conventions

  Schema definitions are provided using LDAPv3 description formats
  [RFC2252].  Definitions provided here are formatted (line wrapped) for
  readability.

  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
  document are to be interpreted as described in BCP 14 [RFC2119].


Table of Contents (to be expanded by editor)

  Status of this Memo                                  1
  Abstract
  Conventions                                          2
  Table of Contents
  1.   Background and Intended Use                     3
  2.   Matching Rules
  2.1.   booleanMatch                                  4
  2.2.   caseExactMatch
  2.3.   caseExactOrderingMatch
  2.4.   caseExactSubstringsMatch
  2.5.   caseIgnoreListSubstringsMatch
  2.6.   directoryStringFirstComponentMatch            5
  2.7.   integerOrderingMatch
  2.8.   keywordMatch
  2.9.   numericStringOrderingMatch                    6
  2.10.  octetStringOrderingMatch
  2.11.  storedPrefixMatch
  2.12.  wordMatch                                     7
  3.   Attribute Types
  3.1.   associatedDomain
  3.2.   associatedName
  3.3.   buildingName
  3.3.   co                                            8
  3.5.   documentAuthor
  3.6.   documentIdentifier
  3.7.   documentLocation
  3.8.   documentPublisher                             9
  3.9.   documentTitle
  3.10.  documentVersion
  3.11.  drink
  3.12.  homePhone                                    10
  3.13.  homePostalAddress
  3.14.  host
  3.16.  info
  3.17.  mail                                         11



Zeilenga           draft-zeilenga-ldap-user-schema-06           [Page 2]

INTERNET-DRAFT     LDAPv3: A Collection of User Schema       17 May 2002


  3.18.  manager
  3.19.  mobile
  3.20.  organizationalStatus
  3.21.  otherMailbox                                 12
  3.22.  pager
  3.23.  personalTitle
  3.24.  roomNumber                                   13
  3.25.  secretary
  3.26.  uid
  3.27.  uniqueIdentifier
  3.28.  userClass                                    14
  4.   Object Classes
  4.1.   account
  4.2.   document                                     15
  4.3.   documentSeries
  4.4.   domainRelatedObject
  4.5.   friendlyCountry
  4.6.   rFC822LocalPart                              16
  4.7.   room
  4.8.   simpleSecurityObject
  5.   Security Considerations                        17
  6.   IANA Considerations
  7.   Acknowledgments                                19
  8.   Author's Address
  9.   Normative References
  10.  Informative References
  Full Copyright                                      20


1. Background and Intended Use

  This document provides descriptions [RFC2252] of user schema for use
  with LDAP [LDAPTS] collected from numerous sources.

  This document includes a summary of select schema introduced for the
  COSINE and Internet X.500 pilot projects [RFC1274].  This document
  obsoletes RFC 1274.

  This document includes a summary of X.500 user schema [X.520] not
  previously specified for use with LDAP.  Some of these items were
  described in the inetOrgPerson [RFC2798] schema.  This document
  supersedes these descriptions, replacing sections 9.1.3 and 9.3.3 of
  RFC 2798.


2. Matching Rules

  This section introduces LDAP matching rules based upon descriptions of



Zeilenga           draft-zeilenga-ldap-user-schema-06           [Page 3]

INTERNET-DRAFT     LDAPv3: A Collection of User Schema       17 May 2002


  their X.500 counterparts.


2.1. booleanMatch

  BooleanMatch compares for equality a asserted Boolean value with an
  attribute value of BOOLEAN syntax.  The rule returns TRUE if and only
  if the values are the same, i.e. both are TRUE or both are FALSE.
  (Source: X.520)

      ( 2.5.13.13 NAME 'booleanMatch'
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 )


2.2. caseExactMatch

  CaseExactMatch compares for equality the asserted value with an
  attribute value of DirectoryString syntax.  The rule is identical to
  the caseIgnoreMatch [RFC2252] rule except that case is not ignored.
  (Source: X.520)

      ( 2.5.13.5 NAME 'caseExactMatch'
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )


2.3. caseExactOrderingMatch

  CaseExactOrderingMatch compares the collation order of the asserted
  string with an attribute value of DirectoryString syntax.  The rule is
  identical to the caseIgnoreOrderingMatch [RFC2252] rule except that
  letters are not folded.  (Source: X.520)

      ( 2.5.13.6 NAME 'caseExactOrderingMatch'
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )


2.4. caseExactSubstringsMatch

  CaseExactSubstringsMatch determines whether the asserted value(s) are
  substrings of an attribute value of DirectoryString syntax.  The rule
  is identical to the caseIgnoreSubstringsMatch [RFC2252] rule except
  that case is not ignored.  (Source: X.520)

      ( 2.5.13.7 NAME 'caseExactSubstringsMatch'
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )


2.5. caseIgnoreListSubstringsMatch



Zeilenga           draft-zeilenga-ldap-user-schema-06           [Page 4]

INTERNET-DRAFT     LDAPv3: A Collection of User Schema       17 May 2002


  CaseIgnoreListSubstringMatch compares the asserted substring with an
  attribute value which is a sequence of DirectoryStrings, but where the
  case (upper or lower) is not significant for comparison purposes.  The
  asserted value matches a stored value if and only if the asserted
  value matches the string formed by concatenating the strings of the
  stored value. This matching is done according to the
  caseIgnoreSubstringsMatch [RFC2252] rule; however, none of the
  initial, any, or final values of the asserted value are considered to
  match a substring of the concatenated string which spans more than one
  of the strings of the stored value.  (Source:  X.520)

      ( 2.5.13.12 NAME 'caseIgnoreListSubstringsMatch'
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )


2.6. directoryStringFirstComponentMatch

  DirectoryStringFirstComponentMatch compares for equality the asserted
  DirectoryString value with an attribute value of type SEQUENCE whose
  first component is mandatory and of type DirectoryString.  The rule
  returns TRUE if and only if the attribute value has a first component
  whose value matches the asserted DirectoryString using the rules of
  caseIgnoreMatch [RFC2252].  A value of the assertion syntax is derived
  from a value of the attribute syntax by using the value of the first
  component of the SEQUENCE.  (Source: X.520)

      ( 2.5.13.31 NAME 'directoryStringFirstComponentMatch'
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )


2.7. integerOrderingMatch

  The integerOrderingMatch rule compares the ordering of the asserted
  integer with an attribute value of Integer syntax.  The rule returns
  True if the attribute value is less than the asserted value. (Source:
  X.520)

      ( 2.5.13.15 NAME 'integerOrderingMatch'
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )


2.8. keywordMatch

  The keywordMatch rule compares the asserted string with keywords in an
  attribute value of DirectoryString syntax.  The rule returns TRUE if
  and only if the asserted value matches any keyword in the attribute
  value.  The identification of keywords in an attribute value and of
  the exactness of match are both implementation specific.  (Source:



Zeilenga           draft-zeilenga-ldap-user-schema-06           [Page 5]

INTERNET-DRAFT     LDAPv3: A Collection of User Schema       17 May 2002


  X.520)

      ( 2.5.13.32 NAME 'keywordMatch'
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )


2.9. numericStringOrderingMatch

  NumericStringOrderingMatch compares the collation order of the
  asserted string with an attribute value of NumericString syntax.  The
  rule is identical to the caseIgnoreOrderingMatch [RFC2252] rule except
  that all space characters are skipped during comparison (case is
  irrelevant as characters are numeric).  (Source: X.520)

      ( 2.5.13.9 NAME 'numericStringOrderingMatch'
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 )


2.10. octetStringOrderingMatch

  OctetStringOrderingMatch compares the collation order of the asserted
  octet string with an attribute value of OCTET STRING syntax.  The rule
  compares octet strings from first octet to last octet, and from the
  most significant bit to the least significant bit within the octet.
  The first occurrence of a different bit determines the ordering of the
  strings. A zero bit precedes a one bit. If the strings are identical
  but contain different numbers of octets, the shorter string precedes
  the longer string.  (Source: X.520)

      ( 2.5.13.18 NAME 'octetStringOrderingMatch'
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )


2.11. storedPrefixMatch

  StoredPrefixMatch determines whether an attribute value, whose syntax
  is DirectoryString, is a prefix (i.e. initial substring) of the
  asserted value, without regard to the case (upper or lower) of the
  strings.  The rule returns TRUE if and only if the attribute value is
  an initial substring of the asserted value with corresponding
  characters identical except possibly with regard to case.  (Source:
  X.520)

      ( 2.5.13.41 NAME 'storedPrefixMatch'
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

  Note: This rule can be used, for example, to compare values in the
        Directory which are telephone area codes with a purported value



Zeilenga           draft-zeilenga-ldap-user-schema-06           [Page 6]

INTERNET-DRAFT     LDAPv3: A Collection of User Schema       17 May 2002


        which is a telephone number.


2.12. wordMatch

  The wordMatch rule compares the asserted string with words in an
  attribute value of DirectoryString syntax.  The rule returns TRUE if
  and only if the asserted word matches any word in the attribute value.
  Individual word matching is as for the caseIgnoreMatch [RFC2252]
  matching rule. The precise definition of a "word" is implementation
  specific.  (Source: X.520)

      ( 2.5.13.32 NAME 'wordMatch'
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )


3. Attribute Types

  This section details attribute types for use in LDAP.


3.1. associatedDomain

  The associatedDomain attribute type specifies a DNS domain [RFC1034]
  which is associated with an object. For example, the entry in the DIT
  with a distinguished name "DC=example,DC=com" might have an associated
  domain of "example.com".  (Source: RFC 1274)

      ( 0.9.2342.19200300.100.1.37 NAME 'associatedDomain'
        EQUALITY caseIgnoreIA5Match
        SUBSTR caseIgnoreIA5SubstringsMatch
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )


3.2. associatedName

  The associatedName attribute type specifies an entry in the
  organizational DIT associated with a DNS domain [RFC1034].  (Source:
  RFC 1274)

      ( 0.9.2342.19200300.100.1.38 NAME 'associatedName'
        EQUALITY distinguishedNameMatch
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )


3.3.  buildingName

  The buildingName attribute type specifies the name of the building



Zeilenga           draft-zeilenga-ldap-user-schema-06           [Page 7]

INTERNET-DRAFT     LDAPv3: A Collection of User Schema       17 May 2002


  where an organization or organizational unit is based.  (Source: RFC
  1274)

      ( 0.9.2342.19200300.100.1.48 NAME 'buildingName'
        EQUALITY caseIgnoreMatch
        SUBSTR caseIgnoreSubstringsMatch
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )


3.3. co

  The co (Friendly Country Name) attribute type specifies names of
  countries in human readable format.  It is commonly used in
  conjunction with the c (Country Name) [RFC2256] attribute type (which
  restricted to one of the two-letter codes defined in [ISO3166]).
  (Source: RFC 1274)

      ( 0.9.2342.19200300.100.1.43
        NAME ( 'co' 'friendlyCountryName' )
        EQUALITY caseIgnoreMatch
        SUBSTR caseIgnoreSubstringsMatch
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )


3.5. documentAuthor

  The documentAuthor attribute type specifies the distinguished name of
  the author of a document.  (Source: RFC 1274)

      ( 0.9.2342.19200300.100.1.14 NAME 'documentAuthor'
        EQUALITY distinguishedNameMatch
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )


3.6. documentIdentifier

  The documentIdentifier attribute type specifies a unique identifier
  for a document.  (Source: RFC 1274)

      ( 0.9.2342.19200300.100.1.11 NAME 'documentIdentifier'
        EQUALITY caseIgnoreMatch
        SUBSTR caseIgnoreSubstringsMatch
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )


3.7. documentLocation

  The documentLocation attribute type specifies the location of the



Zeilenga           draft-zeilenga-ldap-user-schema-06           [Page 8]

INTERNET-DRAFT     LDAPv3: A Collection of User Schema       17 May 2002


  document original.  (Source: RFC 1274)

      ( 0.9.2342.19200300.100.1.15 NAME 'documentLocation'
        EQUALITY caseIgnoreMatch
        SUBSTR caseIgnoreSubstringsMatch
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )


3.8. documentPublisher

  The documentPublisher attribute is the person and/or organization that
  published a document.  (Source: RFC 1274)

      ( 0.9.2342.19200300.100.1.56 NAME 'documentPublisher'
        EQUALITY caseIgnoreMatch
        SUBSTR caseIgnoreSubstringsMatch
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )


3.9. documentTitle

  The documentTitle attribute type specifies the title of a document.
  (Source: RFC 1274)

      ( 0.9.2342.19200300.100.1.12 NAME 'documentTitle'
        EQUALITY caseIgnoreMatch
        SUBSTR caseIgnoreSubstringsMatch
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )


3.10. documentVersion

  The documentVersion attribute type specifies the version number of a
  document. (Source: RFC 1274)

      ( 0.9.2342.19200300.100.1.13 NAME 'documentVersion'
        EQUALITY caseIgnoreMatch
        SUBSTR caseIgnoreSubstringsMatch
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )


3.11. drink

  The drink (Favourite Drink) attribute type specifies the favorite
  drink of an object (or person).  (Source: RFC 1274)

      ( 0.9.2342.19200300.100.1.5 NAME ( 'drink' 'favouriteDrink' )
        EQUALITY caseIgnoreMatch



Zeilenga           draft-zeilenga-ldap-user-schema-06           [Page 9]

INTERNET-DRAFT     LDAPv3: A Collection of User Schema       17 May 2002


        SUBSTR caseIgnoreSubstringsMatch
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )


3.12. homePhone

  The homePhone (Home Telephone Number) attribute type specifies a home
  telephone number (e.g., "+44 71 123 4567") associated with a person.
  (Source: RFC 1274)

      ( 0.9.2342.19200300.100.1.20
        NAME ( 'homePhone' 'homeTelephoneNumber' )
        EQUALITY telephoneNumberMatch
        SUBSTR telephoneNumberSubstringsMatch
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 )


3.13. homePostalAddress

  The homePostalAddress attribute type specifies a home postal address
  for an object.  This SHOULD be limited to up to 6 lines of 30
  characters each.  (Source: RFC 1274)

      ( 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 )


3.14. host

  The host attribute type specifies a host computer.  (Source: RFC 1274)

      ( 0.9.2342.19200300.100.1.9
        NAME 'host'
        EQUALITY caseIgnoreMatch
        SUBSTR caseIgnoreSubstringsMatch
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )


3.16. info

  The info (Information) attribute type specifies any general
  information pertinent to an object.  It is RECOMMENDED that specific
  usage of this attribute type is avoided, and that specific
  requirements are met by other (possibly additional) attribute types.
  Note that the description attribute type [RFC2256] is available for



Zeilenga           draft-zeilenga-ldap-user-schema-06          [Page 10]

INTERNET-DRAFT     LDAPv3: A Collection of User Schema       17 May 2002


  specifying descriptive information pertinent to an object.  (Source:
  RFC 1274)

      ( 0.9.2342.19200300.100.1.4
        NAME 'info'
        EQUALITY caseIgnoreMatch
        SUBSTR caseIgnoreSubstringsMatch
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{2048} )


3.17. mail

  The mail (rfc822mailbox) attribute type holds an the electronic mail
  address in [RFC822] form (e.g.: user@example.com).  Note that this
  attribute SHOULD NOT be used to hold non-Internet addresses.  (Source:
  RFC 1274)


      ( 0.9.2342.19200300.100.1.3
        NAME ( 'mail' 'rfc822Mailbox' )
        EQUALITY caseIgnoreIA5Match
        SUBSTR caseIgnoreIA5SubstringsMatch
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} )


3.18. manager

  The Manager attribute type specifies the manager of an object
  represented by an entry.  (Source: RFC 1274)

      ( 0.9.2342.19200300.100.1.10
        NAME 'manager'
        EQUALITY distinguishedNameMatch
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )


3.19. mobile

  The mobile (Mobile Telephone Number) attribute type specifies a mobile
  telephone number (e.g., "+44 71 123 4567") associated with a person.
  (Source: RFC 1274)

      ( 0.9.2342.19200300.100.1.41
        NAME ( 'mobile' 'mobileTelephoneNumber' )
        EQUALITY telephoneNumberMatch
        SUBSTR telephoneNumberSubstringsMatch
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 )




Zeilenga           draft-zeilenga-ldap-user-schema-06          [Page 11]

INTERNET-DRAFT     LDAPv3: A Collection of User Schema       17 May 2002


3.20. organizationalStatus

  The organizationalStatus attribute type specifies a category by which
  a person is often referred to in an organization.  Examples of usage
  in academia might include undergraduate student, researcher, lecturer,
  etc.

  A Directory administrator SHOULD consider carefully the distinctions
  between this and the title and userClass attributes.  (Source: RFC
  1274)

      ( 0.9.2342.19200300.100.1.45
        NAME 'organizationalStatus'
        EQUALITY caseIgnoreMatch
        SUBSTR caseIgnoreSubstringsMatch
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )


3.21. otherMailbox

  The otherMailbox attribute type specifies values for electronic
  mailbox types other than X.400 and RFC822.  (Source: RFC 1274)

      ( 0.9.2342.19200300.100.1.22
        NAME 'otherMailbox'
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.39 )


3.22. pager

  The pager (Pager Telephone Number) attribute type specifies a pager
  telephone number (e.g., "+44 71 123 4567") for an object.  (Source:
  RFC 1274)

      ( 0.9.2342.19200300.100.1.42
        NAME ( 'pager' 'pagerTelephoneNumber' )
        EQUALITY telephoneNumberMatch
        SUBSTR telephoneNumberSubstringsMatch
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 )


3.23. personalTitle

  The personalTitle attribute type specifies a personal title for a
  person.  Examples of personal titles are "Frau", "Dr", "Herr", and
  "Prof".  (Source: RFC 1274)

      ( 0.9.2342.19200300.100.1.40



Zeilenga           draft-zeilenga-ldap-user-schema-06          [Page 12]

INTERNET-DRAFT     LDAPv3: A Collection of User Schema       17 May 2002


        NAME 'personalTitle'
        EQUALITY caseIgnoreMatch
        SUBSTR caseIgnoreSubstringsMatch
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )


3.24. roomNumber

  The roomNumber attribute type specifies the room number of an object.
  Note that the cn (commonName) attribute type SHOULD be used for naming
  room objects.  (Source: RFC 1274)

      ( 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} )


3.25. secretary

  The secretary attribute type specifies the secretary of a person.  The
  attribute value for Secretary is a distinguished name.  (Source: RFC
  1274)

      ( 0.9.2342.19200300.100.1.21
        NAME 'secretary'
        EQUALITY distinguishedNameMatch
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )


3.26. uid

  The uid (userid) attribute type specifies a computer system login
  name.  (Source: RFC 1274)

      ( 0.9.2342.19200300.100.1.1
        NAME ( 'uid' 'userid' )
        EQUALITY caseIgnoreMatch
        SUBSTR caseIgnoreSubstringsMatch
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )


3.27. uniqueIdentifier

  The Unique Identifier attribute type specifies a "unique identifier"
  for an object represented in the Directory.  The domain within which
  the identifier is unique, and the exact semantics of the identifier,



Zeilenga           draft-zeilenga-ldap-user-schema-06          [Page 13]

INTERNET-DRAFT     LDAPv3: A Collection of User Schema       17 May 2002


  are for local definition.  For a person, this might be an institution-
  wide payroll number.  For an organizational unit, it might be a
  department code.  An attribute value for uniqueIdentifier is a
  directoryString.  (Source: RFC 1274)

      ( 0.9.2342.19200300.100.1.44 NAME 'uniqueIdentifier'
        EQUALITY caseIgnoreMatch
        SUBSTR caseIgnoreSubstringsMatch
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )

  Note: X.520 describes an attribute also called 'uniqueIdentifier'
        (2.5.4.45) which is called 'x500UniqueIdentifier' in LDAP
        [RFC2256].  The attribute detailed here ought not be confused
        with x500UniqueIdentifier.


3.28. userClass

  The userClass attribute type specifies a category of computer user.
  The semantics placed on this attribute are for local interpretation.
  Examples of current usage od this attribute in academia are
  undergraduate student, researcher, lecturer, etc.  Note that the
  organizationalStatus attribute type is now often be preferred as it
  makes no distinction between computer users and others.  (Source: RFC
  1274)

      ( 0.9.2342.19200300.100.1.8 NAME 'userClass'
        EQUALITY caseIgnoreMatch
        SUBSTR caseIgnoreSubstringsMatch
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )


4. Object Classes

  This section details object classes for use in LDAP.


4.1. account

  The account object class is used to define entries representing
  computer accounts.  The uid (userid) attribute SHOULD be used for
  naming entries of this object class.  (Source: RFC 1274)

      ( 0.9.2342.19200300.100.4.5
        NAME 'account'
        SUP top STRUCTURAL
        MUST uid
        MAY ( description $ seeAlso $ l $ o $ ou $ host ) )



Zeilenga           draft-zeilenga-ldap-user-schema-06          [Page 14]

INTERNET-DRAFT     LDAPv3: A Collection of User Schema       17 May 2002


4.2. document

  The document object class is used to define entries which represent
  documents.  (Source: RFC 1274)

      ( 0.9.2342.19200300.100.4.6
        NAME 'document'
        SUP top STRUCTURAL
        MUST documentIdentifier
        MAY ( cn $ description $ seeAlso $ l $ o $ ou $
              documentTitle $ documentVersion $ documentAuthor $
              documentLocation $ documentPublisher ) )


4.3. documentSeries

  The documentSeries object class is used to define an entry which
  represents a series of documents (e.g., The Request For Comments
  memos).  (Source: RFC 1274)

      ( 0.9.2342.19200300.100.4.9
        NAME 'documentSeries'
        SUP top STRUCTURAL
        MUST cn
        MAY ( description $ l $ o $ ou $ seeAlso $
              telephonenumber ) )


4.4.  domainRelatedObject

  The domainRelatedObject object class is used to define entries which
  represent DNS domains which are "equivalent" to an X.500 domain: e.g.,
  an organization or organizational unit.  (Source: RFC 1274)

      ( 0.9.2342.19200300.100.4.17
        NAME 'domainRelatedObject'
        SUP top AUXILIARY
        MUST associatedDomain )


4.5.  friendlyCountry

  The friendlyCountry object class is used to define country entries in
  the DIT.  The object class is used to allow friendlier naming of
  countries than that allowed by the object class country [RFC2256].
  (Source: RFC 1274)

      ( 0.9.2342.19200300.100.4.18



Zeilenga           draft-zeilenga-ldap-user-schema-06          [Page 15]

INTERNET-DRAFT     LDAPv3: A Collection of User Schema       17 May 2002


        NAME 'friendlyCountry'
        SUP country STRUCTURAL
        MUST co )


4.6.  rFC822LocalPart

  The rFC822LocalPart object class is used to define entries which
  represent the local part of [RFC822] mail addresses.  This treats this
  part of an RFC 822 address as a domain [RFC2247].  (Source: RFC 1274)

      ( 0.9.2342.19200300.100.4.14
        NAME 'rFC822localPart'
        SUP domain STRUCTURAL
        MAY ( cn $ description $ destinationIndicator $
              facsimileTelephoneNumber $ internationaliSDNNumber $
              physicalDeliveryOfficeName $ postalAddress $
              postalCode $ postOfficeBox $ preferredDeliveryMethod $
              registeredAddress $ seeAlso $ sn $ street $
              telephoneNumber $ teletexTerminalIdentifier $
              telexNumber $ x121Address ) )


4.7.  room

  The room object class is used to define entries representing rooms.
  The cn (commonName) attribute SHOULD be used for naming entries of
  this object class.  (Source: RFC 1274)

      ( 0.9.2342.19200300.100.4.7 NAME 'room'
        SUP top STRUCTURAL
        MUST cn
        MAY ( roomNumber $ description $
              seeAlso $ telephoneNumber ) )


4.8.  simpleSecurityObject

  The simpleSecurityObject object class is used to require an entry to
  have a userPassword attribute when the entry's structural object class
  does not require (or allow) the userPassword attribute.  (Source: RFC
  1274)


      ( 0.9.2342.19200300.100.4.19 NAME 'simpleSecurityObject'
        SUP top AUXILIARY
        MUST userPassword )




Zeilenga           draft-zeilenga-ldap-user-schema-06          [Page 16]

INTERNET-DRAFT     LDAPv3: A Collection of User Schema       17 May 2002


  Note: Security considerations related to the use of simple
        authentication mechanisms in LDAP are discussed in RFC 2829
        [RFC2829].


5. Security Considerations

  General LDAP security considerations [LDAPTS] is applicable to the use
  of this schema.  Additional considerations are noted above where
  appropriate.


6. IANA Considerations

  It is requested that IANA update the LDAP descriptors registry as
  indicated the following template:

      Subject: Request for LDAP Descriptor Registration Update
      Descriptor (short name): see comment
      Object Identifier: see comment
      Person & email address to contact for further information:
          Kurt Zeilenga <kurt@OpenLDAP.org>
      Usage: see comment
      Specification: RFCXXXX
      Author/Change Controller: IESG
      Comments:

      The following descriptors should be added:

        NAME                               Type OID
        ------------------------           ---- ---------
        booleanMatch                       M    2.5.13.13
        caseExactMatch                     M    2.5.13.5
        caseExactOrderingMatch             M    2.5.13.6
        caseExactSubstringsMatch           M    2.5.13.7
        caseIgnoreListSubstringsMatch      M    2.5.13.12
        directoryStringFirstComponentMatch M    2.5.13.31
        integerOrderingMatch               M    2.5.13.15
        keywordMatch                       M    2.5.13.32
        numericStringOrderingMatch         M    2.5.13.9
        octetStringOrderingMatch           M    2.5.13.18
        storedPrefixMatch                  M    2.5.13.41
        wordMatch                          M    2.5.13.32

      The following descriptors should be updated to refer to RFC XXXX.

        NAME                           Type OID
        ------------------------       ---- --------------------------



Zeilenga           draft-zeilenga-ldap-user-schema-06          [Page 17]

INTERNET-DRAFT     LDAPv3: A Collection of User Schema       17 May 2002


        account                        O    0.9.2342.19200300.100.4.5
        associatedDomain               A    0.9.2342.19200300.100.1.37
        associatedName                 A    0.9.2342.19200300.100.1.38
        buildingName                   A    0.9.2342.19200300.100.1.48
        co                             A    0.9.2342.19200300.100.1.43
        document                       O    0.9.2342.19200300.100.4.6
        documentAuthor                 A    0.9.2342.19200300.100.1.14
        documentIdentifier             A    0.9.2342.19200300.100.1.11
        documentLocation               A    0.9.2342.19200300.100.1.15
        documentPublisher              A    0.9.2342.19200300.100.1.56
        documentSeries                 O    0.9.2342.19200300.100.4.8
        documentTitle                  A    0.9.2342.19200300.100.1.12
        documentVersion                A    0.9.2342.19200300.100.1.13
        domainRelatedObject            O    0.9.2342.19200300.100.4.17
        drink                          A    0.9.2342.19200300.100.1.5
        favouriteDrink                 A    0.9.2342.19200300.100.1.5
        friendlyCountry                O    0.9.2342.19200300.100.4.18
        friendlyCountryName            A    0.9.2342.19200300.100.1.43
        homePhone                      A    0.9.2342.19200300.100.1.20
        homePostalAddress              A    0.9.2342.19200300.100.1.39
        homeTelephone                  A    0.9.2342.19200300.100.1.20
        host                           A    0.9.2342.19200300.100.1.9
        info                           A    0.9.2342.19200300.100.1.4
        mail                           A    0.9.2342.19200300.100.1.3
        manager                        A    0.9.2342.19200300.100.1.10
        mobile                         A    0.9.2342.19200300.100.1.41
        mobileTelephoneNumber          A    0.9.2342.19200300.100.1.41
        organizationalStatus           A    0.9.2342.19200300.100.1.45
        otherMailbox                   A    0.9.2342.19200300.100.1.22
        pager                          A    0.9.2342.19200300.100.1.42
        pagerTelephoneNumber           A    0.9.2342.19200300.100.1.42
        personalTitle                  A    0.9.2342.19200300.100.1.40
        RFC822LocalPart                O    0.9.2342.19200300.100.4.14
        RFC822Mailbox                  A    0.9.2342.19200300.100.1.3
        room                           O    0.9.2342.19200300.100.4.7
        roomNumber                     A    0.9.2342.19200300.100.1.6
        secretary                      A    0.9.2342.19200300.100.1.21
        simpleSecurityObject           O    0.9.2342.19200300.100.4.19
        singleLevelQuality             A    0.9.2342.19200300.100.1.50
        uid                            A    0.9.2342.19200300.100.1.1
        uniqueIdentifier               A    0.9.2342.19200300.100.1.44
        userClass                      A    0.9.2342.19200300.100.1.8
        userId                         A    0.9.2342.19200300.100.1.1

      where Type A is Attribute, Type O is ObjectClass, and Type M
      is Matching Rule.





Zeilenga           draft-zeilenga-ldap-user-schema-06          [Page 18]

INTERNET-DRAFT     LDAPv3: A Collection of User Schema       17 May 2002


  This document make no OID assignments, it only associates LDAP schema
  descriptions with existing elements of X.500 schema.


7. Acknowledgments

  This document borrows from a number of IETF documents including RFC
  1274 by Paul Barker and Steve Kille.  This document also borrows from
  a number of ITU documents including X.520.


8. Author's Address

  Kurt D. Zeilenga
  OpenLDAP Foundation
  <Kurt@OpenLDAP.org>


9. Normative References

  [RFC822]  D. Crocker, "Standard for the format of ARPA Internet text
            messages", STD 11 (also RFC 822), August 1982.

  [RFC1034] P.V. Mockapetris, "Domain names - concepts and facilities",
            STD 13 (also RFC 1034), November 1987.

  [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
            Requirement Levels", BCP 14 (also RFC 2119), March 1997.

  [RFC2247] S. Kille, M. Wahl, A. Grimstad, R. Huber, S. Sataluri,
            "Using Domains in LDAP/X.500 Distinguished Names", January
            1998.

  [RFC2252] M. Wahl, A. Coulbeck, T. Howes, S. Kille, "Lightweight
            Directory Access Protocol (v3):  Attribute Syntax
            Definitions", RFC 2252, December 1997.

  [RFC2256] M. Wahl, "A Summary of the X.500(96) User Schema for use
            with LDAPv3", RFC 2256, December 1997.

  [RFC2829] M. Wahl, H. Alvestrand, J. Hodges, R. Morgan,
            "Authentication Methods for LDAP", RFC 2829, May 2000.

  [LDAPTS]  J. Hodges, R. Morgan, "Lightweight Directory Access Protocol
            (v3): Technical Specification", draft-ietf-ldapbis-
            ldapv3-ts-00.txt.





Zeilenga           draft-zeilenga-ldap-user-schema-06          [Page 19]

INTERNET-DRAFT     LDAPv3: A Collection of User Schema       17 May 2002


10. Informative References

  [ISO3166] International Standards Organization, "Codes for the
            representation of names of countries", ISO 3166.

  [RFC1274] P. Barker, S. Kille, "The COSINE and Internet X.500 Schema",
            November 1991.

  [RFC2798] M. Smith, "The LDAP inetOrgPerson Object Class", RFC 2798,
            April 2000.

  [X.520]   International Telephone Union, "The Directory: Selected
            Attribute Types", X.520, 1997.


Full Copyright

  Copyright 2002, The Internet Society.  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 AUTHORS, 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.










Zeilenga           draft-zeilenga-ldap-user-schema-06          [Page 20]