view Side-By-Side changes

INTERNET-DRAFT                                      Editor:





Network Working Group                                  A. Sciberras
Intended Category:  Standard Track Sciberras, Ed.
Request for Comments: 4519                                       eB2Bcom
Obsoletes: 2256                                                June 2006
Updates:  RFC 2247, RFC 2798, RFC 2377                  January 30, 2006
Obsoletes:  RFC 2256

                   LDAP:
Category: Standards Track


             Lightweight Directory Access Protocol (LDAP):
                      Schema for User Applications
                 draft-ietf-ldapbis-user-schema-11.txt

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

Status of this This Memo

   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.

   By submitting this Internet-Draft, I accept the provisions of Section
   3 of BCP 78.

   Internet-Drafts are working documents of

   This document specifies an Internet standards track protocol for the
   Internet Engineering
   Task Force (IETF), its areas, community, 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 requests discussion and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or suggestions for
   improvements.  Please refer to cite them other than as "work in progress".

   The list of the current Internet-Drafts can be accessed at
   http://www.ietf.org/1id-abstracts.html

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

   This document is intended to be, after appropriate review and
   revision, submitted to the RFC Editor as a Standard Track document. "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this document memo is unlimited.  Technical discussion of
   this document should take place on the IETF LDAP Revision Working
   Group (LDAPbis) mailing list <ietf-ldapbis@openldap.org>.  Please
   send editorial comments directly to the editor
   <andrew.sciberras@eb2bcom.com>.

   This Internet-Draft expires on 30 July 2006.






Sciberras                 Expires 30 July 2006                  [Page 1]

INTERNET-DRAFT     LDAP: Schema for User Applications   January 30, 2006

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   This document is an integral part of the Lightweight Directory Access
   Protocol (LDAP) technical specification [Roadmap]. specification.  It provides a technical
   specification of attribute types and object classes intended for use
   by LDAP directory clients for many directory services, such as, as White
   Pages.  These objects are widely used as a basis for the schema in
   many LDAP directories.  This document does not cover attributes used
   for the administration of directory servers, nor does it include
   directory objects defined for specific uses in other documents.



















Sciberras                 Expires 30 July 2006                   Standards Track                     [Page 2]

INTERNET-DRAFT 1]

RFC 4519           LDAP: Schema for User Applications   January 30,          June 2006


Table of Contents

   Status of this Memo . . . . . . . . . . . . . . . . . . . . . . .   1
   Copyright Notice. . . . . . . . . . . . . . . . . . . . . . . . .   1
   Abstract. . . . . . . . . . . . . . . . . . . . . . . . . . . . .   2
   Table of Contents . . . . . . . . . . . . . . . . . . . . . . . .   3

   1.  Introduction. . . . . . . . . . . . . . . . . . . . . . . . .   5
       1.1 Introduction ....................................................3
      1.1. Relationship with other specifications . . . . . . . . .   5
       1.2  Conventions. . . . . . . . . . . . . . . . . . . . . . .   5
       1.3 Other Specifications .....................3
      1.2. Conventions ................................................4
      1.3. General Issues . . . . . . . . . . . . . . . . . . . . .   5 .............................................4
   2. Attribute Types . . . . . . . . . . . . . . . . . . . . . . .   6
       2.1 .................................................4
      2.1. 'businessCategory' . . . . . . . . . . . . . . . . . . .   6
       2.2  'c'. . . . . . . . . . . . . . . . . . . . . . . . . . .   6
       2.3 .........................................5
      2.2. 'c' ........................................................5
      2.3. 'cn' . . . . . . . . . . . . . . . . . . . . . . . . . .   7
       2.4 .......................................................5
      2.4. 'dc' . . . . . . . . . . . . . . . . . . . . . . . . . .   7
       2.5  'description'. . . . . . . . . . . . . . . . . . . . . .   8
       2.6 .......................................................6
      2.5. 'description' ..............................................6
      2.6. 'destinationIndicator' . . . . . . . . . . . . . . . . .   8
       2.7  'distinguishedName'. . . . . . . . . . . . . . . . . . .   8
       2.8  'dnQualifier'. . . . . . . . . . . . . . . . . . . . . .   9
       2.9  'enhancedSearchGuide'. . . . . . . . . . . . . . . . . .   9
       2.10 .....................................7
      2.7. 'distinguishedName' ........................................7
      2.8. 'dnQualifier' ..............................................8
      2.9. 'enhancedSearchGuide' ......................................8
      2.10. 'facsimileTelephoneNumber' . . . . . . . . . . . . . . .  10
       2.11 'generationQualifier'. . . . . . . . . . . . . . . . . .  10
       2.12 'givenName'. . . . . . . . . . . . . . . . . . . . . . .  10
       2.13 'houseIdentifier'. . . . . . . . . . . . . . . . . . . .  11
       2.14 ................................9
      2.11. 'generationQualifier' .....................................9
      2.12. 'givenName' ...............................................9
      2.13. 'houseIdentifier' .........................................9
      2.14. 'initials' . . . . . . . . . . . . . . . . . . . . . . .  11
       2.15 'internationalISDNNumber'. . . . . . . . . . . . . . . .  11
       2.16 'l'. . . . . . . . . . . . . . . . . . . . . . . . . . .  12
       2.17 ...............................................10
      2.15. 'internationalISDNNumber' ................................10
      2.16. 'l' ......................................................10
      2.17. 'member' . . . . . . . . . . . . . . . . . . . . . . . .  12
       2.18 .................................................11
      2.18. 'name' . . . . . . . . . . . . . . . . . . . . . . . . .  12
       2.19 'o'. . . . . . . . . . . . . . . . . . . . . . . . . . .  13
       2.20 ...................................................11
      2.19. 'o' ......................................................11
      2.20. 'ou' . . . . . . . . . . . . . . . . . . . . . . . . . .  13
       2.21 'owner'. . . . . . . . . . . . . . . . . . . . . . . . .  13
       2.22 .....................................................12
      2.21. 'owner' ..................................................12
      2.22. 'physicalDeliveryOfficeName' . . . . . . . . . . . . . .  13
       2.23 'postalAddress'. . . . . . . . . . . . . . . . . . . . .  14
       2.24 .............................12
      2.23. 'postalAddress' ..........................................13
      2.24. 'postalCode' . . . . . . . . . . . . . . . . . . . . . .  14
       2.25 'postOfficeBox'. . . . . . . . . . . . . . . . . . . . .  14
       2.26 'preferredDeliveryMethod'. . . . . . . . . . . . . . . .  15
       2.27 'registeredAddress'. . . . . . . . . . . . . . . . . . .  15
       2.28 .............................................13
      2.25. 'postOfficeBox' ..........................................14
      2.26. 'preferredDeliveryMethod' ................................14
      2.27. 'registeredAddress' ......................................14
      2.28. 'roleOccupant' . . . . . . . . . . . . . . . . . . . . .  16
       2.29 'searchGuide'. . . . . . . . . . . . . . . . . . . . . .  16
       2.30 'seeAlso'. . . . . . . . . . . . . . . . . . . . . . . .  16
       2.31 ...........................................15
      2.29. 'searchGuide' ............................................15
      2.30. 'seeAlso' ................................................15
      2.31. 'serialNumber' . . . . . . . . . . . . . . . . . . . . .  17
       2.32 ...........................................16
      2.32. 'sn' . . . . . . . . . . . . . . . . . . . . . . . . . .  17
       2.33 .....................................................16
      2.33. 'st' . . . . . . . . . . . . . . . . . . . . . . . . . .  17
       2.34 .....................................................16
      2.34. 'street' . . . . . . . . . . . . . . . . . . . . . . . .  18
       2.35 'telephoneNumber'. . . . . . . . . . . . . . . . . . . .  18
       2.36 'teletexTerminalIdentifier'. . . . . . . . . . . . . . .  18



Sciberras                 Expires 30 July 2006 .................................................17
      2.35. 'telephoneNumber' ........................................17
      2.36. 'teletexTerminalIdentifier' ..............................17
      2.37. 'telexNumber' ............................................18
      2.38. 'title' ..................................................18
      2.39. 'uid' ....................................................18
      2.40. 'uniqueMember' ...........................................19
      2.41. 'userPassword' ...........................................19



Sciberras                   Standards Track                     [Page 3]

INTERNET-DRAFT 2]

RFC 4519           LDAP: Schema for User Applications   January 30,          June 2006


       2.37 'telexNumber'. . . . . . . . . . . . . . . . . . . . . .  19
       2.38 'title'. . . . . . . . . . . . . . . . . . . . . . . . .  19
       2.39 'uid'. . . . . . . . . . . . . . . . . . . . . . . . . .  19
       2.40 'uniqueMember' . . . . . . . . . . . . . . . . . . . . .  19
       2.41 'userPassword' . . . . . . . . . . . . . . . . . . . . .  20
       2.42 'x121Address'. . . . . . . . . . . . . . . . . . . . . .  21
       2.43


      2.42. 'x121Address' ............................................20
      2.43. 'x500UniqueIdentifier' . . . . . . . . . . . . . . . . .  21 ...................................20
   3. Object Classes. . . . . . . . . . . . . . . . . . . . . . . .  22
       3.1 Classes .................................................20
      3.1. 'applicationProcess' . . . . . . . . . . . . . . . . . .  22
       3.2  'country'. . . . . . . . . . . . . . . . . . . . . . . .  22
       3.3 ......................................21
      3.2. 'country' .................................................21
      3.3. 'dcObject' . . . . . . . . . . . . . . . . . . . . . . .  22
       3.4 ................................................21
      3.4. 'device' . . . . . . . . . . . . . . . . . . . . . . . .  23
       3.5 ..................................................21
      3.5. 'groupOfNames' . . . . . . . . . . . . . . . . . . . . .  23
       3.6 ............................................22
      3.6. 'groupOfUniqueNames' . . . . . . . . . . . . . . . . . .  23
       3.7 ......................................22
      3.7. 'locality' . . . . . . . . . . . . . . . . . . . . . . .  24
       3.8 ................................................23
      3.8. 'organization' . . . . . . . . . . . . . . . . . . . . .  24
       3.9 ............................................23
      3.9. 'organizationalPerson' . . . . . . . . . . . . . . . . .  24
       3.10 ....................................24
      3.10. 'organizationalRole' . . . . . . . . . . . . . . . . . .  25
       3.11 .....................................24
      3.11. 'organizationalUnit' . . . . . . . . . . . . . . . . . .  25
       3.12 .....................................24
      3.12. 'person' . . . . . . . . . . . . . . . . . . . . . . . .  26
       3.13 'residentialPerson'. . . . . . . . . . . . . . . . . . .  26
       3.14 'uidObject'. . . . . . . . . . . . . . . . . . . . . . .  26 .................................................25
      3.13. 'residentialPerson' ......................................25
      3.14. 'uidObject' ..............................................26
   4. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  27 ............................................26
   5. Security Considerations . . . . . . . . . . . . . . . . . . .  28 ........................................28
   6.  Acknowledgements. . . . . . . . . . . . . . . . . . . . . . .  29 Acknowledgements ...............................................28
   7.  References. . . . . . . . . . . . . . . . . . . . . . . . . .  30
       7.1  Normative. . . . . . . . . . . . . . . . . . . . . . . .  30
       7.2  Informative. . . . . . . . . . . . . . . . . . . . . . .  31

   8.  Author's Address. . . . . . . . . . . . . . . . . . . . . . .  31

   9.  Intellectual Property Statement . . . . . . . . . . . . . . .  32

   10. Full Copyright Statement. . . . . . . . . . . . . . . . . . .  32












Sciberras                 Expires 30 July 2006                  [Page 4]

INTERNET-DRAFT     LDAP: Schema for User Applications   January 30, 2006 References .....................................................29
      7.1. Normative References ......................................29
      7.2. Informative References ....................................30
   Appendix A  Changes Made Since RFC 2256 ...........................32

1.  Introduction

   This document provides an overview of attribute types and object
   classes intended for use by Lightweight Directory Access Protocol
   (LDAP) directory clients for many directory services, such as, as White
   Pages.  Originally specified in the X.500 [X.500] documents, these
   objects are widely used as a basis for the schema in many LDAP
   directories.  This document does not cover attributes used for the
   administration of directory servers, nor does it include directory
   objects defined for specific uses in other documents.

1.1

1.1.  Relationship with other specifications Other Specifications

   This document is an integral part of the LDAP technical specification
   [Roadmap]
   [RFC4510], which obsoletes the previously defined LDAP technical
   specification, RFC 3377, in its entirety.  In terms of RFC 2256,
   Sections 6 and 8 of RFC 2256 are obsoleted by [Syntaxes]. [RFC4517].  Sections
   5.1, 5.2, 7.1 7.1, and 7.2 of RFC 2256 are obsoleted by [Models]. [RFC4512].  The
   remainder of RFC 2256 is obsoleted by this document.  Section 2.4 of
   this document supersedes the  The technical
   specification for the 'dc' attribute type and 'dcObject' object class
   found in RFC 2247. 2247 are superseded by sections 2.4 and 3.3 of this
   document.  The remainder of RFC 2247 remains in force.




Sciberras                   Standards Track                     [Page 3]

RFC 4519           LDAP: Schema for User Applications          June 2006


   This document updates RFC 2798 by replacing the informative
   description of the 'uid' attribute type, type with the definitive
   description provided in Section 2.39 of this document.

   This document updates RFC 2377 by replacing the informative
   description of the 'uidObject' object class with the definitive
   description provided in Section 3.14 of this document.

   A number of schema elements which that were included in the previous
   revision of the LDAP Technical Specification are not included in this
   revision of LDAP.  PKI-related schema elements are now specified in
   [LDAP-PKI].
   [RFC4523].  Unless reintroduced in future technical specifications,
   the remainder are to be considered Historic.

   The descriptions in this document SHALL be considered definitive for
   use in LDAP.

1.2

1.2.  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 RFC 2119 [RFC2119].

1.3

1.3.  General Issues

   This document references Syntaxes defined in Section 3 of [Syntaxes] [RFC4517]
   and Matching Rules defined in Section 4 of [Syntaxes]. [RFC4517].

   The definitions of Attribute Types and Object Classes are written



Sciberras                 Expires 30 July 2006                  [Page 5]

INTERNET-DRAFT     LDAP: Schema for User Applications   January 30, 2006
   using the Augmented Backus-Naur Form (ABNF) [RFC4234] of
   AttributeTypeDescription and ObjectClassDescription given in
   [Models].
   [RFC4512].  Lines have been folded for readability.  When such values
   are transferred as attribute values in the LDAP Protocol Protocol, the values
   will not contain line breaks.

2.  Attribute Types

   The Attribute Types attribute types contained in this section hold user information.

   There is no requirement that servers implement the 'searchGuide' and
   'teletexTerminalIdentifier' attribute types.  In fact, their use is
   greatly discouraged.

   An LDAP server implementation SHOULD recognize the rest of the
   attribute types described in this section.

2.1






Sciberras                   Standards Track                     [Page 4]

RFC 4519           LDAP: Schema for User Applications          June 2006


2.1.  'businessCategory'

   The 'businessCategory' attribute type describes the kinds of business
   performed by an organization.  Each kind is one value of this
   multi-valued attribute.
   (Source: X.520 [X.520])

      ( 2.5.4.15 NAME 'businessCategory'
         EQUALITY caseIgnoreMatch
         SUBSTR caseIgnoreSubstringsMatch
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

   1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax
   [Syntaxes].
   [RFC4517].

   Examples: "banking", "transportation" "transportation", and "real estate".

2.2

2.2.  'c'

   The 'c' ('countryName' in X.500) attribute type contains a two-letter
   ISO 3166 [ISO3166] country code.
   (Source: X.520 [X.520])

      ( 2.5.4.6 NAME 'c'
         SUP name
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.11
         SINGLE-VALUE )

   1.3.6.1.4.1.1466.115.121.1.11 refers to the Country String syntax
   [Syntaxes].




Sciberras                 Expires 30 July 2006                  [Page 6]

INTERNET-DRAFT     LDAP: Schema for User Applications   January 30, 2006
   [RFC4517].

   Examples: "DE", "AU" and "FR".

2.3

2.3.  'cn'

   The 'cn' ('commonName' in X.500) attribute type contains names of an
   object.  Each name is one value of this multi-valued attribute.  If
   the object corresponds to a person, it is typically the person's full
   name.
   (Source: X.520 [X.520])

      ( 2.5.4.3 NAME 'cn'
         SUP name )

   Examples: "Martin K Smith", "Marty Smith" and "printer12".

2.4






Sciberras                   Standards Track                     [Page 5]

RFC 4519           LDAP: Schema for User Applications          June 2006


2.4.  'dc'

   The 'dc' ('domainComponent' in RFC 2247) 1274) attribute type is a string
   holding one component, a label, of a DNS domain name [RFC1034].
   [RFC1034][RFC2181] naming a host [RFC1123].  That is, a value of this
   attribute is a string of ASCII characters adhering to the following
   ABNF [RFC4234]:

   label = (ALPHA / DIGIT) [*61(ALPHA / DIGIT / HYPHEN) (ALPHA / DIGIT)]
   ALPHA   = %x41-5A / %x61-7A     ; "A"-"Z" / "a"-"z"
   DIGIT   = %x30-39               ; "0"-"9"
   HYPHEN  = %x2D                  ; hyphen ("-")

   The encoding of IA5String for use in LDAP is simply the characters of
   the ASCII label.  The equality matching rule is case insensitive, as
   is today's DNS.  (Source: RFC 2247 [RFC2247]) [RFC2247] and RFC 1274 [RFC 1274])

      ( 0.9.2342.19200300.100.1.25 NAME 'dc'
         EQUALITY caseIgnoreIA5Match
         SUBSTR caseIgnoreIA5SubstringsMatch
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
         SINGLE-VALUE )

   1.3.6.1.4.1.1466.115.121.1.26 refers to the IA5 String syntax
   [Syntaxes].
   [RFC4517].

   Examples: Valid values include "example" and "com". "com" but not
   "example.com".  The value
             "example.com" latter is invalid, because invalid as it contains two label multiple domain
   components.

   It is noted that the directory service will not ensure that values of
   this attribute conform to the host label restrictions [RFC1123]
   illustrated by the <label> production provided above.  It is the
   directory client's responsibility to ensure that the labels it stores
   in this attribute are appropriately restricted.

   Directory applications supporting International Domain Names SHALL
   use the ToASCII method [RFC3490] to produce the domain name component
   label.  The special considerations discussed in section Section 4 of RFC 3490
   [RFC3490] should be taken, depending on whether the domain component
   is used for "stored" or "query" purposes.









Sciberras                 Expires 30 July 2006                  [Page 7]

INTERNET-DRAFT     LDAP: Schema for User Applications   January 30, 2006


2.5

2.5.  'description'

   The 'description' attribute type contains human-readable descriptive
   phrases about the object.  Each description is one value of this
   multi-valued attribute.
   (Source: X.520 [X.520])



Sciberras                   Standards Track                     [Page 6]

RFC 4519           LDAP: Schema for User Applications          June 2006


      ( 2.5.4.13 NAME 'description'
         EQUALITY caseIgnoreMatch
         SUBSTR caseIgnoreSubstringsMatch
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

   1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax
   [Syntaxes].
   [RFC4517].

   Examples: "a color printer", "Maintenance is done every Monday, at
             1pm."
             1pm.", and "distribution list for all technical staff".

2.6

2.6.  'destinationIndicator'

   The 'destinationIndicator' attribute type contains country and city
   strings,
   strings associated with the object (the addressee), addressee) needed to provide
   the Public Telegram Service.  The strings are composed in accordance
   with CCITT Recommendations F.1 [F.1] and F.31 [F.31].  Each string is
   one value of this multi-valued attribute.
   (Source: X.520 [X.520])

      ( 2.5.4.27 NAME 'destinationIndicator'
         EQUALITY caseIgnoreMatch
         SUBSTR caseIgnoreSubstringsMatch
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 )

   1.3.6.1.4.1.1466.115.121.1.44 refers to the Printable String syntax
   [Syntaxes].
   [RFC4517].

   Examples: "AASD" as a destination indicator for Sydney, Australia.
             "GBLD" as a destination indicator for London, United
             Kingdom.

   It is noted that the directory will not ensure that values of this
   attribute conform to the F.1 and F.30 F.31 CCITT Recommendations.  It is
   the application's responsibility to ensure destination indicators
   that it stores in this attribute are appropriately constructed.

2.7

2.7.  'distinguishedName'

   The 'distinguishedName' attribute type is not used as the name of the
   object itself, but it is instead a base type from which some user



Sciberras                 Expires 30 July 2006                  [Page 8]

INTERNET-DRAFT     LDAP: Schema for User Applications   January 30, 2006
   attribute types with a DN syntax can inherit.

   It is unlikely that values of this type itself will occur in an
   entry.  LDAP server implementations which that do not support attribute
   subtyping need not recognize this attribute in requests.  Client
   implementations MUST NOT assume that LDAP servers are capable of
   performing attribute subtyping.



Sciberras                   Standards Track                     [Page 7]

RFC 4519           LDAP: Schema for User Applications          June 2006


   (Source: X.520 [X.520])

      ( 2.5.4.49 NAME 'distinguishedName'
         EQUALITY distinguishedNameMatch
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )

   1.3.6.1.4.1.1466.115.121.1.12 refers to the DN syntax [Syntaxes].

2.8 [RFC4517].

2.8.  'dnQualifier'

   The 'dnQualifier' attribute type contains disambiguating information
   strings to add to the relative distinguished name of an entry.  The
   information is intended for use when merging data from multiple
   sources in order to prevent conflicts between entries which that would
   otherwise have the same name.  Each string is one value of this
   multi-valued attribute.  It is recommended that a value of the
   'dnQualifier' attribute be the same for all entries from a particular
   source.
   (Source: X.520 [X.520])

      ( 2.5.4.46 NAME 'dnQualifier'
         EQUALITY caseIgnoreMatch
         ORDERING caseIgnoreOrderingMatch
         SUBSTR caseIgnoreSubstringsMatch
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 )

   1.3.6.1.4.1.1466.115.121.1.44 refers to the Printable String syntax
   [Syntaxes].
   [RFC4517].

   Examples: "20050322123345Z" - timestamps can be used to disambiguate
             information.
             "123456A" - serial numbers can be used to disambiguate
             information.

2.9

2.9.  'enhancedSearchGuide'

   The 'enhancedSearchGuide' attribute type contains sets of information
   for use by directory clients in constructing search filters.  Each
   set is one value of this multi-valued attribute.
   (Source: X.520 [X.520])




Sciberras                 Expires 30 July 2006                  [Page 9]

INTERNET-DRAFT     LDAP: Schema for User Applications   January 30, 2006

      ( 2.5.4.47 NAME 'enhancedSearchGuide'
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.21 )

   1.3.6.1.4.1.1466.115.121.1.21 refers to the Enhanced Guide syntax
   [Syntaxes].
   [RFC4517].





Sciberras                   Standards Track                     [Page 8]

RFC 4519           LDAP: Schema for User Applications          June 2006


   Examples: "person#(sn$APPROX)#wholeSubtree" and
             "organizationalUnit#(ou$SUBSTR)#oneLevel".

2.10

2.10.  'facsimileTelephoneNumber'

   The 'facsimileTelephoneNumber' attribute type contains telephone
   numbers (and, optionally, the parameters) for facsimile terminals.
   Each telephone number is one value of this multi-valued attribute.
   (Source: X.520 [X.520])

      ( 2.5.4.23 NAME 'facsimileTelephoneNumber'
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.22 )

   1.3.6.1.4.1.1466.115.121.1.22 refers to the Facsimile Telephone
   Number syntax [Syntaxes]. [RFC4517].

   Examples: "+61 3 9896 7801" and "+81 3 347 7418$fineResolution".

2.11

2.11.  'generationQualifier'

   The 'generationQualifier' attribute type contains name strings that
   are typically the suffix part of a person's name which typically is the suffix. name.  Each string is one
   value of this multi-valued attribute.
   (Source: X.520 [X.520])

      ( 2.5.4.44 NAME 'generationQualifier'
         SUP name )

   Examples: "III", "3rd" "3rd", and "Jr.".

2.12

2.12.  'givenName'

   The 'givenName' attribute type contains name strings that are the
   part of a person's name which that is not their surname.  Each string is
   one value of this multi-valued attribute.
   (Source: X.520 [X.520])

      ( 2.5.4.42 NAME 'givenName'
         SUP name )

   Examples: "Andrew", "Charles" "Charles", and "Joanne".




Sciberras                 Expires 30 July 2006                 [Page 10]

INTERNET-DRAFT     LDAP: Schema for User Applications   January 30, 2006


2.13

2.13.  'houseIdentifier'

   The 'houseIdentifier' attribute type contains identifiers for a
   building within a location.  Each identifier is one value of this
   multi-valued attribute.
   (Source: X.520 [X.520])



Sciberras                   Standards Track                     [Page 9]

RFC 4519           LDAP: Schema for User Applications          June 2006


      ( 2.5.4.51 NAME 'houseIdentifier'
         EQUALITY caseIgnoreMatch
         SUBSTR caseIgnoreSubstringsMatch
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

   1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax
   [Syntaxes].

   Examples:
   [RFC4517].

   Example: "20" to represent the house number 20.

2.14

2.14.  'initials'

   The 'initials' attribute type contains strings of initials of some or
   all of an individual's names, except the surname(s).  Each string is
   one value of this multi-valued attribute.
   (Source: X.520 [X.520])

      ( 2.5.4.43 NAME 'initials'
         SUP name )

   Examples: "K. A." and "K".

2.15

2.15.  'internationalISDNNumber'

   The 'internationalISDNNumber' attribute type contains Integrated
   Services Digital Network (ISDN) addresses, as defined in the
   International Telecommunication Union (ITU) Recommendation E.164
   [E.164].  Each address is one value of this multi-valued attribute.
   (Source: X.520 [X.520])

      ( 2.5.4.25 NAME 'internationalISDNNumber'
         EQUALITY numericStringMatch
         SUBSTR numericStringSubstringsMatch
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 )

   1.3.6.1.4.1.1466.115.121.1.36 refers to the Numeric String syntax
   [Syntaxes].
   [RFC4517].

   Example: "0198 333 333".





Sciberras                 Expires 30 July 2006                 [Page 11]

INTERNET-DRAFT     LDAP: Schema for User Applications   January 30, 2006


2.16

2.16.  'l'

   The 'l' ('localityName' in X.500) attribute type contains names of a
   locality or place, such as a city, county county, or other geographic
   region.  Each name is one value of this multi-valued attribute.
   (Source: X.520 [X.520])





Sciberras                   Standards Track                    [Page 10]

RFC 4519           LDAP: Schema for User Applications          June 2006


      ( 2.5.4.7 NAME 'l'
         SUP name )

   Examples: "Geneva", "Paris" "Paris", and "Edinburgh".

2.17

2.17.  'member'

   The 'member' attribute type contains the Distinguished Names distinguished names of
   objects that are on a list or in a group.  Each name is one value of
   this multi-valued attribute.
   (Source: X.520 [X.520])

      ( 2.5.4.31 NAME 'member'
         SUP distinguishedName )

   Examples: "cn=James Clarke,ou=Finance,o=Widget\, Inc." and
             "cn=John Xerri,ou=Finance,o=Widget\, Inc." may
             be two members of the financial team (group) at Widget,
             Inc. In
             Inc., in which case, both of these distinguished names
             would be present as individual values of the member
             attribute.

2.18

2.18.  'name'

   The 'name' attribute type is the attribute supertype from which user
   attribute types with the name syntax inherit.  Such attribute types
   are typically used for naming.  The attribute type is multi-valued.

   It is unlikely that values of this type itself will occur in an
   entry.  LDAP server implementations which that do not support attribute
   subtyping need not recognize this attribute in requests.  Client
   implementations MUST NOT assume that LDAP servers are capable of
   performing attribute subtyping.
   (Source: X.520 [X.520])

      ( 2.5.4.41 NAME 'name'
         EQUALITY caseIgnoreMatch
         SUBSTR caseIgnoreSubstringsMatch
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

   1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax
   [Syntaxes].



Sciberras                 Expires 30 July 2006                 [Page 12]

INTERNET-DRAFT     LDAP: Schema for User Applications   January 30, 2006


2.19
   [RFC4517].

2.19.  'o'

   The 'o' ('organizationName' in X.500) attribute type contains the
   names of an organization.  Each name is one value of this
   multi-valued attribute.



Sciberras                   Standards Track                    [Page 11]

RFC 4519           LDAP: Schema for User Applications          June 2006


   (Source: X.520 [X.520])

      ( 2.5.4.10 NAME 'o'
         SUP name )

   Examples: "Widget", "Widget, Inc." Inc.", and "Widget, Incorporated.".

2.20

2.20.  'ou'

   The 'ou' ('organizationalUnitName' in X.500) attribute type contains
   the names of an organizational unit.  Each name is one value of this
   multi-valued attribute.
   (Source: X.520 [X.520])

      ( 2.5.4.11 NAME 'ou'
         SUP name )

   Examples: "Finance", "Human Resources" Resources", and "Research and
             Development".

2.21

2.21.  'owner'

   The 'owner' attribute type contains the Distinguished Names distinguished names of
   objects that have an ownership responsibility for the object that is
   owned.  Each owner's name is one value of this multi-valued
   attribute.
   (Source: X.520 [X.520])

      ( 2.5.4.32 NAME 'owner'
         SUP distinguishedName )

   Example: The mailing list object, whose DN is "cn=All Employees,
            ou=Mailing List,o=Widget\, Inc.", is owned by the Human
            Resources Director.

            Therefore, the value of the 'owner' attribute within the
            mailing list object, would be the DN of the director (role):
            "cn=Human Resources Director,ou=employee,o=Widget\, Inc.".

2.22

2.22.  'physicalDeliveryOfficeName'

   The 'physicalDeliveryOfficeName' attribute type contains names that a
   Postal Service uses to identify a post office.
   (Source: X.520 [X.520])







Sciberras                 Expires 30 July 2006                   Standards Track                    [Page 13]

INTERNET-DRAFT 12]

RFC 4519           LDAP: Schema for User Applications   January 30,          June 2006


      ( 2.5.4.19 NAME 'physicalDeliveryOfficeName'
         EQUALITY caseIgnoreMatch
         SUBSTR caseIgnoreSubstringsMatch
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

   1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax
   [Syntaxes].
   [RFC4517].

   Examples: "Bremerhaven, Main" and "Bremerhaven, Bonnstrasse".

2.23

2.23.  'postalAddress'

   The 'postalAddress' attribute type contains addresses used by a
   Postal Service to perform services for the object.  Each address is
   one value of this multi-valued attribute.
   (Source: X.520 [X.520])

      ( 2.5.4.16 NAME 'postalAddress'
         EQUALITY caseIgnoreListMatch
         SUBSTR caseIgnoreListSubstringsMatch
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 )

   1.3.6.1.4.1.1466.115.121.1.41 refers to the Postal Address syntax
   [Syntaxes].
   [RFC4517].

   Example: "15 Main St.$Ottawa$Canada".

2.24

2.24.  'postalCode'

   The 'postalCode' attribute type contains codes used by a Postal
   Service to identify postal service zones.  Each code is one value of
   this multi-valued attribute.
   (Source: X.520 [X.520])

      ( 2.5.4.17 NAME 'postalCode'
         EQUALITY caseIgnoreMatch
         SUBSTR caseIgnoreSubstringsMatch
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

   1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax
   [Syntaxes].
   [RFC4517].

   Example: "22180", to identify Vienna, VA VA, in the USA.

2.25








Sciberras                   Standards Track                    [Page 13]

RFC 4519           LDAP: Schema for User Applications          June 2006


2.25.  'postOfficeBox'

   The 'postOfficeBox' attribute type contains postal box identifiers
   that a Postal Service uses when a customer arranges to receive mail



Sciberras                 Expires 30 July 2006                 [Page 14]

INTERNET-DRAFT     LDAP: Schema for User Applications   January 30, 2006
   at a box on the premises of the Postal Service.  Each postal box
   identifier is a single value of this multi-valued attribute.
   (Source: X.520 [X.520])

      ( 2.5.4.18 NAME 'postOfficeBox'
         EQUALITY caseIgnoreMatch
         SUBSTR caseIgnoreSubstringsMatch
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

   1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax
   [Syntaxes].
   [RFC4517].

   Example: "Box 45".

2.26

2.26.  'preferredDeliveryMethod'

   The 'preferredDeliveryMethod' attribute type contains an indication
   of the preferred method of getting a message to the object.
   (Source: X.520 [X.520])

      ( 2.5.4.28 NAME 'preferredDeliveryMethod'
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.14
         SINGLE-VALUE )

   1.3.6.1.4.1.1466.115.121.1.14 refers to the Delivery Method syntax
   [Syntaxes].
   [RFC4517].

   Example: If the mhs-delivery Delivery Method is preferred over
            telephone-delivery, which is preferred over all other
            methods, the value would be: "mhs $ telephone".

2.27

2.27.  'registeredAddress'

   The 'registeredAddress' attribute type contains postal addresses
   suitable for reception of telegrams or expedited documents, where it
   is necessary to have the recipient accept delivery.  Each address is
   one value of this multi-valued attribute.
   (Source: X.520 [X.520])

      ( 2.5.4.26 NAME 'registeredAddress'
         SUP postalAddress
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 )





Sciberras                   Standards Track                    [Page 14]

RFC 4519           LDAP: Schema for User Applications          June 2006


   1.3.6.1.4.1.1466.115.121.1.41 refers to the Postal Address syntax
   [Syntaxes].
   [RFC4517].

   Example: "Receptionist$Widget, Inc.$15 Main St.$Ottawa$Canada".




Sciberras                 Expires 30 July 2006                 [Page 15]

INTERNET-DRAFT     LDAP: Schema for User Applications   January 30, 2006


2.28

2.28.  'roleOccupant'

   The 'roleOccupant' attribute type contains the Distinguished Names distinguished names of
   objects (normally people) that fulfill the responsibilities of a role
   object.  Each distinguished name is one value of this multi-valued
   attribute.
   (Source: X.520 [X.520])

      ( 2.5.4.33 NAME 'roleOccupant'
         SUP distinguishedName )

   Example: The role object, "cn=Human Resources
            Director,ou=Position,o=Widget\, Inc.", is fulfilled by two
            people whose object names are "cn=Mary
            Smith,ou=employee,o=Widget\, Inc." and "cn=James
            Brown,ou=employee,o=Widget\, Inc.".  The 'roleOccupant'
            attribute will contain both of these distinguished names,
            since they are the occupants of this role.

2.29

2.29.  'searchGuide'

   The 'searchGuide' attribute type contains sets of information for use
   by clients in constructing search filters.  It is superseded by
   'enhancedSearchGuide', described above in section Section 2.9.  Each set is
   one value of this multi-valued attribute.
   (Source: X.520 [X.520])

      ( 2.5.4.14 NAME 'searchGuide'
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.25 )

   1.3.6.1.4.1.1466.115.121.1.25 refers to the Guide syntax [Syntaxes]. [RFC4517].

   Example: "person#sn$EQ".

2.30

2.30.  'seeAlso'

   The 'seeAlso' attribute type contains Distinguished Names the distinguished names of
   objects that are related to the subject object.  Each related object
   name is one value of this multi-valued attribute.
   (Source: X.520 [X.520])

      ( 2.5.4.34 NAME 'seeAlso'
         SUP distinguishedName )



Sciberras                   Standards Track                    [Page 15]

RFC 4519           LDAP: Schema for User Applications          June 2006


   Example: The person object, object "cn=James Brown,ou=employee,o=Widget\,
            Inc." is related to the role objects, objects "cn=Football Team
            Captain,ou=sponsored activities,o=Widget\, Inc." and
            "cn=Chess Team,ou=sponsored activities,o=Widget\, Inc.".



Sciberras                 Expires 30 July 2006                 [Page 16]

INTERNET-DRAFT     LDAP: Schema for User Applications   January 30, 2006
            Since the role objects are related to the person object, the
            'seeAlso' attribute will contain the distinguished name of
            each role object as separate values.

2.31

2.31.  'serialNumber'

   The 'serialNumber' attribute type contains the serial numbers of
   devices.  Each serial number is one value of this multi-valued
   attribute.
   (Source: X.520 [X.520])

      ( 2.5.4.5 NAME 'serialNumber'
         EQUALITY caseIgnoreMatch
         SUBSTR caseIgnoreSubstringsMatch
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 )

   1.3.6.1.4.1.1466.115.121.1.44 refers to the Printable String syntax
   [Syntaxes].
   [RFC4517].

   Examples: "WI-3005" and "XF551426".

2.32

2.32.  'sn'

   The 'sn' ('surname' in X.500) attribute type contains name strings
   for the family names of a person.  Each string is one value of this
   multi-valued attribute.
   (Source: X.520 [X.520])

      ( 2.5.4.4 NAME 'sn'
         SUP name )

   Example: "Smith".

2.33

2.33.  'st'

   The 'st' ('stateOrProvinceName' in X.500) attribute type contains the
   full names of states or provinces.  Each name is one value of this
   multi-valued attribute.
   (Source: X.520 [X.520])

      ( 2.5.4.8 NAME 'st'
         SUP name )

   Example: "California".



Sciberras                 Expires 30 July 2006                   Standards Track                    [Page 17]

INTERNET-DRAFT 16]

RFC 4519           LDAP: Schema for User Applications   January 30,          June 2006


2.34


2.34.  'street'

   The 'street' ('streetAddress' in X.500) attribute type contains site
   information from a postal address (i.e., the street name, place,
   avenue, and the house number.). number).  Each street is one value of this
   multi-valued attribute.
   (Source: X.520 [X.520])

      ( 2.5.4.9 NAME 'street'
         EQUALITY caseIgnoreMatch
         SUBSTR caseIgnoreSubstringsMatch
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

   1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax
   [Syntaxes].
   [RFC4517].

   Example: "15 Main St.".

2.35

2.35.  'telephoneNumber'

   The 'telephoneNumber' attribute type contains telephone numbers that
   comply with the ITU Recommendation E.123 [E.123].  Each number is one
   value of this multi-valued attribute.
   (Source: X.520 [X.520])

      ( 2.5.4.20 NAME 'telephoneNumber'
         EQUALITY telephoneNumberMatch
         SUBSTR telephoneNumberSubstringsMatch
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 )

   1.3.6.1.4.1.1466.115.121.1.50 refers to the Telephone Number syntax
   [Syntaxes].
   [RFC4517].

   Example: "+1 234 567 8901".

2.36

2.36.  'teletexTerminalIdentifier'

   The withdrawal of Rec. Recommendation F.200 has resulted in the withdrawal
   of this attribute.
   (Source: X.520 [X.520])

      ( 2.5.4.22 NAME 'teletexTerminalIdentifier'
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.51 )

   1.3.6.1.4.1.1466.115.121.1.51 refers to the Teletex Terminal
   Identifier syntax [Syntaxes]. [RFC4517].





Sciberras                 Expires 30 July 2006                   Standards Track                    [Page 18]

INTERNET-DRAFT 17]

RFC 4519           LDAP: Schema for User Applications   January 30,          June 2006


2.37


2.37.  'telexNumber'

   The 'telexNumber' attribute type contains sets of strings which that are a
   telex number, country code, and answerback code of a telex terminal.
   Each set is one value of this multi-valued attribute.
   (Source: X.520 [X.520])

      ( 2.5.4.21 NAME 'telexNumber'
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.52 )

   1.3.6.1.4.1.1466.115.121.1.52 refers to the Telex Number syntax
   [Syntaxes].
   [RFC4517].

   Example: "12345$023$ABCDE".

2.38

2.38.  'title'

   The 'title' attribute type contains the title of a person in their
   organizational context.  Each title is one value of this multi-valued
   attribute.
   (Source: X.520 [X.520])

      ( 2.5.4.12 NAME 'title'
         SUP name )
   Examples: "Vice President", "Software Engineer" Engineer", and "CEO".

2.39

2.39.  'uid'

   The 'uid' ('userid' in RFC 1274) attribute type contains computer
   system login names associated with the object.  Each name is one
   value of this multi-valued attribute.
   (Source: RFC 2798 [RFC2798] and RFC 1274 [RFC1274])

      ( 0.9.2342.19200300.100.1.1 NAME 'uid'
         EQUALITY caseIgnoreMatch
         SUBSTR caseIgnoreSubstringsMatch
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

   1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax
   [Syntaxes].
   [RFC4517].

   Examples: "s9709015", "admin" "admin", and "Administrator".

2.40









Sciberras                   Standards Track                    [Page 18]

RFC 4519           LDAP: Schema for User Applications          June 2006


2.40.  'uniqueMember'

   The 'uniqueMember' attribute type contains the Distinguished Names distinguished names of
   an object that is on a list or in a group, where the Relative
   Distinguished Names relative
   distinguished names of the object include a value that distinguishes



Sciberras                 Expires 30 July 2006                 [Page 19]

INTERNET-DRAFT     LDAP: Schema for User Applications   January 30, 2006
   between objects when a distinguished name has been reused.  Each
   distinguished name is one value of this multi-valued attribute.
   (Source: X.520 [X.520])

      ( 2.5.4.50 NAME 'uniqueMember'
         EQUALITY uniqueMemberMatch
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.34 )

   1.3.6.1.4.1.1466.115.121.1.34 refers to the Name and Optional UID
   syntax [Syntaxes]. [RFC4517].

   Example: If "ou=1st Battalion,o=Defense,c=US" is a battalion that was
            disbanded, establishing a new battalion with the "same" name
            would have a unique identifier value added, resulting in
            "ou=1st Battalion, o=Defense,c=US#'010101'B".

2.41

2.41.  'userPassword'

   The 'userPassword' attribute contains octet strings that are known
   only to the user and the system to which the user has access.  Each
   string is one value of this multi-valued attribute.

   The application SHOULD prepare textual strings used as passwords by
   transcoding them to Unicode, applying SASLprep [RFC4013], and
   encoding as UTF-8.  The determination of whether a password is
   textual is a local client matter.
   (Source: X.509 [X.509])

      ( 2.5.4.35 NAME 'userPassword'
         EQUALITY octetStringMatch
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )

   1.3.6.1.4.1.1466.115.121.1.40 refers to the Octet String syntax
   [Syntaxes].
   [RFC4517].

   Passwords are stored using an Octet String syntax and are not
   encrypted.  Transfer of cleartext passwords is strongly discouraged
   where the underlying transport service cannot guarantee
   confidentiality and may result in disclosure of the password to
   unauthorized parties.

   An example of a need for multiple values in the 'userPassword'
   attribute is an environment where every month the user was is expected to



Sciberras                   Standards Track                    [Page 19]

RFC 4519           LDAP: Schema for User Applications          June 2006


   use a different password generated by some automated system.  During
   transitional periods, like the last and first day of the periods, it
   may be necessary to allow two passwords for the two consecutive
   periods to be valid in the system.




Sciberras                 Expires 30 July 2006                 [Page 20]

INTERNET-DRAFT     LDAP: Schema for User Applications   January 30, 2006


2.42

2.42.  'x121Address'

   The 'x121Address' attribute type contains data network addresses as
   defined by ITU Recommendation X.121 [X.121].  Each address is one
   value of this multi-valued attribute.
   (Source: X.520 [X.520])

      ( 2.5.4.24 NAME 'x121Address'
         EQUALITY numericStringMatch
         SUBSTR numericStringSubstringsMatch
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 )

   1.3.6.1.4.1.1466.115.121.1.36 refers to the Numeric String syntax
   [Syntaxes].
   [RFC4517].

   Example: "36111222333444555".

2.43

2.43.  'x500UniqueIdentifier'

   The 'x500UniqueIdentifier' attribute type contains binary strings
   that are used to distinguish between objects when a distinguished
   name has been reused.  Each string is one value of this multi-valued
   attribute.

   In X.520 [X.520], this attribute type is called 'uniqueIdentifier'.
   This is a different attribute type from both the 'uid' and
   'uniqueIdentifier' LDAP attribute types.  The 'uniqueIdentifier'
   attribute type is defined in [RFC1274]. [RFC4524].
   (Source: X.520 [X.520])

      ( 2.5.4.45 NAME 'x500UniqueIdentifier'
         EQUALITY bitStringMatch
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 )

   1.3.6.1.4.1.1466.115.121.1.6 refers to the Bit String syntax
   [Syntaxes].
















Sciberras                 Expires 30 July 2006                 [Page 21]

INTERNET-DRAFT     LDAP: Schema for User Applications   January 30, 2006
   [RFC4517].

3.  Object Classes

   LDAP servers SHOULD recognize all the Object Classes listed here as
   values of the 'objectClass' attribute (see [Models]).

3.1 [RFC4512]).





Sciberras                   Standards Track                    [Page 20]

RFC 4519           LDAP: Schema for User Applications          June 2006


3.1.  'applicationProcess'

   The 'applicationProcess' object class definition is the basis of an
   entry which that represents an application executing in a computer system.
   (Source: X.521 [X.521])

      ( 2.5.6.11 NAME 'applicationProcess'
         SUP top
         STRUCTURAL
         MUST cn
         MAY ( seeAlso $
               ou $
               l $
               description ) )

3.2

3.2.  'country'

   The 'country' object class definition is the basis of an entry which that
   represents a country.
   (Source: X.521 [X.521])

      ( 2.5.6.2 NAME 'country'
         SUP top
         STRUCTURAL
         MUST c
         MAY ( searchGuide $
               description ) )

3.3

3.3.  'dcObject'

   The 'dcObject' object class permits an entry to contains domain
   component information.  This object class is defined as auxiliary,
   because it will be used in conjunction with an existing structural
   object class.
   (Source: RFC 2247 [RFC2247])

      ( 1.3.6.1.4.1.1466.344 NAME 'dcObject'
         SUP top
         AUXILIARY
         MUST dc )






Sciberras                 Expires 30 July 2006                 [Page 22]

INTERNET-DRAFT     LDAP: Schema for User Applications   January 30, 2006


3.4

3.4.  'device'

   The 'device' object class is the basis of an entry which that represents an
   appliance, computer computer, or network element.
   (Source: X.521 [X.521])





Sciberras                   Standards Track                    [Page 21]

RFC 4519           LDAP: Schema for User Applications          June 2006


      ( 2.5.6.14 NAME 'device'
         SUP top
         STRUCTURAL
         MUST cn
         MAY ( serialNumber $
               seeAlso $
               owner $
               ou $
               o $
               l $
               description ) )

3.5

3.5.  'groupOfNames'

   The 'groupOfNames' object class is the basis of an entry which that
   represents a set of named objects including information related to
   the purpose or maintenance of the set.
   (Source: X.521 [X.521])

      ( 2.5.6.9 NAME 'groupOfNames'
         SUP top
         STRUCTURAL
         MUST ( member $
               cn )
         MAY ( businessCategory $
               seeAlso $
               owner $
               ou $
               o $
               description ) )

3.6

3.6.  'groupOfUniqueNames'

   The 'groupOfUniqueNames' object class is the same as the
   'groupOfNames' object class except that the object names are not
   repeated or reassigned within a set scope.
   (Source: X.521 [X.521])














Sciberras                   Standards Track                    [Page 22]

RFC 4519           LDAP: Schema for User Applications          June 2006


      ( 2.5.6.17 NAME 'groupOfUniqueNames'
         SUP top
         STRUCTURAL
         MUST ( uniqueMember $



Sciberras                 Expires 30 July 2006                 [Page 23]

INTERNET-DRAFT     LDAP: Schema for User Applications   January 30, 2006
               cn )
         MAY ( businessCategory $
               seeAlso $
               owner $
               ou $
               o $
               description ) )

3.7

3.7.  'locality'

   The 'locality' object class is the basis of an entry which that represents
   a place in the physical world.
   (Source: X.521 [X.521])

      ( 2.5.6.3 NAME 'locality'
         SUP top
         STRUCTURAL
         MAY ( street $
               seeAlso $
               searchGuide $
               st $
               l $
               description ) )

3.8

3.8.  'organization'

   The 'organization' object class is the basis of an entry which that
   represents a structured group of people.
   (Source: X.521 [X.521])

      ( 2.5.6.4 NAME 'organization'
         SUP top
         STRUCTURAL
         MUST o
         MAY ( userPassword $ searchGuide $ seeAlso $
               businessCategory $ x121Address $ registeredAddress $
               destinationIndicator $ preferredDeliveryMethod $
               telexNumber $ teletexTerminalIdentifier $
               telephoneNumber $ internationaliSDNNumber internationalISDNNumber $
               facsimileTelephoneNumber $ street $ postOfficeBox $
               postalCode $ postalAddress $ physicalDeliveryOfficeName $
               st $ l $ description ) )

3.9





Sciberras                   Standards Track                    [Page 23]

RFC 4519           LDAP: Schema for User Applications          June 2006


3.9.  'organizationalPerson'

   The 'organizationalPerson' object class is the basis of an entry
   which that
   represents a person in relation to an organization.
   (Source: X.521 [X.521])



Sciberras                 Expires 30 July 2006                 [Page 24]

INTERNET-DRAFT     LDAP: Schema for User Applications   January 30, 2006

      ( 2.5.6.7 NAME 'organizationalPerson'
         SUP person
         STRUCTURAL
         MAY ( title $ x121Address $ registeredAddress $
               destinationIndicator $ preferredDeliveryMethod $
               telexNumber $ teletexTerminalIdentifier $
               telephoneNumber $ internationaliSDNNumber internationalISDNNumber $
               facsimileTelephoneNumber $ street $ postOfficeBox $
               postalCode $ postalAddress $ physicalDeliveryOfficeName $
               ou $ st $ l ) )

3.10

3.10.  'organizationalRole'

   The 'organizationalRole' object class is the basis of an entry which that
   represents a job, function function, or position in an organization.
   (Source: X.521 [X.521])

      ( 2.5.6.8 NAME 'organizationalRole'
         SUP top
         STRUCTURAL
         MUST cn
         MAY ( x121Address $ registeredAddress $ destinationIndicator $
               preferredDeliveryMethod $ telexNumber $
               teletexTerminalIdentifier $ telephoneNumber $
               internationaliSDNNumber
               internationalISDNNumber $ facsimileTelephoneNumber $
               seeAlso $ roleOccupant $ preferredDeliveryMethod $
               street $ postOfficeBox $ postalCode $ postalAddress $
               physicalDeliveryOfficeName $ ou $ st $ l $
               description ) )

3.11

3.11.  'organizationalUnit'

   The 'organizationalUnit' object class is the basis of an entry which that
   represents a piece of an organization.
   (Source: X.521 [X.521])










Sciberras                   Standards Track                    [Page 24]

RFC 4519           LDAP: Schema for User Applications          June 2006


      ( 2.5.6.5 NAME 'organizationalUnit'
         SUP top
         STRUCTURAL
         MUST ou
         MAY ( businessCategory $ description $ destinationIndicator $
               facsimileTelephoneNumber $ internationaliSDNNumber internationalISDNNumber $ l $
               physicalDeliveryOfficeName $ postalAddress $ postalCode $
               postOfficeBox $ preferredDeliveryMethod $
               registeredAddress $ searchGuide $ seeAlso $ st $ street $
               telephoneNumber $ teletexTerminalIdentifier $
               telexNumber $ userPassword $ x121Address ) )




Sciberras                 Expires 30 July 2006                 [Page 25]

INTERNET-DRAFT     LDAP: Schema for User Applications   January 30, 2006

3.12  'person'

   The 'person' object class is the basis of an entry which that represents a
   human being.
   (Source: X.521 [X.521])

      ( 2.5.6.6 NAME 'person'
         SUP top
         STRUCTURAL
         MUST ( sn $
               cn )
         MAY ( userPassword $
               telephoneNumber $
               seeAlso $ description ) )

3.13

3.13.  'residentialPerson'

   The 'residentialPerson' object class is the basis of an entry which that
   includes a person's residence in the representation of the person.
   (Source: X.521 [X.521])

      ( 2.5.6.10 NAME 'residentialPerson'
         SUP person
         STRUCTURAL
         MUST l
         MAY ( businessCategory $ x121Address $ registeredAddress $
               destinationIndicator $ preferredDeliveryMethod $
               telexNumber $ teletexTerminalIdentifier $
               telephoneNumber $ internationaliSDNNumber internationalISDNNumber $
               facsimileTelephoneNumber $ preferredDeliveryMethod $
               street $ postOfficeBox $ postalCode $ postalAddress $
               physicalDeliveryOfficeName $ st $ l ) )

3.14







Sciberras                   Standards Track                    [Page 25]

RFC 4519           LDAP: Schema for User Applications          June 2006


3.14.  'uidObject'

   The 'uidObject' object class permits an entry to contains user
   identification information.  This object class is defined as
   auxiliary, because it will be used in conjunction with an existing
   structural object class.
   (Source: RFC 2377 [RFC2377])

      ( 1.3.6.1.1.3.1 NAME 'uidObject'
         SUP top
         AUXILIARY
         MUST uid )






Sciberras                 Expires 30 July 2006                 [Page 26]

INTERNET-DRAFT     LDAP: Schema for User Applications   January 30, 2006

4.  IANA Considerations

   It is requested that the

   The Internet Assigned Numbers Authority (IANA)
   update has updated the LDAP
   descriptors registry as indicated in the following template:

      Subject: Request for LDAP Descriptor Registration Update
      Descriptor (short name): see comment comments
      Object Identifier: see comment comments
      Person & email address to contact for further information:
         Andrew Sciberras <andrew.sciberras@eb2bcom.com>
      Usage: (A = attribute type, O = Object Class) see comment
      Specification: RFC XXXX [editor's note:  The RFC number will be
         the one assigned to this document.] 4519
      Author/Change Controller: IESG

   Comments

      In the LDAP descriptors registry, the following descriptors (short
      names) should be have been updated to refer to RFC XXXX [editor's note:  This
   document]. 4519.  Names that need to
      be reserved, rather than assigned to an Object Identifier, will
      contain an Object Identifier value of RESERVED.

      NAME                         Type OID
      ------------------------     ---- ----------------------------
      applicationProcess           O    2.5.6.11
      businessCategory             A    2.5.4.15
      c                            A    2.5.4.6
      cn                           A    2.5.4.3
      commonName                   A    2.5.4.3
      country                      O    2.5.6.2
      countryName                  A    2.5.4.6
      DC
      dc                           A    0.9.2342.19200300.100.1.25
      dcObject                     O    1.3.6.1.4.1.1466.344
      description                  A    2.5.4.13
      destinationIndicator         A    2.5.4.27
      device                       O    2.5.6.14



Sciberras                   Standards Track                    [Page 26]

RFC 4519           LDAP: Schema for User Applications          June 2006


      NAME                         Type OID
      ------------------------     ---- ----------------------------
      distinguishedName            A    2.5.4.49
      dnQualifier                  A    2.5.4.46
      domainComponent              A    0.9.2342.19200300.100.1.25
      enhancedSearchGuide          A    2.5.4.47
      facsimileTelephoneNumber     A    2.5.4.23
      generationQualifier          A    2.5.4.44
      givenName                    A    2.5.4.42
      GN
      gn                           A    RESERVED
      groupOfNames                 O    2.5.6.9
      groupOfUniqueNames           O    2.5.6.17
      houseIdentifier              A    2.5.4.51
      initials                     A    2.5.4.43



Sciberras                 Expires 30 July 2006                 [Page 27]

INTERNET-DRAFT     LDAP: Schema for User Applications   January 30, 2006
      internationalISDNNumber      A    2.5.4.25
      L
      l                            A    2.5.4.7
      locality                     O    2.5.6.3
      localityName                 A    2.5.4.7
      member                       A    2.5.4.31
      name                         A    2.5.4.41
      o                            A    2.5.4.10
      organization                 O    2.5.6.4
      organizationName             A    2.5.4.10
      organizationalPerson         O    2.5.6.7
      organizationalRole           O    2.5.6.8
      organizationalUnit           O    2.5.6.5
      organizationalUnitName       A    2.5.4.11
      ou                           A    2.5.4.11
      owner                        A    2.5.4.32
      person                       O    2.5.6.6
      physicalDeliveryOfficeName   A    2.5.4.19
      postalAddress                A    2.5.4.16
      postalCode                   A    2.5.4.17
      postOfficeBox                A    2.5.4.18
      preferredDeliveryMethod      A    2.5.4.28
      registeredAddress            A    2.5.4.26
      residentialPerson            O    2.5.6.10
      roleOccupant                 A    2.5.4.33
      searchGuide                  A    2.5.4.14
      seeAlso                      A    2.5.4.34
      serialNumber                 A    2.5.4.5
      sn                           A    2.5.4.4
      st                           A    2.5.4.8
      street                       A    2.5.4.9
      surname                      A    2.5.4.4
      telephoneNumber              A    2.5.4.20
      teletexTerminalIdentifier    A    2.5.4.22
      telexNumber                  A    2.5.4.21



Sciberras                   Standards Track                    [Page 27]

RFC 4519           LDAP: Schema for User Applications          June 2006


      NAME                         Type OID
      ------------------------     ---- ----------------------------
      title                        A    2.5.4.12
      uid                          A    0.9.2342.19200300.100.1.1
      uidObject                    O    1.3.6.1.1.3.1
      uniqueMember                 A    2.5.4.50
      userId
      userid                       A    0.9.2342.19200300.100.1.1
      userPassword                 A    2.5.4.35
      x121Address                  A    2.5.4.24
      x500UniqueIdentifier         A    2.5.4.45

5.  Security Considerations

   Attributes of directory entries are used to provide descriptive
   information about the real-world objects they represent, which can be
   people, organizations organizations, or devices.  Most countries have privacy laws



Sciberras                 Expires 30 July 2006                 [Page 28]

INTERNET-DRAFT     LDAP: Schema for User Applications   January 30, 2006
   regarding the publication of information about people.

   Transfer of cleartext passwords is strongly discouraged where the
   underlying transport service cannot guarantee confidentiality and
   integrity, since this may result in disclosure of the password to
   unauthorized parties.

   Multiple attribute values for the 'userPassword' attribute need to be
   used with care.  Especially reset/deletion of a password by an admin
   administrator without knowing the old user password gets tricky or
   impossible if multiple values for different applications are present.

   Certainly, applications which that intend to replace the 'userPassword'
   value(s) with new value(s) should use modify/replaceValues (or
   modify/deleteAttribute+addAttribute).  Additionally,  In addition, server
   implementations are encouraged to provide administrative controls
   which,
   that, if enabled, restrict the 'userPassword' attribute to one value.

   Note that when used for authentication purposes [AuthMeth], [RFC4513], the user
   need only prove knowledge of one of the values, not all of the
   values.

6.  Acknowledgements

   The definitions, on which this document is based, have been developed
   by committees for telecommunications and international standards.

   This document is an update of RFC 2256 by Mark Wahl.  RFC 2256 was a
   product of the IETF ASID Working Group.






Sciberras                   Standards Track                    [Page 28]

RFC 4519           LDAP: Schema for User Applications          June 2006


   The 'dc' attribute type definition and the 'dcObject' object class
   definition in this document supersede the specification in RFC 2247
   by S. Kille, M. Wahl, A. Grimstad, R. Huber, and S. Sataluri.

   The 'uid' attribute type definition in this document supersedes the
   specification of the 'userid' in RFC 1274 by P. Barker and S. Kille
   and of the uid in RFC 2798 by M. Smith.

   The 'uidObject' object class definition in this document supersedes
   the specification of the 'uidObject' in RFC 2377 by A. Grimstad, R.
   Huber, S. Sataluri Sataluri, and M. Smith. Wahl.

   This document is based upon input of the IETF LDAPBIS working group.
   The author wishes to thank S. Legg and K. Zeilenga for their
   significant contribution to this update.  The author would also like
   to thank Kathy Dally Dally, who edited early drafts versions of this document.



Sciberras                 Expires 30 July 2006                 [Page 29]

INTERNET-DRAFT     LDAP: Schema for User Applications   January 30, 2006

7.  References

7.1

7.1.  Normative References

   [E.123]    Notation for national and international telephone numbers,
              ITU-T Recommendation E.123, 1988

   [E.164]    The international public telecommunication numbering plan,
              ITU-T Recommendation E.164, 1997

   [F.1]      Operational Provisions For The International Public
              Telegram Service Transmission System, CCITT Recommendation
              F.1, 1992

   [F.31]     Telegram Retransmission System, CCITT Recommendation F.31,
              1988

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

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

   [RFC1034]     P.  Mockapetris, " DOMAIN NAMES P., "Domain names - CONCEPTS AND
                 FACILITIES", concepts and facilities",
              STD 13, RFC 1034,  January 1987 November 1987.

   [RFC1123]  Braden, R., "Requirements for Internet Hosts - Application
              and Support", STD 3, RFC 1123, October 1989.

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

   [RFC2181]  Elz, R. and R. Bush, "Clarifications to the DNS
              Specification", RFC 2181, July 1997.



Sciberras                   Standards Track                    [Page 29]

RFC 4519           LDAP: Schema for User Applications          June 2006


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

   [RFC4013]     Zeilenga  Zeilenga, K., "SASLprep: Stringprep profile Profile for User Names
              and Passwords", RFC 4013, February 2005.

   [RFC4234]  Crocker, D., Overell P., D. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", RFC 4234, October 2005

   [Roadmap] 2005.

   [RFC4510]  Zeilenga, K., "LDAP: Ed., "Lightweight Directory Access Protocol
              (LDAP): Technical Specification Road Map", draft-ietf-ldapbis-roadmap-xx (a work in
                 progress)

   [Syntaxes]    S. Legg (editor), "LDAP: Syntaxes", draft-ietf-ldapbis-
                 syntaxes-xx (a work in progress) RFC 4510, June
              2006.

   [RFC4512]  Zeilenga, K., "Lightweight Directory Access Protocol
              (LDAP): Directory Information Models", RFC 4512, June
              2006.

   [RFC4517]  Legg, S., Ed., "Lightweight Directory Access Protocol
              (LDAP): Syntaxes and Matching Rules", RFC 4517, June 2006.

   [X.121]    International numbering plan for public data networks,
              ITU-T Recommendation X.121, 1996



Sciberras                 Expires 30 July 2006                 [Page 30]

INTERNET-DRAFT     LDAP: Schema for User Applications   January 30, 2006

   [X.509]    The Directory:  Authentication Framework, ITU-T
              Recommendation X.509, 1993

   [X.520]    The Directory: Selected Attribute Types, ITU-T
              Recommendation X.520, 1993

   [X.521]    The Directory: Selected Object Classes.  ITU-T
              Recommendation X.521, 1993

7.2

7.2.  Informative

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

   [LDAP-PKI]    Zeilenga, K., "Lightweight Directory Access Protocol
                 (LDAP) schema definitions for X.509 Certificates",
                 draft-zeilenga-ldap-x509-xx (a work in progress) References

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

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

   [RFC2377]  Grimstad, A., Huber, R., Sataluri, S., and M. Wahl, M.,
              "Naming Plan for Internet-Enabled Internet Directory-Enabled Applications",
              RFC 2377, September 1998.

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

   [X.500]       ITU-T Recommendations X.500 (1993) | ISO/IEC
                 9594-1:1994, Information Technology - Open Systems
                 Interconnection - The Directory: Overview of concepts,
                 models and services.

8.  Author's Address

   Andrew Sciberras
   eB2Bcom
   Suite 3, Woodhouse Corporate Centre,
   935 Station Street,
   Box Hill North, Victoria 3129
   AUSTRALIA

   Phone:  +61 3 9896 7833 2000.



Sciberras                 Expires 30 July                   Standards Track                    [Page 30]

RFC 4519           LDAP: Schema for User Applications          June 2006


   [RFC4513]  Harrison R., Ed., "Lightweight Directory Access Protocol
              (LDAP): Authentication Methods and Security Mechanisms",
              RFC 4513, June 2006.

   [RFC4523]  Zeilenga, K., "Lightweight Directory Access Protocol
              (LDAP) Schema Definitions for X.509 Certificates", RFC
              4523, June 2006.

   [RFC4524]  Zeilenga, E., Ed., "COSINE LDAP/X.500 Schema", RFC 4524,
              June 2006.

   [X.500]    ITU-T Recommendations X.500 (1993) | ISO/IEC 9594-1:1994,
              Information Technology - Open Systems Interconnection -
              The Directory: Overview of concepts, models and services.





































Sciberras                   Standards Track                    [Page 31]

INTERNET-DRAFT

RFC 4519           LDAP: Schema for User Applications   January 30,          June 2006


   Email:  andrew.sciberras@eb2bcom.com

9.  Intellectual Property Statement

   The IETF takes no position regarding


Appendix A.  Changes Made Since RFC 2256

   This appendix lists the validity or scope of any
   Intellectual Property Rights or other rights changes that might be claimed to
   pertain have been made from RFC 2256 to the implementation or use
   RFC 4519.

   This appendix is not a normative part of the technology described in this document or the extent to specification, 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 been provided for informational purposes only.

      1.  Replaced the document title.

      2.  Removed the IESG Note.

      3.  Dependencies on RFC 1274 have been eliminated.

      4.  Added a Security Considerations section and an IANA
          Considerations section.

      5.  Deleted the procedures with respect to rights conformance requirement for subschema object
          classes in RFC documents can be
   found favor of a statement 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
   ietf-ipr@ietf.org.

10.  Full Copyright Statement

   Copyright (C) The Internet Society (2006).

   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.










Sciberras                 Expires 30 July 2006                 [Page 32]

INTERNET-DRAFT     LDAP: Schema for User Applications   January 30, 2006


                  Appendix A  Changes Made Since RFC 2256

   This appendix lists the changes that have been made from RFC 2256 to
   this I-D.

   This appendix is not a normative part of this specification, which
   has been provided for informational purposes only.

      1.  Replaced the document title.

      2.  Removed the IESG Note.

      3.  Dependencies on RFC 1274 have been eliminated.

      4.  Added a Security Considerations section and an IANA
          considerations section.

      5.  Deleted the conformance requirement for subschema object
          classes in favor of a statement in [Syntaxes].

      6.  Added explanation to attribute types [RFC4517].

      6.  Added explanation to attribute types and to each object class.

      7.  Removed Section 4, Syntaxes, and Section 6, Matching Rules,
          (moved to [Syntaxes]). [RFC4517]).

      8.  Removed the certificate-related attribute types:
          authorityRevocationList, cACertificate,
          certificateRevocationList, crossCertificatePair,
          deltaRevocationList, supportedAlgorithms, and userCertificate.

          Removed the certificate-related Object Classes:
          certificationAuthority, certificationAuthority-V2,
          cRLDistributionPoint, strongAuthenticationUser, and
          userSecurityInformation

          LDAP PKI is now discussed in [LDAP-CRL] and [LDAP-CERT]. [RFC4523].

      9.  Removed the dmdName, knowledgeInformation,
          presentationAddress, protocolInformation, and
          supportedApplicationContext attribute types and the dmd,
          applicationEntity, and dSA object classes.

      10. Deleted the aliasedObjectName and objectClass attribute type
          definitions.  Deleted the alias and top object class
          definitions.  They are included in [Models].

      11. Added the 'dc' attribute type from RFC 2247. [RFC4512].






Sciberras                 Expires 30 July 2006                   Standards Track                    [Page 33]

INTERNET-DRAFT 32]

RFC 4519           LDAP: Schema for User Applications   January 30,          June 2006


      11. Added the 'dc' attribute type from RFC 2247, making the
          distinction between 'stored' and 'query' values when preparing
          IDN strings.

      12. Numerous edititorial editorial changes.

      13. Removed upper bound after the SYNTAX oid in all attribute
          definitions where it appeared.

      14. Added text about Unicode, SASLprep [RFC4013], and UTF-8 for
          userPassword.

      changes since 07:

      15. Corrected examples in preferredDeliveryMethod, uniqueMember,
          postalAddress, and registeredAddress attribute types.

      16. Clarified Included definitions, comments and corrected examples in owner references for 'dcObject'
          and roleOccupant
          attribute types.

      17. Added RFC 2234 'uidObject'.

      16. Replaced PKI schema references to normative references.

      18. Added use RFC 1274 4523.

      17. Spelt out and RFC 2798 to informative references.

      19. referenced ABNF on first usage.

      18. Removed Section 2.4 (Source).  Replaced the statement about RFC 2026 conformance. source table with
          explicit references for each definition.

      19. All references to an attribute type or object class are
          enclosed in single quotes.

      20. Added The layout of attribute type definitions has been changed to
          provide consistency throughout the IPR Disclosure and Notice

      21. Updated document:
          > Section Heading
          > Description of Attribute type
          > Multivalued description
          > Source Information
          > Definition
          > Example
          > Additional Comments

          Adding this consistent output included the Copyright text.

      changes since 08:

      22. Included RFC 2377 into Updates header and Informative
          References

      23. Changed Editor information addition of
          examples to Andrew Sciberras.

      24. Updated I-D Template information.

      25. some definitions.

      21. References made consistent to alternate names for attributes types are
          provided with other LDAPbis ID's. [ROADMAP]
          -> [RoadMap] and [AUTHMETH] -> [AuthMeth].

      26. Changed Introduction a reference to include an (LDAP) acronym after where they were originally
          specified.

      22. Clarification of the description of 'distinguishedName' and
          'name', in regards to these attribute types being supertypes.

      23. Spelt out ISDN on first usage.

      27.





Sciberras                   Standards Track                    [Page 33]

RFC 4519           LDAP: Schema for User Applications          June 2006


      24. Inserted a reference to [RFC4517] for the
          'teletexTerminalIdentifier' definition's SYNTAX OID.

      25. Additional names were added to the IANA Considerations.  Names
          include 'commonName', 'dcObject', 'domainComponent', 'GN',
          'localityName', 'organizationName', 'organizationUnitName',
          'surname', 'uidObject' and 'userid'.

      26. Renamed section 1.1 all instances of supercede to "Relationship with other
          specifications" supersede.

      27. Moved [F.1], [F.31] and [RFC4013] from "Situation". informative to
          normative references.

      28. Included definitions, comments and references for 'dcObject'
          and 'uidObject'.

      29. Replaced PKI schema references Changed the 'c' definition to use draft-zeilenga-ldap-
          x509-xx be consistent with X.500.

Author's Address

   Andrew Sciberras                 Expires 30 July 2006
   eB2Bcom
   Suite 3, Woodhouse Corporate Centre,
   935 Station Street,
   Box Hill North, Victoria 3129
   AUSTRALIA

   Phone: +61 3 9896 7833
   EMail: andrew.sciberras@eb2bcom.com

























Sciberras                   Standards Track                    [Page 34]

INTERNET-DRAFT

RFC 4519           LDAP: Schema for User Applications   January 30,          June 2006


      30. Spelt out


Full Copyright Statement

   Copyright (C) The Internet Society (2006).

   This document is subject to the rights, licenses and referenced ABNF on first usage.

      31. Removed Section 2.4 (Source). Replaced restrictions
   contained in BCP 78, and except as set forth therein, the source table with
          explicit references for each definition.

      32. All references to an attribute type or object class authors
   retain all their rights.

   This document and the information contained herein are
          enclosed in single quotes.

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

Intellectual Property

   The layout of attribute type definitions has been changed to
          provide consistency throughout IETF takes no position regarding the document:
          > Section Heading
          > Description validity or scope of Attribute type
          > Multivalued description
          > Source Information
          > Definition
          > Example
          > Additional Comments

          Adding this consistent output included any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the addition implementation or use of
          examples the technology described in
   this document or the extent to some definitions.

      34. References which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to alternate names for attributes types are
          provided identify any such rights.  Information
   on the procedures with a reference respect to where they were originally
          specified.

      35. Clarification rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the description of 'distinguishedName' IETF Secretariat and
          'name', in regards to these attribute types being supertypes.

      36. Spelt out ISDN on first usage.

      37. Inserted a reference any
   assurances of licenses to [Syntaxes] for be made available, or the
          'teletexTerminalIdentifier' definition's SYNTAX OID.

      38. Additional names were added result of an
   attempt made to obtain a general license or permission for the IANA Considerations. Names
          include 'commonName', 'dcObject', 'domainComponent', 'GN',
          'localityName', 'organizationName', 'organizationUnitName',
          'surname', 'uidObject' and 'userid'.

      39. Renamed all instances use of supercede to supersede.

      40. Moved [F.1], [F.30] and [SASLprep]
   such proprietary rights by implementers or users of this
   specification can be obtained from informative to
          normative references.

      41. Changed the 'c' definition 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 consistent with X.500.

      42. Added text required to 'dc', making implement
   this standard.  Please address the distinction between 'stored'
          and 'query' values when preparing IDN strings. information to the IETF at
   ietf-ipr@ietf.org.

Acknowledgement

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).







Sciberras                 Expires 30 July 2006                   Standards Track                    [Page 35]

----