RFC 4510

Lightweight Directory Access Protocol (LDAP): Technical Specification Road Map

📅 published June 2006, from ietf

Lightweight Directory Access Protocol (LDAP): Technical Specification Road Map 🦋

  • Request for Comments: 4510
  • Author: K. Zeilenga, Ed. (OpenLDAP Foundation) 💅
  • Date: June 2006 📅
  • Category: Standards Track 🎀
  • Obsoletes: RFC 2251, 2252, 2253, 2254, 2255, 2256, 2829, 2830, 3377, 3771 💀
  • Updates: none listed

Status of This Memo ✨

okay so this document is an Internet standards track protocol doc for the whole Internet community, and it's literally asking everyone for discussion and suggestions 🫶 For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). And distribution is unlimited, so share the tea 🍓

Copyright (C) The Internet Society (2006).

Abstract 🔮

LDAP (the Lightweight Directory Access Protocol) is an Internet protocol for getting into distributed directory services that play by the X.500 data and service models, and this doc is basically the road map for the whole LDAP Technical Specification 🗺️✨

1. The LDAP Technical Specification 👑

so the technical spec for version 3 of LDAP (yes, it's an Internet Protocol 💖) is made up of this document plus these bestie docs:

  • LDAP: The Protocol [RFC4511]
  • LDAP: Directory Information Models [RFC4512]
  • LDAP: Authentication Methods and Security Mechanisms [RFC4513]
  • LDAP: String Representation of Distinguished Names [RFC4514]
  • LDAP: String Representation of Search Filters [RFC4515]
  • LDAP: Uniform Resource Locator [RFC4516]
  • LDAP: Syntaxes and Matching Rules [RFC4517]
  • LDAP: Internationalized String Preparation [RFC4518]
  • LDAP: Schema for User Applications [RFC4519]

people casually say "LDAP" and "LDAPv3" to mean the protocol this spec describes 🧚 but if you're writing other docs, the LDAP suite should be formally identified by a normative reference to this document. that's the proper way to name-drop it 💅

LDAP is extensible 🌈 Extensions can be specified in other documents. This document doesn't define the naming for LDAP-plus-extensions combos, but that may be defined in some future document(s). Extensions are expected to be truly optional ✨ The considerations for LDAP extensions in BCP 118, RFC 4521 [RFC4521] fully apply to this revision of the LDAP Technical Specification, so go read those too 🫶

IANA (Internet Assigned Numbers Authority) considerations for LDAP are in BCP 64, RFC 4520 [RFC4520], and they apply fully to this revision of the LDAP technical specification 🎀

1.1. Conventions 🎯

the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be read as described in BCP 14 [RFC2119]. these are the capital-letter words that carry real weight, so don't mess with them 😤

2. Relationship to X.500 🌐

this technical specification defines LDAP in terms of [X.500] as an X.500 access mechanism, so it's giving X.500 vibes all the way 💜 An LDAP server MUST act in accordance with the X.500 (1993) series of International Telecommunication Union - Telecommunication Standardization (ITU-T) Recommendations when it's providing the service. but it is not required that an LDAP server use any X.500 protocols to do that 🙈 For example, LDAP can be mapped onto any other directory system, as long as the X.500 data and service models [X.501][X.511], as used in LDAP, aren't violated in the LDAP interface. no cap, that's the only real rule 🔥

this spec explicitly pulls in portions of X.500(93). Later revisions of X.500 do not automatically apply to this technical specification, so don't assume they do 🛑

3. Relationship to Obsolete Specifications 🗂️

this technical specification (as defined in Section 1) completely obsoletes the earlier LDAP technical specification from RFC 3377, which consisted of RFCs 2251-2256, 2829, 2830, 3771, and 3377 itself 🧹 It was significantly reorganized, so it's a whole glow-up ✨

this document replaces RFC 3377, plus Section 3.3 of RFC 2251. And here's the breakdown:

[RFC4518] is brand new to this revision 🆕

every document in this spec has appendices summarizing the changes to all the sections it replaces. Appendix A.1 covers what changed from RFC 3377, and Appendix A.2 covers what changed from Section 3.3 of RFC 2251 📝

on top of that, parts of this technical specification update and/or replace a bunch of other documents that aren't listed above. Those relationships are explained in the docs covering those specific parts 🦋

4. Security Considerations 🔐

LDAP security considerations are discussed in each document that makes up the technical specification. so check every single one, because security is not the place to be lazy 💀🔥

5. Acknowledgements 🫶

this document is based largely on RFC 3377 by J. Hodges and R. Morgan, a product of the LDAPBIS and LDAPEXT Working Groups 🌸 It also borrows from RFC 2251 by M. Wahl, T. Howes, and S. Kille, a product of the ASID Working Group 💖

and yes, this document is a product of the IETF LDAPBIS Working Group 👑

6. Normative References 📚

  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [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.
  • [RFC4514] Zeilenga, K., Ed., "Lightweight Directory Access Protocol (LDAP): String Representation of Distinguished Names", RFC 4514, June 2006.
  • [RFC4515] Smith, M., Ed. and T. Howes, "Lightweight Directory Access Protocol (LDAP): String Representation of Search Filters", RFC 4515, June 2006.
  • [RFC4516] Smith, M., Ed. and T. Howes, "Lightweight Directory Access Protocol (LDAP): Uniform Resource Locator", RFC 4516, June 2006.
  • [RFC4517] Legg, S., Ed., "Lightweight Directory Access Protocol (LDAP): Syntaxes and Matching Rules", RFC 4517, June 2006.
  • [RFC4518] Zeilenga, K., "Lightweight Directory Access Protocol (LDAP): Internationalized String Preparation", RFC 4518, June 2006.
  • [RFC4519] Sciberras, A., Ed., "Lightweight Directory Access Protocol (LDAP): Schema for User Applications", RFC 4519, June 2006.
  • [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access Protocol (LDAP)", BCP 64, RFC 4520, June 2006.
  • [RFC4521] Zeilenga, K., "Considerations for LDAP Extensions", BCP 118, RFC 4521, June 2006.
  • [X.500] International Telecommunication Union - Telecommunication Standardization Sector, "The Directory -- Overview of concepts, models and services", X.500(1993) (also ISO/IEC 9594-1:1994).
  • [X.501] International Telecommunication Union - Telecommunication Standardization Sector, "The Directory -- Models", X.501(1993) (also ISO/IEC 9594-2:1994).
  • [X.511] International Telecommunication Union - Telecommunication Standardization Sector, "The Directory: Abstract Service Definition", X.511(1993) (also ISO/IEC 9594-3:1993).

Appendix A. Changes to Previous Documents 🎀

this appendix lays out what this document changes compared to the documents it replaces, whether in whole or in part 📝

A.1. Changes to RFC 3377 💅

this document is almost a complete rewrite of RFC 3377, since a lot of that material no longer applies 🧹 The changes include redefining the terms "LDAP" and "LDAPv3" so they refer to this revision of the technical specification.

A.2. Changes to Section 3.3 of RFC 2251 ✨

this section got a slight edit: the word "document" was swapped for "technical specification." That makes it clear the section applies to the entire LDAP technical specification 🫶

Author's Address 📮

Kurt D. Zeilenga OpenLDAP Foundation

EMail: Kurt@OpenLDAP.org

Copyright (C) The Internet Society (2006).

this document is subject to the rights, licenses and restrictions in BCP 78, and except as set out there, the authors keep all their rights.

this document and the information in it 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 on the validity or scope of any Intellectual Property Rights or other rights that might be claimed to cover the implementation or use of the technology in this document, or on whether any license under those rights might or might not be available. it also doesn't claim to have made any independent effort to find those rights. info about how RFC documents handle rights is in BCP 78 and BCP 79 📖

copies of IPR disclosures sent to the IETF Secretariat, any assurances of licenses to be made available, or the results of an attempt to get a general license or permission for implementers or users to use those proprietary rights can be found in 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, patent applications, or other proprietary rights that may cover technology needed to implement this standard. send that info to ietf-ipr@ietf.org 📬

Acknowledgement 🌷

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

📦 where this page comes from