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]