idnits 2.17.1 draft-ietf-ldup-lcup-03.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document is more than 15 pages and seems to lack a Table of Contents. == There is 1 instance of lines with non-ascii characters in the document. == The page length should not exceed 58 lines per page, but there was 21 longer pages, the longest (page 2) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 7 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: Megginson, et. al. Proposed Standard - Expires: December 2002 5 entry. To represent a deleted entry, the server attaches an entryUpdate control to the corresponding SearchResultEntry. The SearchResultEntry corresponding to a deleted entry MUST contain a valid DN and SHOULD contain a valid UUID but, to reduce the amount of data sent to the client, it SHOULD not contain any other attributes. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 2002) is 7957 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 18 == Missing Reference: 'LDUP' is mentioned on line 81, but not defined == Unused Reference: 'RFC2251' is defined on line 919, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2251 (Obsoleted by RFC 4510, RFC 4511, RFC 4512, RFC 4513) ** Obsolete normative reference: RFC 2252 (Obsoleted by RFC 4510, RFC 4512, RFC 4517, RFC 4523) -- No information found for draft-zeilenga-ldap-cancel-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'CANCEL' Summary: 9 errors (**), 0 flaws (~~), 5 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft R. Megginson, Editor 3 Document: M. Smith 4 Category: Proposed Standard Netscape 5 Communications Corp. 6 O. Natkovich 7 Yahoo 8 J. Parham 9 Microsoft Corporation 10 June 2002 12 LDAP Client Update Protocol 14 Status of this Memo 16 This document is an Internet-Draft and is in full conformance with 17 all provisions of Section 10 of RFC2026 [1]. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six 25 months and may be updated, replaced, or obsoleted by other documents 26 at any time. It is inappropriate to use Internet- Drafts as 27 reference material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet- 31 Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 1. Abstract 36 This document defines the LDAP Client Update Protocol (LCUP). The 37 protocol is intended to allow an LDAP client to synchronize with the 38 content of a directory information tree (DIT) stored by an LDAP 39 server and to be notified about the changes to that content. 41 2. Conventions used in this document 43 In the protocol flow definition, the notation C->S and S->C 44 specifies the direction of the data flow from the client to the 45 server and from the server to the client respectively. 47 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 48 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 49 this document are to be interpreted as described in RFC-2119 50 [KEYWORDS]. 52 3. Overview 53 The LCUP protocol is intended to allow LDAP clients to synchronize 54 with the content stored by LDAP servers. 56 The problem areas addressed by the protocol include: 58 - mobile clients that maintain a local read-only copy of the 59 directory data. While off-line, the client uses the local copy of 60 the data. When the client connects to the network, it 61 synchronizes with the current directory content and can be 62 optionally notified about the changes that occur while it is on- 63 line. For example, a mail client can maintain a local copy of the 64 corporate address book that it synchronizes with the master copy 65 whenever the client gets connected to the corporate network. 67 - applications intending to synchronize heterogeneous data stores. 68 A meta directory application, for instance, would periodically 69 retrieve a list of modified entries from the directory, construct 70 the changes and apply them to a foreign data store. 72 - clients that need to take certain actions when a directory entry 73 is modified. For instance, an electronic mail repository may want 74 to perform a "create mailbox" task when a new person entry is 75 added to an LDAP directory and a "delete mailbox" task when a 76 person entry is removed. 78 The problem areas not being considered: 80 - directory server to directory server synchronization. The IETF is 81 developing a LDAP replication protocol, called [LDUP], which is 82 specifically designed to address this problem area. 84 There are currently several protocols in use for LDAP client server 85 synchronization. While each protocol addresses the needs of a 86 particular group of clients (e.g., on-line clients or off-line 87 clients) none satisfies the requirements of all clients in the 88 target group. For instance, a mobile client that was off-line and 89 wants to become up to date with the server and stay up to date while 90 connected can't be easily supported by any of the existing 91 protocols. 93 Several features of the protocol distinguish it from LDUP 94 replication. LCUP is designed such that the server does not need to 95 maintain state information on behalf of the client. The clients are 96 responsible for storing the information about how up to date they 97 are with respect to the server's content. LCUP design avoids the 98 need for LCUP-specific update agreements to be made between client 99 and server prior to LCUP use. The client decides when and from where 100 to retrieve the changes. LCUP design requires clients to initiate 101 the update session and "pull" the changes from server. 103 LCUP operations are subject to administrative and access 104 control policies enforced by the server. 106 Megginson, et. al. Proposed Standard - Expires: December 2002 2 107 A part of the DIT which is enabled for LCUP is referred to as an 108 LCUP Context. A server may support one or more LCUP Contexts. 110 4. Protocol Specification 112 This section describes the protocol elements and the protocol flow. 114 4.1 Universally Unique Identifiers 116 Distinguished names can change, so are therefore unreliable 117 as identifiers. The server SHOULD assign a Universally Unique 118 Identifier (or UUID for short) to each entry as it is created. This 119 identifier will be stored as an operational attribute of the entry, 120 named `entryUUID'. The entryUUID attribute is single valued. A 121 consistent algorithm for generating such universally unique 122 identifiers may be standardized at some point in the future. 123 The definition of the entryUUID attribute type, written using the 124 BNF form of AttributeDescription described in RFC 2252 [RFC2252] is: 126 ( OID-To-Be-Specified 127 NAME `entryUUID' 128 DESC `universally unique entry identifier' 129 EQUALITY caseIgnoreMatch 130 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 131 SINGLE-VALUE 132 NO-USER-MODIFICATION 133 USAGE directoryOperation ) 135 4.2 LCUP Cookie Value 137 The LCUP protocol uses a cookie to hold the state of the client's 138 data with respect to the server's data. The LCUP Cookie is a value 139 of the following ASN.1 type: 141 LCUPCookie ::= SEQUENCE { 142 scheme LDAPOID, 143 value OCTET STRING OPTIONAL 144 } 146 scheme - this is the OID which identifies the format of the value. 147 The scheme OID, like all object identifiers, MUST be unique for a 148 given cookie scheme. The cookie value may be opaque or it may be 149 exposed to LCUP clients. For cookie schemes that expose their 150 value, the preferred form of documentation is an RFC. It is 151 expected that there will be one or more standards track cookie 152 schemes where the value format is exposed and described in detail. 154 value - this is the actual data describing the state of the 155 client's data. This value may be opaque, or its value may have 156 some well-known format, depending on the scheme. The cookie value 157 MUST be included except when a client has no stored state; i.e., 158 when the client is requesting a full synchronization. When the 159 server sends back a cookie, the cookie value MUST be present. 161 Megginson, et. al. Proposed Standard - Expires: December 2002 3 162 Further uses of the LCUP Cookie value are described below. 164 4.3 Additional LDAP Result Codes defined by LCUP 166 The LDAP result code names and numbers defined in the following 167 table are to be replaced with IANA assigned result code names and 168 numbers per draft-ietf-ldapbis-iana-xx.txt. 170 lcupResourcesExhausted (TBD) the server is running out of 171 resources 172 lcupSecurityViolation (TBD) the client is suspected of malicious 173 actions 174 lcupInvalidCookie (TBD) invalid cookie was supplied by the 175 client - both/either the scheme 176 and/or the value part was invalid 177 lcupUnsupportedScheme (TBD) The scheme part of the cookie is a 178 valid OID but is not supported by 179 this server 180 lcupClientDisconnect (TBD) client requested search termination 181 using the LDAP Cancel extended 182 operation request [CANCEL] 183 lcupReloadRequired (TBD) indicates that client data needs to 184 be reinitialized. This reason is 185 returned if the server does not 186 contain sufficient information to 187 synchronize the client or if the 188 server's data was reloaded since the 189 last synchronization session 191 The uses of these codes are described below. 193 4.4 Client Update Control Value 195 A client initiates a synchronization session with a server by 196 attaching a clientUpdate control to an LDAP searchRequest message. 197 The client SHOULD specify entryUUID in the attributes list in the 198 searchRequest message. The search specification determines the part 199 of the directory information tree (DIT) the client wishes to 200 synchronize with, the set of attributes it is interested in and the 201 amount of data the client is willing to receive. The clientUpdate 202 control contains the client's synchronization specification. The 203 controlType field for the clientUpdate control is 204 ClientUpdateControlOID (to be assigned). The controlValue is an 205 OCTET STRING, whose contents are the bytes of the BER encoding of 206 the following: 208 Megginson, et. al. Proposed Standard - Expires: December 2002 4 209 ClientUpdateControlValue ::= SEQUENCE { 210 updateType ENUMERATED { 211 synchronizeOnly (0), 212 synchronizeAndPersist (1), 213 persistOnly (2) }, 214 sendCookieInterval INTEGER OPTIONAL, 215 cookie LCUPCookie OPTIONAL 216 } 218 updateType - specifies the type of update requested by the client 220 synchronizeOnly - the server sends all the data needed to 221 synchronize the client with the server, then closes the 222 connection 224 synchronizeAndPersist - the server sends all the data needed to 225 synchronize the client with the server, then leaves open the 226 connection, sending to the client any new added, modified, or 227 deleted entries that satisfy the search criteria. 229 persistOnly - the server does not synchronize the data with the 230 client but leaves open the connection and sends over any new 231 added, modified, or deleted entries that satisfy the search 232 criteria. 234 sendCookieInterval � (optional) the server SHOULD send the cookie 235 back in the entryUpdate control value for every 236 sendCookieInterval number of SearchResultEntry PDUs returned to 237 the client. For example, if the value is 5, the server SHOULD 238 send the cookie back in the entryUpdate control value for every 5 239 search results returned to the client. If this value is absent, 240 zero or less than zero, the server chooses the interval. 242 cookie - a value that represents the current state of the client's 243 data. If a cookie is provided, the server MUST use the enclosed 244 scheme throughout the duration of the LCUP session or until an 245 LCUP context boundary is crossed, since a new cookie may be 246 required in that case. If the value or scheme part of the cookie 247 is invalid, the server MUST return immediately with a 248 SearchResultDone message with the resultCode set to the value of 249 lcupInvalidCookie. If the scheme part of the cookie is a valid 250 OID, but is not supported, the server MUST return immediately 251 with a SearchResultDone message with the resultCode set to the 252 value of lcupUnsupportedScheme. 254 If the cookie is omitted, the server MAY use any scheme it 255 supports. 257 4.5 Entry Update Control Value 259 In response to the client's synchronization request, the server 260 returns one or more SearchResultEntry PDU that fits the client's 261 specification. Each SearchResultEntry PDU also contains an 262 entryUpdateControl that describes the LCUP state of the returned 264 Megginson, et. al. Proposed Standard - Expires: December 2002 5 265 entry. To represent a deleted entry, the server attaches an 266 entryUpdate control to the corresponding SearchResultEntry. The 267 SearchResultEntry corresponding to a deleted entry MUST contain a 268 valid DN and SHOULD contain a valid UUID but, to reduce the amount 269 of data sent to the client, it SHOULD not contain any other 270 attributes. 272 Furthermore, the server may elect to periodically return to the 273 client the cookie that represents the state of the client's data. 274 This information is useful in case the client crashes or gets 275 disconnected. The client MAY specify how often to receive the cookie 276 by the use of the sendCookieInterval in the clientUpdate control 277 value (see above). If the client does not specify a value, the 278 server will determine the interval. 280 The controlType field for the entryUpdate control is 281 EntryUpdateControlOID (to be assigned). The controlValue is an 282 OCTET STRING, whose contents are the bytes of the BER encoding of 283 the following: 285 EntryUpdateControlValue ::= SEQUENCE { 286 stateUpdate BOOLEAN, 287 entryDeleted BOOLEAN, 288 cookie LCUPCookie OPTIONAL 290 } 292 stateUpdate - if set to TRUE, indicates that the entry to which the 293 control is attached contains no changes and it is sent only to 294 communicate to the client the new cookie. In this case, the 295 entryDeleted field MUST be ignored and the cookie field MUST 296 contain the updated cookie. This feature allows updating the 297 client's cookie when there are no changes that effect the 298 client's data store. Note that the control MUST be attached to a 299 valid SearchResultEntry, which should contain a valid LDAPDN in 300 the objectName field, and MAY contain an entryUUID attribute, but 301 SHOULD NOT contain any other attributes. The server MAY send the 302 entry named by the baseObject from the client's search request. 304 entryDeleted - if set to TRUE, indicates that the entry to which 305 the control is attached was deleted. The server MAY also set 306 this to TRUE if the entry has left the client's search result 307 set. As far as the client is concerned, a deleted entry is no 308 different than an entry that has left the result set. 310 cookie - the LCUP cookie value that represents the current state of 311 the client's data. 313 4.6 Client Update Done Control Value 315 When the server has finished processing the client's request, it 316 attaches a clientUpdateDone control to the SearchResultDone message 317 and sends it to the client. However, if the SearchResultDone message 318 contains a resultCode that is not success or lcupClientDisconnect, 320 Megginson, et. al. Proposed Standard - Expires: December 2002 6 321 the clientUpdateDone control MAY be omitted. The controlType field 322 for the clientUpdateDone control is ClientUpdateDoneControlOID (to 323 be assigned). The controlValue is an OCTET STRING, whose contents 324 are the bytes of the BER encoding of the following: 326 ClientUpdateDoneControlValue ::= SEQUENCE { 327 cookie LCUPCookie OPTIONAL 328 } 330 cookie - the LCUP cookie value that represents the current state of 331 the client's data. Although this value is OPTIONAL, it MUST be set 332 in the ClientUpdateDoneControlValue if the SearchResultDone 333 resultCode is success or lcupClientDisconnect. This provides a 334 good "checksum" of what the server thinks the state of the client 335 is. If some error occurred, either an LDAP search error (e.g. 336 insufficientAccessRights) or an LCUP error (e.g. 337 lcupUnsupportedScheme), the cookie MAY be omitted. 339 If server resources become tight, the server can terminate one or 340 more search operations by sending a SearchResultDone message to the 341 client(s) with a resultCode of lcupResourcesExhausted. Unless the 342 client sets the updateType field to persistOnly, the server attaches 343 a clientUpdateDone control that contains the cookie that corresponds 344 to the current state of the client's data. A server set policy is 345 used to decide which searches to terminate. This can also be used as 346 a security mechanism to disconnect clients that are suspected of 347 malicious actions, but if the server can infer that the client is 348 malicious, the server should return lcupSecurityViolation instead. 350 4.7 Client Initiated Termination 352 If the client needs to terminate the synchronization process and it 353 wishes to obtain the cookie that represents the current state of its 354 data, it issues an LDAP Cancel operation [CANCEL]. The server 355 responds immediately with a LDAP Cancel response [CANCEL]. The 356 server MAY send any pending SearchResultEntry PDUs if the server 357 cannot easily abort or remove those search results from its outgoing 358 queue. The server SHOULD send as few of these remaining 359 SearchResultEntry PDUs as possible. Finally, the server sends the 360 message SearchResultDone with the clientUpdateDone control attached. 362 If the client is not interested in the state information, it can 363 simply abandon the search operation or disconnect from the server. 365 4.8 Protocol Flow 367 The client server interaction can proceed in three different ways 368 depending on the client's requirements. Protocol flows beginning 369 with an asterisk (*) are optional or conditional. 371 If the client's intent is not to synchronize data but to trigger 372 actions in response to directory modifications, the protocol 373 proceeds as follows: 375 Megginson, et. al. Proposed Standard - Expires: December 2002 7 376 C->S Sends a search operation with a clientUpdate control attached. 377 The search specification determines the part of the DIT the 378 client wishes to synchronize with and the set of attributes it 379 is interested in. The updateType field of the control value 380 should be set to persistOnly. 381 *S->C If there is an error (invalid search scope, invalid cookie) 382 the server returns the appropriate error codes and terminates 383 the request (SearchResultDone message with optional 384 clientUpdateDone control) 385 S->C Sends change notification to the client for each change to the 386 data within the client's search specification. Each 387 SearchResultEntry may have an entryUpdate control attached. 388 *S->C If the server starts to run out of resources or the client is 389 suspected of malicious actions, the server SHOULD terminate 390 the search operation by sending to the client a 391 SearchResultDone message with optional clientUpdateDone 392 control attached. The resultCode in the SearchResultDone 393 mesasge SHOULD be set to lcupResourcesExhausted or 394 lcupSecurityViolation depending on the reason for termination. 395 *C->S If the client receives lcupResourcesExhausted error from the 396 server, it MUST wait for a while before attempting another 397 synchronization session with the server. It is RECOMMENDED 398 that clients use an exponential backoff strategy. 399 C->S The client terminates the search. The client can do this by 400 abandoning the search operation, disconnecting from the 401 server, or by sending an LDAP Cancel operation. 402 *S->C If the server receives the LDAP Cancel op, it will immediately 403 send back the LDAP Cancel response 404 *S->C If the server sent the LDAP Cancel response, the server MAY 405 send any pending SearchResultEntry PDUs in its outgoing queue 406 *S->C If the server sent the LDAP Cancel response, after the server 407 sends the response and any pending SearchResultEntry PDUs, the 408 server sends the SearchResultDone message with the 409 clientUpdateDone control attached. The resultCode in the 410 SearchResultDone message will be either lcupClientDisconnect 411 or some LDAP error code (not success). 412 S->C Stops sending changes to the client and closes the connection. 414 If the client's intent is to synchronize with the server and then 415 disconnect, the protocol proceeds as follows: 417 C->S Sends a search operation with the clientUpdate control 418 attached. The search specification determines the part of the 419 DIT the client wishes to synchronize with, the set of 420 attributes it is interested in and the amount of data the 421 client is willing to receive. If this is the initial 422 synchronization session, the client either does not provide a 423 cookie or provides a cookie with no value; otherwise, the 424 cookie field of the control is set to the cookie received from 425 the server at the end of the last synchronization session. If 426 the scheme field of the cookie was provided, the server MUST 427 use that scheme throughout the duration of the LCUP session or 428 until an LCUP boundary is crossed, since the server will 429 usually require a different cookie in that case anyway. (Note 431 Megginson, et. al. Proposed Standard - Expires: December 2002 8 432 that the client can synchronize with different servers during 433 different synchronization sessions.) The updateType field of 434 the control value is set to synchronizeOnly. 435 *S->C If there is an error (invalid search scope, invalid cookie) 436 the server returns the appropriate error codes and terminates 437 the request (SearchResultDone message with optional 438 clientUpdateDone control) 439 *S->C If no cookie is specified in the clientUpdate control, or if 440 the value field of the cookie is empty, the server sends all 441 data that matches the client's search specification followed 442 by the SearchResultDone message with a clientUpdateDone 443 control attached. The control contains the cookie that 444 corresponds to the current state of the client's data. If 445 synchronization was successful, the resultCode in the 446 SearchResultDone message should be success. 447 *S->C If an invalid cookie is specified, the server sends the 448 SearchResultDone message with the resultCode set to 449 lcupInvalidCookie. 450 *S->C If a valid cookie is specified and the data that matches the 451 search specification has been reloaded or the server does not 452 contain enough state information to synchronize the client, 453 the server sends a SearchResultDone message with the 454 resultCode set to lcupReloadRequired. 455 *S->C If the cookie is valid and the client is up to date, the 456 server sends a success response to the client. 457 S->C If the cookie is valid and there is data to be sent, the 458 server sends the modified entries to the client. Each 459 SearchResultEntry contains the attributes requested by the 460 client in the search specification regardless of whether they 461 were modified. An entryUpdate control with the entryDeleted 462 field set to TRUE MUST be attached to every deleted entry. The 463 server may also periodically attach an entryUpdate control to 464 the entries sent to the client to indicate the current state 465 of the client's data. In that case, the cookie field of the 466 control represents the state of the client's data including 467 the entry to which the control is attached. Once all the 468 changes are sent successfully, the server sends a 469 SearchResultDone with the clientUpdateDone control attached. 470 The control contains the cookie that represents the current 471 state of the client's data. The resultCode in the 472 SearchResultDone message is set to success. If the resultCode 473 is not success, the server may OPTIONALLY attach the 474 clientUpdateDone control to the SearchResultDone message. 475 The client stores the cookie received from the server until 476 the next synchronization session. 477 *C->S If the resultCode in the SearchResultDone message is set 478 lcupReloadRequired, the client clears its data store and 479 repeats the synchronization process by sending the search 480 operation with clientUpdate control that contains no cookie, 481 or that contains a cookie with no value field. 483 If the client's intent is to be synchronized with the server and 484 stay notified about data modifications, the protocol proceeds as 485 follows: 487 Megginson, et. al. Proposed Standard - Expires: December 2002 9 488 C->S The client behaves exactly as in the previous case except it 489 sets the updateType field in the control value to 490 synchronizeAndPersist. 491 S->C The server behaves exactly as in the previous case except the 492 connection is kept open after the initial set of changes is 493 sent to the client. A SearchResultDone message is not sent to 494 the client; instead, the server keeps sending changes to the 495 client. 496 *S->C If the server starts to run out of resources or the client is 497 suspected of malicious actions, the server SHOULD terminate 498 the search operation by sending to the client a 499 SearchResultDone message with the resultCode set to 500 lcupResourcesExhausted or lcupSecurityViolation depending on 501 the reason for termination. 502 *C->S If the client receives lcupResourcesExhausted error from the 503 server, it MUST wait for a while before attempting another 504 synchronization session with the server. We recommend 505 exponential backoff strategy. 506 C->S Sends an LDAP Cancel operation to the server to terminate the 507 synchronization session. 508 S->C Responds with an LDAP Cancel response, followed optionally by 509 SearchResultEntry PDUs, followed by a SearchResultDone with 510 the clientUpdateDone control optionally attached. If the 511 control is present, it contains the cookie that represents the 512 current state of the client's data. The value of the 513 resultCode in the SearchResultDone message will be either 514 lcupClientDisconnect or some other LDAPResult resultCode (not 515 success). The control may not be present if some error 516 occurred. 518 4.9 Size and Time Limits 520 The search request size or the time limits can only be imposed for 521 non-persistent operations, those that set the updateType field of 522 the ClientUpdateControlValue to synchronizeOnly (for the entire 523 operation) or synchronizeAndPersist (for the initial synchronization 524 phase only). All other operations MUST set both limits to 0. The 525 server SHOULD ignore the limits set for persistent operations. 527 4.10 Changes vs. Operations 529 A server that supports UUIDs SHOULD communicate a modifyDN 530 operation by sending the client the current form of the entry (with 531 its new DN) along with an entryUUID attribute. A server that does 532 not support UUIDs SHOULD communicate a modifyDN operation by sending 533 the client a deletion for the previous DN followed by an entry for 534 the new DN. Note that for servers that do not support UUIDs, no 535 guarantees are made about the correctness of the client state in the 536 presence of modifyDN operations. 538 Communicating modifyDN operations by sending a delete of the old DN 539 followed by an entry with the new DN makes it impossible for an LCUP 540 client to distinguish between a modifyDN operation, which is one 542 Megginson, et. al. Proposed Standard - Expires: December 2002 10 543 atomic operation, and an delete operation followed by an add of a 544 new entry. The loss of information about atomicity may cause 545 problems for some LCUP clients. For example, when an entry is 546 renamed, a client that manages resources such as a person's mailbox 547 might delete the mailbox and everything in it instead of merely 548 changing the name associated with the mailbox. 550 Also note that regardless of how a modifyDN operation is 551 communicated to the client, if the client state shows that the 552 object that underwent the modifyDN operation was the root of a 553 subtree, the client MUST infer that the DNs of all objects in the 554 subtree have changed such that they reflect the new DN of the 555 subtree root. 557 4.11 Operations on the Same Connection 559 It is permissible for the client to issue other LDAP operations on 560 the connection used by the protocol. Since each LDAP 561 request/response carries a message id there will be no ambiguity 562 about which PDU belongs to which operation. By sharing the 563 connection among multiple operations, the server will be able to 564 conserve its resources. 566 4.12 Interactions with Other LDAP Search and Response Controls 568 LCUP defines neither restrictions nor guarantees about the ability 569 to use the LDAP client update control defined in this document in 570 conjunction with other LDAP controls, except for the following: A 571 server MAY ignore non-critical controls supplied with the LCUP 572 control. A server MAY ignore the LCUP control if it is non-critical 573 and it is supplied with other critical controls. If a server 574 receives a critical LCUP control with another critical control, and 575 the server does not support both controls at the same time, the 576 server SHOULD return unavailableCriticalExtension. 578 5. Additional Features 580 There are several features present in other protocols or considered 581 useful by clients that are currently not included in the protocol 582 primarily because they are difficult to implement on the server. 583 These features are briefly discussed in this section. This section 584 is intended to open a discussion on the merits of including and 585 approaches to implementing these features. 587 5.1 Triggered Search Change Type 589 This feature is present in the Triggered Search specification. A 590 flag is attached to each entry returned to the client indicating the 591 reason why this entry is returned. The possible reasons from the 592 draft are 593 "- notChange: the entry existed in the directory and matched the 594 search at the time the operation is being performed, 595 - enteredSet: the entry entered the result, 596 - leftSet: the entry left the result, 598 Megginson, et. al. Proposed Standard - Expires: December 2002 11 599 - modified: the entry was part of the result set, was modified or 600 renamed, and still is in the result set." 602 The leftSet feature is particularly useful because it indicates to 603 the client that an entry is no longer within the client's search 604 specification and the client can remove the associated data from its 605 data store. Ironically, this feature is the hardest to implement on 606 the server because the server does not keep track of the client's 607 state and has no easy way of telling which entries moved out of 608 scope between synchronization sessions with the client. 610 A compromise could be reached by only providing this feature for the 611 operations that occur while the client is connected to the server. 612 This is easier to accomplish because the decision about the change 613 type can be made based only on the change without need for any 614 historical information. This, however, would add complexity to the 615 protocol. 617 5.2 Persistent Search Change Type 619 This feature is present in the Persistent Search specification. 620 Persistent search has the notion of changeTypes. The client 621 specifies which type of updates will cause entries to be returned, 622 and optionally whether the server tags each returned entry with the 623 type of change that caused that entry to be returned. 625 For LCUP, the intention is full synchronization, not partial. Each 626 entry returned by an LCUP search will have some change associated 627 with it that may concern the client. The client may have to have a 628 local index of entries by DN or UUID to determine if the entry has 629 been added or just modified. It is easy for clients to determine if 630 the entry has been deleted because the entryDeleted value of the 631 entryUpdateControl will be TRUE. 633 5.3 Sending Changes 635 Some earlier synchronization protocols sent the client(s) only the 636 modified attributes of the entry rather than the entire entry. While 637 this approach can significantly reduce the amount of data returned 638 to the client, it has several disadvantages. First, unless a 639 separate mechanism (like the change type described above) is used to 640 notify the client about entries moving into the search scope, 641 sending only the changes can result in the client having an 642 incomplete version of the data. Let's consider an example. An 643 attribute of an entry is modified. As a result of the change, the 644 entry enters the scope of the client's search. If only the changes 645 are sent, the client would never see the initial data of the entry. 646 Second, this feature is hard to implement since the server might not 647 contain sufficient information to construct the changes based solely 648 on the server's state and the client's cookie. On the other hand, 649 this feature can be easily implemented by the client assuming that 650 the client has the previous version of the data and can perform 651 value by value comparisons. 653 Megginson, et. al. Proposed Standard - Expires: December 2002 12 654 5.4 Data Size Limits 656 Some earlier synchronization protocols allowed clients to control 657 the amount of data sent to them in the search response. This feature 658 was intended to allow clients with limited resources to process 659 synchronization data in batches. However, an LDAP search operation 660 already provides the means for the client to specify the size limit 661 by setting the sizeLimit field in the SearchRequest to the maximum 662 number of entries the client is willing to receive. While the 663 granularity is not the same, the assumption is that regular LDAP 664 clients that can deal with the limitations of the LDAP protocol will 665 implement LCUP. 667 5.5 Data Ordering 669 Some earlier synchronization protocols allowed a client to specify 670 that parent entries should be sent before the children for add 671 operations and children entries sent before their parents during 672 delete operations. This ordering helps clients to maintain a 673 hierarchical view of the data in their data store. While possibly 674 useful, this feature is relatively hard to implement and is 675 expensive to perform. 677 6. Client Side Considerations 679 Clients SHOULD always specify entryUUID in the SearchRequest 680 attribute list. 682 The cookie received from the server after a synchronization session 683 can only be used with the same or more restrictive search 684 specification than the search that generated the cookie. The server 685 will reject the search operation with a cookie that does not satisfy 686 this condition. This is because the client can end up with an 687 incomplete data store otherwise. A more restrictive search 688 specification is the one that generates a subset of the data 689 produced by the original search specification. 691 Because an LCUP client specifies the area of the tree with which it 692 wishes to synchronize through the standard LDAP search 693 specification, the client can be returned noSuchObject error if the 694 root of the synchronization area was renamed between the 695 synchronization sessions or during a synchronization session. If 696 this condition occurs, the client can attempt to locate the root by 697 using the root's UUID saved in client's local data store. It then 698 can repeat the synchronization request using the new search base. In 699 general, a client can detect that an entry was renamed and apply the 700 changes received to the right entry by using the UUID rather than DN 701 based addressing. 703 Each active persistent operation requires that an open TCP 704 connection be maintained between an LDAP client and an LDAP server 705 that might not otherwise be kept open. Therefore, client 706 implementors are encouraged to avoid using persistent operations for 707 non-essential tasks and to close idle LDAP connections as soon as 709 Megginson, et. al. Proposed Standard - Expires: December 2002 13 710 practical. The server may close connections if server resources 711 become tight. 713 The client MAY receive a continuation reference 714 (SearchResultReference [RFC2251 SECTION 4.5.3]) if the search 715 request spans multiple parts of the DIT, some of which may require a 716 different LCUP cookie, some of which may not even be managed by 717 LCUP. The client SHOULD maintain a cache of the LDAP URLs returned 718 in the continuation references and the cookies associated with them. 719 The client is responsible for performing another LCUP search to 720 follow the references, and SHOULD use the cookie corresponding to 721 the LDAP URL for that reference (if it has a cookie). 723 The client may receive a referral (Referral [RFC2251 SECTION 724 4.1.11]) when the search base is a subordinate reference, and this 725 will end the operation. 727 For alias dereferencing, the server will behave as if the client had 728 requested neverDerefAliases or derefFindingBaseObj as the 729 derefAliases field in the search request [RFC2251, Section 4.5.1]. 730 If the client specifies a value other than neverDerefAliases or 731 derefFindingBaseObj, the server will return protocolError to the 732 client. 734 Changes to data (e.g., that might affect the LCUP client's filter or 735 scope) or meta-data (e.g., that might affect the client's read 736 access) may affect the presence of entries in the search set. 737 Servers MAY notify LCUP clients of changes to the search set that 738 result from such changes, but an LCUP client MUST NOT assume that 739 such notification will occur. Therefore, in the case where a client 740 is maintaining a cache of entries using LCUP, the data held by the 741 client may be a superset or a subset of the entries that would be 742 returned by a new search request. For example, if access control 743 meta information is changed to deny access to particular entries in 744 the search result set, and the access control information is outside 745 of the search scope (e.g., in a parent entry), the client may have 746 entries stored locally which are no longer part of its desired 747 search set. Similarly, if entries are added to the search result 748 set due to changes in meta-data, the client's cache of entries may 749 not include these entries. 751 Some clients may wish to perform an initial synchronization in order 752 to prime a cache or establish a baseline set of entries, then look 753 for changes after that. The recommended way to do this is to first 754 issue an LCUP search with the updateType field of the clientUpdate 755 control value set to synchronizeOnly, then after that search 756 successfully completes, immediately issue an LCUP search with the 757 updateType field of the clientUpdate control value set to 758 synchronizeAndPersist. 760 Some clients may have unreliable connections, for example, a 761 wireless device or a WAN connection. These clients may want to 762 insure that the cookie is returned often in the entryUpdate control 763 value, so that if they have to reconnect, they do not have to 765 Megginson, et. al. Proposed Standard - Expires: December 2002 14 766 process many redundant entries. These clients should set the 767 sendCookieInterval in the clientUpdate control value to a low 768 number, perhaps even 1. Also, some clients may have a limited 769 bandwidth connection, and may not want to receive the cookie very 770 often, or even at all (however, the cookie is always sent back in 771 the clientUpdateDone control value upon successful completion). 772 These clients should set the sendCookieInterval in the clientUpdate 773 control value to a high number. 775 7. Server Implementation Considerations 777 Servers SHOULD support UUIDs. Otherwise, it will be very difficult 778 to support modifyDN operations. Adding support for UUIDs should be 779 seen as a necessary component of LCUP. 781 By design, the protocol supports multiple cookie schemes. This is 782 to allow different implementations the flexibility of storing any 783 information applicable to their environment. A reasonable 784 implementation for an LDUP compliant server would be to use the 785 Replica Update Vector (RUV). For each master, RUV contains the 786 largest CSN seen from this master. In addition, the RUV implemented 787 by some directory servers (not yet in LDUP) contains replica 788 generation - an opaque string that identifies the replica's data 789 store. The replica generation value changes whenever the replica's 790 data is reloaded. Replica generation is intended to signal the 791 replication/synchronization peers that the replica's data was 792 reloaded and that all other replicas need to be reinitialized. RUV 793 satisfies the three most important properties of the cookie: (1) it 794 uniquely identifies the state of client's data, (2) it can be used 795 to synchronize with multiple servers, and (3) it can be used to 796 detect that the server's data was reloaded. 798 A server may support one or more LCUP cookie schemes. It is 799 expected that schemes will be published along with their OIDs as 800 RFCs. If a client initiates an LCUP session with a particular 801 scheme, the server MUST use that same scheme throughout the LCUP 802 session, or until an LCUP context boundary is crossed, in which case 803 the server will usually require a different cookie anyway. 805 In addition, the cookie must contain enough information to allow the 806 server to determine whether the cookie can be safely used with the 807 search specification it is attached to. As discussed earlier in the 808 document, the cookie can only be used with the search specification 809 that is equally or more restrictive than the one for which the 810 cookie was generated. 812 An implementation must make sure that it can correctly update the 813 client's cookie when there is a size limit imposed on the search 814 results by either the client's request or by the server's 815 configuration. If RUV is used as the cookie, entries last modified 816 by a particular master must be sent to the client in the order of 817 their last modified CSN. This ordering guarantees that the RUV can 818 be updated after each entry is sent. 820 Megginson, et. al. Proposed Standard - Expires: December 2002 15 821 The server's DIT may be partitioned into different sections which 822 may have different cookies associated with them. For example, some 823 servers may use some sort of replication mechanism to support LCUP. 824 If so, the DIT may be partitioned into multiple replicas. A client 825 may send an LCUP search request that spans multiple replicas. Some 826 parts of the DIT spanned by the search request scope may be managed 827 by LCUP and some may not. A part of the DIT which is enabled for 828 LCUP is referred to as an LCUP Context. The server SHOULD send a 829 SearchResultReference [RFC2251, SECTION 4.5.3] when the LCUP Context 830 for a returned entry changes. The server SHOULD return all entries 831 for a particular LCUP Context before returning a reference to other 832 LCUP Contexts or non-LCUP enabled parts of the DIT, in order to 833 minimize the processing burden on the clients. The LDAP URL(s) 834 returned MUST contain the DN(s) of the base of another section of 835 the DIT (however the server implementation has partitioned the DIT). 836 The client will then issue another LCUP search using the LDAP URL 837 returned. Each section of the DIT MAY require a different cookie 838 value, so the client SHOULD maintain a cache, mapping the different 839 LDAP URL values to different cookies. If the cookie changes, the 840 scheme may change as well, but the cookie scheme MUST be the same 841 within a given LCUP Context. 843 An implementation SHOULD notify the client about all entries deleted 844 from the search set since the client's last session, but an LCUP 845 client MUST NOT assume that such notification will occur. For 846 example, the server might not notify the client of the deletion of 847 an object if the object left the search set following the client's 848 last synchronization and prior to the object's deletion. An LDUP 849 compliant implementation can achieve this through the use of entry 850 tombstones. The implementation should avoid aggressive tombstone 851 purging since lack of tombstones would cause client's data to be 852 reloaded. We suggest that only the tombstone content be removed 853 during the regular trimming cycle while tombstones themselves are 854 discarded much less frequently. 856 The specification makes no guarantees about how soon a server should 857 send notification of a changed entry to the client when the 858 connection between the client and the server is kept open. This is 859 intentional as any specific maximum delay would be impossible to 860 meet in a distributed directory service implementation. Server 861 implementors are encouraged to minimize the delay before sending 862 notifications to ensure that clients' needs for timeliness of change 863 notification are met. 865 Implementors of servers that support the mechanism described in this 866 document should ensure that their implementation scales well as the 867 number of active persistent operations and the number of changes 868 made in the directory increases. Server implementors are also 869 encouraged to support a large number of client connections if they 870 need to support large numbers of persistent operations. 872 8. Synchronizing Heterogeneous Data Stores 874 Megginson, et. al. Proposed Standard - Expires: December 2002 16 875 Clients, like a meta directory join engine, synchronizing multiple 876 writable data stores will only work correctly if each piece of 877 information is single mastered (for instance, only by an LDUP 878 compliant directory). This is because different systems have 879 different notions of time and different update resolution 880 procedures. As a result, a change applied on one system can be 881 discarded by the other, thus preventing the data stores from 882 converging. 884 9. Security Considerations 886 In some situations, it may be important to prevent general exposure 887 of information about changes that occur in an LDAP server. 888 Therefore, servers that implement the mechanism described in this 889 document SHOULD provide a means to enforce access control on the 890 entries returned and MAY also provide specific access control 891 mechanisms to control the use of the controls and extended 892 operations defined in this document. 894 As with normal LDAP search requests, a malicious client can initiate 895 a large number of persistent search requests in an attempt to 896 consume all available server resources and deny service to 897 legitimate clients. The protocol provides the means to stop 898 malicious clients by disconnecting them from the server. The servers 899 that implement the mechanism SHOULD provide the means to detect the 900 malicious clients. In addition, the servers SHOULD provide the means 901 to limit the number of resources that can be consumed by a single 902 client. 904 Access control on the data can be modified in such a way that the 905 data is no longer visible to the client. The specification does not 906 specify how the server should handle this condition. Moreover, data 907 consistency is not guaranteed if access control is changed from a 908 more restrictive to a less restrictive one. This is because access 909 control can be considered as an additional filter on the search 910 specification and the protocol does not support going from a more to 911 a less restrictive search specification. See Client Side 912 Considerations Section for more detailed explanation of the problem. 914 10. Normative References 916 [KEYWORDS] S. Bradner, "Keywords for use in RFCs to Indicate 917 Requirement Levels", RFC 2119, March 1997. 919 [RFC2251] M. Wahl, T. Howes, S. Kille "Lightweight Directory 920 Access Protocol", RFC 2251, December 1997. 922 [RFC2252] M. Wahl, A. Coulbeck, T. Howes, S. Kille, "Lightweight 923 Directory Access Protocol (v3): Attribute Syntax 924 Definitions", RFC 2252, December 1997. 926 [CANCEL] K. Zeilenga, "LDAP Cancel Extended Operation", 927 draft-zeilenga-ldap-cancel-xx.txt, a work in progress. 929 Megginson, et. al. Proposed Standard - Expires: December 2002 17 930 11. Acknowledgements 932 The LCUP protocol is based in part on the Persistent Search Change 933 Notification Mechanism defined by Mark Smith, Gordon Good, Tim 934 Howes, and Rob Weltman, the LDAPv3 Triggered Search Control defined 935 by Mark Wahl, and the LDAP Control for Directory Synchronization 936 defined by Michael Armijo. 938 12. Author's Addresses 940 Rich Megginson 941 Netscape Communications Corp. 942 901 San Antonio Rd. 943 Palo Alto, CA 94303-4900 944 Mail Stop SCA17 - 201 945 Phone: +1 505 797-7762 946 Email: richm@netscape.com 948 Olga Natkovich 949 Yahoo, Inc. 950 701 First Ave. 951 Sunnyvale, CA 94089 952 Phone: +1 408 349-6153 953 Email: olgan@yahoo-inc.com 955 Mark Smith 956 Netscape Communications Corp. 957 901 San Antonio Rd. 958 Palo Alto, CA 94303-4900 959 Mail Stop SCA17 - 201 960 Phone: +1 650 937-3477 961 Email: mcs@netscape.com 963 Jeff Parham 964 Microsoft Corporation 965 One Microsoft Way 966 Redmond, WA 98052-6399 967 Phone: +1 425 882-8080 968 Email: jeffparh@microsoft.com 970 13. Full Copyright Statement 971 "Copyright (C) The Internet Society (date). All Rights Reserved. 972 This document and translations of it may be copied and furnished to 973 others, and derivative works that comment on or otherwise explain it 974 or assist in its implementation may be prepared, copied, published 975 and distributed, in whole or in part, without restriction of any 976 kind, provided that the above copyright notice and this paragraph 977 are included on all such copies and derivative works. However, this 978 document itself may not be modified in any way, such as by removing 979 the copyright notice or references to the Internet Society or other 980 Internet organizations, except as needed for the purpose of 981 developing Internet standards in which case the procedures for 982 copyrights defined in the Internet Standards process must be 983 followed, or as required to translate it into languages other than 985 Megginson, et. al. Proposed Standard - Expires: December 2002 18 986 English. 988 The limited permissions granted above are perpetual and will not be 989 revoked by the Internet Society or its successors or assigns. 991 This document and the information contained herein is provided on an 992 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 993 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 994 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 995 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 996 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 998 14. Appendix A - Summary of Changes 1000 Changes new to version 03: 1002 Emphasized the use of UUIDs throughout the document. Implementers 1003 are strongly encouraged to use UUIDs as a necessary component of 1004 the protocol. 1006 Removed the LCUP Cancel extended operation in favor of the new 1007 LDAP Cancel operation [CANCEL]. 1009 Got rid of the lcupSuccess result code. All result codes will be 1010 added to the IANA LDAP result code registry as part of the LDAP 1011 standard. Also removed the result code and text from the client 1012 update done control value. 1014 Changed any and all wording suggesting an LCUP Context is related 1015 to a naming context. New text says an LCUP Context is a part of 1016 the DIT that supports LCUP, and that a server may have one or more 1017 LCUP Contexts. 1019 Removed Old Section 4.2: lcupCookieScheme 1020 We decided that LCUP did not need a discovery mechanism. The 1021 controls and extended operations will be published in the root DSE 1022 as per the LDAP standards. 1024 Changed references to "Unique Identifier" to either "Universally 1025 Unique Identifier" or "UUID". 1027 Added this text to section 6 "Client Side Considerations": 1028 "- The client may receive a referral (Referral [RFC2251 SECTION 1029 4.1.11]) when the search base is a subordinate reference, and 1030 this will end the operation." 1032 Added a note to section 6 "Client Side Considerations" about how 1033 to establish a baseline set of entries or entry cache. 1035 Added the field sendCookieInterval to the clientUpdate control 1036 value. 1038 Added a note to section 6 "Client Side Considerations" explaining 1039 possible uses of the sendCookieInterval. 1041 Megginson, et. al. Proposed Standard - Expires: December 2002 19 1042 Changes new to version 02: 1044 Section 4.2: The lcupCookieScheme operational attribute MUST be 1045 present in the root DSE, and MAY be present in entries. Each 1046 value of the attribute in the root DSE will be a list of OIDs of 1047 cookie schemes followed by the DN of the LCUP context which 1048 supports the schemes. The attribute value in the DIT entries will 1049 be the list of OIDs followed by the DN of the LCUP context. 1051 section 4.5 - the entry uuid is now MAY instead of MUST - if 1052 implementers do not wish to identify entries by a unique ID other 1053 than DN (which may not be unique), then so be it. For returned 1054 SearchResultEntry PDUs other than deleted entries, the client MAY 1055 request that the Unique Identifier attribute be returned by 1056 specifying it in the attribute list to be returned by the search 1057 request. 1059 section 4.5 - added "or the base DN of the client's search 1060 request." to the phrase. "The server MAY send the entry at the 1061 root of the client's tree, or the base DN of the client's search 1062 request." I think this clarifies which entry the client may 1063 search for. 1065 section 4.6 - the clientUpdateDone control is now optional for 1066 error conditions. Also, the cookie value of the control is now 1067 optional for lcup error conditions (e.g. not lcupSuccess or 1068 lcupClientDisconnect). 1070 Added section 4.12 - Interactions with Other LDAP Search and 1071 Response Controls 1073 Added blurb about alias dereferencing back to section 6: 1074 "For alias dereferencing, the server will behave as if the client 1075 had requested neverDerefAliases or derefFindingBaseObj as the 1076 derefAliases field in the search request [RFC2251, Section 4.5.1]. 1077 If the client specifies a value other than neverDerefAliases or 1078 derefFindingBaseObj, the server will return protocolError to the 1079 client." 1081 Changed this in section 6: 1082 Because an LCUP client specifies the area of the tree with which 1083 it wishes to synchronize through the standard LDAP search 1084 specification, the client can be returned noSuchObject error if 1085 the root of the synchronization area was renamed between the 1086 synchronization sessions "or during a synchronization session" 1088 Changes new to version 01: 1090 The opaque cookie has been split into two parts - a scheme which 1091 is an OID, and a value. The value may or may not have a format 1092 known to the client, depending on the specified scheme. Section 1093 4.2 describes the new cookie format and defines the LCUP Cookie 1094 Value. 1096 Megginson, et. al. Proposed Standard - Expires: December 2002 20 1097 Added new section 4.3 - the lcupCookieScheme operational 1098 attribute. 1100 Changes new to version 00: 1102 Added the definition for Unique Identifier (basically copied from 1103 the LDUP model doc http://search.ietf.org/internet-drafts/draft- 1104 ietf-ldup-model-06.txt. I needed to add the definition here 1105 because LCUP needs a Unique Identifier but should not be dependent 1106 on LDUP. 1108 Removed all normative references to LDUP. I've left the 1109 implementation suggestions that refer to LDUP, but LCUP should not 1110 be dependent on LDUP. 1112 Cleaned up the protocol flows. 1114 Removed this text from section 4.8: "Clients MUST NOT issue 1115 multiple synchronization requests on the same connection. This is 1116 because the protocol includes an extended operation and it would 1117 be impossible to decide which synchronization session it belongs 1118 to." - This is no longer true, since the extended operation now 1119 includes the message ID of the search request. 1121 "Client Side Consideration" section - the client will never 1122 receive a referral or continuation reference 1124 Added section 12. Acknowledgements 1126 Removed normative references to documents not depended on. 1128 Removed explicit references to software vendors. 1130 Section 4.1 - Changed ClientUpdateControlValue to remove the 1131 keepConnection and changesOnly fields and replace them with 1132 updateType which is an ENUMERATED with three values: 1133 synchronizeOnly, synchronizeAndPersist, and persistOnly. 1135 Section 4.2 - The EntryUpdateControlValue fields stateUpdate and 1136 entryDeleted no longer have DEFAULT values, they must be specified 1137 - this eliminates any potential ambiguity. 1139 Added this text to the description of the entryDeleted field 1140 (section 4.2): "The server SHOULD also set this to TRUE if the 1141 entry has left the clients search result set. As far as the client 1142 is concerned, a deleted entry is no different than an entry which 1143 has left the result set." 1144 Section 4.2 - Added an explanation of the concept and requirement 1145 for the Unique Identifier. 1147 Section 4.4 - Added to the extended operation a request value 1148 containing the message id of the operation to stop. 1150 Megginson, et. al. Proposed Standard - Expires: December 2002 21 1151 Updated contact information for Olga. 1153 Removed Michael Armijo and added Jeff Parham as an author. 1155 Changes new to previous version: 1157 "Authors" section - added Rich Megginson as the new editor. 1159 "Client Side Consideration" section - added a note and a question 1160 concerning referral and continuation reference handling. 1162 "Client Update Control Value" section (4.1) - clarified the meaning 1163 of keepConnection and added a table summarizing the effects of 1164 different values of keepConnection and changesOnly. 1166 "Stop Client Update Request and Response" - added section 4.4 1167 describing this extended operation. 1169 Megginson, et. al. Proposed Standard - Expires: December 2002 22