s4:torture: send the TCONX_FLAG_EXTENDED_RESPONSE flag
[Samba/gebeck_regimport.git] / source4 / ldap_server / devdocs / rfc4525.txt
blob6e15e4f6e974aca5a3ccb3895bdc125b027fd18c
7 Network Working Group                                        K. Zeilenga
8 Request for Comments: 4525                           OpenLDAP Foundation
9 Category: Informational                                        June 2006
12               Lightweight Directory Access Protocol (LDAP)
13                        Modify-Increment Extension
16 Status of This Memo
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.
22 Copyright Notice
24    Copyright (C) The Internet Society (2006).
26 Abstract
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.
34 Table of Contents
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
48 1.  Background and Intended Use
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
58 Zeilenga                     Informational                      [Page 1]
60 RFC 4525            LDAP Modify-Increment Extension            June 2006
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.
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.
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].
78 2.  The Modify-Increment Extension
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.
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.
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.
102 3. LDIF Support
104    To represent Modify-Increment requests in LDAP Data Interchange
105    Format [RFC2849], the ABNF [RFC4234] production <mod-spec> is
106    extended as follows:
108        mod-spec =/ "increment:" FILL AttributeDescription SEP
109             attrval-spec "-" SEP
114 Zeilenga                     Informational                      [Page 2]
116 RFC 4525            LDAP Modify-Increment Extension            June 2006
119    For example,
121        # Increment uidNumber
122        dn: cn=max-assigned uidNumber,dc=example,dc=com
123        changetype: modify
124        increment: uidNumber
125        uidNumber: 1
126        -
128    This LDIF fragment represents a Modify request to increment the
129    value(s) of uidNumber by 1.
131 4.  Security Considerations
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.
141 5.  IANA Considerations
143    Registration of the following values [RFC4520] have been completed.
145 5.1.  Object Identifier
147    The IANA has assigned an LDAP Object Identifier to identify the LDAP
148    Modify-Increment feature, as defined in this document.
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
158 5.2.  LDAP Protocol Mechanism
160    The following LDAP Protocol Mechanism has been registered.
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>
170 Zeilenga                     Informational                      [Page 3]
172 RFC 4525            LDAP Modify-Increment Extension            June 2006
175        Usage: Feature
176        Specification: RFC 4525
177        Author/Change Controller: Kurt Zeilenga <kurt@openldap.org>
178        Comments: none
180 5.3.  LDAP Protocol Mechanism
182    The IANA has assigned an LDAP ModifyRequest Operation Type (3)
183    [RFC4520] for use in this document.
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
195 6.  References
197 6.1.  Normative References
199    [RFC2119]     Bradner, S., "Key words for use in RFCs to Indicate
200                  Requirement Levels", BCP 14, RFC 2119, March 1997.
202    [RFC4234]     Crocker, D. and P. Overell, "Augmented BNF for Syntax
203                  Specifications: ABNF", RFC 4234, October 2005.
205    [RFC2849]     Good, G., "The LDAP Data Interchange Format (LDIF) -
206                  Technical Specification", RFC 2849, June 2000.
208    [RFC4510]     Zeilenga, K., Ed., "Lightweight Directory Access
209                  Protocol (LDAP): Technical Specification Road Map", RFC
210                  4510, June 2006.
212    [RFC4511]     Sermersheim, J., Ed., "Lightweight Directory Access
213                  Protocol (LDAP): The Protocol", RFC 4511, June 2006.
215    [RFC4512]     Zeilenga, K., "Lightweight Directory Access Protocol
216                  (LDAP): Directory Information Models", RFC 4512, June
217                  2006.
226 Zeilenga                     Informational                      [Page 4]
228 RFC 4525            LDAP Modify-Increment Extension            June 2006
231 6.2.  Informative References
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.
237    [RFC4527]     Zeilenga, K., "Lightweight Directory Access Protocol
238                  (LDAP) Read Entry Controls", RFC 4527, June 2006.
240    [RFC4528]     Zeilenga, K., "Lightweight Directory Access Protocol
241                  (LDAP) Assertion Control", RFC 4528, June 2006.
243 Author's Address
245    Kurt D. Zeilenga
246    OpenLDAP Foundation
248    EMail: Kurt@OpenLDAP.org
282 Zeilenga                     Informational                      [Page 5]
284 RFC 4525            LDAP Modify-Increment Extension            June 2006
287 Full Copyright Statement
289    Copyright (C) The Internet Society (2006).
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.
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.
303 Intellectual Property
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.
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.
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.
327 Acknowledgement
329    Funding for the RFC Editor function is provided by the IETF
330    Administrative Support Activity (IASA).
338 Zeilenga                     Informational                      [Page 6]