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 60RFC 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 862. 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 1043. 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 114Zeilenga Standards Track [Page 2] 115 116RFC 4526 LDAP Absolute True and False Filters June 2006 117 118 1194. 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 1345. References 135 1365.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 1565.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 170Zeilenga Standards Track [Page 3] 171 172RFC 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 200Author'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 226Zeilenga Standards Track [Page 4] 227 228RFC 4526 LDAP Absolute True and False Filters June 2006 229 230 231Full 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 247Intellectual 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 271Acknowledgement 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 282Zeilenga Standards Track [Page 5] 283 284