1 2 3 4 5 6 7Network Working Group R. Harrison 8Request for Comments: 4373 J. Sermersheim 9Category: Informational Novell, Inc. 10 Y. Dong 11 January 2006 12 13 14 Lightweight Directory Access Protocol (LDAP) 15 Bulk Update/Replication Protocol (LBURP) 16 17Status of This Memo 18 19 This memo provides information for the Internet community. It does 20 not specify an Internet standard of any kind. Distribution of this 21 memo is unlimited. 22 23Copyright Notice 24 25 Copyright (C) The Internet Society (2006). 26 27Abstract 28 29 The Lightweight Directory Access Protocol (LDAP) Bulk 30 Update/Replication Protocol (LBURP) allows an LDAP client to perform 31 a bulk update to an LDAP server. The protocol frames a sequenced set 32 of update operations within a pair of LDAP extended operations to 33 notify the server that the update operations in the framed set are 34 related in such a way that the ordering of all operations can be 35 preserved during processing even when they are sent asynchronously by 36 the client. Update operations can be grouped within a single 37 protocol message to maximize the efficiency of client-server 38 communication. 39 40 The protocol is suitable for efficiently making a substantial set of 41 updates to the entries in an LDAP server. 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58Harrison, et al. Informational [Page 1] 59 60RFC 4373 LDAP Bulk Update/Replication Protocol January 2006 61 62 63Table of Contents 64 65 1. Introduction ....................................................3 66 2. Conventions Used in This Document ...............................3 67 3. Overview of Protocol ............................................3 68 3.1. Update Initiation ..........................................4 69 3.2. Update Stream ..............................................4 70 3.2.1. LBURPUpdateRequest ..................................4 71 3.2.2. LBURPUpdateResponse .................................4 72 3.3. Update Termination .........................................4 73 3.4. Applicability of Protocol ..................................5 74 4. Description of Protocol Flow ....................................5 75 5. Elements of Protocol ............................................6 76 5.1. StartLBURPRequest ..........................................7 77 5.1.1. updateStyleOID ......................................7 78 5.2. StartLBURPResponse .........................................7 79 5.2.1. maxOperations .......................................8 80 5.3. LBURPUpdateRequest .........................................8 81 5.3.1. sequenceNumber ......................................8 82 5.3.2. UpdateOperationList .................................9 83 5.4. LBURPUpdateResponse ........................................9 84 5.4.1. OperationResults ...................................10 85 5.4.1.1. operationNumber ...........................10 86 5.4.1.2. ldapResult ................................10 87 5.5. EndLBURPRequest ...........................................10 88 5.5.1. sequenceNumber .....................................10 89 5.6. EndLBURPResponse ..........................................11 90 6. Semantics of the Incremental Update Style ......................11 91 7. General LBURP Semantics ........................................11 92 8. Security Considerations ........................................12 93 9. IANA Considerations ............................................13 94 9.1. LDAP Object Identifier Registrations ......................13 95 10. Normative References ..........................................14 96 11. Informative References ........................................14 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114Harrison, et al. Informational [Page 2] 115 116RFC 4373 LDAP Bulk Update/Replication Protocol January 2006 117 118 1191. Introduction 120 121 The Lightweight Directory Access Protocol (LDAP) Bulk 122 Update/Replication Protocol (LBURP) arose from the need to allow an 123 LDAP client to efficiently present large quantities of updates to an 124 LDAP server and have the LDAP server efficiently process them. LBURP 125 introduces a minimum of new operational functionality to the LDAP 126 protocol because the update requests sent by the client encapsulate 127 standard LDAP [RFC2251] update operations. However, this protocol 128 greatly facilitates bulk updates by allowing the client to send the 129 update operations asynchronously and still allow the server to 130 maintain proper ordering of the operations. It also allows the 131 server to recognize the client's intent to perform a potentially 132 large set of update operations and then to change its processing 133 strategy to more efficiently process the operations. 134 1352. Conventions Used in This Document 136 137 Imperative keywords defined in RFC 2119 [RFC2119] are used in this 138 document, and carry the meanings described there. 139 140 All Basic Encoding Rules (BER) [X.690] encodings follow the 141 conventions found in section 5.1 of [RFC2251]. 142 143 The term "supplier" applies to an LDAP client or an LDAP server 144 (acting as a client) that supplies a set of update operations to a 145 consumer. 146 147 The term "consumer" applies to an LDAP server that consumes (i.e., 148 processes) the sequenced set of update operations sent to it by a 149 supplier. 150 1513. Overview of Protocol 152 153 LBURP frames a set of update operations within a pair of LDAP 154 extended operations that mark the beginning and end of the update 155 set. These updates are sent via LDAP extended operations, each 156 containing a sequence number and a list of one or more update 157 operations to be performed by the consumer. Except for the fact that 158 they are grouped together as part of a larger LDAP message, the 159 update operations in each subset are encoded as LDAP update 160 operations and use the LDAP Abstract Syntax Notation One (ASN.1) 161 [X.680] message types specified in [RFC2251]. 162 163 164 165 166 167 168 169 170Harrison, et al. Informational [Page 3] 171 172RFC 4373 LDAP Bulk Update/Replication Protocol January 2006 173 174 1753.1. Update Initiation 176 177 The protocol is initiated when a supplier sends a StartLBURPRequest 178 extended operation to a consumer as a notification that a stream of 179 associated LBURPUpdateRequests will follow. The supplier associates 180 semantics with this stream of requests by including the Object 181 Identifier (OID) of the bulk update/replication style in the 182 StartLBURPRequest. The consumer responds to the StartLBURPRequest 183 with a StartLBURPResponse message. 184 1853.2. Update Stream 186 187 After the consumer responds with a StartLBURPResponse, the supplier 188 sends a stream of LBURPUpdateRequest messages to the consumer. 189 Messages within this stream may be sent asynchronously to maximize 190 the efficiency of the transfer. The consumer responds to each 191 LBURPUpdateRequest with an LBURPUpdateResponse message. 192 1933.2.1. LBURPUpdateRequest 194 195 Each LBURPUpdateRequest contains a sequence number identifying its 196 relative position within the update stream and an UpdateOperationList 197 containing an ordered list of LDAP update operations to be applied to 198 the Directory Information Tree (DIT). The sequence number enables 199 the consumer to process LBURPUpdateRequest messages in the order they 200 were sent by the supplier even when they are sent asynchronously. 201 The consumer processes each LBURPUpdateRequest according to the 202 sequence number by applying the LDAP update operations in its 203 UpdateOperationList to the DIT in the order they are listed. 204 2053.2.2. LBURPUpdateResponse 206 207 When the consumer has processed the update operations from an 208 UpdateOperationList, it sends an LBURPUpdateResponse to the supplier 209 indicating the success or failure of the update operations contained 210 within the corresponding LBURPUpdateRequest. 211 2123.3. Update Termination 213 214 After the supplier has sent all of its LBURPUpdateRequest messages, 215 it sends an EndLBURPRequest message to the consumer to terminate the 216 update stream. Upon servicing all LBURPOperation requests and 217 receiving the EndLBURPRequest, the consumer responds with an 218 EndLBURPResponse, and the update is complete. 219 220 221 222 223 224 225 226Harrison, et al. Informational [Page 4] 227 228RFC 4373 LDAP Bulk Update/Replication Protocol January 2006 229 230 2313.4. Applicability of Protocol 232 233 LBURP is designed to facilitate the bulk update of LDAP servers. It 234 can also be used to synchronize directory information between a 235 single master and multiple slaves. 236 237 No attempt is made to deal with the issues associated with multiple- 238 master replication environments (such as keeping modification times 239 of attribute values) so that updates to the same entry on different 240 replicas can be correctly ordered. For this reason, when LBURP alone 241 is used for replication, proper convergence of the data between all 242 replicas can only be assured in a single-master replication 243 environment. 244 2454. Description of Protocol Flow 246 247 This section describes the LBURP protocol flow and the information 248 contained in each protocol message. Throughout this section, the 249 client or server acting as a supplier is indicated by the letter "S", 250 and the server acting as a consumer is indicated by the letter "C". 251 The construct "S -> C" indicates that the supplier is sending an LDAP 252 message to the consumer, and "C -> S" indicates that the consumer is 253 sending an LDAP message to the supplier. Note that the protocol flow 254 below assumes that a properly authenticated LDAP session has already 255 been established between the supplier and consumer. 256 257 S -> C: StartLBURPRequest message. The parameter is: 258 259 1) OID for the LBURP update style (see section 5.1.1). 260 261 C -> S: StartLBURPResponse message. The parameter is: 262 263 1) An optional maxOperations instruction 264 (see section 5.2.1). 265 266 S -> C: An update stream consisting of zero or more 267 LBURPUpdateRequest messages. The requests MAY be sent 268 asynchronously. The parameters are: 269 270 1) A sequence number specifying the order of 271 this LBURPUpdateRequest with respect to the 272 other LBURPUpdateRequest messages in the update 273 stream (see section 5.3.1). 274 275 2) LBURPUpdateRequest.updateOperationList, a list 276 of one or more LDAP update operations (see section 277 5.3.2). 278 279 280 281 282Harrison, et al. Informational [Page 5] 283 284RFC 4373 LDAP Bulk Update/Replication Protocol January 2006 285 286 287 The consumer processes the LBURPUpdateRequest messages 288 in the order of their sequence numbers and applies the 289 LDAP update operations contained within each 290 LBURPUpdateRequest to the DIT in the order they are 291 listed. 292 293 C -> S: LBURPUpdateResponse message. This is sent when the 294 consumer completes processing the update operations 295 from each LBURPUpdateRequest.updateOperationList. 296 297 S -> C: EndLBURPRequest message. This is sent after the 298 supplier sends all of its LBURPUpdateRequest messages 299 to the consumer. The parameter is: 300 301 1) A sequence number that is one greater than the 302 sequence number of the last LBURPUpdateRequest 303 message in the update stream. This allows the 304 EndLBURPRequest to also be sent asynchronously. 305 306 C -> S: EndLBURPResponse message. This is sent in response to 307 the EndLBURPRequest after the consumer has serviced 308 all LBURPOperation requests. 309 3105. Elements of Protocol 311 312 LBURP uses two LDAP ExtendedRequest messages--StartLBURPRequest and 313 EndLBURPRequest--to initiate and terminate the protocol. A third 314 LDAP ExtendedRequest message--LBURPUpdateRequest--is used to send 315 update operations from the supplier to the consumer. These three 316 requests along with their corresponding responses comprise the entire 317 protocol. 318 319 LBURP request messages are defined in terms of the LDAP 320 ExtendedRequest [RFC2251] as follows: 321 322 ExtendedRequest ::= [APPLICATION 23] SEQUENCE { 323 requestName [0] LDAPOID, 324 requestValue [1] OCTET STRING OPTIONAL 325 } 326 327 LBURP response messages are defined in terms of the LDAP 328 ExtendedResponse [RFC2251] as follows: 329 330 ExtendedResponse ::= [APPLICATION 24] SEQUENCE { 331 COMPONENTS of LDAPResult, 332 responseName [10] LDAPOID OPTIONAL, 333 response [11] OCTET STRING OPTIONAL 334 } 335 336 337 338Harrison, et al. Informational [Page 6] 339 340RFC 4373 LDAP Bulk Update/Replication Protocol January 2006 341 342 3435.1. StartLBURPRequest 344 345 The requestName value of the StartLBURPRequest is OID 1.3.6.1.1.17.1. 346 347 The requestValue of the StartLBURPRequest contains the BER-encoding 348 of the following ASN.1: 349 350 StartLBURPRequestValue ::= SEQUENCE { 351 updateStyleOID LDAPOID 352 } 353 354 LDAPOID is defined in [RFC2251], section 4.1.2. 355 3565.1.1. updateStyleOID 357 358 The updateStyleOID is an OID that uniquely identifies the LBURP 359 update style being used. This document defines one LBURP update 360 semantic style that can be transmitted between the StartLBURPRequest 361 and EndLBURPRequest. The updateStyleOID is included in the protocol 362 for future expansion of additional update styles. For example, a 363 future specification might define an update style with semantics to 364 replace all existing entries with a new set of entries and thus only 365 allows the Add operation. 366 367 The updateStyleOID for the LBURP Incremental Update style is 368 1.3.6.1.1.17.7. The semantics of this update style are described in 369 section 6. 370 3715.2. StartLBURPResponse 372 373 The responseName of the StartLBURPResponse is the OID 1.3.6.1.1.17.2. 374 375 The optional response element contains the BER-encoding of the 376 following ASN.1: 377 378 StartLBURPResponseValue ::= maxOperations 379 380 maxOperations ::= INTEGER (0 .. maxInt) 381 382 maxInt INTEGER ::= 2147483647 -- (2^^31 - 1) -- 383 384 385 386 387 388 389 390 391 392 393 394Harrison, et al. Informational [Page 7] 395 396RFC 4373 LDAP Bulk Update/Replication Protocol January 2006 397 398 3995.2.1. maxOperations 400 401 When present, the value of maxOperations instructs the supplier to 402 send no more than that number of update operations per 403 LBURPUpdateRequest.updateOperationList (see section 5.3.2). If the 404 consumer does not send a maxOperations value, it MUST be prepared to 405 accept any number of update operations per 406 LBURPUpdateRequest.updateOperationList. The supplier MAY send fewer 407 but MUST NOT send more than maxOperations update operations in a 408 single LBURPUpdateRequest.updateOperationList. 409 4105.3. LBURPUpdateRequest 411 412 The LBURPUpdateRequest message is used to send a set of zero or more 413 LDAP update operations from the supplier to the consumer along with 414 sequencing information that enables the consumer to maintain the 415 proper sequencing of multiple asynchronous LBURPUpdateRequest 416 messages. 417 418 The requestName of the LBURPUpdateRequest is the OID 1.3.6.1.1.17.5. 419 420 The requestValue of an LBURPOperation contains the BER-encoding of 421 the following ASN.1: 422 423 LBURPUpdateRequestValue ::= SEQUENCE { 424 sequenceNumber INTEGER (1 .. maxInt), 425 updateOperationList UpdateOperationList 426 } 427 4285.3.1. sequenceNumber 429 430 The sequenceNumber orders associated LBURPOperation requests. This 431 enables the consumer to process LBURPOperation requests in the order 432 specified by the supplier. The supplier MUST set the value of 433 sequenceNumber of the first LBURPUpdateRequest to 1, and MUST 434 increment the value of sequenceNumber by 1 for each succeeding 435 LBURPUpdateRequest. In the unlikely event that the number of 436 LBURPUpdateRequest messages exceeds maxInt, a sequenceNumber value of 437 1 is deemed to be the succeeding sequence number following a sequence 438 number of maxInt. 439 440 441 442 443 444 445 446 447 448 449 450Harrison, et al. Informational [Page 8] 451 452RFC 4373 LDAP Bulk Update/Replication Protocol January 2006 453 454 4555.3.2. UpdateOperationList 456 457 The UpdateOperationList is a list of one or more standard LDAP update 458 requests and is defined as follows: 459 460 UpdateOperationList ::= SEQUENCE OF SEQUENCE{ 461 updateOperation CHOICE { 462 addRequest AddRequest, 463 modifyRequest ModifyRequest, 464 delRequest DelRequest, 465 modDNRequest ModifyDNRequest 466 }, 467 controls [0] Controls OPTIONAL 468 } 469 470 AddRequest, ModifyRequest, DelRequest, and ModifyDNRequest are 471 defined in [RFC2251], sections 4.6, 4.7, 4.8, and 4.9. 472 473 The LDAP update requests in the UpdateOperationList MUST be applied 474 to the DIT in the order in which they are listed. 475 4765.4. LBURPUpdateResponse 477 478 An LBURPUpdateResponse message is sent from the consumer to the 479 supplier to signal that all of the update operations from the 480 UpdateOperationList of an LBURPUpdateRequest have been completed and 481 to give the results for the update operations from that list. 482 483 The responseName of the LBURPUpdateResponse is the OID 484 1.3.6.1.1.17.6. 485 486 If the consumer server cannot successfully decode an 487 LBURPUpdateRequest in its entirety, the resultCode for the 488 corresponding LBURPUpdateResponse is set to protocolError and the 489 response element is omitted. Updates from the LBURPUpdateRequest 490 SHALL NOT be committed to the DIT in this circumstance. 491 492 If the status of all of the update operations being reported by an 493 LBURPUpdateResponse message is success, the resultCode of the 494 LBURPUpdateResponse message is set to success and the response 495 element is omitted. 496 497 If the status of any of the update operations being reported by an 498 LBURPUpdateResponse message is something other than success, the 499 resultCode for the entire LBURPUpdateResponse is set to other to 500 signal that the response element is present. 501 502 503 504 505 506Harrison, et al. Informational [Page 9] 507 508RFC 4373 LDAP Bulk Update/Replication Protocol January 2006 509 510 5115.4.1. OperationResults 512 513 When a response element is included in an LBURPUpdateResponse 514 message, it contains the BER-encoding of the following ASN.1: 515 516 OperationResults ::= SEQUENCE OF OperationResult 517 518 OperationResult ::= SEQUENCE { 519 operationNumber INTEGER, 520 ldapResult LDAPResult 521 } 522 523 An OperationResult is included for each operation from the 524 UpdateOperationList that failed during processing. 525 5265.4.1.1. operationNumber 527 528 The operationNumber identifies the LDAP update operation from the 529 UpdateOperationList of the LBURPUpdateRequest that failed. 530 Operations are numbered beginning at 1. 531 5325.4.1.2. ldapResult 533 534 The ldapResult included in the OperationResult is the same ldapResult 535 that would be sent for the update operation that failed if it had 536 failed while being processed as a normal LDAP update operation. 537 LDAPResult is defined in [RFC2251], section 4.1.10. 538 5395.5. EndLBURPRequest 540 541 The requestName of the EndLBURPRequest is the OID 1.3.6.1.1.17.3. 542 543 The requestValue contains the BER-encoding of the following ASN.1: 544 545 EndLBURPRequestValue::= SEQUENCE { 546 sequenceNumber INTEGER (1 .. maxInt) 547 } 548 5495.5.1. sequenceNumber 550 551 The value in sequenceNumber is one greater than the last 552 LBURPUpdateRequest.sequenceNumber in the update stream. It allows 553 the server to know when it has received all outstanding asynchronous 554 LBURPUpdateRequests. 555 556 557 558 559 560 561 562Harrison, et al. Informational [Page 10] 563 564RFC 4373 LDAP Bulk Update/Replication Protocol January 2006 565 566 5675.6. EndLBURPResponse 568 569 The responseName of the EndLBURPResponse is the OID 1.3.6.1.1.17.4. 570 571 There is no response element in the EndLBURPResponse message. 572 5736. Semantics of the Incremental Update Style 574 575 The initial state of entries in the consumer's DIT plus the 576 LBURPUpdateRequest messages in the update stream collectively 577 represent the desired final state of the consumer's DIT. All LDAP 578 update operations defined in [RFC2251]--Add, Modify, Delete, and 579 Modify DN--are allowed in the incremental update stream. All of the 580 semantics of those operations are in effect, so for instance, an 581 attempt to add an entry that already exists will fail just as it 582 would during a normal LDAP Add operation. 583 5847. General LBURP Semantics 585 586 The consumer server may take any action required to efficiently 587 process the updates sent via LBURP, as long as the final state is 588 equivalent to that which would have been achieved if the updates in 589 the update stream had been applied to the DIT using normal LDAP 590 update operations. 591 592 The LBURPUpdateRequest messages that form the update stream MAY be 593 sent asynchronously by the supplier to the consumer. This means that 594 the supplier need not wait for an LBURPUpdateResponse message for one 595 LBURPUpdateRequest message before sending the next LBURPUpdateRequest 596 message. 597 598 When the LBURP update stream contains a request that affects multiple 599 Directory System Agents (DSAs), the consumer MAY choose to perform 600 the request or return a resultCode value of affectsMultipleDSAs. As 601 with any LDAP operation, a consumer MAY send a resultCode value of 602 referral as part of the OperationResult element for any operation on 603 an entry that it does not contain. If the consumer is configured to 604 do so, it MAY chain on behalf of the supplier to complete the update 605 operation instead. 606 607 While a consumer server is processing an LBURP update stream, it may 608 choose not to service LDAP requests on other connections. This 609 provision is designed to allow implementers the freedom to implement 610 highly-efficient methods of handling the update stream without being 611 constrained by the need to maintain a live, working DIT database 612 while doing so. 613 614 615 616 617 618Harrison, et al. Informational [Page 11] 619 620RFC 4373 LDAP Bulk Update/Replication Protocol January 2006 621 622 623 If a consumer chooses to refuse LDAP operation requests from other 624 suppliers during LBURP update, it is RECOMMENDED that the consumer 625 refer those requests to another server that has the appropriate data 626 to complete the operation. 627 628 Unless attribute values specifying timestamps are included as part of 629 the update stream, updates made using LBURP are treated the same as 630 other LDAP operations wherein they are deemed to occur at the 631 present. Consumers MAY store timestamp values sent by suppliers but 632 are not required to do so. 633 634 Implementations may choose to perform the operations in the update 635 stream with special permissions to improve performance. 636 637 Consumer implementations should include functionality to detect and 638 terminate connections on which an LBURP session has been initiated 639 but information (such as the EndLBURPRequest) needed to complete the 640 LBURP session is never received. A timeout is one mechanism that can 641 be used to accomplish this. 642 6438. Security Considerations 644 645 Implementations should ensure that a supplier making an LBURP request 646 is properly authenticated and authorized to make the updates 647 requested. There is a potential for loss of data if updates are made 648 to the DIT without proper authorization. If LBURP is used for 649 replication, implementers should note that unlike other replication 650 protocols, no existing replication agreement between supplier and 651 consumer is required. These risks increase if the consumer server 652 also processes the update stream with special permissions to improve 653 performance. For these reasons, implementers should carefully 654 consider which permissions should be required to perform LBURP 655 operations and take steps to ensure that only connections with 656 appropriate authorization are allowed to perform them. 657 658 The data contained in the update stream may contain passwords and 659 other sensitive data. Care should be taken to properly safeguard 660 this information while in transit between supplier and consumer. The 661 StartTLS [RFC2830] operation is one mechanism that can be used to 662 provide data confidentiality and integrity services for this purpose. 663 664 As with any asynchronous LDAP operation, it may be possible for an 665 LBURP supplier to send asynchronous LBURPUpdateRequest messages to 666 the consumer faster than the consumer can process them. Consumer 667 implementers should take steps to prevent LBURP suppliers from 668 interfering with the normal operation of a consumer server by issuing 669 a rapid stream of asynchronous LBURPUpdateRequest messages. 670 671 672 673 674Harrison, et al. Informational [Page 12] 675 676RFC 4373 LDAP Bulk Update/Replication Protocol January 2006 677 678 6799. IANA Considerations 680 681 Registration of the following values has been made by the IANA 682 [RFC3383]. 683 6849.1. LDAP Object Identifier Registrations 685 686 The IANA has registered LDAP Object Identifiers identifying the 687 protocol elements defined in this technical specification. The 688 following registration template was provided: 689 690 Subject: Request for LDAP OID Registration 691 Person & email address to contact for further information: 692 Roger Harrison 693 rharrison@novell.com 694 Specification: RFC 4373 695 Author/Change Controller: IESG 696 Comments: 697 Seven delegations will be made under the assigned OID. The 698 following 6 OIDs are Protocol Mechanism OIDs of type "E" 699 (supportedExtension): 700 701 1.3.6.1.1.17.1 StartLBURPRequest LDAP ExtendedRequest message 702 1.3.6.1.1.17.2 StartLBURPResponse LDAP ExtendedResponse message 703 1.3.6.1.1.17.3 EndLBURPRequest LDAP ExtendedRequest message 704 1.3.6.1.1.17.4 EndLBURPResponse LDAP ExtendedResponse message 705 1.3.6.1.1.17.5 LBURPUpdateRequest LDAP ExtendedRequest message 706 1.3.6.1.1.17.6 LBURPUpdateResponse LDAP ExtendedResponse message 707 708 The following 1 OID is a Protocol Mechanism OID of type "F" 709 (supportedFeature): 710 711 1.3.6.1.1.17.7 LBURP Incremental Update style OID 712 713 714 715 716 717 718 719 720 721 722 723 724 725 726 727 728 729 730Harrison, et al. Informational [Page 13] 731 732RFC 4373 LDAP Bulk Update/Replication Protocol January 2006 733 734 73510. Normative References 736 737 [RFC2119] Bradner, S., "Key Words for use in RFCs to Indicate 738 Requirement Levels", BCP 14, RFC 2119, March 1997. 739 740 [RFC2251] Wahl, M., Howes, T., and S. Kille, "Lightweight Directory 741 Access Protocol (v3)", RFC 2251, December 1997. 742 743 [RFC3383] Zeilenga, K., "Internet Assigned Numbers Authority (IANA) 744 Considerations for the Lightweight Directory Access 745 Protocol (LDAP)", BCP 64, RFC 3383, September 2002. 746 747 [X.680] ITU-T Recommendation X.680 (07/2002) | ISO/IEC 8824-1:2002 748 "Information Technology - Abstract Syntax Notation One 749 (ASN.1): Specification of basic notation" 750 751 [X.690] ITU-T Rec. X.690 (07/2002) | ISO/IEC 8825-1:2002, 752 "Information technology - ASN.1 encoding rules: 753 Specification of Basic Encoding Rules (BER), Canonical 754 Encoding Rules (CER) and Distinguished Encoding Rules 755 (DER)", 2002. 756 75711. Informative References 758 759 [RFC2830] Hodges, J., Morgan, R., and M. Wahl, "Lightweight 760 Directory Access Protocol (v3): Extension for Transport 761 Layer Security", RFC 2830, May 2000. 762 763 764 765 766 767 768 769 770 771 772 773 774 775 776 777 778 779 780 781 782 783 784 785 786Harrison, et al. Informational [Page 14] 787 788RFC 4373 LDAP Bulk Update/Replication Protocol January 2006 789 790 791Authors' Addresses 792 793 Roger Harrison 794 Novell, Inc. 795 1800 S. Novell Place 796 Provo, UT 84606 797 798 Phone: +1 801 861 2642 799 EMail: rharrison@novell.com 800 801 802 Jim Sermersheim 803 Novell, Inc. 804 1800 S. Novell Place 805 Provo, UT 84606 806 807 Phone: +1 801 861 3088 808 EMail: jimse@novell.com 809 810 811 Yulin Dong 812 813 EMail: yulindong@gmail.com 814 815 816 817 818 819 820 821 822 823 824 825 826 827 828 829 830 831 832 833 834 835 836 837 838 839 840 841 842Harrison, et al. Informational [Page 15] 843 844RFC 4373 LDAP Bulk Update/Replication Protocol January 2006 845 846 847Full Copyright Statement 848 849 Copyright (C) The Internet Society (2006). 850 851 This document is subject to the rights, licenses and restrictions 852 contained in BCP 78, and except as set forth therein, the authors 853 retain all their rights. 854 855 This document and the information contained herein are provided on an 856 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 857 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 858 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 859 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 860 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 861 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 862 863Intellectual Property 864 865 The IETF takes no position regarding the validity or scope of any 866 Intellectual Property Rights or other rights that might be claimed to 867 pertain to the implementation or use of the technology described in 868 this document or the extent to which any license under such rights 869 might or might not be available; nor does it represent that it has 870 made any independent effort to identify any such rights. Information 871 on the procedures with respect to rights in RFC documents can be 872 found in BCP 78 and BCP 79. 873 874 Copies of IPR disclosures made to the IETF Secretariat and any 875 assurances of licenses to be made available, or the result of an 876 attempt made to obtain a general license or permission for the use of 877 such proprietary rights by implementers or users of this 878 specification can be obtained from the IETF on-line IPR repository at 879 http://www.ietf.org/ipr. 880 881 The IETF invites any interested party to bring to its attention any 882 copyrights, patents or patent applications, or other proprietary 883 rights that may cover technology that may be required to implement 884 this standard. Please address the information to the IETF at 885 ietf-ipr@ietf.org. 886 887Acknowledgement 888 889 Funding for the RFC Editor function is provided by the IETF 890 Administrative Support Activity (IASA). 891 892 893 894 895 896 897 898Harrison, et al. Informational [Page 16] 899 900