view Side-By-Side changes

INTERNET-DRAFT                                          K. Dally, Editor                                      Editor: A. Sciberras
Intended Category:  Standard Track                       The MITRE Corp.
Expires:  January 2005                                         July 2004                               eB2Bcom
Updates:  RFC 2247, RFC 2798 2798, RFC 2377                     April 4, 2005
Obsoletes:  RFC 2256


                   LDAP: Schema for User Applications                  
                  <draft-ietf-ldapbis-user-schema-08>
		  draft-ietf-ldapbis-user-schema-09.txt

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

   Status of this Memo

   This document is intended to be, after appropriate review an Internet-Draft and 
   revision, submitted is subject to the RFC Editor as a Standard Track document.
   Distribution all provisions
   of Section 3 of RFC 3978.  By submitting this memo Internet-Draft, each
   author represents that any applicable patent or other IPR claims of
   which he or she is unlimited.  Technical discussion aware have been or will be disclosed, and any of 
   this document
   which he or she become aware will take place on the IETF LDAP Revision Working 
   Group (LDAPbis) mailing list <ietf-ldapbis@openldap.org>.  Please 
   send editorial comments directly to the author <kdally@mitre.org>. be disclosed, in accordance with
   RFC 3979.

   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.

   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." progress".

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

   The list of Internet-Draft Shadow Directories can be accessed at 
   http://www.ietf.org/shadow.html.
   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.
   Distribution of this memo is unlimited.  Technical discussion of this
   document will 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 4 October 2005.

Copyright Notice

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



Sciberras                Expires 4 October 2005                 [Page 1]

INTERNET-DRAFT     LDAP: Schema for User Applications      April 4, 2005


Abstract

   This document is a an integral part of the Lightweight Directory Access
   Protocol (LDAP) technical specification [ROADMAP]. [Roadmap].  It provides a
   technical specification of attribute types and object classes
   intended for use by LDAP directory clients for many directory
   services, such 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.  








Dally








































Sciberras                Expires  January 4 October 2005                 [Page 1] 2]

INTERNET-DRAFT      draft-ietf-ldapbis-user-schema-08          July 2004     LDAP: Schema for User Applications      April 4, 2005


Table of Contents

   Status of this Memo . . . . . . . . . . . . . . . . . . . . . . .   1
   Copyright Notice                                                       1

Abstract Notice. . . . . . . . . . . . . . . . . . . . . . . . .   1
   Abstract. . . . . . . . . . . . . . . . . . . . . . . . . . . . .   2
   Table of Contents                                                      2 . . . . . . . . . . . . . . . . . . . . . . . .   3
   1.  Introduction                                                       4  Introduction. . . . . . . . . . . . . . . . . . . . . . . . .   5
       1.1  Situation                                                     4  Relationship with other specifications . . . . . . . . .   5
       1.2  Conventions                                                   4  Conventions. . . . . . . . . . . . . . . . . . . . . . .   5
       1.3  General Issues                                                4
    1.4  Source . . . . . . . . . . . . . . . . . . . . .   5

   2.  Attribute Types                                                    5 . . . . . . . . . . . . . . . . . . . . . . .   6
       2.1  businessCategory                                              5  'businessCategory' . . . . . . . . . . . . . . . . . . .   6
       2.2  c  'c'. . . . . . . . . . . . . . . . . . . . . . . . . . .   6
       2.3  cn                                                            6  'cn' . . . . . . . . . . . . . . . . . . . . . . . . . .   7
       2.4  dc                                                            6
    2.5  description  'dc' . . . . . . . . . . . . . . . . . . . . . . . . . .   7
       2.5  'description'. . . . . . . . . . . . . . . . . . . . . .   8
       2.6  destinationIndicator                                          7  'destinationIndicator' . . . . . . . . . . . . . . . . .   8
       2.7  distinguishedName                                             7
    2.8  dnQualifier  'distinguishedName'. . . . . . . . . . . . . . . . . . .   8
       2.8  'dnQualifier'. . . . . . . . . . . . . . . . . . . . . .   9
       2.9  enhancedSearchGuide                                           8  'enhancedSearchGuide'. . . . . . . . . . . . . . . . . .   9
       2.10 facsimileTelephoneNumber                                      8 'facsimileTelephoneNumber' . . . . . . . . . . . . . . .  10
       2.11 generationQualifier                                           8 'generationQualifier'. . . . . . . . . . . . . . . . . .  10
       2.12 givenName                                                     9 'givenName'. . . . . . . . . . . . . . . . . . . . . . .  10
       2.13 houseIdentifier                                               9 'houseIdentifier'. . . . . . . . . . . . . . . . . . . .  11
       2.14 initials                                                      9 'initials' . . . . . . . . . . . . . . . . . . . . . . .  11
       2.15 internationalISDNNumber                                       9 'internationalISDNNumber'. . . . . . . . . . . . . . . .  11
       2.16 l                                                            10 'l'. . . . . . . . . . . . . . . . . . . . . . . . . . .  12
       2.17 member                                                       10 'member' . . . . . . . . . . . . . . . . . . . . . . . .  12
       2.18 name                                                         10 'name' . . . . . . . . . . . . . . . . . . . . . . . . .  12
       2.19 o                                                            10 'o'. . . . . . . . . . . . . . . . . . . . . . . . . . .  13
       2.20 ou                                                           11 'ou' . . . . . . . . . . . . . . . . . . . . . . . . . .  13
       2.21 owner                                                        11 'owner'. . . . . . . . . . . . . . . . . . . . . . . . .  13
       2.22 physicalDeliveryOfficeName                                   11 'physicalDeliveryOfficeName' . . . . . . . . . . . . . .  13
       2.23 postalAddress                                                11 'postalAddress'. . . . . . . . . . . . . . . . . . . . .  14
       2.24 postalCode                                                   12 'postalCode' . . . . . . . . . . . . . . . . . . . . . .  14
       2.25 postOfficeBox                                                12 'postOfficeBox'. . . . . . . . . . . . . . . . . . . . .  14
       2.26 preferredDeliveryMethod                                      12 'preferredDeliveryMethod'. . . . . . . . . . . . . . . .  15
       2.27 registeredAddress                                            13 'registeredAddress'. . . . . . . . . . . . . . . . . . .  15
       2.28 roleOccupant                                                 13 'roleOccupant' . . . . . . . . . . . . . . . . . . . . .  16
       2.29 searchGuide                                                  13 'searchGuide'. . . . . . . . . . . . . . . . . . . . . .  16
       2.30 seeAlso                                                      13 'seeAlso'. . . . . . . . . . . . . . . . . . . . . . . .  16
       2.31 serialNumber                                                 14 'serialNumber' . . . . . . . . . . . . . . . . . . . . .  17
       2.32 sn                                                           14 'sn' . . . . . . . . . . . . . . . . . . . . . . . . . .  17
       2.33 st                                                           14


Dally 'st' . . . . . . . . . . . . . . . . . . . . . . . . . .  17
       2.34 'street' . . . . . . . . . . . . . . . . . . . . . . . .  18
       2.35 'telephoneNumber'. . . . . . . . . . . . . . . . . . . .  18
       2.36 'teletexTerminalIdentifier'. . . . . . . . . . . . . . .  18



Sciberras                Expires  January 4 October 2005                 [Page 2] 3]

INTERNET-DRAFT     draft-ietf-ldapbis-user-schema-08           July 2004


    2.34 street                                                       14
    2.35 telephoneNumber                                              15
    2.36 teletexTerminalIdentifier                                    15     LDAP: Schema for User Applications      April 4, 2005


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

   3.  Object Classes                                                    18 Classes. . . . . . . . . . . . . . . . . . . . . . . .  22
       3.1  applicationProcess                                           18  'applicationProcess' . . . . . . . . . . . . . . . . . .  22
       3.2  country                                                      18  'country'. . . . . . . . . . . . . . . . . . . . . . . .  22
       3.3  device                                                       18  'dcObject' . . . . . . . . . . . . . . . . . . . . . . .  22
       3.4  groupOfNames                                                 19  'device' . . . . . . . . . . . . . . . . . . . . . . . .  23
       3.5  groupOfUniqueNames                                           19  'groupOfNames' . . . . . . . . . . . . . . . . . . . . .  23
       3.6  locality                                                     19  'groupOfUniqueNames' . . . . . . . . . . . . . . . . . .  23
       3.7  organization                                                 20  'locality' . . . . . . . . . . . . . . . . . . . . . . .  24
       3.8  organizationalPerson                                         20  'organization' . . . . . . . . . . . . . . . . . . . . .  24
       3.9 organizationalRole                                            20  'organizationalPerson' . . . . . . . . . . . . . . . . .  24
       3.10 organizationalUnit                                           21 'organizationalRole' . . . . . . . . . . . . . . . . . .  25
       3.11 person                                                       21 'organizationalUnit' . . . . . . . . . . . . . . . . . .  25
       3.12 residentialPerson                                            21 'person' . . . . . . . . . . . . . . . . . . . . . . . .  26
       3.13 'residentialPerson'. . . . . . . . . . . . . . . . . . .  26
       3.14 'uidObject'. . . . . . . . . . . . . . . . . . . . . . .  26

   4.  IANA Considerations                                               22 . . . . . . . . . . . . . . . . . . . . .  27

   5.  Security Considerations                                           23 . . . . . . . . . . . . . . . . . . .  28

   6.  Acknowledgements                                                  24  Acknowledgements. . . . . . . . . . . . . . . . . . . . . . .  29

   7.  References                                                        24  References. . . . . . . . . . . . . . . . . . . . . . . . . .  30
       7.1  Normative                                                    24  Normative. . . . . . . . . . . . . . . . . . . . . . . .  30
       7.2  Informative                                                  25  Informative. . . . . . . . . . . . . . . . . . . . . . .  31

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

   9.  Intellectual Property Rights (IPR) Disclosure                     26 Statement . . . . . . . . . . . . . . .  32

   10. IPR Notice                                                        26

11. Copyright Notice and Disclaimer                                   27










Dally of Validity. . . . . . . . . . . . . . . . . . . .  32












Sciberras                Expires  January 4 October 2005                 [Page 3] 4]

INTERNET-DRAFT     draft-ietf-ldapbis-user-schema-08           July 2004     LDAP: Schema for User Applications      April 4, 2005


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, 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  Situation Relationship with other specifications

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

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

   A number of schema elements which 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-CERT] and [LDAP-CRL].
   [LDAP-PKI].  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  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  General Issues

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

   The definitions of Attribute Types and Object Classes are written



Sciberras                Expires 4 October 2005                 [Page 5]

INTERNET-DRAFT     LDAP: Schema for User Applications      April 4, 2005


   using the ABNF form Augmented Backus-Naur Form (ABNF) [RFC2234] of
   AttributeTypeDescription and ObjectClassDescription given in
   [Models].  Lines have been folded for readability.





Dally                    Expires  January 2005                  [Page 4]
INTERNET-DRAFT     draft-ietf-ldapbis-user-schema-08           July 2004


1.4  Source

   The schema definitions in this document  When such values
   are based on those found transferred as attribute values in the X.500-series [X.520] and [X.521], RFC 2798 [RFC2798] and 
   RFC 2247 [RFC2247], specifically:
   
      Sections             Source
      ============         ==================
      2.1 - 2.3            X.520 [X.520]
      2.4                  RFC 2247 [RFC2247]
      2.5 - 2.38           X.520 [X.520]
      2.39                 RFC 2798 [2798]
      2.40 - 2.43          X.520 [X.520]
      3.1  - 3.12          X.521 [X.521]



   However, LDAP Protocol the descriptions in this document SHALL be considered 
   definitive for use in LDAP. values
   will not contain line breaks.

2.  Attribute Types

   The Attribute Types contained in this section hold user information.

   There is no requirement that servers implement the following 'searchGuide' and
   'teletexTerminalIdentifier' attribute types: 

      searchGuide
      teletexTerminalIdentifier 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  businessCategory  'businessCategory'

   The businessCategory 'businessCategory' attribute type describes the kinds of business
   performed by an organization (e.g., "banking", "transportation"). 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].







Dally                    Expires  January 2005                  [Page 5]
INTERNET-DRAFT     draft-ietf-ldapbis-user-schema-08           July 2004

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

2.2  c  'c'

   The c (countryName) 'c' ('countryName' in X.500) attribute type contains a two-letter
   ISO 3166 [ISO3166] country code (e.g., "DE"). code.
   (Source:  X.520) 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 4 October 2005                 [Page 6]

INTERNET-DRAFT     LDAP: Schema for User Applications      April 4, 2005


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

2.3  cn  'cn'

   The cn (commonName) 'cn' ('commonName' in X.500) attribute type contains names of an object 
   (e.g., "Martin K Smith", "Marty Smith", "printer12").
   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 [X.520])

      ( 2.5.4.3 NAME 'cn'
         SUP name )

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

2.4  dc  'dc'

   The dc (short for domainComponent) 'dc' ('domainComponent' in RFC 2247) attribute type is a string
   holding one component, a <label> [RFC1034}, [RFC1034], of a DNS domain name 
   (e.g., "example" or "com", but not "example.com"). name.
   The encoding of IA5String for use in LDAP is simply the characters of
   the string itself.  The equality matching rule is case insensitive,
   as is today's DNS.
   (Source: RFC 2247 [RFC2247])

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

   Examples: Valid values include "example" and "com".  The value
             "example.com" is invalid, because it contains two <label>
             components.

   It is noted that the directory will not ensure that values of this
   attribute conform to the label production [RFC1034].  It is the 
   application
   application's 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.






Dally <domain> [RFC1034] production.  The special
   considerations discussed in section 4 of RFC 3490 [RFC3490] should be
   taken, depending on whether the domain component is used for "stored"
   or "query" purposes.



Sciberras                Expires  January 4 October 2005                 [Page 6] 7]

INTERNET-DRAFT     draft-ietf-ldapbis-user-schema-08           July 2004     LDAP: Schema for User Applications      April 4, 2005


2.5  description  'description'

   The description 'description' attribute type contains human-readable descriptive
   phrases about the object (e.g., "a color printer", "Maintenance is 
   done every Monday, at 1pm."). object.  Each description is one value of this
   multi-valued attribute.
   (Source: X.520 [X.520])

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

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

2.6  destinationIndicator  'destinationIndicator'

   The destinationIndicator 'destinationIndicator' attribute type contains country and city
   strings, associated with the object (the addressee), needed to
   provide the Public Telegram Service.  Each string is one value of 
   this multi-valued attribute.  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].

   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 CCITT Recommendations.  It is
   the application's responsibility to ensure destination indicators
   that it stores in this attribute are appropriately constructed.

2.7  distinguishedName  'distinguishedName'

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



Sciberras                Expires 4 October 2005                 [Page 8]

INTERNET-DRAFT     LDAP: Schema for User Applications      April 4, 2005


   attribute types with a DN syntax inherit, instead of containing 
   values which name the object itself.  The attribute type is 
   multi-valued. can inherit.

   It is unlikely that values of this type itself will occur in an
   entry.  LDAP server implementations which 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.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].



Dally                    Expires  January 2005                  [Page 7]
INTERNET-DRAFT     draft-ietf-ldapbis-user-schema-08           July 2004

2.8  dnQualifier  'dnQualifier'

   The dnQualifier '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 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
   '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].

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

2.9  enhancedSearchGuide  'enhancedSearchGuide'

   The enhancedSearchGuide '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 4 October 2005                 [Page 9]

INTERNET-DRAFT     LDAP: Schema for User Applications      April 4, 2005


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

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

2.10  facsimileTelephoneNumber  'facsimileTelephoneNumber'

   The facsimileTelephoneNumber '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].

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

2.11  generationQualifier  'generationQualifier'

   The generationQualifier 'generationQualifier' attribute type contains name strings that
   are the part of a person's name which typically is the suffix, as in 
   "IIIrd" or "3rd". suffix.  Each
   string is one value of this multi-valued attribute.


Dally                    Expires  January 2005                  [Page 8]
INTERNET-DRAFT     draft-ietf-ldapbis-user-schema-08           July 2004
   (Source: X.520 [X.520])

      ( 2.5.4.44 NAME 'generationQualifier'
         SUP name )

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

2.12  givenName  'givenName'

   The givenName 'givenName' attribute type contains name strings that are the
   part of a person's name which 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" and "Joanne"




Sciberras                Expires 4 October 2005                [Page 10]

INTERNET-DRAFT     LDAP: Schema for User Applications      April 4, 2005


2.13  houseIdentifier  'houseIdentifier'

   The houseIdentifier '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])

      ( 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: "20" to represent a the house number 20.

2.14  initials  'initials'

   The initials 'initials' attribute type contains strings of initials of some or
   all of an individual's names, except the surname(s) 
   (e.g., "K. A.", "K"). 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  internationalISDNNumber  'internationalISDNNumber'

   The internationalISDNNumber 'internationalISDNNumber' attribute type contains ISDN Integrated
   Services Digital Network (ISDN) addresses, as defined in ITU 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].



Dally

   Example: "0198 333 333"





Sciberras                Expires  January 4 October 2005                [Page 9] 11]

INTERNET-DRAFT     draft-ietf-ldapbis-user-schema-08           July 2004     LDAP: Schema for User Applications      April 4, 2005


2.16  l  'l'

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

      ( 2.5.4.7 NAME 'l'
         SUP name )

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

2.17  member  'member'

   The member 'member' attribute type contains the 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 which case, both of these distinguished names would
             be present as individual values of the member attribute.

2.18  name  'name'

   The name 'name' attribute type is the attribute supertype from which 
   attributes user
   attribute types with the name syntax inherit.  Such attributes 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 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 4 October 2005                [Page 12]

INTERNET-DRAFT     LDAP: Schema for User Applications      April 4, 2005


2.19  o  'o'

   The o (organizationName) 'o' ('organizationName' in X.500) attribute type contains the
   names of an 
   organization (e.g., "IETF", "Internet Engineering Task Force"). organization.  Each name is one value of this
   multi-valued attribute.
   (Source:  X.520) X.520 [X.520])

      ( 2.5.4.10 NAME 'o'
         SUP name )




Dally                   Expires  January 2005                  [Page 10]
INTERNET-DRAFT     draft-ietf-ldapbis-user-schema-08           July 2004

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

2.20  ou  'ou'

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

      ( 2.5.4.11 NAME 'ou'
         SUP name )

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

2.21  owner  'owner'

   The owner 'owner' attribute type contains the 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.
   (e.g.,
   (Source: X.520 [X.520])

      ( 2.5.4.32 NAME 'owner'
         SUP distinguishedName )

   Example: The mailing list object which has DN: object, whose DN is "cn=All Employees,
            ou=Mailing List,o=Widget\, Inc.", is owned by the Human
            Resources Director.
            Therefore, the DN value of the director (role) owner attribute within the
            mailing list object, would be a value the DN of the owner attribute: director (role):
            "cn=Human Resources Director,
   ou=employee,o=Widget\, Inc.")  

   ( 2.5.4.32 NAME 'owner' 
      SUP distinguishedName ) Director,ou=employee,o=Widget\, Inc.".

2.22  physicalDeliveryOfficeName  'physicalDeliveryOfficeName'

   The physicalDeliveryOfficeName 'physicalDeliveryOfficeName' attribute type contains names that a
   Postal Service uses to identify a post office (e.g., "Bremerhaven, 
   Main", "Bremerhaven, Bonnstrasse"). office.
   (Source: X.520 [X.520])



Sciberras                Expires 4 October 2005                [Page 13]

INTERNET-DRAFT     LDAP: Schema for User Applications      April 4, 2005


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

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

2.23  postalAddress  'postalAddress'

   The postalAddress '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.(e.g., one value is "15 Main 
   St.$Ottawa$Canada"). 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 ) 



Dally                   Expires  January 2005                  [Page 11]
INTERNET-DRAFT     draft-ietf-ldapbis-user-schema-08           July 2004

   1.3.6.1.4.1.1466.115.121.1.41 refers to the Postal Address syntax
   [Syntaxes].

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

2.24  postalCode  'postalCode'

   The postalCode 'postalCode' attribute type contains codes used by a Postal
   Service to identify a postal service zones, such as the southern 
   quadrant of a city (e.g., "22180"). 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].

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

2.25  postOfficeBox  'postOfficeBox'

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



Sciberras                Expires 4 October 2005                [Page 14]

INTERNET-DRAFT     LDAP: Schema for User Applications      April 4, 2005


   at a box on premises of the Postal Service (e.g., "Box 45"). Service.  Each number postal box
   identifier is one 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].

   Example: "Box 45".

2.26  preferredDeliveryMethod  'preferredDeliveryMethod'

   The preferredDeliveryMethod 'preferredDeliveryMethod' attribute type contains an indication
   of the preferred method of getting a message to the object.  For 
   example, if
   (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].

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

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





Dally                   Expires  January 2005                  [Page 12]
INTERNET-DRAFT     draft-ietf-ldapbis-user-schema-08           July 2004 telephone"

2.27  registeredAddress  'registeredAddress'

   The registeredAddress '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.   (e.g., one value is 
   "Receptionist\, Widget Inc.\, 15 Main St.\, Ottawa\, Canada")
   (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 )

   1.3.6.1.4.1.1466.115.121.1.41 refers to the Postal Address syntax
   [Syntaxes].

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




Sciberras                Expires 4 October 2005                [Page 15]

INTERNET-DRAFT     LDAP: Schema for User Applications      April 4, 2005


2.28  roleOccupant  'roleOccupant'

   The roleOccupant 'roleOccupant' attribute type contains the Distinguished Names of
   objects (normally people) that fulfill the responsibilities of a role
   object.  For example, the  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." Inc.".  The roleOccupant 
   attribute would have two values, one for each occupant.  

   ( 2.5.4.33 NAME 'roleOccupant' 
      SUP distinguishedName )
            attribute will contain both of these distinguished names,
            since they are the occupants of this role.

2.29  searchGuide  'searchGuide'

   The searchGuide 'searchGuide' attribute type contains sets of information for use
   by clients in constructing search filters.  It is superseded by 
   enhancedSearchGuide,
   'enhancedSearchGuide', described above in 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].

   Example: "person#sn$EQ"

2.30  seeAlso  'seeAlso'

   The seeAlso 'seeAlso' attribute type contains Distinguished Names of objects
   that are related to the subject object.  For example, the  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 )

   Example: The person object, "cn=James Brown,ou=employee,o=Widget Brown,ou=employee,o=Widget\,
            Inc." is related to the role objects, "cn=Football Team
            Captain,ou=sponsored activities,
   o=Widget activities,o=Widget\, Inc." and "cn=Chess Team,ou=sponsored activities,o=Widget 
   Inc.".  Each related object name is one value of this multi-valued 
   attribute.




Dally



Sciberras                Expires  January 4 October 2005                [Page 13] 16]

INTERNET-DRAFT     draft-ietf-ldapbis-user-schema-08           July 2004


   ( 2.5.4.34 NAME     LDAP: Schema for User Applications      April 4, 2005


            "cn=Chess Team,ou=sponsored activities,o=Widget\, Inc.".
            Since the role objects are related to the person object, the
            'seeAlso' 
      SUP distinguishedName ) attribute will contain the distinguished name of
            each role object as separate values.

2.31  serialNumber  'serialNumber'

   The serialNumber 'serialNumber' attribute type contains the serial numbers of 
   devices (e.g., "WI-3005".
   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].

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

2.32  sn  'sn'

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

      ( 2.5.4.4 NAME 'sn'
         SUP name )

   Example: "Smith"

2.33  st  'st'

   The st (stateOrProvinceName) 'st' ('stateOrProvinceName' in X.500) attribute type contains the
   full names of states or provinces, (e.g. "California"). 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 4 October 2005                [Page 17]

INTERNET-DRAFT     LDAP: Schema for User Applications      April 4, 2005


2.34  street  'street'

   The street (streetAddress) 'street' ('streetAddress' in X.500) attribute type contains physical 
   addresses of site
   information from a postal address (i.e., the object to which street name, place,
   avenue, and the entry corresponds, such as an 
   address for package delivery. house number.).  Each address 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].



Dally                   Expires  January 2005                  [Page 14]
INTERNET-DRAFT     draft-ietf-ldapbis-user-schema-08           July 2004

   Example: "15 Main St."

2.35  telephoneNumber  'telephoneNumber'

   The telephoneNumber 'telephoneNumber' attribute type contains telephone numbers 
   complying that
   comply with the ITU Recommendation E.123 [E.123] (e.g., 
   +1 234 567 8901) [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].

   Example: "+1 234 567 8901".

2.36  teletexTerminalIdentifier  'teletexTerminalIdentifier'

   The withdrawal of Rec. 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].





Sciberras                Expires 4 October 2005                [Page 18]

INTERNET-DRAFT     LDAP: Schema for User Applications      April 4, 2005


2.37  telexNumber  'telexNumber'

   The telexNumber 'telexNumber' attribute type contains sets of strings which 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].

   Example: "12345$023$ABCDE"

2.38  title

   This  'title'

   The 'title' attribute type contains the title, such as "Vice President", 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" and "CEO".

2.39  uid  'uid'

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




Dally                   Expires  January 2005                  [Page 15]
INTERNET-DRAFT     draft-ietf-ldapbis-user-schema-08           July 2004
   (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].

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

2.40  uniqueMember  'uniqueMember'

   The uniqueMember 'uniqueMember' attribute type contains the Distinguished Names of



Sciberras                Expires 4 October 2005                [Page 19]

INTERNET-DRAFT     LDAP: Schema for User Applications      April 4, 2005


   an object that is on a list or in a group, where the Relative
   Distinguished Names of the object include a value that distinguishes
   between objects when a distinguished name has been reused.  For 
   example, if "ou=1st Battalion,o=Defense,c=US" is a battalion that 
   was disbanded, establishing a new battalion with the "same"  Each
   distinguished name 
   would have a uid is one value added, resulting in "ou=1st Battalion,
   o=Defense,c=US#'010101'B". 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].

   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  userPassword  'userPassword'

   The userPassword '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 [SASLprep], 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].

   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.



Dally                   Expires  January 2005                  [Page 16]
INTERNET-DRAFT     draft-ietf-ldapbis-user-schema-08           July 2004

   An example of a need for multiple values in the userPassword 'userPassword'
   attribute is an environment where every month the user was expected
   to use a different password generated by some automated system.
   During transitional periods, like say the last and first day of the
   periods, it may be necessary to allow two passwords for the two



Sciberras                Expires 4 October 2005                [Page 20]

INTERNET-DRAFT     LDAP: Schema for User Applications      April 4, 2005


   consecutive periods to be valid in the system.

2.42  x121Address  'x121Address'

   The x121Address 'x121Address' attribute type contains data network addresses 
   (e.g., 36111222333444555) 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].

   Example: "36111222333444555".

2.43  x500UniqueIdentifier  'x500UniqueIdentifier'

   The x500UniqueIdentifier '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. 'uniqueIdentifier'.
   This is a different attribute type from both the 
   "uid" 'uid' and "uniqueIdentifier"
   'uniqueIdentifier' LDAP attribute types.  The 
   uniqueIdentifier 'uniqueIdentifier'
   attribute type is defined in [RFC1274].
   (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].















Dally














Sciberras                Expires  January 4 October 2005                [Page 17] 21]

INTERNET-DRAFT     draft-ietf-ldapbis-user-schema-08           July 2004     LDAP: Schema for User Applications      April 4, 2005


3.  Object Classes

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

3.1  applicationProcess  'applicationProcess'

   The applicationProcess 'applicationProcess' object class definition is the basis of an
   entry which 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  country  'country'

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

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

3.3  device 'dcObject'

   The device '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 4 October 2005                [Page 22]

INTERNET-DRAFT     LDAP: Schema for User Applications      April 4, 2005


3.4  'device'

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

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





Dally                   Expires  January 2005                  [Page 18]
INTERNET-DRAFT     draft-ietf-ldapbis-user-schema-08           July 2004


3.4  groupOfNames

3.5  'groupOfNames'

   The groupOfNames 'groupOfNames' object class is the basis of an entry which
   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.5  groupOfUniqueNames

3.6  'groupOfUniqueNames'

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

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



Sciberras                Expires 4 October 2005                [Page 23]

INTERNET-DRAFT     LDAP: Schema for User Applications      April 4, 2005


               cn )
         MAY ( businessCategory $
               seeAlso $
               owner $
               ou $
               o $
               description ) ) 

3.6  locality

3.7  'locality'

   The locality 'locality' object class is the basis of an entry which 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 ) )


Dally                   Expires  January 2005                  [Page 19]
INTERNET-DRAFT     draft-ietf-ldapbis-user-schema-08           July 2004


3.7  organization

3.8  'organization'

   The organization 'organization' object class is the basis of an entry which
   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 $
               facsimileTelephoneNumber $ street $ postOfficeBox $
               postalCode $ postalAddress $ physicalDeliveryOfficeName $
               st $ l $ description ) )

3.8  organizationalPerson

3.9  'organizationalPerson'

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



Sciberras                Expires 4 October 2005                [Page 24]

INTERNET-DRAFT     LDAP: Schema for User Applications      April 4, 2005


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

3.9  organizationalRole

3.10  'organizationalRole'

   The organizationalRole 'organizationalRole' object class is the basis of an entry which
   represents a job or job, 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 $ facsimileTelephoneNumber $
               seeAlso $ roleOccupant $ preferredDeliveryMethod $
               street $ postOfficeBox $ postalCode $ postalAddress $
               physicalDeliveryOfficeName $ ou $ st $ l $ description ) )


Dally                   Expires  January 2005                  [Page 20]
INTERNET-DRAFT     draft-ietf-ldapbis-user-schema-08           July 2004


3.10  organizationalUnit $
               description ) )

3.11  'organizationalUnit'

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

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

3.11  person




Sciberras                Expires 4 October 2005                [Page 25]

INTERNET-DRAFT     LDAP: Schema for User Applications      April 4, 2005


3.12  'person'

   The person 'person' object class is the basis of an entry which 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.12  residentialPerson

3.13  'residentialPerson'

   The residentialPerson 'residentialPerson' object class is the basis of an entry which
   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 $
               facsimileTelephoneNumber $ preferredDeliveryMethod $
               street $ postOfficeBox $ postalCode $ postalAddress $
               physicalDeliveryOfficeName $ st $ l ) )





Dally

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  January 4 October 2005                [Page 21] 26]

INTERNET-DRAFT     draft-ietf-ldapbis-user-schema-08           July 2004     LDAP: Schema for User Applications      April 4, 2005


4.  IANA Considerations

   It is requested that the Internet Assigned Numbers Authority (IANA)
   update the LDAP descriptors registry as indicated in the following
   template:

      Subject: Request for LDAP Descriptor Registration Update
      Descriptor (short name): see comment
      Object Identifier: see comment
      Person & email address to contact for further information:
            Kathy Dally <kdally@mitre.org>
         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.]
      Author/Change Controller: IESG


   Comments
   In the LDAP descriptors registry, the following descriptors (short
   names) should be updated to refer to RFC XXXX [editor's note:  This
   document].  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
      dc
      countryName                  A    2.5.4.6
      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
      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                           A    RESERVED
      groupOfNames                 O    2.5.6.9
      groupOfUniqueNames           O    2.5.6.17



Sciberras                Expires 4 October 2005                [Page 27]

INTERNET-DRAFT     LDAP: Schema for User Applications      April 4, 2005


      houseIdentifier              A    2.5.4.51
      initials                     A    2.5.4.43
      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


Dally                   Expires  January 2005                  [Page 22]
INTERNET-DRAFT     draft-ietf-ldapbis-user-schema-08           July 2004
      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
      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                       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



Sciberras                Expires 4 October 2005                [Page 28]

INTERNET-DRAFT     LDAP: Schema for User Applications      April 4, 2005


   information about the real-world objects they represent, which can be
   people, organizations or devices.  Most countries have privacy laws
   regarding the publication of information about people.

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

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

   Certainly, applications which intend to replace the userPassword 'userPassword'
   value(s) with new value(s) should use modify/replaceValues (or
   modify/deleteAttribute+addAttribute).  Additionally, server 



Dally                   Expires  January 2005                  [Page 23]
INTERNET-DRAFT     draft-ietf-ldapbis-user-schema-08           July 2004
   implementations are encouraged to provide administrative controls
   which, if enabled, restrict the userPassword 'userPassword' attributer to one
   value.

   Note that when used for authentication purposes [AuthMeth], 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.

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

   The uid 'uid' attribute type definition in this document supercedes supersedes the
   specification of the userid '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 and M. Smith.

   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 who edited early drafts of this document.



Sciberras                Expires 4 October 2005                [Page 29]

INTERNET-DRAFT     LDAP: Schema for User Applications      April 4, 2005


7.  References

7.1  Normative

   [E.123]       Notation for national and international telephone
                 numbers, ITU-T Recommendation E.123, 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

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

   [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 - CONCEPTS AND
                 FACILITIES", RFC 1034,  January 1987

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


Dally                   Expires  January 2005                  [Page 24]
INTERNET-DRAFT     draft-ietf-ldapbis-user-schema-08           July 2004

   [RFC2234]     Crocker, D., Overell P., "Augmented BNF for Syntax
                 Specifications: ABNF", RFC 2234, November 1997

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

   [ROADMAP]

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

   [SASLprep]    Zeilenga K., "SASLprep: Stringprep profile for user
                 names and passwords", draft-ietf-sasl-saslprep-xx (a
                 work in progress)

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

   [X.121]       International numbering plan for public data networks,



Sciberras                Expires 4 October 2005                [Page 30]

INTERNET-DRAFT     LDAP: Schema for User Applications      April 4, 2005


                 ITU-T Recommendation X.121, 1996

   [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  Informative

   [AUTHMETH]

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

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

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

   [LDAP-CERT]  Klasen, N., Gietz, P. "An LDAPv3 Schema

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

   [LDAP-CRL]  Chadwick, D. W. and M. V. Sahalayev, "Internet X.509
               Public Key Infrastructure - LDAP Schema for X.509 CRLs",
               Internet Draft  draft-ietf-pkix-ldap-crl-schema-xx
                 draft-zeilenga-ldap-x509-xx (a work in progress)

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




Dally                   Expires  January 2005                  [Page 25]
INTERNET-DRAFT     draft-ietf-ldapbis-user-schema-08           July 2004

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

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

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

   [RFC3377]  Hodges, J., Morgan, R., "Lightweight Directory Access 
              Protocol (v3):  Technical Specification", RFC 3377, 
              September 2002

   [SASLprep]  Zeilenga K., "SASLprep: Stringprep profile for user 
               names and passwords", draft-ietf-sasl-saslprep-xx (a 
               work in progress)

   [X.500]       The Directory, ITU-T Recommendations X.501-X.525, 1993

8.  Author's Address

   Kathy Dally
   The MITRE Corp.
   7515 Colshire Dr., H300
   McLean VA 22102
   USA

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

   Phone:  +1 703 883 6058  +61 3 9896 7833
   Email:  kdally@mitre.org  andrew.sciberras@eb2bcom.com



Sciberras                Expires 4 October 2005                [Page 31]

INTERNET-DRAFT     LDAP: Schema for User Applications      April 4, 2005


9.  Intellectual Property Rights (IPR) Disclosure

   By submitting this Internet-Draft, I certify that any applicable 
   patent or other IPR claims of which I am aware have been disclosed, 
   or will be disclosed, and any of which I become aware will be 
   disclosed, in accordance with RFC 3668.


10. IPR Notice Statement

   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.




Dally                   Expires  January 2005                  [Page 26]
INTERNET-DRAFT     draft-ietf-ldapbis-user-schema-08           July 2004

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


11.  Copyright Notice and Disclaimer

   Copyright (C) The Internet Society (2004).  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. the IETF at
   ietf-ipr@ietf.org.

10.  Disclaimer of Validity

   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.























Dally

Copyright Statement 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.













Sciberras                Expires  January 4 October 2005                [Page 27] 32]

INTERNET-DRAFT     draft-ietf-ldapbis-user-schema-08           July 2004     LDAP: Schema for User Applications      April 4, 2005


                  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 and to each object class.

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

      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]. [LDAP-CERT].

      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.


Dally




Sciberras                Expires  January 4 October 2005                [Page 28] 33]

INTERNET-DRAFT     draft-ietf-ldapbis-user-schema-08           July 2004     LDAP: Schema for User Applications      April 4, 2005


      12. Numerous edititorial changes.

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

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

      changes since 07:

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

      16. Clarified and corrected examples in owner and roleOccupant
          attribute types.

      17. Added RFC 2234 to normative references.

      18. Added RFC 1274 and RFC 2798 to informative references.

      19. Removed the statement about RFC 2026 conformance.

      20. Added the IPR Disclosure and Notice

      21. Updated the Copyright text.




























Dally

      changes since 08:

      22. Included RFC 2377 into Updates header and Informative
          References

      23. Changed Editor information to Andrew Sciberras.

      24. Updated I-D Template information.

      25. References made consistent with other LDAPbis ID's. [ROADMAP]
          -> [RoadMap] and [AUTHMETH] -> [AuthMeth].

      26. Changed Introduction to include an (LDAP) acronym after the
          first usage.

      27. Renamed section 1.1 to "Relationship with other
          specifications" from "Situation".

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

      29. Replaced PKI schema references to use draft-zeilenga-ldap-
          x509-xx



Sciberras                Expires  January 4 October 2005                [Page 29] 34]

INTERNET-DRAFT     LDAP: Schema for User Applications      April 4, 2005


      30. Spelt out and referenced ABNF on first usage.

      31. Removed Section 2.4 (Source). Replaced the source table with
          explicit references for each definition.

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

      33. The layout of attribute type definitions has been changed to
          provide consistency throughout the document:
          > Section Heading
          > Description of Attribute type
          > Multivalued description
          > Source Information
          > Definition
          > Example
          > Additional Comments

          Adding this consistent output included the addition of
          examples to some definitions.

      34. References to alternate names for attributes types are
          provided with a reference to where they were originally
          specified.

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

      36. Spelt out ISDN on first usage.

      37. Inserted a reference to [Syntaxes] for the
          'teletexTerminalIdentifier' definition's SYNTAX OID.

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

      39. Renamed all instances of supercede to supersede.

      40. Moved [F.1], [F.30] and [SASLprep] from informative to
          normative references.

      41. Changed the 'c' definition to be consistent with X.500.

      42. Added text to 'dc', making the distinction between 'stored'
          and 'query' values when preparing IDN strings.




Sciberras                Expires 4 October 2005                [Page 35]


----