-INTERNET-DRAFT K. Dally, Editor
-Intended Category: Standard Track The MITRE Corp.
-Expires: December 2003 June 2003
-Updates: RFC 2247, RFC 2798
+
+INTERNET-DRAFT Editor: A. Sciberras
+Intended Category: Standard Track eB2Bcom
+Updates: RFC 2247, RFC 2798, RFC 2377 April 4, 2005
Obsoletes: RFC 2256
- LDAP: Schema for User Applications
- <draft-ietf-ldapbis-user-schema-06>
+ 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.
-Status of this Memo
+ 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 document is an Internet-Draft and is in full conformance with
- all provisions of Section 10 of RFC 2026.
+ The list of current Internet-Drafts can be accessed at
+ http://www.ietf.org/1id-abstracts.html
+
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html
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 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.
-
-
-Dally Expires December 2003 [Page 1]
-INTERNET-DRAFT draft-ietf-ldapbis-user-schema-06 June 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 7
- 2.7 distinguishedName 7
- 2.8 dnQualifier 7
- 2.9 enhancedSearchGuide 8
- 2.10 facsimileTelephoneNumber 8
- 2.11 generationQualifier 8
- 2.12 givenName 8
- 2.13 houseIdentifier 9
- 2.14 initials 9
- 2.15 internationalISDNNumber 9
- 2.16 l 9
- 2.17 member 10
- 2.18 name 10
- 2.19 o 10
- 2.20 ou 10
- 2.21 owner 11
- 2.22 physicalDeliveryOfficeName 11
- 2.23 postalAddress 11
- 2.24 postalCode 11
- 2.25 postOfficeBox 12
- 2.26 preferredDeliveryMethod 12
- 2.27 registeredAddress 12
- 2.28 roleOccupant 13
- 2.29 searchGuide 13
- 2.30 seeAlso 13
- 2.31 serialNumber 13
- 2.32 sn 14
- 2.33 st 14
- 2.34 street 14
- 2.35 telephoneNumber 14
-Dally Expires December 2003 [Page 2]
-INTERNET-DRAFT draft-ietf-ldapbis-user-schema-06 June 2003
- 2.36 teletexTerminalIdentifier 14
- 2.37 telexNumber 15
- 2.38 title 15
- 2.39 uid 15
- 2.40 uniqueMember 15
- 2.41 userPassword 16
- 2.42 x121Address 16
- 2.43 x500UniqueIdentifier 16
-3. Object Classes 17
- 3.1 applicationProcess 17
- 3.2 country 17
- 3.3 device 17
- 3.4 groupOfNames 18
- 3.5 groupOfUniqueNames 18
- 3.6 locality 18
- 3.7 organization 19
- 3.8 organizationalPerson 19
- 3.9 organizationalRole 19
- 3.10 organizationalUnit 20
- 3.11 person 20
- 3.12 residentialPerson 20
-4. IANA Considerations 21
-5. Security Considerations 22
-6. Acknowledgements 23
-7. References 23
- 7.1 Normative 23
- 7.2 Informative 24
-8. Author's Address 25
-9. Full Copyright Statement 25
+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
-Dally Expires December 2003 [Page 3]
-INTERNET-DRAFT draft-ietf-ldapbis-user-schema-06 June 2002
+ 10. Disclaimer of Validity. . . . . . . . . . . . . . . . . . . . 32
+
+
+
+
+
+
+
+
+
+
+
+
+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
- 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
+ This document provides an overview of attribute types and object
+ classes intended for use by Lightweight Directory Access Protocol
+ (LDAP) directory clients for many directory services, such as, White
+ Pages. Originally specified in the X.500 [X.500] documents, these
+ objects are widely used as a basis for the schema in many LDAP
+ directories. This document does not cover attributes used for the
+ administration of directory servers, nor does it include directory
objects defined for specific uses in other documents.
-1.1 Situation
-
- 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. Section 3.4 of
- this document supercedes the technical specification for the 'dc'
- attribute type found in RFC 2247.[editor's note: Substitute
- replacement RFC at time of publication.] 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
+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
+ 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
-Dally Expires December 2003 [Page 4]
-INTERNET-DRAFT draft-ietf-ldapbis-user-schema-06 June 2003
+ 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
-1.4 Source
+ The Attribute Types contained in this section hold user information.
- The schema definitions in this document are based on those found in
- the X.500-series [X.520] and [X.521], RFC 2798 [RFC2798] and
- RFC 2247 [RFC2247], specifically:
-
- Sections Source
- ============ ==================
- 2.1 - 2.3 X.520 [X.520]
- 2.4 RFC 2247 [RFC2247]
- 2.5 - 2.38 X.520 [X.520]
- 2.39 RFC 2798 [2798]
- 2.40 - 2.43 X.520 [X.520]
- 3.1 - 3.12 X.521 [X.521]
+ There is no requirement that servers implement the 'searchGuide' and
+ 'teletexTerminalIdentifier' attribute types. In fact, their use is
+ greatly discouraged.
- However, the descriptions in this document SHALL be considered
- definitive for use in LDAP.
+ An LDAP server implementation SHOULD recognize the rest of the
+ attribute types described in this section.
+2.1 'businessCategory'
-2. Attribute Types
+ 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])
- The Attribute Types contained in this section hold user information.
+ ( 2.5.4.15 NAME 'businessCategory'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
- There is no requirement that servers implement the following
- attribute types:
+ 1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax
+ [Syntaxes].
- searchGuide
- teletexTerminalIdentifier
+ Examples: "banking", "transportation" and "real estate".
- In fact, their use is greatly discouraged.
+2.2 'c'
- An LDAP server implementation SHOULD recognize the rest of the
- attribute types described in this section.
+ The 'c' ('countryName' in X.500) attribute type contains a two-letter
+ ISO 3166 [ISO3166] country code.
+ (Source: X.520 [X.520])
-2.1 businessCategory
+ ( 2.5.4.6 NAME 'c'
+ SUP name
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.11
+ SINGLE-VALUE )
- The businessCategory attribute type describes the kinds of business
- performed by an organization (e.g., "banking", "transportation").
- Each kind is one value of this multi-valued attribute.
+ 1.3.6.1.4.1.1466.115.121.1.11 refers to the Country String syntax
+ [Syntaxes].
- ( 2.5.4.15 NAME 'businessCategory'
- EQUALITY caseIgnoreMatch
- SUBSTR caseIgnoreSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
- 1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String
- syntax [Syntaxes].
-2.2 c
- The c (countryName) attribute type contains a two-letter ISO 3166
- [ISO3166] country code (e.g., "DE"). (Source: X.520)
+Sciberras Expires 4 October 2005 [Page 6]
+\f
+INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
-Dally Expires December 2003 [Page 5]
-INTERNET-DRAFT draft-ietf-ldapbis-user-schema-06 June 2003
+ Examples: "DE", "AU" and "FR".
+2.3 'cn'
- ( 2.5.4.6 NAME 'c'
- SUP name
- SINGLE-VALUE )
+ The 'cn' ('commonName' in X.500) attribute type contains names of an
+ object. Each name is one value of this multi-valued attribute. If
+ the object corresponds to a person, it is typically the person's full
+ name.
+ (Source: X.520 [X.520])
-2.3 cn
+ ( 2.5.4.3 NAME 'cn'
+ SUP name )
- The cn (commonName) attribute type contains names of an object
- (e.g., "Martin K Smith", "Marty Smith", "printer12"). 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)
+ Examples: "Martin K Smith", "Marty Smith" and "printer12".
- ( 2.5.4.3 NAME 'cn'
- SUP name )
+2.4 'dc'
-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])
- The dc (short for domainComponent) attribute type is a string
- holding one component, a <label> [RFC1034}, of a DNS domain name
- (e.g., "example" or "com", but not "example.com"). 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.
+ ( 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 )
- ( 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].
- 1.3.6.1.4.1.1466.115.121.1.26 refers to the IA5 String
- syntax [Syntaxes].
+ Examples: Valid values include "example" and "com". The value
+ "example.com" is invalid, because it contains two <label>
+ components.
- It is noted that the directory will not ensure that values of this
- attribute conform to the label production [RFC1034]. It is the
- application responsibility to ensure domains it stores in this
+ 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.
- It is also noted that applications supporting Internationalized
- Domain Names SHALL use the ToASCII method [RFC3490] to produce
- <label> components of the <domain> production.
+ 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.5 description
- The description attribute type contains human-readable descriptive
- phrases about the object (e.g., "a color printer", "Maintenance is
- done every Monday, at 1pm."). Each description is one value of this
- multi-valued attribute.
- ( 2.5.4.13 NAME 'description'
- EQUALITY caseIgnoreMatch
+Sciberras Expires 4 October 2005 [Page 7]
+\f
+INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
+2.5 'description'
-Dally Expires December 2003 [Page 6]
-INTERNET-DRAFT draft-ietf-ldapbis-user-schema-06 June 2003
+ 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 )
- 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].
- 1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String
- syntax [Syntaxes].
+ Examples: "a color printer", "Maintenance is done every Monday, at
+ 1pm." and "distribution list for all technical staff".
-2.6 destinationIndicator
+2.6 'destinationIndicator'
- The destinationIndicator attribute type contains country and city
- strings, associated with the object (the addressee), needed to
- provide the Public Telegram Service. Each string is one value of
- this multi-valued attribute. The strings are composed in accordance
- with CCITT Recommendations F.1 [F.1] and F.31 [F.31].
+ 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])
- ( 2.5.4.27 NAME 'destinationIndicator'
- EQUALITY caseIgnoreMatch
- SUBSTR caseIgnoreSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 )
+ ( 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].
+ 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.
-2.7 distinguishedName
+ 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.
- The distinguishedName attribute type is the attribute supertype from
- which attribute types with DN syntax inherit, instead of containing
- values which name the object itself. The attribute type is
- multi-valued.
+2.7 'distinguishedName'
- 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 'distinguishedName' attribute type is not used as the name of the
+ object itself, but it is instead a base type from which some user
+
+
+
+Sciberras Expires 4 October 2005 [Page 8]
+\f
+INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
+
+
+ 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
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 )
+ ( 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
+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.
+ 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].
-Dally Expires December 2003 [Page 7]
-INTERNET-DRAFT draft-ietf-ldapbis-user-schema-06 June 2003
+ Examples: "20050322123345Z" - timestamps can be used to disambiguate
+ information.
+ "123456A" - serial numbers can be used to disambiguate
+ information.
+2.9 'enhancedSearchGuide'
- ( 2.5.4.46 NAME 'dnQualifier'
- EQUALITY caseIgnoreMatch
- ORDERING caseIgnoreOrderingMatch
- SUBSTR caseIgnoreSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 )
+ 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])
- 1.3.6.1.4.1.1466.115.121.1.44 refers to the Printable String
- syntax [Syntaxes].
-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.
- ( 2.5.4.47 NAME 'enhancedSearchGuide'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.21 )
+Sciberras Expires 4 October 2005 [Page 9]
+\f
+INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
- 1.3.6.1.4.1.1466.115.121.1.21 refers to the Enhanced Guide
- syntax [Syntaxes].
-2.10 facsimileTelephoneNumber
+ ( 2.5.4.47 NAME 'enhancedSearchGuide'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.21 )
+
+ 1.3.6.1.4.1.1466.115.121.1.21 refers to the Enhanced Guide syntax
+ [Syntaxes].
+
+ Examples: "person#(sn$APPROX)#wholeSubtree"
+ "organizationalUnit#(ou$SUBSTR)#oneLevel"
- The facsimileTelephoneNumber attribute type contains telephone
- numbers (and, optionally, the parameters) for facsimile terrminals.
+2.10 'facsimileTelephoneNumber'
+
+ The 'facsimileTelephoneNumber' attribute type contains telephone
+ numbers (and, optionally, the parameters) for facsimile terminals.
Each telephone number is one value of this multi-valued attribute.
+ (Source: X.520 [X.520])
- ( 2.5.4.23 NAME 'facsimileTelephoneNumber'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.22 )
+ ( 2.5.4.23 NAME 'facsimileTelephoneNumber'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.22 )
- 1.3.6.1.4.1.1466.115.121.1.22 refers to the Facsimile Telephone
+ 1.3.6.1.4.1.1466.115.121.1.22 refers to the Facsimile Telephone
Number syntax [Syntaxes].
-2.11 generationQualifier
+ Examples: "+61 3 9896 7801" and "+81 3 347 7418$fineResolution"
- The generationQualifier attribute type contains name strings that
- are the part of a person's name which typically is the suffix, as in
- "IIIrd" or "3rd". Each string is one value of this multi-valued
- attribute.
+2.11 'generationQualifier'
- ( 2.5.4.44 NAME 'generationQualifier'
- SUP name )
+ 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.12 givenName
+ ( 2.5.4.44 NAME 'generationQualifier'
+ SUP name )
- 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.
+ Examples: "III", "3rd" and "Jr.".
- ( 2.5.4.42 NAME 'givenName'
- SUP name )
+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])
+ ( 2.5.4.42 NAME 'givenName'
+ SUP name )
-Dally Expires December 2003 [Page 8]
-INTERNET-DRAFT draft-ietf-ldapbis-user-schema-06 June 2003
+ Examples: "Andrew", "Charles" and "Joanne"
-2.13 houseIdentifier
- The houseIdentifier attribute type contains identifiers for a
- building within a location. Each identifier is one value of this
+
+Sciberras Expires 4 October 2005 [Page 10]
+\f
+INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
+
+
+2.13 'houseIdentifier'
+
+ The 'houseIdentifier' attribute type contains identifiers for a
+ building within a location. Each identifier is one value of this
multi-valued attribute.
+ (Source: X.520 [X.520])
- ( 2.5.4.51 NAME 'houseIdentifier'
- EQUALITY caseIgnoreMatch
- SUBSTR caseIgnoreSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+ ( 2.5.4.51 NAME 'houseIdentifier'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
- 1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String
- syntax [Syntaxes].
+ 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 strings of initials of some or
- all of an individual's names, except the surname(s)
- (e.g., "K. A.", "K"). Each string is one value of this multi-valued
- attribute.
+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 )
- The internationalISDNNumber attribute type contains ISDN addresses,
- as defined in ITU Recommendation E.164 [E.164]. Each address is one
- value of this multi-valued attribute.
+ 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 )
+2.15 'internationalISDNNumber'
- 1.3.6.1.4.1.1466.115.121.1.36 refers to the Numeric String
- syntax [Syntaxes].
+ 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 )
-2.16 l
+ 1.3.6.1.4.1.1466.115.121.1.36 refers to the Numeric String syntax
+ [Syntaxes].
- The l (localityName) attribute type contains names of a locality or
- place, such as a city, county or other geographic region (e.g.,
- "Geneva"). Each name is one value of this multi-valued attribute.
- (Source: X.520)
+ Example: "0198 333 333"
- ( 2.5.4.7 NAME 'l'
- SUP name )
+Sciberras Expires 4 October 2005 [Page 11]
+\f
+INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
+2.16 'l'
-Dally Expires December 2003 [Page 9]
-INTERNET-DRAFT draft-ietf-ldapbis-user-schema-06 June 2003
+ 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])
+ ( 2.5.4.7 NAME 'l'
+ SUP name )
-2.17 member
+ Examples: "Geneva", "Paris" and "Edinburgh".
- 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
+2.17 'member'
+
+ 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 )
- ( 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
+2.18 'name'
- The name attribute type is the attribute supertype from which
- attributes with the name syntax inherit. Such attributes are
- typically used for naming. The attribute type is multi-valued.
+ 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
+ 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 )
+ ( 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].
+ 1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax
+ [Syntaxes].
-2.19 o
- The o (organizationName) attribute type contains the names of an
- organization (e.g., "IETF", "Internet Engineering Task Force").
- Each name is one value of this multi-valued attribute.
- (Source: X.520)
- ( 2.5.4.10 NAME 'o'
- SUP name )
+Sciberras Expires 4 October 2005 [Page 12]
+\f
+INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
-2.20 ou
- The ou (organizationalUnitName) attribute type contains the names of
- an organizational unit (e.g., "Application Area", "LDAPbis WG").
- Each name is one value of this multi-valued attribute.
- (Source: X.520)
+2.19 'o'
- ( 2.5.4.11 NAME 'ou'
- SUP name )
+ 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 )
-Dally Expires December 2003 [Page 10]
-INTERNET-DRAFT draft-ietf-ldapbis-user-schema-06 June 2003
+ Examples: "Finance", "Human Resources" and "Research and
+ Development".
+2.21 'owner'
-2.21 owner
+ 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])
- The owner attribute type contains the Distinguished Names of objects
- that have an ownership responsibility for the object that is owned.
- (e.g., The list object, "cn=All Employees, ou=Mailing List,
- o=Widget, Inc.", is owned by the role object, "cn=ou=Human Resources
- Director, ou=employee, o=Widget, Inc.") Each name is one value of
- this multi-valued attribute.
+ ( 2.5.4.32 NAME 'owner'
+ SUP distinguishedName )
- ( 2.5.4.32 NAME 'owner'
- SUP distinguishedName )
+ Example: The mailing list object, whose DN is "cn=All Employees,
+ ou=Mailing List,o=Widget\, Inc.", is owned by the Human
+ Resources Director.
+ Therefore, the value of the owner attribute within the
+ mailing list object, would be the DN of the director (role):
+ "cn=Human Resources Director,ou=employee,o=Widget\, Inc.".
-2.22 physicalDeliveryOfficeName
+2.22 'physicalDeliveryOfficeName'
- The physicalDeliveryOfficeName attribute type contains names that a
- Postal Service uses to identify a post office (e.g., "Bremerhaven,
- Main", "Bremerhaven, Bonnstrasse").
+ The 'physicalDeliveryOfficeName' attribute type contains names that a
+ Postal Service uses to identify a post office.
+ (Source: X.520 [X.520])
- ( 2.5.4.19 NAME 'physicalDeliveryOfficeName'
- EQUALITY caseIgnoreMatch
- SUBSTR caseIgnoreSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
- 1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String
- syntax [Syntaxes].
-2.23 postalAddress
+Sciberras Expires 4 October 2005 [Page 13]
+\f
+INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
- The postalAddress attribute type contains addresses used by a Postal
- Service to perform services for the object (e.g., "15 Main St.,
- Ottawa, Canada"). Each address is one value of this multi-valued
- attribute.
- ( 2.5.4.16 NAME 'postalAddress'
- EQUALITY caseIgnoreListMatch
- SUBSTR caseIgnoreListSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 )
+ ( 2.5.4.19 NAME 'physicalDeliveryOfficeName'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
- 1.3.6.1.4.1.1466.115.121.1.41 refers to the Postal Address
- syntax [Syntaxes].
+ 1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax
+ [Syntaxes].
-2.24 postalCode
+ Examples: "Bremerhaven, Main" and "Bremerhaven, Bonnstrasse".
- The postalCode attribute type contains codes used by a Postal
- Service to identify a postal service zones, such as the southern
- quadrant of a city (e.g., "22180"). Each code is one value of this
- multi-valued attribute.
+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 )
+ The 'postalAddress' attribute type contains addresses used by a
+ Postal Service to perform services for the object. Each address is
+ one value of this multi-valued attribute.
+ (Source: X.520 [X.520])
+ ( 2.5.4.16 NAME 'postalAddress'
+ EQUALITY caseIgnoreListMatch
+ SUBSTR caseIgnoreListSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 )
-Dally Expires December 2003 [Page 11]
-INTERNET-DRAFT draft-ietf-ldapbis-user-schema-06 June 2003
+ 1.3.6.1.4.1.1466.115.121.1.41 refers to the Postal Address syntax
+ [Syntaxes].
+ Example: "15 Main St.$Ottawa$Canada".
- 1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String
- syntax [Syntaxes].
+2.24 'postalCode'
-2.25 postOfficeBox
+ 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])
- The postOfficeBox attribute type contains numbers that a Postal
- Service uses when a customer arranges to receive mail at a box on
- premises of the Postal Service (e.g., "Box 45"). Each number is one
- value of this multi-valued attribute.
+ ( 2.5.4.17 NAME 'postalCode'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+ 1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax
+ [Syntaxes].
- ( 2.5.4.18 NAME 'postOfficeBox'
- EQUALITY caseIgnoreMatch
- SUBSTR caseIgnoreSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+ Example: "22180", to identify Vienna, VA in the USA.
- 1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String
- syntax [Syntaxes].
+2.25 'postOfficeBox'
-2.26 preferredDeliveryMethod
+ The 'postOfficeBox' attribute type contains postal box identifiers
+ that a Postal Service uses when a customer arranges to receive mail
- The preferredDeliveryMethod attribute type contains an indication of
- the preferred method of getting a message to the object. For example,
- if mhs-delivery is preferred over telephone-delivery, which is
- preferred over all other methods, the value of the value would
- be {1, 9}.
- ( 2.5.4.28 NAME 'preferredDeliveryMethod'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.14
- SINGLE-VALUE )
- 1.3.6.1.4.1.1466.115.121.1.14 refers to the Delivery Method
- syntax [Syntaxes].
+Sciberras Expires 4 October 2005 [Page 14]
+\f
+INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
-2.27 registeredAddress
- The registeredAddress attribute type contains postal addresses
- suitable for reception of telegrams or expedited documents, where it
- is necessary to have the recipient accept delivery (e.g.,
- "Receptionist, Widget Inc., 15 Main St., Ottawa, Canada"). Each
- address is one value of this multi-valued attribute.
+ 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.26 NAME 'registeredAddress'
- SUP postalAddress
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 )
+ ( 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.41 refers to the Postal Address
- syntax [Syntaxes].
+ 1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax
+ [Syntaxes].
+ Example: "Box 45".
+2.26 'preferredDeliveryMethod'
+ The 'preferredDeliveryMethod' attribute type contains an indication
+ of the preferred method of getting a message to the object.
+ (Source: X.520 [X.520])
+ ( 2.5.4.28 NAME 'preferredDeliveryMethod'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.14
+ SINGLE-VALUE )
+ 1.3.6.1.4.1.1466.115.121.1.14 refers to the Delivery Method syntax
+ [Syntaxes].
-Dally Expires December 2003 [Page 12]
-INTERNET-DRAFT draft-ietf-ldapbis-user-schema-06 June 2003
+ Example: If the mhs-delivery Delivery Method is preferred over
+ telephone-delivery, which is preferred over all other
+ methods, the value would be: "mhs $ telephone"
+2.27 'registeredAddress'
-2.28 roleOccupant
+ 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 roleOccupant attribute type contains the Distinguished Names of
- objects(normally people) that fulfill the responsibilities of a role
- object. For 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." Each name is one
- value of this multi-valued attribute.
+ ( 2.5.4.26 NAME 'registeredAddress'
+ SUP postalAddress
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 )
+
+ 1.3.6.1.4.1.1466.115.121.1.41 refers to the Postal Address syntax
+ [Syntaxes].
- ( 2.5.4.33 NAME 'roleOccupant'
- SUP distinguishedName )
+ Example: "Receptionist$Widget, Inc.$15 Main St.$Ottawa$Canada".
-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.
- ( 2.5.4.14 NAME 'searchGuide'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.25 )
+
+Sciberras Expires 4 October 2005 [Page 15]
+\f
+INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
+
+
+2.28 'roleOccupant'
+
+ 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.33 NAME 'roleOccupant'
+ SUP distinguishedName )
+
+ Example: The role object, "cn=Human Resources
+ Director,ou=Position,o=Widget\, Inc.", is fulfilled by two
+ people whose object names are "cn=Mary
+ Smith,ou=employee,o=Widget\, Inc." and "cn=James
+ Brown,ou=employee,o=Widget\, Inc.". The 'roleOccupant'
+ attribute will contain both of these distinguished names,
+ since they are the occupants of this role.
+
+2.29 '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].
-2.30 seeAlso
+ Example: "person#sn$EQ"
- The seeAlso attribute type contains Distinguished Names of objects
- that are related to the subject object. For 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 "cn=Chess Team, ou=sponsored
- activities, o=Widget Inc.". Each name is one value of this
- multi-valued attribute.
+2.30 'seeAlso'
- ( 2.5.4.34 NAME 'seeAlso'
- SUP distinguishedName )
+ 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.
-2.31 serialNumber
+ (Source: X.520 [X.520])
- The serialNumber attribute type contains the serial numbers of
- devices (e.g., "WI-3005". Each number is one value of this
- multi-valued attribute.
+ ( 2.5.4.34 NAME 'seeAlso'
+ SUP distinguishedName )
- ( 2.5.4.5 NAME 'serialNumber'
- EQUALITY caseIgnoreMatch
- SUBSTR caseIgnoreSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 )
+ 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
- 1.3.6.1.4.1.1466.115.121.1.44 refers to the Printable String
- syntax [Syntaxes].
+Sciberras Expires 4 October 2005 [Page 16]
+\f
+INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
-Dally Expires December 2003 [Page 13]
-INTERNET-DRAFT draft-ietf-ldapbis-user-schema-06 June 2003
+ "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.31 'serialNumber'
-2.32 sn
+ 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])
- The sn (surname)attribute type contains name strings for the family
- names of a person (e.g., "Smith"). Each string is one value of this
- multi-valued attribute. (Source: X.520)
+ ( 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.4 NAME 'sn'
- SUP name )
+ 1.3.6.1.4.1.1466.115.121.1.44 refers to the Printable String syntax
+ [Syntaxes].
-2.33 st
+ Examples: "WI-3005" and "XF551426".
- The st (stateOrProvinceName) attribute type contains the full names
- of states or provinces, (e.g. "California"). Each name is one value
- of this multi-valued attribute.
+2.32 'sn'
- ( 2.5.4.8 NAME 'st'
- SUP name )
+ The 'sn' ('surname' in X.500) attribute type contains name strings
+ for the family names of a person. Each string is one value of this
+ multi-valued attribute.
+ (Source: X.520 [X.520])
+
+ ( 2.5.4.4 NAME 'sn'
+ SUP name )
-2.34 street
+ Example: "Smith"
- The street (streetAddress) attribute type contains physical
- addresses of the object to which the entry corresponds, such as an
- address for package delivery. Each address is one value of this
+2.33 'st'
+
+ The 'st' ('stateOrProvinceName' in X.500) attribute type contains the
+ full names of states or provinces. Each name is one value of this
multi-valued attribute.
+ (Source: X.520 [X.520])
+
+ ( 2.5.4.8 NAME 'st'
+ SUP name )
+
+ Example: "California".
+
+
- ( 2.5.4.9 NAME 'street'
- EQUALITY caseIgnoreMatch
- SUBSTR caseIgnoreSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
- 1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String
- syntax [Syntaxes].
-2.35 telephoneNumber
- The telephoneNumber attribute type contains telephone numbers
- complying with ITU Recommendation E.123 [E.123]
- (e.g., 1 234 567 8901) Each number is one value of this
+Sciberras Expires 4 October 2005 [Page 17]
+\f
+INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
+
+
+2.34 'street'
+
+ The 'street' ('streetAddress' in X.500) attribute type contains site
+ information from a postal address (i.e., the street name, place,
+ avenue, and the house number.). Each street is one value of this
multi-valued attribute.
+ (Source: X.520 [X.520])
- ( 2.5.4.20 NAME 'telephoneNumber'
- EQUALITY telephoneNumberMatch
- SUBSTR telephoneNumberSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 )
+ ( 2.5.4.9 NAME 'street'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
- 1.3.6.1.4.1.1466.115.121.1.50 refers to the Telephone Number
- syntax [Syntaxes].
+ 1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax
+ [Syntaxes].
-2.36 teletexTerminalIdentifier
+ Example: "15 Main St."
- The withdrawal of Rec. F.200 has resulted in the withdrawal of this
- attribute.
+2.35 'telephoneNumber'
+ The 'telephoneNumber' attribute type contains telephone numbers that
+ comply with the ITU Recommendation E.123 [E.123]. Each number is one
+ value of this multi-valued attribute.
+ (Source: X.520 [X.520])
-Dally Expires December 2003 [Page 14]
-INTERNET-DRAFT draft-ietf-ldapbis-user-schema-06 June 2003
+ ( 2.5.4.20 NAME 'telephoneNumber'
+ EQUALITY telephoneNumberMatch
+ SUBSTR telephoneNumberSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 )
+ 1.3.6.1.4.1.1466.115.121.1.50 refers to the Telephone Number syntax
+ [Syntaxes].
- ( 2.5.4.22 NAME 'teletexTerminalIdentifier'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.51 )
+ Example: "+1 234 567 8901".
-2.37 telexNumber
+2.36 'teletexTerminalIdentifier'
- 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.
+ The withdrawal of Rec. F.200 has resulted in the withdrawal of this
+ attribute.
+ (Source: X.520 [X.520])
- ( 2.5.4.21 NAME 'telexNumber'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.52 )
+ ( 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.52 refers to the Telex Number
- syntax [Syntaxes].
+ 1.3.6.1.4.1.1466.115.121.1.51 refers to the Teletex Terminal
+ Identifier syntax [Syntaxes].
-2.38 title
- This attribute contains the title, such as "Vice President", of a
- person in their organizational context.
- ( 2.5.4.12 NAME 'title'
- SUP name )
-2.39 uid
- The uid attribute type contains computer system login names
- associated with the object. (Source: RFC 1274,
- RFC 2798). Each name is one value of this multi-valued attribute.
+Sciberras Expires 4 October 2005 [Page 18]
+\f
+INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
- ( 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].
+2.37 'telexNumber'
-2.40 uniqueMember
+ 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])
- The uniqueMember attribute type contains the Distinguished Names of
- an object that is on a list or in a group, where the Relative
- Distinguished Names of the object include a value that distinguishs
- between objects when a distinguished name has been reused. For
- example, if "ou=1st Battalion, o=Defense, c=US" is a battalion that
- was disbanded, establishing a new battalion with the "same" name
- would have a uid value added, resulting in
- "ou=1st Battalion#'010101', o=Defense, c=US".
+ ( 2.5.4.21 NAME 'telexNumber'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.52 )
- ( 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.52 refers to the Telex Number syntax
+ [Syntaxes].
+ Example: "12345$023$ABCDE"
-Dally Expires December 2003 [Page 15]
-INTERNET-DRAFT draft-ietf-ldapbis-user-schema-06 June 2003
+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])
- 1.3.6.1.4.1.1466.115.121.1.34 refers to the Name and Optional UID
- syntax [Syntaxes].
+ ( 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
-2.41 userPassword
- The userPassword attribute type contains character 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.
+Sciberras Expires 4 October 2005 [Page 19]
+\f
+INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
- ( 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
+ 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].
- 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
+ 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.
- 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 say the last and first day of the
- periods, it may be necessary to allow two passwords for the two
+ 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
+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])
- The x121Address attribute type contains data network addresses
- (e.g., 36111222333444555) as defined by ITU Recommendation X.121
- [X.121]. Each address is one value of this multi-valued attribute.
+ ( 2.5.4.24 NAME 'x121Address'
+ EQUALITY numericStringMatch
+ SUBSTR numericStringSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 )
- ( 2.5.4.24 NAME 'x121Address'
- EQUALITY numericStringMatch
- SUBSTR numericStringSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 )
+ 1.3.6.1.4.1.1466.115.121.1.36 refers to the Numeric String syntax
+ [Syntaxes].
- 1.3.6.1.4.1.1466.115.121.1.36 refers to the Numeric String
- syntax [Syntaxes].
+ Example: "36111222333444555".
-2.43 x500UniqueIdentifier
+2.43 'x500UniqueIdentifier'
- The x500UniqueIdentifier attribute type contains binary strings that
- are used to distinguish between objects when a distinguished name
- has been reused. Each string is one value of this multi-valued
+ 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])
+ ( 2.5.4.45 NAME 'x500UniqueIdentifier'
+ EQUALITY bitStringMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 )
-Dally Expires December 2003 [Page 16]
-INTERNET-DRAFT draft-ietf-ldapbis-user-schema-06 June 2003
+ 1.3.6.1.4.1.1466.115.121.1.6 refers to the Bit String syntax
+ [Syntaxes].
- attribute. 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 )
- 1.3.6.1.4.1.1466.115.121.1.6 refers to the Bit String
- syntax [Syntaxes].
+
+
+
+
+
+
+
+
+
+
+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 (see [Models]).
+ 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 ) )
+ ( 2.5.6.2 NAME 'country'
+ SUP top
+ STRUCTURAL
+ MUST c
+ MAY ( searchGuide $
+ description ) )
-3.3 device
+3.3 'dcObject'
- The device object class is the basis of an entry which represents an
- appliance or computer or network element.
+ 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])
- ( 2.5.6.14 NAME 'device'
- SUP top
- STRUCTURAL
- MUST cn
+ ( 1.3.6.1.4.1.1466.344 NAME 'dcObject'
+ SUP top
+ AUXILIARY
+ MUST dc )
-Dally Expires December 2003 [Page 17]
-INTERNET-DRAFT draft-ietf-ldapbis-user-schema-06 June 2003
- MAY ( serialNumber $
- seeAlso $
- owner $
- ou $
- o $
- l $
- description ) )
-3.4 groupOfNames
- The groupOfNames object class is the basis of an entry which
- represents a set of named objects including information related to
+Sciberras Expires 4 October 2005 [Page 22]
+\f
+INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
+
+
+3.4 'device'
+
+ The 'device' object class is the basis of an entry which represents
+ an appliance, computer or network element.
+ (Source: X.521 [X.521])
+
+ ( 2.5.6.14 NAME 'device'
+ SUP top
+ STRUCTURAL
+ MUST cn
+ MAY ( serialNumber $
+ seeAlso $
+ owner $
+ ou $
+ o $
+ l $
+ description ) )
+
+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.5 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.
-
- ( 2.5.6.17 NAME 'groupOfUniqueNames'
- SUP top
- STRUCTURAL
- MUST ( uniqueMember $
- cn )
- MAY ( businessCategory $
- seeAlso $
- owner $
- ou $
- o $
- description ) )
-
-3.6 locality
-
- The locality object class is the basis of an entry which represents
- a place in the physical world.
+ ( 2.5.6.9 NAME 'groupOfNames'
+ SUP top
+ STRUCTURAL
+ MUST ( member $
+ cn )
+ MAY ( businessCategory $
+ seeAlso $
+ owner $
+ ou $
+ o $
+ description ) )
- ( 2.5.6.3 NAME 'locality'
- SUP top
- STRUCTURAL
+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])
-Dally Expires December 2003 [Page 18]
-INTERNET-DRAFT draft-ietf-ldapbis-user-schema-06 June 2003
+ ( 2.5.6.17 NAME 'groupOfUniqueNames'
+ SUP top
+ STRUCTURAL
+ MUST ( uniqueMember $
- MAY ( street $
- seeAlso $
- searchGuide $
- st $
- l $
- description ) )
-3.7 organization
+Sciberras Expires 4 October 2005 [Page 23]
+\f
+INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
- The organization object class is the basis of an entry which
- represents a structured group of people.
- ( 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 ) )
+ cn )
+ MAY ( businessCategory $
+ seeAlso $
+ owner $
+ ou $
+ o $
+ description ) )
-3.8 organizationalPerson
+3.7 'locality'
- The organizationalPerson object class is the basis of an entry which
- represents a person in relation to an organization.
+ 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.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 ) )
+ ( 2.5.6.3 NAME 'locality'
+ SUP top
+ STRUCTURAL
+ MAY ( street $
+ seeAlso $
+ searchGuide $
+ st $
+ l $
+ description ) )
-3.9 organizationalRole
+3.8 'organization'
- The organizationalRole object class is the basis of an entry which
- represents a job or function or position in an 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.8 NAME 'organizationalRole'
- SUP top
- STRUCTURAL
- MUST cn
- MAY ( x121Address $ registeredAddress $ destinationIndicator $
- preferredDeliveryMethod $ telexNumber $
- teletexTerminalIdentifier $ telephoneNumber $
+ ( 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 ) )
-Dally Expires December 2003 [Page 19]
-INTERNET-DRAFT draft-ietf-ldapbis-user-schema-06 June 2003
- internationaliSDNNumber $ facsimileTelephoneNumber $
- seeAlso $ roleOccupant $ preferredDeliveryMethod $
- street $ postOfficeBox $ postalCode $ postalAddress $
- physicalDeliveryOfficeName $ ou $ st $ l $ description ) )
+Sciberras Expires 4 October 2005 [Page 25]
+\f
+INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
-3.10 organizationalUnit
- The organizationalUnit object class is the basis of an entry which
- represents a piece of an organization.
+3.12 'person'
- ( 2.5.6.5 NAME 'organizationalUnit'
- SUP top
- STRUCTURAL
- MUST ou
- MAY ( businessCategory $ description $ destinationIndicator $
- facsimileTelephoneNumber $ internationaliSDNNumber $ l $
- physicalDeliveryOfficeName $ postalAddress $ postalCode $
- postOfficeBox $ preferredDeliveryMethod $
- registeredAddress $ searchGuide $ seeAlso $ st $ street $
- telephoneNumber $ teletexTerminalIdentifier $ telexNumber $
- userPassword $ x121Address ) )
-
-3.11 person
-
- The person object class is the basis of an entry which represents a
+ 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'
+
+ 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.6 NAME 'person'
- SUP top
- STRUCTURAL
- MUST ( sn $
- cn )
- MAY ( userPassword $
- telephoneNumber $
- seeAlso $
- description ) )
+ ( 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.12 residentialPerson
+3.14 'uidObject'
- The residentialPerson object class is the basis of an entry which
- includes a person's residence in the representation of the person.
+ 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])
- ( 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 $
+ ( 1.3.6.1.1.3.1 NAME 'uidObject'
+ SUP top
+ AUXILIARY
+ MUST uid )
-Dally Expires December 2003 [Page 20]
-INTERNET-DRAFT draft-ietf-ldapbis-user-schema-06 June 2003
- 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
- It is requested that the Internet Assigned Numbers Authority (IANA)
- update the LDAP descriptors registry as indicated in the following
+ It is requested that the Internet Assigned Numbers Authority (IANA)
+ update the LDAP descriptors registry as indicated in the following
template:
Subject: Request for LDAP Descriptor Registration Update
Descriptor (short name): see comment
Object Identifier: see comment
Person & email address to contact for further information:
- Kathy Dally <kdally@mitre.org>
+ Andrew Sciberras <andrew.sciberras@eb2bcom.com>
Usage: (A = attribute type, O = Object Class) see comment
- Specification: RFC XXXX [editor's note: The RFC number will be
- the one assigned to this document.
+ 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].
+ 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
------------------------ ---- ----------------------------
businessCategory A 2.5.4.15
c A 2.5.4.6
cn A 2.5.4.3
+ commonName A 2.5.4.3
country O 2.5.6.2
- dc A 0.9.2342.19200300.100.1.25
+ 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
+ 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
-
-
-Dally Expires December 2003 [Page 21]
-INTERNET-DRAFT draft-ietf-ldapbis-user-schema-06 June 2003
-
-
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
sn A 2.5.4.4
st A 2.5.4.8
street A 2.5.4.9
+ surname A 2.5.4.4
telephoneNumber A 2.5.4.20
teletexTerminalIdentifier A 2.5.4.22
telexNumber A 2.5.4.21
title A 2.5.4.12
uid A 0.9.2342.19200300.100.1.1
+ uidObject O 1.3.6.1.1.3.1
uniqueMember A 2.5.4.50
+ userId A 0.9.2342.19200300.100.1.1
userPassword A 2.5.4.35
x121Address A 2.5.4.24
x500UniqueIdentifier A 2.5.4.45
-
5. Security Considerations
- Attributes of directory entries are used to provide descriptive
- information about the real-world objects they represent, which can be
- people, organizations or devices. Most countries have privacy laws
- regarding the publication of information about people.
+ Attributes of directory entries are used to provide descriptive
- Transfer of cleartext passwords is strongly discouraged where the
- underlying transport service cannot guarantee confidentiality and may
- result in disclosure of the password to unauthorized parties.
- Multiple attribute values for the userPassword 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
+Sciberras Expires 4 October 2005 [Page 28]
+\f
+INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
+ information about the real-world objects they represent, which can be
+ people, organizations or devices. Most countries have privacy laws
+ regarding the publication of information about people.
-Dally Expires December 2003 [Page 22]
-INTERNET-DRAFT draft-ietf-ldapbis-user-schema-06 June 2003
-
+ 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.
- implementations are encouraged to provide administrative controls
- which, if enabled, restrict the userPassword attributer to one value.
+ 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.
- Note that when used for authentication purposes [AuthMeth], the user
- need only prove knowledge of one of the values, not all of
- the values.
+ 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.
+ 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 in this document supercedes the
- specification in RFC 2247 by S. Kille, M. Wahl, A. Grimstad,
- R. Huber, and S. Sataluri.
+ 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 supercedes the
- specification of the userid in RFC 1274 by P. Barker and S. Kille
+ 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
- [ISO3166] ISO 3166, "Codes for the representation of names of
- countries".
+ [F.1] Operational Provisions For The International Public
+ Telegram Service Transmission System, CCITT
+ Recommendation F.1, 1992
- [Models] K. Zeilenga, "LDAP: The Models", draft-ietf-ldapbis-
- models-xx (a work in progress)
+ [F.31] Telegram Retransmission System, CCITT Recommendation
+ F.31, 1988
- [RFC1034] P. Mockapetris, " DOMAIN NAMES - CONCEPTS AND
- FACILITIES", RFC 1034, November 1987
+ [ISO3166] ISO 3166, "Codes for the representation of names of
+ countries".
- [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)
+ [RFC1034] P. Mockapetris, " DOMAIN NAMES - CONCEPTS AND
+ FACILITIES", RFC 1034, January 1987
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", RFC 2119, March 1997
+ [RFC2234] Crocker, D., Overell P., "Augmented BNF for Syntax
+ Specifications: ABNF", RFC 2234, November 1997
-Dally Expires December 2003 [Page 23]
-INTERNET-DRAFT draft-ietf-ldapbis-user-schema-06 June 2003
+ [RFC3490] Faltstrom P., Hoffman P., Costello A.,
+ "Internationalizing Domain Names in Applications
+ (IDNA)", RFC 3490, March 2003
+ [Roadmap] Zeilenga, K., "LDAP: Technical Specification Road
+ Map", draft-ietf-ldapbis-roadmap-xx (a work in
+ progress)
- [RFC3490] Faltstrom P., Hoffman P., Costello A. "Internationalizing
- Domain Names in Applications (IDNA)", RFC 3490, March 2003
+ [SASLprep] Zeilenga K., "SASLprep: Stringprep profile for user
+ names and passwords", draft-ietf-sasl-saslprep-xx (a
+ work in progress)
-...[ROADMAP] Zeilenga, K., "LDAP: Technical Specification Road Map",
- draft-ietf-ldapbis-roadmap-xx (a work in progress)
+ [Syntaxes] S. Legg (editor), "LDAP: Syntaxes", draft-ietf-ldapbis-
+ syntaxes-xx (a work in progress)
- [Syntaxes] S. Legg (editor), "LDAP: Syntaxes", draft-ietf-ldapbis-
- syntaxes-xx (a work in progress)
+ [X.121] International numbering plan for public data networks,
- [X.121] International numbering plan for public data networks,
- 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
+Sciberras Expires 4 October 2005 [Page 30]
+\f
+INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
- [X.521] The Directory: Selected Object Classes. ITU-T
- Recommendation X.521, 1993
-7.2 Informative
+ 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
- [AUTHMETH] Harrison R., "LDAP: Authentication Methods and
- Connection Level Security Mechanisms", draft-ietf-
- ldapbis-authmeth-xx (a work in progress)
+ [X.521] The Directory: Selected Object Classes. ITU-T
+ Recommendation X.521, 1993
- [F.1] Operational Provisions For The International Public Telegram
- Service Transmission System, CCITT Recommmendation F.1, 1992
+7.2 Informative
+
+ [AuthMeth] Harrison R., "LDAP: Authentication Methods and
+ Connection Level Security Mechanisms", draft-ietf-
+ ldapbis-authmeth-xx (a work in progress)
- [F.31] Telegram Retransmission System, CCITT Recommendation
- F.31, 1988
+ [LDAP-PKI] Zeilenga, K., "Lightweight Directory Access Protocol
+ (LDAP) schema definitions for X.509 Certificates",
+ draft-zeilenga-ldap-x509-xx (a work in progress)
- [LDAP-PKI] Chadwick, D. W., Legg S., "LDAP Schema and Syntaxes for
- PKIs", draft-ietf-pkix-ldap-pki-schema-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
+ [RFC2247] Kille, S., Wahl, M., Grimstad, A., Huber, R., and
+ Sataluri, S., "Using Domains in LDAP/X.500
+ Distinguished Names", RFC 2247, January 1998
- [RFC3377] Hodges, J., Morgan, R., "Lightweight Directory Access
- Protocol (v3): Technical Specification", RFC 3377,
- September 2002
+ [RFC2377] Grimstad, A., Huber, R., Sataluri, S., and Wahl, M.,
+ "Naming Plan for Internet-Enabled Applications", RFC
+ 2377, September 1998.
- [SASLprep] Zeilenga K., "SASLprep: Stringprep profile for user
- names and passwords", draft-ietf-sasl-saslprep-xx (a
- work in progress)
+ [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
+ [X.500] The Directory, ITU-T Recommendations X.501-X.525, 1993
+8. Author's Address
+ Andrew Sciberras
+ eB2Bcom
+ Suite 3, Woodhouse Corporate Centre,
+ 935 Station Street,
+ Box Hill North, Victoria 3129
+ AUSTRALIA
+ Phone: +61 3 9896 7833
+ Email: andrew.sciberras@eb2bcom.com
-Dally Expires December 2003 [Page 24]
-INTERNET-DRAFT draft-ietf-ldapbis-user-schema-06 June 2003
-8. Author's Address
+Sciberras Expires 4 October 2005 [Page 31]
+\f
+INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
- Kathy Dally
- The MITRE Corp.
- 7515 Colshire Dr., H300
- McLean VA 22102
- USA
-
- Phone: +1 703 883 6058
- Email: kdally@mitre.org
+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.
+Sciberras Expires 4 October 2005 [Page 32]
+\f
+INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
-Dally Expires December 2003 [Page 25]
-INTERNET-DRAFT draft-ietf-ldapbis-user-schema-06 June 2003
+ Appendix A Changes Made Since RFC 2256
- Appendix A Changes 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.
+ This appendix is not a normative part of this specification, which
+ has been provided for informational purposes only.
1. Replaced the document title.
3. Dependencies on RFC 1274 have been eliminated.
- 4. Added a Security Considerations section.
+ 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 explanations to many attribute types and to each object
- class.
+ 6. Added explanation to attribute types and to each object class.
- 7. Removed Section 4, Syntaxes, and Section 6, Matching Rules,
+ 7. Removed Section 4, Syntaxes, and Section 6, Matching Rules,
(moved to [Syntaxes]).
- 8. Removed the certificate-related attribute types:
- authorityRevocationList,
- cACertificate,
- certificateRevocationList,
- crossCertificatePair,
- deltaRevocationList,
- supportedAlgorithms, and
- userCertificate.
-
- Removed the certificate-related Object Classes:
- certificationAuthority,
- certificationAuthority-V2,
- cRLDistributionPoint,
- strongAuthenticationUser, and
- userSecurityInformation
-
- LDAP PKI is now discussed in [LDAP-PKI].
-
- 9. Removed the dmdName, knowledgeInformation,
- presentationAddress, protocolInformation, and
- supportedApplicationContext attribute types and the dmd,
- applicationEntity, and dSA object classes.
-
- 10. Deleted the aliasedObjectName and objectClass attribute
- type definitions. Deleted the alias and top object class
- definitions. They are included in [Models].
-
- 11. Added the 'dc' attribute type from RFC 2247.
-
-
-
-
-Dally Expires December 2003 [Page 26]
-INTERNET-DRAFT draft-ietf-ldapbis-user-schema-06 June 2003
+ 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
- 12. Added an IANA Considerations section.
-
- 13. Numerous edititorial changes.
+ LDAP PKI is now discussed in [LDAP-CRL] and [LDAP-CERT].
+ 9. Removed the dmdName, knowledgeInformation,
+ presentationAddress, protocolInformation, and
+ supportedApplicationContext attribute types and the dmd,
+ applicationEntity, and dSA object classes.
+ 10. Deleted the aliasedObjectName and objectClass attribute type
+ definitions. Deleted the alias and top object class
+ definitions. They are included in [Models].
+ 11. Added the 'dc' attribute type from RFC 2247.
+Sciberras Expires 4 October 2005 [Page 33]
+\f
+INTERNET-DRAFT LDAP: Schema for User Applications April 4, 2005
+ 12. Numerous edititorial changes.
+ 13. Removed upper bound after the SYNTAX oid in all attribute
+ definitions where it appeared.
+ 14. Added text about Unicode, SASLprep and UTF-8 for userPassword.
+ changes since 07:
+ 15. Corrected examples in preferredDeliveryMethod, uniqueMember,
+ postalAddress, and registeredAddress attribute types.
+ 16. Clarified and corrected examples in owner and roleOccupant
+ attribute types.
+ 17. Added RFC 2234 to normative references.
+ 18. Added RFC 1274 and RFC 2798 to informative references.
+ 19. Removed the statement about RFC 2026 conformance.
+ 20. Added the IPR Disclosure and Notice
+ 21. Updated the Copyright text.
+ 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 December 2003 [Page 27]
projects / openldap / blobdiff