This document is obsolete. Please
refer to RFC 4520.
Network Working Group K. Zeilenga Request for Comments: 3383 OpenLDAP Foundation BCP: 64 September 2002 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 (2002). All Rights Reserved.
Abstract
This document provides procedures for registering extensible elements of the Lightweight Directory Access Protocol (LDAP). This document also provides guidelines to the Internet Assigned Numbers Authority (IANA) describing conditions under which new values can be assigned.
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 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.
A number of syntaxes in this document are described using ABNF [RFC2234]. 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 [RFC2279] encoded characters from the Universal Character Set (UCS) [ISO10646] restricted to the <keystring> production.
Zeilenga Best Current Practice [Page 2]
RFC 3383 IANA Considerations for LDAP September 2002
Numerous LDAP schema and protocol elements are identified by Object Identifiers. Specifications which assign OIDs to elements SHOULD state who delegated the OIDs for its use.
For IETF developed elements, specifications SHOULD use OIDs under "Internet Directory Numbers" (1.3.6.1.1.x). Numbers under this OID arc 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.
For elements developed by others, any properly delegated OID can be used, including those under "Internet Private Enterprise Numbers" (1.3.6.1.4.1.x) assigned by IANA <http://www.iana.org/cgi-bin/enterprise.pl>.
To avoid interoperability problems between early implementations of "works 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.
Experimental OIDs are not to used in published specifications (e.g., RFCs).
Practices for IANA assignment of Internet Enterprise and Experimental OIDs are detailed in STD 16 [RFC1155].
LDAP provides a number of Root DSE attributes for discovery of protocol mechanisms identified by OIDs, including:
- supportedControl [RFC2252] and - supportedExtension [RFC2252].
Zeilenga Best Current Practice [Page 3]
RFC 3383 IANA Considerations for LDAP September 2002
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.
OIDs associated with discoverable protocol mechanisms SHOULD be registered. These are be considered on a First Come First Served with Specification Required basis.
OIDs associated with Standard Track mechanisms MUST be registered and require Standards Action.
LDAP allows short descriptive names (or descriptors) to be used instead of a numeric Object Identifier to identify protocol extensions [RFC2251], schema elements [RFC2252], LDAP URL [RFC2255] extensions, and other objects. Descriptors are restricted to strings of UTF-8 encoded UCS 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 conforming to the ABNF:
numericoid = number *( DOT number ) ; e.g., 1.1.0.23.40
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 values ending with a hyphen ("-") reserve all descriptors which start with the 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 be registered on a First Come First Served basis.
All other descriptors require Expert Review to be registered.
Zeilenga Best Current Practice [Page 4]
RFC 3383 IANA Considerations for LDAP September 2002
The registrant need not "own" the OID being named.
The OID namespace is managed by The ISO/IEC Joint Technical Committee 1 - Subcommittee 6.
An AttributeDescription [RFC2251, Section 4.1.5] can contain zero or more options specifying additional semantics. An option SHALL be restricted to a string UTF-8 encoded UCS 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.
Each protocol message is encapsulated in an LDAPMessage envelope [RFC2251, Section 4.1.1]. The protocolOp CHOICE indicates the type of message encapsulated. Each message type consists of a keyword and a non-negative 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 [RFC2251].
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.
Zeilenga Best Current Practice [Page 5]
RFC 3383 IANA Considerations for LDAP September 2002
LDAP result messages carry an resultCode enumerated value to indicate the outcome of the operation [RFC2251, Section 4.1.10]. Each result code consists 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.
The LDAP Bind operation supports multiple authentication methods [RFC2251, Section 4.2]. Each authentication choice consists 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 SASL [RFC2222] as an Authentication CHOICE. SASL is an extensible LDAP authentication method.
Zeilenga Best Current Practice [Page 6]
RFC 3383 IANA Considerations for LDAP September 2002
The IANA-maintained "Directory Systems Names" registry [IANADSN] of valid keywords for well known attributes used in the LDAPv2 string representation of a distinguished name [RFC1779]. RFC 1779 was obsoleted by RFC 2253.
Directory systems names are not known to be used in any other context. LDAPv3 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.
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 <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 upon public comments, SHALL either approve the request and forward it to the IESG 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: <iana@iana.org>. The requester is viewed as the owner of values registered under First Come First Served.
Zeilenga Best Current Practice [Page 7]
RFC 3383 IANA Considerations for LDAP September 2002
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 revise the I-D to use registered values.
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 assert ownership in order to update the registration.
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 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.
The security considerations detailed in [RFC2434] are generally applicable to this document. Additional security considerations specific to each namespace are discussed in Section 3 where appropriate.
Security considerations for LDAP are discussed in documents comprising the technical specification [RFC3377].
Zeilenga Best Current Practice [Page 8]
RFC 3383 IANA Considerations for LDAP September 2002
This document is a product of the IETF LDAP Revision (LDAPbis) Working Group. Some text was borrowed from "Guidelines for Writing an IANA Considerations Section in RFCs" [RFC2434] by Thomas Narten and Harald Alvestrand.
[RFC1155] Rose, M. and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", STD 16, RFC 1155, May 1990.
[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.
[RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[RFC2251] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access Protocol (v3)", RFC 2251, December 1997.
[RFC2252] Wahl, M., Coulbeck, A., Howes, T. and S. Kille, "Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions", RFC 2252, December 1997.
[RFC2255] Howes, T. and M. Smith, "The LDAP URL Format", RFC 2255, December, 1997.
[RFC2256] Wahl, M., "A Summary of the X.500(96) User Schema for use with LDAPv3", RFC 2256, December 1997.
[RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access Protocol (v3): Technical Specification", RFC 3377, September 2002.
NAME Type OID [REF] ------------------------ ---- ----------------- account O 0.9.2342.19200300.100.4.5 [RFC1274] alias O 2.5.6.1 [RFC2256] aliasedEntryName A 2.5.4.1 [X.501] aliasedObjectName A 2.5.4.1 [RFC2256] altServer A 1.3.6.1.4.1.1466.101.120.6 [RFC2252] applicationEntity O 2.5.6.12 [RFC2256] applicationProcess O 2.5.6.11 [RFC2256] aRecord A 0.9.2342.19200300.100.1.26 [RFC1274] associatedDomain A 0.9.2342.19200300.100.1.37 [RFC1274] associatedInternetGateway A 1.3.6.1.4.1.453.7.2.8 [RFC2164] associatedName A 0.9.2342.19200300.100.1.38 [RFC1274] associatedORAddress A 1.3.6.1.4.1.453.7.2.6 [RFC2164] associatedX400Gateway A 1.3.6.1.4.1.453.7.2.3 [RFC2164] attributeTypes A 2.5.21.5 [RFC2252] audio A 0.9.2342.19200300.100.1.55 [RFC1274] authorityRevocationList A 2.5.4.38 [RFC2256]
Zeilenga Best Current Practice [Page 14]
RFC 3383 IANA Considerations for LDAP September 2002
bitStringMatch M 2.5.13.16 [RFC2252] buildingName A 0.9.2342.19200300.100.1.48 [RFC1274] businessCategory A 2.5.4.15 [RFC2256] C A 2.5.4.6 [RFC2256] cACertificate A 2.5.4.37 [RFC2256] calCalAdrURI A 1.2.840.113556.1.4.481 [RFC2739] calCalURI A 1.2.840.113556.1.4.478 [RFC2739] calCAPURI A 1.2.840.113556.1.4.480 [RFC2739] calEntry O 1.2.840.113556.1.5.87 [RFC2739] calFBURL A 1.2.840.113556.1.4.479 [RFC2739] calOtherCalAdrURIs A 1.2.840.113556.1.4.485 [RFC2739] calOtherCalURIs A 1.2.840.113556.1.4.482 [RFC2739] calOtherCAPURIs A 1.2.840.113556.1.4.484 [RFC2739] calOtherFBURLs A 1.2.840.113556.1.4.483 [RFC2739] caseExactIA5Match M 1.3.6.1.4.1.1466.109.114.1 [RFC2252] caseIgnoreIA5Match M 1.3.6.1.4.1.1466.109.114.2 [RFC2252] caseIgnoreListMatch M 2.5.13.11 [RFC2252] caseIgnoreMatch M 2.5.13.2 [RFC2252] caseIgnoreOrderingMatch M 2.5.13.3 [RFC2252] caseIgnoreSubstringsMatch M 2.5.13.4 [RFC2252] certificateRevocationList A 2.5.4.39 [RFC2256] certificationAuthority O 2.5.6.16 [RFC2256] certificationAuthority-V2 O 2.5.6.16.2 [RFC2256] CN A 2.5.4.3 [RFC2256] cNAMERecord A 0.9.2342.19200300.100.1.31 [RFC1274] co A 0.9.2342.19200300.100.1.43 [RFC1274] commonName A 2.5.4.3 [RFC2256] country O 2.5.6.2 [RFC2256] countryName A 2.5.4.6 [RFC2256] createTimestamp A 2.5.18.1 [RFC2252] creatorsName A 2.5.18.3 [RFC2252] cRLDistributionPoint O 2.5.6.19 [RFC2256] crossCertificatePair A 2.5.4.40 [RFC2256] DC A 0.9.2342.19200300.100.1.25 [RFC2247] dcObject O 1.3.6.1.4.1.1466.344 [RFC2247] deltaCRL O 2.5.6.23 [RFC2587] deltaRevocationList A 2.5.4.53 [RFC2256] description A 2.5.4.13 [RFC2256] destinationIndicator A 2.5.4.27 [RFC2256] device O 2.5.6.14 [RFC2256] distinguishedName A 2.5.4.49 [RFC2256] distinguishedNameMatch M 2.5.13.1 [RFC2252] distinguishedNameTableEntry O 1.3.6.1.4.1.453.7.1.5 [RFC2293] distinguishedNameTableKey A 1.3.6.1.4.1.453.7.2.3 [RFC2293] dITContentRules A 2.5.21.2 [RFC2252] dITRedirect A 0.9.2342.19200300.100.1.54 [RFC1274] dITStructureRules A 2.5.21.1 [RFC2252] dmd O 2.5.6.20 [RFC2256]
Zeilenga Best Current Practice [Page 15]
RFC 3383 IANA Considerations for LDAP September 2002
dmdName A 2.5.4.54 [RFC2256] dnQualifier A 2.5.4.46 [RFC2256] dNSDomain O 0.9.2342.19200300.100.4.15 [RFC1274] document O 0.9.2342.19200300.100.4.6 [RFC1274] documentAuthor A 0.9.2342.19200300.100.1.14 [RFC1274] documentIdentifier A 0.9.2342.19200300.100.1.11 [RFC1274] documentLocation A 0.9.2342.19200300.100.1.15 [RFC1274] documentPublisher A 0.9.2342.19200300.100.1.56 [RFC1274] documentSeries O 0.9.2342.19200300.100.4.8 [RFC1274] documentTitle A 0.9.2342.19200300.100.1.12 [RFC1274] documentVersion A 0.9.2342.19200300.100.1.13 [RFC1274] domain O 0.9.2342.19200300.100.4.13 [RFC2247] domainComponent A 0.9.2342.19200300.100.1.25 [RFC2247] domainNameForm N 1.3.6.1.4.1.1466.345 [RFC2247] domainRelatedObject O 0.9.2342.19200300.100.4.17 [RFC1274] drink A 0.9.2342.19200300.100.1.5 [RFC1274] dSA O 2.5.6.13 [RFC2256] dSAQuality A 0.9.2342.19200300.100.1.49 [RFC1274] dynamicObject O 1.3.6.1.4.1.1466.101.119.2 [RFC2589] dynamicSubtrees A 1.3.6.1.4.1.1466.101.119.4 [RFC2589] enhancedSearchGuide A 2.5.4.47 [RFC2256] entryTtl A 1.3.6.1.4.1.1466.101.119.3 [RFC2589] extensibleObject O 1.3.6.1.4.1.1466.101.120.111 [RFC2252] facsimileTelephoneNumber A 2.5.4.23 [RFC2256] favouriteDrink A 0.9.2342.19200300.100.1.5 [RFC1274] friendlyCountry O 0.9.2342.19200300.100.4.18 [RFC1274] friendlyCountryName A 0.9.2342.19200300.100.1.43 [RFC1274] generalizedTimeMatch M 2.5.13.27 [RFC2252] generalizedTimeOrderingMatch M 2.5.13.28 [RFC2252] generationQualifier A 2.5.4.44 [RFC2256] givenName A 2.5.4.42 [RFC2256] GN A 2.5.4.42 [RFC2256] groupOfNames O 2.5.6.9 [RFC2256] groupOfUniqueNames O 2.5.6.17 [RFC2256] homePhone A 0.9.2342.19200300.100.1.20 [RFC1274] homePostalAddress A 0.9.2342.19200300.100.1.39 [RFC1274] homeTelephone A 0.9.2342.19200300.100.1.20 [RFC1274] host A 0.9.2342.19200300.100.1.9 [RFC1274] houseIdentifier A 2.5.4.51 [RFC2256] info A 0.9.2342.19200300.100.1.4 [RFC1274] initials A 2.5.4.43 [RFC2256] integerFirstComponentMatch M 2.5.13.29 [RFC2252] integerMatch M 2.5.13.14 [RFC2252] internationaliSDNNumber A 2.5.4.25 [RFC2256] janetMailbox A 0.9.2342.19200300.100.1.46 [RFC1274] jpegPhoto A 0.9.2342.19200300.100.1.60 [RFC1488] knowledgeInformation A 2.5.4.2 [RFC2256] L A 2.5.4.7 [RFC2256]
Zeilenga Best Current Practice [Page 16]
RFC 3383 IANA Considerations for LDAP September 2002
labeledURI A 1.3.6.1.4.1.250.1.57 [RFC2079] labeledURIObject A 1.3.6.1.4.1.250.3.15 [RFC2079] lastModifiedBy A 0.9.2342.19200300.100.1.24 [RFC1274] lastModifiedTime A 0.9.2342.19200300.100.1.23 [RFC1274] ldapSyntaxes A 1.3.6.1.4.1.1466.101.120.16 [RFC2252] locality O 2.5.6.3 [RFC2256] localityName A 2.5.4.7 [RFC2256] mail A 0.9.2342.19200300.100.1.3 [RFC2798] mailPreferenceOption A 0.9.2342.19200300.100.1.47 [RFC1274] manager A 0.9.2342.19200300.100.1.10 [RFC1274] matchingRules A 2.5.21.4 [RFC2252] matchingRuleUse A 2.5.21.8 [RFC2252] mcgamTables A 1.3.6.1.4.1.453.7.2.9 [RFC2164] mDRecord A 0.9.2342.19200300.100.1.27 [RFC1274] member A 2.5.4.31 [RFC2256] mixerGateway O 1.3.6.1.4.1.453.7.1.4 [RFC2164] mobile A 0.9.2342.19200300.100.1.41 [RFC1274] mobileTelephoneNumber A 0.9.2342.19200300.100.1.41 [RFC1274] modifiersName A 2.5.18.4 [RFC2252] modifyTimestamp A 2.5.18.2 [RFC2252] mXRecord A 0.9.2342.19200300.100.1.28 [RFC1274] name A 2.5.4.41 [RFC2256] nameForms A 2.5.21.7 [RFC2252] namingContexts A 1.3.6.1.4.1.1466.101.120.5 [RFC2252] nSRecord A 0.9.2342.19200300.100.1.29 [RFC1274] numericStringMatch M 2.5.13.8 [RFC2252] numericStringSubstringsMatch M 2.5.13.10 [RFC2252] O A 2.5.4.10 [RFC2256] objectClass A 2.5.4.0 [RFC2256] objectClasses A 2.5.21.6 [RFC2252] objectIdentifierFirstComponentMatch M 2.5.13.30 [RFC2252] objectIdentifiersMatch M 2.5.13.0 [RFC2252] octetStringMatch M 2.5.13.17 [RFC2252] omittedORAddressComponent O 1.3.6.1.4.1.453.7.1.3 [RFC2164] oRAddressComponentType A 1.3.6.1.4.1.453.7.2.7 [RFC2164] organization O 2.5.6.4 [RFC2256] organizationalPerson O 2.5.6.7 [RFC2256] organizationalRole O 2.5.6.8 [RFC2256] organizationalStatus A 0.9.2342.19200300.100.1.45 [RFC1274] organizationalUnit O 2.5.6.5 [RFC2256] organizationalUnitName A 2.5.4.11 [RFC2256] organizationName A 2.5.4.10 [RFC2256] otherMailbox A 0.9.2342.19200300.100.1.22 [RFC1274] OU A 2.5.4.11 [RFC2256] owner A 2.5.4.32 [RFC2256] pager A 0.9.2342.19200300.100.1.42 [RFC1274] pagerTelephoneNumber A 0.9.2342.19200300.100.1.42 [RFC1274] person O 2.5.6.6 [RFC2256]
Zeilenga Best Current Practice [Page 17]
RFC 3383 IANA Considerations for LDAP September 2002
personalSignature A 0.9.2342.19200300.100.1.53 [RFC1274] personalTitle A 0.9.2342.19200300.100.1.40 [RFC1274] photo A 0.9.2342.19200300.100.1.7 [RFC1274] physicalDeliveryOfficeName A 2.5.4.19 [RFC2256] pilotDSA O 0.9.2342.19200300.100.4.21 [RFC1274] pilotObject O 0.9.2342.19200300.100.4.3 [RFC1274] pilotOrganization O 0.9.2342.19200300.100.4.20 [RFC1274] pilotPerson O 0.9.2342.19200300.100.4.4 [RFC1274] pkiCA O 2.5.6.22 [RFC2587] pkiUser O 2.5.6.21 [RFC2587] postalAddress A 2.5.4.16 [RFC2256] postalCode A 2.5.4.17 [RFC2256] postOfficeBox A 2.5.4.18 [RFC2256] preferredDeliveryMethod A 2.5.4.28 [RFC2256] presentationAddress A 2.5.4.29 [RFC2256] presentationAddressMatch M 2.5.13.22 [RFC2252] protocolInformation A 2.5.4.48 [RFC2256] protocolInformationMatch M 2.5.13.24 [RFC2252] qualityLabelledData O 0.9.2342.19200300.100.4.22 [RFC1274] ref A 2.16.840.1.113730.3.1.34 [RFC3296] referral 0 2.16.840.1.113730.3.2.6 [RFC3296] registeredAddress A 2.5.4.26 [RFC2256] residentialPerson O 2.5.6.10 [RFC2256] RFC822LocalPart O 0.9.2342.19200300.100.4.14 [RFC1274] RFC822Mailbox A 0.9.2342.19200300.100.1.3 [RFC1274] rFC822ToX400Mapping O 1.3.6.1.4.1.453.7.1.1 [RFC2164] roleOccupant A 2.5.4.33 [RFC2256] room O 0.9.2342.19200300.100.4.7 [RFC1274] roomNumber A 0.9.2342.19200300.100.1.6 [RFC1274] searchGuide A 2.5.4.14 [RFC2256] secretary A 0.9.2342.19200300.100.1.21 [RFC1274] seeAlso A 2.5.4.34 [RFC2256] serialNumber A 2.5.4.5 [RFC2256] simpleSecurityObject O 0.9.2342.19200300.100.4.19 [RFC1274] singleLevelQuality A 0.9.2342.19200300.100.1.50 [RFC1274] SN A 2.5.4.4 [RFC2256] sOARecord A 0.9.2342.19200300.100.1.30 [RFC1274] ST A 2.5.4.8 [RFC2256] stateOrProvinceName A 2.5.4.8 [RFC2256] street A 2.5.4.9 [RFC2256] streetAddress A 2.5.4.9 [RFC2256] strongAuthenticationUser O 2.5.6.15 [RFC2256] subschema O 2.5.20.1 [RFC2252] subschemaSubentry A 2.5.18.10 [RFC2252] subtree O 1.3.6.1.4.1.453.7.1.1 [RFC2293] subtreeMaximumQuality A 0.9.2342.19200300.100.1.52 [RFC1274] subtreeMinimumQuality A 0.9.2342.19200300.100.1.51 [RFC1274] supportedAlgorithms A 2.5.4.52 [RFC2256]
Zeilenga Best Current Practice [Page 18]
RFC 3383 IANA Considerations for LDAP September 2002
supportedApplicationContext A 2.5.4.30 [RFC2256] supportedControl A 1.3.6.1.4.1.1466.101.120.13 [RFC2252] supportedExtension A 1.3.6.1.4.1.1466.101.120.7 [RFC2252] supportedLDAPVersion A 1.3.6.1.4.1.1466.101.120.15 [RFC2252] supportedSASLMechanisms A 1.3.6.1.4.1.1466.101.120.14 [RFC2252] surname A 2.5.4.4 [RFC2256] table O 1.3.6.1.4.1.453.7.1.2 [RFC2293] tableEntry O 1.3.6.1.4.1.453.7.1.3 [RFC2293] telephoneNumber A 2.5.4.20 [RFC2256] telephoneNumberMatch M 2.5.13.20 [RFC2252] telephoneNumberSubstringsMatch M 2.5.13.21 [RFC2252] teletexTerminalIdentifier A 2.5.4.22 [RFC2256] telexNumber A 2.5.4.21 [RFC2256] textEncodedORAddress A 0.9.2342.19200300.100.1.2 [RFC1274] textTableEntry O 1.3.6.1.4.1.453.7.1.4 [RFC2293] textTableKey A 1.3.6.1.4.1.453.7.2.1 [RFC2293] textTableValue A 1.3.6.1.4.1.453.7.2.2 [RFC2293] title A 2.5.4.12 [RFC2256] top O 2.5.6.0 [RFC2256] uid A 0.9.2342.19200300.100.1.1 [RFC2253] uniqueIdentifier A 0.9.2342.19200300.100.1.44 [RFC1274] uniqueMember A 2.5.4.50 [RFC2256] uniqueMemberMatch M 2.5.13.23 [RFC2252] userCertificate A 2.5.4.36 [RFC2256] userClass A 0.9.2342.19200300.100.1.8 [RFC1274] userId A 0.9.2342.19200300.100.1.1 [RFC1274] userPassword A 2.5.4.35 [RFC2256] userSecurityInformation O 2.5.6.18 [RFC2256] x121Address A 2.5.4.24 [RFC2256] x400ToRFC822Mapping O 1.3.6.1.4.1.453.7.1.2 [RFC2164] x500UniqueIdentifier A 2.5.4.45 [RFC2256]
Legend ------------------------ A => Attribute Type C => DIT Content Rule E => LDAP URL Extension M => Matching Rule N => Name Form O => Object Class
Zeilenga Best Current Practice [Page 19]
RFC 3383 IANA Considerations for LDAP September 2002
* These LDAPv2-only mechanisms were deprecated in favor of the LDAPv3 SASL authentication method, specifically the GSSAPI mechanism.
Author's Address
Kurt D. Zeilenga OpenLDAP Foundation
EMail: Kurt@OpenLDAP.org
Zeilenga Best Current Practice [Page 22]
RFC 3383 IANA Considerations for LDAP September 2002
Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the Internet Society.