Net::LDAP::RFC(3)

📦
version 0.68 · 10 versions
, in opensuse-leap 16.0

💖 Net::LDAP::RFC(3) — User Contributed Perl Documentation 💖

okay bestie, this is the Net::LDAP::RFC(3) page from the User Contributed Perl Documentation, and it's literally a list of related RFCs. It's part 1 of 6, so buckle up 💅✨

🌸 NAME 🌸

Net::LDAP::RFC - List of related RFCs

🦋 SYNOPSIS 🦋

There is no synopsis, bestie. It literally says:

  none

✨ DESCRIPTION ✨

The LDAP protocol is defined in the following RFCs, no cap:

👑 Core LDAP Specification 👑

These are the core LDAP docs. Main-character energy only 👑

🎀 RFC-4510 Lightweight Directory Access Protocol (LDAP): Technical Specification Road Map 🎀

Link: http://www.ietf.org/rfc/rfc4510.txt

So LDAP is an Internet protocol for accessing distributed directory services that act in accordance with X.500 data and service models, and this document gives you the road map of the LDAP Technical Specification. Iconic.

🎀 RFC-4511 Lightweight Directory Access Protocol (LDAP): The Protocol 🎀

Link: http://www.ietf.org/rfc/rfc4511.txt

This one describes the protocol elements of LDAP, plus their semantics and encodings. LDAP provides access to distributed directory services that act in accordance with X.500 data and service models. These protocol elements are based on those described in the X.500 Directory Access Protocol (DAP). Periodt.

🎀 RFC-4512 Lightweight Directory Access Protocol (LDAP): Directory Information Models 🎀

Link: http://www.ietf.org/rfc/rfc4512.txt

LDAP is an Internet protocol for accessing distributed directory services that act in accordance with X.500 data and service models, and this doc describes the X.500 Directory Information Models as used in LDAP. Slay.

🎀 RFC-4513 Lightweight Directory Access Protocol (LDAP): Authentication Methods and Security Mechanisms 🎀

Link: http://www.ietf.org/rfc/rfc4513.txt

This one describes authentication methods and security mechanisms of LDAP. It details establishment of Transport Layer Security (TLS) using the StartTLS operation.

It also details the simple Bind authentication method, including anonymous, unauthenticated, and name/password mechanisms, plus the Simple Authentication and Security Layer (SASL) Bind authentication method, including the EXTERNAL mechanism.

It discusses various authentication and authorization states through which a session to an LDAP server may pass, and the actions that trigger these state changes. Very much a glow-up journey 💅

🎀 RFC-4514 Lightweight Directory Access Protocol (LDAP): String Representation of Distinguished Names 🎀

Link: http://www.ietf.org/rfc/rfc4514.txt

The X.500 Directory uses distinguished names (DNs) as primary keys to entries in the directory. This document defines the string representation used in LDAP to transfer distinguished names. The string representation is designed to give a clean representation of commonly used distinguished names, while still being able to represent any distinguished name. Versatile queen 👑

🎀 RFC-4515 Lightweight Directory Access Protocol (LDAP): String Representation of Search Filters 🎀

Link: http://www.ietf.org/rfc/rfc4515.txt

LDAP search filters are transmitted in the LDAP protocol using a binary representation that is appropriate for use on the network. This document defines a human-readable string representation of LDAP search filters that is appropriate for use in LDAP URLs (RFC 4516) and in other applications. Cute and useful 🎀

🎀 RFC-4516 Lightweight Directory Access Protocol (LDAP): Uniform Resource Locator 🎀

Link: http://www.ietf.org/rfc/rfc4516.txt

This describes a format for an LDAP Uniform Resource Locator (URL). An LDAP URL describes an LDAP search operation that is used to retrieve information from an LDAP directory, or, in the context of an LDAP referral or reference, an LDAP URL describes a service where an LDAP operation may be progressed. URL lore fr fr 🌐

🎀 RFC-4517 Lightweight Directory Access Protocol (LDAP): Syntaxes and Matching Rules 🎀

Link: http://www.ietf.org/rfc/rfc4517.txt

Each attribute stored in an LDAP directory, whose values may be transferred in the LDAP protocol, has a defined syntax that constrains the structure and format of its values. The comparison semantics for values of a syntax are not part of the syntax definition; instead they are provided through separately defined matching rules. Matching rules specify an argument, an assertion value, which also has a defined syntax. This document defines a base set of syntaxes and matching rules for use in defining attributes for LDAP directories. Big rules energy, but make it directory 💅

🎀 RFC-4518 Lightweight Directory Access Protocol (LDAP): Internationalized String Preparation 🎀

Link: http://www.ietf.org/rfc/rfc4518.txt

The previous LDAP technical specifications did not precisely define how character string matching is to be performed. That led to a number of usability and interoperability problems. This document defines string preparation algorithms for character-based matching rules defined for use in LDAP. Not me learning about past interoperability drama 😭

🎀 RFC-4519 Lightweight Directory Access Protocol (LDAP): Schema for User Applications 🎀

Link: http://www.ietf.org/rfc/rfc4519.txt

This document is an integral part of the LDAP technical specification. It provides a technical specification of attribute types and object classes intended for use by LDAP directory clients for many directory services, such as White Pages. These objects are widely used as a basis for the schema in many LDAP directories. This document does not cover attributes used for the administration of directory servers, nor does it include directory objects defined for specific uses in other documents. Boundaries, bestie ✨

These are the other LDAP-related RFCs in the Proposed Standards category. Keep the vibe, keep the facts 🫶

💜 RFC-6171 The Lightweight Directory Access Protocol (LDAP) Don't Use Copy Control 💜

Link: http://www.ietf.org/rfc/rfc6171.txt

This defines the LDAP Don't Use Copy control extension, which allows a client to specify that copied information should not be used in providing service. This control is based upon the X.511 dontUseCopy service control option. No copy, no problem 💅

💜 RFC-5020 The Lightweight Directory Access Protocol (LDAP) entryDN Operational Attribute 💜

Link: http://www.ietf.org/rfc/rfc5020.txt

This describes the LDAP/X.500 'entryDN' operational attribute. The attribute provides a copy of the entry's distinguished name for use in attribute value assertions. Little DN copy, very iconic.

💜 RFC-4792 Encoding Instructions for the Generic String Encoding Rules (GSER) 💜

Link: http://www.ietf.org/rfc/rfc4792.txt

Abstract Syntax Notation One (ASN.1) defines a general framework for annotating types in an ASN.1 specification with encoding instructions that alter how values of those types are encoded according to ASN.1 encoding rules. This document defines the supporting notation for encoding instructions that apply to the Generic String Encoding Rules (GSER), and in particular defines an encoding instruction to provide a machine-processable representation for the declaration of a GSER ChoiceOfStrings type. ASN.1 said let there be annotations ✨

💜 RFC-4532 Lightweight Directory Access Protocol (LDAP) Who am I? Operation 💜

Link: http://www.ietf.org/rfc/rfc4532.txt

This specification provides a mechanism for LDAP clients to obtain the authorization identity the server has associated with the user or application entity. This mechanism is specified as an LDAP extended operation called the LDAP "Who am I?" operation. Identity check, but make it protocol 🔥

💜 RFC-4530 Lightweight Directory Access Protocol (LDAP) entryUUID Operational Attribute 💜

Link: http://www.ietf.org/rfc/rfc4530.txt

This describes the LDAP/X.500 'entryUUID' operational attribute and associated matching rules and syntax. The attribute holds a server-assigned Universally Unique Identifier (UUID) for the object. Directory clients may use this attribute to distinguish objects identified by a distinguished name or to locate an object after renaming. UUID slay 🦋

💜 RFC-4528 Lightweight Directory Access Protocol (LDAP) Assertion Control 💜

Link: http://www.ietf.org/rfc/rfc4528.txt

This defines the LDAP Assertion Control, which allows a client to specify that a directory operation should only be processed if an assertion applied to the target entry of the operation is true. It can be used to construct "test and set", "test and clear", and other conditional operations. Conditional operations are lowkey a vibe.

💜 RFC-4527 Lightweight Directory Access Protocol (LDAP) Read Entry Controls 💜

Link: http://www.ietf.org/rfc/rfc4527.txt

This specifies an extension to LDAP to allow the client to read the target entry of an update operation. The client may request to read the entry before and/or after the modifications are applied. These reads are done as an atomic part of the update operation. Atomic reads, we love to see it 🫶

💜 RFC-4526 Lightweight Directory Access Protocol (LDAP) Absolute True and False Filters 💜

Link: http://www.ietf.org/rfc/rfc4526.txt

This extends LDAP to support absolute True and False filters based upon similar capabilities found in X.500 directory systems. The document also extends the String Representation of LDAP Search Filters to support these filters. True or False, no in-between 💀

💜 RFC-4524 COSINE LDAP/X.500 Schema 💜

Link: http://www.ietf.org/rfc/rfc4524.txt

This provides a collection of schema elements for use with LDAP from the COSINE and Internet X.500 pilot projects. Schema collection unlocked 🌸

💜 RFC-4523 Lightweight Directory Access Protocol (LDAP) Schema Definitions for X.509 Certificates 💜

Link: http://www.ietf.org/rfc/rfc4523.txt

This describes schema for representing X.509 certificates, X.521 security information, and related elements in directories accessible using LDAP. The LDAP definitions for these X.509 and X.521 schema elements replace those provided in RFCs 2252 and 2256. Out with the old, in with the schema 💅

💜 RFC-4522 Lightweight Directory Access Protocol (LDAP): The Binary Encoding Option 💜

Link: http://www.ietf.org/rfc/rfc4522.txt

Each attribute stored in an LDAP directory has a defined syntax (i.e., data type). A syntax definition specifies how attribute values conforming to the syntax are normally represented when transferred in LDAP operations. This representation is referred to as the LDAP-specific encoding, to distinguish it from other methods of encoding attribute values. This document defines an attribute option, the binary option, that can be used to specify that the associated attribute values are instead encoded according to the Basic Encoding Rules (BER) used by X.500 directories. Binary option said alternate encoding era 💀✨

💜 RFC-4370 Lightweight Directory Access Protocol (LDAP) Proxied Authorization Control 💜

Link: http://www.ietf.org/rfc/rfc4370.txt

This document defines the Lightweight Directory Access Protocol (LDAP) Proxy Authorization Control. The Proxy Authorization Control allows a client to request that an operation be processed under a provided authorization identity instead of under the current authorization identity associated with the connection. yes bestie you read that right — you get to say "do this as them" 💅

RFC-4104 Policy Core Extension Lightweight Directory Access Protocol Schema (PCELS)

http://www.ietf.org/rfc/rfc4104.txt

This document defines a number of changes and extensions to the Policy Core Lightweight Directory Access Protocol (LDAP) Schema (RFC 3703) based on the model extensions defined by the Policy Core Information Model (PCIM) Extensions (RFC 3460). These changes and extensions consist of new LDAP object classes and attribute types. Some of the schema items defined in this document re-implement existing concepts in accordance with their new semantics introduced by RFC 3460. The other schema items implement new concepts, not covered by RFC 3703. This document updates RFC 3703. so it's a glow-up and a soft reboot of the policy schema — iconic behavior honestly ✨

RFC-3928 Lightweight Directory Access Protocol (LDAP) Client Update Protocol (LCUP)

http://www.ietf.org/rfc/rfc3928.txt

This document defines the Lightweight Directory Access Protocol (LDAP) Client Update Protocol (LCUP). The protocol is intended to allow an LDAP client to synchronize with the content of a directory information tree (DIT) stored by an LDAP server and to be notified about the changes to that content. sync + push notifs for your directory, lowkey ahead of its time 🦋

RFC-3909 Lightweight Directory Access Protocol (LDAP) Cancel Operation

http://www.ietf.org/rfc/rfc3909.txt

This specification describes a Lightweight Directory Access Protocol (LDAP) extended operation to cancel (or abandon) an outstanding operation. Unlike the LDAP Abandon operation, but like the X.511 Directory Access Protocol (DAP) Abandon operation, this operation has a response which provides an indication of its outcome. so you actually get to hear back whether it worked — character development fr 💀

RFC-3876 Returning Matched Values with the Lightweight Directory Access Protocol version 3 (LDAPv3)

http://www.ietf.org/rfc/rfc3876.txt

This document describes a control for the Lightweight Directory Access Protocol version 3 that is used to return a subset of attribute values from an entry. Specifically, only those values that match a "values return" filter. Without support for this control, a client must retrieve all of an attribute's values and search for specific values locally. server-side filtering instead of dragging the whole attribute home in your tote bag — we love efficiency 🎀

RFC-3866 Language Tags and Ranges in the Lightweight Directory Access Protocol (LDAP)

http://www.ietf.org/rfc/rfc3866.txt

It is often desirable to be able to indicate the natural language associated with values held in a directory and to be able to query the directory for values which fulfill the user's language needs. This document details the use of Language Tags and Ranges in the Lightweight Directory Access Protocol (LDAP). multilingual directory era 🌈

RFC-3727 ASN.1 Module Definition for the LDAP and X.500 Component Matching Rules

http://www.ietf.org/rfc/rfc3727.txt

This document updates the specification of the component matching rules for Lightweight Directory Access Protocol (LDAP) and X.500 directories (RFC3687) by collecting the Abstract Syntax Notation One (ASN.1) definitions of the component matching rules into an appropriately identified ASN.1 module so that other specifications may reference the component matching rule definitions from within their own ASN.1 modules. it's giving "put the definitions in a labeled box so everyone else can borrow them" — tidy queen behavior 🧚

RFC-3703 Policy Core Lightweight Directory Access Protocol (LDAP) Schema

http://www.ietf.org/rfc/rfc3703.txt

This document defines a mapping of the Policy Core Information Model to a form that can be implemented in a directory that uses Lightweight Directory Access Protocol (LDAP) as its access protocol. This model defines two hierarchies of object classes: structural classes representing information for representing and controlling policy data as specified in RFC 3060, and relationship classes that indicate how instances of the structural classes are related to each other. Classes are also added to the LDAP schema to improve the performance of a client's interactions with an LDAP server when the client is retrieving large amounts of policy-related information. These classes exist only to optimize LDAP retrievals: there are no classes in the information model that correspond to them. two hierarchies bestie — the real ones and the relationship ones 🫶

RFC-3698 Lightweight Directory Access Protocol (LDAP): Additional Matching Rules

http://www.ietf.org/rfc/rfc3698.txt

This document provides a collection of matching rules for use with the Lightweight Directory Access Protocol (LDAP). As these matching rules are simple adaptations of matching rules specified for use with the X.500 Directory, most are already in wide use. nothing new under the sun, just repackaged and already familar 💜

RFC-3687 Lightweight Directory Access Protocol (LDAP) and X.500 Component Matching Rules

http://www.ietf.org/rfc/rfc3687.txt

The syntaxes of attributes in a Lightweight Directory Access Protocol (LDAP) or X.500 directory range from simple data types, such as text string, integer, or Boolean, to complex structured data types, such as the syntaxes of the directory schema operational attributes. Matching rules defined for the complex syntaxes usually only provide the most immediately useful matching capability. This document defines generic matching rules that can match any user selected component parts in an attribute value of any arbitrarily complex attribute syntax. "arbitrarily complex" is doing SO much heavy lifting in that sentence 😭

RFC-3672 Subentries in the Lightweight Directory Access Protocol (LDAP)

http://www.ietf.org/rfc/rfc3672.txt

In X.500 directories, subentries are special entries used to hold information associated with a subtree or subtree refinement. This document adapts X.500 subentries mechanisms for use with the Lightweight Directory Access Protocol (LDAP). subentries: the side-character entries with main character energy 👑

RFC-3671 Collective Attributes in the Lightweight Directory Access Protocol (LDAP)

http://www.ietf.org/rfc/rfc3671.txt

X.500 collective attributes allow common characteristics to be shared between collections of entries. This document summarizes the X.500 information model for collective attributes and describes use of collective attributes in LDAP (Lightweight Directory Access Protocol). This document provides schema definitions for collective attributes for use in LDAP. shared attributes = matching outfits for a whole squad of entries, adorable 🌸

RFC-3296 Named Subordinate References in Lightweight Directory Access Protocol (LDAP) Directories

http://www.ietf.org/rfc/rfc3296.txt

This document details schema and protocol elements for representing and managing named subordinate references in Lightweight Directory Access Protocol (LDAP) Directories. schema and protocol elements, both halves ate 💅

RFC-3062 LDAP Password Modify Extended Operation

http://www.ietf.org/rfc/rfc3062.txt

The integration of the Lightweight Directory Access Protocol (LDAP) and external authentication services has introduced non-DN authentication identities and allowed for non-directory storage of passwords. As such, mechanisms which update the directory (e.g., Modify) cannot be used to change a user's password. This document describes an LDAP extended operation to allow modification of user passwords which is not dependent upon the form of the authentication identity nor the password storage mechanism used. because sometimes the password literally is not in the directory, bestie — Modify can't help you there 🫶

RFC-2891 LDAP Control Extension for Server Side Sorting of Search Results

http://www.ietf.org/rfc/rfc2891.txt

This document describes two LDAPv3 control extensions for server side sorting of search results. These controls allows a client to specify the attribute types and matching rules a server should use when returning the results to an LDAP search request. The controls may be useful when the LDAP client has limited functionality or for some other reason cannot sort the results but still needs them sorted. Other permissible controls on search operations are not defined in this extension. two controls, server does the sorting, your poor little client doesn't have to 🔥

RFC-2849 The LDAP Data Interchange Format (LDIF) - Technical Specification

http://www.ietf.org/rfc/rfc2849.txt

This document describes a file format suitable for describing directory information or modifications made to directory information. The file format, known as LDIF, for LDAP Data Interchange Format, is typically used to import and export directory information between LDAP-based directory servers, or to describe a set of changes which are to be applied to a directory. LDIF my beloved — the export format that keeps on giving ✨

RFC-2831 Using Digest Authentication as a SASL Mechanism

http://www.ietf.org/rfc/rfc2831.txt

This specification defines how HTTP Digest Authentication can be used as a SASL [RFC 2222] mechanism for any protocol that has a SASL profile. It is intended both as an improvement over CRAM-MD5 [RFC 2195] and as a convenient way to support a single authentication mechanism for web, mail, LDAP, and other protocols. one auth mechanism to rule them all — web, mail, LDAP, everything 💅

RFC-2739 Calendar Attributes for vCard and LDAP

http://www.ietf.org/rfc/rfc2739.txt

When scheduling a calendar entity, such as an event, it is a prerequisite that an organizer has the calendar address of each attendee that will be invited to the event. Additionally, access to an attendee's current "busy time" provides an a priori indication of whether the attendee will be free to participate in the event. In order to meet these challenges, a calendar user agent (CUA) needs a mechanism to locate individual user's calendar and free/busy time. This memo defines three mechanisms for obtaining a URI to a user's calendar and free/busy time. These include: (and then the list just... trails off right there in this text, bestie — the colon stays, the items do not 🙈)

RFC-2589 Extensions for Dynamic Directory Services

http://www.ietf.org/rfc/rfc2589.txt

LDAP supports lightweight access to static directory services, allowing relatively fast search and update access. Static directory services store information about people that persists in its accuracy and value over a long period of time. Dynamic directory services are different in that they store information about people that only persists in its accuracy and value while people are online. Though the protocol operations and attributes used by dynamic directory services are similar to the ones used for static directory services, clients that are bound to a dynamic directory service need to periodically refresh their presence at the server to keep directory entries from getting stale in the presence of client application crashes. A flow control mechanism from the server is also described that allows a server to inform clients how often they should refresh their presence. online-status energy: if you don't keep refreshing, you go stale — literally the "last seen" of directory services 😭

RFC-2559 Internet X.509 Public Key Infrastructure Operational Protocols - LDAPv2

http://www.ietf.org/rfc/rfc2559.txt

no blurb on this one in the source text, so no blurb from me — we respect the source in this house 🫶

Okay so real quick — we're still in the middle of this one RFC's description, bestie, so let me just finish that thought before we move on:

The protocol in that document is designed to satisfy some of the operational requirements within the Internet X.509 PKI. Specifically, it addresses requirements to provide access to PKI repositories for the purposes of retrieving PKI information and managing that same information. The mechanism described is based on the LDAPv2, defined in RFC 1777, defining a profile of that protocol for use within the PKIX, and it updates encodings for certificates and revocation lists from RFC 1778. Additional mechanisms addressing PKIX operational requirements are specified in separate documents. 💅

🎀 RFC-2247 Using Domains in LDAP/X.500 Distinguished Names

http://www.ietf.org/rfc/rfc2247.txt

LDAP uses X.500-compatible distinguished names to give entries their unique identification, right? This document defines an algorithm by which a name registered with the Internet Domain Name Service can be represented as an LDAP distinguished name. So your DNS name can glow up into a DN. ✨

🔐 RFC-2222 Simple Authentication and Security Layer (SASL)

http://www.ietf.org/rfc/rfc2222.txt

This one describes a method for adding authentication support to connection-based protocols. To use it, a protocol includes a command for identifying and authenticating a user to a server, plus optionally negotiating protection of subsequent protocol interactions. If its use is negotiated, a security layer gets inserted between the protocol and the connection — like a little bodyguard 🫶. The document describes how a protocol specifies such a command, defines several mechanisms for use by the command, and defines the protocol used for carrying a negotiated security layer over the connection.

📇 RFC-2218 A Common Schema for the Internet White Pages Service

http://www.ietf.org/rfc/rfc2218.txt

The IETF Integrated Directory Services (IDS) Working Group is proposing a standard specification for a simple Internet White Pages service, defining a common schema for use by the various White Pages servers. The schema is independent of specific implementations of the White Pages service. It specifies the minimum set of core attributes of a White Pages entry for an individual, and describes how new objects with those attributes can be defined and published. It does not describe how to represent other objects in the White Pages service. And yeah — it also doesn't address the search sort expectations within a particular service. Not its era, not its problem 💀.

📬 RFC-2164 Use of an X.500/LDAP directory to support MIXER address mapping

http://www.ietf.org/rfc/rfc2164.txt

MIXER (RFC 2156) defines an algorithm for use of a set of global mapping between X.400 and RFC 822 addresses. This specification defines how to represent and maintain these mappings — the MIXER Conformant Global Address Mappings, aka MCGAMs — in an X.500 or LDAP directory. There are mechanisms for representing OR Address and Domain hierarchies within the DIT. These techniques are used to define two independent subtrees in the DIT, which contain the mapping information. Two subtrees! Main character energy, honestly 👑

🔗 RFC-2079 Definition of an X.500 Attribute Type and an Object Class to Hold Uniform Resource Identifiers

http://www.ietf.org/rfc/rfc2079.txt

URLs are being widely used to specify the location of Internet resources. There is an urgent need to be able to include URLs in directories that conform to the LDAP and X.500 information models, plus a desire to include other types of URIs as they get defined. A number of independent groups are already out here experimenting with putting URLs in LDAP and X.500 directories. This document builds on that experimentation to date and defines a new attribute type and an auxiliary object class so URIs — including URLs — can be stored in directory entries in a standard way. Slay. 🌈

Okay these next ones are the "best current practice" girlies, very "we've been through things and now we have notes" energy. 💜

📝 RFC-4521 Considerations for Lightweight Directory Access Protocol (LDAP) Extensions

http://www.ietf.org/rfc/rfc4521.txt

The Lightweight Directory Access Protocol (LDAP) is extensible. It provides mechanisms for adding new operations, extending existing operations, and expanding user and system schemas. This document discusses considerations for designers of LDAP extensions. So like, if you're out here building an extension, read this first bestie 🙈.

🗂️ RFC-4520 Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access Protocol (LDAP)

http://www.ietf.org/rfc/rfc4520.txt

This document provides procedures for registering extensible elements of the Lightweight Directory Access Protocol (LDAP). It also provides guidelines to the Internet Assigned Numbers Authority (IANA) describing conditions under which new values can be assigned. Bureaucracy but make it directory services 🎀

🌐 RFC-2148 Deployment of the Internet White Pages Service

http://www.ietf.org/rfc/rfc2148.txt

The Internet is used for information exchange and communication between its users. It can only be effective as such if users are able to find each other's addresses. Therefore the Internet benefits from an adequate White Pages Service — i.e., a directory service offering (Internet) address information related to people and organizations.

This document describes the way in which the Internet White Pages Service (abbreviated IWPS from here on out) is best exploited using today's experience, today's protocols, today's products and today's procedures. Very "use what you have, it's giving resourceful" 💅

Informational ones! They're not telling you what to do, they're just sharing. 🫶

🧂 RFC-5803 Lightweight Directory Access Protocol (LDAP) Schema for Storing Salted Challenge Response Authentication Mechanism (SCRAM) Secrets

http://www.ietf.org/rfc/rfc5803.txt

This memo describes how the "authPassword" Lightweight Directory Access Protocol (LDAP) attribute can be used for storing secrets used by the Salted Challenge Response Authentication Mechanism (SCRAM) mechanism in the Simple Authentication and Security Layer (SASL) framework. Salty 🔥

⚙️ RFC-4876 A Configuration Profile Schema for Lightweight Directory Access Protocol (LDAP)-Based Agents

http://www.ietf.org/rfc/rfc4828.txt

(Yes, the RFC is 4876 and the link says 4828 — that's exactly what the page says, I'm just the messenger, no cap 💀)

This document consists of two primary components: a schema for agents that make use of the Lightweight Directory Access protocol (LDAP), and a proposed use case of that schema, for distributed configuration of similar directory user agents. A set of attribute types and an object class are proposed. In the proposed use case, directory user agents (DUAs) can use this schema to determine directory data location and access parameters for specific services they support. Also in the proposed use case, attribute and object class mapping allows DUAs to reconfigure their expected (default) schema to match that of the end user's environment. This document is intended to be a skeleton for future documents that describe configuration of specific DUA services. Skeleton!! spooky but make it structural 🦴

🏷️ RFC-4529 Requesting Attributes by Object Class in the Lightweight Directory Access Protocol (LDAP)

http://www.ietf.org/rfc/rfc4529.txt

The Lightweight Directory Access Protocol (LDAP) search operation provides mechanisms for clients to request all user application attributes, all operational attributes, and/or attributes selected by their description. This document extends LDAP to support a mechanism that LDAP clients may use to request the return of all attributes of an object class. "Gimme everything from that class" — iconic request, honestly 👑

➕ RFC-4525 Lightweight Directory Access Protocol (LDAP) Modify-Increment Extension

http://www.ietf.org/rfc/rfc4525.txt

This document describes an extension to the Lightweight Directory Access Protocol (LDAP) Modify operation to support an increment capability. It's useful in provisioning applications, especially when combined with the assertion control and/or the pre-read or post-read control extension. Math but for directories 🧮✨

🏢 RFC-4403 Lightweight Directory Access Protocol (LDAP) Schema for Universal Description, Discovery, and Integration version 3 (UDDIv3)

http://www.ietf.org/rfc/rfc4403.txt

This document defines the Lightweight Directory Access Protocol (LDAPv3) schema for representing Universal Description, Discovery, and Integration (UDDI) data types in an LDAP directory. It defines the LDAP object class and attribute definitions and containment rules to model UDDI entities — defined in the UDDI version 3 information model — in an LDAPv3-compliant directory. That's a lot of acronyms and every single one of them is load-bearing 💅

📦 RFC-4373 Lightweight Directory Access Protocol (LDAP) Bulk Update/Replication Protocol (LBURP)

http://www.ietf.org/rfc/rfc4373.txt

The Lightweight Directory Access Protocol (LDAP) Bulk Update/Replication Protocol (LBURP) allows an LDAP client to perform a bulk update to an LDAP server. The protocol frames a sequenced set of update operations within a pair of LDAP extended operations, to notify the server that the update operations in the framed set are related in such a way that the ordering of all operations can be preserved during processing — even when they're sent asynchronously by the client. Update operations can be grouped within a single protocol message to maximize the efficiency of client-server communication.

The protocol is suitable for efficiently making a substantial set of updates to the entries in an LDAP server. Bulk queen behavior 🔥

📹 RFC-3944 H.350 Directory Services

http://www.ietf.org/rfc/rfc3944.txt

The International Telecommunications Union Standardization Sector (ITU-T) has created the H.350 series of Recommendations that specify directory services architectures in support of multimedia conferencing protocols. The goal of the architecture is to "directory enable" multimedia conferencing, so these services can leverage existing identity management and enterprise directories. A particular goal is to enable an enterprise or service provider to maintain a canonical source of users and their multimedia conferencing systems, so that multiple call servers from multiple vendors, supporting multiple protocols, can all access the same data store. One data store, many call servers, no drama 🌸

Because SIP is an IETF standard, the contents of H.350 and H.350.4 are made available via this document to the IETF community. This document contains the entire normative text of ITU-T Recommendations H.350 and H.350.4 in sections 4 and 5, respectively. The remaining sections are included only in this document, not in the ITU-T version. Exclusive bonus content 🎀

🪪 RFC-3829 Lightweight Directory Access Protocol (LDAP) Authorization Identity Request and Response Controls

http://www.ietf.org/rfc/rfc3829.txt

This document extends the Lightweight Directory Access Protocol (LDAP) bind operation with a mechanism for requesting and returning the authorization identity it establishes. Specifically, it defines the Authorization Identity Request and Response controls for use with the Bind operation. Who am I? Asking for a friend 💅

🖨️ RFC-3712 Lightweight Directory Access Protocol (LDAP): Schema for Printer Services

http://www.ietf.org/rfc/rfc3712.txt

(mood, no notes — this one's just here, standing pretty 🦋)

Okay so this one is literally all about printers and printer services 🖨️✨ It defines a schema, object classes and attributes for printers and printer services, for use with directories that support Lightweight Directory Access Protocol v3 (LDAP-TS). It’s based on the printer attributes listed in Appendix E of Internet Printing Protocol/1.1 (IPP) (RFC 2911), and a few extra printer attributes come from definitions in the Printer MIB (RFC 1759). Niche? Yes. Iconic? Also yes 💅

RFC-3494 Lightweight Directory Access Protocol version 2 (LDAPv2) to Historic Status 🪦💅

🔗 http://www.ietf.org/rfc/rfc3494.txt

This one recommends the retirement of version 2 of the Lightweight Directory Access Protocol (LDAPv2) and other dependent specifications, and it discusses the reasons for doing so. It also recommends that RFC 1777, 1778, 1779, 1781, and 2559 (as well as documents they superseded) be moved to Historic status. Like, bestie, it’s time to let go 👋✨

RFC-3384 Lightweight Directory Access Protocol (version 3) Replication Requirements 🔁🫶

🔗 http://www.ietf.org/rfc/rfc3384.txt

This document discusses the fundamental requirements for replication of data accessible via the Lightweight Directory Access Protocol (version 3) (LDAPv3). It is intended to be a gathering place for general replication requirements needed to provide interoperability between informational directories. Replication tea, served fresh ☕💜

RFC-3112 LDAP Authentication Password Schema 🔐✨

🔗 http://www.ietf.org/rfc/rfc3112.txt

This document describes schema in support of user/password authentication in a LDAP (Lightweight Directory Access Protocol) directory, including the authPassword attribute type. This attribute type holds values derived from the user's password(s) (commonly using cryptographic strength one-way hash). authPassword is intended to be used instead of userPassword. Password glow-up, no cap 🫶

RFC-3045 Storing Vendor Information in the LDAP root DSE 🏷️👑

🔗 http://www.ietf.org/rfc/rfc3045.txt

This document specifies two Lightweight Directory Access Protocol (LDAP) attributes, vendorName and vendorVersion, that MAY be included in the root DSA-specific Entry (DSE) to advertise vendor-specific information. These two attributes supplement the attributes defined in section 3.4 of RFC 2251. Vendor lore, but make it directory 💅

RFC-2985 PKCS #9: Selected Object Classes and Attribute Types Version 2.0 🔑🌷

🔗 http://www.ietf.org/rfc/rfc2985.txt

This memo provides a selection of object classes and attribute types for use in conjunction with public-key cryptography and Lightweight Directory Access Protocol (LDAP) accessible directories. It also includes ASN.1 syntax for all constructs. PKI bestie behavior, fr fr 🔥

RFC-2967 TISDAG - Technical Infrastructure for Swedish Directory Access Gateways 🇸🇪🌐

🔗 http://www.ietf.org/rfc/rfc2967.txt

The strength of the TISDAG (Technical Infrastructure for Swedish Directory Access Gateways) project's DAG proposal is that it defines the necessary technical infrastructure to provide a single-access- point service for information on Swedish Internet users. The resulting service will provide uniform access for all information — the same level of access to information (7x24 service), and the same information made available, irrespective of the service provider responsible for maintaining that information, their directory service protocols, or the end-user's client access protocol. Uniform access is the main character here 👑✨

RFC-2927 MIME Directory Profile for LDAP Schema 💌📬

🔗 http://www.ietf.org/rfc/rfc2927.txt

This document defines a multipurpose internet mail extensions (MIME) directory profile for holding a lightweight directory access protocol (LDAP) schema. It is intended for communication with the Internet schema listing service. MIME plus LDAP schema pen pals, lowkey cute 🎀

RFC-2926 Conversion of LDAP Schemas to and from SLP Templates 🔄🦋

🔗 http://www.ietf.org/rfc/rfc2926.txt

This document describes a procedure for mapping between Service Location Protocol (SLP) service advertisements and lightweight directory access protocol (LDAP) descriptions of services. The document covers two aspects of the mapping:

  • Aspect one: mapping between SLP service type templates and LDAP directory schema. Because the SLP service type template grammar is relatively simple, mapping from service type templates to LDAP types is straightforward. Mapping in the other direction is straightforward if the attributes are restricted to use just a few of the syntaxes defined in RFC 2252. If arbitrary ASN.1 types occur in the schema, then the mapping is more complex and may even be impossible.
  • Aspect two: representation of service information in an LDAP directory. The recommended representation simplifies interoperability with SLP by allowing SLP directory agents to backend into LDAP directory servers. The resulting system allows service advertisements to propagate easily between SLP and LDAP.

Mapping drama, but make it structured 💀💜

RFC-2820 Access Control Requirements for LDAP 🛡️🔐

🔗 http://www.ietf.org/rfc/rfc2820.txt

This document describes the fundamental requirements of an access control list (ACL) model for the LDAP directory service. It is intended to be a gathering place for access control requirements needed to provide authorized access to and interoperability between directories. ACL requirements, gathered together like a group chat 🫶

RFC-2798 Definition of the inetOrgPerson Object Class 👤👑

🔗 http://www.ietf.org/rfc/rfc2798.txt

While the X.500 standards define many useful attribute types [X520] and object classes [X521], they do not define a person object class that meets the requirements found in today's Internet and Intranet directory service deployments. We define a new object class called inetOrgPerson for use in LDAP and X.500 directory services that extends the X.521 standard organizationalPerson class to meet these needs. inetOrgPerson is the blueprint, no cap 💅

RFC-2714 Schema for Representing CORBA Objects in an LDAP Directory 🧩🌈

🔗 http://www.ietf.org/rfc/rfc2714.txt

CORBA is the Common Object Request Broker Architecture defined by the Object Management Group. This document defines the schema for representing CORBA object references in an LDAP directory. CORBA objects in LDAP: yes, we’re doing this 🫶

RFC-2713 Schema for Representing Java Objects in an LDAP Directory ☕💜

🔗 http://www.ietf.org/rfc/rfc2713.txt

This document defines the schema for representing Java objects in an LDAP directory. It defines schema elements to represent a Java serialized object, a Java marshalled object, a Java remote object, and a JNDI reference. Java object representation in LDAP, slay ✨

RFC-2696 LDAP Control Extension for Simple Paged Results Manipulation 📄💀

🔗 http://www.ietf.org/rfc/rfc2696.txt

This document describes an LDAPv3 control extension for simple paging of search results. This control extension allows a client to control the rate at which an LDAP server returns the results of an LDAP search operation. This control may be useful when the LDAP client has limited resources and may not be able to process the entire result set from a given LDAP query, or when the LDAP client is connected over a low-bandwidth connection. Other operations on the result set are not defined in this extension. This extension is not designed to provide more sophisticated result set management. Paging, but make it simple — don’t ask for extra 😭

RFC-1823 The LDAP Application Program Interface 🧑‍💻⭐

🔗 http://www.ietf.org/rfc/rfc1823.txt

This document defines a C language application program interface to LDAP, which is designed to be powerful, yet simple to use. It defines compatible synchronous and asynchronous interfaces to LDAP to suit a wide variety of applications. This document gives a brief overview of the LDAP model, then an overview of how the API is used by an application program to obtain LDAP information. The API calls are described in detail, followed by an appendix that provides some example code demonstrating the use of the API. C API bestie: powerful yet simple, periodt 🔥

🌈 RFC-5805 Lightweight Directory Access Protocol (LDAP) Transactions

http://www.ietf.org/rfc/rfc5805.txt

Okay so bestie, LDAP update operations — the Add, Delete, and Modify girlies — already have atomic, consistency, isolation, durability (ACID) properties, no cap. Each of those update operations acts upon an entry. But sometimes you really want to update two or more entries in a single unit of interaction, aka a transaction, and that’s exactly what this is giving. Transactions are necessary to support a bunch of applications, including resource provisioning. This document extends LDAP to support transactions. Slay. 💅

🦋 RFC-4533 The Lightweight Directory Access Protocol (LDAP) Content Synchronization Operation

http://www.ietf.org/rfc/rfc4533.txt

This specification describes the Lightweight Directory Access Protocol (LDAP) Content Synchronization Operation. The operation lets a client maintain a copy of a fragment of the Directory Information Tree (DIT) — like, keep their own little piece of the directory vibe. It supports both polling for changes and listening for changes. The operation is defined as an extension of the LDAP Search Operation. Obsessed. ✨

🎀 RFC-4531 Lightweight Directory Access Protocol (LDAP) Turn Operation

http://www.ietf.org/rfc/rfc4531.txt

This specification describes a Lightweight Directory Access Protocol (LDAP) extended operation to reverse (or "turn") the roles of client and server for subsequent protocol exchanges in the session. It can also enable each peer to act as both client and server with respect to the other. It’s giving switch-up main character energy, fr fr. 🔄

🌸 RFC-3663 Domain Administrative Data in Lightweight Directory Access Protocol (LDAP)

http://www.ietf.org/rfc/rfc3663.txt

Domain registration data has typically been exposed to the general public via Nicname/Whois for administrative purposes. This document describes the Referral Lightweight Directory Access Protocol (LDAP) Service — an experimental service using LDAP and well-known LDAP types to make domain administrative data available. Lowkey useful, highkey experimental. 🫶

⭐ RFC-3088 OpenLDAP Root Service - An experimental LDAP referral service

http://www.ietf.org/rfc/rfc3088.txt

The OpenLDAP Project is operating an experimental LDAP (Lightweight Directory Access Protocol) referral service known as the "OpenLDAP Root Service". The automated system generates referrals based upon service location information published in DNS SRV RRs (Domain Name System location of services resource records). This document describes this service. It’s very much giving automated-matchmaker-for-directories, iykyk. 💖

🧚 RFC-2657 LDAPv2 Client vs. the Index Mesh

http://www.ietf.org/rfc/rfc2657.txt

LDAPv2 clients as implemented according to RFC 1777 have no notion of referral. The integration between such a client and an Index Mesh, as defined by the Common Indexing Protocol, heavily depends on referrals and therefore needs to be handled in a special way. This document defines one possible way of doing this. Not me reading this and feeling the referral drama. 😭

🔥 RFC-2649 Signed Directory Operations Using S/MIME

http://www.ietf.org/rfc/rfc2649.txt

This document defines an LDAPv3 based mechanism for signing directory operations in order to create a secure journal of changes that have been made to each directory entry. Both client based signatures and server based signatures are supported. An object class for subsequent retrieval of 'journal entries' is also defined. This document specifies LDAPv3 controls that enable this functionality. It also defines an LDAPv3 schema that allows for subsequent browsing of the journal information. It’s giving receipts, but make them cryptographically secure. 👑

🍓 RFC-2307 An Approach for Using LDAP as a Network Information Service

http://www.ietf.org/rfc/rfc2307.txt

This document describes an experimental mechanism for mapping entities related to TCP/IP and the UNIX system into X.500 entries so that they may be resolved with the LDAP. A set of attribute types and object classes are proposed, along with specific guidelines for interpreting them. The intention is to assist the deployment of LDAP as an organizational nameservice. No proposed solutions are intended as standards for the Internet. Rather, it is hoped that a general consensus will emerge as to the appropriate solution to such problems, leading eventually to the adoption of standards. The proposed mechanism has already been implemented with some success. So yes, it’s experimental, but it’s also out here thriving. 🌈

💀 Expired but still interesting Internet Drafts 💀

Okay bestie, these are the drafts that have technically expired but are still lowkey iconic — the "they didn't make it to RFC status but the vibes were immaculate" collection. Let's go 🫶

🎀 draft-wahl-ldap-adminaddr — Administrator Address Attribute

So picture this: organizations running multiple directory servers need a way for admins to figure out who's actually responsible for a particular server. It's conceptually the same energy as the 'sysContact' object in SNMP, fr fr. The administratorsAddress attribute lets a server administrator supply the contact info of whoever's the responsible party for an LDAP server. Management clients can use this — say, ones that are checking the state of a replication or referral topology — so the user of the management client can send email to the manager of a particular server. Iconic little feature, honestly. 💌

🙈 draft-zeilenga-ldap-noop — The LDAP No-Op Control

This one defines the Lightweight Directory Access Protocol (LDAP) No-Op control, which you can use to disable the normal effect of an operation. Translation: you get to discover how a server might react to a particular update request without actually updating the directory. It's the "what would happen if I did this 👀" control. No cap, very useful.

✨ draft-legg-ldap-transfer — Lightweight Directory Access Protocol (LDAP): Transfer Encoding Options

Every attribute stored in an LDAP directory has a defined syntax (i.e., a data type). A syntax definition specifies how attribute values that conform to the syntax are normally represented when they're transferred in LDAP operations. That representation is called the LDAP-specific encoding, and the whole point of the name is to distinguish it from other methods of encoding attribute values. This document introduces a whole new category of attribute options called transfer encoding options — these let you specify that the associated attribute values are encoded according to one of those other methods. Slay, flexible encoding. 🌈

🦋 draft-furuseth-ldap-untypedobject — Structural object class 'namedObject' for LDAP/X.500

This document defines a 'namedObject' structural object class for the Lightweight Directory Access Protocol (LDAP) and X.500. It's the plug for entries with no natural choice of structural object class — like when an entry must exist even though its contents are, and I say this with love, uninteresting. It's giving "I'm here, I'm named, get used to it." 👑

🍓 draft-wahl-ldap-p3p — P3P Policy Attributes for LDAP

Here's the deal: this document defines attributes you can retrieve via Lightweight Directory Access Protocol version 3 (LDAP) requests, which contain URIs pointing to privacy policy documents. Those documents describe the privacy policy concerning access to a directory server, and the privacy policies that apply to the contents of the directory (a subtree of entries). Privacy matters, bestie. 🔒✨

💜 draft-chu-ldap-xordered — Ordered Entries and Values in LDAP

As LDAP gets used more extensively for managing all kinds of data, you often run into a need to preserve both the ordering and the content of data — even though entries and attribute values in the directory are inherently unordered. This document describes a scheme for attaching ordering information to attributes in a directory so that the ordering can be preserved and propagated to other LDAP applications. Literally fighting the chaos of unordered data with sheer willpower and metadata. 💅

🌸 draft-chu-ldap-logschema — A Schema for Logging the LDAP Protocol

To facilitate remote administration and auditing of LDAP server operation, it's desirable to provide the server's operational logs themselves as a searchable LDAP directory. And those logs can also double as a persistent change log to support various replication mechanisms. So this document defines a schema that can be used to represent all the requests that have been processed by an LDAP server — useful for auditing, flight recorder, replication, and other purposes. A whole schema just for the receipts. 📝🔥

🧚 draft-zeilenga-ldap-relax — The LDAP Relax Rules Control

This document defines the Lightweight Directory Access Protocol (LDAP) Relax Rules Control, which allows a directory user agent (a client) to request that the directory service temporarily relax enforcement of various data and service model rules. It's the "girl, just this once, loosen up" control. 🫶

⭐ draft-gpaterno-dhcp-ldap — DHCP Option for LDAP Directory Services discovery

This document defines a new DHCP option for delivering configuration information for LDAP services. Through this option, the client receives an LDAP URL [8] of the closest available LDAP server/replica that can be used to authenticate users or look up any useful data. Auto-discovery but make it directory services. 🔎

🎀 draft-schleiff-ldap-xri — LDAP Schema for eXtensible Resource Identifier (XRI)

This document describes Attribute Types and an Object Class for use in representing XRI (eXtensible Resource Identifier) values in LDAP (Lightweight Directory Access Protocol) and X.500 directory services. XRI representation, handled. 💖

🌈 draft-wahl-ldap-session — LDAP Session Tracking Control

Okay so — lots of network devices, application servers, and middleware components of an enterprise software infrastructure generate some form of session tracking identifiers. Those are useful when you're analyzing activity and accounting logs to group activity relating to a particular session.

This document discusses how Lightweight Directory Access Protocol version 3 (LDAP) clients can include session tracking identifiers with their LDAP requests. The info is provided through controls in the requests that clients send to LDAP servers. The LDAP server receiving these controls can include the session tracking identifiers in the log messages it writes, so LDAP requests in the LDAP server's logs can be correlated with activity in the logs of other components in the infrastructure. The control also enables session tracking information to be generated by LDAP servers and returned to clients and other servers.

And yes — three formats of session tracking identifiers are defined in this document. Three! 🌸

🦋 draft-wahl-ldap-subtree-source — LDAP Subtree Data Source URI Attribute

This document defines an attribute that enables administrative clients using the Lightweight Directory Access Protocol (LDAP) to determine the source of directory entries. Knowing where your entries came from? Immaculate. 🔍

👑 draft-ietf-ldapext-psearch — Persistent Search: A Simple LDAP Change Notification Mechanism

This document defines two controls that extend the LDAPv3 search operation, providing a simple mechanism by which an LDAP client can receive notification of changes that occur in an LDAP server. The mechanism is designed to be super flexible yet easy for clients and servers to implement. Flexible and easy — the dream combo, periodt. 💅

🔥 draft-ietf-ldapext-ldapv3-vlv — LDAP Extensions for Scrolling View Browsing of Search Results

This document describes a Virtual List View control extension for the LDAP Search operation. It's designed to allow the "virtual list box" feature — you know, the one that's common in existing commercial e-mail address book applications — to be supported efficiently by LDAP servers. And ngl, LDAP servers' inability to support this client feature is a significant impediment to LDAP replacing proprietary protocols in commercial e-mail systems. Big stakes, bestie.

The control allows a client to specify that the server return, for a given LDAP search with associated sort keys, a contiguous subset of the search result set. This subset is specified in terms of offsets into the ordered list, or in terms of a greater than or equal comparison value. Clean. Precise. Iconic. ✨

🔎 Where to find the latest information 🔎

Latest information on the RFCs and drafts around LDAP can be found at IETF's datatracker: https://datatracker.ietf.org. Go touch grass in the datatracker, it's worth it 🌱

And that's the whole page, bestie!! 🎉 You made it to the end, so here's the cute little sign-off: this was perl v5.42.0, dated 2024-01-02, page Net::LDAP::RFC(3). Go forth and cite your RFCs with confidence 💖👑🎀

📦 where this page comes from