idnits 2.17.1 draft-good-ldap-changelog-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-03-29) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 33 instances of too long lines in the document, the longest one being 8 characters in excess of 72. ** The abstract seems to contain references ([2], [3], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (11 March 1998) is 9515 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-05) exists of draft-good-ldap-ldif-03 ** Obsolete normative reference: RFC 2251 (ref. '2') (Obsoleted by RFC 4510, RFC 4511, RFC 4512, RFC 4513) Summary: 11 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Change Record Object Class Definition Gordon Good 3 INTERNET-DRAFT Netscape Communications 4 11 March 1998 6 Definition of an Object Class to Hold LDAP Change Records 7 Filename: draft-good-ldap-changelog-00.txt 9 Status of this Memo 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its 13 areas, and its working groups. Note that other groups may also 14 distribute working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six 17 months and may be updated, replaced, or obsoleted by other 18 documents at any time. It is inappropriate to use Internet- 19 Drafts as reference material or to cite them other than as 20 ``work in progress.'' 22 To learn the current status of any Internet-Draft, please check 23 the ``1id-abstracts.txt'' listing contained in the Internet- 24 Drafts Shadow Directories on ds.internic.net (US East Coast), 25 nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or 26 munnari.oz.au (Pacific Rim). 28 This Internet Draft expires October 1st, 1998. 30 Abstract 32 In order to support more flexible replication methods, it is 33 desirable to specify some manner in which an LDAP client may retrieve 34 a set of changes which have been applied to an LDAP server's 35 database. The client, which may be another LDAP server, may then 36 choose to update its own replicated copy of the data. This document 37 specifies an object class which may be used to represent changes 38 applied to an LDAP server. It also specifies a method for 39 discovering the location of the container object which holds these 40 change records, so that clients and servers have a common rendezvous 41 point for this information. 43 Background and Intended Usage 45 This document describes an objectclass which can be used to represent 46 changes which have been applied to a directory server. It also 47 suggests a common location for a container which holds these objects. 48 A client may update its local copy of directory information by 49 reading the entries within this container, and applying the changes 50 to its local database. 52 The key words "MUST", "MAY", and "SHOULD" used in this document are 53 to be interpreted as described in [3]. 55 New Attribute Types Used in the changeLogEntry Object Class 57 ( 2.16.840.1.113730.3.1.5 58 NAME 'changeNumber' 59 DESC 'a number which uniquely identifies a change made to a 60 directory entry' 61 SYNTAX 'INTEGER' 62 EQUALITY 'integerMatch' 63 ORDERING 'integerOrderingMatch' ) 65 ( 2.16.840.1.113730.3.1.6 66 NAME 'targetDN' 67 DESC 'the DN of the entry which was modified' 68 EQUALITY distinguishedNameMatch 69 SYNTAX 'DN' ) 71 ( 2.16.840.1.113730.3.1.7 72 NAME 'changeType' 73 DESC 'the type of change made to an entry' 74 EQUALITY caseIgnoreMatch 75 SYNTAX 'DirectoryString' ) 77 ( 2.16.840.1.113730.3.1.8 78 NAME 'changes' 79 DESC 'a set of changes to apply to an entry' 80 SYNTAX 'OctetString' ) 82 ( 2.16.840.1.113730.3.1.9 83 NAME 'newRDN' 84 DESC 'the new RDN of an entry which is the target of a 85 modrdn operation' 86 EQUALITY distinguishedNameMatch 87 SYNTAX 'DN' ) 89 ( 2.16.840.1.113730.3.1.10 90 NAME 'deleteOldRDN' 91 DESC 'a flag which indicates if the old RDN should be retained 92 as an attribute of the entry' 93 EQUALITY booleanMatch 94 SYNTAX 'BOOLEAN' ) 96 ( 2.16.840.1.113730.3.1.11 97 NAME 'newSuperior' 98 DESC 'the new parent of an entry which is the target of a 99 moddn operation' 100 EQUALITY distinguishedNameMatch 101 SYNTAX 'DN' ) 103 Schema Definition of the changeLogEntry Object Class 105 ( 2.16.840.1.113730.3.2.1 106 NAME 'changeLogEntry' 107 SUP top 108 STRUCTURAL 109 MUST ( 110 changeNumber $ targetDN $ changeType 111 ) 112 MAY ( 113 changes $ newRDN $ deleteOldRDN $ newSuperior 114 ) 115 ) 117 Discussion of changeLogEntry Attributes: 119 changeNumber: the change number, as assigned by the supplier. This 120 integer MUST strictly increase as new entries are added, and must 121 always be unique within a given server. Syntax: INTEGER 123 targetdn: the distinguished name of the entry which was added, 124 modified or deleted. In the case of a modrdn operation, the targetdn 125 gives the DN of the entry before it was modified. Syntax: DN 127 changeType: the type of change. One of: "add", "delete", "modify", 128 "modrdn". Later RFCs may define additional values for changeType. 129 Syntax: DirectoryString 131 changes: the changes which were made to the directory server. These 132 changes are in LDIF format, which is described in [1]. 133 Syntax: OctetString 135 newRDN: the new RDN (Relative Distinguished Name) of the entry, if the 136 changeType is "modrdn". If the changeType attribute does not have the 137 value "modrdn", then there should be no values contained in the newRDN 138 attribute. 140 Syntax: DN 142 deleteOldRDN: a flag which tells whether the old RDN of the entry 143 should be retained as a distinguished attribute of the entry, or 144 should be deleted. A value of "FALSE" indicates that the RDN should be 145 retained as a distinguished attribute, and a value of "TRUE" indicates 146 that it should not be retained as a distinguished attribute of the 147 entry. If any value other than "TRUE" or "FALSE" is contained in the 148 deleteOldRDN attribute, or if the deleteOldRDN contains multiple 149 values, the RDN should be retained as a distinguished attribute (that 150 is, "FALSE" is the default if no values are present, or if illegal 151 values are present). 152 Syntax: BOOLEAN 154 newSuperior: if present, gives the name of the entry which 155 becomes the immediate superior of the existing entry. This optional 156 attribute reflects LDAPv3 functionality, and MUST NOT be generated 157 by LDAPv2 servers [2]. 158 Syntax: DN 160 Discussion of the changeLogEntry object class 162 The changeLogEntry object class is used to represent changes made to a 163 directory server. The set of changes made to a directory server, then, 164 is given by the ordered set of all entries within the changelog 165 container, ordered by changeNumber. 167 A client may synchronize its local copy of a remote directory server's 168 contents by searching the remote server's changelog container for any 169 entries where the changenumber is greater than or equal to the last 170 change previously retrieved from that server. If the entry with the 171 changenumber matching the last change retrieved is not returned in the 172 search results, then the server's changelog has been trimmed. The 173 client must then fall back to reading the entire directory to bring its 174 copy in sync with the server's. 176 Assuming that the client has successfully retrieved one or more changelog 177 entries from the server, it can then use the information contained in each 178 entry to update the corresponding entry (named by the targetDN attribute) 179 in its local copy of the database. 181 Note that, due to access control restrictions, the client is not guaranteed 182 read access to the "changes" attribute. If the client discovers that the 183 "changes" attribute has no values, then it must read the entry given by 184 the targetDN attribute, possibly only retrieving attributes it deems 185 "interesting". However, in the case of delete and modrdn operations, there 186 is never a "changes" attribute, so it is never necessary to read the target 187 entry in these cases. 189 Examples of the changeLogEntry object class 191 In each example below, the "changes" attribute is shown in plain text, 192 with embedded newlines. This is done for clarity. It is intended that 193 newlines be stored in the entry literally, not encoded in any way. 194 If a "changes" attribute value is stored in an LDIF file, it must 195 base-64 encoded. 197 Example 1: A changeLogEntry representing the addition of a 198 new entry to the directory 200 dn: changenumber=1923, cn=changelog 201 changenumber: 1923 202 targetdn: cn=Barbara Jensen, ou=Accounting, o=Ace Industry, c=US 203 changetype: add 204 changes: cn: Barbara Jensen\ncn: Babs Jensen\nsn: Jensen\n 205 givenname: Barbara\ntelephonenumber: +1 212 555-1212\nmail: babs@ace.com\n 206 objectclass: top\nobjectclass: person\nobjectclass: organizationalPerson\n 207 objectclass: inetOrgPerson 209 Example 2: A changeLogEntry representing the deletion of an entry 210 from the directory 212 dn: changenumber=2933, cn=changelog 213 changenumber: 2933 214 targetdn: cn=Gern Jensen, ou=Product Testing, o=Ace Industry, c=US 215 changetype: delete 217 Example 3: A changeLogEntry representing the modification of an entry 218 in the directory 220 dn: changenumber=5883, cn=changelog 221 changenumber: 5883 222 targetdn: cn=Bjorn Jensen, ou=Product Development, o=Ace Industry, c=US 223 changetype: modify 224 changes: delete: telephonenumber\ntelephonenumber: 1212\n-\n 225 add: telephonenumber\ntelephonenumber: +1 212 555 1212\n- 227 Example 4: A changeLogEntry representing a modrdn operation performed 228 on an entry in the directory 230 dn: changenumber=10042, cn=changelog 231 changenumber: 10042 232 targetdn: cn=Bjorn Jensen, ou=Product Development, o=Ace Industry, c=US 233 changetype: modrdn 234 newrdn: cn=Bjorn J Jensen 235 deleteoldrdn: FALSE 237 Location of the container containing changeLogEntry objects 239 For LDAPv3 servers, the location of the container which holds 240 changeLogEntry objects is obtained by reading the "changeLog" attribute 241 of a server's root DSE. For example, if the container's root is 242 "cn=changelog", then the root DSE must have an attribute named 243 "changeLog" with the value "cn=changelog". 245 The "changelog" attribute is defined as follows: 247 ( 2.16.840.1.113730.3.1.35 248 NAME 'changelog' 249 DESC 'the distinguished name of the entry which contains 250 the set of entries comprising this server's changelog' 251 EQUALITY distinguishedNameMatch 252 SYNTAX 'DN' 253 ) 255 For LDAPv2 servers, the name of the changelog container must be 256 "cn=changelog". 258 Differences from previous versions of this document 260 Differences between draft-ietf-asid-changelog-00.txt and 261 draft-ietf-asid-changelog-01.txt 263 1) Fixed a deficiency in the syntax of the changeNumber attribute. The 264 attribute now has INTEGER syntax, with appropriate matching and 265 ordering rules defined. 267 2) Removed unneeded substring matching rules from the changeType and 268 deleteOldRDN attribute definitions. 270 3) Made use of MAY, SHOULD, etc. consistent with RFC 2119. 272 4) Renamed document (now an individual submission). 274 5) Changed syntax of "changes" attribute from "Binary" to "OctetString". 276 6) Removed references to X.500 supplier and consumer-initiated 277 replication. 279 7) Updated references to current drafts/proposed standards documents. 281 Security Considerations 283 Servers implementing this scheme MUST NOT allow the "changes" 284 attribute to be generally readable. The "changes" attribute contains 285 all modifications made to an entry, and some changes may contain 286 sensitive data, e.g. passwords. 288 If a server does allow read access on the "changes: attribute to a 289 particular bound DN, then that DN should be trusted. For example, two 290 cooperating servers may exchange the password for some DN which is 291 granted read access to the "changes" attribute of the changeLog. This 292 would allow one server to retrieve changes and apply them directly to 293 its database. 295 In situations where the "changes" attribute is not readable by a client, 296 that client may still use the entries in the changeLog to construct a 297 list of entry DNs which are known to have changed since the last time 298 the client synchronized. The client may then read each of those entries, 299 subject to whatever access control is in effect on the server, 300 and update its local copy of each entry. 302 Servers implementing this scheme should disallow write access to the 303 changelog container object and all entries contained within. 305 Acknowledgements 307 This material is based in part upon work supported by the National 308 Science Foundation under Grant No. NCR-9416667. 310 References 312 [1] Good, G., "The LDAP Data Interchange Format", INTERNET-DRAFT 313 draft-good-ldap-ldif-03.txt, Netscape Communications Corp., March 1997, 314 316 [2] Wahl, M., Howes, T., Kille, S., "Lightweight Directory Access 317 Protocol (v3)", RFC 2251 Critical Angle, Inc., Netscape Communications Corp., 318 ISODE Consortium, July, 1997, 319 321 [3] S. Bradner, "Key Words for use in RFCs to Indicate Requirement 322 Levels", Harvard University, RFC 2119, March 1997, 323 325 Author's Address 327 Gordon Good 328 Netscape Communications Corp. 329 501 E. Middlefield Rd. 330 Mailstop MV068 331 Mountain View, CA 94043, USA 332 Phone: +1 415 937-3825 333 EMail: ggood@netscape.com 335 This Internet Draft expires October 1st, 1998.