Movatterモバイル変換

Network Working Group                                        K. ZeilengaRequest for Comments: 4527                           OpenLDAP FoundationCategory: Standards Track                                      June 2006Lightweight Directory Access Protocol (LDAP)Read Entry ControlsStatus of This Memo   This document specifies an Internet standards track protocol for the   Internet community, and requests discussion and suggestions for   improvements.  Please refer to the current edition of the "Internet   Official Protocol Standards" (STD 1) for the standardization state   and status of this protocol.  Distribution of this memo is unlimited.Copyright Notice   Copyright (C) The Internet Society (2006).Abstract   This document specifies an extension to the Lightweight Directory   Access Protocol (LDAP) to allow the client to read the target entry   of an update operation.  The client may request to read the entry   before and/or after the modifications are applied.  These reads are   done as an atomic part of the update operation.Table of Contents1. Background and Intent of Use ....................................22. Terminology .....................................................23. Read Entry Controls .............................................33.1. The Pre-Read Controls ......................................33.2. The Post-Read Controls .....................................34. Interaction with Other Controls .................................45. Security Considerations .........................................46. IANA Considerations .............................................56.1. Object Identifier ..........................................56.2. LDAP Protocol Mechanisms ...................................57. Acknowledgement .................................................58. References ......................................................68.1. Normative References .......................................68.2. Informative References .....................................7Zeilenga                    Standards Track                     [Page 1]

RFC 4527                LDAP Read Entry Controls               June 20061.  Background and Intent of Use   This document specifies an extension to the Lightweight Directory   Access Protocol (LDAP) [RFC4510] to allow the client to read the   target entry of an update operation (e.g., Add, Delete, Modify,   ModifyDN).  The extension utilizes controls [RFC4511] attached to   update requests to request and return copies of the target entry.   One request control, called the Pre-Read request control, indicates   that a copy of the entry before application of update is to be   returned.  Another control, called the Post-Read request control,   indicates that a copy of the entry after application of the update is   to be returned.  Each request control has a corresponding response   control used to return the entry.   To ensure proper isolation, the controls are processed as an atomic   part of the update operation.   The functionality offered by these controls is based upon similar   functionality in the X.500 Directory Access Protocol (DAP) [X.511].   The Pre-Read controls may be used to obtain replaced or deleted   values of modified attributes or a copy of the entry being deleted.   The Post-Read controls may be used to obtain values of operational   attributes, such as the 'entryUUID' [RFC4530] and 'modifyTimestamp'   [RFC4512] attributes, updated by the server as part of the update   operation.2. 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 inSection 5.1 of [RFC4511].   DN stands for Distinguished Name.   DSA stands for Directory System Agent (i.e., a directory server).   DSE stands for DSA-specific Entry.   In this document, the key words "MUST", "MUST NOT", "REQUIRED",   "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",   and "OPTIONAL" are to be interpreted as described inBCP 14   [RFC2119].Zeilenga                    Standards Track                     [Page 2]

RFC 4527                LDAP Read Entry Controls               June 20063.  Read Entry Controls3.1.  The Pre-Read Controls   The Pre-Read request and response controls are identified by the   1.3.6.1.1.13.1 object identifier.  Servers implementing these   controls SHOULD publish 1.3.6.1.1.13.1 as a value of the   'supportedControl' [RFC4512] in their root DSE.   The Pre-Read request control is a LDAP Control [RFC4511] whose   controlType is 1.3.6.1.1.13.1 and whose controlValue is a BER-encoded   AttributeSelection [RFC4511], as extended by [RFC3673].  The   criticality may be TRUE or FALSE.  This control is appropriate for   the modifyRequest, delRequest, and modDNRequest LDAP messages.   The corresponding response control is a LDAP Control whose   controlType is 1.3.6.1.1.13.1 and whose the controlValue, an OCTET   STRING, contains a BER-encoded SearchResultEntry.  The criticality   may be TRUE or FALSE.  This control is appropriate for the   modifyResponse, delResponse, and modDNResponse LDAP messages with a   resultCode of success (0).   When the request control is attached to an appropriate update LDAP   request, the control requests the return of a copy of the target   entry prior to the application of the update.  The AttributeSelection   indicates, as discussed in [RFC4511][RFC3673], which attributes are   requested to appear in the copy.  The server is to return a   SearchResultEntry containing, subject to access controls and other   constraints, values of the requested attributes.   The normal processing of the update operation and the processing of   this control MUST be performed as one atomic action isolated from   other update operations.   If the update operation fails (in either normal or control   processing), no Pre-Read response control is provided.3.2.  The Post-Read Controls   The Post-Read request and response controls are identified by the   1.3.6.1.1.13.2 object identifier.  Servers implementing these   controls SHOULD publish 1.3.6.1.1.13.2 as a value of the   'supportedControl' [RFC4512] in their root DSE.   The Post-Read request control is a LDAP Control [RFC4511] whose   controlType is 1.3.6.1.1.13.2 and whose controlValue, an OCTET   STRING, contains a BER-encoded AttributeSelection [RFC4511], as   extended by [RFC3673].  The criticality may be TRUE or FALSE.  ThisZeilenga                    Standards Track                     [Page 3]

RFC 4527                LDAP Read Entry Controls               June 2006   control is appropriate for the addRequest, modifyRequest, and   modDNRequest LDAP messages.   The corresponding response control is a LDAP Control whose   controlType is 1.3.6.1.1.13.2 and whose controlValue is a BER-encoded   SearchResultEntry.  The criticality may be TRUE or FALSE.  This   control is appropriate for the addResponse, modifyResponse, and   modDNResponse LDAP messages with a resultCode of success (0).   When the request control is attached to an appropriate update LDAP   request, the control requests the return of a copy of the target   entry after the application of the update.  The AttributeSelection   indicates, as discussed in [RFC4511][RFC3673], which attributes are   requested to appear in the copy.  The server is to return a   SearchResultEntry containing, subject to access controls and other   constraints, values of the requested attributes.   The normal processing of the update operation and the processing of   this control MUST be performed as one atomic action isolated from   other update operations.   If the update operation fails (in either normal or control   processing), no Post-Read response control is provided.4.  Interaction with Other Controls   The Pre-Read and Post-Read controls may be combined with each other   and/or with a variety of other controls.  When combined with the   assertion control [RFC4528] and/or the manageDsaIT control [RFC3296],   the semantics of each control included in the combination applies.   The Pre-Read and Post-Read controls may be combined with other   controls as detailed in other technical specifications.5.  Security Considerations   The controls defined in this document extend update operations to   support read capabilities.  Servers MUST ensure that the client is   authorized for reading of the information provided in this control   and that the client is authorized to perform the requested directory   update.   Security considerations for the update operations [RFC4511] extended   by this control, as well as general LDAP security considerations   [RFC4510], generally apply to implementation and use of this   extensionZeilenga                    Standards Track                     [Page 4]

RFC 4527                LDAP Read Entry Controls               June 20066.  IANA Considerations   Registration of the following protocol values [RFC4520] have been   completed by the IANA.6.1.  Object Identifier   The IANA has registered an LDAP Object Identifier to identify LDAP   protocol elements 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 4527       Author/Change Controller: IESG       Comments: Identifies the LDAP Read Entry Controls6.2.  LDAP Protocol Mechanisms   The IANA has registered the LDAP Protocol Mechanism described in this   document.       Subject: Request for LDAP Protocol Mechanism Registration       Object Identifier: 1.3.6.1.1.13.1       Description: LDAP Pre-read Control       Person & email address to contact for further information:            Kurt Zeilenga <kurt@openldap.org>       Usage: Control       Specification:RFC 4527       Author/Change Controller: IESG       Comments: none       Subject: Request for LDAP Protocol Mechanism Registration       Object Identifier: 1.3.6.1.1.13.2       Description: LDAP Post-read Control       Person & email address to contact for further information:            Kurt Zeilenga <kurt@openldap.org>       Usage: Control       Specification:RFC 4527       Author/Change Controller: IESG       Comments: none7.  Acknowledgement   The LDAP Pre-Read and Post-Read controls are modeled after similar   capabilities offered in the DAP [X.511].Zeilenga                    Standards Track                     [Page 5]

RFC 4527                LDAP Read Entry Controls               June 20068.  References8.1.  Normative References   [RFC2119]     Bradner, S., "Key words for use in RFCs to Indicate                 Requirement Levels",BCP 14,RFC 2119, March 1997.   [RFC3296]     Zeilenga, K., "Named Subordinate References in                 Lightweight Directory Access Protocol (LDAP)                 Directories",RFC 3296, July 2002.   [RFC3673]     Zeilenga, K., "Lightweight Directory Access Protocol                 version 3 (LDAPv3): All Operational Attributes",RFC3673, December 2003.   [RFC4510]     Zeilenga, K., Ed, "Lightweight Directory Access                 Protocol (LDAP): Technical Specification Road Map",RFC4510, June 2006.   [RFC4511]     Sermersheim, J., Ed., "Lightweight Directory Access                 Protocol (LDAP): The Protocol",RFC 4511, June 2006.   [RFC4512]     Zeilenga, K., "Lightweight Directory Access Protocol                 (LDAP): Directory Information Models",RFC 4512, June                 2006.   [RFC4528]     Zeilenga, K., "Lightweight Directory Access Protocol                 (LDAP) Assertion Control",RFC 4528, June 2006.   [X.680]       International Telecommunication Union -                 Telecommunication Standardization Sector, "Abstract                 Syntax Notation One (ASN.1) - Specification of Basic                 Notation", X.680(1997) (also ISO/IEC 8824-1:1998).   [X.690]       International Telecommunication Union -                 Telecommunication Standardization Sector,                 "Specification of ASN.1 encoding rules: Basic Encoding                 Rules (BER), Canonical Encoding Rules (CER), and                 Distinguished Encoding Rules (DER)", X.690(1997) (also                 ISO/IEC 8825-1:1998).Zeilenga                    Standards Track                     [Page 6]

RFC 4527                LDAP Read Entry Controls               June 20068.2.  Informative References   [RFC4520]     Zeilenga, K., "Internet Assigned Numbers Authority                 (IANA) Considerations for the Lightweight Directory                 Access Protocol (LDAP)",BCP 64,RFC 4520, June 2006.   [RFC4530]     Zeilenga, K., "Lightweight Directory Access Protocol                 (LDAP) EntryUUID Operational Attribute",RFC 4530, June                 2006.   [X.511]       International Telecommunication Union -                 Telecommunication Standardization Sector, "The                 Directory: Abstract Service Definition", X.511(1993)                 (also ISO/IEC 9594-3:1993).Author's Address   Kurt D. Zeilenga   OpenLDAP Foundation   EMail: Kurt@OpenLDAP.orgZeilenga                    Standards Track                     [Page 7]

RFC 4527                LDAP Read Entry Controls               June 2006Full Copyright Statement   Copyright (C) The Internet Society (2006).   This document is subject to the rights, licenses and restrictions   contained inBCP 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   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.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 inBCP 78 andBCP 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 athttp://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.Acknowledgement   Funding for the RFC Editor function is provided by the IETF   Administrative Support Activity (IASA).Zeilenga                    Standards Track                     [Page 8]