6 INTERNET-DRAFT Kurt D. Zeilenga
7 Intended Category: Standard Track OpenLDAP Foundation
8 Expires in six months 10 February 2005
12 LDAP Read Entry Controls
13 <draft-zeilenga-ldap-readentry-04.txt>
16 1. Status of this Memo
18 This document is intended to be, after appropriate review and
19 revision, submitted to the RFC Editor as a Standard Track document.
20 Distribution of this memo is unlimited. Technical discussion of this
21 document will take place on the IETF LDAP Extensions mailing list
22 <ldapext@ietf.org>. Please send editorial comments directly to the
23 author <Kurt@OpenLDAP.org>.
25 By submitting this Internet-Draft, I accept the provisions of Section
26 4 of RFC 3667. By submitting this Internet-Draft, I certify that any
27 applicable patent or other IPR claims of which I am aware have been
28 disclosed, or will be disclosed, and any of which I become aware will
29 be disclosed, in accordance with RFC 3668.
31 Internet-Drafts are working documents of the Internet Engineering Task
32 Force (IETF), its areas, and its working groups. Note that other
33 groups may also distribute working documents as Internet-Drafts.
35 Internet-Drafts are draft documents valid for a maximum of six months
36 and may be updated, replaced, or obsoleted by other documents at any
37 time. It is inappropriate to use Internet-Drafts as reference material
38 or to cite them other than as "work in progress."
40 The list of current Internet-Drafts can be accessed at
41 http://www.ietf.org/1id-abstracts.html
43 The list of Internet-Draft Shadow Directories can be accessed at
44 http://www.ietf.org/shadow.html
47 Copyright (C) The Internet Society (2005). All Rights Reserved.
49 Please see the Full Copyright section near the end of this document
57 Zeilenga LDAP Read Entry Controls [Page 1]
59 INTERNET-DRAFT draft-zeilenga-ldap-readentry-04 10 February 2005
64 This document specifies an extension to the Lightweight Directory
65 Access Protocol (LDAP) to allow the client to read the target entry of
66 an update operation. The client may request to read the entry before
67 and/or after the modifications are applied. These reads are done as
68 an atomic part of the update operation.
71 1. Background and Intent of Use
73 This document specifies an extension to the Lightweight Directory
74 Access Protocol (LDAP) [Roadmap] to allow the client to read the
75 target entry of an update operation (e.g., Add, Delete, Modify,
76 ModifyDN). The extension utilizes controls [Protocol] attached to
77 update requests to request and return copies of the target entry. One
78 request control, called the Pre-Read request control, indicates that a
79 copy of the entry before application of update is to be returned.
80 Another control, called the Post-Read request control, indicates that
81 a copy of the entry after application of the update is to be returned.
82 Each request control has a corresponding response control used to
85 To ensure proper isolation, the controls are processed as an atomic
86 part of the update operation.
88 The functionality offered by these controls is based upon similar
89 functionality in the X.500 Directory Access Protocol (DAP) [X.511].
91 The Pre-Read controls may be used to obtain replaced or deleted values
92 of modified attributes or a copy of the entry being deleted.
94 The Post-Read controls may be used to obtain values of operational
95 attributes, such as the 'entryUUID' [EntryUUID] and 'modifyTimestamp'
96 [Models] attributes, updated by the server as part of the update
102 Protocol elements are described using ASN.1 [X.680] with implicit
103 tags. The term "BER-encoded" means the element is to be encoded using
104 the Basic Encoding Rules [X.690] under the restrictions detailed in
105 Section 5.2 of [Protocol].
107 DN stands for Distinguished Name.
108 DSA stands for Directory System Agent (i.e., a directory server).
109 DSE stands for DSA-specific Entry.
113 Zeilenga LDAP Read Entry Controls [Page 2]
115 INTERNET-DRAFT draft-zeilenga-ldap-readentry-04 10 February 2005
118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
120 document are to be interpreted as described in BCP 14 [RFC2119].
123 3. Read Entry Controls
125 3.1. The Pre-Read Controls
127 The Pre-Read request and response controls are identified by the
128 IANA-ASSIGNED-OID.1 object identifier. Servers implementing these
129 controls SHOULD publish IANA-ASSIGNED-OID.1 as a value of the
130 'supportedControl' [Models] in their root DSE.
132 The Pre-Read request control is an LDAP Control [Protocol] whose
133 controlType is IANA-ASSIGNED-OID.1 and whose controlValue is a
134 BER-encoded AttributeSelection [Protocol], as extended by [RFC3673].
135 The criticality may be TRUE or FALSE. This control is appropriate for
136 the modifyRequest, delRequest, and modDNRequest LDAP messages.
138 The corresponding response control is a LDAP Control whose controlType
139 is IANA-ASSIGNED-OID.1 and whose the controlValue, an OCTET STRING,
140 contains a BER-encoded SearchResultEntry. The criticality may be TRUE
141 or FALSE. This control is appropriate for the modifyResponse,
142 delResponse, and modDNResponse LDAP messages with a resultCode of
145 When the request control is attached to an appropriate update LDAP
146 request, the control requests the return of a copy of target entry
147 prior to the application of the update. The AttributeSelection
148 indicates, as discussed in [Protocol][RFC3673] which attributes are
149 requested to appear in the copy. The server is to return a
150 SearchResultEntry containing, subject to access controls and other
151 constraints, values of the requested attributes.
153 The normal processing of the update operation and the processing of
154 this control MUST be performed as one atomic action isolated from
155 other update operations.
157 If the update operation fails (in either normal or control
158 processing), no response control is provided.
161 3.2. The Post-Read Controls
163 The Post-Read request and response controls are identified by the
164 IANA-ASSIGNED-OID.2 object identifier. Servers implementing these
165 controls SHOULD publish IANA-ASSIGNED-OID.2 as a value of the
169 Zeilenga LDAP Read Entry Controls [Page 3]
171 INTERNET-DRAFT draft-zeilenga-ldap-readentry-04 10 February 2005
174 'supportedControl' [Models] in their root DSE.
176 The Post-Read request control is an LDAP Control [Protocol] whose
177 controlType is IANA-ASSIGNED-OID.2 and whose controlValue, an OCTET
178 STRING, contains a BER-encoded AttributeSelection [Protocol], as
179 extended by [RFC3673]. The criticality may be TRUE or FALSE. This
180 control is appropriate for the addRequest, modifyRequest, and
181 modDNRequest LDAP messages.
183 The corresponding response control is a LDAP Control whose controlType
184 is IANA-ASSIGNED-OID.2 and whose controlValue is a BER-encoded
185 SearchResultEntry. The criticality may be TRUE or FALSE. This
186 control is appropriate for the addResponse, modifyResponse, and
187 modDNResponse LDAP messages with a resultCode of success (0).
189 When the request control is attached to an appropriate update LDAP
190 request, the control requests the return of a copy of target entry
191 after the application of the update. The AttributeSelection
192 indicates, as discussed in [Protocol][RFC3673], which attributes are
193 requested to appear in the copy. The server is to return a
194 SearchResultEntry containing, subject to access controls and other
195 constraints, values of the requested attributes.
197 The normal processing of the update operation and the processing of
198 this control MUST be performed as one atomic action isolated from
199 other update operations.
201 If the update operation fails (in either normal or control
202 processing), no response control is provided.
205 4. Interaction with other controls
207 The Pre-Read and Post-Read controls may be combined with each other
208 and/or with a variety of other controls. When combined with the
209 assertion control [Assertion] and/or the manageDsaIT control
210 [RFC3296], the semantics of each control included in the combination
211 apply. The Pre-Read and Post-Read controls may be combined with other
212 controls as detailed in other technical specifications.
215 5. Security Considerations
217 The controls defined in this document extend update operations to
218 support read capabilities. Servers MUST ensure that the client is
219 authorized both for reading of the information provided in this
220 control in addition to ensuring the client is authorized to perform
221 the requested directory update.
225 Zeilenga LDAP Read Entry Controls [Page 4]
227 INTERNET-DRAFT draft-zeilenga-ldap-readentry-04 10 February 2005
230 Security considerations for the update operations [Protocol] extended
231 by this control, as well as general LDAP security considerations
232 [Roadmap], generally apply to implementation and use of this extension
235 6. IANA Considerations
237 Registration of the following protocol values [BCP64bis] is requested.
240 6.1. Object Identifier
242 It is requested that IANA register an LDAP Object Identifier to
243 identify LDAP protocol elements defined in this document.
245 Subject: Request for LDAP Object Identifier Registration
246 Person & email address to contact for further information:
247 Kurt Zeilenga <kurt@OpenLDAP.org>
248 Specification: RFC XXXX
249 Author/Change Controller: IESG
251 Identifies the LDAP Read Entry Controls
254 6.2. LDAP Protocol Mechanisms
256 It is requested that IANA register the LDAP Protocol Mechanism
257 described in this document.
259 Subject: Request for LDAP Protocol Mechanism Registration
260 Object Identifier: IANA-ASSIGNED-OID.1
261 Description: LDAP Pre-read Control
262 Person & email address to contact for further information:
263 Kurt Zeilenga <kurt@openldap.org>
265 Specification: RFC XXXX
266 Author/Change Controller: IESG
270 Subject: Request for LDAP Protocol Mechanism Registration
271 Object Identifier: IANA-ASSIGNED-OID.2
272 Description: LDAP Post-read Control
273 Person & email address to contact for further information:
274 Kurt Zeilenga <kurt@openldap.org>
276 Specification: RFC XXXX
277 Author/Change Controller: IESG
281 Zeilenga LDAP Read Entry Controls [Page 5]
283 INTERNET-DRAFT draft-zeilenga-ldap-readentry-04 10 February 2005
291 The LDAP Pre-Read and Post-Read controls are modeled after similar
292 capabilities offered in the DAP [X.511].
297 [[Note to the RFC Editor: please replace the citation tags used in
298 referencing Internet-Drafts with tags of the form RFCnnnn where
302 8.1. Normative References
304 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
305 Requirement Levels", BCP 14 (also RFC 2119), March 1997.
307 [Roadmap] Zeilenga, K. (editor), "LDAP: Technical Specification
308 Road Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in
311 [Protocol] Sermersheim, J. (editor), "LDAP: The Protocol",
312 draft-ietf-ldapbis-protocol-xx.txt, a work in progress.
314 [Models] Zeilenga, K. (editor), "LDAP: Directory Information
315 Models", draft-ietf-ldapbis-models-xx.txt, a work in
318 [RFC3296] Zeilenga, K., "Named Subordinate References in
319 Lightweight Directory Access Protocol (LDAP)
320 Directories", RFC 3296, July 2002.
322 [RFC3673] Zeilenga, K., "LDAPv3: All Operational Attributes", RFC
325 [Assertion] Zeilenga, K., "LDAP Assertion Control",
326 draft-zeilenga-ldap-assert-xx.txt, a work in progress.
328 [X.680] International Telecommunication Union -
329 Telecommunication Standardization Sector, "Abstract
330 Syntax Notation One (ASN.1) - Specification of Basic
331 Notation", X.680(1997) (also ISO/IEC 8824-1:1998).
333 [X.690] International Telecommunication Union -
337 Zeilenga LDAP Read Entry Controls [Page 6]
339 INTERNET-DRAFT draft-zeilenga-ldap-readentry-04 10 February 2005
342 Telecommunication Standardization Sector, "Specification
343 of ASN.1 encoding rules: Basic Encoding Rules (BER),
344 Canonical Encoding Rules (CER), and Distinguished
345 Encoding Rules (DER)", X.690(1997) (also ISO/IEC
349 8.2. Informative References
351 [BCP64bis] Zeilenga, K., "IANA Considerations for LDAP",
352 draft-ietf-ldapbis-bcp64-xx.txt, a work in progress.
354 [EntryUUID] Zeilenga, K., "The LDAP EntryUUID Operational
355 Attribute", draft-zeilenga-ldap-uuid-xx.txt, a work in
358 [X.511] International Telecommunication Union -
359 Telecommunication Standardization Sector, "The
360 Directory: Abstract Service Definition", X.511(1993)
361 (also ISO/IEC 9594-3:1993).
369 Email: Kurt@OpenLDAP.org
373 Intellectual Property Rights
375 The IETF takes no position regarding the validity or scope of any
376 Intellectual Property Rights or other rights that might be claimed to
377 pertain to the implementation or use of the technology described in
378 this document or the extent to which any license under such rights
379 might or might not be available; nor does it represent that it has
380 made any independent effort to identify any such rights. Information
381 on the procedures with respect to rights in RFC documents can be found
382 in BCP 78 and BCP 79.
384 Copies of IPR disclosures made to the IETF Secretariat and any
385 assurances of licenses to be made available, or the result of an
386 attempt made to obtain a general license or permission for the use of
387 such proprietary rights by implementers or users of this specification
388 can be obtained from the IETF on-line IPR repository at
389 http://www.ietf.org/ipr.
393 Zeilenga LDAP Read Entry Controls [Page 7]
395 INTERNET-DRAFT draft-zeilenga-ldap-readentry-04 10 February 2005
398 The IETF invites any interested party to bring to its attention any
399 copyrights, patents or patent applications, or other proprietary
400 rights that may cover technology that may be required to implement
401 this standard. Please address the information to the IETF at
408 Copyright (C) The Internet Society (2005). This document is subject
409 to the rights, licenses and restrictions contained in BCP 78, and
410 except as set forth therein, the authors retain all their rights.
412 This document and the information contained herein are provided on an
413 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
414 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
415 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
416 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
417 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
418 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
449 Zeilenga LDAP Read Entry Controls [Page 8]