Don't include revision number in file name (to allow in place updating)

doc/drafts/draft-byrne-ldap-alias-xx.txt

+
+          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
+
+

doc/drafts/draft-good-ldap-changelog-xx.txt

+
+
+
+
+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,
+   <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]
+
+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]
+