Internet Draft R. Megginson, Editor Document: <draft-natkovich-ldap-lcup-02.txt> O. Natkovich Category: Proposed Standard M. Smith Netscape Communications Corp. M. Armijo Microsoft Corporation December 2000 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 LDUP replication protocol [LDUPPROT] should be used for this purpose. Several features of the protocol distinguish it from LDUP replication. First, the server does not maintain any state information on behalf of its clients. The clients are responsible for storing the information about how up to date they are with respect to the server's content. Second, no predefined agreements exist between the clients and the servers. The client decides when and from where to retrieve the changes. Finally, the server never pushes the data to the client; the client always initiates the update session during which it pulls the changes from the server. The set of clients that are allowed to synchronize with an LDAP server is determined by the server defined policy. There are, currently, several protocols available for LDAP client server synchronization. While each protocol addresses the needs of a particular group of clients (on-line clients in case of Persistent [PSEARCH] and Triggered [TSEARCH] Search, off-line clients in case of DirSync [DIRSYNC]), 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 above protocols. 4. Protocol Specification This section describes the protocol elements and the protocol flow. 4.1 Client Update Control Value A client initiates a synchronization session with a server by attaching a clientUpdate control to a search operation. 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: ClientUpdateControlValue ::= SEQUENCE{ cookie OCTET STRING OPTIONAL, keepConnection BOOLEAN DEFAULT FALSE, changesOnly BOOLEAN DEFAULT FALSE } cookie - an opaque cookie that represents the current state of the client's data. keepConnection - if set to TRUE, indicates that the server should keep the connection open after the initial synchronization and should notify the client of modifications to the data. The connection should stay open until the client abandons the search operation, sends the stopClientUpdate extended operation, or closes the connection. The draft will refer to this type of operation as persistent. If set to FALSE, this indicates that the server will not notify the client of modifications to the data and that the connection should stay open until the client abandons the search operation, sends the stopClientUpdate extended operation, or closes the connection. changesOnly - if set to TRUE, the keepConnection and cookie fields of the control are ignored by the server. In response, the server skips the initial synchronization and only notifies the client about the changes that occur to the data while the client is connected. This feature is useful if the client is not interested in data synchronization but needs to trigger events in response to data modifications. keepConnection changesOnly Action value value FALSE FALSE The server sends all the data needed to synchronize with the client then closes the connection. (synchronize only) TRUE FALSE Same as above, but the server leaves open the connection and sends over any new added, modified, or deleted entries which satisfy the search criteria. (synchronize and persist) FALSE or TRUE TRUE 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 which satisfy the search criteria. (persist only) 4.2 Entry Update Control Value In response to the client's synchronization request, the server returns a set of SearchResultEntries that fits the client's specification. 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 a valid uniqueid 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 cookie is also provided in the entryUpdate control. 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{ cookie OCTET STRING OPTIONAL, stateUpdate BOOLEAN DEFAULT FALSE, entryDeleted BOOLEAN DEFAULT FALSE } cookie - an opaque cookie that represents the current state of the client's data. 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 WILL contain the updated cookie. This feature allows updating the client's cookie when there is no changes that effect the client's data store. Note that the control MUST be attached to a valid SearchResultEntry, i.e. the entry should contain a valid dn. The server MAY send the entry at the root of the client's tree. entryDeleted - if set to TRUE, indicates that the entry to which the control is attached was deleted. 4.3 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. 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{ reason INTEGER, reasonText LDAPString, cookie OCTET STRING OPTIONAL } reason - reason for terminating the operation. Currently supported values are lcupSuccess (0) the operation was successfully processed lcupResourcesExhausted (1) the server is running out of resource lcupSecurityViolation (2) the client is suspected of malicious actions lcupInvalidCookie (3) invalid cookie was supplied by the client lcupClientDisconnect (4) client requested search termination lcupReloadRequired (5) 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 that the server's data was reloaded since the last synchronization session reasonText - may optionally contain a textual explanation of the error returned in the reason field of the control. cookie - an opaque cookie that represents the current state of the client's data. 4.4 Stop Client Update Request and Response The Stop Client Update operation is an LDAPv3 Extended Operation [RFC2251, Section 4.12] and is identified by the OBJECT IDENTIFIER stopClientUpdateOID (to be assigned). This section details the syntax of the protocol. 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 a stopClientUpdateRequest extended operation. The operation carries no data. The server responds with a stopClientUpdateResponse extended operation that also carries no data followed by SearchResultDone with clientUpdateDone control attached. The stopClientUpdateResponse is sent only to satisfy LDAP requirement that every server must issue an extended response for each extended request it receives. If the client is not interested in the state information, it can simply abandon the search operation or disconnect from the server. If server resources become tight, the server can terminate one or more search operations by sending a SearchResultDone message to the client(s). Unless the client sets the changesOnly field to TRUE, the server attaches a clientUpdateDone control that contains the cookie that corresponds to the current state of the client's data and the reload flag set to FALSE. 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. The stopClientUpdate extended operation indicates that the initiator wishes to terminate the current update operation. An LDAPv3 Extended Request is defined in [LDAPv3] as follows: ExtendedRequest ::= [APPLICATION 23] SEQUENCE { requestName [0] LDAPOID, requestValue [1] OCTET STRING OPTIONAL } The requestName portion of the stopClientUpdate must be the OID stopClientUpdateOID <TO BE DETERMINED>. The requestValue is ignored. 4.5 Protocol Flow The client server interaction can proceed in three different ways depending on the client's requirements. If the client's intent is not to synchronize data but to trigger actions in response to directory modifications, the protocol proceeds as follows: 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 changesOnly field of the control should be set to TRUE; other fields are ignored. S->C Sends change notification to the client for each change to the data within the client's search specification. 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 clientUpdateDone control attached. The control contains the reason field set to lcupResourcesExhausted or lcupSecurityViolation depending on the reason for termination. The server MAY provide more details to the client via the reasonText field of the control. 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 Abandons the search operation or disconnects from the server. 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 does not provide a cookie; otherwise, the cookie field of the control is set to the cookie received from the server at the end of the last synchronization session. (Note that the client can synchronize with different servers during different synchronization sessions.) The keepConnection and changesOnly fields are set to FALSE. S->C If no cookie is specified in the clientUpdate control, 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 and the reason flag set to lcupSuccess. If an invalid cookie is specified the server sends. SearchResultDone message with clientUpdateDone control attached. The reason field of the control is set to lcupInvalidCookie and the reasonText field MAY contain explanation of the error. 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 an SearchResultDone message with clientUpdateDone control attached. The reason field of the control is set to lcupReloadRequired and the reasonText field MAY contain explanation of the error. If the client is up to date, the server sends a success response to the client. 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 is 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, 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 reason field of the control is set to lcupSuccess. C->S If the reason field of the control 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. Otherwise, the client stores the cookie received from the server until the next synchronization session. If the client's intent is to be synchronized with the server and stay notified about data modifications, the protocol proceeds as follows: C->S The client behaves exactly as in the previous case except it sets the keepConnection control field to TRUE. 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 clientUpdateDone control attached. The control contains the reason field set to lcupResourcesExhausted or lcupSecurityViolation depending on the reason for termination. The server MAY provide more details to the client via the reasonText field of the control. 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 a stopClientUpdateRequest extended operation to the server to terminate the synchronization session. S->C Responds with a stopClientUpdateResponse extended operation followed by a SearchResultDone with the clientUpdateDone control attached. The control contains the cookie that represents the current state of the client's data. The reason field of the control is set to lcupReloadRequired. 4.6 Size and Time Limits The search request size or the time limits can only be imposed for non-persistent operations, those that set keepConnection field of the clientUpdateControlValue to FALSE. All other operations MUST set both limits to 0. The server SHOULD ignore the limits set for persistent operations. 4.7 Changes vs. Operations Since the server sends to the client the modified entries rather than the operations, a MODDN operation performed on a subtree will be seen by the client as a sequence of added or modified entries depending on whether the operation moved the entries into the scope of the client's search specification. 4.8 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. 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. 5.0 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 implementing 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 Change Type This feature is present in the Triggered Search [TSEARCH] 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 set for one of the reasons defined in section 4 above, - leftSet: the entry left the result set for one of the reasons defined in section 4 above, - 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 Sending Changes The DirSync protocol [DIRSYNC] sends 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. 5.3 Data Size Limits The DirSync protocol [DIRSYNC] allows clients to control the amount of data sent to them in the search response. The client can specify the number of bytes it is willing to receive by setting the maxReturnLength field of the DirSync control. This feature is 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 LCUP protocol will be implemented by regular LDAP clients that can deal with the limitations of the LDAP protocol. 5.4 Data Ordering The DirSync protocol [DIRSYNC] allows 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. Comments from M. Armijo: " Although I appreciate the difficulty in implementing this, I believe we need to at least make it an option. If we do not, we will need to define how clients handle issues where changes are received out of order (stub entries, etc.) At the very least we should define that the server must not return a cookie until all parents involved in a series of operations have been returned (does that make sense or should I reword it?). I am concerned that a client can disconnect and be in what it considers to be a 'valid' state while it's own DIT is no longer valid." 6. The Protocol and the LDUP Architecture The LDAP Client Update Protocol is defined within the framework of the LDUP Architecture [LDUPARCH]. The following aspects of the protocol are drawn from the architecture: - The scope of each search operation is restricted to a single replica as defined in the LDUP architecture document [LDUPARCH]. - Each entry returned to the client contains a unique identifier as defined in the LDUP architecture document [LDUPARCH]. The client can use the identifier to unambiguously cross reference objects stored on the server with those in the client's store. - One of the main criteria for selecting the protocol features is that an LDUP compliant server can implement these features efficiently. 7. Client Side Considerations There are several issues that the implementors of a synchronization client need to consider: - 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. If this condition occurs, the client can attempt to locate the root by using the root's uniqueid 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 uniqueid rather then 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 practical. - The client may receive a referral or a continuation reference. How should this be handled? 8. Server Implementation Considerations By design, the protocol does not specify the format of the cookie. 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 the iPlanet Directory Server (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. 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. An implementation must be able to notify the client about all entries deleted since the last implementation session. 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. 9. Synchronizing Heterogeneous Data Stores Clients synchronizing multiple writeable data stores, like iPlanet Meta Directory, will only work correctly if each piece of information is single mastered (for instance, only by an LDUP compliant directory or only by Oracle). 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. 10. 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. 11. References [KEYWORDS] S. Bradner, "Keywords for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [PSEARCH] M. Smith "A Simple LDAP Change Notification Mechanism", INTERNET-DRAFT <draft-ietf-ldapext-psearch-01.txt>, August 1998. [TSEARCH] M.Wahl "LDAPv3 Triggered Search Control", INTERNET-DRAFT <draft-ietf-ldapext-trigger-01.txt>, August 1998. [DIRSYNC] M. Armijo "Microsoft LDAP Control for Directory Synchronization", INTERNET-DRAFT <draft-armijo-ldap- dirsync-00.txt>, August 1999. [LDUPARCH] J. Merrells, E. Reed, U. Srinivasan, "LDAP Replication Architecture", INTERNET-DRAFT <draft-ietf-ldup-model- 02.txt>, October 1999. [LDUPPROT] E. Stokes, G. Good "The LDUP Replication Update Protocol", INTERNET-DRAFT <draft-ietf-ldup-protocol- 00.txt>, October 1999. 12. Author's Addresses Rich Megginson Netscape Communications Corp. 901 San Antonio Rd. Palo Alto, CA 94303-4900 Mail Stop SCA17 - 201 Phone: +1 408 276-3752 Email: richm@netscape.com Olga Natkovich Netscape Communications Corp. 901 San Antonio Rd. Palo Alto, CA 94303-4900 Mail Stop SCA17 - 201 Phone: +1 408 276-4357 Email: olga@netscape.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 Michael P. Armijo Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399 Phone: +1 425 882-8080 Email: micharm@Exchange.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 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 Since the last version of the draft, the following changes have been made: _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.