-INTERNET-DRAFT K. Dally, Editor
-Intended Category: Standard Track The MITRE Corp.
-Expires: October 2003 April 2003
-Updates: RFC 2247
+
+INTERNET-DRAFT Editor: A. Sciberras
+Intended Category: Standard Track eB2Bcom
+Updates: RFC 2247, RFC 2798, RFC 2377 April 4, 2005
Obsoletes: RFC 2256
- LDAP: User Schema
- <draft-ietf-ldapbis-user-schema-05>
+ LDAP: Schema for User Applications
+ draft-ietf-ldapbis-user-schema-09.txt
+
+ Copyright (C) The Internet Society (2005). All Rights Reserved.
+
+ Status of this Memo
+
+ This document is an Internet-Draft and is subject to all provisions
+ of Section 3 of RFC 3978. 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 become aware will 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 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".
-Status of this Memo
+ The list of current Internet-Drafts can be accessed at
+ http://www.ietf.org/1id-abstracts.html
- This document is an Internet-Draft and is in full conformance with
- all provisions of Section 10 of RFC 2026.
+ The list 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.
- 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 author <kdally@mitre.org>.
+ 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>.
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
- other groups may also distribute working documents as
- Internet-Drafts. Internet-Drafts are draft documents valid for a
- maximum of six months and may be updated, replaced, or obsoleted by
- other documents at any time. It is inappropriate to use
- Internet-Drafts as reference material or to cite them other than as
- "work in progress."
+ This Internet-Draft expires on 4 October 2005.
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/ietf/1id-abstracts.txt.
+Copyright Notice
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html.
+ Copyright (C) The Internet Society 2005. All Rights Reserved.
-Copyright Notice
- Copyright 2003, The Internet Society. All Rights Reserved.
+Sciberras Expires 4 October 2005 [Page 1]
+\f
+INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
Abstract
- This document is a integral part of the LDAP technical specification
- [ROADMAP]. It provides an overview of attribute types and object
- classes intended for use by LDAP directory clients for many
- directory services, such as, White Pages. Originally specified the
- ISO/IEC 9594 and 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.
-
-
-Dally Expires October 2003 [Page 1]
-INTERNET-DRAFT draft-ietf-ldapbis-user-schema-05 April 2003
-
-
- Table of Contents
+ This document is an integral part of the Lightweight Directory Access
+ Protocol (LDAP) technical specification [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.
-Status of this Memo 1
-Copyright Notice 1
-Abstract 1
-Table of Contents 2
-1. Introduction 4
- 1.1 Situation 4
- 1.2 Conventions 4
- 1.3 General Issues 4
- 1.4 Source 5
-2. Attribute Types 5
- 2.1 businessCategory 5
- 2.2 c 5
- 2.3 cn 6
- 2.4 dc 6
- 2.5 description 6
- 2.6 destinationIndicator 6
- 2.7 distinguishedName 7
- 2.8 dnQualifier 7
- 2.9 enhancedSearchGuide 7
- 2.10 facsimileTelephoneNumber 7
- 2.11 generationQualifier 8
- 2.12 givenName 8
- 2.13 houseIdentifier 8
- 2.14 initials 8
- 2.15 internationalISDNNumber 8
- 2.16 l 9
- 2.17 member 9
- 2.18 name 9
- 2.19 o 9
- 2.20 ou 9
- 2.21 owner 10
- 2.22 physicalDeliveryOfficeName 10
- 2.23 postalAddress 10
- 2.24 postalCode 10
- 2.25 postOfficeBox 10
- 2.26 preferredDeliveryMethod 11
- 2.27 registeredAddress 11
- 2.28 roleOccupant 11
- 2.29 searchGuide 11
- 2.30 seeAlso 12
- 2.31 serialNumber 12
- 2.32 sn 12
- 2.33 st 12
- 2.34 street 12
- 2.35 telephoneNumber 12
-Dally Expires October 2003 [Page 2]
-INTERNET-DRAFT draft-ietf-ldapbis-user-schema-05 April 2003
- 2.36 teletexTerminalIdentifier 13
- 2.37 telexNumber 13
- 2.38 title 13
- 2.39 uniqueMember 13
- 2.40 userPassword 14
- 2.41 x121Address 14
- 2.42 x500UniqueIdentifier 14
-3. Object Classes 15
- 3.1 applicationProcess 15
- 3.2 country 15
- 3.3 device 15
- 3.4 domain 15
- 3.5 groupOfNames 16
- 3.6 groupOfUniqueNames 16
- 3.7 locality 17
- 3.8 organization 17
- 3.9 organizationalPerson 17
- 3.10 organizationalRole 18
- 3.11 organizationalUnit 18
- 3.12 person 18
- 3.13 residentialPerson 19
-4. IANA Considerations 19
-5. Security Considerations 19
-6. Acknowledgements 19
-7. References 20
- 7.1 Normative 20
- 7.2 Informative 20
-8. Author's Address 21
-9. Full Copyright Statement 21
-Dally Expires October 2003 [Page 3]
-INTERNET-DRAFT draft-ietf-ldapbis-user-schema-05 April 2002
-1. Introduction
- This document provides an overview of attribute types and object
- classes intended for use by LDAP directory clients for many
- directory services, such as, White Pages. Originally specified in
- the ISO/IEC 9594 and 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
- This document is a integral part of the LDAP technical specification
- [ROADMAP] which obsoletes the previously defined LDAP technical
- specification [RFC3377] 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. Sections
- 3.4 and 4.4 of this document supercede the technical specifications
- for the 'dc' attribute type and 'domain' object class found in
- RFC 2247. The remainder of RFC 2247 remains in force.
+Sciberras Expires 4 October 2005 [Page 2]
+\f
+INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
+
+
+Table of Contents
+
+ Status of this Memo . . . . . . . . . . . . . . . . . . . . . . . 1
+ Copyright Notice. . . . . . . . . . . . . . . . . . . . . . . . . 1
+ Abstract. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
+ Table of Contents . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 5
+ 1.1 Relationship with other specifications . . . . . . . . . 5
+ 1.2 Conventions. . . . . . . . . . . . . . . . . . . . . . . 5
+ 1.3 General Issues . . . . . . . . . . . . . . . . . . . . . 5
+
+ 2. Attribute Types . . . . . . . . . . . . . . . . . . . . . . . 6
+ 2.1 'businessCategory' . . . . . . . . . . . . . . . . . . . 6
+ 2.2 'c'. . . . . . . . . . . . . . . . . . . . . . . . . . . 6
+ 2.3 'cn' . . . . . . . . . . . . . . . . . . . . . . . . . . 7
+ 2.4 'dc' . . . . . . . . . . . . . . . . . . . . . . . . . . 7
+ 2.5 'description'. . . . . . . . . . . . . . . . . . . . . . 8
+ 2.6 'destinationIndicator' . . . . . . . . . . . . . . . . . 8
+ 2.7 'distinguishedName'. . . . . . . . . . . . . . . . . . . 8
+ 2.8 'dnQualifier'. . . . . . . . . . . . . . . . . . . . . . 9
+ 2.9 'enhancedSearchGuide'. . . . . . . . . . . . . . . . . . 9
+ 2.10 'facsimileTelephoneNumber' . . . . . . . . . . . . . . . 10
+ 2.11 'generationQualifier'. . . . . . . . . . . . . . . . . . 10
+ 2.12 'givenName'. . . . . . . . . . . . . . . . . . . . . . . 10
+ 2.13 'houseIdentifier'. . . . . . . . . . . . . . . . . . . . 11
+ 2.14 'initials' . . . . . . . . . . . . . . . . . . . . . . . 11
+ 2.15 'internationalISDNNumber'. . . . . . . . . . . . . . . . 11
+ 2.16 'l'. . . . . . . . . . . . . . . . . . . . . . . . . . . 12
+ 2.17 'member' . . . . . . . . . . . . . . . . . . . . . . . . 12
+ 2.18 'name' . . . . . . . . . . . . . . . . . . . . . . . . . 12
+ 2.19 'o'. . . . . . . . . . . . . . . . . . . . . . . . . . . 13
+ 2.20 'ou' . . . . . . . . . . . . . . . . . . . . . . . . . . 13
+ 2.21 'owner'. . . . . . . . . . . . . . . . . . . . . . . . . 13
+ 2.22 'physicalDeliveryOfficeName' . . . . . . . . . . . . . . 13
+ 2.23 'postalAddress'. . . . . . . . . . . . . . . . . . . . . 14
+ 2.24 'postalCode' . . . . . . . . . . . . . . . . . . . . . . 14
+ 2.25 'postOfficeBox'. . . . . . . . . . . . . . . . . . . . . 14
+ 2.26 'preferredDeliveryMethod'. . . . . . . . . . . . . . . . 15
+ 2.27 'registeredAddress'. . . . . . . . . . . . . . . . . . . 15
+ 2.28 'roleOccupant' . . . . . . . . . . . . . . . . . . . . . 16
+ 2.29 'searchGuide'. . . . . . . . . . . . . . . . . . . . . . 16
+ 2.30 'seeAlso'. . . . . . . . . . . . . . . . . . . . . . . . 16
+ 2.31 'serialNumber' . . . . . . . . . . . . . . . . . . . . . 17
+ 2.32 'sn' . . . . . . . . . . . . . . . . . . . . . . . . . . 17
+ 2.33 'st' . . . . . . . . . . . . . . . . . . . . . . . . . . 17
+ 2.34 'street' . . . . . . . . . . . . . . . . . . . . . . . . 18
+ 2.35 'telephoneNumber'. . . . . . . . . . . . . . . . . . . . 18
+ 2.36 'teletexTerminalIdentifier'. . . . . . . . . . . . . . . 18
+
+
+
+Sciberras Expires 4 October 2005 [Page 3]
+\f
+INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
+
+
+ 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 'x500UniqueIdentifier' . . . . . . . . . . . . . . . . . 21
+
+ 3. Object Classes. . . . . . . . . . . . . . . . . . . . . . . . 22
+ 3.1 'applicationProcess' . . . . . . . . . . . . . . . . . . 22
+ 3.2 'country'. . . . . . . . . . . . . . . . . . . . . . . . 22
+ 3.3 'dcObject' . . . . . . . . . . . . . . . . . . . . . . . 22
+ 3.4 'device' . . . . . . . . . . . . . . . . . . . . . . . . 23
+ 3.5 'groupOfNames' . . . . . . . . . . . . . . . . . . . . . 23
+ 3.6 'groupOfUniqueNames' . . . . . . . . . . . . . . . . . . 23
+ 3.7 'locality' . . . . . . . . . . . . . . . . . . . . . . . 24
+ 3.8 'organization' . . . . . . . . . . . . . . . . . . . . . 24
+ 3.9 'organizationalPerson' . . . . . . . . . . . . . . . . . 24
+ 3.10 'organizationalRole' . . . . . . . . . . . . . . . . . . 25
+ 3.11 'organizationalUnit' . . . . . . . . . . . . . . . . . . 25
+ 3.12 'person' . . . . . . . . . . . . . . . . . . . . . . . . 26
+ 3.13 'residentialPerson'. . . . . . . . . . . . . . . . . . . 26
+ 3.14 'uidObject'. . . . . . . . . . . . . . . . . . . . . . . 26
+
+ 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
+
+ 5. Security Considerations . . . . . . . . . . . . . . . . . . . 28
+
+ 6. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . 29
+
+ 7. References. . . . . . . . . . . . . . . . . . . . . . . . . . 30
+ 7.1 Normative. . . . . . . . . . . . . . . . . . . . . . . . 30
+ 7.2 Informative. . . . . . . . . . . . . . . . . . . . . . . 31
+
+ 8. Author's Address. . . . . . . . . . . . . . . . . . . . . . . 31
+
+ 9. Intellectual Property Statement . . . . . . . . . . . . . . . 32
+
+ 10. Disclaimer of Validity. . . . . . . . . . . . . . . . . . . . 32
+
+
+
+
+
+
+
+
+
+
+
- A number of schema elements which were included in the previous
+Sciberras Expires 4 October 2005 [Page 4]
+\f
+INTERNET-DRAFT 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 Relationship with other specifications
+
+ This document is an integral part of the LDAP technical specification
+ [Roadmap] 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]. 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 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-PKI]. Unless reintroduced in future technical specifications,
+ revision of LDAP. PKI-related schema elements are now specified in
+ [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",
+ 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 in Section 3 of [Syntaxes]
- and Matching Rules specified in Section 4 of [Syntaxes].
+ This document references Syntaxes defined in Section 3 of [Syntaxes]
+ and Matching Rules defined in Section 4 of [Syntaxes].
- The definitions of Attribute Types and Object Classes are written
- using the ABNF form of AttributeTypeDescription and
- ObjectClassDescription given in [Models]. Lines have been folded
- for readability.
+ The definitions of Attribute Types and Object Classes are written
+Sciberras Expires 4 October 2005 [Page 5]
+\f
+INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
+ using the Augmented Backus-Naur Form (ABNF) [RFC2234] of
+ AttributeTypeDescription and ObjectClassDescription given in
+ [Models]. Lines have been folded for readability. When such values
+ are transferred as attribute values in the LDAP Protocol the 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 '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.
-Dally Expires October 2003 [Page 4]
-INTERNET-DRAFT draft-ietf-ldapbis-user-schema-05 April 2003
+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])
-1.4 Source
+ ( 2.5.4.15 NAME 'businessCategory'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
- The schema definitions in this document are based on those found in
- the X.500-series [X.520] and [X.521] and RFC 2247 [RFC2247],
- specifically:
+ 1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax
+ [Syntaxes].
- Sections Source
- ============ ==================
- 2.1 - 2.3 X.520 [X.520]
- 2.4 RFC 2247 [RFC2247]
- 2.5 - 2.42 X.520 [X.520]
- 3.1 - 3.3 X.521 [X.521]
- 3.4 RFC 2247 [RFC2247]
- 3.5 - 3.13 X.521 [X.521]
+ Examples: "banking", "transportation" and "real estate".
+2.2 'c'
-2. Attribute Types
+ The 'c' ('countryName' in X.500) attribute type contains a two-letter
+ ISO 3166 [ISO3166] country code.
+ (Source: X.520 [X.520])
- The Attribute Types contained in this section hold user information.
+ ( 2.5.4.6 NAME 'c'
+ SUP name
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.11
+ SINGLE-VALUE )
- There is no requirement that servers implement the following
- Attribute Types:
+ 1.3.6.1.4.1.1466.115.121.1.11 refers to the Country String syntax
+ [Syntaxes].
- searchGuide
- teletexTerminalIdentifier
- 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
+Sciberras Expires 4 October 2005 [Page 6]
+\f
+INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
- This Attribute Type describes the kind of business performed by
- an organization.
- ( 2.5.4.15 NAME 'businessCategory'
- EQUALITY caseIgnoreMatch
- SUBSTR caseIgnoreSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{128} )
+ Examples: "DE", "AU" and "FR".
- The SYNTAX oid indicates the Directory String syntax.
+2.3 'cn'
-2.2 c
+ 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])
- This is the X.520 [X.520] countryName Attribute Type, which contains
- a two-letter ISO 3166 [ISO3166]country code.
+ ( 2.5.4.3 NAME 'cn'
+ SUP name )
- ( 2.5.4.6 NAME 'c'
- SUP name
- SINGLE-VALUE )
+ Examples: "Martin K Smith", "Marty Smith" and "printer12".
+2.4 'dc'
+ The 'dc' ('domainComponent' in RFC 2247) attribute type is a string
+ holding one component, a <label> [RFC1034], of a DNS domain 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])
-Dally Expires October 2003 [Page 5]
-INTERNET-DRAFT draft-ietf-ldapbis-user-schema-05 April 2003
+ ( 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].
-2.3 cn
+ Examples: Valid values include "example" and "com". The value
+ "example.com" is invalid, because it contains two <label>
+ components.
- This is the X.520 [X.520] commonName Attribute Type, which contains
- a name of an object. If the object corresponds to a person, it is
- typically the person's full name.
+ It is noted that the directory will not ensure that values of this
+ attribute conform to the label production [RFC1034]. It is the
+ application's responsibility to ensure domains it stores in this
+ attribute are appropriately represented.
- ( 2.5.4.3 NAME 'cn'
- SUP name )
+ It is also noted that applications supporting Internationalized
+ Domain Names SHALL use the ToASCII method [RFC3490] to produce
+ <label> components of the <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.
-2.4 dc
- The dc (short for domainComponent) attribute type is defined as
- follows:
- ( 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 )
+Sciberras Expires 4 October 2005 [Page 7]
+\f
+INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
- The value of this attribute is a string holding one component of a
- DNS domain 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.
-2.5 description
+2.5 'description'
- This Attribute Type contains a human-readable description of
- the object.
+ 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])
- ( 2.5.4.13 NAME 'description'
- EQUALITY caseIgnoreMatch
- SUBSTR caseIgnoreSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{1024} )
+ ( 2.5.4.13 NAME 'description'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
- The SYNTAX oid indicates the Directory String syntax.
+ 1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax
+ [Syntaxes].
-2.6 destinationIndicator
+ Examples: "a color printer", "Maintenance is done every Monday, at
+ 1pm." and "distribution list for all technical staff".
- This attribute is used for the telegram service.
+2.6 'destinationIndicator'
- ( 2.5.4.27 NAME 'destinationIndicator'
- EQUALITY caseIgnoreMatch
- SUBSTR caseIgnoreSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.44{128} )
+ The 'destinationIndicator' attribute type contains country and city
+ strings, associated with the object (the 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])
- The SYNTAX oid indicates the Printable String syntax.
+ ( 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'
+ 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
-Dally Expires October 2003 [Page 6]
-INTERNET-DRAFT draft-ietf-ldapbis-user-schema-05 April 2003
+Sciberras Expires 4 October 2005 [Page 8]
+\f
+INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
-2.7 distinguishedName
- This Attribute Type is not used as the name of the object itself,
- but it is instead a base type from which attributes with DN syntax
- inherit.
+ 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 do not support attribute
- subtyping need not recognize this attribute in requests. Client
- implementations MUST NOT assume that LDAP servers are capable of
+ 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].
+
+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 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].
+
+ Examples: "20050322123345Z" - timestamps can be used to disambiguate
+ information.
+ "123456A" - serial numbers can be used to disambiguate
+ information.
+
+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])
+
+
+
- ( 2.5.4.49 NAME 'distinguishedName'
- EQUALITY distinguishedNameMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
+Sciberras Expires 4 October 2005 [Page 9]
+\f
+INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
- The SYNTAX oid indicates the DN syntax.
-2.8 dnQualifier
+ ( 2.5.4.47 NAME 'enhancedSearchGuide'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.21 )
- The dnQualifier Attribute Type specifies disambiguating information
- to add to the relative distinguished name of an entry. It is
- intended for use when merging data from multiple sources in order to
- prevent conflicts between entries which would otherwise have the same
- name. It is recommended that the value of the dnQualifier attribute
- be the same for all entries from a particular source.
+ 1.3.6.1.4.1.1466.115.121.1.21 refers to the Enhanced Guide syntax
+ [Syntaxes].
- ( 2.5.4.46 NAME 'dnQualifier'
- EQUALITY caseIgnoreMatch
- ORDERING caseIgnoreOrderingMatch
- SUBSTR caseIgnoreSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 )
+ Examples: "person#(sn$APPROX)#wholeSubtree"
+ "organizationalUnit#(ou$SUBSTR)#oneLevel"
- The SYNTAX oid indicates the Printable String syntax.
+2.10 'facsimileTelephoneNumber'
-2.9 enhancedSearchGuide
+ 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])
- This attribute is for use by X.500 clients in constructing search
- filters.
+ ( 2.5.4.23 NAME 'facsimileTelephoneNumber'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.22 )
- ( 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.22 refers to the Facsimile Telephone
+ Number syntax [Syntaxes].
- The SYNTAX oid indicates the Enhanced Guide syntax.
+ Examples: "+61 3 9896 7801" and "+81 3 347 7418$fineResolution"
-2.10 facsimileTelephoneNumber
+2.11 'generationQualifier'
- A value of this Attribute Type is a telephone number for a facsimile
- terminal (and, optionally, its parameters).
+ The 'generationQualifier' attribute type contains name strings that
+ are the part of a person's name which typically is the suffix. Each
+ string 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 )
+ ( 2.5.4.44 NAME 'generationQualifier'
+ SUP name )
+ Examples: "III", "3rd" and "Jr.".
-Dally Expires October 2003 [Page 7]
-INTERNET-DRAFT draft-ietf-ldapbis-user-schema-05 April 2003
+2.12 'givenName'
+ The '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])
- The SYNTAX oid indicates the Facsimile Telephone Number syntax.
+ ( 2.5.4.42 NAME 'givenName'
+ SUP name )
-2.11 generationQualifier
+ Examples: "Andrew", "Charles" and "Joanne"
- The generationQualifier Attribute Type contains the part of a
- person's name which typically is the suffix, as in "IIIrd".
- ( 2.5.4.44 NAME 'generationQualifier'
- SUP name )
-2.12 givenName
- The givenName Attribute Type is used to hold the part of a person's
- name which is not their surname nor middle name.
+Sciberras Expires 4 October 2005 [Page 10]
+\f
+INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
- ( 2.5.4.42 NAME 'givenName'
- SUP name )
-2.13 houseIdentifier
+2.13 'houseIdentifier'
- This Attribute Type is used to identify a building within a location.
+ 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])
- ( 2.5.4.51 NAME 'houseIdentifier'
- EQUALITY caseIgnoreMatch
- SUBSTR caseIgnoreSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} )
+ ( 2.5.4.51 NAME 'houseIdentifier'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
- The SYNTAX oid indicates the Directory String syntax.
+ 1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax
+ [Syntaxes].
-2.14 initials
+ Examples: "20" to represent a the house number 20.
- The initials Attribute Type contains the initials of some or all of
- an individuals names, except the surname(s).
+2.14 'initials'
- ( 2.5.4.43 NAME 'initials'
- SUP name )
+ 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.15 internationalISDNNumber
+ ( 2.5.4.43 NAME 'initials'
+ SUP name )
- A value of this Attribute Type is an ISDN address, as defined in
- ITU Recommendation E.164 [E.164].
+ Examples: "K. A." and "K".
- ( 2.5.4.25 NAME 'internationalISDNNumber'
- EQUALITY numericStringMatch
- SUBSTR numericStringSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.36{16} ) i
+2.15 'internationalISDNNumber'
- The SYNTAX oid indicates the Numeric String syntax.
+ 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].
+ Example: "0198 333 333"
-Dally Expires October 2003 [Page 8]
-INTERNET-DRAFT draft-ietf-ldapbis-user-schema-05 April 2003
-2.16 l
+Sciberras Expires 4 October 2005 [Page 11]
+\f
+INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
- This is the X.520 [X.520] localityName Attribute Type, which
- contains the name of a locality or place, such as a city, county or
- other geographic region.
- ( 2.5.4.7 NAME 'l'
- SUP name )
+2.16 'l'
-2.17 member
+ The 'l' ('localityName' in X.500) attribute type contains names of a
+ locality or place, such as a city, county or other geographic region.
+ Each name is one value of this multi-valued attribute.
+ (Source: X.520 [X.520])
- A value of this Attribute Type is the Distinguished Name of an
- object that is on a list or in a group.
+ ( 2.5.4.7 NAME 'l'
+ SUP name )
- ( 2.5.4.31 NAME 'member'
- SUP distinguishedName )
+ Examples: "Geneva", "Paris" and "Edinburgh".
-2.18 name
+2.17 'member'
- The name Attribute Type is the attribute supertype from which string
- Attribute Types typically used for naming may be formed. 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
+ The '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'
+
+ 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 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]
+\f
+INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
+
+
+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.
+ (Source: X.520 [X.520])
+
+ ( 2.5.4.10 NAME 'o'
+ SUP name )
+
+ Examples: "Widget", "Widget, Inc." and "Widget, Incorporated.".
+
+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 )
- ( 2.5.4.41 NAME 'name'
- EQUALITY caseIgnoreMatch
- SUBSTR caseIgnoreSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} )
+ Examples: "Finance", "Human Resources" and "Research and
+ Development".
- The SYNTAX oid indicates the Directory String syntax.
+2.21 'owner'
-2.19 o
+ The '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.
+ (Source: X.520 [X.520])
- This is the X.520 [X.520] organizationName Attribute Type, which
- contains the name of an organization.
+ ( 2.5.4.32 NAME 'owner'
+ SUP distinguishedName )
- ( 2.5.4.10 NAME 'o'
- SUP name )
+ 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.20 ou
+2.22 'physicalDeliveryOfficeName'
- This is the X.520 [X.520] organizationalUnitName Attribute Type,
- which contains the name of an organizational unit.
+ The 'physicalDeliveryOfficeName' attribute type contains names that a
+ Postal Service uses to identify a post office.
+ (Source: X.520 [X.520])
- ( 2.5.4.11 NAME 'ou'
- SUP name )
+Sciberras Expires 4 October 2005 [Page 13]
+\f
+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 )
-Dally Expires October 2003 [Page 9]
-INTERNET-DRAFT draft-ietf-ldapbis-user-schema-05 April 2003
+ 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.21 owner
+2.23 'postalAddress'
- A value of this Attribute Type is the Distinguished Name of an
- object that has an ownership responsibility for the object that
- is owned.
+ 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.32 NAME 'owner'
- SUP distinguishedName )
+ ( 2.5.4.16 NAME 'postalAddress'
+ EQUALITY caseIgnoreListMatch
+ SUBSTR caseIgnoreListSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 )
-2.22 physicalDeliveryOfficeName
+ 1.3.6.1.4.1.1466.115.121.1.41 refers to the Postal Address syntax
+ [Syntaxes].
- This attribute contains the name that a Postal Service uses to
- identify a post office.
+ Example: "15 Main St.$Ottawa$Canada".
- ( 2.5.4.19 NAME 'physicalDeliveryOfficeName'
- EQUALITY caseIgnoreMatch
- SUBSTR caseIgnoreSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{128} )
+2.24 'postalCode'
- The SYNTAX oid indicates the Directory String syntax.
+ 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.23 postalAddress
+ ( 2.5.4.17 NAME 'postalCode'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
- This attribute contains an address used by a Postal Service to
- perform services for the object.
+ 1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax
+ [Syntaxes].
- ( 2.5.4.16 NAME 'postalAddress'
- EQUALITY caseIgnoreListMatch
- SUBSTR caseIgnoreListSubstringsMatch
- SYNTAX 1.5.6.1.4.1.1466.115.121.1.41 )
+ Example: "22180", to identify Vienna, VA in the USA.
- The SYNTAX oid indicates the Postal Address syntax.
+2.25 'postOfficeBox'
-2.24 postalCode
+ The 'postOfficeBox' attribute type contains postal box identifiers
+ that a Postal Service uses when a customer arranges to receive mail
- This attribute contains a code used by a Postal Service to identify
- a postal service zone, such as the southern quadrant of a city.
- ( 2.5.4.17 NAME 'postalCode'
- EQUALITY caseIgnoreMatch
- SUBSTR caseIgnoreSubstringsMatch
- SYNTAX 1.5.6.1.4.1.1466.115.121.1.15{40} )
- The SYNTAX oid indicates the Directory String syntax.
+Sciberras Expires 4 October 2005 [Page 14]
+\f
+INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
-2.25 postOfficeBox
- This attribute contains the number that a Postal Service uses when a
- customer arranges to receive mail at a box on premises of the Postal
- Service.
+ at a box on 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].
+ Example: "Box 45".
-Dally Expires October 2003 [Page 10]
-INTERNET-DRAFT draft-ietf-ldapbis-user-schema-05 April 2003
+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.18 NAME 'postOfficeBox'
- EQUALITY caseIgnoreMatch
- SUBSTR caseIgnoreSubstringsMatch
- SYNTAX 1.5.6.1.4.1.1466.115.121.1.15{40} )
+ ( 2.5.4.28 NAME 'preferredDeliveryMethod'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.14
+ SINGLE-VALUE )
- The SYNTAX oid indicates the Directory String syntax.
+ 1.3.6.1.4.1.1466.115.121.1.14 refers to the Delivery Method syntax
+ [Syntaxes].
-2.26 preferredDeliveryMethod
+ 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"
- This attribute contains an indication of the preferred method of
- getting a message to the object.
+2.27 'registeredAddress'
- ( 2.5.4.28 NAME 'preferredDeliveryMethod'
- SYNTAX 1.5.6.1.4.1.1466.115.121.1.14
- SINGLE-VALUE )
+ 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])
- The SYNTAX oid indicates the Delivery Method syntax.
+ ( 2.5.4.26 NAME 'registeredAddress'
+ SUP postalAddress
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 )
-2.27 registeredAddress
+ 1.3.6.1.4.1.1466.115.121.1.41 refers to the Postal Address syntax
+ [Syntaxes].
- This attribute holds a postal address suitable for reception of
- telegrams or expedited documents, where it is necessary to have the
- recipient accept delivery.
+ Example: "Receptionist$Widget, Inc.$15 Main St.$Ottawa$Canada".
- ( 2.5.4.26 NAME 'registeredAddress'
- SUP postalAddress
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 )
- The SYNTAX oid indicates the Postal Address syntax.
-2.28 roleOccupant
- A value of this Attribute Type is the Distinguished Name of an
- object (normally a person) that fulfills the responsibilities of a
- role object.
+Sciberras Expires 4 October 2005 [Page 15]
+\f
+INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
- ( 2.5.4.33 NAME 'roleOccupant'
- SUP distinguishedName )
-2.29 searchGuide
+2.28 'roleOccupant'
- This Attribute Type is for use by clients in constructing search
- filters. It is superseded by enhancedSearchGuide, described above
- in section 2.9.
+ The 'roleOccupant' attribute type contains the 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.14 NAME 'searchGuide'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.25 ) ; Guide
+ ( 2.5.4.33 NAME 'roleOccupant'
+ SUP distinguishedName )
-The SYNTAX oid indicates the Guide syntax.
+ 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 '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 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].
-Dally Expires October 2003 [Page 11]
-INTERNET-DRAFT draft-ietf-ldapbis-user-schema-05 April 2003
+ Example: "person#sn$EQ"
+2.30 'seeAlso'
-2.30 seeAlso
+ The 'seeAlso' attribute type contains Distinguished Names of objects
+ that are related to the subject object. Each related object name is
+ one value of this multi-valued attribute.
- A value of this Attribute Type is the Distinguished Name of an
- object that is related to the subject object.
+ (Source: X.520 [X.520])
- ( 2.5.4.34 NAME 'seeAlso'
- SUP distinguishedName )
+ ( 2.5.4.34 NAME 'seeAlso'
+ SUP distinguishedName )
-2.31 serialNumber
+ Example: The person object, "cn=James Brown,ou=employee,o=Widget\,
+ Inc." is related to the role objects, "cn=Football Team
+ Captain,ou=sponsored activities,o=Widget\, Inc." and
- This attribute contains the serial number of a device.
- ( 2.5.4.5 NAME 'serialNumber'
- EQUALITY caseIgnoreMatch
- SUBSTR caseIgnoreSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.44{64} )
- The SYNTAX oid indicates the Printable String syntax.
+Sciberras Expires 4 October 2005 [Page 16]
+\f
+INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
-2.32 sn
- This is the X.520 [X.520] surname Attribute Type, which contains the
- family name of a person.
+ "cn=Chess Team,ou=sponsored activities,o=Widget\, Inc.".
+ 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.5.4.4 NAME 'sn'
- SUP name )
+2.31 'serialNumber'
-2.33 st
+ 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])
- This is the X.520 [X.520] stateOrProvinceName attribute, which
- contains the full name of a state or province.
+ ( 2.5.4.5 NAME 'serialNumber'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 )
- ( 2.5.4.8 NAME 'st'
- SUP name )
+ 1.3.6.1.4.1.1466.115.121.1.44 refers to the Printable String syntax
+ [Syntaxes].
-2.34 street
+ Examples: "WI-3005" and "XF551426".
- This is the X.520 [X.520] streetAddress attribute, which contains the
- physical address of the object to which the entry corresponds, such
- as an address for package delivery.
+2.32 'sn'
- ( 2.5.4.9 NAME 'street'
- EQUALITY caseIgnoreMatch
- SUBSTR caseIgnoreSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{128} )
+ 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])
- The SYNTAX oid indicates the Directory String syntax.
+ ( 2.5.4.4 NAME 'sn'
+ SUP name )
-2.35 telephoneNumber
+ Example: "Smith"
- A value of this Attribute Type is a telephone number complying with
- ITU Recommendation E.123 [E.123].
+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])
-Dally Expires October 2003 [Page 12]
-INTERNET-DRAFT draft-ietf-ldapbis-user-schema-05 April 2003
+ ( 2.5.4.8 NAME 'st'
+ SUP name )
+ Example: "California".
- ( 2.5.4.20 NAME 'telephoneNumber'
- EQUALITY telephoneNumberMatch
- SUBSTR telephoneNumberSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.50{32} )
- The SYNTAX oid indicates the Telephone Number syntax.
-2.36 teletexTerminalIdentifier
- The withdrawal of Rec. F.200 has resulted in the withdrawal of this
- attribute.
- ( 2.5.4.22 NAME 'teletexTerminalIdentifier'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.51 )
- The SYNTAX oid indicates the Teletex Terminal Identifier syntax.
+Sciberras Expires 4 October 2005 [Page 17]
+\f
+INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
-2.37 telexNumber
- A value of this Attribute Type is a telex number, country code, and
- answerback code of a telex terminal.
+2.34 'street'
- ( 2.5.4.21 NAME 'telexNumber'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.52 )
+ 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.). Each street is one value of this
+ multi-valued attribute.
+ (Source: X.520 [X.520])
- The SYNTAX oid indicates the Telex Number syntax.
+ ( 2.5.4.9 NAME 'street'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
-2.38 title
+ 1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax
+ [Syntaxes].
- This attribute contains the title, such as "Vice President", of a
- person in their organizational context. The "personalTitle"
- attribute would be used for a person's title independent of their
- job function.
+ Example: "15 Main St."
- ( 2.5.4.12 NAME 'title'
- SUP name )
+2.35 'telephoneNumber'
-2.39 uniqueMember
+ 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])
- A value of this Attribute Type is the Distinguished Name of an
- object that is on a list or in a group, where the Relative
- Distinguished Name of the object includes a value that distinguishs
- between objects when a distinguished name has been reused.
+ ( 2.5.4.20 NAME 'telephoneNumber'
+ EQUALITY telephoneNumberMatch
+ SUBSTR telephoneNumberSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 )
- ( 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.50 refers to the Telephone Number syntax
+ [Syntaxes].
-The SYNTAX oid indicates the Name and Optional UID syntax.
+ Example: "+1 234 567 8901".
+2.36 '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].
-Dally Expires October 2003 [Page 13]
-INTERNET-DRAFT draft-ietf-ldapbis-user-schema-05 April 2003
-2.40 userPassword
- A value of this Attribute Type is a character string that is known
- only to the user and the system to which the user has access.
- ( 2.5.4.35 NAME 'userPassword'
- EQUALITY octetStringMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.40{128} )
+Sciberras Expires 4 October 2005 [Page 18]
+\f
+INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
- The SYNTAX oid indicates the Octet String syntax.
- 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
+2.37 'telexNumber'
+
+ The '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'
+
+ 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" and "CEO".
+
+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].
+
+ Examples: "s9709015", "admin" and "Administrator".
+
+2.40 'uniqueMember'
+
+ The 'uniqueMember' attribute type contains the Distinguished Names of
+
+
+
+Sciberras Expires 4 October 2005 [Page 19]
+\f
+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. 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].
+
+ 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'
+
+ 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 [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.
-2.41 x121Address
+ An example of a need for multiple values in the '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 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]
+\f
+INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
+
+
+ consecutive periods to be valid in the system.
+
+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 )
- A value of this Attribute Type is a data network address as defined
- by ITU Recommendation X.121 [X.121].
+ 1.3.6.1.4.1.1466.115.121.1.36 refers to the Numeric String syntax
+ [Syntaxes].
- ( 2.5.4.24 NAME 'x121Address'
- EQUALITY numericStringMatch
- SUBSTR numericStringSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.36{15} )
+ Example: "36111222333444555".
- The SYNTAX oid indicates the Numeric String syntax.
+2.43 'x500UniqueIdentifier'
-2.42 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].
+ (Source: X.520 [X.520])
- The x500UniqueIdentifier Attribute Type is used to distinguish
- between objects when a distinguished name has been reused. In X.520
- [X.520], this Attribute Type is called uniqueIdentifier. This is a
- different Attribute Type from both the "uid" and "uniqueIdentifier"
- Attribute Types.
+ ( 2.5.4.45 NAME 'x500UniqueIdentifier'
+ EQUALITY bitStringMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 )
- ( 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].
- The SYNTAX oid indicates the Bit String syntax.
-Dally Expires October 2003 [Page 14]
-INTERNET-DRAFT draft-ietf-ldapbis-user-schema-05 April 2003
+
+Sciberras Expires 4 October 2005 [Page 21]
+\f
+INTERNET-DRAFT 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 attribute.
+ LDAP servers SHOULD recognize all the Object Classes listed here as
+ values of the 'objectClass' attribute (see [Models]).
-3.1 applicationProcess
+3.1 'applicationProcess'
- The applicationProcess Object Class definition is the basis of an
+ The '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 ) )
+ ( 2.5.6.11 NAME 'applicationProcess'
+ SUP top
+ STRUCTURAL
+ MUST cn
+ MAY ( seeAlso $
+ ou $
+ l $
+ description ) )
-3.2 country
+3.2 'country'
- The country Object Class definition is the basis of an entry which
+ The '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
-
- The device Object Class is the basis of an entry which represents
- an appliance or computer or network element.
-
- ( 2.5.6.14 NAME 'device'
- SUP top
- STRUCTURAL
- MUST cn
- MAY ( serialNumber $
- seeAlso $
- owner $
- ou $
- o $
- l $
- description ) )
-
-3.4 domain
-
- The domain Object Class is the basis of an entry which represents a
- portion of a network, as organized by DNS.
-
-
-Dally Expires October 2003 [Page 15]
-INTERNET-DRAFT draft-ietf-ldapbis-user-schema-05 April 2003
-
-
- ( 0.9.2342.19200300.100.4.13 NAME 'domain'
- SUP top
- STRUCTURAL
- MUST dc
- MAY ( userPassword $ searchGuide $ seeAlso $ businessCategory $
- x121Address $ registeredAddress $ destinationIndicator $
- preferredDeliveryMethod $ telexNumber $
- teletexTerminalIdentifier $ telephoneNumber $
- internationaliSDNNumber $ facsimileTelephoneNumber $ street $
- postOfficeBox $ postalCode $ postalAddress $
- physicalDeliveryOfficeName $ st $ l $ description $ o $
- associatedName ) )
-
- An example entry would be:
-
- dn: dc=tcp,dc=critical-angle,dc=com
- objectClass: top
- objectClass: domain
- dc: tcp
- description: a placeholder entry used with SRV records
-
-3.5 groupOfNames
-
- The 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.
+ ( 2.5.6.2 NAME 'country'
+ SUP top
+ STRUCTURAL
+ MUST c
+ MAY ( searchGuide $
+ description ) )
- ( 2.5.6.9 NAME 'groupOfNames'
- SUP top
- STRUCTURAL
- MUST ( member $
- cn )
- MAY ( businessCategory $
- seeAlso $
- owner $
- ou $
- o $
- description ) )
+3.3 'dcObject'
-3.6 groupOfUniqueNames
+ 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])
- 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.
+ ( 1.3.6.1.4.1.1466.344 NAME 'dcObject'
+ SUP top
+ AUXILIARY
+ MUST dc )
- ( 2.5.6.17 NAME 'groupOfUniqueNames'
- SUP top
- STRUCTURAL
- MUST ( uniqueMember $
- cn )
- MAY ( businessCategory $
- seeAlso $
-Dally Expires October 2003 [Page 16]
-INTERNET-DRAFT draft-ietf-ldapbis-user-schema-05 April 2003
- owner $
- ou $
- o $
- description ) )
-3.7 locality
+Sciberras Expires 4 October 2005 [Page 22]
+\f
+INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
- The locality Object Class is the basis of an entry which
- represents a place in the physical world.
- ( 2.5.6.3 NAME 'locality'
- SUP top
- STRUCTURAL
- MAY ( street $
- seeAlso $
- searchGuide $
- st $
- l $
- description ) )
+3.4 'device'
-3.8 organization
+ The 'device' object class is the basis of an entry which represents
+ an appliance, computer or network element.
+ (Source: X.521 [X.521])
- The organization Object Class is the basis of an entry which
- represents a structured group of people.
+ ( 2.5.6.14 NAME 'device'
+ SUP top
+ STRUCTURAL
+ MUST cn
+ MAY ( serialNumber $
+ seeAlso $
+ owner $
+ ou $
+ o $
+ l $
+ description ) )
- ( 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.9 organizationalPerson
-
- The organizationalPerson Object Class is the basis of an entry which
- represents a person in relation to an organization.
-
- ( 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 ) )
-
-
-Dally Expires October 2003 [Page 17]
-INTERNET-DRAFT draft-ietf-ldapbis-user-schema-05 April 2003
-
-
-3.10 organizationalRole
-
- The organizationalRole Object Class is the basis of an entry which
- represents a job or function or position in an organization.
-
- ( 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 ) )
-
-3.11 organizationalUnit
-
- The organizationalUnit Object Class is the basis of an entry which
+3.5 'groupOfNames'
+
+ The '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.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])
+
+ ( 2.5.6.17 NAME 'groupOfUniqueNames'
+ SUP top
+ STRUCTURAL
+ MUST ( uniqueMember $
+
+
+
+Sciberras Expires 4 October 2005 [Page 23]
+\f
+INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
+
+
+ cn )
+ MAY ( businessCategory $
+ seeAlso $
+ owner $
+ ou $
+ o $
+ description ) )
+
+3.7 'locality'
+
+ The '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 ) )
+
+3.8 'organization'
+
+ The '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.9 'organizationalPerson'
+
+ The '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]
+\f
+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.10 'organizationalRole'
+
+ The 'organizationalRole' object class is the basis of an entry which
+ represents a 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 ) )
+
+3.11 'organizationalUnit'
+
+ The '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 ) )
+
+
+
- ( 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.12 person
-
- The person Object Class is the basis of an entry which represents a
+Sciberras Expires 4 October 2005 [Page 25]
+\f
+INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
+
+
+3.12 'person'
+
+ The '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.13 'residentialPerson'
- ( 2.5.6.6 NAME 'person'
- SUP top
- STRUCTURAL
- MUST ( sn $
- cn )
- MAY ( userPassword $
- telephoneNumber $
- seeAlso $
- description ) )
+ The '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 ) )
+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 )
-Dally Expires October 2003 [Page 18]
-INTERNET-DRAFT draft-ietf-ldapbis-user-schema-05 April 2003
-3.13 residentialPerson
- The residentialPerson Object Class is the basis of an entry which
- includes a person's residence in the representation of the person.
- ( 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 ) )
+Sciberras Expires 4 October 2005 [Page 26]
+\f
+INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
4. IANA Considerations
Descriptor (short name): see comment
Object Identifier: see comment
Person & email address to contact for further information:
- Kathy Dally <kdally@mitre.org>
- Usage: (A = Attribute Type, O = Object Class) see comment
- Specification: RFC XXXX
+ 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
+ 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]
+\f
+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 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
+ 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
-Dally Expires October 2003 [Page 19]
-INTERNET-DRAFT draft-ietf-ldapbis-user-schema-05 April 2003
-
-
- Comments:
- The following descriptors (short names) should be updated to
- refer to RFC XXXX.
-
- 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
- country O 2.5.6.2
- dc A 0.9.2342.19200300.100.1.25
- 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
- domain O 0.9.2342.19200300.100.4.13
- enhancedSearchGuide A 2.5.4.47
- facsimileTelephoneNumber A 2.5.4.23
- generationQualifier A 2.5.4.44
- givenName A 2.5.4.42
- groupOfNames O 2.5.6.9
- groupOfUniqueNames O 2.5.6.17
- houseIdentifier A 2.5.4.51
- initials A 2.5.4.43
- internationalISDNNumber A 2.5.4.25
- l A 2.5.4.7
- locality O 2.5.6.3
- member A 2.5.4.31
- name A 2.5.4.41
- o A 2.5.4.10
- organization O 2.5.6.4
- organizationalPerson O 2.5.6.7
- organizationalRole O 2.5.6.8
- organizationalUnit O 2.5.6.5
- 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
-
-
-Dally Expires October 2003 [Page 20]
-INTERNET-DRAFT draft-ietf-ldapbis-user-schema-05 April 2003
-
-
- st A 2.5.4.8
- street A 2.5.4.9
- telephoneNumber A 2.5.4.20
- teletexTerminalIdentifier A 2.5.4.22
- telexNumber A 2.5.4.21
- title A 2.5.4.12
- uniqueMember A 2.5.4.50
- 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]
+\f
+INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
-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 or devices. Most countries have privacy laws
+ 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
+ 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.
- It is required that strong authentication be performed in order to
- modify directory entries using LDAP.
+ Multiple attribute values for the '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'
+ value(s) with new value(s) should use modify/replaceValues (or
+ modify/deleteAttribute+addAttribute). Additionally, server
+ implementations are encouraged to provide administrative controls
+ which, if enabled, restrict the '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.
- No new attribute definitions have been added.
+ 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' 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 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 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]
+\f
+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, 1988
+ [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
+ [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
-Dally Expires October 2003 [Page 21]
-INTERNET-DRAFT draft-ietf-ldapbis-user-schema-05 April 2003
+ [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)
- [ISO3166] ISO 3166, "Codes for the representation of names of
- countries".
+ [RFC1034] P. Mockapetris, " DOMAIN NAMES - CONCEPTS AND
+ FACILITIES", RFC 1034, January 1987
- [LDAP-PKI] Chadwick, D. W., Legg S., "LDAP Schema and Syntaxes for
- PKIs", draft-ietf-pkix-ldap-pki-schema-xx (a work in
- progress)
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", RFC 2119, March 1997
- [Models] K. Zeilenga, "LDAP: The Models", draft-ietf-ldapbis-
- models-xx (a work in progress)
+ [RFC2234] Crocker, D., Overell P., "Augmented BNF for Syntax
+ Specifications: ABNF", RFC 2234, November 1997
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", RFC 2119, March 1997
+ [RFC3490] Faltstrom P., Hoffman P., Costello A.,
+ "Internationalizing Domain Names in Applications
+ (IDNA)", RFC 3490, March 2003
- [RFC3377] Hodges, J., Morgan, R., "Lightweight Directory Access
- Protocol (v3): Technical Specification", RFC 3377,
- September 2002
+ [Roadmap] Zeilenga, K., "LDAP: Technical Specification Road
+ Map", draft-ietf-ldapbis-roadmap-xx (a work in
+ progress)
-...[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)
+ [Syntaxes] S. Legg (editor), "LDAP: Syntaxes", draft-ietf-ldapbis-
+ syntaxes-xx (a work in progress)
- [X.121] International numbering plan for public data networks,
- ITU-T Recommendation X.121, 1996
+ [X.121] International numbering plan for public data networks,
- [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
+Sciberras Expires 4 October 2005 [Page 30]
+\f
+INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
-7.2 Informative
- [RFC2247] Kille, S., Wahl, M., Grimstad, A., Huber, R., and
- Sataluri, S., "Using Domains in LDAP/X.500 Distinguished Names",
- RFC 2247, January 1998
+ 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] 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)
+ [RFC1274] Barker, P., Kille, S.,"The COSINE and Internet X.500
+ Schema", RFC 1274, November 1991
+ [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
+ [X.500] The Directory, ITU-T Recommendations X.501-X.525, 1993
+8. Author's Address
-Dally Expires October 2003 [Page 22]
-INTERNET-DRAFT draft-ietf-ldapbis-user-schema-05 April 2003
+ Andrew Sciberras
+ 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
-8. Author's Address
- Kathy Dally
- The MITRE Corp.
- 1575 Colshire Dr., H300
- McLean VA 22102
- USA
-
- Phone: +1 703 883 6058
- Email: kdally@mitre.org
+Sciberras Expires 4 October 2005 [Page 31]
+\f
+INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
+
+
+9. Intellectual Property Statement
-9. Full Copyright 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.
- Copyright (C) The Internet Society (2002). All Rights Reserved.
+ 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.
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
+ The 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.
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
+10. Disclaimer of Validity
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
- BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
- HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
- MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+ 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.
+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.
-Dally Expires October 2003 [Page 23]
-INTERNET-DRAFT draft-ietf-ldapbis-user-schema-05 April 2003
+Sciberras Expires 4 October 2005 [Page 32]
+\f
+INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
- Appendix A Changes RFC 2256
+ 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 lists the changes that have been made from RFC 2256 to
+ this I-D.
- 1. Revised the Status of this Memo.
+ 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, requiring strong
- authentication in order to modify directory entries.
+ 4. Added a Security Considerations section and an IANA
+ considerations section.
- 5. Deleted the conformance requirement for subschema object
+ 5. Deleted the conformance requirement for subschema object
classes in favor of a statement in [Syntaxes].
- 6. Added a Table of Contents.
-
- 7. Added explanations to many attributes.
+ 6. Added explanation to attribute types and to each object class.
- 8. Removed Section 4, Syntaxes, and Section 6, Matching Rules,
+ 7. Removed Section 4, Syntaxes, and Section 6, Matching Rules,
(moved to [Syntaxes]).
- 9. Reordered Section 3, Attributes, and Section 4, Object
- Classes, alphabetically.
+ 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].
- 10. Added an explanation for each object class.
+ 9. Removed the dmdName, knowledgeInformation,
+ presentationAddress, protocolInformation, and
+ supportedApplicationContext attribute types and the dmd,
+ applicationEntity, and dSA object classes.
- 11. Removed the certificate-related Attribute Types:
- authorityRevocationList,
- cACertificate,
- certificateRevocationList,
- crossCertificatePair,
- deltaRevocationList,
- supportedAlgorithms, and
- userCertificate.
+ 10. Deleted the aliasedObjectName and objectClass attribute type
+ definitions. Deleted the alias and top object class
+ definitions. They are included in [Models].
- Removed the certificate-related Object Classes:
- certificationAuthority,
- certificationAuthority-V2,
- cRLDistributionPoint,
- strongAuthenticationUser, and
- userSecurityInformation
+ 11. Added the 'dc' attribute type from RFC 2247.
- Noted that they are covered in PKIX WG documents.
- 12. Removed the dmdName Attribute Type and dmd Object Class
- because they are not in the version of X.500 which
- is referenced.
+Sciberras Expires 4 October 2005 [Page 33]
+\f
+INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
-Dally Expires October 2003 [Page 24]
-INTERNET-DRAFT draft-ietf-ldapbis-user-schema-05 April 2003
+ 12. Numerous edititorial changes.
-......13. Deleted the 'aliasedObjectName' and 'objectClass' attribute
- type definitions. They are included in [Models].
+ 13. Removed upper bound after the SYNTAX oid in all attribute
+ definitions where it appeared.
- 14. Deleted the 'alias' and 'top' object class definitions. They
- are included in [Models].
+ 14. Added text about Unicode, SASLprep and UTF-8 for userPassword.
- 15. Replaced the document title.
+ changes since 07:
- 16. Added the 'dc' attribute and the 'domain' object class from
- RFC 2247.
+ 15. Corrected examples in preferredDeliveryMethod, uniqueMember,
+ postalAddress, and registeredAddress attribute types.
- 17. Deleted the 'knowledgeInformation', 'presentationAddress',
- 'protocolInformation', and 'supportedApplicationContext'
- attributes.
+ 16. Clarified and corrected examples in owner and roleOccupant
+ attribute types.
- 18. Deleted the 'applicationEntity' and 'dSA' object classes.
+ 17. Added RFC 2234 to normative references.
- 19. Added an IANA Considerations section.
+ 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.
+ 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 4 October 2005 [Page 34]
+\f
+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]
+\f
-Dally Expires October 2003 [Page 25]
projects / openldap / blobdiff