.\" Automatically generated by Pod::Man 2.27 (Pod::Simple 3.28)
.\"
.\" Standard preamble:
.\" ========================================================================
.de Sp \" Vertical space (when we can't use .PP)
.if t .sp .5v
.if n .sp
..
.de Vb \" Begin verbatim text
.ft CW
.nf
.ne \\$1
..
.de Ve \" End verbatim text
.ft R
.fi
..
.\" Set up some character translations and predefined strings.  \*(-- will
.\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left
.\" double quote, and \*(R" will give a right double quote.  \*(C+ will
.\" give a nicer C++.  Capital omega is used to do unbreakable dashes and
.\" therefore won't be available.  \*(C` and \*(C' expand to `' in nroff,
.\" nothing in troff, for use with C<>.
.tr \(*W-
.ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p'
.ie n \{\
.    ds -- \(*W-
.    ds PI pi
.    if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch
.    if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\"  diablo 12 pitch
.    ds L" ""
.    ds R" ""
.    ds C` ""
.    ds C' ""
'br\}
.el\{\
.    ds -- \|\(em\|
.    ds PI \(*p
.    ds L" ``
.    ds R" ''
.    ds C`
.    ds C'
'br\}
.\"
.\" Escape single quotes in literal strings from groff's Unicode transform.
.ie \n(.g .ds Aq \(aq
.el       .ds Aq '
.\"
.\" If the F register is turned on, we'll generate index entries on stderr for
.\" titles (.TH), headers (.SH), subsections (.SS), items (.Ip), and index
.\" entries marked with X<> in POD.  Of course, you'll have to process the
.\" output yourself in some meaningful fashion.
.\"
.\" Avoid warning from groff about undefined register 'F'.
.de IX
..
.nr rF 0
.if \n(.g .if rF .nr rF 1
.if (\n(rF:(\n(.g==0)) \{
.    if \nF \{
.        de IX
.        tm Index:\\$1\t\\n%\t"\\$2"
..
.        if !\nF==2 \{
.            nr % 0
.            nr F 2
.        \}
.    \}
.\}
.rr rF
.\"
.\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2).
.\" Fear.  Run.  Save yourself.  No user-serviceable parts.
.    \" fudge factors for nroff and troff
.if n \{\
.    ds #H 0
.    ds #V .8m
.    ds #F .3m
.    ds #[ \f1
.    ds #] \fP
.\}
.if t \{\
.    ds #H ((1u-(\\\\n(.fu%2u))*.13m)
.    ds #V .6m
.    ds #F 0
.    ds #[ \&
.    ds #] \&
.\}
.    \" simple accents for nroff and troff
.if n \{\
.    ds ' \&
.    ds ` \&
.    ds ^ \&
.    ds , \&
.    ds ~ ~
.    ds /
.\}
.if t \{\
.    ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u"
.    ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u'
.    ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u'
.    ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u'
.    ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u'
.    ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u'
.\}
.    \" troff and (daisy-wheel) nroff accents
.ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V'
.ds 8 \h'\*(#H'\(*b\h'-\*(#H'
.ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#]
.ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H'
.ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u'
.ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#]
.ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#]
.ds ae a\h'-(\w'a'u*4/10)'e
.ds Ae A\h'-(\w'A'u*4/10)'E
.    \" corrections for vroff
.if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u'
.if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u'
.    \" for low resolution devices (crt and lpr)
.if \n(.H>23 .if \n(.V>19 \
\{\
.    ds : e
.    ds 8 ss
.    ds o a
.    ds d- d\h'-1'\(ga
.    ds D- D\h'-1'\(hy
.    ds th \o'bp'
.    ds Th \o'LP'
.    ds ae ae
.    ds Ae AE
.\}
.rm #[ #] #H #V #F C
.\" ========================================================================
.\"
.IX Title "Net::LDAP::RFC 3"
.TH Net::LDAP::RFC 3 "2015-04-07" "perl v5.16.3" "User Contributed Perl Documentation"
.\" For nroff, turn off justification.  Always turn off hyphenation; it makes
.\" way too many mistakes in technical documents.
.if n .ad l
.nh
.SH "NAME"
Net::LDAP::RFC \- List of related RFCs
.SH "SYNOPSIS"
.IX Header "SYNOPSIS"
.Vb 1
\&  none
.Ve
.SH "DESCRIPTION"
.IX Header "DESCRIPTION"
The \s-1LDAP\s0 protocol is defined in the following RFCs
.SH "Core LDAP Specification"
.IX Header "Core LDAP Specification"
.SS "\s-1RFC\-4510\s0 Lightweight Directory Access Protocol (\s-1LDAP\s0): Technical Specification Road Map"
.IX Subsection "RFC-4510 Lightweight Directory Access Protocol (LDAP): Technical Specification Road Map"
http://www.ietf.org/rfc/rfc4510.txt
.PP
The Lightweight Directory Access Protocol (\s-1LDAP\s0) is an Internet
protocol for accessing distributed directory services that act in
accordance with X.500 data and service models.  This document
provides a road map of the \s-1LDAP\s0 Technical Specification.
.SS "\s-1RFC\-4511\s0 Lightweight Directory Access Protocol (\s-1LDAP\s0): The Protocol"
.IX Subsection "RFC-4511 Lightweight Directory Access Protocol (LDAP): The Protocol"
http://www.ietf.org/rfc/rfc4511.txt
.PP
This document describes the protocol elements, along with their
semantics and encodings, of the Lightweight Directory Access Protocol
(\s-1LDAP\s0).  \s-1LDAP\s0 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 (\s-1DAP\s0).
.SS "\s-1RFC\-4512\s0 Lightweight Directory Access Protocol (\s-1LDAP\s0): Directory Information Models"
.IX Subsection "RFC-4512 Lightweight Directory Access Protocol (LDAP): Directory Information Models"
http://www.ietf.org/rfc/rfc4512.txt
.PP
The Lightweight Directory Access Protocol (\s-1LDAP\s0) is an Internet
protocol for accessing distributed directory services that act in
accordance with X.500 data and service models.  This document
describes the X.500 Directory Information Models, as used in \s-1LDAP.\s0
.SS "\s-1RFC\-4513\s0 Lightweight Directory Access Protocol (\s-1LDAP\s0): Authentication Methods and Security Mechanisms"
.IX Subsection "RFC-4513 Lightweight Directory Access Protocol (LDAP): Authentication Methods and Security Mechanisms"
http://www.ietf.org/rfc/rfc4513.txt
.PP
This document describes authentication methods and security
mechanisms of the Lightweight Directory Access Protocol (\s-1LDAP\s0).  This
document details establishment of Transport Layer Security (\s-1TLS\s0)
using the StartTLS operation.
.PP
This document details the simple Bind authentication method including
anonymous, unauthenticated, and name/password mechanisms and the
Simple Authentication and Security Layer (\s-1SASL\s0) Bind authentication
method including the \s-1EXTERNAL\s0 mechanism.
.PP
This document discusses various authentication and authorization
states through which a session to an \s-1LDAP\s0 server may pass and the
actions that trigger these state changes.
.SS "\s-1RFC\-4514\s0 Lightweight Directory Access Protocol (\s-1LDAP\s0): String Representation of Distinguished Names"
.IX Subsection "RFC-4514 Lightweight Directory Access Protocol (LDAP): String Representation of Distinguished Names"
http://www.ietf.org/rfc/rfc4514.txt
.PP
The X.500 Directory uses distinguished names (DNs) as primary keys to
entries in the directory.  This document defines the string
representation used in the Lightweight Directory Access Protocol
(\s-1LDAP\s0) to transfer distinguished names.  The string representation is
designed to give a clean representation of commonly used
distinguished names, while being able to represent any distinguished
name.
.SS "\s-1RFC\-4515\s0 Lightweight Directory Access Protocol (\s-1LDAP\s0): String Representation of Search Filters"
.IX Subsection "RFC-4515 Lightweight Directory Access Protocol (LDAP): String Representation of Search Filters"
http://www.ietf.org/rfc/rfc4515.txt
.PP
Lightweight Directory Access Protocol (\s-1LDAP\s0) search filters are
transmitted in the \s-1LDAP\s0 protocol using a binary representation that
is appropriate for use on the network.  This document defines a
human-readable string representation of \s-1LDAP\s0 search filters that is
appropriate for use in \s-1LDAP\s0 URLs (\s-1RFC 4516\s0) and in other
applications.
.SS "\s-1RFC\-4516\s0 Lightweight Directory Access Protocol (\s-1LDAP\s0): Uniform Resource Locator"
.IX Subsection "RFC-4516 Lightweight Directory Access Protocol (LDAP): Uniform Resource Locator"
http://www.ietf.org/rfc/rfc4516.txt
.PP
This document describes a format for a Lightweight Directory Access
Protocol (\s-1LDAP\s0) Uniform Resource Locator (\s-1URL\s0).  An \s-1LDAP URL\s0
describes an \s-1LDAP\s0 search operation that is used to retrieve
information from an \s-1LDAP\s0 directory, or, in the context of an \s-1LDAP\s0
referral or reference, an \s-1LDAP URL\s0 describes a service where an \s-1LDAP\s0
operation may be progressed.
.SS "\s-1RFC\-4517\s0 Lightweight Directory Access Protocol (\s-1LDAP\s0): Syntaxes and Matching Rules"
.IX Subsection "RFC-4517 Lightweight Directory Access Protocol (LDAP): Syntaxes and Matching Rules"
http://www.ietf.org/rfc/rfc4517.txt
.PP
Each attribute stored in a Lightweight Directory Access Protocol
(\s-1LDAP\s0) directory, whose values may be transferred in the \s-1LDAP\s0
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 but are instead 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 \s-1LDAP\s0 directories.
.SS "\s-1RFC\-4518\s0 Lightweight Directory Access Protocol (\s-1LDAP\s0): Internationalized String Preparation"
.IX Subsection "RFC-4518 Lightweight Directory Access Protocol (LDAP): Internationalized String Preparation"
http://www.ietf.org/rfc/rfc4518.txt
.PP
The previous Lightweight Directory Access Protocol (\s-1LDAP\s0) technical
specifications did not precisely define how character string matching
is to be performed.  This led to a number of usability and
interoperability problems.  This document defines string preparation
algorithms for character-based matching rules defined for use in
\&\s-1LDAP.\s0
.SS "\s-1RFC\-4519\s0 Lightweight Directory Access Protocol (\s-1LDAP\s0): Schema for User Applications"
.IX Subsection "RFC-4519 Lightweight Directory Access Protocol (LDAP): Schema for User Applications"
http://www.ietf.org/rfc/rfc4519.txt
.PP
This document is an integral part of the Lightweight Directory Access
Protocol (\s-1LDAP\s0) technical specification.  It provides a technical
specification of attribute types and object classes intended for use
by \s-1LDAP\s0 directory clients for many directory services, such as White
Pages.  These objects are widely used as a basis for the schema in
many \s-1LDAP\s0 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.
.SH "Other LDAP Related RFCs \- Proposed Standards"
.IX Header "Other LDAP Related RFCs - Proposed Standards"
.SS "\s-1RFC\-6171\s0 The Lightweight Directory Access Protocol (\s-1LDAP\s0) Don't Use Copy Control"
.IX Subsection "RFC-6171 The Lightweight Directory Access Protocol (LDAP) Don't Use Copy Control"
http://www.ietf.org/rfc/rfc6171.txt
.PP
This document defines the Lightweight Directory Access Protocol (\s-1LDAP\s0)
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.
.SS "\s-1RFC\-5020\s0 The Lightweight Directory Access Protocol (\s-1LDAP\s0) entryDN Operational Attribute"
.IX Subsection "RFC-5020 The Lightweight Directory Access Protocol (LDAP) entryDN Operational Attribute"
http://www.ietf.org/rfc/rfc5020.txt
.PP
This document describes the \s-1LDAP/X.500 \s0'entryDN' operational
attribute.  The attribute provides a copy of the entry's distinguished
name for use in attribute value assertions.
.SS "\s-1RFC\-4792\s0 Encoding Instructions for the Generic String Encoding Rules (\s-1GSER\s0)"
.IX Subsection "RFC-4792 Encoding Instructions for the Generic String Encoding Rules (GSER)"
http://www.ietf.org/rfc/rfc4792.txt
.PP
Abstract Syntax Notation One (\s-1ASN.1\s0) defines a general framework for
annotating types in an \s-1ASN.1\s0 specification with encoding instructions
that alter how values of those types are encoded according to \s-1ASN.1\s0
encoding rules.  This document defines the supporting notation for
encoding instructions that apply to the Generic String Encoding Rules
(\s-1GSER\s0), and in particular defines an encoding instruction to provide
a machine-processable representation for the declaration of a \s-1GSER\s0
ChoiceOfStrings type.
.SS "\s-1RFC\-4532\s0 Lightweight Directory Access Protocol (\s-1LDAP\s0) Who am I? Operation"
.IX Subsection "RFC-4532 Lightweight Directory Access Protocol (LDAP) Who am I? Operation"
http://www.ietf.org/rfc/rfc4532.txt
.PP
This specification provides a mechanism for Lightweight Directory
Access Protocol (\s-1LDAP\s0) clients to obtain the authorization identity
the server has associated with the user or application entity.  This
mechanism is specified as an \s-1LDAP\s0 extended operation called the \s-1LDAP
\&\s0\*(L"Who am I?\*(R" operation.
.SS "\s-1RFC\-4530\s0 Lightweight Directory Access Protocol (\s-1LDAP\s0) entryUUID Operational Attribute"
.IX Subsection "RFC-4530 Lightweight Directory Access Protocol (LDAP) entryUUID Operational Attribute"
http://www.ietf.org/rfc/rfc4530.txt
.PP
This document describes the \s-1LDAP/X.500 \s0'entryUUID' operational
attribute and associated matching rules and syntax.  The attribute
holds a server-assigned Universally Unique Identifier (\s-1UUID\s0) for the
object.  Directory clients may use this attribute to distinguish
objects identified by a distinguished name or to locate an object
after renaming.
.SS "\s-1RFC\-4528\s0 Lightweight Directory Access Protocol (\s-1LDAP\s0) Assertion Control"
.IX Subsection "RFC-4528 Lightweight Directory Access Protocol (LDAP) Assertion Control"
http://www.ietf.org/rfc/rfc4528.txt
.PP
This document defines the Lightweight Directory Access Protocol
(\s-1LDAP\s0) 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 \*(L"test and set\*(R", \*(L"test and clear\*(R", and other conditional
operations.
.SS "\s-1RFC\-4527\s0 Lightweight Directory Access Protocol (\s-1LDAP\s0) Read Entry Controls"
.IX Subsection "RFC-4527 Lightweight Directory Access Protocol (LDAP) Read Entry Controls"
http://www.ietf.org/rfc/rfc4527.txt
.PP
This document specifies an extension to the Lightweight Directory
Access Protocol (\s-1LDAP\s0) 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.
.SS "\s-1RFC\-4526\s0 Lightweight Directory Access Protocol (\s-1LDAP\s0) Absolute True and False Filters"
.IX Subsection "RFC-4526 Lightweight Directory Access Protocol (LDAP) Absolute True and False Filters"
http://www.ietf.org/rfc/rfc4526.txt
.PP
This document extends the Lightweight Directory Access Protocol
(\s-1LDAP\s0) 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 \s-1LDAP\s0 Search Filters to support
these filters.
.SS "\s-1RFC\-4524 COSINE LDAP/X.500\s0 Schema"
.IX Subsection "RFC-4524 COSINE LDAP/X.500 Schema"
http://www.ietf.org/rfc/rfc4524.txt
.PP
This document provides a collection of schema elements for use with
the Lightweight Directory Access Protocol (\s-1LDAP\s0) from the \s-1COSINE\s0 and
Internet X.500 pilot projects.
.SS "\s-1RFC\-4523\s0 Lightweight Directory Access Protocol (\s-1LDAP\s0) Schema Definitions for X.509 Certificates"
.IX Subsection "RFC-4523 Lightweight Directory Access Protocol (LDAP) Schema Definitions for X.509 Certificates"
http://www.ietf.org/rfc/rfc4523.txt
.PP
This document describes schema for representing X.509 certificates,
X.521 security information, and related elements in directories
accessible using the Lightweight Directory Access Protocol (\s-1LDAP\s0).
The \s-1LDAP\s0 definitions for these X.509 and X.521 schema elements
replace those provided in RFCs 2252 and 2256.
.SS "\s-1RFC\-4522\s0 Lightweight Directory Access Protocol (\s-1LDAP\s0): The Binary Encoding Option"
.IX Subsection "RFC-4522 Lightweight Directory Access Protocol (LDAP): The Binary Encoding Option"
http://www.ietf.org/rfc/rfc4522.txt
.PP
Each attribute stored in a Lightweight Directory Access Protocol
(\s-1LDAP\s0) 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 \s-1LDAP\s0 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 (\s-1BER\s0) used by X.500
directories.
.SS "\s-1RFC\-4370\s0 Lightweight Directory Access Protocol (\s-1LDAP\s0) Proxied Authorization Control"
.IX Subsection "RFC-4370 Lightweight Directory Access Protocol (LDAP) Proxied Authorization Control"
http://www.ietf.org/rfc/rfc4370.txt
.PP
This document defines the Lightweight Directory Access Protocol
(\s-1LDAP\s0) 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.
.SS "\s-1RFC\-4104\s0 Policy Core Extension Lightweight Directory Access Protocol Schema (\s-1PCELS\s0)"
.IX Subsection "RFC-4104 Policy Core Extension Lightweight Directory Access Protocol Schema (PCELS)"
http://www.ietf.org/rfc/rfc4104.txt
.PP
This document defines a number of changes and extensions to the
Policy Core Lightweight Directory Access Protocol (\s-1LDAP\s0) Schema (\s-1RFC
3703\s0) based on the model extensions defined by the Policy Core
Information Model (\s-1PCIM\s0) Extensions (\s-1RFC 3460\s0).  These changes and
extensions consist of new \s-1LDAP\s0 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 \s-1RFC 3460. \s0 The other schema items implement new concepts, not
covered by \s-1RFC 3703. \s0 This document updates \s-1RFC 3703.\s0
.SS "\s-1RFC\-3928\s0 Lightweight Directory Access Protocol (\s-1LDAP\s0) Client Update Protocol (\s-1LCUP\s0)"
.IX Subsection "RFC-3928 Lightweight Directory Access Protocol (LDAP) Client Update Protocol (LCUP)"
http://www.ietf.org/rfc/rfc3928.txt
.PP
This document defines the Lightweight Directory Access Protocol
(\s-1LDAP\s0) Client Update Protocol (\s-1LCUP\s0).  The protocol is intended to
allow an \s-1LDAP\s0 client to synchronize with the content of a directory
information tree (\s-1DIT\s0) stored by an \s-1LDAP\s0 server and to be notified
about the changes to that content.
.SS "\s-1RFC\-3909\s0 Lightweight Directory Access Protocol (\s-1LDAP\s0) Cancel Operation"
.IX Subsection "RFC-3909 Lightweight Directory Access Protocol (LDAP) Cancel Operation"
http://www.ietf.org/rfc/rfc3909.txt
.PP
This specification describes a Lightweight Directory Access Protocol
(\s-1LDAP\s0) extended operation to cancel (or abandon) an outstanding
operation.  Unlike the \s-1LDAP\s0 Abandon operation, but like the X.511
Directory Access Protocol (\s-1DAP\s0) Abandon operation, this operation has
a response which provides an indication of its outcome.
.SS "\s-1RFC\-3876\s0 Returning Matched Values with the Lightweight Directory Access Protocol version 3 (LDAPv3)"
.IX Subsection "RFC-3876 Returning Matched Values with the Lightweight Directory Access Protocol version 3 (LDAPv3)"
http://www.ietf.org/rfc/rfc3876.txt
.PP
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 \*(L"values return\*(R" filter.  Without support for this control, a
client must retrieve all of an attribute's values and search for
specific values locally.
.SS "\s-1RFC\-3866\s0 Language Tags and Ranges in the Lightweight Directory Access Protocol (\s-1LDAP\s0)"
.IX Subsection "RFC-3866 Language Tags and Ranges in the Lightweight Directory Access Protocol (LDAP)"
http://www.ietf.org/rfc/rfc3866.txt
.PP
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 (\s-1LDAP\s0).
.SS "\s-1RFC\-3727 ASN.1\s0 Module Definition for the \s-1LDAP\s0 and X.500 Component Matching Rules"
.IX Subsection "RFC-3727 ASN.1 Module Definition for the LDAP and X.500 Component Matching Rules"
http://www.ietf.org/rfc/rfc3727.txt
.PP
This document updates the specification of the component matching
rules for Lightweight Directory Access Protocol (\s-1LDAP\s0) and X.500
directories (\s-1RFC3687\s0) by collecting the Abstract Syntax Notation One
(\s-1ASN.1\s0) definitions of the component matching rules into an
appropriately identified \s-1ASN.1\s0 module so that other specifications
may reference the component matching rule definitions from within
their own \s-1ASN.1\s0 modules.
.SS "\s-1RFC\-3703\s0 Policy Core Lightweight Directory Access Protocol (\s-1LDAP\s0) Schema"
.IX Subsection "RFC-3703 Policy Core Lightweight Directory Access Protocol (LDAP) Schema"
http://www.ietf.org/rfc/rfc3703.txt
.PP
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 (\s-1LDAP\s0) 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 \s-1RFC 3060,\s0 and relationship classes that
indicate how instances of the structural classes are related to each
other.  Classes are also added to the \s-1LDAP\s0 schema to improve the
performance of a client's interactions with an \s-1LDAP\s0 server when the
client is retrieving large amounts of policy-related information.
These classes exist only to optimize \s-1LDAP\s0 retrievals: there are no
classes in the information model that correspond to them.
.SS "\s-1RFC\-3698\s0 Lightweight Directory Access Protocol (\s-1LDAP\s0): Additional Matching Rules"
.IX Subsection "RFC-3698 Lightweight Directory Access Protocol (LDAP): Additional Matching Rules"
http://www.ietf.org/rfc/rfc3698.txt
.PP
This document provides a collection of matching rules for use with
the Lightweight Directory Access Protocol (\s-1LDAP\s0).  As these matching
rules are simple adaptations of matching rules specified for use with
the X.500 Directory, most are already in wide use.
.SS "\s-1RFC\-3687\s0 Lightweight Directory Access Protocol (\s-1LDAP\s0) and X.500 Component Matching Rules"
.IX Subsection "RFC-3687 Lightweight Directory Access Protocol (LDAP) and X.500 Component Matching Rules"
http://www.ietf.org/rfc/rfc3687.txt
.PP
The syntaxes of attributes in a Lightweight Directory Access Protocol
(\s-1LDAP\s0) 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.
.SS "\s-1RFC\-3672\s0 Subentries in the Lightweight Directory Access Protocol (\s-1LDAP\s0)"
.IX Subsection "RFC-3672 Subentries in the Lightweight Directory Access Protocol (LDAP)"
http://www.ietf.org/rfc/rfc3672.txt
.PP
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 (\s-1LDAP\s0).
.SS "\s-1RFC\-3671\s0 Collective Attributes in the Lightweight Directory Access Protocol (\s-1LDAP\s0)"
.IX Subsection "RFC-3671 Collective Attributes in the Lightweight Directory Access Protocol (LDAP)"
http://www.ietf.org/rfc/rfc3671.txt
.PP
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 \s-1LDAP \s0(Lightweight Directory Access
Protocol).  This document provides schema definitions for collective
attributes for use in \s-1LDAP.\s0
.SS "\s-1RFC\-3296\s0 Named Subordinate References in Lightweight Directory Access Protocol (\s-1LDAP\s0) Directories"
.IX Subsection "RFC-3296 Named Subordinate References in Lightweight Directory Access Protocol (LDAP) Directories"
http://www.ietf.org/rfc/rfc3296.txt
.PP
This document details schema and protocol elements for representing
and managing named subordinate references in Lightweight Directory
Access Protocol (\s-1LDAP\s0) Directories.
.SS "\s-1RFC\-3062 LDAP\s0 Password Modify Extended Operation"
.IX Subsection "RFC-3062 LDAP Password Modify Extended Operation"
http://www.ietf.org/rfc/rfc3062.txt
.PP
The integration of the Lightweight Directory Access Protocol (\s-1LDAP\s0)
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 \s-1LDAP\s0 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.
.SS "\s-1RFC\-2891 LDAP\s0 Control Extension for Server Side Sorting of Search Results"
.IX Subsection "RFC-2891 LDAP Control Extension for Server Side Sorting of Search Results"
http://www.ietf.org/rfc/rfc2891.txt
.PP
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 \s-1LDAP\s0 search
request. The controls may be useful when the \s-1LDAP\s0 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.
.SS "\s-1RFC\-2849\s0 The \s-1LDAP\s0 Data Interchange Format (\s-1LDIF\s0) \- Technical Specification"
.IX Subsection "RFC-2849 The LDAP Data Interchange Format (LDIF) - Technical Specification"
http://www.ietf.org/rfc/rfc2849.txt
.PP
This document describes a file format suitable for describing
directory information or modifications made to directory
information. The file format, known as \s-1LDIF,\s0 for \s-1LDAP\s0 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.
.SS "\s-1RFC\-2831\s0 Using Digest Authentication as a \s-1SASL\s0 Mechanism"
.IX Subsection "RFC-2831 Using Digest Authentication as a SASL Mechanism"
http://www.ietf.org/rfc/rfc2831.txt
.PP
This specification defines how \s-1HTTP\s0 Digest Authentication can
be used as a \s-1SASL\s0 [\s-1RFC 2222\s0] mechanism for any protocol that
has a \s-1SASL\s0 profile. It is intended both as an improvement over
\&\s-1CRAM\-MD5\s0 [\s-1RFC 2195\s0] and as a convenient way to support a single
authentication mechanism for web, mail, \s-1LDAP,\s0 and other
protocols.
.SS "\s-1RFC\-2739\s0 Calendar Attributes for vCard and \s-1LDAP\s0"
.IX Subsection "RFC-2739 Calendar Attributes for vCard and LDAP"
http://www.ietf.org/rfc/rfc2739.txt
.PP
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 \*(L"busy time\*(R" 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 (\s-1CUA\s0) needs a mechanism to locate
individual user's calendar and free/busy time. This memo
defines three mechanisms for obtaining a \s-1URI\s0 to a user's
calendar and free/busy time. These include:
.SS "\s-1RFC\-2589\s0 Extensions for Dynamic Directory Services"
.IX Subsection "RFC-2589 Extensions for Dynamic Directory Services"
http://www.ietf.org/rfc/rfc2589.txt
.PP
\&\s-1LDAP\s0 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.
.SS "\s-1RFC\-2559\s0 Internet X.509 Public Key Infrastructure Operational Protocols \- LDAPv2"
.IX Subsection "RFC-2559 Internet X.509 Public Key Infrastructure Operational Protocols - LDAPv2"
http://www.ietf.org/rfc/rfc2559.txt
.PP
The protocol described in this document is designed to satisfy
some of the operational requirements within the Internet X.509
\&\s-1PKI.\s0 Specifically, this document addresses requirements to
provide access to \s-1PKI\s0 repositories for the purposes of
retrieving \s-1PKI\s0 information and managing that same information.
The mechanism described in this document is based on the
LDAPv2, defined in \s-1RFC 1777,\s0 defining a profile of that
protocol for use within the \s-1PKIX\s0 and updates encodings for
certificates and revocation lists from \s-1RFC 1778.\s0 Additional
mechanisms addressing \s-1PKIX\s0 operational requirements are
specified in separate documents.
.SS "\s-1RFC\-2247\s0 Using Domains in \s-1LDAP/X.500\s0 Distinguished Names"
.IX Subsection "RFC-2247 Using Domains in LDAP/X.500 Distinguished Names"
http://www.ietf.org/rfc/rfc2247.txt
.PP
\&\s-1LDAP\s0 uses X.500\-compatible distinguished names for providing
unique identification of entries. This document defines an
algorithm by which a name registered with the Internet Domain
Name Service can be represented as an \s-1LDAP\s0 distinguished name.
.SS "\s-1RFC\-2222\s0 Simple Authentication and Security Layer (\s-1SASL\s0)"
.IX Subsection "RFC-2222 Simple Authentication and Security Layer (SASL)"
http://www.ietf.org/rfc/rfc2222.txt
.PP
This document describes a method for adding authentication
support to connection-based protocols. To use this
specification, a protocol includes a command for identifying
and authenticating a user to a server and for optionally
negotiating protection of subsequent protocol interactions. If
its use is negotiated, a security layer is inserted between the
protocol and the connection. This 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.
.SS "\s-1RFC\-2218 A\s0 Common Schema for the Internet White Pages Service"
.IX Subsection "RFC-2218 A Common Schema for the Internet White Pages Service"
http://www.ietf.org/rfc/rfc2218.txt
.PP
This \s-1IETF\s0 Integrated Directory Services(\s-1IDS\s0) Working Group
proposes a standard specification for a simple Internet White
Pages service by defining a common schema for use by the
various White Pages servers. This schema is independent of
specific implementations of the White Pages service. This
document 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. Further, it does not address the search sort
expectations within a particular service.
.SS "\s-1RFC\-2164\s0 Use of an X.500/LDAP directory to support \s-1MIXER\s0 address mapping"
.IX Subsection "RFC-2164 Use of an X.500/LDAP directory to support MIXER address mapping"
http://www.ietf.org/rfc/rfc2164.txt
.PP
\&\s-1MIXER \s0(\s-1RFC 2156\s0) defines an algorithm for use of a set of
global mapping between X.400 and \s-1RFC 822\s0 addresses. This
specification defines how to represent and maintain these
mappings (\s-1MIXER\s0 Conformant Global Address Mappings of MCGAMs)
in an X.500 or \s-1LDAP\s0 directory. Mechanisms for representing \s-1OR\s0
Address and Domain hierarchies within the \s-1DIT.\s0 These techniques
are used to define two independent subtrees in the \s-1DIT,\s0 which
contain the mapping information.
.SS "\s-1RFC\-2079\s0 Definition of an X.500 Attribute Type and an Object Class to Hold Uniform Resource Identifiers"
.IX Subsection "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
.PP
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 \s-1LDAP\s0 and X.500 information
models, and a desire to include other types of URIs as they are
defined. A number of independent groups are already
experimenting with the inclusion of URLs in \s-1LDAP\s0 and X.500
directories. This document builds on the experimentation to
date and defines a new attribute type and an auxiliary object
class to allow URIs, including URLs, to be stored in directory
entries in a standard way.
.SH "Other LDAP Related RFCs \- Best Current Practice"
.IX Header "Other LDAP Related RFCs - Best Current Practice"
.SS "\s-1RFC\-4521\s0 Considerations for Lightweight Directory Access Protocol (\s-1LDAP\s0) Extensions"
.IX Subsection "RFC-4521 Considerations for Lightweight Directory Access Protocol (LDAP) Extensions"
http://www.ietf.org/rfc/rfc4521.txt
.PP
The Lightweight Directory Access Protocol (\s-1LDAP\s0) 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 \s-1LDAP\s0 extensions.
.SS "\s-1RFC\-4520\s0 Internet Assigned Numbers Authority (\s-1IANA\s0) Considerations for the Lightweight Directory Access Protocol (\s-1LDAP\s0)"
.IX Subsection "RFC-4520 Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access Protocol (LDAP)"
http://www.ietf.org/rfc/rfc4520.txt
.PP
This document provides procedures for registering extensible elements
of the Lightweight Directory Access Protocol (\s-1LDAP\s0).  The document
also provides guidelines to the Internet Assigned Numbers Authority
(\s-1IANA\s0) describing conditions under which new values can be assigned.
.SS "\s-1RFC\-2148\s0 Deployment of the Internet White Pages Service"
.IX Subsection "RFC-2148 Deployment of the Internet White Pages Service"
http://www.ietf.org/rfc/rfc2148.txt
.PP
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.
.PP
This document describes the way in which the Internet White Pages
Service (from now on abbreviated as \s-1IWPS\s0) is best exploited using
today's experience, today's protocols, today's products and today's
procedures.
.SH "Other LDAP Related RFCs \- Informational"
.IX Header "Other LDAP Related RFCs - Informational"
.SS "\s-1RFC\-5803\s0 Lightweight Directory Access Protocol (\s-1LDAP\s0) Schema for Storing Salted Challenge Response Authentication Mechanism (\s-1SCRAM\s0) Secrets"
.IX Subsection "RFC-5803 Lightweight Directory Access Protocol (LDAP) Schema for Storing Salted Challenge Response Authentication Mechanism (SCRAM) Secrets"
http://www.ietf.org/rfc/rfc5803.txt
.PP
This memo describes how the \*(L"authPassword\*(R" Lightweight Directory
Access Protocol (\s-1LDAP\s0) attribute can be used for storing secrets used
by the Salted Challenge Response Authentication Mechanism (\s-1SCRAM\s0)
mechanism in the Simple Authentication and Security Layer (\s-1SASL\s0)
framework.
.SS "\s-1RFC\-4876 A\s0 Configuration Profile Schema for Lightweight Directory Access Protocol (\s-1LDAP\s0)\-Based Agents"
.IX Subsection "RFC-4876 A Configuration Profile Schema for Lightweight Directory Access Protocol (LDAP)-Based Agents"
http://www.ietf.org/rfc/rfc4828.txt
.PP
This document consists of two primary components, a schema for agents
that make use of the Lightweight Directory Access protocol (\s-1LDAP\s0) 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.
In addition, 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 \s-1DUA\s0 services.
.SS "\s-1RFC\-4529\s0 Requesting Attributes by Object Class in the Lightweight Directory Access Protocol (\s-1LDAP\s0)"
.IX Subsection "RFC-4529 Requesting Attributes by Object Class in the Lightweight Directory Access Protocol (LDAP)"
http://www.ietf.org/rfc/rfc4529.txt
.PP
The Lightweight Directory Access Protocol (\s-1LDAP\s0) 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 \s-1LDAP\s0 to support a mechanism
that \s-1LDAP\s0 clients may use to request the return of all attributes of
an object class.
.SS "\s-1RFC\-4525\s0 Lightweight Directory Access Protocol (\s-1LDAP\s0) Modify-Increment Extension"
.IX Subsection "RFC-4525 Lightweight Directory Access Protocol (LDAP) Modify-Increment Extension"
http://www.ietf.org/rfc/rfc4525.txt
.PP
This document describes an extension to the Lightweight Directory
Access Protocol (\s-1LDAP\s0) Modify operation to support an increment
capability.  This extension is useful in provisioning applications,
especially when combined with the assertion control and/or the pre\-
read or post-read control extension.
.SS "\s-1RFC\-4403\s0 Lightweight Directory Access Protocol (\s-1LDAP\s0) Schema for Universal Description, Discovery, and Integration version 3 (UDDIv3)"
.IX Subsection "RFC-4403 Lightweight Directory Access Protocol (LDAP) Schema for Universal Description, Discovery, and Integration version 3 (UDDIv3)"
http://www.ietf.org/rfc/rfc4403.txt
.PP
This document defines the Lightweight Directory Access Protocol
(LDAPv3) schema for representing Universal Description, Discovery,
and Integration (\s-1UDDI\s0) data types in an \s-1LDAP\s0 directory.  It defines
the \s-1LDAP\s0 object class and attribute definitions and containment rules
to model \s-1UDDI\s0 entities, defined in the \s-1UDDI\s0 version 3 information
model, in an LDAPv3\-compliant directory.
.SS "\s-1RFC\-4373\s0 Lightweight Directory Access Protocol (\s-1LDAP\s0) Bulk Update/Replication Protocol (\s-1LBURP\s0)"
.IX Subsection "RFC-4373 Lightweight Directory Access Protocol (LDAP) Bulk Update/Replication Protocol (LBURP)"
http://www.ietf.org/rfc/rfc4373.txt
.PP
The Lightweight Directory Access Protocol (\s-1LDAP\s0) Bulk
Update/Replication Protocol (\s-1LBURP\s0) allows an \s-1LDAP\s0 client to perform
a bulk update to an \s-1LDAP\s0 server.  The protocol frames a sequenced set
of update operations within a pair of \s-1LDAP\s0 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 are sent asynchronously by
the client.  Update operations can be grouped within a single
protocol message to maximize the efficiency of client-server
communication.
.PP
The protocol is suitable for efficiently making a substantial set of
updates to the entries in an \s-1LDAP\s0 server.
.SS "\s-1RFC\-3944 H.350\s0 Directory Services"
.IX Subsection "RFC-3944 H.350 Directory Services"
http://www.ietf.org/rfc/rfc3944.txt
.PP
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 that 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.
.PP
Because \s-1SIP\s0 is an \s-1IETF\s0 standard, the contents of H.350 and H.350.4
are made available via this document to the \s-1IETF\s0 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.
.SS "\s-1RFC\-3829\s0 Lightweight Directory Access Protocol (\s-1LDAP\s0) Authorization Identity Request and Response Controls"
.IX Subsection "RFC-3829 Lightweight Directory Access Protocol (LDAP) Authorization Identity Request and Response Controls"
http://www.ietf.org/rfc/rfc3829.txt
.PP
This document extends the Lightweight Directory Access Protocol
(\s-1LDAP\s0) bind operation with a mechanism for requesting and returning
the authorization identity it establishes.  Specifically, this
document defines the Authorization Identity Request and Response
controls for use with the Bind operation.
.SS "\s-1RFC\-3712\s0 Lightweight Directory Access Protocol (\s-1LDAP\s0): Schema for Printer Services"
.IX Subsection "RFC-3712 Lightweight Directory Access Protocol (LDAP): Schema for Printer Services"
http://www.ietf.org/rfc/rfc3712.txt
.PP
This document 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).  This document is
based on the printer attributes listed in Appendix E of Internet
Printing Protocol/1.1 (\s-1IPP\s0) (\s-1RFC 2911\s0).  A few additional printer
attributes are based on definitions in the Printer \s-1MIB \s0(\s-1RFC 1759\s0).
.SS "\s-1RFC\-3494\s0 Lightweight Directory Access Protocol version 2 (LDAPv2) to Historic Status"
.IX Subsection "RFC-3494 Lightweight Directory Access Protocol version 2 (LDAPv2) to Historic Status"
http://www.ietf.org/rfc/rfc3494.txt
.PP
This document recommends the retirement of version 2 of the
Lightweight Directory Access Protocol (LDAPv2) and other dependent
specifications, and discusses the reasons for doing so.  This
document recommends \s-1RFC 1777, 1778, 1779, 1781,\s0 and 2559 (as well as
documents they superseded) be moved to Historic status.
.SS "\s-1RFC\-3384\s0 Lightweight Directory Access Protocol (version 3) Replication Requirements"
.IX Subsection "RFC-3384 Lightweight Directory Access Protocol (version 3) Replication Requirements"
http://www.ietf.org/rfc/rfc3384.txt
.PP
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.
.SS "\s-1RFC\-3112 LDAP\s0 Authentication Password Schema"
.IX Subsection "RFC-3112 LDAP Authentication Password Schema"
http://www.ietf.org/rfc/rfc3112.txt
.PP
This document describes schema in support of user/password
authentication in a \s-1LDAP \s0(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
used instead of userPassword.
.SS "\s-1RFC\-3045\s0 Storing Vendor Information in the \s-1LDAP\s0 root \s-1DSE\s0"
.IX Subsection "RFC-3045 Storing Vendor Information in the LDAP root DSE"
http://www.ietf.org/rfc/rfc3045.txt
.PP
This document specifies two Lightweight Directory Access Protocol
(\s-1LDAP\s0) attributes, vendorName and vendorVersion that \s-1MAY\s0 be included
in the root DSA-specific Entry (\s-1DSE\s0) to advertise vendor-specific
information.  These two attributes supplement the attributes defined
in section 3.4 of \s-1RFC 2251.\s0
.SS "\s-1RFC\-2985 PKCS\s0 #9: Selected Object Classes and Attribute Types Version 2.0"
.IX Subsection "RFC-2985 PKCS #9: Selected Object Classes and Attribute Types Version 2.0"
http://www.ietf.org/rfc/rfc2985.txt
.PP
This memo provides a selection of object classes and attribute types
for use in conjunction with public-key cryptography and Lightweight
Directory Access Protocol (\s-1LDAP\s0) accessible directories.  It also
includes \s-1ASN.1\s0 syntax for all constructs.
.SS "\s-1RFC\-2967 TISDAG \-\s0 Technical Infrastructure for Swedish Directory Access Gateways"
.IX Subsection "RFC-2967 TISDAG - Technical Infrastructure for Swedish Directory Access Gateways"
http://www.ietf.org/rfc/rfc2967.txt
.PP
The strength of the \s-1TISDAG \s0(Technical Infrastructure for Swedish
Directory Access Gateways) project's \s-1DAG\s0 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.
.SS "\s-1RFC\-2927 MIME\s0 Directory Profile for \s-1LDAP\s0 Schema"
.IX Subsection "RFC-2927 MIME Directory Profile for LDAP Schema"
http://www.ietf.org/rfc/rfc2927.txt
.PP
This document defines a multipurpose internet mail extensions (\s-1MIME\s0)
directory profile for holding a lightweight directory access protocol
(\s-1LDAP\s0) schema.  It is intended for communication with the Internet
schema listing service.
.SS "\s-1RFC\-2926\s0 Conversion of \s-1LDAP\s0 Schemas to and from \s-1SLP\s0 Templates"
.IX Subsection "RFC-2926 Conversion of LDAP Schemas to and from SLP Templates"
http://www.ietf.org/rfc/rfc2926.txt
.PP
This document describes a procedure for mapping between Service
Location Protocol (\s-1SLP\s0) service advertisements and lightweight
directory access protocol (\s-1LDAP\s0) descriptions of services.  The
document covers two aspects of the mapping.  One aspect is mapping
between \s-1SLP\s0 service type templates and \s-1LDAP\s0 directory schema.
Because the \s-1SLP\s0 service type template grammar is relatively simple,
mapping from service type templates to \s-1LDAP\s0 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 \s-1RFC 2252.\s0
If arbitrary \s-1ASN.1\s0 types occur in the schema, then the mapping is
more complex and may even be impossible.  The second aspect is
representation of service information in an \s-1LDAP\s0 directory.  The
recommended representation simplifies interoperability with \s-1SLP\s0 by
allowing \s-1SLP\s0 directory agents to backend into \s-1LDAP\s0 directory servers.
The resulting system allows service advertisements to propagate
easily between \s-1SLP\s0 and \s-1LDAP.\s0
.SS "\s-1RFC\-2820\s0 Access Control Requirements for \s-1LDAP\s0"
.IX Subsection "RFC-2820 Access Control Requirements for LDAP"
http://www.ietf.org/rfc/rfc2820.txt
.PP
This document describes the fundamental requirements of an
access control list (\s-1ACL\s0) model for the \s-1LDAP\s0 directory service.
It is intended to be a gathering place for access control
requirements needed to provide authorized access to and
interoperability between directories.
.SS "\s-1RFC\-2798\s0 Definition of the inetOrgPerson Object Class"
.IX Subsection "RFC-2798 Definition of the inetOrgPerson Object Class"
http://www.ietf.org/rfc/rfc2798.txt
.PP
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 \s-1LDAP\s0 and
X.500 directory services that extends the X.521 standard
organizationalPerson class to meet these needs.
.SS "\s-1RFC\-2714\s0 Schema for Representing \s-1CORBA\s0 Objects in an \s-1LDAP\s0 Directory"
.IX Subsection "RFC-2714 Schema for Representing CORBA Objects in an LDAP Directory"
http://www.ietf.org/rfc/rfc2714.txt
.PP
\&\s-1CORBA\s0 is the Common Object Request Broker Architecture defined
by the Object Management Group. This document defines the
schema for representing \s-1CORBA\s0 object references in an \s-1LDAP\s0
directory.
.SS "\s-1RFC\-2713\s0 Schema for Representing Java Objects in an \s-1LDAP\s0 Directory"
.IX Subsection "RFC-2713 Schema for Representing Java Objects in an LDAP Directory"
http://www.ietf.org/rfc/rfc2713.txt
.PP
This document defines the schema for representing Java objects
in an \s-1LDAP\s0 directory. It defines schema elements to represent a
Java serialized object, a Java marshalled object, a Java remote
object, and a \s-1JNDI\s0 reference.
.SS "\s-1RFC\-2696 LDAP\s0 Control Extension for Simple Paged Results Manipulation"
.IX Subsection "RFC-2696 LDAP Control Extension for Simple Paged Results Manipulation"
http://www.ietf.org/rfc/rfc2696.txt
.PP
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 \s-1LDAP\s0 server returns the
results of an \s-1LDAP\s0 search operation. This control may be useful
when the \s-1LDAP\s0 client has limited resources and may not be able
to process the entire result set from a given \s-1LDAP\s0 query, or
when the \s-1LDAP\s0 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.
.SS "\s-1RFC\-1823\s0 The \s-1LDAP\s0 Application Program Interface"
.IX Subsection "RFC-1823 The LDAP Application Program Interface"
http://www.ietf.org/rfc/rfc1823.txt
.PP
This document defines a C language application program
interface to \s-1LDAP,\s0 which is designed to be powerful, yet simple
to use. It defines compatible synchronous and asynchronous
interfaces to \s-1LDAP\s0 to suit a wide variety of applications. This
document gives a brief overview of the \s-1LDAP\s0 model, then an
overview of how the \s-1API\s0 is used by an application program to
obtain \s-1LDAP\s0 information. The \s-1API\s0 calls are described in detail,
followed by an appendix that provides some example code
demonstrating the use of the \s-1API.\s0
.SH "Other LDAP Related RFCs \- Experimental"
.IX Header "Other LDAP Related RFCs - Experimental"
.SS "\s-1RFC\-5805\s0 Lightweight Directory Access Protocol (\s-1LDAP\s0) Transactions"
.IX Subsection "RFC-5805 Lightweight Directory Access Protocol (LDAP) Transactions"
http://www.ietf.org/rfc/rfc5805.txt
.PP
Lightweight Directory Access Protocol (\s-1LDAP\s0) update operations, such
as Add, Delete, and Modify operations, have atomic, consistency,
isolation, durability (\s-1ACID\s0) properties.  Each of these update
operations act upon an entry.  It is often desirable to update two or
more entries in a single unit of interaction, a transaction.
Transactions are necessary to support a number of applications
including resource provisioning.  This document extends \s-1LDAP\s0 to
support transactions.
.SS "\s-1RFC\-4533\s0 The Lightweight Directory Access Protocol (\s-1LDAP\s0) Content Synchronization Operation"
.IX Subsection "RFC-4533 The Lightweight Directory Access Protocol (LDAP) Content Synchronization Operation"
http://www.ietf.org/rfc/rfc4533.txt
.PP
This specification describes the Lightweight Directory Access
Protocol (\s-1LDAP\s0) Content Synchronization Operation.  The operation
allows a client to maintain a copy of a fragment of the Directory
Information Tree (\s-1DIT\s0).  It supports both polling for changes and
listening for changes.  The operation is defined as an extension of
the \s-1LDAP\s0 Search Operation.
.SS "\s-1RFC\-4531\s0 Lightweight Directory Access Protocol (\s-1LDAP\s0) Turn Operation"
.IX Subsection "RFC-4531 Lightweight Directory Access Protocol (LDAP) Turn Operation"
http://www.ietf.org/rfc/rfc4531.txt
.PP
This specification describes a Lightweight Directory Access Protocol
(\s-1LDAP\s0) extended operation to reverse (or \*(L"turn\*(R") the roles of client
and server for subsequent protocol exchanges in the session, or to
enable each peer to act as both client and server with respect to the
other.
.SS "\s-1RFC\-3663\s0 Domain Administrative Data in Lightweight Directory Access Protocol (\s-1LDAP\s0)"
.IX Subsection "RFC-3663 Domain Administrative Data in Lightweight Directory Access Protocol (LDAP)"
http://www.ietf.org/rfc/rfc3663.txt
.PP
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 (\s-1LDAP\s0)
Service, an experimental service using \s-1LDAP\s0 and well-known \s-1LDAP\s0 types
to make domain administrative data available.
.SS "\s-1RFC\-3088\s0 OpenLDAP Root Service \- An experimental \s-1LDAP\s0 referral service"
.IX Subsection "RFC-3088 OpenLDAP Root Service - An experimental LDAP referral service"
http://www.ietf.org/rfc/rfc3088.txt
.PP
The OpenLDAP Project is operating an experimental \s-1LDAP \s0(Lightweight
Directory Access Protocol) referral service known as the \*(L"OpenLDAP
Root Service\*(R".  The automated system generates referrals based upon
service location information published in \s-1DNS SRV\s0 RRs (Domain Name
System location of services resource records).  This document
describes this service.
.SS "\s-1RFC\-2657\s0 LDAPv2 Client vs. the Index Mesh"
.IX Subsection "RFC-2657 LDAPv2 Client vs. the Index Mesh"
http://www.ietf.org/rfc/rfc2657.txt
.PP
LDAPv2 clients as implemented according to \s-1RFC 1777\s0 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.
.SS "\s-1RFC\-2649\s0 Signed Directory Operations Using S/MIME"
.IX Subsection "RFC-2649 Signed Directory Operations Using S/MIME"
http://www.ietf.org/rfc/rfc2649.txt
.PP
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 and server based signatures are supported. An object
class for subsequent retrieval are '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.
.SS "\s-1RFC\-2307\s0 An Approach for Using \s-1LDAP\s0 as a Network Information Service"
.IX Subsection "RFC-2307 An Approach for Using LDAP as a Network Information Service"
http://www.ietf.org/rfc/rfc2307.txt
.PP
This document describes an experimental mechanism for mapping
entities related to \s-1TCP/IP\s0 and the \s-1UNIX\s0 system into X.500
entries so that they may be resolved with the \s-1LDAP. A\s0 set of
attribute types and object classes are proposed, along with
specific guidelines for interpreting them. The intention is to
assist the deployment of \s-1LDAP\s0 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.
.SH "Expired but still interesting Internet Drafts"
.IX Header "Expired but still interesting Internet Drafts"
.SS "draft-wahl-ldap-adminaddr \*(-- Administrator Address Attribute"
.IX Subsection "draft-wahl-ldap-adminaddr Administrator Address Attribute"
Organizations running multiple directory servers need an
ability for administrators to determine who is responsible for
a particular server. This is conceptually similar to the
\&'sysContact' object of \s-1SNMP.\s0 The administratorsAddress
attribute allows a server administrator to provide the contact
information of the responsible party for an \s-1LDAP\s0 server. This
can be used by management clients which are, for example,
checking the state of a replication or referral topology, to
provide a way for the user of the management client to send
email to manager of a particular server.
.SS "draft-zeilenga-ldap-noop \*(-- The \s-1LDAP\s0 No-Op Control"
.IX Subsection "draft-zeilenga-ldap-noop The LDAP No-Op Control"
This document defines the Lightweight Directory Access Protocol (\s-1LDAP\s0)
No-Op control which can be used to disable the normal effect of an
operation.  The control can be used to discover how a server might
react to a particular update request without updating the directory.
.SS "draft-legg-ldap-transfer \*(-- Lightweight Directory Access Protocol (\s-1LDAP\s0): Transfer Encoding Options"
.IX Subsection "draft-legg-ldap-transfer Lightweight Directory Access Protocol (LDAP): Transfer Encoding Options"
Each attribute stored in a Lightweight Directory Access Protocol
(\s-1LDAP\s0) 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 \s-1LDAP\s0 operations.  This
representation is referred to as the LDAP-specific encoding to
distinguish it from other methods of encoding attribute values.  This
document introduces a new category of attribute options, called
transfer encoding options, that can be used to specify that the
associated attribute values are encoded according to one of these
other methods.
.SS "draft-furuseth-ldap-untypedobject \*(-- Structural object class 'namedObject' for \s-1LDAP/X.500\s0"
.IX Subsection "draft-furuseth-ldap-untypedobject Structural object class 'namedObject' for LDAP/X.500"
This document defines an 'namedObject' structural object class for
the Lightweight Directory Access Protocol (\s-1LDAP\s0) and X.500.  This is
useful for entries with no natural choice of structural object class,
e.g. if an entry must exist even though its contents are
uninteresting.
.SS "draft\-wahl\-ldap\-p3p \*(-- P3P Policy Attributes for \s-1LDAP\s0"
.IX Subsection "draft-wahl-ldap-p3p P3P Policy Attributes for LDAP"
This document defines attributes that can be retrieved via
Lightweight Directory Access Protocol version 3 (\s-1LDAP\s0) requests,
which contain URIs pointing to the privacy policy documents.  These
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).
.SS "draft-chu-ldap-xordered \*(-- Ordered Entries and Values in \s-1LDAP\s0"
.IX Subsection "draft-chu-ldap-xordered Ordered Entries and Values in LDAP"
As \s-1LDAP\s0 is used more extensively for managing various kinds of data,
one often encounters a need to preserve both the ordering and the
content of data, despite the inherently unordered structure of
entries and attribute values in the directory.  This document
describes a scheme to attach ordering information to attributes in a
directory so that the ordering may be preserved and propagated to
other \s-1LDAP\s0 applications.
.SS "draft-chu-ldap-logschema \*(-- A Schema for Logging the \s-1LDAP\s0 Protocol"
.IX Subsection "draft-chu-ldap-logschema A Schema for Logging the LDAP Protocol"
In order to facilitate remote administration and auditing of \s-1LDAP\s0
server operation, it is desirable to provide the server's operational
logs themselves as a searchable \s-1LDAP\s0 directory.  These logs may also
be used as a persistent change log to support various replication
mechanisms.  This document defines a schema that may be used to
represent all of the requests that have been processed by an \s-1LDAP\s0
server.  It may be used by various applications for auditing, flight
recorder, replication, and other purposes.
.SS "draft-zeilenga-ldap-relax \*(-- The \s-1LDAP\s0 Relax Rules Control"
.IX Subsection "draft-zeilenga-ldap-relax The LDAP Relax Rules Control"
This document defines the Lightweight Directory Access Protocol (\s-1LDAP\s0)
Relax Rules Control which allows a directory user agent (a client) to
request the directory service temporarily relax enforcement of various
data and service model rules.
.SS "draft-gpaterno-dhcp-ldap \*(-- \s-1DHCP\s0 Option for \s-1LDAP\s0 Directory Services discovery"
.IX Subsection "draft-gpaterno-dhcp-ldap DHCP Option for LDAP Directory Services discovery"
This document defines a new \s-1DHCP\s0 option for delivering configuration
information for \s-1LDAP\s0 services. Through this option, the client
receives an \s-1LDAP URL\s0 [8] of the closest available \s-1LDAP\s0 server/replica
that can be used to authenticate users or look up any useful data.
.SS "draft-schleiff-ldap-xri \*(-- \s-1LDAP\s0 Schema for eXtensible Resource Identifier (\s-1XRI\s0)"
.IX Subsection "draft-schleiff-ldap-xri LDAP Schema for eXtensible Resource Identifier (XRI)"
This document describes Attribute Types and an Object Class for use
in representing \s-1XRI \s0(eXtensible Resource Identifier) values in \s-1LDAP
\&\s0(Lightweight Directory Access Protocol) and X.500 directory services.
.SS "draft-wahl-ldap-session \*(-- \s-1LDAP\s0 Session Tracking Control"
.IX Subsection "draft-wahl-ldap-session LDAP Session Tracking Control"
Many network devices, application servers, and middleware components
of a enterprise software infrastructure generate some form of session
tracking identifiers, which are useful when analyzing activity and
accounting logs to group activity relating to a particular session.
This document discusses how Lightweight Directory Access Protocol
version 3 (\s-1LDAP\s0) clients can include session tracking identifiers
with their \s-1LDAP\s0 requests.  This information is provided through
controls in the requests the clients send to \s-1LDAP\s0 servers.  The \s-1LDAP\s0
server receiving these controls can include the session tracking
identifiers the log messages it writes, enabling \s-1LDAP\s0 requests in
the \s-1LDAP\s0 server's logs to be correlated with activity in logs of
other components in the infrastructure.  The control also enables
session tracking information to be generated by \s-1LDAP\s0 servers and
returned to clients and other servers.  Three formats of session
tracking identifiers are defined in this document.
.SS "draft-wahl-ldap-subtree-source \*(-- \s-1LDAP\s0 Subtree Data Source \s-1URI\s0 Attribute"
.IX Subsection "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 (\s-1LDAP\s0) to
determine the source of directory entries.
.SS "draft-ietf-ldapext-psearch \*(-- Persistent Search: A Simple \s-1LDAP\s0 Change Notification Mechanism"
.IX Subsection "draft-ietf-ldapext-psearch Persistent Search: A Simple LDAP Change Notification Mechanism"
This document defines two controls that extend the LDAPv3
search operation to provide a simple mechanism by which an \s-1LDAP\s0
client can receive notification of changes that occur in an
\&\s-1LDAP\s0 server. The mechanism is designed to be very flexible yet
easy for clients and servers to implement.
.SS "draft\-ietf\-ldapext\-ldapv3\-vlv \*(-- \s-1LDAP\s0 Extensions for Scrolling View Browsing of Search Results"
.IX Subsection "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
\&\s-1LDAP \s0 Search  operation.  This control is designed to allow the \*(L"virtual
list box\*(R" feature, common in existing  commercial  e\-mail  address  book
applications, to be supported efficiently by \s-1LDAP\s0 servers. \s-1LDAP\s0 servers'
inability to support this client feature is a significant impediment  to
\&\s-1LDAP\s0 replacing proprietary protocols in commercial e\-mail systems.
.PP
The control allows a client to specify that the  server  return,  for  a
given  \s-1LDAP\s0 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.
.SH "Where to find the latest information"
.IX Header "Where to find the latest information"
Latest information on the RFCs and drafts around \s-1LDAP\s0 can be found at
\&\s-1IETF\s0's datatracker <https://datatracker.ietf.org>.