idnits 2.17.1 draft-haripriya-ldapext-entryselect-01.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: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 10 longer pages, the longest (page 1) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' scope :: = ENUMERATED {' ) ** 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.) ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 6 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** There are 6 instances of lines with control characters in the document. ** The abstract seems to contain references ([RFC2251]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (25 August 2000) is 8637 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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: '0' on line 266 -- Looks like a reference, but probably isn't: '1' on line 267 -- Looks like a reference, but probably isn't: '2' on line 152 -- Looks like a reference, but probably isn't: '3' on line 153 -- Looks like a reference, but probably isn't: '4' on line 154 -- Looks like a reference, but probably isn't: '5' on line 133 -- Looks like a reference, but probably isn't: '6' on line 134 -- Looks like a reference, but probably isn't: '7' on line 135 -- Looks like a reference, but probably isn't: '8' on line 136 -- Looks like a reference, but probably isn't: '9' on line 137 == Missing Reference: 'ExtPartResp' is mentioned on line 252, but not defined == Missing Reference: 'RFC2251' is mentioned on line 275, but not defined ** Obsolete undefined reference: RFC 2251 (Obsoleted by RFC 4510, RFC 4511, RFC 4512, RFC 4513) == Unused Reference: 'RFC 2119' is defined on line 568, 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 2254 (Obsoleted by RFC 4510, RFC 4515) Summary: 12 errors (**), 0 flaws (~~), 5 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Haripriya S., Novell 2 25 August 2000 3 Expiry: February 25 2001 5 EntrySelection control for 6 LDAP modify and delete operations on multiple entries 7 9 1. Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as 17 Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other 21 documents at any time. It is inappropriate to use Internet- 22 Drafts as reference material or to cite them other than as "work 23 in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet Draft expires February 25, 2001. 33 2. Abstract 35 This document defines an LDAPv3 control that can select multiple 36 entries in a subtree of a container entry for modification or 37 deletion. This control extends the scope of the LDAPv3 modify and 38 delete operations as defined in [RFC 2251]. This control is useful 39 for modifying or deleting multiple entries on the basis of a 40 single selection criterion. This may be useful for maintenance of 41 an LDAP directory having a large number of objects. 43 Example of Usage - This control can be used by client applications 44 who have the need to modify or delete a large number of entries in 45 an LDAP directory based on a selection criterion. One example of 46 such a usage is when two departments in an organization merge. In 47 this case the "department" name or number given to a number of 48 employees need to change, and all the employees in a given 49 department are to be assigned the new "department". Here the 50 EntrySelection control can be used to select the entries to be 51 modified based on the "department" value, and the modify operation 52 can change the "department" value for all the selected entries to 53 the given value. 55 The EntrySelection control is useful when a large number of 57 Haripriya S. INTERNET-DRAFT 1 58 EntrySelection control for 59 LDAP modify and delete on multiple entries, August 2000 61 entries have to be modified or deleted, because what can be 62 achieved in 1 LDAP client operation with the EntrySelection 63 control will take a minimum of 1 + n LDAP operations (1 search, n 64 modifies) otherwise. This will save a lot of time and bandwidth, 65 and hence very useful in situations where the clients are 66 connected over high latency links. Also low-end clients which 67 cannot handle a large number of objects, can use this feature. 68 This also prevents cache pollution or false caching, where a large 69 number of search results are returned only to be immediately 70 modified or deleted, thus invalidating cached information for 71 those results. 73 3. RFC Key Words 75 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 76 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 77 in this document are to be interpreted as described in RFC 2119. 79 4. EntrySelection request control 81 A multi-entry modify or delete operation can be thought of as a 82 combination of a search operation followed by modify or delete 83 operation. The search operation in this case is used to select the 84 entries for modification or deletion. 86 For the purpose of selecting entries, an entry selection control 87 is added. This control will be similar to a search request. The 88 ControlType is , the Criticality field may be TRUE or 89 FALSE, and the controlValue is EntrySelection which is encoded as 90 per the following syntax: 92 EntrySelection ::= SEQUENCE { 93 entryscope [0] scope OPTIONAL, -- Scope for the operation 94 derefAliases [1] aliases OPTIONAL, -- aliases 96 timeLimit [2] INTEGER (0 .. maxInt) OPTIONAL, 97 -- for the selection -- 98 optimeLimit [3] INTEGER (0 .. maxInt) OPTIONAL, 99 -- for the operation -- 100 continueOnError [4] BOOLEAN OPTIONAL DEFAULT FALSE, 101 -- for the operation -- 102 filter [5] Filter OPTIONAL 103 } 105 scope :: = ENUMERATED { 106 baseObject (0), 107 singleLevel (1), 108 wholeSubtree (2) 109 } 111 aliases ::= ENUMERATED { 112 neverDerefAliases (0), 113 derefInSearching (1), 115 Haripriya S. INTERNET-DRAFT 2 116 EntrySelection control for 117 LDAP modify and delete on multiple entries, August 2000 119 derefFindingBaseObj (2), 120 derefAlways (3) 121 } 123 The following definitions are the same as the corresponding 124 definitions in [RFC 2251] 4.5.1. They are just repeated here for 125 completeness. 127 Filter ::= CHOICE { 128 and [0] SET of Filter, 129 or [1] SET of Filter, 130 not [2] Filter, 131 equalityMatch [3] AttributeValueAssertion, 132 subStrings [4] SubstringFilter, 133 greaterOrEqual [5] AttributeValueAssertion, 134 lessOrEqual [6] AttributeValueAssertion, 135 present [7] AttributeDescription, 136 approxMatch [8] AttributeValueAssertion, 137 extensibleMatch [9] MatchingRuleAssertion 138 } 140 SubstringFilter ::= SEQUENCE { 141 type AttributeDescription, 142 -- at least one must be present 143 substrings SEQUENCE OF CHOICE { 144 initial [0] LDAPString, 145 any [1] LDAPString, 146 final [2] LDAPString 147 } 148 } 150 MatchingRuleAssertion ::= SEQUENCE { 151 matchingRule [1] MatchingRuleOd OPTIONAL, 152 type [2] AttributeDescription OPTIONAL, 153 matchValue [3] AssertionValue, 154 dnAttributes [4] BOOLEAN DEFAULT FALSE 155 } 157 entryScope: This field specifies the scope of the operation. It 158 can be baseObject, oneLevel, or wholeSubTree. The field is 159 OPTIONAL, and if not sent, the default scope of the operation will 160 be baseObject, which is similar to the scope of a normal modify or 161 delete operation. 163 derefAliases: This field specified whether to dereference alias 164 while selecting. This is also an OPTIONAL field, and if absent, 165 the default is neverDerefAliases. 167 filter: This field is similar to a search filter. It is OPTIONAL, 168 and if absent, the control selects all entries, that are allowed 169 by the scope and the other fields in the control. 171 timeLimit: This OPTIONAL INTEGER field specifies the time limit 173 Haripriya S. INTERNET-DRAFT 3 174 EntrySelection control for 175 LDAP modify and delete on multiple entries, August 2000 177 in seconds, for the entry selection for the base operation. If the 178 field is absent or 0, then no limit is assumed. 180 optimeLimit: Similar to timeLimit but for the entire operation. 181 Again, if this field is absent or 0, then no limit is assumed. 183 continueOnError: This OPTIONAL BOOLEAN field is used by the client 184 to indicate to the server whether to continue or stop the whole 185 operation, if it encounters an error while performing the 186 operation on one of the entries selected. The default value is 187 FALSE and the corresponding behaviour is to stop the operation on 188 error. 190 The control is used to select the entries that are to be modified 191 or deleted as per the LDAP request message that this attaches 192 to. This control SHOULD only be used with an LDAP Modify or Delete 193 request message. The server SHOULD ignore the control if used with 194 any other message unless the criticality field is set to TRUE. If 195 the criticality field is set to TRUE, then the server SHOULD return 196 the resultCode unavailableCriticalExtension ( RFC 2251 Section 197 4.1.12 ). The server MUST list this control as recognized in the 198 supportedControl attribute in the root DSE. 200 5. Response messages 202 The server upon request of an LDAP modify or delete request with 203 an EntrySelection control in it can return the following 204 responses: EntrySelectionPartialResponse, any other LDAP extended 205 response (could be due to another control in the opertion 206 requiring an extended response), or an LDAPResponse 207 (ModifyResponse or DeleteResponse). For a non-abandoned operation, 208 the server MUST return zero or more EntrySelectionPartialResponse, 209 zero or more of any other extended response, and one 210 ModifyResponse or DeleteResponse message. The ModifyResponse or 211 DeleteResponse SHOULD be returned at the end after all other 212 extended responses have been returned for the operation. 214 The ModifyResponse or DeleteResponse will return the overall 215 result for the whole operation on multiple entries, which MAY 216 also contain some error codes for specifying the result of the 217 entry selection operation, in addition to the error codes usually 218 returned by a Modify or Delete operation. These error codes 219 include timeLimitExceeded(2), adminLimitExceeded(11), 220 undefinedAttributeType(17) and inappropriateMatching(18). 222 5.1 EntrySelectionPartialResponse extended partial response 224 The EntrySelectionPartialResponse is sent to return partial 225 results, as the operation progresses. This is used to inform the 226 client about the result of the operations on each selected entry 227 and for returning search continuation results. 229 The EntrySelectionPartialResponse MUST be returned by the server 231 Haripriya S. INTERNET-DRAFT 4 232 EntrySelection control for 233 LDAP modify and delete on multiple entries, August 2000 235 in the following cases: 237 a. Immediately after attempting the operation for each entry 238 selected by the EntrySelection filter. 240 b. The server is unable to search an entry in the scope, at or 241 under the baseObject, but can return references to another set of 242 servers for continuing the operation. 244 The EntrySelectionPartialResponse is returned in a generalized 245 "ExtendedPartialResponse". ExtendedPartialResponse is defined in 246 the [extpartresp] document as follows: 248 ExtendedPartialResponse ::= [ APPLICATION 25 ] SEQUENCE { 249 responseName [0] LDAPOID OPTIONAL, 250 response [1] OCTET STRING OPTIONAL } 252 Note: The current version of the [ExtPartResp] draft does not 253 define a generalized ExtendedPartialResponse. Work is going on to 254 generalize it. This draft assumes a generalized 255 ExtendedPartialResponse for its purpose. 257 A specific ExtendedPartialResponse for EntrySelection is defined 258 from generalized ExtendedPartialResponse as follows: 260 The EntrySelectionPartialResponse will be a 'specific' generalized 261 ExtendedPartialResponse with the 'responseName' of and 262 the value of 'response' field is an octet string which is the BER 263 encoding of the following: 265 EntrySelectionPartialResult ::= CHOICE { 266 entry [0] EntryResult, 267 searchContinuation [1] SEQUENCE OF LDAPURL 268 } 270 EntryResult ::= SEQUENCE { 271 resultcode resultCode 272 matchedDN LDAPDN 273 } 275 resultCode is defined as in RFC 2251 [RFC2251] 4.1.10 for LDAPResult. 277 6. Semantics of the EntrySelection and EntrySelectionResponse 278 Controls 280 The EntrySelection control, will behave like an LDAP search 281 operation at the server. The server MUST select all the entries 282 that are selected as per the EntrySelection control, before 283 starting the modify or delete operation on any of the matched 284 entries. If deleting entries, the server MUST make sure that all 285 the child entries in the selected list are processed before their 286 parents are processed for deletion. The server SHOULD NOT process 287 the entries in such a way that it would orphan the entries. 289 Haripriya S. INTERNET-DRAFT 5 290 EntrySelection control for 291 LDAP modify and delete on multiple entries, August 2000 293 If the condition of the EntryCriterion evaluates to TRUE with 294 respect to a given DN (either the base DN if the scope is base, or 295 any of the subtree/children DNs if the subtree or onelevel scope 296 is set), then the LDAP server should do the modify or the delete 297 operation that has been specified in the delete or modify request. 298 If the condition evaluates to UNKNOWN or FALSE, then the operation 299 MUST NOT be attempted on the corresponding DN. 301 If the 'timelimit' in the EntrySelection control is exceeded 302 before the search is over, only the entries selected will be 303 considered for modification/deletion, and the ModifyResponse or 304 DeleteResponse will return a resultCode of 'timeLimitExceeded'. If 305 the 'optimeLimit' in the control is exceeded before the whole 306 operation (the selection plus the modifies/deletes) is complete, 307 then operation will be stopped, and a ModifyResponse or 308 DeleteResponse is returned, with resultCode being 309 'timeLimitExceeded'. The EntrySelectionPartialResponses that may 310 have been received by the client in the latter case will indicate 311 to the client that the timeout did not happen during the 312 selection, but during the operation. 314 6.1 Atomicity of the operation and effect of abandon: 316 The modify or delete operation on each selected entry MUST be done 317 atomically, but the server NEED NOT ensure that the modify/delete 318 operation across all selected entries are done as one atomic 319 operation. The atomicity of the entire operation will be the same 320 as if a client first did a search, and then based on the entries 321 selected, gave a series of modify or delete requests. If a client 322 makes changes to some of the entries that are selected by the 323 EntrySelection filter, while the operation is in progress, the 324 combined result of the operations is undefined. 326 The server MUST send extended partial responses for each selected 327 entry on which the modify/delete opeation was attempted. If the 328 client sends an abandon request in the middle of processing, the 329 server MUST stop the processing immediately, including the 330 modify/delete on the current entry it was processing. The server 331 MUST NOT send a ModifyResponse/DeleteResponse, or an 332 EntrySelectionPartialResponse for the current entry in this 333 case. The client will be able to find the entries for which the 334 operation has been tried, along with the the result of the 335 operation, by looking at the EntrySelectionPartialResponses that 336 have been received from the server. The client MUST NOT expect 337 that the modify/delete operation on all the selected entries will 338 be done as one atomic operation. 340 7. Errors and Return Codes 342 If modify or delete operations succeed on all the objects where 343 one or more objects are selected, and no timeouts occured, then 344 the LDAP operation MUST return a result code of success. 346 Haripriya S. INTERNET-DRAFT 6 347 EntrySelection control for 348 LDAP modify and delete on multiple entries, August 2000 350 7.1 Deciding on the return values 352 The server MUST decide what values and error codes to return based 353 on the decision function below, and on the return values of LDAP 354 modify and delete operations. The decision logic to be followed at 355 the server end is discussed as a pseudo-code below, and each 356 tagged branch (eg. // 7.1.3 ) represents a sub-section describing 357 a specific decision that must be followed by the server. 359 LDAPopnresult: Result Code for the LDAP operation ( modify or 360 delete). This is the value that will be sent in the LDAPResult of 361 LDAPResponse. This can be any of the resultcodes specified for 362 Modify, Delete and Search operations in [rescodes]. 364 LDAPopnDN: The DN returned in the LDAPResponse. 366 selectResult: The result code for the select operation due to 367 EntrySelection control. 369 entryResult: The result code associated with each entry for which 370 the operation was attempted to be sent in 371 EntrySelectionPartialResponses. 373 entryDN: The DN of the entry on which the modify or delete was 374 attempted. 376 entry: The entry field in the EntrySelectionPartialResponse 378 The following conditions are possible: 380 if (baseDN is not available) 381 if (there are no referrals) // 7.1.1 382 LDAPopnresult = noSuchObject 383 LDAPopnDN = BaseDN 384 send LDAPResponse 385 else (if there are referrals) // 7.1.2 386 LDAPopnresult = referral 387 referrals field is filled with referral, send LDAPResponse 388 endif 389 else /* baseDN exists */ 390 while (there are continuation references found during searching) do 391 Send the continuation references in 'searchContinuation' // 7.1.3 392 in EntrySelectionPartialResponse packets, 393 'entry' field not sent. 394 done 395 if (search was successful or resulted in 396 timeLimitExceeded or adminLimitExceeded) // 7.1.4 397 LDAPopnresult = success/timeLimitExceeded/adminLimitExceeded 398 if (no entries are returned by the search) // 7.1.5 399 send LDAPResponse and return 400 else /* Entries are returned by search */ 401 while (there are entries remaining to be processed) // 7.1.6 403 Haripriya S. INTERNET-DRAFT 7 404 EntrySelection control for 405 LDAP modify and delete on multiple entries, August 2000 407 process entry named by entryDN 408 lasterror = error code returned for operation on entry 409 if (adminLimit OR optimeLimit exceeded 410 while in modify/delete) // 7.1.7 411 LDAPopnresult = adminLimitExceeded/timeLimitExceeded 412 toquit = yes 413 else if (lasterror != success AND continueOnError is not set) 414 // 7.1.8 415 toquit = yes 416 endif 417 Fill up an EntrySelectionPartialResponse with 418 entry.resultCode = lasterror 419 entry.matchedDN = entryDN 420 Send EntrySelectionPartialResponse, with entry field, 421 searchContinuation field not sent 422 if (toquit == yes) // 7.1.9 423 break; 424 endif /* some entries remaining */ 425 endif /* Some entries returned by search */ 426 else /* Search was not successful */ // 7.1.11 427 LDAPopnresult = selectResult 428 LDAPopnDN = baseDN 429 endif 430 if (LDAPopnresult == success) { // 7.1.12 431 LDAPopnresult = lasterror 432 if (lasterror required matchedDN to be returned // 7.1.13 433 as per RFC 2251 4.1.10) 434 LDAPopnDN = entryDN 435 endif 436 endif 437 Send ModifyResponse or DeleteResponse with LDAPResult containing 438 LDAPopnDN and LDAPopnResult 439 endif 441 The user can decide to stop on error in modify/delete or can set 442 the continueOnError to 1, so that if even an error occurs during 443 modify/delete on an entry, the whole operation will still 444 continue. Otherwise when the first error occurs, the server MUST 445 stop processing the modify or delete for further entries. 447 If the number of modifies or deletes possible in a single LDAP 448 operation is exceeded, then the server SHOULD return 449 adminLimitExceeded(11). In this case objects should have been 450 processed till the error was reached, and the situation is defined 451 in 7.1.7. 453 7.2 Behavior of server with respect to Criticality 455 The default behavior in the absence of the Criticality field is 456 as if the Criticality field is set to false for the control. If 457 the control is not recognized, and the Criticality is set to TRUE, 458 then the server MUST return an unavailableCriticalExtension 459 result code. If the control is not recognized and the criticality 461 Haripriya S. INTERNET-DRAFT 8 462 EntrySelection control for 463 LDAP modify and delete on multiple entries, August 2000 465 is set to False, then the server should try to perform the 466 operation specified on the BaseDN alone and ignore the control. In 467 case unavailablecriticalextension is returned, then the server 468 should not send any of the EntrySelectionPartialResponses. 470 8. Making the operation idempotent with respect to retries 472 Multi-entry deletions even if done partially (only on a subset of 473 all the entries that were selected) will result in idempotent 474 retries, because the deleted entries will not be returned by the 475 EntrySelection filter the next time. But in an entry modify, an 476 add or a delete value, and or an add or delete attribute could 477 cause a AttributeOrValueAlreadyExists or noSuchAttribute, if the 478 operation has already been done. 480 Example: Let ou=hr,o=org be an organizationalUnit in company org. 481 Let cn=jsmith,ou=hr,o=org and cn=mwhite,ou=hr,o=org be two objects 482 of class "inetOrgPerson" under this ou. A multivalued attribute 483 "telephoneNumber" and a singlevalued attribute "preferredLanguage" 484 are optional attributes for "inetOrgPerson". Let the client 485 request, a modify operation on "ou=hr,o=org", with an 486 EntrySelection control with the LDAP search filter[RFC 2254] 487 "objectclass=inetOrgPerson", be as follows (in [ldif] format): 489 dn: ou=hr,o=org 490 changetype: modify 491 add: telephoneNumber 492 telephoneNumber: 801-861-2222 493 - 494 delete: preferredLanguage 496 If the first time around both entries "jsmith" and "mwhite" had 497 "preferredLanguage", and the operation failed on "mwhite" but 498 succeeded on "jsmith", then when the retry is done the operation 499 on "jsmith" would fail due to two reasons: 501 i) The value "801-861-2222" for "telephoneNumber" already exists - 502 AttributeOrValueAlreadyExists 504 ii) The attribute "preferredLanguage" is already deleted - 505 noSuchAttribute 507 The approach taken here is to let the client's filter take care of 508 such conditions creating noSuchAttribute (modify or delete a 509 attribute that does not exist), or AttributeOrValueAlreadyExists 510 (adding an already existing value to a multivalued attribute or 511 adding a single valued attribute which already exists). The 512 argument behind this approach is that such conditions could even 513 happen the first time around (without a retry), if the entry was 514 already in that state. 516 In case the client takes care of these two error conditions, the 517 client's filter in the EntrySelection should be the equivalent of 519 Haripriya S. INTERNET-DRAFT 9 520 EntrySelection control for 521 LDAP modify and delete on multiple entries, August 2000 523 '(&(objectclass=inetOrgPerson)(!(telephoneNumber="801-861-2222")) 524 (preferredLanguage=*))' 526 so that it can avoid changing the same attributes twice and thus 527 getting an error. 529 NOTE: There is no [ldif] format available for specifying the 530 information in an EntrySelection control yet. These examples are 531 not working examples but just to illustrate a situation. 533 6. Interaction with the TreeDelete control [treedelete] 535 If a TreeDelete control is set for a delete operation, then its 536 semantics is the same as if an EntrySelection control is sent with 537 the search filter being "objectclass=*", and the scope being 538 "sub". This similarity is with respect to the functionality of the 539 operation, but error handling and behavior with respect to 540 referrals etc. may vary. Also, the semantics for partial 541 processing of the operation for the EntrySelection control are 542 different from the TreeDelete control. 544 If both the TreeDelete control and the EntrySelection control are 545 present on a given LDAP delete request, then the server SHOULD 546 return an LDAP resultcode of unwillingToPerform(53). 548 7. Security Considerations 550 There are no direct security related issues discussed in this 551 document. But this control could indirectly cause a server to deny 552 service to legitimate clients because of the server being loaded 553 by a huge number of modifies and deletes due to this 554 control. Administrative limits MAY be set for a given server to 555 cope with such situations, and if exceeded the server SHOULD 556 return with an adminLimitExceeded error. 558 8. References 560 [RFC 2251] 561 M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access 562 Protocol (v3)", RFC 2251, December 1997. 564 [RFC 2254] 565 T. Howes, "The String Representation of LDAP Search Filters", 566 RFC 2254, December 1997. 568 [RFC 2119] 569 Bradner, S., "Key words for use in RFCs to Indicate 570 Requirement Levels, "RFC 2119, Harvard University, March 1997. 572 [rescodes] 573 Mike Just, K. Leclair, Jim Sermersheim, Mark smith, "LDAPv3 574 Result Codes: Definitions and Appropriate Use", 576 Haripriya S. INTERNET-DRAFT 10 577 EntrySelection control for 578 LDAP modify and delete on multiple entries, August 2000 580 INTERNET-DRAFT, April 2000, 583 [ldif] 584 Gordon Good, "The LDAP Data Interchange Format (LDIF) - 585 Technical Specification", Netscape Communications, 586 INTERNET-DRAFT, March 2000, 589 [treedelete] 590 M. P. Armijo, "Tree Delete Control", Microsoft Corporation, 591 INTERNET-DRAFT November 12, 1999, 593 ( This document is now expired ) 595 [extpartresp] 597 R. Harrison, "Extended Partial Response Protocol Enhancement 598 to LDAP v3", Novell Inc., INTERNET-DRAFT June 2000, 601 9. Acknowledgements 603 I sincerely thank Kurt D. Zeilenga who gave such invaluable inputs 604 which changed the whole approach of the document from its initial 605 version. I also thank K. K. Subramaniam, VithalPrasad Gaitonde, 606 Dinakar Sitaram, and Girish Elchuri who reviewed this document and 607 gave their valuable suggestions, and the Novell Standards Board 608 for their review. 610 10. Address 612 Haripriya S. 613 Novell Inc. 614 49/1, 49/3, Garvebhavi Palya, 615 7th Mile, Hosur Road, 616 Bangalore - 560068 617 India 618 Phone: +91-80-5721858 Extn:2121 619 Email: sharipriya@novell.com 621 This internet draft expires on 25 February 2001