draft-ietf-ldapbis-iana-04.txt   draft-ietf-ldapbis-iana-05.txt 
INTERNET-DRAFT Kurt D. Zeilenga INTERNET-DRAFT Kurt D. Zeilenga
Intended Category: BCP OpenLDAP Foundation Intended Category: BCP OpenLDAP Foundation
Expires: 20 May 2002 20 November 2001 Expires: 20 June 2002 20 December 2001
IANA Considerations for LDAP IANA Considerations for LDAP
<draft-ietf-ldapbis-iana-04.txt> <draft-ietf-ldapbis-iana-05.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 44 skipping to change at page 1, line 44
<http://www.ietf.org/shadow.html>. <http://www.ietf.org/shadow.html>.
Copyright 2001, The Internet Society. All Rights Reserved. Copyright 2001, 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. The document also provides guidelines to IANA describing of LDAP (Lightweight Directory Access Protocol). The document also
conditions under which new values can be assigned. provides guidelines to IANA (Internet Assigned Numbers Authority)
describing conditions under which new values can be assigned.
1. Introduction 1. Introduction
The Lightweight Directory Access Protocol [LDAPTS] (LDAP) is an The Lightweight Directory Access Protocol [LDAPTS] (LDAP) is an
extensible protocol. LDAP supports: extensible protocol. LDAP supports:
- addition of new operations, - addition of new operations,
- extension of existing operations, and - extension of existing operations, and
- extensible schema. - extensible schema.
This document details procedures for registering values of used to This document details procedures for registering values of used to
skipping to change at page 4, line 15 skipping to change at page 4, line 16
name = keystring name = keystring
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 *( PERIOD 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. IANA MAY refuse to register any descriptors, they SHOULD be short. Descriptors longer than 48
descriptor over 48 characters in length. IANA MAY reject obviously characters MAY be viewed as too long to register. IANA MAY reject
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
SHALL register any descriptor beginning with "e-" on a First Come SHALL register any descriptor beginning with "e-" on a First Come
First Served basis. First Served basis.
Expert Review is REQUIRED before accepting registration of all other Expert Review is REQUIRED before accepting registration of all other
descriptors. descriptors.
skipping to change at page 4, line 44 skipping to change at page 4, line 45
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 UTF-8 case-insensitive string limited by the following
ABNF: ABNF:
option = keystring option = keystring
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. IANA MAY refuse to register any option strings, they SHOULD be short. Options longer than 24 characters MAY
over 16 characters in length. 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.
Options beginning with "x-" are for Private Use and SHALL NOT Options beginning with "x-" are for Private Use and SHALL NOT
registered. registered.
skipping to change at page 5, line 41 skipping to change at page 5, line 42
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-255 upon
Standards Action, in the range 256-1023 with Expert Review, and in the Standards Action, in the range 256-1023 with Expert Review, and in the
range 1024-8191 on a First Come First Served basis. Keywords range 1024-8191 on a First Come First Served basis. Keywords
associated with integers in the range 0-1023 SHALL NOT start with "e-" associated with integers in the range 0-1023 SHALL NOT start with "e-"
or "x- the range 1024-8191 SHALL start with "e-". Values greater than or "x-". Keywords associated with integers in the range 1024-8191
or equal to 8192 and keywords starting with "x-" are for Private Use SHALL start with "e-". Values greater than or equal to 8192 and
and SHALL NOT be registered. keywords starting with "x-" are for 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
following terms: following terms:
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
skipping to change at page 6, line 44 skipping to change at page 6, line 47
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.
Directory systems names are not known to be used in any other context. Directory systems names are not known to be used in any other context.
LDAPv3 uses Object Identifier Descriptors [Section 3.2] (which have a LDAPv3 uses Object Identifier Descriptors [Section 3.2] (which have a
different syntax than directory system names). different syntax than directory system names).
IANA SHALL NOT register new Directory System Names. For historical IANA SHALL NOT register new Directory System Names. For historical
purposes, the current list of registered names SHOULD be remain purposes, the current list of registered names SHOULD remain
available. available.
4. Registration Procedure 4. Registration Procedure
The procedure given here MUST be used by anyone who wishes to use a The procedure given here MUST be used by anyone who wishes to use a
new value of a type described in Section 3 of this document. new value of a type described in Section 3 of this document.
The first step is for the requester to fill out the appropriate form. The first step is for the requester to fill out the appropriate form.
Templates are provided in Appendix A. Templates are provided in Appendix A.
If the policy is Standards Action, the completed form SHOULD be If the policy is Standards Action, the completed form SHOULD be
provided to the IESG with the request for Standards Action. Upon provided to the IESG with the request for Standards Action. Upon
approval of the Standards Action, the IESG SHALL forward the request approval of the Standards Action, the IESG SHALL forward the request
(possibly revised) to IANA. The IESG SHALL be viewed as the owner of (possibly revised) to IANA. The IESG SHALL be viewed as the owner of
skipping to change at page 7, line 25 skipping to change at page 7, line 27
form to the <directory@apps.ietf.org> mailing list for public review. form to the <directory@apps.ietf.org> mailing list for public review.
The review period is two (2) weeks. If a revised form is later The review period is two (2) weeks. If a revised form is later
submitted, the review period is restarted. Anyone may subscribe to submitted, the review period is restarted. Anyone may subscribe to
this list by sending a request to <directory-request@apps.ietf.org>. this list by sending a request to <directory-request@apps.ietf.org>.
During the review, objections may be raised by anyone (including the During the review, objections may be raised by anyone (including the
Expert) on the list. After completion of the review, the Expert, Expert) on the list. After completion of the review, the Expert,
based upon public comments, SHALL either approve the request and based upon public comments, SHALL either approve the request and
forward it to the IESG OR deny the request. In either case, the forward it to the IESG OR deny the request. In either case, the
Expert SHALL promptly notify the requester of the action . Actions of Expert SHALL promptly notify the requester of the action . Actions of
the Expert may be appealed [RFC2026]. The Expert is appointed by the Expert may be appealed [RFC2026]. The Expert is appointed by
Applications Area Director(s). The requester is viewed is the owner Applications Area Director(s). The requester is viewed as the owner
of values registered under Expert Review. of values registered under Expert Review.
If the policy is First Come First Served, the requester SHALL submit If the policy is First Come First Served, the requester SHALL submit
the completed form directly to the IANA <iana@iana.org>. The the completed form directly to the IANA <iana@iana.org>. The
requester is viewed is the owner of values registered under First Come requester is viewed as the owner of values registered under First Come
First Served. First Served.
Neither the Expert nor IANA will take position on the claims of Neither the Expert nor IANA will take position on the claims of
copyright or trademarks issues regarding completed forms. copyright or trademarks issues regarding completed forms.
5. Registration Maintenance 5. Registration Maintenance
This section discusses maintenance of registrations. This section discusses maintenance of registrations.
5.1. Lists of Registered Values 5.1. Lists of Registered Values
IANA makes lists of registered values readily available to the IANA makes lists of registered values readily available to the
Internet community on their web site <http://www.iana.org/>. Internet community on their web site <http://www.iana.org/>.
5.2. Change Control 5.2. Change Control
The registration owner MAY update the registration subject to the same
The registration owner MAY update the specification subject to the constraints and review as with new registrations. In cases where the
same constraints and review as with new registrations. The IESG MAY owner is not unable or unwilling to make necessary updates, the IESG
assert ownership in cases where the owner is not willing or able to MAY assert ownership in order to update the registration.
make necessary updates.
5.3. Comments 5.3. Comments
For cases where others have significant objections to the claims in a For cases where others (anyone other than the owner) have significant
registration and the author does not agree to change the registration, objections to the claims in a registration and the owner does not
comments MAY be attached to registrations after Expert Review. For agree to change the registration, comments MAY be attached to a
registrations owned by the IESG, the objections SHOULD be addressed by registration upon Expert Review. For registrations owned by the IESG,
initiating a Change Control request. the objections SHOULD be addressed by initiating a request for Expert
Review.
The request form to these requests is ad hoc, but MUST include the
specific objections to be reviewed and SHOULD contain (directly or by
reference) materials supporting the objections.
6. Security Considerations 6. Security Considerations
The security considerations detailed in [RFC2434] are generally The security considerations detailed in [RFC2434] are generally
applicable to this document. Additional security considerations applicable to this document. Additional security considerations
specific to each namespace are discussed in Section 3 where specific to each namespace are discussed in Section 3 where
appropriate. appropriate.
Security considerations for LDAP are discussed in documents comprising Security considerations for LDAP are discussed in documents comprising
the technical specification [LDAPTS]. the technical specification [LDAPTS].
skipping to change at page 9, line 27 skipping to change at page 9, line 34
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", draft-ietf-ldapbis- Protocol (v3): Technical Specification",
ldapv3-ts-00.txt (a work in progress). draft-ietf-ldapbis-ldapv3-ts-00.txt (a work in progress).
10. Informative References 10. Informative References
[RFC2222] J. Myers, "Simple Authentication and Security Layer (SASL)", [RFC2222] J. Myers, "Simple Authentication and Security Layer (SASL)",
RFC 2222, October 1997. 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.
skipping to change at page 12, line 12 skipping to change at page 12, line 16
(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: http://www.isi.edu/in-notes/iana/assignments/enterprise- found at:
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]
 End of changes. 

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