RFC 2589 (rfc2589) - Page 2 of 12

Lightweight Directory Access Protocol (v3): Extensions for Dynamic Directory Services

RFC 2589    LDAPv3 Extensions for Dynamic Directory Services    May 1999


   within a given timeout, they will be removed from the directory.  For
   example, this will happen if the client that set them goes offline.

   A flow control mechanism from the server is also described that
   allows a server to inform clients how often they should refresh their
   presence.

2. Requirements

   The protocol extensions must allow accessing dynamic information in a
   directory in a standard LDAP manner, to allow clients to access
   static and dynamic information in the same way.

   By definition, dynamic entries are not persistent and clients may go
   away gracefully or not.  The proposed extensions must offer a way for
   a server to tell if entries are still valid, and to do this in a way
   that is scalable.  There also must be a mechanism for clients to
   reestablish their entry with the server.

   There must be a way for clients to find out, in a standard LDAP
   manner, if servers support the dynamic extensions.

   Finally, to allow clients to broadly use the dynamic extensions, the
   extensions need to be registered as standard LDAP extended
   operations.

3. Description of Approach

   The Lightweight Directory Access Protocol (LDAP) [1] permits
   additional operation requests and responses to be added to the
   protocol.  This proposal takes advantage of these to support
   directories which contain dynamic information in a manner which is
   fully integrated with LDAP.

   The approach described in this proposal defines dynamic entries in
   order to allow implementing directories with dynamic information.  An
   implementation of dynamic directories, must be able to support
   dynamic directory entries.

3.1. Dynamic Entries and the dynamicObject object class

   A dynamic entry is an object in the directory tree which has a time-
   to-live associated with it.  This time-to-live is set when the entry
   is created.  The time-to-live is automatically decremented, and when
   it expires the dynamic entry disappears.  By invoking the refresh
   extended operation (defined below) to re-set the time-to-live, a
   client can cause the entry to remain present a while longer.




Yaacovi, et al.             Standards Track