idnits 2.17.1 draft-ietf-asid-ldapv3-filter-02.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): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** 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? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 5 longer pages, the longest (page 2) being 59 lines 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 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 73: '... matchingRule [1] MatchingRuleID OPTIONAL,...' RFC 2119 keyword, line 74: '... type [2] AttributeDescription OPTIONAL,...' == The 'Obsoletes: ' line in the draft header should list only the _numbers_ of the RFCs which will be obsoleted by this document (if approved); it should not include the word 'RFC' in the list. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 11 has weird spacing: '...fts are worki...' == Line 12 has weird spacing: '...ments of the ...' == Line 13 has weird spacing: '...t other group...' == Line 17 has weird spacing: '...and may be ...' == Line 21 has weird spacing: '...atus of any ...' == (36 more instances...) -- 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 (May 1997) is 9842 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: '0' is mentioned on line 61, but not defined == Missing Reference: '6' is mentioned on line 52, but not defined == Missing Reference: '7' is mentioned on line 53, but not defined == Missing Reference: '8' is mentioned on line 54, but not defined == Missing Reference: '9' is mentioned on line 55, but not defined == Outdated reference: A later version (-09) exists of draft-ietf-asid-ldapv3-protocol-04 == Outdated reference: A later version (-07) exists of draft-ietf-asid-ldapv3-attributes-04 -- Possible downref: Non-RFC (?) normative reference: ref. '3' ** Obsolete normative reference: RFC 822 (ref. '5') (Obsoleted by RFC 2822) Summary: 13 errors (**), 0 flaws (~~), 16 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Tim Howes 3 INTERNET DRAFT Netscape Communications Corp. 4 OBSOLETES: RFC 1960 May 1997 6 The String Representation of LDAP Search Filters 7 9 1. Status of this Memo 11 This document is an Internet-Draft. Internet-Drafts are working docu- 12 ments of the Internet Engineering Task Force (IETF), its areas, and its 13 working groups. Note that other groups may also distribute working 14 documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet- Drafts as reference material 19 or to cite them other than as ``work in progress.'' 21 To learn the current status of any Internet-Draft, please check the 22 ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow 23 Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), 24 ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 26 2. Abstract 28 The Lightweight Directory Access Protocol (LDAP) [1] defines a network 29 representation of a search filter transmitted to an LDAP server. Some 30 applications may find it useful to have a common way of representing 31 these search filters in a human-readable form. This document defines a 32 human-readable string format for representing LDAP search filters. 34 This document replaces RFC 1960, extending the string LDAP filter defin- 35 ition to include support for LDAP version 3 extended match filters, and 36 including support for representing the full range of possible LDAP 37 search filters. 39 RFC DRAFT May 1997 41 3. LDAP Search Filter Definition 43 An LDAPv3 search filter is defined in Section 4.5.1 of [1] as follows: 45 Filter ::= CHOICE { 46 and [0] SET OF Filter, 47 or [1] SET OF Filter, 48 not [2] Filter, 49 equalityMatch [3] AttributeValueAssertion, 50 substrings [4] SubstringFilter, 51 greaterOrEqual [5] AttributeValueAssertion, 52 lessOrEqual [6] AttributeValueAssertion, 53 present [7] AttributeDescription, 54 approxMatch [8] AttributeValueAssertion, 55 extensibleMatch [9] MatchingRuleAssertion 56 } 58 SubstringFilter ::= SEQUENCE { 59 type AttributeDescription, 60 SEQUENCE OF CHOICE { 61 initial [0] LDAPString, 62 any [1] LDAPString, 63 final [2] LDAPString 64 } 65 } 67 AttributeValueAssertion ::= SEQUENCE { 68 attributeDesc AttributeDescription, 69 attributeValue AttributeValue 70 } 72 MatchingRuleAssertion ::= SEQUENCE { 73 matchingRule [1] MatchingRuleID OPTIONAL, 74 type [2] AttributeDescription OPTIONAL, 75 matchValue [3] AssertionValue, 76 dnAttributes [4] BOOLEAN DEFAULT FALSE 77 } 79 AttributeDescription ::= LDAPString 81 AttributeValue ::= OCTET STRING 83 MatchingRuleID ::= LDAPString 85 AssertionValue ::= OCTET STRING 87 LDAPString ::= OCTET STRING 89 RFC DRAFT May 1997 91 where the LDAPString above is limited to the UTF-8 encoding of the ISO 92 10646 character set [4]. The AttributeDescription is a string represen- 93 tation of the attribute description and is defined in [1]. The Attribu- 94 teValue and AssertionValue OCTET STRING have the form defined in [2]. 95 The Filter is encoded for transmission over a network using the Basic 96 Encoding Rules defined in [3], with simplifications described in [1]. 98 4. String Search Filter Definition 100 The string representation of an LDAP search filter is defined by the 101 following grammar, following the ABNF notation defined in [5]. The 102 filter format uses a prefix notation. 104 filter = "(" filtercomp ")" 105 filtercomp = and / or / not / item 106 and = "&" filterlist 107 or = "|" filterlist 108 not = "!" filter 109 filterlist = 1*filter 110 item = simple / present / substring / extensible 111 simple = attr filtertype value 112 filtertype = equal / approx / greater / less 113 equal = "=" 114 approx = "~=" 115 greater = ">=" 116 less = "<=" 117 extensible = attr [":dn"] [":" matchingrule] ":=" value 118 / [":dn"] ":" matchingrule ":=" value 119 present = attr "=*" 120 substring = attr "=" [initial] any [final] 121 initial = value 122 any = "*" *(value "*") 123 final = value 124 attr = AttributeDescription from Section 4.1.5 of [1] 125 matchingrule = MatchingRuleId from Section 4.1.9 of [1] 126 value = AttributeValue from Section 4.1.6 of [1] 128 The attr, matchingrule, and value constructs are as described in the 129 corresponding section of [1] given above. 131 RFC DRAFT May 1997 133 If a value should contain any of the following characters 135 Character ASCII value 136 --------------------------- 137 * 0x2a 138 ( 0x28 139 ) 0x29 140 \ 0x5c 141 NUL 0x00 143 the character must be encoded as the backslash '\' character (ASCII 144 0x5c) followed by the two hexadecimal digits representing the ASCII 145 value of the encoded character. The case of the two hexadecimal digits 146 is not significant. 148 This simple escaping mechanism eliminates filter-parsing ambiguities and 149 allows any filter that can be represented in LDAP to be represented as a 150 NUL-terminated string. Other characters besides the ones listed above 151 may be escaped using this mechanism, for example, non-printing charac- 152 ters. 154 For example, the filter checking whether the "cn" attribute contained a 155 value with the character "*" anywhere in it would be represented as 156 "(cn=*\2a*)". 158 Note that although both the substring and present productions in the 159 grammar above can produce the "attr=*" construct, this construct is used 160 only to denote a presence filter. 162 5. Examples 164 This section gives a few examples of search filters written using this 165 notation. 167 (cn=Babs Jensen) 168 (!(cn=Tim Howes)) 169 (&(objectClass=Person)(|(sn=Jensen)(cn=Babs J*))) 170 (o=univ*of*mich*) 172 The following examples illustrate the use of extensible matching. 174 (cn:1.2.3.4.5:=Fred Flintstone) 175 (sn:dn:2.4.6.8.10:=Barney Rubble) 176 (o:dn:=Ace Industry) 177 (:dn:2.4.6.8.10:=Dino) 179 The second example illustrates the use of the ":dn" notation to indicate 180 that matching rule "2.4.6.8.10" should be used when making comparisons, 181 RFC DRAFT May 1997 183 and that the attributes of an entry's distinguished name should be con- 184 sidered part of the entry when evaluating the match. 186 The third example denotes an equality match, except that DN components 187 should be considered part of the entry when doing the match. 189 The fourth example is a filter that should be applied to any attribute 190 supporting the matching rule given (since the attr has been left off). 191 Attributes supporting the matching rule contained in the DN should also 192 be considered. 194 The following examples illustrate the use of the escaping mechanism. 196 (o=Parens R Us \28for all your parenthetical needs\29) 197 (cn=*\2A*) 198 (filename=C:\5cMyFile) 199 (bin=\00\00\00\04) 200 (sn=Lu\c4\8di\c4\c7) 202 The first example shows the use of the escaping mechanism to represent 203 parenthesis characters. The second shows how to represent a "*" in a 204 value, preventing it from being interpreted as a substring indicator. 205 The third illustrates the escaping of the backslash character. 207 The fourth example shows a filter searching for the four-byte value 208 0x00000004, illustrating the use of the escaping mechanism to represent 209 arbitrary data, including NUL characters. 211 The final example illustrates the use of the escaping mechanism to 212 represent various non-ASCII UTF-8 characters. 214 6. Security Considerations 216 This memo describes a string representation of LDAP search filters. 217 While the representation itself has no known security implications, LDAP 218 search filters do. They are interpreted by LDAP servers to select 219 entries from which data is retrieved. LDAP servers should take care to 220 protect the data they maintain from unauthorized access. 222 7. References 224 [1] Lightweight Directory Access Protocol (v3), M. Wahl, T. Howes, S. 225 Kille, Internet Draft draft-ietf-asid-ldapv3-protocol-04.txt, 226 March, 1997. 228 [2] Lightweight Directory Access Protocol (v3): Attribute Syntax Defin- 229 itions, M. Wahl, A. Coulbeck, T. Howes, S. Kille, Internet Draft 230 draft-ietf-asid-ldapv3-attributes-04.txt, March, 1997. 232 RFC DRAFT May 1997 234 [3] Specification of ASN.1 encoding rules: Basic, Canonical, and Dis- 235 tinguished Encoding Rules, ITU-T Recommendation X.690, 1994. 237 [4] UTF-8, a transformation format of Unicode and ISO 10646, F. Yer- 238 geau, draft-yergeau-utf8-rev-00.txt, April, 1997. 240 [5] Standard for the Format of ARPA Internet Text Messages, D. Crocker, 241 RFC 822, August, 1982. 243 8. Author's Address 245 Tim Howes 246 Netscape Communications Corp. 247 501 E. Middlefield Road 248 Mountain View, CA 94043 249 USA 250 +1 415 937-3419 251 howes@netscape.com