rfc4520.txt

samba最新软件

Network Working Group                                        K. Zeilenga
Request for Comments: 4520                           OpenLDAP Foundation
BCP: 64                                                        June 2006
Obsoletes: 3383
Category: Best Current Practice


     Internet Assigned Numbers Authority (IANA) Considerations for
            the Lightweight Directory Access Protocol (LDAP)

Status of This Memo

   This document specifies an Internet Best Current Practices for the
   Internet Community, and requests discussion and suggestions for
   improvements.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (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 [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 used to
   unambiguously identify extensible elements of the protocol, including
   the following:

      - LDAP message types
      - LDAP extended operations and controls
      - LDAP result codes
      - LDAP authentication methods
      - LDAP attribute description options
      - Object Identifier 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
   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", 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
   [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.




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 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
   Identifiers (OIDs) [X.680].  Specifications that assign OIDs to
   elements SHOULD state who delegated the OIDs for their use.

   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 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
   are detailed in RFC 2578 [RFC2578].

3.2.  Protocol Mechanisms

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



Zeilenga                 Best Current Practice                  [Page 3]

RFC 4520              IANA Considerations for LDAP             June 2006


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

3.3.  LDAP Syntaxes

   This registry provides a listing of LDAP syntaxes [RFC4512].  Each
   LDAP syntax is identified by an 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 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 [RFC4511], schema elements [RFC4512], LDAP URL [RFC4516]
   extensions, and other objects.

   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.

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

   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 that start
   with the name.  For example, the registration of the option
   "optionFamily-" reserves all options 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
   [RFC4511.  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
   encoding.  The choice numbers for existing protocol messages are
   implicit in the protocol's ASN.1 defined in [RFC4511].

   New values will be registered upon Standards Action.

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

3.7.  LDAP Authentication Method

   The LDAP Bind operation supports multiple authentication methods
   [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.
         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 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
         [RFC4422] as an authentication choice.  SASL is an extensible
         authentication framework.

3.8.  LDAP Result Codes

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