draft-ietf-ldapbis-iana-05.txt   draft-ietf-ldapbis-iana-06.txt 
INTERNET-DRAFT Kurt D. Zeilenga INTERNET-DRAFT Kurt D. Zeilenga
Intended Category: BCP OpenLDAP Foundation Intended Category: BCP OpenLDAP Foundation
Expires: 20 June 2002 20 December 2001 Expires in six months 12 May 2002
IANA Considerations for LDAP IANA Considerations for LDAP
<draft-ietf-ldapbis-iana-05.txt> <draft-ietf-ldapbis-iana-06.txt>
Status of Memo Status of Memo
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026. provisions of Section 10 of RFC2026.
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 Best Current Practice revision, submitted to the RFC Editor as a Best Current Practice
document. Distribution of this memo is unlimited. Technical document. Distribution of this memo is unlimited. Technical
discussion of this document will take place on the IETF LDAP Revision discussion of this document will take place on the IETF LDAP Revision
skipping to change at page 1, line 36 skipping to change at page 1, line 36
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as ``work in progress.'' material or to cite them other than as ``work in progress.''
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
<http://www.ietf.org/ietf/1id-abstracts.txt>. The list of <http://www.ietf.org/ietf/1id-abstracts.txt>. The list of
Internet-Draft Shadow Directories can be accessed at Internet-Draft Shadow Directories can be accessed at
<http://www.ietf.org/shadow.html>. <http://www.ietf.org/shadow.html>.
Copyright 2001, The Internet Society. All Rights Reserved. Copyright 2002, The Internet Society. All Rights Reserved.
Please see the Copyright section near the end of this document for Please see the Copyright section near the end of this document for
more information. more information.
Abstract Abstract
This document provides procedures for registering extensible elements This document provides procedures for registering extensible elements
of LDAP (Lightweight Directory Access Protocol). The document also of LDAP (Lightweight Directory Access Protocol). The document also
provides guidelines to IANA (Internet Assigned Numbers Authority) provides guidelines to IANA (Internet Assigned Numbers Authority)
describing conditions under which new values can be assigned. describing conditions under which new values can be assigned.
skipping to change at page 2, line 41 skipping to change at page 2, line 41
2.1. Policy Terminology 2.1. Policy Terminology
The terms "IESG Approval", "Standards Action", "IETF Consensus", The terms "IESG Approval", "Standards Action", "IETF Consensus",
"Specification Required", "First Come First Served", "Expert Review", "Specification Required", "First Come First Served", "Expert Review",
and "Private Use" are used as defined in BCP 26 [RFC2434]. and "Private Use" are used as defined in BCP 26 [RFC2434].
2.2. Requirement Terminology 2.2. Requirement Terminology
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 BCP 14 [RFC2119]. document are to be interpreted as described in BCP 14 [RFC2119]. In
this case, "the specification" as used by BCP 14 refers to the
processing of protocols being submitted to the IETF standards process.
2.3. Common ABNF Productions 2.3. Common ABNF Productions
A number of syntaxes in this document are described using ABNF A number of syntaxes in this document are described using ABNF
[RFC2234]. These syntaxes rely on the following common productions: [RFC2234]. These syntaxes rely on the following common productions:
ALPHA = %x41-5A / %x61-7A ; A-Z / a-z ALPHA = %x41-5A / %x61-7A ; A-Z / a-z
LDIGIT = %x31-39 ; 1-9 LDIGIT = %x31-39 ; 1-9
DIGIT = %x30 / LDIGIT ; 0-9 DIGIT = %x30 / LDIGIT ; 0-9
HYPHEN = %x2D ; "-" HYPHEN = %x2D ; "-"
PERIOD = %x2E ; "." DOT = %x2E ; "."
number = DIGIT / ( LDIGIT 1*DIGIT ) number = DIGIT / ( LDIGIT 1*DIGIT )
keychar = ( ALPHA / DIGIT / HYPHEN ) keychar = ALPHA / DIGIT / HYPHEN
leadkeychar = ALPHA leadkeychar = ALPHA
keystring = leadkeychar *keychar keystring = leadkeychar *keychar
A keyword is UTF-8 [RFC2279] case-insensitive string restricted to the A keyword is a case-insensitive string of UTF-8 [RFC2279] encoded
keystring production. characters from the Universal Character Set (UCS) [ISO10646]
restricted to the <keystring> production.
3. IANA Considerations for LDAP 3. IANA Considerations for LDAP
This section details each kind of protocol value which can be This section details each kind of protocol value which can be
registered and provides IANA guidelines on how to assign new values. registered and provides IANA guidelines on how to assign new values.
3.1. Object Identifiers 3.1. Object Identifiers
Numerous LDAP schema and protocol elements are identified by Object Numerous LDAP schema and protocol elements are identified by Object
Identifiers. Any properly delegated OID MAY be used, including those Identifiers. Specifications which assign OID to elements SHOULD state
under "Internet Private Enterprise Numbers" (1.3.5.1.4.1.x) assigned who delegated the OIDs for its use.
by IANA <http://www.iana.org/cgi-bin/enterprise.pl>.
For IETF developed protocol and schema elements, OIDs under "Internet For IETF developed elements, OIDs under "Internet Directory Numbers"
Directory Numbers" (1.3.6.1.1.x) MAY be used. IANA will assign (1.3.6.1.1.x) SHOULD be used. IANA will assign numbers under this OID
numbers under this OID arc upon Expert Review with Specification arc upon Expert Review with Specification Required. Only one OID per
Required. In general, only one OID per specification SHOULD be specification SHOULD be assigned. The specification MAY then assign
assigned. The specification may then assign any number of OIDs within any number of OIDs within this arc without further coordination with
this arc without further coordination with IANA. IANA.
For elements developed by others, any properly delegated OID can be
used, including those under "Internet Private Enterprise Numbers"
(1.3.6.1.4.1.x) assigned by IANA
<http://www.iana.org/cgi-bin/enterprise.pl>.
To avoid interoperability problems between early implementors of
''works in progress'' and implementors of the published specification
(e.g., the RFC), experimental OIDs SHOULD be used in ''works in
progress''. Experimental OIDs MUST replaced before publication.
OIDs under the Internet Experimental OID arc (1.3.6.1.3.x) may be used
for this purpose.
Practices for IANA assignment of Internet Enterprise and Experimental
OIDs are detailed in STD15 [RFC1157].
3.2. Object Identifier Descriptors 3.2. Object Identifier Descriptors
LDAP allows short descriptive names (or descriptors) to be used LDAP allows short descriptive names (or descriptors) to be used
instead of a numeric Object Identifier to identify protocol extensions instead of a numeric Object Identifier to identify protocol extensions
[RFC2251], schema elements [RFC2252], LDAP URL [RFC2255] extensions, [RFC2251], schema elements [RFC2252], LDAP URL [RFC2255] extensions,
and other objects. Descriptors SHALL be restricted to UTF-8 and other objects. Descriptors SHALL be restricted to strings of
case-insensitive strings limited by the following ABNF: UTF-8 encoded UCS characters restricted by the following ABNF:
name = keystring name = keystring
Descriptors are case-insensitive.
Multiple names MAY be assigned to a given OID. For purposes of Multiple names MAY be assigned to a given OID. For purposes of
registration, an OID SHALL be represented in numeric OID form registration, an OID SHALL be represented in numeric OID form
conforming to the ABNF: conforming to the ABNF:
numericoid = number *( PERIOD number ) ; e.g. 1.1.0.23.40 numericoid = number *( DOT number ) ; e.g. 1.1.0.23.40
While the protocol places no maximum length restriction upon While the protocol places no maximum length restriction upon
descriptors, they SHOULD be short. Descriptors longer than 48 descriptors, they SHOULD be short. Descriptors longer than 48
characters MAY be viewed as too long to register. IANA MAY reject characters MAY be viewed as too long to register. IANA MAY reject
obviously bogus registrations. obviously bogus registrations.
Descriptors beginning with "x-" are for Private Use and SHALL NOT be Descriptors beginning with "x-" are for Private Use and SHALL NOT be
registered. registered.
Descriptors beginning with "e-" are reserved for experiments. IANA Descriptors beginning with "e-" are reserved for experiments. IANA
skipping to change at page 4, line 39 skipping to change at page 5, line 9
IANA SHALL NOT verify the registrant "owns" the OID being named. IANA SHALL NOT verify the registrant "owns" the OID being named.
The OID namespace is managed by The ISO/IEC Joint Technical Committee The OID namespace is managed by The ISO/IEC Joint Technical Committee
1 - Subcommittee 6. 1 - Subcommittee 6.
3.3. AttributeDescription Options 3.3. AttributeDescription Options
An AttributeDescription [RFC2251, Section 4.1.5] can contain zero or An AttributeDescription [RFC2251, Section 4.1.5] can contain zero or
more options specifying additional semantics. An option SHALL be more options specifying additional semantics. An option SHALL be
restricted to UTF-8 case-insensitive string limited by the following restricted to a string UTF-8 encoded UCS characters limited by the
ABNF: following ABNF:
option = keystring option = keystring
Options are case-insensitive.
While the protocol places no maximum length restriction upon option While the protocol places no maximum length restriction upon option
strings, they SHOULD be short. Options longer than 24 characters MAY strings, they SHOULD be short. Options longer than 24 characters MAY
be viewed as too long to register. IANA MAY reject obviously bogus be viewed as too long to register. IANA MAY reject obviously bogus
registrations. registrations.
Values ending with a hyphen ("-") reserve all option names which start Values ending with a hyphen ("-") reserve all option names which start
with the name. For example, the registration of the option with the name. For example, the registration of the option
"optionFamily-" reserves all options which start with "optionFamily-" "optionFamily-" reserves all options which start with "optionFamily-"
for some related purpose. for some related purpose.
skipping to change at page 5, line 38 skipping to change at page 6, line 11
Note: LDAP provides extensible messages which reduces, but does not Note: LDAP provides extensible messages which reduces, but does not
eliminate, the need to add new message types. eliminate, the need to add new message types.
3.5. LDAP Result Codes 3.5. LDAP Result Codes
LDAP result messages carry an resultCode enumerated value to indicate LDAP result messages carry an resultCode enumerated value to indicate
the outcome of the operation [RFC2251, Section 4.1.10]. Each result the outcome of the operation [RFC2251, Section 4.1.10]. Each result
code consists of a keyword and a non-negative integer. code consists of a keyword and a non-negative integer.
IANA SHALL register new resultCode integers in the range 0-255 upon IANA SHALL register new resultCode integers in the range 0-1023 upon
Standards Action, in the range 256-1023 with Expert Review, and in the Standards Action, in the range 1024-4095 with Expert Review with
range 1024-8191 on a First Come First Served basis. Keywords Specification Required, and in the range 4096-16383 on a First Come
associated with integers in the range 0-1023 SHALL NOT start with "e-" First Served basis. Keywords associated with integers in the range
or "x-". Keywords associated with integers in the range 1024-8191 0-4095 SHALL NOT start with "e-" or "x-". Keywords associated with
SHALL start with "e-". Values greater than or equal to 8192 and integers in the range 4096-16383 SHALL start with "e-". Values
keywords starting with "x-" are for Private Use and SHALL NOT be greater than or equal to 16384 and keywords starting with "x-" are for
registered. Private Use and SHALL NOT be registered.
IANA MAY reject obviously bogus registrations. IANA MAY reject obviously bogus registrations.
3.6. LDAP Authentication Method 3.6. LDAP Authentication Method
The LDAP Bind operation supports multiple authentication methods The LDAP Bind operation supports multiple authentication methods
[RFC2251, Section 4.2]. Each authentication choice consists of a [RFC2251, Section 4.2]. Each authentication choice consists of a
keyword and a non-negative integer. keyword and a non-negative integer.
Authentication methods usage SHALL be classified using one of the Authentication methods usage SHALL be classified using one of the
skipping to change at page 6, line 24 skipping to change at page 6, line 41
COMMON - method is appropriate for common use on the Internet, COMMON - method is appropriate for common use on the Internet,
LIMITED USE - method is appropriate for limited use, LIMITED USE - method is appropriate for limited use,
OBSOLETE - method has been deprecated or otherwise found to be OBSOLETE - method has been deprecated or otherwise found to be
inappropriate for any use. inappropriate for any use.
IANA SHALL NOT register new OBSOLETE authentication methods. Methods IANA SHALL NOT register new OBSOLETE authentication methods. Methods
without publicly available specifications SHALL NOT be classified as without publicly available specifications SHALL NOT be classified as
COMMON. IANA MAY reject obviously bogus registrations. COMMON. IANA MAY reject obviously bogus registrations.
IANA SHALL register new authentication method integers in the range IANA SHALL register new authentication method integers in the range
0-255 upon Standards Action, in the range 256-1023 with Expert Review 0-1023 upon Standards Action, in the range 1024-4095 with Expert
with Specification Required, and in the range 1024-8191 on a First Review with Specification Required, and in the range 4096-16383 on a
Come First Served basis. Keywords associated with integers in the First Come First Served basis. Keywords associated with integers in
range 0-1023 SHALL NOT start with "e-" or "x-". Keywords associated the range 0-4095 SHALL NOT start with "e-" or "x-". Keywords
with integers in the range 1024-8191 SHALL start with "e-". Values associated with integers in the range 4096-16383 SHALL start with
greater than or equal to 8192 and keywords starting with "x-" are for "e-". Values greater than or equal to 16384 and keywords starting
Private Use and SHALL NOT be registered. with "x-" are for Private Use and SHALL NOT be registered.
Note: LDAP supports SASL [RFC2222] as an Authentication CHOICE. SASL Note: LDAP supports SASL [RFC2222] as an Authentication CHOICE. SASL
is an extensible LDAP authentication method. is an extensible LDAP authentication method.
3.7. Directory Systems Names 3.7. Directory Systems Names
The IANA-maintained "Directory Systems Names" registry [IANADSN] of The IANA-maintained "Directory Systems Names" registry [IANADSN] of
valid keywords for well known attributes used in the LDAPv2 string valid keywords for well known attributes used in the LDAPv2 string
representation of a distinguished name [RFC1779]. RFC 1779 was representation of a distinguished name [RFC1779]. RFC 1779 was
obsoleted by RFC 2253. obsoleted by RFC 2253.
skipping to change at page 9, line 4 skipping to change at page 9, line 20
Alvestrand. Alvestrand.
8. Author's Address 8. Author's Address
Kurt D. Zeilenga Kurt D. Zeilenga
OpenLDAP Foundation OpenLDAP Foundation
Email: Kurt@OpenLDAP.org Email: Kurt@OpenLDAP.org
9. Normative References 9. Normative References
[RFC1157] J. Case, M. Fedor, M. Schoffstall, J. Davin, "A Simple
Network Management Protocol (SNMP)", STD 15 (also RFC
1157), May 1990.
[RFC2026] S. Bradner, "The Internet Standards Process -- Revision 3", [RFC2026] S. Bradner, "The Internet Standards Process -- Revision 3",
BCP 9 (also RFC 2026), October 1996. BCP 9 (also RFC 2026), October 1996.
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14 (also RFC 2119), March 1997. Requirement Levels", BCP 14 (also RFC 2119), March 1997.
[RFC2234] D. Crocker, P. Overell, "Augmented BNF for Syntax [RFC2234] D. Crocker, P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997. Specifications: ABNF", RFC 2234, November 1997.
[RFC2251] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access [RFC2251] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access
Protocol (v3)", RFC 2251, December 1997. Protocol (v3)", RFC 2251, December 1997.
[RFC2252] M. Wahl, A. Coulbeck, T. Howes, S. Kille, "Lightweight [RFC2252] M. Wahl, A. Coulbeck, T. Howes, S. Kille, "Lightweight
Directory Access Protocol (v3): Attribute Syntax Directory Access Protocol (v3): Attribute Syntax
Definitions", RFC 2252, December 1997. Definitions", RFC 2252, December 1997.
[RFC2255] T. Howes, M. Smith, "The LDAP URL Format", RFC 2255, [RFC2255] T. Howes, M. Smith, "The LDAP URL Format", RFC 2255,
December, 1997. December, 1997.
[RFC2256] Wahl, M., "A Summary of the X.500(96) User Schema for use [RFC2256] M. Wahl, "A Summary of the X.500(96) User Schema for use
with LDAPv3", RFC 2256, December 1997. with LDAPv3", RFC 2256, December 1997.
[RFC2279] F. Yergeau, "UTF-8, a transformation format of ISO 10646", [RFC2279] F. Yergeau, "UTF-8, a transformation format of ISO 10646",
RFC 2279, January 1998. RFC 2279, January 1998.
[RFC2434] T. Narten, H. Alvestrand, "Guidelines for Writing an IANA [RFC2434] T. Narten, H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26 (also RFC 2434), Considerations Section in RFCs", BCP 26 (also RFC 2434),
October 1998. October 1998.
[LDAPTS] J. Hodges, R.L. Morgan, "Lightweight Directory Access [LDAPTS] J. Hodges, R.L. Morgan, "Lightweight Directory Access
Protocol (v3): Technical Specification", Protocol (v3): Technical Specification",
draft-ietf-ldapbis-ldapv3-ts-00.txt (a work in progress). draft-ietf-ldapbis-ldapv3-ts-xx.txt (a work in progress).
[IANADSN] IANA, "Directory Systems Names",
http://www.iana.org/assignments/directory-system-names.
[ISO10646] Universal Multiple-Octet Coded Character Set (UCS) -
Architecture and Basic Multilingual Plane, ISO/IEC 10646-1
: 1993.
10. Informative References 10. Informative References
[RFC2222] J. Myers, "Simple Authentication and Security Layer (SASL)", [RFC1779] S. Kille, "A String Representation of Distinguished Names",
RFC 2222, October 1997. RFC 1779, March 1995.
[RFC2222] J. Myers, "Simple Authentication and Security Layer
(SASL)", RFC 2222, October 1997.
Appendix A. Registration Templates Appendix A. Registration Templates
This appendix provides registration templates for registering new LDAP This appendix provides registration templates for registering new LDAP
values. values.
A.1. LDAP Object Identifier Registration Template A.1. LDAP Object Identifier Registration Template
Subject: Request for LDAP OID Registration Subject: Request for LDAP OID Registration
Person & email address to contact for further information: Person & email address to contact for further information:
Specification: (I-D) Specification: (I-D)
Author/Change Controller: Author/Change Controller:
Comments: Comments:
(Any comments that the requester deems relevant to the request) (Any comments that the requester deems relevant to the request)
skipping to change at page 12, line 16 skipping to change at page 12, line 48
(Any comments that the requester deems relevant to the request) (Any comments that the requester deems relevant to the request)
Appendix B. Assigned Values Appendix B. Assigned Values
The following values are currently assigned. The following values are currently assigned.
B.1. Object Identifiers B.1. Object Identifiers
Currently registered "Internet Private Enterprise Numbers" can be Currently registered "Internet Private Enterprise Numbers" can be
found at: found at <http://www.iana.org/assignments/enterprise-numbers>.
http://www.isi.edu/in-notes/iana/assignments/enterprise-numbers
Currently registered "Internet Directory Numbers" can be found at: Currently registered "Internet Directory Numbers" can be found at
http://www.iana.org/assignments/smi-numbers <http://www.iana.org/assignments/smi-numbers>.
B.2. Object Identifier Descriptors B.2. Object Identifier Descriptors
NAME Type OID [REF] NAME Type OID [REF]
------------------------ ---- ----------------- ------------------------ ---- -----------------
account O 0.9.2342.19200300.100.4.5 [RFC1274] account O 0.9.2342.19200300.100.4.5 [RFC1274]
alias O 2.5.6.1 [RFC2256] alias O 2.5.6.1 [RFC2256]
aliasedEntryName A 2.5.4.1 [X.501] aliasedEntryName A 2.5.4.1 [X.501]
aliasedObjectName A 2.5.4.1 [RFC2256] aliasedObjectName A 2.5.4.1 [RFC2256]
altServer A 1.3.6.1.4.1.1466.101.120.6 [RFC2252] altServer A 1.3.6.1.4.1.1466.101.120.6 [RFC2252]
skipping to change at page 19, line 40 skipping to change at page 20, line 24
Method Value Owner Usage Reference Method Value Owner Usage Reference
------ ----- ----- ----------- ----------------- ------ ----- ----- ----------- -----------------
simple 0 IESG LIMITED USE [RFC2251,RFC2829] simple 0 IESG LIMITED USE [RFC2251,RFC2829]
krbv42LDAP 1 IESG OBSOLETE* [RFC1777] krbv42LDAP 1 IESG OBSOLETE* [RFC1777]
krbv42DSA 2 IESG OBSOLETE* [RFC1777] krbv42DSA 2 IESG OBSOLETE* [RFC1777]
sasl 3 IESG COMMON [RFC2251,RFC2829] sasl 3 IESG COMMON [RFC2251,RFC2829]
* These LDAPv2-only mechanisms were deprecated in favor LDAPv3 SASL * These LDAPv2-only mechanisms were deprecated in favor LDAPv3 SASL
authentication method, specifically the GSSAPI mechanism. authentication method, specifically the GSSAPI mechanism.
Copyright 2001, The Internet Society. All Rights Reserved. Copyright 2002, The Internet Society. All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published and or assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind, distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
 End of changes. 

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