WDIFF

draft-ietf-ldapbis-bcp64-07.txt --> rfc4520.txt

INTERNET-DRAFT Kurt D.

Network Working Group K. Zeilenga
Intended Category: BCP
Request for Comments: 4520 OpenLDAP Foundation
Expires in six months 31 January
BCP: 64 June 2006
Obsoletes: RFC 3383

IANA
Category: Best Current Practice

Internet Assigned Numbers Authority (IANA) Considerations for LDAP
<draft-ietf-ldapbis-bcp64-07.txt>
the Lightweight Directory Access Protocol (LDAP)

Status of This Memo

This document is intended to be, after appropriate review and
revision, submitted to the RFC Editor as a specifies an Internet Best Current Practice
document. This document is intended to replace RFC 3383.
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 document editor
<Kurt@OpenLDAP.org>.

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 becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.

Internet-Drafts are working documents of Practices for the
Internet Engineering
Task Force (IETF), its areas, Community, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid requests discussion and suggestions for a maximum
improvements. Distribution of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It this memo is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

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 unlimited.

Please see the Full Copyright section near the end of this document
for more information.

Zeilenga IANA Considerations for LDAP [Page 1]

INTERNET-DRAFT draft-ietf-ldapbis-bcp64-07.txt 31 January 2006

Abstract

This document provides procedures for registering extensible elements
of the Lightweight Directory Access Protocol (LDAP). The document
also provides guidelines to the Internet Assigned Numbers Authority
(IANA) describing conditions under which new values can be assigned.

1. Introduction

The Lightweight Directory Access Protocol [Roadmap] [RFC4510] (LDAP) is an
extensible protocol. LDAP supports:

- the addition of new operations,
- the extension of existing operations, and
- the extensible schema.

This document details procedures for registering values of used to
unambiguously identify extensible elements of the protocol including: protocol, including
the following:

- LDAP message types; types
- LDAP extended operations and controls; controls
- LDAP result codes; codes
- LDAP authentication methods; methods
- LDAP attribute description options; and options
- Object Identifier descriptors. descriptors

Zeilenga Best Current Practice [Page 1]

RFC 4520 IANA Considerations for LDAP June 2006

These registries are maintained by the Internet Assigned Numbers
Authority (IANA).

In addition, this document provides guidelines to IANA describing the
conditions under which new values can be assigned.

This document replaces RFC 3383.

2. Terminology and Conventions

This section details terms and conventions used in this document.

2.1. Policy Terminology

The terms "IESG Approval", "Standards Action", "IETF Consensus",
"Specification Required", "First Come First Served", "Expert Review",
and "Private Use" are used as defined in BCP 26 [RFC2434].

The term "registration owner" (or "owner") refers to the party

Zeilenga IANA Considerations for LDAP [Page 2]

INTERNET-DRAFT draft-ietf-ldapbis-bcp64-07.txt 31 January 2006
authorized to change a value's registration.

2.2. Requirement Terminology

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 BCP 14 [RFC2119]. In
this case, "the specification" specification", as used by BCP 14 14, refers to the
processing of protocols being submitted to the IETF standards
process.

2.3. Common ABNF Productions

A number of syntaxes in this document are described using ABNF
[ABNF].
[RFC4234]. These syntaxes rely on the following common productions:

ALPHA = %x41-5A / %x61-7A ; "A"-"Z" / "a"-"z"
LDIGIT = %x31-39 ; "1"-"9"
DIGIT = %x30 / LDIGIT ; "0"-"9"
HYPHEN = %x2D ; "-"
DOT = %x2E ; "."
number = DIGIT / ( LDIGIT 1*DIGIT )
keychar = ALPHA / DIGIT / HYPHEN
leadkeychar = ALPHA
keystring = leadkeychar *keychar
keyword = keystring

Keywords are case-insensitive. case insensitive.

Zeilenga Best Current Practice [Page 2]

RFC 4520 IANA Considerations for LDAP June 2006

3. IANA Considerations for LDAP

This section details each kind of protocol value which that can be
registered and provides IANA guidelines on how to assign new values.

IANA may reject obviously bogus registrations.

LDAP values specified in RFCs MUST be registered. Other LDAP values,
except those in private-use name spaces, SHOULD be registered. RFCs
SHOULD NOT reference, use, or otherwise recognize unregistered LDAP
values.

3.1. Object Identifiers

Numerous LDAP schema and protocol elements are identified by Object

Zeilenga IANA Considerations for LDAP [Page 3]

INTERNET-DRAFT draft-ietf-ldapbis-bcp64-07.txt 31 January 2006
Identifiers (OIDs) [X.680]. Specifications which that assign OIDs to
elements SHOULD state who delegated the OIDs for its their use.

For IETF developed IETF-developed elements, specifications SHOULD use OIDs under
"Internet Directory Numbers" (1.3.6.1.1.x). For elements developed
by others, any properly delegated OID can be used, including those
under "Internet Directory Numbers" (1.3.6.1.1.x) or "Internet Private
Enterprise Numbers" (1.3.6.1.4.1.x).

Internet Directory Numbers (1.3.6.1.1.x) will be assigned upon Expert
Review with Specification Required. Only one OID per specification
will be assigned. The specification MAY then assign any number of
OIDs within this arc without further coordination with IANA.

Internet Private Enterprise Numbers (1.3.6.1.4.1.x) are assigned by
IANA <http://www.iana.org/cgi-bin/enterprise.pl>. Practices for IANA
assignment of Internet Private Enterprise Numbers is are detailed in RFC
2578 [RFC2578].

To avoid interoperability problems between early implementations of a
"work in progress" and implementations of the published specification
(e.g., the RFC), experimental OIDs SHOULD be used in "works in
progress" and early implementations. OIDs under the Internet
Experimental OID arc (1.3.6.1.3.x) may be used for this purpose.
Practices for IANA assignment of these Internet Experimental numbers
is
are detailed in RFC 2578 [RFC2578]

3.2 [RFC2578].

3.2. Protocol Mechanisms

LDAP provides a number of Root DSE DSA-Specific Entry (DSE) attributes
for discovery of protocol mechanisms identified by OIDs, including
the supportedControl, supportedExtension, and supportedFeatures
attributes [Models], [RFC4512].

Zeilenga Best Current Practice [Page 3]

RFC 4520 IANA Considerations for LDAP June 2006

A registry of OIDs used for discover discovery of protocol mechanisms is
provided to allow implementors and others to locate the technical
specification for these protocol mechanisms. Future specifications
of additional Root DSE attributes holding values identifying protocol
mechanisms MAY extend this registry for their values.

Protocol Mechanisms mechanisms are registered on a First Come First Served
basis.

3.3

3.3. LDAP Syntaxes

This registry provides a listing of LDAP syntaxes [Models]. [RFC4512]. Each

Zeilenga IANA Considerations for LDAP [Page 4]

INTERNET-DRAFT draft-ietf-ldapbis-bcp64-07.txt 31 January 2006
LDAP syntax is identified by an object identifier (OID). OID. This registry is provided to
allow implementors and others to locate the technical specification
describing a particular LDAP Syntax.

LDAP Syntaxes are registered on a First Come First Served with
Specification Required basis.

Note: unlike Unlike object classes, attribute types types, and various other kinds
of schema elements, descriptors are not used in LDAP to
identify LDAP Syntaxes.

3.4. Object Identifier Descriptors

LDAP allows short descriptive names (or descriptors) to be used
instead of a numeric Object Identifier to identify select protocol
extensions [Protocol], [RFC4511], schema elements [Models], [RFC4512], LDAP URL [LDAPURL] [RFC4516]
extensions, and other objects.

While

Although the protocol allows the same descriptor to refer to
different object identifiers in certain cases and the registry
supports multiple registrations of the same descriptor (each
indicating a different kind of schema element and different object
identifier), multiple registrations of the same descriptor are to be
avoided. All such multiple registration requests require Expert
Review.

Descriptors are restricted to strings of UTF-8 [RFC3629] encoded
Unicode characters restricted by the following ABNF:

name = keystring

Descriptors are case-insensitive. case insensitive.

Multiple names may be assigned to a given OID. For purposes of
registration, an OID is to be represented in numeric OID form (e.g.,
1.1.0.23.40) conforming to the following ABNF:

Zeilenga Best Current Practice [Page 4]

RFC 4520 IANA Considerations for LDAP June 2006

numericoid = number 1*( DOT number )

While the protocol places no maximum length restriction upon
descriptors, they should be short. Descriptors longer than 48
characters may be viewed as too long to register.

A value ending with a hyphen ("-") reserves all descriptors which that
start with that value. For example, the registration of the option
"descrFamily-" reserves all options which that start with "descrFamily-"
for some related purpose.

Zeilenga IANA Considerations for LDAP [Page 5]

INTERNET-DRAFT draft-ietf-ldapbis-bcp64-07.txt 31 January 2006

Descriptors beginning with "x-" are for Private Use and cannot be
registered.

Descriptors beginning with "e-" are reserved for experiments and will
be registered on a First Come First Served basis.

All other descriptors require Expert Review to be registered.

The registrant need not "own" the OID being named.

The OID name space is managed by The the ISO/IEC Joint Technical
Committee 1 - Subcommittee 6.

3.5. AttributeDescription Options

An AttributeDescription [Models] [RFC4512] can contain zero or more options
specifying additional semantics. An option SHALL be restricted to a
string of UTF-8 encoded Unicode characters limited by the following
ABNF:

option = keystring

Options are case-insensitive. case insensitive.

While the protocol places no maximum length restriction upon option
strings, they should be short. Options longer than 24 characters may
be viewed as too long to register.

Values ending with a hyphen ("-") reserve all option names which that start
with the name. For example, the registration of the option
"optionFamily-" reserves all options which that start with "optionFamily-"
for some related purpose.

Options beginning with "x-" are for Private Use and cannot be
registered.

Zeilenga Best Current Practice [Page 5]

RFC 4520 IANA Considerations for LDAP June 2006

Options beginning with "e-" are reserved for experiments and will be
registered on a First Come First Served basis.

All other options require Standards Action or Expert Review with
Specification Required to be registered.

3.6. LDAP Message Types

Each protocol message is encapsulated in an LDAPMessage envelope
[Protocol].
[RFC4511. The protocolOp CHOICE indicates the type of message

Zeilenga IANA Considerations for LDAP [Page 6]

INTERNET-DRAFT draft-ietf-ldapbis-bcp64-07.txt 31 January 2006
encapsulated. Each message type consists of an ASN.1 identifier in
the form of a keyword and a non-negative choice number. The choice
number is combined with the class (APPLICATION) and data type
(CONSTRUCTED or PRIMITIVE) to construct the BER tag in the message's
encoding. The choice numbers for existing protocol messages are
implicit in the protocol's ASN.1 defined in [Protocol]. [RFC4511].

New values will be registered upon Standards Action.

Note: LDAP provides extensible messages which reduces, that reduce but does do not
eliminate,
eliminate the need to add new message types.

3.7. LDAP Authentication Method

The LDAP Bind operation supports multiple authentication methods
[Protocol].
[RFC4511]. Each authentication choice consists of an ASN.1
identifier in the form of a keyword and a non-negative integer.

The registrant SHALL classify the authentication method usage using
one of the following terms:

COMMON - method is appropriate for common use on the
Internet,
Internet.
LIMITED USE - method is appropriate for limited use, use.
OBSOLETE - method has been deprecated or otherwise found to
be inappropriate for any use.

Methods without publicly available specifications SHALL NOT be
classified as COMMON. New registrations of the class OBSOLETE cannot
be registered.

New authentication method integers in the range 0-1023 require
Standards Action to be registered. New authentication method
integers in the range 1024-4095 require Expert Review with
Specification Required. New authentication method integers in the
range 4096-16383 will be registered on a First Come First Served
basis. Keywords associated with integers in the range 0-4095 SHALL
NOT start with "e-" or "x-". Keywords associated with integers in

Zeilenga Best Current Practice [Page 6]

RFC 4520 IANA Considerations for LDAP June 2006

the range 4096-16383 SHALL start with "e-". Values greater than or
equal to 16384 and keywords starting with "x-" are for Private Use
and cannot be registered.

Note: LDAP supports Simple Authentication and Security Layers [SASL]
[RFC4422] as an authentication choice. SASL is an extensible
authentication framework.

Zeilenga IANA Considerations for LDAP [Page 7]

INTERNET-DRAFT draft-ietf-ldapbis-bcp64-07.txt 31 January 2006 framework.

3.8. LDAP Result Codes

LDAP result messages carry an a resultCode enumerated value to indicate
the outcome of the operation [Protocol]. [RFC4511]. Each result code consists of a
an ASN.1 identifier in the form of a keyword and a non-negative
integer.

New resultCodes integers in the range 0-1023 require Standards Action
to be registered. New resultCode integers in the range 1024-4095
require Expert Review with Specification Required. New resultCode
integers in the range 4096-16383 will be registered on a First Come
First Served basis. Keywords associated with integers in the range
0-4095 SHALL NOT start with "e-" or "x-". Keywords associated with
integers in the range 4096-16383 SHALL start with "e-". Values
greater than or equal to 16384 and keywords starting with "x-" are
for Private Use and cannot be registered.

3.9. LDAP Search Scope

LDAP SearchRequest messages carry a scope enumerated scope-enumerated value to
indicate the extend extent of search within the DIT [Protocol] [RFC4511]. Each search
value consists of a an ASN.1 identifier in the form of a keyword and a
non-negative integer.

New scope integers in the range 0-1023 require Standards Action to be
registered. New scope integers in the range 1024-4095 require Expert
Review with Specification Required. New scope integers in the range
4096-16383 will be registered on a First Come First Served basis.
Keywords associated with integers in the range 0-4095 SHALL NOT start
with "e-" or "x-". Keywords associated with integers in the range
4096-16383 SHALL start with "e-". Values greater than or equal to
16384 and keywords starting with "x-" are for Private Use and cannot
be registered.

3.10. LDAP Filter Choice

LDAP filters are used in making assertions against an object
represented in the directory [Protocol]. [RFC4511]. The Filter CHOICE indicates
a type of assertion. Each Filter CHOICE consists of an ASN.1
identifier in the form of a keyword and a non-negative choice number.

Zeilenga Best Current Practice [Page 7]

RFC 4520 IANA Considerations for LDAP June 2006

The choice number is combined with the class (APPLICATION) and data
type (CONSTRUCTED or PRIMITIVE) to construct the BER tag in the
message's encoding.

Note: LDAP provides the extensibleMatching choice choice, which reduces, reduces but
does not eliminate, eliminate the need to add new filter choices.

Zeilenga IANA Considerations for LDAP [Page 8]

INTERNET-DRAFT draft-ietf-ldapbis-bcp64-07.txt 31 January 2006

3.11. LDAP ModifyRequest Operation Type

The LDAP ModifyRequest carries a sequence of modification operations
[Protocol].
[RFC4511]. Each kind (e.g., add, delete, replace) of operation is
consists of a an ASN.1 identifier in the form of a keyword and a
non-negative non-
negative integer.

New operation type integers in the range 0-1023 require Standards
Action to be registered. New operation type integers in the range
1024-4095 require Expert Review with Specification Required. New
operation type integers in the range 4096-16383 will be registered on
a First Come First Served basis. Keywords associated with integers
in the range 0-4095 SHALL NOT start with "e-" or "x-". Keywords
associated with integers in the range 4096-16383 SHALL start with
"e-". Values greater than or equal to 16384 and keywords starting
with "x-" are for Private Use and cannot be registered.

3.12. LDAP authzId Prefixes

Authorization Identities in LDAP are strings conforming to the
<authzId> production [AuthMeth]. [RFC4513]. This production is extensible. Each
new specific authorization form is identified by a prefix string
conforming to the following ABNF:

prefix = keystring COLON
COLON = %x3A ; COLON (":" U+003A)

Prefixes are case-insensitive. case insensitive.

While the protocol places no maximum length restriction upon prefix
strings, they should be short. Prefixes longer than 12 characters
may be viewed as too long to register.

Prefixes beginning with "x-" are for Private Use and cannot be
registered.

Prefixes beginning with "e-" are reserved for experiments and will be
registered on a First Come First Served basis.

All other prefixes require Standards Action or Expert Review with
Specification Required to be registered.

Zeilenga Best Current Practice [Page 8]

RFC 4520 IANA Considerations for LDAP June 2006

3.13. Directory Systems Names

The IANA-maintained "Directory Systems Names" registry [IANADSN] of
valid keywords for well known well-known attributes was used in the LDAPv2

Zeilenga IANA Considerations for LDAP [Page 9]

INTERNET-DRAFT draft-ietf-ldapbis-bcp64-07.txt 31 January 2006
string representation of a distinguished name [RFC1779]. LDAPv2 is
now Historic [RFC3494].

Directory systems names are not known to be used in any other
context. LDAPv3 [LDAPDN] [RFC4514] uses Object Identifier Descriptors
[Section 3.2] (which have a different syntax than directory system
names).

New Directory System Names will no longer be accepted. For
historical purposes, the current list of registered names should
remain publicly available.

4. Registration Procedure

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.

The first step is for the requester to fill out the appropriate form.
Templates are provided in Appendix A.

If the policy is Standards Action, the completed form SHOULD be
provided to the IESG with the request for Standards Action. Upon
approval of the Standards Action, the IESG SHALL forward the request
(possibly revised) to IANA. The IESG SHALL be regarded as the
registration owner of all values requiring Standards Action.

If the policy is Expert Review, the requester SHALL post the
completed 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 submitted, the review period is restarted. Anyone may
subscribe to this list by sending a request to
<directory-request@apps.ietf.org>. <directory-
request@apps.ietf.org>. During the review, objections may be raised
by anyone (including the Expert) on the list. After completion of
the review, the Expert, based upon on public comments, SHALL either
approve the request and forward it to the IANA OR deny the request.
In either case, the Expert SHALL promptly notify the requester of the
action. Actions of the Expert may be appealed [RFC2026]. The Expert
is appointed by Applications Area Director(s). Directors. The requester is viewed
as the registration owner of values registered under Expert Review.

If the policy is First Come First Served, the requester SHALL submit
the completed form directly to the IANA: <iana@iana.org>. The
requester is viewed as the registration owner of values registered
under First Come First Served.

Zeilenga Best Current Practice [Page 9]

RFC 4520 IANA Considerations for LDAP June 2006

Neither the Expert nor IANA will take position on the claims of
copyright or trademarks trademark issues regarding completed forms.

Zeilenga IANA Considerations for LDAP [Page 10]

INTERNET-DRAFT draft-ietf-ldapbis-bcp64-07.txt 31 January 2006

Prior to submission of the Internet Draft (I-D) to the RFC Editor but
after IESG review and tentative approval, the document editor SHOULD
revise the I-D to use registered values.

5. Registration Maintenance

This section discusses maintenance of registrations.

5.1. Lists of Registered Values

IANA makes lists of registered values readily available to the
Internet community on their its web site: <http://www.iana.org/>.

5.2. Change Control

The registration owner MAY update the registration subject to the
same constraints and review as with new registrations. In cases
where the registration owner is not unable or is unwilling to make
necessary updates, the IESG MAY assume ownership of the registration
in order to update the registration.

5.3. Comments

For cases where others (anyone other than the registration owner)
have significant objections to the claims in a registration and the
registration owner does not agree to change the registration,
comments MAY be attached to a registration upon Expert Review. For
registrations owned by the IESG, the objections SHOULD be addressed
by initiating a request for Expert Review.

The form to of 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

The security considerations detailed in BCP 26 [RFC2434] are
generally applicable to this document. Additional security
considerations specific to each name space are discussed in Section 3
3, where appropriate.

Security considerations for LDAP are discussed in documents
comprising the technical specification [Roadmap]. [RFC4510].

Zeilenga Best Current Practice [Page 10]

RFC 4520 IANA Considerations for LDAP [Page 11]

INTERNET-DRAFT draft-ietf-ldapbis-bcp64-07.txt 31 January June 2006

7. Acknowledgment Acknowledgement

This document is a product of the IETF LDAP Revision (LDAPBIS)
Working Group (WG). This document is a revision of RFC 3383, also a
product of the LDAPBIS WG.

This document includes text borrowed from "Guidelines for Writing an
IANA Considerations Section in RFCs" [RFC2434] by Thomas Narten and
Harald Alvestrand.

8. Author's Address

Kurt D. Zeilenga
OpenLDAP Foundation

Email: Kurt@OpenLDAP.org

9. References

[[Note to the RFC Editor: please replace the citation tags used in
referencing Internet-Drafts with tags of the form RFCnnnn where
possible.]]

9.1.

8.1. Normative References

[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9 (also 9, RFC 2026), 2026, October 1996.

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14 (also 14, RFC 2119), 2119, March 1997.

[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26 (also 26, RFC
2434), 2434,
October 1998.

[RFC2578] K. McCloghrie, D. K., Perkins, D., and J. Schoenwaelder,
"Structure of Management Information Version 2 (SMIv2)",
STD 58, RFC 2578
(STD: 58), 2578, April 1999.

[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", RFC 3629 (also STD 63), 63, RFC 3629, November 2003.

[ABNF]

[RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005.

[Roadmap]

[RFC4510] Zeilenga, K. (editor), "LDAP: K., Ed., "Lightweight Directory Access Protocol
(LDAP): Technical Specification

Zeilenga IANA Considerations for LDAP [Page 12]

INTERNET-DRAFT draft-ietf-ldapbis-bcp64-07.txt 31 January 2006 Road Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in
progress.

[AuthMeth] RFC 4510, June
2006.

[RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access
Protocol (LDAP): The Protocol", RFC 4511, June 2006.

[RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol
(LDAP): Directory Information Models", RFC 4512, June
2006.

[RFC4513] Harrison, R. (editor), "LDAP: R., Ed., "Lightweight Directory Access Protocol
(LDAP): Authentication Methods and
Connection Level Security Mechanisms",
draft-ietf-ldapbis-authmeth-xx.txt, a work in progress.

[Models] Zeilenga, K. (editor), "LDAP: Directory Information
Models", draft-ietf-ldapbis-models-xx.txt, a work in
progress.

[Protocol] Sermersheim, J. (editor), "LDAP: The Protocol",
draft-ietf-ldapbis-protocol-xx.txt, a work in progress.

[LDAPURL]
RFC 4513, June 2006.

Zeilenga Best Current Practice [Page 11]

RFC 4520 IANA Considerations for LDAP June 2006

[RFC4516] Smith, M. (editor), "LDAP: M., Ed. and T. Howes, "Lightweight Directory Access
Protocol (LDAP): Uniform Resource Locator",
draft-ietf-ldapbis-url-xx.txt, a work in progress. RFC 4516, June
2006.

[Unicode] The Unicode Consortium, "The Unicode Standard, Version
3.2.0" is defined by "The Unicode Standard, Version 3.0"
(Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5),
as amended by the "Unicode Standard Annex #27: Unicode
3.1" (http://www.unicode.org/reports/tr27/) and by the
"Unicode Standard Annex #28: Unicode 3.2"
(http://www.unicode.org/reports/tr28/).

[X.680] International Telecommunication Union - Telecommunication
Standardization Sector, "Abstract Syntax Notation One
(ASN.1) - Specification of Basic Notation", X.680(2002)
(also ISO/IEC 8824-1:2002).

9.2.

8.2. Informative References

[RFC1779] Kille, S., "A String Representation of Distinguished
Names", RFC 1779, March 1995.

[RFC3494] Zeilenga, K., "Lightweight K.,"Lightweight Directory Access Protocol
version 2 (LDAPv2) to Historic Status", RFC 3494, March
2003.

[Syntaxes] Legg, S. (editor), "LDAP: Syntaxes and Matching Rules",
draft-ietf-ldapbis-syntaxes-xx.txt, a work in progress.

[LDAPDN]

[RFC4514] Zeilenga, K. (editor), "LDAP: K., Ed., "Lightweight Directory Access Protocol
(LDAP): String Representation of Distinguished Names", draft-ietf-ldapbis-dn-xx.txt, a
work in progress.

[SASL] RFC
4514, June 2006.

[RFC4422] Melnikov, A. (Editor), A., Ed. and K. Zeilenga, Ed., "Simple
Authentication and

Zeilenga IANA Considerations for LDAP [Page 13]

INTERNET-DRAFT draft-ietf-ldapbis-bcp64-07.txt 31 January 2006 Security Layer (SASL)",
draft-ietf-sasl-rfc2222bis-xx.txt, a work in progress. RFC 4422, June
2006.

[IANADSN] IANA, "Directory Systems Names",
http://www.iana.org/assignments/directory-system-names.

Zeilenga Best Current Practice [Page 12]

RFC 4520 IANA Considerations for LDAP June 2006

Appendix A. Registration Templates

This appendix provides registration templates for registering new
LDAP values. Note that more than one value may be requested by
extending the template by listing multiple values, or through use of
tables.

A.1. LDAP Object Identifier Registration Template

Subject: Request for LDAP OID Registration

Person & email address to contact for further information:

Specification: (I-D)

Author/Change Controller:

Comments:

(Any comments that the requester deems relevant to the request) request.)

A.2. LDAP Protocol Mechanism Registration Template

Subject: Request for LDAP Protocol Mechanism Registration

Object Identifier:

Description:

Person & email address to contact for further information:

Usage: (One of Control or Extension or Feature or other)

Specification: (RFC, I-D, URI)

Author/Change Controller:

Comments:

Zeilenga IANA Considerations for LDAP [Page 14]

INTERNET-DRAFT draft-ietf-ldapbis-bcp64-07.txt 31 January 2006

Author/Change Controller:

Comments:

(Any comments that the requester deems relevant to the request) request.)

Zeilenga Best Current Practice [Page 13]

RFC 4520 IANA Considerations for LDAP June 2006

A.3. LDAP Syntax Registration Template

Subject: Request for LDAP Syntax Registration

Object Identifier:

Description:

Person & email address to contact for further information:

Specification: (RFC, I-D, URI)

Author/Change Controller:

Comments:

(Any comments that the requester deems relevant to the request) request.)

A.4. LDAP Descriptor Registration Template

Subject: Request for LDAP Descriptor Registration

Descriptor (short name):

Object Identifier:

Person & email address to contact for further information:

Usage: (One of administrative role, attribute type, matching rule,
name form, object class, URL extension, or other)

Specification: (RFC, I-D, URI)

Author/Change Controller:

Comments:

(Any comments that the requester deems relevant to the request) request.)

Zeilenga Best Current Practice [Page 14]

RFC 4520 IANA Considerations for LDAP June 2006

A.5. LDAP Attribute Description Option Registration Template

Subject: Request for LDAP Attribute Description Option Registration

Zeilenga IANA Considerations for LDAP [Page 15]

INTERNET-DRAFT draft-ietf-ldapbis-bcp64-07.txt 31 January 2006
Option Name:

Family of Options: (YES or NO)

Person & email address to contact for further information:

Specification: (RFC, I-D, URI)

Author/Change Controller:

Comments:

(Any comments that the requester deems relevant to the request) request.)

A.6. LDAP Message Type Registration Template

Subject: Request for LDAP Message Type Registration

LDAP Message Name:

Person & email address to contact for further information:

Specification: (Approved I-D)

Comments:

(Any comments that the requester deems relevant to the request) request.)

A.7. LDAP Authentication Method Registration Template

Subject: Request for LDAP Authentication Method Registration

Authentication Method Name:

Person & email address to contact for further information:

Specification: (RFC, I-D, URI)

Intended Usage: (One of COMMON, LIMITED-USE, OBSOLETE)

Author/Change Controller:

Comments:

(Any comments that the requester deems relevant to the request) request.)

Zeilenga Best Current Practice [Page 15]

RFC 4520 IANA Considerations for LDAP [Page 16]

INTERNET-DRAFT draft-ietf-ldapbis-bcp64-07.txt 31 January June 2006

A.8. LDAP Result Code Registration Template

Subject: Request for LDAP Result Code Registration

Result Code Name:

Person & email address to contact for further information:

Specification: (RFC, I-D, URI)

Author/Change Controller:

Comments:

(Any comments that the requester deems relevant to the request) request.)

A.8. LDAP Search Scope Registration Template

Subject: Request for LDAP Search Scope Registration

Search Scope Name:

Filter Scope String:

Person & email address to contact for further information:

Specification: (RFC, I-D, URI)

Author/Change Controller:

Comments:

(Any comments that the requester deems relevant to the request) request.)

Zeilenga Best Current Practice [Page 16]

RFC 4520 IANA Considerations for LDAP June 2006

A.9. LDAP Filter Choice Registration Template

Subject: Request for LDAP Filter Choice Registration

Filter Choice Name:

Person & email address to contact for further information:

Specification: (RFC, I-D, URI)

Author/Change Controller:

Zeilenga IANA Considerations for LDAP [Page 17]

INTERNET-DRAFT draft-ietf-ldapbis-bcp64-07.txt 31 January 2006

Comments:

(Any comments that the requester deems relevant to the request) request.)

A.10. LDAP ModifyRequest Operation Registration Template

Subject: Request for LDAP ModifyRequest Operation Registration

ModifyRequest Operation Name:

Person & email address to contact for further information:

Specification: (RFC, I-D, URI)

Author/Change Controller:

Comments:

(Any comments that the requester deems relevant to the request) request.)

Appendix B. Changes since RFC 3383

This informative appendix provides a summary of changes made since
RFC 3383.

- Object Identifier Descriptors practices were updated to require
all descriptors defined in RFCs to be registered and
recommending all other descriptors (excepting those in
private-use name space) be registered. Additionally, all
requests for multiple registrations of the same descriptor are
now subject to Expert Review.

- Protocol Mechanisms practices were updated to include values of
the 'supportedFeatures' attribute type.

Zeilenga Best Current Practice [Page 17]

RFC 4520 IANA Considerations for LDAP June 2006

- LDAP Syntax, Search Scope, Filter Choice, ModifyRequest
operation, and authzId prefixes registries were added.
[[Initial values provided in Appendix C. This Appendix is to be
removed by the RFC Editor before publication as an RFC.]]

- References to RFCs comprising the LDAP technical specifications
have been updated to latest revisions.

- References to ISO 10646 have been replaced with [Unicode].

- The "Assigned Values" appendix providing initial registry
values

Zeilenga IANA Considerations for LDAP [Page 18]

INTERNET-DRAFT draft-ietf-ldapbis-bcp64-07.txt 31 January 2006 was removed.

- Numerous editorial changes were made.

Appendix C. Initial Values for new registries

This appendix provides initial values for new registries.

C.1. LDAP Syntaxes

Object Identifier Syntax Owner Reference
----------------------------- -------------------------- ----- ---------
1.3.6.1.4.1.1466.115.121.1.3 Attribute Type Description IESG [Syntaxes]
1.3.6.1.4.1.1466.115.121.1.6 Bit String IESG [Syntaxes]
1.3.6.1.4.1.1466.115.121.1.7 Boolean IESG [Syntaxes]
1.3.6.1.4.1.1466.115.121.1.11 Country String IESG [Syntaxes]
1.3.6.1.4.1.1466.115.121.1.12 DN IESG [Syntaxes]
1.3.6.1.4.1.1466.115.121.1.14 Delivery Method IESG [Syntaxes]
1.3.6.1.4.1.1466.115.121.1.15 Directory String IESG [Syntaxes]
1.3.6.1.4.1.1466.115.121.1.16 DIT Content Rule Description IESG [Syntaxes]
1.3.6.1.4.1.1466.115.121.1.17 DIT Structure Rule Description IESG [Syntaxes]
1.3.6.1.4.1.1466.115.121.1.21 Enhanced Guide IESG [Syntaxes]
1.3.6.1.4.1.1466.115.121.1.22 Facsimile Telephone Number IESG [Syntaxes]
1.3.6.1.4.1.1466.115.121.1.23 Fax IESG [Syntaxes]
1.3.6.1.4.1.1466.115.121.1.24 Generalized Time IESG [Syntaxes]
1.3.6.1.4.1.1466.115.121.1.25 Guide IESG [Syntaxes]
1.3.6.1.4.1.1466.115.121.1.26 IA5 String IESG [Syntaxes]
1.3.6.1.4.1.1466.115.121.1.27 Integer IESG [Syntaxes]
1.3.6.1.4.1.1466.115.121.1.28 JPEG IESG [Syntaxes]
1.3.6.1.4.1.1466.115.121.1.30 Matching Rule Description IESG [Syntaxes]
1.3.6.1.4.1.1466.115.121.1.31 Matching Rule Use Description IESG [Syntaxes]
1.3.6.1.4.1.1466.115.121.1.34 Name And Optional UID IESG [Syntaxes]
1.3.6.1.4.1.1466.115.121.1.35 Name Form Description IESG [Syntaxes]
1.3.6.1.4.1.1466.115.121.1.36 Numeric String IESG [Syntaxes]
1.3.6.1.4.1.1466.115.121.1.37 Object Class Description IESG [Syntaxes]
1.3.6.1.4.1.1466.115.121.1.38 OID IESG [Syntaxes]
1.3.6.1.4.1.1466.115.121.1.39 Other Mailbox IESG [Syntaxes]
1.3.6.1.4.1.1466.115.121.1.40 Octet String IESG [Syntaxes]
1.3.6.1.4.1.1466.115.121.1.41 Postal

Author's Address IESG [Syntaxes]
1.3.6.1.4.1.1466.115.121.1.44 Printable String IESG [Syntaxes]
1.3.6.1.4.1.1466.115.121.1.50 Telephone Number IESG [Syntaxes]
1.3.6.1.4.1.1466.115.121.1.51 Teletex Terminal Identifier IESG [Syntaxes]
1.3.6.1.4.1.1466.115.121.1.52 Telex Number IESG [Syntaxes]
1.3.6.1.4.1.1466.115.121.1.53 UTC Time IESG [Syntaxes]
1.3.6.1.4.1.1466.115.121.1.54 LDAP Syntax Description IESG [Syntaxes]
1.3.6.1.4.1.1466.115.121.1.58 Substring Assertion IESG [Syntaxes]

Kurt D. Zeilenga
OpenLDAP Foundation

EMail: Kurt@OpenLDAP.org

Zeilenga Best Current Practice [Page 18]

RFC 4520 IANA Considerations for LDAP [Page 19]

INTERNET-DRAFT draft-ietf-ldapbis-bcp64-07.txt 31 January June 2006

C.2. LDAP Search Scopes

Name URLString Value Owner Reference
---------------- --------- ----- ----- -------------------
baseObject base 0 IESG [Protocol][LDAPURL]
singleLevel one 1 IESG [Protocol][LDAPURL]
wholeSubtree sub 2 IESG [Protocol][LDAPURL]

C.3. LDAP Filter Choices

Name Value Owner Reference
---------------- ----- ----- ---------
and 0 IESG [Protocol]
or 1 IESG [Protocol]
not 2 IESG [Protocol]
equalityMatch 3 IESG [Protocol]
substrings 4 IESG [Protocol]
greaterOrEqual 5 IESG [Protocol]
lessOrEqual 6 IESG [Protocol]
present 7 IESG [Protocol]
approxMatch 8 IESG [Protocol]
extensibleMatch 9 IESG [Protocol]

C.4. LDAP ModifyRequest Operations

Name Value Owner Reference
---------------- ----- ----- ---------
add 0 IESG [Protocol]
delete 1 IESG [Protocol]
replace 2 IESG [Protocol]

C.5. LDAP authzId prefixes

Name Prefix Owner Reference
---------------- ------ ----- ---------
dnAuthzId dn: IESG [AuthMeth]
uAuthzId u: IESG [AuthMeth]

Full Copyright Statement

This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors

Zeilenga IANA Considerations for LDAP [Page 20]

INTERNET-DRAFT draft-ietf-ldapbis-bcp64-07.txt 31 January 2006
retain all their rights.

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.

Intellectual Property Rights

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.

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.

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.

Zeilenga IANA Considerations

Acknowledgement

Funding for LDAP the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).

Zeilenga Best Current Practice [Page 21] 19]

----