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-00.txt < prev    next >
Text File  |  1996-11-26  |  14KB  |  451 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Change Record Object Class Definition                       Gordon Good
  8. INTERNET-DRAFT                                  Netscape Communications
  9.                                                        25 November 1996
  10.  
  11.        Definition of an Object Class to Hold LDAP Change Records
  12.                Filename: draft-ietf-asid-changelog-00.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 May 1st, 1997.
  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       25 November 1996
  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 authoratative 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.    exhanging 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.  
  89.  
  90. New Attribute Types Used in the changeLogEntry Object Class
  91.  
  92.    ( 2.16.840.1.113730.3.1.5
  93.        NAME 'changeNumber'
  94.        DESC 'a number which uniquely identifies a change made to a
  95.              directory entry'
  96.        EQUALITY caseIgnoreMatch
  97.        SUBSTRINGS caseIgnoreSubstringsMatch
  98.        SYNTAX 'DirectoryString' )
  99.  
  100.    ( 2.16.840.1.113730.3.1.6
  101.        NAME 'targetDN'
  102.        DESC 'the DN of the entry which was modified'
  103.        EQUALITY distinguishedNameMatch
  104.        SYNTAX 'DN' )
  105.  
  106.    ( 2.16.840.1.113730.3.1.7
  107.        NAME 'changeType'
  108.        DESC 'the type of change made to an entry'
  109.        EQUALITY caseIgnoreMatch
  110.        SUBSTRINGS caseIgnoreSubstringsMatch
  111.  
  112.  
  113.  
  114. Good                    IETF ASID Working Group                 [Page 2]
  115.  
  116. INTERNET-DRAFT         Change Record Object Class       25 November 1996
  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.        SUBSTRINGS caseIgnoreSubstringsMatch
  139.        SYNTAX 'BOOLEAN' )
  140.  
  141.    ( 2.16.840.1.113730.3.1.11
  142.        NAME 'newSuperior'
  143.        DESC 'the new parent of an entry which is the target of a
  144.              moddn operation'
  145.        EQUALITY distinguishedNameMatch
  146.        SYNTAX 'DN' )
  147.  
  148.  
  149. Schema Definition of the changeLogEntry Object Class
  150.  
  151.    ( 2.16.840.1.113730.3.2.1
  152.        NAME 'changeLogEntry'
  153.        SUP top
  154.        STRUCTURAL
  155.        MUST (
  156.            changeNumber $ targetDN $ changeType $ changes
  157.        )
  158.        MAY (
  159.            newRDN $ deleteOldRDN $ newSuperior
  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       25 November 1996
  173.  
  174.  
  175. Discussion of changeLogEntry Attributes:
  176.  
  177.    changeNumber: the change number, as assigned by the supplier. The
  178.    changeNumber attribute must be the string representation of an
  179.    integer.  This integer must strictly increase as new entries are
  180.    added, and must always be unique within a given server.  Syntax:
  181.    caseIgnoreString
  182.  
  183.    targetdn: the distinguished name of the entry which was added,
  184.    modified or deleted.  In the case of a modrdn operation, the targetdn
  185.    gives the DN of the entry before it was modified.  Syntax: dn
  186.  
  187.    changeType: the type of change. One of: "add", "delete", "modify",
  188.    "modrdn".  Syntax: cis
  189.  
  190.    changes: the changes which were made to the directory server.  These
  191.    changes are in LDIF format, which is described in [1].
  192.    Syntax:binary
  193.  
  194.    newRDN: the new RDN (Relative Distinguished Name) of the entry, if the
  195.    changeType is "modrdn".  If the changeType attribute does not have the
  196.    value "modrdn", then there should be no values contained in the newRDN
  197.    attribute.
  198.    Syntax: dn
  199.  
  200.    deleteOldRDN: a flag which tells whether the old RDN of the entry
  201.    should be retained as a distinguished attribute of the entry, or
  202.    should be deleted.  A value of "FALSE" indicates that the RDN should be
  203.    retained as a distinguished attribute, and a value of "TRUE" indicates
  204.    that it should not be retained as a distinguished attribute of the
  205.    entry.  If any value other than "TRUE" or "FALSE" is contained in the
  206.    deleteOldRDN attribute, or if the deleteOldRDN contains multiple
  207.    values, the RDN should be retained as a distinguished attribute (that
  208.    is, "FALSE" is the default if no values are present, or if illegal
  209.    values are present).
  210.    Syntax: boolean
  211.  
  212.    newSuperior: if present, gives the name of the entry which
  213.    becomes the immediate superior of the existing entry.  This optional
  214.    attribute reflects LDAPv3 functionality, and should not be generated
  215.    by LDAPv2 servers [2].
  216.    Syntax: dn
  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       25 November 1996
  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, with
  265.    embedded newlines.  This is done for clarity.  These values must be
  266.    base-64 encoded in actual practice, because of the embedded newlines.
  267.  
  268.    Example 1: A changeLogEntry representing the addition of a
  269.    new entry to the directory
  270.  
  271.    dn: changenumber=1923, cn=changelog
  272.    changenumber: 1923
  273.    targetdn: cn=Barbara Jensen, ou=Accounting, o=Ace Industry, c=US
  274.    changetype: add
  275.    changes: cn: Barbara Jensen\ncn: Babs Jensen\nsn: Jensen\n
  276.     givenname: Barbara\ntelephonenumber: +1 212 555-1212\nmail: babs@ace.com\n
  277.     objectclass: top\nobjectclass: person\nobjectclass: organizationalPerson\n
  278.     objectclass: inetOrgPerson
  279.  
  280.  
  281.  
  282. Good                    IETF ASID Working Group                 [Page 5]
  283.  
  284. INTERNET-DRAFT         Change Record Object Class       25 November 1996
  285.  
  286.  
  287.    Example 2: A changeLogEntry representing the deletion of an entry
  288.    from the directory
  289.  
  290.    dn: changenumber=2933, cn=changelog
  291.    changenumber: 2933
  292.    targetdn: cn=Gern Jensen, ou=Product Testing, o=Ace Industry, c=US
  293.    changetype: delete
  294.  
  295.    Example 3: A changeLogEntry representing the modification of an entry
  296.    in the directory
  297.  
  298.    dn: changenumber=5883, cn=changelog
  299.    changenumber: 5883
  300.    targetdn: cn=Bjorn Jensen, ou=Product Development, o=Ace Industry, c=US
  301.    changetype: modify
  302.    changes: delete: telephonenumber\ntelephonenumber: 1212\n-\n
  303.     add: telephonenumber\ntelephonenumber: +1 212 555 1212\n-
  304.  
  305.    Example 4: A changeLogEntry representing a modrdn operation performed
  306.    on an entry in the directory
  307.  
  308.    dn: changenumber=10042, cn=changelog
  309.    changenumber: 10042
  310.    targetdn: cn=Bjorn Jensen, ou=Product Development, o=Ace Industry, c=US
  311.    changetype: modrdn
  312.    newrdn: cn=Bjorn J Jensen
  313.    deleteoldrdn: FALSE
  314.  
  315.  
  316. Location of the container containing changeLogEntry objects
  317.  
  318.    For LDAPv3 servers, the location of the container which holds
  319.    changeLogEntry objects is obtained by reading the "changeLog" attribute
  320.    of a server's root DSE.  For example, if the container's root is
  321.    "cn=changelog", then the root DSE must have an attribute named
  322.    "changeLog" with the value "cn=changelog".
  323.  
  324.    For LDAPv2 servers, the name of the changelog container must be
  325.    "cn=changelog".
  326.  
  327.  
  328. Security Considerations
  329.  
  330.    Servers implementing this scheme should not allow the "changes"
  331.    attribute to be generally readable.  The "changes" attribute contains
  332.    all modifications made to an entry, and some changes may contain
  333.    sensitive data, e.g. passwords.
  334.  
  335.  
  336.  
  337.  
  338. Good                    IETF ASID Working Group                 [Page 6]
  339.  
  340. INTERNET-DRAFT         Change Record Object Class       25 November 1996
  341.  
  342.  
  343.    If a server does allow read access on the "changes: attribute to a
  344.    particular bound DN, then that DN should be trusted.  For example, two
  345.    cooperating servers may exchange the password for some DN which is
  346.    granted read access to the "changes" attribute of the changeLog.  This
  347.    would allow one server to retrieve changes and apply them directly to
  348.    its database.
  349.  
  350.    In situations where the "changes" attribute is not readable by a client,
  351.    that client may still use the entries in the changeLog to construct a
  352.    list of entry DNs which are known to have changed since the last time
  353.    the client synchronized.  The client may then read each of those entries,
  354.    subject to whatever access control is in effect on the server,
  355.    and update its local copy of each entry.
  356.  
  357.    Servers implementing this scheme should disallow write access to the
  358.    changelog container object and all entries contained within.
  359.  
  360.  
  361.  
  362. Acknowledgements
  363.  
  364.    This material is based in part upon work supported by the National
  365.    Science Foundation under Grant No. NCR-9416667.
  366.  
  367.  
  368.  
  369. References
  370.  
  371.    [1] Good, G., "The LDAP Data Interchange Format", INTERNET-DRAFT
  372.    draft-ietf-asid-ldif-00.txt, Netscape Communications Corp.,
  373.    <URL:ftp://ftp.ietf.org/internet-drafts/draft-ietf-asid-ldif-00.txt>
  374.  
  375.    [2] Wahl, M., Howes, T., Kille, S., "Lightweight Directory Access
  376.    Protocol (v3)", INTERNET-DRAFT draft-ietf-asid-ldapv3-protocol-03.txt,
  377.    Critical Angle, Inc., Netscape Communications Corp., ISODE Consortium,
  378.    October, 1996,
  379.    <URL:ftp://ftp.ietf.org/internet-drafts/draft-ietf-asid-ldapv3-protocol-03.txt>
  380.  
  381.  
  382. Author's Address
  383.  
  384.    Gordon Good
  385.    Netscape Communications Corp.
  386.    501 E. Middlefield Rd.
  387.    Mountain View, CA 94043, USA
  388.    Phone:  +1 415 937-3825
  389.    EMail:  ggood@netscape.com
  390.  
  391.  
  392.  
  393.  
  394. Good                    IETF ASID Working Group                 [Page 7]
  395.  
  396. INTERNET-DRAFT         Change Record Object Class       25 November 1996
  397.  
  398.  
  399.                 This Internet Draft expires May 1st, 1997.
  400.  
  401.  
  402.  
  403.  
  404.  
  405.  
  406.  
  407.  
  408.  
  409.  
  410.  
  411.  
  412.  
  413.  
  414.  
  415.  
  416.  
  417.  
  418.  
  419.  
  420.  
  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.