Internet DRAFT - draft-ietf-asid-ldap-dir
draft-ietf-asid-ldap-dir
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
<draft-ietf-asid-ldap-dir-00.txt>
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]
