rfc4533.txt

samba最新软件

Network Working Group                                        K. Zeilenga
Request for Comments: 4533                           OpenLDAP Foundation
Category: Experimental                                         J.H. Choi
                                                         IBM Corporation
                                                               June 2006


           The Lightweight Directory Access Protocol (LDAP)
                   Content Synchronization Operation

Status of This Memo

   This memo defines an Experimental Protocol for the Internet
   community.  It does not specify an Internet standard of any kind.
   Discussion and suggestions for improvement are requested.
   Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2006).

IESG Note

   The IESG notes that this work was originally discussed in the LDUP
   working group.  The group came to consensus on a different approach,
   documented in RFC 3928; that document is on the standards track and
   should be reviewed by those considering implementation of this
   proposal.

Abstract

   This specification describes the Lightweight Directory Access
   Protocol (LDAP) Content Synchronization Operation.  The operation
   allows a client to maintain a copy of a fragment of the Directory
   Information Tree (DIT).  It supports both polling for changes and
   listening for changes.  The operation is defined as an extension of
   the LDAP Search Operation.














Zeilenga & Choi               Experimental                      [Page 1]

RFC 4533         LDAP Content Synchronization Operation        June 2006


Table of Contents

   1. Introduction ....................................................3
      1.1. Background .................................................3
      1.2. Intended Usage .............................................4
      1.3. Overview ...................................................5
      1.4. Conventions ................................................8
   2. Elements of the Sync Operation ..................................8
      2.1. Common ASN.1 Elements ......................................9
      2.2. Sync Request Control .......................................9
      2.3. Sync State Control ........................................10
      2.4. Sync Done Control .........................................10
      2.5. Sync Info Message .........................................11
      2.6. Sync Result Codes .........................................11
   3. Content Synchronization ........................................11
      3.1. Synchronization Session ...................................12
      3.2. Content Determination .....................................12
      3.3. refreshOnly Mode ..........................................13
      3.4. refreshAndPersist Mode ....................................16
      3.5. Search Request Parameters .................................17
      3.6. objectName ................................................18
      3.7. Canceling the Sync Operation ..............................19
      3.8. Refresh Required ..........................................19
      3.9. Chattiness Considerations .................................20
      3.10. Operation Multiplexing ...................................21
   4. Meta Information Considerations ................................22
      4.1. Entry DN ..................................................22
      4.2. Operational Attributes ....................................22
      4.3. Collective Attributes .....................................23
      4.4. Access and Other Administrative Controls ..................23
   5. Interaction with Other Controls ................................23
      5.1. ManageDsaIT Control .......................................24
      5.2. Subentries Control ........................................24
   6. Shadowing Considerations .......................................24
   7. Security Considerations ........................................25
   8. IANA Considerations ............................................26
      8.1. Object Identifier .........................................26
      8.2. LDAP Protocol Mechanism ...................................26
      8.3. LDAP Result Codes .........................................26
   9. Acknowledgements ...............................................26
   10. Normative References ..........................................27
   11. Informative References ........................................28
   Appendix A.  CSN-based Implementation Considerations ..............29








Zeilenga & Choi               Experimental                      [Page 2]

RFC 4533         LDAP Content Synchronization Operation        June 2006


1.  Introduction

   The Lightweight Directory Access Protocol (LDAP) [RFC4510] provides a
   mechanism, the search operation [RFC4511], that allows a client to
   request directory content matching a complex set of assertions and to
   request that the server return this content, subject to access
   control and other restrictions, to the client.  However, LDAP does
   not provide (despite the introduction of numerous extensions in this
   area) an effective and efficient mechanism for maintaining
   synchronized copies of directory content.  This document introduces a
   new mechanism specifically designed to meet the content
   synchronization requirements of sophisticated directory applications.

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

1.1.  Background

   Over the years, a number of content synchronization approaches have
   been suggested for use in LDAP directory services.  These approaches
   are inadequate for one or more of the following reasons:

      -  failure to ensure a reasonable level of convergence;

      -  failure to detect that convergence cannot be achieved (without
         reload);

      -  require pre-arranged synchronization agreements;

      -  require the server to maintain histories of past changes to DIT
         content and/or meta information;

      -  require the server to maintain synchronization state on a per-
         client basis; and/or

      -  are overly chatty.

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

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





Zeilenga & Choi               Experimental                      [Page 3]

RFC 4533         LDAP Content Synchronization Operation        June 2006


   The Sync Operation does not require that servers maintain or use any
   history of past changes to the DIT or to meta information.  However,
   servers may maintain and use histories (e.g., change logs,
   tombstones, DIT snapshots) to reduce the number of messages generated
   and to reduce their size.  As it is not always feasible to maintain
   and use histories, the operation may be implemented using purely
   (current) state-based approaches.  The Sync Operation allows use of
   either the state-based approach or the history-based approach on an
   operation-by-operation basis to balance the size of history and the
   amount of traffic.  The Sync Operation also allows the combined use
   of the state-based and the history-based approaches.

   The Sync Operation does not require that servers maintain
   synchronization state on a per-client basis.  However, servers may
   maintain and use per-client state information to reduce the number of
   messages generated and the size of such messages.

   A synchronization mechanism can be considered overly chatty when
   synchronization traffic is not reasonably bounded.  The Sync
   Operation traffic is bounded by the size of updated (or new) entries
   and the number of unchanged entries in the content.  The operation is
   designed to avoid full content exchanges, even when the history
   information available to the server is insufficient to determine the
   client's state.  The operation is also designed to avoid transmission
   of out-of-content history information, as its size is not bounded by
   the content and it is not always feasible to transmit such history
   information due to security reasons.

   This document includes a number of non-normative appendices providing
   additional information to server implementors.

1.2.  Intended Usage

   The Sync Operation is intended to be used in applications requiring
   eventually-convergent content synchronization.  Upon completion of
   each synchronization stage of the operation, all information to
   construct a synchronized client copy of the content has been provided
   to the client or the client has been notified that a complete content
   reload is necessary.  Except for transient inconsistencies due to
   concurrent operation (or other) processing at the server, the client
   copy is an accurate reflection of the content held by the server.
   Transient inconsistencies will be resolved by subsequent
   synchronization operations.








Zeilenga & Choi               Experimental                      [Page 4]

RFC 4533         LDAP Content Synchronization Operation        June 2006


   Possible uses include the following:

      -  White page service applications may use the Sync Operation to
         maintain a current copy of a DIT fragment, for example, a mail
         user agent that uses the sync operation to maintain a local
         copy of an enterprise address book.

      -  Meta-information engines may use the Sync Operation to maintain
         a copy of a DIT fragment.

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

      -  Lightweight master-slave replication between heterogeneous
         directory 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 [X.500] Information Shadowing Protocol (DISP)
         [X.525], which may be used for master-slave replication between
         directory servers.  Other experimental LDAP replication
         protocols also exist.)

   This protocol is not intended to be used in applications requiring
   transactional data consistency.

   As this protocol transfers all visible values of entries belonging to
   the content upon change instead of change deltas, this protocol is
   not appropriate for bandwidth-challenged applications or deployments.

1.3.  Overview

   This section provides an overview of basic ways the Sync Operation
   can be used to maintain a synchronized client 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 client 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) the content matching the search criteria (baseObject,
   scope, filter, attributes).  Additionally, with each entry returned,
   the server provides a Sync State Control indicating state add.  This
   control contains the Universally Unique Identifier (UUID) [UUID] of



Zeilenga & Choi               Experimental                      [Page 5]

RFC 4533         LDAP Content Synchronization Operation        June 2006


   the entry [RFC4530].  Unlike the Distinguished Name (DN), which may
   change over time, an entry's UUID is stable.  The initial content is
   followed by a SearchResultDone with a Sync Done Control.  The Sync
   Done Control provides a syncCookie.  The syncCookie represents
   session state.

   To poll for updates to the client 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 were a normal search operation.
   However, using the syncCookie as an indicator of what content the
   client was sent previously, the server sends copies of entries that
   have changed with a Sync State Control indicating state add.  For
   each changed entry, all (modified or unmodified) attributes belonging
   to the content are sent.

   The server may perform either or both of the two distinct
   synchronization phases that are distinguished by how to synchronize
   entries deleted from the content: the present and the delete phases.
   When the server uses a single phase for the refresh stage, each phase
   is marked as ended by a SearchResultDone with a Sync Done Control.  A
   present phase is identified by a FALSE refreshDeletes value in the
   Sync Done Control.  A delete phase is identified by a TRUE
   refreshDeletes value.  The present phase may be followed by a delete
   phase.  The two phases are delimited by a refreshPresent Sync Info