1 2 3 4 5 6 7Network Working Group K. Zeilenga 8Request for Comments: 4525 OpenLDAP Foundation 9Category: Informational June 2006 10 11 12 Lightweight Directory Access Protocol (LDAP) 13 Modify-Increment Extension 14 15 16Status of This Memo 17 18 This memo provides information for the Internet community. It does 19 not specify an Internet standard of any kind. Distribution of this 20 memo is unlimited. 21 22Copyright Notice 23 24 Copyright (C) The Internet Society (2006). 25 26Abstract 27 28 This document describes an extension to the Lightweight Directory 29 Access Protocol (LDAP) Modify operation to support an increment 30 capability. This extension is useful in provisioning applications, 31 especially when combined with the assertion control and/or the pre- 32 read or post-read control extension. 33 34Table of Contents 35 36 1. Background and Intended Use .....................................1 37 2. The Modify-Increment Extension ..................................2 38 3. LDIF Support ....................................................2 39 4. Security Considerations .........................................3 40 5. IANA Considerations .............................................3 41 5.1. Object Identifier ..........................................3 42 5.2. LDAP Protocol Mechanism ....................................3 43 5.3. LDAP Protocol Mechanism ....................................4 44 6. References ......................................................4 45 6.1. Normative References .......................................4 46 6.2. Informative References .....................................5 47 481. Background and Intended Use 49 50 The Lightweight Directory Access Protocol (LDAP) [RFC4510] does not 51 currently provide an operation to increment values of an attribute. 52 A client must read the values of the attribute and then modify those 53 values to increment them by the desired amount. As the values may be 54 updated by other clients between this add and modify, the client must 55 56 57 58Zeilenga Informational [Page 1] 59 60RFC 4525 LDAP Modify-Increment Extension June 2006 61 62 63 be careful to construct the modify request so that it fails in this 64 case, and upon failure, to re-read the values and construct a new 65 modify request. 66 67 This document extends the LDAP Modify Operation [RFC4511] to support 68 an increment values capability. This feature is intended to be used 69 with either the LDAP pre-read or post-read control extensions 70 [RFC4527]. This feature may also be used with the LDAP assertion 71 control extension [RFC4528] to provide test-and-increment 72 functionality. 73 74 In this document key words "MUST", "MUST NOT", "REQUIRED", "SHALL", 75 "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 76 "OPTIONAL" are to be interpreted as described in BCP 14 [RFC2119]. 77 782. The Modify-Increment Extension 79 80 This document extends the LDAP Modify request to support a increment 81 values capability. Implementations of this extension SHALL support 82 an additional ModifyRequest operation enumeration value increment 83 (3), as described herein. Implementations not supporting this 84 extension will treat this value as they would an unlisted value, 85 e.g., as a protocol error. 86 87 The increment (3) operation value specifies that an increment values 88 modification is requested. All existing values of the modification 89 attribute are to be incremented by the listed value. The 90 modification attribute must be appropriate for the request (e.g., it 91 must have INTEGER or other increment-able values), and the 92 modification must provide one and only one value. If the attribute 93 is not appropriate for the request, a constraintViolation or other 94 appropriate error is to be returned. If multiple values are 95 provided, a protocolError is to be returned. 96 97 Servers supporting this feature SHOULD publish the object identifier 98 (OID) 1.3.6.1.1.14 as a value of the 'supportedFeatures' [RFC4512] 99 attribute in the root DSE. Clients supporting this feature SHOULD 100 NOT use the feature unless they know the server supports it. 101 1023. LDIF Support 103 104 To represent Modify-Increment requests in LDAP Data Interchange 105 Format [RFC2849], the ABNF [RFC4234] production <mod-spec> is 106 extended as follows: 107 108 mod-spec =/ "increment:" FILL AttributeDescription SEP 109 attrval-spec "-" SEP 110 111 112 113 114Zeilenga Informational [Page 2] 115 116RFC 4525 LDAP Modify-Increment Extension June 2006 117 118 119 For example, 120 121 # Increment uidNumber 122 dn: cn=max-assigned uidNumber,dc=example,dc=com 123 changetype: modify 124 increment: uidNumber 125 uidNumber: 1 126 - 127 128 This LDIF fragment represents a Modify request to increment the 129 value(s) of uidNumber by 1. 130 1314. Security Considerations 132 133 General LDAP security considerations [RFC4510], as well as those 134 specific to the LDAP Modify [RFC4511], apply to this Modify-Increment 135 extension. Beyond these considerations, it is noted that 136 introduction of this extension should reduce application complexity 137 (by providing one operation for what presently requires multiple 138 operations) and, hence, it may aid in the production of correct and 139 secure implementations. 140 1415. IANA Considerations 142 143 Registration of the following values [RFC4520] have been completed. 144 1455.1. Object Identifier 146 147 The IANA has assigned an LDAP Object Identifier to identify the LDAP 148 Modify-Increment feature, as defined in this document. 149 150 Subject: Request for LDAP Object Identifier Registration 151 Person & email address to contact for further information: 152 Kurt Zeilenga <kurt@OpenLDAP.org> 153 Specification: RFC 4525 154 Author/Change Controller: Author 155 Comments: 156 Identifies the LDAP Modify-Increment feature 157 1585.2. LDAP Protocol Mechanism 159 160 The following LDAP Protocol Mechanism has been registered. 161 162 Subject: Request for LDAP Protocol Mechanism Registration 163 Object Identifier: 1.3.6.1.1.14 164 Description: Modify-Increment 165 Person & email address to contact for further information: 166 Kurt Zeilenga <kurt@openldap.org> 167 168 169 170Zeilenga Informational [Page 3] 171 172RFC 4525 LDAP Modify-Increment Extension June 2006 173 174 175 Usage: Feature 176 Specification: RFC 4525 177 Author/Change Controller: Kurt Zeilenga <kurt@openldap.org> 178 Comments: none 179 1805.3. LDAP Protocol Mechanism 181 182 The IANA has assigned an LDAP ModifyRequest Operation Type (3) 183 [RFC4520] for use in this document. 184 185 Subject: Request for LDAP Protocol Mechanism Registration 186 ModifyRequest Operation Name: increment 187 Description: Modify-Increment 188 Person & email address to contact for further information: 189 Kurt Zeilenga <kurt@openldap.org> 190 Usage: Feature 191 Specification: RFC 4525 192 Author/Change Controller: Kurt Zeilenga <kurt@openldap.org> 193 Comments: none 194 1956. References 196 1976.1. Normative References 198 199 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 200 Requirement Levels", BCP 14, RFC 2119, March 1997. 201 202 [RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 203 Specifications: ABNF", RFC 4234, October 2005. 204 205 [RFC2849] Good, G., "The LDAP Data Interchange Format (LDIF) - 206 Technical Specification", RFC 2849, June 2000. 207 208 [RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access 209 Protocol (LDAP): Technical Specification Road Map", RFC 210 4510, June 2006. 211 212 [RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access 213 Protocol (LDAP): The Protocol", RFC 4511, June 2006. 214 215 [RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol 216 (LDAP): Directory Information Models", RFC 4512, June 217 2006. 218 219 220 221 222 223 224 225 226Zeilenga Informational [Page 4] 227 228RFC 4525 LDAP Modify-Increment Extension June 2006 229 230 2316.2. Informative References 232 233 [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority 234 (IANA) Considerations for the Lightweight Directory 235 Access Protocol (LDAP)", BCP 64, RFC 4520, June 2006. 236 237 [RFC4527] Zeilenga, K., "Lightweight Directory Access Protocol 238 (LDAP) Read Entry Controls", RFC 4527, June 2006. 239 240 [RFC4528] Zeilenga, K., "Lightweight Directory Access Protocol 241 (LDAP) Assertion Control", RFC 4528, June 2006. 242 243Author's Address 244 245 Kurt D. Zeilenga 246 OpenLDAP Foundation 247 248 EMail: Kurt@OpenLDAP.org 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282Zeilenga Informational [Page 5] 283 284RFC 4525 LDAP Modify-Increment Extension June 2006 285 286 287Full Copyright Statement 288 289 Copyright (C) The Internet Society (2006). 290 291 This document is subject to the rights, licenses and restrictions 292 contained in BCP 78, and except as set forth therein, the authors 293 retain all their rights. 294 295 This document and the information contained herein are provided on an 296 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 297 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 298 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 299 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 300 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 301 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 302 303Intellectual Property 304 305 The IETF takes no position regarding the validity or scope of any 306 Intellectual Property Rights or other rights that might be claimed to 307 pertain to the implementation or use of the technology described in 308 this document or the extent to which any license under such rights 309 might or might not be available; nor does it represent that it has 310 made any independent effort to identify any such rights. Information 311 on the procedures with respect to rights in RFC documents can be 312 found in BCP 78 and BCP 79. 313 314 Copies of IPR disclosures made to the IETF Secretariat and any 315 assurances of licenses to be made available, or the result of an 316 attempt made to obtain a general license or permission for the use of 317 such proprietary rights by implementers or users of this 318 specification can be obtained from the IETF on-line IPR repository at 319 http://www.ietf.org/ipr. 320 321 The IETF invites any interested party to bring to its attention any 322 copyrights, patents or patent applications, or other proprietary 323 rights that may cover technology that may be required to implement 324 this standard. Please address the information to the IETF at 325 ietf-ipr@ietf.org. 326 327Acknowledgement 328 329 Funding for the RFC Editor function is provided by the IETF 330 Administrative Support Activity (IASA). 331 332 333 334 335 336 337 338Zeilenga Informational [Page 6] 339 340