idnits 2.17.1 draft-zeilenga-ldap-readentry-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 22. -- Found old boilerplate from RFC 3978, Section 5.5 on line 337. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 310. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 317. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 323. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 329), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 39. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (10 February 2005) is 6986 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- No information found for draft-ietf-ldapbis-roadmap-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'Roadmap' -- No information found for draft-ietf-ldapbis-protocol-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'Protocol' -- No information found for draft-ietf-ldapbis-models-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'Models' -- No information found for draft-zeilenga-ldap-assert-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'Assertion' -- No information found for draft-ietf-ldapbis-bcp64-xx - is the name correct? -- No information found for draft-zeilenga-ldap-uuid-xx - is the name correct? Summary: 6 errors (**), 0 flaws (~~), 2 warnings (==), 17 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Kurt D. Zeilenga 3 Intended Category: Standard Track OpenLDAP Foundation 4 Expires in six months 10 February 2005 6 LDAP Read Entry Controls 7 9 1. Status of this Memo 11 This document is intended to be, after appropriate review and 12 revision, submitted to the RFC Editor as a Standard Track document. 13 Distribution of this memo is unlimited. Technical discussion of this 14 document will take place on the IETF LDAP Extensions mailing list 15 . Please send editorial comments directly to the 16 author . 18 By submitting this Internet-Draft, I accept the provisions of Section 19 4 of RFC 3667. By submitting this Internet-Draft, I certify that any 20 applicable patent or other IPR claims of which I am aware have been 21 disclosed, or will be disclosed, and any of which I become aware will 22 be disclosed, in accordance with RFC 3668. 24 Internet-Drafts are working documents of the Internet Engineering Task 25 Force (IETF), its areas, and its working groups. Note that other 26 groups may also distribute working documents as Internet-Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference material 31 or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/1id-abstracts.html 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html 39 Copyright (C) The Internet Society (2005). All Rights Reserved. 41 Please see the Full Copyright section near the end of this document 42 for more information. 44 Abstract 46 This document specifies an extension to the Lightweight Directory 47 Access Protocol (LDAP) to allow the client to read the target entry of 48 an update operation. The client may request to read the entry before 49 and/or after the modifications are applied. These reads are done as 50 an atomic part of the update operation. 52 1. Background and Intent of Use 54 This document specifies an extension to the Lightweight Directory 55 Access Protocol (LDAP) [Roadmap] to allow the client to read the 56 target entry of an update operation (e.g., Add, Delete, Modify, 57 ModifyDN). The extension utilizes controls [Protocol] attached to 58 update requests to request and return copies of the target entry. One 59 request control, called the Pre-Read request control, indicates that a 60 copy of the entry before application of update is to be returned. 61 Another control, called the Post-Read request control, indicates that 62 a copy of the entry after application of the update is to be returned. 63 Each request control has a corresponding response control used to 64 return the entry. 66 To ensure proper isolation, the controls are processed as an atomic 67 part of the update operation. 69 The functionality offered by these controls is based upon similar 70 functionality in the X.500 Directory Access Protocol (DAP) [X.511]. 72 The Pre-Read controls may be used to obtain replaced or deleted values 73 of modified attributes or a copy of the entry being deleted. 75 The Post-Read controls may be used to obtain values of operational 76 attributes, such as the 'entryUUID' [EntryUUID] and 'modifyTimestamp' 77 [Models] attributes, updated by the server as part of the update 78 operation. 80 2. Terminology 82 Protocol elements are described using ASN.1 [X.680] with implicit 83 tags. The term "BER-encoded" means the element is to be encoded using 84 the Basic Encoding Rules [X.690] under the restrictions detailed in 85 Section 5.2 of [Protocol]. 87 DN stands for Distinguished Name. 88 DSA stands for Directory System Agent (i.e., a directory server). 89 DSE stands for DSA-specific Entry. 91 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 92 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 93 document are to be interpreted as described in BCP 14 [RFC2119]. 95 3. Read Entry Controls 97 3.1. The Pre-Read Controls 99 The Pre-Read request and response controls are identified by the 100 IANA-ASSIGNED-OID.1 object identifier. Servers implementing these 101 controls SHOULD publish IANA-ASSIGNED-OID.1 as a value of the 102 'supportedControl' [Models] in their root DSE. 104 The Pre-Read request control is an LDAP Control [Protocol] whose 105 controlType is IANA-ASSIGNED-OID.1 and whose controlValue is a 106 BER-encoded AttributeSelection [Protocol], as extended by [RFC3673]. 107 The criticality may be TRUE or FALSE. This control is appropriate for 108 the modifyRequest, delRequest, and modDNRequest LDAP messages. 110 The corresponding response control is a LDAP Control whose controlType 111 is IANA-ASSIGNED-OID.1 and whose the controlValue, an OCTET STRING, 112 contains a BER-encoded SearchResultEntry. The criticality may be TRUE 113 or FALSE. This control is appropriate for the modifyResponse, 114 delResponse, and modDNResponse LDAP messages with a resultCode of 115 success (0). 117 When the request control is attached to an appropriate update LDAP 118 request, the control requests the return of a copy of target entry 119 prior to the application of the update. The AttributeSelection 120 indicates, as discussed in [Protocol][RFC3673] which attributes are 121 requested to appear in the copy. The server is to return a 122 SearchResultEntry containing, subject to access controls and other 123 constraints, values of the requested attributes. 125 The normal processing of the update operation and the processing of 126 this control MUST be performed as one atomic action isolated from 127 other update operations. 129 If the update operation fails (in either normal or control 130 processing), no response control is provided. 132 3.2. The Post-Read Controls 134 The Post-Read request and response controls are identified by the 135 IANA-ASSIGNED-OID.2 object identifier. Servers implementing these 136 controls SHOULD publish IANA-ASSIGNED-OID.2 as a value of the 137 'supportedControl' [Models] in their root DSE. 139 The Post-Read request control is an LDAP Control [Protocol] whose 140 controlType is IANA-ASSIGNED-OID.2 and whose controlValue, an OCTET 141 STRING, contains a BER-encoded AttributeSelection [Protocol], as 142 extended by [RFC3673]. The criticality may be TRUE or FALSE. This 143 control is appropriate for the addRequest, modifyRequest, and 144 modDNRequest LDAP messages. 146 The corresponding response control is a LDAP Control whose controlType 147 is IANA-ASSIGNED-OID.2 and whose controlValue is a BER-encoded 148 SearchResultEntry. The criticality may be TRUE or FALSE. This 149 control is appropriate for the addResponse, modifyResponse, and 150 modDNResponse LDAP messages with a resultCode of success (0). 152 When the request control is attached to an appropriate update LDAP 153 request, the control requests the return of a copy of target entry 154 after the application of the update. The AttributeSelection 155 indicates, as discussed in [Protocol][RFC3673], which attributes are 156 requested to appear in the copy. The server is to return a 157 SearchResultEntry containing, subject to access controls and other 158 constraints, values of the requested attributes. 160 The normal processing of the update operation and the processing of 161 this control MUST be performed as one atomic action isolated from 162 other update operations. 164 If the update operation fails (in either normal or control 165 processing), no response control is provided. 167 4. Interaction with other controls 169 The Pre-Read and Post-Read controls may be combined with each other 170 and/or with a variety of other controls. When combined with the 171 assertion control [Assertion] and/or the manageDsaIT control 172 [RFC3296], the semantics of each control included in the combination 173 apply. The Pre-Read and Post-Read controls may be combined with other 174 controls as detailed in other technical specifications. 176 5. Security Considerations 178 The controls defined in this document extend update operations to 179 support read capabilities. Servers MUST ensure that the client is 180 authorized both for reading of the information provided in this 181 control in addition to ensuring the client is authorized to perform 182 the requested directory update. 184 Security considerations for the update operations [Protocol] extended 185 by this control, as well as general LDAP security considerations 186 [Roadmap], generally apply to implementation and use of this extension 188 6. IANA Considerations 190 Registration of the following protocol values [BCP64bis] is requested. 192 6.1. Object Identifier 194 It is requested that IANA register an LDAP Object Identifier to 195 identify LDAP protocol elements defined in this document. 197 Subject: Request for LDAP Object Identifier Registration 198 Person & email address to contact for further information: 199 Kurt Zeilenga 200 Specification: RFC XXXX 201 Author/Change Controller: IESG 202 Comments: 203 Identifies the LDAP Read Entry Controls 205 6.2. LDAP Protocol Mechanisms 207 It is requested that IANA register the LDAP Protocol Mechanism 208 described in this document. 210 Subject: Request for LDAP Protocol Mechanism Registration 211 Object Identifier: IANA-ASSIGNED-OID.1 212 Description: LDAP Pre-read Control 213 Person & email address to contact for further information: 214 Kurt Zeilenga 215 Usage: Control 216 Specification: RFC XXXX 217 Author/Change Controller: IESG 218 Comments: none 219 in 2 221 Subject: Request for LDAP Protocol Mechanism Registration 222 Object Identifier: IANA-ASSIGNED-OID.2 223 Description: LDAP Post-read Control 224 Person & email address to contact for further information: 225 Kurt Zeilenga 226 Usage: Control 227 Specification: RFC XXXX 228 Author/Change Controller: IESG 229 Comments: none 231 7. Acknowledgment 233 The LDAP Pre-Read and Post-Read controls are modeled after similar 234 capabilities offered in the DAP [X.511]. 236 8. References 238 [[Note to the RFC Editor: please replace the citation tags used in 239 referencing Internet-Drafts with tags of the form RFCnnnn where 240 possible.]] 242 8.1. Normative References 244 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 245 Requirement Levels", BCP 14 (also RFC 2119), March 1997. 247 [Roadmap] Zeilenga, K. (editor), "LDAP: Technical Specification 248 Road Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in 249 progress. 251 [Protocol] Sermersheim, J. (editor), "LDAP: The Protocol", 252 draft-ietf-ldapbis-protocol-xx.txt, a work in progress. 254 [Models] Zeilenga, K. (editor), "LDAP: Directory Information 255 Models", draft-ietf-ldapbis-models-xx.txt, a work in 256 progress. 258 [RFC3296] Zeilenga, K., "Named Subordinate References in 259 Lightweight Directory Access Protocol (LDAP) 260 Directories", RFC 3296, July 2002. 262 [RFC3673] Zeilenga, K., "LDAPv3: All Operational Attributes", RFC 263 3673, December 2003. 265 [Assertion] Zeilenga, K., "LDAP Assertion Control", 266 draft-zeilenga-ldap-assert-xx.txt, a work in progress. 268 [X.680] International Telecommunication Union - 269 Telecommunication Standardization Sector, "Abstract 270 Syntax Notation One (ASN.1) - Specification of Basic 271 Notation", X.680(1997) (also ISO/IEC 8824-1:1998). 273 [X.690] International Telecommunication Union - 274 Telecommunication Standardization Sector, "Specification 275 of ASN.1 encoding rules: Basic Encoding Rules (BER), 276 Canonical Encoding Rules (CER), and Distinguished 277 Encoding Rules (DER)", X.690(1997) (also ISO/IEC 278 8825-1:1998). 280 8.2. Informative References 282 [BCP64bis] Zeilenga, K., "IANA Considerations for LDAP", 283 draft-ietf-ldapbis-bcp64-xx.txt, a work in progress. 285 [EntryUUID] Zeilenga, K., "The LDAP EntryUUID Operational 286 Attribute", draft-zeilenga-ldap-uuid-xx.txt, a work in 287 progress. 289 [X.511] International Telecommunication Union - 290 Telecommunication Standardization Sector, "The 291 Directory: Abstract Service Definition", X.511(1993) 292 (also ISO/IEC 9594-3:1993). 294 10. Author's Address 296 Kurt D. Zeilenga 297 OpenLDAP Foundation 299 Email: Kurt@OpenLDAP.org 301 Intellectual Property Rights 303 The IETF takes no position regarding the validity or scope of any 304 Intellectual Property Rights or other rights that might be claimed to 305 pertain to the implementation or use of the technology described in 306 this document or the extent to which any license under such rights 307 might or might not be available; nor does it represent that it has 308 made any independent effort to identify any such rights. Information 309 on the procedures with respect to rights in RFC documents can be found 310 in BCP 78 and BCP 79. 312 Copies of IPR disclosures made to the IETF Secretariat and any 313 assurances of licenses to be made available, or the result of an 314 attempt made to obtain a general license or permission for the use of 315 such proprietary rights by implementers or users of this specification 316 can be obtained from the IETF on-line IPR repository at 317 http://www.ietf.org/ipr. 319 The IETF invites any interested party to bring to its attention any 320 copyrights, patents or patent applications, or other proprietary 321 rights that may cover technology that may be required to implement 322 this standard. Please address the information to the IETF at 323 ietf-ipr@ietf.org. 325 Full Copyright 327 Copyright (C) The Internet Society (2005). This document is subject 328 to the rights, licenses and restrictions contained in BCP 78, and 329 except as set forth therein, the authors retain all their rights. 331 This document and the information contained herein are provided on an 332 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 333 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 334 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 335 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 336 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 337 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.