[Summary view] [Print] [Text view]

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