





INTERNET-DRAFT                           Editor:  Kurt D. Zeilenga
Intended Category: Standard Track                 OpenLDAP Foundation
Expires in six months                             23 October 2005
Obsoletes: RFC 1274, RFC 2247
Updates: RFC 2798


                         COSINE LDAP/X.500 Schema
                   <draft-zeilenga-ldap-cosine-01.txt>


Status of this Memo

  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 LDAPEXT mailing list
  <ldapext@ietf.org>.  Please send editorial comments directly to the
  author <Kurt@OpenLDAP.org>.

  By submitting this Internet-Draft, each author represents that any
  applicable patent or other IPR claims of which he or she is aware have
  been or will be disclosed, and any of which he or she becomes aware
  will be disclosed, in accordance with Section 6 of BCP 79.

  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/1id-abstracts.html

  The list of Internet-Draft Shadow Directories can be accessed at
  http://www.ietf.org/shadow.html


  Copyright (C) The Internet Society (2005).  All Rights Reserved.

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


Abstract



Zeilenga              draft-zeilenga-ldap-cosine-01             [Page 1]

INTERNET-DRAFT                COSINE Schema              23 October 2005


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

  This document obsoletes RFC 1274 and RFC 2247.


Table of Contents

  Status of this Memo                                  1
  Abstract                                             2
  Table of Contents
  1.     Background and Intended Use                   3
  1.1.     Relationship with Other Documents
  1.2.     Terminology and Conventions
  2.     COSINE Attribute Types                        4
  2.1.     associatedDomain
  2.2.     associatedName
  2.3.     buildingName
  2.3.     co
  2.5.     documentAuthor
  2.6.     documentIdentifier
  2.7.     documentLocation
  2.8.     documentPublisher
  2.9.     documentTitle
  2.10.    documentVersion
  2.11.    drink
  2.12.    homePhone
  2.13.    homePostalAddress
  2.14.    host
  2.16.    info
  2.17.    mail
  2.18.    manager
  2.19.    mobile
  2.20.    organizationalStatus
  2.21.    pager
  2.22.    personalTitle
  2.23.    roomNumber
  2.24.    secretary
  2.26.    uniqueIdentifier
  2.27.    userClass
  3.     COSINE Object Classes                        14
  3.1.     account
  3.2.     document
  3.3.     documentSeries
  3.4.     domain
  3.5.     domainRelatedObject
  3.6.     friendlyCountry



Zeilenga              draft-zeilenga-ldap-cosine-01             [Page 2]

INTERNET-DRAFT                COSINE Schema              23 October 2005


  3.7.     rFC822LocalPart
  3.8.     room
  3.9.     simpleSecurityObject
  4.     Security Considerations                      19
  5.     IANA Considerations                          20
  6.     Acknowledgments                              21
  7.     Editor's Address
  8.     References
  A.     Changes Since RFC 1274                       23
  Intellectual Property Rights                        24
  Full Copyright


1. Background and Intended Use

  In the late 1980s, X.500 Directory Services were standardised by the
  CCITT (Commite' Consultatif International de Telegraphique et
  Telephonique), now a part of the ITU (International Telephone Union).
  This lead to Directory Service piloting activities in the early 1990s,
  including the COSINE (Co-operation and Open Systems Interconnection in
  Europe) PARADISE Project pilot [COSINEpilot] in Europe.  Motivated by
  needs large scale directory pilots, RFC 1274 was published to
  standardize directory schema and naming architecture for use in the
  COSINE and other Internet X.500 pilots [RFC1274].

  In the years that followed, X.500 Directory Services have evolved to
  incorporate new capabilities and even new protocols.  In particular,
  the Lightweight Directory Access Protocol (LDAP) [Roadmap] was
  introduced in the early 1990s [RFC1487], with Version 3 of LDAP
  introduced in the late 1990s [RFC2251] and subsequently revised in the
  2005 [Roadmap].

  While much of the material in RFC 1274 has been superceed by
  subsequently published ITU-T Recommendations and IETF RFCs, many of
  the schema elements lack standardized schema descriptions for use in
  modern X.500 and LDAP directory services despite the fact that these
  schema elements are in wide use today.  As the old schema descriptions
  cannot be used without adaptation, interoperabilty issues may arise
  due to lack of standardized modern schema descriptions.

  This document addresses these issues by offering standardized schema
  descriptions, where needed, for widely-used COSINE schema elements.

1.1.  Relationship to Other Documents

  This document, together with [Schema] and [Syntaxes], obsoletes RFC
  1274 in its entirety.  [Schema] replaces Sections 9.3.1 (Userid) and
  Section 9.3.21 (Domain Component) of RFC 1274.  [Syntaxes] replaces



Zeilenga              draft-zeilenga-ldap-cosine-01             [Page 3]

INTERNET-DRAFT                COSINE Schema              23 October 2005


  section 9.4 (Generally useful syntaxes) of RFC 1274.

  This document replaces the remainder of RFC 1274.  Appendix A.
  discusses changes since RFC 1274, as well as why certain schema
  elements were not brought forward in this revision of the COSINE
  schema.  All elements not brought are to be regarded as Historic.

  This document, together with [NamingPlan] and [Schema], obsoletes RFC
  2247 in its entirety.  [Schema] replaces Section 4 (Attribute Type
  Definition) and Section 5.1 (The dcObject object class) of RFC 2247.
  This document replaces Section 5.2 (The domain object class) of RFC
  2247.  The remainder of RFC 2247 is replaced by [NamingPlan].

  Some of these items were described in RFC 2798 (inetOrgPerson schema).
  This document supersedes these descriptions.  This document, together
  with [Schema], replaces section 9.1.3 of RFC 2798.


1.2. Terminology and Conventions

  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].

  DIT stands for Directory Information Tree.
  DN stands for Distinguished Name.
  DSA stands for Directory System Agent, a server.
  DSE stands for DSA-Specific Entry.
  DUA stands for Directory User Agent, a client.

  These terms are discussed in [Models].

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


2. COSINE Attribute Types

  This section details COSINE attribute types for use in LDAP.


2.1. associatedDomain

  The 'associatedDomain' attribute specifies DNS domains [RFC1034] which
  are associated with an object.  For example, the entry in the DIT with
  a DN <DC=example,DC=com> might have an associated domain of
  "example.com".



Zeilenga              draft-zeilenga-ldap-cosine-01             [Page 4]

INTERNET-DRAFT                COSINE Schema              23 October 2005


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

  The IA5String (1.3.6.1.4.1.1466.115.121.1.26) syntax and the
  'caseIgnoreIA5Match' and 'caseIgnoreIA5SubstringsMatch' rules are
  described in [Syntaxes].

  It is noted that the directory will not ensure that values of this
  attribute conform to the <domain> production [RFC1034].  It is the
  application responsibility to ensure domains it stores in this
  attribute are appropriately represented.

  It is also noted that applications supporting Internationalized Domain
  Names SHALL use the ToASCII method [RFC3490] to produce <label>
  components of the <domain> production.


2.2. associatedName

  The 'associatedName' attribute specifies names of entries in the
  organizational DIT associated with a DNS domain [RFC1034].

      ( 0.9.2342.19200300.100.1.38 NAME 'associatedName'
        EQUALITY distinguishedNameMatch
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )

  The DistinguishedName (1.3.6.1.4.1.1466.115.121.1.12) syntax and the
  'distinguishedNameMatch' rule are described in [Syntaxes].


2.3.  buildingName

  The 'buildingName' attribute specifies names of the buildings where an
  organization or organizational unit is based.  For example, "The White
  House".

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

  The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the
  'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described
  in [Syntaxes].





Zeilenga              draft-zeilenga-ldap-cosine-01             [Page 5]

INTERNET-DRAFT                COSINE Schema              23 October 2005


2.3. co

  The 'co' (Friendly Country Name) attribute specifies names of
  countries in human-readable format.  For example, "Germany" and
  "Federal Republic of Germany".  It is commonly used in conjunction
  with the 'c' (Country Name) [Schema] attribute (whose values are
  restricted to the two-letter codes defined in [ISO3166]).

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

  The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the
  'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described
  in [Syntaxes].


2.5. documentAuthor

  The 'documentAuthor' attribute specifies the distinguished name of
  authors (or editors) of a document.  For example,

      ( 0.9.2342.19200300.100.1.14 NAME 'documentAuthor'
        EQUALITY distinguishedNameMatch
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )

  The DistinguishedName (1.3.6.1.4.1.1466.115.121.1.12) syntax and the
  'distinguishedNameMatch' rule are described in [Syntaxes].


2.6. documentIdentifier

  The 'documentIdentifier' attribute specifies unique identifiers for a
  document.  A document may be identified by more than one unique
  identifier.  For example, RFC 3383 and BCP 64 are unique identifers
  which (presently) refer to the same document.

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

  The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the
  'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described
  in [Syntaxes].





Zeilenga              draft-zeilenga-ldap-cosine-01             [Page 6]

INTERNET-DRAFT                COSINE Schema              23 October 2005


2.7. documentLocation

  The 'documentLocation' attribute specifies locations of the document
  original.

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

  The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the
  'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described
  in [Syntaxes].


2.8. documentPublisher

  The 'documentPublisher' attribute is the persons and/or organizations
  that published the document.  Documents which are jointly published
  have one value for each publisher.

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

  The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the
  'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described
  in [Syntaxes].


2.9. documentTitle

  The 'documentTitle' attribute specifies the titles of a document.
  Multiple values are allowed to accomadate both long and short titles,
  or other situations where a document has multiple titles.  For
  example, "The Lightweight Directory Access Protocol Technical
  Specification" and "The LDAP Technical Specification".

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

  The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the
  'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described
  in [Syntaxes].




Zeilenga              draft-zeilenga-ldap-cosine-01             [Page 7]

INTERNET-DRAFT                COSINE Schema              23 October 2005


2.10. documentVersion

  The 'documentVersion' attribute specifies the version information of a
  document.

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

  The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the
  'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described
  in [Syntaxes].


2.11. drink

  The 'drink' (favoriteDrink) attribute specifies favorite drinks of an
  object (or person).  For instance, "cola" and "beer".

      ( 0.9.2342.19200300.100.1.5 NAME 'drink'
        EQUALITY caseIgnoreMatch
        SUBSTR caseIgnoreSubstringsMatch
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )

  The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the
  'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described
  in [Syntaxes].


2.12. homePhone

  The 'homePhone' (Home Telephone Number) attribute specifies home
  telephone numbers (e.g., "+1 775 555 1234") associated with a person.

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

  The telephoneNumber (1.3.6.1.4.1.1466.115.121.1.50) syntax and the
  'telephoneNumberMatch' and 'telephoneNumberSubstringsMatch' rules are
  described in [Syntaxes].


2.13. homePostalAddress

  The 'homePostalAddress' attribute specifies home postal addresses for



Zeilenga              draft-zeilenga-ldap-cosine-01             [Page 8]

INTERNET-DRAFT                COSINE Schema              23 October 2005


  an object.  Each value should be limited to up to 6 directory strings
  of 30 characters each.  (Note: it is not intended that the directory
  service enforce these limits.)


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

  The PostalAddress (1.3.6.1.4.1.1466.115.121.1.41) syntax and the
  'caseIgnoreListMatch' and 'caseIgnoreListSubstringsMatch' rules are
  described in [Syntaxes].


2.14. host

  The 'host' attribute specifies host computers, generally by their
  primary fully-qualified domain name (e.g., my-host.example.com).

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

  The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the
  'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described
  in [Syntaxes].


2.16. info

  The 'info' attribute specifies any general information pertinent to an
  object.  This information is not necessarily descriptive of the
  object.

  Applications should not attach specific semantics to values of this
  attribute.  The 'description' attribute [Schema] is available for
  specifying descriptive information pertinent to an object.

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

  The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the
  'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described
  in [Syntaxes].



Zeilenga              draft-zeilenga-ldap-cosine-01             [Page 9]

INTERNET-DRAFT                COSINE Schema              23 October 2005


2.17. mail

  The 'mail' (rfc822mailbox) attribute type holds Internet mail
  addresses in Mailbox [RFC2821] form (e.g.: user@example.com).

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

  The IA5String (1.3.6.1.4.1.1466.115.121.1.26) syntax and the
  'caseIgnoreIA5Match' and 'caseIgnoreIA5SubstringsMatch' rules are
  described in [Syntaxes].

  It is noted that the directory will not ensure that values of this
  attribute conform to the <Mailbox> production [RFC2821].  It is the
  application responsibility to ensure domains it stores in this
  attribute are appropriately represented.

  Additionally, the directory will compare values per the matching rules
  named in the above attribute type description.  As these rules differ
  from rules which normally apply to <Mailbox> comparisons, operational
  issues may arise.  For example, the assertion (mail=joe@example.com)
  will match "JOE@example.com" even though the <local-parts> differ.
  Also, where a user has two <Mailbox>es which whose addresses differ
  only by case of the <local-part>, both cannot be listed as values of
  the user's mail attribute (as they are considered by the
  'caseIgnoreIA5Match' rule to be equal).

  It is also noted that applications supporting internationalized domain
  names SHALL use the ToASCII method [RFC3490] to produce <sub-domain>
  components of the <Mailbox> production.


2.18. manager

  The 'manager' attribute specifies managers, by distinguished name, of
  the person (or entity).

      ( 0.9.2342.19200300.100.1.10 NAME 'manager'
        EQUALITY distinguishedNameMatch
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )

  The DistinguishedName (1.3.6.1.4.1.1466.115.121.1.12) syntax and the
  'distinguishedNameMatch' rule are described in [Syntaxes].


2.19. mobile



Zeilenga              draft-zeilenga-ldap-cosine-01            [Page 10]

INTERNET-DRAFT                COSINE Schema              23 October 2005


  The 'mobile' (mobileTelephoneNumber) attribute specifies mobile
  telephone numbers (e.g., "+1 775 555 6789") associated with a person
  (or entity).

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

  The telephoneNumber (1.3.6.1.4.1.1466.115.121.1.50) syntax and the
  'telephoneNumberMatch' and 'telephoneNumberSubstringsMatch' rules are
  described in [Syntaxes].


2.20. organizationalStatus

  The 'organizationalStatus' attribute specifies categories by which a
  person is often referred to in an organization.  Examples of usage in
  academia might include "undergraduate student", "researcher",
  "professor", "staff", etc..  Multiple values are allowed were the
  person is in multiple categories.

  Directory administrators and application designers SHOULD consider
  carefully the distinctions between this and the 'title' and
  'userClass' attributes.

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

  The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the
  'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described
  in [Syntaxes].


2.21. pager

  The 'pager' (pagerTelephoneNumber) attribute specifies pager telephone
  numbers (e.g., "+1 775 555 5555") for an object.

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

  The telephoneNumber (1.3.6.1.4.1.1466.115.121.1.50) syntax and the
  'telephoneNumberMatch' and 'telephoneNumberSubstringsMatch' rules are



Zeilenga              draft-zeilenga-ldap-cosine-01            [Page 11]

INTERNET-DRAFT                COSINE Schema              23 October 2005


  described in [Syntaxes].


2.22. personalTitle

  The 'personalTitle' attribute specifies personal titles for a person.
  Examples of personal titles are "Frau", "Dr.", "Herr", and
  "Professor".

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

  The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the
  'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described
  in [Syntaxes].


2.23. roomNumber

  The 'roomNumber' attribute specifies the room number of an object.
  During periods of renumbering or in other circumstances where a room
  has multiple valid room numbers associated with it, multiple values
  may be provided.  Note that the 'cn' (commonName) attribute type
  SHOULD be used for naming room objects.

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

  The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the
  'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described
  in [Syntaxes].


2.24. secretary

  The 'secretary' attribute specifies secretaries and/or administrative
  assistants, by distinguish name, of a person.

      ( 0.9.2342.19200300.100.1.21 NAME 'secretary'
        EQUALITY distinguishedNameMatch
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )

  The DistinguishedName (1.3.6.1.4.1.1466.115.121.1.12) syntax and the
  'distinguishedNameMatch' rule are described in [Syntaxes].



Zeilenga              draft-zeilenga-ldap-cosine-01            [Page 12]

INTERNET-DRAFT                COSINE Schema              23 October 2005


2.26. uniqueIdentifier

  The 'uniqueIdentifier' attribute 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, 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.

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

  The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the
  'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described
  in [Syntaxes].

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


2.27. userClass

  The 'userClass' attribute specifies categories of computer or
  application user.  The semantics placed on this attribute are for
  local interpretation.  Examples of current usage of this attribute in
  academia are "student", "staff", "faculty", etc..  Note that the
  'organizationalStatus' attribute type is now often be preferred as it
  makes no distinction between persons as opposed to users.

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

  The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the
  'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described
  in [Syntaxes].


3. COSINE Object Classes

  This section details COSINE object classes for use in LDAP.





Zeilenga              draft-zeilenga-ldap-cosine-01            [Page 13]

INTERNET-DRAFT                COSINE Schema              23 October 2005


3.1. account

  The 'account' object class is used to define entries representing
  computer accounts.  The 'uid' attribute SHOULD be used for naming
  entries of this object class.

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

  The 'top' object class is described in [Models].  The 'description',
  'seeAlso', 'l', 'o', 'ou', and 'uid' attribute types are described in
  [Schema].  The 'host' attribute type is described in Section 2 of this
  document.

  Example:

      dn: uid=kdz,cn=Accounts,dc=Example,dc=COM
      objectClass: account
      uid: kdz
      seeAlso: cn=Kurt D. Zeilenga,cn=Persons,dc=Example,dc=COM


3.2. document

  The 'document' object class is used to define entries which represent
  documents.

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

  The 'top' object class is described in [Models].  The 'cn',
  'description', 'seeAlso', 'l', 'o', and 'ou' attribute types are
  described in [Schema].  The 'documentIdentifier', 'documentTitle',
  'documentVersion', 'documentAuthor', 'documentLocation', and
  'documentPublisher' attribute types are described in Section 2 of this
  document.

  Example:

      dn: documentIdentifier=RFCXXXX,cn=RFC,dc=Example,dc=COM
      objectClass: document
      documentIdentifier: RFC XXXXX



Zeilenga              draft-zeilenga-ldap-cosine-01            [Page 14]

INTERNET-DRAFT                COSINE Schema              23 October 2005


      documentTitle: COSINE LDAP/X.500 Schema
      documentAuthor: cn=Kurt D. Zeilenga,cn=Persons,dc=Example,dc=COM
      documentLocation: http://www.rfc-editor.org/rfc/rfcXXXX.txt
      documentPublisher: Internet Engineering Task Force
      description: A collection of schema elements for use in LDAP
      description: Obsoletes RFC 1274
      seeAlso: documentIdentifier=[Roadmap],cn=RFC,dc=Example,dc=COM
      seeAlso: documentIdentifier=RFC 1274,cn=RFC,dc=Example,dc=COM


3.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).

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

  The 'top' object class is described in [Models].  The 'description',
  'l', 'o', 'ou', 'seeAlso', and 'telephoneNumber' attribute types are
  described in [Schema].

  Example:

      dn: cn=RFC,dc=Example,dc=COM
      objectClass: documentSeries
      cn: Request for Comments
      cn: RFC
      description: a series of memos about the Internet


3.4. domain

  The 'domain' object class is used to define entries which represent
  DNS domains for objects which are not organizations, organizational
  units, or other kinds of objects more approproiately defined using an
  object class specific to the kind of object being defined (e.g.,
  'organization', 'organizationUnit', etc.).

  The 'dc' attribute should be used for naming entries of 'domain'
  object class.

      ( 0.9.2342.19200300.100.4.13 NAME 'domain'
        SUP top STRUCTURAL



Zeilenga              draft-zeilenga-ldap-cosine-01            [Page 15]

INTERNET-DRAFT                COSINE Schema              23 October 2005


        MUST dc
        MAY ( userPassword $ searchGuide $ seeAlso $ businessCategory $
          x121Address $ registeredAddress $ destinationIndicator $
          preferredDeliveryMethod $ telexNumber $
          teletexTerminalIdentifier $ telephoneNumber $
          internationaliSDNNumber $ facsimileTelephoneNumber $ street $
          postOfficeBox $ postalCode $ postalAddress $
          physicalDeliveryOfficeName $ st $ l $ description $ o $
          associatedName ) )

  The 'top' object class and the 'dc', 'userPassword', 'searchGuide
  'seeAlso', 'businessCategory', 'x121Address', 'registeredAddress
  'destinationIndicator', 'preferredDeliveryMethod', 'telexNumber',
  'teletexTerminalIdentifier', 'telephoneNumber',
  'internationaliSDNNumber', 'facsimileTelephoneNumber', 'street',
  'postOfficeBox', 'postalCode', 'postalAddress',
  'physicalDeliveryOfficeName', 'st', 'l', 'description', 'o', types are
  described in [Schema].  The 'associatedName' attribute type is
  described in Section 2 of this document.

  Example:
      dn: dc=com
      objectClass: domain
      dc: com
      description: the .COM TLD


3.5.  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.

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

  The 'top' object class is described in [Models].  The
  'associatedDomain' attribute type is described in Section 2 of this
  document.

  Example:

      dn: dc=example,dc=com
      objectClass: organization
      objectClass: dcObject
      objectClass: domainRelatedObject
      dc: example



Zeilenga              draft-zeilenga-ldap-cosine-01            [Page 16]

INTERNET-DRAFT                COSINE Schema              23 October 2005


      associatedDomain: example.com
      o: Example Organization

  The 'organization' and 'dcObject' object classes and the 'dc' and 'o'
  attribute types are described in [Schema].


3.5.  friendlyCountry

  The 'friendlyCountry' object class is used to define entries
  representing countries in the DIT.  The object class is used to allow
  friendlier naming of countries than that allowed by the object class
  'country' [Schema].

      ( 0.9.2342.19200300.100.4.18 NAME 'friendlyCountry'
        SUP country STRUCTURAL
        MUST co )

  The 'country' object class is described in [Schema].  The 'co'
  attribute type is described in Section 2 of this document.

  Example:

      dn: c=DE
      objectClass: country
      objectClass: friendlyCountry
      c: DE
      co: Deutschland
      co: Germany
      co: Federal Republic of Germany
      co: FRG

  The 'c' attribute type is described in [Schema].


3.6.  rFC822LocalPart

  The 'rFC822LocalPart' object class is used to define entries which
  represent the local part of Internet mail addresses [RFC2822].  This
  treats the local part of the address as a 'domain' object.

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



Zeilenga              draft-zeilenga-ldap-cosine-01            [Page 17]

INTERNET-DRAFT                COSINE Schema              23 October 2005


          teletexTerminalIdentifier $ telexNumber $ x121Address ) )

  The 'domain' object class is described in Section 3.4 of this
  document.  The 'cn', 'description', 'destinationIndicator',
  'facsimileTelephoneNumber', 'internationaliSDNNumber,
  'physicalDeliveryOfficeName', 'postalAddress', 'postalCode',
  'postOfficeBox', 'preferredDeliveryMethod', 'registeredAddress',
  'seeAlso', 'sn, 'street', 'telephoneNumber',
  'teletexTerminalIdentifier', 'telexNumber' and 'x121Address' attribute
  types are described in [Schema].


  Example:

      dn: dc=kdz,dc=example,dc=com
      objectClass: domain
      objectClass: rFC822LocalPart
      dc: kdz
      associatedName: cn=Kurt D. Zeilenga,cn=Persons,dc=Example,dc=COM

  The 'dc' attribute type is described in [Schema].


3.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.

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

  The 'top' object class is described in [Models].  The 'cn',
  'description', 'seeAlso' and 'telephoneNumber' attribute types are
  described in [Schema].  The 'roomNumber' attribute type is described
  in Section 2 of this document.

      dn: cn=conference room,dc=example,dc=com
      objectClass: room
      cn: conference room
      telephoneNumber: +1 755 555 1111


3.8.  simpleSecurityObject

  The 'simpleSecurityObject' object class is used to require an entry to



Zeilenga              draft-zeilenga-ldap-cosine-01            [Page 18]

INTERNET-DRAFT                COSINE Schema              23 October 2005


  have an 'userPassword' attribute when the entry's structural object
  class does not require (or allow) the 'userPassword attribute'.

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

  The 'top' object class is described in [Models].  The 'userPassword'
  attribute type is described in [Schema].

      dn: dc=kdz,dc=Example,dc=COM
      objectClass: account
      objectClass: simpleSecurityObject
      uid: kdz
      userPassword: My Password
      seeAlso: cn=Kurt D. Zeilenga,cn=Persons,dc=Example,dc=COM


4. Security Considerations

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

  Directories administrators should ensure that access to sensitive
  information is restricted to authorized entities, but ensure that
  appropriate data security services, including data integrity and data
  confidentiality, are used to protect against eavesdropping.

  Simple authentication (e.g., plain text passwords) mechanisms should
  only be used when adequate data security services are in place.  LDAP
  offers reasonable strong authentication and data security services
  [AuthMeth].



5. IANA Considerations

  It is requested that the Internet Assigned Numbers Authority (IANA)
  update upon Standard Action the LDAP descriptors registry [BCP64bis]
  as indicated the following template:

      Subject: Request for LDAP Descriptor Registration Update
      Descriptor (short name): see comment
      Object Identifier: see comments
      Person & email address to contact for further information:
          Kurt Zeilenga <kurt@OpenLDAP.org>
      Usage: see comments



Zeilenga              draft-zeilenga-ldap-cosine-01            [Page 19]

INTERNET-DRAFT                COSINE Schema              23 October 2005


      Specification: RFC XXXX
      Author/Change Controller: IESG
      Comments:

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

        NAME                           Type OID
        ------------------------       ---- --------------------------
        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
        domain                         O    0.9.2342.19200300.100.4.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
        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
        uniqueIdentifier               A    0.9.2342.19200300.100.1.44



Zeilenga              draft-zeilenga-ldap-cosine-01            [Page 20]

INTERNET-DRAFT                COSINE Schema              23 October 2005


        userClass                      A    0.9.2342.19200300.100.1.8

      where Type A is Attribute and Type O is ObjectClass, and *
      indicates the registration is historic in nature.


6. Acknowledgments

  This document is based upon RFC 1274 by Paul Barker and Steve Kille,
  as well as RFC 2247 by Steve Kill, Mark Wahl, Al Grimstad, Rick Huber,
  and Sri Satulari.


7. Editor's Address

  Kurt D. Zeilenga
  OpenLDAP Foundation

  Email: Kurt@OpenLDAP.org


8. References

  [[Note to the RFC Editor: please replace the citation tags used in
  referencing Internet-Drafts with tags of the form RFCnnnn where
  possible.]]

8.1. Normative References

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

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

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

  [RFC2821]     Klensin, J. (editor), "Simple Mail Transfer Protocol",
                RFC 2822, April 2001.

  [RFC3490]     Faltstrom, P., P. Hoffman, and A. Costello,
                "Internationalizing Domain Names in Applications
                (INDA)", RFC 3490, March 2003.

  [Roadmap]     Zeilenga, K. (editor), "LDAP: Technical Specification
                Road Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in



Zeilenga              draft-zeilenga-ldap-cosine-01            [Page 21]

INTERNET-DRAFT                COSINE Schema              23 October 2005


                progress.

  [Models]      Zeilenga, K. (editor), "LDAP: Directory Information
                Models", draft-ietf-ldapbis-models-xx.txt, a work in
                progress.

  [Syntaxes]    Legg, S. (editor), "LDAP: Syntaxes and Matching Rules",
                draft-ietf-ldapbis-syntaxes-xx.txt, a work in progress.

  [Schema]      Dally, K. (editor), "LDAP: User Schema",
                draft-ietf-ldapbis-user-schema-xx.txt, a work in
                progress.

  [AuthMeth]    Harrison, R. (editor), "LDAP: Authentication Methods and
                Connection Level Security Mechanisms",
                draft-ietf-ldapbis-authmeth-xx.txt, a work in progress.


8.2. Informative References

                [COSINEpilot]

  [NamingPlan]  Zeilenga, K., "The Internet Naming Plan for LDAP/X.500
                Directories", draft-zeilenga-ldap-namingplan-xx.txt, a
                work in progress.

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

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

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

  [BCP64bis]    Zeilenga, K., "IANA Considerations for LDAP",
                draft-ietf-ldapbis-bcp64-xx.txt, a work in progress.


Appendix A.  Changes since RFC 1274

  This document represents a substantial rewrite of RFC 1274.  The
  following sections summarize the substantive changes.

A.1. LDAP Short Names

  A number of COSINE attribute types have short names in LDAP.




Zeilenga              draft-zeilenga-ldap-cosine-01            [Page 22]

INTERNET-DRAFT                COSINE Schema              23 October 2005


  X.500 Name              LDAP Short Name
  -------------           ---------------
  domainComponent         dc
  favoriteDrink           drink
  friendCountryName       co
  homeTelephoneNumber     homePhone
  mobileTelephoneNumber   mobile
  pagerTelephoneNumber    pager
  rfc822Mailbox           mail
  userid                  uid

  While the LDAP short names are generally used in LDAP, some
  implementations may (for legacy reasons [Historic]) recognize the
  attribute type by its X.500 name.  Hence, the X.500 names have been
  reserved solely for this purpose.

  Note: 'uid' and 'dc' are described in [Schema].


A.2. pilotObject

  The 'pilotObject' object class was not brought forward as its function
  is largely replaced by operational attributes introduced in X.500(93)
  [X.501] and version 3 of LDAP [Models].   For instance, the function
  of the 'lastModifiedBy' and 'lastModifiedTime' attribute types is now
  served by the 'creatorsName', 'createTimestamp', 'modifiersName', and
  'modifyTimestamp' operational attributes [Models].


A.3. pilotPerson

  The 'pilotPerson' object class was not brought forward as its function
  is largely replaced by the 'organizationalPerson' [Models] object
  class and its subclasses, such as 'inetOrgPerson' [RFC2798].

  Most of the related attribute types (e.g., 'mail', 'manager', etc.)
  were brought forward as they are used in other object classes.


A.4. dNSDomain

  The 'dNSDomain' object class and related attribute types were not
  brought forward as its use is primarily experimental [RFC1279].


A.5. pilotDSA and qualityLabelledData

  The 'pilotDSA' and 'qualityLabelledData' object classes, as well as



Zeilenga              draft-zeilenga-ldap-cosine-01            [Page 23]

INTERNET-DRAFT                COSINE Schema              23 October 2005


  related attribute types, were not brought forward as it as its use is
  primarily experimental [QoS].


A.6. Attribute syntaxes

  RFC 1274 defined and used caseIgnoreIA5StringSyntax attribute syntax.
  This has been replaced with the IA5String syntax and approrpiate
  matching rules in 'mail' and 'associatedDomain'.

  RFC 1274 restricted 'mail' to have non-zero length values.  This
  restriction is not reflected in the IA5String syntax used in the
  definitions provided in this specification.   However, as values are
  to conform to the <Mailbox> production, the 'mail' should not contain
  zero-length values.  Unfornuately, the directory service will not
  enforce this restriction.


Appendix B. Changes since RFC 2247

  The 'domainNameForm' name form was not brought forward as
  specification of name forms used in LDAP is left to a future
  specification.



Intellectual Property Rights

  The IETF takes no position regarding the validity or scope of any
  Intellectual Property Rights or other rights that might be claimed to
  pertain to the implementation or use of the technology described in
  this document or the extent to which any license under such rights
  might or might not be available; nor does it represent that it has
  made any independent effort to identify any such rights.  Information
  on the procedures with respect to rights in RFC documents can be found
  in BCP 78 and BCP 79.

  Copies of IPR disclosures made to the IETF Secretariat and any
  assurances of licenses to be made available, or the result of an
  attempt made to obtain a general license or permission for the use of
  such proprietary rights by implementers or users of this specification
  can be obtained from the IETF on-line IPR repository at
  http://www.ietf.org/ipr.

  The IETF invites any interested party to bring to its attention any
  copyrights, patents or patent applications, or other proprietary
  rights that may cover technology that may be required to implement
  this standard.  Please address the information to the IETF at



Zeilenga              draft-zeilenga-ldap-cosine-01            [Page 24]

INTERNET-DRAFT                COSINE Schema              23 October 2005


  ietf-ipr@ietf.org.



Full Copyright

  Copyright (C) The Internet Society (2005).

  This document is subject to the rights, licenses and restrictions
  contained in BCP 78, and except as set forth therein, the authors
  retain all their rights.

  This document and the information contained herein are provided on an
  "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
  OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
  ENGINEERING TASK FORCE DISCLAIM 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-cosine-01            [Page 25]

