INTERNET-DRAFT Kurt D. Zeilenga Intended Category: Informational OpenLDAP Foundation Expires in six months Jonghyuk Choi IBM Corporation 3 March 2003 LDAP Content Synchronization Operation 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 . Please send editorial comments directly to the document editor at . 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 . The list of Internet-Draft Shadow Directories can be accessed at . Copyright 2003, 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-01 3 March 2003 Abstract This specification describes the LDAP (Lightweight Directory Access Protocol) Content Synchronization operation offering eventual-convergent data consistency. The operation allows a client to 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 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 approach which could be adapted for use in LCUP. 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 operations, LDAP does not provide an effective, efficient, synchronized shadow copy of content held in the Directory Information Tree (DIT). This document defines the LDAP Content Synchronization operation, or Zeilenga LDAP Content Sync Operation [Page 2] INTERNET-DRAFT draft-zeilenga-ldup-sync-01 3 March 2003 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 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: Zeilenga LDAP Content Sync Operation [Page 3] INTERNET-DRAFT draft-zeilenga-ldup-sync-01 3 March 2003 - 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 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) the content matching the search criteria (baseObject, scope, filter). Additionally, 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 Zeilenga LDAP Content Sync Operation [Page 4] INTERNET-DRAFT draft-zeilenga-ldup-sync-01 3 March 2003 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 indicator of what content the client was sent previously, the server sends copies of entries which have changed with a Sync State control indicating state add. For each unchanged entry, the server sends an empty entry (e.g., no attributes) with a Sync State control indicating 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 unchanged entries not identified as being present are deleted entries from the synchronization content. They are either deleted, moved, or scoped-out from the content. 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 updates of changed entries in the content. By selecting the refreshAndPersist mode, the client requests the server to send updates of entries that are changed after the the initial refresh content is determined. 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 phase. After receipt of this Sync Info message, the client will have 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-01 3 March 2003 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 Sync Intermediate Response messages; and a searchResultDone message with a Sync Done control. As all DSEs of the content are treated as normal entries, no SearchResultReference messages are returned in respone to a Sync Operation request. 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.]] Zeilenga LDAP Content Sync Operation [Page 6] INTERNET-DRAFT draft-zeilenga-ldup-sync-01 3 March 2003 2.1 Common ASN.1 elements syncUUID ::= OCTET STRING 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 messages. Zeilenga LDAP Content Sync Operation [Page 7] INTERNET-DRAFT draft-zeilenga-ldup-sync-01 3 March 2003 2.4 Sync Done Control 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. The criticality is FALSE (and hence absent). 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 Zeilenga LDAP Content Sync Operation [Page 8] INTERNET-DRAFT draft-zeilenga-ldup-sync-01 3 March 2003 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. The mode is either refreshOnly or refreshAndPersist. The refreshOnly and refreshAndPersist modes are discussed in Section 3.3 and 3.4, respectively. The refreshOnly mode consists only of a refresh stage, while the refreshAndPersist mode consists of a refresh stage and a subsequent persist stage. 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. All DSEs of the content are treated as normal entries (as if the ManageDsaIT control [RFC3296] is specified). Servers SHOULD support synchronization for all non-collective Zeilenga LDAP Content Sync Operation [Page 9] INTERNET-DRAFT draft-zeilenga-ldup-sync-01 3 March 2003 user-applications attributes for all entries. If the content is not held by the server, a referral may be returned. 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. 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 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. The searchResultDone message SHALL include a Sync Done control. A resultCode value of success indicates the operation successfully completed. Otherwise, the result code indicates 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 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 syncRefreshRequired, d) return a resultCode other than success or syncRefreshRequired. Zeilenga LDAP Content Sync Operation [Page 10] INTERNET-DRAFT draft-zeilenga-ldup-sync-01 3 March 2003 For each entry added to the content or was changed since the previous Sync operation indicated by the cookie, the server return searchResultEntry 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. 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. No messages are sent for entries 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.3 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 entries 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-01 3 March 2003 Where DIT updates cause an entry to be added to the content, the server provides a searchResultEntry message which represents the entry as it 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 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. 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 provided in the Sync State control as the primary keys to entries. The client MUST use these entryUUIDs to correlate synchronization messages. 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].... Zeilenga LDAP Content Sync Operation [Page 12] INTERNET-DRAFT draft-zeilenga-ldup-sync-01 3 March 2003 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 Sync, the server returns the resultCode of syncRefreshRequired to the client to indicate that the client needs to issue a full reload 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 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 Zeilenga LDAP Content Sync Operation [Page 13] INTERNET-DRAFT draft-zeilenga-ldup-sync-01 3 March 2003 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 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 make 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 syncRefreshRequired or treat the Sync Operation as an initial content request (e.g., ignore the cookie). Zeilenga LDAP Content Sync Operation [Page 14] INTERNET-DRAFT draft-zeilenga-ldup-sync-01 3 March 2003 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 The ManageDsaIT control [RFC3296] indicates that the operation acts upon the DSA Information Tree and causes referral and other special objects to be treated as normal objects with respect to the operation. As such DSEs in the content are treated as normal entries, the presence (or absence) of the ManageDsaIT only impacts determining which content is to be sychronized. That is, the presence (or absence) of the ManageDsaIt impacts the search "finding" phase of the operation as discussed in [RFC3296]. 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. 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. Zeilenga LDAP Content Sync Operation [Page 15] INTERNET-DRAFT draft-zeilenga-ldup-sync-01 3 March 2003 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. [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) - Zeilenga LDAP Content Sync Operation [Page 16] INTERNET-DRAFT draft-zeilenga-ldup-sync-01 3 March 2003 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 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 Zeilenga LDAP Content Sync Operation [Page 17] INTERNET-DRAFT draft-zeilenga-ldup-sync-01 3 March 2003 Kurt D. Zeilenga OpenLDAP Foundation Jonghyuk Choi IBM Corporation Appendix A. A state-based implementation approach This appendix is informative. Content TBD. Copyright 2003, 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. 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 18]