home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_ietf_a_c / draft-ietf-asid-changelog-01.txt < prev    next >
Text File  |  1997-07-26  |  15KB  |  451 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Change Record Object Class Definition                       Gordon Good
  8. INTERNET-DRAFT                                  Netscape Communications
  9.                                                            30 July 1997
  10.  
  11.        Definition of an Object Class to Hold LDAP Change Records
  12.                Filename: draft-ietf-asid-changelog-01.txt
  13.  
  14. Status of this Memo
  15.  
  16.    This document is an Internet-Draft.  Internet-Drafts are working
  17.    documents of the Internet Engineering Task Force (IETF), its
  18.    areas, and its working groups.  Note that other groups may also
  19.    distribute working documents as Internet-Drafts.
  20.  
  21.    Internet-Drafts are draft documents valid for a maximum of six
  22.    months and may be updated, replaced, or obsoleted by other
  23.    documents at any time.  It is inappropriate to use Internet-
  24.    Drafts as reference material or to cite them other than as
  25.    ``work in progress.''
  26.  
  27.    To learn the current status of any Internet-Draft, please check
  28.    the ``1id-abstracts.txt'' listing contained in the Internet-
  29.    Drafts Shadow Directories on ds.internic.net (US East Coast),
  30.    nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or
  31.    munnari.oz.au (Pacific Rim).
  32.  
  33.    Distribution of this memo is unlimited.  Editorial comments should be
  34.    sent to the author (ggood@netscape.com).  Technical discussion will take
  35.    place on the IETF ASID mailing list (ietf-asid@umich.edu).
  36.  
  37.    This Internet Draft expires February 1st, 1998.
  38.  
  39.  
  40.  
  41. Abstract
  42.  
  43.    In order to support more flexible replication methods, it is
  44.    desirable to specify some manner in which an LDAP client may retrieve
  45.    a set of changes which have been applied to an LDAP server's
  46.    database.  The client, which may be another LDAP server, may then
  47.    choose to update its own replicated copy of the data.  This document
  48.    specifies an object class which may be used to represent changes
  49.    applied to an LDAP server.  It also specifies a method for
  50.    discovering the location of the container object which holds these
  51.    change records, so that clients and servers have a common rendezvous
  52.    point for this information.
  53.  
  54.  
  55.  
  56.  
  57.  
  58. Good                    IETF ASID Working Group                 [Page 1]
  59.  
  60. INTERNET-DRAFT         Change Record Object Class           30 July 1997
  61.  
  62.  
  63. Background and Intended Usage
  64.  
  65.    Existing replication methods used by the X.500 directory, and by
  66.    certain standalone LDAP implementations (namely, the University of
  67.    Michigan ldap-3.3 release) are supplier-initiated in nature.  That
  68.    is, a server which holds authoritative data for some directory
  69.    subtree connects to another server and synchronizes the other
  70.    server's copy of the data.  This approach requires that a pre-
  71.    arranged replication agreement exist between the two servers
  72.    exchanging data.  This restriction is an impediment to implementation
  73.    of ad-hoc replication configurations which might be desirable in a
  74.    corporate intranet.  For example, a central computing organization
  75.    may wish to allow a set of departments to maintain replicated copies
  76.    of corporate directory information without entering into a separate
  77.    replication agreement with each.
  78.  
  79.    This document describes an objectclass which can be used to represent
  80.    changes which have occurred on a directory server.  It also suggests
  81.    a common location for a container which holds these objects.  A
  82.    client may update its local copy of directory information by reading
  83.    the entries within this container, and applying the changes to its
  84.    local database.  We term this approach "consumer-initiated
  85.    replication" to differentiate it from the existing method, which we
  86.    call "supplier-initiated replication".
  87.  
  88.    The key words "MUST", "MAY", and "SHOULD" used in this document are
  89.    to be interpreted as described in [3].
  90.  
  91. New Attribute Types Used in the changeLogEntry Object Class
  92.  
  93.    ( 2.16.840.1.113730.3.1.5
  94.        NAME 'changeNumber'
  95.        DESC 'a number which uniquely identifies a change made to a
  96.              directory entry'
  97.        SYNTAX 'INTEGER'
  98.        EQUALITY 'integerMatch'
  99.        ORDERING 'integerOrderingMatch' )
  100.  
  101.    ( 2.16.840.1.113730.3.1.6
  102.        NAME 'targetDN'
  103.        DESC 'the DN of the entry which was modified'
  104.        EQUALITY distinguishedNameMatch
  105.        SYNTAX 'DN' )
  106.  
  107.    ( 2.16.840.1.113730.3.1.7
  108.        NAME 'changeType'
  109.        DESC 'the type of change made to an entry'
  110.        EQUALITY caseIgnoreMatch
  111.  
  112.  
  113.  
  114. Good                    IETF ASID Working Group                 [Page 2]
  115.  
  116. INTERNET-DRAFT         Change Record Object Class           30 July 1997
  117.  
  118.  
  119.        SYNTAX 'DirectoryString' )
  120.  
  121.    ( 2.16.840.1.113730.3.1.8
  122.        NAME 'changes'
  123.        DESC 'a set of changes to apply to an entry'
  124.        SYNTAX 'Binary' )
  125.  
  126.    ( 2.16.840.1.113730.3.1.9
  127.        NAME 'newRDN'
  128.        DESC 'the new RDN of an entry which is the target of a
  129.              modrdn operation'
  130.        EQUALITY distinguishedNameMatch
  131.        SYNTAX 'DN' )
  132.  
  133.    ( 2.16.840.1.113730.3.1.10
  134.        NAME 'deleteOldRDN'
  135.        DESC 'a flag which indicates if the old RDN should be retained
  136.              as an attribute of the entry'
  137.        EQUALITY booleanMatch
  138.        SYNTAX 'BOOLEAN' )
  139.  
  140.    ( 2.16.840.1.113730.3.1.11
  141.        NAME 'newSuperior'
  142.        DESC 'the new parent of an entry which is the target of a
  143.              moddn operation'
  144.        EQUALITY distinguishedNameMatch
  145.        SYNTAX 'DN' )
  146.  
  147.  
  148. Schema Definition of the changeLogEntry Object Class
  149.  
  150.    ( 2.16.840.1.113730.3.2.1
  151.        NAME 'changeLogEntry'
  152.        SUP top
  153.        STRUCTURAL
  154.        MUST (
  155.            changeNumber $ targetDN $ changeType
  156.        )
  157.        MAY (
  158.            changes $ newRDN $ deleteOldRDN $ newSuperior
  159.        )
  160.    )
  161.  
  162.  
  163.  
  164.  
  165.  
  166.  
  167.  
  168.  
  169.  
  170. Good                    IETF ASID Working Group                 [Page 3]
  171.  
  172. INTERNET-DRAFT         Change Record Object Class           30 July 1997
  173.  
  174.  
  175. Discussion of changeLogEntry Attributes:
  176.  
  177.    changeNumber: the change number, as assigned by the supplier.  This
  178.    integer MUST strictly increase as new entries are added, and must
  179.    always be unique within a given server.  Syntax: caseIgnoreString
  180.  
  181.    targetdn: the distinguished name of the entry which was added,
  182.    modified or deleted.  In the case of a modrdn operation, the targetdn
  183.    gives the DN of the entry before it was modified.  Syntax: dn
  184.  
  185.    changeType: the type of change. One of: "add", "delete", "modify",
  186.    "modrdn".  Syntax: cis
  187.  
  188.    changes: the changes which were made to the directory server.  These
  189.    changes are in LDIF format, which is described in [1].
  190.    Syntax:binary
  191.  
  192.    newRDN: the new RDN (Relative Distinguished Name) of the entry, if the
  193.    changeType is "modrdn".  If the changeType attribute does not have the
  194.    value "modrdn", then there should be no values contained in the newRDN
  195.    attribute.
  196.    Syntax: dn
  197.  
  198.    deleteOldRDN: a flag which tells whether the old RDN of the entry
  199.    should be retained as a distinguished attribute of the entry, or
  200.    should be deleted.  A value of "FALSE" indicates that the RDN should be
  201.    retained as a distinguished attribute, and a value of "TRUE" indicates
  202.    that it should not be retained as a distinguished attribute of the
  203.    entry.  If any value other than "TRUE" or "FALSE" is contained in the
  204.    deleteOldRDN attribute, or if the deleteOldRDN contains multiple
  205.    values, the RDN should be retained as a distinguished attribute (that
  206.    is, "FALSE" is the default if no values are present, or if illegal
  207.    values are present).
  208.    Syntax: boolean
  209.  
  210.    newSuperior: if present, gives the name of the entry which
  211.    becomes the immediate superior of the existing entry.  This optional
  212.    attribute reflects LDAPv3 functionality, and MUST NOT be generated
  213.    by LDAPv2 servers [2].
  214.    Syntax: dn
  215.  
  216.  
  217.  
  218.  
  219.  
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Good                    IETF ASID Working Group                 [Page 4]
  227.  
  228. INTERNET-DRAFT         Change Record Object Class           30 July 1997
  229.  
  230.  
  231. Discussion of the changeLogEntry object class
  232.  
  233.    The changeLogEntry object class is used to represent changes made to a
  234.    directory server.  The set of changes made to a directory server, then,
  235.    is given by the ordered set of all entries within the changelog
  236.    container, ordered by changeNumber.
  237.  
  238.    A client may synchronize its local copy of a remote directory server's
  239.    contents by searching the remote server's changelog container for any
  240.    entries where the changenumber is greater than or equal to the last
  241.    change previously retrieved from that server.  If the entry with the
  242.    changenumber matching the last change retrieved is not returned in the
  243.    search results, then the server's changelog has been trimmed.  The
  244.    client must then fall back to reading the entire directory to bring its
  245.    copy in sync with the server's.
  246.  
  247.    Assuming that the client has successfully retrieved one or more changelog
  248.    entries from the server, it can then use the information contained in each
  249.    entry to update the corresponding entry (named by the targetDN attribute)
  250.    in its local copy of the database.
  251.  
  252.    Note that, due to access control restrictions, the client is not guaranteed
  253.    read access to the "changes" attribute.  If the client discovers that the
  254.    "changes" attribute has no values, then it must read the entry given by
  255.    the targetDN attribute, possibly only retrieving attributes it deems
  256.    "interesting".  However, in the case of delete and modrdn operations, there
  257.    is never a "changes" attribute, so it is never necessary to read the target
  258.    entry in these cases.
  259.  
  260.  
  261.  
  262. Examples of the changeLogEntry object class
  263.  
  264.    In each example below, the "changes" attribute is shown in plain text,
  265.    with embedded newlines.  This is done for clarity.  It is intended that
  266.    newlines be stored in the entry literally, not encoded in any way.
  267.    If a "changes" attribute value is stored in an LDIF file, it must
  268.    base-64 encoded.
  269.  
  270.    Example 1: A changeLogEntry representing the addition of a
  271.    new entry to the directory
  272.  
  273.    dn: changenumber=1923, cn=changelog
  274.    changenumber: 1923
  275.    targetdn: cn=Barbara Jensen, ou=Accounting, o=Ace Industry, c=US
  276.    changetype: add
  277.    changes: cn: Barbara Jensen\ncn: Babs Jensen\nsn: Jensen\n
  278.     givenname: Barbara\ntelephonenumber: +1 212 555-1212\nmail: babs@ace.com\n
  279.  
  280.  
  281.  
  282. Good                    IETF ASID Working Group                 [Page 5]
  283.  
  284. INTERNET-DRAFT         Change Record Object Class           30 July 1997
  285.  
  286.  
  287.     objectclass: top\nobjectclass: person\nobjectclass: organizationalPerson\n
  288.     objectclass: inetOrgPerson
  289.  
  290.    Example 2: A changeLogEntry representing the deletion of an entry
  291.    from the directory
  292.  
  293.    dn: changenumber=2933, cn=changelog
  294.    changenumber: 2933
  295.    targetdn: cn=Gern Jensen, ou=Product Testing, o=Ace Industry, c=US
  296.    changetype: delete
  297.  
  298.    Example 3: A changeLogEntry representing the modification of an entry
  299.    in the directory
  300.  
  301.    dn: changenumber=5883, cn=changelog
  302.    changenumber: 5883
  303.    targetdn: cn=Bjorn Jensen, ou=Product Development, o=Ace Industry, c=US
  304.    changetype: modify
  305.    changes: delete: telephonenumber\ntelephonenumber: 1212\n-\n
  306.     add: telephonenumber\ntelephonenumber: +1 212 555 1212\n-
  307.  
  308.    Example 4: A changeLogEntry representing a modrdn operation performed
  309.    on an entry in the directory
  310.  
  311.    dn: changenumber=10042, cn=changelog
  312.    changenumber: 10042
  313.    targetdn: cn=Bjorn Jensen, ou=Product Development, o=Ace Industry, c=US
  314.    changetype: modrdn
  315.    newrdn: cn=Bjorn J Jensen
  316.    deleteoldrdn: FALSE
  317.  
  318.  
  319. Location of the container containing changeLogEntry objects
  320.  
  321.    For LDAPv3 servers, the location of the container which holds
  322.    changeLogEntry objects is obtained by reading the "changeLog" attribute
  323.    of a server's root DSE.  For example, if the container's root is
  324.    "cn=changelog", then the root DSE must have an attribute named
  325.    "changeLog" with the value "cn=changelog".
  326.  
  327.    For LDAPv2 servers, the name of the changelog container must be
  328.    "cn=changelog".
  329.  
  330.  
  331. Differences from previous versions of this document
  332.  
  333.    Differences between draft-ietf-asid-changelog-00.txt and
  334.    draft-ietf-asid-changelog-01.txt
  335.  
  336.  
  337.  
  338. Good                    IETF ASID Working Group                 [Page 6]
  339.  
  340. INTERNET-DRAFT         Change Record Object Class           30 July 1997
  341.  
  342.  
  343.    1) Fixed a deficiency in the syntax of the changeNumber attribute.  The
  344.    attribute now has INTEGER syntax, with appropriate matching and
  345.    ordering rules defined.
  346.  
  347.    2) Removed unneeded substring matching rules from the changeType and
  348.    deleteOldRDN attribute definitions.
  349.  
  350.    3) Made use of MAY, SHOULD, etc. consistent with RFC 2119.
  351.  
  352. Security Considerations
  353.  
  354.    Servers implementing this scheme MUST NOT allow the "changes"
  355.    attribute to be generally readable.  The "changes" attribute contains
  356.    all modifications made to an entry, and some changes may contain
  357.    sensitive data, e.g. passwords.
  358.  
  359.    If a server does allow read access on the "changes: attribute to a
  360.    particular bound DN, then that DN should be trusted.  For example, two
  361.    cooperating servers may exchange the password for some DN which is
  362.    granted read access to the "changes" attribute of the changeLog.  This
  363.    would allow one server to retrieve changes and apply them directly to
  364.    its database.
  365.  
  366.    In situations where the "changes" attribute is not readable by a client,
  367.    that client may still use the entries in the changeLog to construct a
  368.    list of entry DNs which are known to have changed since the last time
  369.    the client synchronized.  The client may then read each of those entries,
  370.    subject to whatever access control is in effect on the server,
  371.    and update its local copy of each entry.
  372.  
  373.    Servers implementing this scheme should disallow write access to the
  374.    changelog container object and all entries contained within.
  375.  
  376.  
  377.  
  378. Acknowledgements
  379.  
  380.    This material is based in part upon work supported by the National
  381.    Science Foundation under Grant No. NCR-9416667.
  382.  
  383.  
  384.  
  385. References
  386.  
  387.    [1] Good, G., "The LDAP Data Interchange Format", INTERNET-DRAFT
  388.    draft-ietf-asid-ldif-02.txt, Netscape Communications Corp., July 1997,
  389.    <URL:ftp://ftp.ietf.org/internet-drafts/draft-ietf-asid-ldif-02.txt>
  390.  
  391.  
  392.  
  393.  
  394. Good                    IETF ASID Working Group                 [Page 7]
  395.  
  396. INTERNET-DRAFT         Change Record Object Class           30 July 1997
  397.  
  398.  
  399.    [2] Wahl, M., Howes, T., Kille, S., "Lightweight Directory Access
  400.    Protocol (v3)", INTERNET-DRAFT draft-ietf-asid-ldapv3-protocol-06.txt,
  401.    Critical Angle, Inc., Netscape Communications Corp., ISODE Consortium,
  402.    July, 1997,
  403.    <URL:ftp://ftp.ietf.org/internet-drafts/draft-ietf-asid-ldapv3-protocol-06.txt>
  404.  
  405.    [3] S. Bradner, "Key Words for use in RFCs to Indicate Requirement
  406.    Levels", Harvard University, RFC 2119, March 1997,
  407.    <URL:http://ds.internic.net/rfc/rfc2119.txt>
  408.  
  409.  
  410. Author's Address
  411.  
  412.    Gordon Good
  413.    Netscape Communications Corp.
  414.    501 E. Middlefield Rd.
  415.    Mailstop MV068
  416.    Mountain View, CA 94043, USA
  417.    Phone:  +1 415 937-3825
  418.    EMail:  ggood@netscape.com
  419.  
  420.               This Internet Draft expires February 1st, 1998.
  421.  
  422.  
  423.  
  424.  
  425.  
  426.  
  427.  
  428.  
  429.  
  430.  
  431.  
  432.  
  433.  
  434.  
  435.  
  436.  
  437.  
  438.  
  439.  
  440.  
  441.  
  442.  
  443.  
  444.  
  445.  
  446.  
  447.  
  448.  
  449.  
  450. Good                    IETF ASID Working Group                 [Page 8]
  451.