]> git.sur5r.net Git - openldap/blob - doc/rfc/rfc4526.txt
Merge remote-tracking branch 'origin/mdb.RE/0.9'
[openldap] / doc / rfc / rfc4526.txt
1
2
3
4
5
6
7 Network Working Group                                        K. Zeilenga
8 Request for Comments: 4526                           OpenLDAP Foundation
9 Category: Standards Track                                      June 2006
10
11
12               Lightweight Directory Access Protocol (LDAP)
13                     Absolute True and False Filters
14
15 Status of This Memo
16
17    This document specifies an Internet standards track protocol for the
18    Internet community, and requests discussion and suggestions for
19    improvements.  Please refer to the current edition of the "Internet
20    Official Protocol Standards" (STD 1) for the standardization state
21    and status of this protocol.  Distribution of this memo is unlimited.
22
23 Copyright Notice
24
25    Copyright (C) The Internet Society (2006).
26
27 Abstract
28
29    This document extends the Lightweight Directory Access Protocol
30    (LDAP) to support absolute True and False filters based upon similar
31    capabilities found in X.500 directory systems.  The document also
32    extends the String Representation of LDAP Search Filters to support
33    these filters.
34
35 Table of Contents
36
37    1. Background ......................................................1
38    2. Absolute True and False Filters .................................2
39    3. Security Considerations .........................................2
40    4. IANA Considerations .............................................3
41    5. References ......................................................3
42       5.1. Normative References .......................................3
43       5.2. Informative References .....................................3
44
45 1.  Background
46
47    The X.500 Directory Access Protocol (DAP) [X.511] supports absolute
48    True and False assertions.  An 'and' filter with zero elements always
49    evaluates to True.  An 'or' filter with zero elements always
50    evaluates to False.  These filters are commonly used when requesting
51    DSA-specific Entries (DSEs) that do not necessarily have
52    'objectClass' attributes; that is, where "(objectClass=*)" may
53    evaluate to False.
54
55
56
57
58 Zeilenga                    Standards Track                     [Page 1]
59 \f
60 RFC 4526          LDAP Absolute True and False Filters         June 2006
61
62
63    Although LDAPv2 [RFC1777][RFC3494] placed no restriction on the
64    number of elements in 'and' and 'or' filter sets, the LDAPv2 string
65    representation [RFC1960][RFC3494] could not represent empty 'and' and
66    'or' filter sets.  Due to this, absolute True or False filters were
67    (unfortunately) eliminated from LDAPv3 [RFC4510].
68
69    This documents extends LDAPv3 to support absolute True and False
70    assertions by allowing empty 'and' and 'or' in Search filters
71    [RFC4511] and extends the filter string representation [RFC4515] to
72    allow empty filter lists.
73
74    It is noted that certain search operations, such as those used to
75    retrieve subschema information [RFC4512], require use of particular
76    filters.  This document does not change these requirements.
77
78    This feature is intended to allow a more direct mapping between DAP
79    and LDAP (as needed to implement DAP-to-LDAP gateways).
80
81    In this document, the key words "MUST", "MUST NOT", "REQUIRED",
82    "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
83    and "OPTIONAL" are to be interpreted as described in BCP 14
84    [RFC2119].
85
86 2.  Absolute True and False Filters
87
88    Implementations of this extension SHALL allow 'and' and 'or' choices
89    with zero filter elements.
90
91    An 'and' filter consisting of an empty set of filters SHALL evaluate
92    to True.  This filter is represented by the string "(&)".
93
94    An 'or' filter consisting of an empty set of filters SHALL evaluate
95    to False.  This filter is represented by the string "(|)".
96
97    Servers supporting this feature SHOULD publish the Object Identifier
98    1.3.6.1.4.1.4203.1.5.3 as a value of the 'supportedFeatures'
99    [RFC4512] attribute in the root DSE.
100
101    Clients supporting this feature SHOULD NOT use the feature unless
102    they know that the server supports it.
103
104 3.  Security Considerations
105
106    The (re)introduction of absolute True and False filters is not
107    believed to raise any new security considerations.
108
109    Implementors of this (or any) LDAPv3 extension should be familiar
110    with general LDAPv3 security considerations [RFC4510].
111
112
113
114 Zeilenga                    Standards Track                     [Page 2]
115 \f
116 RFC 4526          LDAP Absolute True and False Filters         June 2006
117
118
119 4.  IANA Considerations
120
121    Registration of this feature has been completed by the IANA
122    [RFC4520].
123
124    Subject: Request for LDAP Protocol Mechanism Registration Object
125    Identifier: 1.3.6.1.4.1.4203.1.5.3 Description: True/False filters
126    Person & email address to contact for further information:
127         Kurt Zeilenga <kurt@openldap.org> Usage: Feature Specification:
128    RFC 4526 Author/Change Controller: IESG Comments: none
129
130    This OID was assigned [ASSIGN] by OpenLDAP Foundation, under its
131    IANA-assigned private enterprise allocation [PRIVATE], for use in
132    this specification.
133
134 5.  References
135
136 5.1.  Normative References
137
138    [RFC2119]     Bradner, S., "Key words for use in RFCs to Indicate
139                  Requirement Levels", BCP 14, RFC 2119, March 1997.
140
141    [RFC4510]     Zeilenga, K., Ed, "Lightweight Directory Access
142                  Protocol (LDAP): Technical Specification Road Map", RFC
143                  4510, June 2006.
144
145    [RFC4511]     Sermersheim, J., Ed., "Lightweight Directory Access
146                  Protocol (LDAP): The Protocol", RFC 4511, June 2006.
147
148    [RFC4512]     Zeilenga, K., "Lightweight Directory Access Protocol
149                  (LDAP): Directory Information Models", RFC 4512, June
150                  2006.
151
152    [RFC4515]     Smith, M., Ed. and T. Howes, "Lightweight Directory
153                  Access Protocol (LDAP): String Representation of Search
154                  Filters", RFC 4515, June 2006.
155
156 5.2.  Informative References
157
158    [RFC1777]     Yeong, W., Howes, T., and S. Kille, "Lightweight
159                  Directory Access Protocol", RFC 1777, March 1995.
160
161    [RFC1960]     Howes, T., "A String Representation of LDAP Search
162                  Filters", RFC 1960, June 1996.
163
164    [RFC3494]     Zeilenga, K., "Lightweight Directory Access Protocol
165                  version 2 (LDAPv2) to Historic Status", RFC 3494, March
166                  2003.
167
168
169
170 Zeilenga                    Standards Track                     [Page 3]
171 \f
172 RFC 4526          LDAP Absolute True and False Filters         June 2006
173
174
175    [RFC4520]     Zeilenga, K., "Internet Assigned Numbers Authority
176                  (IANA) Considerations for the Lightweight Directory
177                  Access Protocol (LDAP)", BCP 64, RFC 4520, June 2006.
178
179    [X.500]       International Telecommunication Union -
180                  Telecommunication Standardization Sector, "The
181                  Directory -- Overview of concepts, models and
182                  services," X.500(1993) (also ISO/IEC 9594-1:1994).
183
184    [X.501]       International Telecommunication Union -
185                  Telecommunication Standardization Sector, "The
186                  Directory -- Models," X.501(1993) (also ISO/IEC 9594-
187                  2:1994).
188
189    [X.511]       International Telecommunication Union -
190                  Telecommunication Standardization Sector, "The
191                  Directory: Abstract Service Definition", X.511(1993)
192                  (also ISO/IEC 9594-3:1993).
193
194    [ASSIGN]      OpenLDAP Foundation, "OpenLDAP OID Delegations",
195                  http://www.openldap.org/foundation/oid-delegate.txt.
196
197    [PRIVATE]     IANA, "Private Enterprise Numbers",
198                  http://www.iana.org/assignments/enterprise-numbers.
199
200 Author's Address
201
202    Kurt D. Zeilenga
203    OpenLDAP Foundation
204
205    EMail: Kurt@OpenLDAP.org
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226 Zeilenga                    Standards Track                     [Page 4]
227 \f
228 RFC 4526          LDAP Absolute True and False Filters         June 2006
229
230
231 Full Copyright Statement
232
233    Copyright (C) The Internet Society (2006).
234
235    This document is subject to the rights, licenses and restrictions
236    contained in BCP 78, and except as set forth therein, the authors
237    retain all their rights.
238
239    This document and the information contained herein are provided on an
240    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
241    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
242    ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
243    INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
244    INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
245    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
246
247 Intellectual Property
248
249    The IETF takes no position regarding the validity or scope of any
250    Intellectual Property Rights or other rights that might be claimed to
251    pertain to the implementation or use of the technology described in
252    this document or the extent to which any license under such rights
253    might or might not be available; nor does it represent that it has
254    made any independent effort to identify any such rights.  Information
255    on the procedures with respect to rights in RFC documents can be
256    found in BCP 78 and BCP 79.
257
258    Copies of IPR disclosures made to the IETF Secretariat and any
259    assurances of licenses to be made available, or the result of an
260    attempt made to obtain a general license or permission for the use of
261    such proprietary rights by implementers or users of this
262    specification can be obtained from the IETF on-line IPR repository at
263    http://www.ietf.org/ipr.
264
265    The IETF invites any interested party to bring to its attention any
266    copyrights, patents or patent applications, or other proprietary
267    rights that may cover technology that may be required to implement
268    this standard.  Please address the information to the IETF at
269    ietf-ipr@ietf.org.
270
271 Acknowledgement
272
273    Funding for the RFC Editor function is provided by the IETF
274    Administrative Support Activity (IASA).
275
276
277
278
279
280
281
282 Zeilenga                    Standards Track                     [Page 5]
283 \f