2 Change Record Object Class Definition Gordon Good
3 INTERNET-DRAFT Netscape Communications
6 Definition of an Object Class to Hold LDAP Change Records
7 Filename: draft-good-ldap-changelog-01.txt
11 This document is an Internet-Draft and is in full conformance with
12 all provisions of Section 10 of RFC2026.
14 Internet-Drafts are working documents of the Internet Engineering
15 Task Force (IETF), its areas, and its working groups. Note that other
16 groups may also distribute working documents as Internet-Drafts.
18 Internet-Drafts are draft documents valid for a maximum of six months
19 and may be updated, replaced, or obsoleted by other documents at any
20 time. It is inappropriate to use Internet- Drafts as reference
21 material or to cite them other than as "work in progress."
23 The list of current Internet-Drafts can be accessed at
24 http://www.ietf.org/ietf/1id-abstracts.txt
26 The list of Internet-Draft Shadow Directories can be accessed at
27 http://www.ietf.org/shadow.html.
30 This Internet Draft expires September 10, 2000.
36 In order to support more flexible replication methods, it is
37 desirable to specify some manner in which an LDAP client may retrieve
38 a set of changes which have been applied to an LDAP server's
39 database. The client, which may be another LDAP server, may then
40 choose to update its own replicated copy of the data. This document
41 specifies an object class which may be used to represent changes
42 applied to an LDAP server. It also specifies a method for
43 discovering the location of the container object which holds these
44 change records, so that clients and servers have a common rendezvous
45 point for this information.
49 Background and Intended Usage
51 This document describes an objectclass which can be used to represent
52 changes which have been applied to a directory server. It also
53 suggests a common location for a container which holds these objects.
57 Good March 9, 2000 [Page 1]
59 INTERNET-DRAFT Change Record Object Class 11 March 1998
62 A client may update its local copy of directory information by
63 reading the entries within this container, and applying the changes
64 to its local database.
66 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
67 "SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY" in this document are
68 to be interpreted as described in RFC 2119 [3].
70 New Attribute Types Used in the changeLogEntry Object Class
72 ( 2.16.840.1.113730.3.1.5
74 DESC 'a number which uniquely identifies a change made to a
77 EQUALITY 'integerMatch'
78 ORDERING 'integerOrderingMatch' )
80 ( 2.16.840.1.113730.3.1.6
82 DESC 'the DN of the entry which was modified'
83 EQUALITY distinguishedNameMatch
86 ( 2.16.840.1.113730.3.1.7
88 DESC 'the type of change made to an entry'
89 EQUALITY caseIgnoreMatch
90 SYNTAX 'DirectoryString' )
92 ( 2.16.840.1.113730.3.1.8
94 DESC 'a set of changes to apply to an entry'
95 SYNTAX 'OctetString' )
97 ( 2.16.840.1.113730.3.1.9
99 DESC 'the new RDN of an entry which is the target of a
101 EQUALITY distinguishedNameMatch
104 ( 2.16.840.1.113730.3.1.10
106 DESC 'a flag which indicates if the old RDN should be retained
107 as an attribute of the entry'
108 EQUALITY booleanMatch
113 Good March 9, 2000 [Page 2]
115 INTERNET-DRAFT Change Record Object Class 11 March 1998
118 ( 2.16.840.1.113730.3.1.11
120 DESC 'the new parent of an entry which is the target of a
122 EQUALITY distinguishedNameMatch
126 Schema Definition of the changeLogEntry Object Class
128 ( 2.16.840.1.113730.3.2.1
129 NAME 'changeLogEntry'
133 changeNumber $ targetDN $ changeType
136 changes $ newRDN $ deleteOldRDN $ newSuperior
142 Discussion of changeLogEntry Attributes:
144 changeNumber: the change number, as assigned by the supplier. This
145 integer MUST strictly increase as new entries are added, and must
146 always be unique within a given server. Syntax: INTEGER
148 targetdn: the distinguished name of the entry which was added,
149 modified or deleted. In the case of a modrdn operation, the targetdn
150 gives the DN of the entry before it was modified. Syntax: DN
152 changeType: the type of change. One of: "add", "delete", "modify",
153 "modrdn". Later RFCs may define additional values for changeType.
154 Syntax: DirectoryString
156 changes: the changes which were made to the directory server. These
157 changes are in LDIF format, which is described in [1].
160 newRDN: the new RDN (Relative Distinguished Name) of the entry, if the
161 changeType is "modrdn". If the changeType attribute does not have the
162 value "modrdn", then there should be no values contained in the newRDN
169 Good March 9, 2000 [Page 3]
171 INTERNET-DRAFT Change Record Object Class 11 March 1998
174 deleteOldRDN: a flag which tells whether the old RDN of the entry
175 should be retained as a distinguished attribute of the entry, or
176 should be deleted. A value of "FALSE" indicates that the RDN should be
177 retained as a distinguished attribute, and a value of "TRUE" indicates
178 that it should not be retained as a distinguished attribute of the
179 entry. If any value other than "TRUE" or "FALSE" is contained in the
180 deleteOldRDN attribute, or if the deleteOldRDN contains multiple
181 values, the RDN should be retained as a distinguished attribute (that
182 is, "FALSE" is the default if no values are present, or if illegal
186 newSuperior: if present, gives the name of the entry which
187 becomes the immediate superior of the existing entry. This optional
188 attribute reflects LDAPv3 functionality, and MUST NOT be generated
189 by LDAPv2 servers [2].
194 Discussion of the changeLogEntry object class
196 The changeLogEntry object class is used to represent changes made to a
197 directory server. The set of changes made to a directory server, then,
198 is given by the ordered set of all entries within the changelog
199 container, ordered by changeNumber.
201 A client may synchronize its local copy of a remote directory server's
202 contents by searching the remote server's changelog container for any
203 entries where the changenumber is greater than or equal to the last
204 change previously retrieved from that server. If the entry with the
205 changenumber matching the last change retrieved is not returned in the
206 search results, then the server's changelog has been trimmed. The
207 client must then fall back to reading the entire directory to bring its
208 copy in sync with the server's.
210 Assuming that the client has successfully retrieved one or more changelog
211 entries from the server, it can then use the information contained in each
212 entry to update the corresponding entry (named by the targetDN attribute)
213 in its local copy of the database.
215 Note that, due to access control restrictions, the client is not guaranteed
216 read access to the "changes" attribute. If the client discovers that the
217 "changes" attribute has no values, then it must read the entry given by
218 the targetDN attribute, possibly only retrieving attributes it deems
219 "interesting". However, in the case of delete and modrdn operations, there
220 is never a "changes" attribute, so it is never necessary to read the target
221 entry in these cases.
225 Good March 9, 2000 [Page 4]
227 INTERNET-DRAFT Change Record Object Class 11 March 1998
230 Examples of the changeLogEntry object class
232 In each example below, the "changes" attribute is shown in plain text,
233 with embedded newlines. This is done for clarity. It is intended that
234 newlines be stored in the entry literally, not encoded in any way.
235 If a "changes" attribute value is stored in an LDIF file, it must
238 Example 1: A changeLogEntry representing the addition of a
239 new entry to the directory
241 dn: changenumber=1923, cn=changelog
243 targetdn: cn=Barbara Jensen, ou=Accounting, o=Ace Industry, c=US
245 changes: cn: Barbara Jensen\ncn: Babs Jensen\nsn: Jensen\n
246 givenname: Barbara\ntelephonenumber: +1 212 555-1212\nmail: babs@ace.com\n
247 objectclass: top\nobjectclass: person\nobjectclass: organizationalPerson\n
248 objectclass: inetOrgPerson
250 Example 2: A changeLogEntry representing the deletion of an entry
253 dn: changenumber=2933, cn=changelog
255 targetdn: cn=Gern Jensen, ou=Product Testing, o=Ace Industry, c=US
258 Example 3: A changeLogEntry representing the modification of an entry
261 dn: changenumber=5883, cn=changelog
263 targetdn: cn=Bjorn Jensen, ou=Product Development, o=Ace Industry, c=US
265 changes: delete: telephonenumber\ntelephonenumber: 1212\n-\n
266 add: telephonenumber\ntelephonenumber: +1 212 555 1212\n-
268 Example 4: A changeLogEntry representing a modrdn operation performed
269 on an entry in the directory
271 dn: changenumber=10042, cn=changelog
273 targetdn: cn=Bjorn Jensen, ou=Product Development, o=Ace Industry, c=US
275 newrdn: cn=Bjorn J Jensen
281 Good March 9, 2000 [Page 5]
283 INTERNET-DRAFT Change Record Object Class 11 March 1998
286 Location of the container containing changeLogEntry objects
288 For LDAPv3 servers, the location of the container which holds
289 changeLogEntry objects is obtained by reading the "changeLog" attribute
290 of a server's root DSE. For example, if the container's root is
291 "cn=changelog", then the root DSE must have an attribute named
292 "changeLog" with the value "cn=changelog".
294 The "changelog" attribute is defined as follows:
296 ( 2.16.840.1.113730.3.1.35
298 DESC 'the distinguished name of the entry which contains
299 the set of entries comprising this server's changelog'
300 EQUALITY distinguishedNameMatch
304 For LDAPv2 servers, the name of the changelog container must be
307 Interoperability between LDAPv2 and LDAPv3 implementations
309 Implementors are discouraged from developing implementations in which
310 an LDAPv2 server is synchronized from an LDAPv3 server using the
311 changelog method described in this document. Problems can arise when an
312 LDAPv2 server reads a "moddn" changelog entry which gives a new
313 superior. Since LDAPv2 does not support such an operation, there is not
314 way for the v2 server to perform the moddn operation atomically. It
315 could, of course, delete all the entries under the old superior and add
316 them under the new superior entry, but such an operation would either
317 not be atomic, or require extensive server-side support on the LDAPv2
318 server to make the operation appear as if it were atomic.
320 It is recommended that servers which only implement LDAPv2 should
321 refuse to synchronize from LDAPv3 servers. Before beginning
322 synchronization, the LDAPv2 server should attempt to read the root DSE
323 of the supplier server. If the root DSE is present, and the
324 supportedldapversion attribute contained in the root DSE contains the
325 value "3", then the LDAPv2 server should immediately disconnect and
326 proceed no further with synchronization.
328 Security Considerations
330 Servers implementing this scheme MUST NOT allow the "changes"
331 attribute to be generally readable. The "changes" attribute contains
332 all modifications made to an entry, and some changes may contain
333 sensitive data, e.g. passwords.
337 Good March 9, 2000 [Page 6]
339 INTERNET-DRAFT Change Record Object Class 11 March 1998
342 If a server does allow read access on the "changes: attribute to a
343 particular bound DN, then that DN should be trusted. For example, two
344 cooperating servers may exchange the password for some DN which is
345 granted read access to the "changes" attribute of the changeLog. This
346 would allow one server to retrieve changes and apply them directly to
349 In situations where the "changes" attribute is not readable by a client,
350 that client may still use the entries in the changeLog to construct a
351 list of entry DNs which are known to have changed since the last time
352 the client synchronized. The client may then read each of those entries,
353 subject to whatever access control is in effect on the server,
354 and update its local copy of each entry.
356 Servers implementing this scheme should disallow write access to the
357 changelog container object and all entries contained within.
363 This material is based in part upon work supported by the National
364 Science Foundation under Grant No. NCR-9416667.
370 [1] Good, G., "The LDAP Data Interchange Format", INTERNET-DRAFT
371 draft-good-ldap-ldif-06.txt, Netscape Communications Corp., March 2000
372 <URL:ftp://ftp.ietf.org/internet-drafts/draft-good-ldap-ldif-06.txt>
374 [2] Wahl, M., Howes, T., Kille, S., "Lightweight Directory Access
375 Protocol (v3)", RFC 2251 Critical Angle, Inc., Netscape Communications Corp.,
376 ISODE Consortium, July, 1997,
377 <URL:ftp://ftp.isi.edu/in-notes/rfc2251.txt>
379 [3] S. Bradner, "Key Words for use in RFCs to Indicate Requirement
380 Levels", Harvard University, RFC 2119, March 1997,
381 <URL:http://ds.internic.net/rfc/rfc2119.txt>
387 Netscape Communications Corp.
388 501 E. Middlefield Rd.
393 Good March 9, 2000 [Page 7]
395 INTERNET-DRAFT Change Record Object Class 11 March 1998
398 Mountain View, CA 94043, USA
399 Phone: +1 650 937-3825
400 EMail: ggood@netscape.com
402 This Internet Draft expires September 10, 2000
449 Good March 9, 2000 [Page 8]