GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc4520

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:
  1. the addition of new operations,
  2. the extension of existing operations, and
  3. the extensible schema.
 This document details procedures for registering values used to
 unambiguously identify extensible elements of the protocol, including
 the following:
  1. LDAP message types
  2. LDAP extended operations and controls
  3. LDAP result codes
  4. LDAP authentication methods
  5. LDAP attribute description options
  6. 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.
 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 extent of search within the DIT [RFC4511].  Each search
 value consists of 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 [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, which reduces but
       does not eliminate the need to add new filter choices.

3.11. LDAP ModifyRequest Operation Type

 The LDAP ModifyRequest carries a sequence of modification operations
 [RFC4511].  Each kind (e.g., add, delete, replace) of operation
 consists of an 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 [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.
 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 attributes was used in the LDAPv2
 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 [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>.  During the review, objections may be raised
 by anyone (including the Expert) on the list.  After completion of
 the review, the Expert, based 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 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 trademark 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
 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 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 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 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, where appropriate.
 Security considerations for LDAP are discussed in documents
 comprising the technical specification [RFC4510].

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

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

8.1. Normative References

 [RFC2026]  Bradner, S., "The Internet Standards Process -- Revision
            3", BCP 9, RFC 2026, October 1996.
 [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
            Requirement Levels", BCP 14, RFC 2119, March 1997.
 [RFC2434]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
            IANA Considerations Section in RFCs", BCP 26, RFC 2434,
            October 1998.
 [RFC2578]  McCloghrie, K., Perkins, D., and J. Schoenwaelder,
            "Structure of Management Information Version 2 (SMIv2)",
            STD 58, RFC 2578, April 1999.
 [RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO
            10646", STD 63, RFC 3629, November 2003.
 [RFC4234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
            Specifications: ABNF", RFC 4234, October 2005.
 [RFC4510]  Zeilenga, K., Ed., "Lightweight Directory Access Protocol
            (LDAP): Technical Specification Road Map", 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., Ed., "Lightweight Directory Access Protocol
            (LDAP): Authentication Methods and Security Mechanisms",
            RFC 4513, June 2006.

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

 [RFC4516]  Smith, M., Ed. and T. Howes, "Lightweight Directory Access
            Protocol (LDAP): Uniform Resource Locator", 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).

8.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.
 [RFC4514]  Zeilenga, K., Ed., "Lightweight Directory Access Protocol
            (LDAP): String Representation of Distinguished Names", RFC
            4514, June 2006.
 [RFC4422]  Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple
            Authentication and Security Layer (SASL)", 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.)

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

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

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

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

Zeilenga Best Current Practice [Page 15] RFC 4520 IANA Considerations for LDAP 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.)

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

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:
 Comments:
 (Any comments that the requester deems relevant to the 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.)

Appendix B. Changes since RFC 3383

 This informative appendix provides a summary of changes made since
 RFC 3383.
  1. 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.
  1. 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

  1. LDAP Syntax, Search Scope, Filter Choice, ModifyRequest

operation, and authzId prefixes registries were added.

  1. References to RFCs comprising the LDAP technical specifications

have been updated to latest revisions.

  1. References to ISO 10646 have been replaced with [Unicode].
  1. The "Assigned Values" appendix providing initial registry

values was removed.

  1. Numerous editorial changes were made.

Author's Address

 Kurt D. Zeilenga
 OpenLDAP Foundation
 EMail: Kurt@OpenLDAP.org

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

Full Copyright Statement

 Copyright (C) The Internet Society (2006).
 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
 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

 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.

Acknowledgement

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

Zeilenga Best Current Practice [Page 19]

/data/webs/external/dokuwiki/data/pages/rfc/rfc4520.txt · Last modified: 2006/06/06 23:45 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki