1Net::LDAP::RFC(3) User Contributed Perl Documentation Net::LDAP::RFC(3)
2
6 Net::LDAP::RFC - List of related RFC's
7
9 none
10
12 The LDAP protocol is defined in the following RFC's
13
15 RFC-4510 Lightweight Directory Access Protocol (LDAP): Technical Speci‐
16 fication Road Map
17 http://www.ietf.org/rfc/rfc4510.txt
19 The Lightweight Directory Access Protocol (LDAP) is an Internet proto‐
21 col for accessing distributed directory services that act in accordance
22 with X.500 data and service models. This document provides a road map
23 of the LDAP Technical Specification.
24 RFC-4511 Lightweight Directory Access Protocol (LDAP): The Protocol
26 http://www.ietf.org/rfc/rfc4511.txt
28 This document describes the protocol elements, along with their seman‐
30 tics and encodings, of the Lightweight Directory Access Protocol
31 (LDAP). LDAP provides access to distributed directory services that
32 act in accordance with X.500 data and service models. These protocol
33 elements are based on those described in the X.500 Directory Access
34 Protocol (DAP).
35 RFC-4512 Lightweight Directory Access Protocol (LDAP): Directory Infor‐
37 mation Models
38 http://www.ietf.org/rfc/rfc4512.txt
40 The Lightweight Directory Access Protocol (LDAP) is an Internet proto‐
42 col for accessing distributed directory services that act in accordance
43 with X.500 data and service models. This document describes the X.500
44 Directory Information Models, as used in LDAP.
45 RFC-4513 Lightweight Directory Access Protocol (LDAP): Authentication
47 Methods and Security Mechanisms
48 http://www.ietf.org/rfc/rfc4513.txt
50 This document describes authentication methods and security mechanisms
52 of the Lightweight Directory Access Protocol (LDAP). This document
53 details establishment of Transport Layer Security (TLS) using the
54 StartTLS operation.
55 This document details the simple Bind authentication method including
57 anonymous, unauthenticated, and name/password mechanisms and the Simple
58 Authentication and Security Layer (SASL) Bind authentication method
59 including the EXTERNAL mechanism.
60 This document discusses various authentication and authorization states
62 through which a session to an LDAP server may pass and the actions that
63 trigger these state changes.
64 RFC-4514 Lightweight Directory Access Protocol (LDAP): String Represen‐
66 tation of Distinguished Names
67 http://www.ietf.org/rfc/rfc4514.txt
69 The X.500 Directory uses distinguished names (DNs) as primary keys to
71 entries in the directory. This document defines the string representa‐
72 tion used in the Lightweight Directory Access Protocol (LDAP) to trans‐
73 fer distinguished names. The string representation is designed to give
74 a clean representation of commonly used distinguished names, while
75 being able to represent any distinguished name.
76 RFC-4515 Lightweight Directory Access Protocol (LDAP): String Represen‐
78 tation of Search Filters
79 http://www.ietf.org/rfc/rfc4515.txt
81 Lightweight Directory Access Protocol (LDAP) search filters are trans‐
83 mitted in the LDAP protocol using a binary representation that is
84 appropriate for use on the network. This document defines a human-
85 readable string representation of LDAP search filters that is appropri‐
86 ate for use in LDAP URLs (RFC 4516) and in other applications.
87 RFC-4516 Lightweight Directory Access Protocol (LDAP): Uniform Resource
89 Locator
90 http://www.ietf.org/rfc/rfc4516.txt
92 This document describes a format for a Lightweight Directory Access
94 Protocol (LDAP) Uniform Resource Locator (URL). An LDAP URL describes
95 an LDAP search operation that is used to retrieve information from an
96 LDAP directory, or, in the context of an LDAP referral or reference, an
97 LDAP URL describes a service where an LDAP operation may be progressed.
98 RFC-4517 Lightweight Directory Access Protocol (LDAP): Syntaxes and
100 Matching Rules
101 http://www.ietf.org/rfc/rfc4517.txt
103 Each attribute stored in a Lightweight Directory Access Protocol (LDAP)
105 directory, whose values may be transferred in the LDAP protocol, has a
106 defined syntax that constrains the structure and format of its values.
107 The comparison semantics for values of a syntax are not part of the
108 syntax definition but are instead provided through separately defined
109 matching rules. Matching rules specify an argument, an assertion
110 value, which also has a defined syntax. This document defines a base
111 set of syntaxes and matching rules for use in defining attributes for
112 LDAP directories.
113 RFC-4518 Lightweight Directory Access Protocol (LDAP): International‐
115 ized String Preparation
116 http://www.ietf.org/rfc/rfc4518.txt
118 The previous Lightweight Directory Access Protocol (LDAP) technical
120 specifications did not precisely define how character string matching
121 is to be performed. This led to a number of usability and interoper‐
122 ability problems. This document defines string preparation algorithms
123 for character-based matching rules defined for use in LDAP.
124 RFC-4519 Lightweight Directory Access Protocol (LDAP): Schema for User
126 Applications
127 http://www.ietf.org/rfc/rfc4519.txt
129 This document is an integral part of the Lightweight Directory Access
131 Protocol (LDAP) technical specification. It provides a technical spec‐
132 ification of attribute types and object classes intended for use by
133 LDAP directory clients for many directory services, such as White
134 Pages. These objects are widely used as a basis for the schema in many
135 LDAP directories. This document does not cover attributes used for the
136 administration of directory servers, nor does it include directory
137 objects defined for specific uses in other documents.
138
140 RFC-4532 Lightweight Directory Access Protocol (LDAP) Who am I? Opera‐
141 tion
142 http://www.ietf.org/rfc/rfc4532.txt
144 This specification provides a mechanism for Lightweight Directory
146 Access Protocol (LDAP) clients to obtain the authorization identity the
147 server has associated with the user or application entity. This mecha‐
148 nism is specified as an LDAP extended operation called the LDAP "Who am
149 I?" operation.
150 RFC-4530 Lightweight Directory Access Protocol (LDAP) entryUUID Opera‐
152 tional Attribute
153 http://www.ietf.org/rfc/rfc4530.txt
155 This document describes the LDAP/X.500 'entryUUID' operational
157 attribute and associated matching rules and syntax. The attribute
158 holds a server-assigned Universally Unique Identifier (UUID) for the
159 object. Directory clients may use this attribute to distinguish
160 objects identified by a distinguished name or to locate an object after
161 renaming.
162 RFC-4528 Lightweight Directory Access Protocol (LDAP) Assertion Control
164 http://www.ietf.org/rfc/rfc4528.txt
166 This document defines the Lightweight Directory Access Protocol (LDAP)
168 Assertion Control, which allows a client to specify that a directory
169 operation should only be processed if an assertion applied to the tar‐
170 get entry of the operation is true. It can be used to construct "test
171 and set", "test and clear", and other conditional operations.
172 RFC-4527 Lightweight Directory Access Protocol (LDAP) Read Entry Con‐
174 trols
175 http://www.ietf.org/rfc/rfc4527.txt
177 This document specifies an extension to the Lightweight Directory
179 Access Protocol (LDAP) to allow the client to read the target entry of
180 an update operation. The client may request to read the entry before
181 and/or after the modifications are applied. These reads are done as an
182 atomic part of the update operation.
183 RFC-4526 Lightweight Directory Access Protocol (LDAP) Absolute True and
185 False Filters
186 http://www.ietf.org/rfc/rfc4526.txt
188 This document extends the Lightweight Directory Access Protocol (LDAP)
190 to support absolute True and False filters based upon similar capabili‐
191 ties found in X.500 directory systems. The document also extends the
192 String Representation of LDAP Search Filters to support these filters.
193 RFC-4524 COSINE LDAP/X.500 Schema
195 http://www.ietf.org/rfc/rfc4524.txt
197 This document provides a collection of schema elements for use with the
199 Lightweight Directory Access Protocol (LDAP) from the COSINE and Inter‐
200 net X.500 pilot projects.
201 RFC-4523 Lightweight Directory Access Protocol (LDAP) Schema Defini‐
203 tions for X.509 Certificates
204 http://www.ietf.org/rfc/rfc4523.txt
206 This document describes schema for representing X.509 certificates,
208 X.521 security information, and related elements in directories acces‐
209 sible using the Lightweight Directory Access Protocol (LDAP). The LDAP
210 definitions for these X.509 and X.521 schema elements replace those
211 provided in RFCs 2252 and 2256.
212 RFC-4522 Lightweight Directory Access Protocol (LDAP): The Binary
214 Encoding Option
215 http://www.ietf.org/rfc/rfc4522.txt
217 Each attribute stored in a Lightweight Directory Access Protocol (LDAP)
219 directory has a defined syntax (i.e., data type). A syntax definition
220 specifies how attribute values conforming to the syntax are normally
221 represented when transferred in LDAP operations. This representation
222 is referred to as the LDAP-specific encoding to distinguish it from
223 other methods of encoding attribute values. This document defines an
224 attribute option, the binary option, that can be used to specify that
225 the associated attribute values are instead encoded according to the
226 Basic Encoding Rules (BER) used by X.500 directories.
227 RFC-4370 Lightweight Directory Access Protocol (LDAP) Proxied Autho‐
229 rization Control
230 http://www.ietf.org/rfc/rfc4370.txt
232 This document defines the Lightweight Directory Access Protocol (LDAP)
234 Proxy Authorization Control. The Proxy Authorization Control allows a
235 client to request that an operation be processed under a provided
236 authorization identity instead of under the current authorization iden‐
237 tity associated with the connection.
238 RFC-3928 Lightweight Directory Access Protocol (LDAP) Client Update
240 Protocol (LCUP)
241 http://www.ietf.org/rfc/rfc3928.txt
243 This document defines the Lightweight Directory Access Protocol (LDAP)
245 Client Update Protocol (LCUP). The protocol is intended to allow an
246 LDAP client to synchronize with the content of a directory information
247 tree (DIT) stored by an LDAP server and to be notified about the
248 changes to that content.
249 RFC-3909 Lightweight Directory Access Protocol (LDAP) Cancel Operation
251 http://www.ietf.org/rfc/rfc3909.txt
253 This specification describes a Lightweight Directory Access Protocol
255 (LDAP) extended operation to cancel (or abandon) an outstanding opera‐
256 tion. Unlike the LDAP Abandon operation, but like the X.511 Directory
257 Access Protocol (DAP) Abandon operation, this operation has a response
258 which provides an indication of its outcome.
259 RFC-3876 Returning Matched Values with the Lightweight Directory Access
261 Protocol version 3 (LDAPv3)
262 http://www.ietf.org/rfc/rfc3876.txt
264 This document describes a control for the Lightweight Directory Access
266 Protocol version 3 that is used to return a subset of attribute values
267 from an entry. Specifically, only those values that match a "values
268 return" filter. Without support for this control, a client must
269 retrieve all of an attribute's values and search for specific values
270 locally.
271 RFC-3866 Language Tags and Ranges in the Lightweight Directory Access
273 Protocol (LDAP)
274 http://www.ietf.org/rfc/rfc3866.txt
276 It is often desirable to be able to indicate the natural language asso‐
278 ciated with values held in a directory and to be able to query the
279 directory for values which fulfill the user's language needs. This
280 document details the use of Language Tags and Ranges in the Lightweight
281 Directory Access Protocol (LDAP).
282 RFC-3727 ASN.1 Module Definition for the LDAP and X.500 Component
284 Matching Rules
285 http://www.ietf.org/rfc/rfc3727.txt
287 This document updates the specification of the component matching rules
289 for Lightweight Directory Access Protocol (LDAP) and X.500 directories
290 (RFC3687) by collecting the Abstract Syntax Notation One (ASN.1) defi‐
291 nitions of the component matching rules into an appropriately identi‐
292 fied ASN.1 module so that other specifications may reference the compo‐
293 nent matching rule definitions from within their own ASN.1 modules.
294 RFC-3703 Policy Core Lightweight Directory Access Protocol (LDAP)
296 Schema
297 http://www.ietf.org/rfc/rfc3703.txt
299 This document defines a mapping of the Policy Core Information Model to
301 a form that can be implemented in a directory that uses Lightweight
302 Directory Access Protocol (LDAP) as its access protocol. This model
303 defines two hierarchies of object classes: structural classes repre‐
304 senting information for representing and controlling policy data as
305 specified in RFC 3060, and relationship classes that indicate how
306 instances of the structural classes are related to each other. Classes
307 are also added to the LDAP schema to improve the performance of a
308 client's interactions with an LDAP server when the client is retrieving
309 large amounts of policy-related information. These classes exist only
310 to optimize LDAP retrievals: there are no classes in the information
311 model that correspond to them.
312 RFC-3698 Lightweight Directory Access Protocol (LDAP): Additional
314 Matching Rules
315 http://www.ietf.org/rfc/rfc3698.txt
317 This document provides a collection of matching rules for use with the
319 Lightweight Directory Access Protocol (LDAP). As these matching rules
320 are simple adaptations of matching rules specified for use with the
321 X.500 Directory, most are already in wide use.
322 RFC-3687 Lightweight Directory Access Protocol (LDAP) and X.500 Compo‐
324 nent Matching Rules
325 http://www.ietf.org/rfc/rfc3687.txt
327 The syntaxes of attributes in a Lightweight Directory Access Protocol
329 (LDAP) or X.500 directory range from simple data types, such as text
330 string, integer, or boolean, to complex structured data types, such as
331 the syntaxes of the directory schema operational attributes. Matching
332 rules defined for the complex syntaxes usually only provide the most
333 immediately useful matching capability. This document defines generic
334 matching rules that can match any user selected component parts in an
335 attribute value of any arbitrarily complex attribute syntax.
336 RFC-3672 Subentries in the Lightweight Directory Access Protocol (LDAP)
338 http://www.ietf.org/rfc/rfc3672.txt
340 In X.500 directories, subentries are special entries used to hold
342 information associated with a subtree or subtree refinement. This doc‐
343 ument adapts X.500 subentries mechanisms for use with the Lightweight
344 Directory Access Protocol (LDAP).
345 RFC-3671 Collective Attributes in the Lightweight Directory Access Pro‐
347 tocol (LDAP)
348 http://www.ietf.org/rfc/rfc3671.txt
350 X.500 collective attributes allow common characteristics to be shared
352 between collections of entries. This document summarizes the X.500
353 information model for collective attributes and describes use of col‐
354 lective attributes in LDAP (Lightweight Directory Access Protocol).
355 This document provides schema definitions for collective attributes for
356 use in LDAP.
357 RFC-3296 Named Subordinate References in Lightweight Directory Access
359 Protocol (LDAP) Directories
360 http://www.ietf.org/rfc/rfc3296.txt
362 This document details schema and protocol elements for representing and
364 managing named subordinate references in Lightweight Directory Access
365 Protocol (LDAP) Directories.
366 RFC-3062 LDAP Password Modify Extended Operation
368 http://www.ietf.org/rfc/rfc3062.txt
370 The integration of the Lightweight Directory Access Protocol (LDAP) and
372 external authentication services has introduced non-DN authentication
373 identities and allowed for non-directory storage of passwords. As
374 such, mechanisms which update the directory (e.g., Modify) cannot be
375 used to change a user's password. This document describes an LDAP
376 extended operation to allow modification of user passwords which is not
377 dependent upon the form of the authentication identity nor the password
378 storage mechanism used.
379 RFC-2891 LDAP Control Extension for Server Side Sorting of Search
381 Results
382 http://www.ietf.org/rfc/rfc2891.txt
384 This document describes two LDAPv3 control extensions for server side
386 sorting of search results. These controls allows a client to specify
387 the attribute types and matching rules a server should use when return‐
388 ing the results to an LDAP search request. The controls may be useful
389 when the LDAP client has limited functionality or for some other reason
390 cannot sort the results but still needs them sorted. Other permissible
391 controls on search operations are not defined in this extension.
392 RFC-2849 The LDAP Data Interchange Format (LDIF) - Technical Specifica‐
394 tion
395 http://www.ietf.org/rfc/rfc2849.txt
397 This document describes a file format suitable for describing directory
399 information or modifications made to directory information. The file
400 format, known as LDIF, for LDAP Data Interchange Format, is typically
401 used to import and export directory information between LDAP-based
402 directory servers, or to describe a set of changes which are to be
403 applied to a directory.
404 RFC-2831 Using Digest Authentication as a SASL Mechanism
406 http://www.ietf.org/rfc/rfc2831.txt
408 This specification defines how HTTP Digest Authentication can be used
410 as a SASL [RFC 2222] mechanism for any protocol that has a SASL pro‐
411 file. It is intended both as an improvement over CRAM-MD5 [RFC 2195]
412 and as a convenient way to support a single authentication mechanism
413 for web, mail, LDAP, and other protocols.
414 RFC-2739 Calendar Attributes for vCard and LDAP
416 http://www.ietf.org/rfc/rfc2739.txt
418 When scheduling a calendar entity, such as an event, it is a prerequi‐
420 site that an organizer has the calendar address of each attendee that
421 will be invited to the event. Additionally, access to an attendee's
422 current "busy time" provides an a priori indication of whether the
423 attendee will be free to participate in the event. In order to meet
424 these challenges, a calendar user agent (CUA) needs a mechanism to
425 locate individual user's calendar and free/busy time. This memo defines
426 three mechanisms for obtaining a URI to a user's calendar and free/busy
427 time. These include:
428 RFC-2589 Extensions for Dynamic Directory Services
430 http://www.ietf.org/rfc/rfc2589.txt
432 LDAP supports lightweight access to static directory services, allowing
434 relatively fast search and update access. Static directory services
435 store information about people that persists in its accuracy and value
436 over a long period of time. Dynamic directory services are different in
437 that they store information about people that only persists in its
438 accuracy and value while people are online. Though the protocol opera‐
439 tions and attributes used by dynamic directory services are similar to
440 the ones used for static directory services, clients that are bound to
441 a dynamic directory service need to periodically refresh their presence
442 at the server to keep directory entries from getting stale in the pres‐
443 ence of client application crashes. A flow control mechanism from the
444 server is also described that allows a server to inform clients how
445 often they should refresh their presence.
446 RFC-2559 Internet X.509 Public Key Infrastructure Operational Protocols
448 - LDAPv2
449 http://www.ietf.org/rfc/rfc2559.txt
451 The protocol described in this document is designed to satisfy some of
453 the operational requirements within the Internet X.509 PKI. Specifi‐
454 cally, this document addresses requirements to provide access to PKI
455 repositories for the purposes of retrieving PKI information and manag‐
456 ing that same information. The mechanism described in this document is
457 based on the LDAPv2, defined in RFC 1777, defining a profile of that
458 protocol for use within the PKIX and updates encodings for certificates
459 and revocation lists from RFC 1778. Additional mechanisms addressing
460 PKIX operational requirements are specified in separate documents.
461 RFC-2247 Using Domains in LDAP/X.500 Distinguished Names
463 http://www.ietf.org/rfc/rfc2247.txt
465 LDAP uses X.500-compatible distinguished names for providing unique
467 identification of entries. This document defines an algorithm by which
468 a name registered with the Internet Domain Name Service can be repre‐
469 sented as an LDAP distinguished name.
470 RFC-2222 Simple Authentication and Security Layer (SASL)
472 http://www.ietf.org/rfc/rfc2222.txt
474 This document describes a method for adding authentication support to
476 connection-based protocols. To use this specification, a protocol
477 includes a command for identifying and authenticating a user to a
478 server and for optionally negotiating protection of subsequent protocol
479 interactions. If its use is negotiated, a security layer is inserted
480 between the protocol and the connection. This document describes how a
481 protocol specifies such a command, defines several mechanisms for use
482 by the command, and defines the protocol used for carrying a negotiated
483 security layer over the connection.
484 RFC-2218 A Common Schema for the Internet White Pages Service
486 http://www.ietf.org/rfc/rfc2218.txt
488 This IETF Integrated Directory Services(IDS) Working Group proposes a
490 standard specification for a simple Internet White Pages service by
491 defining a common schema for use by the various White Pages servers.
492 This schema is independent of specific implementations of the White
493 Pages service. This document specifies the minimum set of core
494 attributes of a White Pages entry for an individual and describes how
495 new objects with those attributes can be defined and published. It does
496 not describe how to represent other objects in the White Pages service.
497 Further, it does not address the search sort expectations within a par‐
498 ticular service.
499 RFC-2164 Use of an X.500/LDAP directory to support MIXER address map‐
501 ping
502 http://www.ietf.org/rfc/rfc2164.txt
504 MIXER (RFC 2156) defines an algorithm for use of a set of global map‐
506 ping between X.400 and RFC 822 addresses. This specification defines
507 how to represent and maintain these mappings (MIXER Conformant Global
508 Address Mappings of MCGAMs) in an X.500 or LDAP directory. Mechanisms
509 for representing OR Address and Domain hierarchies within the DIT.
510 These techniques are used to define two independent subtrees in the
511 DIT, which contain the mapping information.
512 RFC-2079 Definition of an X.500 Attribute Type and an Object Class to
514 Hold Uniform Resource Identifiers
515 http://www.ietf.org/rfc/rfc2079.txt
517 URLs are being widely used to specify the location of Internet
519 resources. There is an urgent need to be able to include URLs in direc‐
520 tories that conform to the LDAP and X.500 information models, and a
521 desire to include other types of URIs as they are defined. A number of
522 independent groups are already experimenting with the inclusion of URLs
523 in LDAP and X.500 directories. This document builds on the experimenta‐
524 tion to date and defines a new attribute type and an auxiliary object
525 class to allow URIs, including URLs, to be stored in directory entries
526 in a standard way.
527
529 RFC-4521 Considerations for Lightweight Directory Access Protocol
530 (LDAP) Extensions
531 http://www.ietf.org/rfc/rfc4521.txt
533 The Lightweight Directory Access Protocol (LDAP) is extensible. It
535 provides mechanisms for adding new operations, extending existing oper‐
536 ations, and expanding user and system schemas. This document discusses
537 considerations for designers of LDAP extensions.
538 RFC-4520 Internet Assigned Numbers Authority (IANA) Considerations for
540 the Lightweight Directory Access Protocol (LDAP)
541 http://www.ietf.org/rfc/rfc4520.txt
543 This document provides procedures for registering extensible elements
545 of the Lightweight Directory Access Protocol (LDAP). The document also
546 provides guidelines to the Internet Assigned Numbers Authority (IANA)
547 describing conditions under which new values can be assigned.
548 RFC-2148 Deployment of the Internet White Pages Service
550 http://www.ietf.org/rfc/rfc2148.txt
552 The Internet is used for information exchange and communication between
554 its users. It can only be effective as such if users are able to find
555 each other's addresses. Therefore the Internet benefits from an ade‐
556 quate White Pages Service, i.e., a directory service offering (Inter‐
557 net) address information related to people and organizations.
558 This document describes the way in which the Internet White Pages Ser‐
560 vice (from now on abbreviated as IWPS) is best exploited using today's
561 experience, today's protocols, today's products and today's procedures.
562
564 RFC-4525 Lightweight Directory Access Protocol (LDAP) Modify-Increment
565 Extension
566 http://www.ietf.org/rfc/rfc4525.txt
568 This document describes an extension to the Lightweight Directory
570 Access Protocol (LDAP) Modify operation to support an increment capa‐
571 bility. This extension is useful in provisioning applications, espe‐
572 cially when combined with the assertion control and/or the pre- read or
573 post-read control extension.
574 RFC-4403 Lightweight Directory Access Protocol (LDAP) Schema for Uni‐
576 versal Description, Discovery, and Integration version 3 (UDDIv3)
577 http://www.ietf.org/rfc/rfc4403.txt
579 This document defines the Lightweight Directory Access Protocol
581 (LDAPv3) schema for representing Universal Description, Discovery, and
582 Integration (UDDI) data types in an LDAP directory. It defines the
583 LDAP object class and attribute definitions and containment rules to
584 model UDDI entities, defined in the UDDI version 3 information model,
585 in an LDAPv3-compliant directory.
586 RFC-4373 Lightweight Directory Access Protocol (LDAP) Bulk
588 Update/Replication Protocol (LBURP)
589 http://www.ietf.org/rfc/rfc4373.txt
591 The Lightweight Directory Access Protocol (LDAP) Bulk Update/Replica‐
593 tion Protocol (LBURP) allows an LDAP client to perform a bulk update to
594 an LDAP server. The protocol frames a sequenced set of update opera‐
595 tions within a pair of LDAP extended operations to notify the server
596 that the update operations in the framed set are related in such a way
597 that the ordering of all operations can be preserved during processing
598 even when they are sent asynchronously by the client. Update opera‐
599 tions can be grouped within a single protocol message to maximize the
600 efficiency of client-server communication.
601 The protocol is suitable for efficiently making a substantial set of
603 updates to the entries in an LDAP server.
604 RFC-3944 H.350 Directory Services
606 http://www.ietf.org/rfc/rfc3944.txt
608 The International Telecommunications Union Standardization Sector
610 (ITU-T) has created the H.350 series of Recommendations that specify
611 directory services architectures in support of multimedia conferencing
612 protocols. The goal of the architecture is to 'directory enable' mul‐
613 timedia conferencing so that these services can leverage existing iden‐
614 tity management and enterprise directories. A particular goal is to
615 enable an enterprise or service provider to maintain a canonical source
616 of users and their multimedia conferencing systems, so that multiple
617 call servers from multiple vendors, supporting multiple protocols, can
618 all access the same data store.
619 Because SIP is an IETF standard, the contents of H.350 and H.350.4 are
621 made available via this document to the IETF community. This document
622 contains the entire normative text of ITU-T Recommendations H.350 and
623 H.350.4 in sections 4 and 5, respectively. The remaining sections are
624 included only in this document, not in the ITU-T version.
625 RFC-3829 Lightweight Directory Access Protocol (LDAP) Authorization
627 Identity Request and Response Controls
628 http://www.ietf.org/rfc/rfc3829.txt
630 This document extends the Lightweight Directory Access Protocol (LDAP)
632 bind operation with a mechanism for requesting and returning the autho‐
633 rization identity it establishes. Specifically, this document defines
634 the Authorization Identity Request and Response controls for use with
635 the Bind operation.
636 RFC-3712 Lightweight Directory Access Protocol (LDAP): Schema for
638 Printer Services
639 http://www.ietf.org/rfc/rfc3712.txt
641 This document defines a schema, object classes and attributes, for
643 printers and printer services, for use with directories that support
644 Lightweight Directory Access Protocol v3 (LDAP-TS). This document is
645 based on the printer attributes listed in Appendix E of Internet Print‐
646 ing Protocol/1.1 (IPP) (RFC 2911). A few additional printer attributes
647 are based on definitions in the Printer MIB (RFC 1759).
648 RFC-3494 Lightweight Directory Access Protocol version 2 (LDAPv2) to
650 Historic Status
651 http://www.ietf.org/rfc/rfc3494.txt
653 This document recommends the retirement of version 2 of the Lightweight
655 Directory Access Protocol (LDAPv2) and other dependent specifications,
656 and discusses the reasons for doing so. This document recommends RFC
657 1777, 1778, 1779, 1781, and 2559 (as well as documents they superseded)
658 be moved to Historic status.
659 RFC-3384 Lightweight Directory Access Protocol (version 3) Replication
661 Requirements
662 http://www.ietf.org/rfc/rfc3384.txt
664 This document discusses the fundamental requirements for replication of
666 data accessible via the Lightweight Directory Access Protocol (version
667 3) (LDAPv3). It is intended to be a gathering place for general repli‐
668 cation requirements needed to provide interoperability between informa‐
669 tional directories.
670 RFC-3112 LDAP Authentication Password Schema
672 http://www.ietf.org/rfc/rfc3112.txt
674 This document describes schema in support of user/password authentica‐
676 tion in a LDAP (Lightweight Directory Access Protocol) directory
677 including the authPassword attribute type. This attribute type holds
678 values derived from the user's password(s) (commonly using crypto‐
679 graphic strength one-way hash). authPassword is intended to used
680 instead of userPassword.
681 RFC-3045 Storing Vendor Information in the LDAP root DSE
683 http://www.ietf.org/rfc/rfc3045.txt
685 This document specifies two Lightweight Directory Access Protocol
687 (LDAP) attributes, vendorName and vendorVersion that MAY be included in
688 the root DSA-specific Entry (DSE) to advertise vendor-specific informa‐
689 tion. These two attributes supplement the attributes defined in sec‐
690 tion 3.4 of RFC 2251.
691 RFC-2985 PKCS #9: Selected Object Classes and Attribute Types Version
693 2.0
694 http://www.ietf.org/rfc/rfc2985.txt
696 This memo provides a selection of object classes and attribute types
698 for use in conjunction with public-key cryptography and Lightweight
699 Directory Access Protocol (LDAP) accessible directories. It also
700 includes ASN.1 syntax for all constructs.
701 RFC-2967 TISDAG - Technical Infrastructure for Swedish Directory Access
703 Gateways
704 http://www.ietf.org/rfc/rfc2967.txt
706 The strength of the TISDAG (Technical Infrastructure for Swedish Direc‐
708 tory Access Gateways) project's DAG proposal is that it defines the
709 necessary technical infrastructure to provide a single-access- point
710 service for information on Swedish Internet users. The resulting ser‐
711 vice will provide uniform access for all information -- the same level
712 of access to information (7x24 service), and the same information made
713 available, irrespective of the service provider responsible for main‐
714 taining that information, their directory service protocols, or the
715 end-user's client access protocol.
716 RFC-2927 MIME Directory Profile for LDAP Schema
718 http://www.ietf.org/rfc/rfc2927.txt
720 This document defines a multipurpose internet mail extensions (MIME)
722 directory profile for holding a lightweight directory access protocol
723 (LDAP) schema. It is intended for communication with the Internet
724 schema listing service.
725 RFC-2926 Conversion of LDAP Schemas to and from SLP Templates
727 http://www.ietf.org/rfc/rfc2926.txt
729 This document describes a procedure for mapping between Service Loca‐
731 tion Protocol (SLP) service advertisements and lightweight directory
732 access protocol (LDAP) descriptions of services. The document covers
733 two aspects of the mapping. One aspect is mapping between SLP service
734 type templates and LDAP directory schema. Because the SLP service type
735 template grammar is relatively simple, mapping from service type tem‐
736 plates to LDAP types is straightforward. Mapping in the other direc‐
737 tion is straightforward if the attributes are restricted to use just a
738 few of the syntaxes defined in RFC 2252. If arbitrary ASN.1 types
739 occur in the schema, then the mapping is more complex and may even be
740 impossible. The second aspect is representation of service information
741 in an LDAP directory. The recommended representation simplifies inter‐
742 operability with SLP by allowing SLP directory agents to backend into
743 LDAP directory servers. The resulting system allows service advertise‐
744 ments to propagate easily between SLP and LDAP.
745 RFC-2820 Access Control Requirements for LDAP
747 http://www.ietf.org/rfc/rfc2820.txt
749 This document describes the fundamental requirements of an access con‐
751 trol list (ACL) model for the LDAP directory service. It is intended
752 to be a gathering place for access control requirements needed to pro‐
753 vide authorized access to and interoperability between directories.
754 RFC-2798 Definition of the inetOrgPerson Object Class
756 http://www.ietf.org/rfc/rfc2798.txt
758 While the X.500 standards define many useful attribute types [X520] and
760 object classes [X521], they do not define a person object class that
761 meets the requirements found in today's Internet and Intranet directory
762 service deployments. We define a new object class called inetOrgPerson
763 for use in LDAP and X.500 directory services that extends the X.521
764 standard organizationalPerson class to meet these needs.
765 RFC-2714 Schema for Representing CORBA Objects in an LDAP Directory
767 http://www.ietf.org/rfc/rfc2714.txt
769 CORBA is the Common Object Request Broker Architecture defined by the
771 Object Management Group. This document defines the schema for repre‐
772 senting CORBA object references in an LDAP directory.
773 RFC-2713 Schema for Representing Java Objects in an LDAP Directory
775 http://www.ietf.org/rfc/rfc2713.txt
777 This document defines the schema for representing Java objects in an
779 LDAP directory. It defines schema elements to represent a Java serial‐
780 ized object, a Java marshalled object, a Java remote object, and a JNDI
781 reference.
782 RFC-2696 LDAP Control Extension for Simple Paged Results Manipulation
784 http://www.ietf.org/rfc/rfc2696.txt
786 This document describes an LDAPv3 control extension for simple paging
788 of search results. This control extension allows a client to control
789 the rate at which an LDAP server returns the results of an LDAP search
790 operation. This control may be useful when the LDAP client has limited
791 resources and may not be able to process the entire result set from a
792 given LDAP query, or when the LDAP client is connected over a low-band‐
793 width connection. Other operations on the result set are not defined in
794 this extension. This extension is not designed to provide more sophis‐
795 ticated result set management.
796 RFC-1823 The LDAP Application Program Interface
798 http://www.ietf.org/rfc/rfc1823.txt
800 This document defines a C language application program interface to
802 LDAP, which is designed to be powerful, yet simple to use. It defines
803 compatible synchronous and asynchronous interfaces to LDAP to suit a
804 wide variety of applications. This document gives a brief overview of
805 the LDAP model, then an overview of how the API is used by an applica‐
806 tion program to obtain LDAP information. The API calls are described in
807 detail, followed by an appendix that provides some example code demon‐
808 strating the use of the API.
809
811 RFC-4533 The Lightweight Directory Access Protocol (LDAP) Content Syn‐
812 chronization Operation
813 http://www.ietf.org/rfc/rfc4533.txt
815 This specification describes the Lightweight Directory Access Protocol
817 (LDAP) Content Synchronization Operation. The operation allows a
818 client to maintain a copy of a fragment of the Directory Information
819 Tree (DIT). It supports both polling for changes and listening for
820 changes. The operation is defined as an extension of the LDAP Search
821 Operation.
822 RFC-4531 Lightweight Directory Access Protocol (LDAP) Turn Operation
824 http://www.ietf.org/rfc/rfc4531.txt
826 This specification describes a Lightweight Directory Access Protocol
828 (LDAP) extended operation to reverse (or "turn") the roles of client
829 and server for subsequent protocol exchanges in the session, or to
830 enable each peer to act as both client and server with respect to the
831 other.
832 RFC-3663 Domain Administrative Data in Lightweight Directory Access
834 Protocol (LDAP)
835 http://www.ietf.org/rfc/rfc3663.txt
837 Domain registration data has typically been exposed to the general pub‐
839 lic via Nicname/Whois for administrative purposes. This document
840 describes the Referral Lightweight Directory Access Protocol (LDAP)
841 Service, an experimental service using LDAP and well-known LDAP types
842 to make domain administrative data available.
843 RFC-3088 OpenLDAP Root Service - An experimental LDAP referral service
845 http://www.ietf.org/rfc/rfc3088.txt
847 The OpenLDAP Project is operating an experimental LDAP (Lightweight
849 Directory Access Protocol) referral service known as the "OpenLDAP Root
850 Service". The automated system generates referrals based upon service
851 location information published in DNS SRV RRs (Domain Name System loca‐
852 tion of services resource records). This document describes this ser‐
853 vice.
854 RFC-2657 LDAPv2 Client vs. the Index Mesh
856 http://www.ietf.org/rfc/rfc2657.txt
858 LDAPv2 clients as implemented according to RFC 1777 have no notion of
860 referral. The integration between such a client and an Index Mesh, as
861 defined by the Common Indexing Protocol, heavily depends on referrals
862 and therefore needs to be handled in a special way. This document
863 defines one possible way of doing this.
864 RFC-2649 Signed Directory Operations Using S/MIME
866 http://www.ietf.org/rfc/rfc2649.txt
868 This document defines an LDAPv3 based mechanism for signing directory
870 operations in order to create a secure journal of changes that have
871 been made to each directory entry. Both client and server based signa‐
872 tures are supported. An object class for subsequent retrieval are
873 'journal entries' is also defined. This document specifies LDAPv3 con‐
874 trols that enable this functionality. It also defines an LDAPv3 schema
875 that allows for subsequent browsing of the journal information.
876 RFC-2307 An Approach for Using LDAP as a Network Information Service
878 http://www.ietf.org/rfc/rfc2307.txt
880 This document describes an experimental mechanism for mapping entities
882 related to TCP/IP and the UNIX system into X.500 entries so that they
883 may be resolved with the LDAP. A set of attribute types and object
884 classes are proposed, along with specific guidelines for interpreting
885 them. The intention is to assist the deployment of LDAP as an organiza‐
886 tional nameservice. No proposed solutions are intended as standards
887 for the Internet. Rather, it is hoped that a general consensus will
888 emerge as to the appropriate solution to such problems, leading eventu‐
889 ally to the adoption of standards. The proposed mechanism has already
890 been implemented with some success.
891
893 draft-wahl-ldap-adminaddr -- Administrator Address Attribute
894 Organizations running multiple directory servers need an ability for
896 administrators to determine who is responsible for a particular server.
897 This is conceptually similar to the 'sysContact' object of SNMP. The
898 administratorsAddress attribute allows a server administrator to pro‐
899 vide the contact information of the responsible party for an LDAP
900 server. This can be used by management clients which are, for example,
901 checking the state of a replication or referral topology, to provide a
902 way for the user of the management client to send email to manager of a
903 particular server.
904 draft-zeilenga-ldap-txn -- LDAP Transactions
906 Lightweight Directory Access Protocol (LDAP) update operations, such as
908 Add, Delete, and Modify operations, have atomic, consistency, isola‐
909 tion, durability (ACID) properties. Each of these update operations
910 act upon an entry. However, It is often desirable to update two or
911 more entries in a single unit of interaction, a transaction. Transac‐
912 tions are necessary to support a number of applications including
913 resource provisioning. This document defines an LDAP extension to sup‐
914 port transactions.
915 draft-joslin-config-schema -- A Configuration Profile Schema for LDAP-
917 based agents
918 This document consists of two primary components, a schema for agents
920 that make use of the Lightweight Directory Access protocol (LDAP) and a
921 proposed use case of that schema, for distributed configuration of sim‐
922 ilar directory user agents. A set of attribute types and an object‐
923 class are proposed. In the proposed use case, directory user agents
924 (DUAs) can use this schema to determine directory data location and
925 access parameters for specific services they support. In addition, in
926 the proposed use case, attribute and objectclass mapping allows DUAs to
927 re-configure their expected (default) schema to match that of the end
928 user's environment. This document is intended to be a skeleton for
929 future documents that describe configuration of specific DUA services.
930 draft-zeilenga-ldap-noop -- The LDAP No-Op Control
932 This document defines the Lightweight Directory Access Protocol (LDAP)
934 No-Op control which can be used to disable the normal effect of an
935 operation. The control can be used to discover how a server might
936 react to a particular update request without updating the directory.
937 draft-legg-ldap-transfer -- Lightweight Directory Access Protocol
939 (LDAP): Transfer Encoding Options
940 Each attribute stored in a Lightweight Directory Access Protocol (LDAP)
942 directory has a defined syntax (i.e., data type). A syntax definition
943 specifies how attribute values conforming to the syntax are normally
944 represented when transferred in LDAP operations. This representation
945 is referred to as the LDAP-specific encoding to distinguish it from
946 other methods of encoding attribute values. This document introduces a
947 new category of attribute options, called transfer encoding options,
948 that can be used to specify that the associated attribute values are
949 encoded according to one of these other methods.
950 draft-furuseth-ldap-untypedobject -- Structural object class 'namedOb‐
952 ject' for LDAP/X.500
953 This document defines an 'namedObject' structural object class for the
955 Lightweight Directory Access Protocol (LDAP) and X.500. This is useful
956 for entries with no natural choice of structural object class, e.g. if
957 an entry must exist even though its contents are uninteresting.
958 draft-zeilenga-ldap-dontusecopy -- The LDAP Don't Use Copy Control
960 This document defines the Lightweight Directory Access Protocol (LDAP)
962 Don't Use Copy control extension which allows a client to specify that
963 copied information should not be used in providing service. This con‐
964 trol is based upon the X.511 dontUseCopy service control option.
965 draft-wahl-ldap-p3p -- P3P Policy Attributes for LDAP
967 This document defines attributes that can be retrieved via Lightweight
969 Directory Access Protocol version 3 (LDAP) requests, which contain URIs
970 pointing to the privacy policy documents. These documents describe the
971 privacy policy concerning access to a directory server, and the privacy
972 policies that apply to the contents of the directory (a subtree of
973 entries).
974 draft-legg-ldap-gser-ei -- Encoding Instructions for the Generic String
976 Encoding Rules (GSER)
977 Abstract Syntax Notation One (ASN.1) defines a general framework for
979 annotating types in an ASN.1 specification with encoding instructions
980 that alter how values of those types are encoded according to ASN.1
981 encoding rules. This document defines the supporting notation for
982 encoding instructions that apply to the Generic String Encoding Rules
983 (GSER), and in particular defines an encoding instruction to provide a
984 machine-processable representation for the declaration of a GSER
985 ChoiceOfStrings type.
986 draft-chu-ldap-xordered -- Ordered Entries and Values in LDAP
988 As LDAP is used more extensively for managing various kinds of data,
990 one often encounters a need to preserve both the ordering and the con‐
991 tent of data, despite the inherently unordered structure of entries and
992 attribute values in the directory. This document describes a scheme to
993 attach ordering information to attributes in a directory so that the
994 ordering may be preserved and propagated to other LDAP applications.
995 draft-chu-ldap-logschema -- A Schema for Logging the LDAP Protocol
997 In order to facilitate remote administration and auditing of LDAP
999 server operation, it is desirable to provide the server's operational
1000 logs themselves as a searchable LDAP directory. These logs may also be
1001 used as a persistent change log to support various replication mecha‐
1002 nisms. This document defines a schema that may be used to represent
1003 all of the requests that have been processed by an LDAP server. It may
1004 be used by various applications for auditing, flight recorder, replica‐
1005 tion, and other purposes.
1006 draft-zeilenga-ldap-entrydn -- The LDAP entryDN Operational Attribute
1008 This document describes the LDAP/X.500 'entryDN' operational attribute.
1010 The attribute provides a copy of the entry's distinguished name for use
1011 in attribute value assertions.
1012 draft-zeilenga-ldap-relax -- The LDAP Relax Rules Control
1014 This document defines the Lightweight Directory Access Protocol (LDAP)
1016 Relax Rules Control which allows a directory user agent (a client) to
1017 request the directory service temporarily relax enforcement of various
1018 data and service model rules.
1019 draft-gpaterno-dhcp-ldap -- DHCP Option for LDAP Directory Services
1021 discovery
1022 This document defines a new DHCP option for delivering configuration
1024 information for LDAP services. Through this option, the client receives
1025 an LDAP URL [8] of the closest available LDAP server/replica that can
1026 be used to authenticate users or look up any useful data.
1027 draft-schleiff-ldap-xri -- LDAP Schema for eXtensible Resource Identi‐
1029 fier (XRI)
1030 This document describes Attribute Types and an Object Class for use in
1032 representing XRI (eXtensible Resource Identifier) values in LDAP
1033 (Lightweight Directory Access Protocol) and X.500 directory services.
1034 draft-wahl-ldap-session -- LDAP Session Tracking Control
1036 Many network devices, application servers, and middleware components of
1038 a enterprise software infrastructure generate some form of session
1039 tracking identifiers, which are useful when analyzing activity and
1040 accounting logs to group activity relating to a particular session.
1041 This document discusses how Lightweight Directory Access Protocol ver‐
1042 sion 3 (LDAP) clients can include session tracking identifiers with
1043 their LDAP requests. This information is provided through controls in
1044 the requests the clients send to LDAP servers. The LDAP server receiv‐
1045 ing these controls can include the session tracking identifiers the the
1046 log messages it writes, enabling LDAP requests in the LDAP server's
1047 logs to be correlated with activity in logs of other components in the
1048 infrastructure. The control also enables session tracking information
1049 to be generated by LDAP servers and returned to clients and other
1050 servers. Three formats of session tracking identifiers are defined in
1051 this document.
1052 draft-wahl-ldap-subtree-source -- LDAP Subtree Data Source URI
1054 Attribute
1055 This document defines an attribute that enables administrative clients
1057 using the Lightweight Directory Access Protocol (LDAP) to determine the
1058 source of directory entries.
1059
1061 draft-ietf-ldapext-psearch -- Persistent Search: A Simple LDAP Change
1062 Notification Mechanism
1063 This document defines two controls that extend the LDAPv3 search opera‐
1065 tion to provide a simple mechanism by which an LDAP client can receive
1066 notification of changes that occur in an LDAP server. The mechanism is
1067 designed to be very flexible yet easy for clients and servers to imple‐
1068 ment.
1069 draft-ietf-ldapext-ldapv3-vlv -- LDAP Extensions for Scrolling View
1071 Browsing of Search Results
1072 This document describes a Virtual List View control extension for
1074 the LDAP Search operation. This control is designed to allow the
1075 "virtual list box" feature, common in existing commercial e-mail
1076 address book applications, to be supported efficiently by LDAP
1077 servers. LDAP servers' inability to support this client feature is a
1078 significant impediment to LDAP replacing proprietary protocols in com‐
1079 mercial e-mail systems.
1080 The control allows a client to specify that the server return, for
1082 a given LDAP search with associated sort keys, a contiguous subset of
1083 the search result set. This subset is specified in terms of offsets
1084 into the ordered list, or in terms of a greater than or equal compari‐
1085 son value.
1086perl v5.8.8 2007-02-10 Net::LDAP::RFC(3)