draft-ietf-ldapbis-user-schema-10.txt   draft-ietf-ldapbis-user-schema-11.txt 
INTERNET-DRAFT Editor: A. Sciberras INTERNET-DRAFT Editor: A. Sciberras
Intended Category: Standard Track eB2Bcom Intended Category: Standard Track eB2Bcom
Updates: RFC 2247, RFC 2798, RFC 2377 July 11, 2005 Updates: RFC 2247, RFC 2798, RFC 2377 January 30, 2006
Obsoletes: RFC 2256 Obsoletes: RFC 2256
LDAP: Schema for User Applications LDAP: Schema for User Applications
draft-ietf-ldapbis-user-schema-10.txt draft-ietf-ldapbis-user-schema-11.txt
Copyright (C) The Internet Society (2005). All Rights Reserved. Copyright (C) The Internet Society (2006). All Rights Reserved.
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
By submitting this Internet-Draft, I accept the provisions of Section By submitting this Internet-Draft, I accept the provisions of Section
3 of BCP 78. 3 of BCP 78.
skipping to change at page 1, line 47 skipping to change at page 1, line 47
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This document is intended to be, after appropriate review and This document is intended to be, after appropriate review and
revision, submitted to the RFC Editor as a Standard Track document. revision, submitted to the RFC Editor as a Standard Track document.
Distribution of this document is unlimited. Technical discussion of Distribution of this document is unlimited. Technical discussion of
this document should take place on the IETF LDAP Revision Working this document should take place on the IETF LDAP Revision Working
Group (LDAPbis) mailing list <ietf-ldapbis@openldap.org>. Please Group (LDAPbis) mailing list <ietf-ldapbis@openldap.org>. Please
send editorial comments directly to the editor send editorial comments directly to the editor
<andrew.sciberras@eb2bcom.com>. <andrew.sciberras@eb2bcom.com>.
This Internet-Draft expires on 11 January 2006. This Internet-Draft expires on 30 July 2006.
Abstract Abstract
This document is an integral part of the Lightweight Directory Access This document is an integral part of the Lightweight Directory Access
Protocol (LDAP) technical specification [Roadmap]. It provides a Protocol (LDAP) technical specification [Roadmap]. It provides a
technical specification of attribute types and object classes technical specification of attribute types and object classes
intended for use by LDAP directory clients for many directory intended for use by LDAP directory clients for many directory
services, such as, White Pages. These objects are widely used as a services, such as, White Pages. These objects are widely used as a
basis for the schema in many LDAP directories. This document does basis for the schema in many LDAP directories. This document does
not cover attributes used for the administration of directory not cover attributes used for the administration of directory
skipping to change at page 6, line 4 skipping to change at page 6, line 4
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 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
1.3 General Issues 1.3 General Issues
This document references Syntaxes defined in Section 3 of [Syntaxes] This document references Syntaxes defined in Section 3 of [Syntaxes]
and Matching Rules defined in Section 4 of [Syntaxes]. and Matching Rules defined in Section 4 of [Syntaxes].
The definitions of Attribute Types and Object Classes are written The definitions of Attribute Types and Object Classes are written
using the Augmented Backus-Naur Form (ABNF) [RFC2234] of using the Augmented Backus-Naur Form (ABNF) [RFC4234] of
AttributeTypeDescription and ObjectClassDescription given in AttributeTypeDescription and ObjectClassDescription given in
[Models]. Lines have been folded for readability. When such values [Models]. Lines have been folded for readability. When such values
are transferred as attribute values in the LDAP Protocol the values are transferred as attribute values in the LDAP Protocol the values
will not contain line breaks. will not contain line breaks.
2. Attribute Types 2. Attribute Types
The Attribute Types contained in this section hold user information. The Attribute Types contained in this section hold user information.
There is no requirement that servers implement the 'searchGuide' and There is no requirement that servers implement the 'searchGuide' and
skipping to change at page 7, line 23 skipping to change at page 7, line 23
(Source: X.520 [X.520]) (Source: X.520 [X.520])
( 2.5.4.3 NAME 'cn' ( 2.5.4.3 NAME 'cn'
SUP name ) SUP name )
Examples: "Martin K Smith", "Marty Smith" and "printer12". Examples: "Martin K Smith", "Marty Smith" and "printer12".
2.4 'dc' 2.4 'dc'
The 'dc' ('domainComponent' in RFC 2247) attribute type is a string The 'dc' ('domainComponent' in RFC 2247) attribute type is a string
holding one component, a <label> [RFC1034], of a DNS domain name. holding one component, a label, of a DNS domain name [RFC1034]. The
The encoding of IA5String for use in LDAP is simply the characters of encoding of IA5String for use in LDAP is simply the characters of the
the string itself. The equality matching rule is case insensitive, ASCII label. The equality matching rule is case insensitive, as is
as is today's DNS. today's DNS.
(Source: RFC 2247 [RFC2247]) (Source: RFC 2247 [RFC2247])
( 0.9.2342.19200300.100.1.25 NAME 'dc' ( 0.9.2342.19200300.100.1.25 NAME 'dc'
EQUALITY caseIgnoreIA5Match EQUALITY caseIgnoreIA5Match
SUBSTR caseIgnoreIA5SubstringsMatch SUBSTR caseIgnoreIA5SubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
SINGLE-VALUE ) SINGLE-VALUE )
1.3.6.1.4.1.1466.115.121.1.26 refers to the IA5 String syntax 1.3.6.1.4.1.1466.115.121.1.26 refers to the IA5 String syntax
[Syntaxes]. [Syntaxes].
Examples: Valid values include "example" and "com". The value Examples: Valid values include "example" and "com". The value
"example.com" is invalid, because it contains two <label> "example.com" is invalid, because it contains two label
components. components.
It is noted that the directory will not ensure that values of this Directory applications supporting International Domain Names SHALL
attribute conform to the label production [RFC1034]. It is the use the ToASCII method [RFC3490] to produce the domain name component
application's responsibility to ensure domains it stores in this label. The special considerations discussed in section 4 of RFC 3490
attribute are appropriately represented. [RFC3490] should be taken, depending on whether the domain component
is used for "stored" or "query" purposes.
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' 2.5 'description'
The 'description' attribute type contains human-readable descriptive The 'description' attribute type contains human-readable descriptive
phrases about the object. Each description is one value of this phrases about the object. Each description is one value of this
multi-valued attribute. multi-valued attribute.
(Source: X.520 [X.520]) (Source: X.520 [X.520])
( 2.5.4.13 NAME 'description' ( 2.5.4.13 NAME 'description'
EQUALITY caseIgnoreMatch EQUALITY caseIgnoreMatch
skipping to change at page 29, line 7 skipping to change at page 29, line 7
x500UniqueIdentifier A 2.5.4.45 x500UniqueIdentifier A 2.5.4.45
5. Security Considerations 5. Security Considerations
Attributes of directory entries are used to provide descriptive Attributes of directory entries are used to provide descriptive
information about the real-world objects they represent, which can be information about the real-world objects they represent, which can be
people, organizations or devices. Most countries have privacy laws people, organizations or devices. Most countries have privacy laws
regarding the publication of information about people. regarding the publication of information about people.
Transfer of cleartext passwords is strongly discouraged where the Transfer of cleartext passwords is strongly discouraged where the
underlying transport service cannot guarantee confidentiality and may underlying transport service cannot guarantee confidentiality and
result in disclosure of the password to unauthorized parties. integrity, since this may result in disclosure of the password to
unauthorized parties.
Multiple attribute values for the 'userPassword' attribute need to be Multiple attribute values for the 'userPassword' attribute need to be
used with care. Especially reset/deletion of a password by an admin used with care. Especially reset/deletion of a password by an admin
without knowing the old user password gets tricky or impossible if without knowing the old user password gets tricky or impossible if
multiple values for different applications are present. multiple values for different applications are present.
Certainly, applications which intend to replace the 'userPassword' Certainly, applications which intend to replace the 'userPassword'
value(s) with new value(s) should use modify/replaceValues (or value(s) with new value(s) should use modify/replaceValues (or
modify/deleteAttribute+addAttribute). Additionally, server modify/deleteAttribute+addAttribute). Additionally, server
implementations are encouraged to provide administrative controls implementations are encouraged to provide administrative controls
skipping to change at page 30, line 34 skipping to change at page 30, line 34
[Models] K. Zeilenga, "LDAP: The Models", draft-ietf-ldapbis- [Models] K. Zeilenga, "LDAP: The Models", draft-ietf-ldapbis-
models-xx (a work in progress) models-xx (a work in progress)
[RFC1034] P. Mockapetris, " DOMAIN NAMES - CONCEPTS AND [RFC1034] P. Mockapetris, " DOMAIN NAMES - CONCEPTS AND
FACILITIES", RFC 1034, January 1987 FACILITIES", RFC 1034, January 1987
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997 Requirement Levels", RFC 2119, March 1997
[RFC2234] Crocker, D., Overell P., "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997
[RFC3490] Faltstrom P., Hoffman P., Costello A., [RFC3490] Faltstrom P., Hoffman P., Costello A.,
"Internationalizing Domain Names in Applications "Internationalizing Domain Names in Applications
(IDNA)", RFC 3490, March 2003 (IDNA)", RFC 3490, March 2003
[RFC4013] Zeilenga K., "SASLprep: Stringprep profile for User [RFC4013] Zeilenga K., "SASLprep: Stringprep profile for User
Names and Passwords", RFC 4013, February 2005. Names and Passwords", RFC 4013, February 2005.
[RFC4234] Crocker, D., Overell P., "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005
[Roadmap] Zeilenga, K., "LDAP: Technical Specification Road [Roadmap] Zeilenga, K., "LDAP: Technical Specification Road
Map", draft-ietf-ldapbis-roadmap-xx (a work in Map", draft-ietf-ldapbis-roadmap-xx (a work in
progress) progress)
[Syntaxes] S. Legg (editor), "LDAP: Syntaxes", draft-ietf-ldapbis- [Syntaxes] S. Legg (editor), "LDAP: Syntaxes", draft-ietf-ldapbis-
syntaxes-xx (a work in progress) 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 ITU-T Recommendation X.121, 1996
[X.509] The Directory: Authentication Framework, ITU-T [X.509] The Directory: Authentication Framework, ITU-T
skipping to change at page 31, line 37 skipping to change at page 31, line 37
Sataluri, S., "Using Domains in LDAP/X.500 Sataluri, S., "Using Domains in LDAP/X.500
Distinguished Names", RFC 2247, January 1998 Distinguished Names", RFC 2247, January 1998
[RFC2377] Grimstad, A., Huber, R., Sataluri, S., and Wahl, M., [RFC2377] Grimstad, A., Huber, R., Sataluri, S., and Wahl, M.,
"Naming Plan for Internet-Enabled Applications", RFC "Naming Plan for Internet-Enabled Applications", RFC
2377, September 1998. 2377, September 1998.
[RFC2798] Smith, M., "Definition of the inetOrgPerson LDAP Object [RFC2798] Smith, M., "Definition of the inetOrgPerson LDAP Object
Class", RFC 2798, April 2000 Class", RFC 2798, April 2000
[X.500] ITU-T Recommendations X.5000 (1993) | ISO/IEC [X.500] ITU-T Recommendations X.500 (1993) | ISO/IEC
9594-1:1994, Information Technology - Open Systems 9594-1:1994, Information Technology - Open Systems
Interconnection - The Directory: Overview of concepts, Interconnection - The Directory: Overview of concepts,
models and services. models and services.
8. Author's Address 8. Author's Address
Andrew Sciberras Andrew Sciberras
eB2Bcom eB2Bcom
Suite 3, Woodhouse Corporate Centre, Suite 3, Woodhouse Corporate Centre,
935 Station Street, 935 Station Street,
skipping to change at page 32, line 32 skipping to change at page 32, line 32
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
10. Full Copyright Statement 10. Full Copyright Statement
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
 End of changes. 13 change blocks. 
28 lines changed or deleted 23 lines changed or added

This html diff was produced by rfcdiff 1.28, available from http://www.levkowetz.com/ietf/tools/rfcdiff/