{ "mode": "perldoc", "parameter": "Net::LDAP::RFC", "section": "", "url": "https://www.chedong.com/phpMan.php/perldoc/Net%3A%3ALDAP%3A%3ARFC/json", "generated": "2026-10-09T01:19:55Z", "synopsis": "none", "sections": { "NAME": { "content": "Net::LDAP::RFC - List of related RFCs\n", "subsections": [] }, "SYNOPSIS": { "content": "none\n", "subsections": [] }, "DESCRIPTION": { "content": "The LDAP protocol is defined in the following RFCs\n", "subsections": [] }, "Core LDAP Specification": { "content": "RFC-4510 Lightweight Directory Access Protocol (LDAP): Technical Specification Road Map\nhttp://www.ietf.org/rfc/rfc4510.txt\n\nThe Lightweight Directory Access Protocol (LDAP) is an Internet protocol for accessing\ndistributed directory services that act in accordance with X.500 data and service models. This\ndocument provides a road map of the LDAP Technical Specification.\n\nRFC-4511 Lightweight Directory Access Protocol (LDAP): The Protocol\nhttp://www.ietf.org/rfc/rfc4511.txt\n\nThis document describes the protocol elements, along with their semantics and encodings, of the\nLightweight Directory Access Protocol (LDAP). LDAP provides access to distributed directory\nservices that act in accordance with X.500 data and service models. These protocol elements are\nbased on those described in the X.500 Directory Access Protocol (DAP).\n\nRFC-4512 Lightweight Directory Access Protocol (LDAP): Directory Information Models\nhttp://www.ietf.org/rfc/rfc4512.txt\n\nThe Lightweight Directory Access Protocol (LDAP) is an Internet protocol for accessing\ndistributed directory services that act in accordance with X.500 data and service models. This\ndocument describes the X.500 Directory Information Models, as used in LDAP.\n\nRFC-4513 Lightweight Directory Access Protocol (LDAP): Authentication Methods and Security Mechanisms\nhttp://www.ietf.org/rfc/rfc4513.txt\n\nThis document describes authentication methods and security mechanisms of the Lightweight\nDirectory Access Protocol (LDAP). This document details establishment of Transport Layer\nSecurity (TLS) using the StartTLS operation.\n\nThis document details the simple Bind authentication method including anonymous,\nunauthenticated, and name/password mechanisms and the Simple Authentication and Security Layer\n(SASL) Bind authentication method including the EXTERNAL mechanism.\n\nThis document discusses various authentication and authorization states through which a session\nto an LDAP server may pass and the actions that trigger these state changes.\n\nRFC-4514 Lightweight Directory Access Protocol (LDAP): String Representation of Distinguished Names\nhttp://www.ietf.org/rfc/rfc4514.txt\n\nThe X.500 Directory uses distinguished names (DNs) as primary keys to entries in the directory.\nThis document defines the string representation used in the Lightweight Directory Access\nProtocol (LDAP) to transfer distinguished names. The string representation is designed to give a\nclean representation of commonly used distinguished names, while being able to represent any\ndistinguished name.\n\nRFC-4515 Lightweight Directory Access Protocol (LDAP): String Representation of Search Filters\nhttp://www.ietf.org/rfc/rfc4515.txt\n\nLightweight Directory Access Protocol (LDAP) search filters are transmitted in the LDAP protocol\nusing a binary representation that is appropriate for use on the network. This document defines\na human-readable string representation of LDAP search filters that is appropriate for use in\nLDAP URLs (RFC 4516) and in other applications.\n\nRFC-4516 Lightweight Directory Access Protocol (LDAP): Uniform Resource Locator\nhttp://www.ietf.org/rfc/rfc4516.txt\n\nThis document describes a format for a Lightweight Directory Access Protocol (LDAP) Uniform\nResource Locator (URL). An LDAP URL describes an LDAP search operation that is used to retrieve\ninformation from an LDAP directory, or, in the context of an LDAP referral or reference, an LDAP\nURL describes a service where an LDAP operation may be progressed.\n\nRFC-4517 Lightweight Directory Access Protocol (LDAP): Syntaxes and Matching Rules\nhttp://www.ietf.org/rfc/rfc4517.txt\n\nEach attribute stored in a Lightweight Directory Access Protocol (LDAP) directory, whose values\nmay be transferred in the LDAP protocol, has a defined syntax that constrains the structure and\nformat of its values. The comparison semantics for values of a syntax are not part of the syntax\ndefinition but are instead provided through separately defined matching rules. Matching rules\nspecify an argument, an assertion value, which also has a defined syntax. This document defines\na base set of syntaxes and matching rules for use in defining attributes for LDAP directories.\n\nRFC-4518 Lightweight Directory Access Protocol (LDAP): Internationalized String Preparation\nhttp://www.ietf.org/rfc/rfc4518.txt\n\nThe previous Lightweight Directory Access Protocol (LDAP) technical specifications did not\nprecisely define how character string matching is to be performed. This led to a number of\nusability and interoperability problems. This document defines string preparation algorithms for\ncharacter-based matching rules defined for use in LDAP.\n\nRFC-4519 Lightweight Directory Access Protocol (LDAP): Schema for User Applications\nhttp://www.ietf.org/rfc/rfc4519.txt\n\nThis document is an integral part of the Lightweight Directory Access Protocol (LDAP) technical\nspecification. It provides a technical specification of attribute types and object classes\nintended for use by LDAP directory clients for many directory services, such as White Pages.\nThese objects are widely used as a basis for the schema in many LDAP directories. This document\ndoes not cover attributes used for the administration of directory servers, nor does it include\ndirectory objects defined for specific uses in other documents.\n", "subsections": [] }, "Other LDAP Related RFCs - Proposed Standards": { "content": "RFC-6171 The Lightweight Directory Access Protocol (LDAP) Don't Use Copy Control\nhttp://www.ietf.org/rfc/rfc6171.txt\n\nThis document defines the Lightweight Directory Access Protocol (LDAP) Don't Use Copy control\nextension which allows a client to specify that copied information should not be used in\nproviding service. This control is based upon the X.511 dontUseCopy service control option.\n\nRFC-5020 The Lightweight Directory Access Protocol (LDAP) entryDN Operational Attribute\nhttp://www.ietf.org/rfc/rfc5020.txt\n\nThis document describes the LDAP/X.500 'entryDN' operational attribute. The attribute provides a\ncopy of the entry's distinguished name for use in attribute value assertions.\n\nRFC-4792 Encoding Instructions for the Generic String Encoding Rules (GSER)\nhttp://www.ietf.org/rfc/rfc4792.txt\n\nAbstract Syntax Notation One (ASN.1) defines a general framework for annotating types in an\nASN.1 specification with encoding instructions that alter how values of those types are encoded\naccording to ASN.1 encoding rules. This document defines the supporting notation for encoding\ninstructions that apply to the Generic String Encoding Rules (GSER), and in particular defines\nan encoding instruction to provide a machine-processable representation for the declaration of a\nGSER ChoiceOfStrings type.\n\nRFC-4532 Lightweight Directory Access Protocol (LDAP) Who am I? Operation\nhttp://www.ietf.org/rfc/rfc4532.txt\n\nThis specification provides a mechanism for Lightweight Directory Access Protocol (LDAP) clients\nto obtain the authorization identity the server has associated with the user or application\nentity. This mechanism is specified as an LDAP extended operation called the LDAP \"Who am I?\"\noperation.\n\nRFC-4530 Lightweight Directory Access Protocol (LDAP) entryUUID Operational Attribute\nhttp://www.ietf.org/rfc/rfc4530.txt\n\nThis document describes the LDAP/X.500 'entryUUID' operational attribute and associated matching\nrules and syntax. The attribute holds a server-assigned Universally Unique Identifier (UUID) for\nthe object. Directory clients may use this attribute to distinguish objects identified by a\ndistinguished name or to locate an object after renaming.\n\nRFC-4528 Lightweight Directory Access Protocol (LDAP) Assertion Control\nhttp://www.ietf.org/rfc/rfc4528.txt\n\nThis document defines the Lightweight Directory Access Protocol (LDAP) Assertion Control, which\nallows a client to specify that a directory operation should only be processed if an assertion\napplied to the target entry of the operation is true. It can be used to construct \"test and\nset\", \"test and clear\", and other conditional operations.\n\nRFC-4527 Lightweight Directory Access Protocol (LDAP) Read Entry Controls\nhttp://www.ietf.org/rfc/rfc4527.txt\n\nThis document specifies an extension to the Lightweight Directory Access Protocol (LDAP) to\nallow the client to read the target entry of an update operation. The client may request to read\nthe entry before and/or after the modifications are applied. These reads are done as an atomic\npart of the update operation.\n\nRFC-4526 Lightweight Directory Access Protocol (LDAP) Absolute True and False Filters\nhttp://www.ietf.org/rfc/rfc4526.txt\n\nThis document extends the Lightweight Directory Access Protocol (LDAP) to support absolute True\nand False filters based upon similar capabilities found in X.500 directory systems. The document\nalso extends the String Representation of LDAP Search Filters to support these filters.\n\nRFC-4524 COSINE LDAP/X.500 Schema\nhttp://www.ietf.org/rfc/rfc4524.txt\n\nThis document provides a collection of schema elements for use with the Lightweight Directory\nAccess Protocol (LDAP) from the COSINE and Internet X.500 pilot projects.\n\nRFC-4523 Lightweight Directory Access Protocol (LDAP) Schema Definitions for X.509 Certificates\nhttp://www.ietf.org/rfc/rfc4523.txt\n\nThis document describes schema for representing X.509 certificates, X.521 security information,\nand related elements in directories accessible using the Lightweight Directory Access Protocol\n(LDAP). The LDAP definitions for these X.509 and X.521 schema elements replace those provided in\nRFCs 2252 and 2256.\n\nRFC-4522 Lightweight Directory Access Protocol (LDAP): The Binary Encoding Option\nhttp://www.ietf.org/rfc/rfc4522.txt\n\nEach attribute stored in a Lightweight Directory Access Protocol (LDAP) directory has a defined\nsyntax (i.e., data type). A syntax definition specifies how attribute values conforming to the\nsyntax are normally represented when transferred in LDAP operations. This representation is\nreferred to as the LDAP-specific encoding to distinguish it from other methods of encoding\nattribute values. This document defines an attribute option, the binary option, that can be used\nto specify that the associated attribute values are instead encoded according to the Basic\nEncoding Rules (BER) used by X.500 directories.\n\nRFC-4370 Lightweight Directory Access Protocol (LDAP) Proxied Authorization Control\nhttp://www.ietf.org/rfc/rfc4370.txt\n\nThis document defines the Lightweight Directory Access Protocol (LDAP) Proxy Authorization\nControl. The Proxy Authorization Control allows a client to request that an operation be\nprocessed under a provided authorization identity instead of under the current authorization\nidentity associated with the connection.\n\nRFC-4104 Policy Core Extension Lightweight Directory Access Protocol Schema (PCELS)\nhttp://www.ietf.org/rfc/rfc4104.txt\n\nThis document defines a number of changes and extensions to the Policy Core Lightweight\nDirectory Access Protocol (LDAP) Schema (RFC 3703) based on the model extensions defined by the\nPolicy Core Information Model (PCIM) Extensions (RFC 3460). These changes and extensions consist\nof new LDAP object classes and attribute types. Some of the schema items defined in this\ndocument re-implement existing concepts in accordance with their new semantics introduced by RFC\n3460. The other schema items implement new concepts, not covered by RFC 3703. This document\nupdates RFC 3703.\n\nRFC-3928 Lightweight Directory Access Protocol (LDAP) Client Update Protocol (LCUP)\nhttp://www.ietf.org/rfc/rfc3928.txt\n\nThis document defines the Lightweight Directory Access Protocol (LDAP) Client Update Protocol\n(LCUP). The protocol is intended to allow an LDAP client to synchronize with the content of a\ndirectory information tree (DIT) stored by an LDAP server and to be notified about the changes\nto that content.\n\nRFC-3909 Lightweight Directory Access Protocol (LDAP) Cancel Operation\nhttp://www.ietf.org/rfc/rfc3909.txt\n\nThis specification describes a Lightweight Directory Access Protocol (LDAP) extended operation\nto cancel (or abandon) an outstanding operation. Unlike the LDAP Abandon operation, but like the\nX.511 Directory Access Protocol (DAP) Abandon operation, this operation has a response which\nprovides an indication of its outcome.\n\nRFC-3876 Returning Matched Values with the Lightweight Directory Access Protocol version 3 (LDAPv3)\nhttp://www.ietf.org/rfc/rfc3876.txt\n\nThis document describes a control for the Lightweight Directory Access Protocol version 3 that\nis used to return a subset of attribute values from an entry. Specifically, only those values\nthat match a \"values return\" filter. Without support for this control, a client must retrieve\nall of an attribute's values and search for specific values locally.\n\nRFC-3866 Language Tags and Ranges in the Lightweight Directory Access Protocol (LDAP)\nhttp://www.ietf.org/rfc/rfc3866.txt\n\nIt is often desirable to be able to indicate the natural language associated with values held in\na directory and to be able to query the directory for values which fulfill the user's language\nneeds. This document details the use of Language Tags and Ranges in the Lightweight Directory\nAccess Protocol (LDAP).\n\nRFC-3727 ASN.1 Module Definition for the LDAP and X.500 Component Matching Rules\nhttp://www.ietf.org/rfc/rfc3727.txt\n\nThis document updates the specification of the component matching rules for Lightweight\nDirectory Access Protocol (LDAP) and X.500 directories (RFC3687) by collecting the Abstract\nSyntax Notation One (ASN.1) definitions of the component matching rules into an appropriately\nidentified ASN.1 module so that other specifications may reference the component matching rule\ndefinitions from within their own ASN.1 modules.\n\nRFC-3703 Policy Core Lightweight Directory Access Protocol (LDAP) Schema\nhttp://www.ietf.org/rfc/rfc3703.txt\n\nThis document defines a mapping of the Policy Core Information Model to a form that can be\nimplemented in a directory that uses Lightweight Directory Access Protocol (LDAP) as its access\nprotocol. This model defines two hierarchies of object classes: structural classes representing\ninformation for representing and controlling policy data as specified in RFC 3060, and\nrelationship classes that indicate how instances of the structural classes are related to each\nother. Classes are also added to the LDAP schema to improve the performance of a client's\ninteractions with an LDAP server when the client is retrieving large amounts of policy-related\ninformation. These classes exist only to optimize LDAP retrievals: there are no classes in the\ninformation model that correspond to them.\n\nRFC-3698 Lightweight Directory Access Protocol (LDAP): Additional Matching Rules\nhttp://www.ietf.org/rfc/rfc3698.txt\n\nThis document provides a collection of matching rules for use with the Lightweight Directory\nAccess Protocol (LDAP). As these matching rules are simple adaptations of matching rules\nspecified for use with the X.500 Directory, most are already in wide use.\n\nRFC-3687 Lightweight Directory Access Protocol (LDAP) and X.500 Component Matching Rules\nhttp://www.ietf.org/rfc/rfc3687.txt\n\nThe syntaxes of attributes in a Lightweight Directory Access Protocol (LDAP) or X.500 directory\nrange from simple data types, such as text string, integer, or Boolean, to complex structured\ndata types, such as the syntaxes of the directory schema operational attributes. Matching rules\ndefined for the complex syntaxes usually only provide the most immediately useful matching\ncapability. This document defines generic matching rules that can match any user selected\ncomponent parts in an attribute value of any arbitrarily complex attribute syntax.\n\nRFC-3672 Subentries in the Lightweight Directory Access Protocol (LDAP)\nhttp://www.ietf.org/rfc/rfc3672.txt\n\nIn X.500 directories, subentries are special entries used to hold information associated with a\nsubtree or subtree refinement. This document adapts X.500 subentries mechanisms for use with the\nLightweight Directory Access Protocol (LDAP).\n\nRFC-3671 Collective Attributes in the Lightweight Directory Access Protocol (LDAP)\nhttp://www.ietf.org/rfc/rfc3671.txt\n\nX.500 collective attributes allow common characteristics to be shared between collections of\nentries. This document summarizes the X.500 information model for collective attributes and\ndescribes use of collective attributes in LDAP (Lightweight Directory Access Protocol). This\ndocument provides schema definitions for collective attributes for use in LDAP.\n\nRFC-3296 Named Subordinate References in Lightweight Directory Access Protocol (LDAP) Directories\nhttp://www.ietf.org/rfc/rfc3296.txt\n\nThis document details schema and protocol elements for representing and managing named\nsubordinate references in Lightweight Directory Access Protocol (LDAP) Directories.\n\nRFC-3062 LDAP Password Modify Extended Operation\nhttp://www.ietf.org/rfc/rfc3062.txt\n\nThe integration of the Lightweight Directory Access Protocol (LDAP) and external authentication\nservices has introduced non-DN authentication identities and allowed for non-directory storage\nof passwords. As such, mechanisms which update the directory (e.g., Modify) cannot be used to\nchange a user's password. This document describes an LDAP extended operation to allow\nmodification of user passwords which is not dependent upon the form of the authentication\nidentity nor the password storage mechanism used.\n\nRFC-2891 LDAP Control Extension for Server Side Sorting of Search Results\nhttp://www.ietf.org/rfc/rfc2891.txt\n\nThis document describes two LDAPv3 control extensions for server side sorting of search results.\nThese controls allows a client to specify the attribute types and matching rules a server should\nuse when returning the results to an LDAP search request. The controls may be useful when the\nLDAP client has limited functionality or for some other reason cannot sort the results but still\nneeds them sorted. Other permissible controls on search operations are not defined in this\nextension.\n\nRFC-2849 The LDAP Data Interchange Format (LDIF) - Technical Specification\nhttp://www.ietf.org/rfc/rfc2849.txt\n\nThis document describes a file format suitable for describing directory information or\nmodifications made to directory information. The file format, known as LDIF, for LDAP Data\nInterchange Format, is typically used to import and export directory information between\nLDAP-based directory servers, or to describe a set of changes which are to be applied to a\ndirectory.\n\nRFC-2831 Using Digest Authentication as a SASL Mechanism\nhttp://www.ietf.org/rfc/rfc2831.txt\n\nThis specification defines how HTTP Digest Authentication can be used as a SASL [RFC 2222]\nmechanism for any protocol that has a SASL profile. It is intended both as an improvement over\nCRAM-MD5 [RFC 2195] and as a convenient way to support a single authentication mechanism for\nweb, mail, LDAP, and other protocols.\n\nRFC-2739 Calendar Attributes for vCard and LDAP\nhttp://www.ietf.org/rfc/rfc2739.txt\n\nWhen scheduling a calendar entity, such as an event, it is a prerequisite that an organizer has\nthe calendar address of each attendee that will be invited to the event. Additionally, access to\nan attendee's current \"busy time\" provides an a priori indication of whether the attendee will\nbe free to participate in the event. In order to meet these challenges, a calendar user agent\n(CUA) needs a mechanism to locate individual user's calendar and free/busy time. This memo\ndefines three mechanisms for obtaining a URI to a user's calendar and free/busy time. These\ninclude:\n\nRFC-2589 Extensions for Dynamic Directory Services\nhttp://www.ietf.org/rfc/rfc2589.txt\n\nLDAP supports lightweight access to static directory services, allowing relatively fast search\nand update access. Static directory services store information about people that persists in its\naccuracy and value over a long period of time. Dynamic directory services are different in that\nthey store information about people that only persists in its accuracy and value while people\nare online. Though the protocol operations and attributes used by dynamic directory services are\nsimilar to the ones used for static directory services, clients that are bound to a dynamic\ndirectory service need to periodically refresh their presence at the server to keep directory\nentries from getting stale in the presence of client application crashes. A flow control\nmechanism from the server is also described that allows a server to inform clients how often\nthey should refresh their presence.\n\nRFC-2559 Internet X.509 Public Key Infrastructure Operational Protocols - LDAPv2\nhttp://www.ietf.org/rfc/rfc2559.txt\n\nThe protocol described in this document is designed to satisfy some of the operational\nrequirements within the Internet X.509 PKI. Specifically, this document addresses requirements\nto provide access to PKI repositories for the purposes of retrieving PKI information and\nmanaging that same information. The mechanism described in this document is based on the LDAPv2,\ndefined in RFC 1777, defining a profile of that protocol for use within the PKIX and updates\nencodings for certificates and revocation lists from RFC 1778. Additional mechanisms addressing\nPKIX operational requirements are specified in separate documents.\n\nRFC-2247 Using Domains in LDAP/X.500 Distinguished Names\nhttp://www.ietf.org/rfc/rfc2247.txt\n\nLDAP uses X.500-compatible distinguished names for providing unique identification of entries.\nThis document defines an algorithm by which a name registered with the Internet Domain Name\nService can be represented as an LDAP distinguished name.\n\nRFC-2222 Simple Authentication and Security Layer (SASL)\nhttp://www.ietf.org/rfc/rfc2222.txt\n\nThis document describes a method for adding authentication support to connection-based\nprotocols. To use this specification, a protocol includes a command for identifying and\nauthenticating a user to a server and for optionally negotiating protection of subsequent\nprotocol interactions. If its use is negotiated, a security layer is inserted between the\nprotocol and the connection. This document describes how a protocol specifies such a command,\ndefines several mechanisms for use by the command, and defines the protocol used for carrying a\nnegotiated security layer over the connection.\n\nRFC-2218 A Common Schema for the Internet White Pages Service\nhttp://www.ietf.org/rfc/rfc2218.txt\n\nThis IETF Integrated Directory Services(IDS) Working Group proposes a standard specification for\na simple Internet White Pages service by defining a common schema for use by the various White\nPages servers. This schema is independent of specific implementations of the White Pages\nservice. This document specifies the minimum set of core attributes of a White Pages entry for\nan individual and describes how new objects with those attributes can be defined and published.\nIt does not describe how to represent other objects in the White Pages service. Further, it does\nnot address the search sort expectations within a particular service.\n\nRFC-2164 Use of an X.500/LDAP directory to support MIXER address mapping\nhttp://www.ietf.org/rfc/rfc2164.txt\n\nMIXER (RFC 2156) defines an algorithm for use of a set of global mapping between X.400 and RFC\n822 addresses. This specification defines how to represent and maintain these mappings (MIXER\nConformant Global Address Mappings of MCGAMs) in an X.500 or LDAP directory. Mechanisms for\nrepresenting OR Address and Domain hierarchies within the DIT. These techniques are used to\ndefine two independent subtrees in the DIT, which contain the mapping information.\n\nRFC-2079 Definition of an X.500 Attribute Type and an Object Class to Hold Uniform Resource Identifiers\nhttp://www.ietf.org/rfc/rfc2079.txt\n\nURLs are being widely used to specify the location of Internet resources. There is an urgent\nneed to be able to include URLs in directories that conform to the LDAP and X.500 information\nmodels, and a desire to include other types of URIs as they are defined. A number of independent\ngroups are already experimenting with the inclusion of URLs in LDAP and X.500 directories. This\ndocument builds on the experimentation to date and defines a new attribute type and an auxiliary\nobject class to allow URIs, including URLs, to be stored in directory entries in a standard way.\n", "subsections": [] }, "Other LDAP Related RFCs - Best Current Practice": { "content": "RFC-4521 Considerations for Lightweight Directory Access Protocol (LDAP) Extensions\nhttp://www.ietf.org/rfc/rfc4521.txt\n\nThe Lightweight Directory Access Protocol (LDAP) is extensible. It provides mechanisms for\nadding new operations, extending existing operations, and expanding user and system schemas.\nThis document discusses considerations for designers of LDAP extensions.\n\nRFC-4520 Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access Protocol (LDAP)\nhttp://www.ietf.org/rfc/rfc4520.txt\n\nThis document provides procedures for registering extensible elements of the Lightweight\nDirectory Access Protocol (LDAP). The document also provides guidelines to the Internet Assigned\nNumbers Authority (IANA) describing conditions under which new values can be assigned.\n\nRFC-2148 Deployment of the Internet White Pages Service\nhttp://www.ietf.org/rfc/rfc2148.txt\n\nThe Internet is used for information exchange and communication between its users. It can only\nbe effective as such if users are able to find each other's addresses. Therefore the Internet\nbenefits from an adequate White Pages Service, i.e., a directory service offering (Internet)\naddress information related to people and organizations.\n\nThis document describes the way in which the Internet White Pages Service (from now on\nabbreviated as IWPS) is best exploited using today's experience, today's protocols, today's\nproducts and today's procedures.\n", "subsections": [] }, "Other LDAP Related RFCs - Informational": { "content": "RFC-5803 Lightweight Directory Access Protocol (LDAP) Schema for Storing Salted Challenge Response Authentication Mechanism (SCRAM) Secrets\nhttp://www.ietf.org/rfc/rfc5803.txt\n\nThis memo describes how the \"authPassword\" Lightweight Directory Access Protocol (LDAP)\nattribute can be used for storing secrets used by the Salted Challenge Response Authentication\nMechanism (SCRAM) mechanism in the Simple Authentication and Security Layer (SASL) framework.\n\nRFC-4876 A Configuration Profile Schema for Lightweight Directory Access Protocol (LDAP)-Based Agents\nhttp://www.ietf.org/rfc/rfc4828.txt\n\nThis document consists of two primary components, a schema for agents that make use of the\nLightweight Directory Access protocol (LDAP) and a proposed use case of that schema, for\ndistributed configuration of similar directory user agents. A set of attribute types and an\nobject class are proposed. In the proposed use case, directory user agents (DUAs) can use this\nschema to determine directory data location and access parameters for specific services they\nsupport. In addition, in the proposed use case, attribute and object class mapping allows DUAs\nto reconfigure their expected (default) schema to match that of the end user's environment. This\ndocument is intended to be a skeleton for future documents that describe configuration of\nspecific DUA services.\n\nRFC-4529 Requesting Attributes by Object Class in the Lightweight Directory Access Protocol (LDAP)\nhttp://www.ietf.org/rfc/rfc4529.txt\n\nThe Lightweight Directory Access Protocol (LDAP) search operation provides mechanisms for\nclients to request all user application attributes, all operational attributes, and/or\nattributes selected by their description. This document extends LDAP to support a mechanism that\nLDAP clients may use to request the return of all attributes of an object class.\n\nRFC-4525 Lightweight Directory Access Protocol (LDAP) Modify-Increment Extension\nhttp://www.ietf.org/rfc/rfc4525.txt\n\nThis document describes an extension to the Lightweight Directory Access Protocol (LDAP) Modify\noperation to support an increment capability. This extension is useful in provisioning\napplications, especially when combined with the assertion control and/or the pre- read or\npost-read control extension.\n\nRFC-4403 Lightweight Directory Access Protocol (LDAP) Schema for Universal Description, Discovery, and Integration version 3 (UDDIv3)\nhttp://www.ietf.org/rfc/rfc4403.txt\n\nThis document defines the Lightweight Directory Access Protocol (LDAPv3) schema for representing\nUniversal Description, Discovery, and Integration (UDDI) data types in an LDAP directory. It\ndefines the LDAP object class and attribute definitions and containment rules to model UDDI\nentities, defined in the UDDI version 3 information model, in an LDAPv3-compliant directory.\n\nRFC-4373 Lightweight Directory Access Protocol (LDAP) Bulk Update/Replication Protocol (LBURP)\nhttp://www.ietf.org/rfc/rfc4373.txt\n\nThe Lightweight Directory Access Protocol (LDAP) Bulk Update/Replication Protocol (LBURP) allows\nan LDAP client to perform a bulk update to an LDAP server. The protocol frames a sequenced set\nof update operations within a pair of LDAP extended operations to notify the server that the\nupdate operations in the framed set are related in such a way that the ordering of all\noperations can be preserved during processing even when they are sent asynchronously by the\nclient. Update operations can be grouped within a single protocol message to maximize the\nefficiency of client-server communication.\n\nThe protocol is suitable for efficiently making a substantial set of updates to the entries in\nan LDAP server.\n\nRFC-3944 H.350 Directory Services\nhttp://www.ietf.org/rfc/rfc3944.txt\n\nThe International Telecommunications Union Standardization Sector (ITU-T) has created the H.350\nseries of Recommendations that specify directory services architectures in support of multimedia\nconferencing protocols. The goal of the architecture is to 'directory enable' multimedia\nconferencing so that these services can leverage existing identity management and enterprise\ndirectories. A particular goal is to enable an enterprise or service provider to maintain a\ncanonical source of users and their multimedia conferencing systems, so that multiple call\nservers from multiple vendors, supporting multiple protocols, can all access the same data\nstore.\n\nBecause SIP is an IETF standard, the contents of H.350 and H.350.4 are made available via this\ndocument to the IETF community. This document contains the entire normative text of ITU-T\nRecommendations H.350 and H.350.4 in sections 4 and 5, respectively. The remaining sections are\nincluded only in this document, not in the ITU-T version.\n\nRFC-3829 Lightweight Directory Access Protocol (LDAP) Authorization Identity Request and Response Controls\nhttp://www.ietf.org/rfc/rfc3829.txt\n\nThis document extends the Lightweight Directory Access Protocol (LDAP) bind operation with a\nmechanism for requesting and returning the authorization identity it establishes. Specifically,\nthis document defines the Authorization Identity Request and Response controls for use with the\nBind operation.\n\nRFC-3712 Lightweight Directory Access Protocol (LDAP): Schema for Printer Services\nhttp://www.ietf.org/rfc/rfc3712.txt\n\nThis document defines a schema, object classes and attributes, for printers and printer\nservices, for use with directories that support Lightweight Directory Access Protocol v3\n(LDAP-TS). This document is based on the printer attributes listed in Appendix E of Internet\nPrinting Protocol/1.1 (IPP) (RFC 2911). A few additional printer attributes are based on\ndefinitions in the Printer MIB (RFC 1759).\n\nRFC-3494 Lightweight Directory Access Protocol version 2 (LDAPv2) to Historic Status\nhttp://www.ietf.org/rfc/rfc3494.txt\n\nThis document recommends the retirement of version 2 of the Lightweight Directory Access\nProtocol (LDAPv2) and other dependent specifications, and discusses the reasons for doing so.\nThis document recommends RFC 1777, 1778, 1779, 1781, and 2559 (as well as documents they\nsuperseded) be moved to Historic status.\n\nRFC-3384 Lightweight Directory Access Protocol (version 3) Replication Requirements\nhttp://www.ietf.org/rfc/rfc3384.txt\n\nThis document discusses the fundamental requirements for replication of data accessible via the\nLightweight Directory Access Protocol (version 3) (LDAPv3). It is intended to be a gathering\nplace for general replication requirements needed to provide interoperability between\ninformational directories.\n\nRFC-3112 LDAP Authentication Password Schema\nhttp://www.ietf.org/rfc/rfc3112.txt\n\nThis document describes schema in support of user/password authentication in a LDAP (Lightweight\nDirectory Access Protocol) directory including the authPassword attribute type. This attribute\ntype holds values derived from the user's password(s) (commonly using cryptographic strength\none-way hash). authPassword is intended to used instead of userPassword.\n\nRFC-3045 Storing Vendor Information in the LDAP root DSE\nhttp://www.ietf.org/rfc/rfc3045.txt\n\nThis document specifies two Lightweight Directory Access Protocol (LDAP) attributes, vendorName\nand vendorVersion that MAY be included in the root DSA-specific Entry (DSE) to advertise\nvendor-specific information. These two attributes supplement the attributes defined in section\n3.4 of RFC 2251.\n\nRFC-2985 PKCS #9: Selected Object Classes and Attribute Types Version 2.0\nhttp://www.ietf.org/rfc/rfc2985.txt\n\nThis memo provides a selection of object classes and attribute types for use in conjunction with\npublic-key cryptography and Lightweight Directory Access Protocol (LDAP) accessible directories.\nIt also includes ASN.1 syntax for all constructs.\n\nRFC-2967 TISDAG - Technical Infrastructure for Swedish Directory Access Gateways\nhttp://www.ietf.org/rfc/rfc2967.txt\n\nThe strength of the TISDAG (Technical Infrastructure for Swedish Directory Access Gateways)\nproject's DAG proposal is that it defines the necessary technical infrastructure to provide a\nsingle-access- point service for information on Swedish Internet users. The resulting service\nwill provide uniform access for all information -- the same level of access to information (7x24\nservice), and the same information made available, irrespective of the service provider\nresponsible for maintaining that information, their directory service protocols, or the\nend-user's client access protocol.\n\nRFC-2927 MIME Directory Profile for LDAP Schema\nhttp://www.ietf.org/rfc/rfc2927.txt\n\nThis document defines a multipurpose internet mail extensions (MIME) directory profile for\nholding a lightweight directory access protocol (LDAP) schema. It is intended for communication\nwith the Internet schema listing service.\n\nRFC-2926 Conversion of LDAP Schemas to and from SLP Templates\nhttp://www.ietf.org/rfc/rfc2926.txt\n\nThis document describes a procedure for mapping between Service Location Protocol (SLP) service\nadvertisements and lightweight directory access protocol (LDAP) descriptions of services. The\ndocument covers two aspects of the mapping. One aspect is mapping between SLP service type\ntemplates and LDAP directory schema. Because the SLP service type template grammar is relatively\nsimple, mapping from service type templates to LDAP types is straightforward. Mapping in the\nother direction is straightforward if the attributes are restricted to use just a few of the\nsyntaxes defined in RFC 2252. If arbitrary ASN.1 types occur in the schema, then the mapping is\nmore complex and may even be impossible. The second aspect is representation of service\ninformation in an LDAP directory. The recommended representation simplifies interoperability\nwith SLP by allowing SLP directory agents to backend into LDAP directory servers. The resulting\nsystem allows service advertisements to propagate easily between SLP and LDAP.\n\nRFC-2820 Access Control Requirements for LDAP\nhttp://www.ietf.org/rfc/rfc2820.txt\n\nThis document describes the fundamental requirements of an access control list (ACL) model for\nthe LDAP directory service. It is intended to be a gathering place for access control\nrequirements needed to provide authorized access to and interoperability between directories.\n\nRFC-2798 Definition of the inetOrgPerson Object Class\nhttp://www.ietf.org/rfc/rfc2798.txt\n\nWhile the X.500 standards define many useful attribute types [X520] and object classes [X521],\nthey do not define a person object class that meets the requirements found in today's Internet\nand Intranet directory service deployments. We define a new object class called inetOrgPerson\nfor use in LDAP and X.500 directory services that extends the X.521 standard\norganizationalPerson class to meet these needs.\n\nRFC-2714 Schema for Representing CORBA Objects in an LDAP Directory\nhttp://www.ietf.org/rfc/rfc2714.txt\n\nCORBA is the Common Object Request Broker Architecture defined by the Object Management Group.\nThis document defines the schema for representing CORBA object references in an LDAP directory.\n\nRFC-2713 Schema for Representing Java Objects in an LDAP Directory\nhttp://www.ietf.org/rfc/rfc2713.txt\n\nThis document defines the schema for representing Java objects in an LDAP directory. It defines\nschema elements to represent a Java serialized object, a Java marshalled object, a Java remote\nobject, and a JNDI reference.\n\nRFC-2696 LDAP Control Extension for Simple Paged Results Manipulation\nhttp://www.ietf.org/rfc/rfc2696.txt\n\nThis document describes an LDAPv3 control extension for simple paging of search results. This\ncontrol extension allows a client to control the rate at which an LDAP server returns the\nresults of an LDAP search operation. This control may be useful when the LDAP client has limited\nresources and may not be able to process the entire result set from a given LDAP query, or when\nthe LDAP client is connected over a low-bandwidth connection. Other operations on the result set\nare not defined in this extension. This extension is not designed to provide more sophisticated\nresult set management.\n\nRFC-1823 The LDAP Application Program Interface\nhttp://www.ietf.org/rfc/rfc1823.txt\n\nThis document defines a C language application program interface to LDAP, which is designed to\nbe powerful, yet simple to use. It defines compatible synchronous and asynchronous interfaces to\nLDAP to suit a wide variety of applications. This document gives a brief overview of the LDAP\nmodel, then an overview of how the API is used by an application program to obtain LDAP\ninformation. The API calls are described in detail, followed by an appendix that provides some\nexample code demonstrating the use of the API.\n", "subsections": [] }, "Other LDAP Related RFCs - Experimental": { "content": "RFC-5805 Lightweight Directory Access Protocol (LDAP) Transactions\nhttp://www.ietf.org/rfc/rfc5805.txt\n\nLightweight Directory Access Protocol (LDAP) update operations, such as Add, Delete, and Modify\noperations, have atomic, consistency, isolation, durability (ACID) properties. Each of these\nupdate operations act upon an entry. It is often desirable to update two or more entries in a\nsingle unit of interaction, a transaction. Transactions are necessary to support a number of\napplications including resource provisioning. This document extends LDAP to support\ntransactions.\n\nRFC-4533 The Lightweight Directory Access Protocol (LDAP) Content Synchronization Operation\nhttp://www.ietf.org/rfc/rfc4533.txt\n\nThis specification describes the Lightweight Directory Access Protocol (LDAP) Content\nSynchronization Operation. The operation allows a client to maintain a copy of a fragment of the\nDirectory Information Tree (DIT). It supports both polling for changes and listening for\nchanges. The operation is defined as an extension of the LDAP Search Operation.\n\nRFC-4531 Lightweight Directory Access Protocol (LDAP) Turn Operation\nhttp://www.ietf.org/rfc/rfc4531.txt\n\nThis specification describes a Lightweight Directory Access Protocol (LDAP) extended operation\nto reverse (or \"turn\") the roles of client and server for subsequent protocol exchanges in the\nsession, or to enable each peer to act as both client and server with respect to the other.\n\nRFC-3663 Domain Administrative Data in Lightweight Directory Access Protocol (LDAP)\nhttp://www.ietf.org/rfc/rfc3663.txt\n\nDomain registration data has typically been exposed to the general public via Nicname/Whois for\nadministrative purposes. This document describes the Referral Lightweight Directory Access\nProtocol (LDAP) Service, an experimental service using LDAP and well-known LDAP types to make\ndomain administrative data available.\n\nRFC-3088 OpenLDAP Root Service - An experimental LDAP referral service\nhttp://www.ietf.org/rfc/rfc3088.txt\n\nThe OpenLDAP Project is operating an experimental LDAP (Lightweight Directory Access Protocol)\nreferral service known as the \"OpenLDAP Root Service\". The automated system generates referrals\nbased upon service location information published in DNS SRV RRs (Domain Name System location of\nservices resource records). This document describes this service.\n\nRFC-2657 LDAPv2 Client vs. the Index Mesh\nhttp://www.ietf.org/rfc/rfc2657.txt\n\nLDAPv2 clients as implemented according to RFC 1777 have no notion of referral. The integration\nbetween such a client and an Index Mesh, as defined by the Common Indexing Protocol, heavily\ndepends on referrals and therefore needs to be handled in a special way. This document defines\none possible way of doing this.\n\nRFC-2649 Signed Directory Operations Using S/MIME\nhttp://www.ietf.org/rfc/rfc2649.txt\n\nThis document defines an LDAPv3 based mechanism for signing directory operations in order to\ncreate a secure journal of changes that have been made to each directory entry. Both client and\nserver based signatures are supported. An object class for subsequent retrieval are 'journal\nentries' is also defined. This document specifies LDAPv3 controls that enable this\nfunctionality. It also defines an LDAPv3 schema that allows for subsequent browsing of the\njournal information.\n\nRFC-2307 An Approach for Using LDAP as a Network Information Service\nhttp://www.ietf.org/rfc/rfc2307.txt\n\nThis document describes an experimental mechanism for mapping entities related to TCP/IP and the\nUNIX system into X.500 entries so that they may be resolved with the LDAP. A set of attribute\ntypes and object classes are proposed, along with specific guidelines for interpreting them. The\nintention is to assist the deployment of LDAP as an organizational nameservice. No proposed\nsolutions are intended as standards for the Internet. Rather, it is hoped that a general\nconsensus will emerge as to the appropriate solution to such problems, leading eventually to the\nadoption of standards. The proposed mechanism has already been implemented with some success.\n", "subsections": [] }, "Expired but still interesting Internet Drafts": { "content": "draft-wahl-ldap-adminaddr -- Administrator Address Attribute\nOrganizations running multiple directory servers need an ability for administrators to determine\nwho is responsible for a particular server. This is conceptually similar to the 'sysContact'\nobject of SNMP. The administratorsAddress attribute allows a server administrator to provide the\ncontact information of the responsible party for an LDAP server. This can be used by management\nclients which are, for example, checking the state of a replication or referral topology, to\nprovide a way for the user of the management client to send email to manager of a particular\nserver.\n\ndraft-zeilenga-ldap-noop -- The LDAP No-Op Control\nThis document defines the Lightweight Directory Access Protocol (LDAP) No-Op control which can\nbe used to disable the normal effect of an operation. The control can be used to discover how a\nserver might react to a particular update request without updating the directory.\n\ndraft-legg-ldap-transfer -- Lightweight Directory Access Protocol (LDAP): Transfer Encoding Options\nEach attribute stored in a Lightweight Directory Access Protocol (LDAP) directory has a defined\nsyntax (i.e., data type). A syntax definition specifies how attribute values conforming to the\nsyntax are normally represented when transferred in LDAP operations. This representation is\nreferred to as the LDAP-specific encoding to distinguish it from other methods of encoding\nattribute values. This document introduces a new category of attribute options, called transfer\nencoding options, that can be used to specify that the associated attribute values are encoded\naccording to one of these other methods.\n\ndraft-furuseth-ldap-untypedobject -- Structural object class 'namedObject' for LDAP/X.500\nThis document defines an 'namedObject' structural object class for the Lightweight Directory\nAccess Protocol (LDAP) and X.500. This is useful for entries with no natural choice of\nstructural object class, e.g. if an entry must exist even though its contents are uninteresting.\n\ndraft-wahl-ldap-p3p -- P3P Policy Attributes for LDAP\nThis document defines attributes that can be retrieved via Lightweight Directory Access Protocol\nversion 3 (LDAP) requests, which contain URIs pointing to the privacy policy documents. These\ndocuments describe the privacy policy concerning access to a directory server, and the privacy\npolicies that apply to the contents of the directory (a subtree of entries).\n\ndraft-chu-ldap-xordered -- Ordered Entries and Values in LDAP\nAs LDAP is used more extensively for managing various kinds of data, one often encounters a need\nto preserve both the ordering and the content of data, despite the inherently unordered\nstructure of entries and attribute values in the directory. This document describes a scheme to\nattach ordering information to attributes in a directory so that the ordering may be preserved\nand propagated to other LDAP applications.\n\ndraft-chu-ldap-logschema -- A Schema for Logging the LDAP Protocol\nIn order to facilitate remote administration and auditing of LDAP server operation, it is\ndesirable to provide the server's operational logs themselves as a searchable LDAP directory.\nThese logs may also be used as a persistent change log to support various replication\nmechanisms. This document defines a schema that may be used to represent all of the requests\nthat have been processed by an LDAP server. It may be used by various applications for auditing,\nflight recorder, replication, and other purposes.\n\ndraft-zeilenga-ldap-relax -- The LDAP Relax Rules Control\nThis document defines the Lightweight Directory Access Protocol (LDAP) Relax Rules Control which\nallows a directory user agent (a client) to request the directory service temporarily relax\nenforcement of various data and service model rules.\n\ndraft-gpaterno-dhcp-ldap -- DHCP Option for LDAP Directory Services discovery\nThis document defines a new DHCP option for delivering configuration information for LDAP\nservices. Through this option, the client receives an LDAP URL [8] of the closest available LDAP\nserver/replica that can be used to authenticate users or look up any useful data.\n\ndraft-schleiff-ldap-xri -- LDAP Schema for eXtensible Resource Identifier (XRI)\nThis document describes Attribute Types and an Object Class for use in representing XRI\n(eXtensible Resource Identifier) values in LDAP (Lightweight Directory Access Protocol) and\nX.500 directory services.\n\ndraft-wahl-ldap-session -- LDAP Session Tracking Control\nMany network devices, application servers, and middleware components of a enterprise software\ninfrastructure generate some form of session tracking identifiers, which are useful when\nanalyzing activity and accounting logs to group activity relating to a particular session. This\ndocument discusses how Lightweight Directory Access Protocol version 3 (LDAP) clients can\ninclude session tracking identifiers with their LDAP requests. This information is provided\nthrough controls in the requests the clients send to LDAP servers. The LDAP server receiving\nthese controls can include the session tracking identifiers the log messages it writes, enabling\nLDAP requests in the LDAP server's logs to be correlated with activity in logs of other\ncomponents in the infrastructure. The control also enables session tracking information to be\ngenerated by LDAP servers and returned to clients and other servers. Three formats of session\ntracking identifiers are defined in this document.\n\ndraft-wahl-ldap-subtree-source -- LDAP Subtree Data Source URI Attribute\nThis document defines an attribute that enables administrative clients using the Lightweight\nDirectory Access Protocol (LDAP) to determine the source of directory entries.\n\ndraft-ietf-ldapext-psearch -- Persistent Search: A Simple LDAP Change Notification Mechanism\nThis document defines two controls that extend the LDAPv3 search operation to provide a simple\nmechanism by which an LDAP client can receive notification of changes that occur in an LDAP\nserver. The mechanism is designed to be very flexible yet easy for clients and servers to\nimplement.\n\ndraft-ietf-ldapext-ldapv3-vlv -- LDAP Extensions for Scrolling View Browsing of Search Results\nThis document describes a Virtual List View control extension for the LDAP Search operation.\nThis control is designed to allow the \"virtual list box\" feature, common in existing commercial\ne-mail address book applications, to be supported efficiently by LDAP servers. LDAP servers'\ninability to support this client feature is a significant impediment to LDAP replacing\nproprietary protocols in commercial e-mail systems.\n\nThe control allows a client to specify that the server return, for a given LDAP search with\nassociated sort keys, a contiguous subset of the search result set. This subset is specified in\nterms of offsets into the ordered list, or in terms of a greater than or equal comparison value.\n", "subsections": [] }, "Where to find the latest information": { "content": "Latest information on the RFCs and drafts around LDAP can be found at IETF's datatracker\n.\n", "subsections": [] } }, "summary": "Net::LDAP::RFC - List of related RFCs", "flags": [], "examples": [], "see_also": [] }