INTERNET-DRAFT Kurt D. Zeilenga
-Intended Category: Standard Track OpenLDAP Foundation
-Expires in six months 5 March 2006
+Intended Category: Standard Track Isode Limited
+Expires in six months 14 February 2007
The LDAP Don't Use Copy Control
- <draft-zeilenga-ldap-dontusecopy-02.txt>
+ <draft-zeilenga-ldap-dontusecopy-04.txt>
Status of this Memo
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>.
+ comments directly to the author <Kurt.Zeilenga@Isode.COM>.
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware have
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
+ http://www.ietf.org/1id-abstracts.html.
The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html
+ http://www.ietf.org/shadow.html.
- Copyright (C) The Internet Society (2006). All Rights Reserved.
+ Copyright (C) The IETF Trust (2007). All Rights Reserved.
Please see the Full Copyright section near the end of this document
for more information.
Zeilenga LDAP Don't Use Copy Control [Page 1]
\f
-INTERNET-DRAFT draft-zeilenga-ldap-dontusecopy-02 5 March 2006
+INTERNET-DRAFT draft-zeilenga-ldap-dontusecopy-04 14 February 2007
Abstract
1. Background and Intended Usage
This document defines the Lightweight Directory Access Protocol (LDAP)
- [Roadmap] Don't Use Copy control extension. The control may be
+ [RFC4510] Don't Use Copy control extension. The control may be
attached to request messages to indicate that copied (replicated or
cached) information [X.500] should not be used in providing service.
This control is based upon the X.511 [X.511] dontUseCopy service
3. The Don't Use Copy Control
- The Don't Use Copy control is an LDAP Control [Protocol] whose
+ The Don't Use Copy control is an LDAP Control [RFC4511] whose
controlType is IANA-ASSIGNED-OID and controlValue is absent. The
criticality MUST be TRUE. There is no corresponding response control.
The control is appropriate for both LDAP interrogation operations,
- including Compare and Search operations [Protocol]. It is
+ including Compare and Search operations [RFC4511]. It is
inappropriate for all other operations, including Abandon, Bind,
- Delete, Modify, ModifyDN, StartTLS, and Unbind operations [Protocol].
+ Delete, Modify, ModifyDN, StartTLS, and Unbind operations [RFC4511].
When the control is attached to an LDAP request, the requested
operation MUST NOT be performed on copied information. That is, the
Zeilenga LDAP Don't Use Copy Control [Page 2]
\f
-INTERNET-DRAFT draft-zeilenga-ldap-dontusecopy-02 5 March 2006
+INTERNET-DRAFT draft-zeilenga-ldap-dontusecopy-04 14 February 2007
is not available (either locally or through chaining), the server MUST
be better able to service the request or return an appropriate result
code (e.g., unwillingToPerform).
+ Servers implementing this technical specification SHOULD publish the
+ object identifier IANA-ASSIGNED-OID as a value of the
+ 'supportedControl' attribute [RFC4512] in their root DSE. A server
+ MAY choose to advertise this extension only when the client is
+ authorized to use it.
+
4. Security Considerations
consider whether use of copied information, in particular security and
policy information, may result insecure behavior.
- Security considerations for the base operations [Protocol] extended by
+ Security considerations for the base operations [RFC4511] extended by
this control, as well as general LDAP security considerations
- [Roadmap], generally apply to implementation and use of this
+ [RFC4510], generally apply to implementation and use of this
extension.
5.1. Object Identifier
It is requested that IANA assign upon Standards Action an LDAP Object
- Identifier [BCP64bis] to identify the LDAP Don't Use Copy Control
+ Identifier [RFC4520] to identify the LDAP Don't Use Copy 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>
+ Kurt Zeilenga <Kurt.Zeilenga@Isode.COM>
Specification: RFC XXXX
Author/Change Controller: IESG
Comments:
5.2 LDAP Protocol Mechanism
- Registration of this protocol mechanism [BCP64bis] is requested.
+ Registration of this protocol mechanism [RFC4520] is requested.
Subject: Request for LDAP Protocol Mechanism Registration
- Object Identifier: IANA-ASSIGNED-OID
- Description: Don't Use Copy Control
- Person & email address to contact for further information:
- Kurt Zeilenga <kurt@openldap.org>
- Usage: Control
- Specification: RFC XXXX
Zeilenga LDAP Don't Use Copy Control [Page 3]
\f
-INTERNET-DRAFT draft-zeilenga-ldap-dontusecopy-02 5 March 2006
+INTERNET-DRAFT draft-zeilenga-ldap-dontusecopy-04 14 February 2007
+ Object Identifier: IANA-ASSIGNED-OID
+ Description: Don't Use Copy Control
+ Person & email address to contact for further information:
+ Kurt Zeilenga <Kurt.Zeilenga@Isode.COM>
+ Usage: Control
+ Specification: RFC XXXX
Author/Change Controller: IESG
Comments: none
6. Author's Address
Kurt D. Zeilenga
- OpenLDAP Foundation
+ Isode Limited
- Email: Kurt@OpenLDAP.org
+ Email: Kurt.Zeilenga@Isode.COM
7. 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.
+ [RFC4510] Zeilenga, K. (editor), "LDAP: Technical Specification
+ Road Map", RFC 4510, June 2006.
+
+ [RFC4511] Sermersheim, J. (editor), "LDAP: The Protocol", RFC
+ 4511, June 2006.
- [Protocol] Sermersheim, J. (editor), "LDAP: The Protocol",
- draft-ietf-ldapbis-protocol-xx.txt, a work in progress.
+ [RFC4512] Zeilenga, K. (editor), "LDAP: Directory Information
+ Models", RFC 4512, June 2006.
7.2. Informative References
-- Overview of concepts, models and services,"
X.500(1993) (also ISO/IEC 9594-1:1994).
+
+
+
+Zeilenga LDAP Don't Use Copy Control [Page 4]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-dontusecopy-04 14 February 2007
+
+
[X.511] International Telecommunication Union -
Telecommunication Standardization Sector, "The
Directory: Abstract Service Definition", X.511(1993)
(also ISO/IEC 9594-3:1993).
- [BCP64bis] Zeilenga, K., "IANA Considerations for LDAP",
- draft-ietf-ldapbis-bcp64-xx.txt, a work in progress.
-
-
+ [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority
+ (IANA) Considerations for the Lightweight Directory
+ Access Protocol (LDAP)", RFC 4520, BCP 64, June 2006.
-Zeilenga LDAP Don't Use Copy Control [Page 4]
-\f
-INTERNET-DRAFT draft-zeilenga-ldap-dontusecopy-02 5 March 2006
-
-Intellectual Property Rights
+Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
Full Copyright
- Copyright (C) The Internet Society (2006).
+ Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
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
- 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
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
+
+
+
+Zeilenga LDAP Don't Use Copy Control [Page 5]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-dontusecopy-04 14 February 2007
+
+
+ THE INTERNET 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 Don't Use Copy Control [Page 5]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga LDAP Don't Use Copy Control [Page 6]
\f
--- /dev/null
+
+
+
+
+
+
+INTERNET-DRAFT Kurt D. Zeilenga
+Intended Category: Standard Track Isode Limited
+Expires in six months 14 February 2007
+
+
+
+ The LDAP entryDN Operational Attribute
+ <draft-zeilenga-ldap-entrydn-01.txt>
+
+
+
+Status of this Memo
+
+ This document is intended to be, after appropriate review and
+ revision, submitted to the RFC Editor as an Standard Track 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.Zeilenga@Isode.COM>.
+
+ 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 IETF Trust (2007). All Rights Reserved.
+
+ Please see the Full Copyright section near the end of this document
+ for more information.
+
+
+
+
+
+
+Zeilenga draft-zeilenga-ldap-entrydn-01 [Page 1]
+\f
+INTERNET-DRAFT LDAP entryDN 14 February 2007
+
+
+Abstract
+
+ This document describes the LDAP/X.500 'entryDN' operational
+ attribute. The attribute provides a copy of the entry's distinguished
+ name for use in attribute value assertions.
+
+
+1. Background and Intended Use
+
+ In X.500 Directory Services [X.501], such as those accessible using
+ the Lightweight Directory Access Protocol (LDAP) [RFC4510], an entry
+ is identified by its distinguished name (DN) [RFC4512]. However, as
+ an entry's DN is not an attribute of the entry, it is not possible to
+ perform attribute value assertions [RFC4511] against it.
+
+ This document describes the 'entryDN' operational attribute which
+ holds a copy of the entry's distributed name. This attribute may be
+ used in search filters. For instance, searching the subtree
+ <dc=example,dc=com> with the filter:
+ (entryDN:componentFilterMatch:=or:{
+ item:{ component "3", rule rdnMatch, value "ou=A" },
+ item:{ component "3", rule rdnMatch, value "ou=B" } })
+ would return entries in the subtree <ou=A,dc=example,dc=com> and
+ entries in subtree <ou=B,dc=example,com>, but would not return any
+ other entries in the subtree <dc=example,dc=com>.
+
+ In this document, DNs are presented using the string representation
+ defined in [RFC4514]. Search filters above is described using the
+ string representation defined in [RFC4515] with whitespace (line
+ breaks and indentation) added to improve readability. The
+ 'componetFilterMatch' and 'rdnMatch' rules are specified in [RFC3687].
+
+ Schema definitions are provided using LDAP description formats
+ [RFC4512]. Definitions provided here are formatted (line wrapped) for
+ readability.
+
+ 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].
+
+
+2. 'entryDN' Operational Attribute
+
+ The 'entryDN' operational attribute provides a copy of the entry's
+ current DN.
+
+ The following is a LDAP attribute type description suitable for
+ publication in subschema subentries.
+
+
+
+Zeilenga draft-zeilenga-ldap-entrydn-01 [Page 2]
+\f
+INTERNET-DRAFT LDAP entryDN 14 February 2007
+
+
+ ( IANA-ASSIGNED-OID NAME 'entryDN'
+ DESC 'DN of the entry'
+ EQUALITY distinguishedNameMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
+ SINGLE-VALUE
+ NO-USER-MODIFICATION
+ USAGE directoryOperation )
+
+ Note that the DN of the entry cannot be modified through this
+ attribute.
+
+
+3. Security Considerations
+
+ As this attribute only provides an additional mechanism to access an
+ entry's DN, the introduction of this attribute is not believed to
+ introduce new security considerations.
+
+
+4. IANA Considerations
+
+4.1. Object Identifier Registration
+
+ It is requested that IANA register upon Standards Action assign an
+ LDAP Object Identifier [RFC4520] for use in this document.
+
+ Subject: Request for LDAP OID Registration
+ Person & email address to contact for further information:
+ Kurt Zeilenga <Kurt.Zeilenga@Isode.COM>
+ Specification: RFC XXXX
+ Author/Change Controller: IESG
+ Comments:
+ Identifies the 'entryDN' attribute type
+
+
+5.4. 'entryDN' Descriptor Registration
+
+ It is requested that IANA register upon Standards Action the LDAP
+ 'entryDN' descriptor [RFC4520].
+
+ Subject: Request for LDAP Descriptor Registration
+ Descriptor (short name): entryDN
+ Object Identifier: IANA-ASSIGNED-OID
+ Person & email address to contact for further information:
+ Kurt Zeilenga <Kurt.Zeilenga@Isode.COM>
+ Usage: Attribute Type
+ Specification: RFC XXXX
+ Author/Change Controller: IESG
+
+
+
+Zeilenga draft-zeilenga-ldap-entrydn-01 [Page 3]
+\f
+INTERNET-DRAFT LDAP entryDN 14 February 2007
+
+
+6. Acknowledgments
+
+ TBD.
+
+
+7. Author's Address
+
+ Kurt D. Zeilenga
+ Isode Limited
+
+ Email: Kurt.Zeilenga@Isode.COM
+
+
+8. References
+
+
+8.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14 (also RFC 2119), March 1997.
+
+ [RFC4510] Zeilenga, K. (editor), "LDAP: Technical Specification
+ Road Map", RFC 4510, June 2006.
+
+ [RFC4512] Zeilenga, K. (editor), "LDAP: Directory Information
+ Models", RFC 4512, June 2006.
+
+ [X.501] International Telecommunication Union -
+ Telecommunication Standardization Sector, "The Directory
+ -- Models," X.501(1993) (also ISO/IEC 9594-2:1994).
+
+
+8.2. Informative References
+
+ [RFC3687] Legg, S., "Lightweight Directory Access Protocol (LDAP)
+ and X.500 Component Matching Rules", RFC 3687, February
+ 2004.
+
+ [RFC4511] Sermersheim, J. (editor), "LDAP: The Protocol", RFC
+ 4511, June 2006.
+
+ [RFC4514] Zeilenga, K. (editor), "LDAP: String Representation of
+ Distinguished Names", RFC 4514, June 2006.
+
+ [RFC4515] Smith, M. (editor), "LDAP: String Representation of
+ Search Filters", RFC 4515, June 2006.
+
+ [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority
+
+
+
+Zeilenga draft-zeilenga-ldap-entrydn-01 [Page 4]
+\f
+INTERNET-DRAFT LDAP entryDN 14 February 2007
+
+
+ (IANA) Considerations for the Lightweight Directory
+ Access Protocol (LDAP)", RFC 4520, BCP 64, June 2006.
+
+
+
+Intellectual Property
+
+ 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 IETF Trust (2007).
+
+ 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, THE IETF TRUST AND
+ THE INTERNET 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 draft-zeilenga-ldap-entrydn-01 [Page 5]
+\f
+++ /dev/null
-
-
-
-
-
-
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
INTERNET-DRAFT Kurt D. Zeilenga
-Intended Category: Standard Track OpenLDAP Foundation
-Expires in six months 5 March 2006
+Intended Category: Standard Track Isode Limited
+Expires in six months 14 February 2007
The LDAP No-Op Control
- <draft-zeilenga-ldap-noop-08.txt>
+ <draft-zeilenga-ldap-noop-10.txt>
Status of this Memo
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>.
+ comments directly to the author <Kurt.Zeilenga@Isode.COM>.
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware have
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
+ http://www.ietf.org/1id-abstracts.html.
The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html
+ http://www.ietf.org/shadow.html.
- Copyright (C) The Internet Society (2006). All Rights Reserved.
+ Copyright (C) The IETF Trust (2007). All Rights Reserved.
Please see the Full Copyright section near the end of this document
for more information.
Zeilenga LDAP No-Op Control [Page 1]
\f
-INTERNET-DRAFT draft-zeilenga-ldap-noop-08 5 March 2006
+INTERNET-DRAFT draft-zeilenga-ldap-noop-10 14 February 2007
Abstract
1. Overview
It is often desirable to be able to determine if a directory operation
- [Protocol] would successful complete or not without having the normal
+ [RFC4511] would successful complete or not without having the normal
effect of the operation take place. For example, an administrative
client might want to verify that new user could update their entry
(and not other entries) without the directory actually being updated.
auditing tools.
This document defines the Lightweight Directory Access Protocol (LDAP)
- [Roadmap] No-Op control extension. The presence of the No-Op control
+ [RFC4510] No-Op control extension. The presence of the No-Op control
in an operation request message disables its normal effect upon the
directory which operation would otherwise have. Instead of updating
the directory and returning the normal indication of success, the
noOperation resultCode (introduced below).
For example, when the No-Op control is present in a LDAP modify
- operation [Protocol], the server is do all processing necessary to
+ operation [RFC4511], the server is do all processing necessary to
perform the operation without actually updating the directory. If it
detects an error during this processing, it returns a non-success
(other than noOperation) resultCode as it normally would. Otherwise,
Zeilenga LDAP No-Op Control [Page 2]
\f
-INTERNET-DRAFT draft-zeilenga-ldap-noop-08 5 March 2006
+INTERNET-DRAFT draft-zeilenga-ldap-noop-10 14 February 2007
2. No-Op Control
- The No-Op control is an LDAP Control [Protocol] whose controlType is
+ The No-Op control is an LDAP Control [RFC4511] whose controlType is
IANA-ASSIGNED-OID and controlValue is absent. Clients MUST provide a
criticality value of TRUE to prevent unintended modification of the
directory.
The control is appropriate for request messages of LDAP Add, Delete,
- Modify and ModifyDN operations [Protocol]. The control is also
+ Modify and ModifyDN operations [RFC4511]. The control is also
appropriate for requests of extended operations which update the
directory (or other data stores), such as Password Modify Extended
Operation [RFC3062]. There is no corresponding response control.
Servers SHOULD indicate their support for this control by providing
IANA-ASSIGNED-OID as a value of the 'supportedControl' attribute type
- [Models] in their root DSE entry. A server MAY choose to advertise
+ [RFC4512] in their root DSE entry. A server MAY choose to advertise
this extension only when the client is authorized to use this
operation.
tools.
Implementors of this LDAP extension should be familiar with security
- considerations applicable to the LDAP operations [Protocol] extended
- by this control, as well as general LDAP security considerations
+ considerations applicable to the LDAP operations [RFC4511] extended by
+ this control, as well as general LDAP security considerations
[Roadmap].
Zeilenga LDAP No-Op Control [Page 3]
\f
-INTERNET-DRAFT draft-zeilenga-ldap-noop-08 5 March 2006
+INTERNET-DRAFT draft-zeilenga-ldap-noop-10 14 February 2007
4. IANA Considerations
4.1. Object Identifier
- It is requested that IANA assign an LDAP Object Identifier [BCP64bis]
+ It is requested that IANA assign an LDAP Object Identifier [RFC4520]
to identify the LDAP No-Op 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>
+ Kurt Zeilenga <Kurt.Zeilenga@Isode.COM>
Specification: RFC XXXX
Author/Change Controller: IESG
Comments:
4.2 LDAP Protocol Mechanism
- Registration of this protocol mechanism is requested [RFC3383].
+ Registration of this protocol mechanism is requested [RFC4520].
Subject: Request for LDAP Protocol Mechanism Registration
Object Identifier: IANA-ASSIGNED-OID
Description: No-Op Control
Person & email address to contact for further information:
- Kurt Zeilenga <kurt@openldap.org>
+ Kurt Zeilenga <Kurt.Zeilenga@Isode.COM>
Usage: Control
Specification: RFC XXXX
Author/Change Controller: IESG
Subject: LDAP Result Code Registration
Person & email address to contact for further information:
- Kurt Zeilenga <kurt@OpenLDAP.org>
+ Kurt Zeilenga <Kurt.Zeilenga@Isode.COM>
Result Code Name: noOperation
Specification: RFC XXXX
Author/Change Controller: IESG
5. Author's Address
Kurt D. Zeilenga
- OpenLDAP Foundation
+ Isode Limited
Zeilenga LDAP No-Op Control [Page 4]
\f
-INTERNET-DRAFT draft-zeilenga-ldap-noop-08 5 March 2006
+INTERNET-DRAFT draft-zeilenga-ldap-noop-10 14 February 2007
- Email: Kurt@OpenLDAP.org
+ Email: Kurt.Zeilenga@Isode.COM
6. References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14 (also RFC 2119), March 1997.
- [Protocol] Sermersheim, J. (editor), "LDAP: The Protocol",
- draft-ietf-ldapbis-protocol-xx.txt, a work in progress.
+ [RFC4510] Zeilenga, K. (editor), "LDAP: Technical Specification
+ Road Map", RFC 4510, June 2006.
- [Roadmap] Zeilenga, K. (editor), "LDAP: Technical Specification
- Road Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in
- progress.
+ [RFC4511] Sermersheim, J. (editor), "LDAP: The Protocol", RFC
+ 4511, June 2006.
- [Models] Zeilenga, K. (editor), "LDAP: Directory Information
- Models", draft-ietf-ldapbis-models-xx.txt, a work in
- progress.
+ [RFC4512] Zeilenga, K. (editor), "LDAP: Directory Information
+ Models", RFC 4512, June 2006.
6.2. Informative References
[RFC3062] Zeilenga, K., "LDAP Password Modify Extended Operation",
RFC 3062, February 2000.
- [BCP64bis] Zeilenga, K., "IANA Considerations for LDAP",
- draft-ietf-ldapbis-bcp64-xx.txt, a work in progress.
+ [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority
+ (IANA) Considerations for the Lightweight Directory
+ Access Protocol (LDAP)", RFC 4520, BCP 64, June 2006.
-Intellectual Property Rights
+Intellectual Property
The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
Zeilenga LDAP No-Op Control [Page 5]
\f
-INTERNET-DRAFT draft-zeilenga-ldap-noop-08 5 March 2006
+INTERNET-DRAFT draft-zeilenga-ldap-noop-10 14 February 2007
- 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
Full Copyright
- Copyright (C) The Internet Society (2006).
+ Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
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
- 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
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
+ THE INTERNET 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 No-Op Control [Page 6]
\f
--- /dev/null
+
+
+
+
+
+
+INTERNET-DRAFT Kurt D. Zeilenga
+Intended Category: Experimental Isode Limited
+Expires in six months 14 February 2007
+
+
+
+ The LDAP Relax Rules Control
+ <draft-zeilenga-ldap-relax-01.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.Zeilenga@Isode.COM>.
+
+ This document replaces draft-zeilenga-ldap-managedit-xx.txt.
+
+ 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 IETF Trust (2007). All Rights Reserved.
+
+ Please see the Full Copyright section near the end of this document
+ for more information.
+
+
+
+
+
+Zeilenga LDAP Relax Rules Control [Page 1]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-relax-01 14 February 2007
+
+
+Abstract
+
+ This document defines the Lightweight Directory Access Protocol (LDAP)
+ Relax Rules Control which allows a directory user agent (a client) to
+ request the directory service temporarily relax enforcement of various
+ data and service model rules.
+
+
+1. Background and Intended Use
+
+ Directory servers accessible via Lightweight Directory Access Protocol
+ (LDAP) [RFC4510] are expected to act in accordance with the X.500
+ [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 [RFC4512]. 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' [RFC4530] will reflect the object was replaced,
+ not transformed.
+
+ An LDAP server is expected to prevent clients from modifying values of
+ NO-USER-MODIFICATION attributes [RFC4512]. 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 defines the LDAP Relax Rules control. This control may
+ be attached to LDAP requests to update the Directory Information Tree
+ (DIT) to request various data and service rules 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 primarily by directory administrators.
+
+
+
+
+Zeilenga LDAP Relax Rules Control [Page 2]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-relax-01 14 February 2007
+
+
+ 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.1 of [RFC4511].
+
+ 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 Relax Rules Control
+
+ The Relax Rules control is an LDAP Control [RFC4511] 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) [RFC4511].
+
+ The presence of the Rules Rules 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 Relax Rules Control [Page 3]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-relax-01 14 February 2007
+
+
+ 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 [RFC4512] 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 [RFC4511]. The presence of the Relax
+ Rules 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 Relax Rules 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) [RFC4512] normally results in a failure.
+
+
+
+
+Zeilenga LDAP Relax Rules Control [Page 4]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-relax-01 14 February 2007
+
+
+ In the presence of the Relax Rules 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 Relax Rules 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
+ [RFC4512]. 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 Relax Rules 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 Relax Rules control, the service enforces DIT
+ structure rules and name form requirements of the controlling
+ subschema [RFC4512].
+
+ In the presence of the Relax Rules 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 [RFC4512] would normally lead to a
+
+
+
+Zeilenga LDAP Relax Rules Control [Page 5]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-relax-01 14 February 2007
+
+
+ constraintViolation or other appropriate error [RFC4511]. In the
+ presence of the Relax Rules 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 'subschemaSubentry' [RFC4512] 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' attribute
+
+ To provide a value for the 'entryUUID' [RFC4530] attribute on entry
+ creation, the client should issue an LDAP Add request with a Relax
+ Rules 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
+ Relax Rules control including an approrpiate change. For instance:
+
+ dn: ou=Unit,dc=example,dc=net
+ control: IANA-ASSIGNED-OID
+ changetype: modify
+
+
+
+Zeilenga LDAP Relax Rules Control [Page 6]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-relax-01 14 February 2007
+
+
+ replace: entryUUID
+ 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' [RFC4512] attribute
+ on entry creation, the client should issue an LDAP Add request with
+ a Relax Rules 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 Relax Rules 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' [RFC4512] attribute
+
+
+
+Zeilenga LDAP Relax Rules Control [Page 7]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-relax-01 14 February 2007
+
+
+ on entry creation, the client should issue an LDAP Add request with
+ a Relax Rules 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 Relax Rules 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'
+ [RFC4512] attribute on entry creation, the client should issue an
+ LDAP Add request with a Relax Rules 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
+
+
+
+Zeilenga LDAP Relax Rules Control [Page 8]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-relax-01 14 February 2007
+
+
+ modifiersName: cn=Jane Doe,dc=example,net
+
+ 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 Relax Rules 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 [RFC4511] extended
+ by this control, as well as general LDAP security considerations
+ [RFC4510], generally apply to implementation and use of this
+ extension.
+
+
+5. IANA Considerations
+
+5.1. Object Identifier
+
+ It is requested that the IANA assign a LDAP Object Identifier
+ [RFC4520] to identify the LDAP Relax Rules Control defined 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: RFC XXXX
+
+
+
+Zeilenga LDAP Relax Rules Control [Page 9]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-relax-01 14 February 2007
+
+
+ Author/Change Controller: Kurt Zeilenga <Kurt.Zeilenga@Isode.COM>
+ Comments: Identifies the LDAP Relax Rules Control
+
+5.2 LDAP Protocol Mechanism
+
+ Registration of this protocol mechanism [RFC4520] is requested.
+
+ Subject: Request for LDAP Protocol Mechanism Registration
+ Object Identifier: IANA-ASSIGNED-OID
+ Description: Relax Rules Control
+ Person & email address to contact for further information:
+ Kurt Zeilenga <Kurt.Zeilenga@Isode.COM>
+ Usage: Control
+ Specification: RFC XXXX
+ Author/Change Controller: Kurt Zeilenga <Kurt.Zeilenga@Isode.COM>
+ Comments: none
+
+
+6. Author's Address
+
+ Kurt D. Zeilenga
+ Isode Limited
+
+ Email: Kurt.Zeilenga@Isode.COM
+
+
+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.
+
+ [RFC3671] Zeilenga, K., "Collective Attributes in LDAP", RFC 3671,
+ December 2003.
+
+ [RFC4510] Zeilenga, K. (editor), "LDAP: Technical Specification
+ Road Map", RFC 4510, June 2006.
+
+ [RFC4511] Sermersheim, J. (editor), "LDAP: The Protocol", RFC
+ 4511, June 2006.
+
+ [RFC4512] Zeilenga, K. (editor), "LDAP: Directory Information
+
+
+
+Zeilenga LDAP Relax Rules Control [Page 10]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-relax-01 14 February 2007
+
+
+ Models", RFC 4512, June 2006.
+
+ [RFC4530] Zeilenga, K., "Lightweight Directory Access Protocol
+ (LDAP) entryUUID Operational Attribute", RFC 4530, June
+ 2006.
+
+ [X.500] International Telecommunication Union -
+ Telecommunication Standardization Sector, "The Directory
+ -- Overview of concepts, models and services,"
+ X.500(1993) (also ISO/IEC 9594-1:1994).
+
+
+7.2. Informative References
+
+ [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority
+ (IANA) Considerations for the Lightweight Directory
+ Access Protocol (LDAP)", RFC 4520, BCP 64, June 2006.
+
+
+
+Intellectual Property
+
+ 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
+
+
+
+
+Zeilenga LDAP Relax Rules Control [Page 11]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-relax-01 14 February 2007
+
+
+ Copyright (C) The IETF Trust (2007).
+
+ 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, THE IETF TRUST AND
+ THE INTERNET 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 Relax Rules Control [Page 12]
+\f
projects / openldap / commitdiff