[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01 02 03 04 05 06 RFC 4533

INTERNET-DRAFT                                      Kurt D. Zeilenga
Intended Category: Experimental                  OpenLDAP Foundation
Expires in six months                                  Jonghyuk Choi
                                                     IBM Corporation
                                                     28 October 2002




                  LDAP Content Synchronization Operation
                    <draft-zeilenga-ldup-sync-00.txt>




1.      Status of this Memo

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

  Distribution of this memo is unlimited.  Technical discussion of this
  document will take place on the IETF LDUP Working Group mailing list
  at <ietf-ldup@imc.org>.  Please send editorial comments directly to
  the document editor at <Kurt@OpenLDAP.org>.

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

  Copyright 2002, The Internet Society.  All Rights Reserved.

  Please see the Copyright section near the end of this document for
  more information.









Zeilenga               LDAP Content Sync Operation              [Page 1]


INTERNET-DRAFT         draft-zeilenga-ldup-sync-00       28 October 2002


Abstract

  This specification describes an LDAP (Lightweight Directory Access
  Protocol) content synchronization operation offering "eventual
  convergent" data consistency.  The operation allows a client maintain
  a shadow copy of a fragment of directory information tree.  The
  operation supports both polling for changes and listening for changes.

  The LDAP Content Synchronization Operation is defined as an extension
  of the LDAP Search Operation.  This specification defines the Sync
  Request, Sync State, and Sync Done controls, the Sync Intermediate
  Response message, and a number of other protocol and schema elements.


Preface

  This document is intended to be used to further discussions regarding
  the LDAP Client Update Protocol (LCUP) work within the IETF LDUP.
  Presently, LCUP does not provide eventual convergent synchronization
  of content.  This document offers one possible technical approach
  which could be adapted for use in LCUP.

  The authors presently view this approach as experimental.  While the
  authors have gained some operational experience by implementing LCUP,
  they have not yet implemented this approach.  Due to the complexities
  of eventual convergent synchronization of LDAP content, "running code"
  is needed to ensure this approach is suitable for standardization.


Conventions

  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 BCP 14 [RFC2119].

  Protocol elements are described using ASN.1 [X.680].  The term
  "BER-encoded" means the element is to be encoded using the Basic
  Encoding Rules [X.690] under the restrictions detailed in Section 5.1
  of [RFC2251].


1. Introduction

  The Lightweight Directory Access Protocol (LDAP) [RFC3377] provides a
  mechanism, the search operation [RFC2251], to allow a client to
  request the return of content matching a complex set of assertions and
  for the server to return this content, subject to access control and
  other restrictions, to the client.  However, short of issuing search



Zeilenga               LDAP Content Sync Operation              [Page 2]


INTERNET-DRAFT         draft-zeilenga-ldup-sync-00       28 October 2002


  operations, LDAP does not provide an effective, efficient, and
  standardized mechanism for maintaining an complete and accurate shadow
  copy of content held in the Directory Information Tree (DIT).

  This document defines the LDAP Content Synchronization operation, or
  Sync operation for short, which allows a client to maintain a
  synchronized shadow copy of a fragment of a DIT.  The Sync operation
  is defined as a set of controls and other protocol elements which
  extend the Search operation.


1.1. Background

  Over the years, a number of synchronization approaches have been
  suggested.   These approaches are inadequate for one or more of the
  following reasons:

    1) do not ensure a reasonable level of convergence;
    2) fail to detect that convergence cannot be achieved (without
       reload);
    3) require pre-arranged synchronization agreements;
    4) require the server to maintain synchronization state on a per
       user basis; and
    5) require the server to maintain a history of past changes to DIT
       content.

  The Sync operation provides eventual convergence of synchronized
  content when possible and, when not, notification that content reload
  is required.

  The Sync operation does not require pre-arranged synchronization
  agreements.

  The Sync operation does not require servers to maintain
  synchronization state on a per user basis.

  The Sync operation does not require servers to maintain any history of
  past changes to the DIT.  While histories (e.g., change logs) may be
  used in the implementation of the Sync operation, the operation may be
  implemented using entry-level change sequence number (CSN) approach.
  This is discussed in Appendix A.


1.2. Intended Usage

  The Sync operation is intended to be used in applications requiring
  eventual-convergent content-synchronization.  Upon completion of each
  synchronization phase of the operation, all information to construct



Zeilenga               LDAP Content Sync Operation              [Page 3]


INTERNET-DRAFT         draft-zeilenga-ldup-sync-00       28 October 2002


  an up-to-date shadow copy of the content has been provided to the
  client or the client has been notified that a complete content reload
  is necessary.

  Possible uses:
    - White page service applications may use the Sync operation to
      maintain current shadow copy of a DIT fragment.  For example, an
      mail transfer agent which requires, for performance and
      reliability reasons, a copy of select set of attributes of all
      user objects.

    - Meta-directory applications may use the Sync operation to the Sync
      operation to maintain a shadow copy of a DIT fragment in other
      (non-LDAP/X.500) data stores.

    - Caching proxy services may use the Sync operation to maintain a
      coherent content cache.

    - Lightweight master-slave replication between heterogenous LDAP
      servers.  For example, the Sync operation can be used by a slave
      server to maintain a shadow copy of a DIT fragment.

  Note: The International Telephone Union (ITU) has defined the X.500
        Directory Synchronization Protocol [X.525] which may be used for
        master-slave replication between LDAP servers.  Additionally,
        the IETF is designing a feature-rich LDAP server-to-server
        replication protocol called the LDAP Duplication and Update
        Protocol (LDUP) [RFC3384].  LDUP will support multi-master
        replication in addition to master-slave replication.  The Sync
        operation should be viewed as complementary to these replication
        protocols.


1.3. Overview

  This section provides an overview of basis ways the Sync operation can
  be used to maintain a synchronized shadow copy of a DIT fragment.

    - Polling for Changes: refreshOnly mode
    - Listening for Changes: refreshAndPersist mode


1.3.1. Polling for Changes (refreshOnly)

  To obtain its initial shadow copy, the client issues a Sync request: a
  search request with the Sync Request Control with mode set to
  refreshOnly.  The server, much like it would with a normal search
  operation, returns (subject to access controls and other restrictions)



Zeilenga               LDAP Content Sync Operation              [Page 4]


INTERNET-DRAFT         draft-zeilenga-ldup-sync-00       28 October 2002


  the content matching the search criteria (baseObject, scope, filter).
  Additional, for each entry returned, the server provides a Sync State
  control indicating state add.  This control contains the Universally
  Unique Identifier (UUID) [UUID] of the entry.  Unlike Distinguished
  Names (DNs), which may change over time, UUIDs are stable.  The
  initial content is followed by a searchResultDone with a Sync Done
  control.  The Sync Done control provides a syncCookie.  The syncCookie
  can be viewed as both a synchronization session identifier as well as
  representing session state.

  To poll for updates to the shadow copy, the client reissues the Sync
  operation with the syncCookie previously returned.  The server, much
  as it would with a normal search operation, determines which content
  would be returned as if the operation was a normal search operation.
  However, using the syncCookie as an indicate of what content the
  client was sent previously, sends copies of entries which have changed
  with a Sync State control indicating state add.  Each entry which is
  unchanged, the server sends an empty entry with a Sync State control
  indicate state present.  The set of updates is followed by a
  searchResultDone with a Sync Done control.

  The synchronized shadow copy of the DIT fragment is constructed by the
  client.  It includes all changed entries returned by the reissued Sync
  operation as well as all unchanged entries identified as being present
  by the reissued Sync operation, but whose content is provided by the
  previous Sync operation.

  The client can, at some later time, re-poll for changes to this
  synchronized shadow copy.


1.3.2. Listening for Changes (refreshAndPersist)

  Polling for changes can be expensive in terms of server, client, and
  network resources. The refreshAndPersist mode allows for active
  notification of changes to the content.

  By selecting the refreshAndPersist mode, the client requests the
  server to send change notifications after sending refresh messages.
  Instead of sending a searchResultDone message as described above, the
  server sends a Sync Info message to the client indicating that refresh
  phase is complete and then enters persist mode.  Upon receipt of this
  Sync Info message, the client constructs a synchronized shadow copy as
  described above.

  The server may then send change notifications.  For entries to be
  added to the returned content, the server sends a searchResultEntry
  (with attributes) with a Sync State control indicating state add.  For



Zeilenga               LDAP Content Sync Operation              [Page 5]


INTERNET-DRAFT         draft-zeilenga-ldup-sync-00       28 October 2002


  entries to be deleted from the content, the server sends a
  searchResultEntry containing with no attributes and a Sync State
  control indicating state delete.  To modify entries in the return
  content, the server sends a searchResultEntry (with attributes) with a
  Sync State control indicating state modify.  Upon modification of an
  entry, all (modified or unmodified) attributes belonging to the
  content are sent.

  Note that renaming an entry of the DIT may cause an add state change
  where the entry is renamed into the content, a delete state change
  where the entry is renamed out of the content, and a modify state
  change where the entry remains in the content.  Also note that a
  modification of an entry of the DIT may cause a add, delete, or modify
  state change to the content.

  Upon receipt of a change notification, the client updates its copy of
  the content.

  If the server desires to update the syncCookie during the persist
  stage, it may include the syncCookie any Sync State control or Sync
  Info message returned.

  The operation persists until canceled [CANCEL] by the client or
  terminated by the server.   A Sync Done control may be attached to
  searchResultDone message to provide a new syncCookie.


2. Elements of the Sync Operation

  The Sync Operation is defined as an extension to the LDAP Search
  Operation [RFC2251] where the client submits a SearchRequest message
  with a Sync Request control and the server responses with zero or more
  SearchResultEntry messages, each with a Sync State control; zero or
  more SearchResultReference messages, each with a Sync State control;
  zero or more Sync Intermediate Response messages; and a
  searchResultDone message with a Sync Done control.

  To allow clients to discover support for this operation, servers
  implementing this operation SHOULD publish the IANA-ASSIGNED-OID.1 as
  a value of supportedControl root DSE attribute.

  [[Note to IANA and the RFC-Editor: the string IANA-ASSIGNED-OID is a
  place holder for OID requested below.]]


2.1 Common ASN.1 elements

      syncUUID   ::= OCTET STRING



Zeilenga               LDAP Content Sync Operation              [Page 6]


INTERNET-DRAFT         draft-zeilenga-ldup-sync-00       28 October 2002


      syncCookie ::= OCTET STRING


2.2 Sync Request Control

  The Sync Request Control is an LDAP Control [RFC2251, Section 4.1.2]
  where the controlType is the object identifier IANA-ASSIGNED-OID.1 and
  the controlValue, an OCTET STRING, contains a BER-encoded
  syncRequestValue.  The criticality field is either TRUE or FALSE (and
  hence absent).

      syncRequestValue ::= SEQUENCE {
          mode    ENUMERATED {
              -- 0 unused
              refreshOnly       (1),
              -- 2 reserved
              refreshAndPersist (3)
          },
          cookie  syncCookie OPTIONAL
      }

  The Sync Request Control is only applicable to the searchRequest
  message.


2.3 Sync State Control

  The Sync State Control is an LDAP Control [RFC2251, Section 4.1.2]
  where the controlType is the object identifier IANA-ASSIGNED-OID.2 and
  the controlValue, an OCTET STRING, contains a BER-encoded
  syncStateValue.  The criticality is FALSE (and hence absent).

      syncStateValue ::= SEQUENCE {
          state   ENUMERATED {
              present           (0),
              add               (1),
              modify            (2),
              delete            (3)
          },
          entryUUID    syncUUID,
          cookie       syncCookie OPTIONAL
      }

  The Sync State Control is only applicable to SearchResultEntry and
  SearchResultReference messages.


2.4 Sync Done Control



Zeilenga               LDAP Content Sync Operation              [Page 7]


INTERNET-DRAFT         draft-zeilenga-ldup-sync-00       28 October 2002


  The Sync Done Control is an LDAP Control [RFC2251, Section 4.1.2]
  where the controlType is the object identifier IANA-ASSIGNED-OID.3 and
  the controlValue contains a BER-encoded syncDoneValue.  The
  criticality is FALSE (and hence absent).

      syncDoneValue ::= SEQUENCE {
          cookie  syncCookie OPTIONAL
      }

  The Sync Done Control is only applicable to SearchResultDone message.


2.5 Sync Info Message

  The Sync Info Message is an LDAP Intermediate Response [LDAPIR] where
  responseName is the object identifier IANA-ASSIGNED-OID.4 and
  responseValue contains a BER-encoded syncInfoValue.

      syncInfoValue ::= SEQUENCE {
          state   ENUMERATED {
              refreshDone       (0),
              newCookie         (1),
          },
          cookie  syncCookie OPTIONAL
      }

  The cookie MUST be present if the state is newCookie,


2.6 Sync Result Codes

  The following LDAP resultCodes [RFC2251] are defined:

      syncRefreshRequired (IANA-ASSIGNED-CODE-0)

  [[Note to IANA and the RFC-editor: the IANA-ASSIGNED-CODE-* are place
  holders for result codes requested below.]]


3. Content Synchronization

  The Sync Operation is invoked by the client sending a searchRequest
  message with a Sync Request Control.

  The absence of a cookie indicates a request for initial content while
  the presence of a cookie indicates a request for content update.
  Synchronization Sessions are discussed in Section 3.1.  Content
  Determination is discussed in Section 3.2.



Zeilenga               LDAP Content Sync Operation              [Page 8]


INTERNET-DRAFT         draft-zeilenga-ldup-sync-00       28 October 2002


  The mode is either refreshOnly or refreshAndPersist.  The refreshOnly
  and refreshAndPersist modes are discussed in Section 3.3 and 3.4,
  respectively.


3.1. Synchronization Session

  A sequence of Sync Operations where the (last) cookie returned by an
  operation is provided by the client in the next operation are said to
  be belong to the same Synchronization Session.

  A Synchronization Session may span multiple LDAP sessions between the
  client and the server.   The client SHOULD only issue each Sync
  request of a session to the same server.  The client SHOULD also issue
  each Sync request of a session under the same authentication and
  authorization associations with equivalent integrity and confidential
  protections.  If the server does not recognize the request cookie or
  the request is made under different associations or protections, the
  server SHALL process the request as if no cookie had been provided.


3.2.  Content Determination

  The content to be provided is determined by parameters of the Search
  Request, as described in [RFC2251], and possibly other controls.  The
  same content SHOULD be used in each Sync request of a session.  If
  different content is requested and the server is unwilling or unable
  to process the request, the server SHALL process the request as if no
  cookie had been provided.

  The content may not necessarily include all entries which would be
  returned by a normal search operation nor, for those entries included,
  not all attributes returned by a normal search.  Where the server is
  unwilling or unable to provide synchronization for an attribute for a
  set of entries, the server MUST treat all filter components matching
  against these attribute as Undefined and MUST NOT return the attribute
  in searchResultEntry responses.

  Servers SHOULD support synchronization for all non-collective user-
  applications attributes for all entries.


3.3.  refreshOnly mode

  A Sync request with mode refreshOnly and no cookie is a poll for
  initial content.  A Sync request with mode refreshOnly and cookie is a
  poll for content update.




Zeilenga               LDAP Content Sync Operation              [Page 9]


INTERNET-DRAFT         draft-zeilenga-ldup-sync-00       28 October 2002


3.3.1.  Initial Content Poll

  Upon receipt of the request, the server provides the initial content
  using a set of zero or more searchResultEntry messages and zero or
  more searchResultReference messages followed by a searchResultDone
  message.

  Each searchResultEntry message SHALL include a Sync State control of
  state add, entryUUID containing the entry's UUID, and no cookie.  Each
  searchResultReference message SHALL include a Sync State control of
  state add, entryUUID containing the UUID of the DSE holding the
  reference knowledge, and no cookie.   The searchResultDone message
  SHALL include a Sync Done control.

  A resultCode value of success indicates the operation successfully
  completed.  Otherwise, the result code indicate the nature of failure.

  If the operation is successful, a cookie SHOULD be returned for use in
  subsequent Sync operations.


3.3.2.  Content Update Poll

  Upon receipt of the request, the server provides the content refresh
  using a set of zero or more searchResultEntry messages and zero or
  more searchResultReference messages followed by a searchResultDone
  message.

  The server is REQUIRED to either:
      a) provide the sequence of messages necessary for eventual
         convergence of the client's copy of the content to the server's
         copy,

      b) treat the request as an initial content request (e.g., ignore
         the cookie),

      c) indicate that convergence is not possible by returning
         refreshRequired,

      d) return a resultCode other than success or refreshRequired.

  For each entry or reference added to the content or was changed since
  the previous Sync operation indicated by the cookie, the server return
  searchResultEntry and searchResultReference messages with a Sync State
  cookie of state add, entryUUID containing the UUID of the entry (or
  DSE), and no cookie.  Each searchResultEntry message represents the
  current state of a changed entry.  Each searchResultReference
  represents the current state of a changed DSE holding reference



Zeilenga               LDAP Content Sync Operation             [Page 10]


INTERNET-DRAFT         draft-zeilenga-ldup-sync-00       28 October 2002


  knowledge.

  For each entry which has not changed since the previous Sync
  operation, a searchResultEntry is returned whose objectName reflects
  the entry's current DN, the attributes field is empty, and a Sync
  State control of state present, entryUUID containing the UUID of the
  entry, and no cookie.

  For each reference which has not changed since the previous Sync
  operation, a searchResultReference is returned whose SEQUENCE OF
  LDAPURL is empty and a Sync State control of state present, entryUUID
  containing the UUID of the DSE holding the reference knowledge, and no
  cookie.

  No messages are sent for entries or references which are no longer in
  content.

  A resultCode value of success indicates the operation successfully
  completed.  Otherwise, the result code indicate the nature of failure.

  If the operation is successful, a cookie SHOULD be returned for use in
  subsequent Sync operations.


3.4.  refreshAndPersist mode

  A Sync request with mode refreshAndPersist asks for initial content or
  content update (during the refresh stage) followed by change
  notifications (during the persist stage).

3.4.1. refresh stage

  The content refresh is provided as described in Section 3.2 excepting
  that successful completion of content refresh is indicated by sending
  a Sync Info with state refreshDone message instead of a
  SearchResultDone message with resultCode success.   A cookie SHOULD be
  returned for use in subsequent Sync operations.

3.4.2. persist stage

  Change notifications are provided during the persist stage.

  As updates are made to the DIT the server notifies the client of
  changes to the content.  DIT updates may cause entries to be added to
  the content, deleted from the content, or modify of entry in the
  content.  DIT updates may cause references to be added, deleted, or
  modified within the content.




Zeilenga               LDAP Content Sync Operation             [Page 11]


INTERNET-DRAFT         draft-zeilenga-ldup-sync-00       28 October 2002


  Where DIT updates cause an entry to be added to the content, the
  server provides a searchResultEntry message which represents the entry
  as it is appears in the content.  The message SHALL include a Sync
  State control with state of add, entryUUID containing the entry's
  UUID, and an optional cookie.

  Where DIT updates cause an entry to be modified in the content, the
  server provides a searchResultEntry message which represents the entry
  as it is appears in the content.  The message SHALL include a Sync
  State control with state of modify, entryUUID containing the entry's
  UUID, and an optional cookie.

  Where DIT updates cause an entry to be deleted from the content, the
  server provides a searchResultEntry message with no attributes.  The
  message SHALL include a Sync State control with state of delete,
  entryUUID containing the entry's UUID, and an optional cookie.

  Where DIT updates cause an reference to be added to the content, the
  server provides a searchResultReference message which represents the
  entry as it is appears in the content.  The message SHALL include a
  Sync State control with state of add, entryUUID containing the entry's
  UUID, and an optional cookie.

  Where DIT updates cause an reference to be modified in the content,
  the server provides a searchResultReference message which represents
  the entry as it is appears in the content.  The message SHALL include
  a Sync State control with state of modify, entryUUID containing the
  entry's UUID, and an optional cookie.

  Where DIT updates cause an reference to be deleted from the content,
  the server provides a searchResultReference message whose SEQUENCE OF
  LDAPURL is empty.  The message SHALL include a Sync State control with
  state of delete, entryUUID containing the entry's UUID, and an
  optional cookie.

  With each of these messages, the server may provide a new cookie to be
  used in subsequent Sync operations.  Additionally, the server may also
  return Sync Info messages of state newcookie to provide a new cookie.
  The client SHOULD use newest (last) cookie it received from the server
  in subsequent Sync operations.


3.5.  objectName Issues

  The Sync operation uses entryUUID values as the primary keys to
  entries and references.  The client MUST use the entryUUIDs to
  correlate synchronization messages.




Zeilenga               LDAP Content Sync Operation             [Page 12]


INTERNET-DRAFT         draft-zeilenga-ldup-sync-00       28 October 2002


  In some circumstances the DN returned may not reflect the entry's
  current DN.  In particular, when the entry is being deleted from the
  content, the server MAY provide an empty DN if the server does not
  wish to disclose the entry's current DN (or, if deleted from the DIT,
  the entry's last DN).

  It should also be noted that the entry's DN may be viewed as meta
  information (see section 4.1).


3.6.  Canceling the Sync Operation

  Servers SHOULD implement the LDAP Cancel [CANCEL] operation and
  support cancelation of outstanding Sync operations as described here.

  To cancel an outstanding Sync Operation, the client SHOULD issue a
  Cancel operation [CANCEL]....


3.7. Eventual Convergence Considerations

  In order to achieve the eventual-convergent synchronization, the
  server may terminate the Sync operation in refresh or persist stage by
  returning a syncRefreshRequired resultCode to the client.  The client
  may then request a full reload (e.g., no cookie) instead of
  incremental synchronization in order to obtain a new copy of the
  content.  In case that the client issues incremental synchronization
  requests between the issue of a syncRefreshRequired and that of a full
  reload, the server should send a syncRefreshRequired response again,
  but the client may receive one or more searchResultEntry responses
  before it receives the syncRefreshRequired response.

  The server may also choose to provide a full copy in the refresh stage
  (e.g., ignore the cookie) instead of providing an incremental refresh
  in order to achieve the eventual convergence.

  In the case of persist stage synchronization, the server returns the
  resultCode of syncRefreshRequired to the client to indicate that the
  client needs to issue a new Sync operation (e.g., no cookie) in order
  to obtain a synchronized copy of the content.

  The server may also return syncRefreshRequired if it determines that a
  refresh would be more efficient than sending all the messages required
  for convergence.


4. Meta Information Considerations




Zeilenga               LDAP Content Sync Operation             [Page 13]


INTERNET-DRAFT         draft-zeilenga-ldup-sync-00       28 October 2002


4.1. An Entry's DN

  As an entry's DN is constructed from its relative DN (RDN) and the
  entry's parent's DN, it is often viewed as meta information.

  While renaming or moving a superior to an entry causes the entry's DN
  to change, that change SHOULD NOT, by itself, cause synchronization
  message to be sent for that entry.


4.2. Operational Attributes

  Where values of an operational attribute is determined by values not
  held as part of the entry it appears in, the operational attribute
  SHOULD NOT support synchronization of the operational attribute.

  For example, in servers which implement X.501 subschema model [X.501],
  servers should not support synchronization of the subschemaSubentry
  attribute as its value is determined by values held and administrated
  in subschema subentries.

  For a counter example, servers which implement aliases
  [RFC2256][X.501] can support synchronization of the aliasedObjectName
  attribute as its values are held and administrated as part of the
  alias entries.

  Servers SHOULD support synchronization of the following operational
  attributes: createTimestamp, modifyTimestamp, creatorsName,
  modifiersName [RFC2252].  Servers MAY support synchronization of other
  operational attributes.  Synchronization of operational attributes is
  discussed in Section 4.1.


4.3. Collective Attributes

  A collective attribute is "a user attribute whose values are the same
  for each member of an entry collection" [X.501].  Use of collective
  attributes in LDAP is detailed in [COLLECTIVE].

  Modification of a collective attribute generally affects the content
  of multiple entries, each a member of the collection.  It is
  inefficient to include values of collective attributes visible in
  entries of the collection, as a single modification of a collective
  attribute require transmission of multiple SearchResultEntry (one of
  each entry of the collection which the modification affected) to be
  transmitted.

  Servers SHOULD NOT synchronize collective attributes appearing in



Zeilenga               LDAP Content Sync Operation             [Page 14]


INTERNET-DRAFT         draft-zeilenga-ldup-sync-00       28 October 2002


  entries of any collection.  Servers MAY support synchronization of
  collective attributes appearing in collective attribute subentries.


4.4. Access and other administrative controls

  Entries are commonly subject to access and other administrative
  controls.  While portions of the policy information governing a
  particular entry may be held in the entry, policy information is often
  held elsewhere (in superior entries, in subentries, in the root DSE,
  in configuration files, ...).  Because of this, changes to policy
  information makes it difficult to ensure eventual convergence during
  incremental synchronization.

  Where it is impractical or infeasible to generate content changes
  resulting from a change to policy information, servers may opt to
  return syncReloadRequired or treat the Sync Operation as an initial
  content request (e.g., ignore the cookie).


5. Interaction with other controls

  The Sync Operation may be used with:

      - ManageDsaIT Control [RFC3296]
      - Subentries Control [SUBENTRY]

  as described below.  The Sync operation may be used with other LDAP
  extensions as detailed in other documents.


5.1. ManageDsaIT control

  As when used with other operations, the ManageDsaIT control [RFC3296]
  causes referral and other special objects to be treated as normal
  objects with respect to the Sync Operation and other controls.  That
  is, the referral and other special objects appear in the content as
  normal objects.


5.2. Subentries control

  The Subentries control is used with the search operation "to control
  the visibility of entries and subentries which are within scope"
  [SUBENTRY].  When used with the Sync Operation, the subentries control
  and other factors (search scope, filter, etc.) is used to determining
  whether an entry or subentry appear in the content or not.




Zeilenga               LDAP Content Sync Operation             [Page 15]


INTERNET-DRAFT         draft-zeilenga-ldup-sync-00       28 October 2002


6. Security Considerations

  In order to maintain a synchronized copy of the content, a client is
  to delete information from its copy of the content as described above.
  However, the client may maintain knowledge of information disclosed to
  it by the server separate from its copy of the content used for
  synchronization.  Management of this knowledge is beyond the scope of
  this document.

  While the information provided by a series of refreshOnly Sync
  operations is similar to that provided by a series of Search
  operations, persist stage may disclose additional information.  A
  client may be able to discern information about the particular
  sequence of update operations which caused content change.

  Implementors should take precautions against malicious cookie content.

  The Sync operation may be the target of denial of service attacks.
  Implementors should provide safeguards to ensure these mechanisms are
  not abused.  Servers may place access control or other restrictions
  upon the use of this operation.

  Implementors of this (or any) LDAP extension should be familiar with
  general LDAP security considerations [RFC3377].


7. IANA Considerations

  Registration of the following values is requested [RFC3383]....


8. Acknowledgment

  This work borrows significantly from the Lightweight Client Update
  Protocol [LCUP] work under development by the LDUP WG.  This work also
  benefited Persistent Search [PSEARCH], Triggered Search [TSEARCH], and
  Directory Synchronization [DIRSYNC] efforts.


9. Normative References

  [RFC3377]    J. Hodges, R. Morgan, "Lightweight Directory Access
               Protocol (v3): Technical Specification",
               draft-ietf-ldapbis-ldapv3-ts-xx.txt (a work in progress).

  [RFC2119]    S. Bradner, "Key words for use in RFCs to Indicate
               Requirement Levels", BCP 14 (also RFC 2119), March 1997.




Zeilenga               LDAP Content Sync Operation             [Page 16]


INTERNET-DRAFT         draft-zeilenga-ldup-sync-00       28 October 2002


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

  [RFC2830]    J. Hodges, R. Morgan, and M. Wahl, "Lightweight Directory
               Access Protocol (v3): Extension for Transport Layer
               Security", RFC 2830, May 2000.

  [RFC3296]    K. Zeilenga, "Named Subordinate References in Lightweight
               Directory Access Protocol (LDAP) Directories", RFC 3296,
               July 2002.

  [SUBENTRY]   K. Zeilenga, S. Legg, "Subentries in LDAP",
               draft-zeilenga-ldap-subentry-xx.txt, a work in progress.

  [X.680]      ITU-T, "Abstract Syntax Notation One (ASN.1) -
               Specification of Basic Notation", X.680, 1994.

  [X.690]      ITU-T, "Specification of ASN.1 encoding rules:  Basic,
               Canonical, and Distinguished Encoding Rules", X.690,
               1994.

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

  [UUID]       International Organization for Standardization (ISO),
               "Information technology - Open Systems Interconnection -
               Remote Procedure Call", ISO/IEC 11578:1996.


10. Informative References

  [RFC3383]  K. Zeilenga, "IANA Considerations for LDAP", BCP 64 (also
               RFC 3383), September 2002.

  [RFC3384]    E. Stokes, et. al., "LDAPv3 Replication Requirements",
               RFC3384, October 2002.

  [X.511]      ITU, "The Directory: Abstract Service Definition", ITU-T
               Rec. X.511, 1993.

  [X.525]      ITU, "The Directory: Replication", ITU-T Rec. X.525,
               1993.

  [COLLECTIVE] K. Zeilenga, "Collective Attributes in LDAP",
               draft-zeilenga-ldap-collective-xx.txt, a work in
               progress.

  [DIRSYNC]    M. Armijo, "Microsoft LDAP Control for Directory



Zeilenga               LDAP Content Sync Operation             [Page 17]


INTERNET-DRAFT         draft-zeilenga-ldup-sync-00       28 October 2002


               Synchronization", draft-armijo-ldap-dirsync-xx.txt, a
               work in progress.

  [LCUP]       R. Megginson, et. al., "LDAP Client Update Protocol",
               draft-ietf-ldup-lcup-xx.txt, a work in progress.

  [PSEARCH]    M. Smith, et. al., "Persistent Search: A Simple LDAP
               Change Notification Mechanism",
               draft-ietf-ldapext-psearch-xx.txt, a work in progress.

  [TSEARCH]    M. Wahl, "LDAPv3 Triggered Search Control",
               draft-ietf-ldapext-trigger-xx.txt, a work in progress.


10. Authors' Address

  Kurt D. Zeilenga
  OpenLDAP Foundation
  <Kurt@OpenLDAP.org>

  Jonghyuk Choi
  IBM Corporation
  <jongchoi@us.ibm.com>


Appendix A.  A state-based implementation approach

  This appendix is informative.  Content TBD.


Copyright 2002, The Internet Society.  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 English.

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




Zeilenga               LDAP Content Sync Operation             [Page 18]


INTERNET-DRAFT         draft-zeilenga-ldup-sync-00       28 October 2002


  This document and the information contained herein is provided on an
  "AS IS" basis and THE AUTHORS, 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.













































Zeilenga               LDAP Content Sync Operation             [Page 19]


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