INTERNET-DRAFT Kurt D. Zeilenga Intended Category: BCP OpenLDAP Foundation Expires in six months 23 January 2006 Obsoletes: RFC 3383 IANA Considerations for LDAP Status of Memo This document is intended to be, after appropriate review and revision, submitted to the RFC Editor as a Best Current Practice document. This document is intended to replace RFC 3383. Distribution of this memo is unlimited. Technical discussion of this document will take place on the IETF LDAP Revision Working Group (LDAPBIS) mailing list . Please send editorial comments directly to the document editor . By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright (C) The Internet Society (2006). All Rights Reserved. Please see the Full Copyright section near the end of this document for more information. Zeilenga IANA Considerations for LDAP [Page 1] INTERNET-DRAFT draft-ietf-ldapbis-bcp64-06.txt 23 January 2006 Abstract This document provides procedures for registering extensible elements of Lightweight Directory Access Protocol (LDAP). The document also provides guidelines to Internet Assigned Numbers Authority (IANA) describing conditions under which new values can be assigned. 1. Introduction The Lightweight Directory Access Protocol [Roadmap] (LDAP) is an extensible protocol. LDAP supports: - addition of new operations, - extension of existing operations, and - extensible schema. This document details procedures for registering values of used to unambiguously identify extensible elements of the protocol including: - LDAP message types; - LDAP extended operations and controls; - LDAP result codes; - LDAP authentication methods; - LDAP attribute description options; and - Object Identifier descriptors. These registries are maintained by the Internet Assigned Numbers Authority (IANA). In addition, this document provides guidelines to IANA describing the conditions under which new values can be assigned. This document replaces RFC 3383. 2. Terminology and Conventions This section details terms and conventions used in this document. 2.1. Policy Terminology The terms "IESG Approval", "Standards Action", "IETF Consensus", "Specification Required", "First Come First Served", "Expert Review", and "Private Use" are used as defined in BCP 26 [RFC2434]. Zeilenga IANA Considerations for LDAP [Page 2] INTERNET-DRAFT draft-ietf-ldapbis-bcp64-06.txt 23 January 2006 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 [ABNF]. These syntaxes rely on the following common productions: ALPHA = %x41-5A / %x61-7A ; "A"-"Z" / "a"-"z" LDIGIT = %x31-39 ; "1"-"9" DIGIT = %x30 / LDIGIT ; "0"-"9" HYPHEN = %x2D ; "-" DOT = %x2E ; "." number = DIGIT / ( LDIGIT 1*DIGIT ) keychar = ALPHA / DIGIT / HYPHEN leadkeychar = ALPHA keystring = leadkeychar *keychar A keyword is a case-insensitive string of UTF-8 [RFC3629] encoded Unicode [Unicode] restricted to the production. 3. IANA Considerations for LDAP This section details each kind of protocol value which can be registered and provides IANA guidelines on how to assign new values. IANA may reject obviously bogus registrations. 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 which assign OIDs to elements SHOULD state who delegated the OIDs for its use. Zeilenga IANA Considerations for LDAP [Page 3] INTERNET-DRAFT draft-ietf-ldapbis-bcp64-06.txt 23 January 2006 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 . Practices for IANA assignment of Internet Private Enterprise Numbers is 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 is detailed in RFC 2578 [RFC2578] 3.2 Protocol Mechanisms LDAP provides a number of Root DSE attributes for discovery of protocol mechanisms identified by OIDs, including the supportedControl, supportedExtension, and supportedFeatures attributes [Models], A registry of OIDs used for discover of protocol mechanisms is provided to allow implementors and others to locate the technical specification for these protocol mechanisms. Future specifications of additional Root DSE attributes holding values identifying protocol mechanisms MAY extend this registry for their values. Protocol Mechanisms are registered on a First Come First Served basis. 3.3 LDAP Syntaxes This registry provides a listing of LDAP syntaxes [Models]. Each LDAP syntax is identified by an object identifier (OID). This registry is provided to allow implementors and others to locate the technical specification describing a particular LDAP Syntax. Zeilenga IANA Considerations for LDAP [Page 4] INTERNET-DRAFT draft-ietf-ldapbis-bcp64-06.txt 23 January 2006 LDAP Syntaxes are registered on a First Come First Served with Specification Required basis. Note: unlike object classes, attribute types and various other kinds of schema elements, descriptors are not used in LDAP to identify LDAP Syntaxes. 3.4. Object Identifier Descriptors LDAP allows short descriptive names (or descriptors) to be used instead of a numeric Object Identifier to identify select protocol extensions [Protocol], schema elements [Models], LDAP URL [LDAPURL] extensions, and other objects. While the protocol allows the same descriptor to refer to different object identifiers in certain cases and the registry supports multiple registrations of the same descriptor (each indicating a different kind of schema element and different object identifier), multiple registrations of the same descriptor are to be avoided. All such multiple registration requests require Expert Review. Descriptors are restricted to strings of UTF-8 encoded Unicode characters restricted by the following ABNF: name = keystring Descriptors are case-insensitive. Multiple names may be assigned to a given OID. For purposes of registration, an OID is to be represented in numeric OID form (e.g., 1.1.0.23.40) conforming to the ABNF: numericoid = number 1*( DOT number ) While the protocol places no maximum length restriction upon descriptors, they should be short. Descriptors longer than 48 characters may be viewed as too long to register. A value ending with a hyphen ("-") reserves all descriptors which start with that value. For example, the registration of the option "descrFamily-" reserves all options which start with "descrFamily-" for some related purpose. Descriptors beginning with "x-" are for Private Use and cannot be registered. Descriptors beginning with "e-" are reserved for experiments and will Zeilenga IANA Considerations for LDAP [Page 5] INTERNET-DRAFT draft-ietf-ldapbis-bcp64-06.txt 23 January 2006 be registered on a First Come First Served basis. All other descriptors require Expert Review to be registered. The registrant need not "own" the OID being named. The OID name space is managed by The ISO/IEC Joint Technical Committee 1 - Subcommittee 6. 3.5. AttributeDescription Options An AttributeDescription [Models] can contain zero or more options specifying additional semantics. An option SHALL be restricted to a string UTF-8 encoded Unicode characters limited by the following ABNF: option = keystring Options are case-insensitive. While the protocol places no maximum length restriction upon option strings, they should be short. Options longer than 24 characters may be viewed as too long to register. Values ending with a hyphen ("-") reserve all option names which start with the name. For example, the registration of the option "optionFamily-" reserves all options which start with "optionFamily-" for some related purpose. Options beginning with "x-" are for Private Use and cannot be registered. Options beginning with "e-" are reserved for experiments and will be registered on a First Come First Served basis. All other options require Standards Action or Expert Review with Specification Required to be registered. 3.6. LDAP Message Types Each protocol message is encapsulated in an LDAPMessage envelope [Protocol]. The protocolOp CHOICE indicates the type of message encapsulated. Each message type consists of an ASN.1 identifier in the form of a keyword and a non-negative choice number. The choice number is combined with the class (APPLICATION) and data type (CONSTRUCTED or PRIMITIVE) to construct the BER tag in the message's Zeilenga IANA Considerations for LDAP [Page 6] INTERNET-DRAFT draft-ietf-ldapbis-bcp64-06.txt 23 January 2006 encoding. The choice numbers for existing protocol messages are implicit in the protocol's ASN.1 defined in [Protocol]. New values will be registered upon Standards Action. Note: LDAP provides extensible messages which reduces, but does not eliminate, the need to add new message types. 3.7. LDAP Authentication Method The LDAP Bind operation supports multiple authentication methods [Protocol]. Each authentication choice consists of an ASN.1 identifier in the form of a keyword and a non-negative integer. The registrant SHALL classify the authentication method usage using one of the following terms: COMMON - method is appropriate for common use on the Internet, LIMITED USE - method is appropriate for limited use, OBSOLETE - method has been deprecated or otherwise found to be inappropriate for any use. Methods without publicly available specifications SHALL NOT be classified as COMMON. New registrations of class OBSOLETE cannot be registered. New authentication method integers in the range 0-1023 require Standards Action to be registered. New authentication method integers in the range 1024-4095 require Expert Review with Specification Required. New authentication method integers in the range 4096-16383 will be registered on a First Come First Served basis. Keywords associated with integers in the range 0-4095 SHALL NOT start with "e-" or "x-". Keywords associated with integers in the range 4096-16383 SHALL start with "e-". Values greater than or equal to 16384 and keywords starting with "x-" are for Private Use and cannot be registered. Note: LDAP supports Simple Authentication and Security Layers [SASL] as an authentication choice. SASL is an extensible authentication framework. 3.8. LDAP Result Codes LDAP result messages carry an resultCode enumerated value to indicate the outcome of the operation [Protocol]. Each result code consists Zeilenga IANA Considerations for LDAP [Page 7] INTERNET-DRAFT draft-ietf-ldapbis-bcp64-06.txt 23 January 2006 of a ASN.1 identifier in the form of a keyword and a non-negative integer. New resultCodes integers in the range 0-1023 require Standards Action to be registered. New resultCode integers in the range 1024-4095 require Expert Review with Specification Required. New resultCode integers in the range 4096-16383 will be registered on a First Come First Served basis. Keywords associated with integers in the range 0-4095 SHALL NOT start with "e-" or "x-". Keywords associated with integers in the range 4096-16383 SHALL start with "e-". Values greater than or equal to 16384 and keywords starting with "x-" are for Private Use and cannot be registered. 3.9. LDAP Search Scope LDAP SearchRequest messages carry a scope enumerated value to indicate the extend of search within the DIT [Protocol] Each search value consists of a ASN.1 identifier in the form of a keyword and a non-negative integer. New scope integers in the range 0-1023 require Standards Action to be registered. New scope integers in the range 1024-4095 require Expert Review with Specification Required. New scope integers in the range 4096-16383 will be registered on a First Come First Served basis. Keywords associated with integers in the range 0-4095 SHALL NOT start with "e-" or "x-". Keywords associated with integers in the range 4096-16383 SHALL start with "e-". Values greater than or equal to 16384 and keywords starting with "x-" are for Private Use and cannot be registered. 3.10. LDAP Filter Choice LDAP filters are used in making assertions against an object represented in the directory [Protocol]. The Filter CHOICE indicates a type of assertion. Each Filter CHOICE consists of an ASN.1 identifier in the form of a keyword and a non-negative choice number. The choice number is combined with the class (APPLICATION) and data type (CONSTRUCTED or PRIMITIVE) to construct the BER tag in the message's encoding. Note: LDAP provides the extensibleMatching choice which reduces, but does not eliminate, the need to add new filter choices. 3.11. LDAP ModifyRequest Operation Type Zeilenga IANA Considerations for LDAP [Page 8] INTERNET-DRAFT draft-ietf-ldapbis-bcp64-06.txt 23 January 2006 The LDAP ModifyRequest carries a sequence of modification operations [Protocol]. Each kind (e.g., add, delete, replace) of operation is consists of a ASN.1 identifier in the form of a keyword and a non-negative integer. New operation type integers in the range 0-1023 require Standards Action to be registered. New operation type integers in the range 1024-4095 require Expert Review with Specification Required. New operation type integers in the range 4096-16383 will be registered on a First Come First Served basis. Keywords associated with integers in the range 0-4095 SHALL NOT start with "e-" or "x-". Keywords associated with integers in the range 4096-16383 SHALL start with "e-". Values greater than or equal to 16384 and keywords starting with "x-" are for Private Use and cannot be registered. 3.12. LDAP authzId Prefixes Authorization Identities in LDAP are strings conforming to the production [AuthMeth]. This production is extensible. Each new specific authorization form is identified by a prefix string conforming to the following ABNF: prefix = keystring COLON COLON = %x3A ; COLON (":" U+003A) Prefixes are case-insensitive. While the protocol places no maximum length restriction upon prefix strings, they should be short. Prefixes longer than 12 characters may be viewed as too long to register. Prefixes beginning with "x-" are for Private Use and cannot be registered. Prefixes beginning with "e-" are reserved for experiments and will be registered on a First Come First Served basis. All other prefixes require Standards Action or Expert Review with Specification Required to be registered. 3.13. Directory Systems Names The IANA-maintained "Directory Systems Names" registry [IANADSN] of valid keywords for well known attributes was used in the LDAPv2 string representation of a distinguished name [RFC1779]. LDAPv2 is now Historic [RFC3494]. Zeilenga IANA Considerations for LDAP [Page 9] INTERNET-DRAFT draft-ietf-ldapbis-bcp64-06.txt 23 January 2006 Directory systems names are not known to be used in any other context. LDAPv3 [LDAPDN] uses Object Identifier Descriptors [Section 3.2] (which have a different syntax than directory system names). New Directory System Names will no longer be accepted. For historical purposes, the current list of registered names should remain publicly available. 4. Registration Procedure The procedure given here MUST be used by anyone who wishes to use a new value of a type described in Section 3 of this document. The first step is for the requester to fill out the appropriate form. Templates are provided in Appendix A. If the policy is Standards Action, the completed form SHOULD be provided to the IESG with the request for Standards Action. Upon approval of the Standards Action, the IESG SHALL forward the request (possibly revised) to IANA. The IESG SHALL be viewed as the owner of all values requiring Standards Action. If the policy is Expert Review, the requester SHALL post the completed form to the 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 . During the review, objections may be raised by anyone (including the Expert) on the list. After completion of the review, the Expert, based upon public comments, SHALL either approve the request and forward it to the 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 Director(s). The requester is viewed as the owner of values registered under Expert Review. If the policy is First Come First Served, the requester SHALL submit the completed form directly to the IANA: . The requester is viewed as the owner of values registered under First Come First Served. Neither the Expert nor IANA will take position on the claims of copyright or trademarks issues regarding completed forms. Prior to submission of the Internet Draft (I-D) to the RFC Editor but after IESG review and tentative approval, the document editor SHOULD Zeilenga IANA Considerations for LDAP [Page 10] INTERNET-DRAFT draft-ietf-ldapbis-bcp64-06.txt 23 January 2006 revise the I-D to use registered values. 5. Registration Maintenance This section discusses maintenance of registrations. 5.1. Lists of Registered Values IANA makes lists of registered values readily available to the Internet community on their web site: . 5.2. Change Control The registration owner MAY update the registration subject to the same constraints and review as with new registrations. In cases where the owner is not unable or unwilling to make necessary updates, the IESG MAY assume ownership in order to update the registration. 5.3. Comments For cases where others (anyone other than the owner) have significant objections to the claims in a registration and the owner does not agree to change the registration, comments MAY be attached to a registration upon Expert Review. For registrations owned by the IESG, the objections SHOULD be addressed by initiating a request for Expert Review. The form to these requests is ad hoc, but MUST include the specific objections to be reviewed and SHOULD contain (directly or by reference) materials supporting the objections. 6. Security Considerations The security considerations detailed in BCP 26 [RFC2434] are generally applicable to this document. Additional security considerations specific to each name space are discussed in Section 3 where appropriate. Security considerations for LDAP are discussed in documents comprising the technical specification [Roadmap]. 7. Acknowledgment Zeilenga IANA Considerations for LDAP [Page 11] INTERNET-DRAFT draft-ietf-ldapbis-bcp64-06.txt 23 January 2006 This document is a product of the IETF LDAP Revision (LDAPBIS) Working Group (WG). This document is a revision of RFC 3383, also a product of the LDAPBIS WG. This document includes text borrowed from "Guidelines for Writing an IANA Considerations Section in RFCs" [RFC2434] by Thomas Narten and Harald Alvestrand. 8. Author's Address Kurt D. Zeilenga OpenLDAP Foundation Email: Kurt@OpenLDAP.org 9. References [[Note to the RFC Editor: please replace the citation tags used in referencing Internet-Drafts with tags of the form RFCnnnn where possible.]] 9.1. Normative References [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9 (also RFC 2026), October 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14 (also RFC 2119), March 1997. [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26 (also RFC 2434), October 1998. [RFC2578] K. McCloghrie, D. Perkins, J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", RFC 2578 (STD: 58), April 1999. [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 3629 (also STD 63), November 2003. [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005. [Roadmap] Zeilenga, K. (editor), "LDAP: Technical Specification Road Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in progress. Zeilenga IANA Considerations for LDAP [Page 12] INTERNET-DRAFT draft-ietf-ldapbis-bcp64-06.txt 23 January 2006 [AuthMeth] Harrison, R. (editor), "LDAP: Authentication Methods and Connection Level Security Mechanisms", draft-ietf-ldapbis-authmeth-xx.txt, a work in progress. [Models] Zeilenga, K. (editor), "LDAP: Directory Information Models", draft-ietf-ldapbis-models-xx.txt, a work in progress. [Protocol] Sermersheim, J. (editor), "LDAP: The Protocol", draft-ietf-ldapbis-protocol-xx.txt, a work in progress. [LDAPURL] Smith, M. (editor), "LDAP: Uniform Resource Locator", draft-ietf-ldapbis-url-xx.txt, a work in progress. [Unicode] The Unicode Consortium, "The Unicode Standard, Version 3.2.0" is defined by "The Unicode Standard, Version 3.0" (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5), as amended by the "Unicode Standard Annex #27: Unicode 3.1" (http://www.unicode.org/reports/tr27/) and by the "Unicode Standard Annex #28: Unicode 3.2" (http://www.unicode.org/reports/tr28/). [X.680] International Telecommunication Union - Telecommunication Standardization Sector, "Abstract Syntax Notation One (ASN.1) - Specification of Basic Notation", X.680(2002) (also ISO/IEC 8824-1:2002). 9.2. Informative References [RFC1779] Kille, S., "A String Representation of Distinguished Names", RFC 1779, March 1995. [RFC3494] Zeilenga, K., "Lightweight Directory Access Protocol version 2 (LDAPv2) to Historic Status", RFC 3494, March 2003. [Syntaxes] Legg, S. (editor), "LDAP: Syntaxes and Matching Rules", draft-ietf-ldapbis-syntaxes-xx.txt, a work in progress. [LDAPDN] Zeilenga, K. (editor), "LDAP: String Representation of Distinguished Names", draft-ietf-ldapbis-dn-xx.txt, a work in progress. [SASL] Melnikov, A. (Editor), "Simple Authentication and Security Layer (SASL)", draft-ietf-sasl-rfc2222bis-xx.txt, a work in progress. Zeilenga IANA Considerations for LDAP [Page 13] INTERNET-DRAFT draft-ietf-ldapbis-bcp64-06.txt 23 January 2006 [IANADSN] IANA, "Directory Systems Names", http://www.iana.org/assignments/directory-system-names. Appendix A. Registration Templates This appendix provides registration templates for registering new LDAP values. Note that more than one value may be requested by extending the template by listing multiple values, or through use of tables. A.1. LDAP Object Identifier Registration Template Subject: Request for LDAP OID Registration Person & email address to contact for further information: Specification: (I-D) Author/Change Controller: Comments: (Any comments that the requester deems relevant to the request) A.2. LDAP Protocol Mechanism Registration Template Subject: Request for LDAP Protocol Mechanism Registration Object Identifier: Description: Person & email address to contact for further information: Usage: (One of Control or Extension or Feature or other) Specification: (RFC, I-D, URI) Author/Change Controller: Comments: (Any comments that the requester deems relevant to the request) Zeilenga IANA Considerations for LDAP [Page 14] INTERNET-DRAFT draft-ietf-ldapbis-bcp64-06.txt 23 January 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) A.5. LDAP Attribute Description Option Registration Template Subject: Request for LDAP Attribute Description Option Registration Option Name: Family of Options: (YES or NO) Zeilenga IANA Considerations for LDAP [Page 15] INTERNET-DRAFT draft-ietf-ldapbis-bcp64-06.txt 23 January 2006 Person & email address to contact for further information: Specification: (RFC, I-D, URI) Author/Change Controller: Comments: (Any comments that the requester deems relevant to the request) A.6. LDAP Message Type Registration Template Subject: Request for LDAP Message Type Registration LDAP Message Name: Person & email address to contact for further information: Specification: (Approved I-D) Comments: (Any comments that the requester deems relevant to the request) A.7. LDAP Authentication Method Registration Template Subject: Request for LDAP Authentication Method Registration Authentication Method Name: Person & email address to contact for further information: Specification: (RFC, I-D, URI) Intended Usage: (One of COMMON, LIMITED-USE, OBSOLETE) Author/Change Controller: Comments: (Any comments that the requester deems relevant to the request) A.8. LDAP Result Code Registration Template Subject: Request for LDAP Result Code Registration Zeilenga IANA Considerations for LDAP [Page 16] INTERNET-DRAFT draft-ietf-ldapbis-bcp64-06.txt 23 January 2006 Result Code Name: Person & email address to contact for further information: Specification: (RFC, I-D, URI) Author/Change Controller: Comments: (Any comments that the requester deems relevant to the request) A.8. LDAP Search Scope Registration Template Subject: Request for LDAP Search Scope Registration Search Scope Name: Filter Scope String: Person & email address to contact for further information: Specification: (RFC, I-D, URI) Author/Change Controller: Comments: (Any comments that the requester deems relevant to the request) A.9. LDAP Filter Choice Registration Template Subject: Request for LDAP Filter Choice Registration Filter Choice Name: Person & email address to contact for further information: Specification: (RFC, I-D, URI) Author/Change Controller: Comments: (Any comments that the requester deems relevant to the request) Zeilenga IANA Considerations for LDAP [Page 17] INTERNET-DRAFT draft-ietf-ldapbis-bcp64-06.txt 23 January 2006 A.10. LDAP ModifyRequest Operation Registration Template Subject: Request for LDAP ModifyRequest Operation Registration ModifyRequest Operation Name: Person & email address to contact for further information: Specification: (RFC, I-D, URI) Author/Change Controller: Comments: (Any comments that the requester deems relevant to the request) Appendix B. Changes since RFC 3383 This informative appendix provides a summary of changes made since RFC 3383. - Object Identifier Descriptors practices were updated to require all descriptors defined in RFCs to be registered and recommending all other descriptors (excepting those in private-use name space) be registered. Additionally, all requests for multiple registrations of the same descriptor are now subject to Expert Review. - Protocol Mechanisms practices were updated to include values of the 'supportedFeatures' attribute type. - LDAP Syntax, Search Scope, Filter Choice, ModifyRequest operation, and authzId prefixes registries were added. [[Initial values provided in Appendix C. This Appendix is to be removed by the RFC Editor before publication as an RFC.]] - References to RFCs comprising the LDAP technical specifications have been updated to latest revisions. - References to ISO 10646 have been replaced with [Unicode]. - The "Assigned Values" appendix providing initial registry values was removed. - Numerous editorial changes were made. Zeilenga IANA Considerations for LDAP [Page 18] INTERNET-DRAFT draft-ietf-ldapbis-bcp64-06.txt 23 January 2006 Appendix C. Initial Values for new registries This appendix provides initial values for new registries. C.1. LDAP Syntaxes Object Identifier Syntax Owner Reference ----------------------------- -------------------------- ----- --- 1.3.6.1.4.1.1466.115.121.1.3 Attribute Type Description IESG [Syntaxes] 1.3.6.1.4.1.1466.115.121.1.6 Bit String IESG [Syntaxes] 1.3.6.1.4.1.1466.115.121.1.7 Boolean IESG [Syntaxes] 1.3.6.1.4.1.1466.115.121.1.11 Country String IESG [Syntaxes] 1.3.6.1.4.1.1466.115.121.1.12 DN IESG [Syntaxes] 1.3.6.1.4.1.1466.115.121.1.14 Delivery Method IESG [Syntaxes] 1.3.6.1.4.1.1466.115.121.1.15 Directory String IESG [Syntaxes] 1.3.6.1.4.1.1466.115.121.1.16 DIT Content Rule Description IESG [Syntaxes] 1.3.6.1.4.1.1466.115.121.1.17 DIT Structure Rule Description IESG [Syntaxes] 1.3.6.1.4.1.1466.115.121.1.21 Enhanced Guide IESG [Syntaxes] 1.3.6.1.4.1.1466.115.121.1.22 Facsimile Telephone Number IESG [Syntaxes] 1.3.6.1.4.1.1466.115.121.1.23 Fax IESG [Syntaxes] 1.3.6.1.4.1.1466.115.121.1.24 Generalized Time IESG [Syntaxes] 1.3.6.1.4.1.1466.115.121.1.25 Guide IESG [Syntaxes] 1.3.6.1.4.1.1466.115.121.1.26 IA5 String IESG [Syntaxes] 1.3.6.1.4.1.1466.115.121.1.27 Integer IESG [Syntaxes] 1.3.6.1.4.1.1466.115.121.1.28 JPEG IESG [Syntaxes] 1.3.6.1.4.1.1466.115.121.1.30 Matching Rule Description IESG [Syntaxes] 1.3.6.1.4.1.1466.115.121.1.31 Matching Rule Use Description IESG [Syntaxes] 1.3.6.1.4.1.1466.115.121.1.34 Name And Optional UID IESG [Syntaxes] 1.3.6.1.4.1.1466.115.121.1.35 Name Form Description IESG [Syntaxes] 1.3.6.1.4.1.1466.115.121.1.36 Numeric String IESG [Syntaxes] 1.3.6.1.4.1.1466.115.121.1.37 Object Class Description IESG [Syntaxes] 1.3.6.1.4.1.1466.115.121.1.38 OID IESG [Syntaxes] 1.3.6.1.4.1.1466.115.121.1.39 Other Mailbox IESG [Syntaxes] 1.3.6.1.4.1.1466.115.121.1.40 Octet String IESG [Syntaxes] 1.3.6.1.4.1.1466.115.121.1.41 Postal Address IESG [Syntaxes] 1.3.6.1.4.1.1466.115.121.1.44 Printable String IESG [Syntaxes] 1.3.6.1.4.1.1466.115.121.1.50 Telephone Number IESG [Syntaxes] 1.3.6.1.4.1.1466.115.121.1.51 Teletex Terminal Identifier IESG [Syntaxes] 1.3.6.1.4.1.1466.115.121.1.52 Telex Number IESG [Syntaxes] 1.3.6.1.4.1.1466.115.121.1.53 UTC Time IESG [Syntaxes] 1.3.6.1.4.1.1466.115.121.1.54 LDAP Syntax Description IESG [Syntaxes] 1.3.6.1.4.1.1466.115.121.1.58 Substring Assertion IESG [Syntaxes] C.2. LDAP Search Scopes Name URLString Value Owner Reference Zeilenga IANA Considerations for LDAP [Page 19] INTERNET-DRAFT draft-ietf-ldapbis-bcp64-06.txt 23 January 2006 ---------------- --------- ----- ----- ------------------- baseObject base 0 IESG [Protocol][LDAPURL] singleLevel one 1 IESG [Protocol][LDAPURL] wholeSubtree sub 2 IESG [Protocol][LDAPURL] C.3. LDAP Filter Choices Name Value Owner Reference ---------------- ----- ----- --------- and 0 IESG [Protocol] or 1 IESG [Protocol] not 2 IESG [Protocol] equalityMatch 3 IESG [Protocol] substrings 4 IESG [Protocol] greaterOrEqual 5 IESG [Protocol] lessOrEqual 6 IESG [Protocol] present 7 IESG [Protocol] approxMatch 8 IESG [Protocol] extensibleMatch 9 IESG [Protocol] C.4. LDAP ModifyRequest Operations Name Value Owner Reference ---------------- ----- ----- --------- add 0 IESG [Protocol] delete 1 IESG [Protocol] replace 2 IESG [Protocol] C.5. LDAP authzId prefixes Name Prefix Owner Reference ---------------- ------ ----- --------- dnAuthzId dn: IESG [AuthMeth] uAuthzId u: IESG [AuthMeth] Full Copyright Copyright (C) The Internet Society (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 Zeilenga IANA Considerations for LDAP [Page 20] INTERNET-DRAFT draft-ietf-ldapbis-bcp64-06.txt 23 January 2006 "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 Rights The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Zeilenga IANA Considerations for LDAP [Page 21]