From: Will Ballantyne Date: Fri, 5 Feb 1999 06:59:25 +0000 (+0000) Subject: Internet drafts associated with LDAP alias change changelog implementation. X-Git-Tag: OPENLDAP_SLAPD_BACK_LDAP~628 X-Git-Url: https://git.sur5r.net/?a=commitdiff_plain;h=cd9ab253d63e648d7033db6c8d69034ac580cc2c;p=openldap Internet drafts associated with LDAP alias change changelog implementation. --- diff --git a/doc/drafts/draft-byrne-ldap-alias-00.txt b/doc/drafts/draft-byrne-ldap-alias-00.txt new file mode 100644 index 0000000000..0595ecdfe0 --- /dev/null +++ b/doc/drafts/draft-byrne-ldap-alias-00.txt @@ -0,0 +1,324 @@ + + Internet-Draft D. Byrne, IBM + LDAP Extensions WG L. Poitou, Sun + Intended Category: Standards Track E. Stokes, IBM + Expires: 20 October 1998 + + 20 April 1998 + + Use of Aliases within LDAP + + + STATUS OF THIS MEMO + + This document is an Internet Draft. Internet Drafts are + working documents of the Internet Engineering Task Force + (IETF), its Areas, and its Working Groups. Note that other + groups may also distribute working documents as Internet + Drafts. + + Internet Drafts are draft documents valid for a maximum of six + months. Internet Drafts may be updated, replaced, or obsoleted + by other documents at any time. It is not appropriate to use + Internet Drafts as reference material or to cite them other + than as a "working draft" or "work in progress." + + To view the entire list of current Internet-Drafts, please + check the "1id-abstracts.txt" listing contained in the + Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), + ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern + Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East + Coast), or ftp.isi.edu (US West Coast). + + Comments and suggestions on this document are encouraged. + Comments on this document should be sent to the LDAPEXT + working group discussion list: + + ietf-ldapext@netscape.com + + ABSTRACT + + This document describes the suggested behavior for aliases for + LDAPv3 and above to improve LDAP server interoperability . + + The key words "MUST", "SHOULD", and "MAY" used in this + document are to be interpreted as described in [Bradner97]. + + + 1. Objectives + + + Aliases may be used within LDAP to reference entries anywhere + within the directory tree. Conceptually, an alias is simply a + pointer to the DIT entry it represents. It does not contain + additional information about that entry; only the location of + the entry. + + The behavior of the alias object within LDAP is not well- + defined, both in creation of the alias object and the behavior + when dereferencing the alias. + + For successful interoperability, the expected behavior of + servers when encountering alias objects SHOULD be consistent. + + Additionally, it MUST be possible to use aliases without + changing the LDAPv3 schema as defined in [Wahl] and without + adding server-dependent data. + + + 2. Schema Definition + + + 2.1 Schema Expansion + + The alias objectclass definitions presented in the LDAPv3 + Schema [Wahl] are the basis for aliasing within ldap. The + alias objectclass is a Structural objectclass with a single + required attribute; the single valued aliasObjectName. + + This definition of the alias objectclass does not allow for + any attribute other than 'aliasedObjectName' to be used as the + naming attribute within the RDN. The resulting dn for the + alias object must therefore be of the form + "aliasedObjectName=, , ..." This is not a + user-friendly name for a directory entry, and quite possibly + corrupts the naming hierarchy within the directory tree. + + In order to remain true the concept of an alias; that it is + merely a pointer to another entry, an entry of objectclass + alias SHOULD NOT be combined with any other objectclass. If + multiple objectclasses are combined, it becomes possible to + add information to the alias entry without violating the + schema rules. + + While not explicitly specified as either a 'required' or + 'may', any naming attribute MUST be allowed to form the RDN of + the alias. Restricting the possible naming attributes would + potentially corrupt the hierarchy. For example, it would be + impossible to distinguish between a person alias and an + organisation alias. + + 2.2 AliasObject Objectclass + + In order to create an alias object which can be appropriately + named to that which it represents, the definition of the alias + object MUST be expanded. A new objectclass must be defined + which inherits from the current definition of alias but + extends the attributes allowed within the RDN. + + ( 1.3.6.1.4.1.42.2.27.1.2.1 + NAME 'aliasObject' + DESC objectclass for all alias objects + SUP 'ALIAS' + MAY * + ) + + The '*' allows any naming attribute to be used in forming the + RDN of the object. + + For example, the following is a correct LDIF: + dn: cn=John Doe, ou=myOrg, c=US + objectclass: alias + objectclass: aliasObject + aliasedObjectName: cn=President, ou=myOrg, c=US + cn: John Doe + + To prevent the alias from containing extra information about + the object, the naming attribute SHOULD contain only a single + value. + + For example, the following is not a correct LDIF: + dn: cn=John Doe, ou=myOrg, c=US + objectclass: alias + objectclass: aliasObject + aliasedObjectName: cn=President, ou=myOrg, c=US + cn: John Doe + cn: Doe + + Similarly, the following would not be a correct LDIF file + because it adds extra information to the alias object. + + dn: cn=John Doe, ou=myOrg, c=US + objectclass: alias + objectclass: aliasObject + aliasedObjectName: cn=President, ou=myOrg, c=US + cn: John Doe + title: President + + The naming attribute used to form the RDN of the object SHOULD + reflect the naming attribute of the referenced object. + However, there are some cases where the naming attribute MAY + be different. + + Within the X.501 [ITU-T], the attribute used to described the + aliased object is 'aliasedEntryName'. Since the OID for + 'aliasedEntryName' and 'aliasedObjectName' are the same for + both X.500 and LDAP, LDAP servers SHOULD treat the + 'aliasedEntryName' as a synonym for 'aliasedObjectName'. + + + 3. Alias Behavior + + In general alias objects SHOULD NOT be dereferenced during any + operation other than search unless requested to do so by the + client. + + Since an alias points to another section of the tree, it MUST + NOT be possible to add an object under an alias object; alias + objects MUST always be leaf nodes. + + During the dereferencing of aliases, a loop is detected if the + server visits the same alias entry more than once. In this + case a data integrity error has occurred and the server MUST + return an error of 'aliasProblem' + + If an alias is dereferenced, and the resulting directory entry + does not exists, a data integrity problem has occurred, and + the server MUST return an error code of + 'aliasDereferencingProblem' + + If the base entry for an ldapsearch is an alias, and alias + dereferencing is set to either derefFindBaseObj, or + derefAlways, the base entry MUST be dereferenced before the + search is performed. The new base for the search will become + the entry to which the alias resolves. The search is then + performed. + + If multiple aliases are chained, the alias for the first + object MUST resolve to the last entry in the chain. For + example, A, B, and C are alias objects. If A points to B which + points to C which points to D, A resolves to D when + dereferencing the alias. + + If an alias is dereferenced as part of a search, the alias + entry itself SHOULD NOT be returned as part of the search. + + If an alias matches the search filter, and dereferencing is + set to 'searching' or 'always', the dereferenced object SHOULD + be returned, even if it does not match the filter. + + If the alias is not dereferenced during the search, and it + matches the filter, then it SHOULD be returned within the + search result. + + Each directory object matching a filter SHOULD be returned + only once during a search. If an entry is found twice because + of aliases pointing to a part of the tree already searched, + the entry SHOULD NOT be returned to the client a second time. + + 4. Scenarios + + Using the following LDIF, the scenarios would return the + expected information as follows: + + dn: c=myCountry + c: myCountry + objectclass: country + + dn: ou=Area1, c=myCountry + ou: Area1 + aliasedObjectName: o=myCorporation, c=myCountry + objectclass: alias + objectclass:aliasObject + + dn: o=myCorporation, c=myCountry + ou: myCorporation + objectclass:organization + + dn: cn=President, o=myCorporation, c=myCountry + cn: President + aliasObjectName: cn=John Doe, o=myCorporation, c=myCountry + objectclass: alias + objectclass: aliasObject + + dn: cn=John Doe, o=myCorporation, c=myCountry + cn: John Doe + objectclass: person + + + c = myCountry + / | + ou = Area1 -----> o = myCorporation + | \ + cn=President ---> cn = John Doe + + Performing a base search of 'ou = Area1, c=myCountry' with a + filter of 'objectclass=aliasObject' + NeverDerefAlias would return 'ou=Area1, c=myCountry' + DerefFinding would return 'cn=President, o=myCorporation, + c=myCountry' + DerefSearching would return 'o=myCorporation, + c=myCountry' + DerefAlways would return 'cn=John Doe, o=myCorporation, + c=myCountry' + + Performing a one level search of 'c=myCountry' with a filter + of 'ou = * ' + NeverDerefAlias would return 'ou=Area1, c=myCountry' + DerefFinding would return 'ou=Area1, c=myCountry' + DerefSearching would return 'o=myCorporation, + c=myCountry' + DerefAlways would return ' o=myCorporation, c=myCountry' + + Performing a full tree search of 'c=myCountry' with a filter + of ' cn = President ' + NeverDerefAlias would return 'cn=President, o=myCorporation, + c=myCountry' + DerefFinding would return 'cn=President, o=myCorporation, + c=myCountry' + DerefSearching would return 'cn=John Doe, o=myCorporation, + c=myCountry' + DerefAlways would return 'cn=John Doe, o=myCorporation, + c=myCountry' + + + 6. Security Considerations + + Permissions to dereferencing an alias, adding, deleting or + returning alias entries are decided by the directory server's + ACL administration policy. + + + 7. References + + [LDAPv3] M. Wahl, T. Howes, S. Kille, "Lightweight Directory + Access Protocol (v3)", RFC 2251, December 1997. + + [Whal] M.Wahl, A, Coulbeck, T. Howes, S. Kille, "Lightweight + Directory Access Protocol (v3)": Attribute Syntax Definitions, + RFC 2252, December 1997. + + [Bradner97] Bradner, Scott, "Key Words for use in RFCs to + Indicate Requirement Levels", RFC 2119. + + [ITU-T] ITU-T Rec. X.501, "The Directory: Models", 1993 + + + AUTHOR(S) ADDRESS + + + Debbie Byrne + IBM + 11400 Burnet Rd + Austin, TX 78758 + USA + mail-to: djbyrne@us.ibm.com + phone: +1 512 838 1930 + + Ludovic Poitou + Sun Microsystems + 32, Chemin du vieux Chene + 38240 Meylan + France + Phone: +33.(0)4.76.41.42.12 + email: ludovic.poitou@france.sun.com + + Ellen Stokes + IBM + 11400 Burnet Rd + Austin, TX 78758 + USA + mail-to: stokes@austin.ibm.com + phone: +1 512 838 3725 + + diff --git a/doc/drafts/draft-good-ldap-changelog-00.txt b/doc/drafts/draft-good-ldap-changelog-00.txt new file mode 100644 index 0000000000..708c8552f6 --- /dev/null +++ b/doc/drafts/draft-good-ldap-changelog-00.txt @@ -0,0 +1,449 @@ + + + + +Change Record Object Class Definition Gordon Good +INTERNET-DRAFT Netscape Communications + 11 March 1998 + + Definition of an Object Class to Hold LDAP Change Records + Filename: draft-good-ldap-changelog-00.txt + +Status of this Memo + + This document is an Internet-Draft. Internet-Drafts are working + documents of the Internet Engineering Task Force (IETF), its + areas, and its working groups. Note that other groups may also + distribute working documents as Internet-Drafts. + + Internet-Drafts are draft documents valid for a maximum of six + months and may be updated, replaced, or obsoleted by other + documents at any time. It is inappropriate to use Internet- + Drafts as reference material or to cite them other than as + ``work in progress.'' + + To learn the current status of any Internet-Draft, please check + the ``1id-abstracts.txt'' listing contained in the Internet- + Drafts Shadow Directories on ds.internic.net (US East Coast), + nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or + munnari.oz.au (Pacific Rim). + + This Internet Draft expires October 1st, 1998. + + + +Abstract + + In order to support more flexible replication methods, it is + desirable to specify some manner in which an LDAP client may retrieve + a set of changes which have been applied to an LDAP server's + database. The client, which may be another LDAP server, may then + choose to update its own replicated copy of the data. This document + specifies an object class which may be used to represent changes + applied to an LDAP server. It also specifies a method for + discovering the location of the container object which holds these + change records, so that clients and servers have a common rendezvous + point for this information. + + + +Background and Intended Usage + + This document describes an objectclass which can be used to represent + + + +Good March 11, 1998 [Page 1] + +INTERNET-DRAFT Change Record Object Class 11 March 1998 + + + changes which have been applied to a directory server. It also + suggests a common location for a container which holds these objects. + A client may update its local copy of directory information by + reading the entries within this container, and applying the changes + to its local database. + + The key words "MUST", "MAY", and "SHOULD" used in this document are + to be interpreted as described in [3]. + +New Attribute Types Used in the changeLogEntry Object Class + + ( 2.16.840.1.113730.3.1.5 + NAME 'changeNumber' + DESC 'a number which uniquely identifies a change made to a + directory entry' + SYNTAX 'INTEGER' + EQUALITY 'integerMatch' + ORDERING 'integerOrderingMatch' ) + + ( 2.16.840.1.113730.3.1.6 + NAME 'targetDN' + DESC 'the DN of the entry which was modified' + EQUALITY distinguishedNameMatch + SYNTAX 'DN' ) + + ( 2.16.840.1.113730.3.1.7 + NAME 'changeType' + DESC 'the type of change made to an entry' + EQUALITY caseIgnoreMatch + SYNTAX 'DirectoryString' ) + + ( 2.16.840.1.113730.3.1.8 + NAME 'changes' + DESC 'a set of changes to apply to an entry' + SYNTAX 'OctetString' ) + + ( 2.16.840.1.113730.3.1.9 + NAME 'newRDN' + DESC 'the new RDN of an entry which is the target of a + modrdn operation' + EQUALITY distinguishedNameMatch + SYNTAX 'DN' ) + + ( 2.16.840.1.113730.3.1.10 + NAME 'deleteOldRDN' + DESC 'a flag which indicates if the old RDN should be retained + as an attribute of the entry' + EQUALITY booleanMatch + + + +Good March 11, 1998 [Page 2] + +INTERNET-DRAFT Change Record Object Class 11 March 1998 + + + SYNTAX 'BOOLEAN' ) + + ( 2.16.840.1.113730.3.1.11 + NAME 'newSuperior' + DESC 'the new parent of an entry which is the target of a + moddn operation' + EQUALITY distinguishedNameMatch + SYNTAX 'DN' ) + + +Schema Definition of the changeLogEntry Object Class + + ( 2.16.840.1.113730.3.2.1 + NAME 'changeLogEntry' + SUP top + STRUCTURAL + MUST ( + changeNumber $ targetDN $ changeType + ) + MAY ( + changes $ newRDN $ deleteOldRDN $ newSuperior + ) + ) + + + +Discussion of changeLogEntry Attributes: + + changeNumber: the change number, as assigned by the supplier. This + integer MUST strictly increase as new entries are added, and must + always be unique within a given server. Syntax: INTEGER + + targetdn: the distinguished name of the entry which was added, + modified or deleted. In the case of a modrdn operation, the targetdn + gives the DN of the entry before it was modified. Syntax: DN + + changeType: the type of change. One of: "add", "delete", "modify", + "modrdn". Later RFCs may define additional values for changeType. + Syntax: DirectoryString + + changes: the changes which were made to the directory server. These + changes are in LDIF format, which is described in [1]. + Syntax: OctetString + + newRDN: the new RDN (Relative Distinguished Name) of the entry, if the + changeType is "modrdn". If the changeType attribute does not have the + value "modrdn", then there should be no values contained in the newRDN + attribute. + + + +Good March 11, 1998 [Page 3] + +INTERNET-DRAFT Change Record Object Class 11 March 1998 + + + Syntax: DN + + deleteOldRDN: a flag which tells whether the old RDN of the entry + should be retained as a distinguished attribute of the entry, or + should be deleted. A value of "FALSE" indicates that the RDN should be + retained as a distinguished attribute, and a value of "TRUE" indicates + that it should not be retained as a distinguished attribute of the + entry. If any value other than "TRUE" or "FALSE" is contained in the + deleteOldRDN attribute, or if the deleteOldRDN contains multiple + values, the RDN should be retained as a distinguished attribute (that + is, "FALSE" is the default if no values are present, or if illegal + values are present). + Syntax: BOOLEAN + + newSuperior: if present, gives the name of the entry which + becomes the immediate superior of the existing entry. This optional + attribute reflects LDAPv3 functionality, and MUST NOT be generated + by LDAPv2 servers [2]. + Syntax: DN + + + +Discussion of the changeLogEntry object class + + The changeLogEntry object class is used to represent changes made to a + directory server. The set of changes made to a directory server, then, + is given by the ordered set of all entries within the changelog + container, ordered by changeNumber. + + A client may synchronize its local copy of a remote directory server's + contents by searching the remote server's changelog container for any + entries where the changenumber is greater than or equal to the last + change previously retrieved from that server. If the entry with the + changenumber matching the last change retrieved is not returned in the + search results, then the server's changelog has been trimmed. The + client must then fall back to reading the entire directory to bring its + copy in sync with the server's. + + Assuming that the client has successfully retrieved one or more changelog + entries from the server, it can then use the information contained in each + entry to update the corresponding entry (named by the targetDN attribute) + in its local copy of the database. + + Note that, due to access control restrictions, the client is not guaranteed + read access to the "changes" attribute. If the client discovers that the + "changes" attribute has no values, then it must read the entry given by + the targetDN attribute, possibly only retrieving attributes it deems + "interesting". However, in the case of delete and modrdn operations, there + + + +Good March 11, 1998 [Page 4] + +INTERNET-DRAFT Change Record Object Class 11 March 1998 + + + is never a "changes" attribute, so it is never necessary to read the target + entry in these cases. + + + +Examples of the changeLogEntry object class + + In each example below, the "changes" attribute is shown in plain text, + with embedded newlines. This is done for clarity. It is intended that + newlines be stored in the entry literally, not encoded in any way. + If a "changes" attribute value is stored in an LDIF file, it must + base-64 encoded. + + Example 1: A changeLogEntry representing the addition of a + new entry to the directory + + dn: changenumber=1923, cn=changelog + changenumber: 1923 + targetdn: cn=Barbara Jensen, ou=Accounting, o=Ace Industry, c=US + changetype: add + changes: cn: Barbara Jensen\ncn: Babs Jensen\nsn: Jensen\n + givenname: Barbara\ntelephonenumber: +1 212 555-1212\nmail: babs@ace.com\n + objectclass: top\nobjectclass: person\nobjectclass: organizationalPerson\n + objectclass: inetOrgPerson + + Example 2: A changeLogEntry representing the deletion of an entry + from the directory + + dn: changenumber=2933, cn=changelog + changenumber: 2933 + targetdn: cn=Gern Jensen, ou=Product Testing, o=Ace Industry, c=US + changetype: delete + + Example 3: A changeLogEntry representing the modification of an entry + in the directory + + dn: changenumber=5883, cn=changelog + changenumber: 5883 + targetdn: cn=Bjorn Jensen, ou=Product Development, o=Ace Industry, c=US + changetype: modify + changes: delete: telephonenumber\ntelephonenumber: 1212\n-\n + add: telephonenumber\ntelephonenumber: +1 212 555 1212\n- + + Example 4: A changeLogEntry representing a modrdn operation performed + on an entry in the directory + + dn: changenumber=10042, cn=changelog + changenumber: 10042 + + + +Good March 11, 1998 [Page 5] + +INTERNET-DRAFT Change Record Object Class 11 March 1998 + + + targetdn: cn=Bjorn Jensen, ou=Product Development, o=Ace Industry, c=US + changetype: modrdn + newrdn: cn=Bjorn J Jensen + deleteoldrdn: FALSE + + +Location of the container containing changeLogEntry objects + + For LDAPv3 servers, the location of the container which holds + changeLogEntry objects is obtained by reading the "changeLog" attribute + of a server's root DSE. For example, if the container's root is + "cn=changelog", then the root DSE must have an attribute named + "changeLog" with the value "cn=changelog". + + The "changelog" attribute is defined as follows: + + ( 2.16.840.1.113730.3.1.35 + NAME 'changelog' + DESC 'the distinguished name of the entry which contains + the set of entries comprising this server's changelog' + EQUALITY distinguishedNameMatch + SYNTAX 'DN' + ) + + For LDAPv2 servers, the name of the changelog container must be + "cn=changelog". + + +Differences from previous versions of this document + + Differences between draft-ietf-asid-changelog-00.txt and + draft-ietf-asid-changelog-01.txt + + 1) Fixed a deficiency in the syntax of the changeNumber attribute. The + attribute now has INTEGER syntax, with appropriate matching and + ordering rules defined. + + 2) Removed unneeded substring matching rules from the changeType and + deleteOldRDN attribute definitions. + + 3) Made use of MAY, SHOULD, etc. consistent with RFC 2119. + + 4) Renamed document (now an individual submission). + + 5) Changed syntax of "changes" attribute from "Binary" to "OctetString". + + 6) Removed references to X.500 supplier and consumer-initiated + replication. + + + +Good March 11, 1998 [Page 6] + +INTERNET-DRAFT Change Record Object Class 11 March 1998 + + + 7) Updated references to current drafts/proposed standards documents. + +Security Considerations + + Servers implementing this scheme MUST NOT allow the "changes" + attribute to be generally readable. The "changes" attribute contains + all modifications made to an entry, and some changes may contain + sensitive data, e.g. passwords. + + If a server does allow read access on the "changes: attribute to a + particular bound DN, then that DN should be trusted. For example, two + cooperating servers may exchange the password for some DN which is + granted read access to the "changes" attribute of the changeLog. This + would allow one server to retrieve changes and apply them directly to + its database. + + In situations where the "changes" attribute is not readable by a client, + that client may still use the entries in the changeLog to construct a + list of entry DNs which are known to have changed since the last time + the client synchronized. The client may then read each of those entries, + subject to whatever access control is in effect on the server, + and update its local copy of each entry. + + Servers implementing this scheme should disallow write access to the + changelog container object and all entries contained within. + + + +Acknowledgements + + This material is based in part upon work supported by the National + Science Foundation under Grant No. NCR-9416667. + + + +References + + [1] Good, G., "The LDAP Data Interchange Format", INTERNET-DRAFT + draft-good-ldap-ldif-03.txt, Netscape Communications Corp., March 1997, + + + [2] Wahl, M., Howes, T., Kille, S., "Lightweight Directory Access + Protocol (v3)", RFC 2251 Critical Angle, Inc., Netscape Communications Corp., + ISODE Consortium, July, 1997, + + + [3] S. Bradner, "Key Words for use in RFCs to Indicate Requirement + Levels", Harvard University, RFC 2119, March 1997, + + + +Good March 11, 1998 [Page 7] + +INTERNET-DRAFT Change Record Object Class 11 March 1998 + + + + + +Author's Address + + Gordon Good + Netscape Communications Corp. + 501 E. Middlefield Rd. + Mailstop MV068 + Mountain View, CA 94043, USA + Phone: +1 415 937-3825 + EMail: ggood@netscape.com + + This Internet Draft expires October 1st, 1998. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Good March 11, 1998 [Page 8] +