--- /dev/null
+
+ 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
+ <draft-byrne-ldap-alias-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. 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=<dn>, <rdn>, <rdn>..." 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
+
+
--- /dev/null
+
+
+
+
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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,
+ <URL:ftp://ftp.ietf.org/internet-drafts/draft-good-ldap-ldif-03.txt>
+
+ [2] Wahl, M., Howes, T., Kille, S., "Lightweight Directory Access
+ Protocol (v3)", RFC 2251 Critical Angle, Inc., Netscape Communications Corp.,
+ ISODE Consortium, July, 1997,
+ <URL:ftp://ftp.isi.edu/in-notes/rfc2251.txt>
+
+ [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]
+\f
+INTERNET-DRAFT Change Record Object Class 11 March 1998
+
+
+ <URL:http://ds.internic.net/rfc/rfc2119.txt>
+
+
+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]
+\f
projects / openldap / commitdiff