idnits 2.17.1 draft-zeilenga-ldap-t-f-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 22. -- Found old boilerplate from RFC 3978, Section 5.5 on line 233. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 206. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 213. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 219. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 225), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 39. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (10 February 2005) is 7014 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC3674' is mentioned on line 95, but not defined ** Obsolete undefined reference: RFC 3674 (Obsoleted by RFC 4512) == Unused Reference: 'Features' is defined on line 159, but no explicit reference was found in the text -- No information found for draft-ietf-ldapbis-roadmap-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'Roadmap' -- No information found for draft-ietf-ldapbis-protocol-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'Protocol' -- No information found for draft-ietf-ldapbis-models-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'Models' -- No information found for draft-ietf-ldapbis-filter-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'Filters' ** Obsolete normative reference: RFC 3674 (ref. 'Features') (Obsoleted by RFC 4512) -- Obsolete informational reference (is this intentional?): RFC 1777 (Obsoleted by RFC 3494) -- Obsolete informational reference (is this intentional?): RFC 1960 (Obsoleted by RFC 2254) -- No information found for draft-ietf-ldapbis-bcp64-xx - is the name correct? Summary: 8 errors (**), 0 flaws (~~), 4 warnings (==), 18 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Kurt D. Zeilenga 3 Intended Category: Standard Track OpenLDAP Foundation 4 Expires in six months 10 February 2005 6 LDAP Absolute True and False Filters 7 9 Status of this Memo 11 This document is intended to be, after appropriate review and 12 revision, submitted to the RFC Editor as a Standard Track document. 13 Distribution of this memo is unlimited. Technical discussion of this 14 document will take place on the IETF LDAP Extensions mailing list 15 . Please send editorial comments directly to the 16 author . 18 By submitting this Internet-Draft, I accept the provisions of Section 19 4 of RFC 3667. By submitting this Internet-Draft, I certify that any 20 applicable patent or other IPR claims of which I am aware have been 21 disclosed, or will be disclosed, and any of which I become aware will 22 be disclosed, in accordance with RFC 3668. 24 Internet-Drafts are working documents of the Internet Engineering Task 25 Force (IETF), its areas, and its working groups. Note that other 26 groups may also distribute working documents as Internet-Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference material 31 or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/1id-abstracts.html 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html 39 Copyright (C) The Internet Society (2005). All Rights Reserved. 41 Please see the Full Copyright section near the end of this document 42 for more information. 44 Abstract 46 This document extends the Lightweight Directory Access Protocol (LDAP) 47 to support absolute True and False filters based upon similar 48 capabilities found in X.500 directory systems. The document also 49 extends the String Representation of LDAP Search Filters to support 50 these filters. 52 1. Background 54 The X.500 Directory Access Protocol (DAP) [X.511] supports absolute 55 True and False assertions. An 'and' filter with zero elements always 56 evaluates to True. An 'or' filter with zero elements always evaluates 57 to False. These filters are commonly used when requesting DSA- 58 specific Entries (DSEs) which do not necessarily have 'objectClass' 59 attributes. That is, where "(objectClass=*)" may evaluate to False. 61 While LDAPv2 [RFC1777][RFC3494] placed no restriction on the number of 62 elements in 'and' and 'or' filter sets, the LDAPv2 string 63 representation [RFC1960][RFC3494] could not represent empty 'and' and 64 'or' filter sets. Due to this, absolute True or False filters were 65 (unfortunately) eliminated from LDAPv3 [Roadmap]. 67 This documents extends LDAPv3 to support absolute True and False 68 assertions by allowing empty 'and' and 'or' in Search filters 69 [Protocol] and extends the filter string representation [Filters] to 70 allow empty filter lists. 72 It is noted that certain search operations, such as those used to 73 retrieve subschema information [Models], require use of particular 74 filters. This document does not change these requirements. 76 This feature is intended to allow a more direct mapping between DAP 77 and LDAP (as needed to implement DAP-to-LDAP gateways). 79 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 80 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 81 document are to be interpreted as described in BCP 14 [RFC2119]. 83 2. Absolute True and False Filters 85 Implementations of this extension SHALL allow 'and' and 'or' choices 86 with zero filter elements. 88 An 'and' filter consisting of an empty set of filters SHALL evaluate 89 to True. This filter is represented by the string "(&)". 91 An 'or' filter consisting of an empty set of filters SHALL evaluate to 92 False. This filter is represented by the string "(|)". 94 Servers supporting this feature SHOULD publish the Object Identifier 95 1.3.6.1.4.1.4203.1.5.3 as a value of the 'supportedFeatures' [RFC3674] 96 attribute in the root DSE. 98 Clients supporting this feature SHOULD NOT use the feature unless they 99 have knowledge the server supports it. 101 3. Security Considerations 103 The (re)introduction of absolute True and False filters is not 104 believed to raise any new security considerations. 106 Implementors of this (or any) LDAPv3 extension should be familiar with 107 general LDAPv3 security considerations [Roadmap]. 109 4. IANA Considerations 111 Registration of this feature is requested [BCP64bis]. 113 Subject: Request for LDAP Protocol Mechanism Registration 114 Object Identifier: 1.3.6.1.4.1.4203.1.5.3 115 Description: True/False filters 116 Person & email address to contact for further information: 117 Kurt Zeilenga 118 Usage: Feature 119 Specification: RFC XXXX 120 Author/Change Controller: IESG 121 Comments: none 123 This OID was assigned [ASSIGN] by OpenLDAP Foundation, under its 124 IANA-assigned private enterprise allocation [PRIVATE], for use in this 125 specification. 127 5. Author's Address 129 Kurt D. Zeilenga 130 OpenLDAP Foundation 131 133 6. References 135 [[Note to the RFC Editor: please replace the citation tags used in 136 referencing Internet-Drafts with tags of the form RFCnnnn where 137 possible.]] 139 6.1. Normative References 141 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 142 Requirement Levels", BCP 14 (also RFC 2119), March 1997. 144 [Roadmap] Zeilenga, K. (editor), "LDAP: Technical Specification 145 Road Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in 146 progress. 148 [Protocol] Sermersheim, J. (editor), "LDAP: The Protocol", 149 draft-ietf-ldapbis-protocol-xx.txt, a work in progress. 151 [Models] Zeilenga, K. (editor), "LDAP: Directory Information 152 Models", draft-ietf-ldapbis-models-xx.txt, a work in 153 progress. 155 [Filters] Smith, M. (editor), LDAPbis WG, "LDAP: String 156 Representation of Search Filters", 157 draft-ietf-ldapbis-filter-xx.txt, a work in progress. 159 [Features] Zeilenga, K., "Feature Discovery in LDAP", RFC 3674, 160 December 2003. 162 6.2. Informative References 164 [RFC1777] Yeong, W., Howes, T., and S. Kille, "Lightweight 165 Directory Access Protocol", RFC 1777, March 1995. 167 [RFC1960] Howes, T., "A String Representation of LDAP Search 168 Filters", RFC 1960, June 1996. 170 [BCP64bis] Zeilenga, K., "IANA Considerations for LDAP", 171 draft-ietf-ldapbis-bcp64-xx.txt, a work in progress. 173 [RFC3494] Zeilenga, K., "Lightweight Directory Access Protocol 174 version 2 (LDAPv2) to Historic Status", RFC 3494, March 175 2003. 177 [X.500] International Telecommunication Union - 178 Telecommunication Standardization Sector, "The Directory 179 -- Overview of concepts, models and services," 180 X.500(1993) (also ISO/IEC 9594-1:1994). 182 [X.501] International Telecommunication Union - 183 Telecommunication Standardization Sector, "The Directory 184 -- Models," X.501(1993) (also ISO/IEC 9594-2:1994). 186 [X.511] International Telecommunication Union - 187 Telecommunication Standardization Sector, "The 188 Directory: Abstract Service Definition", X.511(1993) 189 (also ISO/IEC 9594-3:1993). 191 [ASSIGN] OpenLDAP Foundation, "OpenLDAP OID Delegations", 192 http://www.openldap.org/foundation/oid-delegate.txt. 194 [PRIVATE] IANA, "Private Enterprise Numbers", 195 http://www.iana.org/assignments/enterprise-numbers. 197 Intellectual Property Rights 199 The IETF takes no position regarding the validity or scope of any 200 Intellectual Property Rights or other rights that might be claimed to 201 pertain to the implementation or use of the technology described in 202 this document or the extent to which any license under such rights 203 might or might not be available; nor does it represent that it has 204 made any independent effort to identify any such rights. Information 205 on the procedures with respect to rights in RFC documents can be found 206 in BCP 78 and BCP 79. 208 Copies of IPR disclosures made to the IETF Secretariat and any 209 assurances of licenses to be made available, or the result of an 210 attempt made to obtain a general license or permission for the use of 211 such proprietary rights by implementers or users of this specification 212 can be obtained from the IETF on-line IPR repository at 213 http://www.ietf.org/ipr. 215 The IETF invites any interested party to bring to its attention any 216 copyrights, patents or patent applications, or other proprietary 217 rights that may cover technology that may be required to implement 218 this standard. Please address the information to the IETF at 219 ietf-ipr@ietf.org. 221 Full Copyright 223 Copyright (C) The Internet Society (2005). This document is subject 224 to the rights, licenses and restrictions contained in BCP 78, and 225 except as set forth therein, the authors retain all their rights. 227 This document and the information contained herein are provided on an 228 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 229 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 230 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 231 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 232 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 233 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.