diff options
Diffstat (limited to 'source4/ldap_server/devdocs/rfc4520.txt')
| -rw-r--r-- | source4/ldap_server/devdocs/rfc4520.txt | 1067 |
1 files changed, 1067 insertions, 0 deletions
diff --git a/source4/ldap_server/devdocs/rfc4520.txt b/source4/ldap_server/devdocs/rfc4520.txt new file mode 100644 index 0000000000..9ef5daadea --- /dev/null +++ b/source4/ldap_server/devdocs/rfc4520.txt @@ -0,0 +1,1067 @@ + + + + + + +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. + + 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. + + - 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.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] + |