HTTP/1.1 200 OK Date: Tue, 09 Apr 2002 00:51:36 GMT Server: Apache/1.3.20 (Unix) Last-Modified: Thu, 27 Jul 1995 22:00:00 GMT ETag: "2e9d15-14c8-30180c60" Accept-Ranges: bytes Content-Length: 5320 Connection: close Content-Type: text/plain Network Working Group Tim Howes INTERNET DRAFT University of Michigan A Simple Caching Scheme for LDAP and X.500 Directories 1. Status of this Memo This memo provides information for the Internet community. The scheme it describes will be presented to the IETF ASID working group, and upon approval, publication will be pursued as an Internet standard RFC. 2. Abstract This memo defines an object class and attribute type in support of a simple caching mechanism for use in LDAP and X.500 directories. The object class allows a simple "time-to-live" attribute to be included in entries, enabling clients retrieving the attribute to tell when the other information they have retrieved from the entry should be thrown away. The use of this scheme does not preclude the subsequent or addi- tional use of other more complicated schemes, for example, allowing dif- ferent TTLs on individual attributes. 3. Need for Caching and Overview X.500 [x500] and LDAP [rfc1777, rfc1778] define a distributed database. To achieve greater performance and availability, it is desirable to replicate information close to the entities accessing it. Formal repli- cation schemes have been devised for this purpose [rfc1276]. Caching is an informal method of replication designed to make repeated use of information by the same or co-located clients more efficient. Systems relying on fast performance that can tolerate temporarily out-of-date data, such as the Domain Name System [rfc1034], often make heavy use of caching to achieve the desired level of performance. X.500 and LDAP comprise another system that could similarly benefit from caching. Until now, there has been no agreed upon scheme for providing a con- sistent caching mechanism for LDAP and X.500. Caching occurs, but it is up to the caching agent to determine the appropriate length of time a piece of information can safely be cached. There is support in X.500 for ignoring all cached or replicated information copies in favor of the master copy, at the client's discretion (the dontUseCopy service con- trol). There is no guidance on the length of time that information (master or not) can safely be cached. This memo defines a simple caching model similar to that used by the Howes [Page 1] RFC DRAFT August 1995 DNS. A new object class, cacheObject is defined, which allows an entry to have a new attribute, timeToLive or tTL, specifying the maximum time for which a cached copy of any attributes in the entry should be con- sidered valid. Note that use of this scheme means that all attributes in an entry are subject to the same TTL. This is ok for a simple scheme, but more com- plicated situations where different attributes (or even values of the same attribute) might have different TTL requirements can easily be envisioned. The scheme described here is not intended to address these situations, nor is it intended to hinder the development of other schemes that do. 4. The cacheObject Object Class The cacheObject object class is defined as follows. Name: cacheObject Description: Auxiliary object class to hold TTL caching information OID: 1.3.6.1.4.1.250.3.15 SubclassOf: top MustContain: MayContain: timeToLive The definition of the timeToLive attribute is as follows. Name: timeToLive ShortName: ttl OID: 1.3.6.1.4.1.250.1.60 Syntax: Integer SizeRestriction: none SingleValued: TRUE MatchesFor: The timeToLive attribute contains the time, in seconds, that any infor- mation from the entry should be kept by a client before it is considered "stale" and a new copy fetched. 5. Security Considerations A caching scheme has implications on the accuracy of data. Both applica- tions and data providers should be aware of how important information consistency is for the data they are using or providing. 6. Bibliography [rfc1777] Yeong, W., Howes, T., Kille, S., "Lightweight Directory Access Protocol", Request for Comments (RFC) 1777, March 1995. Howes [Page 2] RFC DRAFT August 1995 [rfc1034] Mockapetris, P., "Domain Names - Concepts and Facilities", Request for Comments (RFC) 1034, November 1987. [rfc1778] Howes, T., Kille, S., Yeong, W., Robbins, C.J., "The String Representation of Standard Attribute Syntaxes", Request for Comments (RFC) 1778, March 1995. [x500] "Information Processing Systems - Open Systems Interconnection - The Directory: Overview of Concepts, Models and Services", ISO/IEC JTC 1/SC21, International Standard 9594-1, 1988. 7. Author's Address Tim Howes University of Michigan ITD Research Systems 535 W William St. Ann Arbor, MI 48103-4943 USA +1 313 747-4454 tim@umich.edu Howes [Page 3]