home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_ietf_a_c / draft-ietf-asid-ldap-cache-01.txt < prev    next >
Text File  |  1997-10-22  |  10KB  |  297 lines
  1.  
  2.  
  3. Application Working Group                                    Tim Howes
  4. INTERNET-DRAFT                           Netscape Communications Corp.
  5. Expires in six months                                      Luke Howard
  6. Intended Category: Standard                     Independent Consultant
  7.                                                           October 1997
  8.  
  9.  
  10.          A Simple Caching Scheme for LDAP and X.500 Directories
  11.                   <draft-ietf-asid-ldap-cache-01.txt>
  12.  
  13.  
  14.  
  15. 1.  Status of this Memo
  16.  
  17. This document is an Internet-Draft. Internet-Drafts  are  working  docu-
  18. ments  of the Internet Engineering Task Force (IETF), its areas, and its
  19. working groups. Note that other groups may also distribute working docu-
  20. ments as Internet-Drafts.
  21.  
  22. Internet-Drafts are draft documents valid for a maximum  of  six  months
  23. and  may  be  updated,  replaced, or obsoleted by other documents at any
  24. time. It is inappropriate to use Internet- Drafts as reference  material
  25. or to cite them other than as ``work in progress.''
  26.  
  27. To learn the current status of  any  Internet-Draft,  please  check  the
  28. ``1id-abstracts.txt''  listing  contained in the Internet- Drafts Shadow
  29. Directories   on   ftp.is.co.za   (Africa),   nic.nordu.net    (Europe),
  30. munnari.oz.au   (Pacific  Rim),  ds.internic.net  (US  East  Coast),  or
  31. ftp.isi.edu (US West Coast).
  32.  
  33. 2.  Abstract
  34.  
  35. This memo defines an object class and attribute type  in  support  of  a
  36. simple  caching  mechanism  for  use in LDAP and X.500 directories.  The
  37. object class allows a simple 'time-to-live' attribute to be included  in
  38. entries,  enabling  clients  retrieving  the  attribute to tell when the
  39. other information they have retrieved from the entry  should  be  thrown
  40. away.  The  use of this scheme does not preclude the subsequent or addi-
  41. tional use of other more complicated schemes, for example, allowing dif-
  42. ferent TTLs on individual attributes.
  43.  
  44. 3.  Need for Caching and Overview
  45.  
  46. LDAP [ldapv3-1, ldapv3-2] and X.500 [x500] define  a  distributed  data-
  47. base.   To achieve greater performance and availability, it is desirable
  48. to replicate information close to  the  entities  accessing  it.  Formal
  49. replication  schemes  have been devised for this purpose.  Caching is an
  50. informal  method  of  replication  designed  to  make  repeated  use  of
  51.  
  52.  
  53.  
  54. Howes & Howard                                                  [Page 1]
  55.  
  56.  
  57.  
  58.  
  59.  
  60. Expires March 1998                                        INTERNET DRAFT
  61.  
  62.  
  63. information  by  the same or co-located clients more efficient.  Systems
  64. relying on fast performance that can  tolerate  temporarily  out-of-date
  65. data,  such as the Domain Name System [rfc1034], often make heavy use of
  66. caching to achieve the desired level  of  performance.  LDAP  and  X.500
  67. comprise another system that could similarly benefit from caching.
  68.  
  69. Until now, there has been no agreed scheme for  providing  a  consistent
  70. caching  mechanism  for  LDAP and X.500. Caching occurs, but it is up to
  71. the caching agent to determine the appropriate length of time a piece of
  72. information can safely be cached. There is support in X.500 for ignoring
  73. all cached or replicated information copies in favor of the master copy,
  74. at  the  client's discretion (the dontUseCopy service control). There is
  75. no guidance on the length of time that information (master or  not)  can
  76. safely be cached.
  77.  
  78. This draft defines a simple caching model similar to that  used  by  the
  79. DNS. A new operational attribute, ttl, is defined to specify the maximum
  80. time for which a cached copy of any attributes in the  entry  should  be
  81. considered  valid.   The  ttl attribute SHOULD be allowed in every entry
  82. that may be cached.
  83.  
  84. A new object class, cacheObject is defined, which  allows  an  entry  to
  85. have  the  new ttl attribute, even if the server implementation does not
  86. support operational attributes (e.g., an LDAPv2 server).
  87.  
  88. Note that use of this scheme means that all attributes in an  entry  are
  89. subject  to  the  same TTL. This is satisfactory in many cases, but more
  90. complicated situations where different attributes (or even values of the
  91. same  attribute)  may  have different TTL requirements can easily arise.
  92. The scheme described here is not intended to address  these  situations,
  93. nor is it intended to hinder the development of other schemes that do.
  94.  
  95. 4.  The ttl Attribute
  96.  
  97. The definition of the ttl attribute is as follows:
  98.  
  99.    ( 1.3.6.1.4.1.250.1.60 NAME 'ttl' EQUALITY integerMatch
  100.      SYNTAX '1.3.6.1.4.1.1466.115.121.1.27' SINGLE-VALUE )
  101.  
  102. The ttl attribute contains the time, in seconds,  that  any  information
  103. from  the  entry  should  be  kept  by  a client before it is considered
  104. "stale" and a new copy fetched. A value of 0  implies  that  the  object
  105. must not be cached.
  106.  
  107. The behaviour of caching clients with respect to entries lacking the ttl
  108. is  not  prescribed.  Caching  agents may use any appropriate method for
  109. determining  whether  an  entry  without  a  ttl  attribute  should   be
  110. refetched.   For   example,  clients  may  compare  the  modifyTimestamp
  111.  
  112.  
  113.  
  114. Howes & Howard                                                  [Page 2]
  115.  
  116.  
  117.  
  118.  
  119.  
  120. Expires March 1998                                        INTERNET DRAFT
  121.  
  122.  
  123. attribute of the entry with the current one and refetch the  entry  only
  124. if  the entry has been updated since it was cached. A number of factors,
  125. such as network latency, may render this policy  inefficient.  As  such,
  126. clients  may  assume  entries lacking the ttl attribute never expire, or
  127. that they expire in some client-defined time period, or that they should
  128. never be cached.
  129.  
  130. 5.  The cacheObject Object Class
  131.  
  132. The cacheObject object class is defined as follows:
  133.  
  134.    ( 1.3.6.1.4.1.250.3.18 NAME 'cacheObject' AUXILIARY SUP top
  135.      DESC 'Auxiliary object class to hold TTL caching information'
  136.      MAY ttl )
  137.  
  138. 6.  Coexistence with entryTtl and DNS-related attributes
  139.  
  140. The entryTtl attribute, defined in [v3ext], is an operational  attribute
  141. maintained  by  the  directory  server which appears to bear superficial
  142. resemblance to the ttl attribute. The entryTtl attribute is only present
  143. in entries of the dynamicObject object class, and may not be modified by
  144. the user.  A value of 0 indicates that the entry may disappear from  the
  145. directory without warning.
  146.  
  147. By contrast, the ttl attribute as defined here  refers  not  to  dynamic
  148. entries,  but to those defined by the user which are accorded a specific
  149. time to live.
  150.  
  151. Clients caching entries of class dynamicObject should use  the  entryTtl
  152. attribute  instead  of  the  ttl  to determine an object's TTL. The same
  153. behaviour applies: if the value is 0, the entry should not be cached.
  154.  
  155. The dNSDomain  object  class  [rfc1279]  contains  attributes,  such  as
  156. dNSRecord,  which  may  include  embedded TTLs. If the caching agent has
  157. specific cognizance of these attributes, it may wish to honour  them  in
  158. preference to the entryTtl or ttl attributes. This is not required.
  159.  
  160. 7.  Security Considerations
  161.  
  162. A caching scheme has implications on the accuracy and security of  data.
  163. Both  applications  and  data providers should be aware of how important
  164. information consistency is for the data they are using or providing.
  165.  
  166. When accessing anything but publicly available information, care must be
  167. taken  by  the caching entity to ensure that the intended access control
  168. policy of the directory is not violated. This may be accomplished by not
  169. caching  non-public information at all, or by having an understanding of
  170. the source site's access control policies.  Note  that  understanding  a
  171.  
  172.  
  173.  
  174. Howes & Howard                                                  [Page 3]
  175.  
  176.  
  177.  
  178.  
  179.  
  180. Expires March 1998                                        INTERNET DRAFT
  181.  
  182.  
  183. site's  access  control  policy may be difficult, given the existence of
  184. proprietary schemes, and the fact that there may be mechanisms in  place
  185. not  visible  or  detectable by the caching entity. These mechanisms may
  186. even make the determination of what information is  publicly  accessible
  187. difficult or impossible.
  188.  
  189. 8.  Bibliography
  190.  
  191.  
  192. [ldapv3-1]Wahl, M., Howes, T., Kille, S., "Lightweight Directory  Access
  193.           Protocol    (v3)",   INTERNET-DRAFT   <draft-ietf-asid-ldapv3-
  194.           protocol-07.txt>, August 1997.
  195.  
  196. [rfc1034] Mockapetris, P., "Domain Names  -  Concepts  and  Facilities",
  197.           Request for Comments (RFC) 1034, November 1987.
  198.  
  199. [ldapv3-2]Wahl, M., Coulbeck, A., Howes,  T.,  Kille,  S.,  "Lightweight
  200.           Directory Access Protocol (v3): Attribute Syntax Definitions",
  201.           INTERNET-DRAFT     <draft-ietf-asid-ldapv3-attributes-07.txt>,
  202.           August 1997.
  203.  
  204. [x500]    "Information Processing Systems - Open Systems Interconnection
  205.           -  The  Directory: Overview of Concepts, Models and Services",
  206.           ISO/IEC JTC 1/SC21, International Standard 9594-1, 1988.
  207.  
  208. [v3ext]   Yaacovi, Y., Wahl, M., Genovese,  T.,  "Lightweight  Directory
  209.           Access  Protocol  (v3):  Extensions for Dynamic Directory Ser-
  210.           vices",    INTERNET-DRAFT     <draft-ietf-asid-ldapv3-dynamic-
  211.           06.txt>, September 1997.
  212.  
  213. [rfc1279] Kille, S., "X.500 and Domains",  Request  for  Comments  (RFC)
  214.           1279, November 1991.
  215.  
  216. 9.  Authors' Addresses
  217.  
  218.    Tim Howes
  219.    Netscape Communications Corp.
  220.    501 E. Middlefield Rd.
  221.    Mountain View, CA 94043
  222.    USA
  223.    +1 415 937-3419
  224.    howes@netscape.com
  225.  
  226.    Luke Howard
  227.    PO Box 59
  228.    Central Park Vic 3145
  229.    Australia
  230.    lukeh@xedoc.com
  231.  
  232.  
  233.  
  234. Howes & Howard                                                  [Page 4]
  235.  
  236.  
  237.  
  238.  
  239.  
  240. Expires March 1998                                        INTERNET DRAFT
  241.  
  242.  
  243.  
  244.  
  245.  
  246.  
  247.  
  248.  
  249.  
  250.  
  251.  
  252.  
  253.  
  254.  
  255.  
  256.  
  257.  
  258.  
  259.  
  260.  
  261.  
  262.  
  263.  
  264.  
  265.  
  266.  
  267.  
  268.  
  269.  
  270.  
  271.  
  272.  
  273.  
  274.  
  275.  
  276.  
  277.  
  278.  
  279.  
  280.  
  281.  
  282.  
  283.  
  284.  
  285.  
  286.  
  287.  
  288.  
  289.  
  290.  
  291.  
  292.  
  293.  
  294. Howes & Howard                                                  [Page 5]
  295.  
  296.  
  297.