1 files changed, 283 insertions, 0 deletions
diff --git a/doc/rfc/rfc4526.txt b/doc/rfc/rfc4526.txt
new file mode 100644
index 0000000..9795632
--- /dev/null
+++ b/doc/rfc/rfc4526.txt
@@ -0,0 +1,283 @@
+
+
+
+
+
+
+Network Working Group                                        K. Zeilenga
+Request for Comments: 4526                           OpenLDAP Foundation
+Category: Standards Track                                      June 2006
+
+
+              Lightweight Directory Access Protocol (LDAP)
+                    Absolute True and False Filters
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   This document extends the Lightweight Directory Access Protocol
+   (LDAP) to support absolute True and False filters based upon similar
+   capabilities found in X.500 directory systems.  The document also
+   extends the String Representation of LDAP Search Filters to support
+   these filters.
+
+Table of Contents
+
+   1. Background ......................................................1
+   2. Absolute True and False Filters .................................2
+   3. Security Considerations .........................................2
+   4. IANA Considerations .............................................3
+   5. References ......................................................3
+      5.1. Normative References .......................................3
+      5.2. Informative References .....................................3
+
+1.  Background
+
+   The X.500 Directory Access Protocol (DAP) [X.511] supports absolute
+   True and False assertions.  An 'and' filter with zero elements always
+   evaluates to True.  An 'or' filter with zero elements always
+   evaluates to False.  These filters are commonly used when requesting
+   DSA-specific Entries (DSEs) that do not necessarily have
+   'objectClass' attributes; that is, where "(objectClass=*)" may
+   evaluate to False.
+
+
+
+
+Zeilenga                    Standards Track                     [Page 1]
+
+RFC 4526          LDAP Absolute True and False Filters         June 2006
+
+
+   Although LDAPv2 [RFC1777][RFC3494] placed no restriction on the
+   number of elements in 'and' and 'or' filter sets, the LDAPv2 string
+   representation [RFC1960][RFC3494] could not represent empty 'and' and
+   'or' filter sets.  Due to this, absolute True or False filters were
+   (unfortunately) eliminated from LDAPv3 [RFC4510].
+
+   This documents extends LDAPv3 to support absolute True and False
+   assertions by allowing empty 'and' and 'or' in Search filters
+   [RFC4511] and extends the filter string representation [RFC4515] to
+   allow empty filter lists.
+
+   It is noted that certain search operations, such as those used to
+   retrieve subschema information [RFC4512], require use of particular
+   filters.  This document does not change these requirements.
+
+   This feature is intended to allow a more direct mapping between DAP
+   and LDAP (as needed to implement DAP-to-LDAP gateways).
+
+   In this document, the key words "MUST", "MUST NOT", "REQUIRED",
+   "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
+   and "OPTIONAL" are to be interpreted as described in BCP 14
+   [RFC2119].
+
+2.  Absolute True and False Filters
+
+   Implementations of this extension SHALL allow 'and' and 'or' choices
+   with zero filter elements.
+
+   An 'and' filter consisting of an empty set of filters SHALL evaluate
+   to True.  This filter is represented by the string "(&)".
+
+   An 'or' filter consisting of an empty set of filters SHALL evaluate
+   to False.  This filter is represented by the string "(|)".
+
+   Servers supporting this feature SHOULD publish the Object Identifier
+   1.3.6.1.4.1.4203.1.5.3 as a value of the 'supportedFeatures'
+   [RFC4512] attribute in the root DSE.
+
+   Clients supporting this feature SHOULD NOT use the feature unless
+   they know that the server supports it.
+
+3.  Security Considerations
+
+   The (re)introduction of absolute True and False filters is not
+   believed to raise any new security considerations.
+
+   Implementors of this (or any) LDAPv3 extension should be familiar
+   with general LDAPv3 security considerations [RFC4510].
+
+
+
+Zeilenga                    Standards Track                     [Page 2]
+
+RFC 4526          LDAP Absolute True and False Filters         June 2006
+
+
+4.  IANA Considerations
+
+   Registration of this feature has been completed by the IANA
+   [RFC4520].
+
+   Subject: Request for LDAP Protocol Mechanism Registration Object
+   Identifier: 1.3.6.1.4.1.4203.1.5.3 Description: True/False filters
+   Person & email address to contact for further information:
+        Kurt Zeilenga <kurt@openldap.org> Usage: Feature Specification:
+   RFC 4526 Author/Change Controller: IESG Comments: none
+
+   This OID was assigned [ASSIGN] by OpenLDAP Foundation, under its
+   IANA-assigned private enterprise allocation [PRIVATE], for use in
+   this specification.
+
+5.  References
+
+5.1.  Normative References
+
+   [RFC2119]     Bradner, S., "Key words for use in RFCs to Indicate
+                 Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC4510]     Zeilenga, K., Ed, "Lightweight Directory Access
+                 Protocol (LDAP): Technical Specification Road Map", RFC
+                 4510, June 2006.
+
+   [RFC4511]     Sermersheim, J., Ed., "Lightweight Directory Access
+                 Protocol (LDAP): The Protocol", RFC 4511, June 2006.
+
+   [RFC4512]     Zeilenga, K., "Lightweight Directory Access Protocol
+                 (LDAP): Directory Information Models", RFC 4512, June
+                 2006.
+
+   [RFC4515]     Smith, M., Ed. and T. Howes, "Lightweight Directory
+                 Access Protocol (LDAP): String Representation of Search
+                 Filters", RFC 4515, June 2006.
+
+5.2.  Informative References
+
+   [RFC1777]     Yeong, W., Howes, T., and S. Kille, "Lightweight
+                 Directory Access Protocol", RFC 1777, March 1995.
+
+   [RFC1960]     Howes, T., "A String Representation of LDAP Search
+                 Filters", RFC 1960, June 1996.
+
+   [RFC3494]     Zeilenga, K., "Lightweight Directory Access Protocol
+                 version 2 (LDAPv2) to Historic Status", RFC 3494, March
+                 2003.
+
+
+
+Zeilenga                    Standards Track                     [Page 3]
+
+RFC 4526          LDAP Absolute True and False Filters         June 2006
+
+
+   [RFC4520]     Zeilenga, K., "Internet Assigned Numbers Authority
+                 (IANA) Considerations for the Lightweight Directory
+                 Access Protocol (LDAP)", BCP 64, RFC 4520, June 2006.
+
+   [X.500]       International Telecommunication Union -
+                 Telecommunication Standardization Sector, "The
+                 Directory -- Overview of concepts, models and
+                 services," X.500(1993) (also ISO/IEC 9594-1:1994).
+
+   [X.501]       International Telecommunication Union -
+                 Telecommunication Standardization Sector, "The
+                 Directory -- Models," X.501(1993) (also ISO/IEC 9594-
+                 2:1994).
+
+   [X.511]       International Telecommunication Union -
+                 Telecommunication Standardization Sector, "The
+                 Directory: Abstract Service Definition", X.511(1993)
+                 (also ISO/IEC 9594-3:1993).
+
+   [ASSIGN]      OpenLDAP Foundation, "OpenLDAP OID Delegations",
+                 http://www.openldap.org/foundation/oid-delegate.txt.
+
+   [PRIVATE]     IANA, "Private Enterprise Numbers",
+                 http://www.iana.org/assignments/enterprise-numbers.
+
+Author's Address
+
+   Kurt D. Zeilenga
+   OpenLDAP Foundation
+
+   EMail: Kurt@OpenLDAP.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga                    Standards Track                     [Page 4]
+
+RFC 4526          LDAP Absolute True and False Filters         June 2006
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2006).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Zeilenga                    Standards Track                     [Page 5]
+