source: branches/samba-3.5.x/source4/ldap_server/devdocs/rfc4526.txt

Last change on this file was 414, checked in by Herwig Bauernfeind, 15 years ago

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