]> git.sur5r.net Git - openldap/blob - doc/rfc/rfc4373.txt
Fix prev commit
[openldap] / doc / rfc / rfc4373.txt
1
2
3
4
5
6
7 Network Working Group                                        R. Harrison
8 Request for Comments: 4373                                J. Sermersheim
9 Category: Informational                                     Novell, Inc.
10                                                                  Y. Dong
11                                                             January 2006
12
13
14              Lightweight Directory Access Protocol (LDAP)
15                 Bulk Update/Replication Protocol (LBURP)
16
17 Status 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
23 Copyright Notice
24
25    Copyright (C) The Internet Society (2006).
26
27 Abstract
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
58 Harrison, et al.             Informational                      [Page 1]
59 \f
60 RFC 4373         LDAP Bulk Update/Replication Protocol      January 2006
61
62
63 Table 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
114 Harrison, et al.             Informational                      [Page 2]
115 \f
116 RFC 4373         LDAP Bulk Update/Replication Protocol      January 2006
117
118
119 1.  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
135 2.  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
151 3.  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
170 Harrison, et al.             Informational                      [Page 3]
171 \f
172 RFC 4373         LDAP Bulk Update/Replication Protocol      January 2006
173
174
175 3.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
185 3.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
193 3.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
205 3.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
212 3.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
226 Harrison, et al.             Informational                      [Page 4]
227 \f
228 RFC 4373         LDAP Bulk Update/Replication Protocol      January 2006
229
230
231 3.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
245 4.  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
282 Harrison, et al.             Informational                      [Page 5]
283 \f
284 RFC 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
310 5.  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
338 Harrison, et al.             Informational                      [Page 6]
339 \f
340 RFC 4373         LDAP Bulk Update/Replication Protocol      January 2006
341
342
343 5.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
356 5.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
371 5.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
394 Harrison, et al.             Informational                      [Page 7]
395 \f
396 RFC 4373         LDAP Bulk Update/Replication Protocol      January 2006
397
398
399 5.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
410 5.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
428 5.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
450 Harrison, et al.             Informational                      [Page 8]
451 \f
452 RFC 4373         LDAP Bulk Update/Replication Protocol      January 2006
453
454
455 5.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
476 5.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
506 Harrison, et al.             Informational                      [Page 9]
507 \f
508 RFC 4373         LDAP Bulk Update/Replication Protocol      January 2006
509
510
511 5.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
526 5.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
532 5.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
539 5.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
549 5.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
562 Harrison, et al.             Informational                     [Page 10]
563 \f
564 RFC 4373         LDAP Bulk Update/Replication Protocol      January 2006
565
566
567 5.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
573 6.  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
584 7.  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
618 Harrison, et al.             Informational                     [Page 11]
619 \f
620 RFC 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
643 8.  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
674 Harrison, et al.             Informational                     [Page 12]
675 \f
676 RFC 4373         LDAP Bulk Update/Replication Protocol      January 2006
677
678
679 9.  IANA Considerations
680
681    Registration of the following values has been made by the IANA
682    [RFC3383].
683
684 9.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
730 Harrison, et al.             Informational                     [Page 13]
731 \f
732 RFC 4373         LDAP Bulk Update/Replication Protocol      January 2006
733
734
735 10.  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
757 11.  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
786 Harrison, et al.             Informational                     [Page 14]
787 \f
788 RFC 4373         LDAP Bulk Update/Replication Protocol      January 2006
789
790
791 Authors' 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
842 Harrison, et al.             Informational                     [Page 15]
843 \f
844 RFC 4373         LDAP Bulk Update/Replication Protocol      January 2006
845
846
847 Full 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
863 Intellectual 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
887 Acknowledgement
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
898 Harrison, et al.             Informational                     [Page 16]
899 \f