1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
|
<pre>Independent Submission K. Zeilenga
Request for Comments: 5805 Isode Limited
Category: Experimental March 2010
ISSN: 2070-1721
<span class="h1">Lightweight Directory Access Protocol (LDAP) Transactions</span>
Abstract
Lightweight Directory Access Protocol (LDAP) update operations, such
as Add, Delete, and Modify operations, have atomic, consistency,
isolation, durability (ACID) properties. Each of these update
operations act upon an entry. It is often desirable to update two or
more entries in a single unit of interaction, a transaction.
Transactions are necessary to support a number of applications
including resource provisioning. This document extends LDAP to
support transactions.
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for examination, experimental implementation, and
evaluation.
This document defines an Experimental Protocol for the Internet
community. This is a contribution to the RFC Series, independently
of any other RFC stream. The RFC Editor has chosen to publish this
document at its discretion and makes no statement about its value for
implementation or deployment. Documents approved for publication by
the RFC Editor are not a candidate for any level of Internet
Standard; see <a href="./rfc5741#section-2">Section 2 of RFC 5741</a>.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
<a href="http://www.rfc-editor.org/info/rfc5805">http://www.rfc-editor.org/info/rfc5805</a>.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.
<span class="grey">Zeilenga Experimental [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc5805">RFC 5805</a> LDAP Transactions March 2010</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Overview</span>
This document extends the Lightweight Directory Access Protocol
(LDAP) [<a href="./rfc4510" title=""Lightweight Directory Access Protocol (LDAP): Technical Specification Road Map"">RFC4510</a>] to allow clients to relate a number of update
operations [<a href="./rfc4511" title=""Lightweight Directory Access Protocol (LDAP): The Protocol"">RFC4511</a>] and have them performed as one unit of
interaction, a transaction. As with distinct update operations, each
transaction has atomic, consistency, isolation, and durability (ACID)
properties [<a href="#ref-ACID" title=""Information technology -- Open Systems Interconnection -- Distributed Transaction Processing -- Part 1: OSI TP Model"">ACID</a>].
This extension consists of two extended operations, one control, and
one unsolicited notification message. The Start Transaction
operation is used to obtain a transaction identifier. This
identifier is then attached to multiple update operations to indicate
that they belong to the transaction using the Transaction
Specification control. The End Transaction is used to settle (commit
or abort) the transaction. The Aborted Transaction Notice is
provided by the server to notify the client that the server is no
longer willing or able to process an outstanding transaction.
<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a>. Conventions and Terminology</span>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <a href="./rfc2119">RFC 2119</a> [<a href="./rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>].
Protocol elements are described using ASN.1 [<a href="#ref-X.680" title=""Abstract Syntax Notation One (ASN.1) - Specification of Basic Notation"">X.680</a>] with implicit
tags. The term "BER-encoded" means the element is to be encoded
using the Basic Encoding Rules [<a href="#ref-X.690" title=""Specification of ASN.1 encoding rules: Basic Encoding Rules (BER), Canonical Encoding Rules (CER), and Distinguished Encoding Rules (DER)"">X.690</a>] under the restrictions
detailed in <a href="./rfc4511#section-5.1">Section 5.1 of [RFC4511]</a>.
DSA stands for "Directory System Agent" (a server). DSE stands for
"DSA-specific entry".
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Elements of an LDAP Transaction</span>
<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a>. Start Transaction Request and Response</span>
A Start Transaction Request is an LDAPMessage of CHOICE extendedReq
where the requestName is 1.3.6.1.1.21.1 and the requestValue is
absent.
A Start Transaction Response is an LDAPMessage of CHOICE extendedRes
sent in response to a Start Transaction Request. Its responseName is
absent. When the resultCode is success (0), responseValue is present
and contains a transaction identifier. Otherwise, the responseValue
is absent.
<span class="grey">Zeilenga Experimental [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc5805">RFC 5805</a> LDAP Transactions March 2010</span>
<span class="h3"><a class="selflink" id="section-2.2" href="#section-2.2">2.2</a>. Transaction Specification Control</span>
A Transaction Specification Control is an LDAPControl where the
controlType is 1.3.6.1.1.21.2, the criticality is TRUE, and the
controlValue is a transaction identifier. The control is appropriate
for update requests including Add, Delete, Modify, and ModifyDN
(Rename) requests [<a href="./rfc4511" title=""Lightweight Directory Access Protocol (LDAP): The Protocol"">RFC4511</a>], as well as the Password Modify requests
[<a href="./rfc3062" title=""LDAP Password Modify Extended Operation"">RFC3062</a>].
As discussed in <a href="#section-4">Section 4</a>, the Transaction Specification control can
be used in conjunction with request controls appropriate for the
update request.
<span class="h3"><a class="selflink" id="section-2.3" href="#section-2.3">2.3</a>. End Transactions Request and Response</span>
An End Transaction Request is an LDAPMessage of CHOICE extendedReq
where the requestName is 1.3.6.1.1.21.3 and the requestValue is
present and contains a BER-encoded txnEndReq.
txnEndReq ::= SEQUENCE {
commit BOOLEAN DEFAULT TRUE,
identifier OCTET STRING }
A commit value of TRUE indicates a request to commit the transaction
identified by the identifier. A commit value of FALSE indicates a
request to abort the identified transaction.
An End Transaction Response is an LDAPMessage sent in response to a
End Transaction Request. Its response name is absent. The
responseValue when present contains a BER-encoded txnEndRes.
txnEndRes ::= SEQUENCE {
messageID MessageID OPTIONAL,
-- msgid associated with non-success resultCode
updatesControls SEQUENCE OF updateControls SEQUENCE {
messageID MessageID,
-- msgid associated with controls
controls Controls
} OPTIONAL
}
-- where MessageID and Controls are as specified in <a href="./rfc4511">RFC 4511</a>
The txnEndRes.messageID provides the message id of the update request
associated with a non-success response. txnEndRes.messageID is
absent when resultCode of the End Transaction Response is success
(0).
<span class="grey">Zeilenga Experimental [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc5805">RFC 5805</a> LDAP Transactions March 2010</span>
The txnEndRes.updatesControls provides a facility for returning
response controls that normally (i.e., in the absence of
transactions) would be returned in an update response. The
updateControls.messageID provides the message id of the update
request associated with the response controls provided in
updateControls.controls.
The txnEndRes.updatesControls is absent when there are no update
response controls to return.
If both txnEndRes.messageID and txnEndRes.updatesControl are absent,
the responseValue of the End Transaction Response is absent.
<span class="h3"><a class="selflink" id="section-2.4" href="#section-2.4">2.4</a>. Aborted Transaction Notice</span>
The Aborted Transaction Notice is an Unsolicited Notification message
where the responseName is 1.3.6.1.1.21.4 and responseValue is present
and contains a transaction identifier.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. An LDAP Transaction</span>
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>. Extension Discovery</span>
To allow clients to discover support for this extension, servers
implementing this specification SHOULD publish 1.3.6.1.1.21.1 and
1.3.6.1.1.21.3 as values of the 'supportedExtension' attribute
[<a href="./rfc4512" title=""Lightweight Directory Access Protocol (LDAP): Directory Information Models"">RFC4512</a>] within the Root DSE, and publish the 1.3.6.1.1.21.2 as a
value of the 'supportedControl' attribute [<a href="./rfc4512" title=""Lightweight Directory Access Protocol (LDAP): Directory Information Models"">RFC4512</a>] of the Root DSE.
A server MAY choose to advertise this extension only when the client
is authorized to use it.
<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>. Starting a Transaction</span>
A client wishing to perform a sequence of directory updates as a
transaction issues a Start Transaction Request. A server that is
willing and able to support transactions responds to this request
with a Start Transaction Response providing a transaction identifier
and with a resultCode of success (0). Otherwise, the server responds
with a Start Transaction Response with a resultCode other than
success indicating the nature of the failure.
The transaction identifier provided upon successful start of a
transaction is used in subsequent protocol messages to identify this
transaction.
<span class="grey">Zeilenga Experimental [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc5805">RFC 5805</a> LDAP Transactions March 2010</span>
<span class="h3"><a class="selflink" id="section-3.3" href="#section-3.3">3.3</a>. Specification of a Transaction</span>
The client then can issue one or more update requests, each with a
Transaction Specification control containing the transaction
identifier indicating the updates are to be processed as part of the
transaction. Each of these update requests MUST have a different
MessageID value. If the server is unwilling or unable to attempt to
process the requested update operation as part of the transaction,
the server immediately returns the appropriate response to the
request with a resultCode indicating the nature of the failure.
Otherwise, the server immediately returns a resultCode of success (0)
and the defers further processing of the operation is then deferred
until settlement.
If the server becomes unwilling or unable to continue the
specification of a transaction, the server issues an Aborted
Transaction Notice with a non-success resultCode indicating the
nature of the failure. All operations that were to be processed as
part of the transaction are implicitly abandoned. Upon receipt of an
Aborted Transaction Notice, the client is to discontinue all use of
the transaction identifier as the transaction is null and void. Any
future use of identifier by the client will result in a response
containing a non-success resultCode.
<span class="h3"><a class="selflink" id="section-3.4" href="#section-3.4">3.4</a>. Transaction Settlement</span>
A client requests settlement of transaction by issuing an End
Transaction Request for the transaction indicating whether it desires
the transaction to be committed or aborted.
Upon receipt of a request to abort the transaction, the server is to
abort the identified transaction (abandoning all operations that are
part of the transaction) and indicate that it has done so by
returning an End Transaction Response with a resultCode of success
(0).
Upon receipt of a request to commit the transaction, the server
processes all update operations of the transaction as one atomic,
durable, isolated, and consistent action with each requested update
being processed in turn. Either all of the requested updates are to
be successfully applied or none of the requested are to be applied.
The server returns an End Transaction Response with a resultCode of
success (0) and no responseValue to indicate all the requested
updates were applied. Otherwise, the server returns an End
Transaction Response with a non-success resultCode indicating the
nature of the failure. If the failure is associated with a
<span class="grey">Zeilenga Experimental [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc5805">RFC 5805</a> LDAP Transactions March 2010</span>
particular update request, the txnEndRes.messageID in the
responseValue is the message id of this update request. If the
failure was not associated with any particular update request, no
txnEnd.messageID is provided.
There is no requirement that a server serialize transactions or
updates requested outside of a transaction. That is, a server MAY
process multiple commit requests (from one or more clients) acting
upon different sets of entries concurrently. A server MUST avoid
deadlock.
<span class="h3"><a class="selflink" id="section-3.5" href="#section-3.5">3.5</a>. Miscellaneous Issues</span>
Transactions cannot be nested.
Each LDAP transaction should be initiated, specified, and settled
within a stable security context. Between the Start Request and the
End Response, the peers SHOULD avoid negotiating new security
associations and/or layers.
Upon receipt of a Bind or Unbind request, the server SHALL abort any
and all outstanding transactions without notice and nullify their
identifiers.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Interaction with Other Extensions</span>
The LDAP Transaction extension may be used with many but not all LDAP
control extensions designed to extend update (and possibly other)
operations. The subsections that follow discuss interaction with a
number of control extensions. Interaction with other control
extensions may be discussed in other documents, in particular in
control extension specifications.
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>. Assertion Control</span>
The Assertion [<a href="./rfc4528" title=""Lightweight Directory Access Protocol (LDAP) Assertion Control"">RFC4528</a>] control is appropriate for use with update
requests specified as part of a transaction. The evaluation of the
assertion is performed as part of the transaction.
The Assertion control is inappropriate for use with either the Start
or End Transaction Extended operations.
<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>. ManageDsaIT Control</span>
The ManageDsaIT [<a href="./rfc3296" title=""Named Subordinate References in Lightweight Directory Access Protocol (LDAP) Directories"">RFC3296</a>] control is appropriate for use with update
requests specified as part of a transaction.
<span class="grey">Zeilenga Experimental [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc5805">RFC 5805</a> LDAP Transactions March 2010</span>
The ManageDsaIT control is inappropriate for use with either the
Start or End Transaction Extended operations.
<span class="h3"><a class="selflink" id="section-4.4" href="#section-4.4">4.4</a>. Proxied Authorization Control</span>
The Proxied Authorization [<a href="./rfc4370" title=""Lightweight Directory Access Protocol (LDAP) Proxied Authorization Control"">RFC4370</a>] control is appropriate for use
with the Start Transaction Extended operation, but not the End
Transaction Extended operation or any update request specified as
part of a transaction.
To request that a transaction be performed under a different
authorization, the client provides a Proxied Authorization control
with the Transaction Start Request. If the client is not authorized
to assume the requested authorization identity, the server is to
return the authorizationDenied (123) resultCode in its response.
Otherwise, further processing of the request and transaction is
performed under the requested authorization identity.
Any proxied authorization request attached to an update request
specified as part of a transaction, or attached to a Transaction End
Request, is to be regarded as a protocol error.
<span class="h3"><a class="selflink" id="section-4.5" href="#section-4.5">4.5</a>. Read Entry Controls</span>
The Pre- and Post-Read Entry [<a href="./rfc4527" title=""Lightweight Directory Access Protocol (LDAP) Read Entry Controls"">RFC4527</a>] request control are
appropriate for use with update requests specified as part of a
transaction.
The response control produced in response to a Pre- or Post-Read
Entry request control is returned in the txnEndRes.updatesControls
field of responseValue of the End Transaction Response.
The Pre- and Post-Read Entry controls are inappropriate for use in
the LDAPMessage.controls field of the Transaction Start and End
Request and Response messages.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Distributed Directory Considerations</span>
The LDAP/X.500 models provide for distributed directory operations,
including server-side chaining and client-side chasing of referrals.
This document does not preclude servers from chaining operations that
are part of a transaction. However, if a server does attempt such
chaining, it MUST ensure that transaction semantics are provided.
The mechanism defined by this document does not support client-side
chasing. Transaction identifiers are specific to a particular LDAP
association (as established via the LDAP Bind operation).
<span class="grey">Zeilenga Experimental [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc5805">RFC 5805</a> LDAP Transactions March 2010</span>
The LDAP/X.500 models provide for a single-master/multiple-shadow
replication architecture. There is no requirement that changes made
to the directory based upon processing a transaction be replicated as
one atomic action. Hence, clients SHOULD NOT assume tight data
consistency nor fast data convergence of shadow copies unless they
have prior knowledge that these properties are provided. Note that
DontUseCopy control [<a href="#ref-DONTUSECOPY" title=""The LDAP Don't Use Copy Control"">DONTUSECOPY</a>] may be used in conjunction with the
LDAP search request to ask for the return of the authoritative copy
of the entry.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Security Considerations</span>
Transaction mechanisms may be the target of denial-of-service
attacks, especially where implementations lock shared resources for
the duration of a transaction.
General security considerations [<a href="./rfc4510" title=""Lightweight Directory Access Protocol (LDAP): Technical Specification Road Map"">RFC4510</a>], especially those
associated with update operations [<a href="./rfc4511" title=""Lightweight Directory Access Protocol (LDAP): The Protocol"">RFC4511</a>], apply to this extension.
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. IANA Considerations</span>
The Internet Assigned Numbers Authority (IANA) has made the following
assignments.
<span class="h3"><a class="selflink" id="section-7.1" href="#section-7.1">7.1</a>. Object Identifier</span>
IANA has assigned an LDAP Object Identifier (21) [<a href="./rfc4520" title=""Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access Protocol (LDAP)"">RFC4520</a>] to
identify the protocol elements specified in this document.
Subject: Request for LDAP Object Identifier Registration
Person & email address to contact for further information:
Kurt Zeilenga <Kurt.Zeilenga@Isode.COM>
Specification: <a href="./rfc5805">RFC 5805</a>
Author/Change Controller: Kurt Zeilenga <Kurt.Zeilenga@Isode.COM>
Comments: Identifies protocol elements for LDAP Transactions
<span class="grey">Zeilenga Experimental [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc5805">RFC 5805</a> LDAP Transactions March 2010</span>
<span class="h3"><a class="selflink" id="section-7.2" href="#section-7.2">7.2</a>. LDAP Protocol Mechanism</span>
IANA has registered the protocol mechanisms [<a href="./rfc4520" title=""Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access Protocol (LDAP)"">RFC4520</a>] specified in
this document.
Subject: Request for LDAP Protocol Mechanism Registration
Object Identifier: see table
Description: see table
Person & email address to contact for further information:
Kurt Zeilenga <Kurt.Zeilenga@Isode.COM>
Specification: <a href="./rfc5805">RFC 5805</a>
Author/Change Controller: Kurt Zeilenga <Kurt.Zeilenga@Isode.COM>
Comments:
Object Identifier Type Description
------------------- ---- ----------------------------------
1.3.6.1.1.21.1 E Start Transaction Extended Request
1.3.6.1.1.21.2 C Transaction Specification Control
1.3.6.1.1.21.3 E End Transaction Extended Request
1.3.6.1.1.21.4 N Aborted Transaction Notice
Legend
------------------------
C => supportedControl
E => supportedExtension
N => Unsolicited Notice
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. Acknowledgments</span>
The author gratefully acknowledges the contributions made by Internet
Engineering Task Force participants.
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. References</span>
<span class="h3"><a class="selflink" id="section-9.1" href="#section-9.1">9.1</a>. Normative References</span>
[<a id="ref-RFC2119">RFC2119</a>] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.
[<a id="ref-RFC3062">RFC3062</a>] Zeilenga, K., "LDAP Password Modify Extended
Operation", <a href="./rfc3062">RFC 3062</a>, February 2001.
[<a id="ref-RFC3296">RFC3296</a>] Zeilenga, K., "Named Subordinate References in
Lightweight Directory Access Protocol (LDAP)
Directories", <a href="./rfc3296">RFC 3296</a>, July 2002.
<span class="grey">Zeilenga Experimental [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc5805">RFC 5805</a> LDAP Transactions March 2010</span>
[<a id="ref-RFC4370">RFC4370</a>] Weltman, R., "Lightweight Directory Access Protocol
(LDAP) Proxied Authorization Control", <a href="./rfc4370">RFC 4370</a>,
February 2006.
[<a id="ref-RFC4510">RFC4510</a>] Zeilenga, K., Ed., "Lightweight Directory Access
Protocol (LDAP): Technical Specification Road Map", <a href="./rfc4510">RFC</a>
<a href="./rfc4510">4510</a>, June 2006.
[<a id="ref-RFC4511">RFC4511</a>] Sermersheim, J., Ed., "Lightweight Directory Access
Protocol (LDAP): The Protocol", <a href="./rfc4511">RFC 4511</a>, June 2006.
[<a id="ref-RFC4512">RFC4512</a>] Zeilenga, K., Ed., "Lightweight Directory Access
Protocol (LDAP): Directory Information Models", <a href="./rfc4512">RFC</a>
<a href="./rfc4512">4512</a>, June 2006.
[<a id="ref-RFC4527">RFC4527</a>] Zeilenga, K., "Lightweight Directory Access Protocol
(LDAP) Read Entry Controls", <a href="./rfc4527">RFC 4527</a>, June 2006.
[<a id="ref-RFC4528">RFC4528</a>] Zeilenga, K., "Lightweight Directory Access Protocol
(LDAP) Assertion Control", <a href="./rfc4528">RFC 4528</a>, June 2006.
[<a id="ref-X.680">X.680</a>] International Telecommunication Union -
Telecommunication Standardization Sector, "Abstract
Syntax Notation One (ASN.1) - Specification of Basic
Notation", X.680(2002) (also ISO/IEC 8824-1:2002).
[<a id="ref-X.690">X.690</a>] International Telecommunication Union -
Telecommunication Standardization Sector,
"Specification of ASN.1 encoding rules: Basic Encoding
Rules (BER), Canonical Encoding Rules (CER), and
Distinguished Encoding Rules (DER)", X.690(2002) (also
ISO/IEC 8825-1:2002).
<span class="h3"><a class="selflink" id="section-9.2" href="#section-9.2">9.2</a>. Informative References</span>
[<a id="ref-RFC4520">RFC4520</a>] Zeilenga, K., "Internet Assigned Numbers Authority
(IANA) Considerations for the Lightweight Directory
Access Protocol (LDAP)", <a href="https://www.rfc-editor.org/bcp/bcp64">BCP 64</a>, <a href="./rfc4520">RFC 4520</a>, June 2006.
[<a id="ref-ACID">ACID</a>] "Information technology -- Open Systems Interconnection
-- Distributed Transaction Processing -- Part 1: OSI TP
Model", <a href="#section-4">Section 4</a>, ISO/IEC 10026-1:1992.
[<a id="ref-DONTUSECOPY">DONTUSECOPY</a>] Zeilenga, K., <a style="text-decoration: none" href='https://www.google.com/search?sitesearch=datatracker.ietf.org%2Fdoc%2Fhtml%2F&q=inurl:draft-+%22The+LDAP+Don%27t+Use+Copy+Control%22'>"The LDAP Don't Use Copy Control"</a>, Work
in Progress, December 2009.
<span class="grey">Zeilenga Experimental [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc5805">RFC 5805</a> LDAP Transactions March 2010</span>
Author's Address
Kurt D. Zeilenga
Isode Limited
EMail: Kurt.Zeilenga@Isode.COM
Zeilenga Experimental [Page 11]
</pre>
|
