Movatterモバイル変換

Network Working Group                                        K. ZeilengaRequest for Comments: 4520                           OpenLDAP FoundationBCP: 64                                                        June 2006Obsoletes:3383Category: Best Current PracticeInternet Assigned Numbers Authority (IANA) Considerations forthe 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 descriptorsZeilenga                 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 replacesRFC 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 inBCP 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 inBCP 14 [RFC2119].  In   this case, "the specification", as used byBCP 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 20063.  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 inRFC2578 [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 inRFC 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 inZeilenga                 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 20063.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 inSection 3 of this document.   The first step is for the requester to fill out the appropriate form.   Templates are provided inAppendix 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 inBCP 26 [RFC2434] are   generally applicable to this document.  Additional security   considerations specific to each name space are discussed inSection3, 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 20067.  Acknowledgement   This document is a product of the IETF LDAP Revision (LDAPBIS)   Working Group (WG).  This document is a revision ofRFC 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.  References8.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",RFC4514, 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 2006Appendix 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 2006A.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 2006A.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 2006A.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 2006A.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 sinceRFC 3383   This informative appendix provides a summary of changes made sinceRFC 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.      -  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.Author's Address   Kurt D. Zeilenga   OpenLDAP Foundation   EMail: Kurt@OpenLDAP.orgZeilenga                 Best Current Practice                 [Page 18]

RFC 4520              IANA Considerations for LDAP             June 2006Full Copyright Statement   Copyright (C) The Internet Society (2006).   This document is subject to the rights, licenses and restrictions   contained inBCP 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 inBCP 78 andBCP 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 athttp://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]