[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-megginson-ldup-lcup) 00 01 02 03 04 05 06 RFC 3928

Internet Draft                                     R. Megginson, Editor
Document: <draft-ietf-ldup-lcup-03.txt>                        M. Smith
Category: Proposed Standard                                    Netscape
                                                   Communications Corp.
                                                           O. Natkovich
                                                                  Yahoo
                                                              J. Parham
                                                  Microsoft Corporation
                                                              June 2002


                        LDAP Client Update Protocol


Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026 [1].

   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."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-
   Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

1.      Abstract

   This document defines the LDAP Client Update Protocol (LCUP). The
   protocol is intended to allow an LDAP client to synchronize with the
   content of a directory information tree (DIT) stored by an LDAP
   server and to be notified about the changes to that content.


2.      Conventions used in this document

   In the protocol flow definition, the notation C->S and S->C
   specifies the direction of the data flow from the client to the
   server and from the server to the client respectively.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in
   this document are to be interpreted as described in RFC-2119
   [KEYWORDS].


3.      Overview



   The LCUP protocol is intended to allow LDAP clients to synchronize
   with the content stored by LDAP servers.

   The problem areas addressed by the protocol include:

    - mobile clients that maintain a local read-only copy of the
      directory data. While off-line, the client uses the local copy of
      the data. When the client connects to the network, it
      synchronizes with the current directory content and can be
      optionally notified about the changes that occur while it is on-
      line. For example, a mail client can maintain a local copy of the
      corporate address book that it synchronizes with the master copy
      whenever the client gets connected to the corporate network.

    - applications intending to synchronize heterogeneous data stores.
      A meta directory application, for instance, would periodically
      retrieve a list of modified entries from the directory, construct
      the changes and apply them to a foreign data store.

    - clients that need to take certain actions when a directory entry
      is modified. For instance, an electronic mail repository may want
      to perform a "create mailbox" task when a new person entry is
      added to an LDAP directory and a "delete mailbox" task when a
      person entry is removed.

   The problem areas not being considered:

    - directory server to directory server synchronization. The IETF is
      developing a LDAP replication protocol, called [LDUP], which is
      specifically designed to address this problem area.

   There are currently several protocols in use for LDAP client server
   synchronization. While each protocol addresses the needs of a
   particular group of clients (e.g., on-line clients or off-line
   clients) none satisfies the requirements of all clients in the
   target group.  For instance, a mobile client that was off-line and
   wants to become up to date with the server and stay up to date while
   connected can't be easily supported by any of the existing
   protocols.

   Several features of the protocol distinguish it from LDUP
   replication. LCUP is designed such that the server does not need to
   maintain state information on behalf of the client. The clients are
   responsible for storing the information about how up to date they
   are with respect to the server's content. LCUP design avoids the
   need for LCUP-specific update agreements to be made between client
   and server prior to LCUP use. The client decides when and from where
   to retrieve the changes. LCUP design requires clients to initiate
   the update session and "pull" the changes from server.

   LCUP operations are subject to administrative and access
   control policies enforced by the server.



Megginson, et. al. Proposed Standard - Expires: December 2002        2


   A part of the DIT which is enabled for LCUP is referred to as an
   LCUP Context.  A server may support one or more LCUP Contexts.

4.      Protocol Specification

   This section describes the protocol elements and the protocol flow.

4.1     Universally Unique Identifiers

   Distinguished names can change, so are therefore unreliable
   as identifiers. The server SHOULD assign a Universally Unique
   Identifier (or UUID for short) to each entry as it is created. This
   identifier will be stored as an operational attribute of the entry,
   named `entryUUID'. The entryUUID attribute is single valued. A
   consistent algorithm for generating such universally unique
   identifiers may be standardized at some point in the future.
   The definition of the entryUUID attribute type, written using the
   BNF form of AttributeDescription described in RFC 2252 [RFC2252] is:

       ( OID-To-Be-Specified
         NAME `entryUUID'
         DESC `universally unique entry identifier'
         EQUALITY caseIgnoreMatch
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
         SINGLE-VALUE
         NO-USER-MODIFICATION
         USAGE directoryOperation )

4.2     LCUP Cookie Value

   The LCUP protocol uses a cookie to hold the state of the client's
   data with respect to the server's data.  The LCUP Cookie is a value
   of the following ASN.1 type:

     LCUPCookie ::= SEQUENCE {
       scheme          LDAPOID,
       value           OCTET STRING OPTIONAL
     }

     scheme - this is the OID which identifies the format of the value.
     The scheme OID, like all object identifiers, MUST be unique for a
     given cookie scheme.  The cookie value may be opaque or it may be
     exposed to LCUP clients.   For cookie schemes that expose their
     value, the preferred form of documentation is an RFC.  It is
     expected that there will be one or more standards track cookie
     schemes where the value format is exposed and described in detail.

     value - this is the actual data describing the state of the
     client's data.  This value may be opaque, or its value may have
     some well-known format, depending on the scheme.  The cookie value
     MUST be included except when a client has no stored state; i.e.,
     when the client is requesting a full synchronization.  When the
     server sends back a cookie, the cookie value MUST be present.


Megginson, et. al. Proposed Standard - Expires: December 2002        3


   Further uses of the LCUP Cookie value are described below.

4.3     Additional LDAP Result Codes defined by LCUP

   The LDAP result code names and numbers defined in the following
   table are to be replaced with IANA assigned result code names and
   numbers per draft-ietf-ldapbis-iana-xx.txt.

     lcupResourcesExhausted (TBD) the server is running out of
                                   resources
     lcupSecurityViolation  (TBD) the client is suspected of malicious
                                   actions
     lcupInvalidCookie      (TBD) invalid cookie was supplied by the
                                   client - both/either the scheme
                                   and/or the value part was invalid
     lcupUnsupportedScheme  (TBD) The scheme part of the cookie is a
                                  valid OID but is not supported by
                                  this server
     lcupClientDisconnect   (TBD) client requested search termination
                                   using the LDAP Cancel extended
                                   operation request [CANCEL]
     lcupReloadRequired     (TBD) indicates that client data needs to
                                   be reinitialized. This reason is
                                   returned if the server does not
                                   contain sufficient information to
                                   synchronize the client or if the
                                   server's data was reloaded since the
                                   last synchronization session

   The uses of these codes are described below.

4.4     Client Update Control Value

   A client initiates a synchronization session with a server by
   attaching a clientUpdate control to an LDAP searchRequest message.
   The client SHOULD specify entryUUID in the attributes list in the
   searchRequest message.  The search specification determines the part
   of the directory information tree (DIT) the client wishes to
   synchronize with, the set of attributes it is interested in and the
   amount of data the client is willing to receive. The clientUpdate
   control contains the client's synchronization specification. The
   controlType field for the clientUpdate control is
   ClientUpdateControlOID (to be assigned).  The controlValue is an
   OCTET STRING, whose contents are the bytes of the BER encoding of
   the following:










Megginson, et. al. Proposed Standard - Expires: December 2002        4


    ClientUpdateControlValue ::= SEQUENCE {
      updateType         ENUMERATED {
                               synchronizeOnly         (0),
                               synchronizeAndPersist   (1),
                               persistOnly             (2) },
      sendCookieInterval INTEGER    OPTIONAL,
      cookie             LCUPCookie OPTIONAL
    }

     updateType - specifies the type of update requested by the client

      synchronizeOnly - the server sends all the data needed to
        synchronize the client with the server, then closes the
        connection

      synchronizeAndPersist - the server sends all the data needed to
        synchronize the client with the server, then leaves open the
        connection, sending to the client any new added, modified, or
        deleted entries that satisfy the search criteria.

      persistOnly - the server does not synchronize the data with the
        client but leaves open the connection and sends over any new
        added, modified, or deleted entries that satisfy the search
        criteria.

     sendCookieInterval รป (optional) the server SHOULD send the cookie
      back in the entryUpdate control value for every
      sendCookieInterval number of SearchResultEntry PDUs returned to
      the client.  For example, if the value is 5, the server SHOULD
      send the cookie back in the entryUpdate control value for every 5
      search results returned to the client.  If this value is absent,
      zero or less than zero, the server chooses the interval.

     cookie - a value that represents the current state of the client's
      data.  If a cookie is provided, the server MUST use the enclosed
      scheme throughout the duration of the LCUP session or until an
      LCUP context boundary is crossed, since a new cookie may be
      required in that case.  If the value or scheme part of the cookie
      is invalid, the server MUST return immediately with a
      SearchResultDone message with the resultCode set to the value of
      lcupInvalidCookie.  If the scheme part of the cookie is a valid
      OID, but is not supported, the server MUST return immediately
      with a SearchResultDone message with the resultCode set to the
      value of lcupUnsupportedScheme.

     If the cookie is omitted, the server MAY use any scheme it
     supports.

4.5     Entry Update Control Value

   In response to the client's synchronization request, the server
   returns one or more SearchResultEntry PDU that fits the client's
   specification. Each SearchResultEntry PDU also contains an
   entryUpdateControl that describes the LCUP state of the returned

Megginson, et. al. Proposed Standard - Expires: December 2002        5


   entry.  To represent a deleted entry, the server attaches an
   entryUpdate control to the corresponding SearchResultEntry. The
   SearchResultEntry corresponding to a deleted entry MUST contain a
   valid DN and SHOULD contain a valid UUID but, to reduce the amount
   of data sent to the client, it SHOULD not contain any other
   attributes.

   Furthermore, the server may elect to periodically return to the
   client the cookie that represents the state of the client's data.
   This information is useful in case the client crashes or gets
   disconnected. The client MAY specify how often to receive the cookie
   by the use of the sendCookieInterval in the clientUpdate control
   value (see above).  If the client does not specify a value, the
   server will determine the interval.

   The controlType field for the entryUpdate control is
   EntryUpdateControlOID (to be assigned).  The controlValue is an
   OCTET STRING, whose contents are the bytes of the BER encoding of
   the following:

    EntryUpdateControlValue ::= SEQUENCE {
      stateUpdate   BOOLEAN,
      entryDeleted  BOOLEAN,
      cookie        LCUPCookie OPTIONAL

    }

    stateUpdate - if set to TRUE, indicates that the entry to which the
      control is attached contains no changes and it is sent only to
      communicate to the client the new cookie. In this case, the
      entryDeleted field MUST be ignored and the cookie field MUST
      contain the updated cookie. This feature allows updating the
      client's cookie when there are no changes that effect the
      client's data store. Note that the control MUST be attached to a
      valid SearchResultEntry, which should contain a valid LDAPDN in
      the objectName field, and MAY contain an entryUUID attribute, but
      SHOULD NOT contain any other attributes.  The server MAY send the
      entry named by the baseObject from the client's search request.

    entryDeleted - if set to TRUE, indicates that the entry to which
      the control is attached was deleted.  The server MAY also set
      this to TRUE if the entry has left the client's search result
      set.  As far as the client is concerned, a deleted entry is no
      different than an entry that has left the result set.

    cookie - the LCUP cookie value that represents the current state of
      the client's data.

4.6     Client Update Done Control Value

   When the server has finished processing the client's request, it
   attaches a clientUpdateDone control to the SearchResultDone message
   and sends it to the client. However, if the SearchResultDone message
   contains a resultCode that is not success or lcupClientDisconnect,

Megginson, et. al. Proposed Standard - Expires: December 2002        6


   the clientUpdateDone control MAY be omitted.  The controlType field
   for the clientUpdateDone control is ClientUpdateDoneControlOID (to
   be assigned).  The controlValue is an OCTET STRING, whose contents
   are the bytes of the BER encoding of the following:

    ClientUpdateDoneControlValue ::= SEQUENCE {
      cookie  LCUPCookie OPTIONAL
    }

   cookie - the LCUP cookie value that represents the current state of
    the client's data.  Although this value is OPTIONAL, it MUST be set
    in the ClientUpdateDoneControlValue if the SearchResultDone
    resultCode is success or lcupClientDisconnect.  This provides a
    good "checksum" of what the server thinks the state of the client
    is.  If some error occurred, either an LDAP search error (e.g.
    insufficientAccessRights) or an LCUP error (e.g.
    lcupUnsupportedScheme), the cookie MAY be omitted.

   If server resources become tight, the server can terminate one or
   more search operations by sending a SearchResultDone message to the
   client(s) with a resultCode of lcupResourcesExhausted. Unless the
   client sets the updateType field to persistOnly, the server attaches
   a clientUpdateDone control that contains the cookie that corresponds
   to the current state of the client's data. A server set policy is
   used to decide which searches to terminate. This can also be used as
   a security mechanism to disconnect clients that are suspected of
   malicious actions, but if the server can infer that the client is
   malicious, the server should return lcupSecurityViolation instead.

4.7     Client Initiated Termination

   If the client needs to terminate the synchronization process and it
   wishes to obtain the cookie that represents the current state of its
   data, it issues an LDAP Cancel operation [CANCEL].  The server
   responds immediately with a LDAP Cancel response [CANCEL].  The
   server MAY send any pending SearchResultEntry PDUs if the server
   cannot easily abort or remove those search results from its outgoing
   queue.  The server SHOULD send as few of these remaining
   SearchResultEntry PDUs as possible.  Finally, the server sends the
   message SearchResultDone with the clientUpdateDone control attached.

   If the client is not interested in the state information, it can
   simply abandon the search operation or disconnect from the server.

4.8     Protocol Flow

   The client server interaction can proceed in three different ways
   depending on the client's requirements.  Protocol flows beginning
   with an asterisk (*) are optional or conditional.

   If the client's intent is not to synchronize data but to trigger
   actions in response to directory modifications, the protocol
   proceeds as follows:


Megginson, et. al. Proposed Standard - Expires: December 2002        7


    C->S   Sends a search operation with a clientUpdate control attached.
           The search specification determines the part of the DIT the
           client wishes to synchronize with and the set of attributes it
           is interested in. The updateType field of the control value
           should be set to persistOnly.
    *S->C  If there is an error (invalid search scope, invalid cookie)
           the server returns the appropriate error codes and terminates
           the request (SearchResultDone message with optional
           clientUpdateDone control)
    S->C   Sends change notification to the client for each change to the
           data within the client's search specification.  Each
           SearchResultEntry may have an entryUpdate control attached.
    *S->C  If the server starts to run out of resources or the client is
           suspected of malicious actions, the server SHOULD terminate
           the search operation by sending to the client a
           SearchResultDone message with optional clientUpdateDone
           control attached. The resultCode in the SearchResultDone
           mesasge SHOULD be set to lcupResourcesExhausted or
           lcupSecurityViolation depending on the reason for termination.
    *C->S  If the client receives lcupResourcesExhausted error from the
           server, it MUST wait for a while before attempting another
           synchronization session with the server. It is RECOMMENDED
           that clients use an exponential backoff strategy.
    C->S   The client terminates the search.  The client can do this by
           abandoning the search operation, disconnecting from the
           server, or by sending an LDAP Cancel operation.
    *S->C  If the server receives the LDAP Cancel op, it will immediately
           send back the LDAP Cancel response
    *S->C  If the server sent the LDAP Cancel response, the server MAY
           send any pending SearchResultEntry PDUs in its outgoing queue
    *S->C  If the server sent the LDAP Cancel response, after the server
           sends the response and any pending SearchResultEntry PDUs, the
           server sends the SearchResultDone message with the
           clientUpdateDone control attached.  The resultCode in the
           SearchResultDone message will be either lcupClientDisconnect
           or some LDAP error code (not success).
    S->C   Stops sending changes to the client and closes the connection.

   If the client's intent is to synchronize with the server and then
   disconnect, the protocol proceeds as follows:

    C->S  Sends a search operation with the clientUpdate control
          attached. The search specification determines the part of the
          DIT the client wishes to synchronize with, the set of
          attributes it is interested in and the amount of data the
          client is willing to receive. If this is the initial
          synchronization session, the client either does not provide a
          cookie or provides a cookie with no value; otherwise, the
          cookie field of the control is set to the cookie received from
          the server at the end of the last synchronization session.  If
          the scheme field of the cookie was provided, the server MUST
          use that scheme throughout the duration of the LCUP session or
          until an LCUP boundary is crossed, since the server will
          usually require a different cookie in that case anyway. (Note

Megginson, et. al. Proposed Standard - Expires: December 2002        8


          that the client can synchronize with different servers during
          different synchronization sessions.) The updateType field of
          the control value is set to synchronizeOnly.
    *S->C If there is an error (invalid search scope, invalid cookie)
          the server returns the appropriate error codes and terminates
          the request (SearchResultDone message with optional
          clientUpdateDone control)
    *S->C If no cookie is specified in the clientUpdate control, or if
          the value field of the cookie is empty, the server sends all
          data that matches the client's search specification followed
          by the SearchResultDone message with a clientUpdateDone
          control attached. The control contains the cookie that
          corresponds to the current state of the client's data.  If
          synchronization was successful, the resultCode in the
          SearchResultDone message should be success.
    *S->C If an invalid cookie is specified, the server sends the
          SearchResultDone message with the resultCode set to
          lcupInvalidCookie.
    *S->C If a valid cookie is specified and the data that matches the
          search specification has been reloaded or the server does not
          contain enough state information to synchronize the client,
          the server sends a SearchResultDone message with the
          resultCode set to lcupReloadRequired.
    *S->C If the cookie is valid and the client is up to date, the
          server sends a success response to the client.
    S->C  If the cookie is valid and there is data to be sent, the
          server sends the modified entries to the client. Each
          SearchResultEntry contains the attributes requested by the
          client in the search specification regardless of whether they
          were modified. An entryUpdate control with the entryDeleted
          field set to TRUE MUST be attached to every deleted entry. The
          server may also periodically attach an entryUpdate control to
          the entries sent to the client to indicate the current state
          of the client's data. In that case, the cookie field of the
          control represents the state of the client's data including
          the entry to which the control is attached. Once all the
          changes are sent successfully, the server sends a
          SearchResultDone with the clientUpdateDone control attached.
          The control contains the cookie that represents the current
          state of the client's data. The resultCode in the
          SearchResultDone message is set to success.  If the resultCode
          is not success, the server may OPTIONALLY attach the
          clientUpdateDone control to the SearchResultDone message.
          The client stores the cookie received from the server until
          the next synchronization session.
    *C->S If the resultCode in the SearchResultDone message is set
          lcupReloadRequired, the client clears its data store and
          repeats the synchronization process by sending the search
          operation with clientUpdate control that contains no cookie,
          or that contains a cookie with no value field.

   If the client's intent is to be synchronized with the server and
   stay notified about data modifications, the protocol proceeds as
   follows:

Megginson, et. al. Proposed Standard - Expires: December 2002        9



    C->S  The client behaves exactly as in the previous case except it
          sets the updateType field in the control value to
          synchronizeAndPersist.
    S->C  The server behaves exactly as in the previous case except the
          connection is kept open after the initial set of changes is
          sent to the client. A SearchResultDone message is not sent to
          the client; instead, the server keeps sending changes to the
          client.
    *S->C If the server starts to run out of resources or the client is
          suspected of malicious actions, the server SHOULD terminate
          the search operation by sending to the client a
          SearchResultDone message with the resultCode set to
          lcupResourcesExhausted or lcupSecurityViolation depending on
          the reason for termination.
    *C->S If the client receives lcupResourcesExhausted error from the
          server, it MUST wait for a while before attempting another
          synchronization session with the server. We recommend
          exponential backoff strategy.
    C->S  Sends an LDAP Cancel operation to the server to terminate the
          synchronization session.
    S->C  Responds with an LDAP Cancel response, followed optionally by
          SearchResultEntry PDUs, followed by a SearchResultDone with
          the clientUpdateDone control optionally attached. If the
          control is present, it contains the cookie that represents the
          current state of the client's data.  The value of the
          resultCode in the SearchResultDone message will be either
          lcupClientDisconnect or some other LDAPResult resultCode (not
          success).  The control may not be present if some error
          occurred.

4.9     Size and Time Limits

   The search request size or the time limits can only be imposed for
   non-persistent operations, those that set the updateType field of
   the ClientUpdateControlValue to synchronizeOnly (for the entire
   operation) or synchronizeAndPersist (for the initial synchronization
   phase only). All other operations MUST set both limits to 0. The
   server SHOULD ignore the limits set for persistent operations.

4.10    Changes vs. Operations

   A server that supports UUIDs SHOULD communicate a modifyDN
   operation by sending the client the current form of the entry (with
   its new DN) along with an entryUUID attribute. A server that does
   not support UUIDs SHOULD communicate a modifyDN operation by sending
   the client a deletion for the previous DN followed by an entry for
   the new DN. Note that for servers that do not support UUIDs, no
   guarantees are made about the correctness of the client state in the
   presence of modifyDN operations.

   Communicating modifyDN operations by sending a delete of the old DN
   followed by an entry with the new DN makes it impossible for an LCUP
   client to distinguish between a modifyDN operation, which is one

Megginson, et. al. Proposed Standard - Expires: December 2002       10


   atomic operation, and an delete operation followed by an add of a
   new entry.  The loss of information about atomicity may cause
   problems for some LCUP clients. For example, when an entry is
   renamed, a client that manages resources such as a person's mailbox
   might delete the mailbox and everything in it instead of merely
   changing the name associated with the mailbox.

   Also note that regardless of how a modifyDN operation is
   communicated to the client, if the client state shows that the
   object that underwent the modifyDN operation was the root of a
   subtree, the client MUST infer that the DNs of all objects in the
   subtree have changed such that they reflect the new DN of the
   subtree root.

4.11    Operations on the Same Connection

   It is permissible for the client to issue other LDAP operations on
   the connection used by the protocol. Since each LDAP
   request/response carries a message id there will be no ambiguity
   about which PDU belongs to which operation. By sharing the
   connection among multiple operations, the server will be able to
   conserve its resources.

4.12    Interactions with Other LDAP Search and Response Controls

   LCUP defines neither restrictions nor guarantees about the ability
   to use the LDAP client update control defined in this document in
   conjunction with other LDAP controls, except for the following:  A
   server MAY ignore non-critical controls supplied with the LCUP
   control.  A server MAY ignore the LCUP control if it is non-critical
   and it is supplied with other critical controls.  If a server
   receives a critical LCUP control with another critical control, and
   the server does not support both controls at the same time, the
   server SHOULD return unavailableCriticalExtension.

5.      Additional Features

   There are several features present in other protocols or considered
   useful by clients that are currently not included in the protocol
   primarily because they are difficult to implement on the server.
   These features are briefly discussed in this section. This section
   is intended to open a discussion on the merits of including and
   approaches to implementing these features.

5.1     Triggered Search Change Type

   This feature is present in the Triggered Search specification. A
   flag is attached to each entry returned to the client indicating the
   reason why this entry is returned. The possible reasons from the
   draft are
      "- notChange: the entry existed in the directory and matched the
      search at the time the operation is being performed,
      - enteredSet: the entry entered the result,
      - leftSet: the entry left the result,

Megginson, et. al. Proposed Standard - Expires: December 2002       11


      - modified: the entry was part of the result set, was modified or
      renamed, and still is in the result set."

   The leftSet feature is particularly useful because it indicates to
   the client that an entry is no longer within the client's search
   specification and the client can remove the associated data from its
   data store. Ironically, this feature is the hardest to implement on
   the server because the server does not keep track of the client's
   state and has no easy way of telling which entries moved out of
   scope between synchronization sessions with the client.

   A compromise could be reached by only providing this feature for the
   operations that occur while the client is connected to the server.
   This is easier to accomplish because the decision about the change
   type can be made based only on the change without need for any
   historical information. This, however, would add complexity to the
   protocol.

5.2     Persistent Search Change Type

   This feature is present in the Persistent Search specification.
   Persistent search has the notion of changeTypes. The client
   specifies which type of updates will cause entries to be returned,
   and optionally whether the server tags each returned entry with the
   type of change that caused that entry to be returned.

   For LCUP, the intention is full synchronization, not partial.  Each
   entry returned by an LCUP search will have some change associated
   with it that may concern the client.  The client may have to have a
   local index of entries by DN or UUID to determine if the entry has
   been added or just modified.  It is easy for clients to determine if
   the entry has been deleted because the entryDeleted value of the
   entryUpdateControl will be TRUE.

5.3     Sending Changes

   Some earlier synchronization protocols sent the client(s) only the
   modified attributes of the entry rather than the entire entry. While
   this approach can significantly reduce the amount of data returned
   to the client, it has several disadvantages. First, unless a
   separate mechanism (like the change type described above) is used to
   notify the client about entries moving into the search scope,
   sending only the changes can result in the client having an
   incomplete version of the data. Let's consider an example. An
   attribute of an entry is modified. As a result of the change, the
   entry enters the scope of the client's search. If only the changes
   are sent, the client would never see the initial data of the entry.
   Second, this feature is hard to implement since the server might not
   contain sufficient information to construct the changes based solely
   on the server's state and the client's cookie. On the other hand,
   this feature can be easily implemented by the client assuming that
   the client has the previous version of the data and can perform
   value by value comparisons.


Megginson, et. al. Proposed Standard - Expires: December 2002       12


5.4     Data Size Limits

   Some earlier synchronization protocols allowed clients to control
   the amount of data sent to them in the search response. This feature
   was intended to allow clients with limited resources to process
   synchronization data in batches. However, an LDAP search operation
   already provides the means for the client to specify the size limit
   by setting the sizeLimit field in the SearchRequest to the maximum
   number of entries the client is willing to receive. While the
   granularity is not the same, the assumption is that regular LDAP
   clients that can deal with the limitations of the LDAP protocol will
   implement LCUP.

5.5     Data Ordering

   Some earlier synchronization protocols allowed a client to specify
   that parent entries should be sent before the children for add
   operations and children entries sent before their parents during
   delete operations. This ordering helps clients to maintain a
   hierarchical view of the data in their data store. While possibly
   useful, this feature is relatively hard to implement and is
   expensive to perform.

6.      Client Side Considerations

   Clients SHOULD always specify entryUUID in the SearchRequest
   attribute list.

   The cookie received from the server after a synchronization session
   can only be used with the same or more restrictive search
   specification than the search that generated the cookie. The server
   will reject the search operation with a cookie that does not satisfy
   this condition. This is because the client can end up with an
   incomplete data store otherwise. A more restrictive search
   specification is the one that generates a subset of the data
   produced by the original search specification.

   Because an LCUP client specifies the area of the tree with which it
   wishes to synchronize through the standard LDAP search
   specification, the client can be returned noSuchObject error if the
   root of the synchronization area was renamed between the
   synchronization sessions or during a synchronization session. If
   this condition occurs, the client can attempt to locate the root by
   using the root's UUID saved in client's local data store. It then
   can repeat the synchronization request using the new search base. In
   general, a client can detect that an entry was renamed and apply the
   changes received to the right entry by using the UUID rather than DN
   based addressing.

   Each active persistent operation requires that an open TCP
   connection be maintained between an LDAP client and an LDAP server
   that might not otherwise be kept open.  Therefore, client
   implementors are encouraged to avoid using persistent operations for
   non-essential tasks and to close idle LDAP connections as soon as

Megginson, et. al. Proposed Standard - Expires: December 2002       13


   practical.  The server may close connections if server resources
   become tight.

   The client MAY receive a continuation reference
   (SearchResultReference [RFC2251 SECTION 4.5.3]) if the search
   request spans multiple parts of the DIT, some of which may require a
   different LCUP cookie, some of which may not even be managed by
   LCUP.  The client SHOULD maintain a cache of the LDAP URLs returned
   in the continuation references and the cookies associated with them.
   The client is responsible for performing another LCUP search to
   follow the references, and SHOULD use the cookie corresponding to
   the LDAP URL for that reference (if it has a cookie).

   The client may receive a referral (Referral [RFC2251 SECTION
   4.1.11]) when the search base is a subordinate reference, and this
   will end the operation.

   For alias dereferencing, the server will behave as if the client had
   requested neverDerefAliases or derefFindingBaseObj as the
   derefAliases field in the search request [RFC2251, Section 4.5.1].
   If the client specifies a value other than neverDerefAliases or
   derefFindingBaseObj, the server will return protocolError to the
   client.

   Changes to data (e.g., that might affect the LCUP client's filter or
   scope) or meta-data (e.g., that might affect the client's read
   access) may affect the presence of entries in the search set.
   Servers MAY notify LCUP clients of changes to the search set that
   result from such changes, but an LCUP client MUST NOT assume that
   such notification will occur.  Therefore, in the case where a client
   is maintaining a cache of entries using LCUP, the data held by the
   client may be a superset or a subset of the entries that would be
   returned by a new search request.  For example, if access control
   meta information is changed to deny access to particular entries in
   the search result set, and the access control information is outside
   of the search scope (e.g., in a parent entry), the client may have
   entries stored locally which are no longer part of its desired
   search set.  Similarly, if entries are added to the search result
   set due to changes in meta-data, the client's cache of entries may
   not include these entries.

   Some clients may wish to perform an initial synchronization in order
   to prime a cache or establish a baseline set of entries, then look
   for changes after that.  The recommended way to do this is to first
   issue an LCUP search with the updateType field of the clientUpdate
   control value set to synchronizeOnly, then after that search
   successfully completes, immediately issue an LCUP search with the
   updateType field of the clientUpdate control value set to
   synchronizeAndPersist.

   Some clients may have unreliable connections, for example, a
   wireless device or a WAN connection.  These clients may want to
   insure that the cookie is returned often in the entryUpdate control
   value, so that if they have to reconnect, they do not have to

Megginson, et. al. Proposed Standard - Expires: December 2002       14


   process many redundant entries.  These clients should set the
   sendCookieInterval in the clientUpdate control value to a low
   number, perhaps even 1.  Also, some clients may have a limited
   bandwidth connection, and may not want to receive the cookie very
   often, or even at all (however, the cookie is always sent back in
   the clientUpdateDone control value upon successful completion).
   These clients should set the sendCookieInterval in the clientUpdate
   control value to a high number.

7.      Server Implementation Considerations

   Servers SHOULD support UUIDs.  Otherwise, it will be very difficult
   to support modifyDN operations.  Adding support for UUIDs should be
   seen as a necessary component of LCUP.

   By design, the protocol supports multiple cookie schemes.  This is
   to allow different implementations the flexibility of storing any
   information applicable to their environment. A reasonable
   implementation for an LDUP compliant server would be to use the
   Replica Update Vector (RUV). For each master, RUV contains the
   largest CSN seen from this master. In addition, the RUV implemented
   by some directory servers (not yet in LDUP) contains replica
   generation - an opaque string that identifies the replica's data
   store. The replica generation value changes whenever the replica's
   data is reloaded. Replica generation is intended to signal the
   replication/synchronization peers that the replica's data was
   reloaded and that all other replicas need to be reinitialized. RUV
   satisfies the three most important properties of the cookie: (1) it
   uniquely identifies the state of client's data, (2) it can be used
   to synchronize with multiple servers, and (3) it can be used to
   detect that the server's data was reloaded.

   A server may support one or more LCUP cookie schemes.  It is
   expected that schemes will be published along with their OIDs as
   RFCs.  If a client initiates an LCUP session with a particular
   scheme, the server MUST use that same scheme throughout the LCUP
   session, or until an LCUP context boundary is crossed, in which case
   the server will usually require a different cookie anyway.

   In addition, the cookie must contain enough information to allow the
   server to determine whether the cookie can be safely used with the
   search specification it is attached to. As discussed earlier in the
   document, the cookie can only be used with the search specification
   that is equally or more restrictive than the one for which the
   cookie was generated.

   An implementation must make sure that it can correctly update the
   client's cookie when there is a size limit imposed on the search
   results by either the client's request or by the server's
   configuration. If RUV is used as the cookie, entries last modified
   by a particular master must be sent to the client in the order of
   their last modified CSN. This ordering guarantees that the RUV can
   be updated after each entry is sent.


Megginson, et. al. Proposed Standard - Expires: December 2002       15


   The server's DIT may be partitioned into different sections which
   may have different cookies associated with them.  For example, some
   servers may use some sort of replication mechanism to support LCUP.
   If so, the DIT may be partitioned into multiple replicas.  A client
   may send an LCUP search request that spans multiple replicas.  Some
   parts of the DIT spanned by the search request scope may be managed
   by LCUP and some may not.  A part of the DIT which is enabled for
   LCUP is referred to as an LCUP Context.  The server SHOULD send a
   SearchResultReference [RFC2251, SECTION 4.5.3] when the LCUP Context
   for a returned entry changes.  The server SHOULD return all entries
   for a particular LCUP Context before returning a reference to other
   LCUP Contexts or non-LCUP enabled parts of the DIT, in order to
   minimize the processing burden on the clients.  The LDAP URL(s)
   returned MUST contain the DN(s) of the base of another section of
   the DIT (however the server implementation has partitioned the DIT).
   The client will then issue another LCUP search using the LDAP URL
   returned.  Each section of the DIT MAY require a different cookie
   value, so the client SHOULD maintain a cache, mapping the different
   LDAP URL values to different cookies.  If the cookie changes, the
   scheme may change as well, but the cookie scheme MUST be the same
   within a given LCUP Context.

   An implementation SHOULD notify the client about all entries deleted
   from the search set since the client's last session, but an LCUP
   client MUST NOT assume that such notification will occur.  For
   example, the server might not notify the client of the deletion of
   an object if the object left the search set following the client's
   last synchronization and prior to the object's deletion.  An LDUP
   compliant implementation can achieve this through the use of entry
   tombstones. The implementation should avoid aggressive tombstone
   purging since lack of tombstones would cause client's data to be
   reloaded. We suggest that only the tombstone content be removed
   during the regular trimming cycle while tombstones themselves are
   discarded much less frequently.

   The specification makes no guarantees about how soon a server should
   send notification of a changed entry to the client when the
   connection between the client and the server is kept open. This is
   intentional as any specific maximum delay would be impossible to
   meet in a distributed directory service implementation.  Server
   implementors are encouraged to minimize the delay before sending
   notifications to ensure that clients' needs for timeliness of change
   notification are met.

   Implementors of servers that support the mechanism described in this
   document should ensure that their implementation scales well as the
   number of active persistent operations and the number of changes
   made in the directory increases. Server implementors are also
   encouraged to support a large number of client connections if they
   need to support large numbers of persistent operations.

8.      Synchronizing Heterogeneous Data Stores



Megginson, et. al. Proposed Standard - Expires: December 2002       16


   Clients, like a meta directory join engine, synchronizing multiple
   writable data stores will only work correctly if each piece of
   information is single mastered (for instance, only by an LDUP
   compliant directory). This is because different systems have
   different notions of time and different update resolution
   procedures. As a result, a change applied on one system can be
   discarded by the other, thus preventing the data stores from
   converging.

9.      Security Considerations

   In some situations, it may be important to prevent general exposure
   of information about changes that occur in an LDAP server.
   Therefore, servers that implement the mechanism described in this
   document SHOULD provide a means to enforce access control on the
   entries returned and MAY also provide specific access control
   mechanisms to control the use of the controls and extended
   operations defined in this document.

   As with normal LDAP search requests, a malicious client can initiate
   a large number of persistent search requests in an attempt to
   consume all available server resources and deny service to
   legitimate clients.  The protocol provides the means to stop
   malicious clients by disconnecting them from the server. The servers
   that implement the mechanism SHOULD provide the means to detect the
   malicious clients. In addition, the servers SHOULD provide the means
   to limit the number of resources that can be consumed by a single
   client.

   Access control on the data can be modified in such a way that the
   data is no longer visible to the client. The specification does not
   specify how the server should handle this condition. Moreover, data
   consistency is not guaranteed if access control is changed from a
   more restrictive to a less restrictive one. This is because access
   control can be considered as an additional filter on the search
   specification and the protocol does not support going from a more to
   a less restrictive search specification. See Client Side
   Considerations Section for more detailed explanation of the problem.

10.     Normative References

   [KEYWORDS]    S. Bradner, "Keywords for use in RFCs to Indicate
                 Requirement Levels", RFC 2119, March 1997.

   [RFC2251]    M. Wahl, T. Howes, S. Kille "Lightweight Directory
                Access Protocol", RFC 2251, December 1997.

   [RFC2252]    M. Wahl, A. Coulbeck, T. Howes, S. Kille, "Lightweight
                Directory Access Protocol (v3): Attribute Syntax
                Definitions", RFC 2252, December 1997.

   [CANCEL]     K. Zeilenga, "LDAP Cancel Extended Operation",
                draft-zeilenga-ldap-cancel-xx.txt, a work in progress.


Megginson, et. al. Proposed Standard - Expires: December 2002       17


11.     Acknowledgements

   The LCUP protocol is based in part on the Persistent Search Change
   Notification Mechanism defined by Mark Smith, Gordon Good, Tim
   Howes, and Rob Weltman, the LDAPv3 Triggered Search Control defined
   by Mark Wahl, and the LDAP Control for Directory Synchronization
   defined by Michael Armijo.

12.     Author's Addresses

   Rich Megginson
   Netscape Communications Corp.
   901 San Antonio Rd.
   Palo Alto, CA  94303-4900
   Mail Stop SCA17 - 201
   Phone: +1 505 797-7762
   Email: richm@netscape.com

   Olga Natkovich
   Yahoo, Inc.
   701 First Ave.
   Sunnyvale, CA 94089
   Phone: +1 408 349-6153
   Email: olgan@yahoo-inc.com

   Mark Smith
   Netscape Communications Corp.
   901 San Antonio Rd.
   Palo Alto, CA  94303-4900
   Mail Stop SCA17 - 201
   Phone: +1 650 937-3477
   Email: mcs@netscape.com

   Jeff Parham
   Microsoft Corporation
   One Microsoft Way
   Redmond, WA 98052-6399
   Phone: +1 425 882-8080
   Email: jeffparh@microsoft.com

13.     Full Copyright Statement
   "Copyright (C) The Internet Society (date). All Rights Reserved.
   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph
   are included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than

Megginson, et. al. Proposed Standard - Expires: December 2002       18


   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

14.     Appendix A - Summary of Changes

   Changes new to version 03:

     Emphasized the use of UUIDs throughout the document.  Implementers
     are strongly encouraged to use UUIDs as a necessary component of
     the protocol.

     Removed the LCUP Cancel extended operation in favor of the new
     LDAP Cancel operation [CANCEL].

     Got rid of the lcupSuccess result code.  All result codes will be
     added to the IANA LDAP result code registry as part of the LDAP
     standard.  Also removed the result code and text from the client
     update done control value.

     Changed any and all wording suggesting an LCUP Context is related
     to a naming context.  New text says an LCUP Context is a part of
     the DIT that supports LCUP, and that a server may have one or more
     LCUP Contexts.

     Removed Old Section 4.2: lcupCookieScheme
     We decided that LCUP did not need a discovery mechanism.  The
     controls and extended operations will be published in the root DSE
     as per the LDAP standards.

     Changed references to "Unique Identifier" to either "Universally
     Unique Identifier" or "UUID".

     Added this text to section 6 "Client Side Considerations":
     "- The client may receive a referral (Referral [RFC2251 SECTION
      4.1.11]) when the search base is a subordinate reference, and
      this will end the operation."

     Added a note to section 6 "Client Side Considerations" about how
     to establish a baseline set of entries or entry cache.

     Added the field sendCookieInterval to the clientUpdate control
     value.

     Added a note to section 6 "Client Side Considerations" explaining
     possible uses of the sendCookieInterval.

Megginson, et. al. Proposed Standard - Expires: December 2002       19



   Changes new to version 02:

     Section 4.2: The lcupCookieScheme operational attribute MUST be
     present in the root DSE, and MAY be present in entries.  Each
     value of the attribute in the root DSE will be a list of OIDs of
     cookie schemes followed by the DN of the LCUP context which
     supports the schemes.  The attribute value in the DIT entries will
     be the list of OIDs followed by the DN of the LCUP context.

     section 4.5 - the entry uuid is now MAY instead of MUST - if
     implementers do not wish to identify entries by a unique ID other
     than DN (which may not be unique), then so be it.  For returned
     SearchResultEntry PDUs other than deleted entries, the client MAY
     request that the Unique Identifier attribute be returned by
     specifying it in the attribute list to be returned by the search
     request.

     section 4.5 - added "or the base DN of the client's search
     request." to the phrase.  "The server MAY send the entry at the
     root of the client's tree, or the base DN of the client's search
     request."  I think this clarifies which entry the client may
     search for.

     section 4.6 - the clientUpdateDone control is now optional for
     error conditions.  Also, the cookie value of the control is now
     optional for lcup error conditions (e.g. not lcupSuccess or
     lcupClientDisconnect).

     Added section 4.12 - Interactions with Other LDAP Search and
     Response Controls

     Added blurb about alias dereferencing back to section 6:
     "For alias dereferencing, the server will behave as if the client
     had requested neverDerefAliases or derefFindingBaseObj as the
     derefAliases field in the search request [RFC2251, Section 4.5.1].
     If the client specifies a value other than neverDerefAliases or
     derefFindingBaseObj, the server will return protocolError to the
     client."

     Changed this in section 6:
     Because an LCUP client specifies the area of the tree with which
     it wishes to synchronize through the standard LDAP search
     specification, the client can be returned noSuchObject error if
     the root of the synchronization area was renamed between the
     synchronization sessions "or during a synchronization session"

   Changes new to version 01:

     The opaque cookie has been split into two parts - a scheme which
     is an OID, and a value.  The value may or may not have a format
     known to the client, depending on the specified scheme.  Section
     4.2 describes the new cookie format and defines the LCUP Cookie
     Value.

Megginson, et. al. Proposed Standard - Expires: December 2002       20



     Added new section 4.3 - the lcupCookieScheme operational
     attribute.

   Changes new to version 00:

     Added the definition for Unique Identifier (basically copied from
     the LDUP model doc http://search.ietf.org/internet-drafts/draft-
     ietf-ldup-model-06.txt.  I needed to add the definition here
     because LCUP needs a Unique Identifier but should not be dependent
     on LDUP.

     Removed all normative references to LDUP.  I've left the
     implementation suggestions that refer to LDUP, but LCUP should not
     be dependent on LDUP.

     Cleaned up the protocol flows.

     Removed this text from section 4.8: "Clients MUST NOT issue
     multiple synchronization requests on the same connection. This is
     because the protocol includes an extended operation and it would
     be impossible to decide which synchronization session it belongs
     to." - This is no longer true, since the extended operation now
     includes the message ID of the search request.

     "Client Side Consideration" section - the client will never
     receive a referral or continuation reference

     Added section 12.  Acknowledgements

     Removed normative references to documents not depended on.

     Removed explicit references to software vendors.

    Section 4.1 - Changed ClientUpdateControlValue to remove the
    keepConnection and changesOnly fields and replace them with
    updateType which is an ENUMERATED with three values:
    synchronizeOnly, synchronizeAndPersist, and persistOnly.

    Section 4.2 - The EntryUpdateControlValue fields stateUpdate and
    entryDeleted no longer have DEFAULT values, they must be specified
    - this eliminates any potential ambiguity.

    Added this text to the description of the entryDeleted field
    (section 4.2): "The server SHOULD also set this to TRUE if the
    entry has left the clients search result set.  As far as the client
    is concerned, a deleted entry is no different than an entry which
    has left the result set."
    Section 4.2 - Added an explanation of the concept and requirement
    for the Unique Identifier.

    Section 4.4 - Added to the extended operation a request value
    containing the message id of the operation to stop.


Megginson, et. al. Proposed Standard - Expires: December 2002       21


    Updated contact information for Olga.

    Removed Michael Armijo and added Jeff Parham as an author.

   Changes new to previous version:

    "Authors" section - added Rich Megginson as the new editor.

    "Client Side Consideration" section - added a note and a question
    concerning referral and continuation reference handling.

    "Client Update Control Value" section (4.1) - clarified the meaning
    of keepConnection and added a table summarizing the effects of
    different values of keepConnection and changesOnly.

    "Stop Client Update Request and Response" - added section 4.4
    describing this extended operation.






































Megginson, et. al. Proposed Standard - Expires: December 2002       22


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/