idnits 2.17.1 draft-zeilenga-ldapv3bis-rfc2254-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 99: '... matchingRule [1] MatchingRuleID OPTIONAL,...' RFC 2119 keyword, line 100: '... type [2] AttributeDescription OPTIONAL,...' -- The abstract seems to indicate that this document obsoletes RFC1960, but the header doesn't have an 'Obsoletes:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 299 has weird spacing: '...for the purpo...' -- 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 (4 July 2000) is 8697 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) -- Looks like a reference, but probably isn't: 'RFC 2254' on line 42 == Missing Reference: '0' is mentioned on line 86, but not defined == Missing Reference: '6' is mentioned on line 77, but not defined == Missing Reference: '7' is mentioned on line 78, but not defined == Missing Reference: '8' is mentioned on line 79, but not defined == Missing Reference: '9' is mentioned on line 80, but not defined ** Obsolete normative reference: RFC 2251 (ref. '1') (Obsoleted by RFC 4510, RFC 4511, RFC 4512, RFC 4513) ** Obsolete normative reference: RFC 2252 (ref. '2') (Obsoleted by RFC 4510, RFC 4512, RFC 4517, RFC 4523) -- Possible downref: Non-RFC (?) normative reference: ref. '3' ** Obsolete normative reference: RFC 2044 (ref. '4') (Obsoleted by RFC 2279) ** Obsolete normative reference: RFC 822 (ref. '5') (Obsoleted by RFC 2822) Summary: 13 errors (**), 0 flaws (~~), 6 warnings (==), 5 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: 4 January 2001 4 July 2000 6 LDAPv3bis Suggestions: 7 The String Representation of LDAP Search Filters 8 10 Status of Memo 12 This document is an Internet-Draft and is in full conformance with all 13 provisions of Section 10 of RFC2026. 15 This document is intended to be, after appropriate review and 16 revision, submitted to the RFC Editor as a Standard Track document. 17 Distribution of this memo is unlimited. Technical discussion of this 18 document will take place on the IETF LDAP Extension Working Group 19 mailing list . Please send editorial 20 comments directly to the author . 22 Internet-Drafts are working documents of the Internet Engineering Task 23 Force (IETF), its areas, and its working groups. Note that other 24 groups may also distribute working documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as ``work in progress.'' 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft 32 Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 34 Copyright 2000, The Internet Society. All Rights Reserved. 36 Please see the Copyright section near the end of this document for 37 more information. 39 Forward 41 This Internet Draft suggests a number of updates to "The String 42 Representation of LDAP Search Filters" [RFC 2254]. This document is 43 not intended to be published as an RFC but used to identify LDAPv3bis 44 work items. 46 The remainer of this documents incorporates the substantive portion of 47 RFC 2254 text (less status of memo, appendices, etc). Comments and 48 suggested updates to this text are inserted as inline notes prefixed 49 with '//'. 51 // Start of RFC 2254 text 53 2. Abstract 55 The Lightweight Directory Access Protocol (LDAP) [1] defines a network 56 representation of a search filter transmitted to an LDAP server. Some 57 applications may find it useful to have a common way of representing 58 these search filters in a human-readable form. This document defines 59 a human-readable string format for representing LDAP search filters. 61 This document replaces RFC 1960, extending the string LDAP filter 62 definition to include support for LDAP version 3 extended match 63 filters, and including support for representing the full range of 64 possible LDAP search filters. 66 3. LDAP Search Filter Definition 68 An LDAPv3 search filter is defined in Section 4.5.1 of [1] as follows: 70 Filter ::= CHOICE { 71 and [0] SET OF Filter, 72 or [1] SET OF Filter, 73 not [2] Filter, 74 equalityMatch [3] AttributeValueAssertion, 75 substrings [4] SubstringFilter, 76 greaterOrEqual [5] AttributeValueAssertion, 77 lessOrEqual [6] AttributeValueAssertion, 78 present [7] AttributeDescription, 79 approxMatch [8] AttributeValueAssertion, 80 extensibleMatch [9] MatchingRuleAssertion 81 } 83 SubstringFilter ::= SEQUENCE { 84 type AttributeDescription, 85 SEQUENCE OF CHOICE { 86 initial [0] LDAPString, 87 any [1] LDAPString, 88 final [2] LDAPString 89 } 90 } 92 AttributeValueAssertion ::= SEQUENCE { 93 attributeDesc AttributeDescription, 94 attributeValue AttributeValue 96 } 98 MatchingRuleAssertion ::= SEQUENCE { 99 matchingRule [1] MatchingRuleID OPTIONAL, 100 type [2] AttributeDescription OPTIONAL, 101 matchValue [3] AssertionValue, 102 dnAttributes [4] BOOLEAN DEFAULT FALSE 103 } 105 AttributeDescription ::= LDAPString 107 AttributeValue ::= OCTET STRING 109 MatchingRuleID ::= LDAPString 111 AssertionValue ::= OCTET STRING 113 LDAPString ::= OCTET STRING 115 where the LDAPString above is limited to the UTF-8 encoding of the ISO 116 10646 character set [4]. The AttributeDescription is a string 117 representation of the attribute description and is defined in [1]. 118 The AttributeValue and AssertionValue OCTET STRING have the form 119 defined in [2]. The Filter is encoded for transmission over a network 120 using the Basic Encoding Rules defined in [3], with simplifications 121 described in [1]. 123 4. String Search Filter Definition 125 The string representation of an LDAP search filter is defined by the 126 following grammar, following the ABNF notation defined in [5]. The 127 filter format uses a prefix notation. 129 filter = "(" filtercomp ")" 130 filtercomp = and / or / not / item 131 and = "&" filterlist 132 or = "|" filterlist 133 not = "!" filter 134 filterlist = 1*filter 136 // replace (to support empty SET OF) with: 137 // filterlist = 0*filter 139 item = simple / present / substring / extensible 140 simple = attr filtertype value 141 filtertype = equal / approx / greater / less 142 equal = "=" 143 approx = "~=" 144 greater = ">=" 145 less = "<=" 146 extensible = attr [":dn"] [":" matchingrule] ":=" value 147 / [":dn"] ":" matchingrule ":=" value 148 present = attr "=*" 149 substring = attr "=" [initial] any [final] 150 initial = value 151 any = "*" *(value "*") 152 final = value 153 attr = AttributeDescription from Section 4.1.5 of [1] 154 matchingrule = MatchingRuleId from Section 4.1.9 of [1] 155 value = AttributeValue from Section 4.1.6 of [1] 157 The attr, matchingrule, and value constructs are as described in the 158 corresponding section of [1] given above. 160 If a value should contain any of the following characters 162 Character ASCII value 163 --------------------------- 164 * 0x2a 165 ( 0x28 166 ) 0x29 167 \ 0x5c 168 NUL 0x00 170 the character must be encoded as the backslash '\' character (ASCII 171 0x5c) followed by the two hexadecimal digits representing the ASCII 172 value of the encoded character. The case of the two hexadecimal digits 173 is not significant. 175 This simple escaping mechanism eliminates filter-parsing ambiguities 176 and allows any filter that can be represented in LDAP to be 177 represented as a NUL-terminated string. Other characters besides the 178 ones listed above may be escaped using this mechanism, for example, 179 non-printing characters. 181 For example, the filter checking whether the "cn" attribute contained 182 a value with the character "*" anywhere in it would be represented as 183 "(cn=*\2a*)". 185 Note that although both the substring and present productions in the 186 grammar above can produce the "attr=*" construct, this construct is 187 used only to denote a presence filter. 189 5. Examples 191 This section gives a few examples of search filters written using this 192 notation. 194 (cn=Babs Jensen) 195 (!(cn=Tim Howes)) 196 (&(objectClass=Person)(|(sn=Jensen)(cn=Babs J*))) 197 (o=univ*of*mich*) 199 // Add (for empty SET OF): 200 // The following filters evaluate to true or false, 201 // respectively. 202 // (&) 203 // (|) 205 The following examples illustrate the use of extensible matching. 207 (cn:1.2.3.4.5:=Fred Flintstone) 208 (sn:dn:2.4.6.8.10:=Barney Rubble) 209 (o:dn:=Ace Industry) 210 (:dn:2.4.6.8.10:=Dino) 212 The second example illustrates the use of the ":dn" notation to 213 indicate that matching rule "2.4.6.8.10" should be used when making 214 comparisons, and that the attributes of an entry's distinguished name 215 should be considered part of the entry when evaluating the match. 217 The third example denotes an equality match, except that DN components 218 should be considered part of the entry when doing the match. 220 The fourth example is a filter that should be applied to any attribute 221 supporting the matching rule given (since the attr has been left off). 222 Attributes supporting the matching rule contained in the DN should 223 also be considered. 225 The following examples illustrate the use of the escaping mechanism. 227 (o=Parens R Us \28for all your parenthetical needs\29) 228 (cn=*\2A*) 229 (filename=C:\5cMyFile) 230 (bin=\00\00\00\04) 231 (sn=Lu\c4\8di\c4\87) 233 The first example shows the use of the escaping mechanism to represent 234 parenthesis characters. The second shows how to represent a "*" in a 235 value, preventing it from being interpreted as a substring indicator. 236 The third illustrates the escaping of the backslash character. 238 The fourth example shows a filter searching for the four-byte value 239 0x00000004, illustrating the use of the escaping mechanism to 240 represent arbitrary data, including NUL characters. 242 The final example illustrates the use of the escaping mechanism to 243 represent various non-ASCII UTF-8 characters. 245 6. Security Considerations 247 // Add consideration requiring the use of strong authentication 248 // to update the directory. 250 This memo describes a string representation of LDAP search filters. 251 While the representation itself has no known security implications, 252 LDAP search filters do. They are interpreted by LDAP servers to select 253 entries from which data is retrieved. LDAP servers should take care 254 to protect the data they maintain from unauthorized access. 256 7. References 258 [1] Wahl, M., Howes, T., and S. Kille, "Lightweight Directory Access 259 Protocol (v3)", RFC 2251, December 1997. 261 [2] Wahl, M., Coulbeck, A., Howes, T., and S. Kille, "Lightweight 262 Directory Access Protocol (v3): Attribute Syntax Definitions", RFC 263 2252, December 1997. 265 [3] Specification of ASN.1 encoding rules: Basic, Canonical, and 266 Distinguished Encoding Rules, ITU-T Recommendation X.690, 1994. 268 [4] Yergeau, F., "UTF-8, a transformation format of Unicode and ISO 269 10646", RFC 2044, October 1996. 271 [5] Crocker, D., "Standard for the Format of ARPA Internet Text 272 Messages", STD 11, RFC 822, August 1982. 274 // Remainder trimmed 275 // End of RFC 2254 text 277 Additional Information 279 Discussions regarding these suggestions may directed to the author: 281 Kurt D. Zeilenga 282 OpenLDAP Foundation 283 285 or the LDAPext Working Group mailing list: 287 289 Copyright 2000, The Internet Society. All Rights Reserved. 291 This document and translations of it may be copied and furnished 292 to others, and derivative works that comment on or otherwise explain 293 it or assist in its implementation may be prepared, copied, published 294 and distributed, in whole or in part, without restriction of any 295 kind, provided that the above copyright notice and this paragraph 296 are included on all such copies and derivative works. However, 297 this document itself may not be modified in any way, such as by 298 removing the copyright notice or references to the Internet Society 299 or other Internet organizations, except as needed for the purpose 300 of developing Internet standards in which case the procedures for 301 copyrights defined in the Internet Standards process must be 302 followed, or as required to translate it into languages other than 303 English. 305 The limited permissions granted above are perpetual and will not 306 be revoked by the Internet Society or its successors or assigns. 308 This document and the information contained herein is provided on 309 an "AS IS" basis and THE AUTHORS, THE INTERNET SOCIETY, AND THE 310 INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS 311 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE 312 OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY 313 IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR 314 PURPOSE.