idnits 2.17.1 draft-zeilenga-ldap-t-f-09.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 21. -- Found old boilerplate from RFC 3978, Section 5.5 on line 231. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 204. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 211. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 217. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 223), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 37. ** 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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == It seems as if not all pages are separated by form feeds - found 0 form feeds but 6 pages 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 (24 October 2004) is 7123 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 93, but not defined ** Obsolete undefined reference: RFC 3674 (Obsoleted by RFC 4512) == Unused Reference: 'Features' is defined on line 157, 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: 10 errors (**), 0 flaws (~~), 5 warnings (==), 18 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Kurt D. Zeilenga 2 Intended Category: Standard Track OpenLDAP Foundation 3 Expires in six months 24 October 2004 5 LDAP Absolute True and False Filters 6 8 Status of this Memo 10 This document is intended to be, after appropriate review and 11 revision, submitted to the RFC Editor as a Standard Track document. 12 Distribution of this memo is unlimited. Technical discussion of this 13 document will take place on the IETF LDAP Extensions mailing list 14 . Please send editorial comments directly to the 15 author . 17 By submitting this Internet-Draft, I accept the provisions of Section 18 4 of RFC 3667. By submitting this Internet-Draft, I certify that any 19 applicable patent or other IPR claims of which I am aware have been 20 disclosed, or will be disclosed, and any of which I become aware will 21 be disclosed, in accordance with RFC 3668. 23 Internet-Drafts are working documents of the Internet Engineering Task 24 Force (IETF), its areas, and its working groups. Note that other 25 groups may also distribute working documents as Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference material 30 or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 . The list of 34 Internet-Draft Shadow Directories can be accessed at 35 . 37 Copyright (C) The Internet Society (2004). All Rights Reserved. 39 Please see the Full Copyright section near the end of this document 40 for more information. 42 Abstract 44 This document extends the Lightweight Directory Access Protocol (LDAP) 45 to support absolute True and False filters based upon similar 46 capabilities found in X.500 directory systems. The document also 47 extends the String Representation of LDAP Search Filters to support 48 these filters. 50 1. Background 52 The X.500 Directory Access Protocol (DAP) [X.511] supports absolute 53 True and False assertions. An 'and' filter with zero elements always 54 evaluates to True. An 'or' filter with zero elements always evaluates 55 to False. These filters are commonly used when requesting DSA- 56 specific Entries (DSEs) which do not necessarily have 'objectClass' 57 attributes. That is, where "(objectClass=*)" may evaluate to False. 59 While LDAPv2 [RFC1777][RFC3494] placed no restriction on the number of 60 elements in 'and' and 'or' filter sets, the LDAPv2 string 61 representation [RFC1960][RFC3494] could not represent empty 'and' and 62 'or' filter sets. Due to this, absolute True or False filters were 63 (unfortunately) eliminated from LDAPv3 [Roadmap]. 65 This documents extends LDAPv3 to support absolute True and False 66 assertions by allowing empty 'and' and 'or' in Search filters 67 [Protocol] and extends the filter string representation [Filters] to 68 allow empty filter lists. 70 It is noted that certain search operations, such as those used to 71 retrieve subschema subschema information [Models], require use of 72 particular filters. This document does not change these requirements. 74 This feature is intended to allow a more direct mapping between DAP 75 and LDAP (as needed to implement DAP-to-LDAP gateways). 77 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 78 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 79 document are to be interpreted as described in BCP 14 [RFC2119]. 81 2. Absolute True and False Filters 83 Implementations of this extension SHALL allow 'and' and 'or' choices 84 with zero filter elements. 86 An 'and' filter consisting of an empty set of filters SHALL evaluate 87 to True. This filter is represented by the string "(&)". 89 An 'or' filter consisting of an empty set of filters SHALL evaluate to 90 False. This filter is represented by the string "(|)". 92 Servers supporting this feature SHOULD publish the Object Identifier 93 1.3.6.1.4.1.4203.1.5.3 as a value of the 'supportedFeatures' [RFC3674] 94 attribute in the root DSE. 96 Clients supporting this feature SHOULD NOT use the feature unless they 97 have knowledge the server supports it. 99 3. Security Considerations 101 The (re)introduction of absolute True and False filters is not 102 believed to raise any new security considerations. 104 Implementors of this (or any) LDAPv3 extension should be familiar with 105 general LDAPv3 security considerations [Roadmap]. 107 4. IANA Considerations 109 Registration of this feature is requested [BCP64bis]. 111 Subject: Request for LDAP Protocol Mechanism Registration 112 Object Identifier: 1.3.6.1.4.1.4203.1.5.3 113 Description: True/False filters 114 Person & email address to contact for further information: 115 Kurt Zeilenga 116 Usage: Feature 117 Specification: RFC XXXX 118 Author/Change Controller: IESG 119 Comments: none 121 This OID was assigned [ASSIGN] by OpenLDAP Foundation, under its 122 IANA-assigned private enterprise allocation [PRIVATE], for use in this 123 specification. 125 5. Author's Address 127 Kurt D. Zeilenga 128 OpenLDAP Foundation 129 131 6. References 133 [[Note to the RFC Editor: please replace the citation tags used in 134 referencing Internet-Drafts with tags of the form RFCnnnn where 135 possible.]] 137 6.1. Normative References 139 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 140 Requirement Levels", BCP 14 (also RFC 2119), March 1997. 142 [Roadmap] Zeilenga, K. (editor), "LDAP: Technical Specification 143 Road Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in 144 progress. 146 [Protocol] Sermersheim, J. (editor), "LDAP: The Protocol", 147 draft-ietf-ldapbis-protocol-xx.txt, a work in progress. 149 [Models] Zeilenga, K. (editor), "LDAP: Directory Information 150 Models", draft-ietf-ldapbis-models-xx.txt, a work in 151 progress. 153 [Filters] Smith, M. (editor), LDAPbis WG, "LDAP: String 154 Representation of Search Filters", 155 draft-ietf-ldapbis-filter-xx.txt, a work in progress. 157 [Features] Zeilenga, K., "Feature Discovery in LDAP", RFC 3674, 158 December 2003. 160 6.2. Informative References 162 [RFC1777] Yeong, W., Howes, T., and S. Kille, "Lightweight 163 Directory Access Protocol", RFC 1777, March 1995. 165 [RFC1960] Howes, T., "A String Representation of LDAP Search 166 Filters", RFC 1960, June 1996. 168 [BCP64bis] Zeilenga, K., "IANA Considerations for LDAP", 169 draft-ietf-ldapbis-bcp64-xx.txt, a work in progress. 171 [RFC3494] Zeilenga, K., "Lightweight Directory Access Protocol 172 version 2 (LDAPv2) to Historic Status", RFC 3494, March 173 2003. 175 [X.500] International Telecommunication Union - 176 Telecommunication Standardization Sector, "The Directory 177 -- Overview of concepts, models and services," 178 X.500(1993) (also ISO/IEC 9594-1:1994). 180 [X.501] International Telecommunication Union - 181 Telecommunication Standardization Sector, "The Directory 182 -- Models," X.501(1993) (also ISO/IEC 9594-2:1994). 184 [X.511] International Telecommunication Union - 185 Telecommunication Standardization Sector, "The 186 Directory: Abstract Service Definition", X.511(1993) 187 (also ISO/IEC 9594-3:1993). 189 [ASSIGN] OpenLDAP Foundation, "OpenLDAP OID Delegations", 190 http://www.openldap.org/foundation/oid-delegate.txt. 192 [PRIVATE] IANA, "Private Enterprise Numbers", 193 http://www.iana.org/assignments/enterprise-numbers. 195 Intellectual Property Rights 197 The IETF takes no position regarding the validity or scope of any 198 Intellectual Property Rights or other rights that might be claimed to 199 pertain to the implementation or use of the technology described in 200 this document or the extent to which any license under such rights 201 might or might not be available; nor does it represent that it has 202 made any independent effort to identify any such rights. Information 203 on the procedures with respect to rights in RFC documents can be found 204 in BCP 78 and BCP 79. 206 Copies of IPR disclosures made to the IETF Secretariat and any 207 assurances of licenses to be made available, or the result of an 208 attempt made to obtain a general license or permission for the use of 209 such proprietary rights by implementers or users of this specification 210 can be obtained from the IETF on-line IPR repository at 211 http://www.ietf.org/ipr. 213 The IETF invites any interested party to bring to its attention any 214 copyrights, patents or patent applications, or other proprietary 215 rights that may cover technology that may be required to implement 216 this standard. Please address the information to the IETF at 217 ietf-ipr@ietf.org. 219 Full Copyright 221 Copyright (C) The Internet Society (2004). This document is subject 222 to the rights, licenses and restrictions contained in BCP 78, and 223 except as set forth therein, the authors retain all their rights. 225 This document and the information contained herein are provided on an 226 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 227 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 228 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 229 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 230 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 231 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.