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