ready for release

[openldap] / doc / drafts / draft-ietf-ldapbis-bcp64-xx.txt

INTERNET-DRAFT                                Kurt D. Zeilenga
Intended Category: BCP                        OpenLDAP Foundation
Expires in six months                         21 February 2005
Obsoletes: RFC 3383


                      IANA Considerations for LDAP
                   <draft-ietf-ldapbis-bcp64-05.txt>



Status of Memo

   This document is intended to be, after appropriate review and
   revision, submitted to the RFC Editor as a 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, I accept the provisions of Section
   4 of RFC 3667.  By submitting this Internet-Draft, I certify that any
   applicable patent or other IPR claims of which I am aware have been
   disclosed, or will be disclosed, and any of which I become aware will
   be disclosed, in accordance with RFC 3668.

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

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

   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


   Copyright (C) The Internet Society (2005).  All Rights Reserved.

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



Zeilenga              IANA Considerations for LDAP              [Page 1]
\f
INTERNET-DRAFT       draft-ietf-ldapbis-bcp64-05.txt    21 February 2005


Abstract

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


1. Introduction

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

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

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

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

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





Zeilenga              IANA Considerations for LDAP              [Page 2]
\f
INTERNET-DRAFT       draft-ietf-ldapbis-bcp64-05.txt    21 February 2005


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" as used by BCP 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
   [RFC2234].  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

   A keyword is a case-insensitive string of UTF-8 [RFC3629] encoded
   Unicode [Unicode] restricted to the <keystring> production.


3.  IANA Considerations for LDAP

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

   IANA may reject obviously bogus registrations described.

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


3.1. Object Identifiers

   Numerous LDAP schema and protocol elements are identified by Object
   Identifiers (OIDs) [X.680].  Specifications which assign OIDs to
   elements SHOULD state who delegated the OIDs for its use.




Zeilenga              IANA Considerations for LDAP              [Page 3]
\f
INTERNET-DRAFT       draft-ietf-ldapbis-bcp64-05.txt    21 February 2005


   For 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 detailed in STD
   16 [RFC1155].

   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 detailed in STD 16 [RFC1155].


3.2 Protocol Mechanisms

   LDAP provides a number of Root DSE attributes for discovery of
   protocol mechanisms identified by OIDs, including the
   supportedControl, supportedExtension, and supportedFeatures
   attributes [Models],

   A registry of OIDs used for discover 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 are registered on a First Come First Served
   basis.


3.3 LDAP Syntaxes

   This registry provides a listing of LDAP syntaxes [Models].  Each
   LDAP syntax is identified by an object identifier (OID).  This
   registry is provided to allow implementors and others to locate the
   technical specification describing a particular LDAP Syntax.



Zeilenga              IANA Considerations for LDAP              [Page 4]
\f
INTERNET-DRAFT       draft-ietf-ldapbis-bcp64-05.txt    21 February 2005


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

   Note: unlike object classes, attribute 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], schema elements [Models], LDAP URL [LDAPURL]
   extensions, and other objects.

   While 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 registration requests require Expert Review.

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

        name = keystring

   Descriptors are 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 ABNF:

        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
   start with that value.  For example, the registration of the option
   "descrFamily-" reserves all options which start with "descrFamily-"
   for some related purpose.

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

   Descriptors beginning with "e-" are reserved for experiments and will



Zeilenga              IANA Considerations for LDAP              [Page 5]
\f
INTERNET-DRAFT       draft-ietf-ldapbis-bcp64-05.txt    21 February 2005


   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 ISO/IEC Joint Technical
   Committee 1 - Subcommittee 6.


3.5. AttributeDescription Options

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

        option = keystring

   Options are 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
   start with the name.  For example, the registration of the option
   "optionFamily-" reserves all options which start with "optionFamily-"
   for some related purpose.

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

   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].  The protocolOp CHOICE indicates the type of message
   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



Zeilenga              IANA Considerations for LDAP              [Page 6]
\f
INTERNET-DRAFT       draft-ietf-ldapbis-bcp64-05.txt    21 February 2005


   encoding.  The choice numbers for existing protocol messages are
   implicit in the protocol's ASN.1 defined in [Protocol].

   New values will be registered upon Standards Action.

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


3.7. LDAP Authentication Method

   The LDAP Bind operation supports multiple authentication methods
   [Protocol].  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,
          LIMITED USE - method is appropriate for limited 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 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
   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]
         as an authentication choice.  SASL is an extensible
         authentication framework.


3.8. LDAP Result Codes

   LDAP result messages carry an resultCode enumerated value to indicate
   the outcome of the operation [Protocol].  Each result code consists



Zeilenga              IANA Considerations for LDAP              [Page 7]
\f
INTERNET-DRAFT       draft-ietf-ldapbis-bcp64-05.txt    21 February 2005


   of a 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 value to
   indicate the extend of search within the DIT [Protocol] Each search
   value consists of a 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]. 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.
   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 which reduces, but
         does not eliminate, the need to add new filter choices.


3.11. LDAP ModifyRequest Operation Type




Zeilenga              IANA Considerations for LDAP              [Page 8]
\f
INTERNET-DRAFT       draft-ietf-ldapbis-bcp64-05.txt    21 February 2005


   The LDAP ModifyRequest carries a sequence of modification operations
   [Protocol].  Each kind (e.g., add, delete, replace) of operation is
   consists of a ASN.1 identifier in the form of a keyword and a
   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].  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.

   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.


3.13. Directory Systems Names

   The IANA-maintained "Directory Systems Names" registry [IANADSN] of
   valid keywords for well known attributes was used in the LDAPv2
   string representation of a distinguished name [RFC1779].  LDAPv2 is
   now Historic [RFC3494].



Zeilenga              IANA Considerations for LDAP              [Page 9]
\f
INTERNET-DRAFT       draft-ietf-ldapbis-bcp64-05.txt    21 February 2005


   Directory systems names are not known to be used in any other
   context.  LDAPv3 [LDAPDN] 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 viewed as the 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>.  During the review, objections may
   be raised by anyone (including the Expert) on the list.  After
   completion of the review, the Expert, based upon public comments,
   SHALL either approve the request and forward it to the IESG 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).
   The requester is viewed as the 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 owner of values registered under First
   Come First Served.

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

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



Zeilenga              IANA Considerations for LDAP             [Page 10]
\f
INTERNET-DRAFT       draft-ietf-ldapbis-bcp64-05.txt    21 February 2005


   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 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 owner is not unable or unwilling to make necessary updates,
   the IESG MAY assume ownership in order to update the registration.


5.3. Comments

   For cases where others (anyone other than the owner) have significant
   objections to the claims in a registration and the 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 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
   where appropriate.

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


7. Acknowledgment



Zeilenga              IANA Considerations for LDAP             [Page 11]
\f
INTERNET-DRAFT       draft-ietf-ldapbis-bcp64-05.txt    21 February 2005


   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. Normative References

  [RFC1155]     Rose, M. and K. McCloghrie, "Structure and
                Identification of Management Information for TCP/IP-
                based Internets", STD 16 (also RFC 1155), May 1990.

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

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

  [RFC2234]     Crocker, D. and P. Overell, "Augmented BNF for Syntax
                Specifications: ABNF", RFC 2234, November 1997.

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

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

  [Roadmap]     Zeilenga, K. (editor), "LDAP: Technical Specification
                Road Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in



Zeilenga              IANA Considerations for LDAP             [Page 12]
\f
INTERNET-DRAFT       draft-ietf-ldapbis-bcp64-05.txt    21 February 2005


                progress.

  [AuthMeth]    Harrison, R. (editor), "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]     Smith, M. (editor), "LDAP: Uniform Resource Locator",
                draft-ietf-ldapbis-url-xx.txt, a work in progress.

  [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. Informative References

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

  [RFC3494]     Zeilenga, 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]      Zeilenga, K. (editor), "LDAP: String Representation of
                Distinguished Names", draft-ietf-ldapbis-dn-xx.txt, a
                work in progress.

  [SASL]        Melnikov, A. (Editor), "Simple Authentication and
                Security Layer (SASL)",



Zeilenga              IANA Considerations for LDAP             [Page 13]
\f
INTERNET-DRAFT       draft-ietf-ldapbis-bcp64-05.txt    21 February 2005


                draft-ietf-sasl-rfc2222bis-xx.txt, a work in progress.

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


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)


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:

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



Zeilenga              IANA Considerations for LDAP             [Page 14]
\f
INTERNET-DRAFT       draft-ietf-ldapbis-bcp64-05.txt    21 February 2005


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)


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)


A.5.  LDAP Attribute Description Option Registration Template

   Subject: Request for LDAP Attribute Description Option Registration

   Option Name:

   Family of Options: (YES or NO)



Zeilenga              IANA Considerations for LDAP             [Page 15]
\f
INTERNET-DRAFT       draft-ietf-ldapbis-bcp64-05.txt    21 February 2005


   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)


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)


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)


A.8.  LDAP Result Code Registration Template

   Subject: Request for LDAP Result Code Registration



Zeilenga              IANA Considerations for LDAP             [Page 16]
\f
INTERNET-DRAFT       draft-ietf-ldapbis-bcp64-05.txt    21 February 2005


   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)


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)


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:

   Comments:

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




Zeilenga              IANA Considerations for LDAP             [Page 17]
\f
INTERNET-DRAFT       draft-ietf-ldapbis-bcp64-05.txt    21 February 2005


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)


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.

      - 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
        was removed.

      - Numerous editorial changes were made.





Zeilenga              IANA Considerations for LDAP             [Page 18]
\f
INTERNET-DRAFT       draft-ietf-ldapbis-bcp64-05.txt    21 February 2005


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 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]


C.2.  LDAP Search Scopes

  Name              URLString Value  Owner Reference



Zeilenga              IANA Considerations for LDAP             [Page 19]
\f
INTERNET-DRAFT       draft-ietf-ldapbis-bcp64-05.txt    21 February 2005


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

  Copyright (C) The Internet Society (2005).  This document is subject
  to the rights, licenses and restrictions contained in BCP 78, and
  except as set forth therein, the authors retain all their rights.

  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



Zeilenga              IANA Considerations for LDAP             [Page 20]
\f
INTERNET-DRAFT       draft-ietf-ldapbis-bcp64-05.txt    21 February 2005


  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 for LDAP             [Page 21]
\f