openldap/doc/drafts/draft-zeilenga-ldap-managedit-xx.txt

INTERNET-DRAFT                                   Kurt D. Zeilenga
Intended Category: Experimental                  OpenLDAP Foundation
Expires in six months                            27 February 2006



            The LDAP Manage Directory Information Tree Control
                  <draft-zeilenga-ldap-managedit-00.txt>


Status of this Memo

  This document is intended to be, after appropriate review and
  revision, submitted to the RFC Editor for publication as an
  Experimental document.   Distribution of this memo is unlimited.
  Technical discussion of this document will take place on the IETF LDAP
  Extensions mailing list <ldapext@ietf.org>.  Please send editorial
  comments directly to the author <Kurt@OpenLDAP.org>.

  By submitting this Internet-Draft, each author represents that any
  applicable patent or other IPR claims of which he or she is aware have
  been or will be disclosed, and any of which he or she becomes aware
  will be disclosed, in accordance with Section 6 of BCP 79.

  Internet-Drafts are working documents of the Internet Engineering Task
  Force (IETF), its areas, and its working groups. Note that other
  groups may also distribute working documents as Internet-Drafts.

  Internet-Drafts are draft documents valid for a maximum of six months
  and may be updated, replaced, or obsoleted by other documents at any
  time. It is inappropriate to use Internet-Drafts as reference material
  or to cite them other than as "work in progress."

  The list of current Internet-Drafts can be accessed at
  http://www.ietf.org/1id-abstracts.html

  The list of Internet-Draft Shadow Directories can be accessed at
  http://www.ietf.org/shadow.html


  Copyright (C) The Internet Society (2006).  All Rights Reserved.

  Please see the Full Copyright section near the end of this document
  for more information.







Zeilenga                 LDAP Manage DIT Control                [Page 1]

INTERNET-DRAFT      draft-zeilenga-ldap-managedit-00    27 February 2006


Abstract

  This document defines the Lightweight Directory Access Protocol (LDAP)
  Manage Directory Information Tree (DIT) Control which allows a
  directory user agent (a client) to request the directory service
  temporarily relax enforcement of constraints of the X.500 models.


1.  Background and Intended Use

  Directory servers accessible via Lightweight Directory Access Protocol
  (LDAP) [Roadmap] are expected to act in accordance with the X.500
  series of ITU-T Recommendations.  In particular, servers are expected
  to ensure the X.500 data and service models are not violated.

  An LDAP server is expected to prevent modification of the structural
  object class of an object [Models].  That is, the X.500 models do not
  allow a 'person' object to be transformed into an
  'organizationalPerson' object through modification of the object.
  Instead, the 'person' object must be deleted and then a new
  'organizationalPerson' object created in its place.  This approach,
  aside from being inconvient, is problematic for a number reasons.
  First, as LDAP does not have a standardized method for performing the
  two operations in a single transaction, the intermediate directory
  state (after the delete, before the add) is visible to other clients,
  which may lead to undesirable client behavior.  Second, attributes
  such as entryUUID [entryUUID] will reflect the object was replaced,
  not transformed.

  An LDAP server is expected to prevent clients from modifying values of
  NO-USER-MODIFICATION attributes [Models].  For instance, an entry is
  not allowed to assign or modify the value of the entryUUID attribute.
  However, where an administrator is restoring a previously existing
  object, for instance when repartitioning data between directory
  servers or when migrating from one vendor server product to another,
  it may be desirable to allow the client to assign or modify the value
  of the entryUUID attribute.

  This document specifies the Manage Directory Information Tree (DIT)
  control.  The Manage DIT control may be attached to LDAP requests to
  update the DIT to request DIT restrictions be temporarily relaxed
  during the performance of the requested DIT update.  The server is
  however to ensure the resulting directory state is valid.

  Use of this control is expected that use of this extension will be
  restricted by administrative and/or access controls.  It is intended
  to be used by directory administrators.




Zeilenga                 LDAP Manage DIT Control                [Page 2]

INTERNET-DRAFT      draft-zeilenga-ldap-managedit-00    27 February 2006


  This extension is considered experimental as it is not yet clear
  whether it adequately addresses directory administrators' needs for
  flexible mechanisms for managing directory objects.  It is hoped that
  after suitable amount of time, either this extension or a suitable
  replacement will be standardization.


1.1. Terminology

  Protocol elements are described using ASN.1 [X.680] with implicit
  tags.  The term "BER-encoded" means the element is to be encoded using
  the Basic Encoding Rules [X.690] under the restrictions detailed in
  Section 5.2 of [Protocol].

  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 BCP 14 [RFC2119].

  DSA stands for Directory System Agent, a server.  DSE stands for DSA-
  specific Entry.


2.  The Manage DIT Control

  The Manage DIT control is an LDAP Control [Protocol] whose controlType
  is IANA-ASSIGNED-OID, controlValue is empty, and the criticality of
  TRUE.

  There is no corresponding response control.

  The control is appropriate for all LDAP update requests, including
  add, delete, modify, and modifyDN (rename) [Protocol].

  The presence of the Manage DIT control in an LDAP update request
  indicates the server temporarily relax X.500 model contraints during
  performance of the directory update.

  The server may restrict use of this control and/or limit the extent of
  the relaxation provided based upon local policy or factors.

  The server is obligated to ensure the resulting directory state is
  consistent with the X.500 models.  For instance, the server ensure
  that values of attributes conform to the value syntax.

  It is noted that while this extension may be used to add or modify
  objects in a manner which violate the controlling subschema, the
  presence of objects in the DIT is not inconsistent with the X.500
  models.  For instance, an object created prior to establshment of a



Zeilenga                 LDAP Manage DIT Control                [Page 3]

INTERNET-DRAFT      draft-zeilenga-ldap-managedit-00    27 February 2006


  DIT content rule may contain an attribute now precluded by the current
  controlling DIT Content Rule.

  Servers implementing this technical specification SHOULD publish the
  object identifier IANA-ASSIGNED-OID as a value of the
  'supportedControl' attribute [Models] in their root DSE.  A server MAY
  choose to advertise this extension only when the client is authorized
  to use it.


3.  Use Cases

3.1. Object metamorphism

  In absence of this control, an attempt to modify an object's
  'objectClass' in a manner which cause a change in the structural
  object class of the object would normally lead to an
  objectClassModsProhibited error [Protocol].  The presence of the
  Manage DIT control in the modify request requests the change be
  allowed.  If the server is willing and able to allow the change in the
  structural object class of the object.

  For instance, to change an 'organization' object into an
  'organizationalUnit' object, a client could issue the following LDAP
  request:

      dn: o=Unit,dc=example,dc=net
      control: IANA-ASSIGNED-OID
      changetype: modify
      delete: objectClass
      objectClass: organization
      -
      add: objectClass
      objectClass: organizationalUnit
      -

  In this case, the server is expected to either effect the requested
  change in the structural object class, including updating of the value
  of the structural object class, or fail the operation.


3.2. Inactive Attribute Types

  In absence of the Manage DIT control, an attempt to add or modify
  values to an attribute whose type has been marked inactive in the
  controlling subschema (its attribute type description contains the
  OBSOLETE field) [Models] normally results in a failure.




Zeilenga                 LDAP Manage DIT Control                [Page 4]

INTERNET-DRAFT      draft-zeilenga-ldap-managedit-00    27 February 2006


  In the presence of the Manage DIT control, the server performs the
  update operation as if the attribute's type is marked active in the
  controlling subschema (its attribute type description does not contain
  the OBSOLETE field).


3.3. DIT Content Rules

  In absence of the Manage DIT control, an attempt to include the name
  (or OID) of an auxiliary class to an object's 'objectClass' which is
  not allowed by the controlling DIT Content Rule would be disallowed
  [Models].   Additionally, an attempt to add values of an attribute not
  allowed (or explicitly precluded) by the DIT Content Rule would fail.

  In presence of the Manage DIT control, the server performs the update
  operation as if the controlling DIT Content Rule allowed any and all
  known auxiliary classses to be present and allowed any and all known
  attributes to be present (and precluded no attributes).


3.4. DIT Structure Rules and Name Forms

  In absence of the Manage DIT control, the service enforces DIT
  structure rules and name form requirements of the controlling
  subschema [Models].

  In the presence of the Manage DIT control, the server performs the
  update operation ignoring all DIT structure rules and name forms in
  the controlling subschema.


3.5. Modification of Nonconformant Objects

  It is also noted that in absense of this control, modification of an
  object which presently violates the controlling subschema will fail
  unless the modification would result in the object conforming to the
  controlling subschema.  That is, modifications of an non-conformant
  object should result in a conformant object.

  In the presence of this control, modifications of a non-conformant
  object need not result in a conformant object.


3.6. NO-USER-MODIFICATION attribute modification

  In absence of this control, an attempt to modify values of a
  NO-USER-MODIFICATION attribute would normally lead to a
  constraintViolation or other appropriate error [Protocol].  In the



Zeilenga                 LDAP Manage DIT Control                [Page 5]

INTERNET-DRAFT      draft-zeilenga-ldap-managedit-00    27 February 2006


  presence of the Manage DIT control in the update request requests the
  modification be allowed.

  Relaxation of the NO-USER-MODIFICATION constraint is not appropriate
  for some operational attribute types. For instance, as the value of
  the 'structuralObjectClass' is derived by the values of the
  'objectClass' attribute, the 'structuralObjectClass' attribute type's
  NO-USER-MODIFICATION contraint MUST NOT be relaxed.  To effect a
  change in the structuralObjectClass class, values of objectClass
  should be changed as discussed in Section 3.1.  Other attributes for
  which the NO-USER-MODIFICATION constraint should not be relaxed
  include 'entryDN' [EntryDN], 'subschemaSubentry' [Models], and
  'collectiveAttributeSubentries' [RFC3671].

  The subsections of this section discuss modification of various
  operational attributes where their NO-USER-MODIFICATION constraint may
  be relaxed.  Future documents may specify where NO-USER-MODIFICATION
  constraints on other operational attribute may be relaxed.  In absence
  of a document detailing that the NO-USER-MODIFICATION constraint on a
  particular operational attribute may be relaxed, implementors SHOULD
  assume relaxation of the constraint is not appropriate for that
  attribute.


3.1.1. entryUUID

  To provide a value for the 'entryUUID' attribute on entry creation,
  the client should issue an LDAP Add request with a Manage DIT control
  providing the desired value.  For instance:

      dn: ou=Unit,dc=example,dc=net
      control: IANA-ASSIGNED-OID
      changetype: add
      objectClass: organizationalUnit
      ou: Unit
      entryUUID: 597ae2f6-16a6-1027-98f4-d28b5365dc14

  In this case, the server is either to add the entry using the
  provided 'entryUUID' value or fail the request.

  To provide a replacement value for the 'entryUUID' after entry
  creation, the client should issue an LDAP Modify request with a
  Manage DIT control including an approrpiate change.  For instance:

      dn: ou=Unit,dc=example,dc=net
      control: IANA-ASSIGNED-OID
      changetype: modify
      replace: entryUUID



Zeilenga                 LDAP Manage DIT Control                [Page 6]

INTERNET-DRAFT      draft-zeilenga-ldap-managedit-00    27 February 2006


      entryUUID: 597ae2f6-16a6-1027-98f4-d28b5365dc14
      -

  In this case, the server is either to replace the 'entryUUID' value
  as requested or fail the request.


3.2.2. createTimestamp

  To provide a value for the 'createTimestamp' attribute on entry
  creation, the client should issue an LDAP Add request with a Manage
  DIT control providing the desired 'createTimestamp' value.  For
  instance:

      dn: ou=Unit,dc=example,dc=net
      control: IANA-ASSIGNED-OID
      changetype: add
      objectClass: organizationalUnit
      ou: Unit
      createTimestamp: 20060101000000Z

  In this case, the server is either to add the entry using the
  provided 'createTimestamp' value or fail the request.

  To provide a replacement value for the 'createTimestamp' after
  entry creation, the client should issue an LDAP Modify request with
  a Manage DIT control including an approrpiate change.  For instance:

      dn: ou=Unit,dc=example,dc=net
      control: IANA-ASSIGNED-OID
      changetype: modify
      replace: createTimestamp
      createTimestamp: 20060101000000Z
      -

  In this case, the server is either to replace the 'createTimestamp'
  value as requested or fail the request.

  The server should ensure the requested 'createTimestamp' value is
  appropriate.  In particular, it should fail the request if the
  requested 'createTimestamp' value is in the future or is greater
  than the value of the 'modifyTimestamp' attribute.


3.2.3. modifyTimestamp

  To provide a value for the 'modifyTimestamp' attribute on entry
  creation, the client should issue an LDAP Add request with a Manage



Zeilenga                 LDAP Manage DIT Control                [Page 7]

INTERNET-DRAFT      draft-zeilenga-ldap-managedit-00    27 February 2006


  DIT control providing the desired 'modifyTimestamp' value.  For
  instance:

      dn: ou=Unit,dc=example,dc=net
      control: IANA-ASSIGNED-OID
      changetype: add
      objectClass: organizationalUnit
      ou: Unit
      modifyTimestamp: 20060101000000Z

  In this case, the server is either to add the entry using
  the provided 'modifyTimestamp' value or fail the request.

  To provide a replacement value for the 'modifyTimestamp' after
  entry creation, the client should issue an LDAP Modify
  request with a Manage DIT control including an approrpiate
  change.  For instance:

      dn: ou=Unit,dc=example,dc=net
      control: IANA-ASSIGNED-OID
      changetype: modify
      replace: modifyTimestamp
      modifyTimestamp: 20060101000000Z
      -

  In this case, the server is either to replace the 'modifyTimestamp'
  value as requested or fail the request.

  The server should ensure the requested 'modifyTimestamp' value is
  appropriate.  In particular, it should fail the request if the
  requested 'modifyTimestamp' value is in the future or is less than
  the value of the 'createTimestamp' attribute.


  3.2.3. creatorsName and modifiersName

  To provide a value for the 'creatorsName' and/or 'modifiersName'
  attribute on entry creation, the client should issue an LDAP Add
  request with a Manage DIT control providing the desired values.
  For instance:

      dn: ou=Unit,dc=example,dc=net
      control: IANA-ASSIGNED-OID
      changetype: add
      objectClass: organizationalUnit
      ou: Unit
      creatorsName: cn=Jane Doe,dc=example,net
      modifiersName: cn=Jane Doe,dc=example,net



Zeilenga                 LDAP Manage DIT Control                [Page 8]

INTERNET-DRAFT      draft-zeilenga-ldap-managedit-00    27 February 2006


  In this case, the server is either to add the entry using
  the provided values or fail the request.

  To provide a replacement values after entry creation for either of
  the 'creatorsName' or 'modifiersName' attributes or both, the
  client should issue an LDAP Modify request with a Manage DIT control
  including the approrpiate changes.  For instance:

      dn: ou=Unit,dc=example,dc=net
      control: IANA-ASSIGNED-OID
      changetype: modify
      replace: creatorsName
      creatorsName: cn=Jane Doe,dc=example,net
      -
      replace: modifiersName
      modifiersName: cn=Jane Doe,dc=example,net
      -

  In this case, the server is either to replace the provided
  values as requested or fail the request.


4.  Security Considerations

  Use of this extension should be subject to appropriate administrative
  and access controls.  Use of this mechanism is intended to be
  restricted to directory administrators.

  Security considerations for the base operations [Protocol] extended
  by this control, as well as general LDAP security considerations
  [Roadmap], generally apply to implementation and use of this
  extension.


5.  IANA Considerations

5.1.  Object Identifier

  It is requested that IANA assign a LDAP Object Identifier [BCP64bis]
  to identify the LDAP Assertion Control defined in this document.

      Subject: Request for LDAP Object Identifier Registration
      Person & email address to contact for further information:
          Kurt Zeilenga <kurt@OpenLDAP.org>
      Specification: RFC XXXX
      Author/Change Controller: Kurt Zeilenga <kurt@openldap.org>
      Comments: Identifies the LDAP Manage DIT Control




Zeilenga                 LDAP Manage DIT Control                [Page 9]

INTERNET-DRAFT      draft-zeilenga-ldap-managedit-00    27 February 2006


5.2  LDAP Protocol Mechanism

  Registration of this protocol mechanism [BCP64bis] is requested.

      Subject: Request for LDAP Protocol Mechanism Registration
      Object Identifier: IANA-ASSIGNED-OID
      Description: Manage DIT Control
      Person & email address to contact for further information:
          Kurt Zeilenga <kurt@openldap.org>
      Usage: Control
      Specification: RFC XXXX
      Author/Change Controller: Kurt Zeilenga <kurt@openldap.org>
      Comments: none


6.  Author's Address

  Kurt D. Zeilenga
  OpenLDAP Foundation

  Email: Kurt@OpenLDAP.org


7. References

  [[Note to the RFC Editor: please replace the citation tags used in
  referencing Internet-Drafts with tags of the form RFCnnnn where
  possible.]]


7.1. Normative References

  [RFC2119]     Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14 (also RFC 2119), March 1997.

  [Roadmap]     Zeilenga, K. (editor), "LDAP: Technical Specification
                Road Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in
                progress.

  [Models]      Zeilenga, K. (editor), "LDAP: Directory Information
                Models", draft-ietf-ldapbis-models-xx.txt, a work in
                progress.



7.2. Informative References

  [BCP64bis]    Zeilenga, K., "IANA Considerations for LDAP",



Zeilenga                 LDAP Manage DIT Control               [Page 10]

INTERNET-DRAFT      draft-zeilenga-ldap-managedit-00    27 February 2006


                draft-ietf-ldapbis-bcp64-xx.txt, a work in progress.

  [EntryUUID]   Zeilenga, K., "The LDAP EntryUUID Operational
                Attribute", draft-zeilenga-ldap-uuid-xx.txt, a work in
                progress.

  [RFC2849]     Good, G., "The LDAP Data Interchange Format (LDIF) -
                Technical Specification", RFC 2849, June 2000.



Intellectual Property Rights

  The IETF takes no position regarding the validity or scope of any
  Intellectual Property Rights or other rights that might be claimed to
  pertain to the implementation or use of the technology described in
  this document or the extent to which any license under such rights
  might or might not be available; nor does it represent that it has
  made any independent effort to identify any such rights.  Information
  on the procedures with respect to rights in RFC documents can be found
  in BCP 78 and BCP 79.

  Copies of IPR disclosures made to the IETF Secretariat and any
  assurances of licenses to be made available, or the result of an
  attempt made to obtain a general license or permission for the use of
  such proprietary rights by implementers or users of this specification
  can be obtained from the IETF on-line IPR repository at
  http://www.ietf.org/ipr.

  The IETF invites any interested party to bring to its attention any
  copyrights, patents or patent applications, or other proprietary
  rights that may cover technology that may be required to implement
  this standard.  Please address the information to the IETF at
  ietf-ipr@ietf.org.



Full Copyright

  Copyright (C) The Internet Society (2006).

  This document is subject to the rights, licenses and restrictions
  contained in BCP 78, and except as set forth therein, the authors
  retain all their rights.

  This document and the information contained herein are provided on an
  "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
  OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET



Zeilenga                 LDAP Manage DIT Control               [Page 11]

INTERNET-DRAFT      draft-zeilenga-ldap-managedit-00    27 February 2006


  ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
  INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
  INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
  WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.















































Zeilenga                 LDAP Manage DIT Control               [Page 12]