--- /dev/null
+
+
+
+
+
+
+INTERNET-DRAFT Editor: Kurt D. Zeilenga
+Intended Category: Standard Track OpenLDAP Foundation
+Expires: 26 December 2001 26 June 2001
+Obsoletes: RFC 1274
+
+
+
+ LDAPv3: A Collection of User Schema
+ <draft-zeilenga-ldap-user-schema-01.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 LDAP Extension Working Group
+ mailing list <ietf-ldapext@netscape.com>. 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 2001, 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 collected from numerous sources.
+
+
+
+
+
+Zeilenga draft-zeilenga-ldap-user-schema-01 [Page 1]
+\f
+INTERNET-DRAFT LDAPv3: A Collection of User Schema 26 June 2001
+
+
+1. Background and Intended Use
+
+ This document provides descriptions [RFC2252] of user schema for use
+ with LDAP [LDAPTS] collected from numerous sources.
+
+ The document includes a summary of select schema introduced for the
+ COSINE and Internet X.500 pilot projects [RFC1274]. This document
+ obsoletes RFC 1274.
+
+ The document also contains a summary of X.500 user schema [X.520] not
+ included in LDAPv3 [RFC2256].
+
+ The key words ``MUST'', ``MUST NOT'', ``REQUIRED'', ``SHALL'', ``SHALL
+ NOT'', ``SHOULD'', ``SHOULD NOT'', ``RECOMMENDED'', and ``MAY'' in
+ this document are to be interpreted as described in RFC 2119
+ [RFC2119].
+
+
+2. Syntaxes
+
+ None (yet).
+
+
+3. Matching Rules
+
+ This section introduces LDAP matching rules based upon descriptions of
+ their X.500 counterparts.
+
+
+3.1. caseExactMatch
+
+ CaseExactMatch compares for equality the asserted string 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 )
+
+
+3.2. 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'
+
+
+
+Zeilenga draft-zeilenga-ldap-user-schema-01 [Page 2]
+\f
+INTERNET-DRAFT LDAPv3: A Collection of User Schema 26 June 2001
+
+
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+
+3.3. caseExactSubstringsMatch
+
+ CaseExactSubstringsMatch determines whether the asserted value is a
+ substring 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 )
+
+
+3.4. 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 )
+
+
+3.5. caseIgnoreListSubstringsMatch
+
+ 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 )
+
+
+3.6. 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
+
+
+
+Zeilenga draft-zeilenga-ldap-user-schema-01 [Page 3]
+\f
+INTERNET-DRAFT LDAPv3: A Collection of User Schema 26 June 2001
+
+
+ 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
+ which is a telephone number.
+
+
+3.7. 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 )
+
+
+3.8. 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 )
+
+
+3.9. 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
+
+
+
+Zeilenga draft-zeilenga-ldap-user-schema-01 [Page 4]
+\f
+INTERNET-DRAFT LDAPv3: A Collection of User Schema 26 June 2001
+
+
+ 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 )
+
+3.10. 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.11. 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:
+ X.520)
+
+ ( 2.5.13.32 NAME 'keywordMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+
+4. Attribute Types
+
+4.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 )
+
+
+4.2. associatedName
+
+
+
+
+Zeilenga draft-zeilenga-ldap-user-schema-01 [Page 5]
+\f
+INTERNET-DRAFT LDAPv3: A Collection of User Schema 26 June 2001
+
+
+ The Associated Name 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 )
+
+
+4.4. buildingName
+
+ The buildingName attribute type specifies the name of the building
+ 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} )
+
+
+4.5. co
+
+ The co (Friendly Country Name) attribute type specifies names of
+ countries in human readable format. The standard attribute country
+ name must be one of the two-letter codes defined in [ISO 3166].
+ (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 )
+
+
+4.6. destinationIndicator
+
+ The destinationIndicator attribute type specifies (according to CCITT
+ Recommendation F.1 and CCITT Recommendation F.31) the country and city
+ associated with the object (the addressee) needed to provide the
+ Public Telegram Service. An attribute value for Destination Indicator
+ is a printable string containing only alphabetical characters.
+ (Source: X.520)
+
+ ( 2.5.4.27 NAME 'destinationIndicator'
+ EQUALITY caseIgnoreMatch
+ SUBSTRINGS caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.44{128} )
+
+
+
+Zeilenga draft-zeilenga-ldap-user-schema-01 [Page 6]
+\f
+INTERNET-DRAFT LDAPv3: A Collection of User Schema 26 June 2001
+
+
+4.7. 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 )
+
+
+4.8. 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} )
+
+
+4.9. documentLocation
+
+ The documentLocation attribute type specifies the location of the
+ 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} )
+
+
+4.10. 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 )
+
+
+4.11. documentTitle
+
+ The documentTitle attribute type specifies the title of a document.
+ (Source: RFC 1274)
+
+
+
+
+Zeilenga draft-zeilenga-ldap-user-schema-01 [Page 7]
+\f
+INTERNET-DRAFT LDAPv3: A Collection of User Schema 26 June 2001
+
+
+ ( 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} )
+
+
+4.12. 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} )
+
+
+4.13. 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
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
+
+
+4.14. houseIdentifier
+
+ The houseIdentifier attribute type specifies a linguistic construct
+ used to identify a particular building, for example a house number or
+ house name relative to a street, avenue, town or city, etc. An
+ attribute value for houseIdentifier is a string, e.g. "14". (Source:
+ X.520)
+
+ ( 2.5.4.51 NAME 'houseIdentifier'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} )
+
+
+4.15. 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)
+
+
+
+
+Zeilenga draft-zeilenga-ldap-user-schema-01 [Page 8]
+\f
+INTERNET-DRAFT LDAPv3: A Collection of User Schema 26 June 2001
+
+
+ ( 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 )
+
+
+4.16. 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 )
+
+
+4.17. 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} )
+
+4.18. 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.
+ It is noted the description attribute [RFC2256] for 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} )
+
+
+4.19. mail
+
+
+
+
+Zeilenga draft-zeilenga-ldap-user-schema-01 [Page 9]
+\f
+INTERNET-DRAFT LDAPv3: A Collection of User Schema 26 June 2001
+
+
+ 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} )
+
+
+4.20. 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 )
+
+
+4.21. 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 )
+
+
+4.22. 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 probably consider carefully the
+ distinctions between this and the title and userClass attributes.
+ (Source: RFC 1274)
+
+ ( 0.9.2342.19200300.100.1.45
+
+
+
+Zeilenga draft-zeilenga-ldap-user-schema-01 [Page 10]
+\f
+INTERNET-DRAFT LDAPv3: A Collection of User Schema 26 June 2001
+
+
+ NAME 'organizationalStatus'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
+
+
+4.23. 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 )
+
+
+4.24. 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 )
+
+
+4.25. 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
+ NAME 'personalTitle'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
+
+
+4.26. roomNumber
+
+ The roomNumber attribute type specifies the room number of an object.
+ Note that the cn (commonName) attribute should be used for naming room
+ objects. (Source: RFC 1274)
+
+
+
+
+Zeilenga draft-zeilenga-ldap-user-schema-01 [Page 11]
+\f
+INTERNET-DRAFT LDAPv3: A Collection of User Schema 26 June 2001
+
+
+ ( 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} )
+
+
+4.27. 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 )
+
+
+4.28. 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} )
+
+
+4.29. uniqueIdentifier
+
+ The uniqueIdentifier attribute type specifies an identifier which may
+ be used to distinguish between object references when a distinguished
+ name has been reused. It may be, for example, an encoded object
+ identifier, certificate, date, timestamp, or some other form of
+ certification on the validity of the distinguished name.
+
+ An attribute value for uniqueIdentifier is a bitString. (Source:
+ X.520)
+
+ ( 2.5.4.45 NAME 'uniqueIdentifier'
+ EQUALITY bitStringMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 )
+
+
+ Note: RFC 1274 describes a variant of this attribute which is not
+
+
+
+Zeilenga draft-zeilenga-ldap-user-schema-01 [Page 12]
+\f
+INTERNET-DRAFT LDAPv3: A Collection of User Schema 26 June 2001
+
+
+ used.
+
+
+4.30. 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 may 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} )
+
+
+5. Object Classes
+
+5.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 ) )
+
+
+5.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 ) )
+
+
+5.3. documentSeries
+
+
+
+Zeilenga draft-zeilenga-ldap-user-schema-01 [Page 13]
+\f
+INTERNET-DRAFT LDAPv3: A Collection of User Schema 26 June 2001
+
+
+ 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 ) )
+
+
+5.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 )
+
+
+5.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. The naming
+ attribute of object class country, c (countryName), has to be a 2
+ letter string defined in [ISO3166]. (Source: RFC 1274)
+
+ ( 0.9.2342.19200300.100.4.18
+ NAME 'friendlyCountry'
+ SUP country STRUCTURAL
+ MUST co )
+
+
+5.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 RFC822 address as a domain [RFC2247]. (Source: RFC 1274)
+
+ ( 0.9.2342.19200300.100.4.14
+ NAME 'rFC822localPart'
+ SUP domain STRUCTURAL
+ MAY ( cn $ description $ destinationIndicator $
+
+
+
+Zeilenga draft-zeilenga-ldap-user-schema-01 [Page 14]
+\f
+INTERNET-DRAFT LDAPv3: A Collection of User Schema 26 June 2001
+
+
+ facsimileTelephoneNumber $ internationaliSDNNumber $
+ physicalDeliveryOfficeName $ postalAddress $
+ postalCode $ postOfficeBox $ preferredDeliveryMethod $
+ registeredAddress $ seeAlso $ sn $ street $
+ telephoneNumber $ teletexTerminalIdentifier $
+ telexNumber $ x121Address ) )
+
+
+5.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 ) )
+
+
+5.8. simpleSecurityObject
+
+ The simpleSecurityObject object class is used to allow an entry to
+ have a userPassword attribute when an entry's principal object classes
+ do not allow userPassword as an attribute type. (Source: RFC 1274)
+
+ ( 0.9.2342.19200300.100.4.19 NAME 'simpleSecurityObject'
+ SUP top AUXILIARY
+ MUST userPassword )
+
+ Note: Security considerations related to simple authentication
+ mechanisms in LDAP are discussed in RFC 2829 [RFC2829].
+
+
+6. Security Considerations
+
+ General LDAP security considerations [RFC2251][RFC2252][RFC2256] is
+ applicable to the use of this schema. Additional considerations are
+ noted above where appropriate.
+
+
+7. Acknowledgements
+
+ This document borrows from a number of IETF documents including RFC
+ 1274 and RFC 2252. This document also borrows from a number of ITU
+ documents including X.501 and X.520.
+
+
+
+
+Zeilenga draft-zeilenga-ldap-user-schema-01 [Page 15]
+\f
+INTERNET-DRAFT LDAPv3: A Collection of User Schema 26 June 2001
+
+
+8. Author's Address
+
+ Kurt D. Zeilenga
+ OpenLDAP Foundation
+ <Kurt@OpenLDAP.org>
+
+
+References
+
+ [ISO3166] International Standards Organization, "Codes for the
+ representation of names of countries", ISO 3166.
+
+ [RFC822] D. Crocker, "Standard for the format of ARPA Internet text
+ messages", August 1982.
+
+ [RFC1034] P.V. Mockapetris, "Domain names - concepts and facilities",
+ November 1987.
+
+ [RFC1274] P. Barker, S. Kille, "The COSINE and Internet X.500 Schema",
+ November 1991.
+
+ [RFC2219] S. Bradner, "Key words for use in RFCs to Indicate
+ Requirement Levels", 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.
+
+ [RFC2251] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access
+ Protocol (v3)", RFC 2251, December 1997.
+
+ [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", May 2000
+
+ [LDAPTS] J. Hodges, R.L. Morgan, "Lightweight Directory Access
+ Protocol (v3): Technical Specification", draft-ietf-ldapbis-
+ ldapv3-ts-00.txt.
+
+ [X.520] "The Directory: Selected Attribute Types", ITU
+ Recommendation X.520, 1997.
+
+
+
+
+Zeilenga draft-zeilenga-ldap-user-schema-01 [Page 16]
+\f
+INTERNET-DRAFT LDAPv3: A Collection of User Schema 26 June 2001
+
+
+Full Copyright
+
+ Copyright 2001, 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-01 [Page 17]
+\f