source4/ldap_server/devdocs/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