Expand PMF_FN_* macros.
[netbsd-mini2440.git] / external / bsd / openldap / dist / doc / drafts / draft-zeilenga-ldap-relax.txt
blobc656f9ed892207d6bfd98314fba25b0b657fed55
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>
17 Status of this Memo
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
52   for more information.
58 Zeilenga                LDAP Relax Rules Control                [Page 1]
60 INTERNET-DRAFT        draft-zeilenga-ldap-relax-01      14 February 2007
63 Abstract
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,
90   not transformed.
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.
126 1.1. Terminology
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
138   DSA-specific Entry.
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
145   TRUE.
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.
185 3.  Use Cases
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
199   request:
201       dn: o=Unit,dc=example,dc=net
202       control: IANA-ASSIGNED-OID
203       changetype: modify
204       delete: objectClass
205       objectClass: organization
206       -
207       add: objectClass
208       objectClass: organizationalUnit
209       -
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
234   the OBSOLETE field).
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
244   fail.
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
256   subschema [RFC4512].
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
309   attribute.
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
320       changetype: add
321       objectClass: organizationalUnit
322       ou: Unit
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
334       changetype: modify
338 Zeilenga                LDAP Relax Rules Control                [Page 6]
340 INTERNET-DRAFT        draft-zeilenga-ldap-relax-01      14 February 2007
343       replace: entryUUID
344       entryUUID: 597ae2f6-16a6-1027-98f4-d28b5365dc14
345       -
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'
356   value.  For instance:
358       dn: ou=Unit,dc=example,dc=net
359       control: IANA-ASSIGNED-OID
360       changetype: add
361       objectClass: organizationalUnit
362       ou: Unit
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
374       changetype: modify
375       replace: createTimestamp
376       createTimestamp: 20060101000000Z
377       -
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'
401   value.  For instance:
403       dn: ou=Unit,dc=example,dc=net
404       control: IANA-ASSIGNED-OID
405       changetype: add
406       objectClass: organizationalUnit
407       ou: Unit
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
420       changetype: modify
421       replace: modifyTimestamp
422       modifyTimestamp: 20060101000000Z
423       -
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
443       changetype: add
444       objectClass: organizationalUnit
445       ou: Unit
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
467       changetype: modify
468       replace: creatorsName
469       creatorsName: cn=Jane Doe,dc=example,net
470       -
471       replace: modifiersName
472       modifiersName: cn=Jane Doe,dc=example,net
473       -
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
488   extension.
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
497   document.
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>
523       Usage: Control
524       Specification: RFC XXXX
525       Author/Change Controller: Kurt Zeilenga <Kurt.Zeilenga@Isode.COM>
526       Comments: none
529 6.  Author's Address
531   Kurt D. Zeilenga
532   Isode Limited
534   Email: Kurt.Zeilenga@Isode.COM
537 7. References
539   [[Note to the RFC Editor: please replace the citation tags used in
540   referencing Internet-Drafts with tags of the form RFCnnnn where
541   possible.]]
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,
550                 December 2003.
552   [RFC4510]     Zeilenga, K. (editor), "LDAP: Technical Specification
553                 Road Map", RFC 4510, June 2006.
555   [RFC4511]     Sermersheim, J. (editor), "LDAP: The Protocol", RFC
556                 4511, June 2006.
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
571                 2006.
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
609   ietf-ipr@ietf.org.
613 Full Copyright
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]