7 INTERNET-DRAFT Kurt D. Zeilenga
8 Intended Category: Experimental Isode Limited
9 Expires in six months 14 February 2007
13 The LDAP Relax Rules Control
14 <draft-zeilenga-ldap-relax-01.txt>
19 This document is intended to be, after appropriate review and
20 revision, submitted to the RFC Editor for publication as an
21 Experimental document. Distribution of this memo is unlimited.
22 Technical discussion of this document will take place on the IETF LDAP
23 Extensions mailing list <ldapext@ietf.org>. Please send editorial
24 comments directly to the author <Kurt.Zeilenga@Isode.COM>.
26 This document replaces draft-zeilenga-ldap-managedit-xx.txt.
28 By submitting this Internet-Draft, each author represents that any
29 applicable patent or other IPR claims of which he or she is aware have
30 been or will be disclosed, and any of which he or she becomes aware
31 will be disclosed, in accordance with Section 6 of BCP 79.
33 Internet-Drafts are working documents of the Internet Engineering Task
34 Force (IETF), its areas, and its working groups. Note that other
35 groups may also distribute working documents as Internet-Drafts.
37 Internet-Drafts are draft documents valid for a maximum of six months
38 and may be updated, replaced, or obsoleted by other documents at any
39 time. It is inappropriate to use Internet-Drafts as reference material
40 or to cite them other than as "work in progress."
42 The list of current Internet-Drafts can be accessed at
43 http://www.ietf.org/1id-abstracts.html.
45 The list of Internet-Draft Shadow Directories can be accessed at
46 http://www.ietf.org/shadow.html.
49 Copyright (C) The IETF Trust (2007). All Rights Reserved.
51 Please see the Full Copyright section near the end of this document
58 Zeilenga LDAP Relax Rules Control [Page 1]
60 INTERNET-DRAFT draft-zeilenga-ldap-relax-01 14 February 2007
65 This document defines the Lightweight Directory Access Protocol (LDAP)
66 Relax Rules Control which allows a directory user agent (a client) to
67 request the directory service temporarily relax enforcement of various
68 data and service model rules.
71 1. Background and Intended Use
73 Directory servers accessible via Lightweight Directory Access Protocol
74 (LDAP) [RFC4510] are expected to act in accordance with the X.500
75 [X.500] series of ITU-T Recommendations. In particular, servers are
76 expected to ensure the X.500 data and service models are not violated.
78 An LDAP server is expected to prevent modification of the structural
79 object class of an object [RFC4512]. That is, the X.500 models do not
80 allow a 'person' object to be transformed into an
81 'organizationalPerson' object through modification of the object.
82 Instead, the 'person' object must be deleted and then a new
83 'organizationalPerson' object created in its place. This approach,
84 aside from being inconvient, is problematic for a number reasons.
85 First, as LDAP does not have a standardized method for performing the
86 two operations in a single transaction, the intermediate directory
87 state (after the delete, before the add) is visible to other clients,
88 which may lead to undesirable client behavior. Second, attributes
89 such as 'entryUUID' [RFC4530] will reflect the object was replaced,
92 An LDAP server is expected to prevent clients from modifying values of
93 NO-USER-MODIFICATION attributes [RFC4512]. For instance, an entry is
94 not allowed to assign or modify the value of the 'entryUUID'
95 attribute. However, where an administrator is restoring a previously
96 existing object, for instance when repartitioning data between
97 directory servers or when migrating from one vendor server product to
98 another, it may be desirable to allow the client to assign or modify
99 the value of the 'entryUUID' attribute.
101 This document defines the LDAP Relax Rules control. This control may
102 be attached to LDAP requests to update the Directory Information Tree
103 (DIT) to request various data and service rules be temporarily relaxed
104 during the performance of the requested DIT update. The server is
105 however to ensure the resulting directory state is valid.
107 Use of this control is expected that use of this extension will be
108 restricted by administrative and/or access controls. It is intended
109 to be used primarily by directory administrators.
114 Zeilenga LDAP Relax Rules Control [Page 2]
116 INTERNET-DRAFT draft-zeilenga-ldap-relax-01 14 February 2007
119 This extension is considered experimental as it is not yet clear
120 whether it adequately addresses directory administrators' needs for
121 flexible mechanisms for managing directory objects. It is hoped that
122 after suitable amount of time, either this extension or a suitable
123 replacement will be standardization.
128 Protocol elements are described using ASN.1 [X.680] with implicit
129 tags. The term "BER-encoded" means the element is to be encoded using
130 the Basic Encoding Rules [X.690] under the restrictions detailed in
131 Section 5.1 of [RFC4511].
133 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
134 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
135 document are to be interpreted as described in BCP 14 [RFC2119].
137 DSA stands for Directory System Agent, a server. DSE stands for
141 2. The Relax Rules Control
143 The Relax Rules control is an LDAP Control [RFC4511] whose controlType
144 is IANA-ASSIGNED-OID, controlValue is empty, and the criticality of
147 There is no corresponding response control.
149 The control is appropriate for all LDAP update requests, including
150 add, delete, modify, and modifyDN (rename) [RFC4511].
152 The presence of the Rules Rules control in an LDAP update request
153 indicates the server temporarily relax X.500 model contraints during
154 performance of the directory update.
156 The server may restrict use of this control and/or limit the extent of
157 the relaxation provided based upon local policy or factors.
159 The server is obligated to ensure the resulting directory state is
160 consistent with the X.500 models. For instance, the server ensure
161 that values of attributes conform to the value syntax.
163 It is noted that while this extension may be used to add or modify
164 objects in a manner which violate the controlling subschema, the
165 presence of objects in the DIT is not inconsistent with the X.500
166 models. For instance, an object created prior to establshment of a
170 Zeilenga LDAP Relax Rules Control [Page 3]
172 INTERNET-DRAFT draft-zeilenga-ldap-relax-01 14 February 2007
175 DIT content rule may contain an attribute now precluded by the current
176 controlling DIT Content Rule.
178 Servers implementing this technical specification SHOULD publish the
179 object identifier IANA-ASSIGNED-OID as a value of the
180 'supportedControl' attribute [RFC4512] in their root DSE. A server
181 MAY choose to advertise this extension only when the client is
182 authorized to use it.
187 3.1. Object metamorphism
189 In absence of this control, an attempt to modify an object's
190 'objectClass' in a manner which cause a change in the structural
191 object class of the object would normally lead to an
192 objectClassModsProhibited error [RFC4511]. The presence of the Relax
193 Rules control in the modify request requests the change be allowed.
194 If the server is willing and able to allow the change in the
195 structural object class of the object.
197 For instance, to change an 'organization' object into an
198 'organizationalUnit' object, a client could issue the following LDAP
201 dn: o=Unit,dc=example,dc=net
202 control: IANA-ASSIGNED-OID
205 objectClass: organization
208 objectClass: organizationalUnit
211 In this case, the server is expected to either effect the requested
212 change in the structural object class, including updating of the value
213 of the structural object class, or fail the operation.
216 3.2. Inactive Attribute Types
218 In absence of the Relax Rules control, an attempt to add or modify
219 values to an attribute whose type has been marked inactive in the
220 controlling subschema (its attribute type description contains the
221 OBSOLETE field) [RFC4512] normally results in a failure.
226 Zeilenga LDAP Relax Rules Control [Page 4]
228 INTERNET-DRAFT draft-zeilenga-ldap-relax-01 14 February 2007
231 In the presence of the Relax Rules control, the server performs the
232 update operation as if the attribute's type is marked active in the
233 controlling subschema (its attribute type description does not contain
237 3.3. DIT Content Rules
239 In absence of the Relax Rules control, an attempt to include the name
240 (or OID) of an auxiliary class to an object's 'objectClass' which is
241 not allowed by the controlling DIT Content Rule would be disallowed
242 [RFC4512]. Additionally, an attempt to add values of an attribute
243 not allowed (or explicitly precluded) by the DIT Content Rule would
246 In presence of the Relax Rules control, the server performs the update
247 operation as if the controlling DIT Content Rule allowed any and all
248 known auxiliary classses to be present and allowed any and all known
249 attributes to be present (and precluded no attributes).
252 3.4. DIT Structure Rules and Name Forms
254 In absence of the Relax Rules control, the service enforces DIT
255 structure rules and name form requirements of the controlling
258 In the presence of the Relax Rules control, the server performs the
259 update operation ignoring all DIT structure rules and name forms in
260 the controlling subschema.
263 3.5. Modification of Nonconformant Objects
265 It is also noted that in absense of this control, modification of an
266 object which presently violates the controlling subschema will fail
267 unless the modification would result in the object conforming to the
268 controlling subschema. That is, modifications of an non-conformant
269 object should result in a conformant object.
271 In the presence of this control, modifications of a non-conformant
272 object need not result in a conformant object.
275 3.6. NO-USER-MODIFICATION attribute modification
277 In absence of this control, an attempt to modify values of a
278 NO-USER-MODIFICATION attribute [RFC4512] would normally lead to a
282 Zeilenga LDAP Relax Rules Control [Page 5]
284 INTERNET-DRAFT draft-zeilenga-ldap-relax-01 14 February 2007
287 constraintViolation or other appropriate error [RFC4511]. In the
288 presence of the Relax Rules control in the update request requests the
289 modification be allowed.
291 Relaxation of the NO-USER-MODIFICATION constraint is not appropriate
292 for some operational attribute types. For instance, as the value of
293 the 'structuralObjectClass' is derived by the values of the
294 'objectClass' attribute, the 'structuralObjectClass' attribute type's
295 NO-USER-MODIFICATION contraint MUST NOT be relaxed. To effect a
296 change in the structuralObjectClass class, values of objectClass
297 should be changed as discussed in Section 3.1. Other attributes for
298 which the NO-USER-MODIFICATION constraint should not be relaxed
299 include 'subschemaSubentry' [RFC4512] and
300 'collectiveAttributeSubentries' [RFC3671].
302 The subsections of this section discuss modification of various
303 operational attributes where their NO-USER-MODIFICATION constraint may
304 be relaxed. Future documents may specify where NO-USER-MODIFICATION
305 constraints on other operational attribute may be relaxed. In absence
306 of a document detailing that the NO-USER-MODIFICATION constraint on a
307 particular operational attribute may be relaxed, implementors SHOULD
308 assume relaxation of the constraint is not appropriate for that
312 3.1.1. 'entryUUID' attribute
314 To provide a value for the 'entryUUID' [RFC4530] attribute on entry
315 creation, the client should issue an LDAP Add request with a Relax
316 Rules control providing the desired value. For instance:
318 dn: ou=Unit,dc=example,dc=net
319 control: IANA-ASSIGNED-OID
321 objectClass: organizationalUnit
323 entryUUID: 597ae2f6-16a6-1027-98f4-d28b5365dc14
325 In this case, the server is either to add the entry using the
326 provided 'entryUUID' value or fail the request.
328 To provide a replacement value for the 'entryUUID' after entry
329 creation, the client should issue an LDAP Modify request with a
330 Relax Rules control including an approrpiate change. For instance:
332 dn: ou=Unit,dc=example,dc=net
333 control: IANA-ASSIGNED-OID
338 Zeilenga LDAP Relax Rules Control [Page 6]
340 INTERNET-DRAFT draft-zeilenga-ldap-relax-01 14 February 2007
344 entryUUID: 597ae2f6-16a6-1027-98f4-d28b5365dc14
347 In this case, the server is either to replace the 'entryUUID' value
348 as requested or fail the request.
351 3.2.2. createTimestamp
353 To provide a value for the 'createTimestamp' [RFC4512] attribute
354 on entry creation, the client should issue an LDAP Add request with
355 a Relax Rules control providing the desired 'createTimestamp'
358 dn: ou=Unit,dc=example,dc=net
359 control: IANA-ASSIGNED-OID
361 objectClass: organizationalUnit
363 createTimestamp: 20060101000000Z
365 In this case, the server is either to add the entry using the
366 provided 'createTimestamp' value or fail the request.
368 To provide a replacement value for the 'createTimestamp' after
369 entry creation, the client should issue an LDAP Modify request with
370 a Relax Rules control including an approrpiate change. For instance:
372 dn: ou=Unit,dc=example,dc=net
373 control: IANA-ASSIGNED-OID
375 replace: createTimestamp
376 createTimestamp: 20060101000000Z
379 In this case, the server is either to replace the 'createTimestamp'
380 value as requested or fail the request.
382 The server should ensure the requested 'createTimestamp' value is
383 appropriate. In particular, it should fail the request if the
384 requested 'createTimestamp' value is in the future or is greater
385 than the value of the 'modifyTimestamp' attribute.
388 3.2.3. modifyTimestamp
390 To provide a value for the 'modifyTimestamp' [RFC4512] attribute
394 Zeilenga LDAP Relax Rules Control [Page 7]
396 INTERNET-DRAFT draft-zeilenga-ldap-relax-01 14 February 2007
399 on entry creation, the client should issue an LDAP Add request with
400 a Relax Rules control providing the desired 'modifyTimestamp'
403 dn: ou=Unit,dc=example,dc=net
404 control: IANA-ASSIGNED-OID
406 objectClass: organizationalUnit
408 modifyTimestamp: 20060101000000Z
410 In this case, the server is either to add the entry using
411 the provided 'modifyTimestamp' value or fail the request.
413 To provide a replacement value for the 'modifyTimestamp' after
414 entry creation, the client should issue an LDAP Modify
415 request with a Relax Rules control including an approrpiate
416 change. For instance:
418 dn: ou=Unit,dc=example,dc=net
419 control: IANA-ASSIGNED-OID
421 replace: modifyTimestamp
422 modifyTimestamp: 20060101000000Z
425 In this case, the server is either to replace the 'modifyTimestamp'
426 value as requested or fail the request.
428 The server should ensure the requested 'modifyTimestamp' value is
429 appropriate. In particular, it should fail the request if the
430 requested 'modifyTimestamp' value is in the future or is less than
431 the value of the 'createTimestamp' attribute.
434 3.2.3. creatorsName and modifiersName
436 To provide a value for the 'creatorsName' and/or 'modifiersName'
437 [RFC4512] attribute on entry creation, the client should issue an
438 LDAP Add request with a Relax Rules control providing the desired
439 values. For instance:
441 dn: ou=Unit,dc=example,dc=net
442 control: IANA-ASSIGNED-OID
444 objectClass: organizationalUnit
446 creatorsName: cn=Jane Doe,dc=example,net
450 Zeilenga LDAP Relax Rules Control [Page 8]
452 INTERNET-DRAFT draft-zeilenga-ldap-relax-01 14 February 2007
455 modifiersName: cn=Jane Doe,dc=example,net
457 In this case, the server is either to add the entry using
458 the provided values or fail the request.
460 To provide a replacement values after entry creation for either of
461 the 'creatorsName' or 'modifiersName' attributes or both, the
462 client should issue an LDAP Modify request with a Relax Rules control
463 including the approrpiate changes. For instance:
465 dn: ou=Unit,dc=example,dc=net
466 control: IANA-ASSIGNED-OID
468 replace: creatorsName
469 creatorsName: cn=Jane Doe,dc=example,net
471 replace: modifiersName
472 modifiersName: cn=Jane Doe,dc=example,net
475 In this case, the server is either to replace the provided
476 values as requested or fail the request.
479 4. Security Considerations
481 Use of this extension should be subject to appropriate administrative
482 and access controls. Use of this mechanism is intended to be
483 restricted to directory administrators.
485 Security considerations for the base operations [RFC4511] extended
486 by this control, as well as general LDAP security considerations
487 [RFC4510], generally apply to implementation and use of this
491 5. IANA Considerations
493 5.1. Object Identifier
495 It is requested that the IANA assign a LDAP Object Identifier
496 [RFC4520] to identify the LDAP Relax Rules Control defined in this
499 Subject: Request for LDAP Object Identifier Registration
500 Person & email address to contact for further information:
501 Kurt Zeilenga <Kurt.Zeilenga@Isode.COM>
502 Specification: RFC XXXX
506 Zeilenga LDAP Relax Rules Control [Page 9]
508 INTERNET-DRAFT draft-zeilenga-ldap-relax-01 14 February 2007
511 Author/Change Controller: Kurt Zeilenga <Kurt.Zeilenga@Isode.COM>
512 Comments: Identifies the LDAP Relax Rules Control
514 5.2 LDAP Protocol Mechanism
516 Registration of this protocol mechanism [RFC4520] is requested.
518 Subject: Request for LDAP Protocol Mechanism Registration
519 Object Identifier: IANA-ASSIGNED-OID
520 Description: Relax Rules Control
521 Person & email address to contact for further information:
522 Kurt Zeilenga <Kurt.Zeilenga@Isode.COM>
524 Specification: RFC XXXX
525 Author/Change Controller: Kurt Zeilenga <Kurt.Zeilenga@Isode.COM>
534 Email: Kurt.Zeilenga@Isode.COM
539 [[Note to the RFC Editor: please replace the citation tags used in
540 referencing Internet-Drafts with tags of the form RFCnnnn where
544 7.1. Normative References
546 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
547 Requirement Levels", BCP 14 (also RFC 2119), March 1997.
549 [RFC3671] Zeilenga, K., "Collective Attributes in LDAP", RFC 3671,
552 [RFC4510] Zeilenga, K. (editor), "LDAP: Technical Specification
553 Road Map", RFC 4510, June 2006.
555 [RFC4511] Sermersheim, J. (editor), "LDAP: The Protocol", RFC
558 [RFC4512] Zeilenga, K. (editor), "LDAP: Directory Information
562 Zeilenga LDAP Relax Rules Control [Page 10]
564 INTERNET-DRAFT draft-zeilenga-ldap-relax-01 14 February 2007
567 Models", RFC 4512, June 2006.
569 [RFC4530] Zeilenga, K., "Lightweight Directory Access Protocol
570 (LDAP) entryUUID Operational Attribute", RFC 4530, June
573 [X.500] International Telecommunication Union -
574 Telecommunication Standardization Sector, "The Directory
575 -- Overview of concepts, models and services,"
576 X.500(1993) (also ISO/IEC 9594-1:1994).
579 7.2. Informative References
581 [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority
582 (IANA) Considerations for the Lightweight Directory
583 Access Protocol (LDAP)", RFC 4520, BCP 64, June 2006.
587 Intellectual Property
589 The IETF takes no position regarding the validity or scope of any
590 Intellectual Property Rights or other rights that might be claimed to
591 pertain to the implementation or use of the technology described in
592 this document or the extent to which any license under such rights
593 might or might not be available; nor does it represent that it has
594 made any independent effort to identify any such rights. Information
595 on the procedures with respect to rights in RFC documents can be found
596 in BCP 78 and BCP 79.
598 Copies of IPR disclosures made to the IETF Secretariat and any
599 assurances of licenses to be made available, or the result of an
600 attempt made to obtain a general license or permission for the use of
601 such proprietary rights by implementers or users of this specification
602 can be obtained from the IETF on-line IPR repository at
603 http://www.ietf.org/ipr.
605 The IETF invites any interested party to bring to its attention any
606 copyrights, patents or patent applications, or other proprietary
607 rights that may cover technology that may be required to implement
608 this standard. Please address the information to the IETF at
618 Zeilenga LDAP Relax Rules Control [Page 11]
620 INTERNET-DRAFT draft-zeilenga-ldap-relax-01 14 February 2007
623 Copyright (C) The IETF Trust (2007).
625 This document is subject to the rights, licenses and restrictions
626 contained in BCP 78, and except as set forth therein, the authors
627 retain all their rights.
629 This document and the information contained herein are provided on an
630 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
631 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
632 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
633 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
634 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
635 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
674 Zeilenga LDAP Relax Rules Control [Page 12]